cloudflare2026년 8월 14일

Cloudflare는 MCP 트래픽을 어떻게 탐지하고 보안을 강화하는가 (새 탭에서 열림)

AI 에이전트는 기존 사용자보다 훨씬 빠르고 반복적으로 도구를 호출할 수 있어, 한 번의 잘못된 판단이 대규모 권한 오용으로 확산될 수 있다. MCP는 에이전트가 SaaS, 내부 애플리케이션, API의 도구를 호출하게 해주지만, 승인되지 않은 서버로 직접 연결하는 ‘Shadow MCP’가 일반 HTTPS 트래픽처럼 보일 수 있다는 문제가 있다. 따라서 클라이언트·네트워크·MCP 서버의 각 지점에서 호출을 식별하고, 검사하며, 실행 전 차단하는 다층 통제가 필요하다. ## AI 에이전트가 기존 권한 모델을 바꾸는 이유 - 기존 권한 체계는 사용자가 판단하고, 사람의 속도로만 작업한다는 가정에 기반했다. - AI 에이전트는 판단이 비결정적이며, 같은 도구를 피로 없이 반복 호출할 수 있다. - 잘못된 판단 하나가 사람이 알아차리기 전에 수천 건의 잘못된 작업으로 확대될 수 있다. - 에이전트 연결은 한 줄의 설정만으로 가능해, 직원이 승인 여부를 확인하지 않고 MCP 서버를 사용할 위험이 있다. ## MCP 도구 호출의 구조와 보안 신호 MCP 호출은 시스템의 위치에 따라 세 가지 형태로 나타난다. - 클라이언트 내부에서는 특정 도구와 인자를 호출하기로 한 에이전트의 결정이다. - 네트워크에서는 JSON-RPC 메시지를 담은 HTTP 요청이다. - 서버에서는 실제 도구 핸들러를 실행하는 작업으로 변환된다. - 요청에는 다음과 같은 식별 정보가 포함된다. - `Host`, 경로: 대상 서버 식별 - `Authorization`: 호출자 인증 정보 - `MCP-Protocol-Version`: MCP 프로토콜 버전 - `Mcp-Method`: 수행할 작업 - `Mcp-Name`: 호출할 도구 이름 - `id`: 요청과 응답을 연결하는 식별자 - `params`: 도구 인자 - 특히 `params`에는 검색어, 소스 코드, 고객 데이터, 티켓 생성이나 인프라 변경 지시가 포함될 수 있어 가장 민감하다. - 응답에도 도구가 반환한 민감한 데이터가 포함될 수 있으므로 요청뿐 아니라 응답 검사와 로깅도 중요하다. - MCP는 특정 호스트명이나 `/mcp` 경로를 반드시 요구하지 않기 때문에, 승인되지 않은 직접 연결이 일반 HTTPS API 호출처럼 보일 수 있다. ## 클라이언트 내부 통제 - 모델이 도구를 선택한 뒤 실제 요청으로 직렬화하기 전에 서버, 도구 이름, 인자를 검사할 수 있다. - 승인 목록에 없는 서버를 차단할 수 있다. - 민감한 작업에 사용자 확인을 요구할 수 있다. - 요청이 기기를 떠나기 전에 인자에서 민감한 데이터를 제거할 수 있다. - 네트워크를 사용하지 않는 로컬 `stdio` MCP 서버도 통제할 수 있다. - 단점은 사용하는 모든 MCP 클라이언트마다 통제를 별도로 구현해야 한다는 점이다. - 조직이 클라이언트와 기기를 모두 관리할 때 효과적이지만, 단일 클라이언트의 telemetry만으로는 전체 MCP 사용 현황을 파악할 수 없다. ## 네트워크 경계에서의 탐지와 차단 - 보안 웹 게이트웨이는 요청이 클라이언트를 떠난 뒤 HTTP 트래픽을 관찰한다. - TLS 복호화를 적용하면 사용자와 기기, 대상 서버, MCP 관련 헤더를 함께 식별할 수 있다. - 특정 MCP 클라이언트에 의존하지 않고 관리되는 네트워크 경로의 원격 MCP 트래픽을 폭넓게 탐지할 수 있다. - 승인된 MCP Portal을 거치지 않는 직접 연결을 목적지에 도달하기 전에 차단할 수 있다. - DLP 기능을 사용하면 JSON-RPC 메서드와 인자를 검사해 민감한 데이터 전송을 차단하거나 기록할 수 있다. - 다만 로컬 `stdio` 호출이나 조직 네트워크 밖에서 발생한 트래픽은 볼 수 없다. ## MCP 서버에서의 실행 전 통제 - MCP 서버는 호출자를 인증하고, 메시지를 해석하며, 도구와 인자를 검증한 뒤 실행하는 가장 풍부한 실행 컨텍스트를 가진다. - 도구 핸들러가 실행되기 전에 다음 정책을 적용할 수 있다. - 호출자별 도구 권한 확인 - 호출 횟수 제한 - 인자 검사 - 실행 결과와 승인 여부 기록 - 읽기 작업은 허용하되, 쓰기 작업에는 에이전트 식별 정보와 감사 이벤트를 추가할 수 있다. - 중요 작업은 핸들러 실행 전에 차단해야 하며, 실행 후 로그만 남기는 방식으로는 피해를 예방할 수 없다. - Cloudflare의 WriteGuard는 도구별 위험 등급과 활성화 상태를 사용해 읽기·쓰기·중요 작업을 차등 처리한다. - 서버 측 통제는 사용자가 클라이언트를 바꾸거나 로컬 훅을 비활성화해도 우회하기 어렵다. - 단, 해당 통제를 구현한 MCP 서버만 보호할 수 있다는 한계가 있다. ## Cloudflare One과 MCP Portal의 역할 - Cloudflare One은 검사된 MCP 트래픽을 식별하고, 어떤 사용자와 서버가 생성했는지 보여주는 기능을 제공한다. - 관리 네트워크 경로에서 직접 연결을 통제해 승인된 MCP Portal 경로만 사용하도록 강제할 수 있다. - 이를 통해 관리자는 에이전트가 승인된 경로를 이용하는지, 아니면 MCP Portal을 우회해 서버에 직접 연결하는지 확인할 수 있다. - 네트워크 계층은 가장 넓은 범위의 원격 MCP 연결을 감시하고, 클라이언트와 서버 계층은 요청 내용과 실행 맥락을 더 깊이 통제한다. ## 실용적인 권장 방식 MCP 보안은 한 지점에 의존하기보다 다층으로 구성하는 것이 적절하다. 클라이언트에서는 민감한 요청을 사전 확인하고, 네트워크에서는 Shadow MCP와 Portal 우회 연결을 탐지·차단하며, 서버에서는 도구별 권한·위험 등급·속도 제한을 적용해야 한다. 특히 데이터 변경이나 외부 시스템 조작을 수행하는 도구는 반드시 서버에서 실행 전에 검증하고 감사 로그를 남겨야 한다.

ai-agentmodel-context-protocolaccess-controldata-loss-prevention+4

cloudflare2026년 8월 14일

모든 내부 바이브 코딩 애플리케이션을 한 번의 클릭으로 안전하게 보호하세요 (새 탭에서 열림)

AI로 애플리케이션 개발·배포가 쉬워진 만큼, 직원이 실수로 내부 애플리케이션이나 데이터를 인터넷에 노출할 위험도 커졌다. Cloudflare는 이를 막기 위해 Workers에 Cloudflare Access를 직접 연결해, 애플리케이션 코드나 개발자의 설정에 의존하지 않고 기본적으로 인증을 강제할 수 있도록 했다. 계정 전체, 개별 Worker, 프리뷰 환경에 정책을 적용하고, 코드에서는 별도의 JWT 검증 없이 인증 사용자 정보를 사용할 수 있다. ## Worker 단위로 적용하는 Cloudflare Access - Access를 Worker에 활성화하면 요청이 애플리케이션 코드에 도달하기 전에 인증이 수행된다. - 다음과 같은 접근 경로를 모두 보호할 수 있다. - 커스텀 도메인 - 라우트 - `workers.dev` 서브도메인 - 프리뷰 URL - 기존에는 호스트 이름별로 Access 정책을 설정해야 했기 때문에 새 도메인을 추가할 때마다 정책도 갱신해야 했다. - 이제 정책이 호스트 이름이 아닌 Worker에 연결되므로, 해당 Worker에 연결된 새 도메인과 URL도 자동으로 보호된다. - 보호 범위는 다음 중에서 선택할 수 있다. - 프리뷰 URL만 보호 - 모든 호스트 이름 보호 - 기존 IdP를 연결하거나 특정 이메일 주소, 도메인, 그룹만 허용할 수 있으며, 에이전트에는 서비스 토큰을 사용할 수 있다. ## 계정 전체의 Worker를 기본적으로 비공개 처리 - 계정 수준에서 Access 정책을 설정하면 현재 및 향후 생성되는 모든 Worker가 기본적으로 비공개가 된다. - 정책 적용 범위는 다음과 같이 선택할 수 있다. - 프리뷰 트래픽만 - 프로덕션 트래픽만 - 프리뷰와 프로덕션 모두 - 프로덕션은 공개해야 하지만 개발 중인 배포는 노출되면 안 되는 경우, 프리뷰 전용 정책이 유용하다. - 특정 Worker를 공개해야 한다면 계정 전체 정책을 해당 Worker에서 우회할 수 있다. ## 개별 Worker 정책과 우선순위 - 계정 전체를 잠그지 않고 특정 애플리케이션만 보호하는 것도 가능하다. - Worker 화면의 새로운 Access 탭에서 해당 애플리케이션에 적용되는 정책을 확인할 수 있다. - 여러 정책이 겹칠 경우 우선순위는 다음과 같다. 1. 호스트 이름 정책 2. Worker 정책 3. 계정 정책 ## 코드에서 인증 사용자 정보 확인 - Access가 Worker를 보호하면 요청의 `ctx` 객체에 인증 사용자 정보가 포함된다. - `ctx.access.getIdentity()`를 호출해 다음 정보를 얻을 수 있다. - 이메일 - 이름 - 그룹 - 기존에는 JWT를 직접 파싱하고 서명을 검증한 뒤 클레임을 추출해야 했지만, 이제는 Worker에서 바로 identity 객체를 사용할 수 있다. ```js export default { async fetch(request, env, ctx) { if (!ctx.access) { return new Response("Access required", { status: 403 }); } const identity = await ctx.access.getIdentity(); const email = identity?.email ?? "unknown"; return new Response(`Hello, ${email}`); } }; ``` - 사용자별 화면 구성, 권한 검사, 사용자 단위 감사 로그 등에 활용할 수 있다. ## 로컬 개발 환경에서 인증 사용자 시뮬레이션 - 배포 전에 `wrangler dev`에서 Access 사용자 정보를 테스트할 수 있다. - `wrangler.jsonc`에 개발용 Access identity를 설정한다. ```json { "access": { "dev": { "aud": "my-app", "identity": { "email": "admin@company.com" } } } } ``` - 로컬 요청에서도 `ctx.access.getIdentity()`가 프로덕션과 유사한 identity 객체를 반환한다. - 이메일 주소를 바꿔가며 사용자별 콘텐츠와 권한 동작을 배포 없이 검증할 수 있다. ## 내부 애플리케이션 플랫폼 보호 - Workers for Platforms를 이용하면 여러 애플리케이션을 대규모로 배포할 수 있다. - 각 Worker가 네임스페이스에 배포되고, 모든 요청은 하나의 dispatch Worker를 거친다. - dispatch Worker에 Access 정책을 한 번만 설정하면 이를 통해 배포되는 모든 Worker가 기본적으로 비공개가 된다. - 내부 드래그 앤 드롭 배포 플랫폼처럼 직원용 애플리케이션 플랫폼을 구축할 때 유용하다. ## FL2 기반 요청 처리 구조 - Worker 단위 Access 적용은 Cloudflare의 Rust 기반 모듈형 프록시인 FL2를 기반으로 한다. - Access가 실행되기 전에 요청이 어느 Worker로 라우팅될지 알아야 하므로, Workers 라우팅과 실행 로직을 분리해야 했다. - 라우팅을 Access보다 앞 단계로 이동함으로써 호스트 이름이 아니라 개별 Worker를 기준으로 인증 정책을 적용할 수 있게 되었다. - 기존 NGINX·Lua 기반 FL1 구조에서는 요청 파이프라인의 로직을 앞 단계로 옮기는 작업이 복잡하고 위험할 수 있었지만, FL2가 이를 가능하게 했다. 개발 조직에서는 계정 수준에서 프리뷰 배포를 우선 보호하고, 공개가 필요한 Worker만 명시적으로 예외 처리하는 방식이 실용적이다. 내부 플랫폼을 운영한다면 dispatch Worker에 Access를 적용해 새로 배포되는 모든 애플리케이션을 비공개 상태로 시작하는 것이 안전하다.

