4계층 에이전트 스택: 프레임워크만으로는 부족할 때

모델(Models). 하네스(Harnesses). 런타임(Runtimes). 컨트롤 플레인(Control plane).

2026년 중반쯤이면, 대부분의 프로덕션 에이전트 팀들이 명시적으로 인정하든 아니든 이 구조로 수렴하게 될 것입니다. 어떤 규모로든 에이전트를 구축하고 있다면, 여러분은 이미 이 네 가지 계층을 모두 다루고 있습니다. 문제는 여러분의 인프라가 이러한 분리를 가시화하는지, 아니면 무언가 고장 날 때까지 숨기고 있는지입니다.

왜 3계층으로는 충분하지 않게 되었는가

1년 전만 해도 에이전트 인프라는 더 단순해 보였습니다. 모델(Claude, GPT-4)을 선택하고, 오케스트레이션 로직(LangChain, CrewAI, LangGraph)을 작성한 뒤, 어딘가(노트북, 클라우드 인스턴스, 관리형 플랫폼)에서 실행하면 되었습니다. 세 개의 명확한 구성 요소였죠.

에이전트가 챗봇, 단순한 도구 호출(tool calling), 단일 모델 워크플로우와 같이 단순한 도구였을 때는 그것으로 충분했습니다.

하지만 프로덕션 에이전트는 더 이상 그렇지 않습니다. 이들은 다음과 같은 특성을 가집니다:

• 멀티 런타임(Multi-runtime) (팀 내에서 Claude Code, Cursor Agents, Bedrock agents, 커스텀 에이전트 등을 실행하며, 종종 동일한 팀 내에서 이 모든 것을 동시에 사용함)
• 상태 유지(Stateful) (포드(pod) 재시작 후에도 유지되는 세션, 호출 간에 지속되는 메모리)
• 도구 중심(Tool-heavy) (결정당 30개 이상의 도구 호출, 구조화된 실행 및 비용 추적 포함)
• 거버넌스 적용(Governed) (에이전트별 ID, 액세스 제어, 감사 추적(audit trails), 컴플라이언스 요구사항)

3계층으로는 이러한 복잡성을 깔끔하게 처리할 수 없습니다. 그래서 네 번째 계층이 등장했습니다.

4계층 스택

Layer 1: 모델 (Models)

Claude, GPT-5.5, Gemini 3.5, Deepseek. LLM 그 자체입니다. 여러분은 이를 제어하는 것이 아니라 API를 통해 소비합니다.

Layer 2: 하네스 (Harnesses)

모델을 감싸고 모델이 어떻게 추론하고 행동할지를 정의하는 코드입니다. OpenCode (Anthropic의 샌드박스 우선 하네스), Claude Code (터미널 우선), Cursor의 인라인 모델, Codex, 그리고 직접 작성하는 커스텀 하네스 등이 있습니다.

하네스는 다음을 결정합니다: 에이전트가 컴퓨터 사용(computer use)을 할 수 있는가? 디스크에 파일을 쓸 수 있는가? 임의의 셸 명령어를 실행할 수 있는가? 지속성(persistence)을 갖는가? 어떤 도구들을 사용할 수 있는가?

Layer 3: 런타임 (Runtimes)

하네스(harness)를 실행하는 인프라입니다. Claude Managed Agents (Anthropic 호스팅), AWS Bedrock AgentCore (AWS 호스팅), 커스텀 Kubernetes 포드(pods), 로컬 Docker 컨테이너 등이 이에 해당합니다.

런타임(runtime)은 다음을 처리합니다: 샌드박싱 (Sandboxing), 스케일링 (scaling), 빌링 (billing), 컴플라이언스 경계 (compliance boundaries), 모델 라우팅 (model routing).

Layer 4: 컨트롤 플레인 (Control Plane)

이 계층은 모두를 놀라게 한 계층입니다.

컨트롤 플레인은 모든 런타임 상단에 위치하며, 런타임만으로는 해결할 수 없는 문제를 해결합니다: 어떻게 하면 여러 런타임에 걸쳐 있는 에이전트들을 하나의 일관된 시스템으로서 관리할 것인가?

컨트롤 플레인은 다음을 처리합니다:

