#다중 도구를 병렬 호출할 때, 대화 상태는 먼저 갱신하나 나중에 갱신하나

← 전체 목차 · 이전: 여러 Agent가 같은 도구를 동시에 부를 수 있는가 · 다음: 제3자 도구가 갑자기 요청을 제한하면, 재시도가 왜 오히려 눈사태를 키우는가

"도구를 먼저 불러 결과를 받은 다음 대화 상태를 갱신하고, 안 되면 한 번 더 재시도한다"는 답은 순서 하나만 놓고 보면 그럴듯하지만, 순서를 어느 쪽으로 두든 각자 다른 구멍이 뚫린다. 이 문제의 본질은 순서 기억 문제가 아니라 분산 상태 일관성 설계 문제다.

#어느 순서를 택하든 구멍은 남는다

[선갱신을 택하면]
T1  상태 = "대기 실행"으로 표시
T2  도구 호출 중(아직 반환 전)
T3  새 추론 요청이 들어와 → 아직 옛 상태를 그대로 읽고 → 계속 생성
T4  데이터 어긋남 → 오염 상태(더러운 상태)

[후갱신을 택하면]
도구 실행 성공 → 상태 회신을 쓰는 순간 동시성 충돌로 덮어써짐
→ Agent가 자신이 방금 무엇을 했는지 모르게 됨
→ 데이터는 계속 어긋나고, 이후 모든 추론이 잘못된 상태 위에서 진행됨

여기서 "재시도 횟수를 늘리면 되지 않는가"는 방향이 틀린 질문이다. 재시도는 "호출 실패"의 해법이지 "동시 읽기 충돌"의 해법이 아니다. 재시도 횟수와 실행 소요 시간차는 서로 무관한 두 변수이므로, 동시성 시나리오에서는 몇 번을 재시도해도 옛 상태를 읽을 가능성이 그대로 남는다.

#정의부터 바로잡기: 강일관성이 아니라 수용 가능한 최종 일관성

Agent의 일관성은 **강일관성이 아니라 "수용 가능한 최종 일관성"**이다. 이 경계를 먼저 낮춰야 뒤에 나오는 비동기 보정·자연 만료·극단 다운그레이드 같은 방안들이 "허술함"이 아니라 "설계"로 성립한다.

#기준안: 선실행 + 트랜잭션 커밋 후 비동기 상태 갱신

배치 시나리오는 단일 로직을 그대로 순회 확대하면 안 된다. "다중 Agent × N개 작업"에서 개별 Agent 상태를 하나씩 순회 동기화하는 것은 전형적인 오설계이며, 정답은 입도를 바꾸는 것이다 — 배치 표식 위로 전체를 한 번에 수렴 판정하고, 상태 자연 만료로 마지막 안전망을 둔다.

#생산 배치 디테일

호출 실패 → 분급 재시도
   로컬 재시도 3회 → MQ 비동기 재시도 → 데드레터 사람 개입
   (무한 재시도로 도구 서비스를 무너뜨리지 않도록)

다중 Agent 지연 → 쓰기 후 읽기 일관성
   쓰기 직후 짧은 시간 창구 내 읽기 요청은 강제로 주 상태 노드를 경유
   또는 읽기 지연 대기를 설정

모니터링 → 업무 중요도별 분급
   도구 호출 성공률 / 상태 갱신 실패율 / 작업 불일치 경보

극단 다운그레이드 → 비핵심 업무
   능동 상태 동기화를 아예 포기하고
   세션 타임아웃에 의한 자연 리셋만으로 대체 — 시스템 안정성과 맞바꿈

#핵심 통찰

