2026년 8월, 에이전트 플랫폼 시장은 뚜렷한 카테고리로 분화되고 있으며 점점 혼란스러워지고 있습니다.

현재 다음과 같은 것들이 있습니다:

• 에이전트 프레임워크 (Agent frameworks) (LangGraph, CrewAI, Anthropic SDK) — 이것들은 에이전트의 로직 (logic) 문제를 해결합니다.
• 에이전트 플랫폼 (Agent platforms) (Claude Managed Agents, Bedrock AgentCore, Gemini Enterprise Agent Platform) — 이것들은 _관리형 런타임 (managed runtimes)_을 제공합니다.
• 에이전트 인프라 (Agent infrastructure) (제어 평면 (control planes), 오케스트레이션 (orchestration), 멀티 런타임 조정 (multi-runtime coordination)) — 이것들은 운영 제어 (operational control) 문제를 해결합니다.

시장은 이 세 가지 모두를 "에이전트 플랫폼"으로 판매하고 있으며, 팀들은 순수 프레임워크로 인프라 문제를 해결하려 하거나, 관리형 플랫폼이 설계되지 않은 거버넌스(governance) 문제를 해결하도록 만들려다 어려움을 겪고 있습니다.

문제는 이것입니다: 당신은 세 가지 모두가 필요하며, 이들은 서로 다른 계층에서 작동합니다.

팀들이 필요로 하지만 하나로 혼동하는 세 가지 계층

계층 1: 에이전트 로직 (Agent Logic) (프레임워크)
에이전트의 추론 (reasoning), 도구 호출 (tool-calling), 상태 관리 (state management), 계획 (planning). LangGraph, CrewAI, Pydantic AI가 모두 이를 해결합니다. 이들은 이 분야에 매우 뛰어납니다.

계층 2: 에이전트 런타임 (Agent Runtime) (관리형 플랫폼)
실행 샌드박스 (execution sandbox), 세션 격리 (session isolation), 중단/재개 (interrupt/resume), 내장 메모리 (built-in memory). Claude Managed Agents, Bedrock AgentCore, Gemini Enterprise Agent Platform이 모두 이를 제공합니다. 이들은 단일 런타임 배포를 위한 프로덕션 준비가 되어 있습니다.

계층 3: 에이전트 제어 평면 (Agent Control Plane) (인프라)
멀티 런타임 조정 (multi-runtime coordination), 자격 증명 중앙 집중화 (credential centralization), 런타임 간 세션 지속성 (session durability across runtimes), 에이전트별 ID (per-agent identity), 관찰 가능성 (observability), 스케줄링 (scheduling), 비용 귀속 (cost attribution), 평가 기반 의사 결정 (evaluation-driven decision-making). 아직 에이전트를 위해 이를 구축한 곳은 거의 없습니다. 대부분의 팀은 에이전트 프로젝트를 시작한 지 3개월째에 이를 직접 구축하고 있습니다.

에이전트 플랫폼 마케팅의 암묵적인 가정은 에이전트를 관리하는 것이 LLM을 관리하는 것과 같다는 것입니다. 하지만 그렇지 않습니다.

이것이 지금 중요한 이유

2026년 6월에는 단 일주일 만에 세 개의 주요 팀 수준 에이전트 플랫폼이 출시되는 것을 목격했습니다:

• Cognition의 Devin Desktop (에이전트 조정 콘솔)
• Microsoft의 Rayfin (거버넌스/배포 레이어)
• Augment Code의 Cosmos (플릿 오케스트레이션 (fleet orchestration))

이는 시장이 "단일 에이전트, 단일 런타임 (single agent, single runtime)"에서 "다중 에이전트, 다중 팀, 다중 런타임 (multiple agents, multiple teams, multiple runtimes)"으로 전환되고 있음을 나타냅니다.

그 규모에서는 인프라의 격차가 눈에 띄게 드러납니다:

• Claude Managed Agents, Cursor, Bedrock 및 내부 도구에 에이전트를 사용하는 팀들은 여러 런타임에 걸쳐 에이전트를 호출할 수 있는 통합된 방법이 없습니다.
• 자격 증명 (Credentials)이 분산되어 있습니다 (플랫폼별 키, 콘솔별 액세스).
• 비용이 보이지 않습니다 (에이전트당 비용이 아닌 런타임당 지출).
• 거버넌스 (Governance)가 파편화되어 있습니다 (정책 변경 시 에이전트를 다시 배포해야 함).
• 세션의 이식성 (portability)이 없습니다 (한 런타임에서 충돌하면 다른 런타임에서 처음부터 다시 시작해야 함).

