에이전트 아키텍처가 어디로 나아가고 있는지 이해하기 쉬운 방법

현재 세대의 에이전트 시스템은 이미 여러 어려운 문제들을 해결하고 있습니다.

에이전트는 Model Context Protocol (MCP)을 통해 도구를 호출할 수 있습니다. Agent2Agent Protocol (A2A)을 통해 다른 에이전트와 통신할 수 있습니다. 샌드박스를 거쳐 격리된 워크로드를 실행하거나, 점차 휴대성이 높아지는 WebAssembly 컴포넌트를 활용할 수 있습니다. 또한 분산 트레이스를 전파하고, 원격 신원을 인증하며, 도구 실행 전후에 정책을 적용할 수 있습니다.

이것들은 중요한 발전입니다.

하지만 이 모든 메커니즘 사이에는 간극이 존재합니다.

이것들은 에이전트가 어떻게 통신하는지, 어떻게 기능을 발견하는지, 어떻게 도구를 호출하는지, 그리고 소프트웨어가 어떻게 실행되는지를 알려줍니다. 하지만 아직 더 근본적인 질문에 답하기 위한 충분히 강력한 공통 시맨틱 모델을 제공하지는 못합니다.

바로 «실행되고 있는 대상이 정확히 무엇인가?»라는 질문입니다.

본 글은 이 문제를 의도적으로 단순하게 소개한 후, 보다 공식적인 아키텍처의 기술적 기반을 정의합니다.

목표는 MCP, A2A, WebAssembly 또는 기존 에이전트 런타임을 대체하는 것이 아닙니다. 목표는 그 위에 존재할 수 있는 레이어를 설명하는 것입니다.

1. 오늘날 우리가 에이전트를 구축하는 방법

단순화된 에이전트 애플리케이션은 대략 다음과 같은 형태를 가집니다:

User
|
v
LLM Agent
|
+----> Tool
|
+----> API
|
+----> Database
|
+----> Another Agent

LLM은 요청을 받고, 무엇을 할지 결정하며, 하나 이상의 도구를 호출하고, 그 결과를 받아 최종적으로 답변을 생성합니다.

현대적인 프레임워크들은 이를 훨씬 더 정교하게 만듭니다. 다음과 같은 것들이 있을 수 있습니다:

• 도구 레지스트리(tool registries);
• 메모리(memory);
• 플래너(planners);
• 서브 에이전트(sub-agents);
• 재시도(retries);
• 워크플로우 엔진(workflow engines);
• 트레이싱(tracing);
• 인가(authorization);
• 가드레일(guardrails);
• 인간 승인(human approval);
• 지속적 실행(durable execution);
• 샌드박스 코드 실행(sandboxed code execution).

문제는 업계에 인프라가 부족하다는 것이 아닙니다. 문제는 이러한 기능들이 종종 서로 다른 아키텍처 레벨에서 설명된다는 것입니다.

예를 들어:

MCP → 에이전트가 도구와 통신하는 방식

A2A → 에이전트가 에이전트와 통신하는 방식

WASM → 이식 가능한 코드가 실행되는 방식

Tracing → 실행이 관찰되는 방식

Policy → 행동이 허용되거나 거부되는 방식

Workflow → 실행 단계가 조정되는 방식

이 모든 것은 유용합니다.

하지만 어느 것도 개별적으로 다음 질문에 답하지 못합니다:

사용자의 실제 의도는 무엇이었는가?
어떤 행동이 그것을 충족시키기 위해 선택되었는가?
그 행동을 수행할 권한이 있는 행위자는 누구인가?
정확히 어떤 행동이 실행되었는가?
어떤 상태 전환이 발생했는가?
왜 그 결과가 수락된 것으로 간주되어야 하는가?
무슨 증거가 무슨 일이 일어났는지 증명하는가?

이것이 AllasCode가 해결하려는 격차입니다.

1. 첫 번째 비유: HTTP는 비즈니스 의미를 정의하지 않았다

유용한 비유는 웹의 진화 과정입니다.
HTTP는 우리가 어떻게 통신해야 하는지를 알려줍니다.
하지만 은행 송금이 무엇을 의미하는지는 알려주지 않습니다.
예를 들어:

POST /transfer

은 은행 송금 요청을 전송할 수 있습니다. 하지만 HTTP는 다음을 정의하지 않습니다:

누가 돈을 이체할 권한이 있는지
유효한 이체를 구성하는 것이 무엇인지
어떤 계정 상태가 존재해야 하는지
어떤 원장(ledger) 전환이 발생해야 하는지
송금이 최종적으로 확정되는 시점은 언제인지
이체가 일어났음을 증명하는 증거는 무엇인지

