프론트엔드 면접 질문과 답변 예시: JS·렌더링·성능

다섯 갈래예요. 회사마다 여기에 이력서 프로젝트 질문, 라이브 코딩, 과제 리뷰가 붙는데 어떤 조합인지는 채용 공고와 전형 안내가 우선이에요. 아래 표는 갈래별 예시 질문과 함께 준비해 둘 내 사례를 정리한 프리터뷰 편집 제안이에요.

예상 질문 수를 늘리기보다 갈래마다 사례 한 개를 먼저 붙여 두는 편이 연습 효율이 좋아요. 사례가 붙은 답은 면접 꼬리질문 대비법에서 다루는 '왜 그렇게 했나요'에 이어서 말할 재료가 되고, 사례가 없는 갈래는 그 자체로 보완할 지점이니 첫 주에 채우면 돼요. 공고에 TypeScript가 있다면 제네릭과 타입 좁히기도 같은 방식으로 사례를 붙여 두세요.

정의 한 줄, 그렇게 동작하는 이유, 내가 겪은 사례까지 세 칸이 채워지는 깊이를 연습 목표로 잡으세요. 이벤트 루프라면 싱글 스레드에서 비동기가 가능한 이유로 시작해 콜 스택, 태스크 큐, 마이크로태스크 큐를 설명하고, setTimeout(fn, 0)과 Promise.then()의 실행 순서가 왜 다른지까지 이어지면 한 세트예요.

설명을 위한 가상 예시예요. '브라우저는 현재 태스크의 실행을 마친 뒤 마이크로태스크를 처리하고, 다음 태스크와 렌더링 기회를 이어갑니다. 같은 동기 실행 구간에서 이미 이행된 Promise에 등록한 then 콜백과 setTimeout(fn, 0)을 비교하면 then 콜백이 먼저 실행됩니다. 아직 이행되지 않은 Promise까지 항상 타이머보다 먼저라고 말할 수는 없습니다.' 이어서 'await 뒤의 코드는 언제 실행되나요', '마이크로태스크를 계속 추가하면 렌더링에 어떤 영향이 있나요'를 스스로 설명해 보세요.

클로저는 정의 뒤에 쓰임을 붙이는 편이 설명하기 쉬워요. 함수가 선언될 때의 스코프를 기억한다는 한 줄 뒤에, 예를 들어 이벤트 핸들러가 옛 상태 값을 붙잡고 있어 화면이 갱신되지 않았던 일처럼 직접 겪은 사례가 있다면 이어 말하면 돼요. 호이스팅처럼 한 줄로 외운 개념은 'let과 const도 호이스팅되나요'에 답할 수 있는지 스스로 먼저 물어보세요. 다루는 주제 수가 줄더라도 설계 이유까지 말할 수 있는 주제를 확보하는 쪽을 권해요.

'이 화면은 언제, 왜 다시 그려지나요'를 브라우저와 프레임워크로 나눠 설명해 보세요. 브라우저에서는 DOM·CSSOM, 레이아웃, 페인트, 합성이 어떤 일을 하는지 정리합니다. 위치 애니메이션은 top·left 대신 transform을 쓰면 레이아웃 작업을 줄일 수 있고, transform·opacity는 합성 단계에서 처리할 수 있습니다. 항상 비용이 사라지는 것은 아니므로 실제 화면은 개발자도구로 확인하세요(web.dev 안내).

프레임워크 층은 React 기준으로 trigger, render, commit 단계가 구분돼요. 컴포넌트가 렌더된다고 해서 DOM이 전부 교체되는 것은 아니고 commit 단계에서 달라진 부분이 반영된다는 설명을 React 공식 문서에서 한 번 읽어 두면, '리렌더링이 곧 성능 문제인가요'라는 질문에 층을 나눠 답할 수 있어요.

불필요한 렌더링을 다룰 때는 상태를 어디에 둘지, 메모이제이션이 필요한지, 변경 전후 비용을 어떻게 측정했는지 설명하세요. 안정적인 key는 리스트 항목의 정체성을 유지하는 데 필요하지만 key만으로 리렌더링을 막지는 않습니다. 상태 관리 라이브러리는 선택 이유와 서버 데이터·화면 상태를 나눈 기준을 실제 프로젝트와 연결해 준비하세요.

지표의 뜻과 직접 측정한 조건을 함께 준비하세요. LCP는 화면에 보이는 가장 큰 이미지나 텍스트 블록의 표시 시점, INP는 사용자 상호작용에 대한 응답성, CLS는 예상하지 못한 레이아웃 이동을 나타냅니다. 현재 정의와 기준값은 Core Web Vitals 공식 안내에서 확인하세요. 실사용 데이터와 Lighthouse 같은 실험실 측정값은 구분해 설명합니다.

설명을 위한 가상 예시예요. '상품 목록 페이지의 LCP 요소가 상단 배너 이미지였어요. 이미지를 preload하고 WebP로 바꾼 뒤 Lighthouse 모바일 기준으로 LCP가 4초대에서 2초대로 내려왔어요. 다만 preload를 남발하면 다른 리소스 우선순위가 밀려서 첫 화면에 보이는 이미지 한 장에만 적용했어요.' 원인 진단, 조치, 측정, 그리고 대신 내준 것까지 한 흐름으로 말하는 구조예요.

수치가 없다면 지금 프로젝트를 Lighthouse나 개발자도구 Performance 패널로 재서 채워 두세요. 클론 프로젝트라도 폰트 로딩이나 이미지 포맷을 바꾼 전후 수치는 만들 수 있어요. 꼬리질문은 '코드 스플리팅으로 첫 화면은 빨라졌는데 페이지 전환이 느려졌다면', '이미지를 전부 lazy loading하면 무엇이 문제인가'처럼 트레이드오프로 이어지는 경우가 많으니 얻은 것과 잃은 것을 짝지어 준비하세요.

