BoxAgnts Runtime (5) — MCP는 시작일 뿐이며, 중요한 것은 런타임 계층이다

MCP (Model Context Protocol)의 등장은 AI 생태계의 주요 이정표를 기록했습니다. 처음으로 업계가 도구 상호작용을 위한 공유 인터페이스를 중심으로 수렴하고 있습니다. 즉, 모델이 도구를 발견하고, 기능을 호출하며, 컨텍스트를 교환하고, 외부 시스템과 통신하는 방식을 표준화하고 있는 것입니다.

하지만 MCP는 더 큰 아키텍처적 격차를 드러내기도 합니다. MCP는 프로토콜(Protocol) 문제를 해결할 뿐, 런타임(Runtime) 문제를 해결하지는 못합니다. 그리고 런타임 문제는 점점 더 중요해지고 있습니다.

프로토콜은 런타임이 아니다

MCP는 도구 발견, 호출 및 리소스 관리를 정의함으로써 통신을 표준화합니다. 이는 가치 있는 일입니다. 하지만 프로토콜은 "시스템이 어떻게 통신하는가"를 정의할 뿐, "시스템이 어떻게 안전하게 실행되는가"를 정의하지는 않습니다.

비유하자면, HTTP는 웹 통신을 표준화했지만 애플리케이션 격리(Isolation), 런타임 거버넌스(Governance), 리소스 스케줄링(Resource Scheduling) 또는 실행 보안(Execution Security) 문제를 해결하지는 않았습니다. 그것들은 운영체제(Operating Systems)와 런타임의 책임입니다.

BoxAgnts의 MCP 구현은 이러한 계층 구조를 구현하고 있습니다. boxagnts/mcp/src/lib.rs는 JSON-RPC 2.0 메시지 형식, initialize/initialized 핸드셰이크(Handshake), tools/list 발견, tools/call 실행, stdio 및 HTTP/SSE 전송(Transport)과 같은 모든 프로토콜 수준의 로직을 처리합니다:

