엔터프라이즈 MCP에서 조회와 액션을 통제하는 설계

Docusign은 2026년 9월 4일, 자사 MCP 서버를 9월 30일부터 모든 AI 에이전트에 개방한다고 발표했다. 계약 인텔리전스와 통제된 액션을 임의의 MCP 클라이언트에서 호출할 수 있게 되면서, 기업 시스템 연동의 초점도 전용 API 프로젝트에서 능력 공개와 통제 설계로 이동하고 있다.

조회 요청은 반복되어도 시스템 상태를 바꾸지 않는다. 반면 계약 확정이나 서명 요청처럼 한 번 실행하면 되돌리기 어려운 액션은 다르다. 호출한 에이전트와 그 권한을 식별하지 못하면 사고가 발생한 뒤 책임을 추적하기도 어렵다.

MCP로 연 업무 기능을 어떻게 다룰 것인가

MCP 서버를 특정 클라이언트가 아닌 모든 MCP 클라이언트에 개방하면 Claude, ChatGPT, Gemini, Copilot, Slack 등에서 같은 능력을 호출할 수 있다. 확장성은 커지지만, 어떤 기능을 누구에게 어느 범위까지 공개할지의 문제가 함께 커진다.

외부 에이전트에 제공할 기능은 개별적으로 선정하고, 기본 상태는 비공개로 두는 편이 낫다. 기존 API를 그대로 MCP 도구로 옮기면 내부 용도의 기능까지 외부에 노출될 수 있다.

통제 체계에는 다음 항목이 함께 필요하다.

상태를 바꾸지 않는 조회와 상태 변경 액션을 분리한다.
최종 사용자 신원을 토큰에 담아 서버가 사람 단위의 호출자를 식별하게 한다.
에이전트 권한을 사용자가 보유한 권한의 부분집합으로 제한한다.
발송, 서명 요청, 계약 확정처럼 취소 불가한 동작에는 사람 확인을 강제한다.
호출자, 클라이언트 종류, 도구 이름, 인자 요약, 결과, 시각, 승인 여부를 남긴다.
사용자별·클라이언트별·도구별 요청량 상한과 급증 억제 규칙을 둔다.
비정상 시간대 호출, 대량 조회 뒤 액션 실행, 권한 경계 반복 시도를 오용 신호로 다룬다.

조회와 실행을 하나의 도구에 섞어 두고 인자에 따라 성격을 바꾸는 방식은 피해야 한다. 통제 수준이 다른 요청을 같은 인터페이스로 처리하면 승인과 감사 기준도 모호해진다.

⤢✕

액션은 서버에서 멈춰야 한다

되돌릴 수 없는 액션은 클라이언트 화면의 안내만으로 통제할 수 없다. 클라이언트 측 확인은 우회될 수 있으므로, 승인 게이트는 서버가 강제해야 한다.

승인 흐름을 설계할 때는 승인 요청의 전달 위치, 대기 시간, 무응답 처리까지 정해야 한다. 승인만 만들고 만료 처리를 두지 않으면 대기 요청이 누적되어 업무가 멈출 수 있다.

모든 능력에 같은 수준의 통제를 적용할 필요는 없다. 되돌림 가능성, 영향 범위, 금전적 결과를 기준으로 위험 등급을 매기고 통제 수준을 연결할 수 있다. 조회까지 승인 대상으로 만들면 실제 사용성이 떨어진다.

금전이나 법적 효력이 걸린 액션만 승인 대상으로 좁히고, 나머지는 자동 실행 뒤 사후 알림을 붙이는 방식은 속도와 안전을 함께 고려하는 선택지가 된다.

호출자를 식별하고 권한을 넘기지 않기

서버 단일 자격으로 모든 호출을 처리하면 구성이 단순하고 클라이언트 제약도 적다. 하지만 모든 호출이 같은 주체로 기록되므로 사고가 발생했을 때 책임을 특정하기 어렵다. 해당 자격이 유출되면 전체 능력이 노출되고, 권한을 세분화할 수도 없다.

반대로 실제 사용자 신원을 전달하면 각 요청은 해당 사용자의 권한 안에서 수행된다. 권한 상승을 막고, 감사 기록에서 호출자를 특정하며, 이상 행위를 사용자 단위로 탐지할 수 있다. 대신 신원 전달과 토큰 교환 구성이 복잡해지고, 클라이언트별 지원 차이와 사용자 권한 변경의 즉시 반영 문제가 생긴다.

