Webpack·Vite·Metro: 같은 빌드 책임을 어떻게 다르게 수행하는가

30초 요약

이 글은 네 문장으로 시작한다.

1. 세 도구 모두 필요한 코드를 찾고, 바꾸고, 실행할 결과를 제공한다.
2. 비교할 때는 입력 맥락 → 찾기 → 표현 바꾸기 → 출력 → 개발 피드백 순서를 쓴다.
3. 기능을 덧붙이는 구성 요소도 이름보다 언제 호출되고 무엇을 바꾸는지가 중요하다.
4. 개발 중 빠른 화면 갱신은 운영 산출물이 올바르다는 증거가 아니다.

먼저 같은 다섯 가지 질문을 놓는다

Webpack, Vite와 Metro의 설정 파일을 바로 나란히 놓으면 옵션 이름만 남는다. 먼저 어떤 빌드 도구에도 물을 수 있는 다섯 책임을 같은 순서로 놓는다.

이 모형은 세 제품이 서로 완전히 대체 가능하다는 뜻이 아니다. 같은 질문에 서로 다른 답을 준다는 뜻이다. 특히 입력 맥락에는 시작 파일뿐 아니라 브라우저·iOS·Android 같은 대상과 개발·운영 모드가 포함된다. 같은 App.tsx라도 이 셋이 다르면 같은 빌드가 아니다.

Webpack은 그래프와 컴파일 과정을 폭넓게 구성한다

Webpack의 강점은 이 컴파일 과정을 세밀하게 구성할 수 있다는 데 있다. 그만큼 설정을 읽을 때 어느 단계의 책임인지 나눠야 한다.

시작 파일(entry)
  ↓
가져올 대상 찾기(resolve) → 코드 관계 → 파일별 처리(loader) → 청크·자산 출력
                                      ↘ 전체 과정의 plugin 훅 ↗

따라서 TypeScript가 기대한 JavaScript로 바뀌지 않았다면 먼저 loader 규칙과 대상 파일을 본다. 출력 HTML이나 자산 목록이 잘못됐다면 그 결과를 만드는 plugin과 output 설정을 본다. 모든 문제를 “Webpack 설정 문제” 한 종류로 묶지 않는다.

Vite는 개발 제공과 운영 빌드를 구분한다

개발: 브라우저 요청 → 필요한 import 대상 찾기·표현 바꾸기 → ESM으로 제공
운영: 시작 입력 전체 → 코드 관계·표현 바꾸기·최적화 → 배포할 정적 산출물

개발에서 src/App.tsx와 여러 모듈 요청이 보였다고 운영에서도 같은 파일 구조로 배포되는 것은 아니다. 반대로 운영 청크가 합쳐졌다고 개발 서버도 시작 전에 전체 앱을 같은 방식으로 번들링한다고 단정하지 않는다.

현재 버전의 내부 도구 이름은 다시 바뀔 수 있다. 오래 남는 핵심은 개발 피드백과 운영 전달이 같은 목표가 아니라는 점이다.

Metro는 플랫폼 요청을 세 단계로 처리한다

입력 맥락: 시작 파일 + 플랫폼 + 개발 여부 + 축소 여부
  ↓
가져올 대상 찾기 ↔ 파일별 표현 바꾸기
  ↓
최종 형식 조립(serialization)
  ↓
JavaScript 번들 + 선택적 자산 목록·소스 맵

해석과 변환은 개념상 나뉘지만 실제로는 병렬로 진행될 수 있다. 단계 그림을 실행 순서가 항상 한 줄로 고정된다는 뜻으로 읽지 않는다.

이 차이는 App.tsx 하나만 보고 출력이 정해졌다고 말할 수 없다는 뜻이다. iOS와 Android 선택, 개발·릴리스 모드와 React Native 통합 설정도 빌드 입력이다.

다섯 책임으로 세 도구를 다시 압축한다

