MCP와 A2A의 의미: 에이전트 시스템에서 도구 표준과 에이전트 표준이 갈리는 지점

핵심 메시지

• MCP는 공개 직후에는 주목받지 못했지만 앤트로픽이 워크숍과 사용 사례로 계속 밀어붙인 덕에 에이전트 개발이 늘면서 표준으로 자리 잡았다.
• MCP 이전에는 모든 팀이 슬랙·드라이브·깃허브 API 문서를 각자 읽고 같은 도구를 중복 개발했다. 이제는 서비스 제공자가 공식 서버를 내놓아 수십 초 만에 붙일 수 있다.
• 두 사람은 구글의 A2A 발표를 생태계 주도권 방어로 읽었다. 초기 파트너가 대부분 컨설팅 기관이었던 점을 근거로 들었다.
• 그래도 외부 에이전트를 표준화된 방식으로 끌어다 쓰는 흐름 자체는 유효하며, 에이전트 카드로 능력을 기술해 상위 에이전트가 일을 분배하는 구조가 가능해진다.
• MCP 서버 안에 이미 복잡한 에이전트 로직이 들어가 있는 경우가 많다. 예전에 에이전트라 부르던 시스템이 지금은 하나의 도구로 취급된다.

쉽게 이해하기

테디노트 채널의 대담에서 두 개발자는 MCP가 어떻게 사실상의 표준이 됐는지부터 짚었다. 게스트는 MCP가 처음 공개됐을 때는 개발자들이 크게 주목하는 주제가 아니었다고 회상했다. 그런데도 앤트로픽이 관련 워크숍을 열고 사용 사례를 계속 만들며 밀어붙인 덕에 명맥이 유지됐고, 사람들이 본격적으로 에이전트를 만들기 시작하자 단숨에 커졌다는 설명이다. 다른 회사들이 서비스를 쏟아냈다가 반응이 없으면 접는 것과 대비된다는 점도 언급됐다.

실무에서 체감한 변화는 도구 연결 비용이었다. 예전에는 슬랙이나 드라이브, 깃허브에 접근하는 도구를 붙이려면 API 문서부터 읽고 함수를 직접 만들어야 했다. 개발 생태계 전체로 보면 모두가 같은 일을 중복해서 하고 있었다는 것이다. MCP 이후에는 서비스를 운영하는 기업이 자사 서버를 공식으로 공개하기 시작했고, 자기 서비스 사용을 늘리는 일이라 이해가 맞아떨어졌다. 두 사람은 이제 10초면 가져다 쓴다고 표현했다.

MCP 직후 나온 구글의 A2A에 대해서는 평가가 유보적이었다. 게스트는 이를 도구보다 상위인 에이전트 계층에서 추상화해 생태계 주도권을 가져가려는 움직임으로 읽었고, 발표 당시 파트너로 소개된 기업들이 대부분 컨설팅 기관이어서 컨소시엄과 슬로건을 위한 구성처럼 보였다고 말했다. 기술적으로도 완전히 새로운 개념은 아니라고 봤다.

그럼에도 방향 자체는 인정했다. 외부에 공인된 에이전트가 있고 그 에이전트가 할 수 있는 일과 보유한 도구를 에이전트 카드에 담아두면, 우리 시스템의 상위 에이전트가 그 정보를 기준으로 일을 분배할 수 있다. 두 사람은 A2A라는 이름이 아니어도 에이전트 자체를 API로 감싸 파는 기업이 늘고 있다고 봤다. 예로 든 파이어크롤은 URL을 넣으면 크롤링 결과를 주던 도구에서, 리서치 주제를 던지면 자체 도구로 조사해 출처까지 정리해 주는 형태로 확장했다.

대담의 핵심 관찰은 도구와 에이전트의 경계가 흐려졌다는 점이다. 겉으로는 MCP 도구지만 서버 내부에서는 이미 에이전트가 돌고 있는 경우가 많다. 랭그래프로 만든 검색 증강 생성 시스템을 MCP 서버로 띄우면, 과거에는 그 자체를 에이전트라 불렀지만 지금은 상위 시스템의 하위 작업 도구로 취급된다. 두 사람은 복잡한 작업을 서버 뒤로 감춰 함수 하나로 결과를 얻는 용도라면 좋지만, 에이전트 단계까지 MCP 서버에 다 넣으면 멀티 에이전트 구조와 트레이드오프를 계산해야 하고, MCP는 애초에 도구로 설계돼 확장에 한계가 있을 것이라고 봤다.

주요 인사이트

• 표준이 자리 잡는 조건은 기술적 우아함보다 지속적인 밀어붙임이었다. 공개 시점에 반응이 없어도 워크숍과 사용 사례를 계속 만든 쪽이 결국 생태계를 얻었다.
• 공식 MCP 서버를 내놓는 일이 서비스 기업에게 이익이라는 구조가 확산의 진짜 엔진이다. 표준의 성패는 제공자의 동기와 맞물린다.
• 프로토콜 발표에서 파트너 명단을 보는 것은 유용한 판별법이다. 기술력을 직접 가진 기업이 아니라 컨설팅 조직이 앞에 서 있으면 실사용보다 진영 구축일 가능성이 있다.
• "도구인가 에이전트인가"는 이제 구현이 아니라 관점의 문제다. 어제의 에이전트가 오늘의 하위 도구가 되는 재귀 구조가 이미 일상이 됐다.
• 멀티 에이전트와 MCP 서버 내부 처리 사이의 선택은 안정성 대 단순성의 문제다. 복잡한 조합 작업을 서버 뒤로 감추는 편이 관리하기 쉽지만, 확장 여지는 도구 설계의 한계에 묶인다.

자주 묻는 질문

관련 AI 소식