레이아웃이 왜 그렇게 배치됐는지 원인을 추적하는 과정을 말할 수 있는 깊이예요. 자주 준비하는 주제는 박스 모델과 box-sizing, position 값별 기준점, 스태킹 컨텍스트, flex와 grid 선택 기준, margin 상쇄, 미디어 쿼리와 컨테이너 쿼리 차이이고, 시맨틱 마크업과 포커스 이동 같은 접근성 질문을 더하는 팀도 있어요.

'z-index가 안 먹으면 어떻게 하나요'에는 숫자를 올린다는 답보다 '부모 중 transform, opacity, filter로 스태킹 컨텍스트가 생긴 요소가 있는지 개발자도구로 확인해요'처럼 점검 순서를 말하는 편이 설명이 완결돼요. 화면이 의도와 다를 때 어디부터 보는지가 답에 담기기 때문이에요.

브라우저 API 쪽은 이벤트 버블링과 캡처링, 이벤트 위임, CORS를 준비하세요. CORS는 서버가 허용 헤더를 주지 않아 막혔다는 설명에서 멈추지 말고 프리플라이트가 언제 발생하는지까지 설명하고, 개발 환경에서 프록시로 우회해 본 적이 있다면 그 경험을 이어 붙이면 한 세트예요. API 설계나 DB 쪽으로 질문이 넘어가는 풀스택 포지션이라면 백엔드 개발자 면접 질문 가이드의 갈래도 같이 보세요.

질문 문장은 비슷해도 기대하는 답의 초점이 신입은 원리와 선택 이유, 1~3년차는 실무에서 겪은 문제 해결 과정, 그 위는 설계 판단과 포기한 것으로 옮겨가는 경향이 있어요. 회사마다 다르니 하나의 규칙으로 보기보다 공고의 요구 사항을 읽고 어느 초점에 무게를 둘지 정하세요.

신입은 프로젝트 규모보다 기술을 고른 이유와 막혔던 지점의 해결 과정을 준비해요. 클론 코딩이라도 원본과 다르게 구현한 부분과 그 이유가 있으면 소재가 돼요. 포트폴리오를 읽은 면접관은 무엇을 묻는가에서 프로젝트 질문의 흐름을 미리 보면 어떤 사례를 골라 둘지 정하기 쉬워요.

1~3년차는 장애를 어떻게 재현하고 원인을 좁혔는지, 코드 리뷰에서 어떤 의견을 주고받았는지, 레거시를 어떤 순서로 손댔는지를 준비해요. 팀에서 정해준 대로 했더라도 그 결정을 어떻게 이해했는지는 말할 수 있어야 해요. 4년차 이상은 상태 관리 구조를 나눈 기준, 공통 컴포넌트를 뺀 기준, 성능 예산을 정한 방식처럼 선택의 근거와 함께 대신 내준 것을 설명하게 돼요. 연차와 무관하게 AI 코딩 도구로 작성한 코드도 왜 그 구조인지 본인이 설명할 수 있어야 해요.

답변은 결론 한 줄, 동작 원리, 내 사례, 트레이드오프의 네 칸으로 구성하고 아래 점검표로 스스로 검토하는 방식을 제안해요. 이 점검표는 프리터뷰 편집 제안이며 특정 회사의 채점 기준이 아니에요.

• 결론을 첫 문장에 말했나요, 아니면 배경 설명부터 시작했나요?
• 원리 설명에 '왜 그렇게 설계됐는지'가 한 문장이라도 들어갔나요?
• 사례는 내가 직접 한 일이고, 이력서에 적은 내용과 일치하나요?
• 수치를 말했다면 어떤 도구로 언제 쟀는지 답할 수 있나요?
• 얻은 것과 함께 대신 내준 것을 한 가지 이상 말했나요?

첫 주는 재료를 만드는 기간이에요. 갈래별로 예상 질문을 대여섯 개씩 뽑아 '질문 / 결론 한 줄 / 내 사례 / 예상 꼬리질문 / 확인할 문서' 다섯 칸짜리 매칭 시트를 채우고, 빈칸으로 남는 질문이 보완할 지점이에요. 성능 수치가 없으면 이 주에 재고, 이력서에 적은 기술마다 '왜 골랐나, 대안은, 결과는' 문답을 만들어 두세요.

둘째 주는 소리 내어 답하는 기간이에요. 하루에 한 갈래를 잡고 같은 질문을 여러 번 말해 보면 눈으로는 알았던 개념이 입으로 막히는 지점이 나와요. 혼자 연습하면 꼬리질문이 오지 않는 것이 어려운데, 프리터뷰의 서류 기반 모의면접과 면접 후 피드백으로 같은 질문을 반복하며 답을 다듬을 수 있어요. 이용 방식은 요금·이용 조건과 예시 리포트에서 확인하고, AI의 기술 판정은 참고용으로 두고 사실관계는 MDN과 프레임워크 공식 문서로 교차 확인하세요. 연습 절차는 개발자 모의면접 가이드에 더 자세히 있어요.

마지막 이틀은 새 개념에 손대지 않고 막혔던 답 몇 개만 다듬는 기간이에요. 지원 회사의 서비스를 열어 개발자도구로 어떤 프레임워크를 쓰는지, 이미지는 어떻게 로딩하는지 훑어보면 역질문 소재가 나와요.