Capability Runtime이란 무엇인가? AI 에이전트 아키텍처에서 빠져 있던 레이어

시각적 설명: capability runtime은 검색, 생성, 저장, 퍼블리싱의 실행 표면을 하나로 묶어 에이전트가 워크플로를 끝까지 완료할 수 있게 해줍니다.

AI 에이전트는 계획할 수 있습니다. 추론할 수 있습니다. 코드를 작성할 수도 있습니다. 하지만 이미지 생성, 출처가 포함된 웹 검색, 동영상 제작, 클라우드 파일 저장 같은 작업을 맡기면 거기서 멈춰 버립니다.

충분히 똑똑하지 않아서가 아닙니다. 인프라의 한 조각이 빠져 있기 때문입니다.

그 빠진 조각이 바로 capability runtime입니다. 여기서 capability runtime이 무엇인지, 왜 중요한지, 그리고 이것이 에이전트가 실제로 할 수 있는 일을 어떻게 바꾸는지 설명합니다.

문제: 똑똑한 에이전트인데 손이 없다

현대적인 AI 에이전트 스택은 보통 이렇게 생겼습니다.

1. 모델 — Claude, GPT, Gemini. 추론 엔진입니다.
2. 프레임워크 — 계획하고, 도구를 호출하고, 적응하는 루프입니다.
3. 여러 개의 분리된 도구 — 이미지 생성기. 웹 검색. 동영상. 클라우드 스토리지. 퍼블리싱.

앞의 두 레이어는 이미 성숙했습니다. Claude Code는 정교한 에이전트 루프를 갖추고 있습니다. 모델은 20만 토큰이 넘는 컨텍스트를 처리합니다. GPT-5.5는 네이티브 에이전트 모드와 함께 제공됩니다. Anthropic의 Opus 4.7은 여러 시간에 걸친 코딩 세션을 추론으로 버텨 냅니다.

문제가 터지는 곳은 세 번째 레이어입니다.

각 도구는 서로 다른 API 뒤에 있습니다. 인증도 다르고, 속도 제한도 다르고, 출력 형식도 다릅니다. 하나의 에이전트에 다섯 가지 capability를 주려면 다섯 개의 별도 서비스를 설정하고, 여섯 개의 API 키를 관리하고, 에이전트가 코드 한 줄 쓰기 전부터 도구 설명만으로 15,000~40,000토큰을 태워야 합니다.

이건 도구 레이어가 아닙니다. 도구 부담입니다.

왜 2026년에 이것이 중요해졌는가

Capability runtime이 필요해진 데에는 세 가지 흐름이 겹쳤습니다.

1. 에이전트가 틈새에서 주류로 넘어왔다. 2024년에 “AI 에이전트”는 연구 논문을 뜻했습니다. 2025년에는 실험적인 CLI 도구를 뜻했습니다. 2026년에는 Claude Code, Cursor Agent Mode, Codex CLI, Windsurf가 수백만 개발자의 일상 도구가 되었습니다. 그리고 이 개발자들은 모두 같은 벽에 부딪힙니다. 에이전트는 생각할 수 있지만 실행할 수는 없다는 점입니다.

2. 모델과 프레임워크가 도구보다 더 빨리 성숙했다. Claude Opus 4.7은 20만 토큰을 거의 완벽한 기억력으로 처리합니다. GPT-5.5의 에이전트 루프는 다단계 작업을 자율적으로 계획합니다. 추론 레이어는 사실상 해결됐습니다. 하지만 실제로 이미지를 생성하고, 실시간 웹을 검색하고, 파일을 저장하는 실행 레이어는 여전히 분리된 API들의 뒤엉킨 조합입니다.

3. 토큰 비용이 충분히 낮아져 도구 중심 에이전트가 실용화됐다. 예전에는 다섯 개 도구를 호출하는 에이전트를 실행하면 도구 설명만으로도 30,000토큰 이상을 소모했습니다. 2026년 가격 기준으로는 GPT-5.5가 입력 100만 토큰당 1.50달러, Claude Opus 4.7이 2.00달러입니다. 이 정도 오버헤드는 몇 센트 수준입니다. 병목은 비용에서 설정 복잡도로 옮겨갔습니다.

그 결과, 세계에서 가장 똑똑한 모델들이 지능이 아니라 인프라 때문에 막히고 있습니다.

Capability Runtime이 하는 일

Capability runtime은 에이전트와 필요한 도구 사이에 놓입니다.

기존에는 이렇게 됩니다.

