이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 모바일 화면에서 스크롤 시 버벅임이 생기는 성능 문제를 맡아 개선한 경험이 있습니다. 먼저 Chrome DevTools 성능 탭으로 렌더링 병목이 어디서 생기는지 프로파일링했습니다. 문제는 리스트에서 아이템을 수백 개 한꺼번에 렌더링하고 있었고, 스크롤할 때마다 전체 리스트가 다시 그려지고 있었습니다.
가상 스크롤(virtual scroll) 방식을 도입해 화면에 보이는 아이템만 DOM에 유지하도록 변경했습니다. 추가로 이미지 로딩은 Intersection Observer로 뷰포트에 진입할 때만 로드되도록 lazy load를 적용했습니다. 적용 후 Lighthouse 성능 점수가 62점에서 84점으로 올라갔고, 스크롤 시 버벅임이 사라졌다는 팀원 피드백을 받았습니다. 이 경험에서 성능 최적화는 "느릴 것 같은 곳"이 아니라 "실제로 느린 곳"을 먼저 측정하는 것에서 시작해야 한다는 것을 배웠습니다.
팀 프로젝트에서 페이지 로딩이 느린 원인을 추적했을 때 네트워크 요청 수가 문제였습니다. 컴포넌트별로 독립적으로 API를 호출하다 보니 첫 화면 로딩에 11개의 요청이 동시에 발생하고 있었습니다. 먼저 Chrome DevTools 네트워크 탭으로 요청 타임라인을 확인했고, waterfall 구조에서 블로킹이 생기는 지점을 찾았습니다. 중복 요청을 묶어 단일 API로 합치고, 초기 렌더링에 불필요한 데이터는 lazy하게 불러오도록 구조를 바꿨습니다. 추가로 번들 사이즈 분석 도구로 사용하지 않는 라이브러리가 포함된 것을 발견해 제거했습니다. 이 두 가지 개선 이후 TTI가 4.2초에서 2.1초로 줄었고, 모바일 환경에서도 체감 속도가 달라졌다는 팀원 피드백을 받았습니다.
성능 최적화는 무작정 코드를 고치는 것이 아니라, 어디서 시간이 쓰이는지 데이터로 확인하고 나서 시작해야 한다는 것을 그 경험에서 다시 확인했습니다.
웹 애플리케이션 성능 문제를 다룰 때 프론트엔드보다 먼저 API 응답 속도를 확인하는 습관이 생겼습니다. 화면이 느리면 렌더링을 의심하기 쉽지만, 실제 원인이 서버 쪽 쿼리에 있는 경우가 생각보다 많았습니다. 팀 프로젝트에서 특정 페이지가 느린 원인을 추적했을 때, DB 쿼리에 인덱스가 빠져 있어 전체 테이블을 매번 스캔하고 있었습니다. 인덱스를 추가하고 자주 쓰는 쿼리 결과를 서버 캐시에 저장하는 방식으로 바꾸니 응답 시간이 1.8초에서 0.3초로 줄었습니다. 그 경험 이후 성능 이슈를 볼 때 프론트·서버·DB 세 레이어를 함께 확인하는 것을 기본으로 삼고 있습니다.
한 레이어만 잘 최적화해도 다른 레이어에서 병목이 생기면 체감이 안 바뀌기 때문입니다. 측정 도구는 각 레이어에 맞게 골라 쓰고, 수치로 확인하기 전에는 최적화됐다고 판단하지 않는 것을 원칙으로 하고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.