AI 자동화 재시도는 어디서 중복 실행을 만들까

timeout은 실패가 아니라 불확실한 상태일 수 있다

AI 자동화에서 timeout은 가장 흔한 재시도 트리거입니다. 그러나 timeout은 “작업이 실패했다”는 뜻만은 아닙니다. 작업이 실제로 실패했을 수도 있고, 성공했지만 응답이 늦었을 수도 있으며, 외부 시스템에는 반영됐지만 자동화 쪽으로 응답이 돌아오지 않았을 수도 있습니다. 지금 이 글을 읽는 독자는 재시도 오류를 줄이고 싶지만, 먼저 봐야 할 판단은 “실패했는가”보다 “실행 여부를 확인할 수 있는가”입니다.

가상의 예로, AI가 고객 요청을 읽고 외부 티켓 시스템에 우선순위를 업데이트하는 흐름을 생각해볼 수 있습니다. 티켓 시스템은 업데이트를 정상 처리했지만 응답이 제한 시간보다 늦게 도착했습니다. 자동화 엔진은 이를 timeout으로 기록하고 같은 업데이트를 다시 실행합니다. 두 번째 요청이 같은 업데이트로 처리되면 큰 문제가 없을 수도 있지만, 시스템이 매번 새 이벤트를 생성한다면 중복 기록과 중복 알림이 생깁니다.

이 차이는 로그에서 드러납니다. timeout 직후 같은 요청 ID나 같은 사용자 입력을 가진 API write가 반복되고, 외부 시스템에는 여러 개의 비슷한 이벤트가 남는다면 재시도는 복구가 아니라 중복 실행일 수 있습니다. 반대로 timeout 뒤 재시도가 한 번 있었고 외부 상태가 한 번만 반영됐다면 위험은 낮습니다. 같은 timeout이라도 실행 결과를 확인할 수 있는 구조와 없는 구조의 운영 위험은 다릅니다.

진단할 때는 timeout 로그 하나를 독립 사건으로 보지 않는 편이 좋습니다. 먼저 같은 request ID, 같은 사용자 입력 해시, 같은 외부 리소스 ID 주변에 attempt 번호가 이어지는지 묶어 봅니다. 그다음 외부 write가 이미 성공했는지, 자동화 내부 상태만 실패로 남았는지, 후속 단계가 어느 결과를 기준으로 실행됐는지 확인합니다. 묶어서 봤을 때 첫 번째 attempt 뒤 외부 write는 성공했는데 자동화 내부 상태만 실패로 남았다면, 문제는 모델 품질보다 “성공 확인 경로”에 있을 가능성이 큽니다. 이 신호는 재시도 횟수를 늘리기 전에 상태 조회나 결과 확인 단계를 보강해야 한다는 뜻입니다.

따라서 timeout을 단순 실패로만 처리하면 재시도 정책은 거칠어집니다. “실패했으니 다시 한다”가 아니라 “실패로 보이지만 이미 반영됐을 가능성이 있는가”를 확인해야 합니다. 이 판단이 없으면 비용이 늘고도 성공률은 크게 오르지 않는 이상한 패턴이 생깁니다.

멱등성 키가 없으면 같은 작업이 새 작업처럼 처리된다

중복 실행의 핵심 장치는 멱등성입니다. 멱등성은 같은 요청이 여러 번 들어와도 결과가 한 번만 반영되게 하는 성질입니다. AI 자동화에서는 이 성질이 없을 때 같은 LLM 판단, 같은 API write, 같은 알림 발송이 매번 새 작업처럼 처리될 수 있습니다.

