LLM 에이전트 구축: A2A와 MCP 간단히 설명

LLM 에이전트란 무엇인가?

LLM 에이전트는 특정 목표를 달성하기 위해 스스로 행동할 수 있는 AI 시스템입니다. 실제로 에이전트는 사용자의 요청을 단계별로 나누고, 지식 베이스나 API를 사용하여 데이터를 가져온 다음 최종 답변을 작성할 수 있습니다. 이는 에이전트가 독립형 챗봇보다 훨씬 더 강력하게 만들어 여러 작업을 조정하여 복잡한 워크플로우(예: 여행 예약, 보고서 생성, 코드 작성)를 자동화할 수 있습니다.

LLM 에이전트는 플러그인에 접근할 수 있는 디지털 비서와 같습니다: 내부 지식으로 추론하고 도구를 통해 외부 세계에 작용할 수 있습니다. 예를 들어, 계획 에이전트는 필요한 조치를 결정하고, 메모리 모듈은 이미 완료되거나 학습된 내용을 추적하며, 도구(데이터베이스 쿼리나 API와 같은)는 실시간 데이터를 제공합니다. 이러한 모듈성 덕분에 에이전트는 단일 LLM 처리로는 너무 복잡한 작업을 처리할 수 있어 워크플로우를 자동화하거나 "슈퍼" 코파일럿을 구축하는 개발자에게 가치가 있습니다.

에이전트 대 에이전트(A2A)와 멀티 컴포넌트 프롬프팅(MCP)은 이러한 에이전트를 구축하기 위한 두 가지 상호 보완적인 프레임워크입니다. 개념적으로 MCP는 에이전트와 외부 도구 간의 범용 커넥터("USB-C 포트")와 같습니다. 반면에 A2A는 여러 에이전트를 연결하여 협업할 수 있게 하는 네트워크 케이블과 같습니다. A2A는 에이전트 간 통신을 위한 개방형 프로토콜을 제공합니다: 에이전트들은 기능을 알리고, 서로 작업을 보내며, 공통 인터페이스를 통해 출력을 공유합니다. 둘 다 기본 LLM을 확장하는 것을 목표로 하지만 규모와 계층이 다릅니다.

이제 두 프레임워크가 어떻게 작동하는지 이해하고 비교해 봅시다.

모델 컨텍스트 프로토콜(MCP) 이해하기

MCP는 LLM 기반 애플리케이션이 외부 데이터와 도구에 균일한 방식으로 접근할 수 있게 해주는 개방형 표준 프로토콜(Anthropic에서 출시)입니다. 이 상호작용을 세 가지 역할로 나눕니다: 호스트(LLM 애플리케이션 인터페이스), 클라이언트(내장된 커넥터), 그리고 하나 이상의 서버(도구 제공자)입니다. 예를 들어, 호스트 앱(채팅 UI나 IDE와 같은)은 외부 MCP 서버에 연결을 유지하는 MCP 클라이언트를 포함합니다. 각 서버는 하나 이상의 도구(함수, API 또는 리소스 스트림)를 구현합니다. LLM이 작업을 수행해야 할 때 - 예를 들어 데이터베이스 쿼리나 Slack 호출 - 클라이언트는 해당 요청을 적절한 MCP 서버로 전달하고, 서버는 작업을 실행한 후 결과를 반환합니다.

핵심 아이디어는 M×N 통합 문제를 추상화하는 것입니다. MCP 이전에는 개발자들이 각 모델-API 연결에 대해 사용자 지정 코드를 작성해야 했습니다. MCP를 사용하면 도구가 입력과 출력을 자체 설명하므로 MCP 호환 모델은 접착 코드 없이도 도구를 사용할 수 있습니다. 실제로는 에이전트(LLM)가 사용 가능한 도구 목록이나 도구 사용 시기를 안내하는 프롬프트/템플릿을 받습니다. 그런 다음 구조화된 워크플로우에서 도구를 호출할 수 있습니다:

이해 → 계획 → 검증 → 개선 → 행동

