LangGraph 에이전트는 언제 사람의 개입을 요청해야 할까?

우리는 신뢰도 점수가 좋은 신호가 아니라는 걸 금방 깨달았음. 결제 트리거, 이메일 발송, 데이터베이스 변경 같은 실제 작업이 발생할 때는 항상 사람의 개입(human in the loop)을 넣어야 함. 이게 사용자들 사이에서 신뢰를 쌓는 방법이기도 함.

모델의 confidence를 트리거로 쓰는 건 피하는 게 좋아. 보정 자체가 잘 안 되어 있고, 자신감 넘치게 틀리는 게 제일 위험하거든. 차라리 action risk를 기준으로 삼는 게 훨씬 낫지. 되돌릴 수 있는지, 영향 범위가 어느 정도인지(돈, 외부 메시지 발송, 데이터 삭제는 사람 확인 필수; 되돌릴 수 있는 읽기 작업은 제외)를 기준으로 인터럽트를 걸어. 이건 모델이 바뀌어도 안정적이거든. 그러고 나서 사람들이 얼마나 자주 승인/거부하는지 추적해 봐. 그러면 시간이 지남에 따라 어떤 게 너무 빡빡하거나 느슨한지 알 수 있을 거야.

다들 말하듯이 confidence보다는 action risk가 트리거로 훨씬 나음. 반대쪽에서 발생하는 실패 모드는 '승인 피로'임. 너무 빡빡하게 게이트를 걸면 사람이 그냥 도장 찍는 기계가 되어버려서, 안전성은 안 늘고 지연 시간만 늘어남. 효과적이었던 건 각 인터럽트를 영구적인 정책으로 만드는 거였음(앞으로 이런 종류의 작업은 승인한다). 이렇게 하면 똑같은 질문을 계속 반복하는 대신 큐가 줄어들거든.

모델의 raw confidence를 주된 기준으로 삼지는 않을 거임. 약한 신호로는 쓸만하지만, 진짜 골치 아픈 실패 사례들은 보통 모델이 높은 확신을 가지고 틀리는 경우거든.

더 나은 패턴은 action contract를 기준으로 게이트를 거는 거임:

• 되돌릴 수 있는 읽기/분류: 에이전트가 계속하게 두되, 입력값과 출력값은 로그로 남김
• 쉽게 롤백 가능한 내부 쓰기: diff나 영수증을 생성할 수 있다면 계속 진행하고, 샘플 리뷰 정도만 함
• 외부 사이드 이펙트(이메일, 결제, 고객에게 보이는 메시지, 티켓 상태 변경 등): …

우리한테 confidence는 전혀 안 먹혔음. 몇 달 동안이나 수치가 잘못 잡혔거든. 중요한 건 그 작업이 되돌릴 수 있는가였어. 재시도나 DB 읽기는 절대 interrupt() 안 걸어. 메시지 보내기, 카드 결제, 행 삭제 같은 건 점수랑 상관없이 무조건 interrupt() 걸리게 했지. 앱이 성숙해지면서 confidence threshold 대신 하드코딩된 리스트를 썼는데, 딱 5개 툴 이름만 들어감. 그거 관리하려고 impri라는 작은 오픈소스 게이트를 만들었는데, 딱 그 호출들만 막아줌.