권한이 많을수록 위험한 이유

AI 에이전트에 메일 발송, 캘린더 수정, DB 삭제 권한을 모두 주면 한 번의 로직 실수가 돌이킬 수 없는 결과를 만든다. 고객 관리 시스템에서 '활성 상태인 계정'을 찾아 메일을 보내는 에이전트가 쿼리를 잘못 해석해서 모든 계정에 같은 메일을 보낸다면? 캘린더에서 '지난 일정'을 정리하는 에이전트가 현재 날짜를 잘못 읽어서 다음 달 회의를 전부 삭제한다면?

이런 상황은 데이터 복구, 고객 대응, 팀의 신뢰도 회복까지 연쇄 비용을 부른다. 특히 메일 발송이나 데이터 삭제처럼 되돌리기 어려운 작업일수록 그 위험이 크다. AI가 '똑똑해 보이니까' 권한을 주는 것과 '이 작업을 AI가 판단해도 되는가'를 구분하는 것은 완전히 다른 결정이다.

조회와 실행을 분리하는 게 첫 단계

권한을 단계별로 나누는 가장 기본은 조회(Read)와 실행(Write/Delete)을 완전히 분리하는 것이다. AI 에이전트는 메일 목록을 '조회'할 수 있지만, 메일을 직접 '발송'하지는 않는다. 캘린더 일정을 '확인'할 수 있지만, 일정을 '삭제'하지는 않는다. DB에서 특정 고객을 '찾을' 수 있지만, 레코드를 '수정'하지는 않는다.

조회만 가능하면 AI는 상황을 정확히 파악한 후 사람이 확인할 보고서나 제안을 만든다. '다음 주 회의 일정 5개가 있습니다, 취소할까요?'라고 물어보는 단계에서 멈춘다는 뜻이다. 이 방식은 자동화의 속도는 조금 느리지만, 실수의 여지를 거의 없앤다.

검증 단계를 만드는 3가지 방식

조회 권한만으로는 부족한 경우, 검증 단계를 설계해야 한다. 첫 번째는 '초안 작성 후 승인'이다. AI는 발송할 메일을 작성하지만, 실제 발송은 담당자가 버튼을 눌러야 한다. 고객사에 보낼 중요한 공지나 대량 메일이 이 방식에 적합하다. 담당자는 메일 내용이 맞는지 빠르게 확인하고 발송하므로 업무 속도는 크게 떨어지지 않는다.

두 번째는 '작은 범위부터 시작'이다. 1,000명의 고객에게 한 번에 메일을 보내는 대신, 먼저 10명의 테스트 그룹에만 보낸다. 로직이 제대로 작동하는지 확인한 후 나머지에게 발송한다. 특히 세분화된 조건(지역, 구매 이력, 가입 기간)에 따라 메시지를 다르게 보낼 때 효과적이다.

세 번째는 '타임라인 제약'이다. AI가 메일을 발송할 때 발송 예약을 2시간 뒤로 설정해서, 사람이 그 사이에 취소할 기회를 만든다. 또는 삭제 작업을 실행 후 24시간의 '복구 유예 기간'을 설정해서, 실수를 발견했을 때 되돌릴 수 있게 한다.

권한 수준을 3단계로 정의하기

팀에서 실제로 운영할 때는 각 작업마다 권한 수준을 명시적으로 정의하는 게 좋다. 레벨 1은 '조회만 가능', 예를 들어 고객 DB에서 마지막 구매일을 확인하거나 캘린더에서 빈 시간을 찾는 것. 에이전트가 혼자서 할 수 있고, 실시간으로 실행된다.

레벨 2는 '초안 작성 후 승인 필요'다. 이메일 작성, 고객 상태 변경 제안, 캘린더 이벤트 생성 등이 해당한다. AI가 안건을 준비하면 담당자가 확인 후 승인한다. 승인에 걸리는 시간(보통 몇 분에서 몇 시간)을 고려해서 업무 흐름을 설계해야 한다.

레벨 3은 '제한된 범위에서만 실행 가능'이다. 메일은 최대 100명, 삭제는 하루 100개 레코드, 캘린더는 7일 뒤의 일정만 취소 가능하는 식으로 숫자와 시간 제약을 건다. 이렇게 하면 AI의 오류가 일부에만 영향을 미친다.

감시 로그로 신뢰도를 높이기

권한을 단계별로 나누는 것만큼 중요한 건 '뭘 했는지 기록하기'다. AI 에이전트가 실행한 모든 작업을 로그에 남겨야 한다. 누가(에이전트), 언제, 뭘, 어떤 결과로 했는지가 명확해야 문제가 생길 때 추적할 수 있다.

예를 들어 '2024-01-15 14:23, CustomerMailAgent가 segment=VIP 조건으로 메일 150건 발송, 성공'이라는 기록이 있으면, 나중에 '어제 메일이 잘못 갔다'는 불평이 들어올 때 정확히 뭐가 잘못됐는지 확인할 수 있다. 로그는 또한 에이전트의 패턴(특정 시간에만 에러가 난다, 특정 조건에서 자주 실패한다)을 발견하는 데도 도움이 된다.

로그 접근을 담당자만 볼 수 있게 제한하는 것도 중요하다. 에이전트의 행동이 완전히 투명해야 팀이 에이전트를 믿을 수 있다.

팀 크기와 작업 특성에 맞는 권한 설계

작은 팀(5명 이하)은 대부분의 AI 작업을 레벨 2(초안 후 승인)로 설정하는 게 낫다. 담당자가 매번 확인하는 부담이 있지만, 팀원이 적으니까 누가 뭘 했는지 추적하기 쉽고, 실수의 영향도 제한된다.

중간 규모 팀(10~50명)은 업무마다 다르게 설정한다. 반복적인 조회(보고서 생성, 통계 집계)는 레벨 1, 외부로 가는 커뮤니케이션(메일, 메시지)은 레벨 2, 내부 일정 정리 같은 낮은 위험 작업은 레벨 3으로 나눈다.

큰 조직에서 AI 에이전트를 여러 팀이 사용한다면, 각 팀의 리스크 환경에 맞춰 권한을 다르게 줄 수 있다. 고객 대면 팀은 더 엄격하게, 내부 운영 팀은 더 유연하게. 권한 설정 자체를 문서화하고 정기적으로 검토하는 프로세스도 필요하다.

시작할 때 체크리스트

AI 에이전트를 처음 도입할 때, 다음 항목을 하나씩 정리해야 한다.

**첫째, 각 작업의 위험도를 판단한다.** 메일 발송은 외부로 가는 것(높음), 캘린더 수정은 내부 영향(중간), 조회는 조회만(낮음)이라는 식으로 분류한다.

**둘째, 작업마다 권한 레벨을 정한다.** 위험도 높은 것은 레벨 2 이상, 낮은 것은 레벨 1도 괜찮다.

**셋째, 검증 단계를 구체화한다.** 승인이 필요하면 누가 몇 분 안에 확인할 수 있는지, 시간 제약이나 범위 제약이 뭔지 명시한다.

**넷째, 로그와 모니터링을 설정한다.** 에이전트의 모든 작업이 기록되고, 누군가는 그 기록을 정기적으로 확인한다.

**다섯째, 3개월마다 검토한다.** 에이전트가 실수한 사례가 있었는지, 권한이 너무 제한적이지는 않았는지 체크해서 조정한다.

권한을 정하는 것은 AI를 믿고 맡기는 일이 아니라, AI와 팀을 함께 보호하는 시스템을 만드는 일이다.