← 뉴스 타래 목록

에이전트 재시도와 중단을 견디는 애플리케이션 상태 관리

에이전트의 재시도 문제는 모델의 추론보다 요청 결과가 불명확한 상황과 외부 부작용을 어떻게 기록·통제하느냐에 달려 있습니다. 세 글은 작업 의도와 멱등성 키, 애플리케이션이 소유하는 워크플로 상태, 독립적인 대사를 각각 다루며, 안전한 재시도에는 이 관리 방식들이 함께 필요하다고 설명합니다.

응답이 없을 때는 실패로 단정하지 않습니다

‘에이전트의 재시도 버그는 AI 문제가 아닙니다. LLM을 얹은 분산 시스템 문제입니다’는 환불 요청이 결제 서비스에서 처리됐지만 응답이 유실되는 예를 듭니다. 에이전트 관점의 타임아웃만으로는 요청이 도달하지 않았는지, 거절됐는지, 성공 후 응답만 사라졌는지 알 수 없으므로, 이를 모두 실패로 취급해 자동 재시도하면 환불이 중복될 수 있습니다. 글은 애플리케이션이 첫 시도 전에 의도와 멱등성 키를 영속 저장하고, 타임아웃 뒤에는 상태를 ‘실패’가 아니라 ‘불명’으로 기록하자고 제안합니다. 키는 모델이 만들거나 시도마다 새로 발급하는 것이 아니라 같은 의도의 재시도에 재사용해야 합니다.

이 문제는 에이전트에만 국한되지 않습니다. ‘같은 깨달음을 15년째 반복합니다 — 에이전트 시대가 다시 발견하는 분산 시스템의 원칙’도 웹훅을 동시에 두 번 처리할 때 두 요청이 모두 미처리 상태를 확인한 뒤 중복으로 진행할 수 있다고 설명합니다. 이 글은 이벤트 식별자에 대한 데이터베이스 고유성 제약과 중복 기록·업무 쓰기의 단일 트랜잭션 처리를 제시합니다. 즉 환불 사례는 재시도할 동일 의도를 외부 서비스에 전달하는 문제를, 웹훅 사례는 로컬 데이터베이스 안에서 동시 처리를 조정하는 문제를 다룹니다. 각각의 경계에 맞는 멱등성 보장이 필요합니다.

대화 기록 대신 애플리케이션이 상태의 기준이 됩니다

‘LLM에는 기억이 없습니다. 애플리케이션에는 반드시 기억이 있어야 합니다’는 모델 API 요청이 독립적이며, 모델이 이전 대화를 기억하는 것이 아니라 매번 전달받은 내용을 다시 읽는다고 설명합니다. 대화 전문을 계속 보내거나 요약에 의존하면 비용·문맥 한계가 생길 뿐 아니라, 요약 과정에서 주문 ID 같은 핵심 사실이 빠질 수도 있습니다. 그래서 주문 정보와 확인 여부, 워크플로 단계 같은 사실을 코드가 소유하는 구조화된 상태로 저장하고, 프롬프트에는 필요한 상태와 최근 대화만 전달하자고 제안합니다.

같은 글은 중단과 재개를 위해 단계별 상태도 모델 출력에서 추론하지 말고 외부에 영속화하라고 합니다. 그래야 취소나 장애가 발생했을 때 어떤 단계가 이미 실행됐는지, 안전하게 중단할 수 있는지를 애플리케이션이 판단할 수 있습니다. 환불 재시도 글의 의도 기록과 ‘제출됨·확인됨·실패·불명’ 상태는 개별 외부 작업의 실행 결과를 추적하는 데 초점을 둡니다. 반면 LLM 상태 관리 글은 그 작업을 포함한 장기 프로세스의 진행 상태를 다룹니다. 두 관점 모두 대화 기록을 시스템의 기준으로 삼지 않지만, 관리하는 상태의 범위는 서로 다릅니다.

기록만으로 충분하지 않을 때는 결과를 대사합니다

상태를 기록해도 실제 외부 결과를 모르면 판단이 끝나지 않습니다. 환불 재시도 글은 ‘불명’ 상태의 작업을 결제 서비스나 원장에 조회해 확인된 결과에 따라 상태를 갱신하고, 그 전에는 자동 재시도를 막자고 제안합니다. 웹훅 글은 별도의 읽기 전용 대사 작업이 시스템 기록과 기대되는 결과를 비교해 누락을 드러낼 수 있다고 설명합니다. 둘 다 실행 요청이나 성공 응답만으로 전체 작업의 결과를 확정하지 않고 확인 절차를 두지만, 전자는 특정 작업의 불확실성을 해소하고 후자는 파이프라인 전체의 불일치를 찾는 데 초점을 둡니다.

대사에는 한계도 있습니다. 웹훅 글은 단순 건수 비교만으로 누락과 중복이 서로 상쇄되거나, 내용이 비어 있는 레코드가 성공으로 보일 수 있다고 짚으며, 객체별 내용 불변 조건과 복구 경로가 필요하다고 설명합니다. 또한 대사는 복구의 뒷받침이지 그 자체가 수정은 아닙니다. 따라서 애플리케이션은 실행 전에 영속화한 의도와 재사용할 키, 워크플로 단계 및 결과 상태를 관리하고, 외부 시스템이나 독립된 검증 작업을 통해 실제 결과를 확인해야 합니다. 다만 트랜잭션이나 그래프가 데이터의 정당성 또는 모델 판단의 정확성까지 보장하는 것은 아니라는 점도 첫 글은 한정합니다.

함께 읽은 원문