핵심 요약
- 과거 간단했던 웹 개발이 Node.js 등장 이후 서버용 자바스크립트를 브라우저에서 실행하기 위해 복잡한 빌드 과정을 필연적으로 거치게 되었습니다.
- Browserify부터 Webpack, Vite까지 수많은 빌드 도구가 생겼지만 대규모 프로젝트에서는 여전히 빌드에 수 분이 낭비되고 있습니다.
- Next.js 사례처럼 컴파일·압축·번들링 등의 단계를 거치며 비대해진 현대 웹 환경에서 과연 빌드 단계가 필수적인지 질문을 던집니다.
요약 웹 개발 초창기에는 index.html 파일에 jQuery 같은 스크립트 태그 몇 줄만 추가하면 브라우저에서 모든 것이 손쉽게 동작했습니다. 하지만 2009년 Node.js의 등장으로 자바스크립트로 백엔드 서버를 구축할 수 있게 되면서 판도가 바뀌었습니다. 한 가지 언어로 풀스택 개발이 가능해지자, 개발자들 사이에서 "서버용 자바스크립트를 브라우저에서도 그대로 쓰면 안 될까?"라는 질문이 나오기 시작했습니다.
문제는 파일 시스템 기반으로 동작하는 Node.js와 URL을 통해 비동기로 리소스를 가져오는 브라우저의 환경이 근본적으로 달랐다는 점입니다. 브라우저에는 npm 같은 공식 패키지 매니저가 없었고 CommonJS 모듈 방식도 지원하지 않았습니다. 여기에 커피스크립트, JSX, 타입스크립트 등 다양한 파생 언어가 등장하고, 구형 브라우저 호환을 위한 폴리필(Polyfill)과 SASS/LESS 같은 CSS 전처리기까지 도입되면서 브라우저가 직접 해석할 수 없는 코드들이 급증했습니다.
결국 브라우저에서 실행 가능한 순수 자바스크립트로 변환하고 파일 크기를 줄이기 위한 압축(Minify)과 번들링 과정이 필수화되었습니다. 이로 인해 2011년 Browserify를 시작으로 Grunt, Gulp, Webpack, Rollup, 최근의 Vite, Turbopack에 이르기까지 복잡한 빌드 도구 생태계가 탄생했습니다.
오늘날 대규모 Next.js 프로젝트의 경우 빌드에만 수 분이 소요될 정도로 개발 주기를 갉아먹고 있습니다. Next.js 빌드만 해도 컴파일, 코드 압축, 번들링, 코드 분할(Code splitting)의 4단계를 거칩니다. 도구들이 빌드 속도 개선을 내세우고 있지만, Deno 측은 "우리가 개발 편의성과 성능을 위해 감수해 온 빌드 단계가 과연 근본적으로 꼭 필요한 것인가?"라는 본질적인 의문을 던지고 있습니다.
Sponsored · 광고