면접 예상질문

이력서·경력기술서에서 면접관이 파고들 만한 지점을 뽑았습니다. 회색 글씨는 답변 방향이 아니라 왜 이 질문이 나오는지에 대한 메모입니다.

  1. 1분 자기소개를 해주세요. 이력서 태그라인("커머스 안쪽을 만들어 왔습니다")과 같은 이야기로 시작하면 문서와 말이 일치한다.
  2. 이직을 결심한 이유는 무엇인가요? 현재 회사에 대한 불만보다, 다음에서 하고 싶은 일로 답을 끝내는 편이 안전하다.
  3. 본인의 강점은 무엇이고, 그걸 보여준 사례는 무엇인가요?
  4. 약점 혹은 아직 부족하다고 느끼는 부분은 무엇인가요? "보완하려고 무엇을 하고 있는지"까지 붙지 않으면 그냥 약점만 남는다.
  5. 앞으로 어떤 개발자가 되고 싶으신가요? 3년 뒤 모습은?
  6. 저희 회사에 지원한 이유는 무엇인가요? 회사마다 다시 쓸 자리. 제품을 직접 써본 경험이 있으면 그게 가장 세다.
  7. 지금까지 한 일 중 가장 어려웠던 문제는 무엇이었나요?
  8. 일하면서 가장 몰입했던 순간은 언제였나요?

일하는 방식

  1. 지금 개발할 때 AI를 어떻게 쓰고 계신가요? 어떤 작업에 쓰고, 어떤 작업에는 일부러 안 쓰나요? "써봤다"가 아니라 경계선을 그어본 사람인지를 본다. AI Native 조직에서 가장 먼저 나올 질문.
  2. AI가 생성한 코드를 어떤 기준으로 검수하나요? 이해하지 못한 채 머지한 적은 없나요?
  3. AI를 썼는데 오히려 느려지거나 품질이 나빠진 경험이 있나요? 장점만 말하면 실사용 깊이를 의심받는다. 실패 사례가 오히려 신뢰를 만든다.
  4. 같은 작업을 AI에게 잘 시키기 위해 본인만의 방식이 있나요? 컨텍스트를 어떻게 주나요?
  5. AI 도구를 팀에 확산시켜본 경험이 있나요? 안 쓰려는 동료는 어떻게 설득하나요?
  6. 사내 코드를 외부 LLM에 보내는 것에 대한 보안·라이선스 이슈는 어떻게 다루나요?
  7. AI에 의존하면 주니어의 성장이 막힌다는 우려가 있습니다. 어떻게 보시나요?

직접 만든 AI 기능 — PR 봇

  1. PR 봇의 프롬프트는 어떻게 설계했나요? 몇 번쯤 고쳤나요? 이력서에서 가장 강한 AI 크레덴셜이라 반드시 깊게 판다.
  2. 봇의 판단이 맞는지 어떻게 확인했나요? 평가셋이나 회귀 테스트를 만들었나요?
  3. 같은 PR에 매번 다른 답을 내놓는 비결정성 문제는 어떻게 다뤘나요?
  4. 정적 분석 규칙(ESLint·dependency-cruiser 등)으로 충분한 것과 LLM이 필요한 것을 어떻게 나눴나요? "AI로 풀 문제인가"를 판단할 줄 아는지 보는 질문. 전부 LLM에 맡겼다면 설계 감각을 의심받는다.
  5. 오탐이 나올 때 개발자 경험은 어떻게 지켰나요? 차단(blocking)인가요, 권고인가요?
  6. 토큰 비용과 응답 지연은 어떻게 관리했나요?
  7. 지금 다시 만든다면 무엇을 다르게 하시겠어요?

AI 제품의 프론트엔드

  1. LLM 응답은 느리고 결과가 매번 다릅니다. 프론트엔드에서 어떤 UX 장치가 필요하다고 보나요? AI Native 회사가 프론트엔드에게 가장 궁금해하는 지점.
  2. 스트리밍 응답을 렌더링할 때 고려할 점은 무엇인가요? 중간 상태의 마크다운 파싱, 중단, 재시도는?
  3. 모델이 틀린 답을 줬을 때 사용자에게 어떻게 알리고 회복시키나요?
  4. 에이전트가 사용자 대신 행동하는 UI에서는 무엇을 조심해야 하나요? 확인 단계, 되돌리기, 무엇을 했는지 보여주기 — 커머스라면 주문·결제와 직결된다.
  5. AI 기능의 성공을 무엇으로 측정하시겠어요?
  6. 커머스에 LLM을 붙인다면 어디에 넣는 게 가장 효과가 클 것 같나요? 상품 도메인 경험이 있어서 구체적으로 답할 수 있는 자리. 준비해두면 차별화된다.

