MCP 서버를 기능 단위로 분리해야 하는 이유

AI 애플리케이션에서 모델이 외부 기능을 호출하게 만들면, 답변 품질뿐 아니라 실행 권한과 실패 처리도 제품 품질의 일부가 된다. MCP(Model Context Protocol)는 모델 또는 에이전트가 도구와 데이터를 연결하는 인터페이스를 표준화하는 데 유용하지만, 서버를 연결했다고 해서 안전한 운영 구조가 자동으로 만들어지지는 않는다. 특히 데이터 조회, 파일 변경, 배포, 결제처럼 영향 범위가 다른 기능을 하나의 만능 도구로 묶으면 검토와 감사가 어려워진다.

실무에서는 도구를 업무 행위가 아니라 최소 권한의 기능 단위로 나누는 편이 좋다. 예를 들어 주문 조회는 읽기 전용 도구로, 주문 상태 변경은 별도의 쓰기 도구로 제공한다. 사내 문서 검색도 전체 드라이브 접근 대신 허용된 컬렉션과 메타데이터 필터를 명시한다. 모델이 도구 이름과 설명만 보고 선택한다는 점을 고려해, 이름에는 동사와 대상, 설명에는 가능 범위와 금지 범위를 함께 적는다.

입력 스키마는 자연어 요청을 실행 가능한 계약으로 바꾼다

도구 입력을 자유 문자열 하나로 받으면 모델이 불완전한 조건을 전달해도 서버가 추측해서 처리하게 된다. 이는 잘못된 고객, 기간, 환경을 대상으로 작업하는 원인이 된다. 입력은 JSON 스키마로 필요한 필드, 형식, 열거값, 길이와 기본값을 정의하고 서버에서 다시 검증해야 한다. 클라이언트 측 도구 정의는 모델 유도를 위한 안내이며, 최종 방어선은 항상 서버 검증이다.

다음 예시는 주문 상태 변경 도구에서 변경 가능한 상태와 승인 식별자를 제한하는 형태다. 실제 서비스에서는 인증된 사용자 권한, 주문 소유 조직, 변경 전 상태까지 데이터베이스 트랜잭션 안에서 재확인한다.

{
  "name": "update_order_status",
  "description": "승인된 주문의 상태만 변경한다. 취소·환불·금액 변경은 처리하지 않는다.",
  "inputSchema": {
    "type": "object",
    "additionalProperties": false,
    "required": ["orderId", "status", "approvalId"],
    "properties": {
      "orderId": { "type": "string", "pattern": "^ORD-[0-9]{8}$" },
      "status": { "type": "string", "enum": ["PAID", "SHIPPED"] },
      "approvalId": { "type": "string", "minLength": 16, "maxLength": 64 }
    }
  }
}

additionalProperties를 false로 두면 모델이 임의의 플래그를 덧붙여 동작을 바꾸는 것을 막을 수 있다. 다만 스키마 검증만으로 충분하지 않다. orderId가 존재하는지, 해당 테넌트 소유인지, 현재 상태에서 전이가 가능한지, approvalId가 아직 유효한지를 서버에서 검사해야 한다. 오류 응답도 내부 SQL이나 비밀값을 노출하지 말고, 재시도 가능 여부와 수정할 입력 필드만 알려 주는 구조가 안전하다.

읽기·쓰기 권한과 승인 단계를 분리하기

도구는 영향도에 따라 읽기, 제한적 쓰기, 고위험 쓰기로 구분한다. 읽기 도구는 조회 범위와 반환 필드를 최소화하고, 제한적 쓰기는 대상 식별자와 변경 후 값을 명시적으로 받는다. 고위험 쓰기에는 사람이 검토한 승인 토큰, 변경 계획 미리보기, 짧은 만료 시간을 조합한다. “배포해 줘” 같은 자연어 요청이 들어와도 모델이 곧바로 운영 배포 도구를 실행하지 않고, 먼저 계획과 diff를 생성한 뒤 승인된 요청만 실행하도록 설계한다.

권한은 MCP 서버 프로세스의 환경 변수에 광범위한 관리자 키를 넣는 방식보다, 도구별 서비스 계정과 짧은 수명의 자격 증명을 쓰는 방식이 낫다. 개발·스테이징·운영 환경은 서버 URL과 자격 증명을 완전히 분리하고, 운영 쓰기 도구는 별도 등록으로 관리한다. 테스트용 서버 설정이 운영 연결 정보를 참조하지 않도록 배포 파이프라인에서도 확인해야 한다.

감사 로그와 재현 가능한 실패 처리를 준비하기

운영 로그에는 요청 시각, 호출 주체, 도구 이름, 대상 리소스, 결과 코드, 승인 ID, 추적 ID를 남긴다. 고객 개인정보, 접근 토큰, 프롬프트 전문은 기본 로그에 넣지 않고 필요 시 마스킹하거나 별도 보안 저장소로 분리한다. 같은 요청을 재시도할 때 중복 변경이 생기지 않도록 idempotency key를 받거나, 요청 ID와 상태 전이를 함께 기록한다.

2026-07-25T12:15:02+09:00 tool=update_order_status
actor=user:1842 tenant=acme target=ORD-20260725
requested_status=SHIPPED approval=apr_7f3c...
trace_id=tr_01J... result=success idempotency_key=idem_8a1...

장애가 났을 때는 모델에게 무조건 재시도를 맡기지 않는다. 네트워크 시간 초과, 검증 실패, 권한 거부, 동시성 충돌을 구분해 반환하고, 재시도 가능한 오류에만 제한된 횟수와 지수 백오프를 적용한다. 쓰기 작업은 서버가 처리 결과를 조회할 수 있는 작업 ID를 반환하면, 모델이 추측으로 같은 명령을 다시 보내는 일을 줄일 수 있다.

배포 전 체크리스트

  • 각 도구가 읽기 또는 쓰기 중 하나의 명확한 목적만 갖는지 확인한다.
  • 입력 스키마에 필수값, 허용값, 추가 필드 차단이 정의되어 있는지 점검한다.
  • 서버가 인증, 테넌트 소유권, 상태 전이, 승인 만료를 독립적으로 검증하는지 확인한다.
  • 운영 쓰기 도구에 사람 승인과 최소 권한 자격 증명이 적용되는지 확인한다.
  • 비밀값을 제외한 감사 로그와 중복 실행 방지 장치가 준비되어 있는지 확인한다.

MCP 도입의 핵심은 모델에 더 많은 권한을 주는 것이 아니라, 필요한 작업을 검증 가능한 계약으로 바꾸는 데 있다. 작은 읽기 도구부터 시작해 호출 기록과 실패 유형을 관찰하고, 승인·권한·재시도 정책을 갖춘 뒤 쓰기 작업 범위를 넓히는 것이 안정적인 운영 순서다.