AI 에이전트의 두 개의 축 — 도구를 붙이는 일과 동료를 부르는 일은 다르다

AI 에이전트를 처음 만들 때 가장 먼저 하는 일은 "도구를 붙이는 것"이다. 날씨를 물어보면 날씨 API를, 문서를 찾으면 검색 엔진을 연결한다. 나도 그렇게 시작했고, 한동안은 그걸로 충분해 보였다. 그런데 어느 순간 멈칫하는 지점이 왔다. "번역은 번역 잘하는 에이전트한테 맡기고 싶은데, 이건 도구를 붙이는 거랑 뭐가 다르지?"

이 멈칫이 사실 요즘 에이전트 생태계 전체가 두 갈래로 갈라진 이유다. 에이전트가 바깥세상과 연결되는 방식에는 서로 다른 두 개의 축이 있고, 각 축을 담당하는 프로토콜이 따로 있다. 이 글은 그 두 축을 구분하는 것 하나만 다룬다. 이것만 잡으면 MCP·A2A·ACP 같은 약어들이 왜 동시에 존재하는지가 한 번에 풀린다.

먼저 익숙한 축 — 에이전트가 도구를 붙이는 일

에이전트에게 "능력"을 주는 첫 번째 방법은 도구(tool) 연결이다. 에이전트 혼자서는 데이터베이스를 읽지도, 웹을 검색하지도 못한다. 그래서 외부 시스템을 함수처럼 호출할 수 있게 배선(wiring)을 깔아 준다. 이 배선의 표준이 MCP(Model Context Protocol) — Anthropic이 제안한, 에이전트와 외부 도구·데이터를 잇는 규약이다. 흔히 "AI를 위한 USB-C 포트"에 비유된다. 어떤 도구든 이 규격에 맞추면 에이전트가 똑같은 방식으로 꽂아 쓸 수 있다는 뜻이다.

다이어그램 설명. 하나의 에이전트가 여러 도구를 아래로 끌어다 쓰는 그림이다. "에이전트"에서 "데이터베이스", "웹 검색", "파일 시스템"으로 뻗은 선이 전부 MCP 연결이다. 핵심은 방향성이다 — 여기서 도구들은 스스로 판단하지 않는다. 데이터베이스는 시키는 쿼리를 실행할 뿐이고, 검색 엔진은 준 질의어로 결과를 돌려줄 뿐이다. 지능은 오직 에이전트 한 곳에 모여 있고, 도구는 그 지능이 손을 뻗는 말단이다. 이 관계를 나는 수직축이라고 부르겠다. 위에 판단하는 주체가 있고, 아래에 그 명령을 수행하는 부품이 있는 위아래 구조이기 때문이다.

두 번째 축 — 에이전트가 동료를 부르는 일

그런데 번역 이야기로 돌아가 보자. 잘 만들어진 번역 에이전트는 단순한 도구가 아니다. 그 안에 자기만의 판단(어떤 문체로 옮길지), 자기만의 도구(용어 사전, 문법 검사기), 자기만의 대화 맥락이 들어 있다. 이걸 내 에이전트에 "함수처럼" 흡수하려 하면 어색해진다. 번역 에이전트는 지시를 받아 수행하는 부품이 아니라, 일을 맡기면 알아서 처리해 돌려주는 동료에 가깝기 때문이다.

여기서 두 번째 축이 등장한다. 독립적으로 만들어진 에이전트끼리 직접 대화하고 일을 위임하는 수평축이다. 이 축을 담당하는 프로토콜이 A2A(Agent2Agent)와 ACP(Agent Communication Protocol)다. A2A는 Google이, ACP는 IBM이 각각 제안했는데(둘은 나중에 하나로 합쳐진다 — 이건 이 시리즈의 다른 글에서 다룬다), 공통점은 뚜렷하다. 에이전트를 도구가 아니라 대등한 상대로 취급한다는 것이다.

다이어그램 설명. 이 그림이 이 글의 핵심이다. "나의 에이전트"에서 나가는 선이 두 종류라는 점을 보라. "데이터베이스"·"웹 검색"으로 가는 선은 MCP(수직) — 판단 없는 도구를 부린다. "번역 에이전트"·"코드 리뷰 에이전트"로 가는 선은 A2A/ACP(수평) — 스스로 판단하는 동료에게 일을 맡긴다. 같은 에이전트가 두 축을 동시에 쓴다는 게 중요하다. 두 프로토콜은 경쟁 관계가 아니라 역할이 다른 상보 관계다. 흔한 오해가 "MCP가 있는데 A2A가 왜 또 필요하냐"인데, 이 그림이 답이다 — 하나는 도구를 붙이는 축이고, 하나는 동료를 부르는 축이라 애초에 겹치지 않는다.

왜 굳이 나눴나 — "부품"과 "동료"는 필요한 게 다르다

둘을 왜 다른 프로토콜로 나눴는지는, 각각이 무엇을 필요로 하는지 보면 자연스럽다. 도구를 붙일 때 필요한 것과, 동료에게 일을 맡길 때 필요한 것이 다르다.

필요한 것	수직축 (MCP — 도구)	수평축 (A2A/ACP — 동료)
상대가 하는 일	시킨 함수를 실행	맡긴 목표를 스스로 처리
지능의 위치	내 에이전트에만 있음	양쪽 에이전트에 각각 있음
핵심 관심사	"이 도구를 어떻게 호출하지?"	"이 낯선 에이전트를 어떻게 찾고, 믿고, 대화하지?"
대표 비유	손에 쥔 연장	옆자리 전문가 동료

표 설명. 두 축의 차이를 한 줄씩 대비한 것이다. 가장 결정적인 행은 "지능의 위치"다. 도구를 붙일 때는 판단이 내 에이전트 한 곳에만 있어서, 프로토콜이 신경 쓸 일은 "함수를 어떻게 안전하게 호출하는가" 정도로 단순하다. 반면 동료에게 맡길 때는 상대도 스스로 판단하므로, 프로토콜이 "그 에이전트를 어떻게 발견하고(discovery), 무엇을 할 줄 아는지 어떻게 알아내고, 오래 걸리는 일의 진행 상황을 어떻게 주고받는가" 같은 훨씬 무거운 문제를 다뤄야 한다. 필요가 이렇게 다르기 때문에 하나의 프로토콜로 뭉뚱그리지 않고 두 축으로 나눈 것이다.

정리 — 새 프로토콜을 만나면 먼저 축을 묻는다

에이전트 관련 프로토콜이 쏟아져 나오지만, 처음 마주쳤을 때 던질 질문은 하나면 된다. "이건 도구를 붙이는 축인가, 동료를 부르는 축인가?" 수직축이면 MCP 계열의 도구 연결 이야기이고, 수평축이면 A2A/ACP 계열의 에이전트 간 협업 이야기다. 이 하나의 구분만 손에 쥐면 "MCP vs A2A" 같은 소모적 논쟁에 휘말리지 않는다 — 둘은 겹치는 축이 아니라, 내 에이전트가 세상과 연결되는 서로 다른 두 방향이니까.

---

참고한 공개 자료:

• What is Agent Communication Protocol (ACP)? — IBM (https://www.ibm.com/think/topics/agent-communication-protocol)
• Model Context Protocol 소개 — Anthropic (https://www.anthropic.com/news/model-context-protocol)
• Agent Communication Protocol — IBM Research (https://research.ibm.com/projects/agent-communication-protocol)

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.