길리랩blog

멀티에이전트 아키텍처와 MCP 표준화 전략

오케스트레이터·전문 에이전트·비평가 구조와 MCP 표준화, 컨텍스트 격리 및 기업 도입 로드맵을 다룬다.

2026-08-14 · 최초 발행 2026-08-02

단일 프롬프트 루프만으로는 감당하기 어려운 작업

2026년은 단일 LLM 프롬프트 루프 중심의 AI 활용이 오케스트레이터, 전문 에이전트, 비평가(Critic)로 역할을 나눈 멀티에이전트 워크플로우로 옮겨가는 시기로 평가받는다. Model Context Protocol(MCP)의 Linux Foundation 표준화는 이 생태계의 제도적 기반을 다지는 움직임이다. Gartner는 2026년 말까지 포춘 500 기업의 40% 이상이 하나 이상의 AI 에이전트를 생산 환경에 배포할 것으로 예측했다.

한 에이전트가 계획 수립, 실행, 검증을 모두 맡으면 오류가 다음 단계로 전파되고 컨텍스트가 과도하게 누적되며 역할 간 충돌이 생길 수 있다. 장기 실행 작업, 도메인별 전문성, 병렬 처리 요구가 늘면서 개별 모델의 성능보다 시스템 아키텍처의 설계가 경쟁력의 중심으로 이동한다. 이 과정에서 에이전트 간 상호운용을 보장할 프로토콜 표준의 부재도 도입 장벽이 된다.

역할을 분리해 작업을 조율하는 구조

멀티에이전트 시스템에서는 역할 분리를 계층으로 드러내는 방식이 핵심이다. 오케스트레이터(Orchestrator)는 전체 목표를 받아 서브태스크로 나누고, 전문 에이전트(Specialist Agent)는 배정된 작업을 수행한다. 비평가 에이전트(Critic Agent)는 결과를 평가해 피드백과 재시도 여부를 결정한다.

⤢✕재작업 요청승인사용자 요청오케스트레이터 에이전트전문 에이전트 A (코드 생성)전문 에이전트 B (데이터 검색)전문 에이전트 C (문서 작성)비평가 에이전트최종 결과

오케스트레이터는 전역 계획을 세우고 태스크 의존성 그래프를 관리하며, 적절한 에이전트를 선택해 호출한다. 전문 에이전트는 단일 도메인에 집중하고 MCP 서버 도구를 사용해 구조화된 결과를 반환한다. 비평가 에이전트는 출력 품질과 일관성을 검증하고, 재시도·사용자 게이트를 판단한다.

결과를 전달하고 재작업을 요청하는 계약

에이전트 간 전달 형식은 태스크와 결과, 평가 요청을 분리해 정의할 수 있다.

⤢✕U비평가 에이전트전문 에이전트 B전문 에이전트 A오케스트레이터U비평가 에이전트전문 에이전트 B전문 에이전트 A오케스트레이터TaskMessage(task_id, input, constraints)ResultMessage(task_id, output, confidence, tool_calls)TaskMessage(task_id, input + A.output)ResultMessage(task_id, output, confidence, tool_calls)CriticRequest(task_id, all_results, rubric)CriticResponse(pass=false, feedback, retry_targets)RetryMessage(task_id, feedback)ResultMessage(task_id, revised_output, confidence)CriticRequest(task_id, revised_results, rubric)CriticResponse(pass=true)FinalResponse

TaskMessage에는 task_id, parent_task_id, input_schema, constraints, timeout_ms, max_tokens를 담는다. ResultMessage는 task_id, output, confidence_score, tool_calls_log, token_usage를 반환한다. CriticRequest는 rubric의 평가 기준, all_results 집계, user_goal 참조를 포함한다.

재시도 정책에는 최대 재시도 횟수인 max_retries와 백오프 전략을 사전에 정의해야 한다.

컨텍스트를 섞지 않는 경계

전문 에이전트 사이의 컨텍스트 오염을 막고 병렬 실행을 안정화하려면 각 에이전트가 독립된 컨텍스트 윈도우를 보유해야 한다. 공유 메모리에 직접 접근하지 못하게 하고, 오케스트레이터가 중개한 메시지만 교환하게 한다.

실행 전후 상태를 직렬화하면 재개 가능성(Resumability)을 확보할 수 있다. 격리 수준은 논리적 격리(Logical Isolation)와 프로세스 수준 격리(Process-Level Isolation) 중에서 선택적으로 적용한다.

⤢✕에이전트 B 컨텍스트 (격리)에이전트 A 컨텍스트 (격리)오케스트레이터 컨텍스트TaskMessageResultMessageTaskMessageResultMessage전역 계획태스크 그래프에이전트 레지스트리로컬 메모리도구 호출 이력중간 결과로컬 메모리도구 호출 이력중간 결과

재귀 위임을 멈추게 하는 조건

