MCP A2A 멀티 에이전트 아키텍처 — 엔터프라이즈 보안 설계 가이드

핵심 메시지

• MCP를 실제 개발에 쓰려면 내부 데이터가 외부 모델로 새어 나가지 않도록 온프렘 내부 에이전트와 상용 모델을 분리하는 설계가 필요하다.
• 가드레일은 데이터가 조직 밖으로 나가는 시점에 인터럽트를 걸어 룰베이스(정규식 등)로 민감정보를 걸러내는 방식이 현실적이다.
• 에이전트 역할을 아주 잘게 쪼개면, 하나가 뚫려도 접근 가능한 데이터가 제한되므로 보안 사고 범위를 크게 줄일 수 있다.
• A2A는 '에이전트 카드(명함)'를 주고받아 상대의 역할·기술·인증 요구를 확인한 뒤 JSON-RPC로 통신하는 개방형 규약으로, MCP를 대체하지 않고 함께 쓰인다.
• 각 에이전트를 A2A로 감싸 도커라이징하면 MSA처럼 독립 배포·수평 확장이 가능해지고, 궁극적으로 에이전트 마켓 형태로 확장될 수 있다.

쉽게 이해하기

테디노트 채널에서 두 개발자가 기업 환경에서 MCP(Model Context Protocol)와 A2A(Agent-to-Agent)를 활용한 멀티 에이전트 아키텍처를 놓고 나눈 대담이다. MCP를 커서나 클로드에서 시연하는 사례는 많지만, 이를 실제 개발과 기업 업무에 어떻게 안전하게 녹여낼지가 핵심 고민으로 제시된다.

가장 많이 나오는 우려는 데이터 유출이다. MCP로 외부 툴을 붙이면 내부 데이터가 밖으로 나가는 것 아니냐는 질문이 많은데, 대담에서는 공개할 수 없는 데이터는 온프렘 내부 모델·내부 에이전트가 처리하고, 그 결과가 외부(상용) 모델로 넘어가는 경계에 가드레일을 두는 구조를 제안한다.

가드레일은 화려한 개념처럼 보이지만 실무에서는 데이터가 조직 밖으로 나가는 시점에 인터럽트를 걸어 룰베이스로 거르는 방식이 현실적이라고 본다. 주민등록번호 같은 특정 형식은 정규식으로 대부분 잡아낼 수 있고, LLM 기반 검사는 오래 붙잡으면 다른 에이전트가 놀게 되는 부담이 있다.

완벽한 차단은 불가능하다는 점도 솔직히 인정한다. 흰색 글씨로 숨긴 프롬프트 인젝션처럼 룰베이스를 우회해 조직도를 XML로 뽑아 메일로 보내라는 식의 공격 사례가 소개된다. 대신 각 에이전트가 접근할 수 있는 테이블을 한두 개로 제한하고 역할을 잘게 쪼개면 피해 범위를 크게 줄일 수 있다고 강조한다.

후반부는 A2A로 넘어간다. 각 에이전트는 자신이 무엇을 하는지 적힌 '에이전트 카드(명함)'를 들고 있고, 클라이언트가 이를 요청해 역할·기술·엔드포인트·인증 필요 여부를 확인한 뒤 딱 맞는 작업만 JSON-RPC로 보낸다. 내부는 랭그래프로 만들되 A2A 규격으로 감싸면, 각 에이전트를 떼었다 붙였다 하는 완전한 모듈화와 수평 확장이 가능해진다.

주요 인사이트

• MCP는 보안이 취약하다는 오해가 많지만, 실제로는 OAuth 2.1을 권장하며 네트워크 격리 기반 시큐리티 게이트웨이와 결합해 엔터프라이즈 요구를 맞출 수 있다.
• MCP 전송 방식에서 SSE는 사실상 스트리머블 HTTP로 통합·대체됐고, 스펙 자체가 6월 18일 업데이트될 만큼 빠르게 바뀌고 있어 최신 스펙 추적이 중요하다.
• 외부 MCP 서버의 악의적 동작을 잡기 위해 와이어샤크의 도커 버전 같은 프록시 서버로 네트워크 패킷을 모니터링하는 방어책이 제안된다.
• 랭그래프만으로 짜면 A2A 통신 없이도 되지만, A2A로 감싸면 개별 에이전트를 떼어 재사용하고 의존성을 없애 수평 확장하기 쉬워진다.
• 발표자들은 A2A가 구글의 검색기처럼 '에이전트 마켓'이 되는 미래를 그린다. 프레임워크와 무관하게 앱스토어에 올리듯 에이전트를 등록해 쓰이는 만큼 정산받는 구조, 나아가 개인 비서 에이전트가 삼성·LG·현대 같은 제조사 에이전트와 A2A로 연결되는 그림을 전망한다.

자주 묻는 질문

관련 AI 소식