Frontend interview

프론트엔드 성능 최적화 면접 질문 준비

프론트엔드 면접에서 로딩 속도, 렌더링 병목, 성능 회귀 방지 질문에 답할 때 무엇을 증명해야 하는지 정리합니다.

내 경험으로 바로 연습하기

이 질문을 내 이력서와 지원 공고 기준으로 받아보세요.

Google 로그인 후 문서를 등록하면, 이 주제를 반영한 질문과 답변 피드백으로 이어집니다. 가입 시 제공되는 무료 크레딧으로 먼저 연습할 수 있어요.

무료로 이 질문 연습하기

핵심 요약

좋은 답변은 기법 이름을 나열하지 않고, 어떤 지표로 문제를 찾았고 왜 그 순서로 개선했는지를 보여줍니다.

흔히 보이는 답변 패턴

이 직무 질문에서 반복적으로 나타나는 약한 답변 유형입니다. 내 답변이 이 중 하나에 해당하는지 먼저 점검해보세요.

도구 나열형 답변

측정 없이 lazy loading, 코드 스플리팅 같은 기법 이름부터 나열한다.

측정 누락형 답변

Lighthouse 점수만 말하고 실사용자 지표(RUM)를 언급하지 않는다.

만능 해법형 답변

React.memo 같은 기법을 비용 없이 무조건 적용해야 하는 것처럼 말한다.

개인 의존형 답변

성능 회귀 방지가 개인의 수동 점검에만 의존한다.

질문 1

서비스 초기 로딩이 느리다는 불만이 들어왔습니다. 어떤 순서로 원인을 찾고 개선하시겠어요?

평가 의도

성능 지표 이해, 병목 진단 순서, 개선 우선순위 판단

흔한 실수

측정 없이 lazy loading, 코드 스플리팅 같은 기법 이름부터 나열한다.
Lighthouse 점수만 말하고 실사용자 지표를 언급하지 않는다.

좋은 답변 신호

체감 기준 지표(LCP, TTI)를 먼저 정의하고 측정 환경(실사용자 vs 실험실)을 구분한다.
네트워크(번들 크기, 폰트, 이미지)와 렌더링(블로킹 스크립트) 병목을 분리해 진단한다.
개선 효과가 큰 것부터 적용하고, 전후를 같은 지표로 비교한다.

답변 비교: 아쉬운 답변 → 좋은 답변

아쉬운 답변

이미지를 압축하고 lazy loading을 적용하겠습니다.

보통 답변

Lighthouse 점수를 보고 점수가 낮은 항목부터 고치겠습니다.

좋은 답변

체감 기준 지표인 LCP, TTI를 먼저 정의하고, 실험실 환경(Lighthouse)과 실사용자 환경(RUM) 수치를 구분해서 봅니다. 네트워크 병목(번들 크기, 폰트, 이미지)과 렌더링 병목(블로킹 스크립트)을 나눠서 진단하고, 효과가 큰 것부터 적용한 뒤 같은 지표로 전후를 비교합니다.

→LCP, TTI 같은 체감 지표를 먼저 정의해 측정 누락형 답변을 피했다.
→실험실 환경과 실사용자 환경을 구분해서 본다고 말해 측정 방법의 함정을 이해하고 있음을 보였다.
→네트워크와 렌더링 병목을 나눠 진단한 뒤 효과가 큰 것부터 적용한다고 말해 우선순위 판단을 보였다.

꼬리질문 대비

RUM과 Lighthouse 수치가 다르게 나온 적이 있나요?

면접관 의도

두 측정 방식의 차이를 실제로 다뤄봤는지 확인

좋은 방향

실제 사례에서 왜 차이가 났는지(네트워크 환경, 디바이스 분포 등) 구체적으로 설명한다.

길이별 답변

30초

LCP, TTI를 먼저 정의하고 실험실 환경과 실사용자 환경을 구분해서 봅니다. 네트워크 병목과 렌더링 병목을 나눠 진단하고, 효과가 큰 것부터 적용한 뒤 같은 지표로 비교합니다.

60초

90초

체감 기준 지표인 LCP, TTI를 먼저 정의하고, 실험실 환경(Lighthouse)과 실사용자 환경(RUM) 수치를 구분해서 봅니다. 예를 들어 Lighthouse LCP는 2.1초인데 RUM 75퍼센타일은 4.8초였다면, 실제 사용자의 네트워크나 디바이스 분포가 테스트 환경과 다르다는 신호입니다. 네트워크 병목(번들 크기, 폰트, 이미지)과 렌더링 병목(블로킹 스크립트)을 나눠서 진단하고, 효과가 큰 것부터 적용한 뒤 같은 지표로 전후를 비교해 실제로 개선됐는지 확인합니다.

질문 2

리스트 화면에서 스크롤이 버벅인다면 어떤 원인을 의심하고 어떻게 확인하시겠어요?

평가 의도

렌더링 파이프라인 이해, 프로파일링 능력, 추측이 아닌 검증 습관

흔한 실수

원인 확인 없이 'React.memo를 붙인다'처럼 도구를 정답으로 말한다.
메모이제이션의 비용(캐시 비교 연산, 복잡도 증가)을 모른 채 만능으로 취급한다.

좋은 답변 신호

불필요한 리렌더, 무거운 레이아웃 계산, 대량 DOM을 가설로 나누고 프로파일러로 확인한다.
가상화(windowing)·메모이제이션을 언제 쓰고 언제 쓰지 말아야 하는지 판단 기준을 말한다.
수정 후 프레임 드랍이 실제로 줄었는지 측정으로 확인한다.

