에이전트 아키텍처가 주류가 된 해

2026년, AI 에이전트는 실험적인 데모를 넘어 프로덕션 인프라로 자리 잡았습니다. 하지만 Slack 메시지에 답변하는 데모 에이전트와 수천 개의 동시 워크플로우를 처리하는 프로덕션 시스템 사이에는 거대한 격차가 존재합니다.

프로덕션 환경에서 멀티 에이전트 시스템 (multi-agent systems)을 구축하고 배포해 온 경험을 바탕으로, 취미용 프로젝트와 엔터프라이즈급 에이전트 인프라를 구분 짓는 아키텍처 패턴을 공유하고자 합니다.

프로덕션 에이전트 아키텍처의 세 가지 기둥

제가 본 모든 프로덕션 에이전트 시스템은 세 가지 프로토콜에 의존합니다:

1. MCP (Model Context Protocol) — 에이전트와 도구 간의 통신 (Agent-to-tool communication)
2. A2A (Agent-to-Agent) — 에이전트 간의 협업 (Agent-to-agent coordination)
3. 메모리 및 상태 관리 (Memory & State Management) — 세션 전반에 걸친 지속적인 컨텍스트 (Persistent context)

각각의 요소를 자세히 살펴보겠습니다.

1. MCP: 실제로 작동하는 도구 계층

MCP (2024년 Anthropic에 의해 도입되었으며 현재 업계 표준임)는 에이전트가 외부 세계와 소통하는 방식입니다. 이를 "AI 에이전트를 위한 USB-C"라고 생각하십시오. 즉, 어떤 LLM(Large Language Model)이든 어떤 도구와도 연결할 수 있는 단일 프로토콜입니다.

MCP가 승리한 이유

• 표준 스키마 (Standard schema) — 도구가 임의의 프롬프트가 아닌 JSON Schema로 기술됩니다.
• 전송 방식에 구애받지 않음 (Transport agnostic) — stdio, HTTP SSE, WebSockets를 통해 작동합니다.
• 보안 경계 (Security boundaries) — 각 도구는 제한된 권한(scoped access)을 가지며, "에이전트가 sudo rm -rf /를 실행하는" 재앙을 방지합니다.
• 런타임 발견 (Runtime discovery) — 에이전트는 런타임에 사용 가능한 도구와 그 스키마를 나열할 수 있습니다.

프로덕션 MCP 아키텍처