• 멀티 런타임 디스커버리 (Multi-runtime discovery): 에이전트가 어떤 런타임에서 실행되든 상관없이 에이전트를 호출할 수 있는 단일 API
• 세션 지속성 (Session persistence): 런타임 재시작, 포드(pod) 배포, 하드웨어 장애 시에도 에이전트 상태(state)가 유지됨
• 거버넌스 및 감사 (Governance and audit): 에이전트별 신원 (identity), 액세스 제어 (access controls), 정책 집행 (policy enforcement), 변조 방지 로깅 (tamper-evident logging)
• 비용 및 예산 추적 (Cost and budget tracking): 에이전트별, 팀별 지출 귀속 및 강제 적용
• 관측 가능성 (Observability): 에이전트가 무엇을 했는가? 왜 그런 결정을 내렸는가? 어디에 비용을 사용했는가?

왜 프레임워크가 컨트롤 플레인이 될 수 없는가

LangChain, CrewAI, LangGraph—이러한 프레임워크들은 에이전트 로직(Layer 2)을 처리하는 데 매우 뛰어납니다. 이들은 단일 프레임워크 내의 단일 에이전트를 위해 추론 루프 (reasoning loop), 도구 호출 (tool calling), 함수 호출 (function calling), 메모리 관리 (memory management)를 처리합니다.

하지만 이들은 자신의 경계 외부를 볼 수 없기 때문에 컨트롤 플레인 문제를 해결하지 못합니다.

만약 당신이 Claude Managed Agent와 Cursor 에이전트를 가지고 있고, 이들이 다음을 수행하기를 원한다면:

• 세션 메모리 공유
• 통합된 액세스 제어 강제
• 비용을 하나의 팀 예산으로 집계
• 두 에이전트가 수행한 작업에 대한 감사

...당신의 프레임워크는 이를 수행할 수 없습니다. 각 프레임워크는 자신의 에이전트만 알고 있습니다. 다른 런타임에서 실행되는 에이전트에 대해서는 둘 다 알지 못합니다.

결국 팀들은 다음 중 하나를 선택하게 됩니다:

1. 런타임별 에이전트 사일로화 (Siloing agents by runtime) — 각 팀은 하나의 플랫폼(Claude Managed Agents 또는 Cursor 또는 Bedrock)에만 접근할 수 있으며, 이들은 서로 다른 API를 가진 별도의 콘솔에서 운영됩니다. 이는 코드 재사용을 저해하고 가시성을 분산시킵니다.

2. 제어 평면(Control plane)을 수동으로 구축 — 여러 플랫폼에 걸쳐 인증 시스템, 세션 저장소, 비용 추적, 거버넌스 정책을 하나로 묶는 작업입니다. 현재 대부분의 프로덕션 팀은 기능을 출시하는 대신 바로 이 작업에 엔지니어링 시간을 허비하고 있습니다.

3. 제어 평면이 나오기를 기다림 — 프레임워크가 결국 멀티 런타임 오케스트레이션 (Multi-runtime orchestration)을 처리해 주기를 희망하는 것입니다. (하지만 그렇게 되지 않을 것입니다.)

누락된 인프라 계층 (The Missing Infrastructure Layer)

제어 평면은 프레임워크의 문제도, 런타임의 문제도 아닙니다. 이는 인프라의 문제이며, 이를 올바르게 구축하는 데는 많은 비용이 듭니다.

이를 위해서는 다음과 같은 요소가 필요합니다:

• 런타임과 클라우드 제공업체의 경계를 초월하여 유지되는 내구성 있는 세션 저장소 (Durable session store)
• 멀티 테넌트 격리 (Multi-tenant isolation) (서로 다른 팀, 서로 다른 접근 권한, 서로 다른 비용 풀)
• 개발자에게 제공업체 콘솔을 노출하지 않는 자격 증명 금고 (Credential vault)
• 에이전트별 신원 및 정책 집행 (Per-agent identity and policy enforcement)
• 런타임 전반에서 작동하는 비용 귀속 시스템 (Cost attribution system)
• 전체 의사결정 경로, 도구 호출(Tool calls), 결과를 보여주는 구조화된 관측성 (Structured observability)