cloudflare-workersrustcloudflare-accessedge-computing+4

cloudflare2026년 8월 13일

인터넷의 개기일식: 아이슬란드, 스페인, 포르투갈의 트래픽 영향 (새 탭에서 열림)

8월 12일 유럽을 가로지른 개기일식은 사람들의 온라인 활동을 일시적으로 크게 감소시켰다. Cloudflare Radar 분석에 따르면 인터넷 트래픽 하락 시점은 각 지역의 태양 최대 가림 시각과 거의 정확히 일치했으며, 개기일식 경로에 가까울수록 감소 폭도 컸다. 특히 아이슬란드·스페인·포르투갈에서는 트래픽이 최대 약 15~30% 또는 그 이상 줄었다가, 일식이 끝난 뒤 수분 내 정상 수준으로 회복됐다. ## 일식 최대 가림과 인터넷 트래픽 감소의 일치 - Cloudflare는 일식 당일 각 국가의 HTTP 요청량을 5분 단위로 집계했다. - 비교 기준은 같은 시간대의 직전 3개 수요일 트래픽 중앙값으로 설정해 특정 주의 이상치를 줄였다. - 일식이 가장 깊어진 순간을 검은색 다이아몬드로 표시한 결과, 해당 시점이 트래픽 최저점과 거의 겹쳤다. - 개기일식 경로와 깊은 부분일식이 관측된 아이슬란드, 아일랜드, 영국, 프랑스, 스페인, 포르투갈에서 감소 폭이 가장 컸다. - 태양이 거의 가려지지 않은 스웨덴, 덴마크, 폴란드, 스위스에서는 변화가 미미했다. - 일식 최대 가림 직후 사람들이 다시 기기를 사용하면서 트래픽은 대체로 몇 분 안에 회복됐다. ## 태양 가림 정도와 트래픽 하락 폭의 상관관계 - 국가별 최대 태양 가림 비율과 최대 일식 전후 15분간의 평균 트래픽 변화를 비교했다. - 태양이 많이 가려진 지역일수록 트래픽 하락 폭이 커지는 뚜렷한 하향 추세가 나타났다. - 개기일식 경로에 있는 지역은 대략 15~30%의 트래픽 감소를 보였고, 얕은 부분일식 지역은 감소가 작거나 거의 없었다. - 인구 밀도, 관측 시각, 구름 등 지역별 요인이 세부 수치에 영향을 주었지만, 전체적인 방향은 일관됐다. - 하락 시점이 최대 가림 시각과 정확히 맞물린 점까지 고려하면, 트래픽 감소의 주된 원인은 일식 자체로 해석된다. ## 국가별 영향: 아이슬란드·스페인·포르투갈의 큰 하락 - 국가별 트래픽 변화는 약 9.3% 증가부터 -46.7% 감소까지 다양하게 나타났다. - 아이슬란드, 스페인, 포르투갈에서 가장 극적인 트래픽 하락이 발생했다. - 폴란드와 덴마크는 일식 이후 트래픽이 빠르게 평소 수준으로 돌아왔다. - 노르웨이와 스웨덴은 오히려 기준치보다 약간 높은 트래픽을 기록했다. - 덴마크는 전체적으로 일식의 영향이 가장 적은 국가 중 하나였다. - 일식은 알래스카에서 UTC 15시 35분경 시작해 관측 경로를 따라 이동했으며, 국가별 트래픽 변화도 그 순서에 맞춰 나타났다. ## 태양 가림 비율을 계산한 방법 - 각 지역의 태양과 달의 정확한 위치를 바탕으로 두 천체의 겉보기 각 크기와 하늘에서의 거리를 계산했다. - 태양과 달의 원형 원반이 겹치는 면적을 이용해 5분마다 태양 원반이 가려진 비율을 산출했다. - 이를 통해 지역별 최대 가림 비율과 최대 일식 시각을 구했다. - 국가 단위 분석에서는 각 지역의 트래픽을 합산하고, 지역별 가림 정도를 평균해 국가의 대표 최대 일식 시각을 정했다. - 트래픽 수치는 평소 기준 대비 변화율로 표시했으며, 0%는 정상 수준, 음수는 평소보다 낮은 활동을 의미한다. ## 물리적 사건이 디지털 활동에 미치는 영향 - 인터넷 트래픽은 네트워크 장애뿐 아니라 사람들의 관심과 행동 변화를 직접 반영한다. - 이번 사례에서 트래픽 감소는 통신 인프라 문제가 아니라 사람들이 온라인 활동을 멈추고 하늘을 관측했기 때문에 발생했다. - Cloudflare Radar는 일식과 같은 대규모 사건이 전 세계 인터넷 이용 패턴을 어떻게 바꾸는지 추적할 수 있는 분석 도구로 제시된다. - 실제 세계의 공동 경험이 짧은 시간 동안 대륙 전체의 디지털 활동을 동시에 변화시킬 수 있음을 보여준다. 일식처럼 관측 시각이 명확하고 영향 범위가 넓은 사건을 분석할 때는, 실시간 트래픽과 평소 같은 요일의 기준치를 함께 비교하면 사람들의 행동 변화를 정량적으로 파악할 수 있다.

data-visualizationcloudflare-radarstatistical-analysishttp+2

cloudflare2026년 8월 13일

인증서 투명성 모니터링이 이제 정식 출시되었습니다 (새 탭에서 열림)

