AI 자동화 재시도는 왜 비용과 오류를 같이 키울 수 있을까

재시도는 왜 처음에는 안전해 보일까

문서 요약, 고객 문의 분류, CRM 상태 변경처럼 여러 단계가 이어지는 자동화에서는 잠깐의 오류 때문에 작업 전체를 버리고 싶지 않습니다. 다시 실행해도 안전한 단계라면 제한된 재시도로 복구할 수 있습니다. 그러나 응답 지연만 보고 재실행을 결정하면, 이미 끝난 작업을 다시 시도하는 상황도 생깁니다. AWS의 재시도 제한 지침은 일시적 장애에서 재시도가 도움이 될 수 있지만, 과부하 상황이나 여러 계층의 중첩 재시도는 자원 소모와 장애를 악화시킬 수 있다고 설명합니다.

먼저 구분할 것은 ‘응답을 받지 못했다’와 ‘실행되지 않았다’입니다. 타임아웃은 앞의 사실을 알려 줄 뿐입니다. 요청이 처리되지 않았는지, 처리 중인지, 처리는 끝났지만 응답이 오지 않았는지는 별도로 확인해야 합니다. 특히 외부 상태를 바꾸는 요청은 이전 결과가 불명확하고, 멱등성 등 안전한 재시도를 보장하는 조건도 확인되지 않았다면 재실행을 보류해야 합니다. 결과를 모른다는 이유만으로 모든 재시도가 금지되는 것은 아닙니다.

가상의 상황을 보겠습니다. AI가 견적 문의를 분류하고 CRM 상태를 ‘검토 중’으로 바꾼 뒤 담당자에게 알림을 보내는 자동화가 있습니다. CRM은 변경을 마쳤지만 응답이 늦어 타임아웃이 났다고 가정해 봅시다. 이때 전체 흐름을 처음부터 다시 돌리면 문의 분류도 다시 수행하고, 이미 완료된 상태 변경도 다시 요청하게 됩니다.

상태를 다시 ‘검토 중’으로 지정하는 것만으로는 새 티켓이 생기지 않을 수 있습니다. 하지만 요청마다 변경 이력을 추가하거나 알림을 보내도록 구성했다면, 상태값이 같아도 그 별도 효과는 반복될 수 있습니다. 따라서 ‘화면의 상태가 같으니 문제없다’고 끝내지 말고, 동일 작업의 호출·변경 이력·알림이 각각 어떻게 남았는지 봐야 합니다.

확인해야 할 단위도 분리해야 합니다. 원래 사용자가 요청한 작업의 식별자와 각 재시도의 식별자를 연결해 두면, 하나의 작업을 여러 번 시도한 것인지 서로 다른 요청이 많아진 것인지 구분할 수 있습니다. 한 단계의 응답이 늦었다는 이유로 정상 완료된 앞 단계까지 다시 실행하고 있지는 않은지가 첫 점검 지점입니다.

비용 증가는 호출량과 완료 작업을 함께 봐야 한다

호출이 늘었다는 기록만으로 실제 청구액이 얼마나 늘었는지는 알 수 없습니다. 추가 LLM·API 호출이 과금 대상이라면 직접 비용이 늘지만, 실제 금액은 사용 중인 서비스의 과금 기준과 청구 자료로 확인해야 합니다. 보고된 토큰, 호출 시도 횟수, 청구액은 서로 다른 자료입니다.

중복 알림이나 상충하는 결과를 정리하는 시간도 따로 봐야 합니다. 앞의 가상 상황에서 같은 문의를 다시 분류해 다른 판단이 저장됐다면, 담당자는 어느 결과를 최종으로 사용할지 확인해야 합니다. 이 예는 실제 사고 통계가 아니라, 재시도가 호출량 외에 어떤 확인 작업을 만들 수 있는지 보여 주는 상황입니다.

