MCP 서버란 무엇인가? 2026년 MCP와 MCP UI의 작동 방식

2025년 4월 1일, Invariant Labs는 add라는 도구를 공개했습니다. 두 숫자를 받아 합을 돌려주는 도구였습니다. 그런데 설명에는 IMPORTANT라고 표시된 블록이 들어 있었습니다. 클라이언트 화면에는 보이지 않는 이 블록은 모델에게 ~/.cursor/mcp.json과 ~/.ssh/id_rsa를 읽어 남는 매개변수를 통해 두 파일을 밖으로 보내라고 지시했습니다. 모델은 따랐습니다. 사용자가 본 것은 덧셈뿐이었습니다.

제가 아는 한 이 시연은 MCP 서버를 이해하는 가장 좋은 입문입니다. 두 측면을 한 번에 보여 주기 때문입니다. 프로토콜은 설계대로 정확히 작동했습니다. AI 클라이언트가 도구를 발견하고, 설명을 읽고, 호출했습니다. 아직 아무도 만들지 않은 것은 신뢰 모델이었습니다.

MCP 서버란 무엇인가

MCP 서버는 Model Context Protocol(MCP)을 통해 AI 애플리케이션에 도구, 데이터, 프롬프트를 제공하는 프로그램입니다. 공식 문서는 MCP를 “AI 애플리케이션을 외부 시스템에 연결하기 위한 오픈 소스 표준”으로 정의합니다. Claude, ChatGPT, Visual Studio Code, Cursor 같은 AI 클라이언트가 서버에 연결해 무엇을 제공하는지 묻고, 사용자를 대신해 그 기능을 호출합니다.

Anthropic은 2024년 11월 25일 MCP를 발표하면서 Google Drive, Slack, GitHub, Git, Postgres, Puppeteer용 사전 구축 서버 6개를 함께 내놓았습니다. OpenAI는 2025년 3월에 MCP를 채택했고, Google DeepMind가 4월에 뒤따랐습니다. 2025년 12월 Anthropic은 프로토콜을 Agentic AI Foundation에 기부했습니다. Agentic AI Foundation은 Linux Foundation 산하의 지정 기금으로, Anthropic, Block, OpenAI가 공동 설립했습니다.

문제는 연결 수가 곱으로 늘어나는 것입니다. MCP 이전에는 GitHub에 접근하려는 AI 앱마다 자체 커넥터를 만들고, 공급업체도 각 AI 앱에 맞는 연결을 만들어야 했습니다. 모델 열 개와 도구 열 개라면 통합이 최대 백 개 필요할 수 있었습니다. MCP는 클라이언트마다 프로토콜을 한 번 구현하고 시스템마다 서버 하나를 제공해 이를 스무 개로 줄입니다.

MCP를 AI 통합의 선적 컨테이너라고 생각해 보세요. 컨테이너가 나오기 전에는 항구마다 모든 화물을 손으로 실었고, 항구마다 크레인과 인부가 따로 있었습니다. 컨테이너가 상자를 표준화하자 어떤 배, 크레인, 트럭이든 어떤 화물이든 옮길 수 있게 되었습니다. 하지만 컨테이너는 상자 안에 무엇이 들어가는지는 표준화하지 않았고, 내용물을 검사한 적도 없습니다. MCP도 같은 거래입니다. 이 뒷부분을 기억해 두세요. 보안 섹션에서 다시 나옵니다.

MCP 서버의 작동 방식

버전 2026-07-28인 현재 사양은 세 가지 역할 사이에서 JSON-RPC 2.0 메시지를 주고받습니다. 사양 자체의 설명은 세 줄입니다. 호스트는 “연결을 시작하는 LLM 애플리케이션”, 클라이언트는 “호스트 애플리케이션 안의 커넥터”, 서버는 “컨텍스트와 기능을 제공하는 서비스”입니다.

호스트, 클라이언트, 서버

