LLM 기반 에이전트를 프로덕션에 배포할 때 가장 큰 병목은 모델 그 자체가 아닙니다. 진짜 악몽은 사내 데이터베이스, 슬랙(Slack), 지라(Jira), 로컬 파일 시스템 등 수십 개의 외부 리소스를 LLM과 연동할 때 발생하는 'Glue Code(접착 코드)'의 유지보수 비용입니다. 2024년 11월 앤트로픽(Anthropic)이 공개한 MCP(Model Context Protocol)는 바로 이 지점을 타격합니다. 각 서비스마다 제각각인 API 연동 방식을 버리고, 마치 USB-C처럼 단 하나의 표준 프로토콜로 AI와 외부 세계를 연결하겠다는 것입니다. 이 글에서는 MCP가 어떻게 $O(N \times M)$의 연동 복잡도를 $O(N + M)$으로 줄이는지, 그리고 실제 서버 구현은 어떻게 하는지 기술적인 관점에서 파헤쳐 봅니다.
Deep Dive: 왜 MCP인가? (JSON-RPC의 부활)
기존의 LLM 애플리케이션 구조(LangChain이나 LlamaIndex를 사용한 경우 포함)는 특정 데이터 소스에 접근하기 위해 클라이언트 측에 하드코딩된 로직을 심어야 했습니다. PostgreSQL용 어댑터 따로, Google Drive용 어댑터 따로 작성해야 했죠. 이는 새로운 모델이 나올 때마다, 혹은 새로운 데이터 소스가 추가될 때마다 전체 파이프라인을 수정해야 함을 의미합니다.
MCP는 Client-Host-Server 아키텍처를 도입하여 이 문제를 해결합니다. 핵심은 통신 레이어의 추상화입니다. MCP는 전송 계층(Stdio, SSE 등) 위에서 JSON-RPC 2.0 기반의 메시지를 주고받습니다. 이는 개발자가 더 이상 "어떻게 연결할까"를 고민하는 것이 아니라, "무엇을 노출할까(Resource, Prompt, Tool)"에만 집중하게 만듭니다.
The Solution: TypeScript로 MCP 서버 구현하기
말로만 표준을 논하는 것은 의미가 없습니다. 실제로 간단한 날씨 정보를 반환하는 MCP 서버를 TypeScript로 구현해 보겠습니다. 이 코드는 Claude Desktop이나 다른 MCP 호환 클라이언트가 즉시 인식하여 사용할 수 있습니다.
우선 필요한 패키지를 설치합니다: npm install @modelcontextprotocol/sdk zod
// server.ts
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
CallToolRequestSchema,
ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
import { z } from "zod";
// 1. 서버 인스턴스 생성 (이름과 버전 명시)
const server = new Server(
{
name: "weather-mcp-server",
version: "1.0.0",
},
{
capabilities: {
tools: {}, // 이 서버가 'Tool' 기능을 제공함을 선언
},
}
);
// 2. 사용 가능한 도구 목록 정의
// 클라이언트(예: Claude)는 이 목록을 조회하여 사용자에게 기능을 노출합니다.
server.setRequestHandler(ListToolsRequestSchema, async () => {
return {
tools: [
{
name: "get_weather",
description: "특정 도시의 현재 날씨를 조회합니다.",
inputSchema: {
type: "object",
properties: {
city: {
type: "string",
description: "도시 이름 (예: Seoul, New York)",
},
},
required: ["city"],
},
},
],
};
});
// 3. 실제 도구 실행 로직 핸들링
server.setRequestHandler(CallToolRequestSchema, async (request) => {
if (request.params.name === "get_weather") {
// 입력값 검증 (Zod 사용 권장)
const city = String(request.params.arguments?.city);
// 실제 프로덕션에서는 외부 Weather API를 호출해야 합니다.
// 여기서는 시뮬레이션 데이터를 반환합니다.
const weatherData = {
Seoul: "맑음, 15°C",
"New York": "비, 10°C",
};
const result = weatherData[city as keyof typeof weatherData] || "알 수 없음";
return {
content: [
{
type: "text",
text: `Current weather in ${city}: ${result}`,
},
],
};
}
throw new Error("Tool not found");
});
// 4. Stdio Transport로 서버 시작 (파이프 통신)
const transport = new StdioServerTransport();
await server.connect(transport);
console.error("Weather MCP Server running on Stdio...");
StdioServerTransport는 로컬 프로세스로 실행되므로, 서버 코드 내에서 fs(파일 시스템) 접근이나 exec(명령어 실행)와 같은 민감한 작업을 수행할 때는 반드시 엄격한 권한 검증 로직을 포함해야 합니다. MCP는 연결 통로일 뿐, 보안 정책은 개발자의 몫입니다.
성능 및 유지보수성 비교
기존의 Ad-hoc 방식(각 서비스별 SDK 직접 연동)과 MCP 표준 방식을 도입했을 때의 차이를 비교해보았습니다. 저희 팀 내부 테스트 결과, 신규 데이터 소스 연동 시 소요 시간이 획기적으로 단축되었습니다.
| 비교 항목 | 기존 방식 (Ad-hoc Integration) | MCP 표준 방식 |
|---|---|---|
| 연동 복잡도 | 모델 N개 × 서비스 M개 (N × M) | 서비스 M개만 구현하면 모든 모델 연결 (N + M) |
| 코드 재사용성 | 낮음 (특정 앱에 종속적) | 매우 높음 (Claude, IDE, Custom Client 공용) |
| 디버깅 용이성 | 앱 로직과 섞여있어 추적 난해 | MCP Inspector 도구로 메시지 단위 검증 가능 |
| 확장성 | 서비스 추가 시 클라이언트 배포 필요 | 서버만 추가하면 클라이언트 즉시 인식 |
Conclusion
MCP는 단순한 오픈소스 프로젝트가 아니라, AI 애플리케이션 생태계의 '표준 규격'을 정의하려는 시도입니다. MCP 공식 문서를 보면 알 수 있듯이, 이 프로토콜은 AI 모델이 고립된 텍스트 생성기에서 벗어나 실제 세계의 데이터와 도구를 자유자재로 다루는 에이전트로 진화하는 데 필수적인 인프라입니다. 지금 사내 LLM 시스템을 구축하고 있다면, 독자적인 연동 방식을 고집하기보다 MCP 서버를 구축하여 확장성과 호환성을 확보하는 것이 장기적인 기술 부채를 줄이는 가장 확실한 방법입니다.
Post a Comment