사내에 이미 좋은 도구는 많다. 배포 스크립트, 이슈 조회 API, 문서 검색, 견적 산출기, 권한 신청 워크플로가 있다. 문제는 AI가 그 도구를 쓰게 만드는 순간, 기존 화면과 버튼 뒤에 숨어 있던 통제가 사라진다는 점이다. MCP 서버는 이 지점에서 단순한 래퍼가 아니다. 내부 도구를 모델이 호출할 수 있는 운영 경계로 다시 포장하는 일이다.
먼저 API 목록을 도구 목록으로 착각하지 말아야 한다
MCP의 서버 기능은 Prompts, Resources, Tools로 나뉜다. 2025-11-25 MCP specification은 Tools를 모델이 행동하거나 정보를 가져오기 위해 호출하는 실행 함수로, Resources를 모델에 문맥을 주는 구조화 데이터로, Prompts를 사용자가 선택하는 템플릿으로 구분한다. 이 구분이 체크리스트의 출발점이다.
내부 API를 전부 Tools로 노출하면 모델은 너무 많은 행동권을 얻는다. 조회성 데이터는 Resource로 두고, 반복 업무 절차는 Prompt로 두고, 상태를 바꾸는 행위만 Tool로 좁힌다.
| 내부 기능 | MCP 노출 방식 | 설계 기준 |
|---|---|---|
| 사규, 매뉴얼, 코드 리포지터리 조회 | Resource | 읽기 전용, 검색·필터 중심 |
| 장애 보고서 초안 작성 | Prompt | 사용자가 명시적으로 실행 |
| 티켓 생성, 배포 요청, 권한 변경 | Tool | 상태 변경, 승인·감사 필수 |
MCP 도입의 첫 결정은 “무엇을 연결할까”가 아니라 “무엇을 모델에게 맡기지 않을까”다.
권한은 서버 안에서 다시 잘라야 한다
기존 내부 도구는 사람이 로그인하고 화면을 보며 버튼을 누르는 전제를 가진다. MCP 서버는 그 전제를 깨뜨린다. 모델은 화면을 보지 않는다. 사용자의 암묵적 판단도 없다. 그래서 MCP 서버는 기존 API 토큰을 그대로 전달하는 프록시가 되면 안 된다.
체크리스트는 네 가지다.
- 도구별 최소 권한 scope를 따로 둔다.
- 사용자 신원, 호출한 모델, 요청 원문, 도구 인자, 결과를 감사 로그로 남긴다.
- 상태 변경 Tool에는 승인 단계나 dry-run을 둔다.
- 토큰은 모델 context, 로그, 에러 메시지에 노출하지 않는다.
MCP authorization specification은 HTTP 기반 transport에서 MCP 서버가 OAuth resource server로 동작하고, access token이 해당 MCP 서버를 대상으로 발급됐는지 검증해야 한다고 정리한다. 2025-11-25 elicitation 문서도 외부 서비스 credential이 MCP client나 LLM context를 지나가지 않도록 URL mode elicitation을 설명한다. 내부 시스템을 감쌀 때도 같은 원칙을 적용한다.
전송 방식은 배포 모델을 결정한다
로컬 자동화 도구라면 stdio가 단순하다. 사용자의 개발 장비나 폐쇄망 작업기에서 클라이언트가 MCP 서버를 subprocess로 띄운다. 반대로 여러 사용자가 공유하고 Claude, ChatGPT, 사내 agent runtime에서 함께 호출해야 한다면 Streamable HTTP가 맞다.
다만 HTTP로 여는 순간 보안 체크리스트가 늘어난다. 2025-06-18 transport specification은 Streamable HTTP 구현 시 Origin header 검증, 로컬 실행 시 localhost 바인딩, 인증 적용을 요구한다. 이 항목은 옵션이 아니라 배포 승인 조건으로 둬야 한다.
운영 기준은 이렇게 자른다.
| 선택 | 맞는 상황 | 승인 조건 |
|---|---|---|
| stdio | 개인 개발, 로컬 파일·CLI 자동화 | 환경 변수 credential, stdout 오염 방지 |
| Streamable HTTP | 팀 공용 도구, 원격 agent 연동 | 인증, Origin 검증, 세션·감사 로그 |
| 사내 gateway 경유 | 핵심 업무 시스템 연결 | allowlist, rate limit, 승인 플로우 |
OpenAI는 2025년 Responses API에서 remote MCP server 지원을 발표했고, Anthropic의 MCP connector 문서도 Messages API에서 원격 MCP 서버를 직접 연결하는 방식을 설명한다. 즉 MCP 서버는 특정 채팅 제품의 플러그인이 아니라 여러 host가 붙는 운영 인터페이스가 되고 있다.
래핑 완료는 배포가 아니라 운영 인수다
MCP 서버를 만들었다고 도입이 끝나지 않는다. AX Ops 관점에서 완료 기준은 코드 merge가 아니라 운영 인수다. 다음 항목이 없으면 아직 PoC다.
- Tool 이름과 설명이 짧고 오해 없이 쓰였는가
- 입력 schema가 필수값, enum, 범위를 강제하는가
- 실패 응답이 모델 재시도에 안전한가
- 상태 변경 Tool에 승인·취소·재시도 정책이 있는가
- 호출 로그로 원인 추적과 권한 감사가 가능한가
특히 Tool 설명은 모델이 읽는 실행 지시문이다. 설명문에 내부 약어, 모호한 동사, 숨은 예외가 많으면 모델은 그 빈틈을 추론으로 메운다. 좋은 MCP 서버는 똑똑한 모델을 전제로 하지 않는다. 제한된 모델이 잘못 불러도 피해가 작게 설계한다.
참고
- Model Context Protocol Specification 2025-11-25, Server Features: https://modelcontextprotocol.io/specification/2025-11-25/server/index
- Model Context Protocol 2025-11-25 Changelog: https://modelcontextprotocol.io/specification/2025-11-25/changelog
- MCP Authorization, protocol revision 2025-06-18: https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
- MCP Transports, protocol revision 2025-06-18: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports
- Anthropic Claude MCP connector documentation: https://platform.claude.com/docs/en/agents-and-tools/mcp-connector
- OpenAI Responses API remote MCP server support, 2025: https://openai.com/index/new-tools-and-features-in-the-responses-api/
얕게 요약하면 이렇다. 내부 도구를 MCP 서버로 감싼다는 것은 API를 노출하는 일이 아니라, 모델이 호출해도 되는 업무 경계를 새로 정의하는 일이다. AX LABS는 이 경계를 전략, 설계, 운영 인수까지 한 사이클로 다룬다. 내부 도구의 MCP 전환을 PoC가 아니라 운영 체계로 만들려면 AX Ops 방법론 →