AI 에이전트는 계획할 수 있습니다. 추론할 수 있습니다. 코드를 작성할 수 있습니다. 하지만 이미지를 생성하거나, 인용과 함께 웹을 검색하거나, 비디오를 제작하거나, 클라우드에 자산을 저장하거나, 페이지를 퍼블리시하라고 요청하면 — 벽에 부딪힙니다. 모델이 충분히 똑똑하지 않아서가 아닙니다. 에이전트 아키텍처에 한 계층이 빠져 있기 때문입니다.
그 빠진 계층이 바로 캐퍼빌리티 런타임(Capability Runtime) 입니다.
오늘날 AI 에이전트 아키텍처가 무너지는 지점
현대 AI 에이전트 스택은 일반적으로 세 계층으로 구성됩니다:
- 모델 계층 — Claude, GPT, Gemini. 추론 엔진.
- 에이전트 프레임워크 — 계획하고, 도구를 호출하고, 관찰하고, 반복하는 루프.
- 도구 — MCP 서버, API, SDK. 에이전트가 실제로 무언가를 할 수 있게 해주는 것들.
처음 두 계층은 빠르게 성숙했습니다. Claude Code와 Cursor는 정교한 에이전트 루프를 갖추고 있습니다. 모델은 200K+ 토큰 컨텍스트 윈도우를 처리합니다.
세 번째 계층 — 도구 — 여기서 문제가 발생합니다.
에이전트가 필요로 하는 모든 도구는 서로 다른 API 뒤에 존재합니다. 각 API는 고유한 인증, 고유한 레이트 리밋, 고유한 SDK, 고유한 출력 형식을 가지고 있습니다. 단일 에이전트에 다섯 가지 기능(이미지 생성, 비디오, 웹 검색, 스토리지, 퍼블리싱)을 제공하려면, 다섯 개의 별도 서비스를 구성하고, 여섯 개의 API 키를 관리하며, 도구 설명만으로 24,000토큰 이상을 소모하게 됩니다.
그것은 도구 계층이 아닙니다. 도구 부담입니다.
캐퍼빌리티 런타임이 하는 일
캐퍼빌리티 런타임은 에이전트와 에이전트가 필요로 하는 수십 개의 서비스 사이에 위치하는 단일 CLI 도구(또는 API)입니다. 에이전트가 각 서비스와 직접 통신하는 대신:
에이전트 → 이미지 API → 에이전트 → 비디오 API → 에이전트 → 검색 API → 에이전트 → 스토리지 API
에이전트는 하나의 엔드포인트와 통신합니다:
에이전트 → 캐퍼빌리티 런타임 → (이미지, 비디오, 검색, 스토리지, 퍼블리싱)
런타임이 모델 선택, 인증, 형식 변환, 레이트 리밋, 구조화된 출력을 처리하므로 에이전트는 신경 쓸 필요가 없습니다.
이것이 중요한 이유: 토큰 계산
이는 추상화를 위한 추상화가 아닙니다. 에이전트 성능에 측정 가능한 영향을 미칩니다.
에이전트가 연결하는 각 MCP 서버나 API 클라이언트는 에이전트의 컨텍스트에 도구를 등록합니다. 모든 도구에는 이름, 설명, 파라미터 스키마가 포함됩니다. 단일 MCP 서버는 일반적으로 도구 설명에 3,000~8,000토큰을 추가합니다.
다섯 개의 개별 도구(이미지 생성 + 비디오 생성 + 웹 검색 + 클라우드 스토리지 + 퍼블리싱)를 사용하면, 에이전트가 코드 한 줄 작성하기도 전에 15,000~40,000토큰이 소모됩니다.
캐퍼빌리티 런타임은 이러한 도구들을 하나의 엔드포인트로 통합합니다. 다섯 세트의 도구 설명이 하나로 줄어듭니다. 토큰 오버헤드가 24,000+에서 약 2,000으로 감소합니다.
200K 컨텍스트 윈도우의 Claude Sonnet 4 세션에서 이는 컨텍스트의 11%를 확보하는 셈입니다 — 실제 추론, 코드 생성, 대화 이력을 위해 말이죠.
캐퍼빌리티 런타임이 해결하는 세 가지 문제
1. 자격 증명 확산
모든 개별 API는 고유 키가 필요합니다. 다섯 가지 기능은 생성, 저장, 교체, 폐기해야 할 다섯 개의 키를 의미합니다. 캐퍼빌리티 런타임은 모든 것을 커버하는 하나의 자격 증명을 제공합니다.
2. 출력 불일치
한 API는 JSON을 반환합니다. 다른 API는 평문을 반환합니다. 또 다른 API는 바이너리를 스트리밍합니다. 에이전트가 모든 형식을 처리해야 합니다. 캐퍼빌리티 런타임은 기본 서비스와 관계없이 구조화되고 일관된 JSON을 반환합니다.
3. 유지보수 드리프트
API는 변경됩니다. 레이트 리밋은 변동됩니다. 모델은 지원 중단됩니다. 각 기능이 개별적으로 연결되어 있으면 다섯 개의 구성을 유지보수해야 합니다. 런타임은 업데이트를 내부적으로 처리합니다 — 에이전트는 동일한 엔드포인트를 계속 호출하기만 하면 됩니다.
캐퍼빌리티 런타임 vs MCP 서버: 다른 계층
여기서 용어가 혼동되곤 합니다. MCP(Model Context Protocol) 서버는 전송 계층입니다 — 에이전트가 도구에 연결하는 방식을 정의합니다. 캐퍼빌리티 런타임은 번들링 계층입니다 — 어떤 도구를 사용할 수 있고 어떻게 제시할지를 결정합니다.
이 둘은 상호 보완적입니다. 전문화된 통합(회사 내부 데이터베이스, Slack 봇, Jira 커넥터)에는 MCP 서버를 사용하고, 모든 에이전트가 필요로 하는 공통 기능(검색, 이미지, 비디오, 스토리지, 퍼블리싱)에는 캐퍼빌리티 런타임을 사용할 수 있습니다.
하이브리드 접근 방식은 다음과 같습니다:
- 전문화된 도구 → 개별 MCP 서버 (데이터베이스, Slack, CRM)
- 공통 기능 → 캐퍼빌리티 런타임 (이미지, 비디오, 검색, 스토리지, 퍼블리싱)
실제 사례: 랜딩 페이지 구축하기
캐퍼빌리티 런타임 없이 에이전트에게 "새 기능을 위한 랜딩 페이지를 만들어줘"라고 요청하면 다음과 같은 일이 벌어집니다:
- 에이전트가 HTML/CSS 작성 ✅
- 에이전트가 히어로 이미지 필요 — 중단. Replicate API를 구성하고, 수동으로 이미지를 생성한 뒤, URL을 에이전트에 전달.
- 에이전트가 경쟁사 리서치 필요 — 중단. Brave Search를 구성하고, 쿼리를 실행하고, 결과를 붙여넣음.
- 에이전트가 페이지 구축 — 완료. 이제 수동으로 Netlify에 배포.
- 에이전트가 도구만 있었으면 2~4단계를 스스로 처리할 수 있었을 텐데.
캐퍼빌리티 런타임을 사용하면:
- 에이전트가 HTML/CSS 작성 ✅
- 에이전트가
image generate "SaaS 대시보드용 히어로"호출 — CDN URL 수신 ✅ - 에이전트가
search "경쟁사 가격 Q2 2026"호출 — 인용 포함된 구조화된 결과 수신 ✅ - 에이전트가
drive upload ./build/호출 — 공개 URL로 자산 저장 ✅ - 에이전트가
page deploy ./build/호출 — 페이지 라이브 ✅
한 세션. 하나의 에이전트. 인간 병목 없음.
캐퍼빌리티 런타임에서 찾아야 할 것
캐퍼빌리티 런타임을 평가할 때 중요한 기준입니다:
- 범위: 에이전트가 실제로 필요로 하는 기능을 커버하는가? 이미지, 비디오, 검색, 스토리지, 퍼블리싱이 기본입니다.
- 에이전트 호환성: 사용 중인 에이전트와 작동하는가? Claude Code, Cursor, Codex, Windsurf, Gemini CLI.
- 출력 형식: 구조화된 JSON. 에이전트가 HTML을 파싱하거나 바이너리 스트림을 처리할 필요가 없어야 합니다.
- 자격 증명 모델: 하나의 계정, 하나의 인증 흐름, 관리할 하나의 키.
- 토큰 효율성: 컨텍스트에 몇 개의 토큰을 추가하는가? 낮을수록 좋습니다.
빠진 계층에 이제 이름이 생겼다
AI 에이전트 스택에는 이 계층을 부를 이름이 없었습니다. 사람들은 "도구 통합"이나 "MCP 구성" 혹은 "API 연결"이라고 불렀습니다. 그 어떤 것도 실제 모습을 담아내지 못합니다: 에이전트가 네이티브로 가지지 못한 능력을 부여하는 런타임.
캐퍼빌리티 런타임은 MCP의 대체재가 아닙니다. 모델 API의 대체재도 아닙니다. 에이전트의 추론과 에이전트가 상호작용해야 하는 세계 사이에 위치한 계층입니다 — "할 수 없습니다"를 "완료했습니다"로 바꾸는 계층.
마지막 업데이트: 2026년 5월