답변 비교: 아쉬운 답변 → 좋은 답변

아쉬운 답변

React.memo를 붙이겠습니다.

보통 답변

가상화 라이브러리를 적용하겠습니다.

좋은 답변

프로파일러로 먼저 확인합니다. 불필요한 리렌더, 무거운 레이아웃 계산, 대량 DOM 중 어디가 원인인지 가설을 나눠 검증하고, 그에 맞게 가상화나 메모이제이션을 적용합니다. 메모이제이션은 비교 연산 비용이 있어서 모든 곳에 쓰지 않고, 적용 후 프레임 드랍이 실제로 줄었는지 측정으로 확인합니다.

→도구를 정답으로 두지 않고 프로파일러로 원인을 먼저 확인해 만능 해법형 답변을 피했다.
→리렌더, 레이아웃 계산, 대량 DOM을 가설로 나눠 검증하는 순서를 보였다.
→메모이제이션의 비용을 언급하고 적용 후 측정으로 확인한다고 말해 신중한 판단을 보였다.

꼬리질문 대비

메모이제이션을 적용했는데 오히려 느려진 경험이 있나요?

면접관 의도

메모이제이션의 비용을 실제로 겪어봤는지 확인

좋은 방향

비교 연산이 렌더링보다 비싼 경우를 구체적으로 들고, 어떻게 알아챘는지 말한다.

길이별 답변

30초

프로파일러로 먼저 확인합니다. 리렌더, 레이아웃 계산, 대량 DOM 중 어디가 원인인지 가설을 나눠 검증하고, 적용 후 프레임 드랍이 줄었는지 측정으로 확인합니다.

60초

90초

프로파일러로 먼저 확인합니다. 예를 들어 리스트 아이템 하나가 리렌더될 때 부모까지 같이 리렌더되는 게 보이면 메모이제이션 후보지만, 레이아웃 계산(reflow)이 원인이면 메모이제이션은 효과가 없습니다. 불필요한 리렌더, 무거운 레이아웃 계산, 대량 DOM 중 어디가 원인인지 가설을 나눠 검증하고, 그에 맞게 가상화나 메모이제이션을 적용합니다. 메모이제이션은 비교 연산 비용이 있어서 모든 곳에 쓰지 않고, 적용 후 프레임 드랍이 실제로 줄었는지 측정으로 확인합니다.

질문 3

한 번 개선한 성능이 다시 나빠지지 않게 하려면 팀 차원에서 무엇을 갖춰야 할까요?

평가 의도

회귀 방지 체계, 자동화 사고, 팀 협업 관점

흔한 실수

개인이 주기적으로 확인하겠다는 수동 점검에 머문다.
도구 이름만 나열하고 어떤 임계치로 무엇을 막을지 말하지 못한다.

좋은 답변 신호

CI에서 번들 크기·핵심 지표 임계치를 검사해 회귀를 머지 전에 잡는다고 말한다.
실사용자 모니터링으로 배포 후 지표 변화를 추적한다.
성능 예산(performance budget)을 팀 합의로 정한 경험이나 계획을 말한다.

답변 비교: 아쉬운 답변 → 좋은 답변

아쉬운 답변

배포 후에 제가 다시 확인하겠습니다.

보통 답변

정기적으로 Lighthouse를 돌려서 점수를 확인하겠습니다.

좋은 답변

CI에서 번들 크기와 핵심 지표 임계치를 검사해 회귀를 머지 전에 잡습니다. 배포 후에는 실사용자 모니터링으로 지표 변화를 추적합니다. 이 임계치는 개인이 정하지 않고 팀 합의로 성능 예산을 정해서 관리합니다.

→CI에서 자동으로 검사한다고 말해 개인 의존형 답변을 피했다.
→배포 전(CI)과 배포 후(RUM)를 나눠서 회귀를 잡는 두 단계 체계를 제시했다.
→성능 예산을 팀 합의로 정한다고 말해 협업 관점을 보였다.

꼬리질문 대비

성능 예산을 넘었을 때 실제로 머지가 막힌 적이 있나요?

면접관 의도

체계가 실제로 작동했는지, 형식적인 게 아닌지 확인

좋은 방향

실제로 막혔던 사례와 그때 어떻게 해결했는지를 구체적으로 말한다.

길이별 답변

30초

CI에서 번들 크기와 핵심 지표 임계치를 검사해 회귀를 머지 전에 잡고, 배포 후에는 실사용자 모니터링으로 추적합니다. 임계치는 팀 합의로 정한 성능 예산입니다.

60초

90초

CI에서 번들 크기와 핵심 지표 임계치를 검사해 회귀를 머지 전에 잡습니다. 예를 들어 메인 번들이 200KB를 넘거나 LCP 예상치가 기준보다 나빠지면 CI가 실패하도록 만들어, 회귀가 프로덕션에 나가기 전에 막습니다. 배포 후에는 실사용자 모니터링으로 지표 변화를 추적해서 CI가 못 잡은 회귀도 빠르게 발견합니다. 이 임계치는 개인이 정하지 않고 팀 합의로 성능 예산을 정해서 관리하기 때문에, 새 기능을 추가할 때 팀 전체가 성능 비용을 같이 고려하게 됩니다.

내 답변으로 연습하기

내 이력서의 성능 개선 경험을 바탕으로 위 질문에 답변해보고, 측정 지표와 전후 비교가 답변에 들어있는지 점검합니다.

이 질문으로 연습하기