승인 게이트, 에이전트를 믿지 않고도 안심하고 쓰는 법

환불이 "완료됐다"는 보고를 받았는데, 사실은 안 됐던 날

에이전트가 고객 환불을 처리하고 "환불 완료했습니다"라고 보고한 날이 있었습니다. 저는 그걸 믿고 고객에게 "환불 처리됐습니다"라고 답장까지 보냈습니다. 그런데 다음날 PG사 대시보드를 열어보니 그 환불은 처리된 적이 없었습니다. 취소 가능 한도가 사전 예치금을 요구하는 규칙에 막혀 있었던 겁니다. 에이전트는 버튼을 눌렀고, 화면이 뭔가 반응했고, 그걸 "완료"로 보고했습니다. 하지만 버튼 클릭과 실제 완료는 다른 상태입니다.

이 사고 이후로 제 모든 워크플로우에는 한 문장이 박혀 있습니다. "클릭은 확인이 아니다. 상태를 바꾸는 모든 행동 후에는 완료 보고 전에 화면에 나타난 결과 상태를 검증할 것." 이게 승인 게이트라는 시스템의 절반입니다. 나머지 절반은 애초에 에이전트가 특정 행동을 하기 전에 사람이 확인하는 구조입니다.

신뢰가 아니라 아키텍처

직원 없이 회사 하나를 운영한다는 약속 전체는 에이전트가 되돌릴 수 없고 잘못된 일을 하는 단 하루에 무너집니다. 돈을 잘못 보내고, 정부에 틀린 서류를 제출하고, 고객 전체에게 오류가 있는 메일을 보내고, 프로덕션 데이터를 지우는 그 하루요. 이 두려움 때문에 많은 창업자가 AI를 그냥 "채팅 장난감" 수준에 묶어둡니다.

제가 찾은 답은 신뢰가 아니라 아키텍처였습니다. 에이전트를 믿을지 말지 고민하는 대신, 애초에 신뢰가 필요 없는 구조를 만드는 겁니다. 원칙은 하나입니다. 에이전트가 초안을 만들고, 사람이 승인하고, 에이전트가 실행한다.

이걸 실제로 쓰려면 먼저 모든 행동을 되돌릴 수 있는 정도로 분류해야 합니다.

C등급에 반드시 들어가야 하는 항목은 명확합니다. 송금, 정부·법률 기관 제출, 공개 게시, 고객에게 나가는 이메일, 프로덕션 배포, 계약 동의나 서명. 이 목록은 "아무리 일상적으로 느껴져도" 예외를 두지 않는 게 핵심입니다. 매일 하는 반복 작업일수록 오히려 안일해지기 쉽기 때문입니다.

게이트는 한 겹으로는 반드시 뚫린다

처음에는 프롬프트에 "초안만 만들고 절대 발송하지 마세요"라고 써두는 것만으로 충분하다고 생각했습니다. 그런데 "고객 답장을 처리해 줘"라는 애매한 지시 하나에 "처리"가 "발송"과 위험할 만큼 가까운 의미로 해석된 적이 있습니다. 그때부터 게이트를 세 겹으로 겁니다. 프롬프트 수준("초안만, 절대 발송 금지"), 워크플로우 수준(발송에 제 클릭이 필요한 도구에 초안을 스테이징), 플랫폼 수준(에이전트에게 애초에 권한이 없음 — 읽기 전용 API 키, 지출 상한, 계좌이체 권한 없음). 어느 한 겹은 반드시 실패한다는 전제로 설계해야 실제로 안전합니다.

그리고 게이트는 운영하는 데 비용이 싸야 합니다. 그렇지 않으면 바쁜 날 제 손으로 게이트를 건너뛰게 됩니다. 배치된 다이제스트, 원탭 승인, 미리 포맷된 리뷰 화면이면 승인 비용이 몇 초로 줄어듭니다. 비싼 게이트는 결국 우회됩니다.

게이트가 실제로 잡아낸 사고들

• 막힌 환불을 "완료"로 착각. 앞서 말한 사례입니다. 상태 검증 규칙이 나온 계기였고, 지금은 PG사 화면에 환불이 실제로 뜨기 전까지는 고객에게 절대 "환불 완료"라고 말하지 않습니다.
• 다크 패턴으로의 표류. 구독 우선 경쟁사를 벤치마킹하던 에이전트가 결제 화면에서 일회성 구매 옵션을 숨기자고 제안한 적이 있습니다. 단기적으로는 전환율에 도움이 될 수 있지만 브랜드를 갉아먹는 방식입니다. "구독은 기본값일 수는 있어도 절대 덫이어서는 안 된다"는 규칙이 이때 메모리에 박혔습니다.
• 자신만만한 오분류. 장부 자동 분류 초기, 신뢰도 컬럼을 강제하기 전에 에이전트가 병원비 지출을 "직원 복리후생"으로 분류한 적이 있습니다. 직원이 한 명도 없는 회사인데도요. 신뢰도 스코어링과 "모르겠으면 사람에게 묻는다"는 탈출구를 넣자 이런 종류의 문제 대부분이 사라졌습니다.
• 자동 제출 유혹. 몇 달간 지원사업 신청서 초안 품질이 계속 좋았습니다. 그러자 "이 정도면 자동 제출해도 되지 않을까"라는 생각이 들었던 순간이 있었습니다. 하지 않았습니다. 그 직후 초안 하나에 미묘하게 낡은 자격 요건 주장이 섞여 있는 걸 발견했습니다. 게이트는 실수만 잡은 게 아니라 제 안일함을 잡았습니다.
• 공유 컴포넌트 오염. 결제 페이지 리뉴얼이 다른 페이지와 공유되는 컴포넌트의 스타일을 바꿔서 엉뚱한 곳의 레이아웃이 깨진 적이 있습니다. 별도 세션이 리뷰어 역할을 맡아 "공유 컴포넌트를 건드리기 전에 모든 사용처를 grep해서 나열할 것"을 확인하게 하자 재발이 멈췄습니다.

실제로 이 게이트 구조를 새 워크플로우에 붙일 때 쓰는 프롬프트는 이렇습니다.

상시 가드레일 (모든 작업에 로드):
- 행동 등급: A) 가역 → 진행; B) 비용성 가역 → 리뷰 패스와 상태
  검증을 거칠 것; C) 비가역 (송금, 제출, 공개 게시, 고객 커뮤니케이션,
  계약, 삭제) → 준비만 하고 내 명시적 승인을 위해 스테이징할 것.
- 금지 목록: [본인의 절대 금지 사항, 예: 주민등록번호/카드 보안코드
  입력 금지, 계약 서명 금지, 정부 신청서 최종 제출 금지].
- 클릭은 확인이 아니다: 상태를 바꾸는 모든 행동 후에는 완료 보고 전에
  화면에서 결과 상태를 검증할 것.
- 어떤 행동이 어느 등급인지 확신이 없으면 C로 취급하고 물어볼 것.
이 블록의 위반만이 용서받지 못하는 유일한 실패 모드입니다.

승인률이 100%로 계속 찍히는 주가 있다면, 그건 에이전트에 대한 칭찬이 아니라 제 자신에 대한 경고 신호로 읽습니다. 진짜로 검토하고 있다면 가끔은 뭔가를 고치거나 거절하는 게 정상이니까요. 게이트는 자동화의 타협안이 아니라, 그 자체가 자동화 전략입니다. 게이트는 100시간의 실행을 1시간의 리뷰로 바꿔주고, 그 1시간은 한 사람이 실제로 감당할 수 있는 크기입니다.