cloudflare·2026년 7월 30일·4분 읽기큐레이션 요약

대규모 도그푸딩: cdnjs를 Cloudflare의 개발자 플랫폼으로 마이그레이션하기

cdnjs는 2026년 6월 23일부터 Cloudflare Developer Platform만으로 운영되며, 이를 통해 하루 90억 건의 요청을 처리하는 대규모 오픈소스 CDN의 배포 파이프라인까지 단일 플랫폼으로 통합했다. 기존 시스템은 안정적이고 높은 캐시 적중률을 유지했지만, GCP·VM·GitHub·Cloudflare로 분산된 구조 때문에 관측성과 유지보수가 어려웠다. 이번 마이그레이션은 성능 개선보다 배포·처리 과정의 단순화, 추적 가능성, 보안성 향상에 초점을 둔 것이다. ### cdnjs가 여전히 대규모 트래픽을 처리하는 이유 - cdnjs는 JavaScript와 CSS 오픈소스 라이브러리를 무료로 제공하는 커뮤니티 기반 CDN이다. - 사용자는 API 키나 회원가입 없이 `<script>` 태그만으로 jQuery, Bootstrap, Lodash 등을 불러올 수 있다. - 전체 웹사이트의 약 12%, JavaScript CDN 시장의 48.3%가 cdnjs를 사용한다. - 하루 약 90억 건, 초당 평균 10만 8천 건의 요청을 처리하며 330개 이상의 Cloudflare 데이터센터에서 서비스한다. - 캐시 적중률은 98.6%에 달한다. - URL 규칙이 일관되고 버전이 불변이어서 ChatGPT, Claude, Cursor 같은 LLM이 예제 코드에 안정적으로 활용하기 쉽다. - 각 파일에 SRI 해시가 제공되고 미러가 감사 가능해 공급망 공격 대응에도 유리하다. - 무료·무제한 서비스라는 점 역시 cdnjs가 계속 사용되는 중요한 이유다. ### 기존 아키텍처의 배경 - 2020년 파일 제공 영역은 Cloudflare Workers와 KV로 이전됐다. - KV 장애 시에는 베어메탈 오리진을 사용하는 구조로 복원력을 높였다. - Brotli와 gzip으로 모든 자산을 사전 압축해 응답 크기도 줄였다. - 그러나 새 버전 감지, 패키지 다운로드, 압축, 처리 결과 저장을 담당하는 퍼블리싱 파이프라인은 GCP에 남아 있었다. - 당시 Workers에는 장시간 실행 작업, 대용량 아카이브 처리, 다단계 오케스트레이션을 지원할 기능이 충분하지 않았다. - 이에 따라 GCP Functions, VM 기반 `git-sync`, GCS, Pub/Sub, GitHub 저장소가 서로 연결된 형태로 운영됐다. ### 관측성과 데이터 일관성의 문제 - 하나의 패키지 업데이트가 Cloud Functions, GCS 이벤트, Pub/Sub, `git-sync` VM, Workers KV를 거쳤지만 공통 correlation ID가 없었다. - GCP Logging과 Cloudflare Logpush의 로그를 연결할 기준이 없어 장애 원인을 수작업으로 추적해야 했다. - 처리 결과가 KV에는 기록됐지만 GitHub 저장소 반영에 실패하는 부분 성공(partial success)이 발생할 수 있었다. - 두 저장소가 불일치해도 전체 파이프라인 상태를 아는 시스템이나 자동 알림이 없었다. - 파일은 엣지의 KV와 GitHub 저장소에 동시에 존재했지만 어느 쪽도 명확한 단일 원본이 아니었다. ### 이벤트 기반 파이프라인의 한계 - 여러 Cloud Functions가 공유 스토리지에 파일을 기록하고, 스토리지의 새 파일 이벤트가 다음 함수를 호출하는 방식이었다. - 스토리지가 메시지 큐 역할까지 맡으면서 구조가 복잡해졌다. - 명시적인 dead-letter queue가 없어 실패한 작업을 확인하기 어려웠다. - 대기 중인 작업의 backlog를 파악하기 어렵고, 특정 단계부터 깔끔하게 재실행하기도 힘들었다. - npm 업데이트 확인만 해도 알파벳별로 나눈 26개의 Cloud Functions가 필요했다. - 각 함수마다 별도의 배포와 로그가 있어 전체 시스템의 정상 여부를 확인하려면 26개를 모두 점검해야 했다. ### GitHub 저장소의 규모 문제 - `git-sync` VM은 처리된 모든 파일을 GitHub 저장소에 미러링했다. - 저장소의 packed storage가 1.1TB를 넘으면서 GitHub의 tarball·zip 아카이브 생성이 불가능해졌다. - 클론 속도가 느려지고 포크도 사실상 어려워졌다. - 비정상적이거나 처리하기 곤란한 릴리스를 차단하기 위한 `.gitignore` 항목이 274개까지 늘어났다. - GitHub 저장소는 원본 저장소이면서 동시에 배포 미러 역할까지 맡아 장기적인 확장에 부적합해졌다. ### 보안과 운영 부담 - GCP Functions, `git-sync` VM, 컨테이너 이미지, GCS 버킷, 서비스 계정 키 등 관리해야 할 보안 대상이 많았다. - 각 구성 요소마다 패치, 접근 권한 관리, 감사가 필요했다. - 기존 파이프라인을 폐기하면서 최근 발견된 cdnjs 관련 취약점도 함께 줄일 수 있었다. - 시스템 구성 요소가 줄어들어 장애 대응과 보안 관리가 단순해졌다. ### Cloudflare Developer Platform으로의 재구축 - 새 아키텍처는 Workers, Workflows, D1, Queues, Workers Cache, R2, KV, Containers를 사용해 Cloudflare 안에서 전체 파이프라인을 운영한다. - R2가 파일 콘텐츠의 단일 원본(single source of truth)이 됐다. - 실질적인 크기 제한이 없어 기존 KV에 저장하기 어려웠던 소스 맵, 대형 번들, 폰트 패키지도 함께 저장할 수 있다. - R2의 S3 호환 API를 통해 cdnjs 전체 카탈로그를 일반적인 S3 클라이언트로 접근하고 미러링할 수 있다. - 저장소와 처리 시스템을 하나의 플랫폼으로 통합함으로써 배포 상태 추적, 재처리, 장애 분석을 개선할 기반을 마련했다. ### 실용적인 시사점 대규모 서비스에서는 높은 성능이나 캐시 적중률만으로 충분하지 않다. 여러 클라우드와 저장소에 걸친 파이프라인은 부분 성공, 데이터 불일치, 로그 단절 문제를 만들 수 있으므로, 명확한 단일 원본과 공통 추적 ID, 재처리 가능한 작업 큐를 설계하는 것이 중요하다. 또한 플랫폼이 장시간 작업과 대용량 데이터를 지원할 만큼 성숙해졌다면, 분산된 운영 스택을 통합하는 것이 기능 추가와 보안 관리에 큰 이점이 된다.

원문 읽기(새 탭에서 열림)

Cloudflare Workers서버리스content-delivery-networkcloudflare-r2+3

cloudflare·2026년 7월 6일·4분 읽기큐레이션 요약

이제 Worker 앞에 자체 캐시를 둘 수 있습니다

Cloudflare의 **Workers Cache**는 Worker 앞에 계층형 캐시를 배치해, 캐시 적중 시 Worker를 실행하지 않고 응답을 반환하는 기능이다. Wrangler 설정 한 줄과 기존 HTTP `Cache-Control` 헤더만으로 사용할 수 있으며, 캐시 적중 시 CPU 비용과 렌더링 지연을 줄인다. 서버 렌더링 애플리케이션은 정적 사전 생성과 매 요청 렌더링 사이에서, 필요할 때만 렌더링하고 결과를 캐시하는 세 번째 선택지를 얻게 된다. ## 서버 렌더링 앱에 필요한 캐시 - 기존 Workers 구조에서는 Worker가 캐시와 원본 앞에 위치했다. - 요청 변환, URL 재작성, A/B 테스트, 트래픽 필터링 등에 적합했다. - 하지만 Worker 자체가 애플리케이션 서버이자 원본이 되면, 캐시할 대상이 없어 모든 요청이 코드를 실행한다. - Astro, TanStack Start, Next.js, Remix, SvelteKit 같은 프레임워크는 Cloudflare용 어댑터를 통해 앱을 Worker로 배포할 수 있다. - 동일한 응답을 반복 생성하더라도 매번 렌더링해야 하므로: - 페이지 로드마다 렌더링 지연이 발생한다. - Worker CPU 실행 비용이 계속 발생한다. - Workers Cache는 캐시를 Worker 앞에 배치한다. - 캐시 적중: Worker를 실행하지 않고 응답 반환, CPU 비용 0. - 캐시 실패: Worker가 실행되어 응답을 생성하고 캐시에 저장. - 이후 전 세계 어디서든 캐시된 응답을 받을 수 있다. ## 정적 생성과 매 요청 렌더링 사이의 선택지 - 빌드 시점 사전 생성(SSG)은 빠르지만 콘텐츠 변경마다 전체 빌드와 재배포가 필요하다. - 대규모 문서나 전자상거래 사이트에서는 빌드 시간이 길어질 수 있다. - 매 요청 서버 렌더링은 최신 데이터를 반영하지만, 모든 방문자가 렌더링 비용과 지연을 부담한다. - Workers Cache는 요청 시 생성한 결과를 TTL 동안 저장한다. - 새 페이지의 첫 요청만 렌더링한다. - 이후 요청은 정적 페이지처럼 캐시에서 제공한다. - TTL 만료 후 필요할 때 다시 렌더링한다. - 프레임워크별 ISR 구현 없이 표준 HTTP 캐싱 방식으로 동작한다. ## Wrangler 설정과 HTTP 헤더 기반 제어 - Wrangler 설정에서 캐시를 활성화한다. ```json { "name": "my-worker", "main": "src/index.ts", "compatibility_date": "2026-05-01", "cache": { "enabled": true } } ``` - 응답의 `Cache-Control` 헤더로 캐시 정책을 지정한다. ```ts return new Response(body, { headers: { "Cache-Control": "public, max-age=300, stale-while-revalidate=3600", "Cache-Tag": "products,product:123" } }); ``` - 별도의 Zone 설정, 규칙 엔진, 캐시 프로비저닝 없이 Worker 코드와 HTTP 헤더만으로 구성한다. - 커스텀 도메인, `workers.dev`, 서비스 바인딩, 프리뷰, Workers for Platforms 테넌트 등 Worker가 실행되는 여러 진입점에서 동일한 방식으로 사용할 수 있다. ## `stale-while-revalidate`로 만료 시에도 지연 방지 - `max-age=300`은 응답을 5분 동안 신선한 상태로 유지한다. - `stale-while-revalidate=3600`은 만료 후 최대 1시간 동안 오래된 응답을 즉시 제공하면서 백그라운드에서 새 응답을 생성하도록 한다. - 이 설정이 없으면 TTL 만료 직후 첫 요청이 Worker 렌더링을 기다려야 한다. - 설정이 있으면: - 사용자는 오래된 페이지를 즉시 받는다. - 응답에는 `Cf-Cache-Status: UPDATING`이 표시될 수 있다. - Worker는 백그라운드에서 캐시를 갱신한다. - 갱신을 유발한 요청자도 캐시 수준의 응답 속도를 얻는다. ## 캐시 무효화와 고급 기능 - 콘텐츠가 변경되면 Worker에서 직접 캐시를 제거할 수 있다. ```ts await ctx.cache.purge({ tags: ["product:123"] }); ``` - `Cache-Tag`를 사용하면 특정 상품이나 콘텐츠 그룹 단위로 캐시를 무효화할 수 있다. - 글에서 언급한 추가 기능은 다음과 같다. - 네트워크 전반의 계층형 캐싱 - `Vary`를 이용한 콘텐츠 협상 - `ctx.props` 기반의 멀티테넌트 안전 캐시 키 - 태그 또는 경로 접두사 기반 프로그래밍 방식 purge - 공개 엔드포인트뿐 아니라 모든 Worker 진입점 앞에 캐시 배치 - 진입점별 캐시 활성화 여부 제어 ## 적용 범위와 의의 - Workers Cache는 모든 요금제의 Worker에서 사용할 수 있으며 Wrangler로 활성화한다. - 캐시는 애플리케이션 구조에 맞춰 여러 진입점 사이에 배치할 수 있다. - 결과적으로 서버 렌더링 앱은 정적 사이트에 가까운 응답 속도와 동적 서버 렌더링의 최신성, 두 가지를 함께 얻을 수 있다. - 실무에서는 페이지 특성에 따라 `max-age`와 `stale-while-revalidate` 값을 정하고, 데이터 변경 시 `Cache-Tag` 기반 purge를 함께 사용하는 방식이 적합하다.

