이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 리스트 컴포넌트가 데이터가 바뀌지 않았는데도 계속 리렌더링된다는 것을 React DevTools로 확인하였습니다.
원인을 분석해보니 부모 컴포넌트가 렌더링될 때마다 자식에 새 객체를 props로 내려주어 같은 값이어도 참조가 달라지는 문제였습니다. useMemo와 useCallback으로 값을 메모이제이션하였더니 불필요한 리렌더링이 없어졌습니다. 처음에는 모든 컴포넌트에 적용하다가 오히려 코드가 복잡해진 실수가 있었으나, 실제로 느린 곳에만 적용하는 방식이 맞았습니다.
그 경험에서 최적화는 측정 없이 시작하면 오히려 복잡성만 늘어난다는 것을 배웠습니다. 느린 것이 눈에 보이는 곳에만 최적화를 적용하는 것이 원칙이 되었습니다. 그 경험 덕분에 한 단계 성장할 수 있었습니다.
서비스 배포 후 모바일에서 이미지가 많은 페이지 로딩이 5초 이상 걸린다는 피드백이 들어왔어요. Lighthouse로 분석해보니 이미지 최적화 점수가 낮았습니다.
두 가지를 했어요. 이미지를 WebP 포맷으로 변환하고, 스크롤 범위 밖 이미지는 레이지 로딩으로 나중에 불러오게 바꿨습니다. WebP 변환만으로 파일 크기가 평균 60% 줄었고, 레이지 로딩으로 초기에 요청하는 이미지 수가 반으로 줄었어요. 처음엔 레이지 로딩이 적용됐는지 확인을 안 했다가 일부 이미지가 아예 안 나오는 버그가 있었어요.
로딩 성능의 많은 부분이 이미지에서 온다는 걸 직접 확인하니 이후 프로젝트에서는 이미지 처리 방식을 항상 먼저 생각하게 됐어요. 코드 최적화보다 리소스 최적화가 먼저인 경우가 많다는 것도요. 그 경험이 성능을 리소스 관점에서도 보게 해줬습니다.
프로젝트 규모가 커지면서 초기 로딩 시간이 느려진다는 피드백이 반복됐어요. 번들 크기를 확인해보니 잘 사용하지 않는 페이지 코드까지 처음부터 다 받고 있었습니다.
React.lazy와 Suspense로 라우트별 코드 스플리팅을 적용했어요. 자주 쓰는 메인 페이지만 초기에 로드하고 나머지는 해당 페이지에 접근할 때 받아오는 방식이었습니다. 처음엔 Suspense 폴백이 없어서 로딩 중에 화면이 비는 문제가 있었는데, 로딩 스피너를 추가하면서 해결됐어요.
초기 번들 크기가 40% 줄었고 첫 페이지 로딩이 체감상 빨라졌어요. 사용자가 처음에 필요한 것만 주는 것이 전체를 다 주는 것보다 낫다는 걸 그 경험에서 배웠습니다. 그 경험이 번들 구조를 의식적으로 관리하는 계기가 됐어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.