먼저 고백하겠습니다. 저는 검증되지 않은 MCP 서버를 모든 도구 허용 상태로 설치하여, AI가 '어느샌가' 사내 파일을 읽게 만들고 있었습니다.

계기는 확정 신고였습니다. freee의 MCP 서버를 Claude Desktop에 연결했을 때, 저는 도구 목록을 제대로 살펴보지 않았습니다. 그저 작동하기만 하면 된다고 생각했습니다.

나중에 로그를 추적하고 나서 피가 식는 기분이었습니다. AI는 제가 요청하지 않은 도구를 몇 번이나 호출하고 있었습니다. 경비 등록을 요청했을 뿐인데, 계정 과목 마스터나 거래처 목록까지 건드리고 있었습니다. 실질적인 피해는 없었습니다. 다만 '접근했다'는 사실이 남았습니다.

정확히 말하면, 저는 무언가를 허가했다는 기억조차 없었습니다. 서버를 연결한 시점에 270개의 도구가 전부 활성화되어 있었습니다. 허가란 '명시적으로 허락하는 것'이라고 생각했는데, 현실은 정반대였습니다. 연결 = 전체 허용. 기본값이 전체 개방이었던 것입니다.

이때 깨달았습니다. 저는 AI의 행동 범위를 한 번도 살펴보지 않았습니다. 보지 않은 것은 제한할 방법이 없습니다.

권한을 제한하는 것은 제약이 아니라 가시화다

보통 권한을 제한한다고 하면 '답답해진다'고 느낍니다. 할 수 있는 일이 줄어든다. AI의 자유를 빼앗는다. 그런 이미지입니다.

하지만 실제로 제한해 보니 정반대라는 것을 깨달았습니다.

권한을 제한한다는 것은 AI가 접근할 수 있는 범위를 목록화하는 작업입니다. 270개의 도구를 '이것과 이것만'이라고 다시 선택하는 것입니다. 그때 비로소 AI가 무엇에 손을 뻗을 수 있는지가 눈에 보입니다.

제한하기 전에는 범위가 무한했습니다. 그래서 보이지 않았습니다. 제한하는 순간, 윤곽이 나타났습니다.

이것이 본 기사의 핵심입니다. 스코프 최소화 (Scope Minimization)는 방어책이기 이전에 관측의 수단입니다. MCP의 위협 10가지를 나열한 이야기는 이 기사에서 다루었습니다. 본 기사는 그 한 걸음 앞, 구체적인 권한 설계에 대해 이야기합니다.

전체 도구 허용이 일으키는 조용한 월권

freee의 MCP 서버는 270개의 도구를 공개하고 있습니다. 회계뿐만 아니라 HR, 청구서, 근태 관리까지 포함됩니다.

확정 신고에 필요한 것은 기껏해야 10개 정도입니다. 나머지 260개는 제 용도와 무관했습니다. 그럼에도 전부 활성화되어 있었습니다.

문제는 두 가지입니다.

하나는 토큰 비용 (Token Cost)입니다. 270개의 도구 정의를 읽는 것만으로 약 17,500 토큰을 소비합니다. 사용하지 않는 도구의 설명문에도 비용이 청구되는 것입니다.

또 다른 하나는 월권입니다. 도구가 활성화되어 있는 한, AI는 언제든 그것을 호출할 수 있습니다. 제가 지시하지 않아도 AI가 '이 편이 빠르다'고 판단하면 손을 뻗습니다. LLM은 지나치게 친절합니다.

OWASP는 이를 **스코프 크립 (Scope Creep)**이라고 명명합니다. 모호하게 부여한 권한이 시간이 흐름에 따라 확장되어, 에이전트가 과도한 능력을 갖게 되는 상태입니다. 일시적으로 허용한 줄 알았던 권한이 어느샌가 상설화되어 있는 것입니다.

저의 경우, 월권은 실질적 피해 없이 끝났습니다. 운이 좋았을 뿐입니다. 검증되지 않은 서버를 안이하게 설치하는 위험성은 별도 기사에 작성했습니다.

왜 AI는 요청하지 않은 도구를 호출할까요? 심술을 부리는 것이 아닙니다. LLM은 목표를 달성하려고 노력합니다. '경비를 등록해 줘'라는 말을 들으면, 등록에 필요해 보이는 정보를 먼저 수집하려 합니다. 계정 과목을 확인하고 거래처를 대조합니다. 인간의 유능한 신입 사원이 하는 일과 같습니다.

차이점은, 신입 사원이라면 '여기까지 봐도 될까요?'라고 묻는 부분을 AI는 묵묵히 본다는 점입니다. 확인하는 문화가 없는 것이 아니라, 확인해야 할 경계를 이쪽에서 알려주지 않은 것입니다. 경계를 부여하는 유일한 방법이 바로 권한 스코프 (Permission Scope)였습니다.