원문 읽기(새 탭에서 열림)

Cloudflare Workerswranglerhttp-cachingstale-while-revalidate+2

cloudflare·2026년 6월 24일·4분 읽기큐레이션 요약

모두를 위한 OAuth로 Cloudflare 앱 생태계의 잠금 해제

Cloudflare는 API 토큰 중심의 제한적인 연동 방식을 넘어, 모든 고객이 직접 OAuth 클라이언트를 관리할 수 있는 self-managed OAuth를 도입했다. 이를 통해 SaaS, 내부 개발자 플랫폼, 에이전트 도구가 사용자로부터 필요한 권한만 위임받고, 사용자는 동의·철회·권한 범위를 더 명확하게 관리할 수 있게 됐다. 이 확장을 위해 동의 화면과 철회 기능을 개선하고, OAuth 엔진인 Hydra를 무중단에 가깝게 1.X와 2.X로 단계적으로 업그레이드했다. ## 모든 고객을 위한 self-managed OAuth - 기존 Cloudflare OAuth는 Wrangler나 PlanetScale 같은 일부 파트너 통합에만 제공됐다. - 자체 통합을 개발하는 일반 개발자는 API 토큰을 사용해야 했지만, API 토큰은 다음과 같은 한계가 있었다. - 관리가 어렵다. - 사용자가 애플리케이션에 권한을 위임하는 흐름에 적합하지 않다. - 권한 범위와 철회 상태를 사용자 관점에서 명확히 관리하기 어렵다. - self-managed OAuth를 사용하면 개발자가 직접 OAuth 클라이언트를 만들고 관리할 수 있다. - 애플리케이션은 사용자가 승인한 범위 내에서만 Cloudflare API에 접근하며, 사용자는 권한을 쉽게 철회할 수 있다. - 주요 활용 사례는 SaaS 통합, 내부 개발자 플랫폼, 에이전트 기반 도구다. ## 대규모 OAuth 생태계를 위한 보안 개선 - 기존 OAuth 시스템은 소수의 파트너를 수동 관리하는 데는 충분했지만, 모든 고객에게 개방하기에는 권한 모델과 보안 장치가 부족했다. - 동의 화면을 개선해 다음 정보를 명확히 표시했다. - 어떤 애플리케이션이 접근을 요청하는지 - 애플리케이션에 부여될 권한이 무엇인지 - Cloudflare 대시보드에 애플리케이션 권한 철회 기능을 추가했다. - 앱 소유자 정보를 더 잘 표시해 OAuth 피싱 공격을 예방했다. - 동시에 OAuth 엔진의 성능과 데이터 안정성을 개선하면서, 사용자 중단을 최소화하는 업그레이드 계획이 필요했다. ## Hydra 1.X 업그레이드와 데이터베이스 마이그레이션 - Cloudflare는 기존 OAuth 엔진으로 오픈소스 Hydra를 사용하고 있었다. - 개발자 플랫폼과 에이전트 워크플로가 성장하면서 성능과 기능 확장을 위해 Hydra 업그레이드가 필요해졌다. - 한 번에 대규모 업그레이드를 진행하지 않고 다음 두 단계로 나눴다. 1. 최신 1.X 버전으로 업그레이드 2. 동작과 성능을 검증한 뒤 2.X로 업그레이드 - 1.X 업그레이드에도 다음과 같은 위험이 있었다. - 인덱스 생성이 주요 테이블에 배타적 잠금을 걸어 OAuth 작업을 차단할 수 있었다. - 주요 테이블에 컬럼을 추가하거나 다른 테이블로 컬럼을 이동해야 했다. - 기존 Hydra SDK의 `SELECT *` 사용 때문에 스키마 변경 후 역직렬화 문제가 발생할 수 있었다. - 이를 해결하기 위해: - 인덱스 생성 SQL을 `CREATE INDEX CONCURRENTLY` 기반으로 다시 작성했다. - 필요한 컬럼만 명시적으로 조회하는 Hydra 커스텀 버전을 제작했다. - 실제 1.X 마이그레이션은 예상보다 빠르게 완료됐고 사용자 영향도 없었다. - 다만 구버전 Hydra가 신버전에서 생성된 토큰을 조회하지 못했기 때문에 점진적 전환이 아닌 하드 컷오버가 필요했다. ## 2.X 업그레이드를 위한 블루-그린 전략 - Hydra 2.X는 스키마 변경 규모가 커서 기존 데이터베이스에서 바로 업그레이드하는 인플레이스 방식은 적합하지 않았다. - Cloudflare는 새 환경을 준비한 뒤 전환하는 블루-그린 방식을 선택했다. - 단순히 데이터베이스 연결만 바꾸는 방식으로는 부족했다. 마이그레이션에 수 시간이 걸리는 동안에도 OAuth가 계속 작동해야 했기 때문이다. - 검토한 첫 번째 방식은 업그레이드 중 데이터베이스 쓰기를 중단하는 것이었다. - 신규 OAuth 승인을 막아 데이터 유실을 방지할 수 있다. - 하지만 기존 앱도 새 인증을 사용할 수 없게 된다. - 사용자가 애플리케이션 권한을 철회할 수도 없어 보안상 문제가 된다. - 따라서 쓰기를 계속 허용하되, 전환 과정에서 일부 쓰기가 유실될 수 있는 방식을 채택했다. ## 토큰 만료 조정과 철회 이벤트 보존 - 전환 중 발생하는 신규 토큰 쓰기를 줄이기 위해 토큰 만료 시간을 몇 시간으로 늘렸다. - 업그레이드 직전에 발급된 토큰이 갱신 없이 계속 사용되도록 해, 전환 기간의 토큰 갱신 요청을 줄였다. - 반면 권한 철회 이벤트는 절대 유실되면 안 됐다. - 철회 이벤트가 사라지면 사용자가 접근을 차단한 애플리케이션의 권한이 다시 살아날 수 있다. - Cloudflare는 Cloudflare Queues를 이용해 철회 이벤트를 별도 큐에 기록했다. - 녹색 환경으로 전환한 뒤 큐를 비우면서 철회 이벤트를 재생해, 업그레이드 중 발생한 모든 철회를 반영했다. ## 리프레시 토큰 문제와 완화 - Hydra 1.X 업그레이드 후 리프레시 토큰 오류가 증가했다. - 새 버전에서는 리프레시 토큰이 재사용되면 전체 액세스 토큰·리프레시 토큰 체인을 무효화하는 동작이 더 엄격해졌다. - 요청량이 많은 Wrangler와 MCP 클라이언트에서는 재시도 한 번만 발생해도 전체 세션이 무효화될 수 있었다. - Cloudflare는 OAuth 트래픽을 라우팅하는 Worker에 리프레시 토큰 요청 병합(coalescing)을 추가했다. - 동일 요청의 짧은 재시도를 잠시 캐시했다. - 재시도를 감지하면 Hydra에 다시 전달하지 않고 기존 요청 결과를 반환했다. - Hydra 2.X에서는 리프레시 토큰을 일정 시간 동안 재사용해도 전체 체인을 무효화하지 않는 `refresh token grace period` 설정을 제공해 이 문제를 근본적으로 완화할 수 있었다. ## 실용적인 결론 대규모 OAuth 시스템을 개방하려면 클라이언트 등록 기능만 추가해서는 부족하다. 명확한 동의 화면, 즉각적인 권한 철회, 앱 소유자 표시 같은 보안 기능과 함께, 스키마 마이그레이션 중에도 철회 이벤트를 보존하는 큐, 토큰 만료 조정, 토큰 갱신 재시도 제어 같은 운영 설계가 함께 필요하다.

