cloudflare2026년 8월 7일

레이더 리서처 소개: 자연어로 인터넷 데이터를 탐색하는 AI 도구 (새 탭에서 열림)

Cloudflare Radar Researcher는 자연어 질문만으로 인터넷 트래픽 데이터를 조회하고, 실제 API 기반 차트와 설명을 제공하는 AI 도구다. 사용자는 복잡한 필터 설정이나 API 문서 학습 없이 국가별 인터넷 품질, 장애·셧다운 상황 등을 분석할 수 있다. Cloudflare는 이를 통해 초보자부터 네트워크 전문가까지 Radar의 공개 데이터를 더 빠르고 쉽게 활용하도록 하는 것을 목표로 한다. ## Radar Researcher를 만든 배경 - Cloudflare Radar는 2020년부터 전 세계 인터넷 트래픽에 대한 공개 데이터와 시각화를 제공해 왔다. - 주요 데이터에는 다음이 포함된다. - 1.1.1.1 공개 DNS 리졸버의 DNS 질의 - Cloudflare 글로벌 네트워크의 HTTP 트래픽 - Cloudflare Speed Test 기반 네트워크 품질 데이터 - 기존에는 사용자가 적절한 Radar 페이지를 찾고, 필터를 설정하고, API 문서를 읽어야 했다. - AI 도구의 발전으로 데이터셋의 구조와 전문 용어를 몰라도 자연어로 원하는 정보를 얻을 수 있게 되었다. - 기자나 연구자처럼 신속하게 데이터를 확인해야 하는 사용자는 복잡한 탐색 과정을 거치지 않고 바로 분석을 시작할 수 있다. ## 자연어 기반 데이터 질의 - Radar Researcher는 사용자의 질문을 해석해 Radar API에 필요한 데이터 요청을 자동으로 구성한다. - 답변은 단순한 텍스트가 아니라 Radar에서 제공하는 것과 같은 인터랙티브 차트와 간단한 설명으로 제공된다. - 답변의 깊이를 선택할 수 있다. - 짧고 직접적인 답변 - 여러 주제를 다루는 상세 보고서 - 답변 뒤에는 추가로 조사할 만한 후속 질문을 제안한다. - 대화 기록은 검색·고정할 수 있고, 링크로 공유할 수 있다. - 공유 링크는 30일 후 자동 만료된다. - 사용자는 텍스트 입력뿐 아니라 음성 입력이나 Radar 검색창에서도 Researcher를 실행할 수 있다. - 모델이 질문을 어떻게 해석했고, 어떤 데이터셋과 API를 사용했으며, 결과를 어떻게 분석했는지 확인할 수 있다. ## 기존 차트에서 바로 분석 시작 - Radar의 차트에 있는 **Explain with AI** 기능을 사용하면 현재 보고 있는 시각화를 대화의 출발점으로 삼을 수 있다. - 모델에는 다음 세 가지 정보가 함께 전달된다. - 차트 스크린샷: 사용자가 실제로 보는 시각적 맥락 파악 - Radar API의 원시 데이터: 숫자를 픽셀에서 추정하지 않고 정확하게 인용 - 현재 화면의 위치, 날짜 범위, 필터 등 조회 조건 - 따라서 일반적인 차트 설명이 아니라 사용자가 선택한 국가·기간·필터에 정확히 맞춘 분석을 제공한다. ## 사례: 포르투갈의 인터넷 품질 분석 - 사용자는 “포르투갈의 가정용 인터넷 품질은 어떤가?”처럼 자연어로 질문할 수 있다. - Researcher가 인터넷 품질 API를 조회하고 결과를 분석한 뒤, 수치 나열 대신 인터랙티브 차트로 답변한다. - 이후 포르투갈과 인접 국가를 비교하거나, 포르투갈에서 가장 흔한 인터넷 장애를 확인하는 식으로 후속 분석을 이어갈 수 있다. - API 호출 방식이나 파라미터를 직접 알지 않아도 국가별·주제별 비교가 가능하다. ## 사례: 이란 인터넷 셧다운 조사 - 2026년 이란에서 발생한 정부 주도 인터넷 차단 사례를 조사할 때 여러 트래픽 차트와 장애 기록을 직접 찾아 비교할 필요가 없다. - Researcher는 이란의 Cloudflare Radar 장애 이벤트와 관련 HTTP 트래픽 데이터를 함께 조회한다. - 분석 결과를 다음과 같은 타임라인으로 설명한다. - 1월 7일 HTTP 트래픽 지수가 약 0.58에서 시작 - 1월 9일까지 사실상 0으로 하락 - 1월 17일경 부분 회복 시작 - 1월 27일경 셧다운 이전 수준에 근접 - 2월 28일 시작된 두 번째 셧다운도 장애 표에 표시 - 장애 기간은 트래픽 차트 위에 직접 표시되며, 관련 장애 이벤트는 표 형태로 함께 제공된다. - 이후 주변 국가와의 트래픽 비교 같은 추가 조사도 제안한다. ## Cloudflare 개발자 플랫폼으로 구축 - Radar Researcher는 Cloudflare의 자체 개발자 플랫폼 위에서 구현되었다. - 핵심 구성은 다음과 같다. - Cloudflare Worker - Cloudflare Agents SDK - 대화별 상태를 유지하는 Durable Objects - 각 대화의 기록·제목·스트리밍 응답을 저장하는 SQLite 데이터베이스 - Workers AI 기반의 오픈 모델 - 사용자가 페이지를 떠나도 서버에서 응답 생성이 계속되고, 다시 접속하면 결과를 이어받을 수 있다. - 특정 모델이나 제공업체에 의존하지 않도록 세 가지 모델 계열을 순서대로 사용하는 fallback 체인을 구성했다. - 한 모델이 일시적으로 용량 부족 상태가 되면 다른 모델로 자동 전환해 서비스 중단 가능성을 줄인다. - 모든 AI 호출은 AI Gateway를 거친다. ## 실용적인 결론 Radar Researcher는 전문적인 데이터 탐색 과정을 자연어 인터페이스로 감싸, 기자·연구자·네트워크 운영자뿐 아니라 일반 사용자도 Cloudflare Radar의 공개 데이터를 쉽게 활용하게 해준다. 다만 AI의 해석을 그대로 받아들이기보다는 제공되는 API 데이터, 조회 조건, 분석 과정을 함께 확인하는 방식으로 사용하는 것이 적절하다.

durable-objectsllmcloudflare-workerssqlite+3

cloudflare2026년 8월 6일

