실수를 구조로 막는 에이전트 설계: 승인 단계를 어디에 넣어야 하나

승인 게이트는 에이전트의 행동이 실행되기 전에 사람이 확인하는 단계다. 에이전트가 자율적으로 더 많은 작업을 처리하게 하면서도 치명적인 실수를 막으려면, 어디에 승인 단계를 넣을지를 설계해야 한다.

승인 단계가 너무 많으면 자동화의 이점이 사라진다. 너무 적으면 실수가 외부로 나간다. 최적의 위치는 작업 유형에 따라 다르지만, 일반적으로 적용 가능한 기준이 있다.

승인 게이트를 반드시 넣어야 하는 위치

1. 외부로 나가는 직전

이메일 발송, SNS 게시, API 호출, 파일 외부 전달 등 에이전트의 행동이 외부 시스템에 영향을 미치는 시점이다. 이 위치의 승인은 선택이 아니라 필수다. 여기서 실수가 발생하면 취소하거나 복구하는 데 직접적인 비용이 따른다.

운영 경험 기준으로, 외부 발송 직전에 승인 게이트 하나를 넣는 것만으로 에이전트 실수가 외부에 노출되는 빈도를 약 90% 이상 줄일 수 있다.

2. 되돌리기 어려운 삭제나 수정 직전

데이터 삭제, 기존 파일 덮어쓰기, 계정 설정 변경처럼 복구가 어렵거나 불가능한 작업 직전이다. "정말 삭제할 것인가"를 확인하는 단계가 있어야 한다. 에이전트가 빠르게 처리할수록 이 단계를 빼고 싶은 유혹이 생기지만, 1번의 실수로 발생하는 복구 비용이 수십 번의 승인 시간보다 크다.

3. 새로운 유형의 작업 최초 실행 시

에이전트가 처음 수행하는 유형의 작업은 결과를 예측하기 어렵다. 같은 작업 유형을 10회 이상 정상 완료하면 그 이후부터는 자동화로 전환할 수 있지만, 최초 실행 단계에서는 반드시 결과를 확인한다. 이 기준을 지키면 새로운 에이전트 기능을 추가할 때 리스크를 통제하면서 점진적으로 범위를 넓힐 수 있다.

승인 단계를 제거해도 되는 조건

조회, 읽기, 수집만 하는 경우

외부에 영향을 주지 않고 정보를 가져오는 작업은 승인 없이 진행해도 된다. 캘린더 확인, 파일 읽기, API 데이터 조회는 자율 실행이 가능하다.

같은 유형으로 30회 이상 정상 처리된 경우

충분한 반복 실행으로 결과 일관성이 검증된 작업은 승인 단계를 제거할 수 있다. 단, 조건이 변했을 때(입력 형식, 연결 서비스, 규칙 변경) 다시 검증 사이클로 돌아간다.

내부 저장이나 정리에만 영향을 주는 경우

메모 저장, 내부 태그 정리, 로컬 데이터 가공처럼 외부에 노출되지 않고 복구 가능한 작업은 자동화해도 된다.

승인 게이트의 실제 구현 방법

승인 게이트는 도구에 따라 다양하게 구현할 수 있지만, 핵심은 에이전트가 "실행 전 대기"하는 상태를 만드는 것이다.

에이전트가 작업 계획을 먼저 출력한다. "다음 작업을 실행하려 한다. 승인하겠는가?" 형식으로.
사람이 내용을 검토하고 실행 또는 취소를 선택한다.
승인되면 실행하고, 완료 결과를 기록에 남긴다.
취소되면 이유를 받아 다음 유사 상황에 참고한다.

이 흐름을 모든 외부 발송 작업에 적용한 결과, 사람이 직접 개입하는 시간은 작업당 평균 약 15초였다. 자동화된 처리 시간은 줄지 않으면서, 실수 노출 빈도는 거의 0에 수렴했다.

승인 구조를 설계할 때 흔히 하는 실수

모든 작업에 승인을 넣는 것

자동화를 불신해서 모든 단계에 승인을 넣으면 에이전트를 쓰는 이점이 없어진다. 승인은 꼭 필요한 위치에만 넣고 나머지는 자동화로 둔다.

승인 없이 시작하다가 나중에 추가하는 것

처음에는 빠르게 가기 위해 승인 없이 운영하다가 실수가 발생한 후에 승인을 추가하는 패턴이다. 실수가 외부에 노출된 후에는 이미 복구 비용이 발생했다. 외부로 나가는 작업은 처음부터 승인 구조로 설계한다.

승인 내용이 너무 길어서 실제로 읽지 않게 되는 것

승인 메시지가 길고 복잡하면 형식적으로 승인만 하게 된다. 승인 내용은 "무엇을, 어디로, 언제"를 3줄 이내로 압축한다. 이 원칙을 지키면 15초 안에 실제 검토가 가능하다.