• Webpack 5 — 입력 맥락은 entry·target·mode에서 시작한다. 가져올 대상을 찾고 loader로 파일 표현을 바꾸며 output에 하나 이상의 번들·자산을 낸다. 개발 피드백은 webpack-dev-server와 빠른 모듈 갱신 구성이 맡을 수 있다.
• Vite 8 — 입력 맥락에는 프로젝트 root와 serve·build 모드가 들어간다. 개발 서버는 요청된 ESM을 찾아 처리하고, 운영 build는 Rolldown으로 정적 산출물을 만든다. 전체 새로고침을 줄이는 빠른 갱신은 개발 피드백 경로에 속한다.
• Metro — 입력 맥락은 시작 파일과 platform·dev 같은 옵션에서 시작한다. resolver, transformer, serializer가 찾기·표현 바꾸기·출력 조립을 나눠 맡는다. 서버는 번들 요청과 파일 변경에 대응하고, runBuild는 번들과 요청한 경우에만 자산 목록·소스 맵을 만든다.

이 세 줄은 기능 점수표가 아니다. 같은 다섯 책임을 어느 경계가 맡는지 빠르게 되살리는 색인이다. loader나 plugin의 수를 세어 도구의 우열을 정하지 않는다.

확장 이름보다 호출되는 단계를 본다

예를 들어 SVG를 React 컴포넌트로 바꾸는 기능을 옮긴다고 가정한다.

1. 입력은 .svg 파일 내용인가, 파일 URL인가?
2. 출력은 JavaScript 모듈인가, 별도 자산인가?
3. 해석 전에 파일을 다른 대상으로 연결해야 하는가?
4. 개발과 운영 모두 같은 결과가 필요한가?
5. 소스 맵과 오류 위치를 다음 단계에 넘기는가?

이 질문에 답한 뒤 Webpack loader, Vite plugin 훅 또는 Metro transformer 중 맞는 경계를 고른다. 패키지 이름이 비슷하다는 이유만으로 설정을 복사하지 않는다.

빠른 갱신은 운영 산출물의 증거가 아니다

React 개발에서는 상태가 유지된 갱신을 보면 같은 앱이 계속 실행된다고 느끼기 쉽다. 하지만 Effect가 다시 실행되거나 컴포넌트가 다시 마운트될 수 있다. HMR은 운영용 기능이 아니므로 운영 배포 산출물에는 HMR 경로를 포함하지 않아야 하며, 다음 두 검증을 분리한다.

개발 피드백 검증: 저장 → 변경 감지 → 갱신 경계 → 화면 반영
운영 산출물 검증: 운영 모드 빌드 → 실제 산출물 → 대상 환경 로딩

실패는 제품명이 아니라 책임으로 분류한다

캐시를 지우는 일은 이 분류 뒤의 한 선택일 뿐이다. 어떤 책임의 어떤 입력이 잘못됐는지 모른 채 모든 캐시를 지우면 잠시 달라진 결과만 보고 원인을 놓칠 수 있다.

도구는 대상과 산출물 계약으로 선택한다

세 도구 중 “가장 빠른 하나”를 일반식으로 고를 수는 없다. 먼저 시작 파일·대상·모드라는 입력 맥락과 React Native 또는 Web 프레임워크의 통합 경계를 확인한다. 그다음 찾기, 표현 바꾸기, 출력, 개발 피드백에 필요한 계약을 적는다. 개발 환경의 통합 경계에서는 개발 요청을 다른 서버로 대신 전달하는 프록시(proxy)가 필요한지도 별도로 확인한다.

속도를 비교한다면 같은 소스 코드 버전(같은 커밋), 같은 캐시 상태, 같은 대상과 같은 산출물 요구를 고정한다. 시작 시간, 변경 반영 시간과 운영 빌드 시간을 한 숫자로 합치지 않는다.

이 글의 경계

이번 글은 앞선 1~5편의 공통 책임을 세 도구에 대입하는 데 집중했다. 다음 내용은 분리한다.

• 빌드 입력과 결과를 반복 가능하게 만드는 법: 7편 재현 가능한 빌드
• 이전 처리 결과를 다시 써도 되는 조건: 8편 빌드 캐시
• 개발 서버가 아닌 CI에서 운영 빌드를 검증하고 전달하는 법: 10편 CI와 CD
• React Native 릴리스 번들·Hermes·네이티브 빌드의 전체 관계: React Native 전용 글

마지막으로 두 문장만 기억한다. 입력 맥락을 맞춘 뒤 찾기 → 표현 바꾸기 → 출력 → 개발 피드백을 비교한다. 확장은 이름보다 호출 시점과 바꾸는 책임을 본다.