에이전트 런타임 선택이 종속(Lock-in)으로 이어져서는 안 되는 이유: 런타임 상위의 컨트롤 플레인 (Control Plane)

2026년 4월에서 7월 사이, 에이전트 인프라 시장에서 놀라운 일이 일어났습니다. AWS, Google, Anthropic 모두 관리형 에이전트 런타임(managed agent runtimes)을 출시했으며, 이들은 거의 정확히 동일한 프리미티브(primitives)로 수렴했습니다.

이제 각 플랫폼은 다음을 제공합니다:

• 세션별 샌드박스 실행 (격리된 Linux 환경)
• 세션 재시작 후에도 유지되는 내구성이 있는 메모리 (Durable memory)
• 에이전트 ID 및 자격 증명 범위 지정 (Agent identity and credential scoping)
• 게이트웨이 계층에서의 도구 권한 부여 (Tool authorization)
• 멀티 에이전트 오케스트레이션 (Multi-agent orchestration)
• 완전한 추적 가능성 및 감사 로그 (Full traceability and audit logging)

이러한 수렴은 실재합니다. 하지만 문제는 다음과 같습니다. API가 완전히 다르다는 점입니다.

AWS는 이를 CreateHarness 및 InvokeHarness라고 부릅니다. Google은 A2A 프로토콜을 사용하는 Agent Runtime이라고 부릅니다. Anthropic은 wake(sessionId) 패턴을 사용하는 Claude Managed Agents라고 부릅니다. Azure는 자체적인 인터페이스를 가지고 있습니다. 이들 중 어느 것도 서로 통신하지 않습니다.

프리미티브(primitives)의 수렴 + API의 분산 = 새로운 인프라 문제

런타임 종속(Lock-In)의 함정

만약 당신이 2026년 7월에 Claude Managed Agents를 기반으로 에이전트를 구축한다면, 다음과 같은 상황을 맞이하게 됩니다:

• ✅ 우수한 세션 관리
• ✅ 내장된 샌드박스 및 메모리
• ✅ 단순한 가격 책정 (세션 시간당 $0.08)
• ❌ 에이전트 로직이 Anthropic의 하네스(harness)에 밀접하게 결합됨

6개월 후, 규정 준수(compliance) 문제로 AWS에서 에이전트를 실행해야 하거나, 더 나은 멀티 에이전트 협업을 위해 Google의 Agent Runtime을 사용해야 하거나, 데이터 거주성(data residency)을 위해 자체 호스팅 인프라를 배포해야 할 때, 당신의 에이전트 코드는 이식되지 않습니다. 다시 만들어야 합니다.

이것은 2023-2024년에 LLM 전용 게이트웨이들이 OpenAI 호환 API를 통해 해결했던 바로 그 함정입니다. 하지만 우리는 이제 한 단계 위 계층에서 동일한 문제에 다시 갇히게 될 상황입니다.

런타임 선택이 실제로 중요한 이유

팀들은 런타임 선택이 상호 교환 가능하지 않다는 사실을 발견하고 있습니다:

• Claude Managed Agents는 장기적인 자율 작업(long-horizon autonomous work)에 탁월하며 가장 단순한 메모리 모델을 가지고 있습니다.
• AWS AgentCore는 에이전트가 200개 이상의 AWS 서비스에 접근해야 하고 이미 AWS를 사용 중인 경우 가장 효과적입니다.
• Google의 Agent Runtime은 가장 빠른 1초 미만의 콜드 스타트(cold starts)와 가장 강력한 멀티 에이전트 오케스트레이션(multi-agent orchestration)을 제공합니다.
• Self-hosted Multica 또는 LiteLLM을 사용하면 데이터를 온프레미스(on-premises)에 유지하면서 클라우드 제공업체를 교체할 수 있습니다.

런타임 하나를 선택한다는 것은 향후 18개월 동안 전체 운영 영역(operational surface)을 선택하는 것과 같습니다.

하지만 팀들이 발견하고 있는 사실은 다음과 같습니다: 런타임 프리미티브(runtime primitives)는 해결되었습니다. 하지만 런타임 API는 해결되지 않았습니다.

컨트롤 플레인(Control Plane) 솔루션

정답은 LLM 게이트웨이(LLM gateways)의 경우와 동일합니다: 컨트롤 플레인(control plane)을 통해 로직 계층(logic layer)을 런타임 계층(runtime layer)으로부터 분리하는 것입니다.

런타임 상위의 프로덕션 컨트롤 플레인은 다음을 처리합니다:

• 런타임 추상화 (Runtime abstraction): 에이전트는 한 번만 등록하면 코드 변경 없이 어떤 런타임에서도 실행됩니다.
• 세션 이식성 (Session portability): Anthropic의 런타임에서 세션이 충돌하더라도, 동일한 상태로 AWS의 런타임에서 재개할 수 있습니다.
• 메모리 통합 (Memory unification): 지속 가능한 세션 메모리(Durable session memory)는 런타임이 아닌 에이전트를 따라갑니다.
• 자격 증명 범위 지정 (Credential scoping): 컨트롤 플레인이 자격 증명을 관리하고 에이전트를 실행 중인 런타임에 전달합니다.
• 감사 추적 (Audit trails): 플랫폼별로 별도의 로그를 남기는 것이 아니라, 모든 런타임에 걸쳐 하나의 불변 기록(immutable record)을 유지합니다.
• 비용 귀속 (Cost attribution): 플랫폼별로 격리되지 않고, 에이전트별, 런타임별, 세션별 비용을 확인할 수 있습니다.

