E-3: 모듈 시스템 심화 & Vite — 여러 파일을 하나로 묶고, 빌드 도구로 배포까지

안녕하세요, 홍순구 튜터입니다. 지난 시간(E-2)에 우리는 실패를 구조화했어요. ApiError를 만들어 상태 코드·주소·사용자 메시지를 담아 던지고, 받는 쪽은 try-catch로 안전하게 받았죠. 그때 제가 마무리에서 두 가지를 살짝 흘렸어요.

하나는 "코드를 네트워크로 받아오다 실패할 수도 있는데, 그때도 오늘 배운 try-catch로 똑같이 감싼다"였고, 다른 하나는 "배포할 때 코드를 잘게 압축하면 stack이 알아볼 수 없게 되는데, 다음 시간 빌드 도구가 그걸 풀어준다"였어요. 오늘 그 두 약속을 모두 회수해요.

우리는 C-5부터 import / export로 코드를 파일별로 나눠 써왔어요. 그 모듈 시스템을 오늘 한 단계 더 깊이 들여다보고, Vite라는 빌드 도구로 우리 인스타그램 프로젝트를 옮겨요.

   지금까지 (Live Server)               오늘 (Vite 빌드 도구)
   ┌─────────────────────────────┐        ┌───────────────────────────────┐
   │ js 파일 여러 개를 그대로    │        │ 여러 파일을 하나로 묶고       │
   │ 브라우저가 직접 읽음        │  ──▶   │ 압축하고, 안 쓰는 코드는 빼고 │
   │ 새로고침해서 확인           │        │ 소스맵으로 원본을 추적        │
   └─────────────────────────────┘        └───────────────────────────────┘

💡 오늘 수업의 핵심 — "여러 모듈을 하나로 묶어주는 번들러의 필요성을 이해하고, Vite로 개발 서버(dev)와 배포 묶음(build)을 만든다. 동적 import()로 필요할 때만 코드를 불러오고, 소스맵으로 압축된 코드를 추적하고, Tree Shaking으로 안 쓰는 코드를 덜어낸다." 🎯

🎯 학습 목표

• 우리가 C-5부터 써온 import/export가 ESM(ECMAScript Modules) 이라는 표준임을 알고, 모듈이 없던 시절과 비교해 무엇이 좋아졌는지 이해합니다.
• ESM과 CommonJS 두 모듈 방식의 차이를 알고, 왜 ESM의 "정적인 구조"가 빌드 도구에 유리한지 이해합니다.
• 동적 import()로 필요할 때만 모듈을 불러오고, 실패는 try-catch로 처리합니다.
• 번들러(bundler) 가 왜 필요한지, 작은 파일 여러 개를 그대로 배포할 때의 문제를 이해합니다.
• Vite를 우리 프로젝트에 얹어 개발 서버(npm run dev)와 배포 묶음(npm run build)을 만듭니다.
• 소스맵(source map) 으로 압축된 코드에서도 원본 파일·줄 번호를 추적합니다.
• Tree Shaking 으로 import하지 않은 코드가 배포 묶음에서 빠지는 것을 확인합니다.

Step 1: "우리가 이미 모듈을 쓰고 있었다고요?"

새로운 걸 배우기 전에, 우리가 이미 하고 있던 걸 다시 봐요. C-5를 떠올려보세요. 그때 우리는 거대한 main.js 한 덩어리를 data.js(데이터) · format.js(꾸미기) · main.js(조립)로 쪼갰어요. 그리고 import / export로 서로 연결했죠. 그게 바로 모듈(module) 이에요. 코드를 기능별 파일로 나누고, 필요한 것만 가져다 쓰는 방식이요.

모듈이 없던 시절은 어땠을까

지금은 당연해 보이지만, 예전 브라우저에는 import가 없었어요. 그 시절 자바스크립트는 파일을 <script> 태그로 하나씩 줄줄이 불러왔어요. 그런데 이 방식엔 두 가지 큰 골칫거리가 있었어요.

  모듈 이전 (전역 변수 시대)              ESM (지금 우리)
  ┌───────────────────────────┐         ┌──────────────────────────┐
  │ <script src="a.js">       │         │ import { x }             │
  │ <script src="b.js">       │         │   from "./a.js";         │
  │ <script src="c.js">       │  ──▶    │                          │
  │ • 순서 틀리면 깨짐        │         │ • 필요한 것만 콕 집어    │
  │ • 전역 변수 충돌 위험     │         │ • 누가 누굴 쓰는지 명확  │
  └───────────────────────────┘         └──────────────────────────┘

