MCP 도구 표면을 사내 표준으로 운영하는 아키텍처

프로토콜 표준만으로는 도구 운영이 통일되지 않는다

2026년 컨텍스트 엔지니어링에서 도구 호출 표면은 MCP를 중심으로 정리되고 있다. MCP는 Linux Foundation 산하 Agentic AI Foundation의 거버넌스 아래에서 관리되며, 전송·인증·레지스트리 워킹그룹과 SEP 제안 절차를 통해 사양을 개정한다.

2026-07-28 사양에는 확장 프레임워크와 Enterprise Managed Authorization이 포함됐고, 동적 클라이언트 등록은 클라이언트 메타데이터 문서 방식으로 이동했다. Streamable HTTP 요청은 Mcp-Method, Mcp-Name 헤더를 포함해야 하므로 게이트웨이와 레이트 리미터는 JSON 본문을 파싱하지 않고도 라우팅과 계측을 수행할 수 있다.

외부 생태계도 확장 중이다. 2026년 4분기에는 보안 감사, 사용 통계, SLA를 갖춘 검증 서버 디렉터리인 MCP Registry가 예정돼 있다. .well-known URL에서 서버 메타데이터를 노출하는 MCP Server Cards 제안도 로드맵에 포함돼, 연결 전에 서버 능력을 발견하는 흐름을 뒷받침한다.

하지만 사양이 통일돼도 조직 안의 문제는 남는다. 동일 기능이 팀마다 다른 이름과 인자로 제공되면 에이전트는 서버마다 규칙을 다시 배워야 한다. 도구 이름, 인자 스키마, 오류 응답, 권한 등급, 등록·폐기 절차, 버전 호환성, 감사 로그, 상태 점검을 하나의 운영 표준으로 다뤄야 하는 이유다.

카탈로그에 올리기 전에 고정할 계약

도구 이름은 서버 네임스페이스 안의 고유 식별자이지만, 조직 차원에서는 기능을 식별하는 키로 관리할 필요가 있다. 단순 동사보다 대상 영역과 동작이 함께 드러나는 이름이 낫다. 서버가 늘어날수록 get, update 같은 이름만으로는 선택 대상의 의미가 겹친다.

인자도 마찬가지다. 식별자, 페이지네이션, 기간, 필터처럼 반복되는 인자는 조직 전체에서 이름과 타입을 맞춘다. 필수와 선택을 분명히 나누고 기본값은 스키마에 적는다. 기본값이 문서에만 있으면 에이전트가 매 호출에서 이를 명시하려 할 수 있다.

오류 응답에는 오류 코드, 재시도 가능 여부, 사람이 읽을 메시지, 교정 힌트를 고정 필드로 둔다. 교정 힌트가 응답에 있으면 도구 설명을 길게 늘리지 않아도 에이전트가 복구를 시도할 수 있다. 도구 축의 토큰 예산을 줄이는 방법이기도 하다.

권한은 조회, 변경, 되돌릴 수 없는 행위, 외부 발신의 네 등급으로 분류하고 메타데이터에 기록한다. 이 등급은 승인 게이트와 감사 범위를 결정하므로 도구 등록의 필수 항목이어야 한다.

호환성 정책도 사전에 정한다. 인자 추가는 호환 변경, 인자 제거와 의미 변경은 비호환 변경으로 정의한다. 비호환 변경에는 새 이름을 요구하고, 사양 개정에 따른 전송·인증 변경은 서버 단위 업그레이드 계획으로 관리한다.

등록부터 격리까지 이어지는 운영 경로

등록 요청은 명명 규약, 스키마, 오류 형식, 권한 등급을 검사한 뒤 통과한 도구만 카탈로그에 올리는 흐름으로 만든다. 폐기할 때는 예고 기간과 대체 도구 지정을 요구한다. 예고 없이 사라진 도구는 에이전트 실행 실패가 발생한 뒤에야 드러난다.