에이전트가 런타임 A에서 실행되다가 런타임 B로 이동해야 할 때, 컨트롤 플레인이 변환을 처리합니다:

에이전트 로직 (Agent Logic, 프레임워크에 종속되지 않음)
    ↓
컨트롤 플레인 (Control Plane, 벤더 중립적 오케스트레이션)
...

컨트롤 플레인은 런타임을 교체 가능하게 만드는 변환 계층(translation layer)입니다.

이것이 지금 왜 중요한가

2026년 7월 현재, 이것은 이론적인 이야기가 아닙니다. 팀들은 이미 이 벽에 부딪히고 있습니다:

• Claude Managed Agents 기반 파일럿 (빠른 출시, 뛰어난 개발자 경험)
• 3개월 차: "SOC2 준수를 위해 AWS 환경이 필요합니다"
• 4개월 차: "데이터 거주성 (Data Residency)을 위해 온프레미스 (On-premises) 환경이 필요합니다"
• 현실: 런타임 (Runtime) 선택이 아키텍처 (Architecture)에 내재되어 있었기 때문에 에이전트를 세 번이나 다시 구축해야 함

승리하고 있는 팀들은 런타임을 아키텍처적 선택이 아닌, 배포의 선택지로 취급하는 팀들입니다.

LiteLLM Agent Platform은 이 패턴을 구현합니다. 에이전트는 플랫폼에 등록하고 로직을 한 번만 정의하며, 플랫폼은 워크로드 (Workload)에 가장 적합한 런타임으로 실행을 라우팅 (Routing)합니다. 순수 클라우드 배포를 위한 AWS AgentCore, 장기적 자율 작업을 위한 Claude Managed Agents, 데이터 주권 (Data Sovereignty)을 위한 셀프 호스팅 (Self-hosted) 인프라가 그 예입니다.

동일한 에이전트 로직. 서로 다른 런타임. 컨트롤 플레인 (Control Plane)이 번역을 처리합니다.

컨트롤 플레인 성숙도를 확인하는 5가지 질문

에이전트 플랫폼을 평가할 때는 관심사 (Concerns)를 분리해야 합니다:

1. 코드를 다시 작성하지 않고도 동일한 에이전트 정의를 여러 런타임에 배포할 수 있는가? 만약 "네, 가능합니다"와 "네, 하지만 커스텀 코드가 필요합니다"의 차이가 있다면, 당신은 인프라 계층 (Infrastructure Layer)을 찾은 것입니다.

2. 플랫폼이 런타임 어댑터 (Runtime Adapters)를 일급 기능 (First-class features)으로 제공하는가? 아니면 직접 번역 로직을 구현해야 하는가?

3. 실행 중인 세션을 한 런타임에서 다른 런타임으로 이동할 수 있는가? 이는 단순한 래퍼 (Wrapper)와 실제 컨트롤 플레인을 구분 짓는 기준입니다.

4. 감사 추적 (Audit Trail)이 모든 런타임에 걸쳐 통합되어 있는가? 아니면 여러 플랫폼의 실행 로그를 일일이 디버깅해야 하는가?

5. 재배포 없이 에이전트별로 런타임을 변경할 수 있는가? 아니면 에이전트당 하나의 런타임에 평생 종속되어야 하는가?

만약 대부분의 질문에 "예"라고 답할 수 있다면, 당신은 진정한 컨트롤 플레인 인프라를 보고 있는 것입니다. 만약 "직접 구축해야 합니다"라고 답하게 된다면, 당신은 런타임 선택을 아키텍처적 결정이 아닌 운영적 결정으로 만드는 플랫폼을 찾은 것입니다.

스택에서 무엇이 변하는가

만약 하나의 런타임을 선택하고 전념할 계획을 세워왔다면, 2026년 8월에 취해야 할 올바른 조치는 다음과 같습니다:

• 에이전트를 이식 가능한 정의(프롬프트(prompts), 도구(tools), 메모리 스키마(memory schemas))로 구축하십시오.
• 런타임 세부 사항을 추상화하는 컨트롤 플레인(control plane)을 통해 실행하십시오.
• 워크로드(workload)에 적합한 어떤 런타임으로든 배포하십시오.
• 코드 변경 없이 런타임을 마이그레이션(migrate)할 수 있는 옵션을 유지하십시오.

이것은 "최고의" 런타임을 구매하는 것에 관한 것이 아닙니다. 업계가 기본 요소(primitives)로 수렴하고 있다는 것을 이미 알고 있을 때, 런타임 선택이 종속(lock-in) 지점이 되지 않도록 하는 것에 관한 것입니다.

런타임은 계속해서 발전할 것입니다. API는 업계 표준이 등장할 때까지 아마 계속해서 갈라질 것입니다. 컨트롤 플레인(control plane)은 시장이 안정될 때까지 종속(lock-in)에 대비할 수 있는 당신의 헤지(hedge) 수단입니다.

2023-2024년에 LLM 전용 게이트웨이(gateways)는 제공자(provider) 선택이 중요하며, 그것이 앱 로직에 내장되어서는 안 된다는 것을 우리에게 가르쳐 주었습니다. 정확히 동일한 교훈이 이제 에이전트 런타임(agent runtimes)에도 적용됩니다.

워크로드(workload)에 적합한 런타임을 선택하십시오. 하지만 당신의 컨트롤 플레인(control plane)이 마음을 바꿀 수 있게 해주는지 반드시 확인하십시오.