AI 에이전트에게 부족한 거버넌스 계층

기업들은 데이터를 관리(govern)하는 법을 배웠습니다. 도구 거버넌스(Tool governance)는 아직 거의 아무도 구축하지 않은 병렬 계층입니다.

지난 10년 동안 기업들은 데이터에 관한 진정한 규율을 구축해 왔습니다. 단순히 데이터를 저장하는 것이 아니라, 이를 관리(governing)하는 것입니다. 무엇이 존재하는지 카탈로그화하고, 소유자가 누구인지 정의하며, 누가 접근할 수 있는지 제어하고, 데이터가 어디서 왔고 어디로 갔는지 증명하는 과정입니다. "누가 이 데이터를 어떻게 사용하고 있으며, 허가된 것인가?"라는 질문은 답할 수 없는 질문에서 일상적인 질문으로 바뀌었습니다.

Model Context Protocol (MCP)은 바로 한 단계 위 계층에서 그 질문을 다시 만들어냈습니다. 그리고 아직 거의 아무도 그 답을 가지고 있지 않습니다.

어시스턴트에서 에이전트로

MCP는 조용하지만 중요한 일을 해냈습니다. 바로 AI 클라이언트를 에이전트(agents)로 전환시킨 것입니다. 이를 통해 Claude, Cursor, Windsurf와 같은 도구들이 실제 시스템에 접근할 수 있게 되었습니다. 데이터베이스를 쿼리하고, 저장소(repositories)를 읽고, 내부 API를 호출하며, 배포 워크플로우(deployment workflows)를 트리거할 수 있습니다. 프로토콜 자체는 깔끔하고 잘 설계되었습니다. 하지만 모든 기업이 결국 막히게 될 지점은 바로 그 주변의 거버넌스(governance)입니다.

MCP는 개인 개발자에게는 아름답게 작동합니다. 하지만 팀이 이를 채택하는 순간 문제가 됩니다.

대부분의 팀 내부에서 벌어지는 현상

현재 조직 내에서의 MCP 도입은 다음과 같은 양상을 띠는 경향이 있습니다:

거버넌스 부재 (Zero governance). 개발자들이 서버를 임시방편(ad hoc)으로 설치합니다. 보안 부서에는 승인된 목록도, 프로세스도 없으며, 어떤 도구가 AI 클라이언트(AI clients)에 연결되어 있는지에 대한 가시성도 없습니다.
공유된 액세스 (Shared access). 팀원들이 동일한 토큰과 설정 파일(config files)을 돌려가며 사용합니다. 역할에 관계없이 모든 사람이 사실상 동일한 액세스 권한을 갖게 됩니다.
로컬 혼돈 (Local chaos). 많은 MCP 서버가 노트북에서 로컬 stdio 프로세스로 실행됩니다. 이들은 중앙에서 모니터링하거나, 공유하거나, 권한을 취소하거나, 감사(audit)할 수 없습니다.
포렌식 불가 (No forensics). 에이전트가 운영 데이터베이스(production database)를 쿼리하거나 워크플로(workflow)를 트리거할 때, 누가, 언제, 허가된 동작이었는지를 재구성할 수 있는 사람이 아무도 없습니다. 여기서 구매자가 겪는 고통은 '발견(discovery)'의 문제가 아닙니다. MCP 서버를 찾을 수 있는 디렉토리는 이미 충분합니다. 진짜 고통은 '안전한 운영화 (safe operationalization)'입니다. 즉, 섀도우 AI 도구(shadow AI tooling), 통제되지 않는 자격 증명(credentials), 추적 불가능한 에이전트 활동을 생성하지 않으면서 MCP를 도입하는 것입니다.

병렬 계층 (The parallel layer)

이 부분은 특히 데이터 또는 AI 거버넌스(governance) 분야에서 일하고 있다면 깊이 고민해 볼 가치가 있습니다.

데이터 거버넌스(Data governance)는 **자산(asset)**에 관한 질문에 답합니다: 이 데이터셋은 무엇인가, 소유자는 누구인가, 민감도는 어느 정도인가, 누가 사용하도록 허용되었는가, 출처는 어디인가.

도구 거버넌스(Tool governance)는 **행위(action)**에 관한 질문에 답해야 합니다: 에이전트가 어떤 도구를 호출했는가, 에이전트가 누구를 대신하여 행동했는가, 해당 호출이 허용되었는가, 그리고 어떤 일이 일어났는가.