관점

  1. AI Native 조직에서 프론트엔드 개발자의 역할이 어떻게 바뀐다고 보시나요?
  2. AI가 대체하기 어려운 개발자의 일은 무엇이라고 생각하나요?
  3. AI 도입으로 팀 생산성이 올랐다는 걸 어떻게 증명하시겠어요? 막연한 체감이 아니라 측정 방법을 말할 수 있는지 보는 질문.

설명하고 설득하기

  1. 비개발 직군에게 기술적 제약을 설명해야 했던 경험을 말해주세요. 이력서 소개글이 "커뮤니케이션의 중요성"을 앞세우고 있어 반드시 검증하려 든다.
  2. 본인 의견이 받아들여지지 않았을 때 어떻게 하셨나요?
  3. 반대로, 설득당해서 생각을 바꾼 경험이 있나요? 설득한 이야기만 하면 유연성을 의심받는다. 짝으로 준비해둘 것.
  4. 기획·디자인과 의견이 다를 때 근거를 어떻게 만드나요?
  5. 동료와 의견이 부딪혔던 경험과, 어떻게 풀었는지 말해주세요.
  6. 우선순위를 두고 협상해야 했던 경험이 있나요?

나쁜 소식과 피드백

  1. 일정이 밀릴 것 같을 때 언제, 어떻게 알리시나요? "언제"가 핵심이다. 늦게 알리는 사람인지 일찍 알리는 사람인지를 본다.
  2. 장애가 났을 때 커뮤니케이션은 어떻게 하시나요?
  3. 코드 리뷰에서 지적할 때 어떻게 표현하나요?
  4. 껄끄러운 피드백을 받았을 때 어떻게 반응하시나요?
  5. 팀에 나쁜 관행이 있다고 느낄 때 어떻게 바꾸시나요? 깃 정책 도입, CI 자동화, PR 봇 — 재료는 이미 이력서에 있다.

기록과 학습

  1. 문서를 쓰는 편인가요? 무엇을 문서로 남기고, 무엇은 남기지 않나요?
  2. 비동기 커뮤니케이션에서 본인만의 원칙이 있나요?
  3. 새로운 도메인에 들어갈 때 지식을 어떻게 습득하시나요? 차량 → 커머스 → 파트너 플랫폼으로 도메인을 여러 번 갈아탄 경력이라 물어보기 좋은 위치다.
  4. 멘토링을 하면서 가장 어려웠던 점은 무엇이었나요? 프로그래머스·패스트캠퍼스 멘토 경험이 이력서에 있다.
  5. 회고를 해본 적 있나요? 회고 이후 실제로 바뀐 것이 있나요?

코어 파트너 플랫폼 · 아키텍처

  1. 코어 파트너 플랫폼이 어떤 제품이고, 그 안에서 본인 역할은 무엇이었나요?
  2. 아키텍처를 새로 설계해야 했던 이유는 무엇인가요? 그전에는 어떤 문제가 있었나요? "합의된 기준이 없었다"에서 멈추면 안 된다. 그래서 실제로 무슨 일이 벌어졌는지.
  3. 왜 Layered Architecture였나요? 검토했다가 접은 대안은 무엇이고, 왜 접었나요? 가장 높은 확률로 들어올 질문. FSD·클린 아키텍처·도메인별 모듈화와 비교해봤는지.
  4. 계층 간 의존 방향을 어떤 규칙으로 정의했나요? 실제로 위반이 나온 사례는?
  5. 그 아키텍처를 팀에 어떻게 설득했나요? 반대 의견은 없었나요?
  6. 이 구조가 잘 안 맞았던 케이스도 있었나요? 한계를 스스로 말할 수 있으면 설계 경험이 진짜라는 신호가 된다.