호스트는 사용자가 직접 입력하는 애플리케이션입니다. Claude Desktop, IDE, 직접 만든 에이전트가 여기에 해당합니다. 그 안에서 서버 연결마다 클라이언트가 하나씩 실행됩니다. 서버는 반대편에서 실제 시스템과 통신합니다. 그 시스템은 Postgres 데이터베이스일 수도, GitHub API일 수도, 디스크의 폴더일 수도 있습니다. 모델이 무엇을 보고 사용자가 무엇을 승인해야 하는지는 호스트가 정합니다. 기반 시스템이 무엇을 할지는 서버가 정합니다.

1. 호스트 Claude Desktop · IDE · 직접 만든 에이전트

   모델에 도구를 보여 주고 사용자에게 동의를 구함

2. 클라이언트 서버 연결마다 하나

   stdio 또는 Streamable HTTP로 JSON-RPC 통신

3. MCP 서버 도구 · 리소스 · 프롬프트

   제공 항목을 설명하고 호출을 실행함

4. 기반 시스템 데이터베이스 · SaaS API · 로컬 파일

   실제 작업을 수행함

도구, 리소스, 프롬프트

서버는 세 종류를 제공할 수 있습니다.

• 도구는 모델이 실행할 수 있는 함수입니다. create_issue, query_orders, send_email 같은 것입니다. 도구마다 이름, 설명, 입력용 JSON Schema가 있습니다.
• 리소스는 사용자나 모델이 읽는 컨텍스트와 데이터입니다. 파일, 데이터베이스 스키마, 레코드 같은 것입니다.
• 프롬프트는 사용자가 고를 수 있는 템플릿 메시지와 워크플로입니다. 예를 들면 “이 풀 리퀘스트를 요약해 줘” 같은 것입니다.

관심은 대부분 도구에 쏠립니다. 도구는 실제로 행동하기 때문입니다. 위험의 대부분을 도구가 안고 있는 이유도 같습니다.

도구 호출의 단계

2026-07-28 개정판에서 MCP는 무상태(stateless)가 되었습니다. 이제 initialize 핸드셰이크는 없습니다. 모든 요청이 _meta 필드에 프로토콜 버전과 클라이언트 기능을 담아 보내고, 서버는 server/discover 메서드를 반드시 구현해야 합니다. 그래서 클라이언트는 서버가 무엇을 지원하는지 먼저 물어볼 수 있습니다. 이제 도구 호출 한 번은 다음과 같이 진행됩니다.

1. 사용자 요청: 이 버그로 티켓을 만들어 줘

2. 1단계

   탐색

   • 클라이언트는 server/discover로 버전과 기능을 확인할 수 있음
3. 2단계

   도구 목록

   • tools/list가 이름, 설명, 입력 스키마를 반환함
4. 3단계

   모델의 도구 선택

   • 호스트가 도구 정의를 모델에 전달함
5. 4단계

   사용자 동의

   • 사양상 호스트는 도구를 호출하기 전에 명시적 동의를 받아야 함
6. 5단계

   호출

   • 인수와 함께 tools/call, 프로토콜 버전은 _meta에 담음

7. 입력이 부족하면 서버가 input_required를 반환하고, 클라이언트가 답을 채워 다시 시도함

   6단계

   결과

8. 결과는 컨텍스트로 모델에 돌아감

6단계는 이번 개정판에서 새로 생겼습니다. 정보가 더 필요한 서버는 이제 클라이언트에 자체 요청을 되돌려 보내지 않습니다. input_required로 표시한 결과를 반환하면, 클라이언트가 답을 모으고 원래 호출을 다시 시도합니다. 사양은 이를 Multi Round-Trip Request 패턴이라고 부릅니다.

전송 방식: stdio와 Streamable HTTP

사양은 두 가지 표준 전송 방식을 정의합니다.