오케스트레이터가 서브오케스트레이터를 만들고 하위 에이전트에 다시 위임하는 흐름은 무한 재귀로 이어질 수 있다. 이를 막기 위해 max_delegation_depth를 두며, 권장값은 3~5다.

재귀 깊이가 커질수록 토큰 소비는 지수적으로 증가하므로 max_cost_usd와 함께 예산을 제어한다. 각 위임 단계에는 base_case를 명시하고, 리프 에이전트에는 재위임 불가 플래그를 둔다. 재귀 경로는 DAG로 기록해 디버깅과 감사를 지원한다.

MCP를 생태계 계약으로 다루는 방법

Model Context Protocol(MCP)이 2025년 말 Linux Foundation 산하 오픈 거버넌스 체계로 이관된 것은 단일 벤더 종속에서 벗어나는 제도적 전환으로 볼 수 있다.

거버넌스는 Technical Steering Committee(TSC)와 Working Group을 분리해 운영한다. Contributor License Agreement(CLA)를 기반으로 기업과 개인의 동등한 기여를 허용하며, TSC 합의(Consensus)를 우선하되 교착 상태에서는 투표(Supermajority)를 사용한다. Anthropic, Microsoft, Google DeepMind, AWS, Cloudflare 등이 공동 참여하고, Linux Foundation 브랜드는 기업 IT 조달 승인 기준을 충족하는 데 도움이 된다.

서버 레지스트리와 품질 관리

MCP 서버 카탈로그는 데이터베이스 연동, 파일 시스템, 외부 API, 코드 실행, 협업 도구 등을 포함한 10개 대분류로 구성된다.

⤢✕MCP 서버 레지스트리(공식 카탈로그)검증 레이어보안 스캔 / 스키마 검사인증 레이어TSC 승인 / 커뮤니티 기여배포 레이어Docker Hub / npm / PyPI품질 배지 시스템Gold / Silver / Community에이전트 런타임자동 서버 탐색 및 로드

품질 배지는 Gold(TSC 검증), Silver(자동화 테스트 통과), Community(미검증)로 구분한다. 보안 정책에는 CVE 스캔 자동화, 비밀값(Secret) 노출 검사, 샌드박스 실행 요건이 포함된다. 서버 참조에 @version 태그를 강제하면 암묵적 업데이트를 막을 수 있다. 다운로드 횟수와 활성 사용자 공개는 에이전트 생태계의 신뢰도를 측정하는 수단이 된다.

호환성과 구현체 사이의 약속

버전은 MAJOR.MINOR.PATCH 형태의 SemVer를 적용하며, MAJOR 변경에는 하위 호환성 파기를 명시한다. 기능을 제거하기 전에는 최소 6개월의 Deprecation Notice를 의무화하고, 클라이언트와 서버의 프로토콜 버전 협상을 위한 Capability Negotiation 핸드셰이크를 둔다.

각 MAJOR 버전에는 자동 마이그레이션 스크립트를 공식 제공하고, 기업 환경을 위한 LTS 채널은 24개월 보안 패치를 보장한다.

전송 계층은 HTTP+SSE, WebSocket, stdio를 공식 지원한다. 인증에는 OAuth 2.1과 mTLS 조합을 사용하고, Tool·Resource·Prompt 정의는 JSON Schema Draft 2020-12를 기반으로 한다. Python, TypeScript, Go, Rust, Java SDK를 공식 유지하며 MCP Conformance Test Suite로 구현체 호환성 검증을 자동화한다.

단층 구조와 역할 분리 구조의 차이

항목 단층 에이전트 멀티에이전트
구조 단일 LLM + 도구 목록 오케스트레이터 + 전문 에이전트 + 비평가
컨텍스트 관리 단일 컨텍스트 창 공유 에이전트별 격리 컨텍스트
오류 복구 전체 재시작 또는 수동 개입 비평가 피드백 루프 자동 복구
병렬 처리 순차 실행만 가능 전문 에이전트 병렬 실행
도메인 전문성 범용 프롬프트로 커버 에이전트별 특화 프롬프트·도구
비용 단일 호출 저비용 다중 호출 고비용 (태스크 복잡도에 비례)
감사 추적 단일 로그 에이전트별 분리 로그, DAG 가시화
확장성 컨텍스트 창 한계 에이전트 수평 확장
적합 태스크 단순 Q&A, 짧은 요약 장기 실행, 멀티 도메인, 고신뢰 요구 작업
도입 복잡도 낮음 높음 (오케스트레이션 로직 설계 필요)

파일럿에서 전사 운영으로 확장하는 흐름