이러한 의미론적 정보들은 더 높은 계층에 속합니다.
동일한 구분이 에이전트 시스템에서도 존재합니다.
MCP와 A2A는 인프라 프로토콜과 유사해지고 있습니다.
MCP는 도구, 리소스, 프롬프트, 유도(elicitation), 샘플링, 알림 및 권한 부여를 포함하여 클라이언트와 서버 간의 표준화된 상호 작용 모델을 정의합니다. 현재 사양은 MCP를 상태 비저장(stateless)으로 명시적으로 설명합니다: 요청을 처리하는 데 필요한 정보는 해당 요청에 존재해야 하며, 장기적인 상태는 연결 상태가 아닌 명시적 식별자를 통해 표현됩니다.

A2A는 보완적인 에이전트-대-에이전트 계층을 제공합니다.

공식 문서는 MCP를 에이전트-대-도구/컨텍스트(agent-to-tool/context) 통신으로, A2A를 에이전트-대-에이전트(agent-to-agent) 통신으로 명확히 구분하고 있습니다. 또한, A2A 1.0에서는 멀티테넌시(multi-tenancy), 서명된 Agent Card, 다중 프로토콜 바인딩, 폴링(polling), 스트리밍(streaming), 웹훅(webhooks)과 같은 운영 환경 지향적 기능도 도입했습니다.

이것만으로도 충분히 유용한 아키텍처입니다.

하지만 여전히 또 다른 계층이 열려 있습니다.

1. MCP는 에이전트 런타임이 아닙니다.

간단한 요청을 가정해 봅시다:

"내일 오후 8시에 테이블을 예약해 주세요."

MCP가 활성화된 에이전트는 다음과 같은 레스토랑 도구를 발견할 수 있습니다:

search_restaurants
create_reservation
cancel_reservation

에이전트는 이 도구를 호출할 수 있습니다.

MCP는 통신 문제를 해결합니다.

하지만 다음의 시맨틱 라이프사이클을 정의하지는 않습니다:

Intent (의도)
↓
Decision (결정)
↓
Authorization (권한 부여)
↓
Action (행동)
↓
Side effect (부작용)
↓
Acceptance (수락)
↓
Evidence (증거)

이러한 구분은 MCP Tasks를 통해 더욱 명확해집니다.

MCP Tasks 확장 기능은 요청 주변에 영속적인 작업 상태 기계(durable task state machines)를 정의합니다. 작업은 "working", "input_required", "completed", "failed", 또는 "cancelled" 상태일 수 있으며, 지연된 결과를 위해 작업을 폴링할 수 있습니다.

이것은 유용합니다.

하지만 이 작업 자체는 근본적으로 프로토콜 요청의 실행 상태에 불과합니다.

사용자의 의도(intention)라는 시맨틱 정의가 되는 것은 아닙니다.

이 구분은 중요합니다:

MCP Task

"프로토콜 요청이 실행되고 있음"

AllasCode Execution

"이러한 시맨틱 행동이 이 의도에 따라 이 행위자(actor)에 의해 이러한 정책 하에서 실행되고 있음"

전자는 전송/런타임 추상화입니다.

후자는 시맨틱 실행 추상화입니다.

1. A2A는 문제의 또 다른 부분을 해결합니다.

이제 예약 에이전트가 요청을 위임한다고 상상해 봅시다:

Customer Agent
|
| A2A
v
Restaurant Agent

A2A는 바로 이러한 상황을 위해 설계되었습니다.

A2A를 사용한 다양한 프레임워크와 기술 스택으로 구현된 에이전트들이 내부 메모리나 구현을 노출하지 않고도 역량을 발견하고, 통신하며, 작업을 위임하고 협업할 수 있도록 합니다.

이는 독점적인 에이전트 간(agent-to-agent) 통합 방식보다 큰 개선입니다.

하지만 다시 말해, A2A는 다음과 같은 질문에 답합니다:

«Agent A가 Agent B와 어떻게 통신할 수 있습니까?»

그러나 다음 질문에는 완전히 답하지 못합니다:

«위임되는 동작의 시맨틱 계약(semantic contract)은 무엇입니까?»

이러한 구분은 여러 에이전트가 하나의 비즈니스 프로세스에 참여할 때 중요해집니다.

예를 들어:

Customer Agent
|
v
Reservation Agent
|
v
Payment Agent
|
v
Notification Agent

