자연어로 인터넷 데이터를 캐묻는 시대

Cloudflare Radar가 2020년 런칭한 이후로, 전 세계 인터넷 트래픽 데이터를 공개 API로 제공해 왔다는 건 많은 분들이 아실 거예요. 인권 활동가, 기자, 연구자, 네트워크 운영자들이 이 데이터를 실무에 쓰고 있죠.

그런데 문제가 하나 있었습니다. 데이터는 열려 있는데, 접근 장벽이 너무 높았어요. 원하는 답을 얻으려면 알맞은 페이지를 찾고, 필터를 고르고, API 문서를 읽고 쿼리를 짜야 했죠. 특히 마감에 쫓기는 기자가 '이란 인터넷 차단 사태'를 취재한다고 생각해 보세요. 페이지마다 돌아다니면서 그래프를 찾을 시간이 어디 있겠어요.

그래서 Cloudflare가 Agents Week를 맞아 베타로 공개한 게 Radar Researcher입니다. 그냥 자연어로 물어보면, 실제 인터랙티브 차트로 답이 돌아옵니다. 이 글에서는 이 도구가 단순한 'AI 챗봇 붙이기'와 무엇이 다른지, 아키텍처 관점에서 뜯어볼게요.

이 글은 Cloudflare 공식 블로그의 근거자료를 바탕으로 재구성했습니다.

Developer asking natural language questions to Cloudflare Radar Researcher AI chat panel with interactive internet traffic charts Developer Related Image

핵심은 '툴 3개'로 수백 개 API를 다루는 설계

가장 흥미로운 부분은 Radar Researcher가 Radar의 수백 개 엔드포인트마다 툴을 손으로 짜지 않았다는 점입니다. 대신 Cloudflare MCP 서버에 Code Mode로 연결했어요. 모델에게 주는 툴은 딱 세 개뿐입니다.

  • search: OpenAPI 스펙에서 적절한 엔드포인트를 찾음
  • execute: 실제 데이터를 가져오는 코드 스니펫을 실행
  • docs: API 문서 조회

즉, LLM이 스스로 코드를 작성해서 Radar API를 직접 호출합니다. Radar에 새 데이터셋이 추가돼도 프롬프트나 툴 정의를 바꿀 필요가 없어요. 전체 API 스펙이 MCP 서버에 살아 있으니까요.

차트를 '숫자'가 아니라 '스펙'으로 렌더링하는 트릭

여기서 진짜 배울 만한 디테일이 하나 있습니다. LLM은 기본적으로 Markdown으로 답합니다. 그런데 모델이 데이터를 직접 문장에 쓰면 반올림하고, 요약하고, 잘라버리는 습성이 있어요. 데이터 도구로서는 치명적이죠.

Cloudflare의 해법은 데이터를 모델의 산문에서 완전히 분리하는 것입니다. 모델은 숫자를 붙여넣는 대신, API 경로만 참조하는 가벼운 차트 스펙을 emit 합니다.

{ "type": "speedFlower", "title": "Internet speed quality — Portugal", "dataFrom": "/radar/quality/speed/summary?location=PT" }

프론트엔드는 이 dataFrom을 실제 fetch 결과와 매칭시켜서, 사이트 전체에서 쓰는 것과 동일한 시각화 컴포넌트로 렌더링합니다. 결과적으로 차트는 항상 API 원본에 충실하고, 시계열·도넛·지도·히스토그램 등 Radar의 전체 시각화 어휘를 그대로 재활용할 수 있게 됩니다.

인프라 스택: 전부 Cloudflare

  • 컴퓨트: Cloudflare Worker 위에 Agents SDK 구동
  • 상태: 대화마다 Durable Object + SQLite DB (스트리밍 응답 중 페이지 이탈해도 서버에서 계속 생성)
  • 추론: Workers AI로 Kimi K2.7 같은 오픈 모델 구동. 단일 모델에 베팅하지 않고 3개 모델 패밀리 폴백 체인을 돌려서 특정 프로바이더 장애에 견디게 설계
  • 게이트웨이: AI Gateway로 로깅·비용 추적·캐싱·안전 가드레일
  • 저장: 공유 대화는 R2, 프론트엔드는 별도 Worker + service binding

참고로 이런 멀티 에이전트 아키텍처를 실무에서 어떻게 굴리는지는 스포티파이가 광고 플랫폼을 멀티 에이전트 아키텍처로 재구축한 이유 글에서 더 깊게 다뤘어요. 폴백 체인과 에이전트 오케스트레이션 관점에서 같이 보면 이해가 훨씬 잘 됩니다.

Global internet traffic visualization dashboard showing Iran HTTP traffic outage timeline rendered by Radar Researcher IT Technology Image

WebMCP: '남의 에이전트'를 위한 준비

Cloudflare가 이번에 던진 진짜 승부수는 여기입니다. 자사 에이전트만 만든 게 아니라, 브라우저에서 돌아가는 범용 에이전트가 Radar를 직접 조작할 수 있게 WebMCP 표준을 선제 적용했어요.