대부분의 프레임워크는 이것이 추론 로직 (Reasoning logic)과 직교(Orthogonal)하기 때문에 제공하지 않습니다. 대부분의 관리형 플랫폼은 단 하나의 런타임만 관리하기 때문에 이를 제공하지 않습니다. 여러 런타임을 통합할 유인이 없기 때문입니다.

따라서 제어 평면은 별도의 계층이 되었습니다.

이것이 귀하의 인프라에 의미하는 바

여러 런타임에서 에이전트를 운영하고 있다면, 다음이 필요합니다:

제어 평면 (A control plane): 에이전트가 어떤 런타임에서 실행되든 상관없이, 에이전트를 등록하고, 세션을 관리하며, 거버넌스를 집행하고, 지출을 추적할 수 있는 단일 지점입니다. 이것이 바로 팀들이 전용 에이전트 제어 평면을 구축하거나 도입하고 있는 이유입니다.

빠른 데이터 평면 (Fast data plane): 에이전트가 도구 호출 (tool calls) 및 모델 호출 (model invocations)을 수행할 때, 오버헤드가 낮은 라우팅 (routing), 폴백 (fallbacks), 그리고 비용 추적 (cost tracking)이 필요합니다. 규모가 커지면 Python 기반의 게이트웨이 (gateways)는 한계(메모리, 동시성, 지연 시간)를 드러내기 시작합니다. 이것이 인프라 팀들이 제어 평면 (control planes)과 함께 빠른 데이터 평면에 투자하는 이유입니다.

관심사의 분리 (Separation of concerns): 오케스트레이션 계층 (orchestration layer, 프레임워크)은 로직을 처리합니다. 제어 평면 (control plane)은 거버넌스 (governance)와 상태 (state)를 처리합니다. 데이터 평면 (data plane)은 속도를 처리합니다. 각 계층은 서로 다른 역할을 수행하며, 이들을 혼합하는 것이 시스템을 취약하게 만드는 원인이 됩니다.

제어 평면 평가하기

에이전트 제어 플랫폼을 살펴보고 있다면, 다음을 질문하십시오:

• 다중 런타임 (runtimes)을 추상화하는가? 하나의 API를 통해 Claude Managed Agents, Cursor, Bedrock 및 커스텀 런타임에서 에이전트를 호출할 수 있는가?
• 세션을 내구성 있게 유지하는가? 에이전트 세션이 포드 (pod) 재시작, 클라우드 리전 페일오버 (cloud region failover), 또는 모델 교체 시에도 유지될 수 있는가?
• 재배포 없이 거버넌스를 강제할 수 있는가? 아무것도 재시작하지 않고 에이전트 권한, 예산, 또는 도구 액세스 (tool access)를 변경할 수 있는가?
• 에이전트가 수행한 작업을 감사 (audit)할 수 있는가? 전체 결정 경로, 도구 호출, 지출 귀속, 그리고 누가 무엇을 승인했는지 확인할 수 있는가?
• 빠른 데이터 평면과 통합되는가? 밀리초 미만 (sub-millisecond)의 오버헤드가 필요할 때, 제어 평면이 최적화된 게이트웨이 인프라와 함께 작동하는가?

처음 세 가지는 기본 요건 (table-stakes)입니다. 마지막 항목은 확장 가능한 시스템과 결국 한계에 부딪히는 시스템을 구분 짓는 요소입니다.

작동하는 아키텍처

프로덕션 환경에서 나타나고 있는 패턴은 다음과 같습니다:

개발자 → 제어 평면 (세션, 거버넌스, 감사) → 런타임 추상화 (Runtime Abstraction)
                                    ↓
                           빠른 데이터 평면 (Fast Data Plane)
...

제어 평면은 대개 Python 또는 Go로 작성됩니다 (원시적인 속도보다는 유연성이 필요하기 때문입니다). 제어 평면은 상태 변이 (state mutations), 정책 강제 (policy enforcement), 멀티 테넌트 격리 (multi-tenant isolation) 등 10ms의 지연 시간이 미미한 모든 작업을 처리합니다.

데이터 평면 (data plane)은 보통 Rust 또는 Go로 작성됩니다 (속도와 메모리 효율성이 필요하기 때문입니다). 이는 모델 라우팅 (model routing), 폴백 (fallbacks), 속도 제한 (rate limiting), 비용 귀속 (cost attribution) 등 1ms 미만의 지연 시간이 누적되는 모든 작업인 핫 패스 (hot path)를 처리합니다.

