Next.js 15 컴파일러 Turbopack 분석과 웹팩(Webpack)에서 넘어갈 때 겪는 함정들

Webpack 황금시대의 몰락과 Rust 기반 최강 번들러 터보 시대의 개막

지난 10년간 자바스크립트 프론트엔드 생태계, 특히 모범적인 리액트 보일러플레이트 권력을 양분했던 웹팩(Webpack)은 무수히 많은 플러그인과 호환성의 대명사로 군림했습니다. 하지만 이 거대한 생명체는 프로젝트가 엔터프라이즈 모노레포급으로 몸집을 불릴 때마다 속수무책으로 무너졌습니다. 파일 수십 개를 수정하고 `npm run dev` 스크립트를 누르면 개발 서버 부팅에만 최소 2~3분, 소스 코드 오타 한 줄 고치고 브라우저 새로고침을 기다리는 핫 리로드(HMR) 시간에 10초 이상의 지옥 같은 컴파일 병목을 야기하며 대한민국 프론트엔드 개발자들의 조기 퇴사와 커피타임을 강제로 생성하는 주범에 등극했습니다. Next.js를 이끄는 Vercel 팀이 작심하고 Rust를 기반으로 엔진 밑바닥부터 C++ 뺨치는 퍼포먼스로 재작성하여 내어놓은 **Turbopack(터보팩)**은 Next.js 15를 기점으로 완전히 공식적인 기본 번들러 체계로 승격되며 생태계를 뒤집어 엎었습니다. 메모리 내 함수 모듈 단위의 환상적인 점진적 연산 캐싱(Incremental Computation) 트리를 엮어서, 오직 컴포넌트가 수정된 아주 자그마한 파일의 특정 함수 엣지 조각만을 파악하고 0.01초 만에 브라우저에 새로 그리는 방식은 V8 단일 스레드의 파싱 제한을 우습게 짓밟아버릴 정도로 쾌적한 애자일 개발 경험의 극치를 창출해 냅니다.

환상 뒤에 숨겨진 잔혹함: 실무 이관 시 직면하는 무한 호환성 지뢰밭들

그러나 생태계 인프라를 바닥부터 뜯어고치는 교체 시기의 과도기는 항상 유혈 사태를 필연적으로 동반합니다. 저 역시 올해 대규모 B2C 커머스 앱의 코어 엔진을 최신 터보팩 환경으로 이관하는 마이그레이션을 주도하다가, 프로젝트 역사상 존재를 잊고 지냈던 온갖 서드파티 레거시 라이브러리(이를테면 업데이트가 3년 전에 끊긴 구형 애니메이션 라이브러리나 회사 내부적으로 독자 컴파일해서 쓰던 비표준 복잡한 SCSS 변수 로더 체인 등)가 터보의 CJS/ESM 엄격 모드 분석기 위에서 `Module not found` 패닉이나 무한 라우팅 트리 루프를 일으켜 시스템 전체 창을 하얗게 벽돌로 만들어버리는 저주를 몸소 받아냈습니다. 터보팩은 구글과 공식 문서상에서 Webpack 생태계의 호환성을 최대한 지원한다고 프로파간다를 펴고 있지만, 실상 내부 로더 파이프라인의 생명 주기 위상학 스텝이 완전히 상이합니다. 과거 Webpack.config.js 안에서 정규식으로 지저분하게 폴리필(Polyfill)을 구워 넣거나 변태적인 런타임 injection 플러그인 꼼수에 의존하던 낡은 커스텀 모듈들은 사전에 완벽하게 로직을 최신 ESM 플랫폼으로 정리(Refactoring)해 두지 않으면 HMR 터미널 시퀀스와 함께 CPU 점유율이 200%로 솟구치며 Node 프로세스가 뻗어버리는 대참사를 매일 겪게 됩니다. 마치 낡은 구형 마차 바퀴에 페라리 8기통 자연흡기 엔진을 달아놓고 액셀을 최대로 밟아 바퀴 축이 폭발하는 사태와 동일합니다.

컴파일러 캐시 침수와 에러 추적 무력화의 공포

