MCP 도구 권한 설정 — 기본값이 정반대인 이유

AI 일꾼에게 도구를 쥐여줄 때 늘 걸리는 게 어디까지 알아서 하게 둘까입니다. 그런데 공식 문서를 보니 기본값이 갈래마다 정반대더군요 — 기본으로 딸려오는 도구는 묻지 않고 그냥 실행하고, 밖에서 붙인 도구는 매번 물어봅니다. 얼핏 일관성이 없어 보이는데, 이유를 읽고 나니 납득이 됐습니다. 덤으로 거부할 때 한마디 적어 보내면 그게 방향 수정이 된다는 것도 알았고요.

📌 30초 요약

• 기본 도구는 자동, 외부 도구는 확인 — 기본값이 반대입니다.
• ★이유는 "나중에 늘어날 것" 때문입니다.
• 묶음으로 정하고 하나만 예외로 뺄 수 있습니다.
• 거부에 이유를 적으면 AI가 그 이유를 받습니다.
• ⚠️ 답할 때까지 무기한 멈춰 기다립니다.
• ⚠️ 돌던 작업엔 안 먹힙니다 — 다음 작업부터입니다.

기본값이 정반대인 이유

정책은 딱 둘입니다 — 그냥 실행과 물어보고 실행. 그런데 어느 쪽이 기본이냐가 도구 출신에 따라 갈립니다.

도구 출신	기본값
기본으로 딸려오는 묶음	묻지 않고 실행
밖에서 붙인 묶음	매번 물어봄
내가 직접 만든 도구	정책 대상이 아님

🔮 지금이 아니라 나중을 막는 기본값

외부 도구를 왜 매번 묻게 해뒀는지, 문서가 이유를 명시합니다 — 그 서버에 새 도구가 추가되더라도 승인 없이 실행되지 않게 하기 위해서입니다. 여기가 핵심인데, 지금 붙어 있는 도구가 위험해서가 아니라 앞으로 무엇이 늘어날지 모르기 때문입니다. 내가 붙일 때 확인한 목록과 다음 주에 그 서버가 갖고 있을 목록이 다를 수 있으니까요. 반면 기본 묶음은 구성이 정해져 있어 그런 불확실성이 없습니다. 일관성이 없는 게 아니라 "내가 통제하지 못하는 변화가 있느냐"로 갈린 셈입니다.

믿을 만한 외부 서버라면 자동 실행으로 바꿀 수 있습니다. 다만 위 이유를 알고 나면 "지금 이 서버를 믿는다"와 "이 서버가 앞으로 추가할 것도 믿는다"는 다른 판단이라는 게 보입니다. 로컬 도구에서 권한을 어떻게 나눠 쓰는지는 권한 모드 정리에 담아뒀는데, 서버에서 도는 쪽은 모드가 아니라 도구별 정책으로 갈린다는 점이 다릅니다.

묶음으로 정하고 하나만 뺍니다

설정 방식이 실용적입니다. 묶음 전체에 기본을 걸어두고, 특정 도구만 따로 재정의하는 구조예요. 문서가 든 예가 딱 실무적인데 — 전체는 자동으로 두되 명령을 직접 실행하는 도구만 확인을 받게 하는 겁니다. 파일을 읽고 쓰는 건 굳이 매번 물을 필요가 없지만, 시스템 명령은 한 번 보고 넘어가고 싶은 게 사람 마음이죠.

여기서 구분해둘 게 하나 있습니다. 정책은 "언제 실행되느냐"만 정합니다. 도구를 아예 없애고 싶다면 정책이 아니라 비활성화가 따로 있어요. "물어보게 해두면 안 쓰겠지"와 "쓸 수 없게 한다"는 다른 얘기라, 절대 안 쓰길 바라는 도구라면 꺼두는 편이 확실합니다.

거부에 한마디 적으면 방향이 됩니다

확인을 요구하도록 해뒀다면 흐름은 이렇습니다. 도구를 부르려는 순간 작업이 멈추고, 무엇 때문에 멈췄는지가 함께 전달됩니다. 그럼 허용 또는 거부로 답하고, 답이 오면 다시 돌기 시작하죠. 여러 건이 한꺼번에 걸렸으면 한 번에 묶어 답할 수도 있습니다.

좋은 대목은 거부할 때 이유를 적어 보낼 수 있다는 점입니다. 그리고 그 이유가 AI에게 그대로 전달됩니다. 문서의 예가 감을 잘 주는데, "운영 쪽에는 만들지 말고 준비 환경에 만들어라" 같은 식이에요. 그러면 단순한 차단이 아니라 방향 수정이 됩니다 — 막고 끝나는 게 아니라 어디로 가야 하는지까지 알려주는 셈이죠. 매번 붙잡혀 있기 싫다면 멈췄을 때 알림을 받도록 걸어둘 수도 있습니다.

정책이 안 닿는 곳

세 가지는 알아둬야 합니다. 첫째, 내가 직접 만들어 붙인 도구에는 이 정책이 적용되지 않습니다. 그건 내 앱이 실행하는 것이라 실행할지 말지도 내가 판단해야 합니다. 정책만 걸어두고 안심하면 그쪽이 통째로 비어 있게 됩니다.

