AI 자동화 재시도 정책은 어떻게 정해야 할까

AI 자동화의 재시도 정책은 “몇 번 더 시도할까”보다 “어떤 실패를 다시 실행해도 안전한가”에서 출발해야 합니다.

• 일시 오류에는 재시도가 필요하지만 외부 상태를 바꾸는 단계에는 더 강한 조건이 필요합니다.
• backoff는 호출 폭주를 늦추고, 멱등성 키는 중복 반영을 막는 역할을 합니다.
• deduplication과 logging은 재시도 후 최종 상태를 확인하는 데 필요합니다.
• 멈춤 조건이 없으면 자동화는 복구 장치가 아니라 비용과 불확실성을 반복하는 구조가 됩니다.

좋은 재시도 정책은 더 많이 반복하는 규칙이 아니라, 언제 멈추고 무엇을 확인할지 정하는 규칙입니다.

먼저 실패 유형을 나눠야 한다

AI 자동화에서 재시도 정책을 정할 때 첫 질문은 “몇 번 재시도할까”가 아닙니다. 먼저 “이 실패는 다시 실행해도 안전한가”를 물어야 합니다. 독자가 지금 필요한 판단은 재시도 기능을 켤지 끌지가 아니라, 어떤 단계에 어떤 조건을 붙일지입니다. 일시적 네트워크 오류와 외부 상태 변경 실패를 같은 규칙으로 다루면 비용과 오류가 함께 커질 수 있습니다.

가상의 자동화 흐름을 보겠습니다. AI가 문의 내용을 요약하는 단계가 실패했습니다. 이 단계가 외부 상태를 바꾸지 않고 내부 계산만 다시 하는 것이라면 재시도 부담은 상대적으로 낮습니다. 반면 결제 요청, CRM 상태 변경, 고객 메일 발송처럼 외부에 흔적을 남기는 단계라면 같은 재시도가 중복 결과를 만들 수 있습니다. 두 실패를 같은 retry limit로 묶는 것은 위험합니다.

판단은 다음처럼 나눌 수 있습니다.

조건	해석	적절한 대응
읽기 또는 계산 중심 단계가 일시 오류로 실패	다시 실행해도 side effect가 작음	제한된 재시도와 backoff
외부 상태를 바꾸는 단계가 timeout	이미 반영됐을 가능성 있음	상태 확인 또는 멱등성 키 확인 후 재시도
같은 요청에서 중복 결과가 관찰됨	재시도가 안전하지 않음	자동 재시도 중단, 중복 제거와 로그 확인
실패 원인이 분류되지 않음	재시도 조건이 불명확함	재시도보다 실패 분류와 관측 보강 우선

이 표는 재시도를 줄이라는 뜻이 아닙니다. 재시도의 안전 조건을 단계별로 다르게 보라는 뜻입니다. 같은 자동화 안에서도 요약 단계, 분류 단계, 외부 업데이트 단계의 위험은 다릅니다.

정책으로 옮길 때는 세 갈래로 나누면 판단이 쉬워집니다. 첫째, 다시 실행해도 외부 흔적이 거의 없는 단계는 제한된 재시도와 backoff를 허용합니다. 둘째, 외부 상태를 바꾸지만 같은 요청을 식별할 수 있는 단계는 멱등성 키나 상태 조회를 확인한 뒤 재시도합니다. 셋째, 실행 여부도 모르고 중복 결과도 감지할 수 없는 단계는 자동 재시도를 멈추고 사람이 확인할 수 있는 큐로 넘깁니다. 이 세 갈래가 없으면 모든 실패가 같은 retry limit 안에 섞입니다.

backoff와 멱등성은 서로 다른 문제를 푼다

재시도 정책에서 자주 함께 언급되는 것이 backoff와 멱등성입니다. 둘은 모두 필요할 수 있지만 같은 문제를 해결하지는 않습니다. backoff는 재시도 간격을 늘려 호출 폭주를 줄이는 장치입니다. 멱등성 키는 같은 요청이 여러 번 실행돼도 결과가 한 번만 반영되게 하는 장치입니다.

예를 들어 외부 API가 잠깐 느려졌을 때 즉시 5번 재시도하면 호출이 몰려 더 큰 지연을 만들 수 있습니다. 이때 backoff는 “조금 기다렸다가 다시 시도하라”는 규칙을 제공합니다. 하지만 backoff만으로는 중복 반영을 막을 수 없습니다. 요청이 결국 여러 번 도착했을 때 외부 시스템이 이를 같은 작업으로 인식하지 못하면, 간격을 두고 실행했을 뿐 중복 작업은 여전히 생깁니다.

반대로 멱등성 키가 있어도 재시도 간격이 너무 짧으면 시스템에 불필요한 압력이 생깁니다. 같은 요청이 한 번만 반영되더라도 호출 자체는 비용을 만들고, 로그와 큐를 복잡하게 만들 수 있습니다. 그래서 backoff는 속도와 부하의 문제를 줄이고, 멱등성은 중복 결과의 문제를 줄인다고 구분하는 편이 안전합니다.

운영 기준으로는 두 신호를 함께 봐야 합니다. 짧은 시간 안에 같은 요청의 attempt가 급증하면 backoff가 약한 것입니다. 같은 요청이 여러 최종 결과로 남으면 멱등성이나 중복 제거가 약한 것입니다. 하나는 호출 리듬의 문제이고, 다른 하나는 상태 반영의 문제입니다.