원래의 의도(intent)는 누가 소유합니까?
각 행동을 수행할 권한은 누구에게 있습니까?
어떤 상태 전이(state transition)가 성공으로 간주됩니까?
결제가 성공했지만 알림이 실패하면 어떻게 됩니까?
복구(healing)에 책임이 있는 에이전트는 무엇입니까?
예약이 실제로 승인되었다는 증거는 무엇입니까?

이러한 질문들은 A2A의 범위를 넘어섭니다.

1. 누락된 비유: 비즈니스 시맨틱스(business semantics)

전통적인 분산 시스템은 도메인 모델(domain models)을 통해 이 문제를 해결했습니다.

은행 시스템이 모든 것을 다음과 같이 모델링하지는 않습니다:

HTTP Request

대신, 계좌(Account), 거래(Transaction), 권한 부여(Authorization), 원장(Ledger), 정산(Settlement)과 같은 개념을 가지고 있습니다.

마찬가지로, 전자상거래 시스템이 전체 아키텍처를 다음과 같이 정의하지는 않습니다:

POST /something

대신, 주문(Order), 결제(Payment), 배송(Shipment), 고객(Customer), 재고(Inventory), 이행(Fulfillment)을 가지고 있습니다.

에이전트 시스템은 동등한 시맨틱 레이어(semantic layer)가 필요합니다.

tool_call로 시작하는 대신, Intent로 시작할 수 있고,
전체 실행을 LLM 결정의 순서로 취급하기보다 다음과 같이 모델링할 수 있습니다:

Intent
↓
Behavior
↓
Action
↓
Actor
↓
Runtime
↓
Result
↓
Acceptance
↓
Evidence

이것이 AllasCode의 근본적인 아이디어입니다.

1. 간단한 용어로 본 AllasCode 모델

간단한 비유는 다음과 같습니다:

Intent = 무엇이 일어나야 하는가?
Behavior = 그 의도를 만족시키는 동작은 무엇인가?
Action = 그것을 수행하는 구체적인 작업은 무엇인가?
Actor = 누가/무엇이 그것을 수행할 권한이 있는가?
Runtime = 어디서, 어떤 역량 하에 실행되는가?
Result = 무슨 일이 일어났는가?
Acceptance = 일어난 것이 성공으로 간주될 만큼 충분히 좋은가?

Proof = 무슨 일이 일어났다는 것을 어떤 증거가 입증하는가?

예를 들어:

의도(Intent):
"이 고객을 등록하라."

는 다음으로 해결될 수 있다:

행동(Behavior):
고객등록(CustomerRegistration)

이는 다음으로 분해된다:

액션(Action):
고객 유효성 검사(ValidateCustomer)
액션(Action):
중복 확인(CheckDuplicate)
액션(Action):
고객 저장(PersistCustomer)
액션(Action):
고객 등록 완료 알림(EmitCustomerRegistered)

런타임은 이 액션들을 다양한 기술을 통해 실행할 수 있다:

Native Zig
WASM
MCP 툴
원격 A2A 에이전트
데이터베이스 어댑터
사람의 승인(Human approval)

구현 방식은 바뀔 수 있지만,
시맨틱 계약(semantic contract)은 바뀌지 않는다.

그것이 핵심 아이디어이다.

1. WASM이 흥미로운 이유

WebAssembly는 다른 문제를 해결하고 있다.

WebAssembly Component Model은 컴포넌트 간의 이식 가능한 인터페이스 모델을 제공하며, WASI 0.3은 다음과 같은 비동기 인터페이스를 추가한다:

async func
future
stream

이를 통해 컴포넌트 전반에 걸친 비동기 조합(asynchronous composition)이 훨씬 더 실용적이 되었다.

WASI 0.3.1은 다음과 같은 기능을 추가하여 Component Model을 더욱 보강한다:

map
implements
external-id

AllasCode에게 중요한 아이디어는 단순히 "WASM을 실행하는 것"이 아니다.

그것은 다음과 같다:

«어떤 액션이라도 그 액션의 시맨틱 계약을 변경하지 않으면서 다른 언어로 구현될 수 있다.»

예를 들어:

AllasCode 액션
"고객 저장(PersistCustomer)"
|
v
WIT
| +----+----+
| |
v v
Rust Zig
| +----+----+
|
v
same semantic Action

런타임이 역량(capabilities)을 소유한다.
컴포넌트는 임의의 네트워크, 파일 시스템 또는 운영체제 권한을 자동으로 받지 않는다.

