'에이전트가 툴을 호출할 수 있다'는 사실을 확인한 팀이 다음으로 마주치는 질문은 다르다. 어떤 툴을 허용해야 하는가, 누가 승인했는가, 문제가 생겼을 때 어떻게 차단하는가. dev.to에 올라온 분석 글 "MCP Is Everywhere Now. The Next Problem Is Governance."는 이 전환을 정확하게 짚는다. MCP는 개발자 편의 레이어에서 기업 통제 레이어로 이동하고 있다.
문제의 본질은 'API 거버넌스와 무엇이 다른가'에 있다. 일반 API는 결정론적 앱이 호출한다. MCP 툴은 모델이 동적으로 판단해서 호출한다. 툴 설명 자체가 런타임 인터페이스의 일부가 되고, 안전한 툴 하나가 다른 툴과 체이닝되는 순간 위험해질 수 있다. API 키와 로그만으로는 부족하다. 에이전트의 의도를 추적할 수 있는 레이어가 필요하다.
같은 맥락에서 arXiv에 발표된 "How are AI agents used? Evidence from 177,000 MCP tools" 연구도 주목할 만하다. MCP 툴 증식 속도는 이미 팀이 수동으로 검토할 수 있는 범위를 넘어서고 있다. 툴 하나를 추가하는 비용이 낮아질수록 툴 스프롤(tool sprawl)은 과거의 의존성 스프롤과 같은 방식으로 누적된다. 잘 정의된 툴 5개를 가진 에이전트는 관리 가능하다. 느슨하게 정의된 툴 50개를 가진 에이전트는 언어 모델이 중간에 낀 권한 퍼즐이 된다.
1단계: 툴 매니페스트—사람이 검토할 수 있는 문서화
첫 번째 단계는 조용하지만 가장 먼저 해야 할 작업이다. 모든 MCP 툴에 명세서를 붙이는 것. 툴 설명(description)이 유일한 문서라면 이미 문서화가 부족한 상태다. 매니페스트에는 최소한 다섯 가지가 들어가야 한다: 툴의 목적, 권한 수준, 데이터 분류, 사이드이펙트 리스크, 소유자. 여기에 안전한 사용 예시와 위험한 사용 예시를 함께 붙이면 온보딩 비용도 함께 줄어든다.
실용적으로 보면 이 작업은 코드보다 스펙 문서 작업에 가깝다. 팀에서 AI를 활용해 기존 툴 설명을 바탕으로 매니페스트 초안을 생성하고, 시니어 엔지니어나 보안 담당자가 검토하는 방식이 현실적이다. 완벽한 매니페스트보다 검토 가능한 매니페스트가 먼저다.
2단계: 런타임 감사—호출 다음에 무엇이 일어났는가
두 번째 단계는 로깅 설계다. 엔드포인트 호출 로그만으로는 부족하다. 에이전트 ID, 사용자 ID, 툴 이름, 입력 페이로드 형태, 출력 크기와 분류, 상위 태스크—여기까지는 대부분 팀이 생각한다. 핵심은 그다음이다. 툴 호출 이후 에이전트가 취한 다음 행동을 함께 기록해야 한다.
이유는 단순하다. 툴 호출 하나의 가치는 에이전트가 그 결과를 읽고 무엇을 했는지를 봐야 이해된다. "파일을 읽었다"는 로그는 무해하다. 하지만 "파일을 읽고 외부 API에 데이터를 전송했다"는 연속된 행동은 다른 의미를 갖는다. 2026 에이전틱 AI 트렌드 분석에서도 강조되듯, 에이전트 관찰성은 선택 사항이 아니라 핵심 인프라가 되고 있다. 관찰성 없이는 모든 에이전트 장애가 미스터리로 남는다.
3단계: 스코프 번들과 킬스위치—사전 설계가 전부다
세 번째 단계가 가장 지루하고 가장 중요하다. 모든 에이전트에 모든 툴을 주지 않는 것. 툴 번들을 역할별로 정의해야 한다. support-readonly, support-actionable, code-review-readonly, incident-response, finance-readonly, browser-sandboxed처럼 목적과 권한 범위를 명시한 번들 단위로 에이전트에게 접근권을 부여하는 구조다. 지루하다. 지루한 게 맞다. 여기서 지루함은 덕목이다.
그리고 킬스위치. 특정 툴 하나, 특정 MCP 서버 하나, 특정 사용자-에이전트 페어링, 특정 사이드이펙트 클래스 전체를 비활성화할 수 있는 방법이 사전에 준비되어 있어야 한다. 사고가 터진 후 킬스위치를 찾는 팀은 이미 늦다. 이것은 아키텍처 설계 단계에서 결정해야 할 문제지 운영 단계에서 임시방편으로 처리할 문제가 아니다.
Claude Code 워크플로우와의 연결점
실무 레벨에서 이 거버넌스 설계는 Claude Code를 활용하는 팀에게 특히 직접적이다. "The Terminal Stack That Fixed My Claude Code Workflow"에서 소개된 tmux 기반 멀티세션 워크플로우—프로젝트별 독립 세션에 Claude Code, 파일 탐색, git 리뷰를 각각 분리하는 구조—는 사실 거버넌스 설계와 같은 원리다. 컨텍스트를 분리하고, 각 세션의 역할을 명확히 하고, 세션 간 충돌을 원천 차단한다.
Claude Code가 여러 프로젝트를 동시에 다루는 환경에서 어떤 세션이 어떤 MCP 툴에 접근 가능한지를 명확히 구분하지 않으면 툴 스프롤과 권한 혼재가 발생한다. 터미널 스택 설계와 MCP 거버넌스 설계는 결국 같은 질문으로 수렴한다: 이 에이전트는 지금 무엇을 할 수 있고, 무엇을 해서는 안 되는가.
팀 리빌딩 관점의 시사점
10 Agentic AI Trends 분석이 지적한 것처럼, 다음 에이전트 제품 경쟁은 더 좋은 모델이 아니라 더 나은 컨트롤 플레인에서 결정된다. MCP를 안전하고, 관찰 가능하고, 취소 가능하고, 이해 가능하게 만드는 팀이 실제 프로덕션 배포에서 앞선다. "에이전트가 우리 툴을 쓸 수 있다"는 것과 "우리는 에이전트를 받아들일 준비가 됐다"는 것은 전혀 다른 말이다.
AI-First 팀 리빌딩을 실제로 진행 중이라면 MCP 거버넌스 설계는 기술 스택 선택이 아니라 팀 운영 원칙의 문제다. 누가 툴 매니페스트를 소유하는가, 런타임 감사 로그를 누가 검토하는가, 킬스위치 권한은 누구에게 있는가—이 세 질문에 답이 없는 팀은 사실상 거버넌스가 없는 팀이다. 에이전트 도입 이전에 이 설계를 완료하는 것이 이상적이지만, 이미 배포했다면 지금 당장 시작해야 한다.