Cloudflare는 왜 Deno를 품고 ‘탈출구’를 만들려 하나

Cloudflare가 Deno 팀을 품었다.

겉으로 보면 런타임 기업의 인수 또는 인재 영입이다. 하지만 핵심은 Deno 자체보다 더 크다. Cloudflare는 Deno 팀과 함께 Workers와 Durable Objects를 Cloudflare 밖에서도 쉽게 운영할 수 있도록 만들려 한다. 즉 Cloudflare의 핵심 프로그래밍 모델을 더 많은 환경으로 확장하려는 시도다.

Cloudflare는 2026년 10월 9일 “Deno is joining Cloudflare”라는 글을 공개했다. 글의 핵심은 분명하다. Deno 팀이 Cloudflare에 합류해 self-hosting Workers와 Durable Objects를 크게 단순화하고, 개발자가 같은 프로그래밍 기본 요소를 더 많은 곳에서 사용할 수 있도록 하겠다는 것이다.

Ryan Dahl은 더 직접적으로 설명했다.

Deno 팀은 Cloudflare에 합류하고, workerd와 celld를 병합한다. workerd는 Cloudflare Workers 런타임의 오픈소스 구현이고, celld는 Ryan Dahl이 Durable Objects 모델을 자체 인프라에서 분산형으로 운영하기 위해 만든 프로젝트다.

이 조합이 중요한 이유는 Workers의 약점이 아니라 강점 때문이다.

Cloudflare Workers는 전통적인 서버 운영 방식과 다르다. 개발자는 서버 인스턴스, 리전, 로드밸런서, 오토스케일링, 네트워크 배치 같은 세부 인프라를 직접 조립하기보다, JavaScript 기반의 경량 실행 환경 위에서 전 세계 엣지에 애플리케이션을 배포한다. Cloudflare는 Workers가 수백 개 위치에서 실행되는 애플리케이션을 단순하고 저렴하게 운영하게 만든다고 설명한다.

하지만 바로 그 다름이 논란의 원인이었다.

Cloudflare Workers는 기존 클라우드 플랫폼과 다르게 작동한다. 특히 Durable Objects를 쓰는 애플리케이션은 단순히 다른 호스팅 플랫폼으로 옮기기 어렵다. 그래서 인터넷에서는 Cloudflare가 일부러 lock-in을 만들었다는 주장이 있었다. Workers로 앱을 만들면 나중에 다른 곳으로 옮기기 어렵고, 결국 Cloudflare에 갇힌다는 논리다.

Cloudflare의 Kenton Varda는 이 주장이 틀렸다고 반박한다.

그는 Workers가 다른 이유는 더 나은 방식이라고 믿기 때문이라고 말한다. Workers의 설계는 전 세계 수백 개 위치에서 애플리케이션을 운영하는 일을 단순하고 저렴하게 만들고, bindings라는 실행 환경 설계는 외부 리소스 접근 설정을 더 쉽고 안전하게 만든다. Durable Objects는 전통적인 3계층 웹 아키텍처로는 어렵거나 불가능한 실시간 협업과 분산 시스템 구축을 쉽게 만든다고 설명한다.

즉 Cloudflare의 주장은 이것이다.

Workers는 lock-in을 만들기 위해 다른 것이 아니다.
더 나은 클라우드 애플리케이션 모델을 만들기 위해 다르다.
다만 더 나은 모델은 기존 플랫폼과 완전히 호환되기 어렵다.

이 논리에서 Deno 팀 합류의 의미가 생긴다.

Cloudflare가 진짜 lock-in을 원했다면, Workers와 Durable Objects를 Cloudflare 밖에서 실행하기 쉽게 만들 이유가 없다. 그러나 Cloudflare는 오히려 Deno 팀과 함께 자체 호스팅 가능한 Workers 모델을 본격적으로 지원하려 한다. Varda는 lock-in이 오히려 Cloudflare에 해가 된다고 말한다. 대형 고객은 탈출구가 없으면 Cloudflare 위에 중요한 시스템을 구축하지 않을 수 있기 때문이다.

이것은 클라우드 사업에서 중요한 통찰이다.

고객을 가두는 것이 단기적으로는 유리해 보일 수 있다. 그러나 대기업 고객은 장기 위험을 계산한다. 핵심 업무를 특정 플랫폼에 올릴 때, 그 플랫폼에서 빠져나올 수 있는지, 런타임을 자체 운영할 수 있는지, 장애나 가격 정책 변화에 대응할 수 있는지 본다. Cloudflare는 Workers Runtime인 workerd를 오픈소스로 공개한 것도 이런 이유였다고 설명한다.

하지만 workerd에는 큰 빈틈이 있었다.

