cloudflare2026년 8월 4일

수백만 개 리포지토리의 CI/CD를 실행하세요 — 여러분의 플랫폼에서, Cloudflare에서 (새 탭에서 열림)

Cloudflare는 코드 저장소인 Artifacts를 기반으로 빌드·테스트·배포까지 전 과정을 Cloudflare에서 실행하는 CI/CD 환경을 구축하고 있다. 새 CI SDK는 Cloudflare Workflows와 Sandbox SDK를 결합해 CI 파이프라인을 TypeScript로 정의하고, 코드가 Artifacts에 push될 때 자동으로 실행할 수 있게 한다. 각 단계의 재시도·타임아웃·캐싱·병렬 실행을 지원하며, 성공한 경우에만 자동 배포하거나 AI 에이전트를 통한 자동 수정도 가능하다. ## Cloudflare에서 완성되는 코드 개발 생태계 - Cloudflare는 다음 과정을 하나의 플랫폼으로 통합하려 한다. - 코드 저장: Artifacts - 빌드 및 테스트: CI SDK와 Workflows - 배포: `wrangler deploy` - Artifacts는 수백만 개의 저장소를 저장하고 버전을 관리할 수 있는 코드 저장소다. - `wrangler` 설정의 새로운 `events` 필드를 이용하면 Artifacts의 `push` 이벤트를 Workflow 실행으로 직접 연결할 수 있다. - 별도의 이벤트 구독, 큐, 큐 컨슈머를 구성하지 않아도 코드 push를 CI 작업의 시작점으로 사용할 수 있다. ## CI/CD 파이프라인은 하나의 Workflow - CI/CD는 정해진 순서로 여러 단계를 실행하고, 하나라도 실패하면 이후 단계를 중단하는 프로세스다. - Cloudflare는 이를 본질적으로 Workflow와 동일한 구조로 본다. - 기존 YAML 기반 도구 대신 TypeScript의 `step.do()`와 CI SDK를 사용해 파이프라인을 정의할 수 있다. - TypeScript를 사용하면 YAML보다 다음과 같은 장점이 있다. - 조건문과 동적 설정을 쉽게 적용 - 플랫폼별·저장소별 파이프라인 커스터마이징 - 일반 코드와 동일한 방식의 재사용 및 유지보수 ## 격리된 환경에서 실행되는 CI 단계 - CI SDK는 각 명령을 독립적인 Sandbox 환경에서 실행한다. - 대표적인 단계는 다음과 같다. - 의존성 설치 - 코드 빌드 - 린트 실행 - 타입 검사 - 단위 테스트 - 조건부 배포 - 각 Sandbox 명령은 Workflow의 단계로 실행되므로 Cloudflare Workflows가 제공하는 재시도와 타임아웃 기능을 활용할 수 있다. - 기존에는 Sandbox API를 직접 호출하고 단계 간 상태를 별도로 관리해야 했지만, CI SDK가 이 과정을 추상화한다. ## 의존성 캐싱과 병렬 실행 - `bun install --frozen-lockfile` 같은 설치 단계를 먼저 정의하고, `package.json`과 `bun.lock`을 캐시 입력으로 지정할 수 있다. - 의존성 캐시는 계정의 R2 버킷에 Sandbox 스냅샷 형태로 저장된다. - 이후 린트·테스트·타입 검사·빌드 단계는 의존성 설치를 반복하지 않는다. - 독립적인 단계는 `Promise.all()`로 병렬 실행할 수 있어 전체 CI 시간을 줄인다. - 배포 단계는 모든 검사가 성공한 뒤 실행되도록 마지막에 배치한다. ```ts const deps = await ci.runner({ name: "install", command: "bun install --frozen-lockfile", cache: { inputs: ["package.json", "bun.lock"] }, }); await Promise.all([ deps.runner({ name: "lint", command: "bun run lint" }), deps.runner({ name: "test", command: "bun run test" }), deps.runner({ name: "typecheck", command: "bun run typecheck" }), deps.runner({ name: "build", command: "bun run build" }), ]); await deps.runner({ name: "deploy", command: "bun wrangler deploy", cloudflareCredentials: { accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID, }, }); ``` ## 플랫폼 관리 CI와 사용자 정의 CI - 플랫폼 사업자는 고객 애플리케이션을 대신해 CI/CD 파이프라인을 관리할 수 있다. - 하나의 Workflow를 여러 고객 애플리케이션에 공유하면 고객마다 CI 환경을 직접 운영할 필요가 없다. - 반대로 특정 고객이 자체적인 빌드·테스트 규칙을 원한다면 Dynamic Workflows를 이용해 전용 CI를 정의할 수 있다. - 플랫폼이 관리하는 CI와 고객이 직접 작성한 CI는 동일한 namespace 안에서 동시에 실행할 수 있다. - 따라서 모든 고객에게 동일한 파이프라인을 강제하지 않고, 공통 규칙과 개별 요구사항을 함께 지원한다. ## AI 기반 셀프 힐링 CI - CI Workflow에 AI 리뷰 에이전트를 통합할 수 있다. - 빌드 단계가 실패하면 에이전트가 오류를 분석하고 수정 코드를 생성할 수 있다. - 수정 사항을 커밋으로 push해 사람이 검토하고 승인하는 흐름도 구성할 수 있다. - Cloudflare는 이러한 예제를 Project Think의 self-healing CI Workflow로 제공한다. ## 직접 CI Workflow 작성하기 - `@cloudflare/ci`의 `CIWorkflow`를 import해 자체 파이프라인을 작성한다. - 설치 단계에서 Vite, React, esbuild, ESLint, Vitest 등 필요한 패키지와 도구를 설치한다. - lockfile을 지정해 의존성 변경 여부를 검증한다. - 설치 결과를 캐시한 뒤 빌드와 각종 검사를 별도의 격리된 단계에서 실행한다. - 기본적으로 Workflow 단계는 독립적으로 실행되므로 병렬 처리가 가능하다. - 배포 전에 모든 검사가 끝나야 한다면 `Promise.all()`로 여러 검사를 묶어 완료를 기다린다. ## 실용적인 결론 Cloudflare 기반 플랫폼을 운영하거나 고객별 코드를 관리한다면, CI SDK와 Workflows를 이용해 공통 파이프라인을 먼저 만들고 저장소별 예외만 동적으로 추가하는 방식이 적합하다. 설치 단계의 캐싱과 독립 검사의 병렬 실행을 적용하면 CI 지연 시간을 줄일 수 있으며, 배포는 모든 검증 단계가 성공한 뒤에만 실행하도록 구성하는 것이 안전하다.