기존에는 에이전트가 웹사이트를 쓰려면 페이지를 스크래핑하고 DOM을 역설계해야 했습니다. 느리고, 깨지기 쉽고, 오류투성이죠. WebMCP는 페이지가 잘 정의된 툴 세트를 등록하면 브라우저 에이전트가 그걸 발견해서 바로 호출하게 해줍니다.

구분기존 스크래핑 방식WebMCP 방식
접근 방식DOM 파싱·추정등록된 툴 직접 호출
안정성페이지 변경 시 깨짐명세 기반, 안정적
속도느림 (렌더 대기)빠름 (직접 실행)
구현 비용에이전트마다 재작업페이지가 한 번 등록
표준화없음W3C 논의 중 표준

Cloudflare는 두 가지 방식을 모두 지원합니다.

  • Imperative API: JS로 툴을 등록해서 UI를 구동하는 코드를 직접 호출. 국가·지역·대륙·ASN 필터링, 날짜 범위 변경, 엔티티 검색 등
  • Declarative API: 기존 HTML 폼에 속성 몇 개만 붙여서 툴로 전환. URL 스캐너, 도메인 리포트 조회, 포스트퀀텀 TLS 지원 테스트 등

재밌는 건 자기네가 파는 걸 자기가 먼저 적용했다는 점이에요. Radar의 URL Scanner에는 '에이전트 준비도' 체크가 있는데, 여기에 WebMCP 통합 여부를 검사하는 항목이 있습니다. Cloudflare가 직접 구현했으니 Radar는 이제 자기 검사를 스스로 통과합니다.

주의할 점: 아직 베타이고, 한계도 명확합니다

  • 베타 단계: 데이터셋 커버리지가 아직 전체가 아니고, 분석 정확도도 계속 튜닝 중입니다.
  • LLM 할루시네이션 리스크: 차트는 API 원본을 참조하니 안전하지만, 설명 텍스트는 여전히 모델이 생성합니다. 숫자 해석 부분은 반드시 원본 차트와 대조해서 읽어야 해요.
  • WebMCP는 아직 표준화 진행 중: 브라우저 지원이 본격화되기 전까지는 얼리어답터 영역입니다.
  • 공유 링크 30일 만료: 대화 공유 링크는 자동 만료되니, 장기 보관이 필요하면 별도 저장하세요.

다음 단계 학습 방향

이 아키텍처를 직접 따라 만들어 보고 싶다면 순서를 이렇게 잡는 걸 추천합니다.

  1. Cloudflare Agents SDK + Durable Object로 상태 유지되는 대화형 에이전트 뼈대 잡기
  2. MCP 서버 + Code Mode 패턴으로 툴 폭발 문제 해결하기 (툴 N개 → 툴 3개)
  3. AI Gateway 폴백 체인으로 프로바이더 장애 견디는 추론 레이어 구성
  4. WebMCP로 내 서비스에 에이전트 친화적 인터페이스 얹기

특히 2번은 요즘 에이전트 개발의 핵심 트렌드라서, 관련해서는 Kimi Code CLI에 Vercel 플러그인 등장! 에이전틱 개발 시대의 새로운 표준 글도 같이 읽어보시면 흐름이 잡힐 거예요.

Cloudflare Worker and MCP server architecture diagram powering Radar Researcher AI agent with Durable Objects Development Concept Image

정리: '도구를 만드는 도구'로 넘어가는 중

Radar Researcher를 한 줄로 요약하면 이렇습니다. "에이전트에게 툴을 잔뜩 쥐어주지 말고, 코드를 쓸 펜 하나만 쥐어줘라."

수백 개 엔드포인트를 툴로 노출하면 프롬프트가 터지고 유지보수가 지옥이 됩니다. 대신 OpenAPI 스펙을 MCP 서버에 두고, 모델이 search→execute→docs 세 동작만으로 코드를 짜게 하는 겁니다. 이게 지금 에이전트 아키텍처의 실전 해법이에요.

국내 개발 생태계 관점에서 보면, 이 패턴은 사내 API가 수십~수백 개 있는 SI/플랫폼 환경에서 특히 위력적입니다. 매번 툴을 손으로 래핑하는 대신, OpenAPI 스펙만 정리해 두면 에이전트가 알아서 찾아 씁니다. 다만 사내망·권한 체계가 얽혀 있으면 MCP 서버 단에서 인가 레이어를 반드시 설계해야 하고, LLM이 생성한 코드가 실제로 어떤 쿼리를 날리는지 감사 로그(trace) 를 남기는 게 필수입니다. Cloudflare가 'Audit the reasoning' 기능을 넣은 이유가 바로 그거예요.

결국 이 사례가 던지는 메시지는 명확합니다. 웹은 이제 사람만 읽는 문서가 아니라, 에이전트가 호출하는 인터페이스가 되어야 한다는 것. WebMCP가 그 신호탄이고요. 남은 2026년, 내 서비스가 에이전트 친화적인지 한 번쯤 자문해 볼 시점입니다.

Radar Researcher는 지금 Cloudflare Radar에서 베타로 써볼 수 있습니다. 궁금하신 분들은 직접 질문 던져보고, 어떤 trace가 남는지 확인해 보세요. 그게 이 아키텍처를 이해하는 가장 빠른 길입니다.

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.