이들은 서로 경쟁하는 카테고리가 아닙니다. 이들은 동일한 엔터프라이즈 스택 내의 병렬 계층이며, 플랫폼 엔지니어링(platform engineering), 보안(security), 그리고 새롭게 부상하는 AI 인에이블먼트(AI enablement) 부서라는 동일한 주체에 의해 도입됩니다. 그리고 결정적으로, 각 계층은 상대방이 채워줄 수 있는 사각지대를 가지고 있습니다.

개발자가 AI 클라이언트와 MCP 서버를 사용하여 거버넌스가 적용된 테이블을 쿼리할 때, 데이터 플랫폼은 테이블은 보지만 에이전트의 도구 호출(tool call)은 보지 못합니다. 도구 거버넌스 계층은 도구 호출은 보지만 데이터의 분류(classification)는 보지 못합니다. 이 두 계층이 연결되면, 어느 한쪽만으로는 불가능한 결과물을 만들어냅니다. 즉, 비즈니스 데이터 자산에서부터 이를 건드린 AI 에이전트 호출에 이르기까지의 엔드 투 엔드 리니지(end-to-end lineage)를 생성할 수 있게 됩니다.

간단히 말해, 데이터 거버넌스(data governance)는 자산을 설명합니다. 도구 거버넌스(tool governance)는 에이전트의 동작을 설명합니다.

도구 거버넌스 계층에 실제로 필요한 것

이러한 프레임워크를 수용한다면, 요구사항은 자연스럽게 도출됩니다. 이는 ID 제공자(identity provider)가 애플리케이션에 제공했던 기능들을 AI 도구 호출(tool calls)에 적용한 것과 유사합니다.

팀당 단일 관리 엔드포인트 (A single governed endpoint): AI 클라이언트가 수십 개의 관리되지 않는 서버 대신, 하나의 통제된 접점에 연결되도록 합니다.
구성원별 신원 (Per-member identity): 개별 자격 증명을 통해 모든 도구 호출을 특정 개인에게 귀속시키고 독립적으로 권한을 취소할 수 있습니다.
도구 수준의 허용 목록 (Tool-level allowlists): 각 구성원이 호출할 수 있는 정확한 도구에 대해 최소 권한 제어(least-privilege control)를 적용합니다.
프로토콜 수준의 감사 추적 (A protocol-level audit trail): 누가, 무엇을, 언제, 어떤 결과를 냈는지에 대한 모든 호출에 대한 불변의 운영 기록을 생성합니다.
호스팅 및 관리 가능한 인프라 (Hosted, governable infrastructure): 로컬 stdio 서버를 노트북상의 프로세스가 아닌, 모니터링되고 통제되는 서비스로 실행할 수 있는 방법입니다. 이 중 어느 것도 생소한 것이 아닙니다. 이는 기업들이 이미 다른 곳에서 적용하고 있는 것과 동일한 거버넌스 규율입니다. 다만 AI 도구 사용 자체가 시작된 지 1~2년밖에 되지 않았기 때문에, 아직 AI 도구 사용에는 적용되지 않았을 뿐입니다.

왜 지금인가

이것이 나중이 아닌 지금 중요한 이유는 타이밍 때문입니다. MCP 도입 속도가 내부 보안 프로세스보다 빠르게 진행되고 있습니다. 대부분의 조직이 이 격차를 인지할 때쯤이면, 이미 관리되지 않는 AI 도구 액세스가 여러 팀에 퍼져 있을 것입니다. 거버넌스는 광범위하게 배포된 후에 사후 적용(retrofit)하는 것보다, 배포 전에 도입하는 것이 훨씬 비용이 저렴합니다.

이것이 바로 저희가 mcpnest.io에서 구축하고 있는 계층입니다. 관리되는 MCP 게이트웨이, 구성원별 액세스 제어, 호스팅 인프라, 그리고 AI 도구 사용을 위한 프로토콜 감사 로그를 제공합니다. 전체 논지와 아키텍처, 그리고 이것이 기존의 데이터 및 AI 거버넌스 플랫폼을 어떻게 보완하는지에 대해 알고 싶다면, 기업용 개요(enterprise overview)를 정리해 두었습니다.

mcpnest.io 기업용 개요 읽기 (PDF)

만약 귀하가 플랫폼, 보안 또는 데이터 거버넌스 (Data Governance)를 이끌고 있으며, 조직 내에서 AI 도구 도입이 어떻게 통제되는지에 대해 고민하고 계신다면, 이러한 프레임워크 (Framing)가 어디까지 유효하고 어디서부터 한계가 발생하는지에 대한 귀하의 관점을 듣고 싶습니다.