MCP의 차세대 기술 (새 탭에서 열림)

지난 1년 반 동안 MCP는 에이전트와 외부 서비스를 연결하는 표준이 되었지만, 기존에는 세션과 연결 상태를 유지해야 해 원격 서버 운영이 복잡했다. 2026-07-28 사양부터 MCP는 완전한 무상태 프로토콜로 바뀌어, 서버가 세션을 저장하거나 sticky session·장기 스트림을 관리하지 않아도 된다. 그 결과 MCP 서버는 Cloudflare Workers 같은 요청 단위 인프라에서 더 저렴하고 간단하게 운영할 수 있다. ## MCP의 무상태 전환 - 기존 MCP는 `initialize`와 `initialized` 교환으로 세션을 만들고, 서버가 `Mcp-Session-Id`를 발급했다. - 이후 모든 요청은 해당 세션의 상태를 찾아야 했기 때문에 다음과 같은 운영 부담이 발생했다. - 오토스케일링 환경에서 세션 보존 - sticky session을 통한 요청 라우팅 - 배포 시 세션 drain 또는 migration - 인스턴스 장애 시 재연결 및 세션 복구 - 새 사양에서는 필수 handshake와 `Mcp-Session-Id`, 프로토콜 세션이 제거됐다. - 각 요청이 MCP 버전, 클라이언트 식별 정보, 클라이언트 capability를 직접 포함한다. - 서버 정보를 미리 확인해야 하는 경우에만 선택적으로 `server/discover`를 호출한다. - MCP 자체에 상태가 필요하지 않으므로 기존 `McpAgent` 없이도 서버를 구현할 수 있다. - 애플리케이션 자체에 상태가 필요할 때는 Durable Objects를 사용할 수 있지만, MCP 프로토콜만 제공하는 서버는 Cloudflare Workers처럼 요청 단위 인프라에서 실행할 수 있다. - Cloudflare SDK에서는 기존 `McpAgent` 대신 `createMcpHandler`로 새 무상태 사양을 지원한다. ## 장기 연결이 필요 없는 Elicitation - Elicitation은 서버가 작업을 완료하기 전에 사용자 입력이나 승인을 요청하는 기능이다. - 운영 배포 승인 - 디자인 색상 선택 - 환불 확인 - 기존에는 `elicitation/create`가 열린 스트림에 의존했다. - 이 방식은 스트림 유지, 타임아웃, 비용, 로드 밸런싱을 복잡하게 만들었다. - 새 사양은 Multi Round-Trip Requests(MRTR)를 사용한다. - 서버가 `input_required` 결과를 반환한다. - 클라이언트가 사용자 입력을 수집한다. - 클라이언트가 입력값과 함께 작업을 재시도한다. - 서버가 작업을 완료한다. - 요청 사이에 연결이나 transport session을 보존할 필요가 없다. - 기존 Elicitation 방식과 호환되지 않는 breaking change이지만, 구현과 운영은 훨씬 단순해진다. ## HTTP 인프라가 MCP 요청을 직접 이해 - 기존에는 MCP 요청의 메서드와 대상이 JSON-RPC 본문 안에만 있어, 게이트웨이가 내용을 파싱해야 했다. - 새 Streamable HTTP 요청에는 다음 헤더가 필수로 추가된다. - `Mcp-Protocol-Version` - `Mcp-Method` - `Mcp-Name` - 예를 들어 도구 호출은 `Mcp-Method: tools/call`, `Mcp-Name: search`로 표현할 수 있다. - 게이트웨이, rate limiter, WAF가 JSON 본문을 해석하지 않고도 요청 종류별 정책을 적용할 수 있다. - 도구별 metrics 수집, 메서드별 rate limit, 보안 규칙 적용도 기존 HTTP 인프라 방식으로 처리할 수 있다. ## 캐시와 도구 목록 개선 - `tools/list`, `prompts/list`, `resources/list`, `resources/read` 결과에 다음 힌트가 추가된다. - `ttlMs`: 결과를 얼마나 오래 캐시할 수 있는지 나타냄 - `cacheScope`: 캐시 적용 범위를 나타냄 - 도구 카탈로그는 결정론적으로 정렬된다. - 클라이언트가 연결이 끊겼다가 다시 연결되어도 카탈로그를 재사용하기 쉬워진다. - upstream prompt cache가 불필요하게 무효화되는 문제도 줄일 수 있다. ## 인증 체계의 변화 - 새 사양은 MCP 인증 방식의 우선순위를 정비한다. - 서버와 클라이언트 사이에 사전 관계가 있다면 사전 등록된 클라이언트를 우선 사용한다. - 동적 등록이 필요하면 Client ID Metadata Documents(CIMD)를 사용한다. - Dynamic Client Registration(DCR)은 최후의 수단으로 남지만, 신규 구현에서는 deprecated되었다. ## 실용적인 결론 새 MCP 서버는 세션 저장소나 장기 연결을 기본 전제로 설계할 필요가 없다. 단순한 도구·프롬프트·리소스 서버라면 `createMcpHandler`와 요청 단위 실행 환경을 사용하고, 애플리케이션 자체에 지속 상태나 실시간 협업이 필요할 때만 Durable Objects 같은 상태ful 인프라를 선택하는 것이 권장된다.

durable-objectsmodel-context-protocolcloudflare-workersjson-rpc+2

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 플러그인 사용을 권장합니다.

durable-objectsobservabilitycloudflare-workerssqlite+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 저장 시 개인정보 노출 여부를 검토하는 것이 좋다. 이후 세션 리플레이로 판단 오류를 찾고, 워터폴 추적으로 모델·도구·인프라별 지연 시간과 비용을 분석하면 안정성과 효율을 체계적으로 개선할 수 있다.

durable-objectscloudflare-workersopentelemetrywrangler+4

cloudflare2026년 8월 3일

에이전트에게 필요한 건 컨테이너가 아니라 컴퓨터입니다 — @cloudflare/computer 소개 (새 탭에서 열림)

