🔌 MCP(Model Context Protocol) 입문: AI 에이전트 표준화가 바꾸는 것

 

AI 모델과 외부 데이터·도구를 잇는 표준 규격 MCP가 무엇이고, 왜 'AI 시대의 USB-C'로 불리는지 입문자 눈높이에서 정리했습니다.

Anthropic은 2024년 11월 25일 MCP(Model Context Protocol)를 공개했습니다. 1년이 조금 넘은 지금은 Claude뿐 아니라 ChatGPT, VS Code, Cursor 같은 주요 도구가 함께 지원하면서 사실상의 표준으로 자리 잡았습니다. AI 모델이 똑똑해질수록 "그래서 내 데이터와 사내 시스템에 어떻게 연결하지?"라는 질문이 더 커졌고, MCP는 바로 그 연결을 표준화하기 위해 등장했습니다.

이 글은 "MCP가 정확히 무엇이며 왜 필요한가", "내부 구조는 어떻게 생겼는가", "도구·리소스·프롬프트가 무엇인가"를 알고 싶은 분들을 위한 입문서입니다. 클라이언트-서버 구조와 실제 연결 흐름을 따라가며, 도입 전에 반드시 짚어야 할 한계와 보안 고려사항까지 함께 다룹니다. 코드를 몰라도 개념을 잡을 수 있도록 비유와 단계별 흐름을 중심으로 설명합니다.

배경

생성형 AI를 실무에 붙여 본 사람이라면 비슷한 벽에 부딪힙니다. 모델 자체는 뛰어난데, 정작 회사의 데이터베이스, 캘린더, 코드 저장소, 메신저처럼 일이 실제로 일어나는 곳과는 단절되어 있다는 점입니다. Anthropic은 발표문에서 "가장 정교한 모델조차 정보 사일로와 레거시 시스템 뒤에 갇혀 데이터로부터 고립되어 있다"고 표현했습니다. 사일로(silo)란 데이터가 서로 연결되지 못하고 각각 고립된 창고처럼 갇혀 있는 상태를 말합니다.

문제는 연결 방식이 제각각이라는 데 있습니다. 모델 종류가 M개, 연결할 데이터 소스가 N개일 때, 표준이 없으면 M 곱하기 N개의 맞춤형 연결을 일일이 만들고 유지해야 합니다. 새 데이터 소스가 생길 때마다 전용 통합 코드를 또 짜야 하니 확장이 어렵습니다. MCP는 이 난립하는 개별 연결을 하나의 공통 규격으로 대체하자는 아이디어에서 출발했습니다.

공식 문서는 MCP를 "AI 애플리케이션을 위한 USB-C 포트"에 비유합니다. USB-C가 충전기, 모니터, 외장 디스크를 하나의 규격으로 꽂게 해 주듯, MCP는 AI 애플리케이션을 외부 시스템에 연결하는 표준화된 방법을 제공합니다. 한 번 만들어 두면 여러 곳에 그대로 연결되는, "한 번 만들어 어디서나 통합"이 핵심 약속입니다.

핵심

MCP는 AI 애플리케이션을 외부 데이터·도구·워크플로에 연결하기 위한 오픈 표준으로, JSON-RPC 2.0 메시지를 주고받는 클라이언트-서버 규격입니다.

MCP는 흔히 LSP(Language Server Protocol)에서 영감을 받았다고 설명됩니다. LSP가 프로그래밍 언어 지원을 모든 개발 도구에 표준화된 방식으로 추가하는 규격이라면, MCP는 추가 맥락과 도구를 AI 애플리케이션에 통합하는 방식을 표준화합니다. 둘 다 'N×M 난립'을 하나의 프로토콜로 정리한다는 점에서 닮았습니다.

세 명의 참여자: 호스트, 클라이언트, 서버

MCP 구조에는 세 주체가 등장합니다. 호스트(Host)는 Claude Desktop이나 VS Code처럼 LLM을 품고 있는 AI 애플리케이션입니다. 클라이언트(Client)는 호스트 안에서 하나의 서버와 1:1 전용 연결을 유지하는 부품입니다. 서버(Server)는 데이터나 기능을 제공하는 프로그램입니다.

