AX LABS
← 블로그 에이전트 제품 설계

MCP 서버는 API 포장이 아니다

에이전트 권한 경계부터 다시 설계해야 한다

AX LABS 6분 읽기

현장에서 MCP 이야기가 나오면 첫 반응은 비슷하다. “우리 내부 API를 MCP로 감싸면 되겠네요.” 절반만 맞다. 연결은 된다. 하지만 에이전트가 그 도구를 언제, 왜, 누구 권한으로, 어디까지 호출할지 정하지 않으면 MCP 서버는 곧바로 운영 리스크가 된다.

사내 도구를 에이전트에 붙이는 일은 API 문서를 하나 더 만드는 일이 아니다. 사람 대신 행동하는 실행면을 여는 일이다.

MCP 서버는 에이전트의 권한 경계다

MCP 공식 사양은 서버가 세 가지 프리미티브를 제공한다고 정리한다. Prompts, Resources, Tools다. 이 구분이 설계의 출발점이다. Prompts는 사용자가 고르는 절차, Resources는 클라이언트가 붙이는 맥락, Tools는 모델이 호출하는 실행 함수다.

그래서 사내 MCP 서버의 핵심 질문은 “무엇을 연결할까”가 아니다. “무엇을 모델에게 직접 맡길까”다.

구분 사내 설계 질문 잘못된 설계
Resources 읽기 전용 맥락으로 충분한가 조회 API를 전부 Tool로 노출
Tools 모델이 실행해도 되는 행위인가 승인·변경·삭제를 한 도구에 혼합
Prompts 반복 업무 절차를 고정할 필요가 있는가 사용자 지시를 매번 자유문으로 방치

MCP 서버는 에이전트에 붙이는 플러그인이 아니라, 모델이 조직 안에서 행사할 수 있는 권한의 외곽선이다.

이 선을 먼저 그어야 한다. 조회, 검토, 초안 작성, 등록, 변경, 삭제를 같은 수준으로 취급하면 안 된다.

Tool은 작게 쪼개고 이름은 업무 언어로 써야 한다

MCP Tool 설계에서 가장 흔한 실패는 내부 API 구조를 그대로 노출하는 것이다. updateRecord, executeQuery, callWorkflow 같은 이름은 개발자에게 익숙하지만 에이전트에게는 위험하다. 너무 넓고, 의도가 흐리고, 실패했을 때 복구하기 어렵다.

사내 도구는 업무 행위 단위로 잘라야 한다.

  • search_contract_by_vendor: 협력사명으로 계약 검색
  • draft_purchase_request: 구매요청 초안 생성
  • submit_purchase_request_for_approval: 승인 라인으로 제출
  • cancel_draft_request: 초안 상태 요청 취소

이름에 대상, 조건, 결과가 보여야 한다. 입력 스키마도 좁아야 한다. 자유 텍스트 하나로 모든 것을 받는 도구는 빠르게 편해 보이지만 감사와 재현을 망친다.

OpenAI는 2025년 Responses API에 remote MCP server 지원을 추가했고, MCP 서버를 몇 줄 설정으로 모델 도구에 연결할 수 있다고 밝혔다. 연결 난이도는 내려갔다. 그래서 설계 난이도는 올라갔다. 붙이기 쉬운 도구일수록 더 엄격하게 잘라야 한다.

원격 MCP는 인증보다 위임 설계가 먼저다

원격 MCP 서버를 만들 때 OAuth를 붙였다고 안전해지는 것은 아니다. MCP 2025-11-25 Authorization 사양은 MCP 서버를 OAuth 2.1 Resource Server로 다루고 Protected Resource Metadata를 요구한다. 이 방향은 맞다. 하지만 기업 내부에서는 한 단계가 더 필요하다. 사용자의 로그인 권한과 에이전트의 실행 권한을 분리해야 한다.

Cloudflare의 2026년 Remote MCP 가이드는 Streamable HTTP를 현재 MCP 사양의 표준 전송 방식으로 설명하고, 인증 없는 서버와 인증·인가가 있는 서버를 구분한다. 또한 stateful 도구와 stateless 도구를 분리해 접근하라고 제시한다. 이 구분은 사내 설계에도 그대로 적용된다.

권한 설계는 최소한 네 층으로 나눈다.

  1. 사용자 신원: SSO, 계정, 조직, 직무
  2. 도구 권한: 호출 가능한 Tool 목록
  3. 행위 범위: 조회, 초안, 제출, 변경, 삭제
  4. 실행 정책: 자동 실행, 확인 후 실행, 차단

Anthropic의 관리형 MCP 문서도 원격 MCP 서버를 조직 단위로 배포하고, 도구별 정책을 allow, ask, blocked로 잠글 수 있게 설명한다. 이 방식이 엔터프라이즈 운영의 기본값이다. 모든 도구를 “허용”으로 시작하면 나중에 회수하기 어렵다.

AX Ops는 MCP를 운영 단위로 만든다

MCP 서버 개발의 산출물은 코드 저장소가 아니다. 운영 가능한 도구 카탈로그다. AX Ops에서는 MCP 서버를 다음 순서로 설계한다.

첫째, 업무 행위를 나눈다. 사람이 실제로 하는 승인, 조회, 비교, 등록, 회수 단위를 기준으로 자른다.

둘째, Tool별 실행 정책을 붙인다. 자동 실행할 도구와 사람 확인이 필요한 도구를 분리한다.

셋째, 호출 로그를 업무 이벤트로 남긴다. “API 호출 성공”이 아니라 “누가 어떤 근거로 어떤 업무 행위를 위임했는가”가 남아야 한다.

넷째, 실패 경로를 설계한다. 권한 부족, 입력 불충분, 중복 요청, 외부 시스템 장애를 에이전트가 구분해 사용자에게 돌려줘야 한다.

2026년 MCP 로드맵도 transport 확장성, agent communication, governance, enterprise readiness를 우선 영역으로 둔다. 방향은 분명하다. MCP는 개인 개발자 도구에서 기업 운영 인프라로 이동하고 있다.

작게 열고 단단하게 넓혀라

처음부터 전사 시스템을 붙이지 말아야 한다. 읽기 전용 Resource와 낮은 위험의 초안 생성 Tool부터 시작한다. 그다음 승인 요청, 등록, 변경처럼 업무 책임이 생기는 행위를 단계적으로 연다.

좋은 MCP 서버는 에이전트를 똑똑하게 보이게 만드는 서버가 아니다. 에이전트가 조직 안에서 사고 없이 일하게 만드는 서버다. 사내 도구를 에이전트에 붙일 계획이라면 API 목록이 아니라 권한 경계표부터 작성해야 한다. AX LABS는 이 경계표를 실제 운영 설계로 바꾸는 일을 한다. AX Ops 방법론 →

참고