Cloudflare는 Certificate Transparency(CT) 모니터링에서 자사가 발급한 정상적인 인증서 갱신까지 알림으로 보내던 문제를 해결했다. 이제 Cloudflare가 관리·발급한 인증서는 자동으로 필터링하고, 외부에서 발급된 예상치 못한 인증서만 알림을 보낸다. 이를 위해 인증서 발급 초기부터 최종 인증서까지 유지되는 공개키 기반 식별자 `spki_sha256`를 사용한다. ## CT 모니터링의 알림 과다 문제 - CT 모니터링은 고객 도메인에 새로운 TLS 인증서가 공개 CT 로그에 등장하면 이메일을 보낸다. - 이 기능은 잘못 발급된 인증서를 조기에 발견하는 데 유용하지만, Cloudflare가 고객을 대신해 발급하는 인증서도 모두 알림 대상이었다. - Universal SSL, Advanced Certificate Manager, Total TLS, Backup Certificate 등의 정상적인 발급·갱신이 반복적으로 CT 로그에 기록된다. - 기존 인증서는 최대 60일마다 갱신될 수 있으며, 2029년에는 최대 유효기간이 47일로 줄어들 예정이라 정상 갱신 알림은 더욱 늘어날 수 있다. - 결과적으로 중요한 외부 인증서 발급 알림이 정상적인 갱신 알림에 묻히거나, 사용자가 기능을 꺼버리는 문제가 발생했다. ## 인증서 관리 시스템과 CT 알림 시스템의 단절 - 인증서 발급 시스템은 내부 발급 정보를 관리하고, CT 알림 시스템은 공개 CT 로그를 읽어 알림을 생성한다. - 두 시스템은 같은 인증서를 다루지만 처리 시점과 보유 정보가 다르다. - CT 알림 시스템이 로그를 확인하는 순간에는 해당 인증서가 Cloudflare 발급인지 알려주는 발급 시스템의 정보가 없었다. - 따라서 “이 인증서가 Cloudflare가 발급한 것인가?”를 판단할 연결 고리가 필요했다. ## 사전 인증서와 최종 인증서의 처리 순서 - 하나의 인증서 발급은 일반적으로 다음 두 단계로 CT 로그에 기록된다. - CA가 사전 인증서(pre-certificate)를 생성하고 로그에 기록한다. - SCT(Signed Certificate Timestamp)를 최종 인증서에 포함한 뒤 최종 인증서를 다시 로그에 기록한다. - 하나의 발급 요청에 대해 두 개의 로그 항목이 생기므로, Cloudflare는 `stripped_fingerprint`를 사용해 중복 알림을 방지했다. - `stripped_fingerprint`는 DER로 인코딩된 TBSCertificate의 해시이며, 사전 인증서와 최종 인증서 쌍을 식별하는 데 적합하다. - 그러나 발급 시스템은 사전 인증서를 받지 않기 때문에 이 값을 발급 초기에 계산할 수 없다. - 사전 인증서가 먼저 로그에 기록되는 짧은 시간 동안에는 발급 시스템 데이터베이스에 해당 fingerprint가 없어, Cloudflare가 발급한 인증서임에도 알림이 발생할 수 있었다. ## 공개키 기반 식별자 선택 새 식별자는 다음 조건을 만족해야 했다. - CT 로그에 기록되기 전에 생성될 것 - 사전 인증서와 최종 인증서 전반에서 동일할 것 - CT 알림 시스템이 로그 정보만으로 다시 계산할 수 있을 것 - 인증서 발급 요청마다 고유할 것 이 조건을 만족하는 값으로 인증서의 공개키가 선택됐다. - 공개키는 `SubjectPublicKeyInfo(SPKI)` 구조 안에 포함된다. - 키 생성 시점부터 CSR, 사전 인증서, 최종 인증서까지 동일하게 유지된다. - Cloudflare는 발급마다 새로운 키 쌍을 생성하므로 공개키는 사실상 발급 요청마다 고유하다. - 개인키는 Cloudflare만 보유하므로, 동일한 공개키를 가진 유효한 인증서는 Cloudflare 발급 과정에서 나온 것으로 판단할 수 있다. - Cloudflare는 DER 인코딩된 SPKI를 SHA-256으로 해시한 `spki_sha256` 값을 사용한다. ## `spki_sha256`를 이용한 알림 필터링 - 인증서 발급 시스템은 CSR에서 `spki_sha256`를 계산해 키 생성 시점에 데이터베이스에 저장한다. - CT 알림 시스템은 CT 로그에서 인증서를 발견하면 공개키로 동일한 `spki_sha256`를 다시 계산한다. - 이후 발급 시스템 데이터베이스에서 해당 값을 조회한다. - 값이 있으면 Cloudflare가 발급한 인증서로 간주하고 알림을 억제한다. - 값이 없으면 외부 발급 인증서로 간주하고 기존처럼 알림을 보낸다. - 사전 인증서와 최종 인증서의 공개키가 동일하므로 어느 항목이 먼저 처리되더라도 일관되게 판단할 수 있다. ## 필터링 적용 결과 - Cloudflare가 관리하는 Universal SSL, Advanced Certificate Manager, Total TLS, Backup Certificate는 정상적으로 알림에서 제외된다. - 사전 인증서만 로그에 남고 최종 발급이 중단된 경우에도 Cloudflare 발급 기록과 일치하므로 불필요한 알림이 발생하지 않는다. - 사용자가 직접 업로드한 커스텀 인증서는 Cloudflare가 키를 생성하지 않았으므로 발급 시스템에 일치하는 키 기록이 없다. - 따라서 외부에서 관리되는 커스텀 인증서나 예상치 못한 인증서 발급은 계속 알림 대상이다. Cloudflare의 개선은 정상적인 내부 인증서 갱신을 제거하면서도 외부 발급 인증서는 놓치지 않도록 해 CT 모니터링의 신호 대 잡음비를 높인 사례다. 사용자는 알림을 끄기보다, 이제 실제로 확인할 가치가 있는 인증서 발급 이벤트를 중심으로 대응할 수 있다.

cloudflaretls-certificatespublic-key-cryptographycertificate-transparency+3

cloudflare2026년 8월 11일

Cloudflare DDoS 위협 보고서 2026년 상반기: DNS 플러드와 지정학적 긴장으로 새로운 물결이 일며 1Tbps 공격 급증 (새 탭에서 열림)

Cloudflare의 2026년 상반기 DDoS 보고서는 공격 규모가 급격히 커지는 동시에, 공격 방식이 봇넷 기반 대량 트래픽에서 DNS·CLDAP 같은 반사·증폭 공격으로 이동하고 있다고 분석한다. 상반기에만 네트워크 계층 공격 2,320만 건과 HTTP DDoS 요청 29조 6,400억 건이 차단됐으며, 1Tbps 초과 공격은 935건에 달했다. 공격 대부분은 짧고 자동화되어 발생하므로 수동 대응이 아닌 상시 자동화 방어가 필수라는 것이 보고서의 결론이다. ## 2026년 상반기 DDoS 규모 - Cloudflare는 2026년 1~6월 동안 다음 공격을 완화했다. - 네트워크 계층 DDoS: 2,320만 건 - HTTP DDoS 요청: 29조 6,400억 건 - 시간당 약 5,343건, 하루 약 12만 8,000건의 네트워크 계층 공격이 발생했다. - 2026년 4월에는 공격량이 정점에 도달했다. - HTTP 요청 6조 4,600억 건 - 네트워크 트래픽 165PB - 이후 공격량이 감소한 것은 21개국이 참여한 Operation PowerOFF의 영향일 가능성이 있다. - DDoS 대행 서비스 이용자 7만 5,000명 이상 대상 - 도메인 53개 폐쇄 - 수색영장 25건 발부 - 4명 체포 ## 초대형 공격의 급증 - 1Tbps, 10억 패킷/초(Bpps), 100만 요청/초(Mrps)를 초과하는 공격을 초대형 DDoS로 분류한다. - 상반기 1Tbps 초과 네트워크 공격은 총 935건이었다. - 특히 2분기에는 805건이 발생해 전 분기보다 6배 이상 증가했다. - 1Tbps를 넘는 공격은 대규모 인터넷 인프라까지 압박할 수 있는 수준이다. ## 대부분은 작고 짧지만 충분히 치명적 - 네트워크 계층 공격의 96.62%는 500Mbps 미만이었다. - 90.60%는 10분 이내에 종료됐다. - 그러나 “작은 공격”도 일반적인 서비스에는 치명적일 수 있다. - 100Mbps: 서버나 웹사이트를 마비시킬 수 있는 수준 - 100Gbps: 보호되지 않은 대부분의 데이터센터를 오프라인으로 만들 수 있는 수준 - 1Tbps 이상: 주요 인터넷 인프라까지 위협하는 초대형 공격 - 공격자는 대역폭과 패킷 속도를 조합해 네트워크 장비 또는 회선 용량의 약점을 노린다. - 공격 시간이 수십 초에 불과한 경우도 있어, 보안 담당자가 경보를 확인한 뒤 수동으로 대응하는 방식은 현실적으로 늦다. - 짧은 공격도 라우팅 불안정, TCP 재전송, 애플리케이션 타임아웃, 하위 서비스 장애 같은 장기적인 후속 피해를 유발할 수 있다. ## 공격 산업: 미디어와 정부 부문 ### 미디어·출판 산업의 지속적인 표적화 - Media, Production & Publishing 부문은 1·2분기 모두 가장 많이 공격받은 산업이었다. - 전체 완화 HTTP DDoS 요청의 14.2%를 차지해 2위 산업보다 약 4배 많았다. - 이란과 우크라이나 전쟁 관련 보도, 월드컵 등 국제적 관심이 집중된 사건이 공격 증가에 영향을 준 것으로 분석된다. ### Operation Epic Fury 이후 정부 공격 증가 - 2026년 2월 28일 이스라엘과 미국이 이란 지도부 및 인프라를 대상으로 Operation Epic Fury를 시작했다. - 이후 72시간 동안 16개국 110개 조직을 대상으로 한 핵티비스트 DDoS 공격 주장이 149건 보고됐다. - 표적 조직의 약 47.8%가 정부 부문이었다. - 정부 부문은 공격 비중 순위가 1분기 29위에서 2분기 9위로 급상승했다. ## 공격받은 국가 및 지역 - 2분기 기준 가장 많이 공격받은 국가는 중국으로, 전 세계 HTTP DDoS 요청의 22.4%를 차지했다. - 미국은 18.8%로 2위를 유지했다. - 튀르키예는 공격 비중이 두 배 이상 증가하며 3위로 올라섰다. - 이 증가는 2026년 앙카라 NATO 정상회의를 앞두고 보안 당국이 대규모 단속을 진행한 시기와 겹쳤다. ## 공격 발생지 국가 - 브라질이 미국을 제치고 상반기 DDoS 트래픽의 최대 발생지로 나타났다. - 브라질: 14.9% - 미국: 13.4% - 브라질은 2분기에만 전체 완화 DDoS 요청의 21.4%를 차지했다. - 인도네시아는 두 분기 모두 3위를 기록하며 주요 DDoS 발생지로 남았다. ## 공격 벡터의 변화 ### DNS Flood와 DNS Amplification의 확대 - DNS 기반 공격은 상반기 네트워크 계층 공격의 34.3%를 차지했다. - DNS Flood는 봇넷이 피해자의 권한 있는 DNS 서버에 대량 질의를 보내 처리 용량을 고갈시킨다. - DNS가 마비되면 해당 도메인에 의존하는 웹사이트와 서비스가 함께 영향을 받는다. - DNS Amplification은 위조된 출발지 IP를 사용해 개방형 DNS 리졸버에 작은 질의를 보내고, 더 큰 응답이 피해자에게 전달되도록 만드는 반사·증폭 공격이다. - DNS Flood 비중은 1분기 25.7%에서 2분기 40.0%로 상승했다. ### CLDAP 증폭 공격의 폭증 - CLDAP Flood는 노출된 Active Directory LDAP-over-UDP 엔드포인트를 악용하는 반사·증폭 공격이다. - 2분기에 전 분기 대비 580% 증가했다. - 그 결과 CLDAP Flood는 2분기 네트워크 계층 공격 벡터 중 3위가 됐다. - 이는 공격 중심이 단순한 봇넷 트래픽 폭주에서, 개방형 서비스와 프로토콜의 증폭 특성을 악용하는 방식으로 이동하고 있음을 보여준다. ## 실용적인 대응 방향 - 공격이 짧고 빠르게 끝나므로 수동·온디맨드 대응만으로는 부족하다. - DNS 인프라, 네트워크 회선, 애플리케이션 계층을 모두 포함하는 상시 자동화 방어가 필요하다. - CLDAP·DNS 등 반사·증폭에 악용될 수 있는 인터넷 노출 서비스를 점검하고, 불필요한 UDP 서비스와 개방형 리졸버를 차단해야 한다. - 공격 직후에도 재전송, 타임아웃, 라우팅 불안정 등 후속 장애를 확인해야 한다.