멈춤 조건과 로그가 없으면 정책을 검증할 수 없다

재시도 정책에는 반드시 멈춤 조건이 있어야 합니다. retry limit만으로는 충분하지 않습니다. 어떤 오류가 반복될 때 즉시 중단할지, 어떤 경우에는 사람 확인으로 넘길지, 어떤 경우에는 상태 조회 후 재개할지를 정해야 합니다. 그렇지 않으면 자동화는 같은 실패를 정해진 횟수만큼 반복한 뒤 여전히 애매한 상태로 끝납니다.

가상의 상황을 생각해보겠습니다. AI가 계약 문서를 요약한 뒤 외부 문서 관리 시스템에 결과를 저장합니다. 저장 단계가 세 번 timeout이 났습니다. 단순 retry limit은 “세 번 시도 후 실패”라고 기록할 수 있습니다. 하지만 좋은 정책은 여기서 한 단계 더 나아갑니다. 같은 문서 ID에 저장 결과가 이미 있는지 확인하고, 있으면 중복 저장을 막고, 없으면 사람이 확인할 수 있도록 상태와 로그를 남깁니다.

재시도 정책을 점검할 때는 다음 질문을 사용할 수 있습니다.

• 이 단계는 외부 상태를 바꾸는가?
• 같은 요청을 구분하는 idempotency key나 request ID가 있는가?
• 재시도 후 성공, 실패, 이미 처리됨을 구분해 로그에 남기는가?
• 일정 횟수 이후 멈추는 조건이 오류 유형별로 다른가?
• 중복 결과를 발견했을 때 자동으로 정리하거나 사람에게 넘기는 기준이 있는가?

이 질문은 정책 문서의 체크박스가 아니라 운영 중 해석 기준이어야 합니다. 예를 들어 “이미 처리됨” 로그가 명확하면 재시도는 성공한 복구로 정리할 수 있습니다. 반대로 같은 요청에서 여러 최종 상태가 남고 어떤 값이 최종인지 모른다면, 다음 재시도보다 상태 확정이 먼저입니다. “멈춤”은 실패를 포기하는 행동이 아니라, 더 큰 중복 실행을 막기 위해 판단 가능한 지점으로 작업을 옮기는 행동입니다.

이 질문에 답할 수 없다면 재시도 횟수를 늘리는 것은 빠른 해결책이 아닙니다. 먼저 중복 실행이 어디서 생기는지 진단해야 합니다. timeout, 멱등성, 최종 상태 불확실성의 작동 원인은 별도 글에서 더 자세히 설명한 구조를 참고해야 합니다.

정책에 남겨야 할 최소 항목은 복잡하지 않습니다. 실패 유형, 재시도 허용 조건, 같은 요청을 식별할 키, 중복 결과를 확인할 로그, 자동 재시도를 멈출 조건이 있어야 합니다. 이를 짧게 정리하면 다음과 같습니다.

정책 항목	질문	빠지면 생기는 문제
failure type	일시 오류인가, 상태 변경 실패인가	모든 실패가 같은 retry limit에 묶임
retry condition	어떤 조건에서만 다시 시도하는가	호출 수만 늘고 성공률은 그대로일 수 있음
idempotency check	같은 요청을 같은 작업으로 묶는가	중복 write와 중복 알림이 생김
stop condition	언제 자동 재시도를 멈추는가	불확실한 상태를 반복 실행함

실행 경계는 세 가지로 나누면 충분합니다. 읽기나 계산 중심이고 side effect가 작으면 제한된 재시도를 허용합니다. 외부 상태를 바꾸지만 이미 처리 여부를 확인할 수 있으면 먼저 확인한 뒤 재시도합니다. 실행 여부도 모르고 중복 결과도 감지할 수 없으면 자동 재시도를 멈추고 사람 확인으로 넘깁니다. timeout인지 느린 성공인지, 중복 write인지 아직 구분되지 않는다면 정책을 먼저 늘리기보다 중복 실행 원인을 먼저 진단해야 합니다.

재시도 정책의 목표는 실패를 숨기는 것이 아니라 실패를 읽을 수 있게 만드는 것입니다. 실패를 읽을 수 있어야 비용 증가가 정상 복구인지, 재시도 폭주인지, 상태 확인 실패인지 구분할 수 있습니다.

자주 묻는 질문

재시도 횟수는 몇 번으로 정하는 게 좋나요?

보편적인 정답은 없습니다. 외부 상태를 바꾸지 않는 계산 단계와 외부 시스템에 기록을 남기는 단계는 위험이 다릅니다. 먼저 단계의 side effect와 멱등성 여부를 확인한 뒤 retry limit을 정해야 합니다.

backoff만 넣으면 재시도 폭주를 막을 수 있나요?

backoff는 짧은 시간에 호출이 몰리는 문제를 줄이는 데 도움이 됩니다. 하지만 같은 요청이 여러 번 반영되는 문제는 backoff만으로 막기 어렵습니다. 중복 반영을 막으려면 멱등성 키나 중복 제거 기준이 필요합니다.

언제 자동 재시도를 멈추고 사람 확인으로 넘겨야 하나요?

외부 상태가 이미 바뀌었는지 불확실하거나, 같은 요청에서 중복 결과가 보이거나, 실패 원인이 분류되지 않은 채 반복될 때는 멈추는 편이 안전합니다. 이때는 재시도보다 상태 확인, 로그 정리, 중복 제거가 먼저입니다.