첫째, 순서에 목숨을 걸어야 했어요. b.js가 a.js의 함수를 쓰는데 <script> 순서가 뒤바뀌면, 아직 없는 함수를 부르다 깨졌어요. 둘째, 모든 변수가 전역(global) 으로 섞였어요. a.js의 user와 b.js의 user가 같은 이름이면 서로 덮어써 버렸죠. 파일이 수십 개가 되면 누가 누구를 망가뜨리는지 추적이 거의 불가능했어요.

ESM은 이걸 깔끔하게 풀었어요. 파일마다 export로 "이건 밖에서 써도 돼"라고 내놓고, 쓰는 쪽은 import로 "나는 이 파일에서 이것만 가져올게"라고 콕 집어요. 순서는 import가 알아서 맞추고, 변수는 파일 안에 숨어 충돌하지 않아요.

지금 우리 feed.js가 모듈을 어떻게 엮고 있나

우리 피드 화면의 출발점은 feed.js예요. 맨 위를 보면 일곱 줄의 import가 있어요. 이게 곧 "피드 화면을 그리려면 이 파일들이 필요해"라는 지도예요.

// instagram-clone-frontend/js/feed.js
import { fetchPosts, createComment } from "./api.js";
import { ApiError } from "./api-error.js";
import { toggleLike } from "./like.js";
import { addComment, removeComment } from "./comment.js";
import { setupInfiniteScroll } from "./infinite-scroll.js";
import { PostCard, AdPostCard } from "./post-card.js";
import { ThemeToggle } from "./theme-toggle.js";

그리고 api.js는 또 자기 나름대로 auth.js와 api-error.js를 import해요. 이렇게 import가 import를 부르면서 파일들이 나무처럼 이어져요. 이걸 모듈 그래프(module graph) 라고 불러요.

  feed.html
     └─ <script type="module" src="js/feed.js">
           feed.js ─┬─ api.js ─┬─ auth.js
                    │          └─ api-error.js
                    ├─ like.js
                    ├─ comment.js
                    ├─ infinite-scroll.js
                    ├─ post-card.js
                    └─ theme-toggle.js

지금은 이 그래프를 브라우저가 직접 따라가요. C-5에서 배웠듯이 <script type="module">을 만나면, 브라우저가 feed.js를 읽고, 거기서 만난 import를 보고 api.js를 또 받아오고… 이렇게 한 파일씩 네트워크로 받아가며 그래프를 펼쳐요. 오늘 이 "한 파일씩 받아가는" 방식이 배포할 때 왜 문제가 되는지, 그리고 Vite가 그걸 어떻게 푸는지를 차근차근 볼 거예요.

Step 2: "import에 두 종류가 있다고요? — ESM vs CommonJS"

우리가 쓰는 import / export에는 정식 이름이 있어요. ESM, 풀어 쓰면 ECMAScript Modules예요. ECMAScript는 자바스크립트의 공식 표준 이름이고, 그 표준이 정한 모듈 방식이라 ESM이에요. 브라우저가 알아듣는 모듈은 이거예요.

그런데 자바스크립트 세계엔 모듈 방식이 하나 더 있어요. CommonJS예요. 이름이 둘이라니, 왜 이렇게 됐을까요?

왜 두 가지가 생겼나 — 짧은 역사

순서가 이래요. 브라우저 밖에서 자바스크립트를 돌리는 도구(우리가 json-server를 켤 때 쓰는 그 런타임)가 먼저 세상에 나왔는데, 그때는 아직 자바스크립트 표준에 모듈 기능이 없었어요. 그래서 그 도구는 자기만의 모듈 방식을 만들어 썼고, 그게 CommonJS예요. require()로 가져오고 module.exports로 내보내요.

한참 뒤에야 자바스크립트 표준 자체가 모듈을 정식으로 품었어요. 그게 ESM이에요. 그래서 지금은 브라우저·표준은 ESM, 오래된 도구 생태계엔 CommonJS가 함께 남아 있어요.

                 ESM (우리가 쓰는 표준)        CommonJS (오래된 방식)
  가져오기        import { x } from "./a.js"    const x = require("./a.js")
  내보내기        export function x() {}        module.exports = { x }
  주로 쓰는 곳     브라우저 · 최신 표준           오래된 서버 도구

우리 교재의 코드는 전부 ESM이에요. CommonJS의 require는 "이런 게 있구나" 정도로만 알아두면 충분해요. 우리가 직접 쓸 일은 없어요.

진짜 중요한 차이 — "미리 알 수 있느냐"

