이 영상은 클라우드플레어(Cloudflare)의 맷 캐리(Matt Carey)가 AI 에이전트가 API를 활용하는 방식의 진화와 미래에 대해 설명합니다. 기존의 도구 번들링 방식의 한계점을 지적하며, 컨텍스트 문제 해결을 위한 CLI, 도구 검색, 그리고 코드 생성(codemode) 방식의 장점을 소개합니다. 특히 안전한 코드 실행 환경의 중요성과 이를 위한 동적 워커(dynamic worker) 활용 방안, 그리고 미래의 API 및 클라이언트 개발 방향에 대한 통찰을 제공합니다.
1. 에이전트와 API의 만남 🤝
맷 캐리는 클라우드플레어에서 MCP(Mega Context Problem)와 에이전트 관련 업무를 담당하고 있으며, AI 에이전트가 외부 세계와 상호작용하는 방법에 깊은 관심을 가지고 있습니다. 에이전트에게 '손'을 부여하는 것은 도구 호출(tool calling) 또는 함수 호출(function calling)이라는 개념으로 시작되었는데, LLM(Large Language Model)이 함수를 작성하고, 시스템이 이를 실행하는 방식입니다. 초기에는 각 에이전트가 필요한 도구들을 직접 번들링하여 사용했지만, 이는 비효율적이었고, 특히 동일한 API에 대해 여러 에이전트가 각각 도구를 만들어야 하는 번거로움이 있었습니다.
"에이전트에게 어떻게 손을 쥐어줄 수 있을까요? 외부 세계와 어떻게 상호작용하게 할까요? 여러분은 아마 이런 것에 익숙할 겁니다. 이것이 도구 호출, 함수 호출이죠."
작년 4월경, MCP와 원격 MCP(remote MCP) 개념이 등장하면서 서비스 제공자들이 표준화된 도구를 제공하고, 이를 통해 모든 에이전트가 동일한 API를 활용할 수 있게 되었습니다. 하지만 이 방식에도 큰 문제가 있었으니, 바로 컨텍스트 창(context window)의 폭발이었습니다.
2. 컨텍스트 창 폭발 문제 💥
클라우드플레어는 에이전트가 전체 API에 접근할 수 있도록 하고 싶었지만, 모든 API 엔드포인트를 단순하게 도구로 만들 경우, 에이전트의 컨텍스트 창이 감당할 수 없을 정도로 커진다는 문제에 직면했습니다. 클라우드플레어의 Open API 스펙은 무려 230만 토큰에 달하며, 이를 도구로 변환하면 110만 토큰이 필요했습니다. 이는 현존하는 가장 큰 파운데이션 모델로도 처리하기 어려운 수준이었습니다.
"여러분은 '우리 API의 전체 표면에 에이전트가 접근할 수 있도록 하고 싶어'라고 생각할 겁니다. 하지만 그렇게 되지 않을 겁니다. 왜 안될까요? 에이전트의 컨텍스트 창이 폭발할 겁니다."
이 문제를 해결하기 위해 클라우드플레어는 API를 여러 제품 기반 MCP 서비스로 분할했습니다. 이 방식은 컨텍스트 부담을 줄여주었지만, 사용자가 직접 필요한 서비스를 선택해야 했고, 종종 API 전체 기능을 커버하지 못하는 불완전한 상태가 발생했습니다.
"이것은 '모든 API를 에이전트의 도구로 만드는 방법'이라는 목표를 달성하지 못합니다. 오히려 좀 짜증나는 일이죠."
결론적으로, 필요한 것은 도구의 점진적 발견(progressive discovery of tools)이었습니다.
3. 컨텍스트 문제 해결을 위한 세 가지 방법 💡
맷 캐리는 컨텍스트 문제를 해결할 수 있는 세 가지 방법을 제시합니다.
3.1. CLI (Command Line Interface) 활용 💻
CLI는 에이전트가 샌드박스 환경에서 명령어를 실행하고, --help 옵션을 통해 필요한 파라미터 정보를 얻어 스스로 기능을 탐색하고 실행할 수 있도록 합니다. 이는 Open Claw와 같은 곳에서 인기를 얻고 있는 방식이지만, 쉘 접근(shell access)이 필수적이라는 제약이 있습니다.
3.2. 도구 검색 (Tool Search) 🔍
클라우드 코드(Cloud Code)와 같은 서비스는 도구 검색(tool search) 방식을 사용합니다. 사용자의 질문을 키워드로 분석하여, 필요한 도구만 컨텍스트에 로드하는 방식입니다. 예를 들어, "워커를 생성하고 싶어요"라는 질문에 관련 도구 몇 개만 컨텍스트에 추가하는 식입니다. 이는 컨텍스트를 줄이는 데 효과적이지만, 여전히 불필요한 도구들이 컨텍스트에 남아 있을 수 있습니다.
"관련 있는 도구만 로드합니다."
3.3. 코드 생성 (Codemode) ✍️ (강조)
클라우드플레어가 작년에 공개한 블로그 게시물에서 소개된 방식입니다. 에이전트에게 CLI나 정적 검색 도구를 강제하는 대신, 에이전트가 직접 코드를 작성하게 하는 것입니다. 타입스크립트(TypeScript)의 강력한 타입 시스템을 활용하여, API의 입력과 출력을 간결하게 표현하고, 모델이 이 타입을 기반으로 코드를 생성하게 합니다.
"모델이 코드를 작성하도록 하는 것입니다. 모델이 더 나아지는 것에서 이득을 얻고, Open API 스펙이 개선되는 것에서 이득을 얻습니다. 그것이 진실의 근원(source of truth)이 되어야 합니다."
예시로, 워커 목록을 조회하거나, 워커를 배포하고, Cloudflare Access를 통해 보안을 설정하는 등의 작업을 에이전트가 코드를 생성하여 수행하는 것을 보여줍니다. 이 방식은 모델이 점점 더 스마트해질수록 더욱 효과적일 것이라고 설명합니다.
4. 코드 생성 방식의 도전 과제: 안전한 코드 실행 🔒
코드 생성 방식은 매우 강력하지만, 신뢰할 수 없는 코드(untrusted code)를 실행하는 것에 대한 근본적인 보안 문제가 존재합니다. 몇 년 전 같으면 상상도 할 수 없는 일이었고, 이는 곧바로 보안 취약점(CV, vulnerability)으로 간주되었을 것입니다. 잘못된 코드가 파일 시스템에 접근하거나, 비밀 정보를 유출하거나, 무한 루프에 빠져 리소스를 낭비하거나, 심지어 암호화폐 채굴을 시도할 수도 있습니다.
과거에는 이러한 문제를 해결하기 위해 DSL(Domain Specific Language)이나 샌드박스(sandbox) 환경(VM 등)을 사용하거나, 코드 리뷰를 거치는 방식 등이 시도되었습니다. 하지만 맷 캐리는 클라우드플레어가 가진 강력한 해결책, 즉 클라우드플레어 워커(Cloudflare Workers)를 소개합니다.
"하지만 다행히도, 우리는 이 문제를 해결할 수 있는 꽤 멋진 원시 기술을 가지고 있습니다. 그리고 아마 다른 원시 기술들도 있겠지만, 이것이 첫 번째이고 그래서 언급할 가치가 있다고 생각합니다."
클라우드플레어 워커는 V8 엔진의 분리 환경(isolate)을 활용하여 코드를 실행하며, 이는 매우 안전한 샌드박스 환경을 제공합니다. 맷 캐리는 데모를 통해 다음을 보여줍니다.
- 비밀 정보 접근 차단:
process.env를 통해 비밀 정보에 접근하려는 시도가 실패함을 보여줍니다. - 프로그래밍 가능한 샌드박스: Node.js 호환성 모드를 끄면
process.env자체가 존재하지 않아 에러가 발생하는 것을 보여주며, 환경을 프로그래밍 방식으로 제어할 수 있음을 강조합니다. - 외부 네트워크 접근 제어: 에이전트가 외부 API에 접근하는 코드를 실행했을 때, 기본적으로 인터넷 접근이 차단되지만, 관리자가 필요에 따라 특정 도메인에만 접근을 허용하는 등 프로그래밍 가능한 가드레일(programmable guardrails)을 설정할 수 있음을 시연합니다.
이를 통해 클라우드플레어 MCP는 클라우드플레어 API의 2,000개 이상의 모든 엔드포인트에 대해 읽기 전용 접근을 허용하면서도, 안전하게 에이전트가 코드를 실행할 수 있는 환경을 제공합니다.
5. 에이전트와 API의 미래 🔮
맷 캐리는 앞으로 에이전트가 외부 도구에 접근하는 방식과 API 생태계의 변화에 대한 통찰을 공유합니다.
5.1. 더 많은 고립된 환경 (More Isolated Environments) 🌐
웹에는 더욱 많은 고립된 환경(isolated environments)이 생겨나, 신뢰할 수 없는 코드를 안전하게 실행할 수 있는 인프라 프리미티브(infrastructure primitives)가 확산될 것입니다. 코드(code)는 매우 압축적인 계획(compact plan)이며, 모델이 코드를 생성하고 실행하는 방식은 개별 도구 호출보다 훨씬 많은 자유도를 제공하기 때문입니다.
"저는 웹에 아주 많은 고립된 환경이 생겨날 것이라고 생각합니다. 그리고 웹에서 이런 종류의 신뢰할 수 없는 코드를 실행할 수 있는 많은 인프라 프리미티브가 있을 겁니다. 왜냐하면 코드는 실제로 매우 압축적인 계획이기 때문입니다."
Pydantic Monty, Deno, Cloudflare의 WorkerD와 같은 기술들이 이러한 트렌드를 주도하고 있습니다. 과거에는 신뢰할 수 없는 코드 실행이 보안 문제였지만, LLM이 코드를 작성하는 능력이 발전하면서, 이제는 이를 가능하게 하는 프리미티브를 구축하는 시대로 접어들었습니다.
5.2. API 서비스의 변화 🛡️
서비스 제공자는 에이전트가 코드를 통해 API를 호출하는 것에 대비해야 합니다. 이는 API에 대한 요청 증가를 의미하며, 뛰어난 속도 제한(rate limiting)과 같은 보호 메커니즘이 필수적이 될 것입니다.
"사용자들이 코드를 작성할 수 있게 될 겁니다. 왜냐하면 사용자들은 AI이고, AI는 코드를 작성하는 데 매우 능숙하기 때문입니다. 그리고 그것이 그들이 여러분의 플랫폼과 상호작용하는 방식이 될 겁니다... 여러분의 API는 좋은 속도 제한을 가져야 합니다. 왜냐하면 저는 이것을 여러 샌드박스에서 동시에 반복문으로 실행하고 여러분의 API를 마구 공격할 수 있기 때문입니다. 그것에 대비할 수 있는 방법이 있어야 합니다."
5.3. 클라이언트 측의 혁신 🚀
클라이언트 측면에서는 더욱 흥미로운 변화가 예상됩니다.
- 프로그래밍 방식 도구 호출(Programmatic Tool Calling): 워커D, Deno, Pydantic을 이용한 샌드박스 예시에서 보았듯이, 클라이언트에서도 신뢰할 수 없는 코드를 실행하는 방식이 보편화될 것입니다.
- 스크립트 저장 및 재사용(Saved Mini-Scripts): 에이전트가 생성한 코드를 사용자가 미니 스크립트로 저장하고 재사용할 수 있게 됩니다. 이는 크론잡(cron jobs)이나 웹 스크래핑(web scraping)과 같은 반복적인 작업에 유용하며, 에이전트가 스크립트 오류를 스스로 수정하고 다시 저장하는 단계까지 발전할 수 있습니다.
- 더 많은 클라이언트와 스테이트리스(Stateless) 접근: MCP 클라이언트를 구축하는 것이 이전보다 훨씬 쉬워질 것이므로, 더 많은 클라이언트가 등장할 것입니다. 또한, 개인당 수많은 에이전트가 존재하게 될 미래를 대비하여, 클라우드 네이티브 방식으로 스테이트리스(stateless) 에이전트 루프를 구현하는 것이 중요해질 것입니다.
5.4. MCP SDK의 미래 ⚙️
맷 캐리는 자신이 담당하는 MCP 서버와 SDK(Software Development Kit)에 대한 비전을 제시합니다. MCP는 API를 구축할 때 미들웨어(middleware)처럼 작용하게 될 것이며, 즐겨 사용하는 프레임워크에서 간단한 플래그 설정(MCP=true)만으로 API를 에이전트 도구로 노출할 수 있게 될 것이라고 말합니다.
"MCP는 미들웨어처럼 될 것이라고 생각합니다. MCP 서버를 만들 때... API 서비스도 마찬가지죠. 여러분이 좋아하는 프레임워크에서 켜고 끌 수 있는 플래그가 될 겁니다."
SDK는 더욱 경량화되어, 올해 말까지는 타입스크립트 기반의 모든 풀스택 프레임워크에 기본적으로 통합될 정도로 작아질 것입니다. 이는 API 서비스 제공자가 수많은 API를 Next.js 앱 하나로 관리하면서 MCP=true 설정을 통해 에이전트 도구로 쉽게 노출할 수 있게 함을 의미합니다.
마무리 ✨
맷 캐리는 클라우드플레어가 최근 발표한 'Code Mode' 블로그 게시물을 소개하며, 어떻게 천 개의 토큰으로 전체 API를 에이전트에게 제공할 수 있었는지 강조합니다. 그는 큰 API를 가진 모든 개발사나 접근성 제공자들이 이 방식을 채택하여 사용자들이 데이터에 쉽게 접근할 수 있도록 해야 한다고 역설하며 발표를 마쳤습니다.
"크고 거대한 API를 가지고 있다면, 이것을 해야 합니다. 모든 접근성 제공자들도 이것을 해야 합니다. 왜냐하면 사람들이 여러분의 데이터에 접근하는 데 정말 정말 좋기 때문입니다."