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 데이터, 조회 조건, 분석 과정을 함께 확인하는 방식으로 사용하는 것이 적절하다.

sqlitellmcloudflare-workersdurable-objects+3

cloudflare2026년 8월 6일

Kitesurf 소개: Cloudflare Workers의 V8 격리 환경에서 실행되는 에이전트 우선 브라우저 (새 탭에서 열림)

Cloudflare는 인간이 아닌 AI 에이전트에 최적화된 브라우저가 필요하다고 판단해, Workers 위에서 동작하는 헤드리스 브라우저 **Kitesurf**를 개발했다. Chromium이 제공하는 탭·확장 기능·정밀한 시각 렌더링보다 토큰 수, 확장성, 성능, 비용, 구조화된 콘텐츠 추출을 우선하며, 일반적인 에이전트 작업에서 CPU와 메모리 사용량을 크게 줄이는 것이 목표다. Kitesurf는 Browser Run에서 베타 서비스로 무료 제공된다. ## AI 에이전트에 기존 브라우저가 과한 이유 - Chromium 같은 브라우저 엔진은 인간 사용자를 중심으로 설계됐다. - AI 에이전트에는 다음 기능의 가치가 낮다. - 탭, 테마, 브라우저 확장 기능 - 여러 기기 간 동기화 - 픽셀 단위로 정확한 렌더링 - 부드러운 60fps 스크롤 - 반대로 에이전트에는 다음 요소가 중요하다. - 적은 토큰 수와 효율적인 컨텍스트 사용 - HTML 등 구조화된 콘텐츠 - 높은 처리량과 확장성 - 낮은 CPU·메모리 사용량과 비용 - AI 브라우저의 위협 모델도 인간용 브라우저와 다르다. - 임의의 웹사이트를 방문하는 에이전트는 모든 페이지를 신뢰할 수 없는 입력으로 다뤄야 한다. - 프롬프트 인젝션과 도구 사용 안전성이 핵심 보안 문제가 된다. ## Cloudflare 플랫폼이 가능하게 한 전환점 - Kitesurf는 Cloudflare Workers 위에서 전체적으로 실행된다. - 다음 기술 발전이 복잡한 브라우저 구현을 가능하게 했다. - Workers에서의 성숙한 WebAssembly 지원 - 동적 워커 - SQLite 기반 Durable Objects - 워커 간 RPC - 서비스 바인딩 - 향상된 Node.js 호환성 - 더 높은 실행 한도 - AI 에이전트용 브라우저 자동화 수요가 커지면서, 기존 Chromium 인스턴스를 에이전트마다 제공하는 방식의 비용 문제가 부각됐다. - Kitesurf는 이러한 환경에서 더 작고 저렴한 브라우저 실행 모델을 제공하려는 시도다. ## 초기 구현과 AI 활용 - 출발점은 Rust로 작성된 AI 자동화용 헤드리스 엔진 **obscura**였다. - Cloudflare 팀은 AI 에이전트의 도움을 받아 이를 Workers로 포팅했다. - 초기 결과는 불완전했지만, 명확한 실행 계획과 성공 조건을 제공하자 AI가 반복적으로 구현·검증하며 작동하는 프로토타입을 만들 수 있었다. - 이후 프로토타입을 기반으로 실제 대규모 서비스에 필요한 구조와 품질 기준을 마련했다. ## 테스트를 중심으로 한 개발 방식 - 복잡한 브라우저를 AI의 도움으로 빠르게 개발하려면, 구현 속도뿐 아니라 결과 품질을 통제해야 했다. - 이를 위해 가능한 많은 테스트를 성공 기준으로 제공했다. - **Web Platform Tests(WPT)**를 활용해 다음을 검증했다. - 웹 표준에 대한 기능 준수 여부 - 각 브라우저 기능의 구현 상태 - AI 에이전트가 작업을 완료했는지 판단할 수 있는 명확한 기준 - WPT만으로는 실제 웹사이트에서의 동작을 충분히 검증할 수 없기 때문에 추가 테스트도 도입했다. - Chromium과 Kitesurf 양쪽에서 실제 사이트를 대상으로 Puppeteer 통합 테스트 실행 - 여러 단계의 사용자 작업과 assertion 비교 - 각 단계의 렌더링 결과를 비교하는 시각적 회귀 테스트 - 예상하지 못한 렌더링 차이를 자동으로 표시 - AI 에이전트는 기능 구현을 담당하고, 사람은 아키텍처 설계와 구현 방식 검토에 집중하는 방식이다. ## Rust와 WebAssembly 선택 - Cloudflare는 C, C++, Rust 코드를 WebAssembly로 컴파일해 Workers에서 실행할 수 있다. - Emscripten을 사용하면 많은 의존성과 모의 계층이 추가되어 결과 바이너리가 커지고 실행이 느려질 수 있다. - Kitesurf는 가능한 한 네이티브 Rust로 구현하고 `wasm-bindgen`을 통해 WebAssembly로 직접 컴파일했다. - 이를 통해 불필요한 에뮬레이션 계층을 피하고, 성능과 안정성을 높였다. ## 예외 처리와 장애 격리 - 웹페이지는 잘못된 HTML, 예상 밖의 입력, 악의적인 콘텐츠를 포함할 수 있으므로 브라우저는 일부 기능이 실패해도 세션 전체를 중단해서는 안 된다. - Kitesurf의 원칙은 다음과 같다. - 오류가 발생하면 죽은 세션 대신 빈 프레임이나 누락된 요소로 처리 - 모든 경계에서 예외를 포착 - 안전하고 비어 있는 기본값 사용 - 문제를 진단할 수 있을 만큼 충분한 로그 기록 - 목표는 페이지 일부가 손상되더라도 브라우저 요청 자체는 계속 유지하는 것이다. ## 페이지와 컴포넌트의 격리 - AI 에이전트는 작업에 따라 임의의 출처에서 코드를 실행하거나 페이지를 방문할 수 있다. - 따라서 모든 페이지 로드를 신뢰할 수 없는 입력으로 취급하고, 모든 세션을 새로 시작한다. - 각 컴포넌트는 필요한 리소스에만 접근하도록 제한한다. - Workers의 격리 모델이 기본적인 보안 경계를 제공하지만, 그것만으로 충분하지 않다. - 애플리케이션 수준에서도 컴포넌트별 접근 권한을 정의해야 한다. - 한 페이지의 데이터나 리소스가 다른 페이지로 유출되지 않도록 별도로 보장해야 한다. ## 가능한 한 무상태로 설계 - 상태가 많을수록 장애 발생 후 복구 비용이 커진다. - 무상태 컴포넌트는 다음 장점을 가진다. - 실패하면 새 인스턴스를 만들고 요청을 다시 재생하면 됨 - 필요할 때 병렬로 대량 실행 가능 - 멈춘 인스턴스를 즉시 폐기 가능 - 트래픽이 급증하는 자동화 작업에 맞춰 수요 기반으로 확장 가능 - 사용한 만큼만 비용을 지불하고 작업 종료 후 리소스를 제거 가능 - 따라서 상태가 꼭 필요하지 않은 컴포넌트는 가능한 한 무상태로 구현한다. ## 실용적인 결론 AI 브라우저는 인간용 브라우저를 그대로 축소하는 것이 아니라, 구조화된 데이터 처리·낮은 비용·높은 확장성·강한 격리를 중심으로 다시 설계해야 한다. 브라우저 자동화 서비스를 구축할 때는 표준 테스트뿐 아니라 실제 사이트 통합 테스트와 시각적 회귀 테스트를 병행하고, Rust/WebAssembly·무상태 설계·방어적인 예외 처리를 활용하는 것이 효과적이다.

