멀티 에이전트 시스템의 재시도(retry) 문제로 골치 아프네요 — 다들 복구는 어떻게 처리하시나요?

Dedup key랑 단계별 체크포인트가 프로덕션의 기본이다. 중복 적용을 막고 전체 재실행을 피할 수 있음. 주의할 점은 다운스트림 소비자가 결과를 보기 전에 체크포인트를 먼저 써야 한다는 거임. 안 그러면 실제로 존재하지도 않았던 상태에서 재개하게 됨.

멱등성 키와 체크포인트 상태가 우리한테는 가장 큰 성과였음. 재시도가 '다시 돌리고 기도하기'가 아니라 '재생 가능'해지면 복구가 훨씬 덜 무서워지거든.

무작정 재시도하는 것보다 재실행 가능하게 만드는 게 무조건 낫다. 단계를 결정론적으로 재실행할 수 있게 되면, 복구는 기도 메타가 아니라 논리 문제가 됨. 이런 사고방식의 전환이 저평가되어 있는데, 패턴은 같아도 운영 방식은 완전히 달라짐.

위에서 언급된 idempotency-key와 checkpoint 답변들이 올바른 기반이라서, 굳이 반복하기보다는 그 내용을 바탕으로 덧붙여볼게. 그 답변들이 제대로 다루지 못한 부분이 바로 네가 말한 최악의 상황, 즉 아무런 에러도 발생하지 않았는데 시스템이 제대로 완료되지 않은 부분 실패(partial failure)야. 이건 재시도보다는 탐지에 관한 문제지. Idempotency 덕분에 재시도는 안전하게 할 수 있지만, '성공'이라고 반환된 단계가 실제로 올바른 작업을 수행했는지에 대해서는 아무것도 알려주지 않아. 대부분의 에이전트 프레임워크는 'the mo...

기대치 관리

나한테 효과 있었던 해결책 두 가지: 재시도 전에 실패 유형을 분류하는 것. 429 에러나 타임아웃은 재시도할 가치가 있지만, 잘못된 툴 호출이나 로직 에러는 그냥 돈만 날릴 뿐임. 모델은 자기가 루프 돌고 있는지도 모르고 똑같은 삽질을 영원히 반복할 테니까. 그리고 노드별로 상태를 디스크에 체크포인트 해두는 것. 그래야 전체 그래프를 다시 돌릴 필요 없이 마지막으로 성공한 단계부터 복구할 수 있음. 처음부터 다시 돌리는 게 바로 사소한 툴 호출 에러를 연쇄 장애로 만드는 주범임.

나도 에이전트 런타임으로 비슷한 거 겪었는데, 재시작/재개 기능이 이론상이나 레포상으로는 깔끔해 보였는데 정작 중요한 부분에서 터지더라. 부분적인 런타임 재시작 이후에 작업을 제대로 이어가는 거 말이야. 몇 시간 동안 디버깅하면서 코드만 쳐다보고 Claude한테도 검토 맡긴 끝에 겨우 문제 찾았음. 이전 세션에 다시 연결하는 건 잘 됐거든. 다음 턴 보내는 것도 잘 되는 것처럼 보였고. 근데 재개된 이전 세션에서 스트리밍되는 결과값이 재시작 후에 멈추거나 리셋되면서 잠겨버리더라고...

짜증 나는 답변이겠지만, 난 에이전트가 알아서 복구할 거라는 걸 별로 안 믿음. 난 체크포인트, idempotency key, 로그, 그리고 아주 지루한 상태 머신을 믿지. 재시작은 그 단계에 side effect가 없을 때나 괜찮은 거야. 갑자기 '다시 시도'가 이메일 중복 발송, 레코드 중복 생성, 혹은 밤 11시에 아무도 디버깅하고 싶지 않은 저주받은 반쯤 끝난 워크플로우를 의미하게 되거든. 그래서 내 원칙은 이거임: 읽기 작업은 마음껏 재시도하고, 쓰기 작업은 신중하게 재시도하며, 에이전트가 어디서 멈췄는지 추측하게 두지 마라.

무지성 재시도는 보통 잘못된 해결책임. 토큰만 날리고 가끔 side effect를 두 번 발생시키기도 하거든. 우리한테 더 효과적이었던 건 툴을 idempotent하게 만들고 플래너가 추론할 수 있는 구조화된 에러를 반환하게 하는 거였음. 그러면 실패한 단계가 그냥 조용히 삼키고 재시도하는 예외가 아니라, 에이전트가 인식할 수 있는 상태가 되는 거지.