한 줄 요약: MCP는 AI 앱이 파일·데이터베이스·검색 같은 바깥 시스템과 대화할 때 쓰는 공통 약속입니다. 새 능력을 주는 기술이 아니라 연결 방식을 하나로 맞춘 규격이라서, 배워야 할 것은 규격 자체보다 "내가 무엇을 연결했고 그것이 무엇을 할 수 있는가"입니다.
MCP가 무엇인지 공식 문서는 이렇게 설명합니다
MCP(Model Context Protocol) 공식 소개 문서는 MCP를 "AI 애플리케이션을 외부 시스템에 연결하기 위한 오픈소스 표준"이라고 정의합니다. 연결 대상으로는 로컬 파일과 데이터베이스 같은 데이터 소스, 검색 엔진과 계산기 같은 도구, 그리고 특별히 짜 둔 프롬프트 같은 작업 흐름을 듭니다. 비유도 문서에 직접 나옵니다. USB-C 포트가 여러 기기를 같은 방식으로 꽂게 해 주듯, MCP는 AI 앱을 외부 시스템에 같은 방식으로 꽂게 해 준다는 설명입니다.
MCP를 처음 공개한 곳도 문서로 확인됩니다. Anthropic의 발표문(2024년 11월 25일)은 MCP를 AI 어시스턴트를 콘텐츠 저장소, 업무 도구, 개발 환경 같은 데이터 소스에 연결하는 오픈 표준으로 소개합니다. 이때 함께 공개한 것은 MCP 사양과 SDK, Claude Desktop 앱의 로컬 MCP 서버 지원, 그리고 오픈소스 MCP 서버 저장소입니다. 예시로 든 연결 대상은 Google Drive, Slack, GitHub, Git, Postgres, Puppeteer이며, 초기 도입 사례로는 Block과 Apollo가 언급됩니다. 개발자는 데이터를 MCP 서버로 열어 두거나, MCP 클라이언트가 되는 AI 앱을 만들 수 있다는 구조 설명도 같은 글에 있습니다.
이 비유에서 놓치기 쉬운 점이 하나 있습니다. USB-C 포트가 있다고 해서 기기가 안전하거나 쓸모 있는 것은 아닙니다. 포트는 꽂는 모양을 통일할 뿐, 꽂은 기기가 무엇을 하는지는 보장하지 않습니다. MCP도 같습니다. 연결 규격이 같다는 것과 연결된 도구를 믿어도 된다는 것은 별개의 문제입니다.
규격이 없을 때 생기던 문제
AI에게 내 파일, 캘린더, 메모, 데이터베이스를 보게 하려면 도구마다 연결을 따로 만들어야 했습니다. 연결 방식이 도구마다 다르니 도구가 열 개면 연결도 열 개이고, 쓰는 AI 앱을 바꾸면 그 열 개를 다시 만들어야 합니다. MCP 공식 문서는 이 부담을 줄이는 것을 장점으로 꼽습니다. 개발자에게는 AI 앱을 만들거나 연동하는 시간과 복잡도를 줄여 주고, AI 앱에는 여러 데이터 소스와 도구를 쓸 수 있는 생태계를 열어 주며, 사용자에게는 필요할 때 사용자의 자료에 접근하고 대신 작업까지 하는 더 유능한 앱을 제공한다는 설명입니다.
공식 소개 문서가 예로 드는 활용은 다음과 같습니다.
- AI 비서가 구글 캘린더와 노션에 접근해 더 개인화된 도움을 줍니다.
- Claude Code가 Figma 디자인을 보고 웹 앱을 만듭니다.
- 회사 챗봇이 여러 데이터베이스에 연결되어, 사용자가 대화로 데이터를 분석합니다.
세 가지 역할: 호스트, 클라이언트, 서버
공식 아키텍처 문서는 MCP를 클라이언트-서버 구조로 설명하고 참여자를 셋으로 나눕니다. 이름이 비슷해서 헷갈리기 쉬운 부분이라 표로 정리했습니다.
| 역할 | 공식 문서의 정의 | 일반 사용자 눈에 보이는 모습 |
|---|---|---|
| MCP 호스트 | 하나 이상의 MCP 클라이언트를 조율하고 관리하는 AI 애플리케이션 | Claude Desktop, Claude Code, Visual Studio Code처럼 내가 직접 여는 앱 |
| MCP 클라이언트 | MCP 서버와 연결을 유지하며 호스트가 쓸 맥락을 받아 오는 구성 요소 | 보이지 않음. 서버 하나마다 클라이언트가 하나씩 만들어집니다 |
| MCP 서버 | MCP 클라이언트에 맥락(데이터·도구)을 제공하는 프로그램 | "파일 시스템 연결", "캘린더 연결"처럼 설정 화면에 추가하는 항목 |
공식 문서의 예시에서 Visual Studio Code는 호스트입니다. Sentry 서버에 연결하면 클라이언트가 하나 만들어지고, 로컬 파일 시스템 서버에 연결하면 또 하나가 만들어집니다. 사용자가 하는 일은 서버를 추가하는 것뿐이고 나머지는 앱 안에서 일어납니다.
여기서 "서버"라는 말이 꼭 멀리 있는 컴퓨터를 뜻하지는 않습니다. 공식 문서는 서버가 어디서 실행되는지와 무관하게 맥락을 제공하는 프로그램을 서버라고 부른다고 밝힙니다. 내 컴퓨터에서 돌아가면 "로컬 서버", 인터넷 너머 회사 서버에서 돌아가면 "원격 서버"입니다.
서버가 내놓는 것 세 가지: 도구, 자료, 프롬프트
같은 문서는 서버가 AI 앱에 내놓을 수 있는 기본 요소를 세 가지로 정리합니다.
| 요소 | 하는 일 | 공식 문서의 예 | 위험도를 가늠하는 기준 |
|---|---|---|---|
| 도구(Tools) | AI 앱이 호출해 실제 동작을 일으키는 함수 | 파일 작업, API 호출, 데이터베이스 질의 | 쓰기·삭제·전송이 가능한지 여부 |
| 자료(Resources) | 맥락이 되는 데이터를 제공 | 파일 내용, 데이터베이스 기록, API 응답 | 어떤 자료가 AI에게 보이는지 여부 |
| 프롬프트(Prompts) | 언어 모델과 상호작용을 구조화하는 재사용 템플릿 | 시스템 프롬프트, 몇 가지 예시 묶음 | 보통 직접적인 동작은 없음 |
마지막 열은 공식 문서에 있는 내용이 아니라 이 글에서 독자가 판단하기 쉽도록 덧붙인 기준입니다. 같은 서버라도 도구가 읽기만 하는지, 쓰기까지 하는지에 따라 위험의 크기가 달라집니다. 도구 문서는 AI 모델이 상황에 따라 도구를 스스로 찾아 호출하도록 설계되어 있다고 설명합니다. 그래서 "어떤 도구가 노출되어 있는가"는 곧 "AI가 내 허락 없이 시도할 수 있는 행동의 목록"과 가깝습니다.
내 컴퓨터에서 도는 서버와 인터넷 너머 서버의 차이
MCP 명세는 메시지를 실어 나르는 방식(전송 방식)으로 두 가지를 표준으로 둡니다. 아키텍처 문서의 설명을 사용자 관점으로 옮기면 다음과 같습니다.
| 구분 | stdio (로컬 서버) | Streamable HTTP (원격 서버) |
|---|---|---|
| 어디서 실행되나 | 내 컴퓨터에서 앱이 실행하는 프로그램 | 서비스 회사의 서버 |
| 누구와 연결되나 | 대체로 클라이언트 하나 | 대체로 여러 클라이언트 |
| 인증 | 해당 없음(같은 컴퓨터 안의 통신) | 토큰·API 키 등 HTTP 인증, 공식 문서는 OAuth를 권장 |
| 사용자가 먼저 볼 것 | 이 프로그램이 내 컴퓨터에서 무엇을 실행하는가 | 내 계정의 어떤 권한을 빌려 주는가 |
같은 규격이어도 확인할 질문이 달라진다는 점이 중요합니다. 로컬 서버는 "내 컴퓨터에서 도는 프로그램"이라 파일과 명령 실행 범위가 관건이고, 원격 서버는 "내 계정을 대신 쓰는 주체"라 로그인 권한 범위가 관건입니다.
연결하기 전에 확인할 세 가지
공식 보안 문서는 로컬 MCP 서버의 위험을 직접 다룹니다. 악의적인 시작 명령이 설정에 들어 있거나, 서버 자체에 악성 코드가 들어 있거나, 켜 둔 로컬 서버가 외부에서 접근될 수 있다는 점을 위험으로 듭니다. 문서는 이런 서버가 클라이언트와 같은 권한으로 실행되며 임의 코드 실행, 데이터 유출, 복구 불가능한 데이터 손실로 이어질 수 있다고 설명합니다. 이를 바탕으로 사용자가 연결 전에 할 수 있는 확인을 세 가지로 정리했습니다.
- 무엇이 실행되는가. 출처가 서비스 회사의 공식 안내인지, 누가 올린 설정을 복사한 것인지 구분하고, 앱이 보여 주는 실행 명령을 읽습니다. 공식 문서도 한 번의 클릭으로 로컬 서버를 설정하는 클라이언트는 실행할 명령을 줄이지 않고 그대로 보여 주고 사용자 동의를 받아야 한다고 요구합니다. 낯선 주소로 보내는 동작이나 파일 삭제 명령이 섞여 있다면 멈춥니다.
- 무엇까지 할 수 있는가. 읽기만 되는지, 쓰기·삭제·전송도 되는지 확인하고, 범위는 좁게 줍니다. 홈 폴더 전체보다 작업 폴더 하나, 모든 권한보다 필요한 권한만 주고 처음에는 읽기만 되는 연결로 시작합니다. 보안 문서도 낮은 권한으로 시작해 필요할 때 단계적으로 올리는 방식을 권합니다.
- 끌 수 있고 기록이 남는가. 쓰지 않을 때 연결을 끌 수 있어야 하고, 무엇을 했는지 나중에 확인할 수 있어야 합니다. 항상 켜져 있는 연결은 잊어버리기 쉽습니다.
도구를 호출할 때 사람이 개입하는 지점
도구 명세에는 사용자 안전에 관한 권고가 있습니다. 신뢰와 안전을 위해 AI가 도구를 호출할 때 "사용자가 거부할 수 있는 사람의 개입이 항상 있어야 한다(SHOULD)"고 적혀 있고, 앱은 어떤 도구가 AI에 노출되는지 분명히 보여 주고, 도구가 호출될 때 눈에 띄는 표시를 하며, 작업 전에 확인 창을 띄워야 한다고 권합니다. 같은 문서의 보안 항목은 클라이언트가 민감한 작업에서 사용자 확인을 받고, 도구를 호출하기 전에 입력값을 사용자에게 보여 주어 실수나 악의적인 정보 유출을 막으라고 권합니다.
이 권고가 "반드시 지켜진다"는 뜻은 아닙니다. 명세는 앱이 어떤 화면 방식을 쓸지 정하지 않으며, 지키는 정도는 앱마다 다릅니다. 그래서 사용자 입장에서 할 일은 단순합니다. 확인 창이 뜨면 무엇을 보내는지 읽고 승인하고, 매번 자동으로 승인하는 설정은 읽기 전용 도구에만 켭니다.
예시로 보는 권한 판단표
아래 표는 이 글에서 만든 판단 예시입니다. 실제 서비스의 제품명이 아니라 종류별로 가정한 연결이며, 공식 문서의 분류가 아니라는 점을 밝혀 둡니다. 각 칸의 판단은 위 세 가지 확인을 적용한 결과입니다.
| 가정한 연결 | 가능한 일 | 처음 줄 권한 | 승인 방식 |
|---|---|---|---|
| 메모 폴더 하나 읽기 | 메모 검색·요약 | 그 폴더, 읽기 전용 | 자동 승인 가능 |
| 캘린더 일정 보기 | 빈 시간 찾기 | 읽기 전용 | 자동 승인 가능 |
| 캘린더 일정 만들기 | 일정 추가·수정 | 쓰기 허용은 나중에 | 호출마다 확인 |
| 회사 데이터베이스 조회 | 숫자 집계·표 만들기 | 조회 전용 계정 | 호출마다 입력값 확인 |
| 파일 삭제·메일 발송이 가능한 연결 | 되돌리기 어려운 동작 | 필요가 확실할 때만 | 항상 확인, 자동 승인 금지 |
판단 기준은 하나입니다. 틀렸을 때 되돌릴 수 있는가. 읽기는 틀려도 되돌릴 일이 없지만, 보내기와 삭제는 되돌릴 수 없는 경우가 많습니다.
자주 하는 오해 네 가지
- "MCP를 붙이면 AI가 더 똑똑해진다." 모델 성능이 바뀌는 것이 아니라 접근할 수 있는 자료와 동작이 늘어나는 것입니다. 공식 문서도 MCP가 AI 앱이 모델을 쓰는 방식이나 맥락을 관리하는 방식까지 정하지는 않는다고 선을 긋습니다.
- "표준이니까 안전하다." 표준은 연결 모양을 통일할 뿐 서버 내용을 보증하지 않습니다. 앞서 본 보안 문서가 따로 존재하는 이유입니다.
- "서버는 인터넷 어딘가에 있다." 내 컴퓨터에서 도는 로컬 서버도 서버라고 부릅니다.
- "한 번 연결하면 끝이다." 서버가 제공하는 도구 목록은 바뀔 수 있고, 명세에는 목록 변경을 알리는 알림도 있습니다. 연결한 뒤에도 가끔 어떤 도구가 노출되는지 다시 봅니다.
명세가 계속 바뀌는 중이라는 점
이 글을 쓰며 확인한 현재 공식 문서는 명세 버전 2026-07-28을 기준으로 합니다. 이 버전의 아키텍처 문서에는 요청마다 프로토콜 버전과 기능 정보를 담는 무상태(stateless) 방식이 설명되어 있고, 서버가 모델 응답을 요청하는 샘플링 기능은 이 버전부터 사용 중단(deprecated)으로 표시되어 있습니다. 앞선 버전의 설명이나 블로그 글과 용어가 다를 수 있다는 뜻입니다. 일반 사용자가 이 세부 사항을 알아야 하는 것은 아니지만, 오래된 글을 따라 설정할 때 화면이나 용어가 다르면 최신 공식 문서를 먼저 확인하는 것이 좋습니다.
정리하면
MCP는 AI 앱과 바깥 시스템을 같은 방식으로 연결하게 해 주는 공통 약속입니다. 호스트·클라이언트·서버의 역할을 구분하고, 서버가 내놓는 도구·자료·프롬프트 중 어떤 것이 열려 있는지 확인하면 대부분의 판단이 가능합니다. 연결하기 전에는 실행되는 것, 할 수 있는 일의 범위, 끄기와 기록의 세 가지를 보고, 처음에는 읽기 전용으로 시작해 필요할 때만 권한을 넓히세요.
업데이트
이 글은 MCP 공식 문서의 소개, 아키텍처, 도구, 보안 모범 사례 페이지(2026년 10월 9일 기준)와 Anthropic의 MCP 발표문(2026년 10월 18일 기준)을 바탕으로 정리했습니다. 명세와 각 앱의 설정 화면은 바뀔 수 있으므로, 달라진 부분이 있으면 공식 문서가 우선합니다. 이 글의 판단표는 직접 만든 예시이며 실제로 특정 서비스에 연결해 시험한 결과가 아닙니다.
확인 자료
- MCP 공식 문서: What is the Model Context Protocol
- MCP 공식 문서: Architecture overview
- MCP 공식 문서: Tools
- MCP 공식 문서: Security Best Practices
- Anthropic 발표문: Introducing the Model Context Protocol (2024년 11월 25일)
기준일: MCP 공식 문서 2026-10-09, Anthropic 발표문 2026-10-18