▲

Deno 2.4 릴리즈

 (deno.com)
1P by GN⁺ 17시간전 | ★ favorite | 댓글 1개
  • deno bundle이 esbuild 기반으로 다시 도입되어, 서버·브라우저 모두에서 단일 파일 번들 생성 및 자동 트리 쉐이킹과 최적화 가능해짐
  • 텍스트/바이트 임포트 지원 및 OpenTelemetry 내장 안정화 등으로 관측성과 외부 파일 활용 경험 강화됨
  • 새 --preload 플래그, 의존성 편의 개선 deno update, 스크립트 커버리지 측정, 권한 관리, Node.js API 호환성까지 폭넓게 개선됨
  • LSP, Jupyter, bench/coverage, tsconfig 지원 향상과 다양한 편의성 개선도 함께 제공됨

Deno 2.4 주요 변경사항 및 새 기능 요약

deno bundle의 복귀

  • Deno 2.4에서는 단일 파일 JavaScript 번들 생성 기능인 deno bundle 서브커맨드가 esbuild 엔진과 함께 다시 탑재됨
  • 서버, 브라우저 모두를 지원하며, npm, JSR 의존성도 문제없이 번들 가능함
  • 자동 트리 쉐이킹과 코드 최적화(minify) 지원 등으로 관리가 편리해진 환경 제공
  • 향후 런타임 API와 플러그인을 통해 번들 프로세스의 프로그래밍적 확장 및 커스터마이징 기능 추가 예정임

텍스트 및 바이트 임포트 지원

  • 자바스크립트 모듈 그래프에 텍스트, 바이너리, 이미지 등 외부 데이터 파일을 임베드할 수 있도록, --unstable-raw-imports 플래그를 제공함
  • 기존에는 파일 입출력(I/O)로 외부 파일을 읽어야 했으나, 이제는 임포트 구문에서 파일 타입을 지정해 직접 바이트/텍스트 데이터 사용 가능함
  • 이 기능은 번들, 컴파일 시에도 동작해 결과물에 에셋 임베딩을 간편하게 구현 가능함
  • JSON, Wasm 등의 기존 임포트 지원과 함께 여러 파일 포맷을 명세 친화적으로 관리할 수 있음
  • 아직 명세(스펙) 논의 중이나, Deno는 기능 진보와 표준 동향을 조화롭게 반영함

OpenTelemetry 내장 안정화

  • 2.2 버전에 도입된 OpenTelemetry 내장 지원이 2.4에서는 완전히 안정화됨
  • OTEL_DENO=1 환경변수만 설정하면 별도의 플래그 없이도 로그, 메트릭, 트레이스 수집 자동화 가능함
  • Node.js와의 무설정 호환 및 Deno Deploy 배포 환경까지 일괄 지원
  • console.log 로그와 HTTP 요청의 자동 연결/관찰도 가능함
  • 리소스 사용 특성상 환경 변수 제어가 필요함

실행 전 환경 설정용 --preload 플래그

  • 주요 스크립트 실행 전에 글로벌 환경 변경, 데이터 로딩, 종속 모듈 등록 등을 위한 코드를 미리 실행할 수 있는 --preload 플래그가 추가됨
  • 플랫폼 커스터마이징이나 글로벌 오브젝트 재설정 등 다양한 플랫폼 구축 시 유용함
  • deno run, deno test, deno bench 등 주요 커맨드에서 모두 사용 가능함

의존성 관리 간소화: deno update

  • npm, JSR 의존성의 최신 버전 자동 업데이트를 위한 deno update 서브커맨드가 도입됨
  • 여러 종속성 한 번에 최신화 및 Semver 호환성 기반 정밀 업데이트 지원
  • 기존 deno outdated --update 의 별칭 제공, 사용 편의성 강화

스크립트 커버리지: deno run --coverage

  • 각각의 테스트뿐 아니라, subprocess가 포함된 실행 전체의 커버리지 수집이 가능해짐
  • DENO_COVERAGE_DIR 환경 변수 등 다양한 방식의 유연한 데이터 관리 가능
  • HTML 커버리지 리포트 다크 모드 지원 추가

Deno 호환성 환경변수 DENO_COMPAT=1

  • npm 생태계 및 package.json 기반 프로젝트의 편의성·호환성 향상을 위한 DENO_COMPAT=1 변수가 도입됨
  • 여러 불안정(Unstable) 플래그를 자동 적용하며, 향후 npm prefix 생략 등 지원 폭 확대 예정