wranglercloudflareci-cdtypescript+3

cloudflare2026년 8월 4일

이제 에이전트가 로컬 트레이싱으로 Workers를 디버깅할 수 있습니다 (새 탭에서 열림)

`wrangler dev`와 `vite dev`가 로컬 Worker 실행 중 OpenTelemetry 트레이스를 자동 수집해, 코딩 에이전트가 배포 전 오류 원인을 직접 분석하고 수정 결과를 검증할 수 있게 되었습니다. 별도의 SDK 설치, 트레이싱 설정, 에이전트 구성 없이도 에이전트 세션이 감지되면 Local Explorer API가 자동으로 안내됩니다. 에이전트는 트레이스와 로그뿐 아니라 로컬 바인딩 및 데이터 상태까지 조회해 디버깅할 수 있습니다. ## 로컬 Worker 실행 시 자동 트레이싱 - `wrangler dev` 또는 `vite dev`로 실행한 Worker 호출이 자동으로 OpenTelemetry 트레이스로 기록됩니다. - 별도의 SDK나 애플리케이션 코드 수정, 관측성 활성화 설정이 필요하지 않습니다. - Wrangler와 Cloudflare Vite 플러그인은 Miniflare를 통해 Worker를 로컬에서 실행하므로, 실제 Worker 런타임에 내장된 계측 기능을 로컬에서도 사용할 수 있습니다. - 에이전트 세션이 감지되면 개발 서버가 Local Explorer API 주소와 트레이스 조회 엔드포인트를 출력합니다. ## 에이전트가 자동으로 발견하는 Local Explorer API - Local Explorer는 로컬 리소스 데이터와 관측성 데이터를 확인할 수 있는 브라우저 UI이자 REST API입니다. - API 루트에서 OpenAPI 스키마를 제공하므로, 에이전트가 사전에 하드코딩된 지침 없이 실행 중 사용 가능한 엔드포인트를 탐색할 수 있습니다. - 트레이스와 연결된 콘솔 로그는 다음과 같은 읽기 전용 엔드포인트로 조회할 수 있습니다. ```text POST /cdn-cgi/explorer/api/local/observability/query ``` - 에이전트는 트레이스 조회 후 KV, D1, R2, Durable Objects, Workflows 등 로컬 바인딩과 저장 상태도 함께 검사할 수 있습니다. - Local Explorer는 Cloudflare 대시보드가 아니라 Worker와 같은 localhost에서 실행됩니다. - Wrangler에서 `e` 키 입력 - 또는 `/cdn-cgi/explorer` 접속 ## 트레이스로 오류 원인 식별 및 검증 예를 들어 `POST /api/orders`가 다음 작업을 수행한다고 가정합니다. - KV에서 활성 장바구니 조회 - D1에 결제 정보 저장 - Queue에 주문 처리 메시지 전송 스키마 변경 이후 요청이 500 오류를 반환하면 다음과 같이 분석할 수 있습니다. - 트레이스가 없을 때 - 500 응답만으로는 KV, D1, Queue 중 어디서 실패했는지 알기 어렵습니다. - 에이전트가 각 작업 전후에 임시 로그를 추가하고 요청을 반복 실행해야 합니다. - 로그 확인과 코드 수정이 반복되어 시간과 토큰이 소모됩니다. - 트레이스가 있을 때 - KV 조회는 성공했고, D1 삽입 단계에서 `no such column: delivery_window` 오류가 발생했다는 사실을 확인합니다. - D1 작업이 실패했기 때문에 Queue 호출까지 도달하지 않았다는 흐름도 파악할 수 있습니다. - 에이전트가 로컬 D1 스키마를 검사해 저장소에 존재하지만 아직 적용되지 않은 마이그레이션을 발견합니다. - 마이그레이션을 적용한 뒤 요청을 다시 보내고, 새 트레이스에서 성공 여부를 검증합니다. 이 과정은 임시 로그를 추가하거나 배포하지 않고도 오류 위치 확인, 환경 수정, 재검증을 한 번의 로컬 디버깅 루프에서 수행하게 해줍니다. ## 자동으로 기록되는 트레이스 범위 Worker 런타임인 `workerd`에 계측 기능이 내장되어 있어 다음 작업이 자동 기록됩니다. - **Fetch 호출** - 외부 HTTP 요청의 실행 시간 - 상태 코드 - 요청 관련 메타데이터 - **바인딩 호출** - KV, R2, D1, Durable Objects, Queues 등 Cloudflare 바인딩과의 상호작용 - **핸들러 호출** - `fetch`, `scheduled`, Queue 핸들러 등 호출 전체 생명주기 - 애플리케이션이 직접 생성한 커스텀 span도 자동 트레이스에 포함됩니다. - Miniflare는 런타임 이벤트와 콘솔 출력을 수집해 OpenTelemetry 트레이스 및 연결된 로그로 구성합니다. - 수집된 데이터는 내부 SQLite 기반 Durable Object에 저장되고, Local Explorer API를 통해 제공됩니다. ## 사람이 확인하는 Local Explorer - 에이전트는 REST API로 데이터를 조회하지만, 개발자는 브라우저 UI에서 동일한 정보를 시각적으로 확인할 수 있습니다. - 특정 요청을 선택하면 다음 정보를 볼 수 있습니다. - 전체 span 구조 - 각 작업의 실행 시간 - 속성 및 메타데이터 - 오류 정보 - 관련 콘솔 로그 - 로컬 바인딩 상태를 탐색하면서 요청 처리 흐름과 데이터 상태를 함께 점검할 수 있습니다. ## 사용 방법 - Wrangler 기반 프로젝트: ```bash npm install --save-dev wrangler@latest ``` - Cloudflare Vite 플러그인 기반 프로젝트: ```bash npm install --save-dev @cloudflare/vite-plugin@latest ``` 업데이트 후 평소처럼 `wrangler dev` 또는 `vite dev`를 실행하고, 에이전트에게 로컬에서 오류를 재현하고 수정한 뒤 검증하도록 요청하면 됩니다. 로컬 트레이스를 활용하면 배포 전에 실패한 바인딩 호출과 환경 문제를 빠르게 찾아 수정할 수 있으므로, Cloudflare Worker 프로젝트의 에이전트 기반 디버깅에서는 최신 Wrangler 또는 Vite 플러그인 사용을 권장합니다.