스코프 설계의 기본은 read와 write의 분리

그렇다면 어떻게 제한할까요? 출발점은 심플합니다. 읽기 도구와 쓰기 도구를 나누는 것입니다.

2026년 MCP 권한 설계의 베스트 프랙티스 (Best Practice)는 거의 모든 전문가가 이 점을 지적합니다. 읽기와 쓰기를 섞은 채로 권한을 부여하지 말라고 말입니다.

이유는 명확합니다. 읽기는 되돌릴 수 있습니다. 하지만 쓰기와 삭제는 되돌릴 수 없습니다. 리스크의 비대칭성이 존재하는데, 이를 동일하게 취급하는 것은 잘못된 것입니다.

Cerbos의 정리에서는 저위험 행동과 고위험 행동을 나누고, 쓰기 권한을 넓히기 전에 read-write 서버 분리를 완료하라고 권고합니다. 읽을 수 있는 AI와 쓸 수 있는 AI를 별도의 컨텍스트 (Context)에 두는 발상입니다.

여기서 한 가지 실감한 것이 있습니다. read/write의 분리는 AI의 능력을 3단계로 색깔을 나누는 작업처럼 보이지만, 실제로는 자신의 업무를 정리하는 과정이었습니다.

freee를 예로 들면, 계정 과목 조회는 read-only, 거래 생성은 write, 회사 설정 변경은 본래 deny. 이 세 단계로 생각하는 것만으로도 AI가 접근할 수 있는 범위가 확연히 좁혀집니다.

흥미로운 점은, 이러한 분류를 진행하다 보면 "나 자신도 무엇에 AI를 사용하고 싶은지 모호했다"는 사실이 드러난다는 것입니다. 저는 막연하게 "회계를 자동화하고 싶다"고 생각했습니다. 하지만 도구를 하나씩 read(읽기), write(쓰기), deny(거부)로 분류해 보니, 정말로 맡기고 싶은 것은 거래 등록뿐이라는 것을 알게 되었습니다. 나머지는 제가 직접 확인하고 싶은 작업이었습니다.

권한 설계는 AI에 대한 불신에서 시작되는 작업처럼 보이지만, 실제로는 자신의 의도를 언어화하는 작업이었습니다.

도구 유형 × 스코프(Scope) 매트릭스로 설계하기

머릿속으로 "이것은 읽기, 저것은 쓰기"라고 생각해도 빠지는 부분이 생깁니다. 저도 빠졌습니다. 그래서 표로 만들었습니다.

도구의 유형을 세로축에, 허용할 권한 스코프(Scope)를 가로축에 나열합니다. 각 셀에 "허용"인지 "거부"인지를 기입합니다. 이것만으로도 설계의 빈틈이 보입니다.

제가 사용하는 분류 기준은 다음과 같습니다.

포인트는 scoped-write입니다. 쓰기를 전면 금지하면 자동화의 의미가 사라집니다. 그래서 "어디에 쓸 수 있는지"를 좁히는 것입니다. freee라면 "거래 생성만 허용하고, 회사 설정은 건드리지 못하게 한다"는 식입니다.

여기서 허용 리스트(Allowlist) 방식이 효과를 발휘합니다. 명시적으로 허용한 것만 통과시키고, 그 외에는 전부 차단합니다. 사전에 등록하는 수고는 들지만, 운영 중의 추가 비용은 제로입니다.

허용 리스트와 거부 리스트(Denylist)는 비슷해 보이지만 전혀 다릅니다. 거부 리스트는 "위험한 것을 차례로 막는" 방식이라 새로운 위험이 나타날 때마다 추가해야 합니다. 막는 것을 잊은 것은 통과되어 버립니다. 허용 리스트는 반대로, 모르는 것은 전부 멈춥니다. 미지의 도구가 늘어나더라도, 이쪽에서 허용하지 않는 한 도달할 수 없습니다.

MCP는 도구가 나중에 추가되는 세상입니다. 서버를 업데이트했더니 새로운 도구가 10개 늘어나 있는 일이 흔히 발생합니다. 그렇기에 도구가 늘어나도 멋대로 활성화되지 않는 허용 리스트 방식이 적합합니다. 저는 처음에 반대로 하여, 늘어난 도구를 인지하지 못한 채 전면 허용을 유지했었습니다. 실패를 통해 배운 설계입니다.

위험한 도구는 격리한다

매트릭스에서 가장 상단에 두어야 할 것은 격리입니다.

쉘 실행, 파일 시스템에 대한 직접 액세스, 외부로의 데이터 전송. 이런 종류의 도구는 read/write 분리만으로는 부족합니다. 별도의 장소에 가두어야 합니다.

