회고
FE 개발자 면접 준비 (2)
프론트엔드 개발자 면접에서는 프로젝트 경험뿐만 아니라, 기술 선택의 이유와 구현 방법, 그리고 문제 해결 과정까지 깊이 있게 물어보는 경우가 많습니다. 이번 글에서는 제가 준비한 기술 중심의 면접 질문과 답변 예시를 정리했습니다. 상태 관리, API 통신, 성능 최적화, 접근성, CI/CD 등 다양한 주제를 다루었으니, 프론트엔드 면접을 준비하는 분들에게 조금이나마 도움이 되길 바랍니다.
예상 질문 및 답변
Q. 타입 안정성과 유지보수성을 강화한 경험이 있나요?
A. 네 있습니다. 최근 진행한 학습 프로젝트에서 Next.js와 TypeScript를 도입해 타입 안정성과 유지보수성을 높이는 연습을 했습니다. 기존에는 JavaScript로만 개발해 API 응답 값이나 컴포넌트 props의 타입 오류를 런타임에서 발견하는 경우가 많았습니다. 이에 따라 API 응답 구조를 interface와 type으로 정의하고, 공용 타입을 별도 파일로 분리하여 전역적으로 재사용했습니다. 또한 컴포넌트 props에 제네릭과 Optional Chaining을 적용해, 타입 추론만으로도 오류를 사전에 방지할 수 있도록 했습니다. 그 결과, 빌드 단계에서 오류를 바로 잡을 수 있었고, 컴포넌트 수정 시 다른 부분에 미치는 영향을 IDE 자동완성으로 즉시 확인할 수 있어 유지보수가 훨씬 수월해졌습니다.
Q. Next.js에서 이미지 최적화를 어떻게 했나요?
A. Next.js의 <Image> 컴포넌트를 사용해 자동 리사이징·포맷 변환(WebP/AVIF)·지연 로딩을 적용했습니다. width/height와 sizes를 명시해서 뷰포트별 적정 해상도가 내려가도록 했고, 접속 빈도가 높은 이미지는 priority로 LCP 개선을 노렸습니다. 리스트 썸네일은 기본 lazy 동작으로 불필요한 초기 다운로드를 줄여서 사용한 적이 있습니다.
Q. 컴포넌트를 재사용 가능하게 만들기 위해 어떤 방법을 쓰나요?
A. 컴포넌트를 만들 때 가장 중요한 건 복잡하지 않게 하는 것입니다. 작은 기능은 최대한 세분화해서 컴포넌트를 설계하고, 필요한 값과 선택적인 값을 구분합니다. 선택적인 값에는 기본값을 지정해, 별도 설정 없이도 동작하도록 합니다. UI는 단순하게 유지하고, 복잡한 로직은 커스텀 훅으로 분리해 재사용성과 유지보수성을 높입니다.
접근성을 고려한 경험이 있나요?
A. 접근성을 위해 시맨틱 태그와 키보드 포커스를 기본 원칙으로 적용한 경험이 있습니다. 예를 들어 의미 있는 이미지는 반드시 alt 속성을 작성해 스크린리더가 내용을 전달할 수 있도록 했습니다. 또, 키보드 사용자들이 불편 없이 탐색할 수 있도록 포커스 순서를 확인하고, 모달이나 특정 영역에서는 포커스 트랩을 적용해 포커스가 의도한 범위를 벗어나지 않게 했습니다. 이런 기본적인 접근성 규칙을 프로젝트에 반영하면서, 더 많은 사용자가 편하게 이용할 수 있도록 노력했습니다.
컴포넌트 구조를 설계할 때 어떤 기준을 세우나요?
A. 컴포넌트 구조를 설계할 때는 먼저 단일 책임 원칙을 기준으로 합니다. 하나의 컴포넌트가 한 가지 역할만 하도록 하고, 화면의 기능과 UI 단위를 기준으로 세분화합니다. 또, 재사용성을 고려해 비즈니스 로직은 커스텀 훅으로 분리하고, UI는 컴포넌트로 단순하게 유지합니다. 스타일은 공통 컴포넌트나 유틸 클래스로 관리해, 변경 시 다른 부분에 영향을 최소화합니다. 마지막으로, 폴더 구조와 네이밍을 명확히 해서 협업 시에도 쉽게 이해하고 수정할 수 있도록 합니다
API 통신 안정성을 위해 어떤 방법을 사용했나요?
A. API 통신 시에는 Axios를 기반으로 공용 인스턴스를 만들고, 인터셉터를 활용해 요청/응답을 일괄 처리했습니다. 응답 데이터는 TypeScript 인터페이스로 구조를 정의해, 타입 오류를 빌드 단계에서 잡을 수 있도록 했습니다. 에러 상황에서는 상태 코드별 메시지를 사용자에게 전달하며 안전성을 고려했습니다.
상태 관리를 어떤 기준으로 선택하고 적용했나요?
A. 상태 관리 도구는 데이터의 범위와 변경 빈도에 따라 선택했습니다. 전역 상태 관리가 필요한 경우에는 Recoil을 사용했습니다. Recoil은 atom 단위로 상태를 관리하고, selector로 파생 상태를 계산할 수 있어 구조를 단순하게 유지할 수 있었습니다. 예를 들어 로그인 사용자 정보나 다수의 컴포넌트에서 동시에 사용하는 필터 상태를 atom으로 분리해, 필요한 컴포넌트만 리렌더링되도록 했습니다. 반면 페이지나 컴포넌트 한정 데이터는 React의 로컬 상태를 사용했습니다.
반응형 UI 구현 시 어떤 접근 방식을 사용했나요?
A. Tailwind CSS의 반응형 유틸리티 클래스를 사용해 모바일 퍼스트 방식으로 설계했습니다. 기본 스타일은 모바일에 맞추고, 화면 크기에 따라 md:, lg: 프리픽스를 붙여 데스크톱 레이아웃을 적용했습니다. 또한 CSS Grid와 Flexbox를 조합해 레이아웃을 단순하게 유지했습니다.
빌드나 배포 과정에서 마주한 문제와 해결 방법은 무엇인가요?
A. Vercel 배포 과정에서 환경 변수가 누락되어 API 호출이 실패한 적이 있습니다. 이를 해결하기 위해 .env 예시 파일을 프로젝트에 포함시켜 팀원들이 동일한 환경 변수를 설정할 수 있게 했고, 빌드 스크립트 실행 전 환경 변수 유효성을 검사하는 로직을 추가했습니다
실시간 데이터나 동기화가 필요한 기능을 구현한 경험이 있나요?
A. 네, 실시간 데이터나 동기화가 필요한 기능을 구현한 경험이 있습니다. 처음에는 setInterval이나 setTimeout을 사용해서 일정 주기마다 API를 요청하는 방법을 고려했습니다. 하지만 이 방식은 코드가 복잡해지고, 요청 관리가 번거로웠습니다. 이후 React Query의 refetchInterval 기능을 알게 되어 적용했는데, 이를 통해 원하는 주기마다 자동으로 데이터를 갱신할 수 있었고, 탭이 비활성화될 경우 불필요한 요청을 줄일 수도 있었습니다. 결과적으로 최신 상태를 안정적으로 유지하면서도 코드의 가독성과 유지보수성을 개선할 수 있었습니다.
GitHub Actions 또는 Vercel에서 CI/CD를 구축한 경험이 있나요?
A. 네, 실제로 GitHub Actions와 Vercel을 이용해 CI/CD 파이프라인을 구축한 경험이 있습니다. 먼저 GitHub Actions의 워크플로우를 설정해서 Pull Request가 생성되면 자동으로 빌드, 린트, 테스트가 실행되도록 했습니다. 이후 main 브랜치로 병합되면 Vercel이 자동 배포되도록 구성해서, 코드 변경이 실시간 서비스에 반영되도록 했어요. 덕분에 오류가 있는 코드가 바로 드러나고, 안전하게 배포할 수 있게 되었습니다. 이런 경험을 통해 CI/CD가 복잡한 개념이 아니라 효율을 높여주는 실질적인 자동화 도구임을 직접 체감할 수 있었습니다.
Q. Form 데이터 검증을 어떻게 구현했나요? (ex: 회원가입, 게시물 작성)
A. 데이터 검증 로직은 커스텀 훅으로 분리해 재사용성을 높였습니다. 예를 들어 회원가입 시에는 이름, 이메일, 비밀번호 등 각 필드별로 정규식 패턴과 최소/최대 길이 조건을 설정했고, 입력 값이 변경될 때마다 실시간으로 유효성을 검사했습니다. 오류가 있으면 즉시 시각적 피드백(에러 메시지나 강조 표시)을 제공해 사용자가 즉시 수정할 수 있게 했습니다. 이렇게 하면 코드 중복을 줄이고, 다른 Form에도 쉽게 적용할 수 있었습니다.
Q. API 요청 중 로딩 상태를 사용자에게 어떻게 표시했나요?
A. API 요청이 발생하면 전역 상태나 컴포넌트 상태에서 로딩 플래그를 관리하고, 해당 상태에 따라 UI를 다르게 표시했습니다. 단순 텍스트 데이터의 경우 로딩 스피너를, 이미지나 카드 목록 같은 경우는 스켈레톤 UI를 사용했습니다. 특히 이미지가 중요한 페이지에서는 스켈레톤을 적용해 초기 로딩 시 레이아웃이 깨지지 않도록 했습니다.
Q. 협업 과정에서 UI/UX 관련 의견 차이가 있었을 때 어떻게 조율했나요?
A. 의견 차이가 생기면 주관적인 감각보다 데이터와 근거를 바탕으로 논의했습니다. 예를 들어 버튼 위치나 색상에 대한 이견이 있을 경우, 사용자 테스트 결과나 레퍼런스 서비스의 디자인 가이드를 근거로 설명했습니다. 또한, Figma에서 여러 버전을 시뮬레이션한 뒤 팀원들이 직접 비교하도록 해 가장 직관적이고 효율적인 안을 선택했습니다. 이렇게 하면 감정적인 갈등 없이 객관적으로 결론을 내릴 수 있었습니다.
Q. JWT를 이용한 인증/인가 로직을 구현해본 경험이 있나요?
A. 네, 구글 로그인 후 Google Access Token을 백엔드로 전달하고, 서버에서 자체 Access Token과 Refresh Token을 발급받는 구조를 구현했습니다. Refresh Token은 DB에 저장하고, Access Token이 만료되면 Refresh Token으로 재발급받아 세션을 유지했습니다. 이를 통해 사용자가 재로그인 없이 장기간 서비스를 이용할 수 있도록 했고, 보안을 위해 Refresh Token은 암호화하여 저장했습니다.
Q. 배포 후 발견된 버그를 어떻게 추적하고 수정했나요?
A. 배포 후 QA 단계에서 발견된 버그는 우선 재현 과정을 문서화해 팀원과 공유했습니다. 이후 콘솔 로그와 네트워크 탭을 활용해 API 응답, 상태 변화, DOM 렌더링 순서를 분석했습니다. 문제가 해결되면 테스트 코드를 작성하거나 해당 부분의 예외 처리를 강화해 동일한 이슈가 재발하지 않도록 했습니다.
피드백
경험 기반
단순 개념 설명이 아니라 “언제, 왜, 어떻게” 적용했는지가 들어가 있어서 신뢰감이 높습니다.
구체적인 기술 명시
React Query, Recoil, Tailwind CSS, Optional Chaining, refetchInterval 등 실무적인 키워드가 잘 나왔습니다.
문제-해결-결과 구조
기존 문제점 → 해결 방법 → 얻은 효과 순으로 답변이 구성되어 있어 전달력이 높습니다.
개선 포인트
답변 길이 조정
면접에서는 30~40초 내에 핵심만 전달하고, 세부 내용은 꼬리 질문 때 설명하는 게 좋습니다.
효과·성과 강조
“유지보수성이 좋아졌다” 보다는 “유지보수 시간 30% 단축”처럼 수치나 체감 효과를 주면 더 설득력 있습니다.
중복 표현 정리
예: “유지보수성이 좋아졌다”는 표현이 여러 답변에서 반복됨 → 다양하게 표현.
용어 정리
<Image> 같은 JSX 태그는 말로 “Next.js Image 컴포넌트”라고 풀어서 말하는 게 구술형 면접에 적합합니다.
면접 준비는 단순히 답변을 암기하는 것이 아니라, 실제 경험을 바탕으로 왜 그렇게 했는지, 어떤 결과를 얻었는지를 설명할 수 있어야 합니다. 이번에 정리한 기술 질문들은 저의 경험을 토대로 작성했지만, 읽는 분들이 자신의 프로젝트와 상황에 맞게 변형해서 사용하면 더 큰 효과를 볼 수 있습니다. 이 글이 여러분의 기술 면접 준비에 작은 발판이 되길 바라며, 앞으로도 다양한 주제를 공유하겠습니다.