MCP란 무엇인가를 지금 다시 보는 이유는 단순합니다. 요즘 AI 에이전트는 답변만 하는 것이 아니라 파일을 읽고, 문서를 찾고, 이슈를 조회하고, 실제 작업까지 이어지기 때문입니다.
문제는 모델이 아니라 연결입니다. 도구를 한두 개 붙일 때는 wrapper 함수나 function calling만으로도 충분해 보이지만, 도구 수가 늘고 여러 AI 클라이언트가 섞이기 시작하면 연결 방식 자체가 운영 문제로 바뀝니다.
그래서 MCP를 따로 알아둘 가치가 생깁니다. MCP는 더 똑똑한 모델이 아니라, AI 앱과 외부 도구 사이의 연결 구조를 표준화하려는 시도이기 때문입니다.
MCP를 왜 따로 알아야 할까
많은 사람이 MCP를 처음 볼 때 그냥 function calling의 다른 이름이거나, 내부 API를 wrapper로 감싸는 방식의 또 다른 변형이라고 생각합니다. 작은 프로젝트라면 그 생각이 맞을 수 있습니다.
하지만 같은 도구를 여러 AI 클라이언트에서 써야 하고, 도구뿐 아니라 문서와 정책 같은 읽을 맥락도 함께 노출해야 하며, 읽기와 쓰기 권한을 다르게 다뤄야 한다면 중요한 것은 호출 한 번이 아니라 연결 구조가 됩니다.
즉 MCP의 핵심은 모델 성능이 아니라 연결 재사용, 권한 경계, 다중 클라이언트 호환성입니다.
MCP란 무엇인가 한 줄 정의
MCP는 AI 애플리케이션이 외부 도구와 데이터 소스에 표준 방식으로 접근하도록 만든 오픈 프로토콜입니다.
공식 문서는 USB-C 비유를 자주 사용합니다. 다만 실무에서는 모델은 무엇을 할지 판단하고, 애플리케이션은 대화 흐름과 승인 UX를 관리하며, MCP는 외부 시스템과 연결되는 공통 방식을 정리한다고 이해하는 편이 더 정확합니다.
- 모델은 무엇을 할지 판단한다
- 애플리케이션은 대화 흐름과 승인 UX를 관리한다
- MCP는 외부 시스템과 연결되는 공통 방식을 정리한다
- 서버는 실제 도구와 데이터를 제공한다
MCP는 스택 어디에 있나
MCP는 모델 계층보다 연결 계층에 더 가깝습니다. 모델은 추론과 선택을 담당하고, 애플리케이션은 상태와 승인 UX를 담당하며, MCP는 외부 도구와 데이터에 접근하는 공통 방식을 제공합니다.
- 모델 계층: 추론, 답변 생성, tool 선택 판단
- 애플리케이션 계층: 대화 흐름, 승인 UX, 상태 관리
- 연결 계층: 외부 도구와 데이터에 접근하는 공통 방식
- 시스템 계층: 파일, DB, SaaS, 사내 서비스
이 관점을 놓치면 MCP를 모델 기능처럼 과대평가하거나, 반대로 단순 플러그인처럼 과소평가하게 됩니다. 실무에서는 둘 다 틀립니다.
기본 구조: host, client, server
MCP는 보통 host, client, server 세 층으로 설명합니다. host는 사용자가 실제로 쓰는 AI 앱이고, client는 host 안에서 특정 MCP server와 연결을 유지하는 구성요소이며, server는 실제 도구나 데이터를 제공하는 프로그램입니다.
- host: 사용자가 직접 만나는 AI 앱
- client: 서버 연결을 관리하고 요청과 응답을 주고받는 중간 층
- server: filesystem, GitHub, 문서 검색, 데이터베이스처럼 실제 기능을 제공하는 쪽
핵심은 host가 모든 외부 시스템의 세부 구현을 직접 품지 않아도 된다는 점입니다. 필요한 기능은 server가 표준 방식으로 내놓고, host는 그것을 연결해 씁니다.
MCP 구성요소: tools, resources, prompts
tools는 행동이다
tools는 파일 읽기, 특정 이슈 조회, 코멘트 작성, 배포 요청, 로그 검색처럼 실행 가능한 행동입니다.
resources는 읽을 맥락이다
resources는 프로젝트 문서, 데이터베이스 스키마, 정책 문서, API 응답 샘플, 장애 대응 매뉴얼처럼 읽고 판단에 활용할 데이터입니다.
prompts는 재사용 가능한 상호작용 틀이다
prompts는 코드 리뷰 체크리스트, 보안 분석 절차, 장애 원인 분석 흐름처럼 반복해서 재사용할 수 있는 안내 템플릿입니다. 이 구분 덕분에 모든 것을 tool로 몰아 넣지 않고 더 구조적으로 다룰 수 있습니다.
function calling과 무엇이 다른가
겹치는 부분은 있지만 같은 층의 개념은 아닙니다. function calling은 보통 애플리케이션이 모델에게 함수 목록을 주고, 모델이 그중 하나를 선택해 호출하는 흐름입니다. 즉 중심이 애플리케이션 내부에 있습니다.
반면 MCP는 도구와 데이터를 외부 server 형태로 분리하고, 그것을 host와 client가 표준 방식으로 연결하게 합니다. 그래서 function calling은 실행 패턴에 가깝고, MCP는 연결 아키텍처에 가깝다고 보는 편이 더 정확합니다.
- function calling은 한 앱 안에서 함수 목록을 직접 관리하기 좋다
- MCP는 도구 제공자와 도구 소비자 사이의 공통 규약을 만들기 좋다
- function calling은 작고 빠른 통합에 유리하다
- MCP는 재사용성과 다중 클라이언트 연결에 유리하다
- 둘은 경쟁 관계라기보다 서로 다른 층에서 함께 작동할 수 있다
wrapper 방식과 비교하면 무엇이 달라질까
작은 프로젝트에서는 wrapper 방식이 가장 현실적일 때가 많습니다. 하지만 규모가 커지면 같은 도구 설명이 앱마다 복제되고, 인자 형식과 설명 문구가 조금씩 달라지며, 어떤 권한으로 호출됐는지 추적하기도 어려워집니다.
MCP는 이런 편차를 줄이는 방향의 선택지입니다. 특히 여러 host가 같은 server를 재사용할 수 있다는 점이 크고, 이 부분이 단순 tool calling만으로는 잘 드러나지 않는 가치입니다.
왜 다중 클라이언트 시대에 더 중요해질까
지금은 같은 팀 안에서도 데스크톱 앱, IDE 확장, 내부 운영용 에이전트, 고객지원 인터페이스처럼 여러 AI 클라이언트가 함께 쓰일 수 있습니다. 각각이 같은 문서 저장소와 같은 이슈 시스템을 봐야 한다면 연결을 클라이언트마다 따로 구현하는 방식은 오래 버티기 어렵습니다.
이때 도구를 앱 안에 박아 넣는 대신 외부 server로 표준화해 두면 host가 바뀌어도 재사용 가능성이 높아집니다. 물론 모든 클라이언트가 동일한 수준으로 MCP를 지원하는 것은 아니지만, 연결 계층을 공통 구조로 잡아두는 것만으로도 운영 복잡도를 줄일 여지가 생깁니다.
실무 예시 1: 사내 개발 도우미
사내 개발 도우미를 만든다고 해보겠습니다. 저장소 파일 읽기, 최근 배포 정보 확인, 에러 로그 검색, 이슈 트래커 조회, 운영 문서 검색이 모두 필요할 수 있습니다.
- 개발자가 어제 장애와 관련된 최근 배포를 찾아달라고 묻는다
- 에이전트는 로그 검색 server에서 관련 에러를 찾는다
- 배포 문서 resource를 읽어 변경 범위를 확인한다
- 이슈 트래커 tool로 연결된 티켓과 담당자를 조회한다
- 결과를 묶어 원인 후보와 다음 확인 순서를 정리한다
여기서 핵심은 모델 혼자 모든 것을 아는 것이 아니라, 필요한 시스템 연결이 정돈되어 있다는 점입니다. 이런 구조에서 MCP의 가치는 호출 횟수보다 연결 일관성에서 나옵니다.
실무 예시 2: 고객 지원 에이전트
고객 지원 환경에서는 주문 조회 server, 환불 정책 resource, 상담 품질 가이드 prompt, 민감 작업 승인 tool 같은 구성이 가능합니다. 이 구조의 장점은 정책 문서를 읽고 주문 상태를 확인한 뒤, 필요하면 승인 절차를 거쳐 실제 처리까지 연결할 수 있다는 점입니다.
하지만 이런 환경에서는 더 조심해야 합니다. 조회와 쓰기를 같은 수준으로 자동화하면 문제가 생길 수 있기 때문입니다. 읽기 전용 도구와 쓰기 도구를 분리하고, 환불이나 계정 변경 같은 작업은 명시적 승인 단계를 두는 것이 중요합니다.
보안과 승인 설계는 왜 함께 봐야 할까
공식 specification은 사용자 동의, 데이터 프라이버시, tool safety 같은 원칙을 분명하게 다룹니다. OpenAI의 remote MCP 가이드도 custom server를 붙일 때 prompt injection과 과도한 권한 요청 위험을 따로 경고합니다.
- 읽기 전용 도구와 쓰기 도구를 분리하기
- 민감한 작업은 명시적 승인 단계 넣기
- 최소 권한 원칙으로 server 열기
- 신뢰하지 않는 외부 콘텐츠를 그대로 실행 흐름에 넣지 않기
- 호출 기록과 감사 로그를 남기기
쉽게 말해, 연결할 수 있다는 것과 자동으로 실행해도 된다는 것은 전혀 다른 문제입니다. MCP를 도입할수록 무엇을 더 쉽게 호출할지가 아니라, 무엇은 절대 자동 호출되면 안 되는지를 먼저 정해야 합니다.
조금 더 깊게 보면: 프로토콜, 전송, 확장 기능
공식 문서는 MCP를 단순 도구 목록이 아니라 프로토콜 계층으로 설명합니다. 데이터 교환은 JSON-RPC 2.0 기반으로 설명되고, 전송 방식으로 stdio와 streamable HTTP 같은 계층이 나오며, progress와 logging 같은 보조 기능, sampling과 roots, elicitation 같은 확장 개념도 함께 다뤄집니다.
이 말은 MCP를 함수 목록 포맷 정도로만 보면 작게 이해한 것이라는 뜻입니다. 실제로는 도구 발견, 맥락 전달, 상호작용 보조, 진행 상태 전달까지 포함하는 연결 프로토콜에 더 가깝습니다. 다만 스펙 전체와 현재 쓰는 클라이언트의 실제 지원 범위는 구분해서 봐야 합니다.
언제 MCP를 쓰고 언제 단순 방식으로 끝낼까
같은 도구를 여러 AI 클라이언트에서 써야 하고, 도구 수가 계속 늘어날 가능성이 높고, tool과 resource와 prompt를 함께 다뤄야 하며, 내부 시스템 연결을 표준화하고 싶다면 MCP를 검토할 가치가 큽니다.
반대로 한 앱에서만 쓰고, 도구 수가 매우 적고, 빠른 프로토타입이 우선이며, 읽기 전용 몇 개만 필요하다면 function calling이나 wrapper 접근이 더 맞을 수 있습니다. 결국 판단 기준은 최신 유행이 아니라 복잡도와 재사용성입니다.
처음 도입할 때 현실적인 순서
- 읽기 전용 use case 하나를 고른다
- 가장 자주 쓰는 조회형 도구 하나를 server로 분리한다
- host 하나와 server 하나로 가장 작은 흐름을 만든다
- 문서나 스키마 같은 resource를 붙여 맥락 품질을 높인다
- 승인 없는 쓰기 작업은 뒤로 미룬다
- 로그와 권한 정책을 먼저 정리한다
예를 들어 사내 문서 검색과 최근 장애 로그 조회 정도부터 시작하면, 가치도 빨리 확인되고 보안 부담도 비교적 낮습니다.
정리
MCP란 무엇인가를 다시 한 문장으로 정리하면, AI 에이전트가 외부 도구와 데이터를 더 일관되고 재사용 가능한 방식으로 연결하게 해주는 표준입니다.
이 표준을 따로 알아야 하는 이유는 도구 호출 한 번의 문제가 아니라, 여러 시스템과 여러 클라이언트를 오래 운영할 때 연결 구조가 곧 유지보수와 보안 문제가 되기 때문입니다. 그래서 MCP는 function calling의 경쟁자가 아니라, 그보다 바깥에서 연결을 표준화하는 계층으로 이해하는 편이 정확합니다.
관련 글로는 ReAct 논문 쉽게 이해하기, Claude Code란 무엇인가, Claude Code, Codex, Gemini CLI 비교를 함께 보면 흐름이 더 잘 잡힙니다.
주요 참고 문서는 MCP 공식 소개, MCP 아키텍처 문서, 최신 MCP specification, OpenAI function calling 가이드, OpenAI remote MCP 가이드입니다.