원문 읽기(새 탭에서 열림)

Cloudflare Workersoauthwranglerdatabase-migrations+3

cloudflare·2026년 6월 22일·3분 읽기큐레이션 요약

hyper HTTP 라이브러리에서 버그를 발견한 방법

Cloudflare의 Images binding을 로컬 Unix 소켓 기반 구조로 개편한 뒤, 대용량 이미지 응답이 간헐적으로 잘리는 버그가 발생했다. 응답은 HTTP 200과 정상적인 `Content-Length`를 반환했지만 실제 본문은 수백 KB만 전달되어 이미지가 부분적으로 렌더링되거나 디코딩에 실패했다. 원인은 특정 조건에서 발생하는 hyper 라이브러리의 레이스 컨디션이었으며, 최종적으로 네 줄의 코드 수정으로 해결됐다. ### Images binding과 hyper의 데이터 흐름 - Workers는 바인딩을 통해 Images 서비스에 이미지 데이터를 직접 전달하고, 변환 결과를 스트림으로 받을 수 있다. - 이미지 변환 과정은 다음과 같이 진행된다. - Workers 런타임이 소켓을 통해 Images 서비스에 요청을 보낸다. - Images 서비스가 이미지를 합성·리사이즈·트랜스코딩한다. - 변환된 전체 이미지를 메모리 블록으로 hyper에 전달한다. - hyper가 데이터를 내부 버퍼에 저장한 뒤 소켓의 송신 버퍼로 기록한다. - 소켓의 양 끝에는 커널이 관리하는 버퍼가 있다. - 수신자가 충분히 빠르면 hyper가 한 번에 모든 데이터를 보내고 소켓을 종료할 수 있다. - 수신자가 조금이라도 느리면 송신 버퍼가 가득 차고, hyper는 공간이 생길 때까지 추가 쓰기를 기다려야 한다. ### 네트워크 중계에서 로컬 Unix 소켓으로 전환 - 초기 Images binding은 Workers 런타임과 Images 사이에서 FL이라는 내부 중계 서비스를 거쳤다. - FL은 DNS 조회와 라우팅 등 전체 네트워크 처리 파이프라인을 수행했기 때문에 오버헤드가 있었다. - 2025년 12월, Cloudflare는 FL을 같은 머신에서 실행되는 내부 Worker binding으로 교체했다. - 새 구조는 네트워크 소켓 대신 Unix 소켓으로 서비스를 직접 연결했다. - 이 변경으로 다음 효과를 기대했다. - 네트워크 스택과 FL 처리 과정 제거 - Images 요청 경로 단축 - Images 팀이 독립적으로 binding을 배포하고 변경 가능 - 그러나 출시 며칠 뒤부터 대용량 이미지 응답 실패 제보가 접수됐다. ### HTTP 200이지만 잘린 응답 - 고객 사례는 두 단계의 이미지 처리 파이프라인을 중첩한 비표준 구성이었다. - 내부 파이프라인: R2의 JPEG와 PNG를 합성해 JPEG 생성 - 외부 파이프라인: 결과 이미지를 다시 압축·변환·리사이즈 - 실제 문제는 내부 transformation binding의 반환 경로에서 발생했다. - 외부 파이프라인은 내부 응답에서 다음과 같은 모순을 받았다. - 상태 코드는 `200 OK` - `Content-Length`는 수 MB로 설정 - 실제 수신 본문은 일부 데이터에 불과함 - 한 사례에서는 예상 크기 3.3MB 중 약 200KB만 전달됐다. - 상위 계층에서는 다음 오류가 발생했지만, 실제 원인이 어느 서비스에 있는지는 즉시 알기 어려웠다. ```text error reading a body from connection: end of file before message length reached ``` - 브라우저에서는 이미지 형식에 따라 일부만 표시되거나, 하단이 회색으로 남거나, 아예 깨진 이미지로 표시됐다. ### 재현과 원인 범위 좁히기 - 개발팀은 고객의 중첩 파이프라인을 재현하는 Worker를 만들었다. - 이후 외부 파이프라인과 여러 계층을 하나씩 제거해 binding 단독으로도 문제를 재현할 수 있음을 확인했다. - 배치 요청을 보내는 간단한 스크립트로 재현을 자동화했다. - 초기 실행에서는 25건 중 19건이 실패했다. - 매번 도착한 데이터가 약 200KB였는데, 이는 운영 환경의 소켓 버퍼 크기와 매우 유사했다. - 이를 통해 문제는 고객 설정이 아니라 소켓 버퍼가 가득 찬 뒤 hyper가 응답 전송과 연결 종료를 처리하는 방식과 관련 있음을 추정할 수 있었다. - 최종 원인은 특정 타이밍에서 발생하는 hyper 내부의 레이스 컨디션으로 밝혀졌고, 수정에는 네 줄의 코드만 필요했다. ### 실용적인 결론 소켓 기반 스트리밍에서는 `200 OK`나 올바른 `Content-Length`만으로 전송 성공을 판단할 수 없다. 특히 송신 버퍼가 가득 차는 상황, 느린 수신자, 데이터 기록과 연결 종료가 동시에 일어나는 경로를 반드시 테스트해야 하며, 대용량·중첩 파이프라인을 포함한 재현 테스트가 간헐적인 네트워크 버그를 찾는 데 결정적이다.

원문 읽기(새 탭에서 열림)

Cloudflare WorkersRusthttprace-condition+2

cloudflare·2026년 6월 19일·3분 읽기큐레이션 요약

AI 에이전트를 위한 임시 Cloudflare 계정

Cloudflare는 AI 에이전트가 사람의 개입 없이 코드를 배포할 수 있도록 ‘임시 계정’을 출시했다. 에이전트는 `wrangler deploy --temporary`를 실행해 별도 회원가입이나 OAuth, API 토큰 입력 없이 Worker를 배포하고, 60분 동안 결과를 테스트할 수 있다. 사용자가 그 안에 계정을 클레임하면 영구 계정이 되며, 클레임하지 않으면 자동 삭제된다. ## AI 에이전트 배포에서 인증이 걸림돌이 되는 이유 - 기존 클라우드 서비스 가입 과정은 브라우저 OAuth, 대시보드 조작, API 토큰 복사, MFA 입력 등 사람을 전제로 한다. - 백그라운드에서 실행되는 AI 에이전트는 브라우저를 열거나 사용자의 즉각적인 확인을 기다리기 어렵다. - 인증 단계에서 멈추면 에이전트가 다른 배포 서비스를 선택할 가능성도 있다. - 에이전트는 코드를 작성하고 배포한 뒤 직접 요청을 보내 검증하는 반복 작업이 중요하므로, 빠르고 저렴한 임시 배포 환경이 필요하다. ## `wrangler deploy --temporary`를 통한 배포 - 최신 Wrangler CLI에서 다음 명령으로 임시 계정에 Worker를 배포할 수 있다. ```bash wrangler deploy --temporary ``` - 사용자가 Cloudflare에 로그인하지 않은 상태에서 배포를 시도하면 Wrangler가 `--temporary` 옵션을 안내한다. - 에이전트가 해당 옵션으로 다시 배포하면 Cloudflare가 자동으로: - 임시 Cloudflare 계정을 생성하고 - Wrangler가 사용할 API 토큰을 발급하며 - 사용자가 계정을 인수할 수 있는 클레임 URL을 제공한다. - 에이전트는 별도의 사람 확인 없이 코드를 작성하고 즉시 배포할 수 있다. ## 작성·배포·검증의 반복 루프 - 에이전트는 TypeScript Worker를 생성한 뒤 배포 결과로 받은 미리보기 URL에 `curl` 등을 실행해 동작을 검증한다. - 예를 들어 “hello world” Worker를 배포한 뒤 응답이 코드와 일치하는지 확인할 수 있다. - 이후 소스 코드를 수정하고 같은 임시 계정을 재사용해 여러 번 재배포할 수 있다. - 임시 계정은 60분의 클레임 기간 동안 유지되므로, 에이전트가 여러 차례 수정·테스트하는 데 적합하다. ## 임시 계정의 클레임과 자동 삭제 - 사용자는 에이전트가 제공한 클레임 링크를 클릭해 Cloudflare에 가입하거나 로그인할 수 있다. - 계정을 클레임하면 임시 계정이 영구적으로 사용자의 계정이 된다. - Worker뿐 아니라 데이터베이스와 기타 바인딩 리소스도 함께 인수할 수 있다. - 60분 이내에 클레임하지 않으면 임시 계정과 배포된 리소스가 자동으로 삭제된다. ## 더 넓은 에이전트용 인프라 - Cloudflare는 Stripe와 협력해 에이전트가 사용자를 대신해 계정 생성, 구독 시작, 도메인 등록, API 토큰 발급까지 수행할 수 있는 프로토콜도 개발하고 있다. - WorkOS와는 기존 OAuth 표준을 활용해 에이전트가 계정을 생성할 수 있도록 하는 `auth.md` 프로젝트를 추진했다. - 임시 계정은 이러한 ‘에이전트 친화적 배포’ 전략의 한 단계로 소개된다. - 기능과 제한 사항은 변경될 수 있으므로 실제 사용 전 Cloudflare 개발자 문서를 확인해야 한다. 에이전트가 짧은 실험이나 프로토타입을 자동으로 배포·검증해야 한다면 `wrangler deploy --temporary`가 유용하다. 다만 60분 내에 클레임하지 않으면 리소스가 삭제되므로, 장기 운영 서비스는 반드시 계정을 클레임하고 정식 인증·관리 체계로 전환해야 한다.

원문 읽기(새 탭에서 열림)

Cloudflare WorkersAI 에이전트TypeScriptstripe+4

cloudflare·2026년 6월 10일·4분 읽기큐레이션 요약

Cloudflare로 퍼블릭 트래픽을 프라이빗 애플리케이션으로 라우팅하기