팀들은 맞춤형 인프라를 구축함으로써 이 문제를 해결합니다. 현명한 팀들은 프로젝트 중간에 이것이 일주일짜리 스프린트가 아니라는 사실을 깨닫습니다. 이것은 6~8주간의 아키텍처적 헌신 (architectural commitment)입니다.

실제 평가 프레임워크

2026년 8월에 에이전트 플랫폼을 살펴볼 때는 다음 질문들을 던져보십시오. 이 질문들이 운영 인프라와 과장된 광고 (hype)를 구분해 줄 것입니다.

1. 다중 런타임 지원 (Multi-Runtime Support)

질문: 에이전트를 다시 작성하지 않고도, 하루는 Claude Managed Agents에서 실행하고 다음 날은 Bedrock AgentCore에서 동일한 에이전트 로직을 실행할 수 있는가?

확인할 사항: 런타임 어댑터 (Runtime adapters), 런타임 선택과 독립적인 에이전트 등록, 상태(state)를 포함한 세션 이식성.

위험 신호 (Red flags): "하나의 플랫폼을 선택하고 그것을 고수하십시오", "우리는 AWS와 통합됩니다", "Claude와 가장 잘 작동합니다", "다른 런타임을 지원하려면 맞춤형 코드가 필요합니다."

중요한 이유: 파일럿 단계에서는 프로덕션 제약 조건을 알 수 없습니다. 6월에는 SOC2 준수가 필요하여 AWS를 선택할 수 있고, 3개월 차에는 EU 내 데이터 레지던시 (data residency)가 필요할 수 있습니다. 그 후 민감한 워크플로우를 위해 온프레미스 (on-prem)가 필요할 수도 있습니다. 만약 에이전트 인프라가 하나의 런타임에 종속(locked)되어 있다면, 매번 다시 구축해야 할 것입니다.

2. 자격 증명 중앙화 (Credential Centralization)

질문: 에이전트별, 런타임(runtime)별로 관리하는 대신, 제공자 자격 증명(AWS 키, Anthropic 토큰, GitHub OAuth 등)을 한 곳에서 관리할 수 있는가?

확인 사항: Vault 통합, 자격 증명을 (전역이 아닌) 에이전트 단위로 제한하는 스코핑(scoping), 자격 증명 사용에 대한 변경 불가능한(immutable) 감사 추적(audit trails).

위험 신호 (Red flags): "각 에이전트는 자체 API 키를 가집니다", "자격 증명이 런타임의 환경 변수(environment variables)에 저장됩니다", "자격 증명을 교체(rotate)하려면 콘솔 접속이 필요합니다."

중요한 이유: 2개월 차에는 에이전트가 3개뿐일 것입니다. 6개월 차에는 3개의 런타임에 걸쳐 5개의 에이전트가 있고, 접근 권한이 필요한 사람이 10명에 달할 것입니다. 이때 콘솔 접속 방식은 운영 측면에서 유지 관리가 불가능해집니다. 팀원이 퇴사할 때 자격 증명을 교체하는 작업은 혼란 그 자체가 될 것입니다. 에이전트별 자격 증명 스코핑(scoping)만이 확장이 가능한 유일한 접근 방식입니다.

3. 재배포 없는 에이전트별 설정 (Per-Agent Configuration Without Redeployment)

질문: 에이전트 자체를 재배포하지 않고도 에이전트의 모델, 도구 권한(tool permissions), 속도 제한(rate limits) 또는 비용 예산을 변경할 수 있는가?

확인 사항: 에이전트 정의와 별도로 저장되는 설정(configuration), 에이전트 코드나 컨테이너를 건드리지 않고 제어 평면(control plane)에서 정책을 변경할 수 있는 능력.

위험 신호 (Red flags): "설정이 에이전트에 내장(baked into)되어 있습니다", "정책 변경을 위해 컨테이너를 다시 빌드해야 합니다", "모델을 변경하려면 재배포가 필요합니다."

