이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 초기 번들 사이즈가 커서 첫 로딩이 느린 문제를 경험했습니다. Webpack bundle analyzer를 통해 특정 라이브러리가 전체 번들의 30% 이상을 차지한다는 걸 확인했습니다. 해당 라이브러리를 필요한 함수만 import하는 방식으로 교체했더니 번들 사이즈가 눈에 띄게 줄었습니다. 또한 코드 스플리팅을 적용해서 라우트 단위로 청크를 분리하면서, 초기 로딩에 불필요한 코드를 제외했습니다. 이 경험에서 빌드 최적화는 전체를 줄이는 게 아니라 측정을 통해 큰 부분부터 제거하는 것이 효과적이라는 원칙을 갖게 됐습니다.
측정 없이 줄이려 하면 방향이 없어진다는 걸 이 경험에서 배웠고, 빌드 최적화는 항상 측정에서 시작해야 한다는 원칙을 갖게 됐습니다.
번들 사이즈를 줄이는 방법 중 가장 직관적인 것은 필요할 때만 코드를 불러오는 코드 스플리팅입니다. 프로젝트에서 라우트별로 번들을 분리하고 React.lazy와 Suspense를 사용해 각 페이지 컴포넌트를 레이지 로딩으로 전환했습니다. 첫 화면 로딩에 불필요한 코드가 포함되지 않도록 진입점 번들을 최소화했습니다. Lighthouse로 First Contentful Paint를 측정했을 때 수 초 수준에서 1초대로 줄었습니다. 최적화 효과를 수치로 확인하는 과정이 무엇이 실제로 영향을 줬는지를 파악하는 데 중요했습니다.
코드 스플리팅이 초기 로딩 번들을 줄입니다. 레이지 로딩이 불필요한 사전 로드를 없앱니다. 측정 기반 최적화가 실질 개선을 확인합니다.
번들 최적화에서 라이브러리 전체를 임포트하면 실제로 사용하는 기능만 필요해도 전부 번들에 포함됩니다. Moment.js를 날짜 처리에 쓰고 있었는데, 로케일 파일까지 포함돼서 번들 크기가 컸습니다. date-fns로 교체하고 필요한 함수만 named import로 가져오는 방식으로 바꿨더니 해당 부분 번들이 크게 줄었습니다. 트리 쉐이킹이 제대로 작동하려면 라이브러리가 ES 모듈 형식으로 제공돼야 하는데, 이 차이를 그때 배웠습니다.
라이브러리 선택이 번들 크기에 영향을 줍니다. named import가 트리 쉐이킹을 가능하게 합니다. 데드코드 제거가 번들 최적화의 핵심입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.