가상의 상황을 보겠습니다. 자동화가 “고객 A의 요청을 긴급으로 표시하라”는 작업을 수행합니다. 첫 번째 요청이 timeout으로 보였고, 두 번째 요청이 다시 발송됐습니다. 두 요청이 같은 idempotency key를 공유한다면 외부 시스템은 “이미 처리한 요청”으로 볼 수 있습니다. 하지만 그런 키가 없다면 두 요청은 서로 다른 작업으로 처리될 수 있습니다. 이때 중복 API 호출 비용뿐 아니라 중복 알림, 중복 티켓 히스토리, 중복 후속 작업이 생깁니다.

관찰 가능한 신호는 다음과 같습니다.

이 표에서 중요한 점은 비용만 보지 않는 것입니다. 비용 증가는 결과입니다. 원인은 같은 요청을 같은 작업으로 묶지 못하는 데 있을 수 있습니다. 멱등성 키, 요청 ID, attempt 번호, 외부 시스템의 중복 제거 기록이 없으면 운영자는 재시도가 안전했는지 확인하기 어렵습니다.

짧은 점검 순서는 이렇게 잡을 수 있습니다. 먼저 같은 입력이 몇 번 실행됐는지 묶고, 그다음 외부 write가 몇 번 발생했는지 확인합니다. 마지막으로 외부 시스템이 같은 요청을 “이미 처리됨”으로 거절했는지, 아니면 매번 새 이벤트로 받아들였는지 봅니다. 세 번째 단계에서 매번 새 이벤트가 만들어졌다면 재시도 문제는 단순 호출 비용이 아니라 멱등성 또는 deduplication 부재로 좁혀집니다.

재시도는 한 번 더 실행하는 행동이지만, 멱등성은 그 실행이 “같은 일”임을 증명하는 장치입니다. 이 장치가 없으면 자동화는 실패를 고치는 대신 같은 일을 여러 번 벌리는 쪽으로 기울 수 있습니다.

최종 상태가 불명확하면 다음 단계도 흔들린다

중복 실행의 피해는 해당 단계에서 끝나지 않습니다. AI 자동화는 보통 여러 단계를 연결합니다. 분류, 요약, 외부 업데이트, 알림, 후속 작업 생성이 이어질 때 앞 단계의 최종 상태가 불명확하면 뒤 단계는 잘못된 기준으로 실행될 수 있습니다.

예를 들어 AI가 문의를 “환불 요청”으로 분류하고, 재시도 뒤에는 “배송 지연”으로 분류했다고 해봅시다. 두 결과가 모두 로그에 남았는데 어떤 것이 최종인지 정리되지 않으면, 후속 자동화는 잘못된 템플릿을 보내거나 잘못된 담당자에게 전달할 수 있습니다. 이 문제는 모델 품질만의 문제가 아닙니다. 같은 요청의 여러 실행 결과 중 무엇이 최종 상태인지 정하지 못한 워크플로우 문제입니다.

진단 기준은 단순합니다. 재시도 이후 최종 상태가 하나로 수렴하면 복구에 가깝고, 여러 상태가 남아 사람이 해석해야 하면 운영 부채에 가깝습니다. 같은 요청에 여러 final value가 남고, 사람이 “마지막 성공”을 해석해야 하며, 후속 자동화가 서로 다른 기준으로 실행된다면 위험 신호입니다. 특히 비용 증가와 함께 “마지막 성공이 무엇인지” 확인하는 시간이 늘어난다면, 재시도 정책보다 상태 확정 구조를 먼저 봐야 합니다.

원인을 좁힌 뒤에는 대응 질문이 달라집니다. 어떤 실패는 backoff를 두고 다시 시도해도 되는지, 어떤 실패는 idempotency key나 상태 조회 없이는 멈춰야 하는지, 어떤 경우에는 사람 확인으로 넘겨야 하는지를 정해야 합니다. 여기서는 원인을 좁히는 것이 목적입니다. timeout이 실패인지 불확실성인지, 멱등성 키가 있는지, 외부 write가 중복되는지, 최종 상태가 하나로 수렴하는지를 보면 재시도 문제가 어디서 만들어지는지 훨씬 빨리 판단할 수 있습니다.