단계적으로 도입한다면 단일 자격으로 조회 기능만 열고, 액션을 도입하는 시점에는 신원 연동을 전제 조건으로 둘 수 있다.

감사 기록은 거부된 호출까지 남긴다

계약과 결재 업무는 사후 감사를 전제로 한다. 따라서 성공한 실행만 기록해서는 부족하다. 거부된 요청은 권한 경계를 반복적으로 넘으려는 시도나 오용 징후를 드러내는 핵심 신호가 될 수 있다.

감사 기록 설계에는 규제와 내부 규정이 요구하는 기록 항목 및 보존 기간을 반영해야 한다. 기술 로그만으로 감사 요건을 충족한다고 보기 어려운 경우가 많기 때문이다.

오용 탐지도 실패율만 보는 방식으로는 충분하지 않다. 오용은 정상 권한을 사용한 성공 호출로 이뤄질 수 있다. 평소와 다른 시간대의 호출, 대량 조회 이후의 액션 실행, 권한 경계에 대한 반복 시도를 함께 살펴야 한다.

MCP 개방과 전용 API 통합의 선택

구분	표준 MCP 개방	전용 API 개별 통합
연동 확장성	높음	낮음
통제 세밀도	설계 필요	통합별 조정
도달 범위	모든 클라이언트	계약된 상대
초기 구현	한 번	상대마다 반복
오용 면적	넓음	좁음
변경 파급	큼	작음

표준 MCP 개방은 한 번 구현한 능력을 모든 MCP 클라이언트에서 호출하게 해 파트너별 통합 프로젝트를 줄인다. 신규 클라이언트가 나타나도 별도 연동 작업이 필요 없고, 능력 정의를 한곳에서 관리해 통제를 일관되게 적용할 수 있다. 다만 예상하지 못한 클라이언트와 사용 방식이 유입될 수 있으며, 능력 변경의 영향도 모든 이용자에게 퍼진다.

전용 API 개별 통합은 상대별 범위와 통제를 협의해 위험을 좁게 관리할 수 있다. 계약 관계 안에서 책임도 비교적 명확하고 변경 파급도 제한된다. 대신 상대가 늘 때마다 구현이 반복되고 통합마다 통제 수준이 달라질 수 있으며 신규 클라이언트 대응이 느려진다.

조회 계열은 표준 MCP로 넓게 열고, 고위험 액션은 계약된 클라이언트에만 허용하는 이층 개방은 확장성과 통제 사이의 절충안이 될 수 있다.

운영 기준을 조직 표준으로 만들기

노출 후보는 기능 목록이 아니라 실제 사용 시나리오에서 출발해야 한다. 시나리오 없이 열어 둔 기능은 통제 대상만 늘릴 수 있다.

능력 등급, 신원 연동 방식, 승인 대상, 감사 항목, 요청량 한도 정책은 조직 표준으로 등록할 필요가 있다. 능력별 호출량, 승인 대기 시간, 거부 건수, 오용 경보 처리 결과도 정기 보고 항목으로 편성할 수 있다.

분기마다 실제 호출 통계를 검토해 사용되지 않는 능력을 닫는 절차도 필요하다. 한 번 공개한 기능을 계속 유지하면 활용되지 않는 노출만 남는다.

MCP 확산이 바꾸는 통제 지점

주요 업무 시스템은 전용 통합보다 MCP 서버 개방을 기본 채널로 삼는 방향으로 움직이고 있다. 되돌릴 수 없는 액션에 승인 게이트를 두는 방식도 프로토콜 수준 관행으로 논의되는 흐름이다.

호출자 신원 전달 방식의 표준화는 클라이언트 간 호환을 개선하는 방향으로 이어질 수 있다. 규제 산업에서는 감사 기록 항목 자체가 MCP 도입 조건으로 명시되는 흐름도 예상할 수 있다.

기업 시스템을 에이전트에 연결할 때 핵심은 무엇을 공개하는가만이 아니다. 조회·액션 분리, 신원 확인, 권한 부분집합 매핑, 승인 게이트, 감사 기록, 요청량 제한을 함께 설계해야 한다. 특히 거부된 호출을 남기지 않으면 오용 탐지의 공백은 사고가 발생한 뒤에야 드러난다.