• stdio: 클라이언트가 서버를 하위 프로세스로 실행하고, 표준 입력과 표준 출력으로 줄바꿈으로 구분한 JSON-RPC를 주고받습니다. 대부분의 로컬 서버가 이 방식으로 실행됩니다. 즉, 서버가 사용자의 컴퓨터에서 사용자의 권한으로 실행된다는 뜻입니다.
• Streamable HTTP: 메시지마다 단일 엔드포인트로 HTTP POST를 보내고, 응답은 JSON 객체나 요청 범위의 이벤트 스트림으로 돌아옵니다. 원격 호스팅 서버가 이 방식으로 실행됩니다.

예전의 HTTP+SSE 전송 방식은 공식적으로 지원 중단되었습니다. 2026-07-28 개정판은 프로토콜 수준의 세션과 Mcp-Session-Id 헤더도 없앴습니다. 여러 호출에 걸쳐 상태가 필요한 서버는 이제 자체 핸들을 발급하고, 그 핸들을 일반 도구 인수로 돌려받습니다.

인가

MCP의 인가는 선택 사항이며 HTTP에만 적용됩니다. stdio에서는 서버가 자격 증명을 환경에서 가져와야 한다고 사양은 말합니다. HTTP에서 보호된 MCP 서버는 OAuth 2.1 리소스 서버로 동작합니다. 클라이언트가 인가 서버를 찾을 수 있도록 OAuth Protected Resource Metadata(RFC 9728)를 공개해야 합니다. 클라이언트는 토큰이 어느 서버용인지 정확히 지정해야 합니다(RFC 8707 리소스 지시자). 서버는 자신을 위해 발급되지 않은 토큰을 모두 거부해야 합니다. 보안 지침은 클라이언트의 토큰을 수정 없이 하위 API로 넘기는 “토큰 패스스루”를 명시적으로 금지합니다.

이 마지막 규칙은 보기보다 중요합니다. 받은 토큰을 무엇이든 중계하는 서버는 토큰을 가진 누구에게나 프록시가 됩니다.

MCP UI가 더하는 것: 인터페이스를 반환하는 서버

사용자가 40개 행을 비교하거나, 필드 12개짜리 양식을 조정하거나, 변경 묶음을 하나씩 승인해야 하는 순간 텍스트 답변은 쓸모가 없어집니다. “MCP UI”는 사람들이 그 해법을 찾을 때 검색하는 이름입니다. 서버가 인터랙티브 인터페이스를 반환하고, 그 인터페이스가 AI 클라이언트 안에서 대화 바로 옆에 렌더링됩니다.

진행 상황을 정확히 설명하겠습니다. 시작은 커뮤니티 프로젝트 MCP-UI였습니다. OpenAI는 Apps SDK에 비슷한 기능을 구축했습니다. MCP 프로젝트는 2025년 11월 21일 양측과 공동 표준을 제안하고, 2026년 1월 26일 첫 공식 MCP 확장인 MCP Apps를 발표했습니다. MCP-UI 패키지는 이제 이 명세를 구현하며 향후 개선을 위한 커뮤니티 실험 공간으로 남아 있습니다.

그러니 오늘날 MCP UI는 곧 MCP Apps입니다. 공식이고, 핵심 프로토콜이 아니라 확장입니다. 확장은 옵트인이어서 클라이언트와 서버가 모두 지원해야 하며, 문서도 “호스트 지원은 클라이언트마다 다르다”고 분명히 말합니다. MCP Apps 문서는 지원 호스트로 Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam, Archestra.AI를 꼽습니다. 도구가 UI를 반환하는 서버라도 텍스트만 보여 주는 클라이언트에서 작동해야 합니다.

구조적으로는 MCP 자체의 구성 요소를 재사용합니다.

