누구나 이해할 수 있는 MCP 가이드
AI 에이전트가 실제 도구를 쓰지 못하는 이유는 모든 API가 제각각이기 때문이다. MCP가 그 사이에 공통 언어를 놓는다.
AI 에이전트가 Google Calendar, Salesforce 같은 외부 도구를 쓰는 데 겪는 어려움과, 그것을 풀기 위한 새 표준 프로토콜 MCP(Model Context Protocol)를 정리한 가이드다. MCP 가 에이전트와 도구 사이의 ‘공통 언어’ 역할을 어떻게 하는지, 개발자와 SaaS 기업이 이 생태계에 어떻게 참여할 수 있는지까지 다룬다.
가이드 전체 내용은 Gemini 2.5 Pro 로 작성했고, 이미지 정리본은 GPT-4o 로 만들었다.
1. 왜 새 표준이 필요한가
미래는 에이전트 중심이다
ChatGPT 시대를 맞아 우리 모두 AI 가 얼마나 강력할 수 있는지 엿봤다. 하지만 진짜 생산성은 AI 와 대화하는 데서 오는 것이 아니라, AI 가 우리를 위해 실제로 일을 처리할 때 나온다.
에이전트는 단순한 챗봇이 아니다. 회의 예약, 보고서 작성, 데이터 분석처럼 실제 도구(Google Calendar, Salesforce, Notion 등)를 써서 행동하는 AI 다.
그런데 오늘날의 에이전트는 여전히 제한적이다
AI 에게 이렇게 요청한다고 상상해 보자.
“이번 주 나의 모든 1:1 미팅을 찾아서, 논의 내용을 요약하고, 후속 이메일 초안을 작성해 줄 수 있니?”
오늘날 대부분의 AI 에이전트는 아마 멈춰 버릴 것이다. 왜일까. 그들이 쓰는 도구, 즉 여러 서비스의 API 가 마치 수백 개의 다른 방언처럼 제각각이기 때문이다.
모든 도구는 자체 인증 규칙, 고유한 데이터 형식, 서로 다른 기능과 엔드포인트를 갖고 있다. 그래서 개발자는 모든 도구에 대해 맞춤 코드를 써야 한다. 느리고, 불안정하며, 확장되지 않는다.
빠진 조각 — 도구를 위한 공통 언어
이 도구들이 에이전트와 소통할 표준적인 방법이 있다면 어떨까. HTML 이 웹을 표준화하고 REST 가 API 를 표준화했듯, 이제 AI 에이전트를 위한 표준이 필요하다.
그것이 MCP(Model Context Protocol) 다.
2. MCP 는 어떻게 작동하는가
MCP 는 AI 에이전트와 그들이 써야 할 도구 사이에서 번역가 역할을 하는 표준이다. 에이전트가 어떤 도구를 쓸 수 있는지, 그 도구가 무엇을 할 수 있는지, 어떻게 안전하고 효율적으로 쓸 수 있는지 를 이해하도록 돕는 “만능 리모컨” 이라고 생각하면 된다.
주요 개념
MCP 클라이언트 — LLM 을 쓰는 AI 에이전트 또는 앱이다. “이 도구는 무엇을 할 수 있나요?”, “이 함수를 실행해 주세요” 같은 요청을 보낸다.
MCP 서버 — SaaS 도구와의 다리다. 사용 가능한 기능(예: “회의 생성”, “노트 가져오기”)과 관련 데이터를 일관된 형식으로, LLM 이 이해할 수 있는 방식으로 설명한다.
컨텍스트 스키마 — 도구의 기능을 LLM 이 읽을 수 있도록 구조화하고 통합한 형식이다. 모든 도구를 쉽게 탐색할 수 있는 API 플레이그라운드로 바꾸는 것과 같다.
무엇이 달라지나
MCP 가 없으면 에이전트는 모든 도구를 쓰기 위해 수작업 코딩이 필요하다. 느리고 비용이 많이 든다. MCP 가 있으면 도구는 에이전트에게 플러그 앤 플레이가 된다. 빠르고 확장 가능하다.
실제 예시
에이전트가 이런 일을 하기를 원한다고 하자.
“Asana 에서 모든 높은 우선순위 작업을 찾고, 프로젝트 상태를 요약하고, 팀에 알림 보내기”
MCP 를 쓰면 이렇게 된다. Asana MCP 서버가 자기 기능을 설명한다(list_projects, get_tasks 등). 에이전트는 이 작업들을 탐색하고 호출하고 결합할 수 있다. 그 결과 맞춤 코드 없이 완전히 자동화된 워크플로가 가능해진다.
3. 도구가 에이전트의 능력을 결정한다
인간 조수가 일을 처리하려면 적절한 기술 세트가 필요하듯, AI 에이전트의 성능은 쓸 수 있는 도구에 따라 달라진다.
다기능 도구 — 스위스 아미 나이프처럼
여러 관련 작업을 하나의 인터페이스로 묶는다. 단일 단계가 아니라 전체 워크플로를 수행하도록 설계된다.
예를 들어 다기능 도구를 쓰는 Calendar Agent 는 모든 미팅을 찾고(유형별 필터링 = 1:1), 메타데이터를 뽑고(제목·참석자·시간), 미팅 노트를 읽고, 주간 요약을 만드는 일을 한 번에 처리한다. 다섯 개의 도구를 따로 호출할 필요가 없다.
도구 수가 적을수록 오케스트레이션이 단순해지고, 에이전트는 빠르고 똑똑해진다.
다중 도구 에이전트 — 전문가 팀처럼
단일 도구만으로 다 되지 않을 때는 팀 안의 사람들처럼 각기 다른 도구를 쓰는 에이전트들이 협업한다.
목표가 “주요 고객에게 맞춤형 이메일 캠페인 보내기” 라면, 에이전트 1이 Salesforce 에서 고객 데이터를 가져오고, 에이전트 2가 Google Sheets 에서 분석하고, 에이전트 3이 Mailchimp 로 이메일을 보낸다. 이것을 에이전트 시스템(System of Agents) 또는 다중 에이전트 시스템(MAS)이라고 한다.
에이전트들이 강점을 결합해 더 넓은 범위를 커버한다. 회사의 마이크로서비스처럼 말이다.
왜 ChatGPT 만으로는 충분하지 않은가
오늘날 대부분의 맞춤형 GPT 는 너무 단순하다. 작업이 제한적이고, 메모리가 없고, 다른 에이전트와 협업할 수 없고, “단일 도구” 사일로에 갇혀 있다. AutoGen, CrewAI, LangGraph 같은 프레임워크가 등장한 이유가 여기에 있다.
단순히 어떤 LLM 을 쓰느냐의 문제가 아니다. 어떤 도구를 제공하고 그것들이 어떻게 연결되어 있느냐의 문제다.
4. 현실적인 과제와 한계
MCP 는 AI 에이전트와 도구 연동을 바꿀 잠재력이 있지만, 새 표준으로서 현실적인 과제도 있다.
느린 채택 속도. 새 표준의 성공은 얼마나 많은 플레이어가 참여하느냐에 달렸다. SaaS 기업들이 MCP 서버 구축에 투자하고 에이전트 개발자들이 적극적으로 써야 생태계가 산다. 초기에는 ‘닭과 달걀’ 문제에 부딪힐 수 있다. 모든 도구 제공자가 표준화된 단일 인터페이스를 선호하지는 않으며, 자체 API 생태계 강화를 우선할 수도 있다.
구현과 유지보수의 복잡성. MCP 는 클라이언트 개발을 단순화하지만, SaaS 제공자 입장에서는 복잡한 API 기능과 데이터 모델을 MCP 스키마에 정확히 매핑하고 안전하고 효율적인 서버를 만들어 유지하는 것이 상당한 기술적·비용적 부담이다. 도구의 API 가 바뀌거나 MCP 표준이 발전하면 계속 업데이트해야 한다.
표준화의 명암. 모든 도구의 고유하고 세분화된 기능을 단일 표준으로 완벽히 담기는 어렵다. 초기 표준은 ‘최소 공통분모’ 에 집중하게 되어, 특정 도구의 고급 기능을 MCP 로 쓰는 데 제약이 따를 수 있다. 때로는 여전히 직접 API 호출이 필요하다. 또 표준은 한번 자리 잡으면 바꾸기 어려워, 빠르게 변하는 기술 발전을 민첩하게 따라가지 못할 수 있다.
성능과 보안. 중개 계층이 추가되면서 직접 API 호출보다 약간의 지연이 생길 수 있다. 대부분은 무시할 만하지만 실시간성이 중요한 애플리케이션에서는 고려해야 한다. 그리고 표준화된 인터페이스는 잠재적인 공격 표면도 표준화한다. 인증·권한 부여·데이터 암호화를 철저히 구현해야 하며, 그 책임은 각 서버 구현 주체에게 있다.
기술 성숙도. MCP 는 비교적 새로운 개념이라 개발 도구, 디버깅 툴, 테스트 프레임워크, 문서, 커뮤니티 지원이 아직 부족할 수 있다.
이런 문제들은 대부분의 신기술 표준화 과정에서 나타난다. MCP 의 성공 여부는 이 과제들을 얼마나 효과적으로 넘느냐에 달려 있다.
5. 생태계에 참여하는 방법
당신의 제품이 SaaS 도구이고 AI 에이전트가 그것을 쓰기를 원한다면, 지금이 MCP 생태계에 들어가기 좋은 시기다. LLM 기반 에이전트에게 발견될 수 있고, 맞춤 통합 없이 에이전트가 도구를 쓰게 할 수 있으며, 기업 IT 부터 소비자 AI 까지 성장하는 시장에 진입할 수 있다.
1. MCP 서버 구축하기. 도구의 기능을 MCP 호환 인터페이스로 바꾼다. 기능을 설명하고(call_tool, list_tools), 데이터를 노출하고(call_resource, list_resources), 표준 컨텍스트 스키마를 따른다. 공개 API 를 만드는 것과 같지만 LLM 을 위한 것이다. LangGraph, AutoGen 같은 기존 프레임워크를 쓰면 개발이 빨라진다.
2. 마켓플레이스에 호스팅하거나 등록하기. 서버가 준비되면 MCP 레지스트리나 마켓플레이스에 게시한다. 모든 MCP 호환 클라이언트가 도구를 발견할 수 있게 되고, 에이전트가 제품을 찾고 이해하고 쓰게 된다. 일부 플랫폼은 이미 이 플러그 앤 플레이 모델을 지원한다.
3. MCP 를 클라이언트로 쓰기. MCP 로 도구에 연결하는 자체 에이전트나 LLM 앱을 만들 수도 있다. 각 API 마다 맞춤 래퍼를 쓸 필요가 없고, 기존 MCP 서버에 연결해 워크플로를 더 빠르게 만든다. 내부 자동화 도구나 고객 대면 AI 앱에 적합하다.
마무리
REST 가 웹 시대의 API 표준이었다면, MCP 는 에이전트 시대의 프로토콜 표준이 될 수 있다. MCP 는 아직 초기 단계지만 기반은 현실적이고 작동하고 있다. 지금 참여하면 떠오르는 표준에 영향을 미치고, 다른 이들보다 먼저 자기 도구의 LLM 인터페이스를 만들고, 생태계가 커지는 만큼 함께 성장할 수 있다.
핵심 도구 기능을 찾아내고 MCP 형식으로 구조화하는 것부터 시작하면 된다. 모든 것을 지원할 필요는 없다. 에이전트가 시작할 수 있을 만큼만 지원하면 된다.
