ChatGPT나 Claude를 쓰다 보면 아쉬운 순간이 옵니다. 모델은 똑똑한데, 내 데이터베이스도 못 보고 사내 위키도 못 읽으니까요.
그래서 다들 API를 직접 연결하기 시작했습니다. 그런데 모델마다, 도구마다 연동 방식이 제각각이라 조합이 늘어날수록 연동 코드도 기하급수적으로 불어나죠.
MCP(Model Context Protocol)는 이 문제를 풀려고 나온 표준입니다. 한 문장으로 정리하면, AI 모델에 외부 도구와 데이터를 꽂는 공용 규격이에요. 흔히 “AI계의 USB-C”라고 부릅니다.
이 글에서는 MCP가 정확히 뭘 해결하는지, 도입 전후로 연동 작업이 얼마나 달라지는지, 내부 구조와 function calling과의 차이, 그리고 지금 바로 붙여볼 만한 대표 서버까지 정리합니다.
핵심 요약부터 보고 갈게요.
- MCP는 AI와 외부 도구를 연결하는 오픈 표준 프로토콜입니다 (2024년 11월 Anthropic 공개)
- 직접 연동하면 수백 줄이던 작업이, MCP 서버가 있으면 설정 몇 줄로 끝납니다
- function calling을 대체하는 게 아니라 그 위에서 도구를 표준화·재사용하는 층입니다
- OpenAI·Google도 채택하면서 사실상 업계 표준이 됐고, 서버 생태계가 빠르게 크고 있습니다
MCP가 해결하는 문제, M×N 연동 지옥
MCP 이전의 상황을 먼저 볼게요.
AI 앱이 M개, 연결하고 싶은 도구가 N개라면 필요한 연동 코드는 M×N개였습니다. Claude용 GitHub 연동, ChatGPT용 GitHub 연동, 커서용 GitHub 연동을 전부 따로 만들어야 했죠.
MCP는 이 사이에 표준 규격을 끼워 넣습니다. 도구 쪽은 MCP 서버를 한 번만 만들고 AI 앱 쪽은 MCP 클라이언트를 한 번만 구현하면 끝이에요. M×N이 M+N으로 줄어듭니다.
USB-C가 나오기 전, 기기마다 다른 충전 케이블을 들고 다니던 시절을 떠올리면 정확합니다. MCP는 그 케이블 규격을 통일한 겁니다.
그런데 M+N이니 뭐니 하는 수식만 봐서는 체감이 잘 안 되실 겁니다. 실제로 같은 기능을 두 방식으로 만들어 보면 차이가 확실해져요.
같은 기능, 도입 전후 비교
“GitHub 이슈를 조회해서 답해주는 AI”를 만든다고 해볼게요.
MCP 이전에는 이런 작업이 전부 내 몫이었습니다.
- 도구 스키마 정의: “list_issues는 owner, repo, state를 받는다”를 JSON 스키마로 직접 작성
- 실제 호출 코드 작성: GitHub REST API 클라이언트, 토큰 관리, 페이지네이션 처리
- 실행 루프 구현: 모델이 도구를 호출하면 결과를 받아 다시 모델에게 돌려주는 왕복 코드
- 위 전부를 앱마다 반복: Claude 연동용 따로, 사내 챗봇용 따로
이슈 조회 하나에 보일러플레이트까지 수백 줄, 도구가 늘 때마다 1~3번 반복입니다.
MCP가 있으면 이렇게 끝납니다.
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"]
}
}
}스키마 정의, API 호출 코드, 인증 처리, 에러 처리가 전부 서버 안에 이미 들어 있어요. 나는 서버를 등록만 하고, “이 저장소에서 최근 버그 이슈 요약해줘”라고 말하면 됩니다.
| 항목 | 직접 연동 | MCP 서버 사용 |
|---|---|---|
| 작성 코드 | 스키마 + 호출 + 루프 수백 줄 | 설정 5줄 |
| 인증·에러 처리 | 직접 구현 | 서버에 내장 |
| 다른 AI 앱 추가 | 처음부터 다시 | 같은 서버 재사용 |
| 도구 추가 | 코드 수정·재배포 | 서버 업데이트만 |
특히 마지막 줄이 중요합니다. 서버에 기능이 추가돼도 내 쪽 코드는 한 줄도 안 바뀐다는 것, 이게 바로 표준화의 힘이에요.
내부 구조, 호스트-클라이언트-서버
MCP의 등장인물은 셋입니다.
| 구성 요소 | 역할 | 예시 |
|---|---|---|
| 호스트 | 사용자가 쓰는 AI 앱 | Claude Desktop, Cursor |
| 클라이언트 | 호스트 안에서 서버와 1:1 통신 | 호스트에 내장 |
| 서버 | 도구·데이터를 노출하는 프로그램 | GitHub 서버, DB 서버 |
호스트 하나가 클라이언트 여러 개를 띄우고, 클라이언트 하나가 서버 하나와 연결됩니다. 통신 규격은 JSON-RPC 2.0이고, 연결 방식은 로컬 프로세스면 stdio, 원격이면 HTTP 스트리밍을 씁니다.
서버가 노출하는 기능은 세 종류로 나뉩니다.
- 도구(tools): 모델이 호출하는 함수. “이슈 생성”, “쿼리 실행” 같은 동작
- 리소스(resources): 모델이 읽는 데이터. 파일 내용, DB 스키마 같은 읽기 자료
- 프롬프트(prompts): 서버가 미리 준비한 프롬프트 템플릿
핵심은 도구 목록을 런타임에 묻는다는 점입니다. 클라이언트가 서버에 접속하면 “너 뭐 할 수 있어?“라고 묻고, 서버가 도구 목록과 스키마를 돌려줘요. 앞서 본 “서버가 업데이트돼도 내 코드는 그대로”가 가능한 이유입니다.
function calling이랑 뭐가 다른데?
여기까지 읽으면 이런 의문이 듭니다. “그거 function calling으로 이미 되던 거 아니야?”
층이 다릅니다. function calling은 모델과 대화하는 규약이에요. “모델아, 이런 함수들이 있으니 필요하면 호출 형식으로 답해라”라는 약속이죠. 함수를 어떻게 구현하고 어디서 가져올지는 전적으로 개발자 몫입니다.
MCP는 그 함수들을 배포하고 재사용하는 규약입니다. 도구의 구현·인증·문서를 서버라는 패키지로 묶어서, 어떤 AI 앱이든 꽂아 쓸 수 있게 만든 거예요.
function calling이 “함수 호출 문법”이라면, MCP는 “함수들이 담긴 라이브러리 생태계”입니다. 실제로 MCP 클라이언트는 내부적으로 function calling을 그대로 사용해요. 대체 관계가 아니라 위아래 층 관계입니다.
그래서 “function calling vs MCP 중 뭘 쓰지?“는 질문 자체가 성립하지 않습니다. 내 앱 하나에서만 쓸 함수 두어 개면 function calling 직접 구현으로 충분하고, 여러 앱에서 재사용하거나 남이 만든 도구를 가져다 쓸 거면 MCP가 맞아요.
지금 바로 붙여볼 만한 대표 서버
생태계가 빠르게 크고 있어서, 이미 웬만한 도구는 서버가 나와 있습니다. 반응이 좋은 다섯 개만 추렸어요.
| 서버 | 할 수 있는 일 |
|---|---|
| Playwright | AI가 브라우저를 직접 조작. 클릭·입력·스크린샷 |
| Figma | 디자인 시안을 읽어 프론트엔드 코드로 변환 |
| Notion | 문서·회의록 검색과 정리, 페이지 생성 |
| GitHub | 이슈·PR 조회와 생성, 코드 검색 |
| Supabase(Postgres) | 자연어로 DB 질의, 스키마 파악 |
하나만 꼽으라면 Playwright입니다. 연결해 두고 “이 사이트 들어가서 회원가입 폼 채우고 스크린샷 찍어줘”라고 말해보세요. AI가 브라우저를 열고 실제로 클릭하고 타이핑하는 걸 보면, 도구를 연결한다는 게 왜 판을 바꾸는 일인지 굳이 설명할 필요가 없어집니다. E2E 테스트 자동화나 반복적인 웹 작업에 바로 써먹을 수 있고요.
Figma도 프론트엔드 개발자라면 체감이 큽니다. 시안 보고 마크업을 손으로 옮기던 작업이, 시안을 직접 읽는 AI에게 “이 프레임 React 컴포넌트로 만들어줘”라고 시키는 작업으로 바뀌거든요.
주의할 점과 한계
만능은 아닙니다. 실무에서 걸리는 지점도 짚어둘게요.
먼저 보안입니다. MCP 서버는 모델에게 실행 권한을 주는 통로라서, 신뢰할 수 없는 서버를 붙이면 프롬프트 인젝션으로 데이터가 새어 나갈 수 있습니다. 공식 레지스트리나 검증된 서버만 쓰는 게 안전해요.
컨텍스트 비용도 있습니다. 서버를 많이 붙일수록 도구 정의가 컨텍스트 윈도우를 잡아먹어서, 오히려 모델 성능이 떨어지는 역설이 생깁니다. 위 표에서도 지금 필요한 것만 골라 붙이는 편이 낫습니다.
마무리
MCP는 “모델을 더 똑똑하게” 만드는 기술이 아니라 “모델이 손을 뻗을 수 있는 범위”를 표준화한 기술입니다. 직접 연동으로 수백 줄 짜던 일이 설정 몇 줄이 된 것, 그리고 남이 만든 도구를 그대로 꽂아 쓰는 생태계가 생긴 것. 이 두 가지가 본질이에요.
다음 글에서는 MCP와 자주 비교되는 Claude Code의 Skill, 그리고 서브에이전트가 각각 어떤 역할인지 정리하겠습니다.