2026년의 도구 포이즈닝(Tool Poisoning) 대책에서 반복적으로 언급되는 것이 바로 이것입니다. MintMCP는 고권한 도구를 외부 MCP 서버가 닿지 않는 별도의 에이전트 컨텍스트(Context)에서 동작시키라고 정리하고 있습니다.

왜 격리가 필요할까요? MCP에는 **크로스 서버 컨텍스트 악용(Cross-server context exploitation)**이라는 문제가 있기 때문입니다.

세션에 여러 MCP 서버가 연결되어 있으면, 한쪽이 침해되었을 때 다른 쪽의 도구를 호출할 수 있게 됩니다. 일기예보 도구가 파일 전송 도구를 실행하는 식의 연쇄 반응이 일어납니다.

도구의 설명문에 숨겨진 지시를 심어두는 공격도 같은 뿌리입니다. AI는 그 지시를 "사용자의 지시"와 구분할 수 없습니다. 집에 들어온 도둑의 메모를, 얹혀사는 사람이 순순히 실행해 버리는 것과 같습니다. 따라서 위험한 도구는 처음부터 손이 닿지 않는 곳에 두어야 합니다.

그리고 마지막 보루는 인간의 승인입니다. 한 조사에 따르면, AI가 도구 호출을 자동 승인할 경우 공격 성공률이 84.2%였던 반면, 인간이 승인을 거치면 5% 미만으로 떨어진다고 보고되었습니다. 삭제나 외부 전송에는 반드시 인간의 원클릭을 거치게 할 가치가 있습니다.

여기서 중요한 것은 승인을 어디에서 거치느냐입니다. LLM의 컨텍스트 안에서 "실행해도 될까요?"라고 묻는 것은 의미가 없습니다. 숨겨진 지시는 그 확인 절차조차 탈취할 수 있기 때문입니다. 승인은 LLM의 외부, 즉 인간이 직접 보는 UI에서 이루어져야 합니다. Claude Code와 같은 도구가 위험한 조작 전에 화면으로 사용자에게 확인을 요청하는 것이 바로 이 이유입니다.

정리하자면, 방어는 계층(Layer)으로 이루어져 있습니다. read/write 분리로 되돌릴 수 없는 조작을 좁히고, 허용 리스트로 미지의 도구를 차단하며, 격리로 위험한 도구를 컨텍스트로부터 분리하고, 마지막으로 인간의 승인으로 마무리합니다. 하나의 통째로 된 벽이 아니라, 여러 개의 얇은 벽을 겹치는 것입니다. 어느 한 층이 뚫리더라도 다음 층이 남아 있는 설계입니다.

사양 레벨에서도 최소 권한이 전제가 되었다

지금까지 운영에 관한 이야기를 해왔지만, MCP의 사양 자체도 최소 권한 원칙으로 움직이고 있습니다.

2026년 3월의 MCP 사양에서는 MCP 서버가 OAuth 2.1의 리소스 서버(Resource Server)로 정의되었습니다. 토큰 발행은 별도의 인가 서버(Authorization Server)가 담당하고, MCP 서버는 검증만 수행합니다. 역할이 분리된 것입니다.

여기서 효과를 발휘하는 것이 스코프 (Scope) 개념입니다. inventory.read와 inventory.write처럼 토큰에 권한의 범위를 새겨 넣는 것입니다. 서버는 올바른 스코프를 가진 클라이언트에게만 툴 (Tool)을 개방합니다.

나아가 2026년 버전에서는 **단계적 스코프 동의 (Incremental Scope Consent)**가 도입되었습니다. 클라이언트는 조작마다 필요한 최소한의 액세스만 요청할 수 있습니다. 처음부터 모든 권한을 부여하는 것이 아니라, 필요할 때 필요한 만큼만 추가하는 것입니다. 이는 최소 권한의 원칙 (Principle of Least Privilege) 그 자체입니다.

즉, 제가 수동으로 수행하던 read/write 분류가 프로토콜의 설계 사상으로 내려오고 있는 것입니다. 설계의 방향이 맞았다는 사실에 조금 안심했습니다.

단, 주의할 점이 있습니다. OAuth의 스코프가 작동하는 것은 서버 측에서 이를 구현했을 경우뿐입니다. 사양이 정해지더라도 개별 MCP 서버가 대응하지 않는다면 그림의 떡입니다. 2026년 시점에도 인증 자체를 갖추지 않은 공개 MCP 서버가 전체의 40% 가까이 존재한다고 보고되고 있습니다.

