신입개발자의 퇴사와 2026 프론트엔드 면접 6곳에 대한 면접 정리

2월, 회사에서 갑작스럽게 사무실 이전 소식을 들었습니다.

원래 강남 근무였는데 구로디지털단지로 이전한다는 공지가 이사 2주 전에 나왔거든요.

자취방 이사도 보통 몇 달은 시간을 두고 준비하는데,,, 너무 갑작스러운 일정이라 솔직히 눈앞이 막막했습니다.

 

그 다음 날, 사수님과 면담을 하게 됐습니다. 여행 업계 특성상 개발 직군의 처우가 아쉬운 부분이 있다는 이야기부터, 지금보다 더 나은 환경을 찾아보는 것도 충분히 좋은 선택이라는 조언까지 해주셨어요. 저 같은 병아리 개발자를 두 달 동안 정말 많이 이끌어주신 분이라,,, 그 말이 더 크게 와닿았습니다.

물론 원래도 아쉬운 점이 전혀 없었던 건 아닙니다. 그래도 저는 고졸이고, 취업 시장도 쉽지 않다고 느끼고 있었고, 무엇보다 25년 차 사수님 밑에서 배울 수 있는 게 많다고 생각해서 버텨보려 했습니다.

하지만 출퇴근 거리가 더 멀어지는 상황에, 이런 중요한 변화가 통보식으로 전달됐다는 점은 꽤 당황스러웠습니다. 결국 바로 사람인 이력서를 최신화하고 지원을 넣기 시작했습니다.

그렇게 서류 결과가 하나둘 나오기 시작했는데, 최종적으로 11곳에서 합격 연락을 받았습니다. 그런데 또 다른 현실적인 문제가 있었습니다. 휴가가 거의 없어서 면접을 보러 갈 시간이 마땅치 않았던 거예요.

퇴사를 먼저 말씀드려야 할지, 아니면 어느 정도 결정이 난 뒤에 말씀드려야 할지 고민이 많았습니다. 하지만 너무 늦게 이야기하면 더 곤란해질 것 같았고, 설령 공백기가 생기더라도 어떻게든 해보자는 마음이 들었습니다. 그래서 다음 날 바로 퇴사 의사를 말씀드렸고, 3월까지만 근무하겠다고 전달했습니다.

다행히 이사님이자 사수님이셨던 개발팀장님, 그리고 과장님이자 멘토처럼 챙겨주셨던 기획 담당자분 모두 제 이야기를 잘 들어주시고 진심으로 상담해주셔서 정말 감사했습니다.

하필 다음 주에는 오른쪽 사랑니 발치 일정도 있어서, 남아 있던 연차를 거의 다 써야 했습니다. 그래서 ‘이왕 이렇게 된 거, 그날 면접을 몰아서 보자’는 생각을 하게 됐습니다.

그렇게 이틀 동안 면접을 다섯 개 봤습니다. 어떤 날은 월요일 퇴근 후 바로 마곡으로 이동해서 면접을 보기도 했습니다.

 

그 중 2군데가 붙었고, 좋은 처우 개선과 함께 이직을 하게 됬답니다..! 하핳

기분 좋은 이직짤

 

 

 

강남에 있던 사무실 이사.. 지금은 을지로로 이사왔습니다 (무려 청계천뷰이지만, 집에서 1시간 40분 걸림)

 

그러면 이제 그 면접들에 대한 이야기를 하려고 합니다...!

시 - 작

 

---

 

최근 여러 곳의 프론트엔드 포지션 면접을 보면서 느낀 건, 회사마다 분위기는 달라도 결국 확인하는 포인트는 꽤 비슷하다는 점이었다.

단순히 “React 할 줄 아세요?”를 묻는 게 아니라, 지금까지 어떤 방식으로 일해왔는지, 실무에서 어떤 판단을 했는지, 그리고 앞으로 어떤 개발자가 될 사람인지를 함께 보려는 질문이 많았다.

 

이 글은 여러 회사 면접에서 받았던 질문들을 회사명 없이 종합해서 정리한 기록이다. 프론트엔드 면접을 준비하는 사람이라면, 기술 질문만 외우기보다 어떤 맥락에서 이런 질문이 나오는지 같이 보면 훨씬 도움이 될 것 같다.

 

---

 

프론트엔드 이직 면접에서 실제로 많이 나왔던 질문들 정리