핵심은 연결이 1:1이라는 점입니다. 호스트가 여러 서버에 붙으려면 서버마다 클라이언트를 하나씩 만듭니다. 예를 들어 VS Code(호스트)가 파일시스템 서버와 Sentry 서버에 동시에 연결하면, 각각을 담당하는 클라이언트 객체가 별도로 생성됩니다. 서버는 내 컴퓨터에서 도는 '로컬 서버'일 수도, Sentry 플랫폼처럼 원격에서 도는 '원격 서버'일 수도 있습니다.

두 개의 층: 데이터 레이어와 트랜스포트 레이어

MCP는 두 층으로 나뉩니다. 안쪽의 데이터 레이어(Data layer)는 JSON-RPC 2.0 기반 프로토콜로, 연결 수명 관리와 도구·리소스·프롬프트 같은 핵심 기능의 의미를 정의합니다. JSON-RPC 2.0은 "이 함수를 이 인자로 호출해 줘"라는 요청과 응답을 JSON 형식으로 주고받는 표준 규약입니다.

바깥쪽의 트랜스포트 레이어(Transport layer)는 그 메시지를 실제로 어떤 통로로 전달할지 담당합니다. 통로는 두 가지입니다. stdio 트랜스포트는 같은 컴퓨터 안 프로세스끼리 표준 입출력으로 주고받아 네트워크 부담이 없고, Streamable HTTP 트랜스포트는 HTTP POST(필요 시 Server-Sent Events)로 원격 서버와 통신하며 베어러 토큰이나 OAuth 같은 표준 인증을 지원합니다.

서버가 제공하는 세 가지 핵심 기능

MCP에서 가장 중요한 개념은 '프리미티브(primitive, 기본 구성요소)'입니다. 서버가 노출하는 핵심 프리미티브는 세 가지입니다. 도구(Tools)는 모델이 실행할 수 있는 함수로, 파일 조작·API 호출·DB 질의 같은 '행동'을 담당합니다. 리소스(Resources)는 파일 내용이나 DB 레코드처럼 맥락을 제공하는 '데이터'입니다. 프롬프트(Prompts)는 시스템 프롬프트나 예시처럼 상호작용을 구조화하는 '재사용 템플릿'입니다.

반대로 클라이언트도 서버에 기능을 제공할 수 있습니다. 샘플링(Sampling)은 서버가 클라이언트의 LLM에 추론을 요청하는 기능이라, 서버가 자체 모델 SDK 없이도 모델을 빌려 쓸 수 있게 합니다. 일리시테이션(Elicitation)은 서버가 사용자에게 추가 정보나 확인을 요청하는 기능입니다.

실제 연결 흐름

흐름은 한 줄로 요약됩니다. 먼저 클라이언트가 initialize 요청을 보내 프로토콜 버전과 서로 지원하는 기능을 협상합니다(수명 관리). 협상이 끝나면 클라이언트가 tools/list로 사용 가능한 도구 목록을 발견하고, 모델이 필요할 때 tools/call로 특정 도구를 인자와 함께 실행해 결과를 받습니다. 도구 목록이 바뀌면 서버가 notifications/tools/list_changed 알림을 보내 클라이언트가 목록을 갱신하게 합니다. 발견(*/list) → 실행(tools/call) → 알림으로 이어지는 이 패턴 덕분에, 사용 가능한 기능이 실시간으로 늘거나 줄어도 모델이 즉시 따라잡을 수 있습니다.

장점과 한계

장점

통합 비용을 한 번으로 줄인다. MCP의 가장 큰 가치는 'N×M' 난립을 'N+M'으로 바꾸는 데 있습니다. 데이터 소스를 MCP 서버로 한 번 노출하면, 그 규격을 지원하는 모든 호스트가 추가 연결 코드 없이 곧바로 붙을 수 있습니다.

폭넓은 생태계와 즉시 쓰는 서버. Google Drive, Slack, GitHub, Git, Postgres 등 인기 시스템용 참조 서버가 이미 제공됩니다. Claude, ChatGPT, VS Code, Cursor 등 주요 클라이언트가 같은 규격을 지원하므로 "한 번 만들어 어디서나 통합"이 현실이 됩니다.