가장 뛰어난 에이전트는 자체 컴퓨터처럼 사용할 수 있는 파일시스템, 셸, 도구, 실행 환경을 제공받는다는 것이 글의 핵심 주장입니다. Cloudflare는 이를 위해 `@cloudflare/computer`라는 에이전트 런타임을 공개 프리뷰로 제공하며, 격리 실행 환경(isolate)과 컨테이너를 하나의 공유 파일시스템 아래 결합합니다. 이를 통해 컨테이너만 사용하는 방식보다 비용과 확장성 문제를 줄이고, 수억~수십억 개의 동시 에이전트까지 확장하는 것을 목표로 합니다. ## 에이전트마다 컴퓨터를 제공하는 방식 - 코딩 에이전트는 파일시스템, 셸, 패키지, 실행 도구를 직접 사용하면서 환경을 조사하고 코드를 수정·실행·검증한다. - 이런 “컴퓨터”가 모델이 현실의 작업을 수행하는 익숙한 인터페이스가 된다. - `@cloudflare/computer`는 코드가 isolate, 컨테이너, 웹 브라우저 중 어디에서 실행되는지에 대한 세부 사항을 플랫폼이 처리하는 런타임이다. - 각 에이전트에 작업 공간과 실행 환경을 제공하면서 효율성과 확장성을 최적화한다. ## 컨테이너 중심 구조의 확장성 문제 - 초기에는 에이전트 전체를 컨테이너 안에서 실행하는 방식이 일반적이었다. - 최근에는 에이전트의 판단 루프와 실제 코드 실행 환경을 분리하고, 샌드박스를 도구로 호출하는 구조가 확산되고 있다. - 그러나 사용자마다 에이전트 전용 컨테이너를 제공하면 수억, 수십억 개의 동시 에이전트를 감당할 컴퓨팅 자원이 부족하다. - 이 때문에 에이전트 시스템에는 GPU뿐 아니라 막대한 양의 CPU 컴퓨팅 자원도 필요하다. ## Isolate와 컨테이너의 결합 - Cloudflare는 수년 전부터 빠르게 생성·삭제할 수 있고 수평 확장에 적합한 isolate를 핵심 컴퓨팅 단위로 개발해 왔다. - isolate는 다음과 같은 특성을 가진다. - 매우 빠른 시작과 종료 - 유휴 상태에서의 휴면 - 에이전트 상태 저장 - 신뢰할 수 없는 코드를 실행하기 위한 추가 isolate 생성 - 대규모 수평 확장 - Cloudflare의 기존 구조에서는 Durable Object 안에서 에이전트 루프를 isolate로 실행하고, 무거운 작업이 필요할 때만 연결된 컨테이너를 도구로 호출한다. - 즉, 가벼운 작업은 isolate에서 처리하고 Linux, npm, 네이티브 바이너리 등이 필요한 작업만 컨테이너에서 실행해 성능과 비용을 조절한다. - `@cloudflare/computer`는 개발자가 이 여러 컴퓨팅 요소를 직접 조합하지 않아도 되도록 더 단순한 추상화를 제공하려는 실험이다. ## 공유 파일시스템 기반 작업 공간 - 에이전트에게 작업에 필요한 파일과 실행 환경이 미리 준비된 내구성 있는 파일시스템을 제공한다. - 에이전트는 작업 성격에 따라 실행 환경을 선택할 수 있다. - 파일 조작, 데이터 처리, Git 저장소 관리는 isolate에서 실행 - Linux 명령, npm, 네이티브 바이너리가 필요한 작업은 컨테이너에서 실행 - isolate와 컨테이너는 동일한 파일을 사용하며, 변경 사항은 원본 파일시스템과 동기화된다. - 파일시스템은 Git 저장소, 스토리지 버킷, 임의의 파일을 대상으로 사용할 수 있다. - 파일 읽기·쓰기·수정은 Code Mode나 Bash 명령으로 수행할 수 있다. - 모든 작업은 다음 방식으로 관리된다. - 권한 제어 - 감사(audit) - 관찰 및 추적(observability) - 따라서 에이전트가 수행할 수 있는 변경 범위를 세밀하게 제한하고, 어떤 작업을 했는지 기록으로 남길 수 있다. ## 사용 방법과 에이전트 통합 - 패키지는 npm으로 설치한다. ```bash npm install @cloudflare/computer ``` - Durable Object에 `Workspace`를 생성해 가상 파일시스템과 실행 런타임을 연결한다. - `Workspace`는 Durable Object의 저장소를 이용해 에이전트별 상태와 파일을 지속적으로 보관한다. - 예시에서는 `@cloudflare/think` 기반 에이전트가 버그 트리아지를 수행하도록 구성한다. - 시스템 프롬프트를 통해 에이전트가 다음 작업을 수행하게 할 수 있다. - `/workspace/repo`의 프로젝트 조사 - 버그 재현 - 안전한 경우 집중적인 수정 - 검증 명령 실행 - 변경 내용과 실행한 명령, 검증 결과 보고 - `@cloudflare/computer`는 기본 실행 백엔드 외에도 개발자가 직접 백엔드를 작성할 수 있다. - 제공된 `CloudflareContainerBackend`를 사용하면 Workspace를 Cloudflare Container와 연결할 수 있다. - `withWorkspaceContainer` 같은 헬퍼를 통해 에이전트 Durable Object와 컨테이너를 결합한다. ## 실용적인 의미 - 가벼운 작업은 isolate로 처리하고 무거운 작업만 컨테이너로 넘기는 구조가 대규모 에이전트 서비스에 적합하다. - 에이전트별 전용 컨테이너를 항상 실행하는 방식보다 자원 사용량과 비용을 줄일 가능성이 크다. - 파일 변경 권한과 실행 기록을 통제할 수 있어 코드 수정 에이전트, 버그 트리아지, 자동화된 개발 작업에 유용하다. - 현재는 초기 공개 프리뷰이므로, 실제 도입 시 지원되는 백엔드와 API 안정성, 작업 격리 수준, 비용 구조를 확인하는 것이 좋다.

durable-objectstypescriptcloudflare-workersisolates+3

cloudflare2026년 8월 3일

Cloudflare Workers와 Containers, 이제 인바운드 TCP 연결 및 gRPC 지원 (새 탭에서 열림)

