개요
AI 에이전트 시스템이 급속도로 발전하면서 MCP(Model Context Protocol)와 A2A(Agent-to-Agent) 프로토콜이 에이전트 개발 생태계의 핵심 표준으로 자리 잡고 있습니다. 이 영상은 이 두 프로토콜이 에이전트 시스템 구축에서 어떤 역할을 하며, 왜 중요한지를 실무적 관점에서 설명합니다.
이 영상은 테디노트(Teddynote)와 모두의AI 케인님의 라이브 하이라이트 편집본입니다. 테디노트는 랭체인(LangChain) 한국어 튜토리얼과 RAG(Retrieval-Augmented Generation) 관련 강의로 국내 AI 개발자 커뮤니티에서 널리 알려진 채널이며, 실무 중심의 AI 기술 콘텐츠를 제공합니다.
핵심 내용
MCP(Model Context Protocol): 툴 통합의 혁명
MCP는 Anthropic이 2024년 11월에 발표한 프로토콜로, LLM(Large Language Model)이 외부 도구와 통합되는 방식을 표준화합니다. 과거에는 Slack, Google Drive, GitHub 등의 서비스를 에이전트에 연결하려면 각 서비스의 API 문서를 읽고 커스텀 함수를 일일이 개발해야 했습니다.
MCP 이전의 비효율적인 상황은 이랬습니다. 모든 개발자가 동일한 API(예: Slack API)를 각자의 에이전트 시스템에 통합하기 위해 반복적으로 문서를 읽고, 비슷한 래핑(wrapping) 코드를 작성했습니다. 이는 전체 개발 생태계 차원에서 엄청난 중복 작업이었습니다.
MCP가 이 문제를 해결한 방식은 간단하지만 강력합니다. 서비스 제공자(Slack, Google Drive 등)가 직접 MCP 서버를 만들어 공식 배포합니다. 이제 개발자는 약 10초 만에 해당 MCP 서버를 자신의 에이전트 시스템에 연결할 수 있습니다. 서비스 제공자 입장에서도 자사 서비스를 더 많이 사용하게 만드는 인센티브가 있어 적극적으로 MCP 서버를 개발하고 있습니다.
영상에서는 Anthropic이 MCP를 계속 밀어붙인 전략적 노력도 강조됩니다. 2024년 11월 초기 발표 당시에는 개발자들의 큰 관심을 끌지 못했지만, Anthropic은 워크샵을 열고 유즈 케이스를 확산시키며 개발자 생태계에서 MCP의 명맥을 유지했습니다. 이러한 지속적인 노력 덕분에 에이전트 시스템이 주목받기 시작하면서 MCP가 자연스럽게 표준으로 자리 잡을 수 있는 기반이 마련되었습니다.
실무에 적용할 때는 MCP를 단순 툴 래핑 수준이 아닌, 복잡한 작업 처리 레이어로 활용하는 것이 효과적입니다. 예를 들어 LangGraph를 이용한 RAG(Retrieval-Augmented Generation) 시스템 전체를 MCP 서버로 띄우고, 상위 에이전트가 이를 하나의 툴처럼 호출하는 구조도 가능합니다. 다만 MCP 서버 내부에 복잡한 멀티에이전트 로직을 넣는 것은 안정성과 확장성 측면에서 트레이드오프가 있으므로, 현재로서는 멀티에이전트 시스템을 상위 레벨에서 구성하고 MCP는 도구 통합 레이어로 사용하는 것이 더 안정적입니다.
A2A(Agent-to-Agent) 프로토콜: 에이전트 생태계의 표준화
Google이 MCP 발표 직후 내놓은 A2A 프로토콜은 에이전트 간 통신을 표준화하려는 시도입니다. MCP가 “툴 결합”을 표준화했다면, A2A는 “에이전트 결합”을 표준화합니다.
영상에서는 Google의 A2A 발표가 생태계 주도권 선점을 위한 전략적 움직임으로 보인다고 분석합니다. A2A 발표 당시 파트너사 목록을 보면 대부분 컨설팅 기관이었으며, 기술 깊이보다는 컨소시엄 구성에 중점을 둔 것으로 보입니다. 이는 MCP처럼 실질적인 개발자 생태계의 자발적 채택보다는 위에서 내려오는 표준화 시도에 가깝습니다.
그럼에도 A2A의 개념 자체는 가치가 있습니다. 외부에서 공인된 에이전트를 만들고, 이를 에이전트 카드(Agent Card) 형태로 배포하면, 다른 개발자들이 자신의 에이전트 시스템에 쉽게 통합할 수 있습니다. 예를 들어 Slack이 “Slack 전용 에이전트”를 만들어 A2A 프로토콜로 제공하면, 개발자들은 API를 직접 다룰 필요 없이 해당 에이전트를 호출만 하면 됩니다.
에이전트 카드는 해당 에이전트가 할 수 있는 일, 보유한 MCP(도구), 입출력 형식 등을 메타데이터로 담고 있습니다. 상위 에이전트(Supervisor Agent)는 이 카드를 기준으로 작업을 분배하거나, 외부 에이전트에게 일을 위임합니다.
실제로 A2A 프로토콜과 무관하게도 에이전트를 API화하려는 움직임은 이미 진행 중입니다. Firecrawl 같은 크롤링 서비스는 과거에는 단순히 URL을 입력하면 HTML을 반환하는 툴이었지만, 이제는 “딥 리서치를 수행하는 에이전틱 서비스”를 API로 제공합니다. 사용자는 “리서치 주제”를 던지면, Firecrawl이 내부적으로 여러 툴을 조합해 심층 조사를 수행하고 출처와 함께 결과를 반환합니다.
툴에서 에이전트로: MCP 서버의 진화
영상에서 강조하는 중요한 인사이트는 “MCP 서버가 단순한 툴이 아니라 에이전틱한 시스템을 담을 수 있다”는 점입니다.
예를 들어 데이터 분석 에이전트를 만든다고 가정해봅시다. 처음에는 차트 그리기 도구, Pandas 관련 함수, SQL 연결 등을 직접 통합하고 프롬프트를 작성합니다. 그러다 “어? 혹시 데이터 분석 대행 MCP 서버가 있지 않을까?” 하고 검색하면 실제로 존재합니다. 그 MCP 서버 내부에서는 이미 복잡한 에이전트 로직이 돌고 있지만, 외부에서는 단순한 툴처럼 호출할 수 있습니다.
과거에는 그러한 시스템 자체를 “에이전트”라고 불렀습니다. 하지만 이제는 더 큰 단위의 멀티에이전트 시스템이 일반화되면서, 그런 작업을 수행하는 시스템조차 “하위 작업을 담당하는 툴”로 취급됩니다. 이는 추상화 레벨이 한 단계 상승했음을 의미합니다.
MCP 서버는 내부에 복잡한 로직을 담을 수 있습니다. @tool 데코레이터로 만드는 단순한 커스텀 함수 하나만 있는 것이 아니라, 여러 툴을 조합하고 조건부 로직을 처리하는 서버 코드가 들어갑니다. 이를 통해 하나의 함수 호출만으로 복잡한 작업의 결과를 받을 수 있습니다.
다만 MCP 서버 내부에 멀티에이전트 시스템 전체를 구현하는 것은 현재로서는 권장되지 않습니다. MCP는 도구로서 설계되었기 때문에 멀티에이전트 시스템의 복잡성을 감당하기에는 한계가 있습니다. 대신 멀티에이전트 아키텍처는 상위 레벨에서 구성하고, MCP 서버는 특정 작업을 수행하는 “강력한 툴”로 활용하는 것이 안정적입니다.
미래 전망: 에이전트 다운로드 시대
영상 말미에는 “에이전트를 프로그램 다운로드하듯 사용하는 시대”가 곧 올 것이라는 전망이 나옵니다.
현재도 이미 그러한 니즈가 나타나고 있습니다. 개발자가 데이터 분석 에이전트를 만들다가 “이거 누가 이미 만들어놓지 않았을까?”라고 생각하고 MCP 서버를 검색하는 패턴이 일반화되고 있습니다. 앞으로는 특정 작업에 적합한 에이전트를 외부에서 찾아 통합하는 것이 더욱 자연스러워질 것입니다.
이는 소프트웨어 생태계의 큰 변화를 의미합니다. 과거에는 라이브러리나 패키지를 다운로드해 코드에 통합했다면, 이제는 “에이전트”를 다운로드해 에이전트 시스템에 통합합니다. A2A 프로토콜이나 이와 유사한 표준이 확립되면, 에이전트 마켓플레이스가 형성될 가능성도 있습니다.
영상에서는 농담 섞인 톤으로 “2025년 하반기에는 M2M(Model-to-Model) 같은 새로운 약어가 또 나올지도 모른다”며 변화 속도의 빠름을 강조합니다. 실제로 AI 에이전트 생태계는 몇 개월 단위로 새로운 프로토콜과 패러다임이 등장하고 있습니다.
실전 가이드
영상의 내용을 실제로 적용하려면 다음 과정을 따라해볼 수 있습니다.
먼저 MCP 서버 통합 연습부터 시작합니다. Anthropic의 Claude나 기타 MCP를 지원하는 LLM 프레임워크를 선택하고, 공식 MCP 서버 목록(예: GitHub의 MCP server registry)에서 Slack, Google Drive 등 자주 사용하는 서비스의 MCP 서버를 찾습니다. 공식 문서를 따라 10초 내외로 연결하고, 간단한 명령(예: “Slack 채널 목록 가져오기”)을 에이전트에게 지시해 작동을 확인합니다. 이 단계에서는 API 문서를 읽거나 코드를 작성할 필요가 없으며, MCP 서버 설치만으로 충분합니다.
다음으로 커스텀 MCP 서버 작성을 시도합니다. 자주 사용하는 내부 API나 복잡한 작업 로직이 있다면, 이를 MCP 서버로 래핑합니다. 예를 들어 “여러 단계의 데이터 전처리 → 분석 → 시각화”를 수행하는 로직이 있다면, 이를 하나의 MCP 함수로 제공합니다. 이렇게 하면 상위 에이전트는 단순히 “데이터 분석 수행”이라는 명령만으로 전체 파이프라인을 실행할 수 있습니다. MCP 서버 개발에는 Python의 mcp 라이브러리나 JavaScript의 MCP SDK를 사용할 수 있으며, 공식 예제 코드를 참고하면 빠르게 시작할 수 있습니다.
마지막으로 A2A 개념 실험을 진행합니다. 외부 에이전틱 API(예: Firecrawl의 딥 리서치 API)를 자신의 에이전트 시스템에 통합해봅니다. 에이전트 카드 형식으로 “이 에이전트가 할 수 있는 일”을 메타데이터로 정리하고, Supervisor Agent가 작업을 분배할 때 이 메타데이터를 참조하도록 구현합니다. 아직 A2A 프로토콜 자체는 초기 단계이므로, 개념적으로 에이전트를 모듈화하고 느슨하게 결합(loosely coupled)하는 아키텍처를 연습하는 것이 중요합니다.
심층 분석
이 영상은 MCP와 A2A의 기술적 메커니즘보다는 생태계적 의미와 실무 활용에 초점을 맞춥니다. 기술적으로 MCP는 JSON-RPC 기반의 표준화된 통신 프로토콜이며, A2A 역시 에이전트 간 메시지 포맷을 정의하는 규약입니다. 하지만 영상에서 더 강조하는 것은 “왜 이것이 중요한가”입니다.
Anthropic vs Google의 전략적 차이
영상에서는 Anthropic과 Google의 접근 방식 차이를 흥미롭게 비교합니다. Anthropic은 MCP를 11월에 조용히 발표한 후, 개발자 워크샵과 유즈 케이스 확산을 통해 “상향식(bottom-up)” 채택을 유도했습니다. 반면 Google의 A2A는 컨소시엄과 파트너십 발표를 통해 “하향식(top-down)” 표준화를 시도했습니다.
실제로 기술 표준은 두 가지 방식으로 확립됩니다. 하나는 개발자들이 자발적으로 사용하면서 사실상의 표준(de facto standard)이 되는 경우(예: JSON, REST API)이고, 다른 하나는 대기업이나 컨소시엄이 공식 표준(de jure standard)을 선언하는 경우(예: W3C 표준)입니다. MCP는 전자에 가깝고, A2A는 후자에 가깝습니다.
역사적으로 개발자 생태계에서는 사실상의 표준이 더 강력한 생명력을 보였습니다. Google도 이를 알고 있을 것이지만, 에이전트 생태계의 주도권을 Anthropic에게 빼앗기지 않으려는 전략적 판단이 A2A 발표로 이어진 것으로 보입니다.
MCP 서버의 한계와 멀티에이전트 시스템
영상에서는 MCP 서버가 복잡한 멀티에이전트 시스템을 담기에는 한계가 있다고 지적합니다. 이는 MCP가 “도구”로 설계되었기 때문입니다. 도구는 입력을 받아 출력을 반환하는 단순한 인터페이스를 가져야 하는데, 멀티에이전트 시스템은 상태 관리, 에이전트 간 조율, 오류 복구 등 복잡한 오케스트레이션을 필요로 합니다.
현재로서는 LangGraph, AutoGen, CrewAI 같은 멀티에이전트 프레임워크를 상위 레벨에서 사용하고, MCP 서버는 개별 에이전트가 사용하는 “강력한 도구”로 위치시키는 것이 안정적입니다. 하지만 미래에는 MCP 자체가 더 복잡한 워크플로우를 지원하도록 확장될 가능성도 있습니다.
에이전트 API화의 비즈니스 모델
영상에서 언급된 Firecrawl의 사례는 중요한 비즈니스 트렌드를 보여줍니다. 과거에는 “크롤링 API”를 제공했다면, 이제는 “리서치 에이전트 API”를 제공합니다. 사용자는 더 이상 크롤링 결과를 직접 파싱하고 분석할 필요가 없으며, 주제만 던지면 됩니다.
이는 SaaS(Software as a Service)에서 AaaS(Agent as a Service)로의 전환을 의미합니다. 앞으로 많은 B2B SaaS 기업들이 API 엔드포인트를 제공하는 대신, 또는 그에 더해, 에이전트를 제공할 것입니다. 이러한 에이전트는 MCP나 A2A 같은 표준 프로토콜을 통해 쉽게 통합될 것입니다.
에이전트 마켓플레이스의 가능성
NPM(Node Package Manager)이나 PyPI(Python Package Index)처럼, 에이전트 마켓플레이스가 등장할 가능성이 큽니다. 개발자들은 “데이터 분석 에이전트”, “고객 지원 에이전트”, “코드 리뷰 에이전트” 같은 검증된 에이전트를 다운로드해 자신의 시스템에 통합할 것입니다.
이미 Hugging Face는 모델 허브로 시작해 Datasets, Spaces로 확장했습니다. 에이전트 허브가 다음 단계가 될 가능성이 있습니다. 에이전트 카드 형식으로 기능, 요구사항, 라이선스, 성능 벤치마크 등을 표준화하면, 에이전트 검색과 통합이 훨씬 쉬워질 것입니다.
데이터 기반 인사이트
영상에서는 구체적인 통계 수치보다는 정성적 관찰과 추세 분석에 중점을 둡니다. 다음은 영상에서 암시하는 주요 데이터 포인트들입니다.
MCP 채택률의 급증: Anthropic이 2024년 11월에 MCP를 발표한 이후, 초기에는 관심이 미미했지만 워크샵과 유즈 케이스 확산을 통해 개발자 커뮤니티에서 빠르게 채택되었습니다. 영상에서 “10초면 통합 가능”이라는 표현은 MCP의 낮은 진입 장벽을 강조합니다.
MCP 서버 생태계의 성장: Slack, Google Drive, GitHub 등 주요 서비스 제공자들이 공식 MCP 서버를 제공하기 시작했습니다. 이는 MCP가 단순한 실험적 프로토콜이 아니라 실무에서 사용 가능한 표준으로 인정받았음을 의미합니다.
A2A의 제한적 초기 반응: Google이 A2A를 발표했을 때 파트너사 대부분이 컨설팅 기관이었다는 점은 기술 깊이보다는 컨소시엄 구성에 중점을 두었음을 시사합니다. 이는 초기 채택률이 MCP에 비해 낮을 가능성을 의미합니다.
에이전트 API 서비스의 등장: Firecrawl 같은 기존 툴 제공 서비스가 에이전틱 서비스를 추가로 제공하기 시작했습니다. 이는 시장이 “툴”에서 “에이전트”로 이동하고 있음을 보여주는 신호입니다.
채널의 신뢰성: 테디노트는 LangChain 한국어 튜토리얼(https://wikidocs.net/book/14314)을 운영하며, GitHub에 활발한 소스코드 저장소(https://github.com/teddylee777)를 유지하고 있습니다. 모두의AI 케인님 역시 RAG 아키텍처 설계에 대한 전문성을 보유하고 있으며, 패스트캠퍼스에서 “Agent로 완성하는 RAG” 강의를 제공합니다. 두 사람 모두 실무 경험을 바탕으로 한 검증된 정보를 제공하는 것으로 평가됩니다.
핵심 요점
영상을 본 후 기억해야 할 다섯 가지는 다음과 같습니다.
1. MCP는 툴 통합의 표준화를 통해 개발 생산성을 혁신적으로 향상시킵니다. 과거에는 각 서비스의 API를 개별적으로 통합해야 했지만, 이제는 서비스 제공자가 만든 MCP 서버를 10초 만에 연결할 수 있습니다. 실무에서는 Slack, Google Drive, GitHub 같은 자주 사용하는 서비스부터 MCP 통합을 시작하면 즉각적인 생산성 향상을 경험할 수 있습니다.
2. MCP 서버는 단순한 툴이 아니라 복잡한 로직을 담는 에이전틱 레이어가 될 수 있습니다. LangGraph로 구축한 RAG 시스템 전체를 MCP 서버로 제공하거나, 여러 단계의 데이터 처리 파이프라인을 하나의 MCP 함수로 래핑할 수 있습니다. 이를 통해 상위 에이전트는 복잡한 내부 로직을 알 필요 없이 간단한 호출만으로 강력한 기능을 사용할 수 있습니다. 다만 멀티에이전트 오케스트레이션은 상위 레벨에서 처리하고, MCP는 도구 레이어로 사용하는 것이 현재로서는 더 안정적입니다.
3. A2A 프로토콜은 에이전트 간 통신의 표준화를 목표로 하지만, 아직 초기 단계입니다. Google의 A2A는 에이전트 카드를 통해 외부 에이전트를 쉽게 통합하는 비전을 제시하지만, MCP와 달리 개발자 커뮤니티의 자발적 채택보다는 컨소시엄 중심의 하향식 접근을 보입니다. 당장 A2A를 도입하기보다는, 에이전트를 모듈화하고 느슨하게 결합하는 아키텍처 원칙을 먼저 적용하는 것이 실용적입니다.
4. 에이전트 API화는 이미 진행 중이며, SaaS에서 AaaS로의 전환이 가속화되고 있습니다. Firecrawl 같은 사례에서 보듯, 기존 툴 제공 서비스들이 에이전틱 서비스를 추가로 제공하기 시작했습니다. 사용자는 더 이상 원시 데이터를 받아 직접 처리하지 않고, 에이전트에게 작업을 위임합니다. B2B SaaS 기업이라면 자사 API를 에이전트 형태로도 제공하는 전략을 고려해야 합니다.
5. “에이전트 다운로드 시대”가 도래하고 있으며, 에이전트 마켓플레이스가 곧 등장할 것입니다. NPM이나 PyPI처럼 검증된 에이전트를 검색하고 통합하는 생태계가 형성될 것입니다. 장기적으로는 에이전트 개발이 “처음부터 모든 것을 만드는 것”에서 “기존 에이전트를 조합하고 커스터마이징하는 것”으로 전환될 것입니다. 개발자는 데이터 분석 에이전트, 코드 리뷰 에이전트 같은 재사용 가능한 모듈을 미리 준비해두면 경쟁력을 확보할 수 있습니다.
요약자 노트
이 요약은 YouTube 자동 생성 자막(2025-12-19 추출)을 바탕으로 작성되었습니다. 영상은 라이브 하이라이트 편집본이므로 전체 맥락을 완전히 담지는 못했을 수 있습니다. 전체 라이브는 https://youtube.com/live/2eKd4UbSXy0 에서 확인할 수 있습니다.
이 요약의 한계점:
- 자막 기반이므로 화면에 표시된 차트나 코드 예제는 포함되지 않았습니다.
- MCP와 A2A의 기술적 세부사항(프로토콜 스펙, 메시지 포맷 등)보다는 생태계적 의미에 초점을 맞췄습니다.
- 실시간 대화 형식이므로 일부 내용이 맥락 없이 언급되었을 수 있습니다.
보다 완전한 이해를 위해서는 원본 영상 시청을 권장합니다. 특히 MCP 서버 설정 과정이나 실제 코드 예제가 궁금하다면 전체 라이브 영상이나 테디노트의 GitHub 저장소를 참고하세요.
참고자료
영상에서 언급된 자료와 더 깊이 있는 학습을 위한 출처들:
- 테디노트 랭체인 한국어 튜토리얼: https://wikidocs.net/book/14314
- 테디노트 GitHub 저장소: https://github.com/teddylee777
- 테디노트 블로그: https://teddylee777.github.io
- 전체 라이브 영상: https://youtube.com/live/2eKd4UbSXy0
- 모두의 AI 케인 – Agent로 완성하는 RAG 강의: https://buly.kr/H6hpgA9 (패스트캠퍼스, 할인코드: 멀티에이전트구축)
- 테디노트 RAG 비법노트 강의: https://fastcampus.co.kr/data_online_teddy
이 글은 YouTube 자동 생성 자막(자막 추출일: 2025-12-19)을 바탕으로 작성되었습니다. 영상의 핵심 내용을 정리한 것이므로, 보다 완전한 이해를 위해서는 원본 영상 시청을 권장합니다.