2025년 4월 18일·7분
현대 웹 앱에 빌드 도구와 번들러가 중요한 이유
빌드 도구와 번들러는 분산된 코드를 빠르고 신뢰할 수 있는 웹 앱으로 바꿉니다. 성능, 개발자 경험, 캐싱, 프로덕션 안전성 개선 방식을 알아보세요.
빌드 도구와 번들러는 분산된 코드를 빠르고 신뢰할 수 있는 웹 앱으로 바꿉니다. 성능, 개발자 경험, 캐싱, 프로덕션 안전성 개선 방식을 알아보세요.
빌드 도구는 웹 앱의 “조립 라인”입니다. 사람이 읽기 좋은 형태(분리된 파일, 최신 문법, 정돈된 폴더)를 작성하면, 빌드 도구는 그것을 브라우저가 효율적으로 다운로드하고 실행할 수 있는 파일로 변환합니다.
번들러는 패키징에 초점을 맞춘 특정 종류의 빌드 도구로, import를 따라 애플리케이션에 필요한 모든 것을 모아 하나 혹은 그 이상의 최적화된 번들을 출력합니다.
대부분의 현대 앱은 더 이상 하나의 스크립트 태그로만 이루어지지 않습니다. 수많은 JavaScript 모듈, CSS 파일, 이미지, 폰트, 서드파티 의존성이 조합되어 있죠. 빌드 도구는 이러한 입력과 최종 “프로덕션” 출력물 사이에 들어갑니다.
간단히 말해, 빌드 도구는 다음을 수행합니다:
일반적인 빌드는 /dist(또는 유사) 폴더에 브라우저-준비가 끝난 파일들을 생성합니다. 예를 들면:
app.8f3c1c.js 같은 해시된 파일명(캐싱 향상과 안전한 배포)이 출력물들은 브라우저의 강점을 활용하도록 설계되어 있습니다: 요청 수 감소, 페이로드 축소, 예측 가능한 캐싱.
아주 작은 정적 페이지—예컨대 JavaScript가 거의 없는 마케팅 페이지—를 배포할 때는 번들링 없이 평범한 HTML/CSS/JS를 서빙해도 됩니다.
그러나 여러 모듈, npm 패키지나 성능에 민감한 로딩 전략에 의존하게 되면 빌드 도구와 번들러는 “있으면 좋다” 수준을 넘어 필수로 바뀝니다.
10여년 전만 해도 몇 개의 JavaScript 파일을 <script> 태그로 포함하는 것으로 충분한 사이트가 많았습니다. 현대 웹 앱은 그렇지 않습니다. 재사용 가능한 컴포넌트로 UI를 구성하고, 서드파티 패키지를 임포트하고, 라우트 간에 코드를 공유하면 "파일 하나 더 포함하기" 방식은 관리가 불가능해집니다.
모듈은 더 명확한 코드를 가능하게 합니다: 필요한 것만 import 하고, 파일을 작게 유지하며 전역 변수를 피할 수 있습니다. 문제가 있다면, 프로젝트의 의존성 그래프는 브라우저가 런타임에 직접 처리하기에는 너무 커진다는 점입니다. 빌드 스텝은 모듈 더미를 브라우저가 일관되게 효율적으로 로드할 수 있는 출력물로 바꿉니다.
라우팅, 상태 관리, 차트, 에디터, 분석 등 풍부한 UI 패턴은 의존성 수와 파일 수를 모두 늘립니다. 빌드 스텝이 없다면 스크립트를 수동으로 순서화하고, 동일 라이브러리의 여러 버전을 관리하며, "너무 일찍 로드됨" 같은 미묘한 버그를 쫓아야 합니다. 빌드 도구는 의존성 관리를 자동화해 앱이 예측 가능하게 시작되도록 합니다.
팀은 여러 머신, 브랜치, CI에서 재현 가능한 결과물을 필요로 합니다. 빌드 스텝은 코드가 어떻게 변환되는지(TypeScript, JSX, 최신 JS), 에셋은 어떻게 처리되는지, 환경은 어떻게 구성되는지를 고정합니다. 이러한 재현성 덕분에 “내 환경에선 되는데” 문제와 배포 스트레스가 줄어듭니다.
사용자는 느린 로드와 끊기는 인터랙션을 알아차립니다. 코드 축소는 미뤄둘 수 있는 일이 아니라 핵심 요건이 됩니다. 빌드 스텝은 개발 전용 헬퍼를 제거하고 출력물을 최소화하며 더 똑똑한 로딩 전략을 준비하는 장소입니다.
브라우저는 JavaScript 실행에 능하지만 전달 방식에 민감합니다: 작은 파일이 많으면 네트워크 작업이 늘고, 큰 파일은 다운로드를 늦추고, 최신 문법은 오래된 기기에서 실패할 수 있습니다. 번들러는 브라우저가 빠르게 로드할 수 있는 형태로 앱을 패키징합니다.
번들러는 많은 모듈을 적은 파일로 결합해 브라우저가 네고·스케줄링에 소요하는 시간을 줄입니다. HTTP/2나 HTTP/3가 도입되었어도 유용합니다: 각 파일은 여전히 헤더, 캐싱 규칙, 우선순위, 실행 순서를 가집니다.
실무에서는 번들러가 앱을 시작할 수 있는 소수의 진입 파일과, 필요할 때만 로드되는 추가 청크를 목표로 합니다(코드 스플리팅 참조).
번들러는 브라우저가 다운로드하고 읽어야 할 양을 줄입니다:
작은 번들은 더 빠르게 다운로드될 뿐 아니라 파싱·실행도 빨라집니다. 모바일 기기에서 특히 중요합니다.
번들러는 최신 JavaScript를 더 많은 브라우저가 이해할 수 있게 트랜스파일할 수 있지만, 좋은 설정은 지원 브라우저 목록에 따라 필요한 경우에만 이 작업을 합니다. 이렇게 하면 최신 브라우저는 빠르게 유지하면서 구형 브라우저도 지원할 수 있습니다.
최적화된 코드는 사람이 읽기 어렵습니다. 번들러는 소스맵을 생성해 오류 리포트와 스택 트레이스가 원본 파일을 가리키게 해, 프로덕션 이슈의 원인 파악을 쉽게 합니다. 이때 소스맵을 공개적으로 제공할지 여부는 보안 정책에 따라 결정합니다.
번들된 앱이 하나의 덩어리일 필요는 없습니다. 코드 스플리팅은 JavaScript를 더 작은 청크로 나눠 현재 화면에 필요한 것만 로드하게 하고, 나머지는 필요 시 가져오게 합니다. 목표는 단순합니다: 특히 느린 연결에서 사용자가 더 빨리 유의미한 내용을 보게 하는 것.
가장 흔한 방법은 라우트 기반 분할입니다: 각 페이지(또는 주요 라우트)는 자체 청크를 가집니다. 마케팅 페이지에 도착한 사용자가 계정 설정 화면의 비용을 지불하지 않아도 되게 하는 것이 목적입니다.
기능 기반 분할은 차트 라이브러리, 리치 텍스트 에디터, PDF 내보내기 흐름처럼 ‘가끔 쓰는’ 기능에 유용합니다. 사용자가 실제로 기능을 트리거할 때만 해당 청크를 로드합니다.
초기 진입점에 모든 import가 포함되면 단일 대형 번들이 생기기 쉽습니다. 이렇게 되면 처음 로드가 느려지고 작은 변경도 사용자가 많은 코드를 다시 내려받게 만듭니다.
실무 체크: 어떤 의존성이 한 라우트에서만 쓰이거나 버튼 뒤에 숨어 있다면 별도 청크 후보입니다.
스마트 로딩은 단순히 “나중에”가 아닙니다. 곧 필요할 청크는 프리로드하고(우선순위 높음), 브라우저가 한가할 때 다음에 필요할 가능성이 있는 청크는 프리페치(우선순위 낮음)할 수 있습니다. 이렇게 하면 첫 요청을 과도하게 늘리지 않고도 네비게이션이 즉각적으로 느껴지게 할 수 있습니다.
분할은 청크가 안정적일 때 캐싱을 개선합니다: 한 기능을 업데이트해도 그 기능 청크만 바뀌면 됩니다. 하지만 공유 코드가 잘못 배치되면 많은 청크가 함께 바뀔 수 있습니다. 좋은 번들러는 공유 모듈을 추출해 공통 청크로 만들고 예측 가능한 청크 파일을 생성해 불필요한 캐시 무효화를 줄여줍니다.
트리 쉐이킹은 import했지만 실제로 사용하지 않는 코드를 제거하는 빌드 단계입니다. ES 모듈(import/export)을 사용하면 번들러가 어떤 export가 참조되는지 판단해 나머지는 버릴 수 있습니다.
예시: 유틸 라이브러리에서 한 가지 헬퍼만 쓰는데 라이브러리가 수십 개의 함수를 export할 때, 트리 쉐이킹은 참조된 export만 최종 번들에 포함시킵니다—단, 라이브러리와 코드가 트리-쉐이커블해야 합니다.
실무 팁:
번들러는 중복을 줄이려 하지만 다음 상황에서 여전히 중복이 생길 수 있습니다:
lockfile을 감사하고 버전을 정렬하면 뜻밖의 큰 번들을 방지할 수 있습니다. 많은 팀이 단순 규칙을 둡니다: 큰 의존성은 정당한 이유가 있어야 한다.
번들 크기 관리는 쓰이지 않는 코드를 제거하는 것뿐 아니라 어떤 코드를 전송할지 선택하는 것이기도 합니다. 한 기능이 큰 라이브러리를 끌어온다면 고려할 점:
Intl 사용)트리 쉐이킹에는 한계가 있습니다. 모듈에 사이드 이펙트(임포트 시 실행되는 코드)가 있으면 번들러는 보수적으로 동작합니다. 또한 주의할 항목:
번들 크기를 제품 기능처럼 취급하세요: 측정하고, 기대치를 세우고, 리뷰에서 변화 추이를 확인하세요.
빠른 앱은 작은 번들만으로 이루어지지 않습니다—같은 파일을 반복해서 내려받지 않도록 하는 것도 중요합니다. 빌드 도구는 브라우저와 CDN이 공격적으로 캐시할 수 있는 출력물을 만들고, 변경이 있을 때는 즉시 업데이트되도록 도와줍니다.
일반 패턴은 콘텐츠 해싱입니다: 빌드는 파일 내용에서 유도한 해시를 파일명에 포함시킵니다(예: app.3f2c1a.js).
이렇게 하면 파일이 변경되지 않는 한 파일명도 바뀌지 않으므로 긴 캐시 수명을 설정할 수 있습니다. 파일이 바뀌지 않으면 브라우저는 재다운로드 없이 재사용합니다.
반대로 캐시 무효화는 자동으로 일어납니다. 코드 한 줄을 바꾸면 콘텐츠 해시가 바뀌고 출력 파일명이 바뀝니다. 브라우저는 새로운 URL을 보고 새 자산을 가져오므로 “배포했는데 사용자에게는 예전 사이트가 보임” 문제가 발생하지 않습니다.
이 방식은 진입 HTML(또는 로더 파일)이 배포마다 새로운 해시된 파일명을 참조할 때 가장 잘 동작합니다.
번들러는 앱 코드와 서드파티 벤더 코드를 분리할 수 있습니다. 자체 코드가 자주 바뀌고 의존성은 덜 자주 바뀌면, 안정적인 벤더 번들은 재방문 사용자가 라이브러리 파일을 재사용하게 해줍니다.
캐시 적중률을 높이기 위해 도구 체인은 흔히 다음을 지원합니다:
해시된 자산을 사용하면 CDN은 정적 파일을 자신 있게 캐시하고 브라우저는 자연스럽게 제거될 때까지 보관합니다. 결과는 더 빠른 재방문, 전송 바이트 감소, 빠른 수정 배포 시에도 예측 가능한 배포입니다.
빌드 도구는 사용자용 번들을 작게 만드는 것만이 목적이 아닙니다—개발자를 더 빠르고 자신감 있게 만듭니다. 좋은 도구 체인은 “코드 수정 → 결과 확인” 루프를 짧게 만들어 품질에 직접적인 영향을 줍니다.
모던 개발 서버는 매 수정마다 전체 앱을 다시 빌드하지 않습니다. 대신 메모리상 버전을 유지하고 변경분만 푸시합니다.
피드백이 느리면 사람들은 변경을 묶어 한 번에 진행합니다. 큰 배치는 버그 원인을 숨기고 코드 리뷰를 어렵게 만듭니다. 빠른 리빌드와 즉각적인 브라우저 업데이트는 작은 안전한 수정을 장려합니다:
빌드 도구는 로컬/스테이징/프로덕션에서 앱이 읽는 환경 변수와 설정을 표준화합니다. 각 개발자가 고유한 설정을 갖는 대신 도구 체인이 어떤 변수가 브라우저에 노출되고 어떤 변수가 노출되지 않는지 예측 가능한 계약을 정의합니다. 이는 “내 환경에서는 되는데” 문제를 줄입니다.
개발 서버는 종종 API 프록시를 지원해 프런트엔드가 로컬에서 /api/...로 호출하면 CORS 없이 실제 백엔드(또는 로컬 백엔드)로 요청이 전달됩니다.
또한 개발 중에 엔드포인트를 모킹하기 쉬워 백엔드가 완성되기 전에 UI 흐름을 개발하거나 엣지 케이스를 재현할 수 있습니다.
JavaScript가 주목을 많이 받지만 CSS와 정적 파일(이미지, 폰트, SVG)이 페이지의 매끄러움에 큰 영향을 줍니다. 좋은 빌드 파이프라인은 이들을 퍼스트 클래스 시민처럼 처리합니다: 전처리, 최적화, 예측 가능한 전달 방식으로요.
번들러는 컴포넌트에서 import한 CSS를 수집하고 전처리기(Sass 등)와 PostCSS 플러그인(예: Autoprefixer)을 적용할 수 있습니다. 이렇게 하면 작성은 유연하게 유지하면서 출력 CSS는 대상 브라우저 전반에서 동작하게 됩니다. 또한 변수, 중첩 규칙, 호환성 관리를 한 곳에서 강제할 수 있어 개발자별 로컬 설정 의존을 줄입니다.
하나의 거대한 스타일시트를 전부 전송하는 것은 쉬운 방법이지만 초기 페인트를 지연시킬 수 있습니다. 많은 팀은 “크리티컬 CSS”(폴드 위에 필요한 최소 스타일)를 추출하고 나머지는 나중에 로드합니다. 모든 라우트에 적용할 필요는 없고, 우선 홈페이���지·체크아웃·주요 마케팅 페이지 같은 핵심 라우트부터 시작해 영향을 측정하세요.
모던 툴체인은 이미지를 압축하고 여러 사이즈를 생성하며 적절한 경우 PNG/JPEG을 WebP/AVIF로 변환할 수 있습니다. 폰트는 사용된 글리프만 서브셋팅할 수 있고, SVG는 불필요한 메타데이터를 제거해 최소화할 수 있습니다. 빌드 단계에서 이 작업을 자동화하면 커밋마다 수동 최적화를 기대하는 것보다 더 신뢰할 수 있습니다.
FOUC는 보통 CSS가 HTML보다 늦게 도착할 때 발생합니다. 이를 피하려면 프로덕션에서는 CSS를 실제 스타일시트 파일로 추출하고, 주요 폰트를 프리로드하고, 번들러가 필수 스타일을 실수로 지연시키지 않게 설정해야 합니다. 파이프라인이 제대로 구성되면 느린 연결에서도 사용자는 즉시 스타일된 콘텐츠를 보게 됩니다.
모던 번들러는 파일을 패키징하는 것뿐 아니라 작은 실수가 사용자에게 전달되는 것을 막는 품질 게이트를 적용할 수 있습니다. 좋은 파이프라인은 코드를 고치기 쉬운 시점에 문제를 잡고 고객 노출을 방지합니다.
린팅(ESLint)과 포맷(Prettier)은 일관성 없는 코드와 흔한 실수를 예방합니다(미사용 변수, 의도치 않은 전역 등). 타입 체크(TypeScript)는 데이터 흐름을 검증해 특히 빠르게 움직이거나 여러 페이지에서 코드를 공유하는 팀에서 가치를 발휘합니다.
이 검사들을 빌드(또는 사전 빌드) 스텝의 일부로 실행하는 것이 핵심입니다. 그래야 풀 리퀘스트가 팀이 허용하지 않은 오류를 포함해 머지되는 일을 막을 수 있습니다.
자동화된 테스트는 안전장치 역할을 합니다. 단위 테스트는 작은 로직을 확인하고, 통합 테스트는 컴포넌트 간의 파손을 잡아냅니다(예: 의존성 업데이트 후 폼 제출이 멈춘 경우).
빌드 도구는 테스트 명령을 예측 가능한 단계에 연결할 수 있습니다:
테스트 커버리지가 완벽하지 않더라도, 가지고 있는 테스트를 일관되게 실행하는 것은 큰 이득입니다.
크게 말해, 크게 실패하는 프로덕션 앱보다 빌드에서 크게 실패하는 것이 낫습니다. 빌드 시점에 문제를 잡으면 다음을 피할 수 있습니다:
번들러는 또한 출력 제약(예: 번들이 합의된 크기를 넘지 않도록 막는 등)을 검증해 시간이 지남에 따라 성능 저하를 방지할 수 있습니다.
개발자 노트북이 아닌 CI에서 빌드 아티팩트를 생성하면 재현 가능성이 높아집니다. 제어된 환경에서 빌드가 실행되면 “내 환경에서는 되는데” 문제가 줄고, 실제로 통과한 아티팩트를 배포할 수 있습니다.
실용적인 접근: CI는 린트 + 타입체크 + 테스트를 실행한 뒤 프로덕션 빌드 출력을 아티팩트로 생성합니다. 배포는 그 아티팩트를 프로모션하는 과정일 뿐—다시 빌드하지 않기 때문에 추측이 사라집니다.
프로덕션 버그는 번들된, 압축된, 때로는 청크로 나뉜 코드 때문에 찾기 어렵습니다. 소스맵은 이 격차를 메워 도구가 압축된 스택 트레이스를 원본 파일/라인/함수명으로 변환하게 합니다.
소스맵은 생성된 JavaScript/CSS를 원본 소스와 연결하는 매핑 파일(대개 .map)입니다. 소스맵을 사용하면 브라우저 개발자 도구가 압축된 번들에서도 오류가 발생한 실제 모듈과 라인을 표시할 수 있습니다.
소스맵은 에러 리포팅과 결합될 때 가장 가치가 큽니다.
에러 트래커를 사용한다면 CI에서 소스맵을 업로드해 스택 트레이스를 자동으로 복원하세요. 핵심은 버전 일치입니다: 소스맵은 배포된 자산과 정확히 일치해야 합니다(동일 빌드, 동일 해시). 이렇게 설정하면 경고가 더 행동 가능한 정보로 바뀝니다—예: “checkout/validate.ts:83의 크래시” 대신 “app.3fd1.js:1:9283에서의 오류”.
소스 코드를 노출하는 것이 우려된다면 .map 파일을 공개적으로 제공하지 마세요. 대신:
.map URL을 광고하지 않게 함신뢰 가능한 릴리스에 관해서는 /blog/caching-hashing-and-reliable-deployments를 참고하세요.
번들러는 앱을 작게 빠르게 만들 수 있지만, 그 효과는 측정될 때만 실질적입니다. "더 빠르게 느껴진다"는 릴리스도 실제로는 더 많은 JavaScript를 전송하거나 렌더링을 지연시킬 수 있습니다. 좋은 소식은 성능을 반복 가능한 검사로 만들 수 있다는 점입니다.
대부분의 툴체인은 번들 분석 리포트(트리맵 등)를 출력할 수 있습니다. 이 리포트는 프로덕션 빌드에 실제로 무엇이 포함되었는지 보여줍니다. 다음과 같은 놀라운 항목을 발견할 수 있습니다:
큰 블록을 보면 다음 행동은 구체적입니다: 의존성 대체, 작은 엔트리 포인트 임포트, 혹은 지연 경계 뒤로 이동.
성능 예산은 단순한 목표입니다. 예: "초기 JS 180 KB gzip 이하" 또는 "중간급 모바일에서 홈페이지가 3초 내 상호작용 가능" 등. 몇 가지 지표를 선택하고 예산이 악화되면 빌드를 실패시키세요.
초기 설정으로 좋은 예산 항목:
랩 측정은 문제를 초기에 잡지만 실사용 모니터링(RUM)은 고객이 실제로 경험하는 것을 알려줍니다. 각 릴리스 후 Core Web Vitals를 추적하고 배포에 주석을 달아 스파이크를 변경과 연관지으세요. 이미 분석을 사용 중이라면 가벼운 Web Vitals 리포터를 추가해 추이를 관찰하세요.
루프를 만드세요: 분석 리포트 실행 → 한 가지 개선 적용 → 재빌드 → 예산과 Vitals가 개선되었는지 검증. 증명하기 어렵고 유지보수도 힘든 큰 최적화 스프린트보다 작은 검증된 변화가 더 효과적입니다.
빌드 도구 체인을 고르는 것은 "최고의 번들러"를 찾는 문제라기보다 앱, 팀, 배포 환경에 맞는 적합성을 찾는 문제입니다. 많은 팀에 대한 합리적 기본값은 잘 지원되는 메인스트림 번들러와 강력한 개발 서버, 예측 가능한 프로덕션 출력을 가진 툴을 선택한 뒤 필요할 때만 커스터마이즈하는 것입니다.
바꿀 수 없는 제약부터 시작하세요:
매우 설정 가능한 환경은 엣지 케이스(맞춤 에셋 파이프라인, 특이한 모듈 포맷)를 처리할 수 있지만, 그만큼 깨질 여지도 늘어납니다. 더 단순한 도구 체인은 구성 부담을 줄이고 업그레이드를 쉽게 만듭니다—대신 회피 수단이 줄어듭니다.
좋은 규칙: 측정 가능한 필요가 생길 때까지 관례를 따르세요(번들 크기, 빌드 시간, 호환성). 그다음 한 번에 한 가지씩 변경하세요.
작게 시작하세요: 새 도구 체인을 단일 라우트/페이지나 새 패키지에 도입한 뒤 확장합니다. CI에 기본(빌드, 테스트, 린트)을 자동화하고, 모든 개발자가 동일한 명령을 쓰도록 "해피 패스" 명령을 문서화하세요.
만약 목표가 도구 체인 튜닝에 수주를 쓰지 않고 더 빠르게 움직이는 것이라면, 호스티드 워크플로가 많은 빌드·배포 마찰을 제거할 수 있습니다. Koder.ai를 사용하면 팀이 채팅을 통해 웹·백엔드·모바일 앱을 빠르게 생성할 수 있고, 플랫폼은 현대적 스택(프론트엔드 React, 백엔드 Go + PostgreSQL, 모바일 Flutter)을 생성하며 배포/호스팅, 커스텀 도메인, 소스 코드 내보내기, 스냅샷과 롤백 같은 실용적 릴리스 워크플로를 지원합니다. 이는 번들링 개념 이해를 대체하지는 않지만, "아이디어"에서 프로덕션 빌드까지의 경로를 크게 단축할 수 있습니다.
개선 측정을 위한 기초를 원하면 /blog/performance-basics를 참조하세요. 호스티드 워크플로나 지원 옵션을 평가 중이라면 /pricing에서 플랜을 비교해 보세요.
빌드 도구는 프로젝트 소스(모듈, TypeScript/JSX, CSS, 이미지, 폰트)를 브라우저에서 바로 쓸 수 있는 출력물로 변환합니다—보통 /dist 폴더에 생성됩니다.
번들러는 패키징에 집중한 빌드 도구로, import 그래프를 따라가서 브라우저가 효율적으로 로드할 수 있는 하나 이상의 최적화된 번들/청크를 내보냅니다.
간단한 HTML 파일과 아주 적은 양의 CSS/JS만 쓰는 아주 작은 사이트에서는 번들링을 건너뛸 수 있습니다.
하지만 여러 모듈을 사용하거나 npm 패키지, 또는 최소화/해싱/코드 스플리팅 같은 성능 기능이 필요해지면, 빌드 스텝은 사실상 필수가 됩니다.
대부분의 빌드는 브라우저에 적합한 자산을 출력합니다. 예를 들면:
app.8f3c1c.js)HTTP/2나 HTTP/3가 있어도 각 파일은 여전히 오버헤드(헤더, 캐싱 규칙, 우선순위, 실행 순서)를 가집니다. 번들러는 다음을 통해 최적화합니다:
코드 스플리팅은 큰 앱을 더 작은 청크로 쪼개 현재 화면에 필요한 것만 다운로드하게 합니다.
일반적인 패턴:
트리 쉐이킹은 사용되지 않는 export를 제거해 번들 크기를 줄입니다. ES 모듈(import/export)에서 가장 잘 작동합니다.
실무 팁:
해시된 파일명은 파일 내용이 바뀔 때만 URL이 바뀌므로 오래 캐시할 수 있게 해줍니다.
이로 인해:
개발 서버는 메모리상에 앱을 유지하며 편집 시 브라우저에 업데이트를 푸시합니다.
결과적으로 피드백 루프가 빨라지고 큰 단위의 변경을 줄여 디버깅이 쉬워집니다.
빌드 파이프라인은 CSS와 자산을 퍼스트 클래스 대상으로 다룹니다:
이런 처리는 커밋마다 수동 최적화를 기대하는 것보다 더 일관된 결과를 줍니다.
소스맵은 번들/압축된 출력과 원본 소스를 연결해 프로덕션 스택트레이스를 실무에 쓸 수 있게 합니다.
안전한 운영 방법:
.map 파일을 제공하지 않으려면 ‘숨김 소스맵’ 기능 사용자세한 배포 관련 내용은 /blog/caching-hashing-and-reliable-deployments를 참고하세요.