Cloudflare는 Workers에 인바운드 TCP 소켓을 직접 처리하는 `connect(socket)` 기능과 컨테이너 기반의 양방향 gRPC 지원을 추가했습니다. 이를 통해 클라이언트의 TCP 연결을 Worker, Durable Object, Container로 전달하고, 다양한 언어로 작성된 gRPC 서버를 Cloudflare 네트워크에서 실행할 수 있습니다. 특히 저지연·양방향 통신이 중요한 음성 AI와 실시간 애플리케이션을 클라이언트 가까이에서 처리하는 것이 목표입니다. ## Workers의 인바운드 TCP 지원 - 기존 Workers는 주로 HTTP 요청을 처리하거나 아웃바운드 TCP 연결을 생성하는 방식이었지만, 이제 `connect(socket)` 핸들러로 들어오는 TCP 연결을 받을 수 있습니다. - 소켓은 `readable`과 `writable` 스트림으로 제공되며, 다음과 같이 데이터를 읽고 쓸 수 있습니다. - `socket.writable.getWriter()`로 데이터 전송 - `socket.readable.pipeTo(...)`로 다른 소켓에 데이터 전달 - TCP 연결을 Worker에서 직접 종료하거나, 다른 Worker·Durable Object·Container로 라우팅할 수 있습니다. ## Durable Objects와 Container로 소켓 전달 - Worker는 Durable Object의 `connect()` 메서드를 호출해 인바운드 소켓을 특정 객체로 전달할 수 있습니다. - Durable Object는 양방향 스트림을 연결해 클라이언트와 서버 사이의 바이트를 그대로 중계할 수 있습니다. - Durable Object에서 Container의 TCP 포트에 연결한 뒤 다음과 같이 양방향 파이프를 구성합니다. - 클라이언트 → Container - Container → 클라이언트 - Container에서는 Python, Go 등 원하는 언어와 TCP 서버 구현을 사용할 수 있습니다. - 따라서 특정 RPC 프레임워크에 종속되지 않고, TCP를 사용하는 어떤 프로토콜이나 프로그램도 Cloudflare에서 처리할 수 있습니다. ## Spectrum을 이용한 TCP 진입점 - Cloudflare Spectrum은 HTTP가 아닌 TCP·UDP 트래픽을 Cloudflare 네트워크로 받아들이는 인그레스 프록시입니다. - 새로운 Spectrum 애플리케이션 유형에서는 유입된 TCP 연결을 지정한 Worker의 `connect(socket)` 핸들러로 전달할 수 있습니다. - 결과적으로 클라이언트부터 Cloudflare Worker, Durable Object, Container 내부 서버까지 전체 네트워크 경로를 제어할 수 있습니다. ## Cloudflare Containers의 양방향 gRPC - gRPC는 HTTP/2와 TCP를 기반으로 하는 RPC 프레임워크로, 모바일 앱·분산 시스템·음성 AI 서비스에서 널리 사용됩니다. - 실시간 음성 애플리케이션은 단일 연결에서 클라이언트와 서버가 모두 지속적으로 메시지를 보내야 하므로 양방향 스트리밍이 중요합니다. - Cloudflare의 새 기능을 사용하면 다음과 같은 gRPC 서버를 Container에 배포할 수 있습니다. - 모든 언어로 작성된 gRPC 서버 - 클라이언트와 서버 간 full-duplex 양방향 스트리밍 - 지속적인 단일 TCP 연결 - 예시 gRPC 서버는 연결 직후 `connected` 메시지를 보내고, 클라이언트 메시지마다 `echo` 응답을 보내며, 연결 종료 시 `goodbye` 메시지를 전송합니다. - Cloudflare는 330개 이상의 위치에서 요청을 처리하므로, 서버를 사용자와 가까운 위치에서 실행해 지연 시간을 줄일 수 있습니다. ## Workers 기반 gRPC API - Workers에서는 gRPC 서버를 직접 구현하거나 기존 gRPC 서버를 호출할 수 있습니다. - 개발자는 `gRPC-web` 방식으로 코드를 작성하고, Cloudflare가 요청과 응답을 실제 gRPC 형식으로 변환합니다. - 지원 범위에는 다음이 포함됩니다. - 단일 요청·응답 방식인 unary RPC - 서버가 여러 메시지를 보내는 server-streaming RPC - Container로 소켓을 직접 전달하는 양방향 스트리밍 gRPC - 이 기능을 활용하면 기존 gRPC 생태계를 유지하면서 Cloudflare의 글로벌 네트워크와 Workers의 라우팅 기능을 함께 사용할 수 있습니다. ## 음성 AI와 실시간 서비스에 대한 의미 - AI 음성 비서, 실시간 받아쓰기, 음성 기반 에이전트는 모델·클라이언트·지원 서비스 사이의 낮은 지연 시간이 필수적입니다. - WebSockets와 Durable Objects도 적합하지만, 이미 gRPC를 사용하는 기존 시스템은 새 인프라로 전면 재작성할 필요가 줄어듭니다. - Cloudflare는 TCP 연결을 직접 전달하므로 음성 데이터나 스트리밍 추론 요청처럼 연결을 오래 유지하는 서비스에 적합합니다. - 해당 기능은 현재 프라이빗 베타로 제공되며, 사용을 위해 별도 신청이 필요합니다. 실시간 음성 AI나 기존 gRPC 시스템을 Cloudflare에 배포하려는 경우, `connect(socket)`을 이용해 Worker–Durable Object–Container 간 양방향 스트림을 구성하는 방식이 유용합니다. 다만 현재는 프라이빗 베타이므로 실제 도입 전 지원 프로토콜, 연결 수명, 지연 시간, 비용 및 운영 제한을 확인하는 것이 좋습니다.

durable-objectscloudflare-workersgrpctcp+3

cloudflare2026년 6월 17일

Flue를 시작으로 Cloudflare에 더 많은 에이전트 하네스 도입하기 (새 탭에서 열림)

