안녕하세요. 김태영입니다. 이번에는 일반인들도 A2A와 MCP 개념을 익힐 수 있도록 간단하게 영상으로 만들어봤습니다. 영상은 개념 설명에 집중했고, 본 글은 영상 개념을 바탕으로 추가 정보를 수집하여 기술했습니다.

LLM의 등장과 활용 방식의 변화

몇 년 전만 해도 인공지능과 대화한다는 것은 SF 영화 같은 이야기였습니다. 하지만 GPT-3와 GPT-4 같은 대규모 언어 모델(LLM)의 등장으로 이내 현실이 되었죠. LLM은 방대한 데이터로 학습되어 사람이 묻는 거의 모든 질문에 그럴듯한 대답을 내놓을 수 있게 되었습니다. 초창기에는 주로 질문에 답하거나, 글을 요약·생성하는 챗봇이나 AI 비서 형태로 활용됐습니다. 예를 들어 ChatGPT는 사람과 대화를 주고받으며 지식을 전달하는 역할을 했고, 개발자들은 코드 작성 보조 도구(Copilot)로 활용하며 편리함을 느꼈습니다.

이러한 LLM 활용 방식은 시간이 지나면서 점차 고도화되었습니다. 단순히 답변을 출력하는 것을 넘어, 사용자의 복잡한 요구를 처리하거나 여러 단계를 거쳐 목표를 달성하는 방향으로 진화한 것이죠. 특히 2023년 무렵부터 사람들은 LLM에게 한 번의 지시만으로 더 큰 목표를 달성시키고자 하는 시도를 시작했습니다. 예를 들어 “주말 여행 계획 세워줘”라고 하면 LLM이 여행 정보를 검색하고, 일정을 짜고, 필요한 예약까지 추천해주는 식입니다. 이를 위해 LLM 스스로 외부 도구(예: 웹 검색, 계산기, 데이터베이스 등)를 사용하거나 여러 가지 단계를 자율적으로 진행하도록 만드는 새로운 활용 패턴이 나타났습니다. 다시 말해, LLM을 하나의 에이전트(agent)처럼 움직이게 하는 실험이 시작된 것입니다.

에이전트 개념의 등장 배경

여기서 말하는 에이전트(agent)란, 스스로 판단하고 행동할 수 있는 AI 시스템을 뜻합니다. 전통적인 컴퓨터 공학에서 에이전트는 환경을 인지하고(Perceive), 판단을 내린 뒤(Decide), 그에 따라 행동(Act)할 수 있는 주체를 의미합니다. LLM이 발전하면서 이 개념이 현실화되었는데, 이제 LLM 기반 에이전트는 사람의 지시를 받아 적절한 행동 순서를 스스로 계획하고 실행할 수 있게 되었습니다. 예를 들어, 이메일 답장을 대신 써주는 AI를 생각해봅시다. 단순히 글만 생성하는 것이 아니라, 받은 편지함을 훑어보고(Perceive), 어떤 내용으로 답장할지 결정하고(Decide), 실제로 답장을 작성해 보내는 행동(Act)까지 하는 것이죠. 이것이 가능하려면 AI가 주변 외부 세계와 상호작용할 수 있어야 합니다. 지금까지는 사람이 이러한 툴을 직접 사용했죠.

에이전트 개념이 주목받게 된 배경에는 LLM의 한계를 보완하려는 필요성이 있었습니다. LLM은 훈련 데이터에 없는 최신 정보나 개별 사용자의 개인 데이터는 알 수 없다는 한계가 있습니다. 이를 극복하는 방법으로 “도구(tool)”를 사용하는 아이디어가 나왔습니다. 도구란 AI가 외부 시스템에 접근할 수 있게 해주는 기능으로, 예를 들어 웹 검색 API, 데이터베이스 질의, 계산 기능, 코딩 실행 등이 해당됩니다. LLM에게 이런 도구들을 제공하면 마치 만능열쇠를 준 것처럼, 원래 모델이 알 수 없던 최신 정보도 찾아보고 필요한 작업도 수행할 수 있게 됩니다. 실제로 2023년 초 발표된 ReAct라는 논문은 LLM이 “생각(Thought)→행동(Action)→관찰(Observation)”의 반복 과정을 통해 도구를 사용하며 문제를 해결하는 체계를 제안했고, 이러한 에이전트 논리를 구현한 프레임워크들이 속속 등장했습니다. 대표적인 예로, 파이썬 코드를 통해 LLM이 행동하도록 돕는 LangChain 라이브러리가 있고, 2023년 4월에는 Auto-GPT와 BabyAGI 같은 자율 에이전트 실험 프로젝트가 깃허브에서 폭발적인 인기를 끌었습니다. 불과 한 달 만에 Auto-GPT 깃허브 프로젝트에 5만 명이 넘는 개발자가 몰렸다는 소식은 업계의 관심이 얼마나 컸는지를 보여줍니다. 이처럼 LLM을 더 능동적으로 활용하려는 시도가 늘어나면서, 에이전트 개념은 빠르게 확산되었습니다.