cloudflarenetwork-securitydnsddos+3

cloudflare2026년 8월 10일

에이전트 위크 동안 출시한 모든 것 (새 탭에서 열림)

에이전트는 AI 기능을 넘어 사람과 소프트웨어가 인터넷과 상호작용하는 방식을 바꾸는 새로운 소프트웨어 계층이다. Cloudflare는 Agents Week를 통해 실행 환경, 개발 생명주기, 신원·보안, 에이전트 친화적 인터넷, 관측·검색·AI 인프라를 하나의 플랫폼으로 통합하는 방향을 제시했다. 궁극적으로는 인간과 에이전트가 충돌하지 않고 협력하는 “Agentic Internet”을 구축하는 것이 목표다. ### 에이전트를 위한 실행 환경과 인프라 - 에이전트에는 단순한 컨테이너가 아니라 작업에 맞는 컴퓨터 환경이 필요하다는 관점에서 `@cloudflare/computer` 런타임을 소개했다. - Python과 JavaScript Workers 간 RPC 통신을 지원해 혼합 언어 프로젝트를 쉽게 만들 수 있도록 했다. - Kimi, GLM 같은 대규모 모델을 더 작고 빠르며 안전하게 운영하는 방법을 제시했다. - Billable Usage API로 셀프서비스 제품의 사용량과 비용을 프로그램 방식으로 확인할 수 있다. - Workers와 Containers에서 인바운드 TCP 및 gRPC를 지원해 음성 AI 백엔드와 실시간 에이전트 구축이 가능해졌다. ### 프로토타입에서 운영까지: Agent Development Lifecycle - 기존 SDLC를 확장한 ADLC(Agent Development Lifecycle)를 제안했다. - Cloudflare Agents는 에이전트 실행 과정을 실시간으로 관찰하고, 추적·재생하며, 운영 중 사람의 승인을 받을 수 있게 한다. - 로컬 개발 환경에서도 분산 추적을 활용해 에이전트가 Workers 문제를 직접 찾고 디버깅할 수 있다. - Cloudflare Wallets는 에이전트가 안전하게 거래를 수행할 수 있는 프로그래밍 가능한 지갑을 제공한다. - 코드로 정의하는 CI/CD 파이프라인과 실패를 분석하고 수정안을 검토 단계로 보내는 에이전트를 소개했다. - AI를 활용해 코드 표준과 개발 프로세스를 자동으로 점검하고, Astro의 GitHub 이슈를 분석·분류·라우팅해 유지보수 부담을 줄인 사례도 공유했다. ### 에이전트의 신원과 보안 통제 - Zero Trust를 사용자와 기기뿐 아니라 에이전트에도 적용하는 Agent Access Model을 제시했다. - 에이전트가 사용자를 대신해 리소스와 서비스에 접근할 때, 주체와 권한을 명확히 식별하고 통제하는 것이 핵심이다. - Cloudflare OS는 내부 업무와 시스템에 AI를 통합하되 보안과 감독을 유지하도록 설계된 오픈 플랫폼이다. - 신원 기반 분석으로 AI 활동을 실제 사용자와 시스템에 연결해 이상 행동이나 비용 급증을 감지할 수 있다. - WriteGuard는 MCP 서버의 도구 호출을 세밀하게 제한해 에이전트의 위험한 변경이나 원치 않는 작업을 줄인다. ### 사람이 통제하는 Agentic Internet - Agentic Internet은 웹사이트와 콘텐츠가 에이전트에게 읽히고(readable), 발견되며(discoverable), 호출되고(callable), 결제될 수 있어야 한다는 모델이다. - WebMCP를 통해 웹사이트와 웹 애플리케이션에 에이전트용 인터페이스를 쉽게 추가할 수 있다. - 기존 SEO를 넘어 에이전트가 콘텐츠를 이해하고 답변에 활용하도록 만드는 AEO(Answer Engine Optimization)의 필요성을 강조했다. - Kitesurf는 픽셀 단위의 브라우저 렌더링보다 낮은 메모리·CPU 사용량을 우선한 에이전트 전용 브라우저다. - MCPv2는 MCP 기반 애플리케이션의 배포와 확장을 단순화하는 차세대 규격으로 소개됐다. - Cloudflare AI Search는 파일이나 웹사이트를 한 번의 명령으로 에이전트가 사용할 수 있는 검색 엔진으로 변환한다. ### 실제 인터넷에서의 신뢰와 AI 운영 - 봇을 무조건 악성으로 보거나 사람을 항상 신뢰하는 방식에서 벗어나, 행동을 지속적으로 평가하는 신뢰 모델을 제안했다. - Workers AI와 AI Gateway를 하나의 AI 제어 평면으로 통합해 단일 바인딩, 지갑, 대시보드에서 다양한 AI 모델을 호출하도록 했다. - 향후에는 모델 중심 라우팅을 통해 목적과 비용, 성능에 맞는 모델을 자동 선택할 수 있게 될 전망이다. - Cloudflare Ambassadors와 Community Engineers 프로그램, 2년간 추가 100만 달러 규모의 오픈소스 지원 계획을 발표했다. - Radar Researcher는 자연어 질문을 인터랙티브 차트로 변환해 인터넷 데이터를 탐색하도록 돕는다. Cloudflare가 제시한 Agent Cloud는 실행 계층, ADLC 기반 개발 도구, 신원과 보안 제어, 에이전트 친화적 웹 표준, 관측·검색·AI 운영 도구를 함께 제공하는 형태로 구체화되고 있다. 에이전트를 도입할 때는 모델 성능뿐 아니라 권한 관리, 실행 추적, 사람의 승인 절차, 비용 가시성, 웹 접근 규칙까지 함께 설계하는 것이 실용적인 출발점이다.

ai-agentci-cdmodel-context-protocolcloudflare-workers+4

cloudflare2026년 8월 10일

가장 중요한 임무를 지원하는 Cloudflare for Government, FedRAMP Class D(High) 인증 획득 (새 탭에서 열림)

Cloudflare는 공공기관용 서비스인 Cloudflare for Government에서 FedRAMP Class D(High) 인증을 획득했다고 발표했습니다. 이는 미국 정부의 가장 민감한 비기밀 데이터를 처리할 수 있는 높은 수준의 보안·감사·지속적 모니터링 요건을 충족했다는 의미입니다. 또한 이 인증에 사용한 시스템을 기반으로 미 국방부 DoD Impact Level 4(IL4) 승인도 추진하며, 별도 정부용 클라우드가 아닌 글로벌 단일 플랫폼에서 빠른 혁신과 강력한 보안을 제공하겠다는 전략을 강조했습니다. ### FedRAMP High 인증의 의미 - FedRAMP는 미국 연방정부 클라우드 서비스의 보안 평가, 승인, 지속적 모니터링을 표준화한 프로그램입니다. - ‘인증’은 단순한 자체 보안 선언이 아니라 다음 절차를 거친 공식 승인입니다. - 연방기관의 역량 검증 - 후원 기관의 전체 승인 절차 진행 - FedRAMP Program Management Office의 승인 확인 - Cloudflare는 2022년 FedRAMP Moderate 승인을 받았으며, 이번에는 더 높은 수준인 Class D(High)를 획득했습니다. - Moderate는 시스템 침해가 심각한 피해를 일으킬 수 있는 환경에 적용되지만, High는 다음과 같은 국가 핵심 데이터에 적용됩니다. - 법 집행 및 긴급 서비스 데이터 - 금융 시스템 정보 - 국가 안보 관련 데이터 - High 수준에서 보안 통제가 침해되면 인명 피해, 경제적 손실, 국가 안보 위협으로 이어질 수 있어 요구사항과 책임 수준이 크게 높아집니다. ### 분리된 정부용 클라우드의 한계 - 기존 기술 기업들은 공공 부문과 국방 부문을 위해 상용 플랫폼과 분리된 독립 환경을 구축하는 경우가 많았습니다. - 이런 방식은 보안과 규정 준수에는 유리할 수 있지만 다음 문제가 발생했습니다. - 상용 서비스와 정부용 서비스 사이에 기능 격차 발생 - 정부 환경이 최신 기술 적용에서 수년씩 뒤처짐 - 기관이 최신 기능과 엄격한 규정 준수 중 하나를 선택해야 함 - Cloudflare는 정부용 제품을 축소된 별도 플랫폼으로 만들지 않고, 상용 서비스와 동일한 글로벌 네트워크를 기반으로 구축했습니다. ### 하나의 글로벌 네트워크와 소프트웨어 정의 지역성 - Cloudflare는 전 세계 데이터센터에서 동일한 소프트웨어 스택과 서비스를 운영합니다. - FedRAMP High 서비스도 별도 장비나 고립된 네트워크가 아니라 동일한 인프라 위에서 동작합니다. - 핵심 기술은 Data Localization Suite입니다. - 데이터가 어디에서 처리되고 저장되는지 소프트웨어로 세밀하게 제어 - FedRAMP High 환경에서는 트래픽 검사와 처리를 미국 내 데이터센터로만 제한 - 글로벌 네트워크의 확장성과 미국 내 데이터 residency 및 처리 요건을 동시에 충족 - 따라서 연방기관은 기능이 제한된 정부용 버전이 아니라 다음과 같은 최신 기능을 사용할 수 있습니다. - Zero Trust 보안 도구 - 애플리케이션 성능 최적화 - 최신 개발자 플랫폼 기능 - 글로벌 네트워크 기반의 안정성과 확장성 ### DoD IL4 추진과 국방 분야의 혁신 속도 - Cloudflare는 FedRAMP High를 위해 설계한 시스템을 DoD Impact Level 4 승인 기반으로 활용할 계획입니다. - DoD IL4는 통제된 비기밀 정보(Controlled Unclassified Information)를 처리하기 위한 미 국방부의 사이버보안 기준입니다. - 동일한 시스템을 활용하면 국방용 환경을 별도로 구축할 필요가 줄어들고, FedRAMP High와 IL4 요구사항에 대응하는 보안 체계를 재사용할 수 있습니다. - 이를 통해 국방기관이 격리된 정부 클라우드의 느린 배포 주기에 묶이지 않고, 새로운 사이버 위협에 더 빠르게 대응할 수 있다는 것이 Cloudflare의 주장입니다. ### 공공 부문 현대화 전략 - Cloudflare는 이번 인증을 규정 준수 달성 이상의 의미로 설명합니다. - 공공기관이 다음과 같은 현대적 보안·서비스 운영 방식을 도입하도록 지원하는 것이 목표입니다. - Zero Trust 아키텍처 전환 - 정교한 DDoS 공격 방어 - 더 빠르고 복원력 높은 디지털 서비스 제공 - 국가 핵심 애플리케이션의 보안 강화 - 미국 국무부와 상무부 등 기존 연방기관과의 협력도 이번 인증을 계기로 확대할 계획입니다. 실무적으로는 FedRAMP High가 필요한 기관이라면 Cloudflare의 미국 내 데이터 처리 통제, 동일 플랫폼 기반의 최신 기능 제공 여부, 그리고 향후 DoD IL4 승인 진행 상황을 함께 확인하는 것이 적절합니다.

