완전 자동화의 유혹
자동화 시스템을 처음 구축하면 "완전히 자동으로 돌아가는 것"이 목표처럼 느껴진다. 사람이 개입하지 않아도 모든 것이 처리되는 상태. 그 감각이 주는 편의감은 실제로 크다. 메일이 오면 정리되고, 콘텐츠가 생성되고, 보고서가 발송된다. 사람은 결과만 본다.
그런데 이 상태가 한 번 잘못 작동하면 수정보다 피해 수습이 먼저가 된다. 잘못된 내용이 외부로 나가거나, 삭제해선 안 되는 데이터가 지워지거나, 잘못된 정보를 기반으로 다음 행동이 이어진다. 자동화가 실수를 증폭시키는 구조가 된다.
완전 자동화가 나쁜 것이 아니다. 문제는 어느 단계에 사람이 개입해야 하는지를 설계하지 않은 채 자동화를 쌓는 것이다.
시스템이 스스로 잘못 판단하는 지점
실제 운영 경험에서 자동화 시스템이 가장 많이 실패하는 지점은 세 가지다.
맥락 없이 판단해야 할 때. 시스템은 정해진 규칙에 따라 움직인다. 하지만 현실은 규칙 바깥의 상황이 자주 발생한다. 예를 들어 "승인된 콘텐츠를 발행한다"는 규칙이 있어도, 외부 사건으로 해당 주제가 갑자기 민감해지는 상황이 생긴다. 시스템은 그 맥락을 모른다.
여러 단계가 연쇄될 때. 단계가 많을수록 앞 단계의 오류가 다음 단계로 전파된다. 첫 번째 에이전트가 잘못된 요약을 만들면, 두 번째 에이전트가 그 요약을 기반으로 잘못된 콘텐츠를 만들고, 세 번째 에이전트가 그 콘텐츠를 발행한다. 자동화 깊이가 깊을수록 실수가 보정되기 어렵다.
판단 기준이 바뀌었을 때. 시스템은 설계 시점의 기준으로 움직인다. 비즈니스 상황이나 우선순위가 바뀌었는데 시스템은 이전 기준으로 계속 작동한다. 이 경우 시스템이 "틀린 일을 정확하게" 하는 상태가 된다.
사람이 개입해야 하는 단계
모든 단계를 사람이 확인할 수는 없다. 그렇게 하면 자동화의 의미가 없다. 핵심은 어느 지점에 체크포인트를 두느냐다.
외부로 나가는 모든 행동 직전. 발송, 발행, 전송처럼 되돌리기 어려운 행동은 자동화 이전에 사람이 확인한다. 에이전트가 초안을 만들고, 사람이 승인하고, 그 다음에 실행된다. 이 순서를 바꾸지 않는다.
삭제와 수정 직전. 데이터 삭제, 설정 변경, 계정 수정은 복구가 어렵다. 에이전트가 "삭제해야 할 항목 목록"을 제안하고, 사람이 확인 후 실행하는 방식이 낫다.
새로운 패턴이 처음 등장할 때. 시스템이 처음 마주치는 유형의 요청이나 상황에서는 자동으로 처리하지 않는다. "처음 보는 케이스"는 사람에게 넘긴다. 이후 같은 케이스가 반복되면 그때 자동화 규칙을 추가한다.
승인 설계를 간단하게 유지하는 방법
승인 단계가 많아지면 자동화의 속도 이점이 사라진다. 승인 설계는 최소화하는 방향으로 구성한다.
배치 승인. 개별 건마다 승인을 받지 않고, 하루치나 주간 단위로 묶어서 한 번에 확인한다. 5개 메일을 각각 승인하는 대신, "오늘 발송 예정 5건"을 한번에 검토한다.
예외 처리만 넘기기. 정해진 기준에 맞는 건은 자동 처리하고, 기준 바깥의 건만 사람에게 넘긴다. 90%는 자동으로 처리되고, 10%만 확인하는 구조다.
승인 경로를 단순하게. 승인 요청이 오면 한 번의 답변으로 처리할 수 있어야 한다. "예/아니오" 또는 "승인/거절/수정" 세 가지 선택지로 끝나야 한다. 승인 과정 자체가 복잡하면 사람이 확인을 미루게 된다.
실제 운영에서 유지하는 원칙
자동화 시스템을 몇 달 운영하다 보면 어느 지점에서 문제가 자주 생기는지가 보인다. 그 지점이 체크포인트가 되어야 할 곳이다.
처음부터 완벽한 설계는 불가능하다. 자동화를 시작하고, 실수가 생기고, 그 실수가 반복되는 지점에 체크포인트를 추가하는 방식으로 점진적으로 안전해진다. 시스템은 처음보다 나중이 더 안전해야 한다. 처음부터 완전히 안전하게 설계하려 하면 자동화를 시작하지 못한다.
사람이 확인하는 비용을 줄이는 것이 목표가 아니다. 잘못됐을 때 피해가 작은 구조를 만드는 것이 목표다.