wranglerobservabilitycloudflare-workersdurable-objects+4

cloudflare2026년 8월 4일

소개: Cloudflare Agents (새 탭에서 열림)

Cloudflare는 에이전트를 배포·관찰·개선할 수 있는 통합 관리 환경인 Cloudflare Agents를 공개했으며, 첫 기능으로 에이전트 트레이싱을 제공한다. 이 기능은 모델 호출, 도구 실행, 토큰 사용량, 승인 대기, 서브에이전트 작업과 Workers 인프라 동작을 하나의 추적으로 연결해 에이전트의 실제 동작과 비용을 파악하게 한다. 이를 통해 단순한 요청 성공 여부를 넘어 잘못된 도구 선택, 재시도 루프, 오래된 컨텍스트 전달 같은 문제를 분석하고 지속적으로 개선할 수 있다. ## 에이전트 관찰 가능성이 필요한 이유 - 에이전트는 HTTP 200을 반환하더라도 잘못된 도구를 선택하거나, 서브에이전트에 오래된 컨텍스트를 전달하거나, 토큰을 재시도 루프에서 낭비할 수 있다. - 기존 애플리케이션 텔레메트리는 API 요청이나 데이터베이스 쿼리는 보여주지만, 그 동작을 유발한 에이전트의 판단 과정은 보여주지 못한다. - 에이전트 수준의 텔레메트리는 다음 질문에 답해야 한다. - 지연 시간은 모델, 도구, 인프라 중 어디에서 발생했는가? - 승인 대기로 턴이 중단되었는가? - 어떤 모델을 호출했고 토큰을 얼마나 사용했는가? - 올바른 도구를 선택했는가? - 외부 API가 성공했는가, 타임아웃되었는가? - 어떤 서브에이전트가 작업했고 최종 응답에 어떤 영향을 주었는가? ## 에이전트 트레이싱의 범위 - 기존 Workers 트레이싱은 `fetch`, KV, D1 등 인프라 계층의 동작을 기록했다. - 새 에이전트 트레이싱은 여기에 다음과 같은 에이전트 전용 span을 추가한다. - 에이전트 호출 - 모델 호출 - 도구 실행 - 승인 이벤트 - 지원되는 서브에이전트 호출 - 모델명과 토큰 사용량 같은 정보도 메타데이터로 연결된다. - Think, Flue, AI SDK로 만든 에이전트는 Cloudflare 대시보드에서 추적을 확인하거나 OpenTelemetry 호환 대상에 내보낼 수 있다. ## 세션 리플레이로 판단 과정 확인 - Agents 대시보드의 Messages 탭에서는 특정 턴의 전체 대화를 재구성한다. - 시스템 지침 - 사용자 메시지 - 모델의 사고 과정 - 도구 호출 인자와 결과 - 최종 응답 - 이는 에이전트를 다시 실행하는 것이 아니라 기록된 데이터를 재생하는 기능이다. - 잘못된 도구 인자, 도구 선택 당시의 컨텍스트, 서브에이전트 핸드오프, 이전 턴이 이후 결과에 미친 영향을 분석할 수 있다. - Think, Flue, AI SDK에서는 `storeMessages`와 `storeTools` 설정으로 메시지 및 도구 payload 저장 여부를 제어한다. - 개인정보, 비밀값, 민감한 데이터가 포함될 수 있다면 payload 기록을 끄는 것이 권장된다. ## 실행 워터폴과 서브에이전트 추적 - Traces 탭은 각 턴의 실행 과정을 시간순 워터폴로 보여준다. - 부모 에이전트에서 서브에이전트, 모델, 도구, 데이터 저장소까지 하나의 흐름으로 연결된다. - 예시에서는 다음 작업을 한 화면에서 확인할 수 있다. - `TravelPlanner` 부모 에이전트 호출 - `itinerary_builder` 서브에이전트 호출 - `@cf/zai-org/glm-4.7-flash` 모델 호출과 토큰 사용량 - `record_itinerary_builder_execution` 도구 실행 - D1 쿼리 실행 - `record_respond_ready` 도구 실행 - KV 쓰기 - 부모 에이전트와 서브에이전트에는 에이전트 클래스, 대화, Durable Object 식별자가 연결되어 추적 간 상관관계를 파악할 수 있다. - KV, D1, Durable Object, 서비스 바인딩, `fetch` 등 Workers 리소스는 이를 호출한 에이전트 작업 아래에 중첩되어 표시된다. ## 트레이싱 활성화 방법 - 먼저 `wrangler.jsonc`에서 Workers 관찰 기능을 활성화한다. ```json { "observability": { "traces": { "enabled": true } } } ``` - 사용하는 에이전트 스택에 따라 추가 설정이 필요하다. - Think·Flue: 자체 트레이싱 통합 기능으로 에이전트, 대화, 턴, 모델, 도구 텔레메트리 전송 - AI SDK: Cloudflare의 `wrapAISDK()` 어댑터로 SDK 감싸기 - 사용자 정의 하네스: 커스텀 span API와 OpenTelemetry Generative AI 의미 규약 사용 ## OpenTelemetry 기반 확장과 외부 전송 - Cloudflare는 향후 Workers 내부에서 OpenTelemetry API를 직접 지원할 예정이다. - 표준 OpenTelemetry Generative AI span을 생성하는 프레임워크는 Cloudflare 전용 어댑터 없이 Agents 화면에서 시각화될 수 있다. - 표준 에이전트 및 대화 식별자가 포함되면 Cloudflare의 내장 통합처럼 에이전트와 세션 단위로 그룹화할 수 있다. - 추적 데이터는 Cloudflare에 종속되지 않으며, Wrangler 설정에서 OTLP 호환 제공자를 지정해 외부 관찰성 플랫폼으로 내보낼 수 있다. 에이전트 운영을 시작한다면 먼저 트레이싱을 활성화하고 메시지·도구 payload 저장 시 개인정보 노출 여부를 검토하는 것이 좋다. 이후 세션 리플레이로 판단 오류를 찾고, 워터폴 추적으로 모델·도구·인프라별 지연 시간과 비용을 분석하면 안정성과 효율을 체계적으로 개선할 수 있다.

