Cloudflare가 Astro를 인수하고 석 달이 지났다. 그리고 Astro 6가 나왔다. 릴리스 노트를 훑다가 한 줄에서 멈췄다 — "astro dev now runs on workerd." 이거, 생각보다 큰 얘기다.

"내 컴퓨터에선 되는데"의 진짜 원인

프론트엔드 개발자가 가장 많이 듣는 말이 뭐냐고 물으면 대부분 "IE 지원해야 돼요"를 떠올리겠지만, 2026년 현재 실제로 가장 골치 아픈 건 다른 거다. 로컬에서 잘 돌던 SSR 코드가 배포하면 터지는 문제. Node.js 런타임에서 개발하고 엣지 런타임에 배포하니까 당연히 생기는 일이다.

fs 못 쓰는 건 그래도 금방 알아챈다. 진짜 문제는 미묘한 차이들이다. crypto.subtle의 동작이 살짝 다르다든지, fetch의 캐시 정책이 런타임마다 다르다든지, Response 객체의 스트리밍 동작이 Node와 Workers에서 미세하게 갈린다든지. 이런 건 로컬 테스트로 못 잡는다. 스테이징에 올려봐야 알고, 운이 나쁘면 프로덕션에서 처음 발견한다.

기존 해결책은 시뮬레이션이었다. Miniflare가 대표적이다. Workers 런타임을 Node.js 위에서 흉내 내는 방식. 꽤 잘 동작했지만 결국 "흉내"일 뿐이다. 실제 workerd의 V8 isolate와 Node.js의 실행 컨텍스트는 근본적으로 다르다.

workerd가 dev 서버로 들어온다는 것

Astro 6의 접근은 다르다. 시뮬레이션을 개선하는 대신, 아예 dev 서버 자체를 workerd 위에 올렸다. astro dev를 실행하면 로컬에서 workerd 프로세스가 뜨고, 코드가 그 위에서 돌아간다.

이게 가능해진 건 Vite 6의 Environment API 덕분이다. Vite가 번들링은 Node에서 하되, 코드 실행 환경을 플러그인으로 교체할 수 있게 열어뒀다. Cloudflare 팀이 여기에 workerd 런타임을 꽂은 거고, Astro 6가 이걸 퍼스트클래스로 통합했다.

결과가 꽤 극적이다:

# 이전: Astro.locals.runtime으로 시뮬레이션
const db = Astro.locals.runtime.env.DB;  // 가짜

# 이후: 진짜 workerd 위에서 실행
const db = Astro.locals.runtime.env.DB;  // 진짜 D1

코드는 똑같아 보이지만 뒤에서 돌아가는 엔진이 완전히 다르다. D1, KV, R2, Durable Objects — 전부 로컬에서 실제 바인딩으로 접근한다. Mock이 아니다.

이건 Astro만의 이야기가 아니다

솔직히 말하면, 이 방향은 Astro가 처음 제시한 게 아니다. Remix는 일찌감치 어댑터 패턴으로 런타임 차이를 추상화하려 했고, Next.js 16도 Turbopack을 기본으로 밀면서 dev/prod 간극을 좁히는 데 집중하고 있다.

그런데 Astro + Cloudflare 조합이 흥미로운 건 추상화가 아니라 동일화를 택했기 때문이다. 런타임 차이를 감추는 게 아니라, 런타임 자체를 같은 걸 쓰겠다는 접근. 이건 철학적으로 꽤 다른 선택이다.

물론 트레이드오프가 있다. 제일 큰 건 벤더 종속이다. dev 서버가 workerd에 의존한다는 건 사실상 Cloudflare에 묶인다는 뜻이다. Astro 팀은 "workerd는 오픈소스고, 다른 어댑터도 여전히 지원한다"고 말하지만 — 현실적으로 퍼스트클래스 경험은 Cloudflare에서만 가능하다. Vercel이나 AWS에 배포하면 이 기능을 못 쓴다.

그래서 갈아타야 하나

프레임워크를 다섯 번 갈아탄 입장에서 하나 말해두자면: 이건 "Astro로 갈아타세요" 얘기가 아니다.

주목해야 할 건 방향성이다. dev 환경과 prod 환경의 간극을 줄이는 흐름은 이제 돌이킬 수 없다. Docker가 백엔드에서 "내 컴퓨터에선 되는데" 문제를 사실상 해결한 것처럼, 프론트엔드도 비슷한 전환점을 지나고 있다.

다만 Docker와 다른 점은, 컨테이너는 범용 기술이었고 workerd는 특정 벤더의 런타임이라는 거다. WinterCG 스펙이 성숙해서 런타임 간 호환성이 보장되면 좋겠지만, 아직 거기까진 멀었다.

당장 실무에서 고려할 포인트 몇 가지:

  • 콘텐츠 중심 사이트를 Cloudflare에 배포한다면 — Astro 6 + workerd dev 서버 조합은 지금 바로 써볼 가치가 있다. SSR 디버깅 시간이 체감상 반은 줄 거다.

  • Vercel/AWS 기반이라면 — 굳이 옮길 필요 없다. 대신 Next.js 16의 Turbopack 안정화와 dev/prod 패리티 개선을 지켜보는 게 낫다.

  • 멀티 클라우드 전략이라면 — 특정 런타임에 dev 서버를 묶는 건 리스크다. 어댑터 패턴이 여전히 더 안전한 선택일 수 있다.

프론트엔드 인프라의 판이 조용히 바뀌고 있다. 프레임워크를 고르는 기준이 "DX가 좋냐"에서 "런타임까지 일관되냐"로 넘어가는 시점. 번들러 성능 전쟁은 Vite 8 + Rolldown이 사실상 끝냈으니, 다음 전장은 여기다.