도구를 실시간으로 발견하고 갱신한다. 클라이언트는 */list로 기능을 동적으로 발견하고, 알림으로 변경을 즉시 반영합니다. 폴링(주기적으로 확인하기) 없이도 모델의 가용 기능이 항상 최신으로 유지됩니다.

모델에 종속되지 않는 설계. 샘플링 같은 클라이언트 프리미티브 덕분에 서버 제작자는 자체 LLM SDK를 넣지 않고도 호스트의 모델을 빌려 쓸 수 있어, 특정 모델에 묶이지 않는 통합을 만들 수 있습니다.

한계와 주의점

프로토콜 자체가 보안을 강제하지 않는다. 공식 명세는 MCP가 프로토콜 수준에서 보안 원칙을 강제할 수 없다고 명시합니다. 사용자 동의 흐름, 접근 통제, 데이터 보호는 모두 구현자의 책임으로 남습니다. 규격을 따랐다고 해서 안전이 보장되지는 않습니다.

도구는 곧 임의 코드 실행이다. 도구는 본질적으로 임의 코드 실행 경로이며, 명세는 신뢰할 수 있는 서버에서 얻은 것이 아니라면 도구 설명조차 신뢰하지 말라고 경고합니다. 호스트는 도구를 호출하기 전 반드시 사용자의 명시적 동의를 받아야 합니다.

공급망과 단일 장애점 위험. 설치가 쉽다는 장점은 곧 신뢰할 수 없는 서버를 무심코 연결할 위험이기도 합니다. 특히 원격 서버는 여러 서비스의 OAuth 토큰을 한곳에 보관하기 쉬워, 한 번 탈취되면 연결된 모든 서비스로 피해가 번지는 단일 장애점이 될 수 있습니다.

상태를 유지하는 프로토콜. MCP는 수명 관리와 기능 협상이 필요한 상태 유지(stateful) 프로토콜입니다. 연결 초기화, 버전 협상, 알림 처리 같은 흐름을 제대로 다루지 못하면 호환성 문제가 생기므로, 입문 단계에서는 SDK가 추상화해 주는 부분과 직접 신경 써야 할 부분을 구분하는 것이 좋습니다.

적용 방법

입문자가 처음부터 깊이 구현할 필요는 없습니다. MCP는 여러 언어용 공식 SDK가 세부 사항을 대부분 가려 주므로, 처음에는 '서버 붙이기'부터 체험하는 편이 빠릅니다.

가장 간단한 출발점은 공식 참조 서버를 클라이언트에 연결해 보는 것입니다. 동작 점검에는 MCP Inspector라는 공식 개발 도구를 쓰면 서버가 어떤 도구·리소스·프롬프트를 노출하는지 눈으로 확인할 수 있습니다.

npx @modelcontextprotocol/inspector

연결과 발견·실행 흐름이 손에 익으면, 그다음 단계로 자신만의 서버를 만들 수 있습니다. 이때는 자신이 쓰는 언어의 공식 SDK 문서를 따르는 것이 정석이며, 직접 JSON-RPC 메시지를 손으로 조립할 필요는 거의 없습니다. 처음부터 사내 핵심 데이터에 붙이기보다, 읽기 전용 리소스나 안전한 더미 도구로 흐름을 검증한 뒤 권한 범위를 넓혀 가는 순서를 권합니다.

실전 시나리오

MCP가 빛나는 지점은 "AI가 데이터를 보는 것"을 넘어 "AI가 행동하는 것"입니다. 공식 문서가 든 예시들이 직관적입니다. 에이전트가 Google 캘린더와 Notion에 접근해 더 개인화된 비서가 되거나, Claude Code가 Figma 디자인을 받아 웹 앱을 만들어 내거나, 사내 챗봇이 여러 데이터베이스에 연결되어 직원이 채팅만으로 데이터를 분석하는 식입니다.

실무에 옮긴다면 조합은 대개 이렇게 짜입니다. 데이터 조회용으로는 Postgres나 Google Drive 서버를 리소스로 붙여 맥락을 공급하고, 실제 작업용으로는 GitHub·Slack 서버를 도구로 붙여 이슈 생성이나 메시지 전송 같은 행동을 맡깁니다. 여기에 자주 쓰는 업무 흐름을 프롬프트 템플릿으로 표준화해 두면, 모델이 매번 처음부터 지시를 받지 않아도 일관되게 일합니다.