Cloudflare는 이제 퍼블릭 IP를 노출하지 않고도 인터넷 트래픽을 사설 애플리케이션으로 전달하는 **Application Services for Private Origins**를 제공한다. 이를 통해 사설 네트워크의 내부 API, AI 에이전트 백엔드, MCP 서버, 운영 도구에도 WAF, 봇 관리, 레이트 리미팅, 캐싱, Workers 같은 Cloudflare 기능을 적용할 수 있다. 핵심은 기존 Cloudflare Tunnel, WAN, Mesh 등의 사설 연결 경로를 애플리케이션 프록시 계층과 통합해, 마지막 구간만 사설 네트워크로 전송하는 것이다. ### 퍼블릭 애플리케이션과 프라이빗 애플리케이션의 경계 - 기존에는 퍼블릭 애플리케이션이 CDN·WAF 뒤에, 프라이빗 애플리케이션이 VPN·방화벽·별도 네트워크 스택 뒤에 위치했다. - 내부 API, AI 백엔드, MCP 서버처럼 인터넷에 직접 공개할 필요는 없지만 보안·성능 제어가 필요한 서비스가 늘고 있다. - 기존 방식은 퍼블릭 IP, 방화벽 예외, 커넥터 소프트웨어, 복잡한 네트워크 구성을 요구했다. - 그 결과 프라이빗 애플리케이션은 WAF, 봇 관리, 속도 제한, 캐시, 트래픽 가속, URL 변환, Workers 등의 기능을 활용하기 어려웠다. ### Application Services for Private Origins - 적격 Enterprise 고객을 대상으로 클로즈드 베타로 제공된다. - 사설 오리진을 인터넷에 노출하지 않고도 Cloudflare를 통해 퍼블릭 트래픽을 전달한다. - 다음 기능을 프라이빗 오리진 앞에서 사용할 수 있다. - WAF - 봇 관리 - 레이트 리미팅 - 캐싱 - URL·요청 변환 - Workers - 오리진에 퍼블릭 IP, 인바운드 방화벽 규칙, `cloudflared` 실행을 반드시 요구하지 않는다. ### 하나로 통합되는 사설 네트워크 연결 - 기존 Cloudflare Tunnel, Cloudflare One Client, Cloudflare WAN, Cloudflare Mesh 등의 연결 모델을 활용한다. - Cloudflare의 사설 네트워크 라우팅 계층이 다음 경로를 통합적으로 관리한다. - Cloudflare Tunnel - IPsec·GRE 터널 - CNI 연결 - Cloudflare Mesh - 기타 사설 연결 방식 - 고객은 제품별로 별도 네트워크 스택을 운영하는 대신 API나 대시보드에서 라우팅을 정의할 수 있다. - Workers VPC 바인딩과 Spectrum의 프라이빗 오리진 라우팅도 같은 사설 연결 계층을 사용하게 된다. ### 네 가지 트래픽 조합 Cloudflare는 사용자 위치와 애플리케이션 위치에 따라 트래픽을 네 가지 조합으로 구분한다. - 인터넷 사용자 → 인터넷 애플리케이션: 기존 Cloudflare 프록시 모델 - 프라이빗 네트워크 사용자 → 인터넷 서비스: Cloudflare One 모델 - 인터넷 사용자 → 프라이빗 애플리케이션: 이번에 제공하는 기능 - 프라이빗 네트워크 사용자 → 프라이빗 애플리케이션: 향후 구축 대상 ### DNS 레코드로 활성화하는 프라이빗 라우팅 - 프록시된 A 또는 AAAA 레코드에서 `Use private network routing` 옵션을 활성화한다. - Cloudflare의 WAF, 캐싱, 봇 관리, 레이트 리미팅, Transform Rules는 기존처럼 Cloudflare 네트워크에서 실행된다. - 차이는 오리진으로 향하는 최종 연결만 퍼블릭 인터넷이 아닌 사설 네트워크를 이용한다는 점이다. - 다음 주소 범위는 사설 주소이므로 옵션이 자동 활성화된다. - RFC 1918: `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` - RFC 6598 CGNAT: `100.64.0.0/10` - RFC 4193 IPv6 ULA: `FC00::/7` - 퍼블릭 IP라도 사설 터널을 통해서만 접근할 수 있다면 옵션을 수동으로 활성화할 수 있다. ### API 설정 방식 프라이빗 라우팅은 일반 DNS 레코드에 `use_private_routing` 속성을 추가하는 방식이다. ```json { "type": "A", "name": "app.example.com", "content": "10.0.0.50", "ttl": 300, "proxied": true, "use_private_routing": true } ``` - Cloudflare 프록시는 Origin API에서 오리진 주소와 라우팅 메타데이터를 조회한다. - `use_private_routing: true`가 있으면 프라이빗 IP로 인터넷 연결을 시도하지 않는다. - 대신 IPsec, GRE, Tunnel, CNI, Mesh 등 고객의 기존 연결을 통해 사설 네트워크 라우팅 계층으로 요청을 전달한다. ### HTTP 이외의 서비스 지원 - 이 모델은 웹 애플리케이션뿐 아니라 다양한 프로토콜과 서비스에도 적용된다. - Spectrum을 이용하면 TCP·UDP 기반 서비스도 프라이빗 오리진 뒤에 둘 수 있다. - 데이터베이스 - UDP 로그 수집 엔드포인트 - 기타 비HTTP 서비스 - Workers가 프라이빗 API나 데이터베이스를 직접 호출하는 구성에도 사용할 수 있다. - 공통적으로 Cloudflare가 사용자 트래픽과 사설 네트워크 사이에 위치해 보안, 성능, 라우팅을 통합 제공한다. ### 실용적인 결론 퍼블릭 트래픽을 받아야 하지만 오리진을 인터넷에 공개하고 싶지 않은 조직이라면, 기존 Cloudflare WAN·Tunnel·Mesh 연결을 유지한 채 DNS 레코드의 `use_private_routing`을 활성화하는 방식이 가장 단순하다. 이를 통해 별도의 퍼블릭 로드 밸런서, 역방향 프록시, 다중 TLS 종료 계층을 줄이고 사설 애플리케이션에도 Cloudflare의 보안·성능 기능을 일관되게 적용할 수 있다.

원문 읽기(새 탭에서 열림)

Cloudflare Workerscloudflare제로 트러스트web-application-firewall+3

cloudflare·2026년 6월 4일·4분 읽기큐레이션 요약

VoidZero가 Cloudflare에 합류합니다

VoidZero가 Cloudflare에 합류하지만 Vite, Vitest, Rolldown, Oxc, Vite+는 계속 MIT 라이선스의 오픈소스이자 벤더 중립적·커뮤니티 주도 프로젝트로 유지됩니다. Cloudflare는 프로젝트의 방향을 통제하기보다 개발 인력과 자원을 추가하고, Vite 생태계 기금에 100만 달러를 투자해 기반 도구와 기여자들을 지원할 계획입니다. 이번 합류는 Vite를 Cloudflare 전용 도구가 아니라 JavaScript 생태계 전체를 위한 공통 기반으로 더욱 확장하려는 움직임입니다. ## VoidZero의 Cloudflare 합류 - Vite, Vitest, Rolldown, Oxc, Vite+를 만든 VoidZero의 전 구성원이 Cloudflare에 합류합니다. - 해당 프로젝트들은 계속해서: - MIT 라이선스를 유지합니다. - 특정 클라우드나 호스팅 업체에 종속되지 않습니다. - 어디서나 실행할 수 있습니다. - 로드맵과 개발 과정을 공개적으로 운영합니다. - Evan You를 비롯한 기존 VoidZero 팀이 프로젝트 리드를 계속 맡습니다. - Cloudflare는 프로젝트를 자사 제품으로 전환하는 대신 엔지니어링 인력과 개발 자원을 투입합니다. ## Vite 생태계에 대한 투자 - Vite는 Vue, SvelteKit, Nuxt, Astro, Solid, Qwik, Angular, React Router, TanStack Start 등 다양한 프레임워크의 기반으로 자리 잡았습니다. - Next.js 역시 `vinext`를 통해 Vite 기반 구현을 제공하기 시작했습니다. - 따라서 Vite는 단일 프레임워크가 아니라 JavaScript 생태계 전반의 공유 기반으로 평가됩니다. - Cloudflare는 Vite의 핵심 채택 요인인 개방성, 이식성, 벤더 중립성에 대한 신뢰를 유지하는 것을 최우선 목표로 제시했습니다. - Vite 코어 팀이 관리하는 생태계 기금에 100만 달러를 출연해 유지보수자와 기여자를 지원합니다. - 앞서 Cloudflare에 합류한 Astro 역시 오픈소스와 멀티 플랫폼 배포를 유지하고 있다는 점을 선례로 들었습니다. ## Vite Environment API와 Cloudflare 연동 - Vite와 Cloudflare는 2024년부터 Vite Environment API를 함께 개발해 왔습니다. - Environment API를 사용하면 개발 중 서버 코드를 Node.js가 아닌 다른 런타임에서 실행할 수 있습니다. - Cloudflare Vite 플러그인을 사용하면 `vite dev` 실행 시 서버 코드가 프로덕션 Workers와 동일한 오픈소스 런타임인 `workerd` 안에서 동작합니다. - 로컬 개발 환경에서 다음 Cloudflare 기능을 프로덕션과 유사한 런타임 모델로 사용할 수 있습니다. - Durable Objects - D1, KV, R2 - Workflows - Workers AI - Agents - Service Bindings - Workers RPC - 특정 업체 전용 개발 서버를 강제하지 않고, Vite에 범용 확장 지점을 제공한 뒤 각 런타임이 구현하도록 설계한 점이 핵심입니다. - 이 구조를 통해 비-Node.js 런타임에서도 로컬 개발 경험이 프로덕션보다 크게 뒤처지는 문제를 줄일 수 있습니다. ## 급증하는 Vite와 Cloudflare 플러그인 사용량 - 글 작성 시점 기준 Vite는 주간 약 1억 2,900만 회 다운로드를 기록했습니다. - `@cloudflare/vite-plugin`도 주간 약 1,400만 회 다운로드에 도달했습니다. - 이는 Cloudflare 플러그인이 Vite 전체 다운로드의 10% 이상에 해당하는 규모입니다. - AI로 생성되는 소프트웨어가 급증하면서 애플리케이션을 빠르게 만들고 실행할 수 있는 기본 스택에 대한 수요도 커졌습니다. - AI가 작성한 애플리케이션이 Vite를 선택하고, 그중 일부가 Cloudflare에서 실행되면서 플러그인 사용량이 증가한 것으로 설명합니다. ## AI 에이전트 중심의 개발 루프 - 개발 서버, 번들러, 린터, 포매터, CLI는 더 이상 사람만 사용하는 도구가 아닙니다. - AI 에이전트도 다음 작업을 반복적으로 수행합니다. - 프로젝트 스캐폴딩 - 개발 서버 실행 - 오류 분석 - 테스트 작성 및 실행 - 린트와 포맷 적용 - 프리뷰 배포 - 결과 확인 후 재수정 - 에이전트 개발에서는 다음 특성이 특히 중요합니다. - 반복 횟수가 많으므로 빠른 빌드 - 지속적인 검증을 위한 빠른 테스트 - 코드 품질을 보장하는 빠른 린팅·포매팅 - 에이전트가 해석하고 조치하기 쉬운 구조화된 오류 - 불필요한 우회를 줄이는 일관된 CLI - Vitest, Rolldown, Oxc, Oxlint, Oxfmt는 각각 빠른 도구로 설계되었으며, 반복 실행이 많은 에이전트 작업에 적합합니다. - Vite+는 이 도구들을 하나의 CLI와 설정 모델로 통합해 사람과 에이전트 모두가 더 예측 가능하게 사용할 수 있도록 합니다. ## Cloudflare 내부에서의 실제 적용 - Cloudflare 대시보드는 Vite를 기반으로 구축되고 있습니다. - Cloudflare 코드베이스에서는 Oxlint가 엔지니어링 시간을 절약하는 데 사용되고 있습니다. - Astro 팀의 에이전트 하네스 프레임워크인 Flue도 Vite를 기반으로 전환 중입니다. - Flue는 Node.js, Cloudflare Workers, GitHub Actions, GitLab CI/CD 등 여러 환경에서 에이전트를 실행할 수 있습니다. - Cloudflare 대상 환경에서는 공식 Cloudflare Vite 플러그인과 `workerd` 통합을 사용합니다. - 결과적으로 Vite는 외부 생태계뿐 아니라 Cloudflare 내부 애플리케이션 개발의 기본 기반으로도 자리 잡고 있습니다. ## 실용적인 결론 이번 변화는 Vite 사용자가 Cloudflare를 선택해야 한다는 의미가 아니라, Vite를 계속 어느 환경에서나 사용할 수 있도록 지원이 강화된다는 의미에 가깝습니다. 기존 Vite 프로젝트는 플랫폼 종속성 없이 유지할 수 있고, Cloudflare Workers 기능이 필요하다면 공식 Vite 플러그인과 `workerd` 기반 로컬 개발 환경을 선택적으로 활용할 수 있습니다.

