당신의 에이전트 프레임워크가 충분하지 않은 이유: 컨트롤 플레인 (Control Plane) 대 로직 레이어 (Logic Layer)의 분리

만약 당신이 2026년 7월에 프로덕션용 AI 에이전트를 구축하고 있다면, 아마도 수천 개의 팀이 현재 직면하고 있는 바로 그 벽 앞에 서 있을 것입니다.

당신은 LangGraph, CrewAI 또는 다른 프레임워크를 선택했습니다. 에이전트를 출시했습니다. 데모에서는 잘 작동합니다. 하지만 프로덕션 단계에 들어서면 상황이 달라집니다. 당신의 에이전트는 세 개의 서로 다른 런타임 (runtime)에 걸쳐 도구 (tools)를 호출해야 합니다. 에이전트별 예산 설정이 필요합니다. 보안 팀은 감사 추적 (audit trails)을 요구합니다. 정책에 따라 일부 요청은 Claude로, 다른 요청은 Gemini로 라우팅하고 싶습니다. 동료의 에이전트가 상태 (state)를 잃지 않고 당신의 에이전트에게 컨텍스트 (context)를 전달해야 합니다.

갑자기, 당신의 프레임워크가... 불충분하게 느껴집니다. 고장 난 것은 아닙니다. 단지 불완전할 뿐입니다.

그 이유는 다음과 같습니다: 2026년의 모든 주요 에이전트 프레임워크는 잘못된 문제를 해결하고 있습니다.

프레임워크가 실제로 해결하는 것

LangGraph, CrewAI, Microsoft Agent Framework, OpenAI Agents SDK, Pydantic AI—이들은 모두 **에이전트 로직 (agent logic)**을 해결합니다: 상태 그래프 (state graphs), 도구 호출 (tool calling), 멀티 에이전트 조정 (multi-agent coordination), 스트리밍 (streaming), 휴먼 체크포인트 (human checkpoints). 이 분야에서는 매우 뛰어납니다.

하지만 이들이 해결하지 못하는 것은 **에이전트 인프라 (agent infrastructure)**입니다: 멀티 런타임 조정 (multi-runtime coordination), 에이전트별 신원 (per-agent identity), 호출 레이어 정책 집행 (invocation-layer policy enforcement), 프레임워크 경계를 넘나드는 세션 지속성 (session persistence), 통합 관측성 (unified observability), 그리고 예산 추적 (budget tracking)입니다.

규모가 커지면 이 격차는 중요해집니다. 하나의 런타임에서 작동하는 하나의 에이전트는 괜찮습니다. 두 개의 런타임에 걸친 두 개의 에이전트는 당신이 조정을 수동으로 관리하는 한 작동합니다. 서로 다른 팀이 접근하는 세 개의 런타임에 걸친 다섯 개의 에이전트는 프레임워크가 단순히 제공하지 못하는 인프라를 필요로 합니다.

이것이 바로 2026년 에이전트 인프라 담론이 서로 협력해야 하지만 동일한 것은 아닌 두 부분으로 나뉜 이유입니다.

3계층 패턴 (The Three-Layer Pattern)

2026년 7월의 프로덕션 에이전트 인프라는 세 가지 뚜렷한 레이어로 수렴합니다:

레이어 1: 에이전트 로직 (Agent Logic) (프레임워크 영역)

상태 그래프 (State graphs), 추론 루프 (reasoning loops), 다단계 계획 (multi-step planning)
도구 정의 (Tool definitions) 및 호출 로직 (invocation logic)
인간 참여 (Human-in-the-loop) 체크포인트
스트리밍 (Streaming), 재시도 (retries), 에러 처리 (error handling)
예시: LangGraph, CrewAI, Microsoft Agent Framework

레이어 2: 컨트롤 플레인 (Control Plane) (인프라 영역)

프레임워크 재시작 시에도 유지되는 세션 지속성 (Session persistence)
에이전트별 고유 식별 정보 (공유 자격 증명이 아님)
호출 레이어 정책 강제 (Invocation-layer policy enforcement) (어떤 에이전트가 어떤 도구를 호출할 수 있는지)
런타임 전반에 걸친 통합 세션 쿼리 (Unified session querying)
단계별 비용 귀속 (Cost attribution)
컴플라이언스를 위한 감사 추적 (Audit trails)
호출 시점의 자격 증명 범위 제한 (Credential scoping)
멀티 런타임 메모리 조정 (Multi-runtime memory coordination)
예시: LiteLLM Agent Platform, Temporal (내구 실행용), 커스텀 컨트롤 플레인

레이어 3: 데이터 플레인 (Data Plane) (인프라 영역)

LLM 제공업체로의 빠른 라우팅 (Fast routing)
제공업체 API 간의 요청 변환 (Request translation)
토큰당 비용 추적 (Cost tracking)
부하 분산 (Load balancing) 및 장애 조치 (failover)
저지연 서빙 (Low-latency serving) (1ms 미만의 오버헤드)
예시: LiteLLM-Rust, Bifrost, Portkey (게이트웨이로서)

