프론트엔드 개발자 면접 질문 TOP 10 (주니어 합격을 가르는 핵심 토픽)

코딩 테스트는 통과했는데, 막상 기술 면접 들어가면 머리가 새하얘진 적 있으신가요? "분명 알고는 있는데 입으로 풀어 설명하려니 안 되더라"는 후기가 정말 많아요. 주니어 면접에서 어려운 건 모르는 걸 묻는 게 아니라, 아는 걸 정확히 설명하는 일이거든요.

이 글에서는 한국 프론트엔드 면접에서 반복적으로 등장하는 질문 10개를 4개 카테고리로 묶어 드릴게요. 단순히 외워야 할 답을 던지는 게 아니라, 면접관이 무엇을 보려는지와 답변에 꼭 들어가야 할 핵심 포인트를 같이 짚어요. 다 보고 나면 "어디서부터 공부해야 하지?" 하는 막막함이 정리될 거예요.

다룰 카테고리는 이렇게 4가지예요.

1. JavaScript 핵심 (3문항)

2. 브라우저·HTTP 기초 (2문항)

3. 프레임워크·상태 관리 (2문항)

4. 성능·네트워크 최적화 (2문항)

5. 협업·문제 해결 경험 (1문항)

내일배움캠프 2025 면접 문제은행과 신입 면접 회고 글들을 교차 확인했을 때, 이 카테고리들은 빠지지 않고 등장해요^[6][7].

1. JavaScript 핵심 — 가장 자주 나오는 영역

자바스크립트는 프론트엔드의 모국어죠. 그래서 면접관은 "라이브러리 잘 쓰는 사람"보다 "언어 동작을 이해하는 사람"을 골라내려 해요. 이 영역에서 막히면 다음 질문으로 넘어가지도 못하는 경우가 많아요.

Q1. 호이스팅(Hoisting)이 뭔가요? var, let, const는 어떻게 다른가요?

MDN의 정의를 보면, 호이스팅은 인터프리터가 함수·변수·클래스·import의 선언을 스코프 최상단으로 옮긴 것처럼 보이는 동작을 가리켜요^[1]. 흥미로운 점은 호이스팅이 ECMAScript 명세에 공식 정의된 용어가 아니라는 거예요. 관찰되는 동작을 부르는 비공식 이름이라는 사실까지 알면 답변이 한층 단단해져요^[1].

답변에 꼭 넣을 포인트는 세 가지예요.

• var: 선언이 호이스팅되며 undefined로 초기화돼요. 그래서 선언 전 접근하면 undefined가 나와요^[1].

• let, const: 호이스팅은 되지만 초기화가 안 돼서, TDZ(Temporal Dead Zone) 동안 접근하면 ReferenceError가 발생해요^[1].

• 함수 선언문: 본문까지 통째로 호이스팅되어 선언 전에도 호출 가능해요^[1].

면접관이 보려는 것: 단순 암기가 아니라, "왜 let을 쓰는 게 안전한가?" 같은 실무 판단까지 연결되는지를 봐요.

Q2. 클로저(Closure)는 무엇이고 어디에 쓰나요?

클로저는 "함수가 자신이 선언된 렉시컬 스코프를 기억해서, 바깥에서 실행돼도 그 스코프에 접근할 수 있는 함수"라고 한 줄로 정의해요. 답변할 때는 정의 → 짧은 코드 예시 → 실무 활용 순서가 깔끔해요.

활용 예시는 이런 것들이 자주 나와요.

• 데이터 은닉(private 변수 흉내)

• 모듈 패턴, 커링

• React에서 useState/useEffect 내부의 상태 보존

이 토픽은 한국 면접 회고에도 단골로 등장하는 영역이에요^[7].

Q3. 이벤트 루프와 비동기 처리(Promise/async-await)를 설명해 주세요

자바스크립트는 싱글 스레드인데 어떻게 비동기를 처리할까요? 핵심은 Call Stack + Web APIs + Task Queue + Event Loop 구조예요. 이벤트 루프가 콜 스택이 비어 있을 때 큐의 작업을 가져와서 실행해요.

답변에 넣을 포인트는 다음과 같아요.

• 동기 코드는 콜 스택에서 즉시 실행

• setTimeout·네트워크 요청 같은 비동기 작업은 Web API에 위임 → 완료 후 큐로 이동

• 이벤트 루프는 스택이 비면 큐에서 꺼내 실행

• Promise는 마이크로태스크 큐로 들어가 일반 태스크보다 우선 처리

내일배움캠프 자료에서도 동기 vs 비동기, Promise vs async/await가 빈출 토픽으로 정리돼 있어요^[6].