이제 에이전트 AI는 단순한 챗봇을 넘어, 복잡한 목표를 스스로 달성하는 자동화 시스템의 핵심으로 여겨지고 있습니다. 마치 사람의 역할을 일부 대신하는 작은 인공지능 비서들이 등장한 셈이죠. 그렇다면 이런 에이전트들이 제대로 일을 하기 위해 무엇이 필요할까요? 바로 외부 세계와의 연결, 그리고 다른 에이전트들과의 협력입니다. 하지만 현실에서는 이 부분에 여러 기술적 장애물이 존재했습니다.

도구 사용과 관련된 기술적 문제점들

에이전트 AI에게 도구 사용 능력을 부여하는 것은 필수적이지만, 이를 구현하면서 여러 문제에 부딪히게 되었습니다. 첫 번째로, 통합의 복잡성 문제를 들 수 있습니다. LLM이 예를 들어 회사 내부 데이터베이스나 사내 문서 저장소에 접근해야 한다고 하면, 개발자는 그때마다 해당 시스템에 접속하는 맞춤형 코드를 일일이 작성해야 했습니다. 이메일, 캘린더, 고객관리 시스템 등 새로운 데이터 출처마다 별도의 연결 방식을 만들어야 했죠. 이러한 조각난 통합(fragmented integration) 방식은 매우 비효율적이고 확장에 한계가 있습니다. 실제로 Anthropic사가 전한 바에 따르면, “새로운 데이터 소스마다 자체 구현이 필요해 진정한 연결형 시스템을 규모 있게 만들기 어려웠다”고 합니다. 서로 다른 API, 인증 방식, 데이터 형식을 가진 수많은 도구들을 일일이 연결하는 건 마치 각기 다른 모양의 콘센트에 맞춰 어댑터를 갈아끼우는 것처럼 번거로운 일이었습니다. 두 번째 문제는 상호운용성의 부재입니다. 예를 들어 OpenAI의 ChatGPT 플러그인은 OpenAI 플랫폼 내에서 작동하도록 만들어져 있고, 다른 LLM이나 시스템과는 호환되지 않았습니다. 반대로 어떤 회사는 자체 커스텀 에이전트를 운영하고 있다면, 그 에이전트만의 도구 연동 방식을 써야 했습니다. 즉 표준이 없기 때문에 한 에이전트에게 만들어준 도구 연결 방식을 다른 에이전트에 재사용하기 어려웠습니다. 결과적으로 개발자들은 비슷한 통합 작업을 여기저기서 중복 수행해야 했고, 에이전트 기술의 발전 속도에 비해 생태계의 통일성은 떨어졌습니다. 또한 보안과 안전의 문제도 있습니다. 에이전트가 외부 도구를 마음껏 실행할 수 있다는 것은 잘못하면 중요 정보를 유출하거나, 권한이 없는 시스템을 건드릴 위험이 있다는 뜻입니다. 그렇다고 완전히 차단하면 에이전트의 유용성이 떨어지니 딜레마입니다. 따라서 안전한 방식으로 LLM 에이전트가 도구를 활용하도록 하는 구조가 필요했습니다. 예컨대, 에이전트가 데이터베이스 질의를 할 때 허용된 범위 내에서만 접근하도록 통제를 걸어준다든지, 회사 내부망을 벗어나지 않고 정보를 주고받도록 중개해주는 시스템이 요구되었습니다. 마지막으로, 멀티턴 대화와 지연 처리의 이슈도 있었습니다. 에이전트가 한 번 도구를 쓰고 끝나는 게 아니라, 때로는 사용자와 여러 차례 대화를 이어가며 중간중간 도구를 사용해야 합니다. 혹은 어떤 작업은 금방 완료되지 않고 시간이 오래 걸릴 수도 있죠. 이러한 긴 호흡의 작업 관리와 대화 맥락 유지 역시 쉽지 않은 과제였습니다. 개별 개발자들이 이 모든 것을 일일이 짜 맞추기에는 상당한 노력이 필요했고, 에이전트 시스템이 커질수록 관리해야 할 복잡성은 기하급수적으로 증가했습니다. 요약하면, LLM 에이전트에게 도구를 쥐여주는 일은 그 자체로 혁신적이지만, 표준 부재로 인한 비효율, 보안 우려, 대화 맥락 관리의 어려움 등 기술적 장애물이 산적해 있었습니다.