감사 로그는 호출 식별자, 도구 이름, 인자, 호출 주체, 등급, 결과, 소요 시간을 고정 형식으로 남긴다. 헤더 기반 라우팅을 적용하면 게이트웨이 계층에서 본문을 파싱하지 않고 계측할 수 있어 감사 수집 비용을 낮출 수 있다.

도구 목록 조회와 대표 호출을 주기적으로 실행하면 서버 가용성과 스키마 변동을 확인할 수 있다. 예고 없이 스키마가 달라진 서버는 카탈로그에서 자동 격리한다. 운영 사고가 발생하기 전에 변화를 드러내는 지점이다.

⤢✕

기존 도구를 표준 체계로 옮기는 순서

표준을 먼저 배포하기보다 팀별 서버와 도구를 전수 조사해 이름, 인자, 등급 후보를 인벤토리로 정리한다. 무엇을 이관해야 하는지 모르는 상태에서는 규약을 적용할 대상도 정할 수 없다.

인벤토리에서는 같은 대상에 같은 동작을 수행하는 도구를 묶고 하나를 정본으로 지정한다. 통합하기 어려운 경우에는 이름에 적용 범위를 드러내 에이전트가 구분할 수 있게 한다.

명명 패턴, 공통 인자, 오류 필드, 등급 정의는 하나의 문서로 배포한다. 해석 차이를 줄이려면 규약만 전달하지 말고 예시 서버도 함께 제공해야 한다.

이관 우선순위는 사용 빈도와 권한 등급이 높은 도구에 둔다. 두 조건은 사고가 발생했을 때 영향이 큰 순서다. 이관 기간에는 기존 이름을 별칭으로 유지하고 종료 시점을 공지한다.

등록 요청 단계에서는 스키마 검사와 대표 호출 시험을 자동으로 실행한다. 사람 리뷰에만 의존하면 도구 수가 늘어난 뒤 병목이 된다. 카탈로그 전체도 주기적으로 재검사해 사양 개정과 스키마 변동을 흡수하고, 미준수 도구는 신규 노출 대상에서 제외한 뒤 담당 팀에 통지한다.

신규 서버 편입, 등급 변경, 외부 발신 도구 승인은 별도 결재 대상으로 둔다. 외부 레지스트리에서 가져오는 서버에는 공급망 심사 절차를 적용한다.

표준 범위는 통제와 속도의 균형 문제다

구분	사내 공통 MCP 표준	팀별 자율 구현
통합 비용	낮음	높음
팀 자율성	제한	높음
선택 정확도	높음	변동
사고 원인 규명	용이	곤란
초기 도입 속도	느림	빠름
재사용성	높음	낮음

사내 공통 표준은 이름과 인자가 예측 가능해 에이전트의 선택 정확도를 높이고, 통일된 오류 형식으로 복구 로직을 한 번만 만들 수 있게 한다. 감사 로그 형식도 같으므로 사고가 발생했을 때 원인 도구를 특정하기 쉽고, 팀별 도구를 조직 자산으로 재사용할 수 있다. 반대로 규약 합의와 이관에는 시간이 들며, 팀의 도메인 특수성이 공통 규격에 담기지 않아 우회 요구가 생길 수 있다.

팀별 자율 구현은 필요한 시점에 바로 도구를 붙일 수 있고 도메인에 맞는 인터페이스를 자유롭게 설계할 수 있다. 다만 같은 기능이 서로 다른 이름과 인자로 중복되고 오류 형식도 달라진다. 복구 로직을 도구별로 만들어야 하며, 호출 기록의 형식이 달라 사고의 인과관계를 추적하기 어렵다. 명명, 오류 형식, 권한 등급만 공통으로 강제하고 나머지를 자율에 맡기는 최소 표준은 두 요구의 접점이 될 수 있다.

