▲

Deno의 침체에 대한 소문은 크게 과장된 것입니다

 (deno.com)
2P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • 최근 Deno Deploy, KV, Fresh, 전반적인 회사 및 프로젝트 모멘텀에 대한 비판과 우려가 등장함
  • 비판 중 일부는 타당하고, 자체적으로 진행상황을 충분히 공개하지 않아 혼란을 키우기도 했으나, 이 소문 및 비판 중 많은 부분은 근거 없는 추측이나 사실과 다른 내용임
  • Deno 2 출시(2023년 10월 이후) 이후 월간 활성 사용자 지표 기준으로 채택률이 2배 이상 상승함
  • Deno 2의 강력한 Node 호환성이 실제 적용에서 큰 허들을 제거했으며, 플랫폼은 더욱 빠르고 강력하며 간단해짐

Deno Deploy의 변화와 진화

  • 가장 많은 질문 중 하나는 최근 Deno Deploy의 사용 가능 리전 감축에 대한 이유임
  • 감축 배경에는 비용 외에도 실제 사용 패턴과 필요 변화가 있음
    • 대부분의 앱은 모든 리전이 아닌, 데이터와 가까운 지역에서의 속도, 디버그, 규정 준수가 중요함
  • Deploy 출시 이후 25개에서 35개, 현재 6개 리전까지 변동됨
  • 많은 리전이 실제로 거의 사용되지 않아, 오히려 지나치게 분산 시 성능 저하(지연, 용량 문제) 발생함
  • 사용자의 요구에 부합하는 실제적인 “엣지” 비전을 다시 구축 중에 있음
  • 새로운 Deploy 버전 개발 중이며, 플랫폼은 전체 애플리케이션 호스팅 지향으로 진화함
    • 서브프로세스, 백그라운드 작업, OpenTelemetry, 빌드 파이프라인, 자체 호스팅 리전 등을 지원할 예정
  • 곧 앱을 리전에 고정시키거나 자체 클라우드에서 실행 가능한 기능 제공 예정임

KV(키-밸류 스토어) 방향성

  • Deno KV는 설정이 필요 없는, 전역 일관성 보장 및 실시간 기능을 제공하는 간단한 API의 스토어임
  • 세션 데이터, 피처 플래그, 협업 상태 등에 적합하지만, 범용 데이터베이스용은 아님
  • 더 넓은 데이터 관리 니즈에 대해 두 가지 노력을 진행 중임
    • 기존 관계형 데이터베이스의 Deno Deploy 내 통합 강화
    • 컴퓨트와 상태 연계를 단순화하는 신규 프로젝트(Cloudflare Durable Objects에서 영감) 추진
  • 위 방향에 따라 KV는 베타 유지, 중대한 버그/보안 이슈만 지속적 대응
  • 전체 상태 관리 솔루션의 중심이나 진화된 역할은 앞으로 다른 프로젝트가 맡게 될 전망임

Fresh 프레임워크 현황

  • Fresh는 여전히 모든 사내 앱/웹의 기반이면서, 활발히 유지/개선되고 있음
  • Fresh 2에 대한 많은 기대와 오랜 대기 상황을 인지하고 있음
  • 급하게 출시하는 대신 기본 품질과 구조 다듬기를 우선시함
  • 최근 발표된 상세 개선 내용 관련 블로그 글를 참고 할 것
  • 올해 중 안정적인 Fresh 2 배포 예정임

Deno, 런타임 그 이상의 플랫폼

  • Deno는 단순 런타임을 넘어 완전한 JavaScript 시스템 플랫폼임
  • 한 도구 체계로 작성, 실행, 테스트, 배포, 모니터링 등 통합 수행 가능
  • 통합성, 기본 설정, 플래그, 도구간 연결 등이 지속적으로 강화되고 있음
  • 단순한 기능 동등성보다 통합된 생태계 조성을 목표로 함
  • JavaScript 개발의 본질적 품질 향상을 지향하며, 이를 위한 범위 확장에 도전 중임