권한 관리와 보안 개선

  • --allow-net 플래그에서 서브도메인 와일드카드 및 CIDR 범위 지원
  • 코드의 임포트 가능 호스트를 제한하는 --allow-import, 명시적으로 차단하는 --deny-import 플래그 신설
  • Deno.permissions API에 "import" 타입 쿼리 정식 지원
  • Deno.execPath() 사용 시 더 이상 읽기 권한 필요 없음, 실행 파일 경로 활용이 쉬워짐

조건부 package.json exports

  • npm 패키지에서 조건부 exports 지원, 특히 React 서버 구성 등 다양한 생태계 지원 강화
  • 사용자 조건 플래그로 유연한 맞춤 import 동작 구현 가능

deno run에서 bare specifier 지원

  • deno.json의 "imports"에 설정한 별칭(베어 스펙)으로 명령어 진입점 실행 가능
  • 개발 생산성 및 모듈 관리 자동화 측면에서 큰 편의성 제공

XML, SVG 등 포맷의 코드 포매팅 개선

  • deno fmt에서 .xml, .svg, .mustache 등 다양한 템플릿 파일 자동 포매팅 지원

tsconfig.json 지원 강화

  • references, extends, files, include, exclude 등 다양한 옵션 인식 정확도 개선
  • Vue, Svelte, Solid, Qwik 등 최신 프론트엔드 프레임워크와의 향상된 호환성 제공

Node 글로벌 변수 및 API 호환성 증대

  • Buffer, global, setImmediate, clearImmediate 등 Node.js 전역 오브젝트가 사용자 코드에도 항상 존재하도록 변경
  • npm 패키지 전용이던 글로벌도 커맨드 플래그 없이 바로 활용 가능
  • node:buffer, node:events, node:querystring, node:quic, node:wasm 등 95% 이상 호환성 달성, 앞으로도 지속적으로 확대 예정
  • @types/node 타입 기본 버전도 22.15.14로 업데이트

로컬 npm 패키지 관리 변경

  • npm 로컬 패키지 연결 옵션명이 patch에서 links 로 변경되어, npm link의 의미와 일치
  • 기존 옵션 사용 시 디프리케이션 경고 제공, 더 명확한 패키지 관리 가능

LSP 및 개발 생산성 개선

  • LSP 성능·기능 개선과 함께, fetch의 Unix/Vsock 소켓 지원, 서버의 onListen 콜백, Jupyter 커널 관리, 린트 플러그인에서 댓글 읽기 및 bench/coverage 표의 마크다운 호환성 등 다양한 편의성 제공
  • Windows에서의 Ctrl+Close 신호 인식(windows SIGHUP), bench/coverage 텍스트 출력의 마크다운 포맷 등도 새롭게 개선됨

커뮤니티 및 기여자 감사 인사

  • Deno 2.4 발전에는 다양한 커뮤니티 기여자의 참여와 피드백이 큰 역할을 했음
  • 더 많은 내용 및 상세 변경사항은 GitHub 릴리즈 페이지 참조 가능

결론

  • Deno 2.4는 번들, 외부 파일 임포트, 관측성, 권한/보안, 호환성, 생산성 등 다양한 방면에서 큰 발전을 제공함
  • 개발 흐름과 최신 프론트엔드, 노드 생태계 프로젝트에서 쉽고 강력한 통합 개발 환경 경험 가능
  • 추가 정보와 최신 뉴스, 전체 변경 이력은 공식 문서 및 블로그, 깃허브 릴리즈 페이지에서 확인할 수 있음