면접관이 보려는 것: 비동기를 그냥 "기다렸다가 실행"으로 얼버무리지 않고, 큐와 우선순위까지 짚는지를 봐요.

2. 브라우저·HTTP 기초 — 실무 디버깅에 직결되는 영역

이 영역은 "현장에서 막히면 검색만 잘해도 풀리지 않을까?" 싶지만, 면접관은 정반대로 봐요. 막혔을 때 어디부터 의심할 줄 아는가를 검증하는 자리거든요.

Q4. 브라우저에 URL을 입력하면 어떤 일이 일어나나요?

이 질문은 네트워크와 렌더링을 한 번에 묻는 종합 질문이에요. 답변은 단계별로 끊어 가는 게 좋아요.

1. URL 파싱 → DNS 조회로 IP 획득

2. TCP 연결, HTTPS면 TLS 핸드셰이크

3. HTTP 요청 → 서버 응답(HTML)

4. 브라우저가 HTML 파싱 → DOM 트리, CSS 파싱 → CSSOM

5. DOM + CSSOM → Render Tree

6. Layout(Reflow) → Paint → Composite

리플로우/리페인트, DOM/BOM 같은 키워드도 한국 면접 회고에서 자주 등장해요^[7]. "이미지가 늦게 뜨는 페이지가 있을 때 어디부터 의심하시겠어요?" 같은 후속 질문으로 이어지기 좋은 토픽이에요.

Q5. CORS는 왜 발생하고 어떻게 해결하나요?

MDN은 CORS를 "서버가 자신과 다른 origin(도메인·스킴·포트)에서의 리소스 로딩을 브라우저가 허용할지 표시하는 HTTP 헤더 기반 메커니즘"이라고 정의해요^[2]. 즉 CORS는 막는 장치가 아니라 same-origin policy를 푸는 표준이에요.

답변에 들어갈 핵심 포인트예요.

• 브라우저는 보안상 same-origin policy로 cross-origin 요청을 제한해요^[2].

• 단순 요청 조건(GET/HEAD/POST + 안전한 헤더)을 벗어나면 OPTIONS 메서드로 preflight 요청이 먼저 발생해요^[2].

• 서버가 Access-Control-Allow-Origin 등 응답 헤더로 허용 표시를 해야 실제 요청이 진행돼요^[2].

• 쿠키 같은 credentials를 보낼 땐 와일드카드(*) 대신 명시 origin을 적어야 해요^[2].

면접관이 보려는 것: "프록시 서버 깔면 돼요"로 끝내지 않고, 왜 발생하는지까지 설명하는지를 봐요.

3. 프레임워크·상태 관리 — 기술 선택의 trade-off

라이브러리를 쓸 줄 안다는 사실보다, 왜 이걸 골랐는지를 설명할 수 있는 사람이 더 좋은 점수를 받아요.

Q6. React의 Virtual DOM과 재조정(Reconciliation)을 설명해 주세요

React 공식 문서는 Virtual DOM을 "UI의 이상적인 표현을 메모리에 두고 ReactDOM 같은 라이브러리가 실제 DOM과 동기화하는 개념"이라고 설명해요^[5]. 재조정은 그 동기화 과정에 쓰이는 알고리즘이에요.

답변 핵심 포인트예요.

• 상태/props가 바뀌면 새 가상 DOM 트리를 만든 뒤 이전 트리와 비교(diffing)^[5].

• 두 엘리먼트 타입이 다르면 이전 노드를 통째로 destroy하고 새로 생성^[5].

• 같은 타입이면 변경된 속성만 업데이트^[5].

• 리스트 렌더링에선 key prop으로 안정적 식별자를 줘야 불필요한 재생성/상태 손실을 막아요^[5].

Virtual DOM은 "real DOM보다 무조건 빠른 마법"이 아니라, 변경 추적과 일괄 업데이트로 비용을 줄이는 전략이라는 점까지 짚으면 좋아요.

Q7. 상태 관리 도구는 어떻게 고르세요? (Context API · Redux · Zustand)

이 질문엔 정답이 없어요. 그래서 면접관은 본인이 어떤 기준으로 의사결정 하는지를 보고 싶어 해요.

State of React 2024 조사를 보면 Zustand 사용률이 1년 만에 28%에서 41%로 늘었어요^[4]. 만족도도 useState 다음으로 높았고요^[4]. 응답자들은 평균 2.6개의 상태 관리 라이브러리를 병행 사용한다고 답했는데, 이는 하나만 정답이 아니라 상황별로 골라 쓴다는 신호예요^[4].

비교 표를 외우려 하기보다, "규모와 변경 빈도"라는 두 축으로 설명할 수 있으면 충분해요.