┌─────────────┐     MCP stdio     ┌──────────────┐
│   Agent     │◄────────────────►│  MCP Server  │
│  (LLM +     │                  │  (Tools)     │
...

MCP를 위한 주요 프로덕션 규칙

규칙 1: 모든 도구의 범위를 제한하십시오 (Scope every tool). 에이전트에게 파일 시스템 전체에 대한 포괄적인 접근 권한이 있는 도구를 절대 부여하지 마십시오. 대신 다음과 같이 해야 합니다:

# 나쁜 예 — 전체 접근 권한
Tool(name="write_file", args={"path": "*", "content": "*")

...

규칙 2: 턴당 도구 호출 횟수를 제한하십시오 (Rate-limit tool calls per turn). 한 번의 턴에서 50개의 도구를 호출하는 에이전트는 비용과 지연 시간(latency)을 급증시킵니다. 다음과 같이 제한하십시오:

MAX_TOOL_CALLS_PER_TURN = 8  # 엄격한 제한 (hard limit)

규칙 3: 도구 결과 캐싱 (Cache tool results). 만약 에이전트가 "/src에 어떤 파일들이 있는가"라고 두 번 질문한다면, 두 번째 질문에는 캐시된 결과를 제공하십시오.

규칙 4: 모든 인자를 서버 측에서 검증 (Validate every argument server-side). LLM의 파라미터 생성(parameter generation)을 절대 신뢰하지 마십시오. MCP 서버는 실행 전에 스키마(schema)를 검증합니다.

2. A2A: 하나의 에이전트로는 충분하지 않을 때

Google의 에이전트 간 프로토콜 (Agent-to-Agent protocol, 2025년 출시)은 MCP가 남겨둔 문제, 즉 에이전트들이 서로 어떻게 대화할 것인가에 대한 문제를 해결했습니다.

A2A가 해결하는 문제

멀티 에이전트 시스템 (multi-agent system)에는 다음과 같은 구성 요소가 있습니다:

• 작업을 라우팅하는 코디네이터 에이전트 (coordinator agent)
• 특정 도메인(코드, 리서치, 데이터)을 처리하는 전문 에이전트 (specialized agents)
• MCP 서버를 래핑(wrap)하는 도구 에이전트 (tool agents)

A2A가 없다면, 이러한 에이전트들은 협상하거나, 작업을 인계하거나, 상태(state)를 공유할 수 없습니다.

A2A의 실제 적용

# A2A 카드 — 각 에이전트는 자신의 역량을 광고합니다
{
  "agent": "code-reviewer",
...

에이전트들은 서로를 발견하고, 작업을 협상하며, 구조화된 결과(structured results)를 반환합니다. 이것이 바로 스웜(swarm) 스타일 아키텍처를 가능하게 만드는 핵심입니다.

3. 확장 가능한 세 가지 패턴

여러 프로덕션 에이전트 시스템을 구축한 결과, 실제로 확장이 가능한 세 가지 아키텍처 패턴을 발견했습니다:

패턴 A: 감독자 + 작업자 (Supervisor + Workers, 계층형)

적합한 경우: 분해가 필요한 복잡한 작업.

┌────────────┐
│ Supervisor │  — 작업을 하위 작업으로 분해
└─────┬──────┘
...

감독자가 먼저 계획을 세운 다음 작업자들에게 위임합니다. 작업자들은 결과를 보고합니다. 감독자는 그 결과를 종합(synthesize)합니다.

사용 시점: PR 리뷰, 다중 파일 리팩토링 (multi-file refactoring), 리서치 보고서.

패턴 B: 파이프라인 (Pipeline, 순차형)

적합한 경우: 명확한 단계가 있는 선형 워크플로 (linear workflows).

입력(Input) → 에이전트 A → 에이전트 B → 에이전트 C → 출력(Output)
         (계획)      (구축)      (검증)

각 단계는 다음 단계로 구조화된 데이터를 전달합니다. 만약 어느 한 단계라도 실패하면, 파이프라인은 중단되고 에러를 보고합니다.

사용 시점: CI/CD 파이프라인, 검토를 포함한 콘텐츠 생성, 데이터 처리.

패턴 C: 스웜 (Swarm, 피어 투 피어/P2P)

적합한 경우: 단일 에이전트가 전체 컨텍스트를 보유하지 못하는 개방형 탐색 (Open-ended exploration).

    ┌──────────┐
    │  Market   │◄────────┐
    │ Research  │         │
...

에이전트들은 공유된 블랙보드 (Blackboard)에 조사 결과를 게시하고, 자신에게 적합한 작업을 가져옵니다.

사용 시점: 경쟁 분석, 탐색적 데이터 분석 (EDA), 브레인스토밍.

4. 우리가 실제로 사용하는 프로덕션 스택 (Production Stack)

마케팅용 버전이 아닌, 실제 스택은 다음과 같습니다:

5. 에이전트에 대해 아무도 말해주지 않는 한 가지

에이전트는 실패합니다. 아주 많이요. 아키텍처는 실패가 기본값(Default)임을 가정해야 합니다.

여러분의 에이전트는 반드시 다음과 같은 상황을 겪을 것입니다:

• 잘못된 인자 (Arguments)로 도구 (Tool) 호출
• 추론 루프 (Reasoning loop)에 갇힘
• 토큰 제한 (Token limits) 초과
• 도구 출력값으로부터 환각 (Hallucination)된 결과 반환

프로덕션 시스템에는 다음이 필요합니다:

• 지수 백오프를 포함한 재시도 (Retry with backoff) — 에스컬레이션 전 3회 시도
• 턴당 타임아웃 (Timeout per turn) — 최대 120초, 이후 강제 반환
• 인간 참여형 체크포인트 (Human-in-the-loop checkpoint) — 쓰기/삭제 작업 시 필요
• 결과 검증 (Result verification) — 에이전트가 완료를 선언하기 전 자신의 작업물을 스스로 검토

6. 종합하기: 실제 예시

제가 현재 프로덕션 에이전트를 구성하는 방식은 다음과 같습니다:

class ProductionAgent:
    def __init__(self):
        self.llm = LLM(model="deepseek-v4", temperature=0.3)
...

이는 단순화된 형태이지만 핵심 루프를 담고 있습니다: LLM 생성 → 도구 실행 → 결과 피드백 → 완료되거나 제한에 도달할 때까지 반복.

결론

2026년에 에이전트를 만드는 것은 어려운 일이 아닙니다. 인간의 관리 없이 24시간 내내 프로덕션 환경에서 안정적으로 작동하는 에이전트를 만드는 것이 어려운 일입니다.

만약 여러분의 아키텍처가 모든 계층 — LLM, 도구, 메모리, 네트워크 — 에서의 실패를 고려하지 않는다면, 여러분은 제품 (Product)이 아닌 프로토타입 (Prototype)을 만들고 있는 것입니다.

도구에는 MCP를, 조정 (Coordination)에는 A2A를, 복잡한 작업에는 계층적 분해 (Hierarchical decomposition)를 사용하십시오. 그리고 모든 것이 망가질 것이라고 가정하십시오. 그것이 진짜 비결입니다.

Hermes Agent로 제작되었습니다. 프로덕션 AI 아키텍처에 대한 더 깊은 통찰을 원하시면 ext{‐‐}NexMind AI ext{‐‐}를 팔로우하세요."