sqliteai-agentcloudflare-workersrust+4

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

sqliteobservabilitycloudflare-workersdurable-objects+4

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

sqlitecloudflare-workersdurable-objectswebsockets+4

cloudflare2026년 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가 최적의 대안이 될 것입니다. 이 시스템을 통해 인프라 관리의 부담 없이 테넌트별로 특화된 내구성 있는 워크플로우를 무한히 확장할 수 있습니다.

sqlitedatabase-designtypescriptcloudflare-workers+4

cloudflare2026년 4월 20일

에이전트형 클라우드 구축: Agents Week 2026에서 출시한 모든 것 (새 탭에서 열림)

Cloudflare는 인공지능 에이전트가 주요 워크로드로 자리 잡는 미래를 위해 기존의 클라우드 구조를 재정의한 'Cloud 2.0(에이전트 클라우드)' 비전을 제시했습니다. 수천만 개의 에이전트 세션이 동시에 실행될 수 있도록 연산 인프라부터 보안, 도구 모음까지 스택 전반에 걸친 대대적인 신규 기능들을 공개했습니다. 이를 통해 개발자들은 단순한 프로토타입을 넘어 확장성과 보안을 갖춘 에이전트 기반 애플리케이션을 생산 환경에서 구현할 수 있게 되었습니다. **에이전트 전용 연산 환경 및 워크플로우** * **Git 호환 저장소 'Artifacts':** 에이전트가 생성한 코드와 데이터를 관리하기 위해 수천만 개의 레포지토리를 생성할 수 있고, 표준 Git 클라이언트와 연동되는 버전 관리 저장소를 제공합니다. * **격리된 실행 환경 'Sandboxes' (GA):** 에이전트에게 셸, 파일 시스템, 백그라운드 프로세스를 갖춘 독립된 컴퓨터 환경을 제공하며, 작업 중단 지점부터 즉시 재개할 수 있는 영속성을 보장합니다. * **상태 저장 및 확장성:** 'Durable Object Facets'를 통해 에이전트가 생성한 앱마다 독립된 SQLite 데이터베이스를 할당하며, 개선된 워크플로우 엔진으로 최대 50,000개의 동시 실행을 지원합니다. **에이전트를 위한 보안 및 ID 관리** * **Cloudflare Mesh:** 에이전트가 프라이빗 네트워크 내의 데이터베이스나 API에 안전하게 접근할 수 있도록 제로 트러스트 기반의 비공개 네트워크 연결을 지원합니다. * **Managed OAuth:** 에이전트가 보안상 취약한 서비스 계정 대신, 사용자를 대행해 내부 애플리케이션에 안전하게 인증하고 탐색할 수 있는 체계를 구축했습니다. * **비인간 식별자(Non-human Identity) 보호:** 에이전트용 API 토큰의 권한 범위를 세밀하게 제어하고 자동 취소 기능을 도입하여 자격 증명 유출에 따른 리스크를 최소화했습니다. **에이전트의 사고와 소통을 돕는 툴박스** * **다중 채널 소통 지원:** 실시간 음성 상호작용(STT/TTS) 기능을 약 30줄의 코드로 구현할 수 있게 되었으며, 이메일을 직접 송수신하고 처리할 수 있는 'Cloudflare Email Service' 베타를 출시했습니다. * **추론 성능 및 효율 최적화:** LLM의 품질 저하 없이 모델 크기를 22% 압축하는 'Unweight' 기술을 도입하여 더 빠르고 경제적인 추론 인프라를 구축했습니다. * **통합 추론 및 기억:** 14개 이상의 모델 공급자를 연결하는 통합 추론 레이어와 함께, 에이전트가 과거의 맥락을 기억하고 지속적으로 학습할 수 있는 'Agent Memory' 서비스를 제공합니다. 이번 발표는 에이전트가 단순히 텍스트를 생성하는 도구를 넘어, 독립적인 실행 환경과 보안 권한을 가지고 업무를 수행하는 '실행 주체'로 거듭나도록 돕는 데 초점이 맞춰져 있습니다. 대규모 에이전트 시스템을 구축하려는 팀이라면 Cloudflare가 제공하는 Sandboxes와 Mesh 기반의 보안 아키텍처를 활용하여 인프라 구축 비용과 보안 리스크를 획기적으로 낮출 수 있을 것입니다.