이러한 문제를 해결하고자 등장한 것이 바로 MCP(Model Context Protocol)입니다.

MCP의 등장 배경과 구조, 장점

이러한 상황에서 Anthropic은 2024년 말 MCP(Model Context Protocol)라는 오픈 프로토콜(open protocol)을 공개합니다. MCP는 위에서 언급한 도구·데이터 연동 문제를 해결하기 위한 표준화된 규약입니다. 쉽게 말해 “AI를 위한 USB-C 포트”라고 비유할 수 있습니다. 여러 기기를 하나의 단일한 포트(USB-C)로 연결하듯이, MCP를 통해 다양한 외부 데이터 소스와 도구를 LLM에 일관되게 연결할 수 있다는 뜻입니다. Anthropic은 “MCP는 AI 시스템과 데이터 소스를 연결하기 위한 보편적이고 개방된 표준”이라 소개하며, 파편화된 통합을 하나의 프로토콜로 대체함으로써 더 쉽고 신뢰할 수 있는 데이터 접근 방식을 제공한다고 밝혔습니다. MCP의 기본 구조는 클라이언트-서버 아키텍처입니다. 여기서 클라이언트는 LLM이나 그를 활용하는 애플리케이션(예: Claude 데스크톱 앱, Cursor AI 등)이고, 서버는 각종 도구나 데이터 소스에 접속하는 기능을 제공하는 작은 프로그램입니다. 예를 들어 Slack 채팅 기록에 접근하는 MCP 서버, 데이터베이스에 질의하는 MCP 서버, 파일 시스템을 탐색하는 MCP 서버 등이 있을 수 있죠. 이들 MCP 서버는 표준화된 방식으로 자신이 제공하는 리소스(데이터)나 도구 기능(API), 또는 자주 쓰는 프롬프트 양식 등을 노출합니다. 그러면 LLM 클라이언트는 동일한 프로토콜 규칙에 따라 이 서버들과 양방향 통신을 하며 필요한 정보를 주고받거나 작업을 실행합니다. 이때 MCP 서버가 제공하는 데이터나 기능은 통일된 형태의 컨텍스트로 LLM에 주어집니다. LLM 입장에서는 어떤 MCP 서버에서 온 정보든 한결같은 방식으로 받아볼 수 있으니, 마치 자신의 입력 컨텍스트를 확장한 것처럼 활용할 수 있습니다. 이를 통해 LLM은 다양한 외부 지식을 실시간으로 얻어와 더 똑똑한 답변을 생성할 수 있게 됩니다. 예를 들어, MCP를 통해 기업의 문서 저장소와 고객 지원 티켓 DB에 연결된 LLM이라면, 사용자의 질문에 답하기 위해 즉석에서 관련 문서를 찾아보고 요약하거나, 과거 티켓 내역을 조회하여 맥락을 파악하는 것이 가능합니다. 결과적으로 더 관련성 높고 맞춤화된 응답이 가능해집니다.