겉모습 말고, 오늘 수업에서 진짜 의미 있는 차이가 하나 있어요. ESM의 import는 파일 맨 위에 고정으로 적어요. 함수 안에서 조건에 따라 가져오거나 하지 않아요. 그래서 코드를 실행하기 전에 "이 파일은 무엇을 가져오고 무엇을 내보내는지"를 그냥 읽기만 해도 전부 알 수 있어요.

반면 CommonJS의 require()는 함수처럼 코드 중간 아무 데서나 부를 수 있어요. if (조건) { require(...) }처럼요. 그러면 실제로 돌려보기 전엔 무엇을 가져올지 확실히 알기 어려워요.

이 "미리 다 알 수 있다"는 ESM의 성질이 왜 중요하냐면, 빌드 도구가 코드를 실행하지 않고도 분석할 수 있게 해주거든요. 누가 무엇을 쓰는지 미리 다 보이니까, "이건 아무도 안 쓰네? 그럼 빼자"가 가능해져요. 이게 Step 8에서 만날 Tree Shaking의 바탕이에요. 지금은 "ESM은 구조가 고정이라 미리 분석된다" 한 문장만 기억하고 넘어가요.

Step 3: "필요할 때만 불러오기 — 동적 import()"

지금까지 우리 import는 전부 파일 맨 위에 있었어요. 화면이 켜지는 순간 일곱 개 모듈이 무조건 다 따라 들어왔죠. 그런데 생각해보면, 어떤 기능은 사용자가 영영 안 쓸 수도 있어요. 그런 코드까지 첫 화면에서 다 받아오면 그만큼 느려져요.

그래서 자바스크립트엔 필요한 순간에 불러오는 방법이 따로 있어요. 함수처럼 생긴 import()예요. 맨 위의 정적 import와 구분해서 동적 import() 라고 불러요.

  정적 import (맨 위, 항상)            동적 import() (필요할 때, Promise)
  import { x } from "./a.js";        const m = await import("./a.js");
  • 화면 켜질 때 무조건 로드          • 그 줄을 만나는 순간에 로드
  • 파일 맨 위에만                    • 함수 안 아무 데서나

핵심은 동적 import()가 Promise를 돌려준다는 거예요. 모듈을 네트워크로 받아오는 데 시간이 걸리니까, C-6에서 배운 그 Promise 그대로예요. 그래서 await로 기다렸다가 꺼내 써요.

댓글창에 이모지 고르개를 달아보자

우리 댓글 폼에 이모지 버튼(😊)을 하나 달았어요. 이 버튼을 누르면 이모지를 고르는 작은 패널이 떠요. 그런데 이 이모지 고르개는 누군가 버튼을 누르기 전엔 필요 없어요. 그래서 첫 화면엔 빼두고, 버튼을 누르는 그 순간에야 받아오게 만들었어요.

먼저 댓글 폼에 버튼을 더했어요. PostCard가 그리는 댓글 폼 안이에요.

<!-- instagram-clone-frontend/js/post-card.js — 댓글 폼 템플릿 -->
<form class="comment-form">
  <textarea class="comment-input" rows="1" placeholder="댓글 달기..." aria-label="댓글 입력"></textarea>
  <button type="button" class="comment-emoji" aria-label="이모지 넣기">😊</button>
  <button type="submit">게시</button>
</form>

그리고 feed.js의 위임 클릭 핸들러에 이 버튼을 처리하는 가지를 더했어요. 바로 여기가 오늘의 주인공이에요.

// instagram-clone-frontend/js/feed.js — 댓글 위임 클릭 핸들러 안
const emojiBtn = event.target.closest(".comment-emoji");
if (emojiBtn) {
  const input = emojiBtn.closest(".comment-form").querySelector(".comment-input");
  try {
    // import()는 Promise 를 돌려줘요 — 모듈이 도착할 때까지 기다렸다(await) 꺼내 써요.
    const { openEmojiPicker } = await import("./emoji-picker.js");
    openEmojiPicker(emojiBtn, input);
  } catch (error) {
    // 네트워크로 받아오다 실패할 수도 있어요 — 비동기가 있는 곳엔 에러 처리가 따라다녀요.
    showToast("이모지 고르개를 불러오지 못했어요.");
    console.error("emoji-picker 로딩 실패:", error);
  }
}

await import("./emoji-picker.js")가 모듈을 받아온 뒤, 거기서 openEmojiPicker 함수를 꺼내 바로 써요. 이 줄을 만나기 전까지 emoji-picker.js는 받아오지 않아요. 사용자가 😊를 처음 누르는 순간에야 도착해요.