이는 사고 과정 파이프라인과 유사합니다: LLM이 전략을 계획하고, 추론을 확인한 다음, 도구를 통해 최종 단계를 실행합니다. 예를 들어, MCP를 사용하는 여행 계획 에이전트는 "일주일간 일본 여행 계획"을 분석하고 필요한 도구(항공편 API, 호텔 검색)를 식별할 수 있습니다. 그런 다음 MCP 서버를 통해 해당 API를 쿼리하고, 일관성을 확인하며(예: 날짜 일치), 필요에 따라 조정한 다음, 최종적으로 예약된 여정을 출력합니다. 코드에서는 "Google Flights" MCP 서버와 "Hotel Finder" MCP 서버를 추가하는 것과 같을 수 있습니다; 에이전트의 프롬프트에는 필요할 때 호출할 수 있도록 인터페이스가 포함됩니다.

에이전트 대 에이전트(A2A) 프로토콜이란?

A2A는 여러 AI 에이전트가 서로를 찾고, 대화하고, 함께 작업할 수 있게 해주는 새로운 개방형 프로토콜(2025년 Google이 소개)입니다. A2A 시스템에서 각 에이전트는 자체 기능을 가진 독립적인 서비스입니다. 에이전트는 A2A를 구현하는 네트워크 엔드포인트와 "에이전트 카드"(/.well-known/agent.json의 JSON 메타데이터)를 공개합니다. 이 카드는 이름, 기술, 엔드포인트 URL 및 인증 정보를 설명합니다. 한 에이전트가 무언가 필요할 때, 에이전트 카드를 가져와 다른 에이전트를 발견한 다음 HTTP/JSON-RPC를 통해 "작업" 요청을 보낼 수 있습니다. 프로토콜과 라이브러리는 보안, 장기 실행 작업 및 복잡한 데이터 형식을 내부적으로 처리합니다. A2A의 주요 개념은 다음과 같습니다:

• 에이전트 카드: 에이전트의 능력(예: "회의 일정 관리" 또는 "재무 분석")과 엔드포인트를 알리는 작은 JSON 파일입니다. 에이전트는 다른 에이전트가 찾을 수 있도록 주기적으로 이 카드를 게시하거나 등록합니다(디렉토리를 통해 또는 URL을 알고 있음).
• 클라이언트 및 서버 에이전트: A2A 용어에서 클라이언트 에이전트는 작업을 시작하고(요청자), 원격/서버 에이전트는 이를 수행합니다. 예를 들어, "채용 에이전트"(클라이언트)가 "이력서 검색 에이전트"(원격)에 작업을 위임할 수 있습니다.

• 작업 수명 주기: 통신은 고유 ID를 가진 JSON 객체인 작업을 통해 이루어집니다. 클라이언트는 사용자 요청이 포함된 작업을 보냅니다(POST /tasks/send 또는 구독을 통해). 그런 다음 원격 에이전트는 작업을 수행함에 따라 작업 상태를 업데이트("작업 중", "입력 필요" 등)하고 최종적으로 결과물을 반환합니다. 서버는 Server-Sent Events(SSE)를 사용하여 업데이트를 스트리밍하거나 웹훅을 통해 클라이언트에 업데이트를 푸시할 수 있습니다.
• 메시지 및 부분: 작업에는 메시지(채팅 턴과 같은)가 포함됩니다. 각 메시지는 다양한 컨텐츠 유형(텍스트, 이미지, JSON 데이터 등)의 여러 부분을 포함할 수 있어 풍부한 협업이 가능합니다. 예를 들어, 데이터 분석 에이전트는 차트를 ImagePart로, 데이터 테이블을 DataPart로 반환할 수 있습니다. 클라이언트와 원격은 지원되는 형식을 협상하므로 에이전트는 다양한 UI에 적응할 수 있습니다.