또 다른 터보 팩 이관 시의 지독한 난관은 바로 `.next` 디렉토리 하위의 강박적인 캐싱 파일 구조에 있습니다. 빌드 속도를 극한으로 앞당기기 위해 터보팩은 디스크 내부에 `.sst` 확장자를 띤 바이너리 수준의 청크를 괴물처럼 남기며 메모리 트리를 직렬화하는데, Windows 기반의 PC 환경이나 특정 도커 개발 망에서 파일 시스템 감시(Watcher)와의 동기화 타이밍이 초 단위로 어긋나면 이전 과거의 잘못된 에러 캐시를 끝까지 물고 놔주지 않는 파멸적 고집을 피웁니다. 분명히 소스코드를 고쳐서 버그를 해결했음에도 브라우저에는 새빨간 Hydration 에러 창이 내려오지 않으며, 개발자로 하여금 내 뇌가 미쳐버린 건지 터보팩이 미친 건지 고민하게 만듭니다. 이럴 때는 강제로 로컬 터미널 서버를 죽이고 `.next` 전체 폴더를 휴지통에 밀어버린 뒤 처음부터 물리적인 콜드 스타트 빌드를 다시 때려야만 정상적인 정신 건강을 되찾을 수 있었습니다. 결국 이 모든 과도기는 자바스크립트 생태계가 모듈의 순수 함수화를 철저하게 지향해 나가야 한다는 아키텍처적 반성의 교훈이 되었습니다.

자주 묻는 질문 (FAQ)

Q. 그럼에도 프로덕션 실서버 배포 (Build)에는 아직 터보팩을 쓰지 말고 웹팩을 써야 안전할까요?

Next.js 14 이하의 초중기 버전에서는 무조건 프론트 개발 환경(dev)에서만 터보팩을 조심스럽게 지원했고, 정적 파일 패키징 최적화의 기술적 한계 탓에 그 말이 사실이었습니다. 하지만 기나긴 테스트를 마치고 탄생한 Next.js 15 부터는 공식적으로 상용 배포 명령어에도 `next build --turbo` RC 옵션을 당당히 오픈하며, 빌드 단계에서의 난관마저 뚫어내고 웹팩을 지구상에서 완전히 격리 제거하기 위한 무자비한 체제 전환에 박차를 가하고 있습니다. 단, 배포를 앞두고 내부 QA를 철저히 두 번 이상 거친 후에 도입하길 권장합니다.

Q. Turbopack 환경과 Vite 환경을 놓고 신규 프로젝트를 꼴 때 어떤 선택을 해야 할지 기준을 잡아주세요.

거대한 React 프레임워크 환경에서 SSR(서버 사이드 렌더링), RSC(React Server Components), SEO 친화적인 서버 라우팅 기반의 커머스나 미디어 매체 생태계를 반드시 구축해야만 한다면 얄짤없이 Turbopack을 등에 업고 Next.js 15 기차에 탑승하셔야 합니다. 그러나 그딴 건 다 필요 없고, 단순한 대시보드 사내 인트라넷, 어드민 툴, 혹은 극단적으로 가벼운 클라이언트 사이드 렌더링(CSR) 전용 순수 SPA 앱을 만든다면 현재 압도적인 플러그인의 무결성과 esbuild의 미친 스피드를 자랑하는 Vite 최신 버전 생태계가 훨씬 안정적이고 스트레스 없는 천국입니다.

Q. 웹팩 플러그인으로 커스텀 SVG 처리나 별도의 로더를 달아둔 코드는 터보팩에서 다 버려야 하나요?

가장 많이 부딪히는 벽입니다. Webpack을 위해 CJS로 작성된 수만 개의 개인 플러그인 로직들은 곧바로 1:1 환전이 불가능합니다. 다행히도 Vercel에서 보편적으로 많이 쓰이는 @svgr/webpack 기반 인젝팅이나 주요 로더 처리에 대해 터보팩 자체 내장 옵션(next.config.ts 내부 rules)으로 대부분 포팅해 주었으니, 기존 코드를 다 지우고 Next.js의 공식 컨피그 문법을 따라 완전히 새로 선언만 해 주시면 정상적으로 컴파일 체인에 태울 수 있습니다.