cloudflarecloud-securityzero-trustfedramp+3

cloudflare2026년 8월 7일

에이전틱 인터넷의 좋은 행동과 나쁜 행동을 파헤치다 (새 탭에서 열림)

인터넷 트래픽은 인간과 봇으로 단순히 나눌 수 없으며, 한 세션 안에서 인간과 에이전트가 번갈아 행동하는 하이브리드 트래픽도 증가하고 있다. 따라서 사이트 운영자는 일회성 검사보다 세션 전체의 행동을 분석해 위험(Risk)과 신뢰(Trust)를 평가해야 한다. Cloudflare는 투명하게 자신을 밝히고 신뢰를 남용하지 않는 봇은 허용하되, 지속적인 행동 분석으로 악성 자동화 트래픽을 탐지하는 생태계를 구축하고 있다. ## 위험과 신뢰는 서로 다른 개념 - **위험(Risk)**은 특정 요청이나 행동이 해로울 가능성으로, 순간적이고 상황에 따라 달라진다. - **신뢰(Trust)**는 시간에 걸쳐 쌓이는 평판이며, 방문자의 행동 맥락을 바탕으로 형성된다. - 예를 들어 밤늦게 초인종을 여러 번 누르는 행동만 보면 위험해 보이지만, 방문자가 신뢰하는 친구라면 판단이 달라진다. - 인터넷에서도 “특정 시간대의 요청”이나 “일정 횟수 이상의 요청”만으로 차단하면 정상적인 사용자를 오탐할 수 있다. - Cloudflare는 악성 활동을 차단하는 것부터 안전한 참여를 장려하는 것까지, 신뢰를 중심으로 한 도구와 인센티브를 제공하려 한다. ## 투명성을 기반으로 한 정상 봇 - Cloudflare가 정의하는 검증된 봇과 에이전트는 다음 두 조건을 만족해야 한다. - 자신이 누구인지 정직하게 선언한다. - 획득한 신뢰를 악용하지 않는다. - 봇 운영자가 정체성과 데이터 사용 목적을 투명하게 공개하면, 사이트 운영자는 허용할 행동과 접근 범위를 더 쉽게 결정할 수 있다. - **BotBase**는 단순히 “좋은 봇 목록”을 제공하는 디렉터리가 아니라, 알려진 봇과 에이전트의 신원 및 행동 정보를 추적하는 시스템이다. - 검증된 봇이라도 Cloudflare 네트워크에서 신뢰를 남용하면 검증 상태를 잃을 수 있다. - 즉, 정상 여부는 고정된 신분이 아니라 실제 행동과 신뢰 유지 여부에 따라 계속 평가된다. ## 일회성 검사를 넘어서는 악성 봇 탐지 - **Precursor**는 CDN에서 JavaScript를 주입해 클라이언트 측 행동을 지속적으로 분석하는 시스템이다. - CAPTCHA나 한 번의 브라우저 검사는 특정 시점의 위험만 평가하므로, 이후 악성 행동을 시작하는 봇을 놓칠 수 있다. - Precursor는 페이지 이동을 포함한 전체 세션을 관찰해 인간답지 않은 행동 패턴을 탐지한다. - 주요 효과는 다음과 같다. - 세션 전체에 걸친 신뢰 기반 탐지 - 봇 개발자가 여러 페이지에 걸쳐 인간 행동을 모방해야 하도록 비용 증가 - 단 한 번의 검사만 통과한 자동화 트래픽에 지속적인 우회 기회를 주지 않음 - 이는 봇 개발자가 탐지 시스템을 우회하는 경제적 이점을 줄여, 공격자와 방어자 사이의 경쟁에서 방어 측에 유리하게 만든다. ## 세션 중간에 나타나는 의심스러운 행동 - 출시 후 24시간 동안 Precursor는 Cloudflare 네트워크의 73,438개 존에서 2억 600만 건의 평가 이벤트를 처리했다. - 분석 결과, 의심스러운 행동은 세션 시작 시점이 아니라 **세션 중간에 발생하는 경우가 많았다**. - 한 세션이 인간 행동에서 에이전트 행동으로, 다시 인간 행동으로 바뀌는 사례도 확인됐다. - 따라서 무조건 봇을 차단하기보다 다음 요소를 기준으로 분류해야 한다. - 트래픽의 사용 목적 - 요청의 의도 - 접근하는 데이터의 종류와 사용 방식 - 이 같은 하이브리드 트래픽을 정상적인 사용자 흐름과 구분하려면, 세분화된 봇·에이전트 분류 체계가 필요하며 BotBase 개편의 배경도 여기에 있다. ## Precursor Trace와 행동 신호 - **Precursor Trace**는 Precursor 탐지 방식 일부를 체험할 수 있는 인터랙티브 데모다. - 커서 움직임을 분석해 다음과 같은 특징을 보여준다. - 움직임의 가속과 감속 - 이동 중 수정이나 보정 - 커서 이동의 리듬과 질감 - 사람은 무의식적으로 이러한 불규칙성을 보이지만, 자동화 프로그램이 이를 여러 페이지와 긴 시간 동안 정확히 재현하기는 어렵다. ## 적응형 인텔리전스 - Cloudflare는 자동화 여부를 단순한 이진값으로만 판단하지 않고, 요청에 대한 평가 결과를 여러 단계로 구분하는 **Adaptive Intelligence**를 준비하고 있다. - 제공된 글의 본문은 이 기능의 구체적인 평가 단계와 출시 내용이 이어지기 전에 끝나 있어, 세부 사항은 확인할 수 없다. 사이트 운영자는 CAPTCHA 같은 단발성 방어책에만 의존하기보다 세션 전체의 행동, 봇의 신원 공개, 목적과 데이터 사용 방식을 함께 평가하는 것이 좋다. 정상적인 자동화는 투명성과 신뢰를 바탕으로 허용하고, 신뢰를 악용하거나 세션 중간에 비정상 행동을 보이는 트래픽은 지속적으로 재평가하는 접근이 적절하다.

cloudflarejavascriptagentic-aicdn+3

cloudflare2026년 8월 7일

Cloudflare 앰배서더와 커뮤니티 엔지니어, 그리고 오픈 소스에 대한 추가 100만 달러 지원 발표 (새 탭에서 열림)

Cloudflare는 개발자들이 서로 가르치고, 오픈소스에 기여하며, 커뮤니티를 성장시키는 활동을 체계적으로 지원하기 위해 커뮤니티 프로그램을 개편한다. 프로그램은 커뮤니티 행사를 이끄는 **Cloudflare Ambassadors**와 오픈소스 프로젝트에 기여하는 **Cloudflare Community Engineers**의 두 축으로 운영된다. 또한 빠르게 성장한 Discord 커뮤니티를 자동화 도구와 새로운 운영위원회로 개선할 계획이다. ## 커뮤니티 프로그램 개편 - Cloudflare는 개발자 교육, 행사 운영, 오픈소스 유지보수처럼 인터넷 생태계에 기여하는 사람들을 지원하고 인정하려 한다. - 새 프로그램의 두 가지 트랙은 다음과 같다. - **Cloudflare Ambassadors**: 각자의 지역·학교·온라인 커뮤니티에 Cloudflare를 알리고 활동을 확산 - **Cloudflare Community Engineers**: 인터넷과 Cloudflare 생태계를 개선하는 오픈소스 프로젝트에 기여 - 프로그램 관련 정보와 참여 신청은 `cloudflare.com/community`에서 제공된다. ## Cloudflare Ambassadors의 역할 - 앰배서더는 Cloudflare를 자신의 커뮤니티에 소개하고, 다른 개발자들이 실제로 제품을 활용하도록 돕는다. - 활동 사례는 다음과 같다. - 밋업, 해커톤, 워크숍, 강연 개최 - 대학 내 학생 그룹 운영 - 개발자가 함께 학습할 수 있는 공간 조성 - 튜토리얼 작성과 온라인 콘텐츠 공유 - Cloudflare의 활용 가능성을 설명하는 기술 지원 - 선정된 앰배서더는 최대 2년 동안 활동할 수 있어, 단기 이벤트가 아니라 지속적인 커뮤니티 성장을 추진할 수 있다. ## 앰배서더 지원 내용 - 커뮤니티 행사를 개최할 때 다음과 같은 지원을 신청할 수 있다. - Cloudflare 크레딧 - 마케팅 자료 - 기술 리소스 - 행사 운영에 필요한 추가 지원 - Discord 등 Cloudflare 온라인 커뮤니티에서 공식적인 역할과 식별 표시를 제공한다. - 당시 지원서 접수 기간은 9월 6일까지이며, 선정 결과는 10월 5일까지 통보될 예정이었다. - 미시간대학교 학생 Sruthi Pereddy의 사례처럼, 학생과 개발자들이 리소스 부족 때문에 아이디어를 실행하지 못하는 문제를 Cloudflare 인프라로 해결하려는 활동을 장려한다. ## Cloudflare Community Engineers와 오픈소스 지원 - Cloudflare Developer Platform은 `workerd`, `quiche` 등 오픈소스 프로젝트에 크게 의존하거나 직접 오픈소스로 제공된다. - 유지보수자와 기여자는 장기간 핵심 라이브러리, 문서, 도구, 커뮤니티를 관리하지만 그 기여가 충분히 보상받지 못하는 경우가 많다. - Cloudflare는 기존 TanStack 후원에 이어 Community Engineers 프로그램을 통해 오픈소스 기여자에게 직접적인 지원을 제공한다. - 향후 2년 동안 오픈소스 프로젝트 후원과 지원에 **추가 100만 달러**를 투입하고, 자격을 갖춘 Community Engineer에게 보조금을 지급한다. - 프로그램에는 최대 활동 기간이 없다. - 오픈소스 유지보수는 연 단위 일정에 맞지 않을 수 있다. - 어떤 프로젝트는 수년간 관리가 필요하고, 어떤 기여는 특정 시점에 집중적으로 발생하기 때문이다. - 초기 지원 대상은 Cloudflare 오픈소스 생태계와 가까운 프로젝트다. - Astro - Agents SDK - EmDash - Hono - Vinext - Community Engineer에게는 Cloudflare Discord와 기타 온라인 공간에서 특별한 표식이 부여된다. - 보조금 신청은 추후 시작될 예정이다. ## Cloudflare Discord 커뮤니티 개선 - 2020년 개설된 Cloudflare Discord에는 약 10만 명의 사용자가 참여했다. - Discord는 질문, 프로젝트 공유, 제품 피드백이 이루어지는 주요 공간으로 성장했다. - 커뮤니티가 커질수록 스팸, 악성 링크, 운영 부담도 증가하기 때문에 다음과 같은 개선을 추진한다. - Cloudflare 직원과 앰배서더가 참여하는 새로운 Discord 위원회 구성 - 스팸과 악성 링크를 차단하는 자동화 도구 도입 - 운영 자동화 도구를 향후 오픈소스로 공개 - 위원회의 핵심 역할은 단순한 관리자 업무나 채팅방 감시가 아니다. - 질문자를 적절한 도메인 전문가에게 연결 - Cloudflare 내부 팀과 커뮤니티 간 대화 주선 - 기술 세션과 협업 기회 마련 - 커뮤니티 콘텐츠와 성장 기회에 집중 - 제공된 글은 Discord를 “더 쉽게…” 개선하겠다는 대목에서 끝나므로, 이후 구체적인 계획은 확인할 수 없다. Cloudflare의 방향은 단순히 제품 사용자를 늘리는 데서 벗어나, 교육자·행사 주최자·오픈소스 유지보수자를 장기적으로 지원하는 생태계를 만드는 데 있다. Cloudflare를 활용하는 개발자라면 앰배서더 프로그램을, 관련 오픈소스 프로젝트를 유지하거나 기여한다면 Community Engineer 보조금 프로그램을 검토할 만하다.

