코딩 에이전트의 권한 시스템은 대부분 허용 목록 방식입니다. 파일 읽기는 허용, 파일 쓰기도 허용, 테스트 실행도 허용, 그 외의 모든 것은 확인을 거칩니다. 하지만 prompt가 번거로워 누군가 에이전트를 “완전 신뢰”로 설정하고, 그 에이전트가 금요일에 git push --force를 실행하기 전까지만 유효한 방식입니다.
우리의 입장은 에이전트나 요청자가 얼마나 신뢰받든 상관없이, 네 가지 범주의 작업은 매번 사람의 확인을 거쳐야 한다는 것입니다. 신뢰 수준은 다른 작업 중 얼마나 많은 것들이 승인을 필요로 하는지를 결정합니다. 이 네 가지 작업은 결코 조용히 실행되어서는 안 됩니다.
네 가지 작업
1. 공유 브랜치로의 푸시. 피처 브랜치의 커밋은 하나의 제안입니다. 하지만 main이나 release로의 푸시는 팀 전체에 영향을 미치는 결정이며, 종종 배포로 바로 이어집니다. 이 작업은 사전에 물어보는 비용은 저렴하지만, 되돌리는 비용은 매우 큽니다.
2. 삭제. 파일, 브랜치, 테이블, 버킷, 리소스 등입니다. 삭제는 의도에 대한 잘못된 판단을 두 번째 시도로 되돌릴 수 없는 유일한 작업입니다. 에이전트는 늘 확신에 차 있고, 확신에 찬 삭제는 백업 복구를 테스트하게 만듭니다.
3. 비용 지출. 유료 API 호출, 리소스 프로비저닝, 도메인 구매, 캠페인 발송 등입니다. 요청한 사람은 그 요청에 비용이 든다는 사실조차 모를 수 있습니다. 비용을 지불하는 사람이 이를 알아야 합니다.
4. 자격 증명 접근. 키 파일 읽기, 환경 변수 export, 서비스 로그인, 2단계 인증 완료 등입니다. 여기에 해당하는 모든 것은 신원과 관련이 있으며, 신원은 룸에 있는 누군가가 아니라 머신의 소유자에게 속합니다.
“완전 신뢰” 모드에서도 여기서 멈춰야 하는 이유
권한 모드는 사람과 에이전트 간의 관계를 정의합니다. 읽기 전용, 편집 가능(푸시 제외), 완전 신뢰 같은 방식입니다. 이는 에이전트가 세션 중에 수행하는 수백 개의 일반적인 호출을 다루기에는 적절한 단위입니다. 하지만 앞서 언급한 네 가지 작업에는 적절하지 않은 단위입니다. 이 작업들은 드물게 발생하고 되돌릴 수 없거나 비용이 크며, 그 비용을 치러야 하는 사람이 요청자가 아닌 다른 사람이기 때문입니다.
따라서 muti의 규칙은 간단합니다. 어떤 권한 템플릿도 이 네 가지 작업을 조용히 실행되도록 설정할 수 없습니다. “완전 신뢰” 모드에서도 작업은 일시 정지되며 타임라인에 강조 표시됩니다. prompt는 드물게 나타나므로 번거롭지 않으며, 범주가 명확하여 답변하기도 대개 간단합니다.
Claude Code의 권한 모드와의 연계 방식
Claude Code에는 이미 단계별 모드가 있습니다. plan(읽기 전용), default(편집 및 명령 실행 전 확인), acceptEdits(편집은 바로 실행, 명령은 확인), bypassPermissions(모두 확인 없이 실행)입니다. 이러한 모드는 에이전트가 여러분에게 얼마나 자주 물어보는지를 나타냅니다. 반면 네 가지 작업은 다른 사람이 요청할 때 무엇을 소유자에게 반드시 물어봐야 하는지를 정의합니다. 두 가지는 중첩되어 적용됩니다.
마지막 열은 룸이 추가한 규칙이며 모든 행에서 동일합니다. 권한 모드 해설을 참고하세요.
누구에게 물어봐야 하는가
대부분의 설계가 놓치는 부분이 바로 이점입니다. 공유된 에이전트에 사람의 개입이 필요할 때, 어느 사람이어야 할까요?
- 자격 증명은 소유자에게 전달됩니다. 로그인, 2단계 인증 코드, 키 접근은 소유자의 신원과 직결됩니다. 누가 작업을 시작했든 소유자에게 라우팅됩니다. 요청자에게는 소유자가 개입했다는 사실만 표시되며, 비밀 정보는 노출되지 않습니다.
- 의도를 묻는 질문은 요청자에게 전달됩니다. “스테이징 데이터베이스를 의미하신 건가요?” 같은 질문은 요청자가 원했던 바에 관한 것입니다. 이는 요청한 사람에게 라우팅됩니다.
- 두 사람 모두 동일한 타임라인을 봅니다. 서로 맥락을 전달할 필요가 없습니다. 질문과 답변은 작업이 진행되는 동일한 스레드에 그대로 남습니다.
자격 증명 및 위험한 작업 prompt는 소유자에게 라우팅되고, 의도 확인 질문은 요청자에게 라우팅되며, 두 사람 모두 주고받은 내용을 확인합니다.
좋은 승인 카드의 구조
사람이 5초 안에 결정할 수 있는 승인 카드에는 다섯 가지 요소가 있습니다.
여기에 세 가지 버튼을 제공합니다. 승인, 거부, 그리고 읽기 전용으로 계속 진행. 세 번째 버튼은 과소평가되는 경우가 많습니다. 위험한 단계를 보류해 둔 채로 작업을 계속 진행할 수 있게 해줍니다.
콘솔, 휴대폰, 채팅 플랫폼 카드 등 소유자가 이미 머무르고 있는 곳 어디서나 승인에 응답할 수 있도록 해야 합니다. 한 곳에서 결정하면 모든 곳에 적용되어야 합니다. 또한 만료 시간을 설정하여 잊혀진 카드가 일주일 뒤에 실행되는 일이 없도록 해야 합니다.
승인 피로는 진정한 적입니다
모든 prompt는 그것을 보는 사람을 길들입니다. 너무 많으면 사람들은 이를 끌 수 있는 설정을 찾아내고 맙니다. 네 가지 규칙을 느슨하게 하지 않으면서 빈도를 낮추는 세 가지 방법이 있습니다.
- 에이전트의 범위를 제한하세요. 에이전트당 하나의 작업 디렉터리를 사용하면 접근 가능한 파일 수가 줄어들고, 파일 접근에 대한 prompt도 줄어듭니다.
- 일반적인 호출에는 일반 모드를 사용하세요. 탐색에는 읽기 전용을, 대부분의 작업에는 푸시 없는 편집을 사용합니다. “완전 신뢰”는 여러분의 키보드로 직접 타이핑할 수 있을 만큼 믿을 수 있는 사람에게만 남겨두세요.
- 기본 템플릿을 정직하게 만드세요. 읽기 전용, 편집 가능(푸시 제외), 완전 신뢰를 미리 정의된 프리셋으로 제공하여, 아무도 정책을 처음부터 구성하다 실수하지 않도록 하세요.
감사 로그
모든 요청과 모든 승인은 소유자가 내보낼 수 있는 한 줄의 기록을 남겨야 합니다. 누가 요청했는지, 누가 결정했는지, 언제, 어떤 규칙인지, 무슨 일이 일어났는지, 무엇을 사용했는지. 매일 읽기 때문이 아니라, 무언가 잘못된 날이 로그 기록을 시작할 날은 아니기 때문입니다.
자주 묻는 질문
매번 물어보면 에이전트가 느려지지 않나요? 일반적인 세션에서는 드물게 일어나는 이 네 가지 범주에만 해당합니다. 일시 정지로 발생하는 비용은 몇 초에 불과하지만, 실수의 비용은 몇 시간 또는 비용으로 계산됩니다.
소유자가 자신의 에이전트를 직접 사용할 때는 어떤가요? 소유자는 자신의 에이전트에 대해 권한 모드의 제한을 받지 않지만, 기록의 완전성을 위해 네 가지 작업은 여전히 타임라인에 기록됩니다.
요청자가 스스로 승인할 수 있나요? 아니요. 승인 권한은 머신의 소유자에게 있습니다. 요청자는 취소하거나, 다시 시도하거나, 맥락을 추가할 수 있습니다.
muti의 룸은 이 규칙들이 활성화된 상태로 제공되며 이를 비활성화할 방법은 없습니다. 이것이 올바른 기본값이라고 생각된다면, 에이전트에게 룸을 만들어 주세요.
게시일 · 수정일