Agent → 이미지 API → Agent → 동영상 API → Agent → 검색 API → Agent → 스토리지 API

Capability runtime을 쓰면 이렇게 됩니다.

Agent → Capability Runtime → (이미지, 동영상, 검색, 저장, 퍼블리싱)

에이전트는 하나의 엔드포인트와만 대화합니다. 나머지는 runtime이 처리합니다. 모델 선택, 인증, 형식 변환, 속도 제한, 구조화된 출력까지 모두 맡습니다.

아키텍처: 내부에서는 어떻게 동작하는가

Capability runtime에는 네 개의 레이어가 있습니다.

┌─────────────────────────────────────────┐
│               YOUR AGENT                │
│    (Claude Code / Cursor / Codex)       │
├─────────────────────────────────────────┤
│           SKILL / TOOL LAYER            │
│   ~2,000 tokens — one tool description  │
├─────────────────────────────────────────┤
│         CAPABILITY RUNTIME CORE         │
│   • Auth management (one key)           │
│   • Model routing (pick best provider)  │
│   • Format normalization (always JSON)  │
│   • Rate limiting & retry logic         │
├─────────────────────────────────────────┤
│           PROVIDER ADAPTERS             │
│  Image  │ Video │ Search│Storage│Publish│
│  (6+)   │ (4+)  │ (3+)  │ (2+)  │ (2+)  │
└─────────────────────────────────────────┘

Skill / Tool Layer: 에이전트는 runtime의 capability를 설명하는 하나의 도구 또는 skill을 등록합니다. 비용은 약 2,000토큰입니다. 각기 3,000~8,000토큰이 드는 다섯 개의 MCP 서버를 따로 등록하는 것과 비교해 보세요.

Runtime Core: 인증처럼 여러 기능에 걸친 공통 문제를 처리합니다. 하나의 API 키로 모든 capability를 열어 주고, 모델 라우팅도 맡습니다. 예를 들어 에이전트가 “동영상을 생성해”라고 하면 runtime이 프롬프트에 따라 Veo 3.1, Seedance 2.0, Sora 2 Pro 중 최적의 제공자를 선택합니다. 그리고 어떤 제공자를 쓰든 결과는 항상 구조화된 JSON으로 정규화합니다.

Provider Adapters: 각 기반 API를 감싸는 얇은 래퍼입니다. Stability AI가 엔드포인트를 바꾸더라도 업데이트가 필요한 것은 어댑터뿐이고, 에이전트는 그 변화를 알아차리지 못합니다.

이것이 해결하는 세 가지 문제

1. 너무 많은 자격 증명

다섯 가지 capability는 다섯 개의 API 키를 만들고, 저장하고, 교체하고, 폐기해야 한다는 뜻입니다. Capability runtime은 모든 것을 아우르는 하나의 자격 증명을 제공합니다.

실제 숫자: 다섯 명의 개발자가 각자 세 가지 capability(이미지, 검색, 저장)를 연결한 팀이라면, 다섯 대의 개발자 머신에서 15개의 API 키를 관리하게 됩니다. 한 명이 퇴사하면 다섯 개 서비스에 걸쳐 세 개 키를 교체해야 합니다. Runtime을 쓰면 개발자당 키 하나, 퇴사 시 폐기, 끝입니다.

2. 일관되지 않은 출력

어떤 API는 JSON을 반환하고, 어떤 API는 일반 텍스트를 반환하고, 또 어떤 API는 바이너리를 스트리밍합니다. 에이전트가 모든 형식을 처리해야 합니다. Runtime은 기반 서비스가 무엇이든 일관된 구조화 JSON을 반환합니다.

이건 생각보다 훨씬 중요합니다. 에이전트가 image generate를 호출해 {url, width, height, alt_text} 같은 객체를 받으면, 그 URL을 바로 <img> 태그에 넣을 수 있습니다. 반대로 바이너리 데이터가 들어 있는 multipart 응답을 파싱하고, 헤더에서 메타데이터를 뽑아내고, Base64 인코딩을 처리해야 한다면 바로 그 지점에서 에이전트 루프가 깨집니다.

3. 유지보수 드리프트

API는 바뀝니다. 속도 제한도 바뀝니다. 모델도 지원 종료됩니다. 각 capability를 따로 연결해 두면 다섯 개 설정을 계속 관리해야 합니다. Runtime은 업데이트를 내부에서 처리하므로, 에이전트는 같은 엔드포인트만 계속 호출하면 됩니다.

