AI 에이전트의 API 호출 시 재시도 처리 방법

일시적 오류: 지수 백오프(exponential backoff)를 사용한 자동 재시도와 최대 횟수 제한을 두고, 모두 소진 시 사람에게 알림을 보냄.
비멱등성 호출: 호출하는 서비스에 따라 다름. 잘 설계된 서비스라면 에이전트가 재시도 여부를 판단할 수 있도록 적절한 오류를 반환함. 서버에서 무슨 일이 일어났는지 알 수 있는 상태값이 없기 때문에 클라이언트 측에서 멱등성 검사를 하는 건 사실상 불가능함. 그건 그냥 재시도를 막는 것밖에 안 됨. 따라서 서버가 무엇이 잘못되었는지 알려주지 않는 한, 이런 건 실패로 간주하고 사람에게 에스컬레이션해야 한다고 봄.
잘못된 매개변수: 에이전트는 4xx 오류가 발생했을 때 스스로 실수를 파악할 수 있어야 함.
다단계 흐름에서의 부분 실패: 케이스 바이 케이스임. 딱 맞는 정답은 없다고 봄. 하지만 각 단계에서 실패 시 에이전트가 어떻게 복구해야 할지 지시할 수 있어야 함. 사람이(혹은 비에이전트 레거시 시스템이) 하는 것과 똑같음.

API든 워크플로우든 상관없음. 전부 똑같은 분산 시스템 문제임. 바뀐 건 오직 액터(에이전트)뿐임. 말했듯이 다단계 처리는 케이스 바이 케이스임. 각 단계별 성공 및 롤백 조건이 무엇인지, 워크플로우당 몇 단계가 완료되거나 롤백되어야 하는지 등을 정의할 수 있는 건 본인뿐임.

재시도 로직은 모델 밖으로 빼야 함. 에이전트는 오직 '완료' 또는 '실패'만 봐야 함. 에이전트가 스스로 이메일 전송을 재시도하기로 결정하는 순간 이메일이 두 번 발송될 테니까. 첫 번째 시도 전에 멱등성 키를 만들어서 단계와 함께 저장하고, 재시도 계층이 그걸 재사용하게 만드셈.

'클라이언트 측 멱등성 처리는 불가능하다'는 의견에는 조금 반대함. 클라이언트 혼자서 중복 제거를 할 수는 없지만, 재시도하기 전에 확인 절차를 거치게 할 수는 있음. 실제로 사람들을 괴롭히는 건 5xx 오류가 아니라 타임아웃임. 5xx는 보통 처리가 안 됐다는 뜻이지만, 타임아웃은 무슨 일이 일어났는지 알 수 없다는 뜻이니까.

내가 효과를 본 방법은 모든 쓰기 작업에 첫 시도 전 생성한 참조값을 찍는 거임. 실행 ID와 단계 번호를 API가 허용하는 필드(결제 메타데이터, 커스텀 헤더, 메시지 ID 등)에 넣는 식임. 제공자가 멱등성 키를 지원하면 같은 값을 쓰면 됨. 지원하지 않으면 재시도 계층이 먼저 그 참조값으로 조회를 해서 결과가 없을 때만 다시 보냄. 찾으면 해당 단계를 완료 처리하고 넘어가는 거임.

모델은 이런 과정을 전혀 보지 못함. 모델은 '완료'나 '실패'만 전달받고, '실패'는 조회를 해봐도 정말로 데이터가 없을 때만 발생함.