한 명의 엔지니어와 AI 모델이 Vite 위에 Next.js의 API 표면을 재구현해, Cloudflare Workers에 단일 명령으로 배포 가능한 드롭인 대체재 vinext를 1주일 만에 만들어낸 과정과 성능·배포·프리렌더링 전략을 소개합니다.
2026-02-24
10 min read
*이 글은 빌드 시간 벤치마크의 오타를 수정하기 위해 PT 기준 오후 12:35에 업데이트되었습니다.
지난주, 한 명의 엔지니어와 하나의 AI 모델이 가장 인기 있는 프런트엔드 프레임워크를 처음부터 다시 만들었습니다. 그 결과물인 vinext ("비-넥스트"라고 발음)는 Vite 위에서 구축된 Next.js의 드롭인 대체재이며, 단 하나의 명령으로 Cloudflare Workers에 배포할 수 있습니다. 초기 벤치마크에서 프로덕션 앱 빌드는 최대 4배 빠르고, 클라이언트 번들은 최대 57% 더 작습니다. 그리고 이미 프로덕션에서 사용하는 고객도 있습니다.
전체 비용은 토큰으로 약 1,100달러였습니다.
Next.js는 가장 인기 있는 React 프레임워크입니다. 수백만 명의 개발자가 사용합니다. 프로덕션 웹의 상당 부분을 구동하며, 그럴 만한 이유가 있습니다. 개발자 경험은 최상급입니다.
하지만 더 넓은 서버리스 생태계에서 사용할 때 Next.js에는 배포 문제가 있습니다. 툴링이 완전히 맞춤형입니다. Next.js는 Turbopack에 큰 투자를 했지만, Cloudflare, Netlify, AWS Lambda에 배포하려면 해당 빌드 결과물을 대상 플랫폼이 실제로 실행할 수 있는 형태로 다시 가공해야 합니다.
“그거 OpenNext가 하는 거 아닌가요?”라고 생각했다면, 맞습니다.
바로 그 문제를 해결하기 위해 OpenNext가 만들어졌습니다. Cloudflare를 포함해 여러 제공업체가 OpenNext에 많은 엔지니어링 노력을 들였습니다. 작동하긴 하지만, 곧 한계에 부딪히고 두더지 잡기(whack-a-mole) 게임이 됩니다.
Next.js 출력물 위에 구축하는 방식은 어렵고 취약한 접근이라는 것이 입증되었습니다. OpenNext는 Next.js의 빌드 출력물을 역공학해야 하므로, 버전 사이에 예측 불가능한 변화가 생기고 이를 수정하는 데 많은 작업이 필요합니다.
Next.js는 1급(First-class) 어댑터 API를 만들고 있으며, 저희는 그들과 협업하고 있습니다. 아직 초기 단계지만, 어댑터가 있어도 여전히 맞춤형 Turbopack 툴체인 위에서 빌드하게 됩니다. 또한 어댑터는 빌드와 배포만 다룹니다. 개발 중에는 next dev가 Node.js에서만 실행되며 다른 런타임을 꽂을 방법이 없습니다. 애플리케이션이 Durable Objects, KV, AI 바인딩 같은 플랫폼 전용 API를 사용한다면, 우회책 없이 개발 모드에서 그 코드를 테스트할 수 없습니다.
Next.js 출력물을 적응(adapt)시키는 대신, Vite 위에서 Next.js의 API 표면을 직접 재구현하면 어떨까요? Vite는 Next.js 외 프런트엔드 생태계 대부분이 사용하는 빌드 도구로, Astro, SvelteKit, Nuxt, Remix 같은 프레임워크를 구동합니다. 래퍼나 어댑터가 아니라, 깔끔한 재구현입니다. 솔직히 저희도 될 거라고 생각하지 않았습니다. 하지만 2026년이고, 소프트웨어를 만드는 비용 구조가 완전히 바뀌었습니다.
예상보다 훨씬 멀리 갔습니다.
npm install vinext
스크립트에서 next를 vinext로 바꾸기만 하면 나머지는 그대로입니다. 기존 app/, pages/, next.config.js는 변경 없이 동작합니다.
shvinext dev # HMR이 포함된 개발 서버 vinext build # 프로덕션 빌드 vinext deploy # 빌드 후 Cloudflare Workers에 배포
이것은 Next.js 및 Turbopack 출력물에 대한 래퍼가 아닙니다. 라우팅, 서버 렌더링, React Server Components, 서버 액션, 캐싱, 미들웨어 등 API 표면을 대체 구현한 것입니다. 모든 것은 Vite 플러그인 형태로 Vite 위에 구축됩니다. 무엇보다도 Vite 출력물은 Vite Environment API 덕분에 어떤 플랫폼에서도 실행할 수 있습니다.
초기 벤치마크는 유망합니다. 동일한 33개 라우트 App Router 애플리케이션으로 Next.js 16과 vinext를 비교했습니다. 두 프레임워크는 동일한 작업(컴파일, 번들링, 서버 렌더링 라우트 준비)을 수행합니다. Next.js 빌드에서 TypeScript 타입 체크와 ESLint를 비활성화했고(Vite는 빌드 중 이를 실행하지 않습니다), force-dynamic을 사용해 Next.js가 정적 라우트를 추가로 사전 렌더링하느라 시간을 쓰지 않도록 했습니다(그렇게 하면 Next.js 수치가 부당하게 느려집니다). 목표는 번들러 및 컴파일 속도만 측정하는 것이었고, 다른 요소는 배제했습니다. 벤치마크는 main 브랜치로의 모든 머지마다 GitHub CI에서 실행됩니다.
프로덕션 빌드 시간:
| 프레임워크 | 평균 | Next.js 대비 |
|---|---|---|
| Next.js 16.1.6 (Turbopack) | 7.38s | 기준선 |
| vinext (Vite 7 / Rollup) | 4.64s | 1.6배 빠름 |
| vinext (Vite 8 / Rolldown) | 1.67s | 4.4배 빠름 |
클라이언트 번들 크기(gzip):
| 프레임워크 | Gzip | Next.js 대비 |
|---|---|---|
| Next.js 16.1.6 | 168.9 KB | 기준선 |
| vinext (Rollup) | 74.0 KB | 56% 더 작음 |
| vinext (Rolldown) | 72.9 KB | 57% 더 작음 |
이 벤치마크는 컴파일 및 번들링 속도를 측정하며, 프로덕션 서빙 성능을 측정하지 않습니다. 테스트 픽스처는 단일 33개 라우트 앱으로, 모든 프로덕션 애플리케이션을 대표하는 샘플이 아닙니다. 세 프로젝트가 계속 발전함에 따라 이 수치는 변할 것으로 예상합니다. 전체 방법론과 과거 결과는 공개되어 있습니다. 확정적 결론이 아니라 방향성 지표로 보세요.
다만 방향은 고무적입니다. Vite의 아키텍처, 특히 Vite 8에서 도입될 Rust 기반 번들러인 Rolldown은 빌드 성능에서 구조적 이점을 가지며, 여기서 그 점이 분명히 드러납니다.
vinext는 Cloudflare Workers를 첫 번째 배포 대상으로 삼아 만들어졌습니다. 단 하나의 명령으로 소스 코드에서 실행 중인 Worker까지 갈 수 있습니다.
vinext deploy
이 명령은 모든 것을 처리합니다. 애플리케이션을 빌드하고, Worker 설정을 자동 생성하며, 배포합니다. App Router와 Pages Router 모두 Workers에서 동작하며, 완전한 클라이언트 측 하이드레이션, 인터랙티브 컴포넌트, 클라이언트 측 내비게이션, React 상태를 지원합니다.
프로덕션 캐싱을 위해 vinext에는 Cloudflare KV 캐시 핸들러가 포함되어 있어, 별도 설정 없이 ISR(Incremental Static Regeneration)을 제공합니다.
tsimport { KVCacheHandler } from "vinext/cloudflare"; import { setCacheHandler } from "next/cache"; setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));
KV는 대부분의 애플리케이션에 좋은 기본값이지만, 캐싱 레이어는 플러그형으로 설계되어 있습니다. setCacheHandler 호출은 상황에 맞는 어떤 백엔드로든 교체할 수 있다는 뜻입니다. 캐시 페이로드가 크거나 접근 패턴이 다른 앱에는 R2가 더 적합할 수 있습니다. 또한 저희는 설정을 덜 요구하면서 강력한 캐싱 레이어를 제공할 수 있도록 Cache API 개선도 진행 중입니다. 목표는 유연성입니다. 앱에 맞는 캐싱 전략을 선택하세요.
지금 바로 실행 중인 라이브 예시:
또한 getPlatformProxy 같은 우회책 없이도 Next.js 앱에서 Cloudflare Agents를 실행하는 라이브 예시도 있습니다. 이제 전체 앱이 개발과 배포 단계 모두에서 workerd 안에서 실행되기 때문입니다. 즉, 타협 없이 Durable Objects, AI 바인딩, 그 외 모든 Cloudflare 전용 서비스를 사용할 수 있습니다. 여기에서 확인해 보세요.
현재 배포 타깃은 Cloudflare Workers이지만, 그것은 전체 그림의 작은 일부입니다. vinext의 95% 정도는 순수 Vite입니다. 라우팅, 모듈 심(shim), SSR 파이프라인, RSC 통합: 그 어떤 것도 Cloudflare 전용이 아닙니다.
Cloudflare는 다른 호스팅 제공업체들과 협력해 그들의 고객을 위한 이 툴체인 채택을 추진하려고 합니다(부담은 최소입니다 — Vercel에서 30분도 안 되어 PoC가 동작했습니다!). 이는 오픈 소스 프로젝트이며, 장기적 성공을 위해서는 생태계 전반의 파트너들과 협력해 지속적인 투자가 이루어지도록 하는 것이 중요하다고 믿습니다. 다른 플랫폼의 PR도 환영합니다. 배포 타깃 추가에 관심이 있다면 이슈를 열어 주시거나 연락 주세요.
분명히 말씀드리자면 vinext는 실험적입니다. 출시된 지 1주도 채 안 되었고, 대규모 의미 있는 트래픽에서 검증되지 않았습니다. 프로덕션 애플리케이션에 도입을 검토 중이라면 적절한 주의와 함께 진행하세요.
그럼에도 테스트 스위트는 방대합니다. 1,700개 이상의 Vitest 테스트와 380개의 Playwright E2E 테스트가 있으며, Next.js 테스트 스위트와 OpenNext의 Cloudflare 적합성 테스트 스위트에서 직접 포팅한 테스트도 포함됩니다(코드에서 출처 표기를 확인할 수 있습니다). Next.js App Router Playground에 대해 검증했습니다. Next.js 16 API 표면의 94%를 커버합니다. 실사용 고객의 초기 결과도 고무적입니다. 저희는 모든 정부 인터페이스를 현대화하려는 팀인 National Design Studio와 그들의 베타 사이트 중 하나인 CIO.gov에서 함께 작업해 왔습니다. 그들은 이미 vinext를 프로덕션에서 운영 중이며, 빌드 시간과 번들 크기에서 의미 있는 개선을 얻고 있습니다.
README에는 지원하지 않으며 앞으로도 지원하지 않을 것들과 알려진 한계가 솔직하게 정리되어 있습니다. 과장 약속을 하기보다는, 있는 그대로를 투명하게 알리고자 합니다.
vinext는 기본적으로 ISR을 즉시 지원합니다. 어떤 페이지든 첫 요청 이후 캐시되고, 백그라운드에서 재검증되며, Next.js와 동일하게 동작합니다. 이 부분은 지금도 됩니다.
다만 vinext는 아직 빌드 시점의 정적 프리렌더링을 지원하지 않습니다. Next.js에서는 동적 데이터가 없는 페이지가 next build 중 렌더링되어 정적 HTML로 제공됩니다. 동적 라우트가 있다면 generateStaticParams()로 빌드할 페이지를 미리 열거합니다. vinext는… 아직 그걸 하지 않습니다.
이는 출시를 위한 의도적인 설계 결정이었습니다. 로드맵에 포함되어 있지만, 사이트가 100% 정적 콘텐츠로 미리 빌드된 HTML이라면 현재의 vinext에서 큰 이점을 보지 못할 가능성이 큽니다. 그렇다 해도, 한 명의 엔지니어가 토큰 1,100달러로 Next.js를 다시 만들 수 있다면, 여러분은 10달러로 정적 콘텐츠에 특화된 Vite 기반 프레임워크(예: Astro, 그리고 Cloudflare Workers에도 배포 가능)로 마이그레이션할 수도 있을 겁니다.
하지만 순수 정적이 아닌 사이트라면, 빌드 시점에 모든 것을 프리렌더링하는 것보다 더 나은 방법을 할 수 있다고 생각합니다.
Next.js는 generateStaticParams()에 나열된 모든 페이지를 빌드 중에 프리렌더링합니다. 10,000개 상품 페이지가 있는 사이트라면, 그중 99%는 한 번도 요청되지 않을 수도 있는데도 빌드 시점에 10,000번 렌더링합니다. 빌드는 페이지 수에 선형적으로 비례해 커집니다. 대형 Next.js 사이트의 빌드가 30분까지 늘어나는 이유입니다.
그래서 트래픽 인지 프리렌더링(TPR, Traffic-aware Pre-Rendering)을 만들었습니다. 지금은 실험적이며, 더 많은 실전 테스트가 쌓이면 기본값으로 만들 계획입니다.
아이디어는 간단합니다. Cloudflare는 이미 여러분 사이트의 리버스 프록시입니다. 우리는 트래픽 데이터를 가지고 있습니다. 실제로 방문되는 페이지가 무엇인지 압니다. 그러니 전부를 프리렌더링하거나 아무것도 프리렌더링하지 않는 대신, vinext가 배포 시점에 Cloudflare의 존(Zone) 애널리틱스를 조회해 중요한 페이지만 프리렌더링합니다.
shvinext deploy --experimental-tpr Building... Build complete (4.2s) TPR (experimental): Analyzing traffic for my-store.com (last 24h) TPR: 12,847 unique paths — 184 pages cover 90% of traffic TPR: Pre-rendering 184 pages... TPR: Pre-rendered 184 pages in 8.3s → KV cache Deploying to Cloudflare Workers...
100,000개 상품 페이지가 있는 사이트에서는 파워 법칙 때문에 보통 트래픽의 90%가 50~200개 페이지에 몰립니다. 그 페이지들은 몇 초 안에 프리렌더링됩니다. 나머지는 온디맨드 SSR로 처리되고, 첫 요청 이후 ISR을 통해 캐시됩니다. 새로운 배포마다 현재 트래픽 패턴에 따라 대상 집합이 갱신됩니다. 바이럴이 된 페이지도 자동으로 포착됩니다. 이 모든 것이 generateStaticParams() 없이, 그리고 빌드를 프로덕션 데이터베이스에 결합하지 않고 동작합니다.
이런 프로젝트는 보통 여러 엔지니어 팀이 몇 달, 아니 몇 년이 걸립니다. 여러 회사의 여러 팀이 시도했지만 범위가 너무 큽니다. Cloudflare에서도 한 번 시도했습니다! 두 개의 라우터, 33개 이상의 모듈 심, 서버 렌더링 파이프라인, RSC 스트리밍, 파일 시스템 라우팅, 미들웨어, 캐싱, 정적 내보내기(static export). 아무도 해내지 못한 데는 이유가 있습니다.
이번에는 일주일도 안 되어 해냈습니다. 한 명의 엔지니어(정확히는 엔지니어링 매니저)가 AI를 지휘했습니다.
첫 커밋은 2월 13일에 들어갔습니다. 그날 저녁이 끝날 무렵에는 Pages Router와 App Router 모두 기본 SSR이 동작했고, 미들웨어, 서버 액션, 스트리밍도 포함되었습니다. 다음 날 오후에는 App Router Playground가 11개 라우트 중 10개를 렌더링했습니다. 3일차에는 vinext deploy로 완전한 클라이언트 하이드레이션을 포함한 앱을 Cloudflare Workers에 배포할 수 있었습니다. 남은 기간은 하드닝이었습니다. 엣지 케이스 수정, 테스트 스위트 확장, API 커버리지를 94%까지 끌어올리는 작업이었습니다.
이전의 시도들과 비교해 무엇이 달라졌을까요? AI가 좋아졌습니다. 훨씬 더요.
모든 프로젝트가 이렇게 되지는 않습니다. 하지만 이 프로젝트는 몇 가지 조건이 딱 맞아떨어졌기 때문에 가능했습니다.
Next.js는 명세가 잘 정리되어 있습니다. 문서가 방대하고 사용자 기반이 크며, 수년치 Stack Overflow 답변과 튜토리얼이 있습니다. API 표면이 학습 데이터 전반에 퍼져 있습니다. Claude에게 getServerSideProps를 구현해 달라거나 useRouter가 어떻게 동작하는지 설명해 달라고 하면, 환각(hallucination)하지 않습니다. Next가 어떻게 동작하는지 알고 있습니다.
Next.js에는 정교한 테스트 스위트가 있습니다. Next.js 저장소에는 모든 기능과 엣지 케이스를 다루는 수천 개의 E2E 테스트가 있습니다. 저희는 그 테스트를 직접 포팅했습니다(코드에 출처 표기가 있습니다). 이는 기계적으로 검증 가능한 명세가 되어 주었습니다.
Vite는 훌륭한 기반입니다. Vite는 프런트엔드 툴링의 어려운 부분을 처리합니다. 빠른 HMR, 네이티브 ESM, 깔끔한 플러그인 API, 프로덕션 번들링. 번들러를 새로 만들 필요가 없었습니다. Next.js의 언어를 말하도록 가르치기만 하면 됐습니다. @vitejs/plugin-rsc는 아직 초기지만, RSC 구현을 처음부터 만들지 않고도 React Server Components를 지원할 수 있게 해주었습니다.
모델이 따라잡았습니다. 몇 달 전만 해도 이건 불가능했을 거라고 생각합니다. 이전 모델은 이 크기의 코드베이스 전반에 걸쳐 일관성을 유지하지 못했습니다. 새로운 모델은 전체 아키텍처를 문맥 안에 유지하고, 모듈 간 상호작용을 추론하며, 충분히 자주 올바른 코드를 생산해 모멘텀을 유지합니다. 때로는 버그를 해결하기 위해 Next, Vite, React 내부까지 파고드는 모습을 봤습니다. 최첨단 모델은 인상적이고, 계속 더 좋아지는 것 같습니다.
이 모든 조건이 동시에 참이어야 했습니다. 잘 문서화된 목표 API, 포괄적인 테스트 스위트, 탄탄한 빌드 도구 기반, 그리고 복잡도를 감당할 수 있는 모델. 이 중 하나라도 없으면, 결과는 훨씬 덜 좋았을 겁니다.
vinext의 거의 모든 코드는 AI가 작성했습니다. 하지만 더 중요한 점은 모든 라인이 사람이 쓴 코드에 기대하는 것과 같은 품질 관문을 통과한다는 것입니다. 이 프로젝트에는 1,700개 이상의 Vitest 테스트, 380개의 Playwright E2E 테스트, tsgo를 통한 전체 TypeScript 타입 체크, oxlint를 통한 린팅이 있습니다. CI는 모든 PR마다 이를 전부 실행합니다. 좋은 가드레일을 세우는 것이 AI를 코드베이스에서 생산적으로 만드는 데 핵심입니다.
과정은 계획에서 시작했습니다. OpenCode에서 Claude와 2시간 정도 주고받으며 아키텍처를 정의했습니다. 무엇을 만들지, 어떤 순서로 할지, 어떤 추상화를 쓸지. 그 계획이 북극성(north star)이 되었습니다. 이후 워크플로는 단순했습니다.
next/navigation 심을 구현: usePathname, useSearchParams, useRouter 포함")코드 리뷰에도 AI 에이전트를 연결했습니다. PR이 열리면 에이전트가 리뷰하고, 리뷰 코멘트가 돌아오면 다른 에이전트가 반영했습니다. 피드백 루프는 대부분 자동화되었습니다.
매번 완벽하진 않았습니다. 완전히 틀린 PR도 있었습니다. AI가 그럴듯하지만 실제 Next.js 동작과 맞지 않는 구현을 자신 있게 넣기도 했습니다. 저는 नियमित적으로 방향을 수정해야 했습니다. 아키텍처 결정, 우선순위, AI가 막다른 길로 가는지 아는 것: 그건 전부 제 역할이었습니다. AI에 좋은 방향, 좋은 문맥, 좋은 가드레일을 주면 매우 생산적일 수 있습니다. 하지만 결국 사람은 조종간을 잡아야 합니다.
브라우저 수준 테스트를 위해 agent-browser를 사용해 실제 렌더링 결과, 클라이언트 측 내비게이션, 하이드레이션 동작을 검증했습니다. 유닛 테스트는 미묘한 브라우저 이슈를 많이 놓칩니다. 이 도구가 그런 문제를 잡아줬습니다.
프로젝트 전체에서 OpenCode 세션을 800회 이상 실행했습니다. 총 비용은 Claude API 토큰으로 대략 1,100달러였습니다.
왜 우리는 스택에 এত 많은 레이어를 쌓아 왔을까요? 이 프로젝트는 이 질문을 깊이 생각하게 만들었습니다. 그리고 AI가 답에 어떤 영향을 주는지도요.
소프트웨어의 대부분의 추상화는 인간이 도움이 필요해서 존재합니다. 우리는 시스템 전체를 머릿속에 담을 수 없었고, 그래서 복잡도를 관리하기 위해 레이어를 만들었습니다. 각 레이어는 다음 사람의 일을 쉽게 했습니다. 그 결과 프레임워크 위에 프레임워크, 래퍼 라이브러리, 수천 줄의 접착(glue) 코드가 생겼습니다.
AI는 같은 제약이 없습니다. 시스템 전체를 문맥으로 유지하고 코드를 그냥 써낼 수 있습니다. 정리를 위해 중간 프레임워크가 필요하지 않습니다. 명세와 기반만 있으면 됩니다.
어떤 추상화가 진정으로 기반적(foundational)이고, 어떤 것이 인간 인지의 지팡이(crutch)였는지는 아직 확실하지 않습니다. 그 경계는 앞으로 몇 년 동안 크게 이동할 것입니다. 하지만 vinext는 하나의 데이터 포인트입니다. 우리는 API 계약, 빌드 도구, AI 모델을 가져왔고, 그 사이를 AI가 전부 작성했습니다. 중간 프레임워크 없이도요. 우리는 이 패턴이 많은 소프트웨어에서 반복될 것이라 생각합니다. 수년간 쌓아 올린 레이어들이 모두 살아남지는 못할 겁니다.
Vite 팀에 감사드립니다. Vite는 이 모든 것을 지탱하는 기반입니다. @vitejs/plugin-rsc는 아직 초기지만, RSC 지원을 처음부터 만들지 않고도 제공해 줬고, 이는 결정적인 요소였습니다. Vite 메인테이너들은 플러그인이 기존에 테스트되지 않았던 영역으로 확장되는 과정에서 매우 빠르게 응답하고 도움을 주었습니다.
또한 Next.js 팀에도 감사드립니다. 그들은 React 개발 경험의 기준을 높이는 프레임워크를 수년간 만들어 왔습니다. API 표면이 잘 문서화되어 있고 테스트 스위트가 포괄적이라는 사실이 이 프로젝트를 가능하게 한 큰 이유 중 하나입니다. vinext는 그들이 세운 기준 없이는 존재할 수 없었습니다.
vinext에는 마이그레이션을 대신 처리해 주는 Agent Skill이 포함되어 있습니다. Claude Code, OpenCode, Cursor, Codex 등 수십 가지 AI 코딩 도구와 함께 동작합니다. 설치한 뒤 Next.js 프로젝트를 열고, AI에게 마이그레이션하라고 말하면 됩니다.
npx skills add cloudflare/vinext
그다음 지원되는 어떤 도구에서든 Next.js 프로젝트를 열고 이렇게 말하세요:
migrate this project to vinext
이 스킬은 호환성 체크, 의존성 설치, 설정 생성, 개발 서버 시작을 처리합니다. vinext가 지원하는 것을 알고 있으며, 수동 조치가 필요한 부분을 표시해 줍니다.
직접 하고 싶다면:
shnpx vinext init # 기존 Next.js 프로젝트 마이그레이션 npx vinext dev # 개발 서버 시작 npx vinext deploy # Cloudflare Workers로 배포
소스 코드는 github.com/cloudflare/vinext에 있습니다. 이슈, PR, 피드백을 환영합니다.
Cloudflare의 커넥티비티 클라우드는 기업 전체 네트워크를 보호하고, 고객이 인터넷 규모 애플리케이션을 효율적으로 구축하도록 돕고, 어떤 웹사이트 또는 인터넷 애플리케이션이든 가속하며, DDoS 공격을 막고, 해커를 차단하며, Zero Trust 여정에도 도움을 줄 수 있습니다.
어떤 기기에서든 1.1.1.1에 방문해 인터넷을 더 빠르고 안전하게 만드는 무료 앱을 시작해 보세요.
더 나은 인터넷을 만들기 위한 Cloudflare의 미션을 더 알아보려면 여기서 시작하세요. 새로운 커리어를 찾고 있다면 채용 공고를 확인해 보세요.
AI Cloudflare Workers Workers AI Developers Developer Platform JavaScript Open Source Performance