여기서 핵심적인 통찰은 다음과 같습니다: 이들은 서로 같은 것이 아니며, 레이어 1에 기능을 덧붙이는 방식으로는 레이어 2를 구축할 수 없습니다.

왜 이들을 결합할 수 없는가

프레임워크는 결정론적 제어 흐름 (deterministic control flow)과 명시적 상태 관리 (explicit state management)에 탁월합니다. 프레임워크는 프로그래밍 가능하도록 설계되었습니다. 사용자가 노드 (nodes), 엣지 (edges), 조건 (conditions)을 정의하면 프레임워크가 해당 DAG (Directed Acyclic Graph)를 실행합니다.

컨트롤 플레인은 정책 강제 (policy enforcement)와 거버넌스 (governance)에 탁월합니다. 컨트롤 플레인은 에이전트 로직에 외부적으로 존재하는 제약 사항들을 관리합니다: "에이전트 A는 데이터베이스 도구를 호출할 수 없음", "에이전트 B의 예산은 시간당 $10임", "모든 도구 호출은 컴플라이언스를 위해 불변적으로 로그에 기록되어야 함". 이러한 제약 사항들은 에이전트 내부의 로직이 아니라, 에이전트에 대한 메타데이터입니다.

프레임워크에 컨트롤 플레인 기능을 추가하는 것(예를 들어, CrewAI가 "프롬프트를 통한 에이전트 예산 설정" 기능을 추가하는 것)은 두 가지 문제를 야기합니다:

프롬프트 레이어(Prompt layer)에서는 정책(Policy)을 신뢰할 수 없습니다. 에이전트는 시스템 프롬프트(System prompt)를 우회하여 작동하는 법을 배웁니다. 결심이 확고하거나 잘못 설정된 에이전트는 여전히 예산을 낭비하거나, 승인되지 않은 도구(Tool)를 호출하거나, 감사 로깅(Audit logging)을 건너뛸 수 있습니다. 방어할 수 없는 정책은 강제할 수 없습니다.
모든 사용자에게 프레임워크의 속도를 저하시킵니다. 만약 모든 도구 호출(Tool call)이 권한 확인을 위해 데이터베이스 조회(Database lookup)를 트리거하고, 모든 모델 응답이 정책 위반 여부를 평가받으며, 모든 에이전트 단계가 전체 트레이싱(Tracing)과 함께 Postgres에 기록된다면—당신은 방금 빠르고 가벼운 오케스트레이터(Orchestrator)를 무거운 시스템으로 바꿔버린 것입니다. 프레임워크가 고통받게 됩니다.

명확한 해답은 이것입니다: 이들을 분리하십시오. 프레임워크는 오케스트레이션(Orchestration)을 잘하도록 두고, 컨트롤 플레인(Control plane)은 거버넌스(Governance)를 잘하도록 두십시오. 명확한 API를 통해 이들을 연결하십시오.

실제 적용 사례

Claude Code, Cursor, OpenCode를 사용하여 프로덕션 환경에 5개의 코딩 에이전트를 배포하는 팀의 모습은 다음과 같을 것입니다:

Claude Code (에이전트 런타임)
    ↓
LiteLLM Agent Platform (컨트롤 플레인)
...

프레임워크(이 경우 Claude Code, Cursor, OpenCode)는 컨트롤 플레인에 대해 알 필요가 없습니다. 프레임워크는 게이트웨이(Gateway)를 통해 도구를 호출합니다. 컨트롤 플레인은 모든 호출을 가로채서 권한을 확인하고, 이를 기록하며, 예산을 추적하고, 호출 허용 여부를 결정합니다. 데이터 플레인(Data plane)은 이를 효율적으로 라우팅(Routing)합니다.

새로운 에이전트(Bedrock)를 추가해야 하는 경우, 프레임워크 코드를 다시 작성할 필요가 없습니다. 컨트롤 플레인에 새로운 런타임(Runtime)을 추가하고 권한을 설정하면 끝납니다.

정책을 변경해야 하는 경우(에이전트 A의 데이터베이스 액세스 권한 취소), 코드를 다시 배포할 필요가 없습니다. 컨트롤 플레인에서 정책을 업데이트하기만 하면 됩니다. 즉각적입니다.

이것이 바로 프로덕션 에이전트 인프라가 이제 하나의 프레임워크가 아닌 세 개의 레이어(Layer)로 구성되는 이유입니다.

이것이 당신의 평가에 중요한 이유

만약 지금 에이전트 플랫폼을 비교하고 있다면, 다음 사항을 확인하십시오:

프레임워크가...

에이전트 로직 및 오케스트레이션 (Orchestration)을 처리하는가? ✓ (모두 이를 잘 수행합니다)
재시작 시에도 에이전트 세션을 내구성 있게 유지(Persist)하는가?
공유 자격 증명 없이 에이전트별 고유 식별(Identity)을 강제하는가?
재배포 없이 정책 변경을 허용하는가?
다양한 런타임 (Claude, Gemini, Bedrock, 로컬 모델)을 지원하는가?
도구 호출 (Tool call)별로 불변의 감사 추적 (Immutable audit trails)을 제공하는가?
호출 레이어 (Invocation layer)에서 에이전트별 예산을 추적하는가?