2026년에는 AI 에이전트가 프로토타입을 넘어 실제 운영 인프라로 사용되면서, 중단 복구·보안 실행·도구 연동 같은 분산 시스템 문제가 중요해지고 있다. 글은 이를 해결하기 위해 **프레임워크(Flue)–하네스(Pi, Project Think)–런타임(Cloudflare Agents SDK)**의 3계층 구조가 필요하다고 주장한다. Flue는 선언적으로 에이전트를 정의하고, Cloudflare Agents SDK는 내구성 있는 실행·상태·스토리지·샌드박스를 제공해 프로덕션 환경의 안정성을 높인다. ## 프로덕션 에이전트를 위한 3계층 구조 - **프레임워크: Flue** - 프로젝트 구조, 규칙, 외부 서비스 통합, CLI, 개발자 경험을 제공한다. - 에이전트를 실제 업무 환경에 배치하고 관리하는 상위 계층이다. - **하네스: Pi, Project Think** - 모델의 에이전트 루프를 담당한다. - 도구 호출, 결과 확인, 컨텍스트 관리, 작업 완료까지의 반복 과정을 처리한다. - **런타임/플랫폼: Cloudflare Agents SDK** - 에이전트가 의존하는 컴퓨트, 상태 관리, 스토리지 primitives를 제공한다. - 특정 하네스에 종속되지 않고 다양한 하네스와 프레임워크가 사용할 수 있는 기반 계층이다. ## Flue의 선언적 에이전트 모델 - Flue 1.0 Beta는 Pi 하네스를 기반으로 하며, OpenClaw와 같은 하네스를 사용한다. - 에이전트가 무엇을 할지 절차적으로 스크립팅하는 대신, 에이전트가 알아야 할 내용을 선언한다. - 사용할 모델 - 필요한 스킬 - 실행 샌드박스 - 시스템 지침 - 별도의 오케스트레이션 루프를 직접 작성하지 않아도 에이전트가 주어진 작업을 자율적으로 수행한다. - 예를 들어 버그 리포트를 받아 샌드박스에서 재현하고 원인을 진단하는 에이전트를 25줄 이하로 작성할 수 있다. ## 개발자 도구와 외부 서비스 통합 - **Channels** - Slack, GitHub, Linear, Discord 등에 에이전트를 연결한다. - 이벤트 검증과 디스패치에 필요한 반복적인 보일러플레이트를 대신 처리한다. - **헤드리스 실행과 UI 연동** - 백그라운드 작업에서는 완전히 헤드리스로 실행할 수 있다. - `@flue/react`를 사용하면 에이전트 상태, 도구 실행, 실시간 메시지를 프론트엔드로 스트리밍할 수 있다. - 별도의 실시간 통신 인프라를 직접 구축할 필요를 줄인다. - **CLI 기반 생태계 확장** - `flue add channel slack` 같은 명령으로 통합 기능을 추가한다. - 생성된 Markdown blueprint를 코딩 에이전트가 읽고 수정해 기존 코드베이스에 통합할 수 있다. ## Durable Streams를 통한 장애 복구 - 에이전트 실행은 모델 응답 스트리밍, 도구 호출, 도구 결과 대기, 사용자 승인, 하위 에이전트 위임 등 여러 단계로 구성된다. - 호스트 장애, LLM API 타임아웃, 프로세스 재시작이 발생하면 메모리에 있던 실행 상태가 사라질 수 있다. - Flue는 **Durable Streams**를 사용해 실행 이력을 append-only 로그로 기록한다. - 프롬프트 - 도구 응답 - 모델 선택 - 기타 실행 이벤트 - 각 이벤트를 변경할 수 없는 원장처럼 저장하므로 프로세스가 종료되어도 다른 프로세스가 마지막 로그부터 실행을 이어갈 수 있다. - 결과적으로 에이전트가 작업 중이던 정확한 단계에서 복구되고, 사용자가 영원히 끝나지 않는 로딩 상태를 보는 문제를 줄인다. ## 다양한 환경에 배포하는 방식 - Node.js에서는 에이전트를 장시간 실행되는 프로세스로 배포할 수 있다. - VM, 컨테이너, GitHub Actions, 기존 서버 등에 배포할 수 있어 멀티클라우드 구성이 가능하다. - Cloudflare 환경에서는 각 Flue 에이전트가 하나의 **Durable Object**로 실행된다. - 에이전트별 독립적인 컴퓨트와 스토리지를 제공한다. - 필요한 에이전트 수만큼 자동 확장할 수 있다. - 서버 프로비저닝, sticky session, noisy neighbor 문제를 신경 쓰지 않아도 된다. ## Cloudflare Agents SDK의 실행 primitives - Cloudflare에 배포된 Flue는 Agents SDK의 다음 기능을 사용해 내구성 있는 실행을 구현한다. - `runFiber()`: 에이전트 실행을 중단·복구 가능한 작업 단위로 관리 - `stash()`: 실행 중인 상태를 보존 - `onFiberRecovered()`: 복구된 실행을 다시 처리 - `@cloudflare/codemode`와 `@cloudflare/shell`을 활용해 샌드박스 안에서 코드를 실행한다. - 이 코드는 Durable Workspace와 결합되어 에이전트가 지속적으로 사용할 수 있는 작업 공간을 제공한다. ## 하네스가 플랫폼에 요구하는 것 - 에이전트 턴은 단순한 단일 HTTP 요청이 아니라 수초에서 수분간 이어지는 상태ful한 실행이다. - 실행 중 다음과 같은 단계가 발생할 수 있다. - 모델 토큰 스트리밍 - 도구 호출 - 도구 결과 대기 - 사람의 승인 요청 - 하위 에이전트 위임 - 프로세스가 중단되면 스트리밍 연결, 대기 중인 도구 호출, 현재 실행 위치 등 메모리 상태가 사라진다. - 대화 기록만 디스크에 저장되어 있어도 사용자는 완료되지 않는 스피너를 보게 되므로 충분하지 않다. - 따라서 현대적인 하네스에는 실행 중간 상태를 체크포인트로 저장하고 장애 후 이어서 실행할 수 있는 **durable execution**이 필수다. - 글은 Cloudflare Agents SDK의 Fiber가 이러한 체크포인트와 복구를 위한 네이티브 메커니즘을 제공한다고 설명하기 시작하며, 이후 세부 동작은 제공된 본문에서 이어지지 않는다. 에이전트를 실제 서비스로 운영하려면 모델 호출 로직만 구현해서는 부족하다. Flue 같은 프레임워크로 개발 경험과 통합을 단순화하고, Pi 같은 하네스로 에이전트 루프를 처리하며, Durable Objects와 Durable Streams 같은 플랫폼 primitives로 상태 보존·장애 복구·안전한 코드 실행을 확보하는 구성이 실용적이다.

durable-objectscloudflare-agents-sdkdurable-executionflue+3

cloudflare2026년 5월 13일

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를 사용하고, 빈번한 상태 갱신은 큐와 배치 쓰기로 분리하는 설계가 효과적인 접근이다.

durable-objectscloudflare-workerssqlitewebsockets+4

cloudflare2026년 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월 초 공개 베타 전환이 예정되어 있으므로 에이전트 세션 관리나 동적 환경 구축이 필요한 팀은 도입을 적극 검토해 보시기 바랍니다.

durable-objectsdatabase-designtypescriptcloudflare-workers+4

cloudflare2026년 4월 15일

Project Think: Cloudflare에서 차세대 AI 에이전트 구축하기 (새 탭에서 열림)

