에이전트를 위한 6가지 인간 개입 패턴: 가벼운 확인부터 완전 승인까지

나한테 4단계와 5단계의 경계는 신뢰도가 아니라 가역성임. 사람이 몇 분 안에 작업을 되돌릴 수 있고 외부로 나가는 게 없다면(초안, 저장된 양식, 내부 티켓 등), 초안 작성 후 전송 단계로 충분함. 돈이 나가거나, 최종 제출을 하거나, 외부인과 접촉하는 순간, 에이전트의 신뢰도 점수가 어떻든 간에 확실한 게이트가 필요함. 실무에서 중요했던 두 가지 디테일: 게이트는 에이전트가 스스로 답할 수 없는 것이어야 하고(모델을 거쳐 돌아오는 질문이 아니라 사람만 볼 수 있는 질문), 승인 화면은 에이전트의 요약이 아니라 에이전트가 작업한 후의 실제 페이지나 시스템 상태를 보여줘야 함. 빈 양식 필드를 '검증됨'이라고 보고하는 에이전트를 겪어봐서, 이제 요약은 믿지 않기로 했음.

지원 업무에서는 실수의 영향 범위가 전부임. 잘못된 이메일이 나가면 당황스럽고 수습 전화가 필요할 수도 있지만, 보통 세상이 망하는 건 아님. 그래서 초안 작성 후 전송이 먹히는 거임. 돈이 움직이거나 운영 설정이 바뀌는 순간, 피해가 걷잡을 수 없이 커질 수 있어서 반드시 게이트를 거쳐야 함.

난 5분 규칙을 적용하는데, 5분 안에 피해를 되돌릴 수 없으면 무조건 승인이 필요함.

우리가 긋는 경계는 신뢰도나 가역성이 아니라 재사용성임. 특정 페이로드가 아니라 작업 유형에 묶인 게이트는 한 번 승인하면 그 뒤의 모든 작업까지 커버하게 되는데, 이건 아예 안 묻는 거랑 똑같음. 우리 건 몇 분 뒤에 만료되고 딱 그 한 번의 전송 내용에만 묶여 있어서, 이메일 하나에 대한 승인이 몇 초 뒤의 다음 이메일까지 자동으로 커버하지 않음.

우리는 신뢰도가 아니라 메시지가 무엇을 시작하느냐에 따라 경계를 정함. 이미 존재하는 대화 내의 답장은 작성된 체크리스트(스레드 열려 있음, 규칙 읽음, 약속한 것 없음, 개인 번호 없음)를 거친 후 전송됨. 최악의 경우 삭제된 댓글 하나니까. 사람에게 보내는 첫 메시지는 승인이 필요하거나, 딱 그 단계에만 한정된 상시 허가가 필요함. 돈을 쓰거나 무언가를 약속하는 건 항상 사람의 승인을 기다려야 함. 그리고 '전송됨, 결과 알 수 없음' 상태도 추가하고 싶은데, 위험한 건 잘못된 메시지가 아니라 성공 여부를 증명할 수 없는 메시지이기 때문임.

자동화하기 가장 어려운 게이트는 에이전트가 사용자가 말한 것뿐만 아니라 실제로 원하는 게 뭔지 알아야 할 때임. 요약 후에 '의도 확인' 단계를 간단히 넣는 게 어떤 신뢰도 점수보다 더 도움이 됨.