[누가 시키지도 않았는데 번들러 만들기] 0. 프롤로그: 질문이 구현이 되는 순간

0. 프롤로그: 질문이 구현이 되는 순간

이전에 작성한 하루 만에 끝날 줄 알았던 디자인 시스템 배포가 3주 걸린 이유 에서는 "패키지를 배포하는 과정" 그 자체에 집중했습니다.
이번에는 시선을 조금 더 안쪽으로 돌려보려 합니다. 바로 배포물이 만들어지는 생성 과정 입니다.

배포는 성공적으로 마쳤지만, 정작 결과물이 어떤 원리로 만들어지는지 제대로 이해하지 못한 채 도구에만 의존하고 있다는 의문이 들었습니다. "남들이 다 쓰니까", "이게 표준이라니까" 라며 무심코 넘겼던 설정값들이 실제로는 번들러 내부에서 어떤 판단을 내리게 만드는 걸까요?

STEP 1: 당연한 것에 던지는 질문

npm 배포 과정을 정리하면서 계속해서 들었던 질문들이 있습니다. 이 질문들이 이번 시리즈의 기준이 됩니다.

• 결합의 원리: 소스 코드는 수십 개인데, 왜 결과물은 하나로 합쳐질까요? 그 경계는 누가, 어떤 기준으로 정하는 걸까요?
• 설정의 실체: package.json의 main, module, exports, sideEffects 값들은 번들러의 동작에 어떤 영향을 줄까요?
• 의존성의 선별: 모든 의존성을 번들에 포함해야 할까요? external과 peerDependencies는 어떤 기준으로 분류하는 것일까요?
• 트리 쉐이킹: 코드를 직접 실행해보지도 않고, 어떻게 사용하지 않는 코드라고 판단하여 제거할 수 있을까요?

이 시리즈는 이러한 질문들에 대해 이론적인 답변을 찾는 대신, 직접 구현하며 답을 찾아가는 기록입니다. 라이브러리 번들러를 직접 만들어보며 그 블랙박스를 열어보려 합니다.

STEP 2: "Tsup 쓰면 되는데요?"

이 과정을 통해 다음 3가지를 얻을 수 있습니다.

1. 에러 메시지 해석 능력

2. 도구에 대한 적응력

STEP 3: 범위 설정

"프로덕션 레벨의 번들러"를 만드는 것이 목표가 아닙니다. 복잡한 기능은 제외하고, 번들러의 본질적인 역할에만 집중합니다.

다루는 것

'간단한 번들러' 를 목표로 다음 5가지를 직접 구현합니다.

1. Resolve: import 경로를 찾아내는 Node.js의 규칙
2. Dependency Graph: 파일을 읽어 AST로 변환하고, 파일 간 관계 연결
3. Transform: magic-string을 활용한 코드 조작
4. Generate: IIFE로 스코프를 격리하여 하나로 병합
5. Sourcemap: 디버깅을 위해 원본과 번들 연결

다루지 않는 것

번들러의 본질을 이해하는 데 불필요한 기능은 과감히 생략합니다.

• HMR, Dev Server
• Circular Dependency
• JS 이외의 에셋 처리
• 고도화된 Minification

STEP 4: 로드맵

오직 '모듈을 찾아 하나로 합친다' 는 본질에 집중합니다.

Step 1. 개념과 도구

• 번들러의 역사적 맥락
• ESM이 번들링에 유리한 이유
• 코드 조작 도구 Magic String

Step 2. 그래프 그리기 Coming Soon

• 파일을 읽어 AST로 변환
• import를 추적해 의존성 그래프 구축
• 파일을 찾는 과정 구현

Step 3. 번들링과 스코프 Coming Soon

• 그래프를 순회하며 코드 병합
• IIFE로 스코프 격리
• 브라우저용 require 함수 구현

Step 4. 완성도 높이기 Coming Soon

• 소스맵 원리 파악 및 구현
• react 같은 외부 라이브러리 제외 처리

마치며: 이런 분들께 추천합니다

아래 항목 중 하나라도 해당한다면, 이 시리즈가 도움이 될 것입니다.

• tsup.config.ts 설정이 꼬일 때마다 새로 만들고 싶다는 생각이 든다.
• 배포 후 모듈을 찾을 수 없다는 연락을 받으면 당황스럽다.
• CJS와 ESM이 섞여 있을 때 발생하는 에러를 명확히 설명하기 어렵다.
• 단순히 도구를 사용하는 단계를 넘어 원리를 이해하고 싶다.

번들러라는 블랙박스를 함께 열어보겠습니다.