1. 도구 설명에 ui:// 리소스를 가리키는 _meta.ui.resourceUri가 들어갑니다.
2. 호스트는 스크립트가 포함된 HTML 페이지인 그 리소스를 가져오며, 도구가 호출되기 전에 미리 불러올 수도 있습니다.
3. 호스트는 그것을 샌드박스 iframe에 렌더링합니다. 이 iframe은 상위 페이지, 그 페이지의 쿠키, 저장소를 읽을 수 없습니다.
4. 앱과 호스트는 MCP의 JSON-RPC 방언으로 postMessage를 통해 통신합니다. 앱은 도구 호출을 요청할 수 있고, 어떤 호출을 허용할지는 호스트가 정합니다.

비용은 실제로 듭니다. 이제 다른 회사의 애플리케이션 안에 웹 프런트엔드를 배포하는 셈이고, 직접 선언해야 하는 콘텐츠 보안 정책, 통제할 수 없는 렌더링 규칙, UI를 무시하는 모든 호스트를 위한 텍스트 대체 화면이 따라옵니다. 얻는 것은 승인 작업이 더는 채팅 기록이 아니게 된다는 점입니다. 문서가 직접 꼽은 적합한 용도 목록은 “경비 보고서 승인, 코드 변경 검토, 이슈 분류”로 끝나는데, 이것이 핵심을 정직하게 보여 줍니다. MCP UI가 가장 잘하는 일은 의사 결정이지 장식이 아닙니다.

읽기 전용 Tajo 사례

Tajo의 Alto MCP에는 연결된 작업 공간에 저장된 연락처를 검색하는 query_contacts가 있습니다. 기존 연락처 하나를 이메일로 찾아 반환된 ID, 이메일 동의 상태, 마지막 확인 시간을 살펴보세요. 별도 도구 get_contact_topic_status는 해당 연락처의 주제별 구독을 읽습니다.

이는 작업 공간 읽기입니다. 공급업체에서 최신 스냅샷을 가져오거나 동기화를 시작하거나 메시지를 보내지 않습니다. 모든 공급업체 커넥터가 운영 중임을 입증하지도 않습니다. 누락되거나 오래된 데이터는 원본에서 조사하세요. 빈 결과는 그 사람이 Brevo에 없다는 증거가 아닙니다.

Tajo MCP 문서에서 지원되는 클라이언트를 연결하고 권한이 있는 작업 공간에 실제로 노출된 도구를 확인하세요. 호스트가 MCP Apps를 지원한다면 대화형 패널이 검토에 도움을 줄 수 있지만 텍스트 결과도 결과를 설명해야 합니다.

도구 호출은 지속적인 동기화가 아닙니다

정기 동기화에는 일정, 안정적인 레코드 식별자, 저장된 진행 상황, 재시도 판단, 완료된 쓰기의 기록도 필요합니다. 이는 작업을 실행하는 애플리케이션의 책임입니다. MCP는 도구 접근을 표준화할 뿐, 도구를 나열한다고 업무 규칙이 생기지 않습니다.

시간 초과 후 읽기는 보통 다시 시도할 수 있습니다. 전송이나 결제는 이미 일어났을 수 있습니다. 다시 시도하기 전에 실행 기록을 보존하고 결과를 대조하세요. 모델의 확신도는 행동을 허가하거나 재시도를 안전하게 만들지 않습니다.

구체적인 연락처의 대상 쓰기는 Brevo API 가이드를, 계산된 필드에 별도의 관리되는 동기화가 필요한 시점은 reverse ETL을 참고하세요.

보안 비용은 프로토콜과 함께 온다

반론은 온전히 소개할 가치가 있습니다. “MCP는 데이터를 삭제하고 이메일을 보낼 수 있는 함수 목록을 확률적 모델에 넘기고, 그 함수의 설명은 낯선 사람이 쓴 텍스트를 그대로 믿습니다. 이것은 통합 표준이 아닙니다. 사양서가 붙은 공급망 공격입니다.” 대부분 맞는 말입니다. 사양도 그 전제에 동의합니다. 보안 섹션은 도구가 “임의 코드 실행에 해당하므로 적절한 주의를 기울여 다뤄야 한다”고, 도구 설명은 “신뢰할 수 있는 서버에서 받은 것이 아니라면 신뢰할 수 없는 것으로 간주해야 한다”고, 그리고 MCP는 “이러한 보안 원칙을 프로토콜 수준에서 강제할 수 없다”고 말합니다.