MCP의 장점은 명확합니다. 우선, 개발 생산성이 크게 향상됩니다. 이제 일일이 새로운 커넥터를 만들 필요 없이 표준 프로토콜에 맞춰 개발하면 되므로, 한 번 만들어진 MCP 서버는 어디서나 재사용될 수 있습니다. 실제로 Anthropic은 공개와 동시에 여러 오픈소스 MCP 서버 구현체를 공유했는데, Google Drive, Slack, GitHub, Postgres DB 등 인기 서비스용 서버들이 이미 준비되어 있습니다. 개발자는 이를 그대로 쓰거나 필요에 따라 수정하면 되고, 자신이 만든 MCP 서버도 공개해 다른 이들과 공유할 수 있습니다. 이러한 에코시스템 효과로 짧은 시간 안에 다양한 도구들이 MCP 표준을 지원하게 되었습니다. 나아가 MCP는 모델 불가지론적(model-agnostic)이라서 특정 LLM 제품에 종속되지 않습니다. OpenAI의 GPT든 Anthropic의 Claude든 혹은 오픈소스 LLM이든, MCP 클라이언트 역량만 갖추면 똑같이 외부 도구를 활용할 수 있습니다. 이는 기업 입장에서 벤더 종속성을 줄이고 유연성을 얻는 이점이 있습니다. 보안 측면에서도 MCP는 고심하여 설계되었습니다. MCP 서버는 필요한 최소 권한만으로 특정 기능만 제공하도록 되어 있어, LLM이 곧바로 민감한 내부 시스템 전체를 통째로 접근하는 일을 막아줍니다. 모든 통신은 명시적인 요청과 응답의 형태로 이루어지므로 기록과 통제가 용이합니다. Anthropic은 MCP를 통해 “데이터를 여러분의 인프라 내에서 안전하게 지키며 LLM이 활용할 수 있게 한다”고 강조합니다. 예컨대, 회사 내부망에서만 동작하는 MCP 서버로 파일을 읽게 하면 외부로 그 내용이 유출되지 않도록 차단할 수 있습니다. 이러한 통제 가능성은 기업들이 안심하고 LLM 에이전트를 도입할 수 있는 기반이 됩니다. MCP는 등장 이후 빠르게 관심과 지지를 얻고 있습니다. Anthropic이 밝힌 바에 따르면 이미 Block, Apollo 같은 초기 도입 기업들이 MCP를 시스템에 통합했고, Zed, Replit, Codeium 등 여러 개발 도구 회사들도 MCP를 활용해 자사 플랫폼을 강화하고 있다고 합니다. 심지어 OpenAI도 2025년에 들어와 MCP 표준을 지지하는 입장을 밝혔다는 소식이 전해져, 사실상의 업계 표준으로 자리잡을 가능성이 한층 높아졌습니다. 이처럼 MCP는 LLM 에이전트에게 날개를 달아주는 프로토콜이라고 할 수 있습니다. 이제 에이전트는 필요한 데이터를 자유롭게 얻고 다양한 도구를 활용하면서도, 개발과 관리 측면에서는 훨씬 단순하고 안전하게 운용될 수 있게 되었습니다.

에이전트 간 협력의 필요성과 A2A의 등장

MCP가 에이전트 대 외부도구의 연결을 표준화했다면, 다음으로 남은 도전은 에이전트 대 에이전트의 연결이었습니다. 현실 세계의 복잡한 문제를 풀기 위해서는 하나의 에이전트만으로 부족할 때가 많습니다. 사람으로 비유하면, 전문 분야가 다른 동료들끼리 팀을 이루어 협업해야 더 나은 결과를 얻을 수 있는 상황이 있는 것이죠. 마찬가지로 AI 에이전트들도 서로 협력하도록 만들면 훨씬 강력해질 수 있습니다. 예컨대 한 에이전트는 회계 업무에 특화되어 있고 다른 하나는 일정 관리를 잘 한다면, 이 둘이 함께 상호작용하여 회사의 복잡한 프로젝트를 자동화할 수 있을 것입니다. 또는 사용자의 개인 비서 에이전트가 어떤 쇼핑 웹사이트의 상품 추천 에이전트와 대화하며 대신 구매 절차를 진행할 수도 있겠죠. 이러한 다중 에이전트 시나리오에서는 에이전트들끼리 원활히 소통하고 조율하는 능력이 필수입니다. 하지만 지금까지는 각기 다른 에이전트 시스템들을 함께 동작시키기가 어려웠습니다. 이기종의 에이전트는 아래 그림과 같이 사용자가 각각 따로 이용을 해야합니다. 현재 ChatGPT나 클로드 등의 여러 AI 서비스를 동시에 띄워놓고 사용하시는 분들도 계실 껍니다.