중요한 이유: 2개월 차에는 에이전트가 GPT-4로 작동합니다. 3개월 차에 GPT-5가 출시되고 비용이 더 저렴해졌다면, 당신은 재배포가 아니라 설정 파일에서 모델을 교체하고 싶을 것입니다. 도구 권한도 마찬가지입니다. 에이전트가 새로운 API를 발견했을 때, 다시 빌드하는 것이 아니라 제어 평면(control plane)에서 해당 기능을 활성화/비활성화하기를 원할 것입니다.

4. 세션 내구성 및 이식성 (Session Durability and Portability)

질문: 에이전트가 워크플로 도중에 충돌(crash)하더라도, 멈춘 지점부터 정확히 다시 시작할 수 있는가? (가능하다면 다른 런타임에서도 가능한가?)

확인 사항: Postgres 기반의 내구성 있는 세션, 상태(state)/메모리/실행 이력을 포함하는 세션 스냅샷(snapshots), 디버깅을 위한 세션 재생(replay) 기능.

위험 신호 (Red flags): "세션은 인메모리(in-memory) 방식입니다", "재개(resumption) 기능은 직접 구현해야 합니다", "세션은 특정 런타임 포드(runtime pod)에 종속됩니다."

중요한 이유: 조직에 실질적인 가치를 더해주는 것은 장시간 실행되는 에이전트(24시간 이상, 100단계 이상)입니다. 하지만 이러한 에이전트들은 취약하기 쉽습니다. 내구성(Durability)은 "하루 치의 작업량을 날리느냐"와 "4시간 치의 작업량을 날리느냐"의 차이를 만듭니다. 5개 이상의 에이전트가 동시에 실행되는 환경에서는 세션 내구성(session durability)이 운영의 기본값이 됩니다.

5. 통합 관측성(Unified Observability) 및 비용 귀속(Cost Attribution)

질문: 어떤 에이전트가 어떤 지출을 유발했는지 확인할 수 있는가? 모든 런타임에 걸친 모든 호출(invocation)을 쿼리할 수 있는가? 에이전트별 평가 신호(evaluation signals)를 볼 수 있는가?

확인해야 할 사항: 에이전트별 비용 대시보드, 쿼리 가능한 실행 이력(execution history), 에이전트 식별자와 연결된 평가 지표(evaluation metrics), 도구 호출(tool call) 단위까지 세분화된 비용 귀속.

위험 신호 (Red flags): "비용은 제공자(provider)/모델별로 산정됩니다", "관측성(observability)은 에이전트 단위가 아닌 플랫폼 수준에서 제공됩니다", "로깅(logging)은 직접 연결해야 합니다."

중요한 이유: 운영 3개월 차가 되면, 어떤 에이전트는 세션당 비싼 도구를 500번 호출하는 반면, 다른 에이전트는 단 3번의 호출로 완벽하게 수행하고 있다는 사실을 발견하게 될 것입니다. 여러분에게 필요한 것은 총합 비용이 아니라 이러한 세부 내역입니다. 품질 또한 마찬가지입니다. 평가 지표를 특정 에이전트에 귀속시킬 수 없다면 그 지표는 가치가 없습니다.

6. 결정론적 권한 부여 (Deterministic Authorization, 프롬프트 기반이 아닌 방식)

질문: 만약 에이전트 A가 권한이 없는 도구를 호출하려고 시도할 경우, 그 결정은 인프라에 의해 내려지는가(우회 불가능)? 아니면 에이전트의 학습/프롬프트에 내장되어 있는가(우회 가능)?

확인해야 할 사항: 호출 계층(invocation-layer)의 도구 권한 부여, 누가 무엇을 승인했는지 보여주는 불변의 감사 추적(audit trails), 게이트웨이에서 강제되는 에이전트별 도구 범위(tool scoping).

위험 신호 (Red flags): "권한 부여는 시스템 프롬프트(system prompt)에 포함되어 있습니다", "가드레일(guardrails)은 에이전트 로직의 일부입니다", "우리는 모델이 가이드라인을 따르는 것에 의존합니다."

중요한 이유: 이것은 보안/컴플라이언스(compliance)의 경계선입니다. 2026년 7월의 사건들(OpenClaw, Hugging Face, Langflow) 이후, 감사인들은 다음과 같이 질문합니다: "에이전트 A가 삭제 엔드포인트(delete endpoint)를 호출할 수 없다는 것을 증명해 보세요." 프롬프트 기반의 제어(Prompt-based controls)는 적대적 시나리오(adversarial scenarios)에서 실패합니다. 인프라에 의해 강제되는 제어(Infrastructure-enforced controls)는 실패하지 않습니다.