Figma 플러그인 · 디자인 시스템

  1. 토큰을 코드로 변환하는 플러그인을 직접 만든 이유는? 기존 도구(Style Dictionary, Tokens Studio)를 쓰지 않은 이유는?
  2. 디자이너와 토큰 네이밍 규칙은 어떻게 합의했나요?
  3. 플러그인 도입으로 없앤 수작업은 어느 정도였나요? 이력서에 비어 있는 자리.
  4. 디자인이 바뀌었는데 코드가 따라가지 못하는 상황은 어떻게 막았나요?

OCMP · 마케팅 구좌

  1. 무신사와 29CM의 상품 카탈로그 스키마가 달랐을 텐데, 그 차이를 프론트엔드에서 어떻게 흡수했나요?
  2. 두 회사 운영자가 함께 쓰는 어드민이면 권한·용어·업무 흐름이 달랐을 텐데 어떻게 풀었나요?
  3. 세일즈포스를 내재화한 이유는 무엇이고, 무엇이 좋아졌나요?
  4. 파트너 1만 규모에서 프론트엔드 성능 문제는 없었나요? 목록·검색은 어떻게 처리했나요?

상품 상세 아키텍처 전환

  1. 어떤 구조에서 어떤 구조로 전환했나요?
  2. 기존 구조의 "한계"가 구체적으로 무엇이었나요? 느렸나요, 회귀가 잦았나요, SEO에 불리했나요?
  3. 부분 개선이 아니라 전면 전환을 택한 근거는 무엇인가요?
  4. 트래픽이 가장 많은 화면을 바꾸면서 어떤 안전장치를 뒀나요? 점진 배포·피처 플래그·롤백 계획은? 이 답이 있으면 "만들 줄 안다"에서 "운영할 줄 안다"로 올라간다.
  5. 전환 후 성능이 실제로 얼마나 좋아졌나요? 무엇으로 측정했나요?
  6. 전환 중에 사고가 나거나 되돌린 적은 없었나요?

애플 상품 · 속성 피커

  1. AppleCare+ 같은 무형상품이 기존 상품 모델의 어떤 점과 맞지 않았나요?
  2. 본품과 부가상품을 함께 담는 흐름은 어떻게 설계했나요? 본품만 취소되면 어떻게 되나요?
  3. 속성 조합이 많을 때 품절·비활성 조합은 어떻게 표현했나요? 속성 피커를 실제로 만들었다면 반드시 부딪히는 지점.
  4. 피커 UI를 다른 형태로 시도했다가 바꾼 적이 있나요? 어떤 기준으로 판단했나요?

사전판매 대기열

  1. 대기열의 목적이 트래픽 방어인가요, 구매 순서의 공정성인가요?
  2. 클라이언트가 책임진 범위는 어디까지였나요? 폴링 주기, 순번 표시, 이탈 처리는?
  3. 사용자가 새로고침하거나 탭을 여러 개 열면 어떻게 되나요?
  4. 판매 개시 당일 규모는 어느 정도였고, 장애는 없었나요?

SEO

  1. 색인이 6천에서 7~8만으로 늘었다고 했는데, 그게 본인이 한 작업 때문이라는 걸 어떻게 확인했나요? 유일하게 수치가 있는 성과라 인과관계를 반드시 파고든다.
  2. 색인이 10배 늘어난 게 실제 유입이나 매출로 이어졌나요?
  3. 캐노니컬 태그를 잘못 걸면 어떤 일이 생기나요? 검증은 어떻게 했나요?
  4. 사이트맵 자동화는 어떤 구조였나요? 콘텐츠가 계속 늘어나는 상황에서 어떻게 갱신했나요?
  5. 렌더링 방식은 무엇이었고, SEO 관점에서 어떤 선택을 했나요?

TypeScript · React Query 마이그레이션

  1. 전환을 결심하게 만든 구체적인 문제가 무엇이었나요?
  2. 왜 Redux를 걷어내고 React Query였나요? RTK Query나 SWR은 검토했나요?
  3. 서비스를 멈출 수 없는 상태에서 어떻게 점진적으로 전환했나요?
  4. 전환한 범위와 기간은 어느 정도였나요? 끝까지 갔나요, 중간에 남았나요?
  5. "주도했다"고 하셨는데, 팀원들이 실제로 따라왔나요? 안 따라오는 사람은 어떻게 했나요? 주도의 진위를 가르는 질문. 채택률이 곧 증거다.
  6. any를 어디까지 허용했나요? 타입 커버리지를 관리했나요?