최근 여러 곳의 프론트엔드 포지션 면접을 보면서 느낀 건, 회사마다 분위기는 달라도 결국 확인하는 포인트는 꽤 비슷하다는 점이었다.

단순히 “React 할 줄 아세요?”를 묻는 게 아니라, 지금까지 어떤 방식으로 일해왔는지, 실무에서 어떤 판단을 했는지, 그리고 앞으로 어떤 개발자가 될 사람인지를 함께 보려는 질문이 많았다.

 

이 글은 여러 회사 면접에서 받았던 질문들을 회사명 없이 종합해서 정리한 기록이다.

프론트엔드 면접을 준비하는 사람이라면, 기술 질문만 외우기보다 어떤 맥락에서 이런 질문이 나오는지 같이 보면 훨씬 도움이 될 것 같다.

 

1. 가장 많이 나오는 질문은 결국 자기소개였다

어느 면접이든 거의 빠지지 않았던 건 자기소개였다.

그런데 여기서 중요한 건 화려한 표현보다, “나는 어떤 개발자인가”를 한두 문장으로 분명하게 말할 수 있느냐였다.

 

예를 들면 이런 식의 질문들이 반복됐다.

 

- 본인을 어떤 개발자라고 생각하는지

- 어떤 지향점을 가지고 있는지

- 왜 프론트엔드를 선택했는지

- 왜 지금 이직하려고 하는지

- 조기 취업을 하려는 이유는 무엇인지

- 학업과 실무를 병행할 수 있는지

- 현재 회사를 왜 나오려고 하는지

이 질문들은 사실 다 연결되어 있다. 면접관은 기술보다 먼저, 이 사람이 자기 선택에 대해 얼마나 납득 가능한 설명을 할 수 있는지를 본다.

특히 재학 중이거나 첫 이직인 경우에는 “왜 지금 취업/이직을 하려는지”를 굉장히 자주 물었다.

 

그래서 자기소개는 단순한 경력 요약보다 아래 흐름으로 준비하는 게 훨씬 좋다.

 

- 내가 어떤 개발자인지

- 어떤 경험을 통해 그렇게 생각하게 됐는지

- 지금 왜 이 회사를 선택했는지

- 앞으로 어떤 방향으로 성장하고 싶은지

 

2. React와 Next.js는 ‘써봤다’보다 ‘어디까지 이해했는지’를 본다

프론트엔드 포지션이다 보니 React, Next.js 관련 질문은 정말 자주 나왔다.

특히 인상적이었던 건, 문법을 아는지보다 “실무에서 판단 가능한 수준인지”를 보려는 질문이 많았다는 점이다.

 

자주 나온 질문은 이런 것들이었다.

 

- React는 어느 정도 수준으로 다룰 수 있는지

- Next.js를 실제로 얼마나 써봤는지

- React와 Next.js의 장단점은 무엇인지

- Next.js에서 배포는 어떻게 하는지

- React 앱 배포와 Next.js 배포는 뭐가 다른지

- useCallback은 왜 쓰는지

- 하이드레이션은 무엇인지

- 리렌더링 최적화 경험이 있는지

- 상태 관리는 어떤 기준으로 선택하는지

이 질문들에서 느낀 건, 면접관은 “기술 이름을 아는 사람”보다 “기술을 왜 그렇게 썼는지 설명할 수 있는 사람”을 찾는다는 점이었다.

 

예를 들어 React와 Next.js 비교는 단순히

“Next.js는 SSR 되고 React는 안 된다”

이 정도로 끝내면 부족하다.

 

실제로는 이런 정도까지 생각해두는 게 좋다.

 

React는 라이브러리라서 구조 자유도가 높고, CSR 중심으로 가볍게 시작하기 좋다.

Next.js는 React 기반 프레임워크라 라우팅, SSR/SSG, 서버 컴포넌트, 배포 구조 등 풀스택에 가까운 기본 틀을 제공한다.

대신 Next.js는 구조와 런타임 개념을 더 이해해야 해서 초반 진입 난이도는 조금 더 있다.

프로젝트 규모, SEO 필요 여부, 초기 렌더링 전략, 서버 연동 구조에 따라 선택이 달라진다.

useCallback도 마찬가지다.

“함수 메모이제이션입니다”로 끝나는 게 아니라, 언제 의미가 있고 언제 과한지까지 말할 수 있어야 한다.

 

예를 들면 이렇게 정리할 수 있다.

 

useCallback은 함수를 재생성하지 않게 해서 자식 컴포넌트 리렌더링을 줄일 때 의미가 있다.

