프론트엔드 개발자 면접 질문 — 실제로 나오는 5가지 유형과 연차별 준비법

JavaScript 동작 원리, 브라우저 렌더링, 상태관리와 리렌더링, 성능, CSS·레이아웃의 다섯 유형이에요. 여기에 이력서 프로젝트 딥다이브가 얹히고, 회사에 따라 라이브 코딩이나 과제 리뷰가 붙습니다. 질문이 이 다섯으로 수렴하는 건 업무의 성격 때문이에요 — 통제할 수 없는 기기와 네트워크 위에서 남이 만든 런타임을 빌려 화면을 굴리는 일이라, 면접관은 라이브러리 사용법보다 브라우저가 무슨 일을 하는지 알고 코드를 쓰는지를 확인합니다.

그러니 예상 질문 목록을 늘리기보다 유형마다 내 코드 사례를 하나씩 붙여 두세요. 이벤트 루프에는 비동기 순서 때문에 겪은 버그, 리렌더링에는 불필요한 렌더를 잡은 경험, 성능에는 측정 전후 숫자 한 쌍. 사례가 붙은 답은 꼬리질문을 두세 번 견디고, 없는 답은 첫 꼬리질문에서 멈춥니다.

다섯 유형 위에 얹히는 스택 질문은 지원하는 팀을 따라갑니다. Devographics의 State of JavaScript 2025 조사에서 JavaScript와 TypeScript 비중을 답한 응답자 10,934명 가운데 4,367명(약 40%)이 코드를 전부 TypeScript로 쓴다고 답했고, 순수 JavaScript만 쓴다는 응답은 661명(약 6%)이었습니다. 공고에 TypeScript가 적혀 있다면 제네릭이나 타입 좁히기는 가산점이 아니라 기본값이에요.

'정의 한 줄 → 왜 그렇게 동작하는지 → 내가 겪은 사례' 세 칸이 채워질 때까지예요. 세 번째 칸이 비면 아무리 정확한 정의도 암기로 들립니다.

이벤트 루프가 대표적이에요. 싱글 스레드인데 비동기가 되는 이유로 시작해 콜 스택·태스크 큐·마이크로태스크 큐를 설명하고, setTimeout(fn, 0)과 Promise.then()의 실행 순서가 왜 다른지까지 가면 한 세트입니다. 꼬리질문은 대개 '그럼 async/await은 어느 큐로 가나요', '렌더링은 그 사이 어디에 끼나요'로 들어와요. 막히는 지점이 다시 볼 자리입니다.

클로저는 정의보다 쓰임으로 답하는 편이 강해요. '함수가 선언될 때의 스코프를 기억한다'는 한 줄 뒤에 왜 메모리에 남는지, 그리고 이벤트 핸들러가 옛 상태 값을 붙잡고 있어 버그가 났던 경험을 붙이면 이해와 실무가 한 번에 검증됩니다. this 바인딩, 프로토타입 체인, 얕은 복사와 깊은 복사도 같은 틀이에요.

피해야 할 건 키워드 나열입니다. '호이스팅은 선언이 위로 끌어올려지는 것' 같은 한 줄 암기는 'let과 const도 호이스팅되나요' 한 방에 무너져요. 주제 수를 줄이더라도 왜 그렇게 설계됐는지까지 말할 수 있는 주제를 늘리는 쪽이 유리합니다.

'이 화면은 언제, 왜 다시 그려지는가'를 한 문장으로 답할 수 있으면 대부분 커버돼요. 브라우저 렌더링과 프레임워크 리렌더링은 층이 다른데, 면접에서는 둘을 이어서 묻는 경우가 많습니다.

브라우저 층은 DOM과 CSSOM을 만들고 → 렌더 트리를 합치고 → 레이아웃(리플로우) → 페인트 → 합성으로 이어지는 순서를 말로 따라갈 수 있어야 해요. 단골 꼬리질문은 '애니메이션을 top·left 대신 transform으로 하는 이유'입니다. top을 바꾸면 레이아웃부터 다시 계산되지만 transform과 opacity는 합성 단계만 건드린다는 답에, 실제로 버벅이던 화면을 고친 경험이 붙으면 한 세트가 됩니다.