Cloudflare는 workerd를 프로덕션에서 사용할 수 있도록 공개했지만, 실제로 자체 운영 생태계와 도구를 충분히 구축하지 못했다고 인정한다. 특히 Durable Objects가 문제였다. workerd는 Durable Objects를 구현하지만, 단일 인스턴스 방식에 가까워 로컬 테스트에는 충분해도 확장 가능한 자체 호스팅 환경에는 부족했다. Cloudflare의 실제 프로덕션 Durable Objects 라우팅 구현은 수백 개 위치와 여러 외부 서비스, SRE 팀 운영을 전제로 한 복잡한 시스템이기 때문에 self-hosting에 맞지 않았다.

여기서 celld가 등장한다.

Ryan Dahl은 Cloudflare의 Durable Objects에서 강력한 추상화를 봤다. Durable Object는 분산 singleton이면서 SQLite 데이터베이스를 가진 작은 서버처럼 작동한다. 각 객체는 개별적으로 주소 지정 가능하고, 자체 관계형 데이터베이스를 가지며, JavaScript 실행은 단일 스레드라 이해하기 쉽다. WebSockets를 처리하고, 로컬 SQLite 데이터베이스에 동기적으로 접근할 수도 있다. 채팅 애플리케이션을 만들 때 채널마다 하나의 Durable Object를 두면 데이터와 WebSocket 연결이 자연스럽게 샤딩되고, 애플리케이션이 확장 가능해진다.

이 설명은 매우 중요하다.

Durable Objects는 단순한 저장소가 아니다.
작은 서버이자 상태 관리 단위다.
분산 시스템을 개발자가 직접 조립하지 않아도 되도록 해주는 추상화다.
채팅, 실시간 협업, 큐, KV, durable execution, Git storage 같은 서비스를 그 위에 만들 수 있다.

Ryan Dahl이 본 문제는 이것이었다.

Cloudflare 안에서는 이 모델이 강력하지만, Cloudflare 밖에서 분산형으로 돌리는 것은 어려웠다. workerd는 오픈소스였지만 Durable Objects 지원은 단일 인스턴스에 머물렀다. Ryan은 Cloudflare의 네트워크 바깥에서도 Durable Objects의 분산형 버전을 운영하고 싶어 했다. IRC 채널이 여러 머신에 분산되고, 플랫폼이 배치와 라우팅, durable storage를 처리하는 모델이다. 그래서 celld를 시작했다.

celld의 목표는 단순했다.

Deno Deploy를 운영하며 Ryan Dahl은 클라우드 인프라가 얼마나 복잡해질 수 있는지 경험했다. 여러 퍼블릭 클라우드, 여러 데이터베이스, 깊게 얽힌 서비스들이 필요했다. 반면 celld는 그 반대를 지향했다. Rust로 작성된 하나의 바이너리, 외부 의존성은 object storage 하나만 두는 모델이다.

이 지점에서 Cloudflare와 Deno의 이해가 맞아떨어졌다.

Cloudflare는 Workers와 Durable Objects를 자체 호스팅할 수 있게 만들고 싶었지만, 프로덕션 구현이 너무 복잡해 self-hosting용으로 적합하지 않았다. Deno 팀은 이미 celld를 통해 자체 호스팅 가능하고 확장 가능한 Workers·Durable Objects 구현을 만들고 있었다. Cloudflare 입장에서는 자신들이 오래전부터 만들고 싶었던 것을 Deno 팀이 만들고 있었던 셈이다.

그래서 이번 합류는 단순한 인수라기보다 프로젝트의 결합이다.

Ryan Dahl과 Bert Belder는 workerd self-hosting을 Workers 프로그래밍 모델로 앱을 만들고 운영하는 일급 지원 방식으로 만드는 새 노력을 이끌게 된다. 이 과정에서 celld의 코드와 아이디어를 workerd로 다시 병합할 예정이다. Cloudflare는 앞으로 몇 달 안에 추가 발표가 있을 것이며, 당장 기다릴 수 없다면 celld나 workerd를 오늘부터 self-hosting할 수 있다고 설명했다.

이 발표가 중요한 이유는 클라우드 경쟁의 방향을 보여주기 때문이다.

오랫동안 클라우드 경쟁은 인프라 규모와 서비스 수의 경쟁이었다. 더 많은 리전, 더 많은 데이터베이스, 더 많은 매니지드 서비스, 더 강력한 컴퓨팅과 스토리지. 하지만 개발자 입장에서 문제는 점점 더 복잡해졌다. 작은 애플리케이션을 만들 때도 컴퓨트, 데이터베이스, 큐, 캐시, 스토리지, 인증, 오토스케일링, 배포, 로깅, 네트워크를 조립해야 했다.

Ryan Dahl이 말한 문제의식은 바로 이 복잡성이다.