이런 사람에게 추천

AI를 단순 챗봇이 아니라 실제 업무 시스템과 연결해 일하는 에이전트로 키우고 싶은 개발자라면 MCP는 사실상 출발점입니다. 여러 모델·도구를 동시에 다루며 통합 코드를 반복해서 짜는 데 지친 팀, 사내 데이터와 AI를 연결하되 특정 벤더에 종속되고 싶지 않은 조직에도 잘 맞습니다.

반대로 단발성 질의응답이나 간단한 텍스트 생성만 필요하다면, 굳이 MCP를 도입할 이유는 크지 않습니다. 다만 "지금은 아니어도 곧 외부 시스템과 연동할 것 같다"면, 개념만이라도 미리 익혀 두는 편이 나중에 시간을 아껴 줍니다.

도입 전 체크포인트

가장 먼저 점검할 것은 신뢰입니다. 연결하려는 서버가 신뢰할 수 있는 출처인지, 누가 만들고 유지하는지 확인하세요. 명세가 경고하듯 도구 설명조차 신뢰할 수 없는 서버에서 온 것이라면 의심해야 합니다.

다음은 동의와 통제입니다. 명세의 첫 번째 원칙은 사용자의 명시적 동의입니다. 도구 호출 전 사용자 확인, 데이터를 서버에 노출하기 전 동의, 샘플링 승인 같은 사람 개입(human-in-the-loop) 장치가 호스트에 마련되어 있는지 확인하세요. 인증 면에서는 원격 서버 연결 시 OAuth 사용이 권장됩니다. 2025년 6월 18일 명세 업데이트(2025-06-18)는 MCP 서버를 OAuth 리소스 서버로 분류하고, RFC 8707 리소스 인디케이터로 토큰을 의도한 서버에만 묶도록 요구했습니다. 마지막으로 권한은 최소로 시작하세요. 읽기 전용부터 붙이고, 토큰 범위를 좁게 유지하며, 토큰이 한곳에 몰려 단일 장애점이 되지 않는지 점검하는 것이 안전한 도입의 기본입니다.

마치며

MCP는 화려한 신기술이라기보다, AI를 실무에 붙일 때 누구나 부딪히던 '연결의 난립' 문제를 표준으로 정리한 실용적 합의에 가깝습니다. 2024년 11월 등장 이후 명세는 2025년 11월 25일자(2025-11-25) 안정 버전까지 발전했고, 주요 AI 클라이언트가 함께 지원하면서 'AI 시대의 USB-C'라는 별명이 빈말이 아니게 되었습니다.

핵심만 다시 정리하면, MCP는 호스트-클라이언트-서버 구조 위에서 JSON-RPC로 도구·리소스·프롬프트를 주고받는 규격이며, 발견-실행-알림의 흐름으로 움직입니다. 다만 프로토콜이 보안을 대신 책임지지 않는다는 점을 잊지 말고, 신뢰·동의·최소 권한이라는 원칙을 손에 쥐고 작게 시작하길 권합니다.

참고자료

• What is the Model Context Protocol (MCP)?: MCP의 정의, 'AI용 USB-C' 비유, 지원 클라이언트 생태계를 설명하는 공식 입문 문서
• Architecture overview: 호스트-클라이언트-서버 구조, 데이터·트랜스포트 레이어, JSON-RPC 흐름과 프리미티브를 다루는 공식 아키텍처 문서
• Specification (latest): 최신 명세(2025-11-25), 기능 정의, 보안·신뢰 원칙(동의·도구 안전·샘플링 통제)을 규정한 공식 명세
• Introducing the Model Context Protocol — Anthropic: 2024년 11월 25일 MCP 발표 배경, 통합 난립 문제, 초기 SDK·참조 서버를 담은 공식 발표
• Auth0 — MCP Spec Updates from June 2025: 2025-06-18 명세의 OAuth 리소스 서버 분류와 RFC 8707 리소스 인디케이터를 정리한 보안 분석