MCP Server — AI가 외부 도구와 연결하는 방법을 표준화해야 하는 이유

본 기사는 MCP가 해결하는 실무상의 과제와, AI 애플리케이션을 구축하는 개발자에게 가져다주는 구체적인 이점에 초점을 맞춥니다. 설정 절차는 별도의 기사에서 다룹니다.

현재의 AI는 추론, 코드 생성, 데이터 분석을 상당한 수준으로 수행할 수 있습니다. 하지만 명확한 제약이 있습니다. AI는 스스로 외부 시스템에 연결할 수 없다는 점입니다.

간단한 예: 사내 데이터베이스에서 수치를 가져오고, 이번 주 리포트 파일을 읽고, 요약을 Slack에 보내는 것——추론 측면에서 AI는 충분히 가능하지만, 이를 실행하려면 개발자가 모델마다, 도구마다 커넥터(Connector)를 직접 작성해야 합니다. 모델과 도구의 수가 늘어나면, 이는 아키텍처 계층에서 해결해야 할 문제가 됩니다.

5개의 시스템에 연결하는 AI 어시스턴트를 구축한다고 가정해 봅시다:

• Redmine
• Slack
• PostgreSQL
• 사내 Wiki
• Google Drive

회사에서 3종류의 AI 모델을 사용하고 있는 경우, 기존 방식으로는 각 (모델, 도구) 조합마다 전용 커넥터가 필요합니다:

Model A ──── Redmine connector
Model A ──── Slack connector
Model A ──── PostgreSQL connector
...

도구가 바뀔 때마다——함수 이름 변경, 파라미터 추가, API 리팩토링——다음 작업이 발생합니다:

• 로직 코드 수정
• 각 AI를 위한 도구 정의(Tool Definition) 다시 쓰기
• 대응하는 프롬프트(Prompt) 업데이트
• 애플리케이션 재시작

이것이 M×N 문제입니다: M 모델 × N 도구 = M×N 커넥터. 규모가 커질수록 유지보수 비용은 곱절로 증가합니다.

**Model Context Protocol (MCP)**는 Anthropic이 개발한 오픈 프로토콜로, 모델과 도구 사이에 표준화된 레이어를 둡니다. 각 쌍이 독자적으로 통신 방법을 결정하는 것이 아니라, 모든 것이 공통 프로토콜을 따릅니다.

┌── Redmine MCP Server
├── Slack MCP Server
Model A ──┐ ├── PostgreSQL MCP Server
...

새로운 모델을 추가 → 모델 측에서 MCP를 한 번 통합하기만 하면 됩니다.

새로운 도구를 추가 → 해당 도구용 MCP Server를 한 번 작성하기만 하면 됩니다.

양측은 상대방의 구현 상세를 알 필요가 없습니다.

MCP는 클라이언트-서버 모델이며, 다음 3가지 요소로 동작합니다:

사용자가 조작하는 AI 애플리케이션——Claude Desktop, Cursor, VS Code, 자체 채팅 봇 등. Host는 연결을 초기화하고, 액세스 권한을 제어하며, 처리 흐름 전체를 조정합니다.

Host 내부의 프로토콜 계층에서, 1 대 1로 단일 MCP Server와의 연결을 유지합니다. Host가 5개의 도구와 연동하는 경우, 5개의 독립적인 Client를 생성하여 각각이 1개의 연결을 관리합니다.

도구 또는 데이터 소스의 능력을 패키지화하여 MCP 표준에 따라 공개하는 프로그램입니다. Server는 로컬(stdio) 또는 원격(HTTP)으로 실행할 수 있습니다.

MCP 생태계의 예:

Redmine MCP Server→get_issue(id), get_issue_context(id), search_issues(query)

Slack MCP Server→post_message(channel, text)

MCP Server는 primitives라고 불리는 3가지 종류의 리소스를 제공합니다. 각 primitive에는 서로 다른 제어 주체가 있어, 시스템 내의 책임 분리가 명확해집니다:

Primitive	제어 주체	의미
Tools	Model (AI)	AI가 언제 어떤 도구를 호출할지를 자율적으로 결정
Resources	Application (Host)	앱이 취득하는 데이터와 컨텍스트 투입 타이밍을 결정
Prompts	User (사용자)	사용자가 사용할 템플릿을 능동적으로 선택

Tools는 실행 가능한 함수로, AI가 외부 시스템과 상호작용하여 상태를 변경할 수 있습니다: 티켓 업데이트, Slack 게시, 파일 생성, 데이터베이스 업데이트 등. Resources와 달리, Tools는 읽기뿐만 아니라 쓰기도 수행합니다.

사용자는 도구 이름이나 호출 구문을 알 필요가 없습니다. 자연어로 요구 사항을 말하기만 하면, AI가 어떤 도구를 어떤 인자(Argument)로 사용할지 결정합니다.