두 계층은 동일한 설정 (config) 및 동일한 데이터 소스와 통신합니다. 중복도 없고, 상태 불일치 (state divergence)도 없습니다.

이것이 바로 여러 런타임 (runtimes), 여러 리전 (regions), 여러 팀 환경에서 운영되며 규제 제약 조건 하에 에이전트를 실행하는 팀들이 실제로 운영하는 방식입니다.

LiteLLM의 역할

LiteLLM은 역사적으로 게이트웨이 (100개 이상의 LLM 제공업체에 대한 빠른 라우팅)로 알려져 왔습니다. 하지만 이 회사의 최근 행보는 두 계층을 모두 구축하고 있음을 보여줍니다:

• LiteLLM Agent Platform: 멀티 런타임 에이전트 오케스트레이션 (orchestration), 세션 관리 (session management) 및 거버넌스 (governance)를 위한 Rust 기반의 컨트롤 플레인 (control plane)
• LiteLLM-Rust: 에이전트 워크로드 (workloads)를 위한 빠른 데이터 평면 (sub-1ms 오버헤드, Python 대비 15배의 처리량 향상)
• LiteLLM core: 두 계층이 모두 의존하는 게이트웨이 지능 (라우팅, 폴백, 비용 추적)

설계는 명확합니다: 거버넌스를 위한 컨트롤 플레인 (Agent Platform), 속도를 위한 데이터 평면 (LiteLLM-Rust), 그리고 두 계층 모두 100개 이상의 제공업체 지원을 바탕으로 합니다.

여러 런타임에서 에이전트를 실행하며 거버넌스와 속도가 모두 필요한 경우, 이러한 분리를 이해할 가치가 있습니다. 이는 단순히 하나의 도구를 선택하는 문제가 아닙니다. 여러분의 인프라가 실제로는 단순한 게이트웨이에 불과하면서 컨트롤 플레인인 척하거나, 그 반대의 상황이 발생하지 않도록 보장하는 것에 관한 문제입니다.

컨트롤 플레인을 건너뛸 때 발생하는 실제 비용

제가 현장에서 목격하는 대부분의 프로덕션 에이전트 실패는 모델의 능력이나 하네스 (harness) 설계의 문제가 아닙니다. 그것은 바로 컨트롤 플레인 인프라의 부재 때문입니다:

• 세션이 유지되지 않습니다; 에이전트가 재시작된 후 컨텍스트 (context)를 다시 탐색해야 합니다
• 비용 거버넌스 (cost governance)가 강제되지 않습니다; 도구 (tool) 사용이 많은 에이전트가 예상치 못하게 5,000달러를 소모할 수 있습니다
• 액세스 제어 (access controls)가 무분별하게 퍼져 있습니다; 개발자가 권한이 없는 콘솔에 직접 접근할 수 있습니다
• 관측성 (observability)이 파편화되어 있습니다; 무슨 일이 일어났는지 이해하려면 세 개의 서로 다른 대시보드를 확인해야 합니다
• 감사 (auditing)가 불가능합니다; 변조 방지 추적 (tamper-evident trail)이 없기 때문에 컴플라이언스 (compliance) 검토에서 실패합니다

이것들은 해결 가능한 문제들입니다. 하지만 프레임워크 (frameworks)와 런타임 (runtimes) 수준을 넘어서는 인프라가 필요합니다.

그것이 바로 4계층 스택입니다. 만약 당신이 단순히 자신만을 위해서가 아니라 팀을 위해 에이전트를 구축하고 있다면, 당신은 이미 이 문제에 대한 비용을 치르고 있습니다. 문제는 당신이 이를 체계적으로 수행하고 있는지, 아니면 임시방편 (ad hoc)으로 처리하고 있는지입니다.

당신의 에이전트 인프라 요구사항을 이해하고 싶으신가요? 위의 평가 질문들이 좋은 시작점이 될 것입니다. 만약 여러 런타임에서 에이전트를 실행하거나 팀을 위해 에이전트를 관리하고 있다면, 컨트롤 플레인 (control plane)의 공백은 아마 당신이 이미 맞닥뜨린 문제일 것입니다.