안녕하세요. ‘델피가 대신 말아주는 딥테크 이야기’로 인사드립니다. 투자팀 인턴 델피입니다. 제로가 자리를 비우신 틈을 타 제가 한번 키보드를 잡아보았습니다. 😏
오늘은 지난 글에서 간단히 언급했던 키워드, MCP와 A2A에 대해 이야기해보려 합니다.

지난 글에서는 AI 에이전트가 되기 위한 다섯 가지 조건을 짚어보면서, 그중에서도 Connection과 Customization 영역에 스타트업의 기회가 남아 있다고 말씀드렸는데요. 한 달 정도 지난 지금 시점에서 MCP와 A2A는 기대 수준의 진전을 넘어, 눈에 띄는 변화로 현실화되고 있다는 걸 느낄 수 있습니다.
그래서 오늘은 하나의 프로토콜일 뿐인 MCP와 A2A가 어떻게 사실상 표준으로 자리 잡게 되었는지, Agent로의 길을 어떻게 단축시키고 있는지 함께 살펴보려고 합니다.
1. MCP 이것 뭐예요?
AI Agent 이야기가 나올 때마다 자주 등장하는 개념이 있습니다. 바로 MCP, Model Context Protocol인데요. 사실 그리 특별한 건 아닙니다. (ㅎㅎ)
MCP란 무엇인가요?
MCP는 작년 11월 Anthropic이 공개한 표준 프로토콜입니다. 쉽게 말해, LLM이 외부 리소스나 도구를 사용할 수 있게 도와주는 일종의 설명서인데요. 기존 웹의 HTTP나 API처럼, LLM이 외부 Tool을 호출하고 상호작용할 수 있게 해주는 방법을 정의한 것입니다.
지금까지의 LLM이 사용자들에게 훈수만 두는 대감마님 같았다고 한다면, MCP가 등장하면서 AI 에이전트가 직접 일을 수행할 수 있게 도구를 잡는 방법을 알려주었다고 생각하면 됩니다. 이렇게 비유하더라도 잘 안 와닿을 수 있으니, AI 에이전트의 구조를 한번 뜯어보며 MCP가 어떤 역할을 담당하는지 살펴볼게요.
MCP는 AI Agent를 구성하고 있는 요소 중 LLM과 외부 툴을 이어주는 작은 연결고리일 뿐입니다. 눈에 띄는 기능도 없고, 실제로 '작동'하는 것도 아닌 설명서 수준의 구조인데요. "이게 뭐 대단하다고?"싶으시다면, 매우 정확하게 접근하신 겁니다. 실제로 MCP는 올해 3월 전까지만 해도 거의 관심을 못 받았어요.
하지만 기술이란 게 원래 그렇습니다. MCP는 흔히 말하는 ‘C타입 케이블’ 같은 존재예요. 구형 포트를 신형 포트에 꽂으려면 결국 어댑터가 필요하듯, 서로 다른 에이전트, 툴, 모델들을 편하게 연결되기 위해선 이런 작지만 표준화된 인터페이스가 꼭 필요합니다.
Cursor를 시작으로, 다들 MCP 노를 젓기 시작했어요
올해 초 Cursor는 자사 플랫폼 내에서 Claude LLM을 기반으로 한 MCP 연동 기능을 도입했습니다. 이제 개발자는 MCP 포맷으로 툴을 정의해두기만 하면, Claude(LLM)가 툴을 자동으로 인식해 필요에 따라 호출할 수 있게 되었으며, Cursor는 그 툴 실행과정을 UI 상에서 시각적으로 보여주고 사용자 조작도 가능하게끔 만들었어요.
조금 더 풀어서 이야기해보자면, MCP는 외국어 교과서, LLM인 Claude는 그 언어를 읽을 수 있는 학생이라면, Cursor는 그 학생이 실제로 말하고 행동할 수 있는 교실 환경을 만들어준 셈입니다.
즉, MCP는 처음으로 ‘작동하는 생태계’를 갖추게 된 것입니다. 이전까지는 그저 기술 문서였던 MCP가, Cursor의 지원을 통해 현실에서 LLM과 툴을 연결하는 실질적인 표준으로 작동하기 시작했어요. 이것이 바로 MCP가 단순한 프로토콜에서 ‘AI 생태계의 언어’로 발전하게 된 전환점입니다.
최근 들어 Cursor 외에 다양한 개발 도구와 플랫폼에서 MCP를 핵심 연결 규약으로 받아들이는 움직임이 본격화되고 있습니다. 단순히 툴을 호출하는 기능을 넘어서, 툴을 정의하고 공유하며, 여러 에이전트가 함께 사용하는 표준으로 자리 잡아가고 있는 것이죠.
대표적으로 다음과 같은 흐름이 나타나고 있습니다:
AI 마켓 플레이스에서의 MCP 통합 시도
MCP + OSS 툴킷 통합 시도 : 나만의 MCP 기반 에이전트 실행 환경 구축
MCP 확장 프로토콜 제안 (MCP-Mod, MCP-A2A 등)
이처럼 MCP는 단순한 설명서 수준의 프로토콜에서 벗어나, 툴 정의 → 실행 → 공유 → 협력까지 아우르는 새로운 실행 언어로 진화하고 있습니다. 지금은 "우리가 MCP 지원해 줄게! 너희도 같이 만들어보자"는 분위기 속에서 개발자와 기업들이 시장에 뛰어드는 초기 확산기라고 볼 수 있겠습니다.
MCP로 뭐가 달라지긴 한 건가요? (feat. SDK)
"그럼 MCP가 등장하기 전에는 어떻게 했던 거지?" 이 질문에 답하기 위해 SDK 개념부터 짚고 넘어가려 합니다.
SDK(Software Development Kit)란 특정 기능이나 서비스를 다른 소프트웨어에 통합할 수 있도록 도와주는 도구 모음입니다. 예를 들어, 구글 번역 기능을 앱에 넣고 싶다면, 구글 SDK를 사용하면 개발자는 복잡한 기능을 직접 구현하지 않고도 손쉽게 해당 기능을 쓸 수 있습니다.
하지만 이러한 방식에는 한 가지 대전제가 깔려 있는데요. SDK는 "사람 개발자"가 사용할 것으로 전제로 설계되었다는 점입니다.
지금처럼 사람이 아닌 AI model 즉 LLM이 외부 도구를 직접 사용할 수 있어야 하는 시대엔, SDK 방식으론 한계가 많습니다. 간단한 예시로, Claude나 GPT와 같은 LLM이 웹 검색을 하거나, Notion 문서를 읽거나, 코드를 실행해야 하는 상황을 떠올릴 수 있을 텐데요.
매번 프레임워크 (LangChain, AutoGen… 등)마다 SDK를 따로 만들어야 하고, 도구가 업데이트되면 SDK도 다시 고쳐야 하고, 사람이 직접 연결하고 테스트해줘야 합니다. 이런 맥락에서는 SDK를 빠르고 잘 세팅해 주는 개발자에게 어쩌면 MCP는 필요하지 않은 방식일지도 모릅니다.
MCP vs SDK, 한눈에 정리했어요
결국 MCP란 직전에 언급한 문제를 해결하기 위한 ‘표준화된 ‘도구 설명서 형식’입니다. 사람 대신 AI가 읽을 수 있도록, 도구를 JSON-RPC 기반의 구조화된 방식으로 정의한 거죠. MCP는 JSON-RPC 기반의 요청/응답 구조를 따르는데, 함수 호출과 비슷한 구조라서 LLM이 논리적 계획을 짤 때 자연스럽게 추론할 수 있다는 장점이 있어요.
MCP 덕분에 LLM은 아래와 같은 툴을 정의하는 설명서를 보고 어떤 도구인지 파악하고, 필요한 입력값을 결정하고, 스스로 호출할 수 있게 됩니다.
☀️
{ "name": "get_weather", "description": "도시 이름으로 날씨 정보를 불러옵니다", "parameters": { "city": { "type": "string" } } }
무엇보다 중요한 건, 이러한 포맷이 프레임워크에 종속되지 않는다는 점입니다. 결국, 도구 제공자 입장에서는 더 이상 LangChain용 SDK, AutoGen용 SDK를 따로 만들 필요가 없어지고, MCP 하나만 제공하면 AI가 알아서 쓸 수 있는 시대가 온 것이죠.
항목 | 기존 SDK 방식 | MCP 방식 |
---|---|---|
대상 | 사람 개발자 | LLM (AI) |
통합 방식 | 프레임워크별 SDK 따로 개발 | MCP 하나로 통일 |
유지보수 | 도구 업데이트 시 SDK도 수정 필요 | MCP 스펙만 업데이트하면 끝 |
유연성 | 특정 플랫폼에 의존 | 다양한 플랫폼에서 사용 가능 |
이처럼 MCP는 LLM이 외부 도구를 사용할 수 있게 만들어준 하나의 표준이었습니다. 그런데 이제, 도구뿐만 아니라 다른 에이전트와도 협업해야 하는 시대가 오고 있습니다. (사실 이미 와버린 것 같기도 하고요. 속닥속닥)
2. A2A, 이건 또 뭐예요?
도구를 넘어서, 이제는 Agent끼리 대화하는 시대
앞에서 살펴본 MCP가 LLM이 외부 도구를 사용할 수 있도록 만든 약속된 형식이었다면, 이번에 다룰 A2A(Agent-to-Agent)는 AI 에이전트끼리 협업하고 조율할 수 있도록 만든 대화 규칙입니다.
왜 이런 게 필요하게 되었을까요? 이제 LLM이 단순히 도구를 활용하는 것을 넘어서 다른 LLM 또는 Agent와 상호작용하며 함께 일해야 하는 시대로 접어들었기 때문입니다.
왜 A2A가 필요해졌을까요?
그동안은 LLM 하나가 툴 여러 개를 사용해 문제를 해결하는 방식이 주를 이뤘습니다. 하지만 점점 더 복잡하고 유기적인 작업들이 등장하면서, 하나의 Agent가 모든 역할을 담당하기엔 한계가 생기기 시작했습니다.
예를 들어, 채용 보조 에이전트를 만든다고 가정해 볼게요. 하나의 에이전트가 혼자서 이력서 수집, 평판 조회, 인터뷰 일정 조율, 요약 리포트 생성까지 모두 처리해야 한다면, 한계가 발생합니다. 그래서 등장한 개념이 바로 A2A, 각기 다른 역할의 Agent가 서로 협업할 수 있도록 만든 프로토콜입니다.
정리하자면, A2A란 여러 LLM이 역할을 나눠 함께 일할 수 있도록 만들어진 에이전트 간 메시지 교환 규칙입니다. MCP가 AI ↔ 도구 간의 언어라면, A2A는 Agent ↔ Agent 간의 대화 문법인 셈이죠.
A2A는 어떻게 작동하나요?
A2A의 핵심은 단순합니다. 에이전트마다 자신이 수행 가능한 기능을 "역할(role)"로 정의하고, 서로에게 메시지를 주고받으며, 협업을 통해 더 큰 목적을 달성하게 됩니다.
예를 들어, Agentspace 플랫폼에서 "프론트엔드 엔지니어를 추천해 줘"라고 요청한다고 생각해 볼까요? 작업은 이력서 수집 에이전트 → SNS 분석 에이전트 → 인터뷰 요약 에이전트 → 보고 에이전트 순으로 릴레이처럼 분산되고, 각 에이전트는 상태 공유와 목적 협의를 통해 자율적으로 협업할 수 있게 됩니다. 팀플 하듯 역할을 나누고, 의도와 목적성을 공유하며 협력하는 거죠.
참고로 A2A는 단순한 개념 제안에 그치지 않습니다. A2A 프로토콜은 Google이 2025년 초 오픈소스로 공개한 Agent 협업 표준으로, 이미 50개 이상의 테크 파트너들이 참여하며 Agentspace, LangChain, DSPy, Replit 등 주요 프레임워크에서도 실험적으로 도입되고 있어요. MCP가 도구 연결을 표준화했다면, A2A는 에이전트 간의 대화, 조율, 협업까지 구조화하고 있는 셈입니다.
A2A vs MCP, 한눈에 정리했어요
MCP와 A2A의 차이점을 정리하자면, 한 마디로 도구에서 동료가 된 겁니다. MCP는 AI에게 도구를 사용하는 능력을 부여했습니다. 반면 A2A는 AI에게 협업하고 조율하는 능력을 주었죠. 타겟하는 영역부터 다른 것입니다.
구분 | MCP | A2A |
---|---|---|
목적 | 외부 도구 호출 | 다른 에이전트와의 협업 |
방식 | JSON-RPC 기반 도구 spec | 구조화된 메시지 포맷 기반 대화 |
단위 | LLM ↔ 도구 | Agent ↔ Agent |
사례 | Cursor, Claude, Slack GPT Plugins | Agentspace, CrewAI, Autogen |
이제 우리는 혼자 일 잘하는 AI가 아니라, 함께 일 잘하는 AI를 만드는 시대에 들어섰습니다. MCP와 A2A는 이러한 전환을 상징하는 대표적인 프로토콜이며, 앞으로의 AI 생태계의 기본 문법이 될 가능성이 높습니다.
3. 스타트업의 기회도 탐색해 보았습니다
앞으로 등장할 새로운 에이전트 서비스들은, MCP와 A2A 프로토콜을 중심으로 서로 연결되고 대화하며 일하게 될 것입니다. 이제는 단순한 호출(Call)이 아닌, 의미 있는 상호작용(Interaction)의 시대로 접어들고 있는 건데요.
서론에서 잠시 언급한 내용을 짚고 넘어가자면, Connection과 Customization 두 축 중에서 Connection은 MCP와 A2A를 계기로 뚜렷한 진보를 이뤘습니다. 그렇다면 이제 남은 영역은 Customization, 각 조직과 서비스에 맞는 AI 에이전트의 적용 방식입니다.
1. 오히려 스타트업에게 유리한 판이 열리고 있다
MCP와 A2A의 등장은 일종의 '기술 전환점'입니다. 기존 대형 플랫폼에 의존하던 것에서 벗어나, 소규모 팀이 단일 기능만으로도 에이전트 생태계에 참여할 수 있는 시대가 열리고 있는 건데요.
예전에는 하나의 제품을 만들기 위해 전체 UX, 백오피스, 배포, 분석 기능까지 모두 구현해야 했다면, 이제는 그와 반대로 핵심 기능만 잘 구현한 Agent 하나만으로도 시장 진입이 가능해진 겁니다. 즉, 작은 팀도 "단독 실행 가능한 에이전트 유닛"으로 시장에 진입할 수 있게 된 것이죠.
2. 플랫폼 없이도 시장 진입이 가능하다
불과 얼마 전까지만 해도, OpenAI, LangChain 같은 허브 위에서만 Agent가 움직일 수 있었습니다. 하지만 MCP가 등장하면서 모델이 직접 도구를 호출하고 조합할 수 있는 공통 규격을 제공했는데요.
덕분에 이제 플랫폼 의존 없이 각자 만든 Agent가 직접 시장에서 유통될 수 있는 구조가 가능해졌습니다. 앞으로 Agent Marketplace가 본격적으로 열린다면, 스타트업이 만든 기능형 Agent가 '서비스'처럼 배포될 수도 있겠습니다.
3. 진입장벽이 낮아졌지만, 진짜 실력자만 살아남는다
누구나 Agent를 만들 수 있다는 건, 그만큼 경쟁도 치열해졌다는 뜻입니다. 하지만 이러한 상황은 굳이 원영적 사고를 거치지 않아도 기회입니다. 스타트업에게는 명확한 룰이 생긴 시장, 즉 기술력이 곧 실력인 정정당당한 전장이 생긴 셈이기 때문입니다.
예전처럼 브랜드나 마케팅, 유통망이나 네임밸류에 밀리던 시대가 아니라는 건데요. 지금은 작은 기능이라도 독보적이면 살아남고, 즉각적으로 시장의 반응을 확인할 수 있는 환경이 조성되고 있는 겁니다. 결국 "살아남았다는 것 = 기술이 검증되었다는 것"이 되는 구조인 거죠.
4. 결국 플랫폼은 다시 플랫폼이 될 것이다 — 얼리어답터가 되어라
A2A 시대는 초반엔 분산된 형태처럼 보일 수 있습니다. 하지만 결국은 에이전트들의 연결, 유통, 평가 기준을 장악한 쪽이 새로운 플랫폼이 될 가능성이 높다고 보고 있는데요. 과거 앱스토어가 발전한 경로를 보면 비슷합니다.
그렇기 때문에 지금은 창의적인 Agent가 다양하게 등장할 수 있는 초기 생태계이고, 스타트업 입장에서는 이 생태계 안에서 빠르게 자리 잡을 수 있는 '기회의 창'이 열려 있는 상태라고 보고 있습니다. 그래서 지금은 "완성된 SaaS"를 만드는 것이 아닌 , "Agent화할 수 있는 문제"를 먼저 찾는 것이 훨씬 더 전략적인 선택이라고 느껴지기도 해요.
아직까지 MCP와 A2A는 오픈소스로 배포되며, 구매형 마켓플레이스 형태도 아닙니다. 그리고 실제 적용을 위해서는 설치, 인증, 모니터링, 로깅, 버전 관리 같은 현실적인 문제가 여전히 존재하는데요. 바로 이 지점에서 스타트업의 기회가 생기지 않을까 생각합니다.
MCP-Notion 커넥터 SaaS: 노코드 설치, 관리자 UI, 장애 대응 등 포함된 에이전트 연동 서비스
다양한 에이전트를 연결하고 관리하는 오케스트레이션 플랫폼
Slack, Notion, Vercel 등과 연결된 커넥터 계층 SaaS
향후 A2A에 유료 호출/정산 구조가 붙는다면 Token 기반 수익 모델 가능성도 존재
결국 기술이 표준화되더라도, 현실은 여전히 설정과 운영, 커스터마이징의 싸움입니다. Connection의 물꼬가 트인 지금, 이 거대한 흐름을 어떻게 빠르게, 그리고 쉽게 적용하는가에서 다음 스테이지의 승자가 판가름날 것으로 보입니다.
MCP와 A2A는 그 자체로 대단한 기술이라기보다는, AI 에이전트 생태계를 누구나 조립하고 확장할 수 있게 만드는 공통 언어에 가까운데요. 그리고 지금은 그 언어가 막 통용되기 시작한 시점이고, 문법이 만들어지는 시기입니다.
아직은 초기 시장인 만큼 스타트업에게 생각보다 많은 기회가 남아 있는 시점이라고 생각합니다. 이러한 흐름을 간과하지 않고 누구보다 빠르게 실험하고, 더 나은 실행 방식을 고민해 보는 팀이 다음 시장의 판을 만들 것으로 기대되는데요.
새로운 연결을 시도하고 계신 모든 창업자분들, 진심으로 응원합니다. MCP를 만지작거리며, 에이전트를 붙여보고, AI가 진짜 ‘일을 잘하게’ 만들기 위한 실험을 이어가고 계신다면 저희 카카오벤처스도, 그리고 이 글을 쓴 저 델피도 함께 고민하고 이야기 나누고 싶습니다.
그리고 다음 글에서는, 당신이 지금 창업해야 하는 이유에 대해 카카오벤처스의 VaP Taeho와 나눈 대화를 바탕으로 이야기를 풀어보려 합니다. 카카오벤처스 블로그 이메일 구독해 두시고, 다음 아티클도 놓치지 마세요!
Writer Delphi
Editor Bailey
앞으로도 함께할까요?