1. 이 문제의 본질은 분산 상태 일관성이지 도구 호출 순서 암기가 아니다 — 순서만 바꿔 답하려 하면 두 가지 구멍(선갱신의 옛값 읽기, 후갱신의 덮어쓰기 유실) 중 하나로 반드시 떨어진다. 어느 쪽으로 답해도 "그다음 어떻게 막을 것인가"가 이어지지 않으면 답이 완성되지 않는다.
2. 순서를 바꾸는 것은 불일치를 없애는 것이 아니라 불일치의 형태만 바꾸는 것이다 — 선갱신은 "상태는 대기중인데 도구는 아직"이라는 옛값 읽기를 낳고, 후갱신은 "도구는 이미 실행했는데 회신이 덮어써짐"이라는 갱신 유실을 낳는다. 그래서 락, 버전 번호, 비동기 보정으로 보완해야지 둘 중 하나를 고르는 것으로 끝나지 않는다.
3. 재시도는 "실패"의 해법이지 "동시성"의 해법이 아니다 — 재시도 횟수를 3에서 5로 늘려도 옛 상태를 읽는 문제는 풀리지 않는다. 재시도 횟수와 실행 시간차는 서로 다른 두 변수이기 때문이다. "이 구멍은 재시도로 못 고친다"는 것을 식별하는 것 자체가 분수령이다.
4. "수용 가능한 최종 일관성"을 먼저 정의해야 답에 착지점이 생긴다 — 경계를 강일관성에서 최종 일관성으로 낮추지 않으면, 이후에 나오는 비동기 보정·자연 만료·극단 다운그레이드가 전부 "엄밀하지 않다"는 인상을 준다. 경계 정의는 수사가 아니라 설계의 첫 단계다.
5. 실효 시나리오를 목록화하는 것은 모호한 문제를 답할 수 있는 문제로 바꾸는 범용 기법이다 — 동시 읽기/쓰기·네트워크 실패·배치 누락·메시지 지연·비동기 소비 실패 다섯 가지를 나열하면 방안이 항목별로 대응되고 답변 자체도 자연히 구조를 갖춘다.
6. 배치 시나리오는 단일 로직을 순회로 확대하면 안 된다 — "N개 Agent 상태를 하나씩 순회 동기화"는 전형적으로 단체 방안을 배치에 그대로 씌운 오설계다. 정답은 입도를 바꾸는 것: 배치 표식 위로 전체를 수렴시키고 상태 자연 만료로 뒷받침한다.
7. 좋은 방안은 반드시 다운그레이드 경로를 함께 지닌다 — 비핵심 업무는 능동 동기화를 포기하고 세션 타임아웃 자연 리셋으로 대체할 수 있다는 것 자체가, 모든 업무에 같은 강도의 일관성을 강제하지 않는다는 설계 판단이다.
8. 일관성은 결국 관측 가능성의 폐루프로만 증명된다 — 도구 호출 성공률·상태 갱신 실패율·작업 불일치 경보 세 지표가 동시에 감시돼야 "최종적으로 수렴했다"가 자체 선언이 아니라 근거를 갖는다.

#엔지니어링 실전 Tips

• 재시도는 상한과 종점을 반드시 둘 것: 로컬 3회 → MQ 비동기 → 데드레터 사람 개입은 종점이 있는 체인이다. 무한 재시도의 부작용은 이미 불안정한 도구 서비스를 완전히 무너뜨리는 것이다.
• 데드레터 큐는 쓰레기통이 아니라 경보 소스로 취급할 것: 상태 갱신 실패가 자동으로 데드레터에 들어가고 경보가 울려야 "최종 일관성"에 사람이 개입할 최후의 고리가 생긴다.
• 동시 쓰기에는 예외 없이 버전 번호를 붙일 것: 상태 단기 락이 창구를 통제하고 버전 번호가 덮어쓰기를 식별해야, 옛값 읽기와 갱신 유실을 동시에 막을 수 있다.
• 배치 작업은 순회 대신 표식 위를 쓸 것: 배치 표식 위는 N번의 상태 동기를 한 번의 수렴 판정으로 압축하고, 상태 자연 만료가 뒷받침한다 — 순회 동기보다 태생적으로 가볍다.
• 다중 Agent 지연에는 "주 읽기" 스위치를 준비할 것: 쓰기 직후 짧은 시간 강제로 주 상태 노드를 읽게 하는 것이 비용이 가장 낮은 쓰기 후 읽기 일관성 수단이며, 안 되면 읽기 지연 대기로 물러선다.
• 다운그레이드는 사전에 등급을 나눠둘 것: 업무 중요도로 먼저 분류해 핵심 업무는 동기를 보장하고, 비핵심 업무는 세션 타임아웃 자연 회복을 허용한다는 결정을 미리 내려야 한다 — 사고 현장에서 즉석 결정하면 늦는다.