7. 멀티 에이전트 조정 프리미티브 (Multi-Agent Coordination Primitives)

질문: 외부 도구 없이 "에이전트 B가 성공한 후에 에이전트 A가 실행된다"는 것을 표현할 수 있는가? 에이전트들이 서로 메시지를 주고받을 수 있는가? 에이전트 군단(fleet) 전체에 걸쳐 예산을 설정할 수 있는가?

확인해야 할 사항: 네이티브 스케줄링(Native scheduling), 에이전트 간 통신(agent-to-agent communication), 플릿 수준의 리소스 관리(fleet-level resource management), 의존성 그래프(dependency graphs).

위험 신호 (Red flags): "오케스트레이션(orchestration)을 위해 n8n/Temporal/Prefect가 필요합니다", "에이전트들은 독립적으로 실행됩니다", "조정(coordination)은 직접 관리해야 합니다."

중요한 이유: 4개월 차가 되면 단일 에이전트는 지루해집니다. 당신은 에이전트 A가 문제를 찾고, 에이전트 B가 이를 분석하며, 에이전트 C가 해결책을 초안하는 것을 원할 것입니다. 네이티브 조정 프리미티브(native coordination primitives)가 없다면, 외부 오케스트레이션을 덧붙여야 하며, 이는 지연 시간(latency), 복잡성, 그리고 운영해야 할 또 다른 도구를 추가하게 됩니다.

작동하는 아키텍처 패턴

팀들이 파일럿 단계에서 지속적인 멀티 에이전트 운영으로 넘어갈 때 채택하는 패턴은 다음과 같습니다:

에이전트 로직 레이어 (Agent Logic Layer)
    ↓ (한 번 정의되면, 런타임에 무관함)
컨트롤 플레인 (Control Plane)
...

컨트롤 플레인(control plane)은 모든 결정이 이루어지는 곳입니다. 데이터 플레인(data plane)은 요청이 빠르게 이동하는 곳입니다. 이 둘은 결합될 수 없습니다. 거버넌스(governance)는 상태 유지(stateful)가 필요하지만(Postgres, 감사 추적, 권한 확인 필요), 라우팅(routing)은 상태 비저장(stateless)이어야 합니다(1ms 미만의 오버헤드 필요).

진짜 에이전트 플랫폼을 식별하는 방법

위의 7가지 질문을 바탕으로 평가한 후, 실제로 확장 가능한 인프라를 나타내는 결정적인 징후들은 다음과 같습니다:

1. 제어 평면 (Control Plane)과 데이터 평면 (Data Plane)을 분리합니다. 이 플랫폼은 거버넌스 (Governance)와 빠른 라우팅 (Routing)이 서로 다른 문제임을 인지하고 있습니다.

2. 에이전트를 일급 인프라 (First-class infrastructure)로 취급합니다. 에이전트는 단순한 채팅 세션이 아니라, 마이크로서비스 (Microservices)처럼 영구적인 ID (Durable identity), 지속적인 세션 (Persistent sessions), 쿼리 가능한 히스토리 (Queryable history)를 가집니다.

3. 설계 단계부터 런타임 불가지론적 (Runtime-agnostic)입니다. 플랫폼이 단 하나의 관리형 런타임 (Managed runtime)에 회사의 운명을 걸지 않습니다. 플랫폼은 런타임을 대체하는 것이 아니라, 런타임과 함께 작동합니다.

4. 비용, 평가 (Evaluation), 관측성 (Observability)이 내장되어 있습니다. 별도로 덧붙여진 것이 아닙니다. "X와 통합할 수 있습니다" 수준이 아니라, 네이티브한 일급 프리미티브 (First-class primitives)로 제공됩니다.

5. Rust 또는 네이티브로 컴파일된 데이터 평면을 갖추고 있습니다. Python 게이트웨이는 동시성 (Concurrency) 환경에서 요청당 78ms의 지연 시간을 추가합니다. 세션당 100번의 에이전트 단계가 진행된다면, 이는 순수하게 인프라 비용으로만 700800ms가 소모됨을 의미합니다. 에이전트 워크로드 (Agent workloads)의 경우, 1ms 미만의 오버헤드는 기본 요건 (Table-stakes)입니다.

