빌드 / 최적화
번들 최적화(Bundle Optimization)
번들 최적화는 웹앱이 내려받고 실행할 코드의 양과 로딩 시점을 조정해 사용 부담을 줄이는 작업입니다.
쉬운 설명
스터디 사이트에 차트 기능을 넣은 뒤 첫 화면까지 느려질 수 있어요. 아직 차트를 열지 않았는데도 큰 차트 코드를 처음부터 불러오고 있다면 확인해 볼 부분이에요. 번들 최적화에서는 어떤 코드가 언제 로드되는지 살펴보고, 불필요한 내용을 빼거나 필요할 때 불러오도록 나눠요. 파일 크기만 줄이는 것이 아니라 내려받은 코드를 브라우저가 처리하는 비용도 함께 봐요.
이런 상황에서 만나요
첫 화면에는 스터디 목록만 보이고, 통계 버튼을 눌러야 차트가 나오는 앱이라고 해 볼게요. 차트 코드를 처음부터 불러오는 방식과 통계를 열 때 불러오는 방식을 비교해요.
차트를 보지 않아도 차트 코드를 받고 있나요?
목록 코드 + 차트 코드 로드
목록 코드 로드
차트 코드 로드 → 차트 표시
- 1이 예시에서는 처음부터 두 기능의 코드를 받아요.
- 2목록에 필요한 코드부터 불러오도록 구성해요.
- 3미뤄 둔 기능을 열 때의 대기와 오류 처리도 확인해요.
개선 전후에 첫 화면에서 내려받는 파일과 실제 조작 가능 시점을 같은 조건으로 비교해요. 나중으로 미룬 차트 파일은 통계를 열 때 불러와야 하므로, 그 순간의 대기 표시와 로딩 실패 처리도 확인해요. 코드를 나눴다는 사실만으로 성능 개선을 단정하지 않아요.
헷갈리기 쉬운 점
파일을 작게 나누면 무조건 빨라지나요?
아니요. 지나치게 나누면 요청과 로딩 관리가 늘 수 있고, 곧바로 필요한 코드를 늦게 불러오면 오히려 화면이 늦어질 수 있어요. 파일 개수나 점수 하나보다 사용자가 기다리는 시간과 실제 동작을 함께 비교해요.
빌드 로그의 파일 크기, 압축해서 전송한 크기, 브라우저 실행 시간은 서로 다른 수치예요. 비교할 때는 기기·네트워크·캐시 조건을 맞추고 무엇을 측정했는지 적어요.
왜 알아야 할까요?
AI에게 막연히 “사이트를 빠르게 해 줘” 대신 “첫 화면에 필요 없는 차트 코드가 함께 로드되는지 확인해 줘”라고 요청할 수 있어요. 기능 추가가 첫 방문 속도에 미치는 영향도 살펴볼 수 있어요.
조금 더 자세히
코드 분할은 결과물을 여러 조각으로 나누는 방식입니다. 동적 import 등을 사용하면 특정 기능의 코드를 나중에 불러오도록 구성할 수 있습니다. 실제 분할과 미리 불러오기 동작은 프레임워크·번들러 설정의 영향을 받습니다.
트리 셰이킹은 사용하지 않는 코드를 분석해 출력에서 제외하는 최적화입니다. 모든 미사용 코드가 반드시 제거되는 것은 아니며 모듈 형식과 부수 효과 등이 영향을 줍니다. 압축 전송은 전송량을 줄이지만 실행할 코드의 동작 자체를 없애지는 않습니다.
직접 사용할 때 확인해 보세요
- 첫 화면에 필요한 코드와 나중에 필요한 코드를 구분한다
- 같은 조건에서 전송량과 사용자 대기 시간을 비교한다
- 분리한 기능의 로딩·실패·정상 동작을 확인한다
관계 지도
