AI 에이전트를 처음 연결하면 메일, 일정, 문서, 코드 저장소에 모두 접근할 수 있게 해 달라는 요청을 받을 때가 있다. 답변을 잘하는 도구라는 사실과 외부 시스템의 상태를 바꿔도 된다는 판단은 전혀 다른 시험인데, 두 가지가 한 화면에 놓이면 구분하기 어려워진다.

한 줄 답

AI 에이전트의 권한은 성능표가 아니라 작업 증거에 따라 단계적으로 부여하는 편이 안전하다. 처음에는 읽기와 제안만 허용하고, 검증 기록이 쌓인 뒤에 범위가 제한된 쓰기와 배포를 별도로 연다.

1. 답변 품질과 행동 권한을 분리한다

어려운 질문에 정확히 답하는 능력은 좋은 출발점이다. 하지만 답변을 잘했다고 파일을 수정하거나 메일을 보내도 된다는 뜻은 아니다. 외부 상태를 바꾸는 작업에는 대상, 범위, 실패 시 복구 방법이 추가로 필요하다.

따라서 권한을 정할 때는 “이 모델이 얼마나 똑똑한가”와 함께 “무엇을 바꿀 수 있는가”를 따로 적어야 한다. 읽기 권한과 쓰기 권한, 초안 생성과 실제 배포 권한은 같은 묶음으로 다루지 않는다.

2. 권한을 네 단계로 나눈다

  1. 읽기: 문서, 로그, 코드, 데이터의 현재 상태를 확인한다.
  2. 제안: 변경안이나 답변을 만들지만 외부 상태는 바꾸지 않는다.
  3. 제한된 쓰기: 정해진 저장소·브랜치·파일·초안 영역에만 변경을 만든다.
  4. 배포와 외부 실행: 실제 사용자나 운영 시스템에 영향을 주는 작업은 별도 승인 뒤에 실행한다.

이 순서는 에이전트를 믿지 않기 위한 의식이 아니다. 실수할 수 있는 사람과 도구가 사고를 내더라도 피해 범위를 줄이고, 어디에서 문제가 생겼는지 찾기 위한 구조다.

3. 다음 단계로 올릴 때 확인할 증거

권한을 넓히기 전에 최소한 다음 질문에 답할 수 있어야 한다.

  • 어떤 대상까지 접근할 수 있는가.
  • 잘못된 변경을 어떻게 발견하는가.
  • 실패한 작업을 어떻게 되돌리는가.
  • 도구 호출과 결과를 나중에 확인할 기록이 남는가.
  • 테스트와 사람의 승인 중 무엇이 마지막 경계인가.

사고가 없었다는 사실만으로는 충분하지 않다. 실패를 발견했고, 원인을 좁혔고, 복구했다는 기록이 오히려 다음 권한을 판단하는 데 더 유용하다.

4. 자동화와 승인을 함께 설계한다

모든 작업에 사람이 승인하면 자동화의 장점이 사라진다. 반대로 편리하다는 이유로 처음부터 전권을 주면 자동화가 아니라 운전대 없는 시승에 가깝다.

반복적이고 되돌리기 쉬운 읽기·분류 작업은 자동화 범위를 넓힐 수 있다. 외부에 메시지를 보내거나 운영 상태를 바꾸는 작업은 범위를 좁히고, 변경 전후의 상태와 복구 방법을 남기는 편이 낫다. 핵심은 승인 버튼의 개수가 아니라 작업 위험에 맞는 경계를 정하는 일이다.

짧은 글에서는 AI에게도 수습 기간이 필요하다는 관찰을 남겼다. 이 글에서는 그 관찰을 권한 단계와 확인 항목으로 풀어 쓴다.

관련 글