4. 성능·네트워크 최적화 — 사용자 경험에 책임지는 시야

Q8. 웹 성능 최적화, 어떻게 해 보셨어요?

이 질문엔 지표 → 진단 → 개선 → 측정 흐름으로 답하는 게 가장 깔끔해요. Google이 정한 Core Web Vitals 3개 지표가 표준 언어가 됐으니, 면접에서도 그대로 인용해도 좋아요.

INP는 2024년에 정식 Core Web Vital이 되며 FID를 대체했어요^[3]. 측정은 75퍼센타일 페이지 로드 기준이라 상위 25%의 느린 경험까지 챙겨야 한다는 점도 같이 언급하면 좋아요^[3].

대표적인 개선 카드는 다음과 같아요.

• 이미지 최적화(next/image, AVIF/WebP, width/height 명시로 CLS 방지)

• 코드 스플리팅, 동적 import

• 폰트 font-display: swap, preload

• 메인 스레드 블로킹 줄이기(긴 작업 분할, debounce/throttle)

Q9. HTTP 캐싱 전략을 설명해 주세요

캐싱은 "그냥 빠르게 만든다"가 아니라 다시 받아야 할 때를 정확히 정의하는 일이에요. 답변에 들어갈 키워드는 이 정도예요.

• Cache-Control: max-age, no-cache, no-store, public/private의 차이

• ETag/Last-Modified: 조건부 요청과 304 응답

• 정적 자원은 해시 파일명 + 긴 max-age, HTML은 짧은 캐시

• CDN과 브라우저 캐시의 분리

"이미지 변경했는데 사용자 화면이 그대로일 때 어디부터 의심하시겠어요?" 같은 후속 질문이 자주 따라와요.

5. 협업·문제 해결 경험 — 결국은 사람과 일하는 직무

Q10. 가장 어려웠던 기술적 문제와 해결 과정을 말씀해 주세요

기술 면접의 절반은 이 질문이에요. 답변엔 STAR 또는 X-Y-Z 같은 프레임이 잘 어울려요.

• Situation: 어떤 맥락의 문제였는지(서비스/팀 규모, 기한)

• Task: 본인이 맡은 부분

• Action: 어떤 가설을 세우고 무엇을 시도했는지(실패 포함)

• Result: 수치 결과 + 배운 점

내일배움캠프 자료도 "본인의 강약점 표현"과 "결과를 수치로 구체화하는 것"을 면접 준비 핵심으로 짚어요^[6]. 예를 들어 "이미지 최적화로 LCP 4.2초 → 2.1초 단축, 모바일 이탈률 18% 감소" 같은 식이 좋아요.

면접관이 보려는 것: 결과가 화려한지가 아니라, 문제를 정의하고 가설을 검증하는 사고 과정이에요. 실패 경험을 솔직히 말하는 게 오히려 신뢰를 줍니다.

면접 준비, 어떻게 시작할까요?

10개 질문을 카테고리별로 점검해 본 뒤, 다음 3단계로 준비를 좁혀 가는 걸 추천해요.

1. 카테고리별 깊이 체크 — 4개 영역에서 가장 약한 곳부터 1주씩 잡아요. 호이스팅·클로저·이벤트 루프는 MDN을 직접 읽고 코드로 확인하는 게 가장 빠른 길이에요.

2. 본인 프로젝트와 연결 — 모든 답변은 결국 본인 코드로 돌아가야 설득력이 생겨요. 각 토픽마다 "내 프로젝트의 어디서 이 개념을 썼지?"를 한 줄씩 적어 두세요.

3. 입으로 풀어 보기 — 머리로 아는 것과 입으로 설명하는 건 완전히 다른 일이에요. 트리업의 모의 면접으로 카테고리별 질문을 받고, 막히는 지점을 찾아 보강하면 실전 감각이 빨리 올라와요.

이력서에 적힌 키워드와 면접 답변이 어긋나면 평가가 흔들려요. 트리업의 이력서 빌더로 실제 채용 공고 키워드와 본인 경험을 맞춰 두면, 면접 답변도 자연스럽게 정리돼요.

마무리

10개 질문은 끝이 아니라 출발점이에요. 모든 면접관이 같은 질문을 하지도 않고, 같은 질문도 회사마다 깊이가 달라요. 중요한 건 "왜 묻는가"를 이해하고, 본인 경험에 연결해 답할 수 있는가예요.

이번 주에는 카테고리 1개만 골라서, 답변을 소리 내어 3번 말해 보세요. 작은 노력들이 모여 면접장에서의 30초를 바꿔요. 응원할게요.

참고 자료