이 플랫폼의 목표와 이유

  • 스크립트 언어는 빠른 실무 개발에서 불가결한 역할임
  • JavaScript는 표준화, 대규모 생태계, 범용적 확장성 측면에서 미래가 더욱 밝음
  • “배터리 포함” 플랫폼이 필요하며, Deno가 이를 지향함(권한관리, 웹서버, 관측, 린트, 타입체크 등 기본 제공)
  • 조각난 도구 대신 일원화된 경험을 제공함

미래 계획 및 커뮤니케이션 강화

  • Deno는 위축이 아닌 확장 국면에 진입함
  • 플랫폼 속도, 호환성, 완성도 지속 개선 및 JSR의 독립적 거버넌스 성장 중
  • TC39/ WinterTC 등 커뮤니티 협업과 JavaScript 생태계를 위한 다양한 활동 병행
  • Deploy, KV 경험을 바탕으로 지속적이고 분산된 신제품 개발 진행 중이며, 곧 추가 소식 공개 예정
  • 논란이나 불신을 줄이기 위해 커뮤니케이션을 강화하며, 개발자와의 신뢰를 중시할 계획임
▲
xguru 1일전  [-]

Deno의 침체: 전 세계 리전이 6개로 축소
요 글에 대한 대응인가 보네요

Fresh 업데이트가 왜 늦어지는 지에 대한 얘기도 별도로 올렸습니다 Deno의 웹 프레임워크 Fresh 2 업데이트

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 대부분의 개발자가 단순 스테이트리스 함수만 배포하는 게 아니고, 풀스택 앱처럼 데이터베이스와 통신하는 실제 애플리케이션 구축이 일반적이라는 점이 처음부터 명확해 보였다는 생각. 이 사실을 이제야 깨달은 게 약간 당연하게 느껴짐

  • 최근 Deno, Deploy, KV, Fresh, 그리고 전반적인 성장세에 대한 비판 여론이 있었다는 인식 공유. 성장세에 대한 비판에 대해 특별히 언급이나 답변을 보지 못했는데, 일부러 그런 건지 의문. 비판 중 일부가 유효하다고 했으니, 어떤 비판이 유효했는지, 그리고 이를 어떻게 해결하려는지까지 공개했으면 더 신뢰도가 높았겠다는 생각. 회사가 솔직하게 단점까지 인정하는 모습이 오히려 선택에 있어 긍정적 요인이라고 봄. Migadu의 pro/con 페이지처럼 장단점을 투명하게 밝히는 게 마음에 든 경험 공유

    • Deno 측에서 최근 성장세에 대해 언급한 부분은 출시 이후 6개월 남짓 동안 월간 활성 사용자 수가 두 배 이상 증가했다는 설명임. 하지만 무엇을 기준으로 두 배라는 건지, 어떤 수치를 의미하는지는 공개되지 않았음. 초창기에는 막연한 기대감과 신생 서비스에 대한 신뢰로 인해 긍정적으로 평가받았지만, 이제는 수치나 근거 없는 막연한 성장 기대치와 실제 사이의 괴리감에서 실망감이 생기는 분위기라는 의견

  • 초기에 Deno에 기대했던 이유는 기존과의 호환성에 집착하지 않고 적은 복잡성으로 깔끔하게 새로 시작할 수 있다는 점 때문이었음. Node보다 새롭게 불편한 부분은 있었지만 감당할 만한 수준으로 느꼈음. 그런데 고유의 해결책 대신 점점 Node와의 호환성에 매달리기 시작했고, 지금은 오히려 Node보다 더 복잡하게 느껴지는 이중 구조가 됐다고 생각. Node 패키지가 Deno에서 당연히 작동해야 하지만 일부 미구현 API나 버그로 인해 동작하지 않는 엣지 케이스가 많아짐. 가장 좋아하던 테스트 프레임워크인 AVA도 여전히 지원하지 않음. 예전에는 npm 호환성 계층을 무시하고 Deno 자체만 사용했지만, 이제는 점점 더 귀찮아지고 있음. 커맨드라인 옵션만 봐도 몇 년 새 엄청나게 복잡해졌고, 대부분이 npm 연동을 위한 것이어서 나에겐 불필요한 정보일 뿐임. 내가 Node 호환성에서 제일 원하는 건 Deno linter에서 ESLint 설정을 지원하는 거였는데, 이건 관심 없어 보임. 그래도 Deno가 성공하길 바라는 이유는 Node의 개선을 유도한다는 점 때문임. 다만 지금의 Deno 방향성은 처음의 목적과 일관성이 느껴지지 않음

    • AVA 지원 여부 및 ESLint 설정 지원 여부를 최근에 확인해봤는지 질문. 공식 문서 기준으로 AVA 지원이 언급돼 있고, 대다수 Deno 개발자는 기본 내장 테스트 기능을 더 많이 활용하는 듯함. ESLint와 연동되는 커스텀 룰, 플러그인, 세팅 등이 지원된다고 공식 문서에 명시되어 있음. 약 6년간 Deno를 써오면서 별도 테스트/린트 셋업 없이 기본 제공 기능이 만족스럽다는 소감

  • Deno가 방향성을 잃었다고 느낌. 처음에는 Rust로 만들어진 안전하고 빠른 JS/TS 런타임이라는 심플한 포지셔닝이었는데, 지금은 웹사이트 ‘Products’ 드롭다운에 여러 제품이 난잡하게 추가된 상황. Vercel이 NextJS에 이어 데플로이 플랫폼을 만든 방식을 따라가려 한 것 같음

    • 이런 변화가 Deno 자체의 의도라기보다 JavaScript와 Node 커뮤니티가 더 빨리 발전하면서 따라잡은 영향도 크다고 생각. 초창기에는 Deno만의 혁신이 멋있다고 느꼈는데, JS/Node 쪽도 빠르게 개선되다 보니 차별점이 줄어든 느낌

  • Deno가 Node와의 호환성을 추가하며 처음 약속을 포기한 시점부터 기대감이 사라졌음. 나에겐 Deno의 핵심 매력이 Node에서 원치 않는 복잡성과 과거 유산을 제거했다는 점이었는데, 지금은 빌트인 타입스크립트와 퍼미션 같은 몇 가지 소소한 차이만 남고 Node와 다를 게 없음. bun.sh도 마찬가지로 Node 호환성을 제공함. 혹시 Node 호환성을 추구하지 않는 서버사이드 타입스크립트 스크립팅 엔진을 아는지 궁금함

    • npm 호환성은 기능 추가이기 때문에 굳이 그것을 잃는다고 생각하지 않음. 굳이 Node API를 쓰지 않아도 되고, jsr.io에서 원하는 라이브러리만 써도 충분함. 실제로는 Node와 차별화된 개발 경험을 여전히 Deno에서 누릴 수 있다는 주장. 다만 완전한 ‘순수성’을 원한다는 이들은 많지 않으니, 차라리 대중성과 실용성을 선택하는 게 다행이라는 견해

    • Node 호환성을 추구하지 않는 타입스크립트 런타임을 찾는 이유에 의문 표함. Node에도 여러 문제는 있지만 그럼에도 대중적으로 널리 쓰일 만큼 충분히 쓸 만하다는 점을 강조. 실용적 대안을 만들려면 (1) 대규모 마이그레이션을 감수할 만큼 강한 장점이 있거나, (2) 최소한의 마이그레이션 비용과 확실한 개선점(성능, 신뢰성, 사용성)이 있어야 함. 하지만 Deno는 이 두 개 모두 어정쩡하게 놓침. 기존 Node 코드를 돌릴 수 없는 반면, 혁신적인 장점이 충분하지 않아 ‘이상주의자’나 ‘취미 개발자’만 모으는 한계를 가진 접근이라는 생각

    • Node 호환성을 추구하지 않는 타입스크립트 런타임으로 Cloudflare Workers workerd가 떠오르지만, 근본적으로 범용 백엔드 런타임은 아니고, 실질적으로 제공되는 기본 패키지나 내장 기능이 거의 없는 한계가 있음

    • 본인은 JSDoc 사용을 선호함. Node와 상관없으면서도 컴파일 체인 복잡성 없이 비슷한 장점이 있음

    • 백엔드에서 JS에 얽매일 필요 없다면 굳이 TypeScript 대신 더 나은 대안을 고려하는 게 합리적이라는 입장. 스택 전반을 통제할 수 있다면 굳이 Compile-to-JS 언어에 머무를 이유가 없음

  • 최근 글은 과거 https://news.ycombinator.com/item?id=43863937에 대한 반응일 것 같다는 생각

  • CEO가 작성한 글이긴 한데 Deno에 대한 구체적인 비판보다는 내부 결정의 정당화에 집중되어 있음. 그럼에도 불구하고 Deno 제품군은 Deno 환경에서는 꽤 잘 작동하는 듯한 인상

    • Deno 관련 어떤 비판이 해결되지 않았다고 생각하는지 재차 질문

  • 아직 신뢰나 확신이 들지 않는 상황. Deploy가 어떻게 나올지는 곧 알 수 있을 것 같지만, KV는 베타 단계에서 추가 발전 의지가 없다면 새 프로젝트에서는 쓸 이유가 전혀 없다는 생각. Fresh는 Q3 말쯤 알파로 리팩토링된다고 하는데, 사실상 기본만 제공했던 프레임워크였고, 그나마 눈에 띄는 빌드/컴파일이 없는 구조도 사라짐. 런타임은 계속 개발 중이지만, “타 런타임과의 기능 동등성을 추구하지 않는다”는 선언이 무색할 정도로 릴리즈 노트에서는 Node/NPM 호환성에 집중되어 있는 게 흥미로움

    • KV의 지속적인 개발 중단 결정이 정말 안 좋은 선택이라는 생각. 기업들이 KV를 쓰지 않는 건 기능이 나빠서가 아니라 베타 꼬리표 때문이라는 점을 지적. 본인은 Cloudflare Workers KV를 많이 써왔고, Durable Objects에는 큰 관심이 없어서 Deno KV가 기대됐었지만, 앞으로는 고려 대상에서 제외해야 할 듯한 아쉬움. 신제품을 발표하고 바로 방치한다는 인상이 전략적으로도 정말 안 좋아 보인다는 평가

    • KV 활용을 고민하다가 전망이 안 보여서 대안을 고려하게 됐다는 솔직한 소감 공유

  • 대부분의 개발자가 단순 스테이트리스 함수가 아니라 풀스택 앱, 즉 데이터베이스와 긴밀하게 연동되는 앱을 배포한다는 점에 대해 실제로 서버리스 진영 전반에 해당하는 이야기인지 궁금증. 만약 그렇다면 원래 서버리스 운동의 의도와 부합하는 건지, 혹은 단순히 도커/쿠버네티스 같은 복잡한 인프라를 피하고자 선택하는 것인지 의문

    • 내 감으로는 많은 사람들이 모던화된 Heroku 같은 경험, 즉 관리형 RDBMS와 오토스케일링 가능한 서버 세트를 원한다는 느낌. 대다수 회사는 초대규모 스케일이 꼭 필요하지 않기 때문

  • Deno Deploy에서 지역 수 감소에 대한 질문을 자주 받는다는 설명. Deno 측은 대부분의 앱이 전 세계 모든 곳에서 동작할 필요 없이, 데이터와 가까운 곳에서 빠르고, 디버그가 쉽고, 로컬 규제에만 잘 맞으면 된다고 최적화 방향을 설명함. 하지만 본인은 실제로 Deno Deploy의 지역 위치가 충분히 가깝지 않아 성능상 문제가 우려되어 사용하지 않았음. 데이터와 사용자에게 더 가까운 옵션이 이미 다양하고, 규제 준수도 대부분 국가 단위에서 충분하다는 점에서 이 최적화 방향이 납득 가지 않는다는 의견

답변달기