서로 다른 프레임워크로 만들어진 에이전트들은 말 그대로 각자 섬처럼 고립되어 있었고, 협력시키려면 같은 환경 내에 강제로 묶어놓는 식으로 구현해야 했습니다. 예를 들어 LangChain으로 만든 에이전트와 별도의 플랫폼에서 돌아가는 에이전트를 함께 쓰려면, 개발자가 둘 사이에 커스텀 브릿지 코드를 작성해야 했습니다. 이는 도구 통합 문제 못지않게 번거로운 일이었죠.

이러한 배경에서 구글(Google)이 나서서 2025년 초 A2A(Agent-to-Agent) 프로토콜을 공개하게 됩니다. A2A는 이름 그대로 에이전트들끼리 직접 통신하기 위한 표준 프로토콜입니다.구글은 다양한 기업들과 협력하여 (Atlassian, Salesforce, SAP, LangChain 등 50여 곳이 참여) 이 프로토콜을 공동 설계했고, 이를 오픈 소스 형태로 공개하여 누구나 활용할 수 있도록 했습니다. 구글 발표에 따르면 A2A의 목표는 서로 다른 벤더나 프레임워크로 만들어진 에이전트들도 한데 어울려 협력할 수 있는 동적 다중 에이전트 생태계를 구축하는 데 있습니다. 다시 말해, A2A를 따르면 마치 모든 에이전트들이 공통 언어를 습득하는 셈이어서, 서로 모르는 사이여도 바로 소통하고 같이 일할 수 있게 되는 것이죠.

이는 기업 입장에서도 큰 이익인데, 부서마다 도입한 AI 에이전트들이 제각각이라도 A2A만 지원하면 한 팀처럼 엮어서 활용할 수 있으니 생산성이 극대화되고 운영비용은 절감될 것이라고 구글은 강조했습니다. 그렇다면 A2A 프로토콜은 어떤 방식으로 에이전트 협력을 가능하게 할까요? 우선 A2A에서는 각 에이전트가 자신을 나타내는 “에이전트 카드(agent card)”라는 정보를 웹 상에 공개합니다. 이 카드는 .well-known/agent.json 같은 표준 위치에 놓이는 일종의 메타데이터 파일로, 해당 에이전트의 능력(예: “일정 관리 가능”, “데이터 분석 가능” 등), 접속 주소(URL), 버전, 그리고 필요한 인증 방식 등을 명시합니다. 다른 에이전트는 이 카드를 열람함으로써 상대를 발견하고 상호작용을 시작할 준비를 할 수 있습니다. 이는 사람이 서로 명함을 주고받고 소개하는 과정과 비슷합니다. 한 에이전트가 “내가 할 수 있는 일 목록은 이렇고, 나에게 연락하려면 이 주소로 요청을 보내”라고 공개한다고 생각해보세요. 에이전트 간 통신은 HTTP 기반으로 이루어집니다. A2A 프로토콜에 따르면, 기본적으로 하나의 에이전트는 서버(Server) 역할을 하고 다른 하나는 클라이언트(Client) 역할로서 요청을 주고받게 됩니다. 예를 들어 A 에이전트(클라이언트)가 B 에이전트(서버)에게 “이러이러한 작업을 수행해줘”라고 HTTP 요청을 보내면, B는 그 작업을 실행하고 결과를 응답으로 보내주는 식입니다. A2A 프로토콜은 이종 에이전트들 사이의 의사소통과 협동 작업을 위한 공용 언어와 규칙을 제시한다고 볼 수 있습니다. 이를 도입함으로써 개발자들은 특정 프레임워크에 구애받지 않고 자유롭게 여러 에이전트를 조합해 시스템을 구축할 수 있고, 사용자는 겉보기에는 하나의 AI 앱을 쓰는 듯하지만 그 뒤에서는 여러 전문 에이전트들이 팀을 이뤄 돌아가고 있는 강력한 경험을 누릴 수 있게 됩니다. 구글은 내부 대규모 에이전트 시스템을 운영하며 겪은 도전들을 토대로 A2A를 설계했다며, 이것이 미래 AI의 상호운용성(universal interoperability)을 위한 필수 요소입니다.