하지만 무조건 쓰는 건 아니고, React.memo와 함께 실제 병목이 있는 경우에 쓰는 게 낫다.

최적화 도구이지 기본값은 아니다.

하이드레이션 질문도 자주 나왔다.

이건 Next.js를 건드려본 사람인지 확인하기 좋은 질문이라 그런 것 같다.

 

핵심은 이 정도로 정리하면 자연스럽다.

 

서버에서 먼저 렌더링한 HTML에 클라이언트 JavaScript가 붙으면서 상호작용 가능한 상태가 되는 과정

서버 HTML과 클라이언트 렌더 결과가 다르면 하이드레이션 에러가 날 수 있음

시간, 랜덤값, 브라우저 전용 객체 접근 같은 부분이 대표적인 원인

 

3. TypeScript 질문은 생각보다 기본에서 많이 갈린다

TypeScript 관련 질문은 오히려 어려운 문법보다 기본 개념에서 많이 나왔다.

 

대표적으로 이런 것들이다.

 

- 제네릭은 언제 쓰는지

- interface와 type 차이는 무엇인지

- null과 undefined 차이는 무엇인지

- 타입 안정성을 실무에서 어떻게 확보했는지

이런 질문이 반복된 이유는, 결국 실무에서 타입을 “문법”이 아니라 “설계”로 썼는지 알고 있는지 확인하려는 의도 같았다.

 

예를 들어 제네릭은 아래처럼 설명하면 깔끔하다.

 

타입을 고정하지 않고, 사용하는 시점에 타입을 전달받아 재사용 가능한 구조를 만들 때 사용한다

API 응답 타입, 공통 훅, 테이블/폼 컴포넌트처럼 입력과 출력은 달라질 수 있지만 구조는 비슷한 경우에 유용하다

결국 유연성과 타입 안정성을 동시에 확보하려는 도구다

interface와 type 차이도 면접에서 꽤 자주 나왔다.

실무적으로는 이렇게 정리하면 충분하다.

 

interface는 객체 구조를 정의하는 데 직관적이고 확장에 유리하다

type은 유니온, 인터섹션, 튜플, 원시 타입 별칭 등 더 넓은 표현이 가능하다

팀 컨벤션에 따라 다르지만, 객체 중심 구조는 interface, 조합형 타입 표현은 type으로 나누기도 한다

null과 undefined 차이도 기본 같지만 은근 자주 물어본다.

 

undefined는 값이 아직 할당되지 않았거나, 존재하지 않음을 의미하는 경우가 많다.

null은 의도적으로 비어 있음을 명시할 때 사용한다.

실무에서는 API 응답, 폼 초기값, optional 필드 처리에서 이 차이가 꽤 중요하다.

 

4. 네트워크, 인증, 브라우저 저장소 질문은 거의 필수였다.

 

생각보다 많은 회사가 프론트엔드 지원자에게 브라우저와 네트워크 기본기를 중요하게 봤다.

특히 단순 UI 개발자가 아니라, 실제 서비스 환경을 이해하는 사람인지 확인하려는 느낌이 강했다.

 

많이 나온 질문은 아래와 같다.

 

- CORS 에러가 무엇인지

- CORS 에러가 나면 프론트엔드/백엔드에서 어떻게 해결하는지

- 쿠키, 세션, 로컬스토리지 차이

- 로컬스토리지가 쿠키보다 불리한 점은 무엇인지

- 다른 도메인에서 기존 쿠키가 보이는지

- 로그인은 구현해본 적이 있는지

- 했다면 토큰 기반인지 세션 기반인지

- 인증 상태를 어떻게 관리했는지

이런 질문은 외워서 대답하는 것보다, 실제 구현 경험과 연결해서 말하는 게 훨씬 좋다.

 

예를 들어 로그인 질문에는 이렇게 붙일 수 있다.

 

- 액세스 토큰/리프레시 토큰 구조를 사용했는지

- 토큰 저장 위치를 왜 그렇게 선택했는지

- 만료 처리나 재발급은 어떻게 했는지

- 로그인 실패/권한 에러 시 UX는 어떻게 처리했는지

- 브라우저 저장소는 특히 자주 나온다.

- 기본적으로 아래 정도는 정리해두는 게 좋다.

 

쿠키는 요청마다 서버로 자동 전송될 수 있고 만료/도메인/path 설정이 가능하다.

세션은 서버가 상태를 관리하고, 브라우저는 세션 식별자만 들고 있는 구조다.