예시: 2026년 3월, Stability AI는 v1 엔드포인트를 종료했습니다. 직접 연결한 팀들은 MCP 서버 설정을 업데이트할 때까지 이미지 파이프라인이 깨졌습니다. Runtime을 쓰던 팀들은 runtime이 어댑터를 업데이트했습니다. 에이전트 쪽 변경은 0이었습니다.

토큰 계산

에이전트가 연결하는 각 MCP 서버나 API는 컨텍스트에 도구 설명을 등록합니다. 보통 서버 하나당 3,000~8,000토큰이 추가됩니다.

200K 컨텍스트 창 기준으로 보면 실제 추론, 코드 생성, 대화 이력을 위해 7~19%의 공간을 더 확보하는 셈입니다. 여러 시간에 걸친 코딩 작업처럼 컨텍스트가 매우 중요한 긴 에이전트 세션에서는, 이 차이가 작업 완수와 흐름 상실을 가르는 차이가 됩니다.

MCP vs Skills vs Capability Runtime: 각각 어디에 맞는가

이 세 레이어는 서로 다른 문제를 해결합니다. 이를 혼동하면 과도하게 복잡한 구성이 됩니다.

대부분의 팀이 최종적으로 도달하는 구성:

• 1~2개의 MCP 서버 for 내부 또는 회사 전용 도구
• 1개의 capability runtime for 모든 에이전트가 필요로 하는 다섯 가지 capability
• 2~3개의 skill file for 팀별 워크플로와 규칙

안티패턴은 각 capability를 개별 MCP 서버로 감싸는 것입니다. 이것이 바로 도구 설명에 40,000토큰이 드는 문제를 만듭니다.

실제 예시: Before와 After

Runtime 없이 에이전트로 랜딩 페이지를 만드는 경우:

1. 에이전트가 HTML/CSS를 작성한다 ✅
2. 히어로 이미지가 필요하다 — 멈춘다. 사람이 이미지 API를 수동 설정하고, 이미지를 직접 생성한 뒤, URL을 다시 붙여 넣는다. (사람 시간 4분)
3. 경쟁사 조사가 필요하다 — 멈춘다. 사람이 직접 검색해서 결과를 붙여 넣는다. (3분)
4. 에이전트가 페이지를 완성한다 — 끝. 사람이 수동 배포한다. (2분)
5. 더 좋은 이미지 모델을 찾았다고 에이전트가 말한다 — 멈춘다. 사람이 다른 API를 설정한다. (5분)

총합: 사람 병목 약 14분. 에이전트가 다 할 수 있었던 일입니다. 단지 손이 없었습니다.

Capability runtime이 있는 경우:

1. 에이전트가 HTML/CSS를 작성한다 ✅
2. 에이전트가 image generate "hero for SaaS dashboard"를 호출한다 — CDN URL을 받는다 ✅
3. 에이전트가 search "competitor pricing Q2 2026"를 호출한다 — 출처가 포함된 구조화 결과를 받는다 ✅
4. 에이전트가 drive upload ./build/를 호출한다 — 자산이 공유 링크와 함께 저장된다 ✅
5. 에이전트가 page deploy ./build/를 호출한다 — 페이지가 배포된다 ✅
6. 세션 도중 이미지 모델을 바꾼다: image generate --model flux-1-kontext-max — 같은 명령, 다른 플래그 ✅

총합: 사람 시간 0분. 한 번의 세션. 한 명의 에이전트. 사람은 초기 프롬프트를 쓰고 결과를 검토만 하면 됩니다.

Capability Runtime을 고를 때 봐야 할 것

Capability runtime을 평가한다면 다음을 확인하세요.

• 폭넓은 지원 범위 — 에이전트가 실제로 필요한 capability를 다루는가? 핵심 다섯 가지는 이미지, 동영상, 검색, 저장, 퍼블리싱입니다.
• 에이전트 호환성 — 현재 사용하는 에이전트 스택과 동작하는가? Claude Code, Cursor, Codex, Windsurf를 지원해야 합니다.
• 출력 형식 — 구조화된 JSON이어야 합니다. 에이전트가 HTML이나 multipart 응답을 파싱하게 해서는 안 됩니다.
• 자격 증명 — 하나의 계정, 하나의 인증 흐름, 하나의 키. 키 교체가 쉬워야 합니다.
• 토큰 효율성 — 도구 설명은 15,000+가 아니라 약 2,000토큰 수준이어야 합니다.
• 모델 라우팅 — 에이전트가 모델을 직접 지정할 수 있는가, 아니면 작업에 따라 runtime이 선택하게 할 수 있는가? 둘 다 가능해야 합니다.
• 프로바이더 추상화 — 기반 API가 바뀌어도 에이전트가 눈치채지 않는가?

