이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 어떤 상황에서 MCP가 유용하고 어떤 상황에서는 과한가?
- 개인 프로젝트에서 MCP를 현실적으로 어떻게 시작할 수 있는가?
- 기업에서 MCP server를 운영하려면 인프라팀과 무엇을 합의해야 하는가?
- 최신 기술인 MCP를 학습할 때 사양되거나 약한 패턴을 어떻게 피하는가?
개요
MCP는 AI 도구 통합의 표준화 흐름에서 중요한 기술이다. 하지만 모든 AI 기능에 MCP가 필요한 것은 아니다. 단순히 서버 내부에서 하나의 API를 호출하는 기능이라면 기존 service call이나 provider function calling만으로 충분할 수 있다.
MCP는 여러 host가 같은 tool을 공유하거나, 사내 도구와 리소스를 표준 방식으로 노출하거나, 로컬 개발 환경과 AI assistant를 연결할 때 특히 유용하다.
도입이 잘 맞는 경우
- IDE나 데스크톱 AI 도구가 사내 문서를 조회해야 한다.
- 여러 AI host가 같은 internal tool catalog를 공유해야 한다.
- 파일 시스템, Git, DB, 이슈 트래커 같은 외부 context를 표준 방식으로 붙이고 싶다.
- 개인 프로젝트에서 로컬 노트, 작업 목록, 스크립트를 AI와 연결하고 싶다.
- 사내 read-only 도구를 먼저 안전하게 노출하고 싶다.
도입이 과한 경우
- 단일 백엔드 서비스 내부에서만 쓰는 작은 함수다.
- tool이 하나뿐이고 provider function calling으로 충분하다.
- 인증/인가와 감사 로그를 준비할 수 없다.
- write tool이 많지만 idempotency와 승인 흐름이 없다.
- 유지보수되지 않는 데모 MCP server를 production에 붙이려 한다.
최신 기술일수록 데모와 운영의 간격이 크다. 공식 SDK와 활발한 repository를 우선 사용하고, 오래된 agent 데모 코드는 깊게 따르지 않는 편이 좋다.
개인 프로젝트 시작법
개인 프로젝트에서는 작게 시작한다.
- 로컬 read-only resource를 하나 노출한다.
- 입력 schema가 있는 search tool을 만든다.
- tool 호출 로그를 남긴다.
- write tool은 실제 실행 대신 draft 생성까지만 한다.
- API key를 환경 변수로 관리한다.
예를 들어 Obsidian 노트를 검색하는 read-only MCP server는 좋은 출발점이다. 반면 파일 삭제, 결제, 메일 발송 같은 write tool은 나중에 confirmation과 idempotency를 붙인 뒤 도입한다.
기업 도입 체크리스트
기업에서는 다음을 합의해야 한다.
- MCP server owner는 누구인가?
- 배포 위치는 어디인가?
- host는 어떤 방식으로 인증하는가?
- 사용자의 권한이 tool 호출에 어떻게 전달되는가?
- tool별 scope와 rate limit은 무엇인가?
- audit log는 어디에 저장하는가?
- tool result에 민감정보가 들어가면 어떻게 마스킹하는가?
- prompt injection 방어는 host와 server 중 어디서 하는가?
- 장애 시 MCP server를 끄면 어떤 기능이 degrade되는가?
인프라팀의 고충 이해
인프라팀은 MCP를 “server가 하나 더 생겼다”로 보지 않는다. 내부 시스템 접근 경로가 늘어난 것으로 본다.
걱정하는 지점은 다음이다.
- server 수가 늘어나며 운영 표면이 커진다.
- tool마다 외부 API와 내부 API outbound가 다르다.
- secret이 여러 server에 분산된다.
- agent가 예측 불가능한 호출 패턴을 만든다.
- audit log와 trace가 고카디널리티 비용을 만든다.
- 장애가 host, MCP server, 내부 API, provider 중 어디서 났는지 추적해야 한다.
백엔드 개발자는 tool catalog, traffic estimate, timeout, retry, rate limit, owner, runbook을 함께 제시해야 인프라팀이 안심할 수 있다.
코드로 이해하기
tool별 설정을 코드나 manifest로 관리하면 인프라와 보안 리뷰가 쉬워진다.
tools:
search_policy:
mode: read_only
owner: platform-ai
required_scope: policy:read
timeout_ms: 1500
max_result_bytes: 12000
audit: true
create_support_ticket:
mode: write
owner: support-platform
required_scope: ticket:write
timeout_ms: 2000
idempotency_required: true
approval_required: false
audit: true이런 manifest는 모델을 위한 것이 아니라 사람과 운영을 위한 계약이다.
장애 상황과 대응
MCP server 장애는 여러 방식으로 보인다.
- host에서 tool 목록을 못 가져온다.
- 특정 tool만 timeout이 증가한다.
- 내부 API 장애가 MCP 장애처럼 보인다.
- 권한 시스템 장애로 모든 tool이 forbidden을 반환한다.
- agent가 tool 실패 후 무한 반복한다.
대응을 위해 server health check, tool별 metric, trace id, circuit breaker, host fallback 메시지가 필요하다.
개인 프로젝트 최소 기준
- 공식 SDK를 사용한다.
- read-only tool부터 시작한다.
- write tool은 confirmation을 둔다.
- tool 호출 로그와 timeout을 둔다.
- README에 tool 권한과 위험을 적는다.
기업 운영 수준 기준
- MCP server catalog를 운영한다.
- tool별 owner, scope, timeout, rate limit, audit 정책을 둔다.
- 보안팀 threat model을 거친다.
- 인프라팀과 배포, secret, observability, runbook을 합의한다.
- host와 server 사이 schema/version 호환성을 관리한다.
실전 팁
- MCP는 “AI가 모든 것을 할 수 있게 하는 문”이 아니라 “AI가 할 수 있는 일을 제한된 계약으로 연결하는 문”으로 본다.
- 처음에는 read-only, 내부 사용자, 낮은 위험 데이터부터 시작한다.
- MCP server가 늘어나면 owner와 lifecycle을 관리한다.
- 유지보수되지 않는 repo나 블로그 예시를 production 기준으로 삼지 않는다.
위험 신호!
- 최신이라서 모든 내부 API를 MCP로 노출하려 한다.
- MCP server에 owner와 runbook이 없다.
- tool별 scope와 rate limit이 없다.
- write tool이 승인과 idempotency 없이 열려 있다.
- 인프라팀이 server 배포 위치와 secret을 모른다.
확인 질문
확인 질문
- MCP 도입이 잘 맞는 상황은 무엇인가?
- 여러 host가 같은 도구와 리소스를 공유하거나, 외부 context를 표준 방식으로 연결해야 할 때다.
- 개인 프로젝트에서 안전한 시작점은 무엇인가?
- read-only resource나 search tool을 공식 SDK로 작게 만드는 것이다.
- 인프라팀이 MCP를 걱정하는 이유는 무엇인가?
- 내부 시스템 접근 경로, secret, 호출 패턴, 로그 비용, 장애 추적 대상이 늘어나기 때문이다.
Spring AI 적용 연결
- Spring AI에서 MCP 도입은 “도구를 붙일 수 있다”보다 운영 ownership, 네트워크 경계, 인증, 감사 로그가 준비됐는지로 판단한다. 판단 기준은 08. MCP Client Server 통합에서 이어진다.
- 고객지원 RAG 같은 실제 서비스 흐름에서 MCP가 어디까지 들어가는지는 13. 고객지원 RAG Capstone을 함께 본다.