Node.js는 비동기 I/O를 쉽게 쓰게 해 서버 개발을 단순화했다. Deno는 JavaScript 작성 경험을 개선했다. 그러나 런타임 주변에서 개발자가 조립해야 하는 것들은 여전히 많았다. 네트워크 애플리케이션의 더 큰 문제는 연산의 분산, 상태 조정, 데이터 저장, 수요에 맞춘 오토스케일링이었다.

Workers와 Durable Objects는 이 문제에 대한 하나의 답이다.

애플리케이션을 처음부터 분산된 상태 단위로 설계한다.
각 Durable Object는 작은 서버처럼 동작한다.
SQLite를 갖고 상태를 보관한다.
WebSocket을 처리한다.
플랫폼은 배치와 라우팅, 확장을 맡는다.

이 모델이 자체 인프라에서도 쉽게 돌아간다면, 개발자는 Cloudflare에 올리든 자체 서버에서 운영하든 같은 추상화를 사용할 수 있다.

여기서 Cloudflare가 얻는 것은 역설적이다.

자체 호스팅이 쉬워지면 고객이 Cloudflare를 떠날 수 있다. 그러나 Cloudflare는 이것이 오히려 좋은 사업이라고 본다. 탈출구가 있어야 고객이 안심하고 들어온다. lock-in에 대한 불안을 줄이면, 더 많은 기업이 Workers 모델을 채택할 수 있다. 실제로 Cloudflare는 workerd를 오픈소스로 공개했고, 일부 전 고객이 workerd를 이용해 Cloudflare를 떠났지만, 그래도 open source와 escape hatch가 좋은 비즈니스라고 말한다.

이는 클라우드 플랫폼 전략의 중요한 변화다.

과거 클라우드 사업자는 관리형 서비스의 편리함으로 고객을 붙잡았다. 데이터베이스, 큐, 서버리스, 스토리지, AI 서비스가 플랫폼 안에 깊게 결합될수록 이전은 어려워졌다. 그러나 AI와 개발자 플랫폼 경쟁이 치열해지면서, “나갈 수 있음” 자체가 신뢰의 조건이 되고 있다.

Cloudflare의 메시지는 이것이다.

우리는 lock-in으로 이기려는 것이 아니다.
Workers 모델이 더 낫기 때문에 이기려 한다.
그러려면 이 모델을 Cloudflare 밖에서도 쓸 수 있게 해야 한다.

Deno 팀 합류는 이 메시지를 기술적으로 뒷받침한다.

Ryan Dahl은 Node.js를 만든 사람이다. 서버 사이드 JavaScript라는 아이디어 자체를 대중화한 인물이다. 이후 Deno를 통해 JavaScript와 TypeScript 런타임 경험을 다시 개선하려 했다. Cloudflare는 Ryan과 Deno 팀이 self-hosted runtime 주변의 개발자 경험을 만드는 데 강점을 갖고 있다고 본다.

이 지점에서 이번 발표는 개발자 생태계에도 의미가 있다.

Deno는 Node.js의 대안으로 출발했다. 더 안전하고 현대적인 JavaScript·TypeScript 런타임을 만들려 했다. 그러나 이번 합류로 Deno 팀의 초점은 런타임 자체를 넘어 분산 애플리케이션 프로그래밍 모델로 확장된다. Deno가 Cloudflare 안에서 Workers와 Durable Objects self-hosting을 강화한다면, JavaScript 서버 개발의 다음 추상화는 런타임이 아니라 분산 상태와 실행 모델이 될 수 있다.

즉 질문이 바뀐다.

어떤 JavaScript 런타임을 쓸 것인가가 아니다.
어떻게 상태 있는 분산 애플리케이션을 단순하게 만들 것인가다.
어떻게 채팅, 협업, 큐, 데이터 저장, 실시간 통신을 별도 인프라 조립 없이 만들 것인가다.
어떻게 Cloudflare 밖에서도 같은 모델을 운영할 수 있게 할 것인가다.

Durable Objects의 핵심은 바로 상태다.

서버리스는 오랫동안 stateless 실행에 강했다. 요청이 들어오면 코드를 실행하고 끝난다. 하지만 실제 애플리케이션은 상태를 필요로 한다. 사용자 세션, 채팅방, 문서 공동 편집, 게임 룸, 작업 큐, 장기 실행 워크플로, 데이터베이스 연결. 상태가 들어오는 순간 개발자는 데이터베이스와 캐시, 락, 샤딩, 메시지 큐, 라우팅 문제를 마주한다.

Durable Objects는 상태를 작은 객체 단위로 묶는다.