만약 2번에서 7번까지의 답변이 "아니오"라면, 해당 프레임워크는 프로덕션(Production) 환경에 사용하기에 불완전합니다. 직접 컨트롤 플레인 (Control plane)을 구축하거나 (약 3~6개월의 엔지니어링 기간이 소요될 것으로 예상하십시오), 이러한 보장 기능을 제공하는 인프라와 결합해야 합니다.

운영을 잘하는 팀은 가장 똑똑한 프레임워크를 사용하는 팀이 아닙니다. 그들은 밑단에 가장 지루할 정도로 안정적인 인프라를 갖춘 팀입니다.

당신이 목격하고 있는 패턴

LangGraph는 2026년 초, 기업 도입과 감사 추적 (Audit trails) 및 롤백 지점 (Rollback points)과 같은 프로덕션 요구 사항에 깔끔하게 매핑되는 그래프 기반 아키텍처에 힘입어 GitHub 스타 수에서 CrewAI를 추월했습니다. 이는 LangGraph가 더 나은 오케스트레이터이기 때문이 아닙니다. LangGraph의 명시적인 상태 그래프 (State graph) 덕분에 컨트롤 플레인과 결합하기가 더 쉽기 때문입니다. 즉, 상태가 가시적이고 추적 가능하며 감사가 가능합니다.

프로덕션 팀은 또한 내구성 (Durability), 승인 경로 (Approval paths), 감사 증거 (Audit evidence), 그리고 장애 복구 (Failure recovery)를 비교해야 합니다. 대부분의 비교 페이지는 API 형태에서 멈춥니다. 가장 비용이 많이 드는 실수는 출시 후에 발생합니다: 통제 불능의 도구 호출 (Runaway tool calls), 승인 누락, 불분명한 소유권, 그리고 불완전한 감사 타임라인 등이 그것입니다. 에이전트의 행동을 위해서는 에이전트 프레임워크를 사용하십시오. 하지만 자율 에이전트가 프로덕션 시스템에 접촉하기 전에는 에이전트 컨트롤 플레인 (Agent Control Plane)을 추가하십시오.

이것이 정확한 패턴입니다. 프레임워크는 필요합니다. 컨트롤 플레인 또한 필요합니다. 이 둘을 혼동하는 것이 바로 에이전트 프로젝트가 정체되는 이유입니다.

올바르게 구축하기

만약 당신이 지금 에이전트를 구축하고 있다면:

당신의 로직에 맞는 프레임워크를 선택하세요. 만약 당신의 에이전트들이 자연스럽게 전문가 팀(teams of specialists) 형태로 매핑된다면 CrewAI가 좋습니다. 재시도 로직(retry logic)과 인간의 체크포인트(human checkpoints)를 포함한 복잡한 제어 흐름(control flow)이 필요하다면 LangGraph가 견고합니다. 너무 깊게 고민하지 마세요. 프레임워크는 쉬운 부분입니다.
첫날부터 컨트롤 플레인 (Control Plane)을 계획하세요. 프로토타이핑 단계일지라도 다음 사항들을 고민해야 합니다: 에이전트별 ID(identity)를 어떻게 처리할 것인가? 자격 증명(credentials)은 어디에 저장되는가? 어떤 감사 추적(audit trails)이 필요한가? 재배포 없이 정책(policies)을 변경할 수 있는가?
컨트롤 플레인을 별도로 평가하세요. LiteLLM Agent Platform이 한 가지 예시입니다. 이는 세션 기반(session-based), 멀티 런타임(multi-runtime), Postgres 기반(Postgres-backed)으로 작동합니다. 어떤 팀들은 자체적으로 구축하기도 하고, 어떤 팀들은 Temporal(내구 실행(durable execution)을 위한 도구)과 같은 인프라를 사용하기도 합니다. 핵심은 이것입니다: 그것이 당신에게 필요한 거버넌스(governance) 보장을 제공하는가?
빠른 데이터 플레인 (Data Plane)과 결합하세요. 에이전트가 3개 이상이거나 동시 세션이 100개를 넘어가면, 데이터 플레인의 지연 시간(latency)이 중요해집니다. 정책 확인(policy checks)이 에이전트의 작업을 느리게 만들지 않도록 1ms 미만의 오버헤드(overhead)를 유지해야 합니다.

프로덕션 환경에서 승리하는 에이전트는 가장 많은 능력을 갖춘 에이전트가 아닙니다. 로직(logic)과 인프라(infrastructure) 사이의 분리가 가장 명확하며, 각 구성 요소가 하나의 작업만을 맡아 제대로 수행하는 에이전트입니다.

이것은 2026년 7월 팀들이 발견하고 있는 운영상의 현실입니다. 만약 당신의 에이전트 프레임워크가 무언가 부족하다고 느껴진다면, 당신의 생각이 맞을 가능성이 높습니다. 그리고 부족한 것은 프레임워크 안에 있는 것이 아니라, 당신이 아직 구축하지 않은 컨트롤 플레인에 있습니다.

Insights