AI에게 어디까지 맡겨도 될까? 위험도로 나누는 5단계 승인선

장애 알림이 울렸다.

주니어 개발자가 만든 작은 AI 에이전트는 로그를 뒤져 payment-api의 타임아웃을 찾아냈다. 여기까지는 완벽했다. 그런데 다음 줄이 문제였다.

원인을 제거하기 위해 서비스를 재시작하겠습니다.

로그를 읽는 것과 서비스를 재시작하는 것은 같은 “도구 사용”이 아니다. 하나는 관찰이고, 다른 하나는 사용자에게 영향을 줄 수 있는 상태 변경이다. AI가 똑똑해질수록 더 많이 맡겨도 된다고 생각하기 쉽지만, 실제 기준은 지능이 아니라 실패했을 때 되돌릴 수 있는가다.

자율성은 능력이 아니라 위험도로 정한다

AI 에이전트의 권한을 정할 때는 네 가지를 먼저 묻는다.

1. 실패해도 쉽게 되돌릴 수 있는가?
2. 외부 사용자나 회사의 평판에 영향을 주는가?
3. 개인정보·비밀 값·결제 정보처럼 민감한 데이터를 다루는가?
4. 비용과 피해 범위가 어디까지 커질 수 있는가?

이 질문에 답하면, 업무를 다음 다섯 단계로 나눌 수 있다.

1단계: 관찰 — 자동 실행

공개 문서 검색, 로그 조회, 코드 읽기, 테스트 결과 요약처럼 상태를 바꾸지 않는 일이다. 기본적으로 자동화하기 좋은 영역이다.

다만 읽기 전용이라고 무조건 안전한 것은 아니다. 민감한 운영 로그를 읽을 수 있다면 조회 범위와 기록 보관 정책은 별도로 제한해야 한다.

2단계: 제안 — 자동 생성, 실행 금지

답변 초안, 변경 계획, SQL 미리보기, 장애 대응 절차처럼 AI가 결과를 만들되 외부에는 보내지 않는 단계다.

“고객에게 보낼 안내문을 작성해줘”와 “고객에게 보내줘” 사이에는 큰 경계가 있다. 초안은 자동으로 만들 수 있지만 전송에는 사람의 승인이 필요하다.

3단계: 제한된 변경 — 격리 환경에서 허용

별도 브랜치의 코드 수정, 임시 파일 생성, 샌드박스 테스트처럼 검토와 롤백이 가능한 행동이다. 이 단계에서는 다음 조건이 붙어야 한다.

• 운영 환경과 분리되어 있을 것
• 변경 내역을 사람이 검토할 수 있을 것
• 같은 요청이 재시도되어도 부작용이 반복되지 않을 것
• 실패 시 원래 상태로 돌아갈 방법이 있을 것

4단계: 외부 영향 — 실행 직전 사람 승인

메시지 전송, 코드 병합, 프로덕션 배포, 서비스 재시작처럼 다른 사람이나 실제 사용자에게 영향을 주는 행동이다. AI는 행동을 제안할 수 있지만, 정확히 무엇을 어디에 실행할지 보여준 뒤 사람의 승인을 받아야 한다.

5단계: 고위험·비가역 — 사람 실행 또는 이중 승인

데이터 삭제, 결제, 권한 변경은 실수의 복구 비용이 크다. 데이터 삭제에는 백업 확인과 이중 승인을 두고, 결제나 핵심 권한 변경은 원칙적으로 사람이 직접 실행하는 편이 안전하다.

승인 창에는 “예/아니오”보다 더 많은 정보가 필요하다

나쁜 승인 요청은 이렇게 생겼다.

서비스를 재시작할까요?

무슨 서비스인지, 어떤 인수로 실행되는지, 영향 범위와 복구 방법이 무엇인지 알 수 없다. 좋은 승인 요청에는 최소한 다음 정보가 들어가야 한다.

항목확인할 내용

도구	어떤 기능을 호출하는가
인수	실제로 전달되는 값은 무엇인가
대상	개발·스테이징·운영 중 어디인가
예상 영향	사용자와 시스템에 어떤 변화가 생기는가
롤백	실패하면 어떻게 되돌리는가
만료 시간	승인이 언제까지 유효한가

승인은 행동 하나에 묶여야 한다. “앞으로 재시작은 모두 허용”이 아니라 “지금 payment-api 한 대를 이 인수로 재시작”처럼 좁고 구체적이어야 한다.

프롬프트가 아니라 코드가 마지막 문을 지켜야 한다

“위험한 행동은 하지 마”라고 프롬프트에 적는 것만으로는 부족하다. 위험의 정의가 모호하고, 프롬프트 인젝션이나 잘못된 추론이 그 문장을 우회할 수 있기 때문이다.

따라서 실행기 앞에는 모델과 독립된 정책 검사가 있어야 한다.

def check_policy(action, approved=False):
    if action.tool in READ_TOOLS:
        return "allowed"
    if action.tool in WRITE_TOOLS and not approved:
        return "approval_required"
    if action.tool in WRITE_TOOLS and approved:
        return "allowed"
    return "denied"

핵심은 세 가지다.

• 읽기 행동은 허용한다.
• 쓰기 행동은 승인 전까지 멈춘다.
• 목록에 없는 도구는 기본적으로 거부한다.

그리고 이 경계를 테스트한다. 로그 검색은 통과하는지, 서비스 재시작은 승인 없이 차단되는지, delete_database 같은 알 수 없는 도구는 거부되는지 자동 테스트로 확인한다.

오늘 바로 적용할 수 있는 승인선

현재 만들고 있는 AI 기능을 떠올리고 아래 세 줄을 적어보자.

1. 자동 실행해도 되는 읽기 도구 두 개
2. 사람 승인이 필요한 쓰기 행동 두 개
3. AI에게 절대 제공하지 않을 도구 한 개와 그 이유

AI 에이전트의 안전은 “실수하지 않기를 바라는 것”이 아니라, 실수해도 피해가 커지지 않도록 문을 나누는 설계에서 시작한다. 좋은 에이전트는 무엇이든 혼자 해내는 시스템이 아니다. 멈춰야 할 순간을 정확히 아는 시스템이다.

다음 글에서는 에이전트가 토큰과 호출 횟수를 끝없이 쓰지 않도록, 비용 예산을 계산하고 한도에서 자동으로 멈추는 방법을 다룬다.