실제로 A2A는 다중 에이전트 팀워크를 가능하게 합니다. 예를 들어, 기업 이벤트 계획 자동화를 상상해 보세요: 한 에이전트가 전체 계획을 관리하는 동안, 장소 예약은 "장소 에이전트"에, 케이터링은 "음식 에이전트"에, 마케팅은 "소셜 미디어 에이전트" 등에 위임합니다. 이들은 HTTP를 통해 안전하게 통신합니다: 계획 에이전트는 작업을 구성하고(예: "기조 연설자 찾기") A2A를 통해 전문 에이전트에게 보냅니다. 각 에이전트는 내부적으로 자체 LLM과 도구를 사용할 수 있지만 외부적으로는 A2A 사양을 따르므로 A2A 호환 클라이언트가 모두와 대화할 수 있습니다. 이 설계는 본질적으로 모듈식입니다: 에이전트는 마이크로서비스처럼 작동합니다. 한 에이전트가 느리거나 다운되면 코디네이터는 작업을 백업으로 라우팅하거나 기다릴 수 있습니다(프로토콜은 장기 실행 작업과 재시도를 지원).

A2A는 쉬운 통합을 위해 표준 기술(HTTP+JSON-RPC, SSE)을 기반으로 하며 OAuth/OpenAPI 스타일 인증으로 "기본적으로 안전"합니다. 빠른 쿼리부터 확장된 워크플로우(인간 참여 포함)까지 다양한 작업을 처리합니다. 주목할 점은 에이전트가 메모리나 내부 컨텍스트를 공유한다고 가정하지 않는다는 것입니다; 각 에이전트는 자율적입니다. 모든 조정은 명시적입니다: 프로토콜은 누가 대화를 가지고 있고 어떤 메시지가 교환되는지 관리합니다.

비교: A2A vs MCP

| 측면 | MCP | A2A |

|------|-----|-----|

| 아키텍처 | 도구 서버가 있는 단일 에이전트(LLM 중심). 클라이언트-서버: 호스트+클라이언트(앱 내)가 도구를 위한 하나 이상의 MCP 서버에 연결 | 다중 에이전트(피어) 네트워크. 클라이언트 및 원격 역할: 에이전트는 에이전트 카드를 통해 광고한 다음 HTTP/JSON으로 통신 |

| 핵심 목적 | 하나의 에이전트에게 외부 데이터와 API에 구조화된 접근 제공. LLM의 환경을 풍부하게 하는 "컨텍스트 레이어" 역할 | 에이전트 간 협업 가능. 에이전트가 서로를 발견하고, 작업을 위임하며, 공통 팀에 있는 것처럼 출력을 공유할 수 있게 함 |

| 데이터 흐름 | 에이전트는 도구, 리소스 및 프롬프트 템플릿을 사용. 도구 설명 목록을 읽고 필요에 따라 호출 | 에이전트는 작업, 메시지, 결과물 및 부분을 교환. 각 작업에는 수명 주기가 있으며, 메시지는 필요에 따라 콘텐츠(텍스트/데이터)를 전달 |

| 모듈성 | 도구 수준에서 모듈화: 각 MCP 서버는 별도의 서비스. 그러나 LLM 에이전트와 그 추론은 하나의 프로세스로 유지 | 에이전트 수준에서 모듈화: 각 에이전트는 다른 에이전트를 건드리지 않고 별도로 개발, 확장 또는 교체 가능. 새로운 기술을 가진 새 에이전트가 생태계에 참여 가능 |

| 유지 관리성 | 하나의 주요 에이전트 코드베이스와 여러 도구 서버 엔드포인트 유지 필요. 도구 인터페이스 변경 시 서버 업데이트 필요(프로토콜은 표준으로 유지) | 에이전트는 독립적인 마이크로서비스. 다른 에이전트를 재배포하지 않고 새 에이전트를 업데이트하거나 출시 가능. 그러나 조정 로직(주로 최상위 에이전트나 오케스트레이터)이 더 복잡해질 수 있음 |

