MCP 시대의 진짜 병목은 모델이 아니라 권한이다
AI 에이전트가 도구를 더 잘 쓰게 만들수록, 문제는 모델 성능보다 권한 설계로 이동한다. MCP 기반 툴 호출을 안전하게 운영하는 최소 권한 구조를 정리합니다.
MCP 시대의 진짜 병목은 모델이 아니라 권한이다
한 줄 결론부터 말하면 이렇다. 에이전트가 똑똑해질수록, 성패는 모델이 아니라 권한 설계에서 갈린다.
MCP가 유행하면서 많은 팀이 먼저 보는 건 "어떤 툴을 붙일까"다. 하지만 실무에서 더 중요한 질문은 따로 있다.
- 이 에이전트가 무엇을 할 수 있어야 하는가
- 그 행동을 언제, 어떤 조건에서 허용할 것인가
- 실패했을 때 누가, 어떻게 감지하고 되돌릴 것인가
이 세 가지를 못 잡으면, 도구를 많이 붙일수록 시스템은 더 편리해지는 게 아니라 더 위험해진다.
왜 지금 권한이 핵심인가
MCP는 에이전트가 외부 시스템과 대화하는 표준 인터페이스를 제공한다. 문제는 표준이 생겼다는 사실 자체가 아니다. 표준화된 도구 호출이 생기면, 도구 접근 통제가 더 중요해진다는 점이다.
예전에는 LLM이 텍스트만 생성하면 됐다. 이제는:
- GitHub에 이슈를 만들고
- 배포 상태를 조회하고
- 사내 문서를 읽고
- 결제를 트리거하거나
- 운영 작업을 실행할 수 있다
즉, 에이전트는 더 이상 "답변하는 모델"이 아니라 행동하는 사용자에 가까워진다.
사용자가 행동할 수 있다면, 당연히 권한 모델이 필요하다.
흔한 실패 패턴
1) 모든 도구를 한 번에 열어버리는 경우
가장 흔한 실수다. "어차피 내부용이니까"라는 이유로 툴을 통째로 열어두면, 에이전트는 빠르게 편해지지만 운영자는 나중에 통제력을 잃는다.
문제는 악의적인 프롬프트만이 아니다. 훨씬 흔한 건:
- 잘못된 맥락에서의 과도한 실행
- 유사한 이름의 리소스를 잘못 건드림
- 예상보다 큰 범위의 변경
- 반복 실행으로 인한 비용 폭발
2) 모델 신뢰도에만 기대는 경우
"좋은 모델이면 알아서 안전하게 하겠지"는 운영 원칙이 아니다. 모델이 실수하지 않는다는 가정은 유지되지 않는다.
권한은 모델의 지능이 아니라 시스템의 경계에서 설계해야 한다.
3) 승인 단계를 사람 한 명에게 몰아주는 경우
모든 중요한 작업을 수동 승인으로 막아두면 안전해 보이지만, 실제로는 병목이 된다.
좋은 구조는 사람을 매번 세우는 게 아니라:
- 위험도에 따라 자동 실행 / 확인 필요 / 거부로 나누고
- 민감한 작업만 좁게 승인하게 만들며
- 나머지는 정책으로 처리하는 것이다.
내가 권하는 기본 구조
나는 AI 툴 권한을 아래 4층으로 나누는 편이 낫다고 본다.
1) Read-only
조회 전용.
예:
- 문서 검색
- 상태 조회
- 로그 확인
- 일정 확인
이 레벨은 에이전트가 가장 먼저 가져야 하는 기본권이다.
2) Scoped write
범위가 제한된 쓰기.
예:
- 특정 저장소의 브랜치 생성
- 특정 프로젝트의 이슈 작성
- 특정 채널에만 메시지 전송
여기서는 "쓰기 가능"이 아니라 어디에 쓸 수 있는가가 핵심이다.
3) Conditional action
조건부 실행.
예:
- 배포는 staging만 자동, production은 승인 필요
- 비용이 일정 임계치를 넘으면 중단
- 외부 전송은 특정 키워드/대상만 허용
이 레벨에서 정책 엔진의 가치가 나온다.
4) Break-glass
예외적 고위험 작업.
예:
- 권한 상승
- 대규모 삭제
- 결제/송금
- 운영 중단 가능성이 있는 액션
이건 기본 흐름에 넣지 말고, 별도 감사 경로로 분리해야 한다.
실무에서 가장 효과적인 제어 지점
MCP 기반 에이전트 시스템에서는 보통 아래 위치에서 통제가 먹힌다.
툴 등록 시점
툴 자체를 노출할지 말지 결정한다. 가장 강한 필터다.
호출 전 정책 검사
프롬프트와 컨텍스트를 보고 허용 여부를 판단한다.
파라미터 검증
리소스 이름, 환경, 대상 조직, 금액, 파일 경로 같은 값을 강하게 제한한다.
실행 후 감사 로그
누가 무엇을 왜 실행했는지 남긴다. 나중에 문제를 잡을 수 있는 유일한 방법이다.
추천 아키텍처
내가 추천하는 기본형은 이렇다.
LLM → Planner → Policy Check → Tool Adapter → Audit Log
여기서 중요한 점은 LLM이 바로 툴을 때리지 않게 하는 것이다.
- Planner는 "무엇을 할지"만 정한다
- Policy Check는 "해도 되는지"를 판정한다
- Tool Adapter는 "어떻게 실행할지"만 맡는다
- Audit Log는 모든 흔적을 남긴다
이 분리가 있으면 모델 교체가 쉬워지고, 위험도 통제된다.
팀이 실제로 해야 할 일
권한 설계는 문서로 끝나지 않는다. 최소한 아래는 있어야 한다.
- 도구별 위험 등급
- 환경별 권한 분리(dev / staging / prod)
- 사용자/에이전트별 허용 범위
- 승인 필요 작업 목록
- 감사 로그 보존 정책
- 툴 실패 시 롤백 절차
이 정도가 없으면 MCP 도입은 "기능 추가"가 아니라 "위험 면적 확대"가 된다.
내가 보는 결론
MCP는 유행이 아니라 방향이다. 에이전트는 점점 더 많은 툴을 만질 것이고, 그러면 권한은 선택이 아니라 구조가 된다.
그래서 순서는 항상 같다.
- 도구를 많이 붙이지 말고
- 최소 권한부터 설계하고
- 고위험 작업을 분리하고
- 감사 가능하게 만들 것
에이전트 성능을 올리는 가장 현실적인 방법은 더 강한 모델이 아니라 더 좁은 권한이다.
참고 링크
이 글은 공개 문서와 최근 MCP/에이전트 도입 흐름을 바탕으로 쓴 의견입니다. 각 제품의 권한 모델과 API 동작은 빠르게 바뀔 수 있으니, 실제 적용 전 최신 문서를 확인하세요.