원문 읽기(새 탭에서 열림)

Cloudflare Workerscloudflare오픈 소스JavaScript+4

cloudflare·2026년 5월 19일·4분 읽기큐레이션 요약

Cloudflare에서 Claude Managed Agents 발표

Cloudflare와 Anthropic은 Claude Managed Agents의 에이전트 루프는 Anthropic에서 실행하고, 코드 실행·샌드박스·네트워크 연결은 Cloudflare에서 처리하는 통합 환경을 공개했습니다. 이를 통해 보안 프록시, 프라이빗 서비스 연결, 샌드박스 관측성, 브라우저 제어, 이메일, 사용자 정의 도구를 기본 제공하면서도 인프라를 직접 통제할 수 있습니다. 특히 작업 특성에 따라 전체 Linux microVM과 가벼운 V8 isolate를 선택해 비용과 확장성을 조절할 수 있다는 점이 핵심입니다. ## Claude Managed Agents의 구조 - Claude Managed Agents는 Anthropic 플랫폼에서 에이전트를 정의하고 실행하는 관리형 환경입니다. - 에이전트는 파일 읽기, 명령 실행, 웹 브라우징, 코드 실행 등을 수행할 수 있습니다. - 프롬프트 캐싱, 대화 압축(compaction), 에이전트 실행 최적화 기능이 내장되어 있습니다. - 기존에는 에이전트 루프와 실행 인프라를 모두 Anthropic 환경에서 운영했지만, 이제 실행 환경을 Cloudflare 등 외부 인프라로 분리할 수 있습니다. - Anthropic이 이를 “두뇌와 손의 분리”라고 설명하듯이: - **두뇌**: Claude의 에이전트 루프 - **손**: 코드 실행, 파일 시스템, 명령 도구, 네트워크 연결을 담당하는 Cloudflare 환경 ## Cloudflare 기반 실행 환경 - Claude Agent가 세션을 시작하면 Cloudflare Workers 기반 컨트롤 플레인에 메시지를 보냅니다. - 컨트롤 플레인은 각 세션에 샌드박스를 할당해 다음 작업을 지원합니다. - 코드 실행 - 애플리케이션 개발 - CLI 도구 실행 - 파일 생성 및 수정 - 세션이 일시 중지되어도 상태가 자동으로 보존됩니다. - VM 기반 샌드박스는 다음과 같이 설정할 수 있습니다. - 인스턴스 크기 조정 - 실행 컨테이너 이미지 사용자 정의 - Cloudflare 대시보드에서 샌드박스 상태를 확인하고 로그를 조회할 수 있습니다. - 로그는 Datadog이나 Splunk 같은 외부 관측성 플랫폼으로 전송할 수 있습니다. - 기본 UI를 통해 실행 중인 샌드박스에 SSH로 접속하고 대화형 셸 세션을 사용할 수 있습니다. ## 기본 제공되는 통합 기능 - **보안 프록시** - 에이전트의 모든 외부 트래픽을 사용자 정의 프록시로 통과시킬 수 있습니다. - 샌드박스 외부에서 인증 정보를 주입해 에이전트가 비밀값을 직접 보지 못하게 할 수 있습니다. - 데이터 유출을 차단하고 외부 서비스와의 상호작용을 관찰할 수 있습니다. - **샌드박스 제어와 관측성** - 상세한 메트릭과 로그를 제공합니다. - 실행 중인 머신에 SSH로 접근할 수 있습니다. - 샌드박스 이미지를 직접 구성할 수 있습니다. - **프라이빗 서비스 연결** - 인터넷에 서비스를 공개하지 않고 내부 API나 데이터베이스에 연결할 수 있습니다. - **브라우저 제어** - 에이전트의 브라우저 세션을 기록하고 감사 추적을 남길 수 있습니다. - 세션 녹화와 human-in-the-loop 승인 흐름을 지원합니다. - **이메일** - 에이전트별 이메일 주소를 부여하고 이메일을 발송할 수 있습니다. - **사용자 정의 도구** - 별도의 인프라 없이 함수를 작성하고 배포해 에이전트 기능을 확장할 수 있습니다. ## microVM과 isolate를 통한 확장성 - 모든 에이전트에 전용 microVM을 할당하면 대규모 동시 실행에서 비용과 자원 낭비가 커질 수 있습니다. - Cloudflare는 두 가지 샌드박스 방식을 제공합니다. - **microVM 기반 샌드박스** - 완전한 Linux 환경을 제공합니다. - 애플리케이션 개발, Linux 기반 도구, 복잡한 코드 실행에 적합합니다. - Cloudflare Containers를 사용할 수 있습니다. - **V8 isolate 기반 샌드박스** - Dynamic Workers와 Codemode를 이용해 임의의 코드를 실행합니다. - 파일 시스템을 제공하면서도 전체 VM보다 가볍습니다. - 수 밀리초 단위로 부팅할 수 있어 비용과 시작 시간이 줄어듭니다. - 에이전트 설정에서 백엔드 유형으로 `isolate`를 선택하면 V8 isolate를 사용할 수 있습니다. - 수만 개 이상의 동시 에이전트가 필요한 경우 isolate 방식이 VM 기반보다 훨씬 높은 확장성을 제공할 수 있습니다. - 반대로 완전한 Linux 환경이나 강한 격리가 필요하면 microVM을 선택하는 것이 적합합니다. ## 보안과 네트워크 제어 - 에이전트가 조직 내부의 데이터와 서비스에 접근할수록 유용성은 높아지지만 보안 위험도 커집니다. - Cloudflare 샌드박스는 아웃바운드 프록시를 통해 외부 서비스와의 통신을 제어할 수 있습니다. - 프록시에서 동적으로 인증하고 비밀값을 요청에 삽입하면, 샌드박스와 에이전트가 실제 자격 증명을 직접 보유하지 않아도 됩니다. - 이를 통해 샌드박스와 외부 서비스 사이에 동적이고 사용자 정의 가능한 zero-trust 인증 구조를 구성할 수 있습니다. - 제공된 글은 이 보안 섹션이 “데이터 유출 방지” 설명 도중 중단되어 있어, 세부 구현이나 설정 방법까지는 확인할 수 없습니다. ## 실용적인 선택 기준 - 단순한 코드 실행과 대규모 동시성이 중요하면 **V8 isolate**를 우선 고려하는 것이 좋습니다. - Linux 도구, 애플리케이션 빌드, 장시간 실행되는 개발 작업이 필요하면 **microVM 또는 Containers**가 적합합니다. - 내부 시스템에 연결할 때는 프록시 기반 인증과 프라이빗 연결을 사용해 비밀값과 서비스를 샌드박스에 직접 노출하지 않는 구성이 권장됩니다. - 운영 환경에서는 Cloudflare 대시보드, 로그 외부 전송, 브라우저 세션 기록을 함께 활용해 에이전트 행동을 지속적으로 감사하는 것이 중요합니다.

원문 읽기(새 탭에서 열림)

Cloudflare Workerszero-trust-securitycloudflare-sandboxesagent-sdk+3

