에이전트가 외부 작업을 실행한 직후 서버가 재시작됐습니다. 대화 기록만으로 이어가면 왜 중복 실행될 수 있나요?

대화 기록은 모델이 무엇을 요청했는지 보여 줄 수 있지만 외부 시스템에 무엇이 확정됐는지를 원자적으로 보장하지 않습니다. 작업 상태·단계 입력·논리 요청 ID·도구 실행 결과·산출물 참조를 내구 저장하고, 재개할 때 외부 효과와 체크포인트의 차이를 확인해야 합니다. 모델의 기억을 복원하는 것과 실행을 안전하게 복구하는 것은 다른 문제입니다.

체크포인트와 외부 효과 사이의 틈

메일 발송이 성공한 뒤 완료 체크포인트를 쓰기 전에 프로세스가 죽으면 재개 세션은 그 단계가 미완료라고 볼 수 있습니다. 다시 보내면 중복 발송이고, 그냥 건너뛰면 실제로 실패했을 경우 누락입니다. 외부 API가 멱등 키를 지원하면 같은 논리 키로 다시 조회·실행하고, 지원하지 않으면 발송 기록 조회나 대사·사람 확인 경로가 필요합니다. 내구 워크플로 엔진도 임의 외부 API의 exactly-once를 자동 제공하지는 않습니다.

모델 호출을 재실행하면 다른 계획·인자를 생성할 수도 있습니다. 기록된 결정과 도구 인자를 재사용할지 새로 추론할지 단계를 구분하고, 재생 중 모델 호출과 외부 실행이 무심코 반복되지 않게 합니다. 입력·프롬프트·모델·도구 버전도 기록해야 동일 작업의 의미를 확인할 수 있습니다. 내부 추론 전문을 보관하는 대신 실행을 결정한 구조적 결과와 관찰 증거를 저장할 수 있습니다.

재개 가능한 상태 머신

작업을 queued·running·waiting_input·succeeded·failed·cancelled처럼 명확히 나누고 허용 전이와 버전 조건을 둡니다. 두 워커가 같은 체크포인트를 읽고 동시에 재개하면 소유권 lease와 저장 지점의 세대 검사로 옛 실행을 제한합니다. lease 만료는 옛 워커가 멈췄다는 증거가 아니므로 완료 기록뿐 아니라 실제 변경 경계도 보호해야 합니다.

체크포인트는 너무 자주 기록하면 비용이 크고 너무 드물면 재작업이 커집니다. 비가역 효과 전후와 사용자 입력 대기처럼 중요한 경계에 우선 둡니다. 테스트는 도구 실행 전·외부 commit 후·결과 기록 전·사용자 응답 전 중단을 각각 재현하고, 새 워커가 중복 없이 상태를 설명하는지 검사합니다. 장기 에이전트의 신뢰성은 더 긴 대화보다 기존 분산 시스템의 상태·멱등성·소유권 원칙을 모델 루프와 정확히 연결하는 데서 나옵니다.

실행 사례로 확인합니다

체크포인트에 완료 플래그만 저장하면 어떤 인자와 버전으로 완료했는지 알기 어렵습니다. 단계 입력의 정규화 값, 논리 키, 외부 결과 ID, 검증 상태를 함께 남기고 큰 산출물은 별도 저장소의 참조로 연결할 수 있습니다. 워크플로 코드 버전이 바뀐 뒤 옛 작업을 재개하면 단계 이름이나 입력 의미가 달라질 수 있어 마이그레이션 또는 이전 실행기 유지 정책이 필요합니다. 실패한 작업을 새 코드로 무조건 처음부터 실행하지 않습니다. 재개 시험은 성공 경로뿐 아니라 오래된 체크포인트·만료 자격·이미 완료된 외부 결과를 포함해 같은 목표가 어떤 상태에서 이어지는지 확인하겠습니다.