AI 에이전트 권한 설계: 읽기 자동화와 쓰기 승인을 분리하는 실무 기준

AI 에이전트를 개발 워크플로우에 붙일 때 가장 먼저 정해야 할 것은 모델이 아닙니다. 권한입니다. GitHub, Slack, Notion, Jira, 배포 시스템, 데이터베이스를 연결하면 에이전트는 실제 업무를 처리할 수 있습니다. 동시에 잘못된 명령을 실행할 수도 있습니다. 그래서 권한 설계는 “무엇을 할 수 있게 할 것인가”보다 “무엇은 절대 자동으로 하지 않을 것인가”에서 시작해야 합니다.

실무 기준은 단순합니다. 읽기는 넓게 자동화하고, 쓰기는 좁게 승인합니다. 조회, 요약, 비교, 초안 작성은 대부분 자동으로 맡겨도 됩니다. 반면 삭제, 배포, 결제, 외부 전송, 권한 변경은 사람이 승인해야 합니다.

에이전트 사고는 대부분 권한 경계에서 난다

AI 에이전트가 틀린 답을 하는 것은 익숙한 문제입니다. 하지만 도구가 연결된 에이전트가 틀린 행동을 하면 피해가 커집니다. 잘못된 PR 코멘트는 고치면 됩니다. 잘못된 DB 삭제는 복구가 어렵습니다. 잘못된 Slack 공지는 신뢰를 깎습니다. 잘못된 배포는 장애가 됩니다.

권한 설계의 목적은 에이전트를 못 쓰게 하는 것이 아닙니다. 안전하게 많이 쓰기 위한 장치입니다. 사람이 매번 모든 읽기 작업을 승인하면 생산성이 떨어집니다. 반대로 모든 쓰기 작업을 자동화하면 리스크가 커집니다. 둘을 분리해야 합니다.

권한을 4단계로 나누면 운영이 쉬워진다

권한은 allow/deny 두 단계로만 나누면 부족합니다. 다음 4단계가 실무에 맞습니다.

이렇게 나누면 에이전트에게 충분한 자율성을 주면서도 위험한 행동은 막을 수 있습니다. 예를 들어 PR 리뷰 에이전트는 diff 읽기, 테스트 로그 읽기, 리뷰 코멘트 초안 작성까지 자동으로 합니다. 하지만 실제 GitHub 코멘트 등록은 승인 후 실행합니다.

MCP 도구 설명은 권한 문서가 되어야 한다

MCP나 내부 tool을 붙일 때 도구 이름과 설명을 대충 적는 팀이 많습니다. 이것은 위험합니다. 모델은 도구 설명을 보고 언제 사용할지 판단합니다. 설명이 모호하면 원치 않는 상황에서 도구를 호출할 수 있습니다.

좋은 도구 설명에는 다음이 들어갑니다.

• 이 도구가 하는 일
• 읽기인지 쓰기인지
• 외부 영향이 있는지
• 실행 전 필요한 승인 조건
• 실패 시 재시도해도 되는지
• 입력 예시와 금지 입력

예를 들어 sendSlackMessage라는 도구 설명에는 “외부 채널에 실제 메시지를 보낸다. 사용자 승인 없이 호출하지 말 것. 초안 생성에는 draftSlackMessage를 사용할 것”처럼 적어야 합니다. 도구를 둘로 나누는 것도 좋습니다. draft 도구와 send 도구를 분리하면 모델이 안전한 경로를 선택하기 쉽습니다.

승인 UX는 구체적이어야 한다

사람 승인을 받는다고 해서 무조건 안전한 것은 아닙니다. 승인 화면이 추상적이면 사람도 놓칩니다. “작업을 계속할까요?” 같은 문구는 부족합니다. 무엇을 어디에 어떻게 실행하는지 보여줘야 합니다.

좋은 승인 요청은 다음 정보를 포함합니다.

• 실행할 도구 또는 명령
• 대상 시스템
• 변경 대상 ID 또는 URL
• 변경 전후 요약
• 되돌릴 수 있는지 여부
• 예상 영향 범위
• 실패 시 복구 방법

예를 들어 “PR을 생성할까요?”보다 “repo aibase, base main, branch feature/rag-eval, 변경 파일 4개, 외부 배포 없음, 되돌리기는 branch 삭제로 가능”이 훨씬 낫습니다. 사용자는 승인해야 할 정보를 받아야 승인할 수 있습니다.

로그는 감사가 아니라 디버깅 도구다

권한 로그는 보안팀만 보는 문서가 아닙니다. 에이전트가 왜 그런 행동을 했는지 디버깅하는 자료입니다. 특히 장기 작업에서는 사람이 중간 과정을 놓치기 쉽습니다.

로그에는 최소한 다음이 필요합니다.

• 사용자 요청 원문
• 에이전트가 세운 계획
• 호출한 도구와 입력 요약
• 읽기 결과의 핵심 요약
• 승인 요청과 승인자
• 실제 쓰기 결과
• 실패와 재시도 내역

여기서 민감정보는 저장하지 않거나 마스킹해야 합니다. 로그의 목적은 비밀을 쌓는 것이 아니라 의사결정 경로를 남기는 것입니다. “왜 이 메시지를 보냈지?”, “왜 이 브랜치를 만들었지?”를 나중에 설명할 수 있어야 합니다.

자동화 범위는 성공률이 아니라 피해 규모로 정한다

많은 팀이 “에이전트가 95% 정확하니까 자동화하자”고 말합니다. 위험한 기준입니다. 5% 실패의 피해가 작으면 자동화해도 됩니다. 하지만 1% 실패가 큰 장애나 데이터 손실로 이어지면 승인 단계가 필요합니다.

자동화 여부는 다음 질문으로 판단합니다.

1. 실패했을 때 되돌릴 수 있는가?
2. 외부 사용자에게 노출되는가?
3. 돈, 권한, 개인정보와 연결되는가?
4. 같은 실수가 대량으로 반복될 수 있는가?
5. 사람이 승인해도 전체 시간이 크게 늘지 않는가?

읽기와 초안은 대부분 자동화합니다. 제한적 쓰기는 샌드박스나 브랜치 안에서 허용합니다. 외부 영향 쓰기는 승인합니다. 이 기준이 있어야 팀원이 에이전트를 믿고 쓸 수 있습니다.

바로 적용할 체크리스트

• 에이전트 도구를 읽기, 초안, 제한적 쓰기, 외부 영향 쓰기로 분류한다.
• 읽기 도구는 넓게 허용하되 민감정보 마스킹을 적용한다.
• send, delete, deploy, permission 변경 도구는 승인 필수로 둔다.
• draft 도구와 send 도구를 분리한다.
• MCP 도구 설명에 승인 조건과 외부 영향 여부를 명시한다.
• 승인 화면에 대상, 변경 내용, 복구 가능성을 표시한다.
• 에이전트 행동 로그를 요청·계획·도구·승인·결과 단위로 남긴다.
• 자동화 여부는 성공률이 아니라 실패 피해 규모로 결정한다.

AI 에이전트 권한 설계의 목표는 에이전트를 묶어두는 것이 아닙니다. 반복 조회와 초안 작성은 과감히 자동화하고, 되돌리기 어려운 행동은 사람에게 넘기는 것입니다. 이 분리가 되면 에이전트는 더 많이, 더 안전하게 일할 수 있습니다.