cloudflare·2026년 5월 13일·4분 읽기큐레이션 요약

Browser Run: 이제 Cloudflare Containers에서 실행되어 더 빠르고 확장성이 뛰어납니다

Browser Run은 Cloudflare Containers 기반으로 재구축되면서 더 높은 처리량, 낮은 지연 시간, 향상된 안정성을 확보했다. 분당 브라우저 생성 한도는 60개, 동시 실행 수는 120개로 늘어 기존보다 4배 향상됐고, Quick Action 응답 시간은 50% 이상 단축됐다. 이 성능 개선의 핵심은 지역별 사전 준비 컨테이너 풀, D1의 트랜잭션 기반 상태 관리, Queues를 활용한 배치 쓰기다. ## Browser Run의 역할 - Cloudflare의 글로벌 네트워크에서 실행되는 헤드리스 브라우저를 프로그래밍 방식으로 제어한다. - 주요 활용 사례: - 웹 애플리케이션의 엔드투엔드 테스트 - 의심스러운 URL의 안전한 조사 - PDF 렌더링 - 스크린샷 캡처와 콘텐츠 추출 - AI 에이전트의 웹 브라우징 - 목표는 자동화 브라우저를 안전하고 대규모로 활용할 수 있는 플랫폼이 되는 것이다. ## 기존 Browser Isolation 인프라의 한계 - 이전에는 Browser Run과 Browser Isolation(BISO)이 인프라를 공유했다. - BISO의 큰 컨테이너 이미지는 브라우저 시작 시간과 개발 속도를 저하시켰다. - BISO 브라우저의 글로벌 분산이 충분하지 않아 지연 시간과 복원력에도 문제가 있었다. - BISO의 장시간·지속적 세션과 Browser Run의 짧고 급격한 트래픽 패턴이 서로 맞지 않아 확장 병목이 발생했다. ## 점진적인 Containers 마이그레이션 - 요청 경로에 Worker를 추가해 일부 사용자에게만 Container 기반 브라우저를 제공하며 마이그레이션을 시작했다. - 기존 BISO 브라우저와 병행 운영하면서 성능을 비교하고 구현 오류를 검증했다. - 적용 순서는 다음과 같았다. - Quick Actions 엔드포인트 - 무료 계정의 Workers 브라우저 바인딩 - 종량제 계정 - 나머지 계약 고객 - 고객이 별도 설정을 변경하거나 Worker를 재배포하지 않아도 전환되도록 했다. ## 지역별 사전 준비 컨테이너 풀 - Durable Object(DO)는 요청에 가까운 위치에 생성될 수 있지만, 연결되는 Container는 지구 반대편에 배치될 수 있다. - 단일 메시지에서는 문제가 작지만, 스크린샷 요청처럼 WebSocket으로 수십 개 메시지를 주고받는 작업에서는 왕복 지연이 누적된다. - 이를 해결하기 위해: - 지역별로 DO 기반 브라우저 컨테이너를 미리 실행해 둔다. - 요청이 들어오면 해당 지역에서 사용자와 가장 가까운 DO-Container 쌍을 선택한다. - 사용자-DO, DO-Container 양쪽의 네트워크 거리를 줄인다. - 브라우저별 글로벌 상태를 관찰하고 수요에 따라 용량을 재배치해야 하므로 추가적인 아키텍처 복잡성이 생겼다. ## Workers KV의 일관성 문제 - 초기에는 각 컨테이너 상태를 Workers KV에 저장했다. - KV는 최종적 일관성을 사용하며, 캐시 TTL 때문에 최대 약 30초 또는 그 이상 오래된 상태를 읽을 수 있었다. - “사용 가능”으로 읽은 컨테이너가 실제 라우팅 시점에는 이미 다른 요청에 할당되는 경쟁 조건이 발생했다. - 이로 인해: - 동일 브라우저의 중복 할당 - 과도한 브라우저 예약 - 급격한 수요 증가에 대한 확장 지연 문제가 생겼다. ## D1을 이용한 원자적 브라우저 할당 - 컨테이너 상태를 KV에서 D1 데이터베이스로 이전했다. - D1은 SQLite 기반 트랜잭션을 제공하므로 브라우저 할당을 원자적으로 처리할 수 있다. - 브라우저는 사용자 간 공유 자원이 아니므로, 한 번 할당되면 독점적으로 사용되어야 한다. - 후보 컨테이너를 선택하고 상태를 `picked`로 변경하는 작업을 하나의 트랜잭션으로 수행해 동시에 두 요청이 같은 브라우저를 차지하는 문제를 방지한다. - 지역별로 D1 샤드를 구성해 위치 기반 컨테이너 관리도 유지했다. ## Queues를 활용한 상태 업데이트 배치 처리 - 수천 개 컨테이너가 5초마다 상태를 갱신하면 데이터베이스 쓰기 부하가 커진다. - 개별 쓰기만 사용하면 초당 약 1,000회 쓰기라는 한계로 인해 지역당 약 5,000개 컨테이너 수준에서 병목이 발생할 수 있다. - 상태 업데이트를 Queues에 모은 뒤 100개 단위로 배치 처리했다. - 배치 쓰기는 개별 쓰기보다 처리 시간이 크게 늘지 않으므로 처리량을 크게 높일 수 있다. - 100개 단위 배치 기준으로 지역당 최대 약 500,000개 컨테이너까지 업데이트할 수 있는 여유를 확보했다. - 각 컨테이너는 5초마다 자신의 상태를 지역별 큐에 기록한다. - 큐 소비자는 다음과 같이 설정했다. - 최대 배치 크기: 100개 - 최대 배치 대기 시간: 1초 - 최대 재시도 횟수: 1회 - 배치 쓰기의 현재 P95 지연 시간은 0.1ms다. ## 성능 개선 결과 - Workers 바인딩을 통한 브라우저 생성량: - 분당 최대 60개 - 동시 실행 브라우저: - 최대 120개 - 이전보다 4배 증가 - Quick Action 응답 시간: - 50% 이상 단축 - 개선 사항은 기존 고객의 코드 변경이나 Worker 재배포 없이 즉시 적용됐다. Cloudflare의 사례는 짧고 급격한 트래픽을 처리하는 시스템에서 최종적 일관성 저장소를 핵심 할당 경로에 사용할 때 발생할 수 있는 문제를 보여준다. 실시간 자원 예약에는 트랜잭션 기반 DB를 사용하고, 빈번한 상태 갱신은 큐와 배치 쓰기로 분리하는 설계가 효과적인 접근이다.

원문 읽기(새 탭에서 열림)

Cloudflare Workersdurable-objectssqlitewebsockets+4

cloudflare·2026년 5월 1일원문

동적 워크플로우 소개: 테넌트를 따르는 내구성 있는 실행 (새 탭에서 열림)

Cloudflare는 멀티테넌트 SaaS나 AI 에이전트처럼 런타임에 코드가 생성되는 환경을 지원하기 위해 'Dynamic Workflows'를 도입했습니다. 이는 기존의 정적 배포 방식에서 벗어나, 각 테넌트가 작성한 고유한 워크플로우 코드를 동적으로 로드하고 실행할 수 있게 해주는 내구성 있는 실행(Durable Execution) 솔루션입니다. 개발자는 이를 통해 개별 테넌트나 세션마다 서로 다른 비즈니스 로직을 가진 워크플로우를 격리된 샌드박스 환경에서 안전하고 신속하게 구동할 수 있습니다. ### 정적 워크플로우 배포의 한계 * 기존 Cloudflare Workflows는 `wrangler.jsonc` 설정 파일에 워크플로우 클래스를 미리 정의해야 하는 정적 바인딩 구조를 가졌습니다. * AI가 사용자별로 코드를 생성하거나, 각 저장소마다 고유한 파이프라인을 갖는 CI/CD 서비스와 같은 현대적인 플랫폼에서는 모든 테넌트의 로직을 미리 정의하는 것이 불가능합니다. * 컴퓨트(Dynamic Workers)와 스토리지(Durable Object Facets)는 이미 동적 배포가 가능해졌으나, 장기 실행이 필요한 워크플로우 영역은 여전히 테넌트별 맞춤화가 어려운 공백으로 남아 있었습니다. ### 동적 워크플로우의 구조와 작동 방식 * `@cloudflare/dynamic-workflows` 라이브러리는 약 300줄의 TypeScript 코드로 구성되며, 'Worker Loader'가 각 테넌트의 코드로 호출을 라우팅하는 역할을 수행합니다. * 워크플로우 엔진이 `run(event, step)` 함수를 호출할 때, 라이브러리는 수 시간 또는 수일 후에도 해당 워크플로우를 생성했던 정확한 테넌트의 코드를 찾아 실행을 재개합니다. * 테넌트는 표준 `WorkflowEntrypoint`를 사용하여 평범한 워크플로우 코드를 작성하며, 자신이 동적으로 관리되는 환경에 있다는 사실을 인지할 필요 없이 독립적인 실행 환경을 보장받습니다. ### 주요 기능 및 기술적 이점 * **기존 기능 완전 계승**: 워크플로우 상태 확인(`.status()`), 일시 중지(`.pause()`), 재시도, 동적 단계 실행, `step.sleep()`을 이용한 장기 대기, `step.waitForEvent()` 등의 모든 기능을 그대로 사용할 수 있습니다. * **고성능 격리 환경**: 싱글 디지트 밀리초(단위 수 밀리초) 내에 격리된 샌드박스 Worker가 생성되어 보안성과 속도를 동시에 확보합니다. * **확장성**: Workflows V2 아키텍처를 기반으로 설계되어, 계정당 초당 300개의 새로운 인스턴스 생성과 최대 50,000개의 동시 인스턴스 처리를 지원하여 에이전트 중심의 서비스 확장에 최적화되어 있습니다. AI 에이전트가 스스로 도구를 작성하고 실행하거나, 고객마다 고유한 비즈니스 자동화 로직을 부여해야 하는 SaaS 플랫폼을 구축 중이라면 Dynamic Workflows가 최적의 대안이 될 것입니다. 이 시스템을 통해 인프라 관리의 부담 없이 테넌트별로 특화된 내구성 있는 워크플로우를 무한히 확장할 수 있습니다.