프레임워크 층에서는 리렌더링이 일어나는 조건(상태 변경, 부모 리렌더, context 값 변화)과 줄이는 수단(메모이제이션, 상태를 쓰는 컴포넌트로 내리기, 리스트의 key)을 묻습니다. useEffect는 특히 자주 파고들어요. React 공식 문서 「You Might Not Need an Effect」는 이렇게 못 박아 뒀습니다 — "If there is no external system involved (for example, if you want to update a component's state when some props or state change), you shouldn't need an Effect." 외부 시스템이 없다면, 예컨대 props나 state가 바뀔 때 다른 state를 갱신하려는 것뿐이라면 Effect는 필요 없다는 뜻이에요. 렌더 중에 계산하면 되는 값과 외부 시스템과 동기화해야 하는 값을 구분해 말하면 이 계열은 대부분 정리됩니다.

상태관리 라이브러리 질문은 사용법이 아니라 선택 근거를 묻습니다. '왜 Redux였나', '서버에서 받아온 데이터를 전역 상태에 넣은 이유는', '지금이라면 어떻게 나눌 건가'. 서버 상태와 클라이언트 상태를 가르는 기준을 자기 언어로 갖고 있으면 이 축은 안정적으로 넘어가요.

Core Web Vitals 기준값과, 내 프로젝트에서 실제로 측정한 전후 숫자 한 쌍이면 충분해요. 기준값은 구글 web.dev 문서에 명시돼 있습니다 — 필드 데이터 75 퍼센타일 기준으로 LCP는 2.5초 이내, INP는 200밀리초 이하, CLS는 0.1 이하가 '좋음'이에요. INP 문서는 이 지표를 "a metric that assesses a page's overall responsiveness to user interactions"라고 정의합니다.

이 기준을 통과하는 사이트가 생각보다 적다는 점도 알아 두면 좋아요. HTTP Archive가 2025년 7월 CrUX 데이터로 집계한 Web Almanac 2025 성능 챕터에서 세 지표를 모두 통과한 사이트는 모바일 48%, 데스크톱 56%였습니다. 모바일에서 발목을 잡은 건 LCP로 62%만 '좋음'이었고 INP는 77%, CLS는 81%였어요. '어느 지표부터 보겠느냐'는 질문에 LCP를 먼저 짚고 근거를 대면 답이 단단해집니다.

답변 구조는 '원인 진단 → 조치 → 측정' 순서예요. '번들을 줄였습니다'는 약한 답이고, 'LCP 요소가 히어로 이미지였고 프리로드와 포맷 변경으로 4.1초에서 2.3초로 줄였습니다'는 강한 답입니다. 수치가 없으면 지금이라도 Lighthouse나 개발자도구 Performance 패널로 측정해 채워 넣으세요.

꼬리질문은 대개 트레이드오프로 들어옵니다. '코드 스플리팅으로 첫 화면은 빨라졌는데 페이지 전환이 느려졌다면?', '이미지를 전부 lazy loading하면 뭐가 문제인가?' 성능 조치는 대부분 무언가를 내주고 얻는 것이라, 얻은 것만 말하면 얕게 보여요.

레이아웃이 왜 그렇게 배치되는지 설명할 수 있는 깊이까지예요. 프레임워크가 대신 써주지 않는 영역이 그대로 질문이 됩니다. Stack Overflow 2025 개발자 설문에서 기술 사용 문항 응답자 기준 HTML/CSS를 쓴다고 답한 비율은 61.9%로 JavaScript(66%) 다음이었고 TypeScript(43.6%)보다 높았어요. 프레임워크 세대가 몇 번 바뀌어도 이 층은 남습니다.

단골 질문은 좁아요. 박스 모델과 box-sizing, position 값별 기준점, z-index가 안 먹는 이유(스태킹 컨텍스트), flex와 grid를 가르는 기준, margin 상쇄, 미디어 쿼리와 컨테이너 쿼리의 차이. 여기에 시맨틱 마크업·포커스 이동·색 대비 같은 접근성 질문이 붙는 팀이 늘고 있습니다.

답하는 요령은 원인 규명 과정을 말하는 거예요. 'z-index가 안 먹으면 어떻게 하나요'의 정답은 숫자를 올리는 게 아니라 '부모 중에 transform이나 opacity, filter로 스태킹 컨텍스트를 만든 요소가 있는지 개발자도구로 확인한다'입니다. 면접관이 보는 건 지식의 양이 아니라 화면이 의도대로 안 나올 때 어디부터 뒤지는가예요.

브라우저 쪽에서는 이벤트 버블링과 캡처링, 이벤트 위임, CORS가 자주 나옵니다. CORS는 '서버가 허용 헤더를 안 줘서 막힌 것'에서 끝내지 말고, 프리플라이트가 언제 발생하는지와 개발 환경 프록시로 우회했던 경험까지 이어 붙이세요.

신입은 '아는가', 주니어는 '왜 그렇게 했는가', 그 위는 '무엇을 포기했는가'를 묻습니다. 질문 문장은 비슷해도 통과 기준이 달라요.