이것이 WASM이 모델 자체가 아니라 AllasCode 액션 모델을 위한 가능한 실행 기질(execution substrate)이 되게 한다.

1. 기존 프로젝트들이 이미 이 아이디어의 일부를 구현하고 있다

AllasCode는 선례가 없는 것을 제안하는 것이 아니다.
여러 프로젝트들이 이미 중요한 부분을 해결했다.

따라서 흥미로운 질문은 다음과 같지 않다:

«

MCP는 에이전트와 도구(tool) 간, 그리고 에이전트와 리소스(resource) 간의 상호작용을 표준화합니다.

이는 이미 다음 기능을 제공합니다:

tool
resource
prompt
elicitation
sampling
authorization
tasks
notifications

그리고 점차적으로 명시적인 상태 비저장성(statelessness) 및 관측 가능성(observability) 메커니즘을 제공합니다.

AllasCode는 MCP를 바인딩으로 사용할 것입니다.

이는 MCP를 대체하지 않습니다.

AllasCode Action
|
v
MCP Adapter
|
v
MCP Server

A2A

A2A는 에이전트 간(agent-to-agent) 통신, 위임(delegation), 그리고 역량 발견(capability discovery)을 표준화합니다. 이는 특히 실행이 조직적 또는 기술적 경계를 넘나들 때 중요합니다.

AllasCode는 A2A를 또 다른 바인딩으로 사용할 것입니다:

AllasCode Behavior
|
v
A2A Adapter
|
v
Remote Agent

시맨틱(semantic) 동작은 A2A와 독립적으로 유지됩니다.

LangGraph 및 내구성 있는 에이전트 워크플로우

LangGraph 같은 프레임워크는 이미 에이전트 실행을 단일 LLM 호출보다 더 구조화된 것으로 취급합니다.

이는 상태 저장 그래프(stateful graphs), 체크포인트(checkpoints), 내구성 있는 실행(durable execution), 그리고 인간 개입 루프(human-in-the-loop) 패턴을 제공합니다.

이는 개념적으로 다음과 가깝습니다:

Behavior
↓
state transitions
↓
checkpoint
↓
resume

차이점은 AllasCode가 시맨틱 객체 자체를 특정 워크플로우 프레임워크와 독립적으로 만들려고 한다는 것입니다.

따라서 LangGraph는 시맨틱 표준 그 자체가 아니라 문제의 일부를 해결하는 구현/런타임 접근 방식으로 간주될 수 있습니다.

에이전트 런타임

현대적인 에이전트 런타임은 점점 더 다음 기능을 제공합니다:

durable state
sandboxing
tool execution
context management
sub-agents
observability
recovery

이는 산업이 다음 방향으로 이동하고 있음을 보여주기 때문에 중요합니다:

LLM API

→

Agent Runtime

AllasCode는 이 방향에 동의합니다.

차이점은 AllasCode가 한 가지 추가 질문을 던진다는 것입니다:

«시맨틱 실행의 표준 단위(canonical unit of semantic execution)로 런타임이 무엇을 고려해야 하는가?»

제안하는 바는 다음과 같습니다:

Intent → Behavior → Action

대신에:

LLM → tool call

1. 중요한 구분: 프로토콜 대 시맨틱 레이어

우리는 이제 아키텍처를 더 쉽게 이해할 수 있게 되었습니다.

인터넷을 상상해 보세요:

HTTP
TCP
IP
Ethernet

이들 중 어느 것도 다음을 정의하지 않습니다:

순서(Order)
결제(Payment)
고객(Customer)
배송(Shipment)

이들은 애플리케이션 시맨틱스(application semantics)에 속합니다.

에이전트 시스템은 이와 유사한 것을 개발하고 있습니다:

A2A
MCP
WASM
HTTP
gRPC
NATS

이들은 인프라스트럭처를 제공합니다.

AllasCode는 다음을 제안합니다:

의도(Intent)
행동(Behavior)
실행(Action)
주체(Actor)
런타임(Runtime)
결과(Result)
수용(Acceptance)
증명(Proof)

이들을 인프라스트럭처 위에 있는 시맨틱 레이어(semantic layer)로요.

따라서:

             SEMANTICS

────────────────────────────────────
의도(Intent)
행동(Behavior)
실행(Action)
주체(Actor)
런타임(Runtime)
결과(Result)
수용(Acceptance)
증명(Proof)
────────────────────────────────────
BINDINGS
A2A MCP REST NATS
────────────────────────────────────
EXECUTION
WASM Native Sandbox Remote
────────────────────────────────────
INFRASTRUCTURE
Network / OS / Database / Compute