각 객체는 단일 스레드 JavaScript 실행을 제공하므로 동시성 추론이 쉬워진다. 각 객체는 SQLite 데이터베이스를 갖고, WebSocket을 처리할 수 있다. 이 구조는 실시간 협업과 분산 상태 관리에 유리하다. Ryan Dahl이 Durable Objects를 “simple yet incredibly powerful”한 추상화로 본 이유다.

그러나 이 모델이 Cloudflare에만 묶여 있으면, 채택에는 한계가 있다.

기업은 멀티클라우드, 온프레미스, 규제 환경, 데이터 주권, 비용 통제, 장애 대비, 내부 플랫폼 표준 때문에 자체 운영 가능성을 원한다. workerd가 오픈소스였지만 Durable Objects가 제대로 확장되지 못했다면, Workers 모델은 여전히 Cloudflare 네트워크에 강하게 묶인 것으로 보일 수 있다.

Deno 팀과 celld는 이 병목을 풀려는 시도다.

celld는 여러 인스턴스와 하나의 object storage bucket만으로 분산 애플리케이션을 운영하려는 단순한 모델을 지향한다. compute, relational database, queue, real-time communication primitive를 기계 여러 대에 분산된 애플리케이션을 위해 설계된 하나의 모델로 묶는다. Ryan Dahl은 이것이 첫 Node.js 데모 이후 계속 추구해온 단순성에 더 가까운 형태라고 설명했다.

이 단순성은 앞으로 중요해질 가능성이 크다.

AI 에이전트, 실시간 협업, 멀티플레이어 앱, 개인화 서비스, 이벤트 기반 워크플로, 글로벌 SaaS는 모두 분산 상태를 요구한다. 개발자가 매번 클라우드 서비스 여러 개를 조립해야 한다면 속도는 느려지고 복잡성은 커진다. Workers와 Durable Objects 모델이 자체 호스팅까지 쉬워진다면, 개발자는 훨씬 단순한 mental model로 분산 애플리케이션을 만들 수 있다.

Cloudflare의 전략은 그래서 기술적으로도, 사업적으로도 흥미롭다.

기술적으로는 Workers 프로그래밍 모델을 Cloudflare 네트워크 밖으로 확장한다.
사업적으로는 lock-in 비판을 약화시키고 대형 고객의 불안을 줄인다.
생태계적으로는 JavaScript·TypeScript 서버 개발의 다음 추상화를 분산 상태 모델로 제시한다.

물론 위험도 있다.

자체 호스팅이 쉬워지면 Cloudflare의 차별성이 약해질 수 있다. 경쟁 클라우드나 기업 내부 플랫폼이 Workers 모델을 가져다 쓸 수 있다. Cloudflare에 남아야 할 이유가 줄어드는 것처럼 보일 수도 있다. 그러나 Cloudflare의 판단은 반대다. 모델이 널리 퍼질수록 Cloudflare의 네트워크, 운영, 글로벌 배포, 보안, 관리형 경험의 가치가 더 커질 수 있다는 것이다.

이는 오픈소스 플랫폼의 전형적 전략이다.

기술 표준을 열어 생태계를 키운다.
자체 운영을 허용해 신뢰를 얻는다.
가장 편하고 강력한 관리형 운영 경험으로 고객을 붙잡는다.

Cloudflare는 workerd를 이미 오픈소스로 공개했고, 이제 Deno 팀을 통해 Durable Objects self-hosting의 약점을 보완하려 한다. 이 전략이 성공하면, Workers는 Cloudflare 제품이자 동시에 더 넓은 프로그래밍 모델이 될 수 있다.

결국 이번 발표의 본질은 Deno가 Cloudflare에 합류했다는 사실 자체가 아니다.

더 중요한 것은 Cloudflare가 Workers를 “우리 네트워크에서만 쓰는 기능”이 아니라 “서버를 만드는 새로운 방식”으로 밀고 있다는 점이다. 그리고 그 방식을 설득하기 위해, Cloudflare는 탈출구를 더 강하게 만들려 한다.

이것은 역설적으로 가장 강한 플랫폼 전략일 수 있다.

나갈 수 있게 해야 들어온다.
옮길 수 있게 해야 표준이 된다.
자체 운영할 수 있게 해야 관리형 서비스의 가치가 선명해진다.

Deno 팀의 합류는 이 철학을 실행으로 옮기는 단계다.

Ryan Dahl은 Node.js로 JavaScript를 서버로 가져왔다. Deno로 런타임 경험을 다시 설계했다. 이제 Cloudflare 안에서 그는 Workers와 Durable Objects를 Cloudflare 밖으로 가져가려 한다.

서버 개발의 다음 질문은 더 이상 “서버를 어떻게 띄울 것인가”가 아닐 수 있다.

“상태 있는 분산 애플리케이션을 얼마나 단순하게 만들 것인가.”

Cloudflare와 Deno의 결합은 그 질문에 대한 하나의 답이다.