sqlitecloudflareserverlessgit+4

cloudflare2026년 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의 에지 기반 평가 모델이 제공하는 속도와 안정성을 적극적으로 검토해 볼 가치가 있습니다.

sqlitedatabase-designcloudflare-workersedge-computing+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의 내구성 있는 실행 모델과 액터 기반 아키텍처를 도입하여 복구 가능하고 확장성 있는 에이전트 서비스를 설계해 보시기 바랍니다.

sqlitedatabase-designdurable-objectsagents-sdk+4

cloudflare2026년 4월 15일

에이전트에 음성 추가하기 (새 탭에서 열림)

Cloudflare는 기존 Agents SDK에 실시간 음성 기능을 통합할 수 있는 실험적 라이브러리인 `@cloudflare/voice`를 공개했습니다. 이 도구를 사용하면 별도의 음성 전용 프레임워크로 옮길 필요 없이, 기존의 Durable Object 아키텍처와 WebSocket 연결 모델을 그대로 유지하면서 에이전트에 음성 인터페이스를 추가할 수 있습니다. 이를 통해 개발자는 텍스트와 음성 입력을 동일한 상태 공간에서 처리하고 SQLite를 통해 대화 이력을 영속적으로 관리하는 고도화된 음성 에이전트를 구축할 수 있게 됩니다. **@cloudflare/voice의 주요 구성 요소 및 기능** * **고차 에이전트 함수**: 전체 음성 대화를 지원하는 `withVoice(Agent)`와 음성을 텍스트로 변환하는 기능만 제공하는 `withVoiceInput(Agent)`을 통해 용도에 맞는 에이전트를 설계할 수 있습니다. * **React 및 클라이언트 지원**: React 앱에서 음성 상태와 전사 내용을 쉽게 관리할 수 있는 `useVoiceAgent`, `useVoiceInput` 훅과 프레임워크에 구애받지 않는 `VoiceClient`를 제공합니다. * **내장 Workers AI 제공자**: 외부 API 키 설정 없이도 즉시 시작할 수 있도록 Deepgram Flux 및 Nova 3(실시간 STT), Deepgram Aura(TTS) 등 Cloudflare Workers AI 기반의 엔진을 기본 지원합니다. * **개방형 인터페이스**: 특정 기술 스택에 종속되지 않도록 인터페이스를 작게 설계하여, 개발자가 필요에 따라 다양한 음성, 통신, 전송 계층 제공자를 선택하고 조합할 수 있습니다. **서버 및 클라이언트 구현 방식** * **서버 측 로직**: `Agent` 클래스를 `withVoice`로 감싸고, `onTurn()` 메서드 내에서 사용자 발화에 대한 응답 로직을 작성합니다. 이때 전사기(Transcriber)와 TTS 인스턴스를 설정에 추가하는 것만으로 음성 에이전트 서버가 완성됩니다. * **클라이언트 측 연결**: 단일 WebSocket을 통해 16kHz 모노 PCM 오디오 데이터를 스트리밍하며, 클라이언트 라이브러리는 통화 상태(status), 실시간 전사(transcript), 음소거(mute) 기능 등을 자동으로 관리합니다. * **통합 아키텍처**: 음성 기능이 추가되어도 동일한 Durable Object 인스턴스와 SQLite 기반의 대화 기록을 공유하므로, 기존 텍스트 기반 에이전트의 지식과 맥락을 그대로 활용할 수 있습니다. **실시간 음성 파이프라인의 작동 원리** * **지속적 전사 및 턴 감지**: 통화가 시작되면 에이전트는 지속적인 전사 세션을 생성하며, STT 모델이 사용자의 발화 종료 시점을 스스로 판단하여 안정적인 텍스트 결과(Turn)를 앱 로직에 전달합니다. * **문장 단위 스트리밍**: `onTurn()` 메서드가 텍스트 스트림을 반환하면, 파이프라인이 이를 문장 단위로 분할(Chunking)하여 각 문장이 준비되는 즉시 실시간으로 음성을 합성해 클라이언트로 전송합니다. * **데이터 영속성**: 모든 사용자 메시지와 에이전트의 응답은 SQLite 데이터베이스에 자동으로 기록되어, 네트워크 연결이 끊기거나 서버가 재배포되어도 끊김 없는 대화 경험을 보장합니다. 이 라이브러리는 음성 기능을 복잡한 별도의 서비스로 분리하지 않고 에이전트의 라이프사이클 내에 자연스럽게 통합했다는 점에서 매우 실용적입니다. 기존 Cloudflare Agents SDK를 사용 중인 개발자라면 추가적인 인프라 구축 없이 Workers AI의 성능을 활용해 지연 시간이 낮은 실시간 대화형 AI를 구축할 수 있으므로, 단순 텍스트 인터페이스를 넘어선 다중 모달(Multi-modal) 환경으로의 확장을 적극 고려해 보길 추천합니다.

