{ "one_line_msg": " 디노가 Node.js를 쫓을수록 왜 자꾸 멀어지는 걸까" }

자바스크립트 생태계의 설정 파일 과잉(tsconfig.json, .eslintrc, .prettierrc, babel.config.js) 문제에 지치면서 제로 컨피그(Zero-Config) 접근의 Deno를 선택함\n• 웹 표준 기반, 권한 모델, URL 임포트, 통합 도구 체인(deno fmt/lint/test/bench/check)이라는 독립적 생태계(Independent Ecosystem)에 매료됨\n• npm 호환성, node_modules 복귀, deno add의 npm 기본값 전환 등 Node.js 추종 전략(Node.js Chasing Strategy)이 뚜렷해짐\n• OS/2 사례처럼 호환성이 높아질수록 라이브러리 작성자가 Deno를 특별히 고려할 이유가 줄어드는 역설적 효과(Paradoxical Effect) 발생\n• VC 지원 스타트업의 투자 시계(runway) 압박이 인내심 있는 경쟁(Long-term Competition) 대신 눈에 보이는 성과(Visible Result) 추구를 유도하는 것으로 추정

제로콘피그(Zero-Config) 철학의 매력

작성자는 Python의 실용성과 Haskell의 타입 시스템 사이에서 TypeScript를 발견했으나, 설정 파일(tsconfig.json, .eslintrc, .prettierrc, babel.config.js)이라는 진입 장벽에 매번 좌절했다고 한다.

deno run main.ts: 별도 설정 없이 TypeScript를 즉시 실행할 수 있었던 경험이 설정 복잡성 피로(Configuration Fatigue)를 해소함

웹 표준 우선(Web Standards First): fetch(), Web Crypto API, MDN 문서를 그대로 활용하여 에코시스템 학습 곡선(Learning Curve)을 낮춤

통합 도구 체인(Integrated Toolchain): deno fmt, deno lint, deno test, deno bench, deno check가 단일 바이너리로 제공되어 도구 간 설정 충돌(Configuration Conflict)이 없음

이러한 철학은 '지루한 도구는 직접 만들고 웹 표준 위에 올린다'는 명확한 태도를 반영한다.

Node.js 추종 전략의 역설

본문에 따르면 디노는 버전 2.8에서 `deno add`가 기본으로 npm 패키지를 추가하도록 변경했으며, node_modules와 npm:* 모듈 호환성을 지속적으로 추가하고 있다.

OS/2 비유: IBM이 OS/2에 Windows 호환성을 탑재하여 Windows 사용자를 이동시키려 했으나, 오히려 개발자들이 Windows만 타겟으로 하면 양 플랫폼에서 실행 가능하므로 OS/2 API를 별도로 학습할 이유가 사라지는 결과를 초래함

디노의 경우: Node.js 호환성이 높아질수록 라이브러리 작성자가 'Node.js만 타겟하면 된다'고 판단하여 디노를 특별히 고려할 이유가 감소함

수렴 방향(Convergence Direction): Node.js도 TypeScript 기본 지원(v22), 권한 모델(v20), fetch()/Web Crypto API 추가 등 디노 기능을 채택하고 있어 두 런타임이 수렴하고 있음

결론적으로 디노가 더 많은 추격을 하는 구조로, 초기 디노가 에코시스템의 의제를 설정했던 것과 반대 방향이다.

수직 통합(Vertical Integration) 전략의 좌초

{"converted":"작성자는 디노가 개별 도구만으로도 충분히 승부할 수 있었다고 주장합니다.\n\n- 트로이 목마 전략: deno lint와 deno fmt가 ESLint, Prettier보다 확실히 뛰어났다면, 개발자들이 Node.js 프로젝트에서도 이를 선택했을 것이고, 자연스럽게 '왜 디노 런타임을 사용하지 않는가?'라는 질문으로 이어졌을 것입니다.\n- Biome과 Oxc(Oxlint, Oxfmt)가 증명한 것: ESLint와 Prettier가 자리를 확고히 했지만, 새로운 도구들이 자리를 잡으며 더 나은 도구에 대한 수요가 실제로 존재했음을 보여주었습니다.\n- Fresh 2.0의 아쉬운 선택: 디노의 자체 프레임워크가 Vite를 채택하면서, 독립적인 개발 환경 구축이라는 본래 방향과 어긋났습니다.\n\n이른바 '개별 도구 우위'가 디노 런타임 도입의 트로이 목마가 될 수 있다는 분석입니다."}