성공률을 비교할 때는 비슷한 종류의 원래 작업 묶음과 관찰 기간을 정해야 합니다. 그 묶음에서 중복을 제외하고 완료가 확인된 작업의 비율을 보고, 작업별 시도 횟수와 결과가 아직 불명확한 작업 수를 따로 기록합니다. 재시도 한 번이 성공할 때마다 새 작업 하나가 완료된 것처럼 세면 복구 효과를 과대평가할 수 있습니다.

원래 작업의 완료 비율은 나아지지 않는데 같은 작업에 대한 호출과 중복 알림이 함께 증가한다면, 재시도 범위와 결과 확인 방식을 먼저 살펴볼 이유가 있습니다. 이 조합만으로 재시도 폭주나 특정 장애 원인이 확정되지는 않습니다. 작업량·난이도·외부 서비스 상태가 달라졌는지도 같은 기준으로 비교해야 합니다.

반대로 완료가 확인된 원래 작업은 늘고 중복 효과가 생기지 않았다면 복구에 도움이 됐다는 근거가 됩니다. 그래도 그 복구가 비용상 적절했는지는 별도 판단입니다. 완료 건수와 호출량을 확인한 뒤 청구 자료와 운영 시간을 함께 비교해야 합니다.

재시도 횟수보다 이전 결과부터 구분한다

재시도 정책을 보기 전에, 같은 작업을 다시 요청했을 때 어떤 결과가 남는지부터 구분해야 합니다. RFC 9110 §9.2.2는 동일 요청을 반복해도 서버에 의도한 효과가 한 번 요청했을 때와 같다는 성질로 멱등성을 설명합니다. 요청별 로그나 이력 같은 별도 효과까지 한 번이라는 보장은 아닙니다. 의도한 효과가 같다는 것은 실제 실행·호출·과금도 한 번이었다는 증거가 아니며, 알림까지 같은 범위로 보호되는지도 별도로 확인해야 합니다. 이 규격은 연결 오류로 이전 응답을 받지 못한 멱등 요청은 재시도할 수 있다고 설명합니다.

제품별 예로, Stripe의 멱등 요청 문서는 멱등성 키를 사용하는 생성·갱신 요청을 연결 오류 후 안전하게 반복할 수 있다고 설명합니다. 이는 Stripe 문서의 조건을 충족하는 요청에 대한 보장입니다. 다른 API에도 키를 붙이기만 하면 안전하다고 일반화해서는 안 됩니다.

처음 비용 증가를 살펴볼 때는 다음처럼 나눠 볼 수 있습니다. 이는 특정 서비스의 자동 재시도 허용표가 아니라, 로그에서 무엇을 먼저 확인할지 정하는 기준입니다.

표의 핵심은 ‘오류가 났으니 몇 번 더 시도한다’는 순서를 바꾸는 데 있습니다. 이전 결과가 확인됐다면 그 결과를 기준으로 다음 단계를 판단합니다. 결과가 불명확할 때는 멱등성 등 안전한 재시도 조건도 확인해야 합니다. 그러한 조건이 확인된 범위에서는 재시도할 수 있고, 조건도 미확인이라면 재실행을 보류합니다. 결과가 없다는 사실과 결과를 아직 찾지 못했다는 사실도 구분해야 합니다.

타임아웃과 중복 실행이 연결되는 과정을 더 보려면 AI 자동화 재시도는 어디서 중복 실행을 만들까를 참고할 수 있습니다. 원인을 좁힌 뒤 허용 횟수와 중단 조건을 정하는 문제는 AI 자동화 재시도 정책은 어떻게 정해야 할까에서 이어집니다.

개별 서비스의 재시도 허용 조건, 중복 요청 처리 범위, 실제 요금은 이 글만으로 확정할 수 없습니다. 적용할 때는 해당 서비스의 문서와 자신이 가진 처리·청구 기록을 확인해야 합니다. 재시도를 늘리기 전에, 같은 원래 작업에서 완료가 확인된 결과와 아직 모르는 결과를 구분하는 것이 출발점입니다.