Cloudflare는 차세대 AI 에이전트 구축을 위한 새로운 프레임워크인 'Project Think'를 공개했습니다. 이 프로젝트는 단순한 도구 모음을 넘어 내구성 있는 실행(Durable execution), 하위 에이전트 관리, 샌드박스 코드 실행 등을 포함한 강력한 프리미티브(Primitives)를 제공하여 에이전트가 중단 없이 장시간 작업을 수행할 수 있도록 돕습니다. 이를 통해 기존 에이전트의 높은 유지 비용과 확장성 문제를 해결하고, 인프라 수준에서 스스로 사고하고 동작하는 에이전트 환경을 구축하는 것을 목표로 합니다. ### 기존 에이전트 모델의 한계와 확장성 문제 * **로컬 및 고비용 환경의 제약:** 현재의 코딩 에이전트들은 주로 개인 노트북이나 비싼 VPS에서 실행되어 기기 간 협업이나 상태 공유가 어렵고, 사용하지 않을 때도 고정적인 비용이 발생합니다. * **1대1 서비스 구조의 비효율성:** 일반적인 앱은 하나의 인스턴스가 다수의 사용자를 처리하지만, 에이전트는 사용자 한 명당 하나의 인스턴스가 할당되는 '개인 셰프'와 같은 구조를 가집니다. 이는 수천만 명의 사용자를 대응할 때 기존 컨테이너 기반 방식으로는 비용 감당이 불가능함을 의미합니다. * **관리의 복잡성:** 의존성 설치, 업데이트 관리, 비밀번호 및 아이디 설정 등 수동으로 관리해야 할 요소가 많아 대규모 배포에 걸림돌이 됩니다. ### Durable Objects 기반의 지속성 아키텍처 * **액터 모델(Actor Model) 채택:** Cloudflare의 Durable Objects를 기반으로 각 에이전트에 고유한 식별자와 자체 SQLite 데이터베이스를 부여합니다. * **비용 최적화:** 에이전트가 활동하지 않을 때는 휴면(Hibernation) 상태로 전환되어 컴퓨팅 비용이 발생하지 않으며, 이벤트(HTTP, 이메일, 알람 등)가 발생할 때만 즉시 깨어나 상태를 로드합니다. * **자동 확장성:** 별도의 용량 관리 없이 수만 개의 에이전트를 동시에 운영할 수 있으며, 각 에이전트는 독립적인 상태와 로직을 유지합니다. ### Project Think의 핵심 기술 프리미티브 * **Fibers를 이용한 내구성 있는 실행:** `runFiber()` 함수를 통해 실행 중인 작업을 SQLite에 등록하고, `stash()`로 체크포인트를 설정하여 시스템 충돌이나 재시작 후에도 중단된 지점부터 작업을 재개할 수 있습니다. * **샌드박스 및 동적 실행:** Dynamic Workers를 활용해 에이전트가 안전한 격리 환경 내에서 직접 코드를 작성하고 실행할 수 있도록 지원하며, 런타임에 필요한 npm 패키지를 직접 해결합니다. * **계층 구조의 에이전트:** 하위 에이전트(Sub-agents)를 생성하여 복잡한 작업을 분담할 수 있으며, 이들은 각자의 SQLite 데이터베이스와 타입화된 RPC를 통해 부모 에이전트와 통신합니다. * **지능형 세션 관리:** 트리 구조의 메시지 기록, 포킹(forking), 컴팩션 및 전문 검색 기능을 제공하여 에이전트가 과거의 맥락을 정확하게 파악하고 활용할 수 있게 합니다. 프로젝트 Think는 에이전트를 단순히 '실행되는 프로그램'이 아니라 '지속되는 인프라'로 격상시킵니다. 대규모 사용자에게 맞춤형 AI 비서를 저렴한 비용으로 제공하고자 하는 개발자라면, Cloudflare Agents SDK의 내구성 있는 실행 모델과 액터 기반 아키텍처를 도입하여 복구 가능하고 확장성 있는 에이전트 서비스를 설계해 보시기 바랍니다.

durable-objectsdatabase-designsqliteagents-sdk+4

cloudflare2026년 4월 15일

에이전틱 시대를 위한 워크플로 컨트롤 플레인 재설계 (새 탭에서 열림)

Cloudflare의 워크플로우(Workflows) 컨트롤 플레인 재설계 과정을 다룬 이 글은, 인간 중심의 트리거에서 AI 에이전트 중심의 고속 트리거로 변화하는 기술 환경에 대응하기 위한 아키텍처 전환을 설명합니다. 기존의 중앙 집중식 구조에서 발생하는 병목 현상을 해결하기 위해 수평적 확장이 가능한 새로운 컴포넌트를 도입하였으며, 이를 통해 동시 실행 인스턴스 수를 기존 대비 10배 이상인 50,000개까지 확장하는 데 성공했습니다. 결과적으로 에이전트가 생성하는 방대한 양의 워크로드를 안정적이고 탄력적으로 처리할 수 있는 기반을 마련했습니다. ### 에이전트 시대의 워크로드 변화와 새로운 요구사항 * **트리거 주체의 변화:** 과거에는 사용자의 회원가입이나 주문 등 인간의 행동에 의해 워크플로우가 시작되었으나, 현재는 자율적인 AI 에이전트가 기계적인 속도로 워크플로우를 생성합니다. * **지속성 및 내구성의 중요성:** 에이전트가 며칠 동안 작업을 수행하거나 인간의 승인을 기다리는 동안, 워크플로우는 각 단계를 독립적으로 재시도하고 실패 시에도 진행 상황을 유지하는 내구성이 필요합니다. * **폭발적인 인스턴스 생성:** 단일 에이전트 세션이 수십 개의 워크플로우를 생성하고 수천 개의 인스턴스가 동시에 실행되는 환경에 대응하기 위해 더 높은 처리량이 요구됩니다. ### V1 아키텍처의 한계: 중앙 집중형 구조의 병목 * **단일 Durable Object(DO) 의존:** 모든 계정 레벨의 정보와 인스턴스 관리를 'Account'라는 단일 Durable Object가 담당하여 병목 현상이 발생했습니다. * **확장성 제약:** 인스턴스 생성, 업데이트, 조회 등의 모든 작업이 하나의 DO를 거쳐야 했으므로, 동시 실행 4,500개 및 10초당 100개의 생성 제한이라는 물리적인 한계에 부딪혔습니다. * **상태 불일치 가능성:** 워크플로우를 큐에 넣기 전 실제 실행 엔진(Engine)의 생성 여부를 확인하는 로직이 부족하여 비정상적인 상태가 발생할 가능성이 있었습니다. ### V2 아키텍처: 수평적 확장을 위한 재설계 원칙 * **엔진 중심의 진실 공급원(Source of Truth):** 특정 인스턴스의 존재 여부에 대한 권한을 해당 인스턴스의 실행 엔진(Engine)에만 부여하여 의존성을 분산했습니다. * **메타데이터의 최소화:** 계정 수준의 싱글톤(Singleton) 객체는 최소한의 메타데이터만 저장하고, 요청 수에 관계없이 일정한 성능을 유지하도록 설계했습니다. * **새로운 컴포넌트 도입:** 'Account' DO의 부하를 분산하기 위해 메타데이터와 생명주기 관리를 보조하는 **SousChef**와 동시성 제어 및 액세스를 담당하는 **Gatekeeper**를 새롭게 구축했습니다. ### 향상된 성능 지표 및 확장된 한계치 * **동시 실행 인스턴스:** 기존 4,500개에서 **50,000개**로 대폭 상향되었습니다. * **인스턴스 생성 속도:** 계정당 초당 100개에서 **초당 300개**로 향상되었습니다. * **대기열 용량:** 워크플로우당 대기 중인 인스턴스 수가 100만 개에서 **200만 개**로 두 배 늘어났습니다. AI 에이전트가 주도하는 애플리케이션을 구축하는 개발자라면, 이제 인프라의 한계에 구애받지 않고 고도로 병렬화된 워크플로우를 설계할 수 있습니다. Cloudflare Workflows의 V2 컨트롤 플레인은 대규모 자동화 인프라를 위한 강력하고 탄력적인 토대를 제공합니다.