신입은 기본기와 프로젝트 딥다이브가 중심이에요. 원리 질문에 정확히 답하고, 만든 프로젝트에서 기술을 고른 이유를 대면 됩니다. 규모는 통과 기준이 아니에요 — 클론 코딩이라도 '원본과 다르게 구현한 부분과 그 이유', '막혔던 지점과 해결 과정'이 있으면 소재로 충분합니다. 다만 경쟁은 이 구간이 가장 빡빡해요. 앞의 사람인·점핏 리포트에서 공고는 중간 연차에 몰려 있었고(5년차 6.6%, 7년차 6.7%, 8년차 6.7%, 10년차 6.9%) 신입 대상 공고는 0.8%였는데, 입사지원은 신입이 29.5%로 가장 많았습니다.

1~3년차는 실무에서 겪은 문제로 옮겨갑니다. 장애를 어떻게 재현하고 원인을 좁혔는지, 코드 리뷰에서 어떤 지적을 주고받았는지, 레거시를 어떤 순서로 손댔는지. 이 구간에서 '팀에서 정해준 대로 했습니다'는 위험한 답이에요. 결정에 참여하지 않았어도 그 결정을 어떻게 이해했는지는 말할 수 있어야 합니다. 4년차 이상은 설계 판단과 영향 범위로 넘어가요 — 상태관리 구조를 왜 그렇게 나눴는지, 공통 컴포넌트를 어떤 기준으로 뺐는지, 성능 예산을 어떻게 정하고 지켰는지. 여기서는 선택의 근거만큼 포기한 것이 중요합니다.

연차와 무관하게 최근 늘어난 축이 하나 더 있어요. AI 코딩 도구로 짠 코드를 설명할 수 있느냐입니다. 기술면접 플랫폼 Karat이 2026년 1월 발표한 조사에서 미국·인도·중국 엔지니어링 리더 400명 중 71%가 AI 때문에 지원자의 기술 역량을 판단하기 더 어려워졌다고 답했고, 응답 조직의 62%는 기술면접 중 AI 사용을 여전히 금지하고 있었습니다. 도구로 만든 코드라도 왜 그 구조인지 설명하지 못하면 면접에서 그대로 드러나요.

'결론 한 줄 → 동작 원리 → 내 사례 → 트레이드오프' 네 칸이 기본 구조예요. 리렌더링 질문이라면 '상태를 쓰는 곳으로 내리는 게 먼저입니다(결론) → 부모가 리렌더되면 자식도 함께 그려지니까요(원리) → 리스트 화면에서 필터 상태를 항목 컴포넌트로 내려 렌더 횟수를 줄인 적이 있습니다(사례) → 대신 상태가 흩어져 추적이 어려워져서 공유 범위가 넓은 값만 위에 남겼습니다(트레이드오프)' 순서로요.

첫 주(D-14~D-8)는 재료를 만드는 기간이에요. 다섯 유형별로 예상 질문을 6개씩 30개쯤 뽑고 각 질문에 내 코드 사례를 매칭합니다. 사례가 안 붙는 질문이 바로 약한 지점이에요. 성능 수치가 없으면 이 주에 측정하고, 이력서에 쓴 기술마다 '왜 → 대안 → 결과' 3단 문답을 만들어 두세요.

둘째 주(D-7~D-3)는 소리 내는 기간입니다. 하루에 한 유형을 잡고 같은 질문을 3회씩 소리 내어 답하세요. 눈으로 읽을 때는 아는 것 같던 개념이 입으로는 안 나오는 지점이 반드시 나옵니다. 혼자 하면 꼬리질문이 오지 않는 게 문제인데, 프리터뷰처럼 음성으로 문답을 주고받고 리포트로 정리해 주는 도구를 쓰면 같은 질문을 반복하며 답을 다듬을 수 있어요. 가입하면 무료 사용권 1개(포트폴리오 점검 1회 분량)를 주니 결과물을 먼저 확인해 보면 됩니다. 다만 AI의 기술 판정은 참고용이에요 — 사실관계는 MDN과 프레임워크 공식 문서로 교차 확인하세요.

마지막 이틀(D-2~D-1)은 새로운 걸 하지 않는 기간이에요. 새 개념에 손대면 불안만 늘어납니다. 막혔던 답 5개만 다듬고, 지원 회사의 서비스를 실제로 열어 개발자도구로 한 번 훑어보세요. 어떤 프레임워크를 쓰는지, 이미지 로딩은 어떻게 처리했는지 정도만 봐도 역질문 한두 개가 나옵니다.