시리즈: MCP API 본질적 차이 연결표준 (총 7편) | 5회
MCP가 떠오른 진짜 배경 — 에이전트 확산이 만든 N×M 통합 폭발과 표준화 수요
AI 에이전트가 늘어나면서 연결해야 할 시스템이 기하급수적으로 불어났어. 왜 MCP라는 표준이 지금 필요해졌는지, 에이전트 확산과 N×M 통합 비용 문제를 중심으로 풀어볼게.
Summary
- 에이전트가 ‘기본 기능’이 되면서, 파일 접근·티켓 생성·코드 수정·메시지 전송 같은 연결 수요가 폭증했어
- 플러그인·커넥터·Function Calling이 플랫폼별로 파편화되면서 “같은 통합을 여러 번 만드는” 비용이 커졌어
- IDE·코딩 에이전트가 MCP 확산의 전초기지 역할을 했고, 로컬/데스크톱 자동화까지 확장되면서 ‘안전한 연결’ 이슈가 부각됐어
- 핵심은 N×M 통합 비용을 N+M으로 줄이겠다는 MCP의 약속이야
이 글의 대상
- “MCP가 왜 갑자기 이렇게 화제야?”가 궁금한 사람
- 에이전트 도입을 검토하면서 통합 비용이 걱정인 기획자·PM
- IDE/코딩 도구에서 MCP를 접했는데 배경이 궁금한 개발자
목차
- 에이전트가 ‘기본 기능’이 되면서 달라진 것
- 플러그인·Function Calling 파편화의 비용
- IDE·코딩 에이전트 — 확산의 전초기지
- 로컬·데스크톱 자동화와 ‘안전한 연결’ 이슈
- 보안·권한·감사 — ‘나중’이 아니라 ‘처음’ 이슈
- N×M → N+M: MCP가 약속하는 구조 변화
1. 에이전트가 ‘기본 기능’이 되면서 달라진 것
모델이 답변만 하던 시대는 끝났어.
예전에는 AI가 질문에 잘 대답하면 그걸로 충분했지. 근데 지금은 달라. 파일을 읽고, 티켓을 만들고, 코드를 수정하고, 슬랙 메시지를 보내는 — 이런 “행동”을 해야 비로소 생산성이 올라가거든.
이 순간부터 연결이 제품의 핵심이 돼. 모델의 성능이 아무리 좋아도, 사내 문서를 못 읽으면, DB를 못 조회하면, 이슈 트래커를 못 쓰면 쓸모가 반감되니까.
Anthropic이 MCP를 발표하면서 “AI 어시스턴트가 데이터가 있는 곳에 안전하게 연결되도록 하는 오픈 표준”이라고 소개한 것도 이 맥락이야. 연결이 선택 사항에서 필수 요건으로 바뀐 거지.
연결 수요가 폭증한 이유
| 과거 (답변 중심) | 현재 (행동 중심) |
|---|---|
| 모델이 텍스트로 답변 | 모델이 실제 시스템을 읽고/쓰기 |
| 외부 연결은 선택 | 외부 연결이 제품 코어 |
| 연결 대상 1~2개 | 연결 대상 5~20개 이상 |
| 보안은 부차적 | 보안·권한이 즉시 이슈 |
2. 플러그인·Function Calling 파편화의 비용
같은 통합을 여러 번 만드는 비효율이 핵심 문제야.
플랫폼마다 도구를 연결하는 방식이 달라. OpenAI는 Function Calling과 Assistants API, Google은 Built-in Tools, Anthropic은 Tool Use — 각각 강력하지만 규격이 다르지. 여기에 각 SaaS(Slack, Jira, Google Drive 등)마다 API 인증 방식과 데이터 포맷도 다 달라.
결과적으로 뭐가 생기냐면:
- A 플랫폼에서 Jira를 연결하려면 A용 커넥터를 만들어야 하고
- B 플랫폼에서 같은 Jira를 연결하려면 B용 커넥터를 또 만들어야 해
- Jira 말고 Drive도 붙이려면? 또 각각 만들어야 하고
작은 팀이 실험할 때는 괜찮아. 근데 조직 규모가 커지면 이 “같은 통합을 반복 구현하는 비용”이 진짜 부담이 되거든. MCP는 이 파편화를 프로토콜(규격) 레벨에서 정리하려는 시도야.
3. IDE·코딩 에이전트 — 확산의 전초기지
개발 환경에서 MCP의 효과가 가장 먼저, 가장 크게 체감됐어.
왜 하필 IDE일까? 개발자가 일할 때 동시에 연결해야 하는 시스템을 한번 세어보면 바로 이해가 돼:
| 연결 대상 | 예시 |
|---|---|
| 코드 | 로컬 파일, 프로젝트 구조 |
| 버전 관리 | Git 히스토리, 브랜치, PR |
| 이슈 트래커 | Jira, GitHub Issues |
| CI/CD | 빌드·테스트 로그, 결과 |
| 문서 | Confluence, Notion, 위키 |
| 운영 | 로그, 모니터링 지표 |
이 모든 걸 IDE 에이전트가 참조해야 제대로 된 코드 제안이나 리팩토링을 할 수 있어. 근데 각 시스템의 API, 인증, 데이터 포맷이 다 다르니까 플러그인 방식으로는 확장이 안 되거든.
실제 사례
- Zed: MCP를 통해 에디터 어시스턴트가 “코드 밖의 컨텍스트”(이슈, PR, 문서)를 연결하는 방향을 공개했어
- Sourcegraph: AI 코딩 어시스턴트 Cody가 MCP를 지원한다고 밝혔지
- Replit: MCP 프로토콜 지원을 통해 개발 환경 확장
이런 사례들이 “MCP는 실전에서 쓰일 수 있다”는 신호로 작동했어. 그리고 개발 환경은 표준화의 효과가 즉시 생산성으로 나타나는 곳이라 확산이 빨랐지.
4. 로컬·데스크톱 자동화와 ‘안전한 연결’ 이슈
모델이 내 컴퓨터 파일을 읽고 쓰기 시작하면, 편의와 리스크가 동시에 커져.
사용자 입장에서는 AI가 로컬 파일과 앱에 접근하면 정말 편해. 예를 들어 “이 폴더에 있는 CSV 파일 분석해줘”라고 하면 바로 처리해주니까. 근데 기업 입장에서는 민감 데이터 리스크가 급증해.
로컬 MCP 서버 패턴
Anthropic은 Claude Desktop에서 로컬 MCP 서버 패턴을 보여줬어. AI가 사용자의 로컬 파일시스템에 접근하되, MCP 서버를 통해 통제된 방식으로 접근하는 구조야.
Docker도 MCP Toolkit 가이드를 내놓으면서 생태계가 빠르게 확장됐어. 컨테이너 환경에서 MCP 서버를 안전하게 운영하는 방법을 제시한 거지.
핵심은 이거야: 로컬/데스크톱에서의 AI 자동화가 커지면서 “연결은 되지만 안전하게”라는 요구가 MCP의 중요한 축이 됐어.
5. 보안·권한·감사 — ‘나중’이 아니라 ‘처음’ 이슈
MCP 도입을 검토하는 조직이 늘수록, 질문이 바뀌고 있어.
초기 질문: “연결할 수 있나?”
지금 질문: “안전하게 운영할 수 있나?”
모델이 실제 시스템을 변경하거나 민감 데이터를 다루면, 승인·권한·감사로그가 선택이 아니라 필수야. “나중에 보안을 붙이자”는 접근은 안 통해. 처음부터 설계해야 해.
명세의 고도화
MCP 명세도 이 수요를 반영하고 있어:
| 보안 요소 | 설명 |
|---|---|
| OAuth 2.1 | 표준 인증·인가 프레임워크 |
| PKCE | 공개 클라이언트(모바일/SPA)의 코드 탈취 방지 |
| Dynamic Client Registration | 클라이언트 자동 등록 |
| Resource Indicators | 토큰이 의도와 다른 리소스에 사용되는 걸 방지 |
MCP Authorization 문서가 이런 요소들을 구체적으로 다루기 시작한 건, 보안이 “부록”이 아니라 핵심 명세가 됐다는 뜻이야.
6. N×M → N+M: MCP가 약속하는 구조 변화
이 섹션이 MCP 부상의 핵심 동인이야.
N×M 문제란?
에이전트(AI 클라이언트) N개가 데이터소스/툴 M개를 각각 연동하면, 필요한 커넥터 수는 N × M이 돼.
예시: 에이전트 3개 × 데이터소스 5개 = 15개 커넥터
에이전트A ──┬── Drive
├── Git
├── Jira
├── DB
└── Slack
에이전트B ──┬── Drive
├── Git
├── Jira
├── DB
└── Slack
에이전트C ──┬── Drive
├── Git
├── Jira
├── DB
└── Slack
총 커넥터: 3×5 = 15개 (각각 개발·유지보수)
에이전트가 5개로 늘고, 데이터소스가 10개로 늘면? 50개. 이걸 다 개별로 만들고 유지보수하는 건 현실적으로 불가능해.
MCP의 약속: N + M
MCP 방식: 에이전트 3개 + 데이터소스 5개 = 8개 구현
에이전트A ──┐
에이전트B ──┼── MCP 프로토콜 ──┬── Drive MCP서버
에이전트C ──┘ ├── Git MCP서버
├── Jira MCP서버
├── DB MCP서버
└── Slack MCP서버
총 구현: 3(클라이언트) + 5(서버) = 8개
클라이언트는 MCP만 구현하면 되고, 각 시스템은 MCP 서버로 한 번만 감싸면 돼. 새 에이전트가 추가되면? MCP 클라이언트만 구현하면 기존 모든 MCP 서버를 바로 쓸 수 있어. 새 데이터소스가 추가되면? MCP 서버 하나만 만들면 기존 모든 에이전트가 쓸 수 있고.
현실적인 한계도 있어
물론 “N+M으로 줄어든다”는 건 이상적인 그림이야. 실제로는:
- 각 MCP 서버의 도메인 로직과 권한 모델은 여전히 구현해야 하고
- 서버의 툴 메타데이터(설명·스키마) 품질이 낮으면 에이전트가 도구를 잘못 쓸 수 있어
- 표준 자체가 빠르게 진화 중이라 버전 호환 이슈도 있지
그래도 N×M이 N+M 방향으로 줄어드는 것만으로도 조직의 통합 부담이 크게 달라져. 이게 MCP가 “기술 유행”이 아니라 구조적 수요에서 나온 표준이라고 볼 수 있는 이유야.
핵심 정리
1. 에이전트가 행동(읽기/쓰기)을 하면서 연결 대상이 폭증 — 연결이 선택이 아닌 필수가 됐어
2. 플랫폼별 플러그인/Function Calling 파편화 → 같은 통합을 반복 구현하는 비용 폭발
3. IDE·코딩 에이전트가 MCP 확산의 촉매 — 다층적 연결이 필요한 개발 환경에서 효과 체감
4. 로컬/데스크톱 자동화 확산 → '안전한 로컬 연결'이 새로운 축
5. N×M 통합 비용을 N+M으로 줄이겠다는 게 MCP의 핵심 약속이야
FAQ
Q. MCP가 나오기 전에는 어떻게 통합했어?
A. 플랫폼별 플러그인이나 커넥터를 직접 만들었어. OpenAI의 Function Calling, 각 SaaS의 REST API를 개별로 연동하는 식이지. 작동은 하지만, 에이전트와 데이터소스가 늘수록 유지보수가 기하급수적으로 커지는 게 문제였어.
Q. N×M 문제가 왜 ‘지금’ 갑자기 이슈가 된 거야?
A. 에이전트가 소수 연구팀의 실험 도구에서 업무 현장의 기본 기능으로 바뀌었기 때문이야. 에이전트 수와 연결 대상이 동시에 늘면서 통합 비용이 감당 불가 수준으로 커진 게 2024년 전후 시점이거든.
Q. IDE 말고 다른 영역에서도 MCP가 쓰이고 있어?
A. 당연하지. 사내 챗봇, 문서 요약 도구, 고객지원 자동화, 로컬 파일 분석 등 다양한 영역에서 쓰이고 있어. 다만 IDE가 가장 먼저, 가장 크게 체감한 영역이었을 뿐이야. 연결 대상이 다층적인 곳일수록 MCP의 효과가 커.
Q. 로컬 MCP 서버는 안전한 거야?
A. “MCP를 쓰면 자동으로 안전하다”는 건 아니야. MCP는 연결 방식을 표준화할 뿐, 보안은 구현과 운영의 몫이야. 다만 MCP 서버를 관문으로 두면 권한·로깅·승인을 한 곳에서 통제하기 쉬워지는 구조적 이점이 있어.
Q. OAuth 2.1이랑 PKCE가 뭔데?
A. OAuth 2.1은 “누가 어떤 권한으로 접근할 수 있나”를 정하는 인증·인가 표준이야. PKCE는 모바일이나 브라우저 앱처럼 비밀키를 안전하게 보관하기 어려운 환경에서 코드 탈취를 막는 보안 장치야. MCP 명세가 이런 표준을 전제로 설계된다는 건, 보안을 처음부터 고려하겠다는 뜻이지.
Q. MCP가 없어도 에이전트를 잘 쓰고 있는데, 꼭 도입해야 해?
A. 에이전트가 1~2개이고 연결 대상도 소수라면 당장은 괜찮아. 근데 에이전트와 데이터소스가 늘어날 계획이 있다면, N×M 비용이 언제 폭발할지 모르니까 표준화를 미리 검토하는 게 좋아.
Q. Function Calling이랑 MCP는 어떻게 다른 거야?
A. Function Calling은 특정 모델 플랫폼 안에서 “이 함수를 호출해”라고 하는 구현이야. 강력하지만 플랫폼에 종속되기 쉬워. MCP는 플랫폼을 넘어서 “도구를 발견하고, 호출하고, 결과를 돌려주는 전체 흐름”을 표준 규격으로 정의한 거야. 레이어가 다른 셈이지.
참고 자료 (References)
데이터 출처
| 출처 | 설명 | 링크 |
|---|---|---|
| Anthropic | MCP 공식 발표 — AI용 표준 연결 오픈 프로토콜 소개 | Anthropic 발표 |
| MCP 공식 문서 | MCP 개요 및 아키텍처 설명 | modelcontextprotocol.io |
| Zed 블로그 | IDE에서 MCP 활용 사례 | Zed MCP 블로그 |
| Sourcegraph | Cody의 MCP 지원 발표 | Sourcegraph 발표 |
| Docker | Claude Desktop + MCP Toolkit 연결 가이드 | Docker MCP 가이드 |
| Cloudflare | MCP 일반 설명 및 보안 지적 | Cloudflare 학습 |
| MCP Authorization Spec | OAuth 2.1/PKCE 기반 인증·인가 명세 | MCP Authorization |
| a16z | MCP와 AI 도구의 미래 분석 | a16z 분석 |
핵심 인용
“MCP is an open protocol that standardizes how applications provide context to LLMs.”
— Anthropic, “Introducing the Model Context Protocol”“MCP는 에이전트가 외부 도구와 데이터를 표준화된 방식으로 호출할 수 있게 해, N×M 문제를 줄인다.”
— Cloudflare 학습 가이드 요지
다음 편 예고
[6편] 실무 시나리오 — API로 충분한 곳 vs MCP가 유리한 곳
- 결제 처리, 사내 데이터 통합, IDE 코딩, 로컬 파일 접근 — 4가지 사례로 판단 기준 정리
- MCP 도입의 장점과 리스크를 균형 있게 분석
- “MCP는 API를 대체하나?” 질문에 대한 실무적 결론