한 줄 요약: Agent는 코드는 쓸 수 있는데 GitHub Issue, 데이터베이스 schema, 내부 문서는 읽지 못합니다——문제는 모델이 아니라 「데이터가 어디서 오는지」가 정리되지 않은 경우가 많습니다. 본문은 MCP 프로토콜 원리부터 아키텍처 계층, Tools/Resources/Prompts 3대 기능, stdio·HTTP 전송, Cursor·Claude Code 설정 예시와 검수 체크리스트까지 다룹니다. 읽고 나면 각 SaaS마다 별도 접착 코드 없이 주요 데이터 소스를 Agent에 연결할 수 있습니다.
관련 글: Claude Code MCP 설치 튜토리얼 · MCP Server 20선 추천 · MCP 권한 최소 노출
MCP란? 무엇을 해결하나?
Model Context Protocol(MCP, 모델 컨텍스트 프로토콜)은 2024년 말 Anthropic이 오픈소스로 공개한 개방형 표준입니다. 목표는 분명합니다: AI 애플리케이션(Host)이 통일되고 감사 가능한 방식으로 외부 세계——코드 저장소, 데이터베이스, 문서 사이트, 티켓 시스템, 브라우저——에 연결되게 하는 것. 데이터 소스마다 맞춤 통합을 작성할 필요가 없습니다.
MCP 이전 팀이 택하던 길은 대략 두 가지였습니다:
- 수동으로 컨텍스트 운반——Issue 링크, SQL 결과, API 응답을 채팅에 복사. 정확하지만 느리고 확장되지 않습니다.
- 자체 Function Calling——GitHub, Postgres, Notion마다 tool schema와 인증을 구현. 유연하지만 유지보수 비용이 크고, 클라이언트(Cursor → Claude Code)를 바꾸면 다시 작성해야 합니다.
MCP는 세 번째 길을 제공합니다: 「데이터 소스 ↔ Agent」 인터페이스를 표준화합니다. GitHub MCP Server 하나를 설정하면 Cursor, Claude Code, VS Code Copilot, OpenAI Codex에서 재사용할 수 있습니다. 커뮤니티에는 이미 수천 개의 Server가 있으며 주요 SaaS와 개발 도구를 커버합니다.
한 줄로 위치 짚기
MCP는 대규모 언어 모델 자체가 아니라 Agent의 「USB 인터페이스」입니다——Host가 추론과 계획을 담당하고, MCP Server가 외부 데이터를 모델이 호출할 수 있는 구조화된 기능으로 바꿉니다. 모델이나 클라이언트를 바꿔도 데이터 소스 설정은 따라갈 수 있습니다.
3계층 아키텍처: Host, Client, Server
MCP 설정을 이해하려면 세 역할의 협력 관계를 먼저 봐야 합니다:
| 역할 | 대표 예 | 책임 |
|---|---|---|
| Host(호스트) | Cursor, Claude Code, Claude Desktop, VS Code | 대화 UI 제공, 대규모 언어 모델 스케줄링, MCP 도구 호출 여부 결정 |
| Client(클라이언트) | Host 내장 MCP 커넥터 | Server와의 세션 유지, tools/list, tools/call 등 JSON-RPC 메시지 중계 |
| Server(서버) | GitHub MCP, Context7, Supabase MCP, 자체 Server | Tools/Resources/Prompts 노출, 실제 데이터 읽기·쓰기와 API 호출 실행 |
전형적인 호출 체인: Cursor에서 「PR #42에서 변경된 파일은?」이라고 질문 → Host가 대규모 언어 모델에 전달 → 모델이 mcp__github__get_pull_request 호출 결정 → Client가 stdio 또는 HTTP로 GitHub MCP Server에 요청 → Server가 GitHub API를 호출해 구조화 JSON 반환 → 모델이 실제 데이터로 답변 생성.
주의: 설정하는 것은 Server 연결 방식(명령, URL, 환경 변수)입니다. Host가 노출된 도구를 자동으로 발견합니다. prompt에 API 문서를 손으로 쓸 필요 없이, Server 시작 시 tools/list로 기능 목록을 Client에 푸시합니다.
3대 기능 원시 타입: Tools, Resources, Prompts
MCP Server는 Agent에 세 종류의 기능을 노출하며, 각각 다른 데이터 소스 연결 패턴에 대응합니다:
Tools(도구)——「Agent가 동작을 실행하게 하기」
가장 많이 씁니다. 각 Tool에는 이름, 설명, 입력 schema(JSON Schema)가 있고, Agent가 추론 중 필요할 때 호출합니다. 예: GitHub MCP의 search_code, Playwright MCP의 browser_click, 데이터베이스 MCP의 execute_query.
데이터 소스 설정에서 90% 시나리오는 Tool형 Server 선택입니다: 저장소 읽기, 테이블 조회, HTTP 전송, 브라우저 조작.
Resources(리소스)——「Agent가 정적 컨텍스트를 읽게 하기」
Resources는 주소 지정 가능한 데이터 조각으로, 「URI가 붙은 읽기 전용 파일」과 비슷합니다. Server가 file://docs/api.md 또는 db://schema/users를 선언하면, Host가 대화 시작 전이나 중에 내용을 가져와 컨텍스트에 주입할 수 있습니다. Agent가 어떤 Tool을 호출할지 「추측」할 필요가 없습니다.
적합한 대상: 프로젝트 README, OpenAPI spec, 데이터베이스 schema 스냅샷, 설정 템플릿 등 비교적 안정적이고 열거 가능한 지식.
Prompts(프롬프트 템플릿)——「프리셋 워크플로 진입점」
Server는 이름 있는 Prompt 템플릿(매개변수 포함)을 노출할 수 있고, Host에서 「Code Review」「마이그레이션 스크립트 작성」 같은 고정 흐름을 원클릭으로 시작합니다. 커뮤니티 Server에서 Tools보다 채택률은 낮지만, 팀 SOP를 재사용 가능한 진입점으로 포장하기에 적합합니다.
데이터 소스에서 Agent까지: 설정 인과 체인
권장 순서
- 먼저 읽기 전용 데이터 소스 1개 연결
- 실제 작업으로 한 번 통과
- 그다음 쓰기 권한 Server 추가
흔한 실수
- 한 번에 10+ Server 설치
- 프로덕션 DB에 쓰기 가능 DSN 부여
- 설정 후 검수하지 않음
데이터 소스 유형과 대표 MCP Server 매핑
아래 표로 「무엇을 연결하고 싶은지」를 「어떤 Server를 설치할지」에 빠르게 매핑할 수 있습니다. 더 완전한 20개 목록은 MCP Server 추천을 참고하세요.
| 데이터 소스 유형 | 대표 MCP Server | 주요 기능(Tools) | 인증 방식 |
|---|---|---|---|
| 코드 저장소(GitHub) | GitHub MCP(공식) | 파일 읽기, 코드 검색, Issue/PR, CI 상태 | OAuth Remote 또는 세분화 PAT |
| 로컬 코드 시맨틱 | CodeGraph MCP | 심볼 점프, 의존 영향 범위 분석 | 로컬 인덱스, 원격 token 불필요 |
| 라이브러리/프레임워크 문서 | Context7 | 라이브러리명·버전으로 공식 문서 가져오기 | API Key(Remote) |
| 관계형 데이터베이스 | Supabase MCP / DBHub | schema 조회, SQL 실행 | OAuth 또는 읽기 전용 DSN |
| 웹/공개 API | Fetch MCP | HTTP GET → Markdown | 없음(제어된 아웃바운드) |
| 브라우저/UI 검증 | Playwright MCP | 클릭, 폼 입력, 접근성 트리 어설션 | 로컬 프로세스 |
| 티켓/협업 | Linear / Notion / Slack MCP | 티켓 읽기·쓰기, 페이지 검색, 메시지 전송 | OAuth Remote |
| 오류 모니터링 | Sentry MCP | 스택 트레이스 가져오기, issue 상태 | OAuth Remote |
선정 원칙
워크플로에 맞춰 고르고, 순위표대로 전부 설치하지 마세요. 풀스택 일상 개발은 Context7 + GitHub + Playwright 3종 세트로 80% 커버; 백엔드면 Supabase 추가; 팀이 Linear를 쓸 때만 Linear MCP. 동시 활성은 3–7개 Server를 권장합니다.
전송 계층: stdio와 HTTP, 무엇을 고를까?
MCP Client와 Server는 JSON-RPC 2.0으로 통신합니다. 2026년 주류는 두 가지입니다:
stdio(표준 입출력)
Host가 자식 프로세스로 Server를 시작합니다. 예: npx -y @modelcontextprotocol/server-github. stdin/stdout으로 메시지를 주고받습니다. 장점: 설정 단순, 포트 개방 불필요, 로컬 개발에 적합. 단점: Server마다 프로세스 1개; 일부 전체 Docker판은 도구 수가 많아 Cursor 약 40개 도구 상한을 넘길 수 있음.
Streamable HTTP / SSE(원격)
Server가 원격(또는 공식 호스팅)에서 동작하고, Client가 HTTPS로 연결합니다. OAuth로 권한 부여가 일반적입니다. GitHub, Supabase, Linear, Sentry 등 공식 Remote판 제공. 장점: 도구 집합이 정제됨, 로컬 Node/Docker 불필요, token은 OAuth로 관리. 단점: 네트워크 의존; 기업 내부망은 아웃바운드 정책 확인 필요.
| 시나리오 | 권장 전송 | 이유 |
|---|---|---|
| Cursor + GitHub | Remote HTTP(OAuth) | 로컬판 40+ 도구로 상한 초과 방지 |
| Claude Code + CodeGraph | stdio(codegraph mcp) |
로컬 저장소 인덱스 의존, 동일 머신 필수 |
| 내부망 자체 데이터 소스 | stdio 또는 내부망 HTTP | 데이터가 외부로 나가지 않음, 감사 가능 |
| 팀 통합 SaaS 연결 | Remote HTTP | 로컬 의존 제로, 권한 중앙 관리 |
Cursor에서 데이터 소스 설정
Cursor MCP 설정은 Settings → MCP, 또는 ~/.cursor/mcp.json을 직접 편집. mcpServers 객체에 Server마다 항목 하나.
예 1: 로컬 stdio — Fetch MCP
{
"mcpServers": {
"fetch": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-fetch"]
}
}
}
예 2: 로컬 stdio — GitHub MCP(PAT)
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxx"
}
}
}
}
Cursor UI에서 GitHub 공식 Remote MCP(OAuth)를 추가하는 편이 더 낫습니다. 도구 수가 적고 PAT를 손으로 넣을 필요가 없습니다. PAT는 세분화 읽기 전용으로, git에 커밋하지 마세요.
예 3: Context7(문서 데이터 소스)
{
"mcpServers": {
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp"]
}
}
}
저장 후 Cursor를 재시작하고 Settings → MCP 패널에서 Server 상태가 녹색 Connected인지 확인. Agent 모드에서 「Next.js 15 middleware 작성법을 찾아줘」라고 질문——설정이 맞으면 모델은 Context7을 호출하고 API를 환각하지 않습니다.
Claude Code에서 데이터 소스 설정
Claude Code는 ~/.claude.json(사용자 수준) 또는 프로젝트 루트 .mcp.json(프로젝트 수준)을 사용합니다. 구조는 Cursor와 비슷하지만 필드명과 경로에 약간 차이가 있습니다.
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxx"
}
},
"codegraph": {
"command": "codegraph",
"args": ["mcp"]
}
}
}
설정 변경 후 Claude Code를 완전히 종료하고 다시 시작. 저장소 루트에서 claude를 실행하고, 세션에서 /mcp로 연결된 Server와 도구 목록 확인. 성공 기준: mcp__github__*, mcp__codegraph__* 등 접두사 도구가 보이는 것.
단계별 가이드는 Claude Code MCP 설치 튜토리얼; 트리플 연결 아키텍처는 MCP 개요를 참고하세요.
프로젝트 vs 사용자 수준: 설정을 어디에 쓸까?
| 설정 위치 | Cursor | Claude Code | 적용 시나리오 |
|---|---|---|---|
| 사용자 수준(전역) | ~/.cursor/mcp.json |
~/.claude.json |
개인 상용 Server: Context7, GitHub, Fetch |
| 프로젝트 수준(저장소) | .cursor/mcp.json |
.mcp.json |
팀 통일: CodeGraph, 내부망 API, 프로젝트 전용 DB |
모범 사례: 자격 증명과 사용자 설정은 사용자 수준(git에 넣지 않음); 저장소에 묶인 데이터 소스(CodeGraph 인덱스 경로, 프로젝트 문서 Server)는 프로젝트 수준으로 .mcp.json을 커밋해 팀원이 clone 후 바로 쓰게 하세요. 민감 token은 환경 변수 참조를 사용. 예: "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PAT}" }. shell 또는 CI에서 주입.
설정 검수: Agent가 실제로 데이터 소스를 쓰게 하기
설정했다고 바로 쓰이지는 않습니다. 아래 체크리스트로 항목별 검수하세요:
- 연결성 — Cursor: Settings → MCP 녹색; Claude Code:
/mcp에 Server 목록, error 없음. - 도구 가시성 — 대상 Tool 이름 존재 확인(예:
mcp__github__search_code). - 스모크 작업 — 명확한 한 문장으로 도구 트리거. 「GitHub MCP로 이 저장소 open issues 목록」 또는 「Context7로 Prisma 최신 migrate 문법 찾기」.
- 실패 관측 가능성 — Agent가 도구를 호출하지 않으면 도구 과다, 설명 불명확, 작업이 모호한지 확인. 필요하면 prompt에 「GitHub MCP를 사용해 주세요」 명시.
- 권한 경계 — 의도적으로 권한 없는 작업(저장소 삭제 등)을 시도해 Server가 403을 반환하는지 확인. 조용히 성공하면 안 됩니다.
도구 수 상한
Cursor에는 약 40개 도구 상한이 있습니다. GitHub MCP 로컬 전체판만으로 40+ 도구를 노출하므로, 공식 Remote 경량판으로 바꾸거나 쓰지 않는 Server를 끄세요. 도구가 많으면 Agent가 「잘못된 도구를 고르고」 컨텍스트 token을 낭비합니다.
권한과 보안 경계
데이터 소스를 하나 연결할 때마다 Agent에 외부 시스템으로 가는 문을 엽니다. 핵심 원칙: 기본 읽기 전용, 쓰기는 명시적 활성화, 프로덕션 환경 분리.
- GitHub PAT — 세분화 token, 대상 저장소만 허용; Issues/Contents 읽기 전용으로 대부분 개발 시나리오 커버.
- 데이터베이스 DSN — 개발 DB는 읽기 전용 역할; 프로덕션 쓰기 연결 문자열을 프로젝트 설정에 쓰지 마세요.
- Filesystem MCP —
args에서 프로젝트 루트로 제한.$HOME이나/를 가리키지 마세요. - 내부망 API — 스테이징 읽기 전용 엔드포인트 사용; Claude Code 워크스페이스에 프로덕션
.env를 로드하지 마세요.
전체 정책 매트릭스와 공격 체인 분석은 MCP 권한 최소 노출을 참고하세요.
흔한 문제 해결
| 현상 | 가능한 원인 | 조치 |
|---|---|---|
| 도구 목록이 비어 있음 | JSON 구문 오류; Host 미재시작 | JSON 검증; Cursor/Claude Code 완전 종료 후 재시작 |
| GitHub 401 / 403 | PAT 만료 또는 저장소 미허용 | token 재생성, repo 범위 확인 |
| CodeGraph가 빈 결과 | 저장소 루트 밖에서 시작; 인덱스 미구축 | codegraph init -i; cwd 맞추기 |
| Agent가 MCP를 호출하지 않음 | 도구 과다; 작업 설명 모호 | Server 수 줄이기; prompt에 도구 지정 |
| npx 시작 타임아웃 | 첫 다운로드 느림; Node 미설치 | 의존성 사전 설치; node -v 확인 |
자주 묻는 질문
MCP와 Function Calling의 차이는?
Function Calling은 단일 API 요청 안의 도구 선언으로, 보통 특정 모델/벤더에 묶입니다. MCP는 지속적인 Server 연결과 개방형 프로토콜로, 한 번 설정하면 여러 클라이언트에서 재사용하고 커뮤니티가 생태계를 유지합니다. MCP를 「표준화된 플러그앤플레이 Function Calling 런타임」으로 이해하면 됩니다.
직접 MCP Server를 작성할 수 있나요?
가능합니다. 공식 SDK로 TypeScript(@modelcontextprotocol/sdk), Python 등이 있습니다. 전형적 시나리오: 사내 Wiki, 티켓 API, 전용 데이터 레이크 연결. 최소 Server는 tools/list와 tools/call만 구현하고 stdio 전송으로 Cursor에서 디버깅할 수 있습니다.
MCP가 데이터를 모델 벤더에 보내나요?
Tool 호출 결과는 대화 컨텍스트에 들어가 Host가 쓰는 대규모 언어 모델 API로 요청과 함께 전송됩니다——Agent 동작에 필요한 부분입니다. MCP 자체가 추가로 데이터를 「업로드」하지는 않습니다. 위험은 Server에 어떤 권한을 주는지(어떤 저장소를 읽을 수 있는지, 어떤 SQL을 실행할 수 있는지)에 있습니다. 최소 권한으로 노출면을 제어하세요.
2026년에 먼저 연결할 데이터 소스는?
대부분 개발자는 Context7(문서) + GitHub(저장소) + Playwright(브라우저 검증)부터 시작합니다. 백엔드면 Supabase 또는 DBHub 추가; 팀이 Linear/Notion을 쓰면 필요에 따라 더합니다. 자세히는 MCP Server 20선 추천을 참고하세요.
ZavCloud Cloud Mac
실제 macOS에서 MCP + Agent 워크플로 통과하기
전용 Mac mini 노드: 로컬 CodeGraph 인덱스, Claude Code 트리플 연결, GitHub Runner CI——한 대의 머신에서 개발·검증·자동화를 완료.
지금 설정 시작하기