Every API Is a Tool for Agents
📺 원본 영상: Every API Is a Tool for Agents - Matt Carey, Cloudflare 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-04-26 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Cloudflare에서 MCP(Model Context Protocol)와 에이전트 개발을 담당하는 Matt Carey가 이 강연에서 던지는 핵심 질문은 단 하나다. “어떻게 하면 모든 API를 에이전트의 도구로 만들 수 있는가?” 수천 개의 API 엔드포인트를 보유한 기업이 이것을 에이전트에게 노출하려 할 때, 전통적인 MCP 도구 방식으로는 컨텍스트 윈도우(Context Window)가 폭발적으로 증가하여 현실적으로 불가능해진다. 강연자는 이 문제를 해결하기 위한 세 가지 접근법을 비교하면서, 특히 에이전트가 직접 코드를 작성하고 격리된 샌드박스에서 실행하는 방식이 미래의 표준이 될 것이라고 주장한다.
도구 호출의 역사 - 번들 도구에서 MCP까지
에이전트가 외부 세계와 상호작용하는 방식은 지난 몇 년 사이 급격히 진화했다. 초기의 도구 호출(Tool Calling, 또는 Function Calling)은 단순한 구조였다. LLM이 함수를 정의하면 개발자가 그것을 실행하고 결과를 다시 LLM에 돌려주는 왕복 구조였다. 문제는 도구들이 에이전트 안에 묶여(Bundled) 있었다는 점이다. Gmail과 상호작용하고 싶은 개발자는 Gmail 전용 도구들을 직접 만들어 에이전트에 내장해야 했고, 다음 개발자도 정확히 똑같은 작업을 처음부터 반복해야 했다. 재사용성이 전혀 없는 구조였다.
이 비효율을 해소하고자 등장한 것이 MCP와 Remote MCP다. 강연자에 따르면 2024년 4월을 전후해 서비스 제공업체들이 MCP 서버를 공개하기 시작했다. 이를 통해 표준화된 도구를 누구나 공유할 수 있게 되었고, CLI나 REST API처럼 MCP 역시 하나의 소비 인터페이스(Surface)로 자리잡았다. 하지만 도구가 8개일 때는 문제가 없었다. 도구가 수십 개, 수백 개로 늘어나면서 새로운 문제가 모습을 드러냈다.
컨텍스트 윈도우의 함정 - 2.3백만 토큰의 현실
Cloudflare는 약 2,600개의 API 엔드포인트를 보유하고 있다. 강연자는 이 모든 엔드포인트를 MCP 도구로 변환하려 했을 때 벌어진 상황을 적나라하게 설명한다. Cloudflare의 OpenAPI 스펙을 그대로 토큰으로 환산하면 약 2.3백만 토큰이다. 이것을 MCP 도구 형태로 변환하면 약 1.1백만 토큰이 된다. 어떤 최신 파운데이션 모델도 이 크기의 컨텍스트를 실용적으로 처리하기 어렵다. 사실상 에이전트의 컨텍스트 윈도우를 완전히 날려버리는 셈이다.
이 문제에 대한 Cloudflare의 첫 번째 임시방편은 API를 제품 단위로 쪼개 16개의 MCP 서버로 분리하는 것이었다. 하지만 이 접근법은 치명적인 단점을 안고 있었다. 사용자가 어떤 서버를 써야 하는지 직접 선택해야 하는 부담이 생겼고, 각 서버의 커버리지가 불완전했다. 하나의 제품군에 30개의 엔드포인트가 있어도 MCP 서버에는 그중 6개만 담겨 있는 식이었다. 강연자는 이것이 원래의 목표, 즉 “모든 API를 에이전트의 도구로”라는 비전과는 거리가 먼 결과라고 솔직하게 인정한다.
프로그레시브 디스커버리 - 세 가지 경로의 비교
이 문제를 해결하는 핵심 개념이 **프로그레시브 디스커버리(Progressive Discovery)**다. 처음부터 모든 도구를 컨텍스트에 올려두는 것이 아니라, 에이전트가 필요한 순간에 필요한 도구를 찾아내는 방식이다. 강연자는 이를 구현하는 세 가지 접근법을 소개하면서 각각의 장단점을 설명한다.
CLI 방식 - 셸 접근의 딜레마
첫 번째 방식은 에이전트가 셸 환경에서 CLI 명령어를 직접 실행하는 것이다. Cloudflare의 Wrangler CLI를 예로 들면, 에이전트가 wrangler 명령을 실행해 사용 가능한 서브커맨드 목록을 파악하고, --help 플래그로 필요한 파라미터를 확인하며 점진적으로 원하는 작업을 수행한다. 강연자는 실제로 wrangler d1 명령을 통해 Cloudflare D1 데이터베이스 목록을 조회하는 과정을 데모로 보여주었다.
06:17 - Wrangler CLI 데모 - 에이전트가 —help 플래그로 파라미터를 확인하며 D1 데이터베이스 목록을 조회하는 화면
이 방식은 개발자 커뮤니티에서 꽤 인기 있으며, 여러 CLI 기반 AI 도구들이 채택하고 있다. 그러나 근본적인 제약이 있다. 반드시 **셸 접근 권한(Shell Access)**이 필요하다는 것이다. 보안이나 접근 제어가 중요한 환경에서는 이것이 큰 걸림돌이 된다.
도구 검색(Tool Search) 방식 - 현실적인 절충안
두 번째 방식은 Claude Code처럼 구조화된 환경을 선호하는 클라이언트가 채택하는 방식이다. 사용자의 질문을 받으면 키워드 매칭 등의 기법으로 관련성 높은 도구 몇 가지(K개)만 컨텍스트에 추가하고, LLM이 그 안에서 적합한 도구를 선택한다. 예를 들어 “워커를 생성해줘”라는 요청이 들어오면 workers.create를 포함한 8개 내외의 관련 도구만 컨텍스트에 올라온다. 강연자의 추정에 따르면 실제 사용되는 토큰은 약 500개이지만, 컨텍스트에는 약 2,100개의 토큰이 올라오는 비효율이 있다. 그럼에도 이 방식은 꽤 잘 작동하며, 필요한 도구만 선택적으로 로드한다는 점에서 컨텍스트 폭발 문제를 실용적으로 완화한다.
코드 생성(Code Generation) 방식 - 근본적 해법
세 번째 방식이 강연의 핵심이다. 정적인 도구 검색이나 CLI 강제 대신, 에이전트가 직접 코드를 작성하고 그 코드를 API에 대해 실행하게 하는 방식이다. Cloudflare가 블로그에 공개한 이 접근법은 이미 사용 가능한 수준으로 구현되어 있다.
타입이 곧 도구다 - TypeScript와 코드 생성
코드 생성 방식의 핵심은 **TypeScript의 타입 시스템(Type System)**을 활용한다는 점에 있다. OpenAPI 스펙에서 TypeScript 타입을 자동 생성하면, 수천 개의 API 엔드포인트가 입력과 출력이 명확하게 정의된 타입으로 표현된다. LLM은 이 타입 정보만 보고도 어떤 함수가 존재하는지, 어떤 파라미터가 필요한지 추론할 수 있다. 그리고 이 타입에 맞는 코드를 직접 작성한다.
강연자는 데모에서 “워커 목록 조회”라는 요청을 LLM에 던지고, LLM이 생성한 TypeScript 코드가 Cloudflare의 타입 기반 SDK에 맞춰 작성되는 과정을 보여주었다. 그 코드는 실제로 실행되어 계정의 워커 목록을 반환했다.
08:05 - 타입 기반 코드 생성 데모 - LLM이 생성한 TypeScript 코드로 워커 목록을 조회하는 실행 결과 화면
더 나아가 새 워커를 배포하고, Cloudflare Access(관리형 IdP, Identity Provider)를 붙여 특정 사용자만 접근할 수 있는 보안 설정까지 에이전트가 자동으로 처리하는 것도 시연되었다.
이 접근법의 강점은 모델 성능 향상의 혜택을 자동으로 받는다는 것이다. 모델이 똑똑해질수록 생성하는 코드의 품질이 높아지고, OpenAPI 스펙이 개선될수록 도구의 정확성도 높아진다. 개발자가 개별 도구를 수동으로 유지보수할 필요가 없으며, OpenAPI 스펙이 진실의 단일 소스(Single Source of Truth)가 된다.
신뢰할 수 없는 코드 실행 - CVE인가, 미래인가
이 접근법의 가장 큰 걸림돌은 명확했다. LLM이 생성한 코드를 검증 없이 실행하는 것은, 몇 년 전이라면 심각한 보안 취약점(CVE, Common Vulnerabilities and Exposures)으로 분류되었을 것이다. 에이전트가 사용자 모르게 파일 시스템을 읽고, 비밀키(Secret)를 탈취하여 네트워크 요청으로 외부 서버에 유출하거나, 무한 루프를 통해 자원을 고갈시키거나, 심지어 암호화폐 채굴 악성코드를 실행할 수도 있다. 강연자는 이것이 진짜 두려움이라는 사실을 인정하면서도, 이 두려움을 정면으로 해소할 기술적 기반이 이미 존재한다고 말한다.
역사적으로 이 문제를 우회하려는 시도는 다양하게 있었다. JSON 스펙으로 코드를 인터폴레이션하는 DSL(Domain-Specific Language)을 만드는 방식, 대형 VM을 스핀업하여 샌드박스 환경에서 실행하는 방식, 혹은 코드 리뷰 프로세스를 사이에 끼워넣는 방식이 그것이다. 하지만 이것들은 모두 신뢰할 수 없는 코드 실행에 대한 두려움을 전제로 한 타협책이었다. 강연자는 이제 그 두려움 자체를 기술적으로 해소할 수 있는 시대가 왔다고 주장한다.
Cloudflare Workers의 격리 샌드박스 - 실용적인 해법
Cloudflare가 제시하는 해법은 Cloudflare Workers의 격리 특성을 활용하는 것이다. Cloudflare Workers는 V8 엔진의 격리 실행 환경(Isolate)을 기반으로 동작한다. 핵심은 **동적 워커(Dynamic Worker)**다. 문자열 형태의 코드를 받아 즉시 격리된 환경에서 실행할 수 있으며, 이 환경은 호스트 시스템의 파일 시스템이나 비밀키에 접근할 수 없다.
강연자는 데모에서 이를 직접 증명했다. LLM이 생성한 코드를 동적 워커로 실행시키고, process.env를 통해 환경 변수를 조회하려 시도했을 때 아무런 비밀키도 노출되지 않았다. Node.js 호환 모드(Node Compatibility Mode)를 끄면 process.env 자체가 존재하지 않아 오류가 발생한다.
11:51 - 격리 샌드박스에서 process.env 조회 시 비밀키가 노출되지 않음을 보여주는 화면
인터넷 접근 역시 기본적으로 차단되어 있으며, 서버에서 Boolean 플래그 하나를 바꾸는 것만으로 접근 허용 여부를 제어할 수 있다. 더 세밀하게는 특정 도메인에만 접근을 허용하는 함수를 주입할 수도 있다. 이처럼 격리 샌드박스이면서도 가드레일(Guardrail)을 프로그래밍으로 세밀하게 제어할 수 있는 환경이 완성된다.
12:43 - 프로그래밍 가능한 가드레일 시연 - 네트워크 접근 차단 및 Boolean 플래그로 제어하는 화면
이와 같은 격리 실행 기술은 Cloudflare만의 것이 아니다. 강연자는 유사한 접근법으로 WorkerD(Cloudflare의 오픈소스 Workers 런타임), Deno(deno run 기반 격리 실행), 그리고 Pydantic AI 생태계의 코드 인터프리터(정확한 제품명은 STT 불명확, Python 실행을 위한 격리 환경)를 언급했다. Python의 경우 런타임을 별도로 다운로드해야 하는 부담이 있지만 원리는 동일하다. 강연자는 이러한 격리 실행 환경이 점점 더 많은 인프라 제공업체에 의해 구현될 것이라고 전망한다. 코드는 개별 도구 호출보다 훨씬 많은 자유도를 가진 계획(Plan)이며, 모델이 스마트해질수록 에이전트는 도구를 호출하는 것이 아니라 코드를 작성하게 될 것이기 때문이다.
15:40 - WorkerD 동적 샌드박스에서 피보나치 코드를 실행하는 화면 - 격리 실행 환경 비교 데모
전체 Cloudflare API를 에이전트에게 - 실시간 데모
강연자는 이러한 모든 구성 요소가 통합된 MCP 클라이언트를 실제로 시연했다. 에이전트에게 질문을 던지면 인증(Auth) 화면이 나타나고, 인증이 완료되면 에이전트는 Cloudflare 계정의 워커 목록 조회, DNS 설정 확인, 이메일 발송, 워커 배포 등 2,600여 개의 전체 API 엔드포인트에 접근할 수 있게 된다.
13:34 - Cloudflare MCP 클라이언트 데모 - 인증 완료 후 전체 API에 접근하여 워커 목록이 출력되는 화면
이것이 강연 제목이 말하는 바다. 모든 API는 에이전트의 도구가 될 수 있다. 단, 전통적인 MCP 도구를 컨텍스트에 전부 쑤셔넣는 방식이 아니라, 에이전트가 필요한 코드를 작성하고 격리된 환경에서 실행하는 방식으로. 그리고 에이전트가 작성한 코드는 Cloudflare가 “약 1,000개의 토큰으로 전체 API에 접근하는 방법”이라는 블로그 포스트에서 상세히 설명한 바와 같이, 타입 기반 SDK를 통해 전체 API 서피스를 훨씬 적은 컨텍스트로 다룰 수 있게 만든다.
미래 전망 - 클라이언트 측의 혁신
서버 측 문제를 해결했다면, 이제 클라이언트(에이전트) 측에서는 어떤 변화가 일어날 것인가? 강연자는 MCP 클라이언트를 제대로 만드는 것이 지금까지는 매우 어려웠다고 인정한다. 상태 유지(Stateful) 연결 관리, 연결 간 재개(Resumability) 처리 등 복잡한 인프라 요구사항이 개발자들을 단순한 MCP 클라이언트 구현 수준에 머무르게 만들었고, 그 결과 UI/UX 면에서 독창적인 시도가 거의 없었다. 하지만 강연자는 이 상황이 곧 바뀔 것이라고 예측하며 세 가지 변화를 제시한다.
첫 번째는 프로그래매틱 도구 호출(Programmatic Tool Calling)의 보편화다. 정적인 도구 호출 대신 에이전트가 코드를 생성하고 실행하는 방식이 클라이언트에서도 표준이 될 것이다. 로컬 클라이언트라면 격리 없이 단순히 코드를 평가(eval)하는 방식도 가능하고, 원격 클라이언트라면 WorkerD나 Deno 같은 격리 환경을 활용하게 된다.
두 번째는 미니 스크립트(Mini Script) 저장 기능의 등장이다. 에이전트가 생성한 유용한 코드를 사용자가 저장해두면, 이후 훨씬 빠르게 재실행할 수 있다. 강연자가 든 예시는 웹 스크래핑 크론 잡이다. 사용자가 웹 스크래핑 방법을 몰라도 에이전트가 스크립트를 생성하고, 그것이 매일 또는 이틀에 한 번 실행되며, 스크립트가 깨지면 에이전트가 자동으로 수정하고 재저장한다. 이런 미니 스크립트들은 프로그래매틱 도구 호출을 수용하는 클라이언트에서만 의미 있게 동작한다.
세 번째는 MCP 클라이언트 수의 폭발적 증가다. 만들기가 어려웠던 시절에는 실질적으로 잘 작동하는 MCP 클라이언트의 수가 많지 않았다. 이것이 쉬워지면서 클라우드에서 실행되는 원격 에이전트들이 MCP 클라이언트로서 동작하는 사례가 급증할 것이다. 동시에 에이전트 수가 사람 1명당 수백 개에 달하게 되면, 각 에이전트마다 격리 샌드박스를 상시 유지하는 것은 비현실적이 된다. 따라서 상태(State)를 필요에 따라 켜고 끌 수 있는 클라우드 네이티브(Cloud-Native) 방식, 즉 **무상태 에이전트 루프(Stateless Agent Loop)**가 필연적으로 등장할 것이라고 강연자는 말한다.
MCP의 미래 - 플래그 하나로 켜는 미들웨어
강연의 마지막 예측은 MCP의 위상 변화에 관한 것이다. 강연자는 MCP가 별도로 설계하고 구성해야 하는 전용 서버가 아니라, 기존 API 프레임워크에 플래그 하나로 켤 수 있는 **미들웨어(Middleware)**로 진화할 것이라고 전망한다. TypeScript 생태계의 모든 주요 풀스택 프레임워크(Next.js 등)에 MCP가 네이티브로 통합되어, 개발자는 mcp: true 설정 한 줄만 추가하면 자신의 1,000개 API 엔드포인트 전체를 MCP 도구로 노출할 수 있게 된다는 것이다.
이것이 가능해지려면 MCP SDK 자체가 어떤 번들 환경에도 포함될 수 있을 만큼 경량화되어야 한다. 강연자는 마지막 남은 걸림돌이 바로 이 SDK 경량화 작업이며, 2025년 내에 완성될 것이라는 전망과 함께 강연을 마무리한다. 그리고 이 목표가 달성되면, 모든 클라이언트가 프로그래매틱 도구 호출을 수행하는 시대에 서비스 제공업체는 Next.js 앱 하나에서 mcp: true 설정만으로 수천 개의 API를 에이전트에게 완전히 개방할 수 있게 된다.
마무리 / 핵심 정리
Matt Carey의 강연은 AI 에이전트와 API 통합의 현재 한계를 솔직하게 직시하면서, 동시에 그 한계를 극복할 기술적 경로를 구체적으로 제시한다는 점에서 가치 있다. 강연자의 핵심 논지를 한 문장으로 정리하면 이렇다. “도구(Tool)를 컨텍스트에 쌓지 말고, 에이전트가 코드를 쓰게 하라. 그리고 그 코드를 안전하게 실행할 격리 환경을 만들어라.”
MCP가 나쁜 아이디어였던 것이 아니라, 우리가 MCP를 활용하는 방식이 잘못되었을 뿐이다. 컨텍스트에 수천 개의 도구를 던져넣는 것은 구조적으로 불가능하며, 이 문제를 인식하고 프로그레시브 디스커버리와 코드 생성 방식을 결합한 접근법이 우아한 해답이 된다. 또한 강연자는 서비스 제공업체들에게 명확한 메시지를 전달한다. API를 잘 설계하고, 적절한 Rate Limiting을 구축하고, OpenAPI 스펙을 진실의 단일 소스로 유지하라. 에이전트는 이미 당신의 API를 두드리고 있으며, 앞으로는 for 루프로 수십 개의 샌드박스에서 동시에 API를 호출하는 시대가 온다. 그 충격을 견딜 준비가 되어 있어야 한다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Every API Is a Tool for Agents - Matt Carey, Cloudflare |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-04-26 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.
Related Reports
- Code Mode - Sunil Pai, Cloudflare
- A Piece of Pi - Embedding The OpenClaw Coding Agent In Your Product - Matthias Luebken, Tavon
- Why Eval++ Is the Next Great Compute Primitive — Sunil Pai & Matt Carey, Cloudflare
- Why, and how you need to sandbox AI-Generated Code — Harshil Agrawal, Cloudflare
- Give Your Agent a Computer — Nico Albanese, Vercel