// MCP 클라이언트 연결
pub async fn connect_stdio(config: &McpServerConfig) -> anyhow::Result<Self> {
    let backend = RmcpClientBackend::connect_stdio(config).await?;
...

하지만 주의해야 할 점은, MCP 클라이언트는 "도구를 호출하고 결과를 가져오는 것"에 대해서만 책임을 진다는 것입니다. "이 도구가 호출되어야 하는지" 또는 "어떤 제약 조건 하에서 호출이 실행되어야 하는지"에 대해서는 책임이 없습니다. 그 책임은 런타임 계층(Runtime Layer)에 있습니다.

현재의 에이전트 스택은 불완전하다

대부분의 AI 시스템 아키텍처는 다음과 같은 형태를 띱니다:

LLM → 프롬프트 프레임워크 (Prompt Framework) → 도구 호출 프로토콜 (Tool Calling Protocol) → 호스트 실행 (Host Execution)

중간에 한 계층이 빠져 있습니다: 바로 **런타임 인프라(Runtime Infrastructure)**입니다. 이 계층은 실행 격리(Execution Isolation), 기능 경계(Capability Boundaries), 리소스 제약(Resource Constraints), 상태 지속성(State Persistence) 및 실행 관측성(Execution Observability)을 책임집니다.

BoxAgnts의 전체 스택은 이러한 계층 구조를 명확하게 보여줍니다:

LLM (api/ layer)
  ↓
Gateway / Query (gateway/ + query/)
...

MCP는 도구 인터페이스 (Tool Interface) 계층과 나란히 위치합니다. MCP는 외부 도구를 에이전트의 도구 세트(toolkit)로 가져오지만, 근본적인 실행 격리 (execution isolation)를 변경하지는 않습니다. BoxAgnts에서 MCP 도구는 McpToolWrapper를 통해 등록됩니다:

// boxagnts/gateway/src/api/mcp.rs
pub struct McpToolWrapper {
    pub tool_def: ToolDefinition,
...

MCP 도구가 연결되면, 이들은 네이티브 도구와 동일한 Tool 트레이트 (trait) 인터페이스를 사용합니다. 하지만 이들의 실행은 BoxAgnts의 WASM 샌드박스 (sandbox) 보호 구역 외부인 원격 MCP 서버에서 발생합니다. 이는 명확한 인식이 필요한 보안 경계 (security boundary)의 차이입니다.

도구 호출 (Tool Calling) ≠ 도구 실행 (Tool Execution)

MCP는 도구 호출 (tool calling)을 표준화합니다. 즉, 모델이 도구 이름, 구조화된 인자 (arguments), 그리고 실행 요청을 선택하는 과정입니다. 하지만 더 어려운 문제들은 호출 이후에 발생합니다. 도구가 어떤 권한을 부여받는가? 어떤 파일에 접근할 수 있는가? 어떤 네트워크 엔드포인트 (endpoints)가 허용되는가? 리소스는 어떻게 제한되는가? 실행은 어떻게 격리되는가? 동작은 어떻게 감사 (audited)되는가?

이것들은 런타임 (runtime) 관련 사항들입니다. MCP는 이에 대해 답할 수 없습니다. BoxAgnts는 MCP 도구와 네이티브 WASM 도구를 동일한 인터페이스 계층 아래에 두지만, 그 실행 경로를 구분합니다:

• WASM 도구: RunOption에 의해 완전히 제한된 상태로 Wasmtime 샌드박스 내부에서 실행됩니다.
• MCP 도구: McpToolWrapper를 통해 위임됩니다. 신뢰 경계 (trust boundary)는 MCP 서버 그 자체입니다.

이는 MCP 도구의 보안이 MCP 서버 제공자의 구현 품질에 달려 있음을 의미합니다. 만약 MCP 서버가 샌드박싱 (sandboxing)을 수행하지 않는다면, 해당 도구 호출은 호스트에서 직접 실행되는 것과 동일합니다.

AI 에이전트에게 런타임 격리 (Runtime Isolation)가 필요한 이유

전통적인 소프트웨어는 이미 애플리케이션이 실패할 수 있고, 의존성(dependencies)이 침해될 수 있으며, 프로세스가 예기치 않게 동작할 수 있음을 가정합니다. 이것이 컨테이너(containers), VM(가상 머신), 그리고 프로세스 경계(process boundaries)가 존재하는 이유입니다. AI 에이전트는 이보다 더 심각한 문제에 직면합니다. LLM(대규모 언어 모델) 기반 시스템은 프롬프트 주입(prompt injection), 적대적 문서(adversarial documents), 그리고 조작된 컨텍스트(manipulated context)에 노출됩니다.

BoxAgnts의 Connection Manager (boxagnts/mcp/src/connection_manager.rs)는 MCP 연결조차 거버넌스(governance)가 필요함을 보여줍니다:

pub async fn connect_all(&self) -> anyhow::Result<()> {
    for name in names {
        if let Err(e) = self.connect(&name).await {
...

연결 실패는 격리된 상태로 처리됩니다. 즉, 하나의 MCP 서버가 다운되어도 다른 서버에는 영향을 미치지 않습니다. 이는 당연해 보이지만, 많은 에이전트 프레임워크에는 이 정도의 계층조차 존재하지 않습니다.

업계가 잘못된 계층을 먼저 표준화했다

현재의 생태계는 모델 인터페이스, 도구 프로토콜(tool protocols), 프롬프트 형식, 그리고 오케스트레이션 프레임워크(orchestration frameworks)를 표준화하는 데 막대한 투자를 하고 있습니다. 이것들은 유용하지만, 역사는 인프라가 궁극적으로 인터페이스가 아닌 실행(execution)에 의해 제약받는다는 것을 보여줍니다.

웹이 확장될 수 있었던 것은 단순히 HTTP 때문만이 아닙니다. 운영 체제(operating systems), 프로세스 격리(process isolation), 컨테이너 오케스트레이션(container orchestration), 런타임 환경(runtime environments), 그리고 스케줄링 시스템(scheduling systems) 덕분에 확장되었습니다. AI 인프라 역시 다르지 않습니다. 도구 프로토콜은 필요조건이지만 충분조건은 아닙니다. 궁극적인 핵심 차별화 요소는 도구 호출 구문(tool invocation syntax)이 아니라 런타임 신뢰성(runtime reliability)입니다.

BoxAgnts의 아키텍처는 이를 예견했습니다. 프로토콜 계층(MCP)은 상위에 위치하고, 런타임 계층(WASM Sandbox)은 하위에 위치합니다. 새로운 도구는 프로토콜을 통해 발견될 수 있지만, 실행 제약 조건은 런타임에 의해 일관되게 제어됩니다.

런타임 엔지니어링: 부상하는 인프라 전문 분야

신뢰할 수 있는 AI 시스템에는 결정론적 실행(deterministic execution), 명시적 권한(explicit permissions), 샌드박스화된 도구(sandboxed tooling), 거버넌스가 적용된 오케스트레이션(governed orchestration), 제한된 부수 효과(bounded side effects), 리소스 계정(resource accounting), 그리고 실행 관측성(execution observability)이 필요합니다. 이는 프롬프트 엔지니어링(prompt engineering)의 범위를 훨씬 뛰어넘는 영역입니다.

BoxAgnts는 다음과 같은 몇 가지 핵심 모듈을 통해 이러한 방향성을 구현합니다:

• boxagnts/wasm-sandbox/: 실행 격리 (Execution isolation) 및 권한 제약 (capability constraints)
• boxagnts/tools/: 도구 인터페이스 (Tool interface) 및 권한 모델 (permission model)
• boxagnts/gateway/cron/: 예약된 작업 실행 거버넌스 (Scheduled task execution governance)
• boxagnts/workspace/: 상태 지속성 (State persistence) 및 관리

미래의 AI 스택은 다음과 같아야 합니다:

LLM
  ↓
Protocol Layer (MCP)
...

MCP는 여전히 매우 중요합니다

위의 내용 중 그 어떤 것도 MCP의 가치를 떨어뜨리지 않습니다. 오히려 그 반대입니다. 표준화된 프로토콜은 런타임 (runtime) 혁신을 더 쉽게 만듭니다. 공유된 도구 인터페이스는 이식 가능한 런타임 (portable runtimes), 교체 가능한 오케스트레이션 시스템 (interchangeable orchestration systems), 그리고 표준화된 권한 주입 (standardized capability injection)을 가능하게 합니다.

프로토콜은 통합을 단순화합니다. 런타임은 동작을 강제합니다. 두 계층 모두 중요하지만, 이 둘을 혼동해서는 안 됩니다.

결론

MCP는 모델이 외부 시스템과 통신하는 방식을 표준화하며, 이는 중요한 이정표입니다. 하지만 통신은 문제의 절반에 불과합니다. 더 어려운 과제는 실행 안전성 (execution safety)입니다. 에이전트 (agents)가 운영 권한을 갖게 됨에 따라, 프로덕션 시스템에는 런타임 격리 (runtime isolation), 권한 거버넌스 (capability governance), 결정론적 실행 (deterministic execution), 그리고 샌드박스화된 도구 (sandboxed tooling)가 필요합니다.

이제 핵심 질문은 "모델이 도구를 호출할 수 있는가?"가 아니라, "시스템이 안전하게 실행될 수 있는가?"입니다.

리소스

• BoxAgnts: https://github.com/guyoung/boxagnts