⤢✕Phase 1 (Q1 2026)단일 에이전트 파일럿MCP 서버 1-3개 연동내부 도구 자동화(Slack, Jira, GitHub)보안 정책 수립(샌드박스, 비밀값관리)Phase 2 (Q2 2026)오케스트레이터 도입2개 이상 전문 에이전트분리컨텍스트 격리 설계비용 예산 제어 구현Phase 3 (Q3 2026)비평가 에이전트 추가품질 게이트 자동화재시도 정책 정교화감사 로그 시스템 연동Phase 4 (Q4 2026)프로덕션 배포멀티에이전트워크플로우 전사 확산MCP 서버 사내레지스트리 구축SLA 정의 및 모니터링기업 멀티에이전트 도입 로드맵 2026

Phase 1에서는 소규모 파일럿을 통해 에이전트 거버넌스 기준을 먼저 수립한다. Phase 2에서는 도메인별 에이전트와 기능별 에이전트의 경계를 명확히 하고, 컨텍스트 격리와 비용 예산 제어를 설계한다.

Phase 3에서는 비평가 에이전트로 품질 게이트를 자동화하고 재시도 정책과 감사 로그 연동을 다듬는다. Phase 4의 운영 지표는 에이전트 호출 성공률, 평균 완료 시간, 비용-태스크 비율, 재시도 횟수 분포다. 비평가 에이전트의 오류 거부율(False Rejection Rate)도 조정 대상이 된다.

AI 시스템 통합 관점에서 본 설계 항목

멀티에이전트 아키텍처는 정보관리기술사 시험의 「AI 시스템 통합」 출제 영역과 연결된다.

소프트웨어 아키텍처 관점에서 멀티에이전트 시스템은 SOA(Service-Oriented Architecture)의 AI 시대 진화형으로 해석할 수 있다. 오케스트레이터는 ESB(Enterprise Service Bus), 전문 에이전트는 마이크로서비스 역할에 대응한다. 에이전트 간 계약(Contract)은 OpenAPI Schema에서 MCP Tool Schema로 대체된다.

데이터 거버넌스에서는 컨텍스트 격리를 데이터 분류(Data Classification) 정책과 연계한다. 개인정보를 처리하는 에이전트에는 Process-Level Isolation을 적용해 격리 수준을 강화하고, 비평가 에이전트가 출력의 데이터 품질 관리(DQM)를 맡는다.

보안 아키텍처는 Zero Trust 원칙을 따른다. 에이전트 간 통신에도 상호 인증(mTLS)과 최소 권한(Least Privilege)을 적용하며, Agent Identity는 서비스 계정(Service Account)처럼 관리한다. 도구 호출 이력은 SIEM으로 보내 이상 행동을 탐지한다.

프로젝트 관리에서는 멀티에이전트 도입을 「AI 중심 비즈니스 프로세스 재설계(BPR)」로 접근한다. ROI는 자동화 태스크 건수, 인적 개입 감소율, 오류 감소율로 측정한다. 에이전트 할루시네이션 위험은 비평가 에이전트와 인간 게이트를 결합해 이중으로 제어한다.

에이전트 생태계가 향하는 방향

⤢✕2026년 (멀티에이전트 전환 원년)2025년 (단일 에이전트 시대)아키텍처 전환단일 LLM 에이전트범용 도구 목록순차 실행오케스트레이터전문 에이전트코드 생성전문 에이전트데이터 분석전문 에이전트문서 작성비평가 에이전트MCP 서버 생태계1만 개 이상

도메인별 파인튜닝 모델을 전문 에이전트로 활용하는 패턴은 확산될 전망이다. 태스크 유형에 따라 에이전트 조합을 런타임에 결정하는 메타-오케스트레이터도 등장한다. 오케스트레이터는 호출 비용을 실시간으로 추적해 예산 한도 안에서 조합을 선택하고, MCP 서버 레지스트리를 기반으로 유료 전문 에이전트 마켓플레이스가 형성될 전망이다.

비평가 에이전트가 신뢰도 미달 결과를 사람에게 에스컬레이션하는 휴먼-인-더-루프 패턴도 표준화된다. AWS Bedrock, GCP Vertex AI, Azure AI Foundry는 멀티에이전트 오케스트레이션을 매니지드 서비스로 제공하는 경쟁을 벌이고 있다. LangGraph, AutoGen, CrewAI, Mastra 등의 오픈소스 프레임워크는 MCP 표준으로 수렴한다.

EU AI Act의 고위험 AI 시스템 분류에는 에이전트 자율 의사결정이 포함되며, 비평가 에이전트는 규제 준수 역할도 병행한다. 소형 SLM 기반 전문 에이전트를 엣지 디바이스에 배포하는 분산 멀티에이전트 구조 역시 실험 중이다.

단층 에이전트에서 출발하되 역할 설계, 컨텍스트 격리, 비용 예산 제어, 감사 추적을 갖춘 구조로 점진적으로 옮겨가는 것이 기업 도입의 흐름이다. MCP 표준 생태계를 조기에 내재화하는 일은 이 전환의 기반이 된다.

Sources

멀티에이전트MCPAI 아키텍처오케스트레이션컨텍스트 격리