MCP와 A2A의 차이점과 상호 보완 관계

이쯤에서 의문이 생길 수 있습니다. MCP와 A2A는 무엇이 다르고, 둘은 어떻게 함께 쓰일까요? 간단히 말해 MCP는 에이전트와 “도구/데이터”를 연결하는 프로토콜이고, A2A는 에이전트와 “다른 에이전트”를 연결하는 프로토콜입니다. 각각 초점이 다르기 때문에 경쟁하는 관계라기보다 서로 보완적인 관계로 보는 것이 맞습니다. 실제로 구글도 A2A를 발표하면서 “Anthropic의 MCP가 에이전트에게 유용한 도구와 컨텍스트를 제공해준다면, A2A는 에이전트들 간의 협력을 가능케 하는 보완적 관계”라고 설명했습니다. 두 프로토콜은 AI 에이전트 생태계의 서로 다른 영역의 문제를 풀어주고 있는 셈입니다. 차이점을 조금 더 구체적으로 살펴볼까요? MCP는 앞서 언급했듯 단일 또는 소수의 LLM 프로세스에 외부 지식과 기능을 공급하는 데 집중합니다. 따라서 MCP는 그 LLM이 필요한 데이터를 얻거나 액션을 취할 수 있도록 파일, DB, API 등과의 인터페이스를 표준화해주는 것입니다. 반면 A2A는 여러 개의 독립적인 에이전트 프로세스가 상호 대화하고 작업을 주고받는 방식을 정의합니다. A2A에는 특정 도구와 직접 연결하는 기능은 없고, 어디까지나 “동료 에이전트에게 도움을 요청”하는 형태입니다. 예를 들어 어떤 물류 관리 에이전트가 재고를 조회해야 한다면, A2A를 통해 재고 조회 에이전트에게 말을 걸 수 있지만, 만약 그 재고 조회가 실제 데이터베이스 질의를 필요로 한다면 그 부분은 재고 에이전트 쪽에서 MCP 등을 통해 처리하게 될 것입니다. 이렇듯 A2A는 에이전트 대 에이전트 대화, MCP는 에이전트 대 툴 대화로 구분됩니다. 다만 경우에 따라 경계가 모호해질 수는 있습니다. 예를 들어 매우 고도화된 도구(예: 스스로 판단하는 로봇 시스템)는 사실상 하나의 에이전트처럼 동작할 수도 있고, 반대로 단순한 에이전트는 도구처럼 취급될 수도 있습니다. 이런 이유로 일각에서는 장기적으로 MCP와 A2A가 경합하거나 통합되지 않겠냐는 예상도 있습니다. 하지만 현재로서는 두 프로토콜이 명확히 다른 문제 영역에 집중하고 있고, 함께 사용할 때 시너지가 크다고 보는 견해가 지배적입니다. 이처럼 MCP는 개별 에이전트의 손과 발을 넓혀주고, A2A는 여러 에이전트를 한 팀으로 묶어준다고 정리할 수 있겠습니다. 결국 궁극적으로 복잡한 AI 서비스를 만들 때는 MCP와 A2A를 함께 활용하게 될 가능성이 큽니다. 한 에이전트가 MCP로 외부 정보를 수집하고 작업을 수행하면서, 동시에 A2A로 다른 전문 에이전트들과 협업하여 전체적인 목표를 달성하는 식입니다. 예컨대 당신의 개인 비서 에이전트는 MCP로 이메일과 캘린더 정보를 얻고 회사 내부 시스템에 안전하게 접근하면서, A2A로 회사의 재무 담당 에이전트나 인사 담당 에이전트와 대화를 주고받으며 일을 처리할 수 있을 것입니다. 이렇게 되면 마치 여러 명의 직원들이 각자 컴퓨터와 도구를 다루며 회의까지 해가며 일하는 것을 AI들이 대신해주는 그림이 그려지죠. MCP가 데이터의 맥락(Context)을 책임지고, A2A가 에이전트 간 의사소통을 책임진다고 이해하면 쉽겠습니다.

에이전트 생태계의 발전 가능성과 미래 전망