로컬스토리지는 브라우저에 직접 저장되고 자동 전송되지 않는다.

로컬스토리지는 XSS에 취약할 수 있어서 민감한 토큰 저장에는 신중해야 한다.

쿠키는 도메인/서브도메인/path/sameSite 설정에 따라 접근 범위가 달라진다.

 

5. 실무 경험을 물을 때는 “무슨 기능을 했나”보다 “어떻게 일했나”를 본다

 

면접에서 실무 이야기가 나오면 단순히 프로젝트 소개를 시키는 게 아니었다.

실제로는 아래를 확인하는 질문이 많았다.

 

- TypeScript로 구체적으로 어떤 작업을 했는지

- 맡았던 역할이 무엇인지

- 기존 코드를 분석할 때 어떤 방식으로 접근하는지

- 레거시를 개선한 경험이 있는지

- 로그인, 버전관리, 대시보드, 위젯 관리 같은 기능을 어떻게 설계했는지

- 사용자 편의성과 운영 안정성을 어떻게 같이 봤는지

여기서 중요했던 건 “내가 뭘 만들었다”보다 “그 상황에서 어떤 판단을 했다”를 말하는 것이었다.

 

예를 들어 관리자 대시보드를 두 명이 동시에 편집하는 상황 같은 경우도 좋은 사례가 된다.

이런 경험은 단순한 UI 구현이 아니라, 상태 충돌과 동시성 문제를 이해하고 있다는 신호가 되기 때문이다.

 

이럴 때는 아래처럼 풀면 좋다.

 

소켓 통신으로 현재 편집 중인 사용자 정보를 실시간 공유했다

브라우저별 식별을 위해 브라우저 ID를 두고, 같은 리소스를 누가 보고 있는지 추적했다

같은 대시보드를 두 명이 동시에 수정할 수 있는 경우, 편집 잠금 또는 충돌 감지 전략이 필요했다

예를 들어 한 사용자가 편집 중이면 다른 사용자는 읽기 전용으로 보거나, 특정 위젯 단위만 잠그는 방식으로 설계할 수 있다

저장 시점에는 마지막 수정 시간이나 버전 값을 비교해 충돌 여부를 확인하고, 필요하면 사용자에게 알리는 방식도 고려했다

이런 답변은 “소켓 써봤습니다”보다 훨씬 실무적으로 들린다.

 

6. AI 활용 질문은 이제 거의 빠지지 않는다

 

이번 면접들에서 확실히 느낀 건, 이제 AI 활용 경험은 선택지가 아니라 검증 항목에 가까워졌다는 점이다.

 

실제로 많이 나온 질문은 이랬다.

 

- Cursor, Claude Code, Antigravity 같은 도구를 써봤는지

- CLI로 Claude Code를 쓸 때 서브 에이전트나 MCP를 써봤는지

- AI가 짠 코드를 어디까지 이해하고 책임질 수 있는지

- AI 결과물의 품질은 어떻게 검증하는지

- AI 시대에 개발자의 방향성은 뭐라고 생각하는지

- 새로운 AI 도구를 회사에 제안할 생각이 있는지

이 질문들에서 중요한 건 “저 AI 잘 써요”가 아니었다.

오히려 “AI를 통제하면서 쓰는 사람인지”를 보는 느낌이 강했다.

 

그래서 답변도 이런 결이 좋다.

 

AI는 속도를 올려주는 도구지만, 최종 책임은 개발자에게 있다

생성된 코드는 반드시 직접 읽고, 타입/로직/부수효과를 검증해야 한다

프로젝트 규모가 커질수록 AI에게 수정 범위와 제약을 명확히 줘야 한다

공식 문서, 네트워크 탭, 실제 데이터 흐름으로 교차 검증하는 습관이 중요하다

개인적으로는 이 부분이 앞으로 더 중요해질 것 같다.

이제는 코드를 “직접 다 쓰는 사람”보다, 도구를 활용하면서도 품질을 지킬 수 있는 사람이 더 강한 개발자가 될 가능성이 크다.

 

7. 회사가 진짜 궁금해하는 건 조직 적응력이다

기술 질문만큼 많이 나왔던 게 협업, 태도, 조직 적응 관련 질문이었다.

 

예를 들면 이런 질문들이다.

 

- 개발자가 기획이나 도메인 지식에 참여하는 것에 대해 어떻게 생각하는지

- 팀의 방향과 내 생각이 다를 때 어떻게 행동하는지

