MCP 도구 연결에서 먼저 정해야 할 것

MCP(Model Context Protocol)는 AI 모델이 데이터 조회, 사내 시스템 호출, 파일 처리 같은 외부 도구를 사용할 수 있게 만드는 연결 방식이다. 그러나 모델이 자연어를 해석해 도구 호출을 결정한다는 특성 때문에, 일반 API 연동보다 권한과 입력 경계를 더 명확하게 설계해야 한다. 특히 고객 정보, 주문 정보, 서버 운영 기능을 하나의 도구 서버에 섞어 두면 프롬프트 오염이나 잘못된 요청 한 번이 넓은 권한으로 이어질 수 있다.

실무에서는 모델이 무엇을 할 수 있는가보다 모델이 요청해도 무엇을 할 수 없는가를 먼저 정의한다. 조회와 변경을 분리하고, 사용자별 권한을 서버에서 다시 검증하며, 외부 입력을 실행 명령으로 바로 전달하지 않는 구조가 기본이다. 도구 설명문에 주의 문구를 적는 것만으로는 보호가 되지 않는다. 최종 통제는 MCP 서버와 연결 대상 시스템이 맡아야 한다.

도구를 작은 권한 단위로 나누기

처음에는 범용 도구 하나에 action 파라미터를 두고 모든 기능을 넣기 쉽다. 하지만 삭제 기능까지 한 인터페이스에 섞이면 허용 범위 검토와 로그 분석이 어려워진다. 업무 단위와 위험도에 따라 도구를 나누고, 읽기 전용 도구는 읽기 전용 자격 증명으로 연결하는 편이 안전하다.

  • search_customer_orders: 고객 주문을 제한된 필드로 조회
  • create_support_ticket: 문의 티켓 생성과 필수 항목 검증
  • request_refund_approval: 환불을 직접 실행하지 않고 승인 요청만 생성
  • run_report: 미리 등록한 보고서 식별자만 실행

결제 취소, 계정 삭제, 배포처럼 되돌리기 어려운 기능은 모델이 직접 실행하는 도구로 만들지 않는 것이 좋다. 승인 대기 레코드를 생성한 뒤 담당자가 검토하거나, 별도 워크플로에서 다단계 인증을 요구하도록 설계한다.

입력값은 스키마와 서버 규칙으로 이중 검증

도구 입력 스키마는 모델이 올바른 형식의 값을 만들도록 돕지만 보안 경계는 아니다. 서버는 형식 검증 뒤에도 권한, 소유권, 범위, 허용 목록을 검사해야 한다. 예를 들어 주문 조회의 customerId가 문자열인지 확인한 다음, 현재 사용자가 그 고객 정보를 볼 권한이 있는지 판정해야 한다. 날짜 범위와 조회 건수도 제한해 대량 반출을 막는다.

const inputSchema = z.object({ customerId: z.string().uuid(), limit: z.number().int().min(1).max(100).default(20) }); async function searchOrders(input, actor) { const v = inputSchema.parse(input); if (!actor.permissions.includes("orders:read")) throw new Error("권한이 없습니다."); if (!(await canAccessCustomer(actor.id, v.customerId))) throw new Error("접근이 허용되지 않았습니다."); return db.query("SELECT id, status, total_amount FROM orders WHERE customer_id = $1 LIMIT $2", [v.customerId, v.limit]); }

SQL은 반드시 바인딩 파라미터를 사용하고, 모델이 만든 SQL이나 셸 명령을 그대로 실행해서는 안 된다. 검색 조건, 정렬 기준, 보고서 종류처럼 선택지가 정해진 항목은 문자열 자유 입력 대신 enum 또는 서버 허용 목록으로 제한한다. 파일을 다루는 도구도 사용자가 준 경로를 그대로 열지 말고, 허용된 작업 디렉터리 아래인지 정규화한 뒤 확인해야 한다.

사용자 정체성과 권한을 모델 밖에서 전달하기

모델 대화에 나는 관리자라는 문장이 들어왔다고 관리자 권한을 부여하면 안 된다. 로그인 세션 또는 서비스 토큰에서 확인한 사용자 ID, 조직 ID, 역할을 MCP 서버 요청 컨텍스트로 전달하고, 각 도구에서 이를 기준으로 인가한다. 멀티 테넌트 서비스라면 모델 입력으로 받은 tenantId를 신뢰하지 말고, 인증된 컨텍스트의 tenantId를 쿼리 조건에 강제해야 한다.

서비스 계정도 최소 권한 원칙을 적용한다. 개발·스테이징·운영 환경의 키를 분리하고, 읽기 전용 조회 도구에는 쓰기 권한 데이터베이스 계정을 연결하지 않는다. 비밀값은 환경 변수나 비밀 관리 시스템에서 주입하며, 도구 응답과 오류 메시지에 토큰·연결 문자열·내부 경로가 노출되지 않게 마스킹한다. 운영 시스템 도구에는 만료 시간이 짧은 토큰과 대상 서비스별 권한을 부여하는 것이 좋다.

감사 로그와 승인 흐름을 운영에 포함하기

도구 호출 로그에는 요청 시각, 인증 주체, 도구명, 허용 또는 거부 결과, 대상 리소스 식별자, 처리 시간, 상관관계 ID를 남긴다. 민감한 본문 전체나 비밀번호는 기록하지 않는다. 로그를 통해 예상보다 많은 조회, 반복 실패, 평소와 다른 변경 요청을 탐지할 수 있다. 오류를 사용자에게 반환할 때는 내부 예외 대신 처리 가능한 메시지를 제공하고, 상세 원인은 운영 로그에서만 확인한다.

{ "event": "mcp_tool_call", "requestId": "req_8f31", "actorId": "user_42", "tool": "search_customer_orders", "result": "allowed", "resourceCount": 12, "durationMs": 84 }

변경 작업에는 금액, 대상 수, 영향 범위를 사람이 읽을 수 있는 형태로 재확인하는 단계가 필요하다. 예를 들어 환불 승인 요청 세 건 생성은 가능하지만 환불 실행은 승인자와 사유를 별도로 받아야 한다. 운영 초기에는 모든 변경성 도구를 승인 모드로 두고 실제 사용 패턴을 확인한 뒤 제한적으로 자동화를 늘리는 편이 좋다. 도구 정의가 바뀌면 권한 매트릭스와 감사 대시보드도 함께 검토한다.

배포 전 체크리스트

  • 도구별로 조회·변경·관리 권한이 분리되어 있는가
  • 입력 스키마 외에 서버 측 인가와 범위 제한을 수행하는가
  • 모델 입력이 아닌 인증된 사용자·조직 컨텍스트를 인가에 사용하는가
  • 명령, SQL, URL, 파일 경로에 허용 목록과 안전한 파라미터 처리를 적용했는가
  • 민감 정보를 제외한 감사 로그와 변경 승인 흐름이 준비되어 있는가

MCP는 도구 연결을 간단하게 만들지만, 신뢰 경계를 대신 설계해 주지는 않는다. 작고 명확한 도구, 최소 권한, 서버 측 검증, 추적 가능한 로그를 기본값으로 두면 AI 기능을 업무 시스템에 안전하게 확장할 수 있다.