MCP와 A2A의 등장은 AI 에이전트 생태계에 있어서 획기적인 전환점으로 평가받습니다. 이제 AI 업계는 개별 모델의 성능 향상만이 아니라, 여러 모델과 시스템의 연결과 협업이라는 새로운 지평으로 나아가고 있습니다. 이러한 표준 프로토콜들의 도입으로 기대되는 미래상은 매우 흥미롭습니다. 우선, AI 에이전트의 생태계가 본격적으로 형성될 가능성이 높습니다. 과거에는 각 기업이나 연구팀이 자체적으로 폐쇄된 에이전트 솔루션을 개발했다면, 이제는 MCP와 A2A 같은 공용 인프라 위에서 다양한 에이전트와 도구가 호환성을 갖고 등장할 수 있습니다. 이는 스마트폰 등장 이후 앱 생태계가 폭발적으로 성장한 것과 비견할 수 있습니다. 표준화된 플랫폼 덕분에 수많은 써드파티 앱이 나왔듯, 표준화된 에이전트 프로토콜 덕분에 누구나 자신만의 에이전트나 MCP 도구를 만들어 배포할 수 있는 환경이 기대됩니다. 실제로 벌써부터 오픈소스로 다양한 MCP 커넥터가 공유되고 있고, 여러 AI 회사들이 A2A 합류를 선언하는 등 움직임이 일어나고 있습니다. 또한 이종 업체 간의 협력도 원활해질 전망입니다. 예를 들어 한 기업의 제품이 Anthropic의 Claude 모델을 기반으로 한 에이전트를 쓰고, 다른 기업의 서비스는 GPT-4 기반 에이전트를 쓰더라도, 둘 다 A2A만 따른다면 두 에이전트가 직접 대화하며 작업을 연계할 수 있습니다. 이는 마치 이메일이 어떤 메일 서버를 쓰든지 간에 인터넷 표준을 따르기만 하면 서로 주고받을 수 있는 것과 같습니다. 보편성은 기술 확산의 강력한 동력이므로, 언젠가 A2A나 MCP가 지금의 HTTP나 TCP/IP처럼 눈에 보이지 않지만 어디서나 쓰이는 기본 인프라로 자리잡을 가능성도 있습니다. 물론 경쟁과 조율의 과정은 있을 것입니다. 현재도 A2A와 MCP 외에 IBM이 주도하는 ACP(Agent Communication Protocol) 같은 또 다른 프로토콜도 나오고 있고, 기존의 개별 솔루션들이 완전히 사라진 것은 아니기 때문입니다. 업계 전문가들은 개발자들이 동시에 너무 많은 프로토콜을 학습하고 지원할 수는 없으니 결국 몇 가지로 표준이 수렴될 것이라고 내다봅니다. 구글과 Anthropic이 손잡고 A2A와 MCP의 상호연동성을 강조하는 것을 보면, 향후에는 두 프로토콜이 사실상 한 세트로 굳어질 가능성도 있습니다. 한편으로 오픈소스 커뮤니티의 역할도 중요해서, 모두가 참여해 개선해가는 과정에서 더 나은 통합안이 나올 수도 있습니다. 기술적인 발전 외에도, 사회적 영향과 활용 분야에 대한 고민도 필요합니다. 여러 에이전트가 자율적으로 움직이는 미래에서는 인간의 개입이 줄어드는 만큼, 오작동 시의 책임 소재, 윤리적인 의사결정, 보안 위험 등에 대한 새로운 기준이 요구될 것입니다. 다행히도 A2A나 MCP 모두 접근 통제와 투명성을 염두에 두고 설계되어 있어 이런 문제 해결의 토대가 되고 있습니다. 예를 들어 A2A는 기업용 인증/인가 체계를 지원하고, MCP도 내부 인프라 내에서의 안전한 데이터 활용을 강조합니다. 앞으로 표준 프로토콜이 발전하면서 감사(logging) 기능, 사용 권한 관리, 악의적 에이전트 대응 등도 함께 고도화될 것으로 보입니다. 기술의 진화 방향이 개방성, 협업, 상호운용성을 지향하는 한, 에이전트 생태계의 미래는 밝다고 하겠습니다. 새로운 에이전트 시대의 전개를 지켜보며, 그 가능성을 모두가 함께 누릴 수 있기를 기대합니다.

A2A와 MCP 다 품은 어시웍스 - 1부 A2A, MCP 개념잡기