여기서 지난 시간의 약속을 회수해요. 모듈을 네트워크로 받아오니까, 신호가 끊기면 실패할 수 있어요. 그래서 동적 import()도 try-catch로 감쌌어요. E-2에서 익힌 그 감각 그대로예요. "비동기가 있는 곳엔 에러 처리가 따라다닌다"는 말, 여기서도 똑같이 통해요.

⚠️ 핸들러 맨 윗줄을 보면 feed.addEventListener("click", async (event) => {처럼 async가 붙어 있어요. 안에서 await를 쓰려면 그 함수가 async여야 하기 때문이에요. 이모지 가지를 더하면서 기존 클릭 핸들러를 async로 바꿨어요.

Step 4: "작은 파일 여러 개의 함정 — 번들러는 왜 필요한가"

이제 오늘의 큰 그림으로 가요. 우리 피드 화면은 모듈 그래프(Step 1)를 따라 파일이 여덟 개쯤 이어져 있어요. 지금까지는 브라우저가 이걸 한 파일씩 받아왔어요. 개발할 땐 별 문제가 없어요. 내 컴퓨터 안이라 빠르니까요.

문제는 배포예요. 진짜 사용자가 멀리 떨어진 서버에서 우리 사이트를 열면, 브라우저는 파일 하나를 받고 → 그 안의 import를 읽고 → 다음 파일을 또 요청하고 → 그걸 받아 또 읽고… 이렇게 줄줄이 이어가요. 파일이 많을수록 이 왕복이 쌓여 느려져요.

  번들 전: 브라우저가 파일마다 따로 왕복
  feed.js ─▶ (받고 분석) ─▶ api.js ─▶ (받고) ─▶ auth.js ─▶ ...
            요청 ①           요청 ②          요청 ③      ... 요청 ⑧

  번들 후: 미리 하나로 합쳐 한 번에
  feed-abc123.js  ◀── 요청 ① (끝)

여기서 번들러(bundler) 가 등장해요. 번들(bundle)은 "묶음"이라는 뜻이에요. 번들러는 흩어진 모듈들을 미리 따라가며 하나(또는 몇 개)의 파일로 합쳐 줘요. 그러면 브라우저는 왕복을 여러 번 할 필요 없이 합쳐진 파일을 한 번에 받아요.

번들러가 하는 일은 합치기만이 아니에요. 합치는 김에 이런 것도 해줘요.

• 압축(minify): 공백·줄바꿈·긴 변수 이름을 줄여 파일 크기를 작게 만들어요.
• 안 쓰는 코드 제거(Tree Shaking): export했지만 아무도 import 안 한 코드는 묶음에서 빼요. (Step 8)
• 필요할 때만 쪼개기(code splitting): Step 3의 동적 import()로 부른 모듈은 따로 떼어 둬요. 첫 묶음엔 안 넣고, 진짜 필요할 때 그 조각만 받아오게요.

마지막 항목이 바로 Step 3과 이어져요. 우리가 이모지 고르개를 동적 import()로 부른 덕분에, 번들러는 그걸 첫 화면 묶음에서 떼어내 별도 조각으로 만들어요. 그래서 첫 화면은 그만큼 가벼워져요.

자, 그러면 이 똑똑한 번들러를 우리가 직접 손으로 만들어야 할까요? 다행히 아니에요. 잘 만들어진 도구가 있어요. 바로 Vite예요. 다음 Step에서 만나요.

Step 5: "Vite 만나기 — 우리 프로젝트에 빌드 도구 얹기"

Vite(비트라고 읽어요)는 요즘 가장 널리 쓰이는 프론트엔드 빌드 도구예요. 방금 이야기한 번들러를 품고 있으면서, 개발할 때 쓰는 빠른 서버까지 함께 줘요. 우리 인스타그램 프로젝트를 Vite로 옮겨볼게요.

npm — 도구를 받아오는 창구

지금까지 우리는 D-3에서 json-server를 쓸 때 말고는 외부 도구를 거의 안 썼어요. Vite는 우리가 직접 짤 수 없는 도구라, 만들어진 걸 받아와야 해요. 그 창구가 npm이에요. (Node 생태계의 패키지 관리자예요. json-server를 켤 때 쓰던 그 도구 묶음이에요.)

먼저 우리 프로젝트가 어떤 도구를 쓰는지 적어두는 명세서, package.json을 만들어요.

// instagram-clone-frontend/package.json
{
  "name": "instagram-clone-frontend",
  "version": "1.0.0",
  "private": true,
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview",
    "mock": "json-server mock/db.json --port 3001"
  },
  "devDependencies": {
    "vite": "^8.0.16"
  }
}

scripts는 "이 이름으로 부르면 이 명령을 실행해줘"라는 단축키 모음이에요. npm run dev라고 치면 vite가 돌아가는 식이에요. "type": "module"은 "이 프로젝트는 ESM을 쓴다"는 선언이고요(우리가 줄곧 import/export를 써왔으니 당연하죠).

그다음 Vite를 실제로 받아와요. 터미널에서 한 줄이면 돼요.

npm install -D vite

이러면 node_modules라는 폴더에 Vite와 그게 필요로 하는 부품들이 내려받아져요. -D는 "개발할 때만 쓰는 도구"라는 표시예요(배포 결과물엔 Vite 자체는 안 들어가요).

vite.config.js — Vite에게 우리 프로젝트를 소개하기

Vite는 기본적으로 index.html 하나를 출발점으로 봐요. 그런데 우리 프로젝트는 페이지가 여러 개예요(로그인 index.html, 피드 feed.html, 프로필 profile.html). 그래서 "이 HTML들이 각각 출발점이야"라고 알려주는 설정 파일을 둬요.

// instagram-clone-frontend/vite.config.js
import { defineConfig } from 'vite';

export default defineConfig({
  build: {
    // 압축된 코드에서도 원본 파일·줄 번호를 추적하도록 소스맵을 켜요.
    sourcemap: true,
    rollupOptions: {
      input: {
        main: 'index.html',
        feed: 'feed.html',
        profile: 'profile.html',
      },
    },
  },
});

input에 세 페이지를 적어, "이 셋을 각각 묶어줘"라고 부탁했어요. sourcemap: true는 잠시 뒤 Step 7에서 진가를 발휘할 설정이에요(압축된 코드를 원본으로 되짚는 지도를 함께 만들어줘요).

여기서 반가운 사실 하나. 우리 프로젝트는 C-5부터 줄곧 ESM(import/export)으로 짜왔고, HTML도 이미 <script type="module">로 모듈을 불러오고 있었어요. 그래서 Vite로 옮기는 데 고칠 게 거의 없었어요. 설정 파일 하나만 두면 끝이에요. 평소에 모듈을 제대로 써온 보람이 여기서 나와요.

Step 6: "npm run dev — 개발 서버와 즉시 반영(HMR)"

설정을 마쳤으니 개발 서버를 켜요. 터미널에서 한 줄이에요.

npm run dev

그러면 Vite가 주소를 하나 알려줘요. http://localhost:5173예요. 이 주소를 브라우저로 열면 우리 사이트가 떠요. 지금까지 쓰던 Live Server를 Vite의 개발 서버가 대신하는 거예요.

⚠️ 우리는 D-3부터 데이터를 json-server(포트 3001)에서 받아왔죠. 그건 그대로예요. 터미널 하나에선 npm run dev(우리 사이트, 5173), 다른 하나에선 npm run mock(가짜 API, 3001)을 함께 켜두면 돼요.

Live Server와 뭐가 다를까 — HMR

겉보기엔 비슷한데, 개발 경험에서 큰 차이가 하나 있어요. HMR, 풀어 쓰면 Hot Module Replacement(뜨거운 모듈 교체)예요.

Live Server는 파일을 저장하면 페이지 전체를 새로고침했어요. 그래서 입력하던 내용이나 열어둔 상태가 날아갔죠. Vite의 HMR은 바뀐 그 모듈만 콕 집어 화면에 갈아끼워요. 전체 새로고침 없이요. CSS 한 줄을 고치면, 화면은 그대로인 채 색만 스르륵 바뀌는 식이에요. 작업하다 보면 이 차이가 생각보다 크게 느껴져요.

  Live Server            Vite (HMR)
  파일 저장               파일 저장
     ↓                      ↓
  페이지 전체 새로고침      바뀐 모듈만 교체
  (상태 날아감)            (상태 유지, 깜빡임 없음)

이 개발 서버는 우리가 쓴 코드를 묶지 않고 그대로 보여줘요. 그래서 브라우저 개발자 도구로 열어보면 js/feed.js가 우리가 쓴 모습 그대로 보여요. 개발 중엔 원본 그대로가 디버깅하기 편하니까요. 진짜로 합치고 압축하는 건 배포할 때예요. 그게 다음 Step이에요.

Step 7: "npm run build — 배포용 묶음과 소스맵"

개발이 끝나고 진짜 사용자에게 내보낼 차례가 되면, 배포용 묶음을 만들어요.

npm run build

그러면 Vite가 모듈 그래프를 전부 따라가 합치고, 압축하고, dist라는 폴더에 결과물을 만들어요. dist는 distribution(배포)의 줄임말이에요. 우리 프로젝트에서 만들어진 결과를 그려보면 이래요.

  src (우리가 쓴 코드)              dist (배포용 묶음)
  js/feed.js  ┐                   assets/feed-CeR4U_ri.js     ← 8개 모듈을 1개로 (압축)
  js/api.js   │                   assets/emoji-picker-*.js    ← 동적 import 조각은 따로
  js/auth.js  ├─ vite build ─▶    assets/responsive-*.css     ← CSS 6개를 1개로
  css/*.css(6)┘                   feed.html  (script·link 자동 교체)
                                   assets/*.js.map             ← 원본 추적용 지도

눈여겨볼 게 많아요. 첫째, feed.js가 import하던 여덟 개 모듈이 하나의 파일로 합쳐졌어요. 여섯 개였던 CSS도 하나로 묶였고요. 둘째, 파일 이름에 feed-CeR4U_ri.js처럼 알 수 없는 글자가 붙었어요. 이건 내용이 바뀔 때마다 달라지는 표식이에요(캐시 때문인데, 자세한 건 F 카테고리 성능 편에서 다뤄요). 셋째, feed.html 안의 <script>·<link> 주소도 이 새 파일 이름으로 자동으로 바뀌어 있어요. 우리가 손댈 필요 없이요.

그리고 Step 3에서 동적 import()로 불렀던 이모지 고르개는 emoji-picker-*.js라는 별도 조각으로 떨어져 나왔어요. 첫 화면 묶음(feed-*.js)엔 안 들어가 있어요. 이게 바로 Step 4에서 예고한 코드 스플리팅이에요. 사용자가 😊를 누를 때에야 이 조각이 따로 도착해요.

압축된 코드와 소스맵 — 지난 시간의 약속 회수

이제 지난 시간(E-2)에 흘린 두 번째 약속을 회수해요. 배포용으로 압축된 feed-*.js를 열어보면, 우리가 정성껏 지은 이름들이 이렇게 뭉개져 있어요.

// 압축된 배포 묶음의 일부 — 변수 이름이 한 글자로 줄어 있어요
var n=class extends Error{constructor(e,t,n){super(`API ${e} 응답 — ${t}`),this.name=`ApiError`,...

ApiError의 그 깔끔한 코드가 e, t, n 같은 한 글자로 변했죠. 파일을 작게 만들려고 일부러 이렇게 줄인 거예요. 그런데 E-2에서 걱정했듯이, 이 상태에서 에러가 나면 stack(에러가 난 위치 추적표)이 이 뭉개진 코드를 가리켜요. "n 파일 1번째 줄에서 났어요"라고 하면 어디가 어딘지 알 수가 없죠.

그래서 우리가 vite.config.js에 켜둔 sourcemap: true가 일을 해요. 빌드할 때 feed-*.js.map이라는 지도 파일을 함께 만들어요. 이 지도가 "압축된 코드의 이 위치는 사실 원본 js/api-error.js의 몇 번째 줄이야"를 전부 기록해둬요. 그래서 개발자 도구는 압축된 코드를 보면서도 원본 파일·줄 번호로 에러 위치를 되짚어 보여줄 수 있어요. E-2에서 "압축하면 stack을 못 알아본다"던 걱정이 소스맵으로 풀린 거예요.

npm run preview — 배포 묶음을 미리 확인하기

dist 폴더가 진짜 잘 도는지 배포 전에 확인하고 싶을 때가 있어요. 그때 쓰는 명령이에요.

npm run preview

이건 개발 서버(dev)와 달리, 방금 빌드한 dist 묶음을 그대로 띄워줘요. 사용자가 받을 모습 그대로 미리 보는 거예요. 여기서 화면이 잘 돌고 이모지 조각도 잘 도착하면, 배포 준비가 끝난 거예요.

Step 8: "안 쓰는 코드는 떨어진다 — Tree Shaking"

마지막으로, Step 2에서 심어둔 씨앗을 거둬요. ESM은 구조가 고정이라 "누가 무엇을 쓰는지" 미리 다 분석된다고 했죠. 그 덕분에 번들러는 아무도 안 쓰는 코드를 찾아낼 수 있어요. 그리고 배포 묶음에서 그걸 빼버려요. 이걸 Tree Shaking(나무 흔들기)이라고 불러요. 나무를 흔들면 죽은 잎이 떨어지듯, 안 쓰는 코드가 떨어진다는 비유예요.

우리 util.js로 직접 확인하기

D-2에서 만든 util.js를 떠올려보세요. 디바운스와 스로틀, 두 함수를 export해뒀어요.

// instagram-clone-frontend/js/util.js
export function debounce(fn, delay) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), delay);
  };
}

export function throttle(fn, delay) {
  let waiting = false;
  return (...args) => {
    if (waiting) return;
    fn(...args);
    waiting = true;
    setTimeout(() => { waiting = false; }, delay);
  };
}

그런데 우리 이모지 고르개(emoji-picker.js)는 이 중 debounce만 가져다 써요. 검색창에 글자를 칠 때마다 거르지 않고, 다 치고 잠깐 멈춘 뒤에 한 번만 거르려고요.

// instagram-clone-frontend/js/emoji-picker.js (발췌)
import { debounce } from "./util.js";

export function openEmojiPicker(anchorButton, targetInput) {
  // ... 패널을 만들고 이모지 격자를 그려요 ...

  // 검색창 입력은 디바운스 — 다 치고 손을 뗀 뒤에야 한 번 걸러요.
  search.oninput = debounce(() => renderGrid(grid, targetInput, search.value), 200);

  // ... anchor 버튼 근처에 띄워요 ...
}

debounce만 import하고 throttle은 어디서도 안 써요. 그러면 Vite는 빌드할 때 "throttle은 아무도 안 쓰네?" 하고 배포 묶음에서 빼버려요. 빌드해서 결과물을 열어보면, debounce의 코드는 들어 있는데 throttle의 코드는 흔적도 없어요. import 하나 차이로 안 쓰는 함수가 깔끔하게 떨어진 거예요.

이게 가능한 건 우리가 ESM을 썼고, util.js가 그냥 함수만 내보내는 깔끔한 모듈이기 때문이에요. 만약 모듈이 불러오는 것만으로 화면을 건드리는 동작(부수 효과)을 한다면, 번들러는 "혹시 필요할지 몰라" 하고 함부로 못 빼요. 그래서 "안 쓰는 건 빠진다"는 효과를 제대로 누리려면, 모듈을 부수 효과 없이 깔끔하게 짜는 습관이 중요해요.

마무리

오늘 우리는 모듈 시스템을 한 단계 깊이 들여다보고, 빌드 도구 Vite로 우리 프로젝트를 옮겼어요.

• ESM: 우리가 C-5부터 써온 import/export의 정식 이름. 모듈 이전의 전역 변수·순서 문제를 풀어줬어요.
• ESM vs CommonJS: 브라우저·표준은 ESM, 오래된 도구는 CommonJS. ESM은 구조가 고정이라 미리 분석돼요.
• 동적 import(): 필요할 때만 불러오기. Promise라서 await로 받고, 실패는 try-catch로(E-2 회수).
• 번들러: 흩어진 모듈을 합치고 압축하고 안 쓰는 코드를 덜어내요.
• Vite: npm run dev(개발 서버 + HMR) · npm run build(배포 묶음) · npm run preview(미리 보기).
• 소스맵: 압축된 코드를 원본 파일·줄로 되짚어요(E-2 회수).
• Tree Shaking: import 안 한 코드는 배포 묶음에서 떨어져요.

지난 시간 두 약속 — 동적 import() 실패도 try-catch로, 압축된 코드도 소스맵으로 — 둘 다 오늘 지켰어요. 에러를 다루던 감각과 모듈을 다루는 감각이 Vite 위에서 한데 만났어요.

다음 시간 예고

다음 시간(F-1)부터는 웹 성능으로 넘어가요. 오늘 우리가 만든 배포 묶음이 얼마나 빠른지를 숫자로 측정하기 시작해요. 화면이 얼마 만에 뜨는지(LCP), 클릭에 얼마나 빨리 반응하는지(INP) 같은 지표를 Lighthouse라는 도구로 재요. 오늘 번들 크기를 줄인 게 그 점수와 직접 이어져요. 그리고 그다음(F-2)엔 오늘 맛본 코드 스플리팅을 본격적으로 써서, 무거운 조각을 잘게 쪼개 더 빠르게 만들어요.

그리고 한 가지만 귀띔할게요. 오늘 만난 Vite는 다음 과목에서 React라는 도구와 함께 다시 만나요. 모듈과 빌드 도구를 제대로 익혀둔 오늘이 그때의 든든한 바탕이 돼요.

과제

오늘은 Vite를 실제로 켜고 굴려보는 게 핵심이에요. 터미널 둘을 준비하세요. 하나는 npm run dev(우리 사이트), 다른 하나는 npm run mock(가짜 API, 포트 3001)이에요.

[구현] 동적 import로 모듈을 하나 더 미뤄보기

오늘 이모지 고르개를 동적 import()로 불렀죠. 같은 방식으로, 사용자가 자주 안 쓰는 기능을 하나 골라 똑같이 미뤄보세요.

• 예를 들어 게시물의 "공유" 버튼을 눌렀을 때에야 공유 관련 코드를 받아오게 만들어보세요. 새 모듈(예: js/share-card.js)에 함수 하나를 export하고, feed.js에서 버튼을 누를 때 await import("./share-card.js")로 불러오면 돼요.
• 반드시 try-catch로 감싸세요. 모듈을 받아오다 실패할 수 있다는 걸 잊지 마세요.
• npm run build로 빌드한 뒤 dist/assets 폴더를 열어보세요. 여러분이 미룬 그 모듈이 별도 조각 파일로 떨어져 나왔나요?

[구현] 소스맵으로 원본 위치 추적하기

vite.config.js에 sourcemap: true를 켜둔 효과를 직접 확인해보세요.

• npm run build로 빌드한 뒤 npm run preview로 그 결과를 띄우세요.
• 개발자 도구 Sources 탭을 열어보세요. 압축된 feed-*.js만 있는 게 아니라, 원본 js/feed.js·js/api.js 모습도 함께 보이나요? 소스맵이 만들어준 거예요.
• 일부러 코드 한 곳에서 에러를 내보세요(예: 없는 함수 호출). 콘솔의 에러가 압축된 파일이 아니라 원본 파일의 줄 번호를 가리키는지 확인해보세요.

[탐구] Tree Shaking을 눈으로 확인하기

Step 8에서 throttle이 빠진다고 했죠. 진짜 그런지 직접 실험해보세요.

• npm run build로 빌드한 결과물(dist/assets의 js 파일)을 텍스트 에디터로 열어보세요. clearTimeout(디바운스가 쓰는 함수)은 보이는데, 스로틀만의 코드는 안 보이나요?
• 이번엔 emoji-picker.js에서 throttle도 함께 import하고 어딘가에서 한 번 써보세요. 다시 빌드하면 결과물 크기가 어떻게 달라지나요?
• 안 쓰던 코드를 쓰기 시작하니 묶음에 다시 들어오는 걸 보면, "import가 곧 묶음의 명단"이라는 감각이 잡힐 거예요.

생각해볼 주제

정답을 적는 문제가 아니에요. 오늘 배운 것의 "왜"를 곱씹어보는 질문들이에요. 스스로 답을 만들어본 뒤, 예시답안과 비교해보세요.

1. 모든 걸 동적 import로 미루면 더 빠를까?

동적 import()로 미루면 첫 화면이 가벼워진다고 배웠어요. 그러면 모든 모듈을 다 동적 import()로 미루면 가장 빠를까요?

그런데 미룬 모듈은 나중에 별도로 받아와야 해요. 사용자가 그 기능을 누르는 순간, 잠깐 기다림이 생기죠. 너무 잘게 쪼개 미루면 오히려 누를 때마다 끊기는 느낌이 날 수도 있어요. 어떤 코드는 첫 화면에 함께 넣는 게 낫고, 어떤 코드는 미루는 게 나을까요? 그 경계를 우리 인스타그램 화면을 예로 생각해보세요.

2. 개발 서버는 안 묶는데, 배포는 왜 묶을까?

Vite는 개발할 땐(dev) 모듈을 안 묶고 그대로 보여주고, 배포할 땐(build) 하나로 묶어요. 같은 도구가 왜 두 상황에서 정반대로 행동할까요?

개발할 때 중요한 것과 배포할 때 중요한 것이 다르기 때문이에요. 개발 중엔 무엇이 더 중요하고(고치고 바로 확인하기?), 사용자에게 내보낼 땐 무엇이 더 중요할까요(빠르게 받기?)? 두 상황의 우선순위가 어떻게 다른지, 그게 왜 "안 묶기 vs 묶기"라는 정반대 선택으로 이어지는지 정리해보세요.

3. ESM의 고정된 구조가 왜 도구에 유리할까?

오늘 "ESM은 import가 맨 위에 고정이라 미리 분석된다, 그래서 Tree Shaking이 된다"고 했어요. CommonJS의 require()는 코드 중간 아무 데서나 부를 수 있어서 미리 알기 어렵다고 했고요.

여기서 한 걸음 더 들어가 보세요. 만약 우리가 import를 if문 안에 조건부로 넣을 수 있었다면, 번들러는 "이 코드는 쓰일까 안 쓰일까"를 어떻게 판단해야 할까요? "제약이 오히려 도구에 자유를 준다"는 말이 모듈 시스템에서 어떻게 들어맞는지 곱씹어보세요.