MCP 서버란 무엇인가: 도구, 리소스, 프롬프트를 쉬운 말로 설명합니다
MCP 서버는 AI 어시스턴트에게 어떤 시스템에서 무엇을 할 수 있는지 알려주고, 요청하면 실행하는 프로그램입니다. 도구, 리소스, 프롬프트의 작동 방식을 실제 예로 설명합니다.
목차
MCP 서버는 데이터베이스, 파일 트리, SaaS 제품 같은 시스템 앞에 놓인 작은 프로그램으로, AI 어시스턴트에게 거기서 무엇을 할 수 있는지 설명합니다. 어떤 도구를 호출할 수 있는지, 어떤 데이터를 읽을 수 있는지, 어떤 프롬프트를 제공하는지. 어시스턴트는 접속해서 "무엇을 갖고 있어?"라고 묻고, 그때부터 당신의 허락 아래 Model Context Protocol(MCP)을 통해 그 시스템을 대신 다룰 수 있습니다.
그게 전부입니다. 이 가이드의 나머지는 서버가 제공하는 세 가지, 어시스턴트가 그것을 발견하는 방식, API나 플러그인과의 차이, 그리고 실제 도구 호출이 어떻게 생겼는지를, 우리가 자체 워크스페이스를 위해 운영하는 서버를 예로 설명합니다.
MCP 서버가 해결하는 문제
MCP 이전에는 어시스턴트를 제품에 연결하려면 조합마다 연동을 따로 만들어야 했습니다. 이슈 트래커용 ChatGPT 플러그인, Cursor용 별도 확장, Claude용 맞춤 함수 세트, 이런 식으로요. 어시스턴트마다 형식이 달랐고, 각 연동은 충분히 신경 쓰는 사람이 유지보수했습니다.
2024년 11월 Anthropic이 공개했고 지금은 공개 사양으로 관리되는 MCP는 이 조합들을 하나의 표준으로 대체합니다. 제품은 서버 하나를 만듭니다. MCP를 지원하는 어시스턴트(2026년 10월 기준 Claude, ChatGPT, Cursor, Codex, VS Code 등 수십 종)는 누구나 거기에 접속할 수 있습니다. 어시스턴트는 제품이 내부적으로 어떻게 돌아가는지 알 필요 없이, 서버가 제공한다고 말한 것만 알면 됩니다.
가장 잘 들어맞는 비유는 USB 포트입니다. 그 전에는 기기마다 전용 커넥터가 필요했고, 그 후에는 어떤 기기든 어떤 컴퓨터에나 꽂을 수 있게 됐습니다. MCP는 AI 어시스턴트와 그것이 다루는 시스템을 잇는 그런 커넥터입니다.
서버가 제공하는 세 가지
사양(현재 리비전 2025-11-25)은 서버가 노출할 수 있는 것을 세 종류로 정의합니다. 셋 다 제공할 필요는 없고, 도구만 제공하는 서버도 많습니다.
| 도구 | 리소스 | 프롬프트 | |
|---|---|---|---|
| 무엇인가 | 모델이 호출할 수 있는 함수 | 모델이 읽을 수 있는 데이터 | 재사용 가능한 지시 템플릿 |
| 사용을 결정하는 쪽 | 모델, 사용자 동의 아래 | 애플리케이션 또는 사용자 | 사용자, 보통 메뉴에서 |
| 예시 | work_create_issue | 프로젝트의 요구사항 문서 | "통화 전에 이 고객을 요약해 줘" |
| 발견 방법 | tools/list | resources/list | prompts/list |
| 사용 방법 | tools/call | resources/read | prompts/get |
| 데이터 변경 가능 여부 | 쓰기 도구라면 가능 | 불가 | 불가 |
도구
도구는 이름, 설명, 그리고 어떤 인수를 받는지 정하는 JSON Schema를 가진 함수입니다. 모델은 설명을 읽고 요청에 맞는 도구를 고른 뒤 인수를 채우고, 애플리케이션은 실행 전에 당신에게 묻습니다. 도구는 어시스턴트가 대답만 하는 게 아니라 행동하게 하는 MCP의 부분입니다.
우리 서버는 85개의 도구를 노출합니다. 분위기를 보여주기 위해 몇 개만 들면, projects_list와 project_status는 프로덕트 상태를 읽고, work_create_issue와 work_set_issue_status는 백로그를 바꾸고, crm_list_deals와 crm_move_deal은 파이프라인을 다루고, calendar_find_time은 여러 사람의 빈 시간을 찾고, people_find는 이름으로 동료를 찾습니다. 각 도구는 읽기인지 쓰기인지 표시되어 있고 필요한 권한 스코프를 명시합니다.
리소스
리소스는 모델이 컨텍스트로 읽을 수 있는 것, 즉 문서, 레코드, 파일입니다. 도구와의 차이는 누가 고르느냐입니다. 도구는 모델이 제어합니다. 모델이 호출을 결정합니다. 리소스는 애플리케이션이 제어합니다. 앱이나 사람이 채팅에 파일을 떨어뜨리듯 대화에 첨부합니다. 좋은 서버는 사람들이 그렇지 않으면 손으로 붙여넣었을 문서를 노출합니다.
프롬프트
프롬프트는 흔한 작업을 위해 서버가 제공하는 템플릿으로, 인수를 넣을 자리가 있습니다. 어시스턴트에서 명령이나 메뉴 항목으로 나타나고, 사람이 고르면 서버가 텍스트를 채웁니다. 셋 중 가장 덜 쓰이지만, 서버의 도구를 매번 지시를 쓰지 않고 누구나 반복할 수 있는 워크플로로 바꾸는 데는 가장 유용합니다.
어시스턴트는 서버를 어떻게 발견하는가
프로토콜은 JSON-RPC 2.0으로, 코드 에디터의 언어 서버가 쓰는 것과 같은 요청-응답 형식입니다. 연결은 이렇게 진행됩니다.
- 초기화. 클라이언트가 지원하는 프로토콜 버전과 자신의 기능을 담아
initialize를 보냅니다. 서버는 자기 버전과 제공 내용(도구, 리소스, 프롬프트, 그리고 그것이 바뀔 때 클라이언트에 알릴 수 있는지)을 답합니다. - 목록 조회. 클라이언트가
tools/list를, 보통resources/list와prompts/list도 호출합니다. 서버는 각 도구의 이름, 설명, 입력 스키마를 돌려줍니다. 이제 모델은 무엇을 할 수 있는지 압니다. - 호출. 모델이 도구를 고르면 클라이언트는 이름과 인수를 담아
tools/call을 보냅니다. 서버가 작업을 수행하고 결과를 돌려줍니다. 결과는 콘텐츠 항목(보통 텍스트)의 목록이고, 선택적으로 출력 스키마에 맞는 구조화 데이터를 포함합니다. - 알림. 누군가 새 권한을 승인해서 서버의 도구 목록이 바뀌면, 서버가 알림을 보내고 클라이언트가 다시 목록을 조회합니다.
거부된 쓰기나 잘못된 인수처럼 모델이 알아야 할 방식으로 실패한 도구는 isError: true와 메시지가 담긴 정상 결과를 돌려줍니다. 모델은 메시지를 읽고 연결 전체가 끊기는 대신 다른 방법을 시도할 수 있습니다.
여기에는 보안 원칙이 녹아 있습니다. 사양은 애플리케이션에게 완전히 신뢰하지 않는 서버의 도구 설명을 신뢰할 수 없는 것으로 취급하고, 도구 호출에 사람을 개입시키라고 말합니다. 도구 설명은 서버가 쓴 텍스트일 뿐이고, 악의적인 서버라면 오해를 부르는 설명을 쓸 수 있습니다.
로컬 서버와 원격 서버
서버는 두 가지 형태로 나오며, 고르거나 만들 때 그 차이가 중요합니다.
로컬 서버는 당신의 컴퓨터에서 돌아갑니다. 어시스턴트가 하위 프로세스로 실행하고 표준 입출력(stdio 전송)으로 대화합니다. 보통 환경 변수에서 자격 증명을 읽습니다. 초기 MCP 서버 대부분이 이렇게 동작했습니다. 파일 시스템 서버, Git 서버, 자기 Postgres를 가리키는 데이터베이스 서버. 개발자 한 명에게는 좋지만 팀에는 불편합니다. 모든 노트북에 서버를 설치하고 업데이트하고 키를 넣어 줘야 하니까요.
원격 서버는 인터넷상의 하나의 HTTPS 엔드포인트에서 Streamable HTTP 전송으로 돌아가고 여러 사용자가 공유합니다. URL로 어시스턴트에 추가하고 브라우저에서 OAuth로 로그인하면, 서버는 사용자별 데이터를 분리해 관리합니다. 호스팅 제품이 MCP를 제공한다면 이 방식이어야 합니다. 아무도 무언가를 설치하거나 설정 파일에 API 키를 붙여넣고 싶어 하지 않기 때문입니다. Atrix 서버가 https://atrix.dev/api/mcp에서 원격 전용인 이유가 그것입니다. 워크스페이스는 공유되므로 연결은 개인별이어야 하고 취소할 수 있어야 합니다.
용어집의 MCP 서버 항목이 전송 방식을 더 깊이 다룹니다. 짧게 말하면 stdio는 내 컴퓨터용, Streamable HTTP는 공유되는 모든 것을 위한 것입니다.
실제 도구 호출, 처음부터 끝까지
Claude Code로 우리 서버에 연결한 누군가가 "버그 등록해 줘: 인보이스 페이지의 내보내기 버튼이 Safari에서 아무 반응이 없어"라고 입력하면 벌어지는 일입니다.
모델은 tools/list에서 받은 도구 설명을 읽고 work_create_issue를 고릅니다. 용어집의 MCP 도구 항목에 일반적인 형태가 있고, 구체적인 호출은 이렇게 생겼습니다.
{
"method": "tools/call",
"params": {
"name": "work_create_issue",
"arguments": {
"projectId": "Billing",
"title": "내보내기 버튼이 Safari에서 반응하지 않음 (인보이스 페이지)",
"priority": "HIGH"
}
}
}
무언가 기록되기 전에 세 가지가 일어납니다. Claude Code가 호출을 보여주고 사람에게 승인을 요청합니다. 서버는 제시된 토큰에 work.write 스코프가 있는지 확인합니다. 그다음 토큰 뒤의 사람이 그 프로젝트에서 이슈를 만들 수 있는지 확인합니다. 토큰은 만든 사람보다 더 많은 일을 할 수 없습니다. 어느 확인이든 실패하면 결과는 isError: true와 빠진 스코프를 명시한 메시지로 돌아오고, 모델은 무엇을 추가해야 하는지 사람에게 알려줍니다.
셋 다 통과하면 이슈가 만들어지고 결과에 식별자가 담깁니다.
{
"content": [{ "type": "text", "text": "BIL-142 생성됨: 내보내기 버튼이 Safari에서 반응하지 않음 (인보이스 페이지)" }],
"structuredContent": { "issueId": "BIL-142", "href": "/dashboard/projects/billing?issue=BIL-142" }
}
호출은 감사 기록에도 남습니다. 어떤 도구였는지, 결과가 무엇이었는지, 어떤 레코드였는지. 내용은 절대 남기지 않습니다. 이 감사 기록이 팀에 맡길 수 있는 어시스턴트와 나 혼자만 쓸 수 있는 어시스턴트의 차이입니다.
"Billing"이 ID가 아니라 이름으로 전달된 점에 주목하세요. 어시스턴트를 위해 만든 서버는 가능한 한 이름을 받아들여야 합니다. 모델은 보통 ID가 아니라 이름을 갖고 있기 때문입니다. 그리고 이름이 모호할 때는 후보를 나열하며 명확히 거부해야 합니다.
MCP 서버 vs API vs 플러그인
제품에 이미 REST API가 있는데 왜 서버가 필요하냐는 질문은 당연합니다. 셋은 서로 다른 문제를 풉니다.
| REST API | 플러그인 또는 확장 | MCP 서버 | |
|---|---|---|---|
| 대상 | 코드를 쓰는 개발자 | 특정 어시스턴트 하나 | 모든 MCP 어시스턴트 |
| 모델에게 스스로를 설명하는가 | 아니요; 연결 코드를 직접 씀 | 예, 그 어시스턴트의 형식으로 | 예, 하나의 표준 형식으로 |
| 발견 방법 | 문서를 읽음 | 스토어에서 설치 | 연결 시 tools/list |
| 인증 | API 키, OAuth | 제각각 | 원격은 OAuth 2.1, 로컬은 환경 변수 |
| 유지보수 | 한 번 | 어시스턴트마다 한 번 | 한 번 |
API는 프로그램을 위한 것이고, 플러그인은 어시스턴트 하나를 위한 것이며, MCP 서버는 어떤 모델이든 읽을 수 있는 형태로 API 위에 얹은 얇은 층입니다. 모델이 고를 수 있는 도구 이름과 설명, 채울 수 있는 스키마, 이해할 수 있는 결과. 실제로 우리 서버는 REST API와 같은 함수를 호출하며, 설명하는 방식만 다릅니다.
솔직한 한계도 있습니다. 85개 도구 중에서 고르는 모델은 설명을 보고 고르기 때문에, 설명이 나쁘면 잘못된 호출로 이어집니다. 서버를 만드는 일은 어떤 SDK든 처리해 주는 프로토콜보다, 모델이 올바른 것을 고르도록 도구에 이름을 붙이고 설명하는 일에 가깝습니다.
작은 팀은 언제 써야 하나
MCP 서버의 이점을 얻기 위해 직접 만들 필요는 없습니다. 5~15명 팀의 흔한 경우는 이미 비용을 내는 어시스턴트를 이미 쓰는 도구에 연결하는 것입니다.
채팅창에 컨텍스트를 복사해 넣고 있는 자신을 발견하면 서버를 쓸 때입니다. 최근 이슈 세 개, 고객의 딜 단계, 요구사항 페이지를 붙여넣고 있다면요. 연결된 어시스턴트는 그것들을 스스로 읽습니다. 앱을 바꾸지 않고 어시스턴트에서 이슈를 등록하거나 시간을 잡고 싶을 때도 유용합니다.
서버가 로컬 전용이라 모든 노트북에 설치해야 하거나, 스코프 없는 API 키 붙여넣기를 요구한다면 미루세요. 모든 걸 할 수 있는 키가 다섯 대의 설정 파일에 들어 있는 건 부채입니다. 그리고 어시스턴트는 여전히 도구가 허용하는 것만 한다는 점을 기억하세요. 예를 들어 우리 서버에는 설계상 급여를 읽는 도구가 없습니다.
MCP 기능 페이지에 지금 Atrix에 연결되는 어시스턴트가 나와 있고, 개발자 개요에 각각의 설정 방법이 있습니다.
FAQ
MCP는 무엇의 약자인가요?
Model Context Protocol입니다. 2024년 11월 Anthropic이 공개한 공개 사양으로, AI 애플리케이션이 도구, 리소스, 프롬프트를 노출하는 서버를 통해 외부 시스템에 연결하는 방법을 정의합니다. 현재 리비전은 2025-11-25입니다.
MCP 서버는 API와 같은 건가요?
아니요. API는 개발자를 위해 문서화된, 프로그램용 인터페이스입니다. MCP 서버는 그 위의 층으로, 표준 형식으로 언어 모델에게 스스로를 설명하기 때문에 누구도 맞춤 연결 코드를 쓰지 않아도 모델이 tools/list로 도구를 발견하고 tools/call로 호출할 수 있습니다. 대부분의 서버는 아래에서 API를 호출합니다.
MCP 서버를 쓰려면 코드를 짜야 하나요?
쓰는 데는 필요 없습니다. 원격 서버는 URL로 어시스턴트에 추가하고 브라우저에서 승인하면 되고, 로컬 서버는 보통 명령 하나로 설치됩니다. 직접 서버를 만들려면 코드가 필요하지만, 공식 SDK(TypeScript, Python 등)가 프로토콜을 처리합니다.
MCP로 회사 데이터에 어시스턴트를 연결해도 안전한가요?
서버에 따라 다릅니다. 직접 고르는 스코프가 있는 개인별 로그인, 어시스턴트가 당신보다 더 많은 일을 할 수 없도록 매 호출마다 확인되는 권한, 감사 로그, 접근 취소 기능을 확인하세요. 만능 키 하나를 파일에 붙여넣게 하는 서버는 피하세요.
도구와 리소스의 차이는 무엇인가요?
도구는 모델이 사용자 동의 아래 호출을 결정하는 함수이며 데이터를 바꿀 수 있습니다. 리소스는 애플리케이션이나 사용자가 모델이 읽도록 첨부하는 데이터이며 아무것도 바꿀 수 없습니다.
어떤 어시스턴트가 MCP 서버에 연결할 수 있나요?
2026년 10월 기준 Claude(웹, 데스크톱, Claude Code), ChatGPT, Cursor, OpenAI Codex, GitHub Copilot이 있는 VS Code 등 다수입니다. OAuth를 쓰는 원격 서버 지원은 어시스턴트마다 다르므로 각 어시스턴트의 커넥터 설정을 확인하세요.
다음 단계
서버를 안쪽에서 보고 싶다면 개발자 개요가 Claude Code, ChatGPT, Cursor를 Atrix 서버에 연결하는 과정을 각각의 정확한 명령과 모든 도구의 스코프 목록과 함께 안내합니다. MCP 기능 페이지는 비기술적인 버전입니다. 용어는 용어집의 MCP 서버와 MCP 도구 항목을 참고하세요.