경쟁이 자산, Deno의 역할 끝나고 JavaScript는 앞으로

핵심 요약

• Deno 팀이 Cloudflare에 합류하고 런타임은 올해 안에 운영을 중단하며, JSR은 Cloudflare 인프라에서 계속 운영된다.
• Ryan Dahl은 2018년 JSConf EU에서 Node의 문제점을 지적하며 권한 거부-기본값 정책, TypeScript 우선 지원, 웹 표준 API, ES모듈만 사용, npm·package.json·node_modules 제거 등을 약속했다.
• Deno 1.0은 2020년 출시했으나 이후 4년에 걸쳐 URL 기반 의존성 관리를 포기하고 deps.ts, lock.json, import maps, 결국 npm 호환성을 단계적으로 추가했다.
• Bun이 2022년 npm 패키지 호환성을 유지하면서 성능 중심으로 출시하자, Deno는 2개월 후 npm 지원을 선언했고 2024년 Deno 2에서 완전한 Node·npm 호환성을 달성했다.
• Node.js는 2018년 이후 fetch, WebSocket, 권한 모델, 테스트 러너, --watch, TypeScript 타입 제거, sqlite 모듈, require(esm) 등을 추가하며 Deno와 Bun의 아이디어에 대응했다.
• Yarn(2016)의 lockfile과 workspace, pnpm의 효율적 node_modules, Bun의 빠른 설치 속도, Deno의 소스 읽기 가능성 같은 경쟁 속 혁신들이 npm과 Node.js 개선을 촉발했다.
• JSR은 TypeScript 소스 발행, ESM 필수, 코드 기반 문서 생성을 요구하며 다른 전략을 택했고, vlt 등 다른 패키지 매니저들이 이를 채택했다.
• install 스크립트 자동 실행 거부 같은 기능도 pnpm과 Bun이 먼저 구현한 뒤 npm이 수년 후 기본 동작으로 변경했다.
• 이제 Bun과 Deno 같은 주요 독립 런타임들은 Google Chrome/V8처럼 클라우드 회사(Anthropic, Cloudflare) 내부로 들어갔다.
• JavaScript는 엔진·런타임·패키지 매니저 각 층에서 다양성을 유지하고 있으며, 한 층이 통합되면 다른 층들이 혁신을 계속 추진한다.
• Deno의 직접적 성공은 제한적이었지만 권한 모델, 권한 시스템, 웹 표준 API 등의 아이디어는 Node.js와 전체 생태계에 채택되었다.