예시: Redmine MCP Server와 Slack MCP Server에 연결된 AI 어시스턴트의 경우:

"Redmine의 #1234를 확인해서 담당자, 블로커(Blocker), 수락 조건(Acceptance Criteria)을 요약한 뒤, #dev 채널에 게시해줘."

AI는 자동으로 다음을 호출합니다:

get_issue_context(id: 1234)

post_message(channel: "#dev", text: "…")

Redmine을 열어 티켓을 다시 읽거나, Slack에 직접 복사하여 붙여넣을 필요가 없습니다.

Resources는 Host가 가져와서 AI의 컨텍스트(Context)에 전달하는 읽기 전용 데이터—파일, DB 레코드, 로그, 문서 등입니다. 각 리소스는 URI로 식별됩니다:

redmine://issues/1234 → Redmine 티켓 본문·커스텀 필드
redmine://projects/backend-api → 프로젝트 트래커·설명
db://orders/schema → 데이터베이스 테이블 스키마

Resources는 가져올 때 변경되지 않습니다—이는 Tools와의 명확한 경계입니다.

Prompts는 서버에 정의된 대화용 템플릿입니다. 사용자가 필요할 때 선택하여 실행할 수 있으며, 매번 처음부터 입력할 필요가 없습니다. 서버에 저장되므로 한 곳에서 업데이트하면 모든 클라이언트에 즉시 반영됩니다.

MCP Server 작성을 마치면, MCP를 지원하는 어떤 LLM(Large Language Model)에서도 사용할 수 있습니다—모델을 바꾸더라도 커넥터(Connector)를 다시 작성할 필요가 없습니다.

MCP 이전: 함수 시그니처(Function Signature) 변경 → 코드 수정 → 각 AI용 도구 정의 재작성 → 프롬프트 업데이트 → 앱 재시작.

MCP 방식: MCP Server만 수정하면 됩니다. 연결된 모든 Host가 tools/list를 통해 새로운 정의를 자동으로 가져오며—모델 측의 변경이나 재시작은 필요하지 않습니다.

Slack 게시, 티켓 상태 변경, 파일 삭제 등 실제로 영향을 미치는 도구를 AI가 호출할 때, Host는 사전에 확인을 요청합니다:

AI가 도구를 사용하려고 합니다: post_message
Input: { "channel": "#dev", "text": "Issue #1234: …" }
[항상 허용] [이번만 허용] [거부]

사용자는 AI가 무엇을 하고 있는지 정확히 파악하고 거부할 수 있습니다.

Roots 메커니즘을 통해 클라이언트는 서버가 작업해야 할 데이터 영역을 지정할 수 있습니다:

{
"roots": [
{ "uri": "file:///home/user/projects/myapp", "name": "Project Directory" }
...

주의: 공식 문서에 따르면, Roots는 **조정 메커니즘 (coordination mechanism)**이며 엄격한 보안 경계는 아닙니다. 서버는 이를 따를 것이 권장(SHOULD)되지만, 필수(MUST) 사항은 아닙니다. 실제 보안은 OS 레벨의 권한에 의존해야 합니다. Roots는 작업 범위 제한이나 잘못된 접근 방지에 적합하며—보안 레이어의 대체제로 사용해서는 안 됩니다.

Sampling 기능을 통해 MCP Server는 필요에 따라 클라이언트 측의 LLM을 역방향으로 호출할 수 있습니다—데이터 요약, 분석, 텍스트 생성 등—모델을 직접 통합하거나 추가적인 API 비용을 부담할 필요가 없습니다:

Server가 데이터 취득 완료
→ 요약 필요 → Client에 Sampling 요청 전송
→ Client가 기존 LLM을 사용 → 결과를 Server에 반환
...

이를 통해 멀티 에이전트 아키텍처 (Multi-agent architecture)가 가능해집니다: 여러 에이전트가 MCP를 통해 협력하며, 어떤 에이전트도 독자적인 LLM을 배포할 필요가 없습니다.

관점	Function Calling	MCP
도구 구현 위치	AI 애플리케이션에 내장	독립된 MCP Server
...

MCP는 아키텍처 계층에서 AI 통합 문제를 해결합니다. 케이스마다 개별적으로 대응하는 것이 아니라, 개발자가 모델 측이든 도구 측이든 MCP 표준을 한 번만 따라 구현하면 양측이 자동으로 연결됩니다.

그 결과, 커넥터(Connector) 수는 M×N에서 M+N으로 줄어들고, 도구는 여러 모델에서 재사용할 수 있으며, 업데이트 시 재시작이 필요하지 않고, 사용자는 AI의 각 액션 (Action)을 제어할 수 있습니다.

실제 데이터나 실제 시스템에 연결하는 AI 애플리케이션의 경우, 나중에 임시방편 (ad-hoc)으로 대처하기보다 처음부터 MCP를 아키텍처로 검토할 가치가 있습니다.