따라서 사양의 진화에 기대하면서도, 운영 측면에서도 고삐를 쥐고 있어야 합니다. 클라이언트 설정의 툴 허가 리스트는 서버가 미대응 상태일 때도 즉시 효과를 발휘하는 방어 수단입니다. 사양 레벨의 최소 권한과 운영 레벨의 최소 권한. 이 두 바퀴를 함께 생각하는 것이 현실적이었습니다.

설정 파일은 이렇게 바뀌었습니다

추상론만으로는 전달하기 어려우므로, 제 설정이 어떻게 바뀌었는지 적어보겠습니다. 실제 프로덕트의 값은 모호하게 처리하겠지만, 구조는 실제와 같습니다.

처음에는 이랬습니다. 서버를 연결하기만 하면 되었습니다.

{
"mcpServers": {
"accounting": {
...

이렇게 하면 270개의 툴이 전부 활성화됩니다. AI는 무엇이든 호출할 수 있습니다.

범위를 좁힌 후에는 다음과 같이 되었습니다. 허가할 툴을 명시합니다.

{
"mcpServers": {
"accounting": {
...

조회 계열인 list_*는 read-only로 허가합니다. create_deal만 scoped-write로 통과시킵니다. 삭제나 설정 변경 툴은 애초에 리스트에 올리지 않습니다. 리스트에 없으면 호출할 수 없습니다.

단 몇 줄에 불과하지만, 이 차이는 매우 큽니다. 전자가 "무엇이든 할 수 있는 AI"라면, 후자는 "거래 등록만 맡긴 AI"입니다. 같은 서버, 같은 모델이지만 허가 리스트만 다를 뿐입니다. 그런데도 AI의 인격이 완전히 달라졌습니다.

참고로, 모든 MCP 클라이언트가 툴 단위의 허가를 지원하는 것은 아닙니다. 대응하지 않는 클라이언트에서는 서버를 실행하는 측에서 툴을 걸러내거나, 용도별로 서버를 분리해야 합니다. 이 부분은 2026년 현재 아직 과도기입니다.

범위를 좁힌 뒤에 보인 것들

확정 신고가 끝난 후, 저는 매트릭스 (Matrix)를 다시 만들었습니다. 조회 계열은 read-only, 거래 생성은 scoped-write, 설정 변경과 삭제는 deny, 셸 실행은 격리.

그 결과, AI가 만질 수 있는 툴은 270개에서 12개로 줄었습니다.

변한 것은 숫자뿐만이 아닙니다. 저는 처음으로 AI의 행동 범위를 하나의 표로서 조망할 수 있게 되었습니다. 어디까지 손을 뻗을 수 있고, 어디에는 닿지 못하는지. 그것이 눈에 보입니다.

신기하게도 범위를 알게 되면 안심하고 맡길 수 있습니다. 범위를 좁히기 전이 훨씬 불안했습니다. 무엇을 할 수 있는지 모르는 상대에게 일을 부탁하고 있었으니까요.

사람을 채용할 때와 같다고 생각했습니다. 유능한 사람에게 "마음대로 해보세요"라고 말하는 것은 통째로 떠넘기는 것에 가깝습니다. 역할을 정하고, 권한을 부여하며, 보고 라인을 그립니다. 거기까지 해야 비로소 안심하고 맡길 수 있습니다. AI도 마찬가지입니다. 스코프 설계는 AI를 위한 직무 기술서 (Job Description)를 작성하는 작업이었습니다.

토큰 비용도 낮아졌습니다. 270개 분량의 정의를 읽지 않아도 되므로 불필요한 소비가 사라졌습니다. 보안을 목적으로 시작한 설계가 지갑에도 도움이 되었습니다. 최소 권한은 인색함이 아니라 합리성입니다.

여러 개의 MCP를 묶어서 운용하는 설계는 모노레포 (Monorepo) 운용에 관한 기사에도 정리해 두었습니다. 스코프 설계는 그 토대가 됩니다.

요약

• 모든 툴을 허가하는 MCP는 토큰을 낭비하고, AI의 조용한 경계 침범을 초래한다
• 권한을 좁히는 작업은 제약이 아니라, AI의 행동 범위를 가시화하는 관측 수단이다
• 설계의 기본은 read-only / scoped-write / deny의 3단계 분리이다
• 툴 종류 × 스코프의 매트릭스로 구성하면 설계의 허점이 보인다
• 셸 실행이나 외부 전송은 격리하고, 삭제에는 인간의 승인을 거치게 한다
• MCP 사양도 OAuth 2.1의 스코프와 단계적 동의를 통해 최소 권한을 향해 가고 있다

권한을 좁히고 나서야 비로소 AI에게 무엇을 맡기고 있는지 알 수 있었습니다. 가시화는 방어의 부산물이 아니라, 목적 그 자체입니다.

토론 (Discussion)