Cloudflare Workers데이터베이스 설계CI/CDTypeScript+4

cloudflare·2026년 4월 17일원문

Flagship을 소개합니다: AI 시대를 위해 구축된 피처 플래그 (새 탭에서 열림)

Cloudflare가 발표한 'Flagship'은 AI가 코드를 직접 작성하고 배포하는 시대에 대응하기 위해 설계된 네이티브 피처 플래그(Feature Flag) 서비스입니다. 이 서비스는 배포와 출시를 분리함으로써 AI 에이전트가 안전하게 기능을 테스트하고 롤아웃할 수 있는 환경을 제공하며, Cloudflare의 에지(Edge) 인프라를 활용해 지연 시간 없는 성능을 보장합니다. 결과적으로 Flagship은 개발자와 AI가 속도와 안전성을 동시에 확보하며 프로덕션 환경에 기여할 수 있도록 돕는 핵심 인프라 역할을 합니다. ### AI 자율 코딩 시대의 안전장치 * AI 에이전트가 코드를 작성, 검토, 병합, 배포하는 자동화된 워크플로우에서 피처 플래그는 필수적인 '안전 그물' 역할을 수행합니다. * AI가 작성한 신규 코드를 플래그 뒤에 숨겨 배포한 뒤, 에이전트가 프로덕션 환경에서 직접 기능을 테스트하고 지표에 따라 노출 범위를 조절하거나 즉시 비활성화할 수 있습니다. * 이를 통해 인간의 개입을 줄이면서도 배포로 인한 장애의 영향 범위를 최소화(Blast Radius Control)할 수 있습니다. ### 기존 방식의 성능 및 관리 문제 * **하드코딩의 한계:** 코드 내에 플래그 로직을 직접 작성하면 초기에는 빠르지만, 플래그 개수가 늘어날수록 중앙 집중적인 가시성이 사라지고 감사 추적(Audit Trail)이 어려워집니다. * **외부 서비스 호출의 지연:** 외부 피처 플래그 서비스를 API로 호출할 경우, 에지에서 동작하는 애플리케이션의 응답 속도가 외부 네트워크 지연 시간에 종속되는 문제가 발생합니다. * **서버리스 환경의 제약:** 기존의 '로컬 평가' SDK는 메모리에 규칙을 상주시켜야 하지만, Cloudflare Workers와 같은 서버리스 환경은 프로세스가 짧게 유지되므로 매번 SDK를 초기화해야 하는 비효율이 있습니다. ### Flagship의 동작 원리 및 아키텍처 * **네이티브 인프라 활용:** 외부 데이터베이스 없이 Cloudflare의 Durable Objects와 KV(Key-Value)를 기반으로 구축되었습니다. * **데이터 동기화:** 플래그 설정 변경 시 Durable Object에 원자적으로 기록되며, 수 초 이내에 전 세계 Cloudflare 에지의 KV 스토리지로 복제됩니다. * **에지 로컬 평가:** 플래그 평가 로직이 사용자의 요청을 처리하는 동일한 에지 위치(Worker Isolate)에서 실행되므로 외부 네트워크 호출이 발생하지 않습니다. ### 구현 및 표준 준수 * **Worker 바인딩:** `wrangler.jsonc`에 설정을 추가하면 HTTP 라운드트립 없이 Workers 런타임 내부에서 직접 플래그 값을 읽어올 수 있습니다. * **OpenFeature 표준 지원:** CNCF의 오픈 표준인 OpenFeature를 준수하여 Node.js, Bun, Deno 및 브라우저 환경에서도 일관된 방식으로 사용할 수 있으며 벤더 종속성을 줄였습니다. * **타입 안정성:** Boolean, String, Number, Object 등 다양한 타입의 접근자를 제공하며, 평가 결과와 함께 선택 이유(Reason) 등의 상세 정보도 함께 확인할 수 있습니다. 현재 Flagship은 클로즈 베타로 제공되고 있으며, Cloudflare Workers 생태계를 사용하는 팀에게 네트워크 지연 없는 고성능 피처 플래그 솔루션으로서 강력한 선택지가 될 것으로 보입니다. 특히 AI 기반의 자동화된 배포 파이프라인을 구축하려는 조직이라면 Flagship의 에지 기반 평가 모델이 제공하는 속도와 안정성을 적극적으로 검토해 볼 가치가 있습니다.

Cloudflare Workers데이터베이스 설계sqliteedge-computing+4

cloudflare·2026년 4월 17일원문

기억하는 에이전트: 에이전트 메모리를 소개합니다 (새 탭에서 열림)

AI 에이전트가 방대한 컨텍스트 윈도우를 사용할 때 발생하는 정보 과부하와 품질 저하(Context Rot) 문제를 해결하기 위해, Cloudflare는 관리형 영구 기억 서비스인 'Agent Memory'를 출시했습니다. 이 서비스는 대화 내용에서 핵심 정보를 자동으로 추출하고 필요할 때만 검색하여 제공함으로써, 컨텍스트를 채우지 않고도 에이전트가 과거의 경험을 기억하고 시간이 지남에 따라 더 똑똑해지도록 돕습니다. 이를 통해 개발자는 긴 시간 동안 실행되는 복잡한 워크로드에서도 비용 효율적이고 고성능인 추론 환경을 구축할 수 있습니다. ### 기존 에이전트 메모리의 한계와 차별점 * **컨텍스트 부패(Context Rot) 해결**: 컨텍스트 윈도우가 100만 토큰 이상으로 커져도 정보를 모두 담으면 모델의 추론 품질이 떨어지고, 반대로 정보를 삭제하면 나중에 필요한 데이터를 잃게 되는 딜레마를 해결합니다. * **검색 기반 아키텍처**: 에이전트에게 파일 시스템에 대한 직접적인 접근 권한을 주는 대신, 최적화된 API를 통한 검색 기반 방식을 채택하여 보안과 성능을 높였습니다. * **복잡한 추론 지원**: 단순 저장을 넘어 시간 논리(temporal logic), 정보의 최신성 유지(supersession), 지시 사항 준수와 같은 운영 환경의 복잡한 요구사항을 처리할 수 있는 토대를 제공합니다. ### 주요 기능 및 API 동작 방식 * **프로필(Profile) 단위 관리**: 메모리는 '프로필'이라는 독립된 저장소에 이름별로 관리되며, 여러 세션이나 사용자, 에이전트 간에 공유될 수 있습니다. * **핵심 오퍼레이션**: * **Ingest**: 대화 이력을 분석하여 중요한 정보를 추출합니다. 보통 컨텍스트를 압축해야 하는 시점에 호출됩니다. * **Remember**: 에이전트가 도구 사용(Tool Use)을 통해 특정 사실을 즉시 명시적으로 저장합니다. * **Recall**: 전체 메모리 파이프라인을 실행하여 질문에 최적화된 합성된 답변(Synthesized answer)을 반환합니다. * **유연한 연결성**: Cloudflare Workers 내에서 직접 바인딩하여 사용하거나, REST API를 통해 외부 프레임워크(Claude Code, Anthropic Managed Agents 등)와 연동할 수 있습니다. ### 활용 가능한 에이전트 아키텍처 * **개별 및 자율 에이전트**: 코딩 에이전트나 백그라운드에서 실행되는 자율형 에이전트가 세션 재시작 후에도 이전 작업 내용을 기억하도록 구현할 수 있습니다. * **에이전트 간 지식 공유**: 팀 단위로 메모리 프로필을 공유하여, 한 엔지니어의 코딩 에이전트가 학습한 코딩 컨벤션이나 아키텍처 결정 사항을 팀 내 다른 에이전트와 도구가 즉시 활용하게 할 수 있습니다. * **비용 및 성능 최적화**: 모든 데이터를 컨텍스트에 넣는 대신 필요한 정보만 호출함으로써 추론당 비용을 낮추고 응답 속도를 향상시킵니다. Agent Memory는 단순한 데이터 저장을 넘어 에이전트가 장기적으로 학습하고 협업할 수 있는 기반을 제공합니다. 특히 긴 호흡의 프로젝트를 수행하거나 복잡한 운영 업무를 자동화하려는 개발자들에게 컨텍스트 관리 부담을 줄여주는 실용적인 해결책이 될 것입니다.

Cloudflare WorkersReactTypeScriptAPI 설계+3

cloudflare·2026년 4월 16일원문

아티팩트: Git 방식으로 작동하는 버전 관리 저장소 (새 탭에서 열림)