sqlitedatabase-designreactspeech-to-text+3

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 컨트롤 플레인은 대규모 자동화 인프라를 위한 강력하고 탄력적인 토대를 제공합니다.

sqlitedatabase-designdurable-objectsscalability+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를 활용해 보시기 바랍니다. 이를 통해 인프라 설정의 번거로움 없이 각 사용자 앱마다 독립적이고 성능이 뛰어난 전용 데이터베이스를 즉시 제공할 수 있으며, 관리자 계층을 통해 시스템 안정성과 가시성을 동시에 확보할 수 있습니다.

sqlitedatabase-designcloudflarepostgresql+3

cloudflare2026년 3월 3일

Cloudflare 위협 인텔리전 (새 탭에서 열림)

Cloudflare는 복잡한 ETL(추출, 변환, 적재) 파이프라인을 제거하고 SQLite 기반의 샤딩된 아키텍처를 활용하여 차세대 위협 인텔리전스 플랫폼(TIP)을 구축했습니다. 이 플랫폼은 전 세계 네트워크 엣지에서 GraphQL을 직접 실행함으로써 수백만 건의 위협 이벤트를 1초 미만의 지연 시간으로 쿼리하고 시각화할 수 있는 성능을 제공합니다. 이를 통해 보안 팀은 단순히 위협을 관찰하는 수준을 넘어, 위협 행위자와 멀웨어를 실시간으로 연결하고 Cloudflare 네트워크 전체에서 공격을 선제적으로 차단할 수 있는 통합된 방어 체계를 갖추게 되었습니다. ### 위협 인텔리전스 플랫폼의 필요성과 진화 Cloudforce One 팀이 공격자 인프라를 추적하기 위해 내부용으로 개발했던 도구가 이제 모든 사용자를 위한 클라우드 네이티브 위협 인텔리전스 플랫폼으로 발전했습니다. 단순히 데이터를 나열하는 것이 아니라 위협의 전체 생명주기를 매핑하여 공격자와 멀웨어, 케이스, 지표를 하나로 연결합니다. * **데이터의 유용성 확보:** 방대한 텔레메트리 데이터 속에서 실행 가능한 통찰력을 추출하여 보안 운영 센터(SOC)의 의사결정을 지원합니다. * **엣지 기반의 혁신:** Cloudflare Workers 환경을 활용하여 실시간으로 위협 이벤트를 그래프와 다이어그램으로 합성하며, 데이터 수집과 가용성 사이의 지연 시간을 완전히 제거했습니다. ### SIEM의 한계 극복과 지능형 강화 실시간 로그 집계와 알람에 최적화된 기존 SIEM과 달리, TIP는 공격자 패턴을 추적하기 위한 전용 스키마와 장기 보관 기능을 제공하여 보안 생태계를 보완합니다. * **상황 맥락 제공:** 단순한 IP나 해시 값을 넘어 해당 지표의 역사, 관련 위협 행위자, 캠페인 내 역할 및 위험 점수를 즉각적으로 제공하여 분석가의 수동 조사 시간을 단축합니다. * **선순환 피드백 루프:** 분석가가 발견한 새로운 침해 지표(IOC)를 플랫폼에 다시 입력하면 자동화된 방어 기능이 강화되어, 모든 사용자가 실시간으로 업데이트된 인텔리전스의 혜택을 누릴 수 있습니다. ### 병목 현상을 제거한 ETL-less 아키텍처 중앙 집중식 데이터베이스의 성능 한계를 극복하기 위해 SQLite 기반의 Durable Objects를 활용한 분산 샤딩 구조를 채택했습니다. * **고가용성 샤딩:** 위협 이벤트를 수천 개의 논리적 샤드(Durable Objects)로 분산 저장하여 쓰기 병목 현상을 방지하고 고성능 트랜잭션을 보장합니다. * **계층화된 저장소:** 고부하 공격 시 발생하는 데이터 스파이크를 Cloudflare Queues로 처리하며, 장기 데이터는 R2에 저장하고 즉각적인 조회가 필요한 인덱스는 Durable Object 내의 SQLite에 유지합니다. ### 엣지에서의 병렬 쿼리 실행 사용자가 GraphQL 엔드포인트를 통해 검색을 수행하면 플랫폼은 단일 테이블이 아닌 네트워크 전역에 분산된 여러 샤드에 쿼리를 동시에 전송(Fan-out)합니다. * **지연 시간 최소화:** Smart Placement 기술을 통해 쿼리를 처리하는 Worker를 데이터가 보관된 Durable Object와 물리적으로 가까운 곳에 배치하여 응답 속도를 극대화했습니다. * **권한 기반 필터링:** 쿼리 실행 전 사용자 권한과 날짜 기반 샤드 필터링을 거쳐 필요한 데이터만 병렬로 취합함으로써 효율적인 데이터 검색을 실현합니다. 보안 운영의 효율성을 높이기 위해서는 데이터의 양보다 그 데이터가 얼마나 빠르게 실행 가능한 정보로 전환되는지가 중요합니다. Cloudflare의 새로운 TIP는 인텔리전스를 별도의 분리된 데이터셋이 아닌 방어 체계의 일부로 통합함으로써, 보안 팀이 사후 대응 방식에서 벗어나 선제적이고 능동적인 방어 태세를 구축할 수 있도록 돕습니다.

sqlitedatabase-designcloudflare-workersgraphql+4