지금까지의 기록은 이렇습니다.

• 도구 포이즈닝. 2025년 4월 Invariant Labs의 공개로, 앞에서 본 add 도구가 그 사례입니다. 같은 글은 사용자가 승인한 뒤 서버가 도구 설명을 바꾸는 러그 풀(rug pull)과, 악성 서버 하나가 신뢰받는 다른 서버를 대하는 모델의 행동을 바꿔 버리는 섀도잉(shadowing)도 설명했습니다.
• 로컬 서버 침해. 2025년 7월 JFrog는 mcp-remote 0.0.5부터 0.1.15 버전에 있던 CVE-2025-6514를 공개했습니다. 악성 서버가 사용자 컴퓨터에서 명령을 실행할 수 있는 취약점이었습니다. 같은 해 여름에는 CVE-2025-49596이 Anthropic의 자체 도구인 MCP Inspector를 덮쳤습니다. MCP Inspector는 기본적으로 인증 없이 배포되었습니다.
• 권한 범위 팽창. 공식 보안 모범 사례는 이 패턴을 직접 지적합니다. 서버가 모든 범위를 나열하고 클라이언트가 그 범위를 전부 요청한 탓에, 처음부터 files:*나 admin:* 권한을 받은 토큰입니다.
• 공식 기관의 우려. 2026년 5월 미국 국가안보국(NSA)은 MCP의 “빠른 확산이 보안 모델의 발전 속도를 앞질렀다”고 밝혔습니다.

반론이 틀린 곳은 결론입니다. 해법은 처음부터 모델을 시스템에 연결하지 않는 것이 아니었습니다. 팀들은 이미 원시 API 키를 프롬프트와 스크립트에 붙여 넣어 같은 일을 하고 있었고, 감사 기록은 전혀 없었습니다. 해법은 MCP 서버를 다른 특권 의존성과 똑같이 다루는 것입니다.

• MCP 밖에서도 같은 자격 증명을 맡길 수 있는 출처의 서버만 설치합니다.
• 오래 유지되는 키를 가진 로컬 바이너리보다 OAuth와 좁은 범위를 쓰는 원격 서버를 택합니다.
• 모든 쓰기 작업에 사람의 승인을 요구하고, 누가 무엇을 승인했는지 기록합니다.
• 서버 버전을 고정하고, 도구 설명이 바뀌면 다시 검토합니다.
• API 전체가 아니라 작업 단위의 도구를 노출합니다. 노출된 적 없는 삭제 엔드포인트는 모델도 오용할 수 없습니다.

프로토콜은 상자를 표준화했습니다. 화물 검사는 여전히 여러분의 몫입니다.

MCP 서버를 만들 것인가, 기존 서버를 쓸 것인가

mcp.so 같은 공개 디렉터리는 커뮤니티가 만든 서버를 모아 두고, 많은 SaaS 벤더가 자체 서버를 공개합니다. 예를 들어 Brevo는 MCP 서버를 제공하는데, 이 서버는 개별 서버로도 나뉘어 있어 에이전트에게 캠페인 없이 연락처만 줄 수 있습니다. 결정의 핵심은 수고보다 도구의 형태를 누가 정해야 하느냐입니다.

에이전트는 어떤 MCP 서버를 써야 할까요?

1. 벤더가 작업을 다루는 서버를 공개함

   벤더 서버를 사용

   API 변경을 따라가고 벤더가 유지 관리합니다.

2. 시스템은 하나지만 작업을 줄이거나 더 안전하게 해야 함

   범위를 좁혀서 사용

   권한 범위를 최소로 주고 에이전트에 필요한 도구 그룹만 노출합니다.