durable-objectsdatabase-designsqlitescalability+3

cloudflare2026년 4월 13일

동적 워커의 Durable Objects: AI가 생성한 각 앱에 자체 데이터베이스를 제공하세요 (새 탭에서 열림)

Cloudflare는 AI가 생성한 애플리케이션에 독립적인 영구 저장소를 제공하기 위해 'Durable Object Facets' 기능을 출시했습니다. 이 기능은 가볍고 빠른 Dynamic Workers 환경에서 AI 코드가 자신만의 전용 SQLite 데이터베이스를 가질 수 있게 하여, 일회성 실행을 넘어 상태를 유지하는 복잡한 앱 구축을 가능하게 합니다. 개발자는 이를 통해 동적으로 생성된 코드에 대해 제로 레이턴시 수준의 저장소 성능과 체계적인 관리 권한을 동시에 확보할 수 있습니다. ### Dynamic Workers와 상태 관리의 필요성 * **Isolate 기반의 효율성:** Dynamic Workers는 컨테이너가 아닌 Isolate 기술을 사용하여 기존 방식보다 100배 빠르고 메모리 사용량은 1/10 수준으로 가볍습니다. * **일회성 실행의 한계:** 기존에는 AI 에이전트가 생성한 코드를 즉시 실행하고 버리는 용도로 주로 사용되었으나, 사용자 상호작용이 필요한 앱을 만들려면 장기적인 상태(State) 저장이 필수적입니다. * **스토리지 대안:** 원격 SQL 데이터베이스(D1, Postgres 등)를 연결할 수도 있지만, 더 빠르고 밀접한 데이터 처리를 위해 Durable Object의 로컬 SQLite 활용이 제안되었습니다. ### 기존 Durable Objects의 제약 사항 * **정적 설정의 한계:** 일반적인 Durable Object는 코드 작성 후 API를 통한 프로비저닝과 Wrangler 설정이 필요하며, 이는 실시간으로 코드가 생성되는 동적 환경에는 적합하지 않습니다. * **통제 및 관리 문제:** AI나 사용자가 생성한 코드가 무제한으로 스토리지를 생성하거나 사용하는 것을 방지하기 위해 로깅, 과금, 리소스 제한 등을 수행할 '감독자(Supervisor)' 역할이 필요합니다. ### Durable Object Facets의 구조와 작동 방식 * **Facets 개념 도입:** 개발자가 작성한 고정된 Durable Object(관리자) 내에서 AI가 생성한 Dynamic Worker 코드를 'Facet'이라는 하위 단위로 로드하고 인스턴스화합니다. * **독립된 SQLite 데이터베이스:** 각 Facet은 관리자의 데이터베이스와 분리된 자신만의 SQLite 데이터베이스를 할당받습니다. 이를 통해 일반적인 Durable Object 스토리지 API(kv, sql)를 그대로 사용할 수 있습니다. * **감독자 패턴(Supervisor Pattern):** 모든 요청은 먼저 관리자 Durable Object를 거쳐 Facet으로 전달되므로, 개발자는 요청 전달 전에 로깅, 보안 검사, 할당량 제한 등의 로직을 실행할 수 있습니다. * **코드 구현:** `this.ctx.facets.get()` 메서드를 사용하여 동적 클래스를 인스턴스로 만들고, RPC(원격 프로시저 호출)나 HTTP 요청을 통해 해당 Facet과 통신합니다. AI 기반의 맞춤형 앱 플랫폼이나 사용자 정의 로직을 실행해야 하는 SaaS를 구축한다면, Durable Object Facets를 활용해 보시기 바랍니다. 이를 통해 인프라 설정의 번거로움 없이 각 사용자 앱마다 독립적이고 성능이 뛰어난 전용 데이터베이스를 즉시 제공할 수 있으며, 관리자 계층을 통해 시스템 안정성과 가시성을 동시에 확보할 수 있습니다.

durable-objectsdatabase-designcloudflarepostgresql+3

cloudflare2026년 2월 3일

R2 로컬 업로드로 글로벌 (새 탭에서 열림)

