'Deno랑 절교했다'는 선언
웹 개발자 David Bushell이 자기 블로그에 'Friendship ended with Deno, now Node is my best friend'라는 글을 올렸어요. 제목은 해외 인터넷에서 오래된 밈('Friendship ended with ○○, now △△ is my best friend')을 그대로 가져온 건데요, 한마디로 그동안 쓰던 Deno를 내려놓고 Node.js로 돌아왔다는 이야기예요.
그냥 한 사람이 런타임 취향을 바꾼 이야기로 보일 수도 있어요. 그런데 지난 몇 년 동안 자바스크립트 런타임 판도가 어떻게 바뀌었는지가 이 글 하나에 꽤 잘 드러나거든요. 'Node를 대체하겠다'며 나온 Deno를 쓰다가 정작 Node로 되돌아가는 개발자가 생긴다는 것 자체가요.
Deno는 원래 'Node 창시자의 반성문'이었어요
Deno를 만든 사람이 바로 Node.js를 만든 Ryan Dahl이에요. 2018년 JSConf EU에서 'Node.js에 대해 후회하는 10가지'라는 발표를 했는데, 그 후회를 바로잡겠다며 내놓은 게 Deno거든요.
그래서 Deno는 첫인상이 정말 깔끔했어요. TypeScript를 별도 설정 없이 바로 실행할 수 있었고, 파일이나 네트워크 접근은 기본으로 막혀 있어서 --allow-net처럼 직접 허락해줘야 했어요. 이게 뭐냐면, 스마트폰 앱이 카메라나 위치 권한을 요청하듯이 스크립트도 필요한 권한만 받아 가는 구조예요. 거기다 fetch 같은 웹 표준 API, 포매터, 린터, 테스트 러너까지 바이너리 하나에 다 들어 있었죠. node_modules에 지친 개발자들한텐 꽤 끌리는 제안이었어요.
Deno 2: 이기는 대신 친해지기로
문제는 생태계였어요. 런타임이 아무리 우아해도 npm에 쌓인 수많은 패키지를 못 쓰면 실무에선 한계가 있거든요. 그래서 Deno는 2024년에 Deno 2를 내면서 package.json과 node_modules를 지원하기 시작했고, npm: 접두사로 npm 패키지를 바로 가져다 쓸 수 있게 했어요. 새 패키지 레지스트리인 JSR도 만들었고요.
현실적인 선택이었지만 아이러니가 생겼어요. Deno가 Node를 닮아갈수록 '이것저것 Node 호환까지 신경 쓰면서 Deno를 쓸 바엔 그냥 Node 쓰면 되지 않나?'라는 질문이 자연스럽게 나오게 된 거죠.
그 사이 Node는 Deno의 장점을 하나씩 가져갔어요
Deno를 쓸 이유를 가장 많이 줄인 건 사실 Node 자신이에요. 최근 Node에 들어온 기능들을 보면 Deno가 먼저 보여준 아이디어가 꽤 많거든요.
- TypeScript 바로 실행: Node 22.6에 실험 기능으로 들어온 '타입 스트리핑'이 Node 23.6부터는 플래그 없이 동작해요. 이게 뭐냐면, 코드에서 타입 표기만 쓱 지우고 남은 자바스크립트를 실행하는 방식이에요. 그래서
enum처럼 실제 런타임 코드를 만들어내는 문법은 기본적으로 안 돼요. TypeScript 5.8의--erasableSyntaxOnly옵션을 켜두면 이런 문법을 미리 걸러낼 수 있어요. - 내장 도구들:
node --test(테스트 러너),node --watch(파일이 바뀌면 재시작),node --env-file=.env(환경변수 로딩)가 기본으로 들어왔어요. jest, nodemon, dotenv를 따로 설치하지 않아도 되는 경우가 많아졌죠. - 웹 표준 API와 그 밖의 기능:
fetch, WebSocket 클라이언트, 내장 SQLite(node:sqlite)에 Deno처럼 권한을 제한하는 모델(--permission)까지 들어왔어요.
결국 '생태계 중력'의 문제
기능 차이가 줄면 남는 건 생태계예요. 호스팅 서비스, 라이브러리 문서, Stack Overflow 답변, 채용 시장은 물론이고 AI 코딩 도구가 만들어주는 예제 코드까지 기본값은 여전히 Node거든요. 빠른 속도를 내세운 Bun까지 나오면서 '대안 런타임' 자리마저 나눠 갖게 됐고요.
그렇다고 Deno가 의미 없다는 얘기는 아니에요. deno compile로 실행 파일 하나를 만드는 기능, 처음부터 설계에 들어간 권한 모델, 설정 없이 바로 돌아가는 스크립트 경험은 여전히 강점이에요. 다만 '굳이 갈아탈 이유'가 예전보다 약해진 건 분명해 보여요.
한국 개발자에게 주는 시사점
당장 해볼 수 있는 건 프로젝트 개발 의존성 다이어트예요. Node 22 LTS 이상을 쓰고 있다면 ts-node, nodemon, dotenv 같은 패키지가 정말 필요한지 한번 점검해보세요. 간단한 스크립트나 사내 도구라면 node --watch script.ts 한 줄이면 충분할 수도 있어요.
그리고 Deno를 공부했던 시간도 아깝지 않아요. fetch나 Request/Response 같은 웹 표준 API 중심으로 코드를 짜는 습관은 Node, Bun, Cloudflare Workers 같은 엣지 런타임 어디서든 통하거든요. 런타임끼리 공통 API를 맞추려는 WinterTC(구 WinterCG) 같은 표준화 흐름도 같은 방향이고요.
마무리
한 줄로 정리하면, 이건 'Deno가 틀렸다'는 이야기라기보다 'Deno가 옳았고, 그래서 Node가 따라왔다'는 이야기에 가까워요. 런타임을 고를 때 결국 이기는 건 기술적 우아함보다 생태계와 유지보수성이라는 것도 다시 한번 보여주고요.
여러분 팀은 어떤 런타임을 쓰고 계신가요? Deno나 Bun을 실무에 들였다가 다시 돌아온 경험이 있거나, 반대로 Node를 떠나서 만족하고 계신다면 경험담을 나눠주세요!
🔗 출처: Hacker News