3. 내부 데이터이거나 서버가 없는 시스템

   작은 서버를 직접 구축

   자체 API 위에 자체 인증으로 작업 단위 도구 몇 개를 둡니다.

4. 작업이 둘 이상의 시스템에 걸침

   통제된 계층을 구축하거나 도입

   모든 시스템에 걸쳐 하나의 도구 세트, 동의 규칙, 감사 기록을 둡니다.

기본 서버를 만드는 것은 쉬운 부분입니다. 공식 SDK를 쓰면 도구 하나를 가진 stdio 서버는 오후 한나절이면 완성됩니다. 비용은 나중에 옵니다. HTTP 버전을 위한 OAuth, 지원 중단 대응(2026-07-28 개정판은 Roots, Sampling, Logging, Dynamic Client Registration을 지원 중단했습니다), 그리고 모델이 제대로 읽을 수 있는 도구 설명을 계속 써야 하는 일입니다. 가장 흔한 실수는 API를 엔드포인트 하나당 도구 하나로 감싸는 것입니다. 도구 설명 하나하나가 모델이 읽고 따져 봐야 하는 텍스트이므로, 작업 단위로 만든 짧은 도구 목록이 API 전체보다 낫습니다.

MCP, API, 통합, iPaaS

MCP는 API를 대체하지 않습니다. 거의 모든 MCP 서버는 API를 감싼 래퍼입니다. 실제 작업은 여전히 API에서 일어나고, API에는 고유한 호출 한도, 데이터 모델, 특이점이 있습니다. MCP가 바꾸는 것은 누가 API를 호출할 수 있느냐입니다. 개발자가 미리 하드코딩하는 대신, 모델이 실행 시점에 설명을 보고 호출을 고릅니다.

이 차이 덕분에 MCP와 자주 혼동되는 다른 두 가지와 깔끔하게 선을 그을 수 있습니다.

• 통합과 iPaaS(주요 플랫폼 비교는 여기에서)는 채팅에 누가 있든 없든 일정이나 트리거에 따라 결정론적으로 데이터를 옮깁니다. 매일 밤 주문 40,000건을 CRM에 동기화하는 작업이 모델이 도구 호출 40,000번을 하기로 결정하느냐에 달려 있어서는 안 됩니다.
• 리버스 ETL은 웨어하우스에서 모델링한 데이터를 운영 도구로 되돌려 보냅니다. 리버스 ETL이 무엇이고 언제 맞는지는 별도의 주제이며, 대화가 아니라 파이프라인입니다.
• MCP는 사람이나 에이전트가 필요할 때 그 시스템들을 가로질러 묻고, 살펴보고, 작업해야 하는 순간을 위한 것입니다.

실수는 양쪽 방향에서 일어납니다. 어떤 팀은 대량 동기화를 하려고 MCP 서버를 만들고, 느리고 비싸고 반복 불가능한 파이프라인을 얻습니다. 다른 팀은 통합을 꼼꼼히 만든 뒤 그 통합을 조회하라며 AI 어시스턴트에 원시 API 키를 넘기고, 통제되지 않는 뒷문을 얻습니다.

지원되는 통합에서는 지속 작업과 검토 도구가 명확한 권한 경계를 공유해야 합니다. 특정 흐름의 커넥터, 허용된 행동, 기록된 결과를 확인하세요. 통합 문서는 설정 안내와 아직 운영 증거가 필요한 경로를 구분합니다. MCP가 별도 승인된 도구를 제공할 수 있지만 목록만으로는 정기 동기화나 모든 필수 통제가 활성화되었다고 증명할 수 없습니다.

22개월 만에 MCP는 참조 서버 6개에서 Claude, ChatGPT, VS Code, Cursor가 모두 쓰는 Linux Foundation 프로젝트가 되었습니다. 모델을 시스템에 연결하는 일은 이제 싼 부분입니다. 진짜 일은 그 모델이 거기서 무엇을 해도 되는지 정하는 것입니다.