AI 비서가 메일을 대신 보내거나 SNS에 게시물을 올릴 수 있도록 권한을 주는 시점은 생각보다 빨리 찾아온다. 이 전환을 안전하게 지나는 데 필요한 기준은 세 가지다.
기준 1: 행동 범위가 명확하게 한정되어 있는가
"메일을 보낼 수 있다"는 권한은 너무 넓다. "지정한 수신자 목록에, 미리 정해진 형식의 메일만 보낼 수 있다"는 권한은 관리 가능하다.
처음 권한을 줄 때는 범위를 최대한 좁게 시작한다. 2주간 관찰한 후 문제가 없으면 범위를 조금 넓힌다. 이렇게 단계적으로 확장하는 방식이 처음부터 넓은 범위를 허용하는 것보다 안정적이다.
범위가 모호한 채로 권한을 부여하면 에이전트는 스스로의 판단으로 범위를 채운다. 그 판단이 예상과 다를 때 예상치 못한 행동이 발생한다.
기준 2: 실수가 복구 가능한 상황인가
모든 행동이 동일한 수준의 위험을 갖지 않는다. 복구 가능한 행동과 복구 불가능한 행동을 구분하는 것이 권한 부여 결정의 핵심이다.
복구 불가능한 행동의 예: 외부 메일 발송, SNS 게시물 공개 발행, 결제 실행, 파일 삭제. 이 종류의 행동은 에이전트가 처리하더라도 반드시 사람의 최종 승인 단계를 유지해야 한다.
복구 가능한 행동의 예: 초안 작성, 임시 저장, 큐에 대기, 내부 메모 기록. 이 종류는 자동화를 먼저 허용해도 위험이 낮다.
처음 권한을 부여할 때는 복구 가능한 행동부터 시작하는 것이 순서다. 복구 불가능한 행동은 복구 가능한 행동이 안정화된 이후에 단계적으로 허용한다.
기준 3: 무엇이 실행됐는지 5분 이내에 확인할 수 있는가
권한을 주기 전에 반드시 로그 확인 방법을 먼저 만들어야 한다. 에이전트가 어떤 행동을 했는지 빠르게 파악할 수 없다면, 문제가 생겼을 때 어디서 어떻게 틀어졌는지 알 수 없다.
최소 기준은 하나다. 지난 24시간 동안 에이전트가 어떤 행동을 했는지 5분 이내에 확인할 수 있어야 한다. 이 확인이 불가능한 상태라면 권한 부여를 미뤄야 한다.
권한을 주기 전에 로그를 먼저 설계하는 것이 이상하게 느껴질 수 있다. 하지만 이 순서가 이후의 운영 비용을 크게 줄인다. 로그 없이 문제가 생기면 원인을 찾는 데 드는 시간이 로그를 설계하는 데 드는 시간보다 훨씬 길다.