2026년의 생태계

Capability runtime은 새로운 카테고리입니다. 현재 구도는 다음과 같습니다.

올바른 선택은 에이전트가 무엇을 해야 하는지에 달려 있습니다. 이미지, 동영상, 배포된 페이지, 검색 리포트처럼 실제 산출물을 내는 에이전트는 결국 runtime이 필요해지는 경우가 많습니다. 텍스트 읽기와 쓰기만 하는 에이전트는 MCP 서버만으로도 버틸 수 있습니다.

결론

에이전트의 두뇌는 이미 준비되어 있습니다. 모델은 충분히 좋습니다. Claude Opus 4.7, GPT-5.5, Gemini 2.5는 모두 복잡한 추론을 처리합니다. 프레임워크도 성숙했습니다. 병목은 지능이 아니라, 에이전트가 실행할 손을 가졌는지 여부입니다.

Capability runtime은 그 손을 제공합니다. 한 번의 설치. 하나의 자격 증명. 모든 도구.

→ AnyCap을 무료로 사용해 보세요 — 한 번의 명령으로 에이전트에 현실 세계 capability를 부여하세요

FAQ

Capability runtime은 MCP 서버와 같은 것인가요?

아닙니다. MCP 서버는 하나의 도구 또는 서비스를 노출합니다. Capability runtime은 여러 capability를 하나의 인터페이스 뒤에 묶습니다. 둘은 함께 사용할 수 있습니다. 내부 도구에는 MCP 서버를, 모든 에이전트가 공통으로 필요로 하는 capability에는 runtime을 사용하는 식입니다.

각 provider마다 개별 API 키가 아직도 필요한가요?

Capability runtime을 사용하면 그렇지 않습니다. Runtime에 한 번만 인증하면 됩니다. Provider 자격 증명은 runtime이 내부적으로 관리합니다. Provider API가 바뀌면 runtime이 업데이트되고, 에이전트는 그 사실을 모릅니다.

어떤 코딩 에이전트와 함께 사용할 수 있나요?

좋은 capability runtime은 Claude Code, Cursor(Agent Mode), Codex CLI, Windsurf와 함께 동작합니다. 설치 방법은 에이전트별로 다르지만(skill 디렉터리가 다름), CLI 명령은 에이전트 전반에서 동일합니다.

별도의 MCP 서버와 비교해 runtime은 얼마나 많은 토큰을 절약하나요?

대략 13,00038,000토큰입니다. 얼마나 많은 개별 도구를 대체하느냐에 따라 달라집니다. 200K 컨텍스트 창에서는 실제 작업을 위한 여유가 719% 늘어납니다.

기존 MCP 서버와 함께 runtime을 사용할 수 있나요?

예. 이것이 권장 구성입니다. 회사 전용 도구(Jira, Slack, 내부 DB)를 위해 1~2개의 MCP 서버를 두고, 모든 에이전트가 필요로 하는 다섯 가지 횡단 capability를 위해 하나의 capability runtime을 두고, 팀 규칙을 위해 몇 개의 skill file을 추가하는 방식입니다.

📖 다음에 읽을 글

• Agentic AI vs Traditional AI: 5 Key Differences — 반응형 AI에서 목표 지향 에이전트로의 전환, 그리고 왜 지금 에이전트 인프라가 중요한지 이해해 보세요.
• How to Give Claude Code Cloud Storage — 구체적인 예시로, 3개의 명령으로 에이전트에 파일 저장 기능을 추가하는 방법입니다.
• Best AI Video Models for Coding Agents in 2026 — Veo 3.1 vs Seedance 2.0 vs Kling 3.0 vs Sora 2 Pro: 어떤 모델이 에이전트 워크플로에 맞는지 비교합니다.

관련 글

• How to Generate Video with Claude Code — 에이전트에 동영상 생성을 추가하는 완전 가이드입니다.
• AI Image-to-Video: The Complete Pipeline — 하나의 에이전트 워크플로 안에서 이미지 생성과 동영상 생성을 연결하는 방법입니다.
• What Is an AI Agent? The Complete Developer Guide — 에이전트 유형, 아키텍처, 도구 레이어 같은 기본 개념부터 시작하는 개발자 가이드입니다.