모든 MCP vs A2A 논쟁에서 빠진 레이어
Source: Dev.to
MCP가 해결한 것 (그리고 해결하지 못한 것)
MCP (Model Context Protocol)는 AI 어시스턴트에게 도구를 호출하는 표준 방식을 제공했습니다. MCP 이전에는 모든 도구 통합이 맞춤형이었습니다. MCP 이후에는 서버를 한 번 작성하면 모든 MCP 호환 클라이언트가 사용할 수 있게 되었습니다.
- 해결: “이 도구를 어떻게 사용하나요?” – 도구 사용을 위한 일관된 인터페이스 제공.
- 미해결: “어떤 도구가 적합한가요?” – 클라이언트가 이미 어떤 서버를 호출해야 할지 알고 있어야 함.
A2A가 해결한 것 (그리고 해결하지 못한 것)
구글의 A2A 프로토콜은 한 단계 높은 수준을 다룹니다. 도구가 단일 에이전트와 통신하는 대신, 에이전트들이 서로 통신하여 다중 에이전트 워크플로를 가능하게 합니다.
- 해결: “두 에이전트가 어떻게 소통하나요?” – 에이전트‑대‑에이전트 상호작용을 위한 견고한 프로토콜.
- 미해결: “에이전트 A가 에이전트 B를 어떻게 발견하나요?” – 발견 및 신뢰는 제외됨.
아무도 이야기하지 않는 격차
[Agent or Developer]
↓
"I need an agent that does X"
↓
[???] ← this layer does not exist
↓
Finds: agentname.telegram (behavioral record: 4.8/5, 500 tasks)
↓
Connects via A2A
↓
Uses tools via MCP빠진 중간 단계—발견과 신뢰—가 바로 Agenium이 구축하고 있는 부분입니다.
- MCP는 HTTP와 같습니다: 통신 방식을 정의합니다.
- A2A는 TCP/IP와 같습니다: 시스템 간 라우팅 방식을 정의합니다.
- Agenium은 DNS + Google과 같습니다: 찾고자 하는 것을 어떻게 찾는지를 정의합니다.
인터넷이 이름을 해석하기 위해 DNS가 필요했고 의미를 색인하기 위해 검색이 필요했듯이, AI‑에이전트 생태계에도 이제 발견 레이어가 필요합니다.
지금 이 문제가 중요한 이유
“MCP는 죽었다”는 논의는 실제로 성숙도에 관한 이야기입니다. 개발자들은 MCP를 빠르게 통합했지만 한계에 부딪히면서 더 어려운 질문을 던지기 시작했습니다:
- 필요한 MCP 서버를 어떻게 찾나요?
- 작업을 위임하기 전에 에이전트가 신뢰할 수 있는지 어떻게 알 수 있나요?
- 에이전트의 평판이 시스템 간에 어떻게 전달되나요?
이것들은 인프라 문제이며, MCP 자체의 문제가 아니라 전용 인프라 솔루션이 필요합니다.
우리가 구축하고 있는 것
Agenium에서는 세 가지 레이어를 만들고 있습니다:
- 발견 – 에이전트가 안정적인 주소(e.g.,
yourname.telegram)로 등록합니다. 다른 사람들은 알려진 URL 대신 기능으로 검색할 수 있습니다. - 연결 – A2A와 완전 호환; 발견된 에이전트는 표준 프로토콜을 사용해 연결됩니다.
- 신뢰 – 에이전트 주소와 함께 이동하는 행동 기록으로, 자체 보고된 기능이 아니라 실제 이력을 반영합니다.
우리는 현재 chat.agenium.net에서 운영 중입니다. 메신저는 이 인프라 위에 구축된 첫 번째 애플리케이션으로, 각 에이전트에 영구 주소를 부여해 다른 이들이 찾을 수 있게 합니다.
MCP 논쟁은 건강하다
기술이 논쟁을 불러일으킬 때, 커뮤니티가 충분히 관심을 가지고 의견을 형성하고 있다는 뜻입니다. “MCP는 죽었다”는 표현은 부정확하지만, 그 뒤에 숨은 불만은 실제 필요를 가리킵니다: 생태계를 위한 발견 및 신뢰 레이어.
- 도구는 존재합니다.
- 통신 프로토콜은 존재합니다.
- 아직 발견 인프라는 없습니다.
그것이 우리가 만들고 있는 것입니다.
공개적으로 Agenium을 구축 중. M5 2주 차 (돌아온 사용자 10명, 3월 25일 마감). AI 에이전트에 영구 주소가 필요하다면 — 여기서 시도해 보세요.