MCP와 API는 무엇이 다른가 — 'MCP가 API를 대체한다'는 오해
MCP는 API를 대체하지 않는다. 워크플로를 누가 결정하는가, 클라이언트가 누구인가 — 두 질문으로 정리하는 MCP와 API의 관계.
MCP(Model Context Protocol)가 퍼지면서 “이제 API는 필요 없다”, “MCP가 API를 대체한다”는 말이 자주 들립니다.
결론부터 말하면 틀린 말입니다. 그런데 왜 이런 오해가 생겼는지는 이해할 만합니다. 둘은 경쟁 관계가 아니라 층이 다른 물건인데, 이름만 나란히 놓고 비교하니 대체재처럼 보이는 겁니다.
이 글에서는 두 개의 질문으로 정리합니다.
- 워크플로를 누가 결정하는가 — 개발자인가, 모델인가
- 클라이언트가 누구인가 — 프로그램인가, 모델인가
이 두 개만 잡으면 나머지는 자연스럽게 따라옵니다.
1. 전통적인 API가 하던 일
전자상거래 앱을 만든다고 해봅시다.
고객이 주문 페이지를 열면 앱이 주문 API를 호출하고, 응답받은 주문 내역을 화면에 뿌립니다. 고객이 새 주문을 넣으면 결제 API를 부르고, 이어서 재고 API로 재고를 차감하고, 마지막으로 이메일 API로 확인 메일을 보냅니다.
여기서 중요한 건 워크플로가 예측 가능하다는 점입니다. 개발자가 엔드포인트를 고르고, 순서를 정하고, 모든 단계를 통제합니다.
그리고 이게 정확히 API가 설계된 목적입니다. 소프트웨어끼리 통신하는 것.
2. 사용자가 AI에게 말을 걸면 문제가 달라진다
이제 시나리오를 바꿔봅시다. 고객이 버튼을 누르는 대신 AI 어시스턴트에게 이렇게 말합니다.
“내 최근 주문 찾아서 배송 정보를 메일로 보내줘”
이건 완전히 다른 문제입니다. 모델은 사용자가 뭘 원하는지는 이해하지만,
- 어떤 API가 존재하는지 모릅니다
- 어떤 API를 먼저 불러야 하는지 모릅니다
- 그 API들이 어떤 입력을 받는지 모릅니다
그렇다고 회사의 API 문서 전체를 모델에 하드코딩해 넣을 수도 없습니다. 이게 MCP가 풀려는 문제입니다.
두 번째 영상에서는 이 상황을 이렇게 비유합니다.
API는 잠긴 캐비닛과 같다. 어떤 서랍을 열어야 하는지, 열쇠가 어떻게 생겼는지 정확히 알아야 한다. 그런데 모델은 라벨도 없는 캐비닛 안에 뭐가 들었는지 이해하려 애쓰는 쪽에 가깝다.
그래서 지금까지는 어떻게 했느냐 — 프롬프트로 계속 설명했습니다. “Jira 티켓을 만들려면 이 엔드포인트에 이 필드들을 넣어서 호출해”, “메일에 답장하려면 Gmail에 이 페이로드로…” 서비스가 늘어날수록 이 설명은 감당이 안 됩니다.
3. 용어 두 개만 정리하고 갑니다
도구 (Tool)
AI 애플리케이션이 수행할 수 있는 동작입니다.
- Gmail을 다룬다면 →
search_emails,create_draft,send_email - GitHub을 다룬다면 →
get_commit_history,create_issue,create_pull_request
모델이 골라 쓸 수 있는 능력 정도로 생각하면 됩니다.
MCP 서버
Model Context Protocol을 써서 AI 애플리케이션에 능력을 노출하는 프로그램입니다.
- Tools — 동작을 수행
- Resources — 정보를 제공 (파일, 문서, DB 레코드)
여기서 핵심은 모델이 Gmail이나 GitHub에 직접 연동되지 않는다는 점입니다. AI 애플리케이션이 MCP 서버에 붙고, 어떤 능력이 있는지 물어봐서 알아냅니다.
4. 같은 문제를 MCP는 이렇게 푼다
아까 전자상거래로 돌아갑니다. 이미 고객 API, 주문 API, 이메일 API가 있습니다.
이걸 갈아엎지 않습니다. 그대로 둡니다. 대신 MCP 서버를 하나 세우고 도구 세 개를 노출합니다 — get_customer, get_latest_order, send_email.
사용자가 “내 최근 주문 찾아서 배송 정보를 메일로 보내줘”라고 하면,
- AI 애플리케이션이 MCP 서버에 붙어 사용 가능한 도구를 발견합니다
- 각 도구가 뭘 하는지, 어떤 입력을 받는지 설명까지 함께 받습니다
- 모델이 요청에 맞는 도구를 고릅니다 —
get_customer→get_latest_order→send_email - 이 도구들은 뒤에서 기존 API를 그대로 호출합니다
5. 핵심 차이 ① — 워크플로를 누가 결정하는가
이게 가장 큰 차이입니다.
| 전통적인 API | MCP | |
|---|---|---|
| 워크플로 결정 | 개발자가 코드로 | 모델이 추론으로 |
| 위치 | 애플리케이션 코드 | 모델의 추론 계층 |
| 새 기능 추가 | 코드 수정 후 배포 | 서버에 도구 추가 → 다음 연결 때 자동 발견 |
내일 회사가 cancel_order 도구를 추가했다고 해봅시다. AI 애플리케이션이 다음에 MCP 서버에 연결할 때 그 도구를 발견하고 모델에게 넘겨줍니다. 앱 코드를 고칠 필요가 없습니다.
6. 핵심 차이 ② — 클라이언트가 누구인가
두 번째 영상이 짚은 지점인데, 저는 이게 제일 본질적이라고 봅니다.
- API의 클라이언트 = 다른 프로그램, 혹은 사람
- MCP의 클라이언트 = 모델 그 자체
API는 코드 레벨의 계약입니다. 양쪽 모두 뭐가 오갈지 정확히 안다고 전제합니다. MCP는 모델과 환경 사이의 의미론적(semantic) 프로토콜입니다. 그 전제를 뒤집습니다.
이 차이가 설계 전체를 바꿉니다. API는 결정론적(deterministic) 시스템을 위해 만들어졌고, MCP는 확률적(probabilistic) 시스템을 위해 만들어졌습니다.
7. 핵심 차이 ③ — 발견하는 방식
개발자가 API를 쓸 때는 이렇게 합니다.
1
2
문서를 읽는다 → 엔드포인트를 찾는다 → 요청 형식을 파악한다
→ 인증을 처리한다 → 연동 코드를 작성한다
MCP는 서버가 표준화된 설명을 스스로 노출합니다. 각 도구가 무엇을 하고 어떤 입력을 받는지 JSON 스키마로요.
1
연결한다 → 도구 목록과 스키마를 받는다 → 끝
정적인 사용설명서 대신, 기계가 읽을 수 있는 살아있는 지도를 주는 셈입니다. 그래서 100개의 커스텀 연동을 만드는 대신, MCP 인터페이스 하나를 만들면 호환되는 모든 모델이 바로 씁니다.
8. 그래서 계층은 이렇게 된다
“MCP가 API를 대체한다”가 왜 틀렸는지, 계층으로 보면 명확합니다.
MCP는 백엔드를 대체하지 않습니다. 모델과 API 사이의 미들웨어를 대체합니다.
9. 요청 하나가 실제로 흐르는 경로
10. 한 장으로 정리
| API | MCP | |
|---|---|---|
| 클라이언트 | 프로그램 · 사람 | 모델 |
| 계약의 성격 | 코드 레벨 계약 | 의미론적(semantic) 프로토콜 |
| 워크플로 결정 | 개발자 (코드) | 모델 (추론) |
| 발견 방식 | 문서를 읽고 연동 코드 작성 | 스키마를 받아 자동 발견 |
| 대상 시스템 | 결정론적 | 확률적 |
| 확장 | 연동마다 코드 추가 | 도구 추가 → 자동 발견 |
| 위치 | 시스템 통합의 기반 | API 위의 한 층 |
HTTP 비유가 잘 들어맞습니다. FTP, Gopher, Telnet이 각자 놀던 시절, HTTP가 표준이 되자 웹 전체가 상호운용 가능해졌습니다. MCP는 AI 에이전트 세계에서 같은 일을 하려 합니다. 커넥터를 한 번 만들면 Claude든 GPT든 Gemini든 바로 씁니다.
11. 아직 이른 부분
장밋빛만 이야기하면 정직하지 않습니다. 두 번째 영상이 짚은 한계는 실무에서 그대로 부딪히는 것들입니다.
채택(adoption) 프로토콜은 생태계가 같은 표준에 합의해야 의미가 있습니다. 서버·클라이언트·도구가 아직 다 갖춰지지 않았습니다.
보안과 권한 — 제일 중요합니다 모델이 프로토콜을 통해 도구를 직접 호출할 수 있게 되면, 명확한 권한 계층이 반드시 필요합니다. 모델이 실수로 메일을 보내거나, 파일을 지우거나, DB를 크게 바꾸는 일은 없어야 합니다. API는 인증·키·레이트리밋으로 이걸 처리해왔습니다. MCP도 스펙에 capability, scope, 인증 방식을 정의하고 있지만 아직 초기입니다.
개발자의 사고방식 우리 대부분은 API 세계에서 자랐습니다. 엔드포인트와 라우트로 생각합니다. MCP는 능력(capability)과 맥락(context)으로 생각하라고 요구합니다. 어떻게 하는지가 아니라 무엇을 할 수 있는지를 기술하는 시스템을 설계하라는 것 — 꽤 큰 전환입니다.
마치며
정리하면 이렇습니다.
- API는 죽지 않았습니다. 여전히 시스템 통합의 기반이고, 실제 비즈니스 동작을 수행하는 건 API입니다
- 많은 MCP 서버가 기존 API 위에 만들어집니다. MCP 서버는 AI 애플리케이션과 기존 시스템 사이의 어댑터입니다
- 바뀐 건 클라이언트입니다. 프로그램이 아니라 모델이 소프트웨어의 1급 사용자가 되었습니다
다음에 누가 “MCP가 API를 대체한다”고 하면 이렇게 답하면 됩니다.
대체가 아니라 한 층 위에 얹는 것이다. 정적인 라우트를, 모델이 추론할 수 있는 살아있는 인터페이스로 바꾸는 것.
영상으로 보기
기초부터 짚고 싶다면 이 영상을 먼저 보세요. (AI 에이전트 기초 EP.04 — 도구 사용)
📺 Peanut Radio AI 유튜브 채널 — AI 시대의 IT, 기초부터 실무까지
참고
이 글은 아래 두 영상의 내용을 정리하고 재구성한 것입니다.
- MCP vs API Explained: Do We Still Need API After MCP? — Cloud X Berry (6분 42초)
- MCP vs API: Why traditional APIs are failing AI agents (12분 25초)