AX LABS
← 블로그 AX Ops 방법론

MCP 래핑은 통제가 먼저다

도구 연결보다 권한 경계가 설계의 출발점이다

AX LABS 6분 읽기

현장에서 MCP 이야기가 나오면 첫 질문은 대개 비슷하다. “우리 내부 API를 MCP 서버로 래핑하면 에이전트가 바로 쓸 수 있지 않나.” 기술적으로는 맞다. 운영적으로는 틀리다. MCP 서버는 단순 어댑터가 아니라 AI가 내부 시스템을 호출하는 실행 경계다.

MCP 공식 specification의 최신 문서는 2025-11-25 버전이다. 여기서 서버는 Resources, Prompts, Tools를 제공하고, 클라이언트는 Sampling, Roots, Elicitation 같은 기능을 제공한다. 즉 MCP는 “도구 호출 규격”에 그치지 않는다. 내부 데이터, 사용자 입력, 실행 권한이 한 세션 안에서 만나는 운영 인터페이스다.

먼저 래핑할 도구를 줄여야 한다

MCP 도입의 첫 실패는 “가능한 도구를 모두 노출”하는 데서 시작한다. 내부 검색, 결재 조회, 티켓 생성, 배포 트리거, 고객 정보 조회를 한 서버에 묶으면 편해 보인다. 실제로는 권한 검토와 사고 추적이 어려워진다.

래핑 대상은 업무 흐름 기준으로 자른다. API 목록이 아니라 사용자 의도 기준으로 묶는다.

점검 항목 잘못된 출발점 AX Ops 기준
도구 범위 있는 API 전부 노출 한 업무 흐름에 필요한 최소 도구
실행 권한 시스템 계정 공유 사용자별 권한 위임
출력 데이터 API 응답 그대로 반환 모델이 봐도 되는 필드만 반환
승인 방식 호출 후 로그 확인 호출 전 위험도별 승인

내부 도구를 MCP로 감쌀 때 첫 산출물은 코드가 아니다. “도구 카탈로그”다. 각 tool에 대해 읽기 전용인지, 변경 작업인지, 외부 전송이 있는지, 되돌릴 수 있는지 표시해야 한다. 이 분류가 없으면 나중에 모든 통제가 예외 처리로 밀린다.

MCP 서버 설계의 핵심은 연결성이 아니라 실행 권한의 최소화다.

원격 MCP는 인증과 감사가 붙어야 한다

로컬 stdio 방식은 실험에 빠르다. 그러나 조직 도입의 기본값으로 두면 관리되지 않는 Shadow MCP가 생긴다. 누가 어떤 서버를 설치했는지, 어떤 토큰이 흘렀는지, 어떤 내부 API가 호출됐는지 보기 어렵다.

운영형 MCP는 원격 서버와 중앙 거버넌스를 기본으로 잡는다. Cloudflare의 2026년 MCP 문서는 원격 MCP 서버에서 인증, 권한 범위, tool별 접근 제어, 실행 로그를 관리하는 패턴을 제시한다. OpenAI도 Responses API에서 remote MCP server 연결을 지원한다고 공식 발표했다. 이제 MCP는 특정 클라이언트의 플러그인이 아니라 여러 에이전트 런타임이 공유하는 접속면이다.

체크리스트는 단순하다.

  1. 사용자 인증은 SSO와 연결한다.
  2. MCP scope는 내부 RBAC와 매핑한다.
  3. tool 실행 로그에는 user, tool, input hash, output class, 승인 여부를 남긴다.
  4. 변경·삭제·외부전송 tool은 HITL 승인을 둔다.
  5. 서버 버전과 tool manifest 변경은 배포 승인 대상으로 둔다.

이 다섯 가지가 없으면 PoC는 가능해도 운영은 불가능하다.

보안 검토는 프롬프트가 아니라 경계에서 한다

MCP 공식 specification은 MCP가 데이터 접근과 코드 실행 경로를 열기 때문에 동의, 프라이버시, tool safety를 명시적으로 다뤄야 한다고 적고 있다. 이 문장은 과장이 아니다. 에이전트는 tool 설명, 파라미터, 응답을 모두 문맥으로 읽는다. 악성 설명이나 오염된 응답은 실행 판단에 영향을 준다.

따라서 보안 검토를 “프롬프트를 잘 쓰면 된다”로 끝내면 안 된다. 서버 경계에서 막아야 한다.

  • 입력 검증: tool schema에 맞지 않는 인자는 거부한다.
  • 출력 정제: 비밀값, 토큰, 과도한 개인정보는 반환하지 않는다.
  • 권한 축소: MCP 서버가 내부 관리자 토큰을 대신 들고 있지 않게 한다.
  • 실행 격리: 파일, 셸, 네트워크 접근 tool은 별도 샌드박스에서 실행한다.
  • 변경 감지: tool 설명과 schema 변경을 보안 리뷰 대상으로 둔다.

특히 Elicitation은 사용자에게 추가 정보를 요청하는 강력한 기능이다. 2025-11-25 specification은 비밀번호, API key, access token 같은 민감 정보는 form mode로 요청하지 말고 URL mode를 사용하라고 규정한다. 내부 업무용 MCP도 같은 원칙을 따라야 한다.

체크리스트가 운영 리듬이 된다

MCP 서버 하나를 잘 만드는 것보다 중요한 일은 MCP 서버가 늘어날 때도 같은 기준으로 운영되는 것이다. AX Ops에서는 MCP 도입을 네 단계로 끊는다.

단계 산출물 통과 기준
후보 선정 도구 카탈로그 업무 흐름별 최소 tool 정의
래핑 설계 tool schema와 권한표 사용자 권한과 scope 매핑
운영 검증 로그·승인·실패 처리 재현 가능한 감사 추적
확산 관리 registry와 배포 정책 승인된 서버만 사용

MCP는 이미 Anthropic이 2025년 12월 Agentic AI Foundation에 기부하며 중립 표준으로 이동했다. 표준이 안정될수록 내부 도구 래핑 수요는 늘어난다. 그때 필요한 것은 더 많은 서버가 아니라 같은 방식으로 검토되고 운영되는 서버다.

얕은 결론은 이렇다. MCP 도입은 “내부 API를 AI에 붙이는 일”이 아니다. 내부 실행 권한을 에이전트 시대에 맞게 다시 포장하는 일이다. 처음부터 도구 카탈로그, 권한 경계, 감사 로그, 승인 흐름을 같이 설계해야 한다. AX LABS는 이 구간을 AX Ops로 묶어 도입과 운영을 한 사이클로 다룬다. AX Ops 방법론 →

참고