discordcloudflareopen-sourcecloudflare-workers+4

cloudflare2026년 8월 7일

Workers AI와 AI Gateway를 하나의 AI 제어 플레인으로 통합하기 (새 탭에서 열림)

AI Gateway와 Workers AI는 각각 모델 호출 프록시와 Cloudflare 관리형 추론 서비스로 출발했지만, 이제 하나의 통합 AI 제어 평면으로 수렴하고 있다. 사용자는 단일 바인딩과 REST API를 통해 Workers AI를 포함한 여러 모델 제공자를 호출하면서 관측성, 로깅, 보안, 비용 관리, 결제를 한곳에서 처리할 수 있다. 향후에는 제공자가 아니라 원하는 모델을 기준으로 자동 라우팅·장애 조치·부하 분산까지 수행하는 모델 우선 라우팅을 제공할 계획이다. ## 통합된 바인딩과 REST API - Workers AI와 AI Gateway는 별도의 호출 경로가 아니라 동일한 `env.AI.run()` 바인딩으로 통합된다. - `gateway: { id: "default" }`를 지정하면 기본 AI Gateway를 통해 Workers AI 모델을 호출할 수 있다. - REST API도 통합되어 다음과 같은 `/ai/` 엔드포인트를 사용한다. - `https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/{model}` - `cf-aig-gateway-id: default` 헤더로 기본 게이트웨이를 지정 - 사용자는 처음부터 Workers AI와 AI Gateway 중 어느 제품을 선택할 필요 없이 관측성과 제어 기능이 포함된 경로를 사용할 수 있다. - 여러 애플리케이션을 분리하거나 애플리케이션별 정책을 적용해야 하는 경우에는 별도의 이름 있는 게이트웨이를 지정할 수 있다. ## 자동 관측성과 제어 - AI Gateway를 사전에 생성하지 않아도 `default` 게이트웨이를 처음 인증 요청에 사용하면 자동으로 생성된다. - 별도 대시보드 설정 없이 다음 정보가 기록된다. - 요청 및 응답 전문 - 모델별 토큰 사용량 - 요청 비용 및 비용 귀속 - 지연 시간 분석 - 오류율 - 기존 Workers AI 직접 호출에 게이트웨이 옵션만 추가하면 전체 관측성을 활성화할 수 있다. - 이후 캐싱 규칙을 사용자 지정하거나 애플리케이션별로 트래픽을 분리하려면 이름 있는 게이트웨이로 변경하면 된다. - 프롬프트와 응답까지 확인할 수 있어 모델 동작 디버깅과 AI 출력 감사에 유용하다. ## AI Gateway 크레딧과 Workers AI 통합 결제 - 기존에는 AI Gateway 크레딧을 OpenAI, Anthropic 등 외부 제공자에만 사용할 수 있었다. - 이제 동일한 크레딧 지갑으로 다음 서비스의 사용량을 결제할 수 있다. - OpenAI - Anthropic - Workers AI - 기타 지원 모델 제공자 - Workers AI에도 선불 결제가 적용된다. - AI Gateway 통합 결제를 사용하는 Workers AI 이용자에게는 더 높은 요청 한도가 제공될 수 있다. - 실제 한도와 상향 요청 방법은 최신 개발자 문서를 확인해야 한다. ## 모델 우선 라우팅 - 현재는 사용자가 특정 제공자를 직접 선택해야 하므로, 해당 제공자의 장애나 속도 제한이 애플리케이션 장애로 이어질 수 있다. - 향후에는 “어느 제공자를 호출할지”가 아니라 “어떤 모델이 필요한지”를 지정하는 방식으로 전환한다. - 추론 능력이 높은 모델 - 빠른 요약 모델 - 저렴한 임베딩 모델 - AI Gateway가 모델을 호스팅하는 제공자를 선택하고 다음 작업을 자동으로 처리한다. - 제공자 선택 - 장애 조치 - 부하 분산 - 용량 부족 시 다른 제공자로의 투명한 전환 - 예를 들어 `kimi-k2.7-code`를 요청하면 Workers AI, Moonshot API 또는 동일 가중치를 제공하는 다른 검증된 제공자 중 적절한 경로가 선택될 수 있다. - 원하면 특정 제공자에 고정할 수도 있다. - 검증된 제공자를 사용하고 Zero Data Retention(ZDR) 같은 데이터 처리 요구사항도 반영할 예정이다. ## 실용적인 적용 방향 새 프로젝트라면 `default` 게이트웨이를 사용해 별도 설정 없이 로그, 토큰 사용량, 비용, 오류율을 확보하는 것이 권장된다. 애플리케이션이 커지면 이름 있는 게이트웨이로 분리하고 캐싱·보안·라우팅 정책을 세분화하면 된다. 장기적으로는 특정 제공자에 강하게 결합하기보다 모델 중심으로 호출 구조를 설계하는 편이 장애 대응과 비용 최적화에 유리하다.

observabilityrest-apiai-gatewayload-balancing+3

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

llmcloudflare-workersdurable-objectssqlite+3

cloudflare2026년 8월 6일

개방형 에이전틱 인터넷 구축하기: 읽을 수 있고, 발견 가능하며, 호출 가능하고, 결제 가능한 (새 탭에서 열림)