| 성능/확장성 | 서버가 로컬이거나 잘 프로비저닝된 경우 도구 호출의 지연 시간이 낮음(직접 HTTP 또는 SSE 사용). 도구 수가 늘어나면 복잡성도 증가하지만 통합은 표준화됨. 컨텍스트 창이 넘치거나 동시 호출이 너무 많으면 문제 발생 가능 | 에이전트 간 HTTP 네트워크 호출의 오버헤드. 대규모 워크플로우에 적합: 여러 에이전트 인스턴스를 병렬로 실행하여 확장 가능. 스트리밍 업데이트로 장기 실행 작업(시간/일) 처리 가능. 비동기 통신에 의존하므로 처리량은 네트워크 및 에이전트 가용성에 따라 달라짐 |

| 기능 | 구조화된 추론에 탁월: 에이전트가 작업을 예측 가능한 단계로 나누고 각각 검증. 투명한 실행(각 단계 기록), 감사 용이. 코딩 도우미, 데이터 조회 또는 정확한 도구 사용이 필요한 작업에 적합 | 다양한 전문성에 탁월: 각각 전문화된(금융, NLP, 시각 등) 에이전트 팀이 협업. 단일 에이전트가 모든 지식을 갖고 있지 않은 복잡한 다중 도메인 작업(기업 워크플로우, 다단계 비즈니스 프로세스)에 이상적. 풍부한 미디어(텍스트, 오디오, 비디오) 협상 지원 |

| 주목할 예 | Claude Desktop과 GitHub, 캘린더 등에 연결하는 Zed나 Cursor AI 같은 도구에서 사용. 단일 에이전트 시나리오에 적합(예: "모든 데이터베이스에 연결하는 AI 코파일럿") | 조직 간 설정(예: 이력서 검색 에이전트와 면접 일정 관리 에이전트 협업), 복잡한 비즈니스 프로세스 및 Google의 Agentspace와 같은 프로젝트에서 등장. Atlassian, Cohere, LangChain 등 많은 기여자들이 A2A 지원 에이전트를 구축 중 |

실제로 MCP와 A2A는 서로 경쟁하기보다 상호 보완적입니다. Google은 명시적으로 A2A를 Anthropic의 MCP와 "상호 보완적"이라고 부릅니다. 예를 들어, 한 에이전트가 내부적으로 MCP를 사용하여(여러 도구 호출 연결) 결과를 A2A를 통해 다른 에이전트에게 전달할 수 있습니다. 또는 특수한 A2A 에이전트가 자체 내부 도구 사용을 관리하기 위해 MCP를 사용하여 구현될 수 있습니다. 위 표는 이를 강조합니다: MCP는 도구와 데이터에 관한 것이고, A2A는 에이전트 오케스트레이션에 관한 것입니다.

보안과 복잡성 면에서 두 프로토콜 모두 새로운 우려 사항을 도입합니다. MCP의 개방형 도구 호출은 신중하게 샌드박스화되어야 합니다(프롬프트 삽입이나 도구 중독이 위험). A2A는 에이전트 간에 많은 엔드포인트를 열기 때문에 인증(OAuth, API 키 등)과 권한 부여(RBAC, 토큰)가 중요합니다. 그러나 둘 다 기업 사용을 염두에 두고 구축되었습니다: A2A는 기본적으로 HTTP 인증 또는 OAuth2.0을 사용하고, MCP는 서버를 위한 OAuth2.1을 지원하도록 업데이트되었습니다.

마무리

지금까지 MCP와 A2A가 어떻게 상호 보완적인지 - 하나는 도구 및 데이터 통합에 중점을 두고, 다른 하나는 에이전트 오케스트레이션에 중점을 두는지 이해했습니다. 또한 에이전트의 기능을 확장하는 동시에 관리해야 할 새로운 복잡성과 보안 계층을 도입한다는 것도 확인했습니다. 이제 실제 질문은:

• 자신의 시스템에서 이러한 프레임워크를 어떻게 결합할 수 있을까요?
• 다음 에이전트가 MCP로 도구를 연결한 다음 A2A로 서비스 간 협업할 수 있을까요?

개발자와 아키텍트로서 우리는 더 이상 단순한 챗봇만 구축하는 것이 아니라 계획하고, 행동하고, 조정할 수 있는 에이전트 시스템을 설계하고 있습니다. 필요한 빌딩 블록이 여기 있습니다. 다음 행동은 여러분의 몫입니다.