6. 멀티 에이전트 조정 (Multi-agent coordination)이 숨겨져 있지 않고 명확합니다. 만약 "에이전트들이 어떻게 협업하게 만드나요?"라고 물어야 한다면, 그 플랫폼은 불완전한 것입니다.

LiteLLM 에이전트 플랫폼이 제공하는 것

솔직하게 말씀드리겠습니다. 저는 LiteLLM 인프라 팀에서 일하고 있습니다. 투명하게 공개합니다.

LiteLLM 에이전트 플랫폼 (LiteLLM Agent Platform, LAP)은 정확히 위의 패턴에 맞춰 구축되었습니다:

• 멀티 런타임 (Multi-runtime) (Claude Managed, Bedrock, 어댑터를 통한 자체 호스팅 런타임)
• 자격 증명 금고 (Credential vault) (중앙 집중식, 에이전트별 범위 지정, 감사 추적 (Audit trails))
• 에이전트별 설정 (Per-agent config) (재배포 없이 모델/도구/예산 변경 가능)
• 지속적인 세션 (Durable sessions) (Postgres 기반, 재개 가능, 이식 가능)
• 비용/평가 귀속 (Cost/eval attribution) (에이전트별 대시보드, 품질 지표)
• 호출 계층 인증 (Invocation-layer auth) (인프라 수준에서 강제되는 도구 권한 부여)
• 네이티브 스케줄링 (Native scheduling) (cron, 의존성, 멀티 에이전트 워크플로우)
• LiteLLM-Rust 데이터 평면 (LiteLLM-Rust data plane) (p99 오버헤드 0.66ms, Python보다 11배 적은 메모리 사용, 평가 기반 라우팅 (Evaluation-driven routing)이 실용적으로 작동할 만큼 빠른 속도)

이것이 일곱 가지 질문 모두에 답할 수 있는 유일한 플랫폼일까요? 아닙니다. 하지만 이 플랫폼은 _런타임(runtimes) 전반에 걸쳐 에이전트를 확장해야 하는 팀_을 위해 특별히 구축되었으며, 이는 2026년 6월에는 거의 존재하지 않았으나 이제는 시장의 현실이 된 카테고리입니다.

실제 의사결정 지점

2026년 8월, 만약 당신이 에이전트 플랫폼을 평가하면서 "우리 팀은 영원히 Claude Managed Agents 위에서 모든 에이전트를 실행할 것이다"라고 생각한다면, 컨트롤 플레인 (control-plane) 인프라는 필요하지 않습니다. 프레임워크와 관리형 런타임 (managed runtime)만으로도 충분합니다.

하지만 "컴플라이언스(compliance)를 위해 AWS가 필요할 수도 있고, 민감한 데이터를 위해 온프레미스 (on-prem)가 필요할 수도 있으며, 비용 제어를 위해 반드시 셀프 호스팅 (self-hosted)이 필요할 것이다"라고 생각한다면, 단일 런타임에 종속되지 않는 인프라가 필요합니다.

그때가 바로 위의 일곱 가지 질문을 던져야 할 시점입니다. 그리고 당신은 아직 이 일곱 가지 질문 모두에 답할 수 있는 것이 거의 없다는 사실을 알게 될 것입니다. 일곱 가지 질문 모두에 답할 수 있는 플랫폼들은, "하나의 플랫폼만 선택하는 것"은 대규모 확장 시 작동하지 않는다는 것을 팀들이 고통스러운 경험을 통해 깨닫게 됨에 따라 2026년 4분기에는 기본 요건 (table-stakes)이 될 것입니다.

2026년 8월에 승리하는 팀들은 가장 똑똑한 에이전트나 가장 화려한 모델을 가진 팀들이 아닙니다. 그들은 에이전트 조정 (agent coordination)을 위해 지루하지만 신뢰할 수 있는 인프라를 구축하거나 채택한 팀들입니다. 일곱 가지 질문을 던지십시오. 그중 대부분에 "예"라고 답하는 플랫폼을 선택하십시오. 그 외의 모든 것은 있으면 좋은 기능 (nice-to-have)일 뿐입니다.