에이전트가 사람을 대신해 웹을 읽고, 행동하고, 비용을 지불하는 시대가 오면서 기존의 인간 중심 웹은 한계에 부딪히고 있다. Cloudflare는 이를 “에이전틱 인터넷”이라 부르며, 웹이 에이전트에게 읽기 쉽고(readable), 발견 가능하며(discoverable), 호출 가능하고(callable), 결제 가능해야 한다고 주장한다. 이를 위해 특정 기업에 종속되지 않는 개방형 표준과 도구를 구축해야 하며, 궁극적으로 에이전트와 웹사이트가 충돌하는 대신 협력하는 구조를 만들어야 한다. ## 에이전트가 바꾸는 웹의 전제 - 기존의 `User-Agent`는 브라우저가 사용자를 대신해 웹을 방문한다는 의미였지만, 이제는 실제로 사람이나 기업을 대신해 작업하는 프로그램이 웹의 방문자가 되고 있다. - 코딩 에이전트는 문서를 읽고, 코드를 작성하며, 필요한 페이지를 가져오지만 CSS를 렌더링하거나 광고를 보지는 않는다. - 에이전트의 각 요청에는 비용을 지불하는 사람과 구체적인 목적이 있다. - 에이전트를 단순 스크래퍼로 차단하면 실제 고객의 요청까지 막게 되고, 기존의 페이지뷰·광고 중심 분석과 비즈니스 모델도 제대로 작동하지 않는다. - 현재 웹에는 변경되지 않은 페이지를 정상적인 봇이 반복해서 가져오는 요청이 수십억 건 발생하며, 이는 막대한 컴퓨팅 자원의 낭비를 보여준다. ## 개방형 에이전틱 인터넷 - 에이전틱 인터넷의 미래는 특정 플랫폼이 검색, 신원 확인, 결제를 독점하는 방식과 개방형 표준을 사용하는 방식으로 나뉠 수 있다. - Cloudflare는 누구나 구현할 수 있는 공개 표준을 기반으로 한 개방형 인터넷을 지향한다. - 핵심 기술로 다음을 제시한다. - **x402**: 에이전트가 웹 리소스나 서비스에 직접 비용을 지불하는 결제 표준 - **MCP**: 에이전트가 도구와 기능을 발견하고 호출하기 위한 프로토콜 - **Web Bot Auth**: 봇이 자신을 암호학적으로 증명하는 인증 방식 - **PACT**: 신뢰할 수 있는 사이트가 에이전트를 익명으로 보증하는 토큰 - 도메인 소유자는 원하는 인증 제공자, 결제 사업자, 에이전트 파트너를 선택할 수 있으며 Cloudflare도 여러 선택지 중 하나로 남아야 한다. ## 신원 확인과 신뢰 - **Web Bot Auth**를 사용하면 사이트는 User-Agent 문자열에 의존하거나 위조 여부를 추측하지 않고, 방문한 봇의 신원을 암호학적으로 확인할 수 있다. - 사이트는 자신이 이미 로그인, 앱 사용 기록, 구매 이력 등을 통해 알고 있는 사용자를 기반으로 에이전트에게 **PACT(Private Access Control Tokens)**를 발급할 수 있다. - 에이전트는 다른 사이트에서 이 토큰을 제시해 자신이 신뢰할 만한 사용자와 연결되어 있음을 증명할 수 있다. - 이를 통해 정상적인 에이전트는 불필요한 차단과 CAPTCHA를 줄이고, 사이트는 악성 자동화 트래픽을 더 정확히 구분할 수 있다. ## Readable: 에이전트가 읽기 쉬운 웹 - 에이전트는 인간처럼 화면을 보고 CSS를 해석하지 않으므로, 인간용 HTML 전체를 전달하는 방식은 토큰과 대역폭을 낭비한다. - 보이지 않는 장식 요소와 레이아웃 정보는 에이전트의 컨텍스트를 오염시키고, 결국 처리 비용을 증가시킨다. - **Markdown for Agents**는 서버 측에서 에이전트가 필요한 콘텐츠를 더 간결한 Markdown 형태로 제공하는 접근이다. - Cloudflare의 **Kitesurf**는 에이전트를 일급 사용자로 고려한 브라우저로, Workers에서 요청마다 실행하고 폐기할 수 있도록 가볍게 설계되었다. - 에이전트는 인간용 브라우저의 광고, 시각 효과, 기타 불필요한 기능 없이 콘텐츠와 기능에 직접 접근할 수 있다. ## Discoverable: 에이전트가 자원을 찾는 방법 - 에이전트가 콘텐츠를 읽거나 도구를 호출하거나 결제하려면 먼저 해당 자원이 존재한다는 사실을 알아야 한다. - 인간용 검색창과 키워드 중심 검색만으로는 에이전트의 목적과 작업 흐름을 충분히 지원하기 어렵다. - **AI Search**는 공개 웹사이트가 에이전트 검색 결과에 포함되도록 지원한다. - 반대로 콘텐츠 제작자와 API 운영자는 자신의 서비스가 에이전트에게 얼마나 노출되는지도 측정해야 한다. - **AEO(Agent Engine Optimization)**는 주요 모델과 에이전트에서 브랜드나 콘텐츠가 얼마나 잘 발견되는지를 측정한다. - 고객이 사용하는 에이전트에서 발견되지 않는 서비스는 사실상 해당 고객에게 오프라인 상태가 된다. ## Callable: 웹 기능을 직접 호출하기 - 인간용 웹에서는 예약, 구독 갱신, 보고서 조회 같은 기능이 버튼과 폼으로 구현되어 있다. - 에이전트가 이를 사용하려면 HTML을 분석하고, 어떤 버튼이 작업을 수행하는지 추측하고, DOM 변화에 대응해야 한다. - **WebMCP**는 웹사이트가 브라우저 안에서 에이전트에게 기능을 명시적으로 도구로 노출하도록 한다. - 예를 들어 `add-todo` 도구는 다음 정보를 직접 선언할 수 있다. - 도구 이름과 설명 - 입력값의 JSON 스키마 - 실제 작업을 수행하는 함수 - 실행 결과 - 이 방식에서는 HTML 파싱이나 버튼 위치 추측이 필요 없다. - 도구가 페이지 내부에서 실행되므로 기존 사용자의 로그인 세션과 상태를 그대로 활용할 수 있다. - **Code Mode**는 에이전트가 자연어로 도구를 호출하는 대신 코드로 직접 호출하도록 해 정확성과 속도를 높인다. - 사이트 운영자는 에이전트가 어떤 기능과 콘텐츠를 실제로 사용하는지 명확한 호출 신호를 얻을 수 있다. ## Payable: 에이전트가 직접 지불하는 웹 - 광고 기반 모델은 에이전트가 광고를 보거나 페이지를 렌더링하지 않기 때문에 약화될 수밖에 없다. - 사용자 단위 좌석 과금도 한 명의 사람이 프로그램을 통해 작업하는 상황에는 적합하지 않다. - 에이전트가 요청마다 소액을 지불하면 기존의 페이지뷰나 광고 노출 없이도 콘텐츠 제공자가 수익을 얻을 수 있다. - 예를 들어: - 레시피 사이트는 fetch 한 건당 아주 작은 금액을 받아 수익성을 확보할 수 있다. - 지역 신문은 별도 장기 라이선스 계약이나 로그인 없이 기사 열람 시점에 과금할 수 있다. - 에이전트는 사용자가 미리 설정한 지갑과 예산을 가지고 서비스에 접근하며, 결제는 에이전트가 직접 처리한다. - 따라서 에이전틱 인터넷에서는 콘텐츠 접근 자체가 작고 자동화된 경제적 거래가 될 수 있다. ## 실용적인 시사점 웹사이트 운영자는 에이전트를 무조건 차단하거나 스크래퍼로 취급하기보다, 봇 신원 확인·에이전트용 콘텐츠 제공·명시적 도구 API·소액 결제를 함께 설계해야 한다. 특히 기존 HTML UI를 에이전트가 추측하게 두기보다는 WebMCP 같은 명시적 계약을 제공하고, 에이전트 검색 노출과 실제 호출량을 별도로 측정하는 것이 중요하다.

cloudflare-workerswebmcpx402agentic-internet+2

cloudflare2026년 8월 6일

Cloudflare AI 검색: 에이전트에게 데이터 검색 엔진을 제공하세요 (새 탭에서 열림)

Cloudflare AI Search는 Workers AI, AI Gateway, Vectorize, R2, Browser Run 등을 직접 조합하지 않아도 에이전트용 검색 엔진을 구축할 수 있도록 개발자 경험을 개선했다. 웹사이트와 파일을 쉽게 색인하고, 여러 데이터 소스를 하나의 검색 엔드포인트나 MCP 엔드포인트로 통합할 수 있으며, 임베딩과 재순위화 비용은 일부 기본 모델 사용 시 무료다. Cloudflare는 이를 자사 문서·블로그·개발자 생태계 검색과 Dev Stack MCP에 실제로 적용하고 있다. ### 에이전트용 데이터 색인 - 구조화·비구조화 데이터를 AI 에이전트가 검색할 수 있도록 색인한다. - 개별 파일뿐 아니라 소유권을 확인할 수 있는 웹사이트도 데이터 소스로 사용할 수 있다. - AI Search가 웹 크롤링, 데이터 수집, 임베딩, 검색 결과 반환 과정을 처리한다. - 현재는 Cloudflare 계정에 등록된 zone이어야 하며, 향후 소유권 확인 방식이 확대될 예정이다. ### 사이트맵 없이 웹사이트 검색 구축 - 기존에는 웹사이트 연동에 sitemap이 필요했다. - 이제 `Discover` 파싱 옵션을 사용하면 sitemap이 없는 사이트도 링크를 따라가며 페이지를 발견하고 색인할 수 있다. - 내부적으로 Browser Run의 `/crawl` 기능을 활용해 페이지를 탐색한다. - Wrangler 명령어 예시는 다음과 같다. ```bash npx wrangler ai-search instance create cloudflare-community \ --namespace dev-stack \ --source https://community.cloudflare.com \ --type web-crawler \ --parse-type discover ``` ### 여러 검색 인스턴스를 하나로 통합 - 하나의 namespace 안에 여러 웹사이트나 데이터 인스턴스를 구성할 수 있다. - `/search`와 `/mcp` 공개 엔드포인트를 활성화하면 여러 인스턴스를 한 번에 검색할 수 있다. - 별도 Worker를 작성하지 않고도 여러 소스를 대상으로 통합 검색을 제공할 수 있다. - 검색 결과에는 출처 인스턴스 정보와 인용 가능한 청크가 포함된다. ### Worker와 MCP를 통한 검색 연동 - 기존 애플리케이션이나 MCP 서버에 검색 기능을 포함하려면 namespace를 Worker에 바인딩한다. - Worker에서는 `AI_SEARCH.search()`를 호출하고, `instance_ids`로 검색 대상들을 지정한다. - `max_num_results`로 결과 수를 제한하고 `reranking.enabled`로 재순위화를 활성화할 수 있다. - Cloudflare Dev Stack MCP는 이 방식을 사용해 Docs, Blog, API Docs, Community, Astro, Vite, Vitest, Hono, Replicate, OpenNext 등 여러 표면을 한 번에 검색한다. ```json { "ai_search_namespaces": [ { "binding": "AI_SEARCH", "namespace": "cloudflare-stack" } ] } ``` - 간단히 공유 가능한 검색 URL만 필요하다면 Worker 대신 공개 엔드포인트를 활성화하면 된다. ### 공개 엔드포인트와 사용자 도메인 - namespace에 공개 URL을 활성화하면 다음 엔드포인트가 제공된다. - `/search`: 일반 검색 API - `/mcp`: MCP 클라이언트와 에이전트 연동용 엔드포인트 - 기본 공개 URL 대신 `search.example.com/mcp`처럼 사용자 정의 도메인을 연결할 수 있다. - Cloudflare Access를 도메인 앞에 배치하면 공개 엔드포인트를 인증 기반의 비공개 검색 서비스로 전환할 수 있다. ### 예측 가능한 가격 모델 - AI Search는 임베딩 및 재순위화 비용을 포함하는 방향으로 가격 모델을 설계했다. - Workers AI 카탈로그의 일부 기본 모델을 사용하면 임베딩과 재순위화가 무료다. - 토큰 수를 직접 계산해 비용을 예측해야 하는 부담을 줄이고, 데이터 규모가 커져도 비용을 예측하기 쉽게 만드는 것이 목표다. - 가격은 현재 프리뷰 단계다. ### EmDash와 Cloudflare 서비스에 적용 - Cloudflare의 오픈소스 CMS인 EmDash에는 AI Search 플러그인을 추가할 수 있다. - 이 플러그인은 EmDash로 구축한 사이트 콘텐츠에 의미 기반 검색을 제공한다. - Cloudflare는 AI Search를 Blog, Developer Docs, Cloudflare.com, EmDash 기반 사이트 등에 실제 검색 기능으로 사용하고 있다. ### Cloudflare Dev Stack MCP 사례 - Dev Stack MCP는 Cloudflare 개발자 생태계 전체에서 최신 문서를 검색해 코딩 에이전트에 제공한다. - 검색 결과에 출처와 인용 정보가 포함되어 최신 기능과 수정 사항을 반영할 수 있다. - 기존처럼 웹 검색 후 여러 페이지를 직접 가져오는 방식보다 빠르고, 토큰 사용량이 적으며, 오래되거나 부정확한 문서를 선택할 가능성이 낮다. - MCP 설정에 다음 URL을 추가하면 에이전트에서 사용할 수 있다. ```json { "mcpServers": { "dev-stack": { "url": "https://stack.mcp.cloudflare.com/mcp" } } } ``` Cloudflare AI Search는 여러 Cloudflare 서비스를 직접 연결해야 했던 검색 구축 과정을 단순화하고, 웹사이트·문서·MCP를 하나의 검색 계층으로 묶는 데 초점을 둔다. 기존 애플리케이션에 통합하려면 Worker 방식을, 빠르게 공유 가능한 검색 기능이 필요하면 공개 `/search` 또는 `/mcp` 엔드포인트를 선택하는 것이 적합하다.