- 시니어 개발자와 커뮤니케이션은 어땠는지

- 팀 프로젝트 중 의견 충돌은 어떻게 해결했는지

- 신입을 왜 뽑아야 한다고 생각하는지

- 야근이나 지방출장에 대한 생각은 어떤지

- 새로운 스택을 맡게 되면 어떻게 공부할 건지

- 적성과 조금 안 맞는 업무를 맡아도 할 수 있는지

- 이 질문들에 대한 공통된 답은 결국 하나였다.

“잘하려고 하는 사람”보다 “같이 일하기 괜찮은 사람”을 찾는다는 것.

 

특히 좋은 인상을 줄 수 있는 포인트는 아래와 같았다.

 

모르는 걸 숨기지 않고 빠르게 공유하는 태도

본인 주장만 세우지 않고 근거를 가져오는 태도

시키는 일만 하지 않고, 필요한 걸 먼저 찾아보는 태도

새로운 기술을 배우는 데 거부감이 없는 태도

기획/디자인/운영의 맥락까지 이해하려는 태도

 

 

8. 희망 연봉, 출근 가능일, 근무 조건 질문도 생각보다 중요하다

많은 지원자가 기술 준비에만 집중하지만, 실제 면접에서는 처우와 근무 조건도 꽤 구체적으로 확인한다.

 

주로 이런 것들을 물었다.

 

- 희망 연봉은 얼마인지

- 계약직 후 정규직 전환이 가능한지

- 출근 가능일은 언제인지

- 출퇴근 거리 문제는 없는지

- 지방출장 가능 여부

- 야근에 대한 생각

- 회사 규모나 문화가 본인과 맞는지

이 부분은 너무 전략적으로만 접근하기보다, 현실적으로 답하는 게 중요하다.

특히 희망 연봉은 시장가, 본인 경력, 현재 조건, 회사 규모를 고려해서 일관된 기준을 갖고 말하는 게 좋다.

 

9. 결국 면접은 ‘암기’보다 ‘정리’ 싸움이었다

여러 면접을 보면서 느낀 건, 질문 자체가 아주 특별해서 어려운 건 아니었다.

오히려 기본적인 질문을 얼마나 자기 경험과 연결해서 말할 수 있는지가 더 중요했다.

 

예를 들면 이런 것들이다.

 

“제네릭이 뭔가요?”

이걸 사전식으로 말하는 사람보다, 실제 API 응답 타입이나 공통 컴포넌트 설계 경험과 연결하는 사람이 더 설득력이 있다.

 

“하이드레이션이 뭔가요?”

정의만 말하는 사람보다, 서버 렌더링과 클라이언트 상태 불일치 때문에 에러가 날 수 있다는 실무 감각을 보여주는 사람이 더 기억에 남는다.

 

“AI를 어떻게 쓰나요?”

그냥 많이 쓴다고 말하는 사람보다, 검증 루프와 책임 범위를 같이 말하는 사람이 더 신뢰를 준다.

 

결국 면접 준비는 질문을 외우는 게 아니라, 내 경험을 기술 언어로 다시 정리하는 과정에 더 가깝다.

 

마무리

프론트엔드 면접이라고 해서 화면 구현 이야기만 나오는 시대는 이미 지난 것 같다.

이제는 React/Next.js 같은 프레임워크 이해도는 기본이고, 브라우저/네트워크/인증/타입 시스템에 대한 감각, 실무에서의 판단력, 협업 태도, AI 활용 방식까지 함께 본다.

 

면접을 준비하면서 가장 크게 느낀 건 하나였다.

좋은 답변은 멋있는 말에서 나오지 않고, 내가 실제로 해본 일을 스스로 정리해본 사람에게서 나온다.

 

그래서 앞으로 면접을 준비한다면, 질문을 많이 모으는 것보다 먼저 아래를 정리해보는 걸 추천한다.

 

1. 나는 어떤 개발자인가

2. 어떤 문제를 어떤 방식으로 해결해봤는가

3. 왜 그 기술을 선택했는가

4. 협업에서 나는 어떤 태도를 보였는가

5. AI와 같은 도구를 어디까지 이해하고 통제할 수 있는가

 

이 다섯 가지만 정리돼 있어도, 대부분의 질문은 훨씬 덜 흔들리게 된다.

(실제로 저는 많은 질문에 제대로 답변을 못했기 때문에, 이 글을 보시는 분들은 좋은 결과가 있기를 바랍니다...)

 

끝!