에이전트 거버넌스가 아키텍처다: MCP 시대의 진짜 제어면
MCP가 툴 연결을 표준화했다면, 프로덕션 AI 에이전트를 안전하게 만드는 건 권한, 정책, 감사, 격리다.
에이전트 거버넌스가 아키텍처다: MCP 시대의 진짜 제어면
MCP가 뜨고 나서 많은 팀이 같은 착각을 한다. 툴만 연결되면 에이전트 시스템이 완성된다고 보는 것이다. 하지만 프로덕션에서 진짜 중요한 건 연결이 아니라 누가 무엇을 할 수 있는가다.
요약하면 이렇다.
- MCP는 인터페이스다.
- 거버넌스는 운영 아키텍처다.
2026년 4월 초 Microsoft는 Agent Governance Toolkit을 공개했고, Cerbos는 MCP permissions를 정리했다. 메시지는 분명하다. 이제 질문은 “에이전트가 무엇을 할 수 있나?”가 아니라 **“어떤 조건에서, 어떤 범위로, 어떤 기록을 남기며 할 수 있나?”**로 바뀌었다.
핵심 결론
- 에이전트 권한은 모델 성능 문제가 아니라 시스템 설계 문제다.
- 가장 위험한 실패는 reasoning 오류보다 과도한 권한과 기록 없는 실행이다.
- 실전에서는 least privilege, explicit approval, audit log, sandbox가 기본값이어야 한다.
- MCP는 도구 연결을 쉽게 만들지만, 정책 계층이 없으면 안전도 운영도 보장하지 않는다.
1) MCP가 해결하는 것
MCP는 에이전트와 외부 시스템 사이의 통신을 표준화한다. 덕분에 툴 등록, 호출, 응답 흐름이 훨씬 깔끔해진다.
이건 분명한 진전이다. 하지만 진전의 범위는 여기까지다.
MCP가 잘하는 것:
- 툴을 일관된 방식으로 노출한다
- 모델과 시스템 사이의 연결 비용을 낮춘다
- 여러 도구를 같은 방식으로 다루게 해준다
MCP가 못하는 것:
- 권한 경계를 자동으로 설계해주지 않는다
- 위험한 행동을 스스로 막아주지 않는다
- 감사와 추적성을 대신 제공하지 않는다
- 승인 상태를 영구적으로 관리해주지 않는다
즉, MCP는 배선이고, 아키텍처는 제어판이다.
2) 에이전트에서 가장 먼저 터지는 건 권한이다
실제로 사고는 대부분 “모델이 멍청해서”가 아니라 “모델이 너무 많은 일을 할 수 있어서” 난다.
자주 보이는 실패 패턴은 이렇다.
- 읽기만 되어야 할 에이전트가 삭제 권한까지 가진다
- 사용자 대신 행동하는데도 사용자 권한을 넘어서 실행한다
- 한 번 승인된 작업이 재시도 과정에서 중복 실행된다
- 누가 어떤 툴을 썼는지 나중에 재구성할 수 없다
이 문제는 모델을 더 크게 만든다고 해결되지 않는다. 권한 모델이 없으면, 더 똑똑한 에이전트는 그냥 더 빨리 더 크게 실패할 뿐이다.
3) 프로덕션용 에이전트에는 정책 계층이 필요하다
Microsoft의 Agent Governance Toolkit이 흥미로운 이유는 여기 있다. 이 도구가 보여주는 건 “새로운 에이전트 프레임워크”가 아니라 에이전트 위에 얹는 통제면이다.
실전 구조는 대체로 이렇게 간다.
- Identity: 이 에이전트는 누구를 대표하는가?
- Policy: 무엇을 허용하고 무엇을 막을 것인가?
- Interception: 툴 호출 직전에 검사할 수 있는가?
- Approval: 위험한 행동은 사람이 승인하는가?
- Audit: 나중에 누가 봐도 재현 가능한 로그가 남는가?
- Isolation: 위험한 작업은 샌드박스에서만 도는가?
이 중 하나라도 빠지면 운영 난도가 급격히 올라간다.
내 기준에서 우선순위는 이렇다.
- 1순위: 최소 권한
- 2순위: 승인 단계
- 3순위: 감사 로그
- 4순위: 격리 실행
- 5순위: 세밀한 관측성
반대로 말하면, 이 다섯 개가 없는데 에이전트를 “자율적”이라고 부르는 건 거의 마케팅에 가깝다.
4) MCP permissions는 보안 기능이 아니라 설계 원칙이다
Cerbos가 강조하는 포인트도 같다. 에이전트가 사용자 대신 행동한다면, 사용자가 원래 가질 수 있는 권한의 축소판으로만 움직여야 한다.
여기서 중요한 건 “권한 제어를 붙일 수 있느냐”가 아니다. 이미 붙일 수 있다. 진짜 질문은 권한을 시스템의 기본 원칙으로 삼고 있느냐다.
좋은 설계는 다음 조건을 만족한다.
- 툴마다 read/write/admin을 분리한다
- 파괴적 작업은 별도 승인 흐름을 탄다
- 정책은 코드와 설정으로 버전 관리된다
- 운영 중인 에이전트도 정책 변경에 즉시 반응한다
- 실패 시 기본값은 always deny다
이 정도가 되어야 “에이전트가 안전하게 일한다”는 말을 할 수 있다.
5) 개발팀이 지금 당장 할 수 있는 것
거창한 플랫폼이 없어도 시작할 수 있다.
- 에이전트별로 허용 툴 목록을 명시한다
- 파괴적 툴은 별도 승인 함수 뒤에 둔다
- 모든 툴 호출에 correlation id를 붙인다
- 결과를 저장하되, 모델 입력은 요약본만 쓴다
- 재시도는 idempotent하게 설계한다
- 운영자용 대시보드에 승인/실행/실패를 한 화면에 모은다
이걸 해두면 에이전트가 “똑똑해져서”가 아니라 다루기 쉬워져서 신뢰할 수 있게 된다.
결론
MCP는 에이전트의 연결 문제를 크게 줄였다. 하지만 프로덕션에서 더 중요한 문제는 여전히 남아 있다.
- 누가 실행할 수 있는가
- 무엇을 실행할 수 있는가
- 어떤 조건에서 허용되는가
- 어떻게 기록되고 감사되는가
그래서 내 결론은 단순하다.
MCP는 시작점이고, 거버넌스가 아키텍처다.
에이전트를 진짜 운영하려면 모델보다 먼저 권한, 정책, 감사, 격리를 설계해야 한다.