무슨 일이 있었나요?
Deno 공식 블로그에 Cloudflare가 Deno를 인수한다는 소식이 올라왔어요. Deno는 Node.js를 처음 만든 라이언 달(Ryan Dahl)이 시작한 JavaScript/TypeScript 런타임이에요. “Node를 처음부터 다시 만든다면 이렇게 하겠다”는 생각에서 출발했거든요. 2018년에 그가 ‘Node.js에 대해 후회하는 10가지’라는 발표를 했는데, 일종의 반성문이었어요. 그 반성을 코드로 옮긴 게 바로 Deno였어요.
여기서 런타임이 뭐냐면, 브라우저 밖에서 JavaScript 코드를 실행해 주는 환경이에요. 브라우저가 웹페이지 안의 JS를 실행하듯, 서버나 내 컴퓨터에서 JS를 실행해 주는 엔진과 도구 묶음이라고 보면 돼요. 대표적인 게 Node.js, Deno, Bun이에요.
그럼 왜 하필 Cloudflare일까요? Deno를 쓰고 있거나 도입을 고민하던 개발자한테는 뭐가 달라질까요? 하나씩 풀어볼게요.
Deno와 Cloudflare Workers는 원래 닮은꼴이에요
두 회사를 나란히 놓고 보면 기술적으로 놀랄 만큼 비슷한 길을 걸어왔어요.
첫째, 둘 다 구글의 V8 엔진을 기반으로 해요. 특히 Cloudflare Workers는 V8의 아이솔레이트(isolate) 라는 기능을 써서 수많은 고객 코드를 한 프로세스 안에서 서로 격리한 채로 실행해요. 아이솔레이트는 쉽게 말해 “한 건물 안에 칸막이를 친 개인 사무실”이에요. 컨테이너나 VM은 매번 건물을 새로 짓는 셈인데, 아이솔레이트는 칸막이만 세우면 되거든요. 그래서 몇 밀리초 만에 뜨고 메모리도 훨씬 적게 먹어요. Deno의 서버리스 플랫폼인 Deno Deploy도 같은 아이디어를 쓰고 있어요.
둘째, 둘 다 웹 표준 API를 가장 먼저 챙겨요. Node.js에는 http 모듈이나 Buffer처럼 Node에만 있는 API가 많았어요. 반면 Deno와 Workers는 브라우저에 있는 fetch, Request/Response, Web Streams를 서버에서도 그대로 쓰게 해 줬어요. 그래서 두 환경의 코드가 거의 똑같이 생겼어요.
// Deno
Deno.serve((req: Request) => new Response('Hello DayCraft'));
// Cloudflare Workers
export default {
fetch(req: Request) {
return new Response('Hello DayCraft');
},
};
진입점 모양만 살짝 다르고, 요청과 응답을 다루는 방식은 같아요. 두 회사는 서버 사이드 JS 런타임끼리 API를 맞추자는 표준화 모임에서도 함께 활동해 왔어요. 처음엔 WinterCG라는 이름이었고, 지금은 Ecma 산하의 WinterTC예요. 그래서 이번 인수는 뜬금없는 결합이라기보다, 원래 같은 방향을 보던 두 팀이 합친 것에 가까워요.
업계 맥락: 런타임 혼자서는 버티기 어려운 시대
이번 인수만 유독 튀는 사건은 아니에요. 최근 JS 생태계에서는 비슷한 일이 이어졌거든요. Bun은 2025년 말 Anthropic에 인수됐어요. Vercel은 Next.js를 키워 온 데 이어 Nuxt를 만든 NuxtLabs도 품었고요. Cloudflare도 PartyKit 같은 개발자 도구 회사를 꾸준히 인수해 왔어요.
공통점이 보이시나요? 런타임이나 프레임워크는 오픈소스라서 그 자체로는 돈을 벌기 어려워요. 그래서 보통 호스팅으로 수익을 내려고 하는데, 호스팅 시장은 AWS, Vercel, Cloudflare 같은 거대 플레이어가 꽉 잡고 있어요. 게다가 Node.js도 최근 타입 정보만 걷어내는 방식(type stripping)으로 .ts 파일을 바로 실행할 수 있게 됐어요. ‘설정 없이 TypeScript 실행’은 원래 Deno의 대표 장점이었는데, 그 차별점이 점점 옅어지고 있었던 거예요.
Cloudflare가 얻는 건 꽤 많아요. 로컬 개발 경험이 좋은 런타임에, 린터·포매터·테스트 러너가 다 들어 있는 올인원 CLI가 따라오고, JSR 같은 패키지 레지스트리도 있어요. 무엇보다 런타임을 깊이 아는 엔지니어 팀이 함께 와요. 엣지 플랫폼 위에 얹을 ‘개발자 경험’ 레이어를 통째로 가져오는 셈이에요.
한국 개발자에게 주는 시사점
1. Deno를 쓰고 있어도 당장 걱정할 필요는 없어요. Deno CLI는 MIT 라이선스 오픈소스라서 코드가 사라지지는 않아요. 다만 Deno Deploy나 Deno KV처럼 회사가 운영하는 호스팅 서비스에 기대고 있다면, 앞으로 나올 공지를 꼼꼼히 챙겨 보세요. 서비스를 합치거나 옮기라는 안내가 나올 가능성이 충분하거든요.
2. 웹 표준 API로 코드를 짜는 습관이 더 중요해졌어요. 런타임 회사의 운명은 언제든 바뀔 수 있어요. fetch, Request/Response 같은 표준 위에 코드를 짜고, Hono처럼 여러 런타임에서 돌아가는 프레임워크를 쓰면 Node, Deno, Bun, Workers 중 어디로든 옮기기 쉬워져요. 특정 런타임 전용 API는 얇은 어댑터 뒤에 숨겨 두는 걸 추천해요.
3. 엣지 컴퓨팅을 지금 한번 맛봐 두세요. 국내 서비스는 아직 클라우드 서울 리전 중심으로 구성된 곳이 많아요. 그래도 이미지 리사이징, 인증 게이트웨이, A/B 테스트처럼 가벼운 로직을 엣지로 빼는 사례는 계속 늘고 있어요. 무료 플랜으로 작은 사이드 프로젝트 하나만 올려 봐도 감이 확 올 거예요.
마무리
한 줄 정리: Node의 반성문으로 태어난 Deno가 Cloudflare 품에 안겼어요. JS 런타임 경쟁의 질문도 ‘누가 더 좋은 런타임이냐’에서 ‘누구의 플랫폼 위에서 돌아가냐’로 바뀌고 있어요.
여러분은 어떻게 보세요? 런타임이 대형 플랫폼 회사에 흡수되는 흐름이 오픈소스 생태계에 득일까요, 실일까요? 지금 새 프로젝트를 시작한다면 Node, Deno, Bun 중에 무엇을 고르시겠어요?
🔗 출처: Hacker News