wranglercloudflare-workersdurable-objectsopentelemetry+4

cloudflare2026년 7월 6일

이제 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를 함께 사용하는 방식이 적합하다.

wranglercloudflare-workershttp-cachingstale-while-revalidate+2

cloudflare2026년 6월 24일

모두를 위한 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 시스템을 개방하려면 클라이언트 등록 기능만 추가해서는 부족하다. 명확한 동의 화면, 즉각적인 권한 철회, 앱 소유자 표시 같은 보안 기능과 함께, 스키마 마이그레이션 중에도 철회 이벤트를 보존하는 큐, 토큰 만료 조정, 토큰 갱신 재시도 제어 같은 운영 설계가 함께 필요하다.

wranglercloudflare-workersoauthdatabase-migrations+3

cloudflare2026년 6월 19일

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분 내에 클레임하지 않으면 리소스가 삭제되므로, 장기 운영 서비스는 반드시 계정을 클레임하고 정식 인증·관리 체계로 전환해야 한다.

wranglerai-agenttypescriptcloudflare-workers+4

cloudflare2026년 4월 13일

클라우드플레어 전체를 위한 CLI 구축하기 (새 탭에서 열림)

Cloudflare는 100개 이상의 제품과 3,000여 개의 API 작업을 아우르는 거대한 생태계를 단일화하기 위해 Wrangler CLI를 전면 재구축하고 있습니다. 특히 AI 에이전트가 주요 사용자로 부상함에 따라, 모든 제품을 CLI, SDK, Terraform 등 다양한 인터페이스에서 일관되게 사용할 수 있도록 하는 것을 목표로 합니다. 이를 위해 새로운 TypeScript 기반 스키마 시스템을 도입하여 코드 생성 파이프라인을 자동화하고 개발 생산성을 높이고 있습니다. ### 통합 CLI 'cf'로의 진화 * Cloudflare의 방대한 API를 모두 수용하기 위해 차세대 Wrangler의 기술 프리뷰 버전인 `cf` 커맨드를 공개했습니다. * 기존 Wrangler가 일부 제품만 지원하던 한계를 극복하고, 인간과 AI 에이전트 모두에게 인체공학적인 출력을 제공하도록 설계되었습니다. * 현재 `npx cf` 또는 `npm install -g cf`를 통해 초기 버전을 미리 체험해 볼 수 있으며, 향후 기존 Wrangler 기능들과 통합될 예정입니다. ### TypeScript 기반의 새로운 스키마 엔진 * 기존 OpenAPI 스키마만으로는 로컬 개발 환경과 API 요청이 결합된 복잡한 CLI 명령어나 Workers 바인딩을 표현하는 데 한계가 있었습니다. * 이에 Cloudflare는 API, CLI 인자, 에이전트 기술(Agent Skills) 등을 포괄적으로 정의할 수 있는 새로운 TypeScript 기반 스키마 시스템을 구축했습니다. * 이 시스템은 일종의 '코드 생성기' 역할을 하며, 단일 정의로부터 OpenAPI 스키마, SDK, Terraform 제공자 등을 자동으로 생성하여 제품 업데이트 속도에 맞춘 신속한 동기화를 지원합니다. ### 일관성 확보와 컨텍스트 엔지니어링 * 수많은 제품군 사이에서 일관성 없는 명령어(예: `info`와 `get`의 혼용)는 특히 AI 에이전트의 오작동을 유발하므로, 스키마 계층에서 명칭 규칙을 강제합니다. * 모든 명령어에 `--force`, `--json`과 같은 표준 플래그를 적용하여 예측 가능성을 높였습니다. * 로컬 리소스와 원격 리소스 간의 동작 차이를 명확히 시그널링하여, 에이전트가 개발 중 리소스를 수정할 때 혼동하지 않도록 컨텍스트를 제공합니다. ### 로컬 익스플로러(Local Explorer) 도입 * 로컬 개발 환경에서 시뮬레이션되는 KV, D1, R2, Durable Objects 등의 리소스 내부를 쉽게 들여다볼 수 있는 'Local Explorer' 기능이 베타로 출시되었습니다. * Wrangler나 Cloudflare Vite 플러그인 실행 중 단축키 `e`를 눌러 활성화할 수 있으며, 기존처럼 `.wrangler/state` 디렉토리를 직접 분석할 필요가 없습니다. * 이를 통해 개발자와 에이전트는 로컬 데이터 상태를 즉각 확인하고, 테스트 레코드를 삽입하거나 스키마를 검증하는 등 상호작용 중심의 개발 사이클을 가질 수 있습니다. Cloudflare의 새로운 변화를 미리 경험해보고 싶다면 지금 바로 터미널에서 `npx cf`를 실행해 보세요. 또한 로컬 개발 중에는 `e` 키를 활용해 데이터 상태를 실시간으로 점검하며 개발 속도를 높일 수 있습니다.

wranglerdatabase-designcloudflaretypescript+4