React Native · 오픈소스 · 그 외

  1. React Native 대형 라이브러리의 문제를 어떻게 찾아냈나요? 디버깅 과정을 설명해주세요.
  2. 그 PR은 머지됐나요? 링크가 있나요? 실물 링크가 있으면 이 항목의 신뢰도가 크게 올라간다.
  3. Sentry를 붙이면 노이즈가 많았을 텐데 어떻게 걸러냈나요?
  4. WebView와 웹 사이 통신 규칙을 정리했다고 했는데, 앱 구버전 하위호환은 어떻게 다뤘나요?
  5. SDU(Server Driven UI)의 트레이드오프는 무엇이라고 보나요? 어디까지 서버에 맡기는 게 맞나요?
  6. 스코어본에서 1인 개발로 1.0까지 갔다고 했는데, 혼자 할 때 품질은 어떻게 담보했나요?
  1. React 렌더링 최적화를 실제로 적용한 사례를 말해주세요. 무엇으로 병목을 찾았나요?
  2. 서버 상태와 클라이언트 상태를 어떤 기준으로 나누나요?
  3. React Query에서 캐시 무효화 전략을 어떻게 세우나요? staleTime과 gcTime 기준은?
  4. SSR과 CSR을 어떤 기준으로 선택하나요? 커머스에서 SSR이 필요한 이유는?
  5. 프론트엔드 성능을 볼 때 어떤 지표를 보나요? 최근에 개선해본 지표는?
  6. 타입을 어디까지 엄격하게 가져가나요? 과한 타이핑이라고 느낀 경험은?
  7. 테스트는 어디까지 작성하나요? 프론트엔드에서 무엇을 테스트할 가치가 있다고 보나요?
  8. 공용 컴포넌트의 API를 설계할 때 어떤 원칙을 두나요?
  9. 웹 접근성을 고려한 경험이 있나요?
  10. 어드민과 대고객 서비스를 만들 때 접근이 어떻게 달라지나요? 둘 다 해본 경력이라 비교를 물어보기 좋은 위치에 있다.
  11. 최근에 관심 있게 본 기술이나 읽은 자료가 있나요?
  1. 기술 부채를 갚아야 할 시점을 어떻게 판단하나요? 그걸 어떻게 설득하나요?
  2. 코드 리뷰에서 무엇을 주로 보나요? 의견이 갈리면 어떻게 결론을 내나요?
  3. 일정과 품질이 충돌할 때 어떻게 결정하나요? 실제 사례가 있나요?
  4. 본인이 내린 기술 결정 중 틀렸다고 판명된 것이 있나요? 어떻게 수습했나요? 실패를 말할 수 있으면 신뢰도가 가장 크게 오르는 질문. 하나는 반드시 준비해둘 것.
  5. 말씀하신 성과 중에서 본인이 직접 한 부분과 팀이 함께 한 부분을 구분해주세요. 주어가 불명확한 서술은 서류 감점 요인으로 자주 지적된다. 면접에서도 그대로 확인한다.
  6. 주니어가 합류했을 때 어떻게 온보딩시키나요?
  7. 개발 프로세스나 팀 문화를 바꿔본 경험이 있나요? 저항은 없었나요?
  8. 혼자 결정할 일과 팀에 물어볼 일을 어떻게 구분하나요?
  1. 팀 구성과 제가 맡게 될 범위가 어떻게 되나요?
  2. 프론트엔드 기술 결정은 누가, 어떤 방식으로 내리나요?
  3. AI를 실제 개발 흐름 어디까지 쓰고 계신가요? 팀에서 자리 잡은 방식이 있나요? AI Native를 표방하는 회사라면 실제 운영 수준을 물어보는 게 자연스럽고, 관심도 드러난다.
  4. AI가 만든 코드에 대한 리뷰나 품질 기준이 따로 있나요?
  5. 코드 리뷰 문화는 어떤가요? 리뷰가 배포를 막나요?
  6. 기술 부채를 다루는 시간이 일정에 포함되나요?
  7. 지금 팀에서 가장 큰 기술적 과제는 무엇인가요?
  8. 입사 후 3개월 동안 제가 무엇을 해내면 잘 적응했다고 보시겠어요?