Frontend interview
프론트엔드 성능 최적화 면접 질문 준비
프론트엔드 면접에서 로딩 속도, 렌더링 병목, 성능 회귀 방지 질문에 답할 때 무엇을 증명해야 하는지 정리합니다.
Core takeaway
좋은 답변은 기법 이름을 나열하지 않고, 어떤 지표로 문제를 찾았고 왜 그 순서로 개선했는지를 보여줍니다.
Question 1
서비스 초기 로딩이 느리다는 불만이 들어왔습니다. 어떤 순서로 원인을 찾고 개선하시겠어요?
평가 의도
성능 지표 이해, 병목 진단 순서, 개선 우선순위 판단
흔한 실수
- 측정 없이 lazy loading, 코드 스플리팅 같은 기법 이름부터 나열한다.
- Lighthouse 점수만 말하고 실사용자 지표를 언급하지 않는다.
좋은 답변 신호
- 체감 기준 지표(LCP, TTI)를 먼저 정의하고 측정 환경(실사용자 vs 실험실)을 구분한다.
- 네트워크(번들 크기, 폰트, 이미지)와 렌더링(블로킹 스크립트) 병목을 분리해 진단한다.
- 개선 효과가 큰 것부터 적용하고, 전후를 같은 지표로 비교한다.
Question 2
리스트 화면에서 스크롤이 버벅인다면 어떤 원인을 의심하고 어떻게 확인하시겠어요?
평가 의도
렌더링 파이프라인 이해, 프로파일링 능력, 추측이 아닌 검증 습관
흔한 실수
- 원인 확인 없이 'React.memo를 붙인다'처럼 도구를 정답으로 말한다.
- 메모이제이션의 비용(캐시 비교 연산, 복잡도 증가)을 모른 채 만능으로 취급한다.
좋은 답변 신호
- 불필요한 리렌더, 무거운 레이아웃 계산, 대량 DOM을 가설로 나누고 프로파일러로 확인한다.
- 가상화(windowing)·메모이제이션을 언제 쓰고 언제 쓰지 말아야 하는지 판단 기준을 말한다.
- 수정 후 프레임 드랍이 실제로 줄었는지 측정으로 확인한다.
Question 3
한 번 개선한 성능이 다시 나빠지지 않게 하려면 팀 차원에서 무엇을 갖춰야 할까요?
평가 의도
회귀 방지 체계, 자동화 사고, 팀 협업 관점
흔한 실수
- 개인이 주기적으로 확인하겠다는 수동 점검에 머문다.
- 도구 이름만 나열하고 어떤 임계치로 무엇을 막을지 말하지 못한다.
좋은 답변 신호
- CI에서 번들 크기·핵심 지표 임계치를 검사해 회귀를 머지 전에 잡는다고 말한다.
- 실사용자 모니터링으로 배포 후 지표 변화를 추적한다.
- 성능 예산(performance budget)을 팀 합의로 정한 경험이나 계획을 말한다.
내 답변으로 연습하기
내 이력서의 성능 개선 경험을 바탕으로 위 질문에 답변해보고, 측정 지표와 전후 비교가 답변에 들어있는지 점검합니다.
이 질문으로 연습하기