Cloudflare는 전 세계 어디에서나 R2 객체 스토리지의 업로드 성능을 극대화할 수 있는 'Local Uploads' 기능을 오픈 베타로 출시했습니다. 이 기능은 클라이언트와 가장 가까운 위치에 데이터를 먼저 기록한 뒤 버킷이 위치한 지역으로 비동기 복제하는 방식을 통해, 지리적 거리로 인한 업로드 지연 시간을 최대 75%까지 단축합니다. 특히 데이터의 즉각적인 접근성과 강력한 일관성을 유지하면서도 글로벌 서비스의 쓰기 성능을 획기적으로 개선한 것이 핵심입니다. ### 전 세계 업로드 성능의 비약적 향상 * **TTLB(Time to Last Byte) 감축**: 내부 테스트 결과, 클라이언트와 버킷의 지역이 다를 때 업로드 완료까지 걸리는 시간이 최대 75% 감소했습니다. * **성능 벤치마크**: 북미 서부에서 아시아 태평양 지역 버킷으로 5MB 크기의 객체를 업로드할 때, 기존 약 2초 소요되던 시간이 Local Uploads 적용 후 약 500ms 수준으로 단축되었습니다. * **글로벌 사용자 경험 최적화**: 전 세계에 분산된 사용자로부터 미디어 콘텐츠를 수집하거나 IoT 장치의 로그 및 텔레메트리 데이터를 전송받는 애플리케이션에 이상적입니다. ### 데이터 처리 메커니즘과 거리 문제 해결 * **기존 방식의 한계**: 기존에는 사용자가 어디에 있든 데이터가 버킷이 지정된 지역의 스토리지까지 물리적으로 이동해야 했으므로, 거리가 멀수록 대기 시간과 불안정성이 증가했습니다. * **로컬 우선 쓰기**: 클라이언트가 버킷과 다른 지역에 있을 경우, R2 게이트웨이는 데이터를 클라이언트 인근 스토리지 인프라에 즉시 기록하고 메타데이터만 버킷 지역에 게시합니다. * **즉각적인 가용성**: 로컬에 쓰기가 완료되는 즉시 객체에 접근할 수 있으며, 배경에서 복제 작업이 진행되는 중에도 데이터 읽기가 가능해 대기 시간이 전혀 없습니다. ### 아키텍처 및 내부 구현 기술 * **Cloudflare Queues 활용**: 복제 작업(Replication Task)을 비동기적으로 처리하기 위해 Cloudflare Queues를 도입했습니다. 이를 통해 실패 시 재시도 처리와 부하 조절(Rate limiting)을 효율적으로 관리합니다. * **원자적 작업 처리**: 메타데이터 저장 시 객체 메타데이터 저장, 보류 중인 복제 키 생성, 복제 작업 마커 생성을 원자적(Atomic)으로 수행하여 데이터 무결성을 보장합니다. * **구성 요소**: 인증과 라우팅을 담당하는 'R2 Gateway Worker', 메타데이터를 관리하는 'Durable Object Metadata Service', 그리고 실제 암호화된 데이터를 저장하는 분산 스토리지 인프라가 협업합니다. ### 사용 환경 및 권장 사항 * **적용 방법**: Cloudflare 대시보드 설정이나 Wrangler 명령(`npx wrangler r2 bucket local-uploads enable [BUCKET]`)을 통해 기존 버킷에서 즉시 활성화할 수 있습니다. * **제한 사항**: 데이터 주권 준수가 필요한 지역 제한(Jurisdiction restriction, 예: EU 전용) 버킷에서는 이 기능을 사용할 수 없습니다. * **활용 팁**: 대시보드의 R2 버킷 메트릭 페이지에서 '지역별 요청 분포'를 확인하여, 읽기/쓰기 요청이 전 세계적으로 분산되어 있다면 Local Uploads를 활성화하는 것이 성능 최적화에 큰 도움이 됩니다.

durable-objectscloudflare-workerscloudflare-r2object-storage+4

cloudflare2026년 1월 27일

서버리스, 양자 내 (새 탭에서 열림)

전통적인 Matrix 홈서버는 데이터베이스, 캐싱, 리버스 프록시 등 복잡한 인프라 관리 부담이 크지만, 이를 Cloudflare Workers 기반의 서버리스 아키텍처로 전환함으로써 운영 부담을 획기적으로 줄일 수 있습니다. 이 방식은 사용량에 비례해 비용이 발생하여 유휴 상태에서는 비용이 거의 들지 않으며, 전 세계 엣지 노드에서 실행되어 낮은 지연 시간을 보장합니다. 특히 양자 내성 암호(PQC)를 기본 TLS 계층에 적용하여 미래의 보안 위협에 선제적으로 대응할 수 있는 고도의 보안성을 갖춘 것이 특징입니다. **서버리스 아키텍처로의 전환** - 기존 Python 기반의 Synapse 홈서버 구성을 TypeScript와 Hono 프레임워크를 사용하는 Cloudflare Workers 환경으로 재설계했습니다. - 데이터 저장소의 경우, PostgreSQL은 D1으로, Redis 캐싱은 KV로, 파일 시스템은 R2(Object Storage)로 각각 대체하여 서버리스 환경에 최적화했습니다. - 강력한 일관성과 원자성이 필요한 Matrix 상태 결정(State Resolution) 및 실시간 조율 로직은 Cloudflare Durable Objects를 활용해 해결했습니다. **운영 및 비용의 효율성** - 서버 프로비저닝, TLS 인증서 갱신, 로드 밸런싱 등의 복잡한 작업이 `wrangler deploy`라는 단일 명령어로 단순화되었습니다. - 고정 비용이 발생하는 VPS 방식과 달리, 실제 요청이 있을 때만 비용을 지불하는 구조를 통해 개인용 서버 운영 비용을 0에 가깝게 낮출 수 있습니다. - 전 세계 300개 이상의 지역에 분포된 엣지에서 코드가 실행되므로, 사용자의 위치와 상관없이 지연 시간이 최소화됩니다. **양자 내성 암호(PQC) 기반의 이중 보안** - Cloudflare의 하이브리드 양자 내성 키 합의 알고리즘(X25519MLKEM768)을 TLS 1.3 연결에 적용하여, 미래의 양자 컴퓨터 공격으로부터 데이터를 보호합니다. - 보안은 전송 계층(TLS)의 양자 내성 암호와 애플리케이션 계층(Megolm)의 종단간 암호화(E2EE)라는 이중 레이어로 구성됩니다. - 서버 운영자나 인프라 제공자는 메시지 메타데이터는 확인할 수 있지만, 메시지 본문은 발신자와 수신자의 기기에서만 복호화가 가능하므로 내용의 기밀성이 완벽하게 보장됩니다. **데이터 모델 및 저장소 설계** - **D1(SQL):** 사용자, 방, 이벤트, 장치 키 등 구조화된 데이터 모델링을 위해 25개 이상의 테이블을 운영하며 데이터의 영속성을 보장합니다. - **KV(Key-Value):** 세션 관리 및 캐싱 등 빠른 읽기 속도가 필요한 데이터를 처리합니다. - **R2:** 암호화된 미디어 파일 및 대용량 바이너리 데이터를 저장하는 오브젝트 스토리지 역할을 수행합니다. 이 프로젝트는 개인 개발자나 보안이 중요한 조직이 관리 부담 없이 안전하고 확장 가능한 통신 인프라를 구축할 수 있는 실무적인 대안을 제시합니다. 특히 복잡한 암호화 라이브러리를 직접 관리하지 않고도 최신 보안 표준을 누릴 수 있다는 점이 큰 장점입니다.

durable-objectstypescriptcloudflare-workersserverless+4