MCP
Model Context Protocol
AI를 외부 도구·데이터에 꽂는 공용 규격. 「AI계의 USB-C」로 불린다.
쉽게 말하면
MCP(Model Context Protocol, 모델 컨텍스트 프로토콜)는 AI를 바깥 도구·데이터에 연결하는 공용 규격입니다. 2024년 말 앤스로픽이 공개했고, 이후 오픈AI·구글까지 채택하면서 업계 표준이 됐습니다. 별명은 「AI계의 USB-C」 — 비유가 아니라 거의 정의에 가깝습니다.
MCP 이전에는 AI에 도구 하나를 붙일 때마다 전용 연결을 따로 만들어야 했습니다. 기기마다 충전 단자가 다르던 시절과 같았죠. MCP는 단자를 통일했습니다. 규격에 맞춰 「MCP 서버」를 하나 만들어 두면, 클로드든 챗GPT든 규격을 아는 AI 어디에나 꽂힙니다.
이게 왜 뉴스가 되냐면, AI 에이전트 시대의 기반 시설이기 때문입니다. AI가 캘린더를 읽고, 사내 문서를 검색하고, 결제까지 하려면 도구 연결이 필수인데 그 배선 표준이 MCP입니다. 「○○ 서비스가 MCP를 지원한다」는 기사는 「그 서비스에 AI를 꽂을 수 있게 됐다」로 읽으면 됩니다.
기사에서 이렇게 나와요
「주요 AI 3사가 모두 MCP 지원을 공식화하며 사실상 표준이 됐다」 — 충전 단자 통일 같은 사건이라, 이후로는 「어떤 서비스가 MCP로 연결됐나」가 후속 뉴스로 이어집니다.
직접 해보기
- 클로드 데스크톱 앱이나 챗GPT 설정에서 「커넥터(Connectors)」 항목을 찾아보세요 — 이 커넥터들이 MCP로 연결됩니다.
- 구글 드라이브나 캘린더 같은 커넥터를 하나 연결해 봅니다.
- 「내 드라이브에서 지난달 회의록 찾아서 요약해 줘」라고 시켜 보세요. AI가 외부 데이터에 손을 뻗는 것 — 그 배선이 MCP입니다.
깊이 알아보기
AI가 앱과 데이터에 손을 뻗는 방식에도 공용 문법이 생겼습니다.
MCP는 AI 애플리케이션과 외부 시스템이 도구, 자료, 작업 양식을 주고받는 공개 프로토콜입니다. 연결은 쉬워지지만, 무엇을 믿고 실행할지는 여전히 사람이 설계해야 합니다.
3분 요약
- MCP는 Model Context Protocol의 약자로, AI 애플리케이션이 파일, 데이터베이스, 업무 서비스 같은 외부 기능을 일정한 방식으로 발견하고 이용하게 해 줍니다.
- 사용자가 만나는 호스트 안에서 MCP 클라이언트가 연결을 관리하고, MCP 서버는 도구, 리소스, 프롬프트를 제공합니다. 서버가 AI 모델 자체인 것은 아닙니다.
- 표준화는 연결 비용을 줄일 뿐 자동으로 안전을 보장하지 않습니다. 권한을 작게 나누고, 실행 전 확인하며, 외부 콘텐츠의 지시를 신뢰하지 않는 운영이 함께 필요합니다.
왜 지금 알아야 하나
AI가 답변을 넘어 행동하기 시작했다
오늘의 AI 애플리케이션은 문장을 만드는 데서 그치지 않고 일정 조회, 문서 검색, 코드 실행 같은 작업을 합니다. 모델과 각 서비스를 잇는 방식이 제각각이면 연결을 추가할 때마다 별도 개발과 검토가 필요합니다.
도구 생태계에 공통 접점이 필요해졌다
MCP를 지원하는 호스트와 서버는 같은 메시지 규칙으로 기능 목록과 호출 결과를 주고받을 수 있습니다. 모든 제품이 완전히 똑같이 동작한다는 뜻은 아니지만, 매번 처음부터 전용 통합을 만드는 부담은 줄어듭니다.
연결이 늘수록 신뢰 경계도 중요해졌다
AI가 읽기 전용 자료뿐 아니라 메일 발송이나 데이터 변경 도구까지 만날 수 있게 되면서 인증, 승인, 감사 기록이 제품의 핵심이 됐습니다. 편리한 연결과 안전한 실행은 별개의 설계 과제입니다.
어떻게 작동하나
1. 호스트가 연결을 연다
호스트는 사용자가 대화하는 AI 앱이나 개발 도구입니다. 호스트 안의 MCP 클라이언트가 각 서버와 연결을 만들고, 지원 기능과 프로토콜 버전을 협의하며 통신을 관리합니다.
2. 서버의 기능을 발견한다
서버는 자신이 제공하는 도구, 리소스, 프롬프트 목록을 알립니다. 도구는 검색이나 변경처럼 실행 가능한 동작이고, 리소스는 읽어 올 수 있는 데이터이며, 프롬프트는 사용자가 선택해 활용할 수 있는 작업 양식입니다.
3. 모델과 사용자가 필요한 기능을 고른다
호스트는 발견한 기능의 이름, 설명, 입력 형식을 모델에 보여줄 수 있습니다. 모델이 작업에 맞는 도구 호출을 제안하면 호스트는 권한과 사용자 승인을 확인한 뒤 구조화된 인수를 담아 서버에 요청합니다. 발견됐다는 사실만으로 실행이 허용되는 것은 아닙니다.
4. 결과를 받아 다음 판단에 쓴다
서버는 실행 결과나 오류를 클라이언트에 돌려주고, 호스트는 필요한 내용을 모델의 컨텍스트에 넣습니다. 모델은 그 결과를 바탕으로 답하거나 다음 호출을 제안합니다. 실제 데이터 변경은 모델의 문장이 아니라 서버와 연결된 시스템에서 일어납니다.
흐름 한눈에 보기
사용자 요청 → 호스트 → MCP 클라이언트가 서버 기능 발견 → 모델이 도구 호출 제안 → 호스트가 권한과 승인 확인 → MCP 서버가 외부 시스템 실행 → 결과 반환 → 모델이 답변 또는 다음 행동 제안
도입 전과 후
이전: 서비스마다 전용 연결
AI 앱이 캘린더, 파일 저장소, 이슈 관리 도구를 쓰려면 각 서비스의 인증과 호출 방식을 따로 구현해야 했습니다. 다른 AI 앱으로 옮기면 비슷한 연결 코드를 다시 작성하는 경우가 많았습니다.
이후: 같은 프로토콜로 기능 공개
서비스 쪽은 MCP 서버를 통해 기능과 입력 형식을 설명하고, 호스트 쪽은 MCP 클라이언트로 이를 발견하고 호출합니다. 구현과 지원 범위는 제품마다 다르지만 서로 맞물릴 공통 접점이 생깁니다.
변하지 않는 것: 권한과 책임
공용 규격이 생겨도 서버의 품질, 데이터 정확성, 사용자 동의까지 자동으로 해결되지는 않습니다. 어떤 서버를 설치하고 어떤 동작을 승인할지는 호스트 운영자와 사용자의 책임으로 남습니다.
예시로 이해하기
회의 준비 도우미
사용자가 내일 고객 회의를 준비해 달라고 요청합니다. 호스트는 캘린더 서버의 일정 조회 도구로 참석자와 시간을 확인하고, 문서 서버의 리소스에서 최신 제안서를 읽습니다. AI는 두 결과를 종합해 안건을 만들지만, 캘린더 수정 도구는 사용자가 변경을 승인하기 전까지 호출하지 않습니다.
개발 이슈 조사
코딩 도구가 저장소 서버에서 오류가 난 파일을 읽고, 이슈 관리 서버의 검색 도구로 같은 증상의 보고를 찾습니다. 발견된 이슈 본문에 다른 명령을 실행하라는 문장이 있어도 그것은 신뢰할 수 없는 데이터로 취급합니다. AI는 조사 근거로만 사용하고, 셸 실행이나 외부 전송은 별도 권한과 확인을 거칩니다.
직접 해보기
1. 읽기 전용 목표를 고른다
처음에는 공개 문서 검색이나 로컬 메모 읽기처럼 결과를 되돌릴 필요가 없는 작업을 선택합니다. 계정 변경이나 메시지 발송 기능부터 연결하지 않습니다.
2. 호스트가 표시하는 서버 정보를 확인한다
서버 제공자, 설치 출처, 요청 권한, 접근할 데이터 범위를 살펴봅니다. 이름이 익숙하다는 이유만으로 공식 서버라고 단정하지 않습니다.
3. 발견된 기능을 살펴본다
연결 뒤 호스트에 표시되는 도구와 리소스 목록을 확인합니다. 예상하지 못한 쓰기, 삭제, 외부 전송 기능이 있으면 비활성화하거나 연결을 중단합니다.
4. 호출과 결과를 대조한다
간단한 조회를 요청한 뒤 어떤 도구가 어떤 인수로 호출됐고 무엇이 반환됐는지 기록에서 확인합니다. 쓰기 작업을 시험한다면 별도 테스트 계정에서 실행 직전 승인 화면이 나오는지도 확인합니다.
한계와 주의점
호환성이 동일한 경험을 뜻하지는 않는다
MCP 규격을 지원해도 호스트마다 제공 기능, 승인 화면, 전송 방식, 지원 버전이 다를 수 있습니다. 한 서버가 모든 MCP 제품에서 같은 수준으로 작동한다고 가정하면 안 됩니다.
서버는 새로운 신뢰 경계다
서버는 민감한 데이터와 실제 동작에 접근할 수 있으므로 취약하거나 악의적인 서버는 정보를 노출하거나 원치 않는 요청을 시도할 수 있습니다. 최소 권한, 명시적 동의, 자격 증명 분리, 로그 검토가 필요합니다.
프롬프트 인젝션은 프로토콜만으로 사라지지 않는다
문서나 웹페이지에 숨은 지시가 모델을 속여 다른 도구를 부르게 할 수 있습니다. 외부 콘텐츠를 명령이 아닌 데이터로 구분하고, 중요한 호출은 정책 검사와 사용자 확인을 거쳐야 합니다. 이런 통제는 위험을 낮추지만 모든 공격을 막는다고 보장할 수는 없습니다.
자주 묻는 질문
MCP 서버 안에 AI 모델이 들어 있나요?
반드시 그렇지는 않습니다. 일반적으로 모델과 사용자 인터페이스는 호스트 쪽에 있고, MCP 서버는 외부 데이터나 기능을 표준 형식으로 제공합니다. 서버가 별도의 AI 기능을 품을 수는 있지만 MCP의 필수 조건은 아닙니다.
도구, 리소스, 프롬프트는 어떻게 다른가요?
도구는 서버에서 실행하는 동작, 리소스는 애플리케이션이 읽어 컨텍스트로 쓸 데이터, 프롬프트는 사용자가 선택할 수 있도록 서버가 제공하는 작업 양식입니다. 실제 노출 방식은 호스트 구현에 따라 달라질 수 있습니다.
MCP 서버를 연결하면 안전한가요?
연결 자체가 안전을 인증하지는 않습니다. 서버의 출처와 권한을 확인하고, 민감한 동작은 승인 절차를 두며, 외부 데이터에서 온 지시가 도구 호출로 이어지지 않도록 통제해야 합니다.
출처
- Model Context Protocol specification: Architecture — Model Context Protocol
- Model Context Protocol specification: Tools — Model Context Protocol
- Model Context Protocol security best practices — Model Context Protocol
MCP와 API, 뭐가 다른가
AI가 알아서 쓰는 공용 규격이냐, 사람이 짜 넣는 개별 창구냐
둘 다 「AI를 바깥과 잇는다」고 설명되기 때문에 같은 말의 다른 이름처럼 들립니다. 그런데 API는 서비스마다 제각각인 개별 창구이고, MCP는 그 창구들의 모양을 통일하자는 약속입니다. 층이 다릅니다 — MCP를 지원하는 서비스도 그 속에서는 결국 API를 씁니다.
| 구분 | MCP | API |
|---|---|---|
| 무엇인가 | 창구의 모양을 통일한 공용 규격 | 서비스마다 따로 있는 주문 창구 |
| 누가 쓰나 | AI가 연결된 도구를 스스로 골라 쓴다 | 사람이 코드를 짜서 부른다 |
| 부르는 방향 | 대개 AI가 바깥 도구를 갖다 쓴다 | 대개 앱이 AI를 갖다 쓴다 |
| 붙이는 비용 | 규격에 맞춰 한 번 만들면 어느 AI에나 꽂힌다 | 서비스 100개면 연결 100개를 따로 만든다 |
| 비유 | USB-C 단자 규격 | 식당의 주문 창구 |
| 기사에서 | 에이전트·커넥터 같은 연결 이야기와 붙는다 | 가격 인하·사용량 같은 돈 이야기와 붙는다 |
가를 때는앱이 AI를 갖다 쓰는 이야기면 API, AI가 내 도구와 데이터를 갖다 쓰는 이야기면 MCP입니다.
MCP와 스킬, 뭐가 다른가
도구를 꽂아 주느냐, 요령을 가르쳐 주느냐
에이전트 기사에 늘 같이 나오고, 둘 다 「AI에게 뭔가를 더해 준다」고 설명되니 비슷해 보입니다. 하지만 하나는 손을 달아 주는 일이고 하나는 매뉴얼을 쥐여 주는 일입니다. 손 없이 매뉴얼만 있으면 읽고 못 하고, 매뉴얼 없이 손만 있으면 우리 방식대로 안 합니다.
| 구분 | MCP | 스킬 |
|---|---|---|
| 무엇을 주나 | 바깥 도구와 데이터에 닿는 연결 | 그 일을 우리 방식으로 하는 절차 |
| 정체 | 업계가 함께 쓰는 규격 | 지시문과 참고 자료를 담은 폴더 |
| 누가 만드나 | 서비스를 가진 회사가 서버를 연다 | 쓰는 사람이 직접 쓴다. 글만 쓸 줄 알면 된다 |
| 예를 들면 | 구글 드라이브·캘린더·사내 문서에 연결 | 우리 회사 견적서 양식, 우리 팀 공지 말투 |
| 비유 | 연장과 열쇠 | 업무 매뉴얼 |
가를 때는AI가 손을 뻗을 곳이 없어서 못 하면 MCP가 필요하고, 할 줄은 아는데 우리 방식이 아니면 스킬이 필요합니다.
함께 볼 용어
이 용어가 나온 기사
아직 이 용어를 다룬 기사가 없습니다. 새 기사가 나오면 여기 자동으로 붙습니다.