- 들어가며
- MCP를 도입할 때 먼저 정해야 할 것
- Transport 선택: stdio와 Streamable HTTP
- Tool 설계 원칙
- 토큰 예산과 컨텍스트 낭비 줄이기
- 인증과 권한 모델
- 관찰 가능성과 운영 체크리스트
- 안티패턴
- 마무리
- References
들어가며
Model Context Protocol, 줄여서 MCP는 에이전트 애플리케이션이 외부 시스템과 상호작용하는 방식을 표준화하려는 시도입니다. 실제 운영 관점에서 중요한 질문은 프로토콜 자체보다도 다음에 가깝습니다.
- 어디까지를 하나의 MCP 서버로 묶을 것인가
- tool과 resource를 어떻게 나눌 것인가
- stdio와 HTTP 중 무엇을 선택할 것인가
- 모델이 너무 많은 도구 설명과 결과를 읽어 토큰을 낭비하지 않게 하려면 어떻게 설계할 것인가
- 누가 어떤 tool을 호출했는지 어떻게 감사할 것인가
이 글은 MCP 공식 문서를 기준으로, 프로덕션 환경에서 바로 부딪히는 설계와 운영 문제를 정리합니다.
MCP를 도입할 때 먼저 정해야 할 것
MCP는 강력하지만, 무턱대고 모든 내부 시스템을 하나의 서버에 연결하면 곧 운영 부채가 됩니다. 시작 전에 다음 원칙을 명확히 두는 것이 좋습니다.
1. 서버 경계는 도메인 기준으로 나눈다
가장 흔한 실패는 "우리 회사 도구를 전부 하나의 MCP 서버에 넣자"는 접근입니다. 이렇게 되면 다음 문제가 생깁니다.
- 도구 설명이 과도하게 길어져 모델 컨텍스트를 잡아먹음
- 권한 경계가 흐려짐
- 장애 격리가 어려워짐
- 버전 관리가 거대 저장소 단위로 고정됨
더 나은 방법은 업무 도메인이나 보안 경계 기준으로 나누는 것입니다.
| 서버 경계 예시 | 포함 기능 | 분리 이유 |
|---|---|---|
github-governance | PR 조회, 체크 상태, ruleset 정보 | 개발 워크플로와 권한 모델이 명확함 |
incident-ops | 알림 조회, 런북 링크, 장애 타임라인 | 운영 데이터와 감사 로그 요구가 다름 |
docs-search | 문서 검색, 문서 요약용 리소스 | 읽기 전용 성격이 강함 |
2. Tool과 Resource를 구분한다
공식 문서 기준으로 tool은 호출 시 부작용이 있거나 계산이 필요한 액션에 가깝고, resource는 읽기 가능한 문맥을 제공하는 데 적합합니다.
tool- 승인, 배포, 이슈 생성, 실행 상태 조회처럼 함수 호출에 가까운 기능
resource- 정책 문서, 런북, 아키텍처 노트, 서비스 인벤토리처럼 읽기 문맥에 가까운 정보
이 구분이 중요한 이유는 모델의 행동 패턴이 달라지기 때문입니다. 읽기 문맥을 모두 tool로 만들면 모델이 불필요한 호출을 반복하고, 반대로 액션을 resource처럼 포장하면 거버넌스와 감사가 어려워집니다.
Transport 선택: stdio와 Streamable HTTP
MCP 공식 문서에서 가장 먼저 마주치는 선택 중 하나가 transport입니다.
stdio가 잘 맞는 경우
- 로컬 개발 도구와 데스크톱 클라이언트
- 단일 사용자 맥락
- 프로세스 생명주기를 클라이언트가 직접 관리해도 되는 경우
장점:
- 구현이 단순함
- 로컬 보안 경계 안에서 빠르게 시작 가능
- 배포보다는 통합 테스트에 유리함
주의점:
- 서버 프로세스 수명 주기가 클라이언트에 종속됨
- 중앙 감사와 멀티테넌시 운영이 어렵다
Streamable HTTP가 잘 맞는 경우
- 여러 클라이언트가 같은 서버를 호출하는 플랫폼 환경
- 중앙 인증, 로깅, rate limit, 네트워크 정책이 필요한 경우
- 조직 단위 운영과 배포 자동화가 필요한 경우
장점:
- 운영 표준을 붙이기 쉽다
- API gateway, service mesh, ingress 정책과 자연스럽게 결합된다
- 클라이언트 다양성이 높아도 확장하기 쉽다
주의점:
- 인증과 세션 경계 설계를 더 명확히 해야 함
- 잘못 설계하면 "그냥 또 하나의 HTTP 래퍼"가 되기 쉽다
Tool 설계 원칙
이름은 모델이 추론하기 쉽게, 범위는 좁게
나쁜 예시는 너무 일반적인 이름입니다.
run_action
manage_item
operate_system
좋은 예시는 입력과 효과가 예상 가능한 이름입니다.
list_pull_requests
get_ruleset_status
create_incident_note
이름이 모호하면 모델은 더 많은 추론을 해야 하고, 잘못된 tool 선택 확률도 높아집니다.
입력 스키마는 짧고 엄격하게
입력 필드가 많을수록 모델 실수 가능성도 올라갑니다. 실무에서는 다음 규칙이 유용합니다.
- 필수 필드는 최대한 적게 유지
- enum으로 제한 가능한 값은 자유 텍스트로 두지 않기
- 설명 텍스트는 짧고 행동 지향적으로 작성
- 사람이 읽는 식별자와 내부 식별자를 혼합하지 않기
Tool 결과는 "큰 덩어리"보다 "다음 행동"에 맞게
모델은 긴 JSON 덤프보다, 다음 행동을 고르는 데 필요한 구조화된 결과를 더 잘 씁니다.
좋은 결과 예시:
{
"repository": "platform/api",
"ruleset_status": "blocking",
"missing_checks": ["lint", "integration-test"],
"next_actions": [
"wait_for_required_checks",
"request_codeowner_review"
]
}
운영 경험상, tool 결과에 다음 행동 후보를 넣어두면 모델이 불필요한 반복 호출을 줄이는 데 도움이 됩니다.
토큰 예산과 컨텍스트 낭비 줄이기
GeekNews에서 화제가 된 MCP optimizer류 도구가 보여주듯, 실제 병목은 종종 모델 품질이 아니라 컨텍스트 낭비입니다.
흔한 낭비 패턴
- tool 설명이 길고 중복됨
- resource 본문을 매번 전체 반환함
- 사용하지 않는 필드까지 모두 결과에 포함함
- 하나의 서버가 너무 많은 tool을 노출함
운영 원칙
- tool 설명은 짧게 유지한다.
- resource는 전체 문서보다 요약 가능한 단위로 쪼갠다.
- 결과는 기본 요약과 필요 시 상세 조회의 2단계로 나눈다.
- 로그와 추적 데이터를 통해 실제 호출 빈도가 낮은 tool을 정리한다.
예를 들어 런북 시스템이라면 처음부터 전체 markdown을 돌려주지 말고, 제목, 담당 팀, 마지막 수정일, 핵심 단계만 우선 반환하는 편이 더 낫습니다.
인증과 권한 모델
MCP 서버가 조직 시스템에 연결되는 순간, 핵심 문제는 편의성이 아니라 권한 경계입니다.
꼭 정해야 할 질문
- 호출 주체는 사용자 대리인가, 시스템 계정인가
- 읽기 전용과 쓰기 가능 tool이 섞여 있는가
- 민감한 리소스 접근은 별도 서버로 분리할 것인가
- 감사 로그에 어떤 최소 필드를 남길 것인가
추천 운영 패턴
- 읽기 전용 서버와 변경형 서버를 분리한다
- 쓰기 가능한 tool은 idempotency와 승인 단계를 명확히 둔다
- 호출 로그에 사용자, 세션, tool 이름, 입력 요약, 결과 상태를 남긴다
- 실패 원인도 사람이 검토 가능한 형태로 기록한다
관찰 가능성과 운영 체크리스트
MCP 서버를 운영 시스템으로 취급한다면, 최소한 다음은 모니터링해야 합니다.
| 영역 | 봐야 할 지표 | 이유 |
|---|---|---|
| 가용성 | 요청 성공률, 응답 시간 | 모델이 tool 호출을 포기하는 원인을 빠르게 찾기 위해 |
| 품질 | tool 호출 후 재시도 비율 | 도구 설명이나 입력 스키마가 모호한지 확인 가능 |
| 비용 | 평균 응답 크기, 토큰 사용량 추정 | 과도한 문맥 전달을 줄이기 위해 |
| 보안 | 거부된 호출, 권한 오류, 비정상 호출 패턴 | 정책 위반과 오남용을 탐지하기 위해 |
운영 전 체크리스트
- 서버 경계가 도메인과 권한 기준으로 분리되어 있는가
- tool 이름과 스키마가 좁고 명확한가
- resource가 과도하게 큰 payload를 반환하지 않는가
- 감사 로그가 충분한가
- 실패 시 fallback 동작이 정의되어 있는가
- transport 선택 이유가 문서화되어 있는가
안티패턴
"우리 내부 API를 전부 MCP로 감싸면 된다"
이 접근은 거의 항상 실패합니다. MCP는 단순 프록시 계층이 아니라, 모델이 이해하고 선택할 수 있는 인터페이스 설계가 핵심입니다.
"도구가 많을수록 똑똑해진다"
반대로 도구 수가 많아질수록 선택 오류와 토큰 낭비가 늘어납니다. 좋은 MCP는 도구 수보다 경계와 명명 규칙이 좋습니다.
"로컬에서 되니까 운영도 된다"
stdio 기반 로컬 통합이 잘 동작해도, 중앙 인증과 멀티클라이언트 환경으로 넘어가면 다른 문제들이 나타납니다. 운영 환경에서는 transport, rate limit, 감사, 배포 전략을 별도로 다뤄야 합니다.
마무리
MCP를 잘 도입한 팀은 "모델이 더 똑똑해졌다"기보다 "모델이 안전하게 활용할 수 있는 인터페이스를 설계했다"는 쪽에 가깝습니다. 결국 성패를 가르는 것은 프로토콜보다도 서버 경계, tool 스키마, transport 선택, 권한 모델, 그리고 토큰 예산 운영입니다.
작게 시작하되, 다음 두 가지는 처음부터 잘 잡는 편이 좋습니다.
- 도메인 기준 서버 분리
- 짧고 명확한 tool과 resource 인터페이스
이 두 가지를 지키면 이후 인증, 관찰 가능성, 비용 최적화도 훨씬 쉬워집니다.