▲
GN⁺ 17시간전  [-]
Hacker News 의견

  • Deno의 컨셉이 정말 마음에 들어서, Next.js, Hono, 그리고 프라이빗 패키지들을 포함한 모노레포 프로젝트에 Deno.json, JSR, 모던 import, Deno Deploy 등을 최대한 적용해봤던 경험 공유. Hono는 깔끔하게 잘 동작했지만 Next.js는 그렇지 않았고, 타입 관련 이슈도 미묘하게 깨지는 경우가 발생. 배포 목적지(Vercel 등) 선택도 문제였던 기억. 예시로 겪었던 작은 문제를 이슈 링크로 공유. 반면 Bun은 사용감이 Deno처럼 깔끔하진 않았어도 생각할 게 적었고 그냥 "동작"하는 인상. 다만 Bun도 Vercel에서 Bun 런타임 미지원 등 완벽하지 않음

    • 선택한 스택이 여전히 npm 중심, 특히 프라이빗 npm 패키지가 많은 환경에서 무리였다는 조언. Deno식 방식의 달콤한 포인트는 자체적으로 Deno 혹은 ESM 친화적인 스택 선택에 있다고 생각. Lume을 사용하거나 Deno Deploy로 타겟팅한 경험이 좋았음. (JSR 스코어 덕분에 흥미롭고 ESM 호환이 강한 라이브러리 탐색에도 도움) 물론, 완전히 새로운 스택으로 시작하라는 건 현실적으로 어렵고 기존 Next.js 등의 투자도 커서 Deno를 추천하기엔 부담. 하지만 Deno의 장점이 드러나는 건 Deno-native, ESM-native 툴 전체로 0부터 스타트하는 환경이라고 봄. 참고로 Deno의 npm 호환성이 점점 좋아지고 있고, 2.4 릴리즈 노트에도 관련 개선 내용 있음. 풀스택 환경에서는 deno.json이 아니라 package.json 우선 접근이 오히려 더 호환성이 좋으니, 장기적으론 deno.json으로 밀어도 패키지 json 기반 세팅도 추천

    • npm 호환 모드에서 Deno를 사용해보니 의외로 잘 동작한다는 인상. Bun의 활용 방식과 많이 비슷. package.json이 있는 디렉토리에서 deno install을 실행하면 슬림한 node_modules를 만들어주고, deno task something 명령으로 package.json에 정의된 스크립트 실행 가능. 하지만 Deno만의 방식은 시간이 많이 드는 경우가 많아 답답했고, 다시 node/npm 환경으로 돌아가려 하면 골치만 더 아픔. 결론적으로 Deno를 package.json과 함께 쓰는 쪽이 더 수월함

    • 처음엔 Deno에 올인했었지만 사소한 문제점이 너무 많아서 힘들었던 경험. 그에 비해 Bun은 별다른 신경 쓸 것 없이 잘 동작함

  • Deno의 node 호환성을 사람들이 과소평가하는 경향. compat 환경 변수 도입이 확산에 도움이 될 거라 기대. denon 등의 커맨드가 자동으로 켜주는 식이면 더 편할 듯

    • 내 경험상 Deno의 node 호환성은 기대 이하였다는 실망. 100~200라인 정도 되는 간단한 프로젝트를 Deno로 옮기는 데 1시간 정도 걸렸는데, 사실 5~10분이면 끝나야 정상이었음. node의 일부 메소드 미지원 및 관련 문서도 부실했고, 기본 기능도 obscure한 URL에서 직접 다운받아야 했음. 테스트 슈트 포팅 때는 결국 포기. 특히 CommonJS(CJS)에서 ESM 전환 과정이 생각보다 훨씬 고통스러웠고, 결코 Deno 공식 문서에서 설명하는 만큼 쉽게 전환 불가능. 전체 라이브러리 포팅 불가 경험

    • 예전엔 Deno에 꽤 긍정적이었지만, 이제는 딱히 Bun 대신에 Deno를 쓸 이유를 못 느끼겠음

  • Deno의 최근 변화 리스트가 좋다는 평. 랜덤 스크립트/글루 코드 작성용으로 Deno를 만족스럽게 사용 중이며(머신러닝 등은 python/uv 활용), 향후 gRPC 지원과 번들 커맨드에도 기대

  • 아직도 Deno가 FreeBSD에서 제대로 안 되는 게 신기하다는 이야기. Rust 기반 V8 바인딩이 아직 포팅이 안 됨

    • 현대 자바스크립트 개발자 중 FreeBSD 유저가 사실 얼마나 되는지 궁금

    • 예전에는 유닉스 간 이식성이 코드의 청결함 척도였는데, 요즘은 다양한 유닉스 시스템 간 호환성이 별로 강조되지 않아 당황

    • FreeBSD용 포트에는 등록되어 있는 것으로 보임

    • FreeBSD 지원에 큰 노력을 안 들이는 이유는 충분히 납득 가능

  • Deno가 프로덕션에서 더 널리 쓰이지 않는 이유가 표준화된 취약점 DB 부재라는 의견. npm 100% 호환성으로 보완은 가능하지만 그럴 경우 대다수 인기 deno 패키지가 범위에서 빠져버림. 근본적으로 중앙 패키지 매니저가 없다는 점(의도된 설계)이 챌린지임. 관련 진전이 있었는지 질문

    • 만약 취약점 DB 부재가 정말 프로덕션에서는 큰 문제가 된다면, C/C++도 똑같이 못 쓸 것이라는 반론. 실제로 C/C++은 언어 중립적인 CVE/GHSA DB 등을 참고해서 보안 이슈 체크함. 참고로 C는 그냥 외부 파일을 베닝해서 쓰고 버전 추적도 안 하는 경우가 많음. 또 "deno.lock" 파일이 있어서, 신경 쓰는 사람은 여기에 의존하여 사용하는 버전으로 취약점 DB 체크 가능함

    • URL(GitHub 등)에서 직접 패키지 가져오는 구조는 Go도 비슷하므로, 동일한 이슈가 Go에도 적용됨

  • bundle 서브커맨드가 다시 추가된 점이 마음에 듦. 번거로운 우회 방법이 필요 없어 만족

  • 번들 작업에 Rust 기반 Rolldown이 아닌 esbuild를 채택한 게 의외. Rolldown은 이제 곧 v1 될 예정인데

    • esbuild는 현재 매우 안정적이고 성숙한 반면, Rolldown은 아직 빠르게 변화 중이므로 esbuild 선택이 더 무난

  • Deno의 방향성이 정말 마음에 들고, Node가 원래 이렇게 나왔어야 했다는 생각. 다만 걱정되는 점은 경쟁사들의 '하입'에 휩쓸려 Deno까지 변화 없이 따라가는 것

    • Deno 자체가 그동안 Node.js의 '하입' 기반 경쟁자로 인식됐던 것 같기도 함

  • Deno에 대해 좋은 평가를 계속 듣고 있음. 덕분에 js를 한번 써볼까 하는 생각도 들기 시작

    • 요즘이라면 처음부터 TS로 가는 것도 괜찮은 선택

  • 보안 관점에서 Deno를 응원하지만, 공식 사이트에서 사용자에게 'curl mywebsite.com/foo.sh | sh' 형식 설치를 권장하는 부분이 꺼림칙했던 경험 공유. 물론 위험 허용 수준은 다르지만, 최소한 파일을 다운받고 실행하면 본인이나 안티바이러스가 점검할 수 있음. Node/Deno + npm 생태계는 기본적으로 상당한 신뢰가 필요한 구조. 공식 가이드에서 'curl | sh' 외에 'npm install -g deno' 옵션도 제공하는데, npm은 그래도 최소 파일 무결성 체크와 간단한 악성코드 검사가 있어 상대적으로 안전. deno.land 웹사이트도 codebase 수준으론 안전해도 운영 측면에선 100% 장담 불가하므로, 'curl | sh'는 보안 모범 사례가 아니라고 봄

    • 이 논리에 공감하지 않는 입장. 대부분의 설치 스크립트는 결국 같은 저자가 만든 수백~수백만 줄의 바이너리를 받아와 실행하는 역할. 만약 저자를 아예 신뢰 못해서 서버가 특정 IP만 악성코드 뿌릴 수 있다고 가정할 정도면, 아예 바이너리 수준에서도 악성코드 심을 수 있으니 애초에 그 프로젝트를 쓰면 안 된다고 봄. 'curl | sh' 논쟁이 널리 퍼진 건 쉽고 반복하기 쉬운 논거라서 그런 것 같고, 오히려 수백만 줄의 코드 리뷰가 진짜 보안 문제. 만약 정부 기관의 MITM 공격까지 걱정할 수준이면 애초에 인터넷 외부 신뢰를 끊는 수밖에 없음

    • 신규 유저 온보딩에 어려움이 있다는 지적. npm 사용하라고 권장해도 npm이 먼저 설치되어 있어야 하는데, npm 공식 사이트는 nvm 설치를 알려주고, nvm조차 'curl | sh'를 사용함. 그래서 결국 npm 접근도 간접적으로 같은 문제

    • npm install -g deno가 curl | sh보다 실제로 더 안전한지에 대한 논의에서, 핵심은 'npm 서버와 자체 서버 중 해커가 더 쉽게 침투할 수 있는 쪽은 어디인가?'에 달림. 만약 자체 서버 침투가 아니라고 확신할 수 있으면 curl | sh가 npm install보다 덜 안전할 이유도 없음. 결국 보안 관점에서 보면 이 두 방법 다 동일하게 취약할 수 있어서, 극단적으로 접근하면 인터넷을 사용하는 자체가 문제

    • Deno의 샌드박스 구현이 90년대 기술 느낌이라며, 사용 자체가 좋은 보안 습관은 아니라는 비판

    • 실제로 curl | sh 설치 방식의 공격이 실전에서 성공한 사례가 있는지 궁금

답변달기