번들 없이도 빠른 개발 환경을 만들 수 있다는 주장과 그 방법. 파이썬의 모듈 로딩을 예로 들어 번들링보다 코드 실행 축소, 지연 로딩, 의존성 최소화가 핵심임을 설명하고, Vite 같은 도구와 올바른 구조로 번들리스 개발을 현실적인 선택지로 만들자고 제안한다.
2023년 11월 30일 작성
최근 이 트윗을 봤는데, 그 안의 한 문장이 저를 꽤 자극했습니다: 번들 없이 동작하는(dev) 서버는 작동하지 않는다는 주장입니다. 요지는 성능상의 이유로 개발 중에는 번들링을 피할 수 없다는 것입니다. 이는 Vite의 설계가 가진 핵심 개념과 전제에 도전합니다. Vite의 개발 서버는 주로 초기 트랜스파일 이후 개별 파일을 그대로 서빙하는 방식으로 동작합니다.
번들리스 개발은, 특히 수천 개 모듈을 가진 프로젝트에서는 성능 문제가 생길 수 있어 실현 불가능하다는 믿음이 있습니다. 하지만 저는 이런 생각이 번들리스 접근의 이점을 간과한다고 봅니다.
물론 문제가 있다는 데에는 분명 일리가 있습니다. 수천 개 모듈이 있다면 로드하는 데 시간이 걸릴 수 있고, 반대로 그 대부분을 하나의 파일로 묶어 두면 로드 시간이 줄어듭니다.
하지만 저는 이 문제를 그렇게 생각하는 것이 옳지 않다고 봅니다. 예시로 파이썬을 생각해 보세요. 파이썬은 수많은 모듈을 더 큰 파일로 번들링하지 않고, 필요할 때마다 파일 시스템에서 각 모듈을 로드합니다. 이 접근에는 단점이 있습니다. 대규모 애플리케이션에서는 import 시 과도한 코드가 실행되면서 시작 시간이 실용적이지 않을 정도로 길어질 수 있습니다.
해결책은 번들링을 늘리는 것이 아니라 전체적인 코드 실행을 줄이는 것입니다. 특히 시작 시점의 실행을 줄여야 합니다. 모듈 구조를 최적화하고, 교차 의존성을 최소화하며, 지연 로딩을 채택하면 로드 시간을 크게 줄이고 컴포넌트의 핫 리로딩도 가능해집니다. 로드하지 않는 바이트가 줄어드는 것뿐 아니라, 코드를 파싱하거나 실행하지 않는다는 점도 잊지 마세요. 이런 것들을 하지 않음으로써 더 빨라집니다.
최종 사용자이든 프레임워크 제작자이든 개발자의 목표는 번들리스 개발을 가능하게 만들고, 적어도 원칙적으로는 그것을 선호하는 방향이어야 합니다. 이는 애플리케이션을 처음부터 초기 로드 요구사항이 최소가 되도록 구조화해 반복 속도를 높인다는 뜻입니다. 덜 하는 데 집중하면 번들링 단계의 제거가 실현 가능하고 유익한 목표가 됩니다. Flask를 만들면서 제가 얻은 큰 교훈 중 하나도 이것입니다. 데코레이터와 import가 만들어내는 수많은 부작용은 대규모 앱에서 큰 좌절 요인입니다.
그렇게만 되면, 번들리스는 이제 중요하지 않게 된 마지막 요소, 즉 번들링 단계를 없애게 되고, 이를 없앰으로써 얻는 이점도 많습니다.
물론 뉘앙스는 있습니다. 예를 들어 내부에 수백 개 모듈을 가진, 변경이 거의 없는 서드파티 라이브러리는 여전히 번들링의 이점을 봅니다. Vite 같은 도구는 이 경우를 최적화해 이 필요를 충족합니다.
따라서 새로운 프로젝트나 프레임워크를 시작할 때는 처음부터 지연 로딩과 효과적인 import 관리에 우선순위를 두세요. 순환 의존성을 피하고 코드의 격리를 신중하게 관리하세요. 이런 초기 정리 작업은 프로젝트가 커질수록 배가되어, 앞으로의 개발을 더 빠르고 효율적으로 만들어 줄 것입니다.
미래의 당신은 분명 행복해할 것입니다 — 그리고 올바른 프로젝트 설정만 갖추면, Vite가 보여주듯 번들리스도 잘 작동합니다.
이 글의 태그: javascript 및 thoughts