둘째, 이미 돌아가는 작업에는 변경이 안 먹힙니다. 시작될 때의 설정을 그대로 유지하고, 바꾼 정책은 그 뒤에 시작되는 작업부터 적용됩니다. 급히 조여야 할 상황이라면 이 시차를 감안해야 하죠. 셋째, 답을 줄 때까지 무기한 기다립니다 — 시간이 지나면 알아서 진행되거나 취소되지 않습니다. 자동화에 물릴 거라면 답하는 쪽을 반드시 만들어둬야 합니다. 열쇠를 안 보여주는 방식과 함께 쓰면 두 겹이 되는데, 그쪽이 값이 새는 걸 막는다면 이쪽은 그 값으로 무엇을 하느냐를 막습니다.

🔔 멈춘 걸 알아채는 쪽은 이렇습니다 (8월 27일 추가)

여기서 답할 때까지 무기한 기다린다고 했는데, 그럼 멈춘 걸 어떻게 알아채느냐가 남습니다. 알림을 걸어둘 수 있지만 그 알림에 세 가지 함정이 있습니다 — 세 번 시도해서 안 닿으면 그냥 버리고 없어졌다는 신호도 없고, 도착 순서가 보장되지 않으며, 내용이 아니라 "무엇이 바뀌었다"는 사실만 옵니다. 그래서 알림은 "지금 봐야 한다"를 알려주는 용도로 쓰고, 실제 상태는 직접 가져와 판단하는 구조가 맞습니다. 정리는 놓치면 사라지는 알림에 담았습니다.

자주 묻는 질문 (FAQ)

Q. 전부 물어보게 해두면 안전한가요?

안전해지지만 자동화는 사라집니다. 모든 도구를 확인 대상으로 두면 사실상 사람이 옆에 붙어 있어야 돌아갑니다. 게다가 확인 창이 계속 뜨면 내용을 안 보고 누르게 되는 익숙한 문제도 생기죠. 문서가 권하는 구조가 현실적입니다 — 기본은 자동으로 두고, 되돌리기 어려운 것만 골라 확인 대상으로. 무엇이 되돌리기 어려운지는 하는 일마다 다르니 거기서부터 정하시면 됩니다.

Q. 제가 쓰는 앱에도 해당되나요?

직접 해당되진 않습니다. 이건 서버에서 대신 도는 일꾼을 직접 만들어 쓰는 쪽의 설정이에요. 다만 발상은 그대로 쓸 만합니다 — 내가 쓰는 도구에서도 "밖에서 붙인 것"과 "원래 있던 것"을 다르게 대하는 게 합리적이거든요. 특히 남이 만든 걸 연결할 때는 지금 목록만 보고 판단하면 나중에 늘어난 것까지 허용하게 된다는 점을 기억해두면 좋습니다.

Q. 거부하면 작업이 끝나나요?

아닙니다. 계속 갑니다. 거부된 도구만 실행되지 않고, AI는 "거절됐다"는 결과를 받아 이어서 일합니다. 이때 내가 적은 이유도 함께 전달되니, 왜 안 되는지 알려주면 다른 방법을 찾습니다. 그래서 거부는 중단이 아니라 대화에 가깝습니다. 같은 제품군의 기억 정리 기능처럼, 사람이 개입할 자리를 남겨두는 설계가 곳곳에 보입니다.

🧾 정직하게 밝혀둘 것

• 직접 구성해보지 않았습니다. 공식 문서의 정책 종류·기본값·흐름·제약을 정리한 것입니다.
• ★"확인 창이 잦으면 안 보고 누른다"는 제 관찰입니다. 문서에 그런 서술은 없고, FAQ에서 판단을 돕기 위해 덧붙였습니다.
• ★설정 이름·정책 값·이벤트 이름·도구 묶음 식별자는 전부 풀어서 적었습니다. 실제로 구성할 때는 원문 표기를 그대로 보셔야 합니다.
• ★조직 계정에서 쓰는 제품군의 일부입니다. 개인이 쓰는 앱이나 대화 서비스의 설정과는 다릅니다.
• 기본값은 바뀔 수 있습니다. 특히 "어느 쪽이 기본인가"는 도입 판단에 직결되니 구성 전에 원문을 확인하세요.

✨ 정리하면

기본값이 갈린 기준은 "내가 통제하지 못하는 변화가 있느냐"입니다. 밖에서 붙인 도구를 매번 묻게 한 건 지금이 위험해서가 아니라 나중에 늘어날 것을 모르기 때문이죠. 실무에서는 기본을 자동으로 두고 되돌리기 어려운 것만 확인 대상으로 두는 게 현실적이고, 거부할 때 이유를 한 줄 적으면 방향 수정이 됩니다. 로컬 도구의 권한 나누기는 권한 모드 6가지, 값이 새는 걸 막는 쪽은 AI가 못 보는 열쇠, 같은 제품군의 기억 정리는 AI가 꾸는 꿈, 전체 지출 흐름은 AI 지출 관리 허브에 모아뒀습니다.

※ 출처: Claude 관리형 에이전트 권한 정책 공식 문서(2026년 8월 27일 열람). 조직 계정 전용이며 시험 단계 표기로 제공돼 기본값과 항목이 바뀔 수 있습니다. 구성 전에 원문을 확인하시길 권합니다.