AI 에이전트가 생성하는 코드와 데이터의 양이 기하급수적으로 증가함에 따라, 기존의 소스 제어 플랫폼은 인간의 작업 속도를 상회하는 대규모 수요를 감당하기 어려워지고 있습니다. Cloudflare는 이러한 문제를 해결하기 위해 AI 에이전트 중심의 분산 버전 관리 파일 시스템인 'Artifacts'를 출시했습니다. Artifacts는 익숙한 Git 프로토콜을 기반으로 하면서도 API를 통해 수백만 개의 리포지토리를 프로그래밍 방식으로 즉시 생성하고 제어할 수 있는 새로운 저장소 프리미티브를 제공합니다. ### AI 에이전트에 최적화된 Git 인터페이스 * AI 모델들이 이미 학습 데이터로 익숙하게 습득한 Git 프로토콜을 그대로 사용하여, 별도의 CLI나 기술 전파 없이도 에이전트가 즉시 소스 제어를 수행할 수 있습니다. * 에이전트 세션마다 독립적인 리포지토리를 할당하거나, 특정 시점에서 수만 개의 포크(Fork)를 생성하여 병렬적으로 작업을 수행하는 것이 가능합니다. * 서버리스 환경과 같이 표준 Git 클라이언트를 사용하기 어려운 곳을 위해 REST API와 네이티브 Workers API를 별도로 제공하여 커밋과 자격 증명 관리를 단순화합니다. ### 단순 소스 제어를 넘어선 상태 관리 도구 * Git의 데이터 모델을 코드 저장뿐만 아니라 세션 프롬프트 히스토리, 샌드박스 상태, 사용자별 설정(Config) 등 시간 흐름에 따른 상태 추적이 필요한 모든 곳에 활용합니다. * Cloudflare 내부적으로는 에이전트 세션마다 Artifacts 리포지토리를 할당하여, 블록 스토리지 없이도 파일 시스템 상태를 영구 저장하고 특정 시점으로의 타임트래블(복구) 기능을 구현하고 있습니다. * 세션 자체를 포크(Fork)하여 동료와 공유하거나, 특정 실험 단계에서부터 다시 작업을 시작하는 등의 협업 워크플로우를 데이터 계층에서 지원합니다. ### Durable Objects와 Zig 기반의 고성능 아키텍처 * Cloudflare의 Durable Objects를 기반으로 설계되어 수천만 개의 독립적인 상태 저장 인스턴스를 확장성 있게 관리할 수 있습니다. * 런타임 효율성을 극대화하기 위해 Git 구현체를 Zig 언어로 작성한 뒤 WebAssembly(Wasm)로 컴파일하여 Cloudflare Workers 환경에서 가볍고 빠르게 동작하도록 구축했습니다. * 기존 외부 Git 저장소(예: GitHub)에서 데이터를 가져오는 `.import()` 기능과 읽기 전용 포크 생성 기능을 통해 복잡한 코드 베이스 위에서도 에이전트가 안전하게 독립적인 작업을 수행할 수 있도록 돕습니다. AI 에이전트가 주도하는 소프트웨어 개발 환경을 구축하고 있다면, Artifacts는 대규모 상태 관리와 버전 제어를 위한 가장 강력한 인프라가 될 것입니다. 현재 유료 Workers 플랜 사용자를 대상으로 프라이빗 베타를 진행 중이며, 5월 초 공개 베타 전환이 예정되어 있으므로 에이전트 세션 관리나 동적 환경 구축이 필요한 팀은 도입을 적극 검토해 보시기 바랍니다.

Cloudflare Workers데이터베이스 설계TypeScriptGit+4

cloudflare·2026년 4월 12일원문

에이전트 위크에 오신 것을 환영합니다 (새 탭에서 열림)

AI 에이전트의 시대가 도래함에 따라 기존의 컨테이너 기반 클라우드 인프라는 확장성과 비용 측면에서 한계에 직면하고 있습니다. 클라우드플레어는 일대다(1:N) 방식의 전통적인 아키텍처 대신, 개별 에이전트마다 독립적인 실행 환경을 즉시 제공할 수 있는 격리(Isolate) 기반의 서버리스 기술이 미래 인터넷의 핵심이 될 것이라고 주장합니다. 에이전트의 대중화를 위해서는 수 밀리초 안에 실행되고 자원 소모가 적은 가벼운 컴퓨팅 환경으로의 전환이 필수적이라는 결론입니다. **기존 클라우드 모델과 에이전트의 충돌** * 스마트폰 시대를 거치며 발전한 현재의 클라우드는 소수의 마이크로서비스 인스턴스가 다수의 사용자를 처리하는 '일대다(One-to-Many)' 모델을 기본으로 합니다. * 반면 AI 에이전트는 한 명의 사용자가 하나의 특정 작업을 수행하기 위해 고유한 실행 환경을 점유하는 '일대일(One-to-One)' 모델을 요구합니다. * 기존 애플리케이션이 정해진 메뉴를 제공하는 '레스토랑'이라면, 에이전트는 작업마다 다른 도구와 재료를 사용하는 '개인 요리사'와 같아서 기존의 컨테이너 방식으로는 이를 효율적으로 수용하기 어렵습니다. **에이전트 대중화를 가로막는 확장성 산식** * 수억 명의 지식 노동자가 동시에 에이전트를 사용할 경우, 기존 컨테이너 방식으로는 수백만 대의 서버 CPU가 필요하며 이는 현재 가용 가능한 컴퓨팅 용량을 수십 배 초과합니다. * 컨테이너는 실행 시 수백 메가바이트의 메모리를 소모하고 시작 속도가 느려, 에이전트 한 대당 운영 비용이 매우 높게 형성됩니다. * 이러한 경제적 한계 때문에 현재 에이전트 도구들은 높은 비용을 정당화할 수 있는 코딩 도구 등 일부 영역에만 국한되어 있습니다. **V8 Isolate 기술을 통한 인프라 혁신** * Cloudflare Workers의 기반인 V8 Isolate 기술은 컨테이너 대비 시작 속도는 약 100배 빠르고(수 밀리초), 메모리 사용량은 100배가량 효율적입니다. * 'Dynamic Workers' 환경을 통해 요청이 들어올 때마다 실시간으로 에이전트 실행 환경을 할당하고 작업 종료 즉시 폐기함으로써 하드웨어 밀도를 극대화할 수 있습니다. * Isolate는 에이전트가 필요로 하는 최소한의 자원만 할당하므로, 전 세계 수십억 명의 사용자를 위한 에이전트 서비스 운영에 필요한 경제적 타당성을 제공합니다. **전환기의 과제와 하이브리드 전략** * 현재는 에이전트가 사람이 사용하던 웹사이트를 탐색하기 위해 헤드리스 브라우저를 사용하는 '말 없는 마차(Horseless Carriage)' 단계에 머물러 있습니다. * 향후에는 에이전트가 직접 서비스를 호출하는 MCP(Model Context Protocol) 표준과 에이전트 전용 인증 방식이 확산될 것으로 보입니다. * 클라우드플레어는 파일 시스템과 바이너리 실행이 필수적인 코딩 에이전트를 위한 '컨테이너 기반 샌드박스'를 정식 출시함과 동시에, 가벼운 작업을 위한 Isolate 기술을 병행 지원하여 구시대와 신시대의 인프라를 연결할 계획입니다. 에이전트 중심의 서비스를 구축하려는 기업은 컨테이너 중심의 무거운 기존 설계에서 벗어나, 실행 밀도가 높고 비용 효율적인 Isolate 기반의 서버리스 아키텍처를 도입하여 대규모 사용자 환경에 대비할 것을 추천합니다.

Cloudflare Workers데이터베이스 설계대규모 언어 모델쿠버네티스+4

cloudflare·2026년 3월 24일원문

AI 에이전트 샌드박싱, 100배 더 빠르게 (새 탭에서 열림)

Cloudflare는 AI 에이전트가 생성한 코드를 안전하고 신속하게 실행할 수 있는 'Dynamic Worker Loader' API를 공개했습니다. 이 기술은 기존 컨테이너 방식보다 100배 빠른 실행 속도와 뛰어난 메모리 효율성을 제공하여, 수백만 명의 사용자를 대상으로 하는 대규모 AI 에이전트 서비스의 보안 및 성능 문제를 해결합니다. 개발자는 이를 통해 AI가 작성한 코드를 독립된 V8 Isolate 환경에서 즉시 실행하고, TypeScript 인터페이스를 통해 효율적으로 도구(Tool)를 연동할 수 있습니다. ### 기존 컨테이너 기반 샌드박스의 한계 * AI가 생성한 코드를 직접 실행(eval)하는 것은 보안상 매우 위험하므로 격리된 샌드박스 환경이 필수적입니다. * 기존의 리눅스 기반 컨테이너 샌드박스는 부팅에 수백 밀리초(ms)가 소요되고 수백 메가바이트(MB)의 메모리를 점유하여 비용이 많이 듭니다. * 지연 시간을 줄이기 위해 컨테이너를 미리 띄워두는 방식은 자원 낭비가 심하며, 컨테이너를 재사용할 경우 보안성이 취약해지는 딜레마가 있습니다. ### V8 Isolate 기반의 'Dynamic Worker Loader' * Cloudflare는 구글 크롬에서 사용하는 V8 엔진의 격리 기술인 'Isolate'를 활용해 런타임에 워커를 즉시 생성하는 API를 제공합니다. * Isolate 기술은 실행에 단 몇 밀리초만 소요되며 수 메가바이트의 메모리만 사용하므로, 컨테이너 대비 속도는 100배 빠르고 메모리 효율은 10~100배 더 뛰어납니다. * 모든 유료 워커 사용자는 이 API를 통해 요청마다 독립된 샌드박스를 생성하고, 실행이 끝나면 즉시 폐기하는 방식을 비용 효율적으로 구현할 수 있습니다. ### 무한한 확장성과 제로 레이턴시 * 동적 워커 로더는 전역 동시 실행 수나 생성 속도에 제한이 없어, 초당 수백만 건의 요청이 발생하는 대규모 트래픽도 안정적으로 처리할 수 있습니다. * 샌드박스가 코드를 호출한 워커와 동일한 머신 혹은 동일한 스레드 내에서 실행되므로, 전 세계 어느 지역에서든 네트워크 지연 없이 즉각적인 코드 실행이 가능합니다. * 특정 API에 대한 접근 권한을 부여하거나 외부 인터넷 접속을 차단하는 등 세밀한 보안 제어가 가능합니다. ### AI 친화적인 TypeScript 도구 정의 * AI 에이전트는 이미 자바스크립트와 타입스크립트에 능숙하며, 이러한 언어들은 태생적으로 웹 샌드박스 환경에 최적화되어 있습니다. * 장황한 OpenAPI 명세 대신 간결한 TypeScript 인터페이스를 사용하여 에이전트에게 API 도구를 설명함으로써 토큰 사용량을 80% 이상 절감할 수 있습니다. * `env.LOADER.load()` 함수를 통해 생성된 워커에 RPC(Remote Procedure Call) 스텁을 전달하여 에이전트가 안전하게 외부 기능을 호출하도록 설계되었습니다. 대규모 AI 에이전트 서비스를 구축하려는 개발자에게 Cloudflare의 Dynamic Worker Loader는 최적의 선택지입니다. 기존의 무거운 컨테이너 방식에서 벗어나 V8 Isolate 기반의 가벼운 샌드박스를 채택하고, 도구 정의를 TypeScript로 전환함으로써 성능 최적화와 비용 절감을 동시에 달성할 수 있습니다.

Cloudflare Workers대규모 언어 모델TypeScriptJavaScript+4