AI 에이전트가 위험한 작업(환불, 결제 등)을 수행할 때 사람의 승인을 어떻게 처리하시나요?

이건 정말 현실적인 문제예요. 에이전트에게 어떤 종류든 쓰기 권한을 주는 순간, 기본적으로 소규모 변경 관리 흐름이 필요하게 되죠.

저에게 가장 효과적이었던 건 승인을 일급 객체(first-class artifact)로 취급하는 것이었어요. '승인 객체'(작업 유형, 파라미터, 위험 수준, 변경 사항/미리보기, 승인자, 타임스탬프)를 만들고, 단일 경로(슬랙/팀즈 등)로 라우팅한 뒤, 서명된 토큰을 받아야만 에이전트가 진행하게 하는 거죠. 작업 전후의 전체 페이로드를 기록하고 재실행하기 쉽게 만들면 금상첨화고요.

100% 공감해요. '에이전트에게 쓰기 권한을 주는 순간, 소규모 변경 관리 흐름이 필요하다'는 말, 제가 생각하던 것과 정확히 일치해요. 승인을 일급 객체로 보는 것도 딱 맞고요. 작업 유형, 파라미터, 위험도, 변경 사항/미리보기, 누가/언제 승인했는지, 그리고 서명된 토큰 없이는 진행하지 않는 것. 제가 만들고 있는 구조와 거의 똑같네요.

그 위에 제가 계속 집착하는 한 가지 측면은 라우팅/전달 단계예요. 슬랙/팀즈로 라우팅은 하지만, 승인 요청이 그냥... 방치된 적 없나요? 승인자들은...

우리는 승인을 알림이 아니라 또 다른 워크플로우 상태로 취급하게 됐어요. 에이전트가 일시 정지하고, 왜 요청하는지 기록하고, 결정을 기다렸다가 재개하는 방식이죠. 승인 채널 자체보다 그런 감사 추적(audit trail)을 갖는 게 훨씬 중요했어요.

네, 워크플로우 상태로 취급하는 것(일시 정지, 이유 기록, 대기, 재개)이 정확히 맞는 방향이에요. 그냥 던져놓고 잊어버리는 알림보다 훨씬 깔끔하죠.

'채널보다 감사 추적이 더 중요하다'는 말이 정말 흥미롭네요. 승인자들이 어떤 환경이었는지 물어봐도 될까요? 제 추측으로는, 승인자들이 이미 슬랙을 쓰거나 책상 앞에 앉아 있다면 채널은 '그냥 잘 작동'하니까 감사 추적이 가치를 발하는 것 같아요. 제가 본 채널의 문제는 승인자가 키보드 앞에 없을 때였는데...

위험한 작업의 경우, 승인을 사이드 채널 알림이 아니라 워크플로우의 상태 전환으로 만들겠어요.

저에게 가장 효과적이었던 형태는 이렇습니다:

1. 에이전트가 작업 유형, 리소스 ID, 정규화된 파라미터, 위험 수준, 이유, 변경 전후 미리보기, 만료 시간, 멱등성 키를 포함한 승인 요청을 생성함.
2. 워크플로우가 waiting_for_approval 상태로 이동하고 해당 분기 실행을 멈춤. 숨겨진 재시도 루프나 기본 승인 경로는 없음.
3. 승인자는 정확한 변경 사항/미리보기와 충분한 컨텍스트를 확인...