cloudflare-workersmcpembeddingscloudflare-access+4

cloudflare2026년 8월 6일

순위에서 추천으로: AI 에이전트 시대에 성공할 수 있도록 사이트를 준비하세요 (새 탭에서 열림)

AI 에이전트가 검색엔진을 대신해 고객의 질문에 답하고 제품·서비스를 추천하는 시대가 오면서, 웹사이트의 발견 가능성은 검색 순위뿐 아니라 에이전트가 사이트를 읽고 신뢰하며 추천할 수 있는지에 달려 있다. Cloudflare는 이를 위해 에이전트가 사이트를 실제로 이용할 수 있는지 점검하는 **Agent Readiness Diagnostics**와, AI 답변에서 브랜드가 얼마나 추천·인용되는지 측정하는 **AEO** 도구를 제공한다. 앞으로는 사람이 읽기 좋은 사이트를 넘어, 에이전트가 쉽게 찾고 읽고 호출할 수 있는 사이트가 경쟁력을 갖게 된다. ## 에이전트 중심으로 바뀌는 웹사이트 발견 방식 - 고객은 검색 결과 페이지보다 AI 어시스턴트에게 직접 질문하고 추천을 받을 가능성이 커지고 있다. - HTML 페이지 요청 중 인간이 직접 발생시키는 요청은 절반 이하이며, 나머지에는 크롤러·자동화 도구·AI 에이전트 등이 포함된다. - 기존의 클릭 수와 페이지뷰만으로는 다음을 알기 어렵다. - AI 에이전트가 사이트에 접근하고 콘텐츠를 사용할 수 있는지 - AI 답변에서 경쟁사 대신 자사 브랜드가 추천되는지 - 에이전트에게 중요한 사이트의 조건은 다음과 같다. - 쉽게 발견될 것 - 기계가 읽기 쉬울 것 - 정보의 출처와 신뢰성이 명확할 것 - 필요한 경우 API나 도구를 통해 직접 작업할 수 있을 것 ## Agent Readiness Diagnostics: 에이전트가 사이트를 사용할 수 있는가 Diagnostics는 사람이 브라우저로 접속하는 방식이 아니라, 에이전트가 사이트를 해석하는 방식으로 기술 상태를 점검한다. - 주요 점검 대상 - `robots.txt` 접근 규칙 - XML 사이트맵 - HTTP 응답 헤더 - 에이전트용 Markdown 콘텐츠 - 인증 및 도구 사용을 위한 공개 메타데이터 - 결과는 “Not Ready”부터 완전한 에이전트 네이티브 상태까지 하나의 준비도 화면으로 통합된다. - 각 항목은 다음 정보를 제공한다. - 통과, 실패, 중립 상태 - 해당 검사가 중요한 이유 - 실제 요청과 응답을 확인할 수 있는 증거 - 개선 항목은 구현 난이도와 우선순위에 따라 나뉜다. ### 빠른 개선 항목 - 크롤러가 읽을 수 있는 `robots.txt` - XML 사이트맵 - AI 크롤러를 위한 접근 규칙 - 에이전트가 처리하기 쉬운 정제된 Markdown 콘텐츠 ### 기술적 기반 - 콘텐츠를 어떤 방식으로 사용해도 되는지 선언하는 Content Signals - API 카탈로그 - 링크 헤더 - 에이전트 로그인 지침 ### 고급 에이전트 통합 - OAuth 검색·발견 기능 - MCP(Model Context Protocol) - A2A(Agent2Agent) 에이전트 카드 - skills index - Web Bot Auth - WebMCP ### 에이전트 상거래 - x402: HTTP 402 Payment Required를 확장한 결제 표준 - ACP(Agent Commerce Protocol) - UCP(Universal Commerce Protocol) - AP2(Agent Payments Protocol) 상거래 관련 항목은 현재 정보 제공 목적이며 준비도 점수에는 포함되지 않는다. ## 진단 결과를 실제 개선으로 연결하는 방식 - Cloudflare 기능으로 해결할 수 있는 문제에는 바로 설정 화면으로 이동하는 “Set up in Cloudflare” 링크가 제공된다. - 예: 에이전트용 Markdown 활성화 - 관리형 `robots.txt` 설정 - 별도 개발이 필요한 경우 “Copy Agent Prompt” 버튼으로 코딩 에이전트에 전달할 구현 지침을 생성할 수 있다. - 변경 후 다시 스캔해 해결 여부를 확인하고, 통과한 항목을 즉시 확인할 수 있다. ## AEO: AI 어시스턴트가 브랜드를 추천하는가 AEO는 사이트를 읽을 수 있는지에서 더 나아가, 실제 고객 질문에 AI가 해당 브랜드를 추천하는지를 측정한다. - Cloudflare는 사이트에서 산업과 카테고리를 추론한다. - 예: 건강·피트니스 산업 - 예: 스포츠 의류 카테고리 - 이후 Claude와 GPT 같은 주요 AI 어시스턴트에 실제 고객이 할 법한 질문을 입력한다. - 질문 유형은 다음을 포함한다. - 제품·서비스 추천 - 경쟁 제품 비교 - 카테고리 전반에 대한 조언 - 특정 브랜드를 질문에 직접 넣지 않고, 자연스러운 시장 탐색 상황에서 어떤 사이트와 브랜드가 선택되는지 측정한다. ## AEO에서 사용하는 주요 지표 - **Citation Rate** - 해당 카테고리의 AI 답변 중 자사 사이트가 출처로 인용된 비율 - **Prominence** - 인용된 경우 답변의 얼마나 앞부분에 등장하는지 - 답변 내용 중 자사 사이트에 얼마나 많은 비중이 귀속되는지 - **Mention Rate** - 출처 링크 여부와 관계없이 답변에서 브랜드명이 언급되는 비율 - 언급률은 높지만 인용률이 낮다면 브랜드 인지도는 있으나 신뢰할 만한 출처로 인정받지는 못하고 있다는 뜻이다. - **Share of Voice** - 경쟁사 대비 자사가 차지하는 인용 비중 - 어떤 질문에서 경쟁사에 밀리는지 파악할 수 있다. - **Industry Fit** - AI가 해당 사이트를 실제 경쟁사들과 함께 인식하는 정도를 나타내는 점수 ## 카테고리별 벤치마크와 사전 계산 - Cloudflare는 산업·카테고리별로 브랜드를 지정하지 않은 질문을 AI에 먼저 질의한다. - 이 과정에서 다음 정보를 수집한다. - 어떤 사이트가 인용되는지 - 답변에서 어느 위치에 등장하는지 - 얼마나 큰 비중으로 다뤄지는지 - 카테고리별 기준 데이터를 한 번 구축한 뒤 여러 계정에서 재사용한다. - 이 방식의 장점 - 매번 AI 모델을 다시 호출하지 않아 결과가 즉시 표시된다. - 수천 개 사이트가 같은 질문을 반복하는 데 따른 컴퓨팅 비용을 줄인다. - 동일 시장에서 함께 등장하는 브랜드를 파악해 Industry Fit을 계산할 수 있다. ## AI 답변의 변동성을 반영한 평가 방식 - AI는 같은 질문에도 매번 완전히 동일한 답변을 생성하지 않는다. - 이를 보완하기 위해 Cloudflare AI Gateway를 사용해 여러 모델과 여러 번의 질의를 수행한다. - 평가 대상은 단순한 브랜드 언급이 아니다. - 사이트가 출처로 인용됐는지 - 인용이 답변의 앞부분에 나오는지 - 답변의 실질적인 내용이 사이트에 얼마나 귀속되는지 - Workers AI가 답변을 분석하고 점수를 계산한다. - 모델이 자기 답변을 다시 평가하는 방식이 아니라, 응답 텍스트와 출처를 대상으로 정확한 텍스트 분석을 함께 사용한다. - 따라서 직접 다중 모델 평가 시스템을 구축하지 않아도 실행 가능한 AEO 지표를 얻을 수 있다. ## AI Operator Activity로 실제 유입과 오류 확인 - AI Operator Activity는 실제 운영자별 크롤링 및 추천 트래픽을 보여준다. - 확인 가능한 정보 - OpenAI, Google 등 어떤 운영자가 사이트를 읽는지 - 어떤 운영자가 방문자를 사이트로 보내는지 - 크롤링·추천 과정에서 발생한 오류 - `403`: 접근 차단 - `404`: 잘못되거나 사라진 링크 - 이를 통해 AI가 사이트를 발견하지 못하는 문제와, 발견했지만 접근·탐색 과정에서 실패하는 문제를 구분할 수 있다. 사이트 운영자는 먼저 `robots.txt`, 사이트맵, Markdown 콘텐츠 같은 기본적인 기계 가독성을 확보한 뒤, API·OAuth·MCP 등 직접 실행 가능한 인터페이스를 추가하는 것이 좋다. 이후 AEO 지표를 통해 인용률과 경쟁사 대비 점유율을 지속적으로 추적해야 하며, 단순히 AI 봇 방문 수를 늘리는 것보다 실제 추천과 출처 인용으로 이어지는 구조를 만드는 데 집중해야 한다.

cloudflaremodel-context-protocoloauthai-gateway+4

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 인프라를 선택하는 것이 권장된다.

model-context-protocolcloudflare-workersdurable-objectsjson-rpc+2