중앙 게이트웨이는 인가, 레이트 제한, 감사 수집을 한 지점에서 강제하고 문제 서버를 즉시 차단할 수 있다. 헤더 기반 라우팅은 본문 파싱 없는 계측을 가능하게 하며 자격증명을 에이전트 실행 환경에서 분리한다. 대신 게이트웨이는 단일 장애점이 되고 홉이 하나 늘어나며 스트리밍 응답 처리의 구현 난도가 올라간다.

직접 연결은 지연이 최소이고 게이트웨이 운영 부담이 없으며 서버 고유 기능을 그대로 활용할 수 있다. 그러나 에이전트마다 인가와 감사를 구현해야 하고 자격증명이 실행 환경에 흩어진다. 사고 시 즉시 차단할 수단도 없다. 되돌릴 수 없는 행위와 외부 발신 도구에는 게이트웨이를 강제하고 조회 도구에는 직접 연결을 허용하는 등급별 분리가 통제와 지연을 함께 관리한다.

전량 노출은 필요한 도구가 항상 존재해 작업 실패가 적고, 노출 정책을 유지할 필요가 없어 운영이 단순하다. 새 도구가 추가돼도 별도 조치가 필요 없다. 하지만 도구 정의는 스키마 때문에 토큰 단가가 높아 컨텍스트 예산을 크게 잠식하며, 선택지가 많아질수록 에이전트가 잘못된 도구를 고를 빈도가 올라간다. 높은 권한 등급의 도구도 상시 사정권에 들어온다.

역할별 선별 노출은 선택지를 좁혀 정확도와 토큰 소비를 관리하고, 고위험 도구를 필요한 단계에서만 노출해 공격 표면을 줄인다. 대신 노출 규칙을 관리해야 하며 규칙이 잘못되면 필요한 도구가 없어 작업이 중단된다. 신규 도구의 역할 분류 비용도 계속 발생한다. 조회 도구는 넓게 노출하고 변경과 비가역 도구는 단계별로 좁히는 등급 연동 방식이 실용적이다.

서비스 관리와 변경 관리로 보는 MCP 운영

인자 스키마와 오류 형식의 통일은 이종 서비스 연계에서 인터페이스를 표준화하는 작업이다. 중앙 게이트웨이는 통합 계층에 정책 강제 지점을 두는 구조다.

명명 규약과 버전 호환성 정책은 구성 항목 식별 체계와 변경 분류 기준에 해당한다. 등록·폐기 절차와 준수 점검 주기는 표준 준수 관리 체계를 이룬다.

도구 카탈로그는 서비스 카탈로그 관리의 구조를 따르며, 권한 등급은 서비스 수준 구분에 대응한다. 서버 상태 점검과 자동 격리는 가용성 관리와 변경 관리가 만나는 지점이다.

사양 변화가 조직 운영에 미치는 방향

MCP Registry가 가동되면 외부 서버를 도입할 때 감사 이력과 SLA 확인이 조달 절차에 편입되는 방향으로 갈 수 있다. Server Cards 기반의 능력 발견이 확산되면 연결 없이 도구 인벤토리를 수집하는 방식도 표준화되는 흐름이다.

헤더 기반 라우팅을 전제로 한 게이트웨이 계측은 에이전트 운영 도구의 기본 기능으로 자리 잡는 방향이다. Enterprise Managed Authorization의 채택 역시 사내 MCP 도입에서 필수 요건으로 요구되는 흐름이다.

같은 기능의 도구가 팀마다 다른 이름과 인자로 존재하면 에이전트는 규칙을 반복해 학습해야 하고, 사고가 나도 원인 도구를 특정하기 어렵다. 프로토콜 수준의 표준과 조직 내부 운영 표준은 분리해서 설계해야 한다. 등록 시 규약 준수를 자동 검증하고, 권한 등급을 승인과 감사의 입력으로 쓰며, 스키마 변동을 감지해 격리하는 구성이 운영 체계의 뼈대가 된다. 그 출발점은 현행 도구의 전수 인벤토리다.