재시도할까, 말까? AI 모델은 API 실패 상황을 제대로 판단할까요

AI 요약

외부 API 호출에 재시도 정책을 추가할 때 상태 코드만 보고 결정하면 위험합니다. 503 응답이라도 서버가 요청을 처리했는지 알 수 없고, 결제 요청에 멱등성 키(Idempotency Key)가 없다면 다시 보냈을 때 중복 결제가 생길 수 있습니다. 글쓴이는 이런 맥락을 AI 모델이 얼마나 잘 판단하는지 살펴보려고 Kaggle 벤치마크 챌린지에 맞춰 실험을 구성했습니다.

벤치마크 구성

14개 시나리오마다 요청, 응답, 부가 정보를 제시하고 모델이 YES, NO, YES_AFTER_DELAY 가운데 하나와 한 문장 이유를 출력하게 했습니다. 점수에는 결정값만 반영했습니다. 이유도 수집해 모델이 상황을 이해했는지, 우연히 정답을 골랐는지 확인하려는 목적입니다.

시나리오는 멱등성 키가 있는 결제 요청부터 멱등성 키가 없는 결제 요청, 응답을 받기 전에 연결이 끊긴 PUT·PATCH·DELETE 요청, 429 응답과 Retry-After 헤더, 오래된 ETag로 인한 412 응답, 418 응답, 캐시된 장바구니 옵션 사용까지 다룹니다. 각 과제의 기대 답과 설명은 별도 앱에서 볼 수 있으며 사람용 테스트도 마련했습니다.

비교 대상은 GPT-5.6 Sol·Luna, Gemini 3.7 Flash·3.1 Pro Preview, Claude Sonnet 5·Haiku 4.5, GLM-5, DeepSeek-R1입니다. Grok 4.5와 4.6은 404 오류가 나 결과에서 제외했습니다. 모델마다 같은 벤치마크를 세 번 실행했습니다.

정확도와 반복 실행 결과

첫 실행에서는 GPT-5.6 Sol이 14개 모두 맞혔고 Gemini 3.7 Flash가 13개를 맞혔습니다. 이어 네 모델이 12개, DeepSeek-R1이 11개, Claude Haiku 4.5가 9개를 맞혔습니다. 세 번의 평균 점수는 GPT-5.6 Sol 13.67/14, Gemini 3.7 Flash 13/14, Gemini 3.1 Pro Preview와 GLM-5 각각 12.33/14, Claude Sonnet 5와 GPT-5.6 Luna 각각 12/14, DeepSeek-R1 10.33/14, Claude Haiku 4.5 9/14였습니다.

전체 112개 모델·시나리오 조합 가운데 102개는 세 번 모두 정오답 결과가 같았습니다. 다만 점수가 같아도 매번 같은 문제를 틀린 것은 아니었습니다. 만료된 임시 필터 시나리오에서는 네 모델이 실행마다 답을 바꿨습니다. GPT-5.6 Sol도 첫 두 번에는 YES, 세 번째에는 YES_AFTER_DELAY를 냈습니다. 재시도 자체가 안전한지와 언제 재시도할지는 서로 다른 판단인데, 현재 점수 방식은 이를 한데 묶습니다.

가장 까다로운 사례는 멱등성 키가 없는 결제 요청에 503과 Retry-After가 함께 온 상황입니다. Retry-After 지시만 따르면 기다린 뒤 재시도하라는 답이 자연스러워 보이지만, 결제가 이미 처리됐을 가능성을 배제할 수 없습니다. 24회 시도 가운데 정답은 6회, 즉 25%였습니다. GPT-5.6 Sol과 Gemini 3.1 Pro Preview만 세 번 모두 맞혔고, 나머지 여섯 모델은 매번 틀렸습니다. 반면 14개 시나리오 중 절반은 24회 시도에서 모두 정답이었습니다. 모델 간 차이는 단순한 재시도보다 시점, 요청 맥락, 여러 단계에 걸친 상태가 걸린 문제에서 나타났습니다.

비용과 실험의 한계

비용과 토큰 효율을 비교한 결과 GPT-5.6 Luna가 가장 효율적인 영역에 자리했습니다. Claude Haiku 4.5도 비용 효율이 높은 쪽에 있었지만, 정확도는 비교 모델 중 가장 낮았고 GPT-5.6 Luna보다 비용도 더 들었습니다. DeepSeek-R1은 두 번째로 비용이 많이 들었습니다. 출력 형식을 Decision과 Reason으로 제한했는데도 응답이 4,000~9,000자에 달했습니다. 다른 모델은 지시한 형식을 따랐습니다. 따라서 비용 차이는 토큰 단가뿐 아니라 출력 형식 준수 여부에도 영향을 받았습니다.

글쓴이는 YES와 YES_AFTER_DELAY를 똑같이 오답 처리하는 방식이 적절한지 의문을 제기합니다. 멱등 요청을 재시도해도 안전하다고 판단하면서 시점만 다르게 답한 경우와, 중복 결제를 일으킬 수 있는 요청을 재시도한 경우는 위험도가 다릅니다. 다음 버전에서는 안전성과 재시도 시점을 분리해 채점하는 방안이 제안됐습니다. 실험은 14개 시나리오와 모델당 세 번의 실행으로 구성된 작은 벤치마크이며, 점수만으로 모델 순위를 단정하기보다 어떤 시나리오에서 같은 실수가 반복되는지 살피는 편이 타당합니다.

dev.to 반응

• @arhancanli — ‘Unsafe Payment Retry’ 항목이 가장 많은 정보를 주지만, 모델 오류로 해석하기 전에 정답 기준을 확인해야 합니다. 503은 핸들러가 실행되지 않았다는 뜻이 아니므로, Retry-After에 따라 기다렸다 재시도하는 답도 방어 가능한 선택입니다. 반면 보수적인 정책은 NO입니다. 재시도가 중복 효과를 일으키는지와 YES·YES_AFTER_DELAY처럼 시점만 다른지를 나눠 점수화하는 편이 낫습니다. 14개 시나리오에서는 한 문제당 점수 차이가 약 7%포인트입니다. 14/14의 95% Wilson 신뢰구간은 대략 78~100%, 12/14는 60~96%, Haiku의 9/14는 39~84%입니다. 이번 실행만으로 모델 순위가 명확히 갈렸다고 보기는 어렵고, 모델들이 공통으로 틀리는 항목이 더 의미 있습니다.
  • @gramli — 자세한 의견 감사합니다. 재시도 안전성과 시점을 나누면 벤치마크가 더 의미 있어진다는 데 동의합니다. 결제 시나리오는 멱등성 보장이 없으므로 NO가 맞다고 봅니다. 503은 결제가 처리됐다는 증거도, 처리되지 않았다는 증거도 아닙니다. 그래서 그 위험을 시험하고 싶었습니다. 벤치마크를 세 번 실행했는데 Unsafe Payment Retry 결과는 세 번 모두 같았습니다. 더 많이 실행하면 좋겠지만, 이번 실험은 작은 규모입니다. 다음 버전에 쓸 좋은 제안입니다.
  • @arhancanli — 결제 시나리오에서 NO가 맞다는 데 동의합니다. 멱등성 키가 없으면 503만으로 결제 여부를 알 수 없고, 무작정 재시도하면 중복 청구가 생길 수 있습니다. 다만 같은 설정으로 세 번 같은 결과가 나왔다고 해서 답이 옳다는 뜻은 아니며, 해당 프롬프트에서 모델이 안정적이라는 뜻입니다. 다음 버전에서는 Idempotency-Key가 있는 같은 시나리오를 추가해 모델이 필요한 경우에만 YES로 바꾸는지 볼 수 있습니다.
  • @gramli — 완전히 같은 시나리오는 아니지만, 벤치마크에는 Retry-After 헤더가 없는 Safe Payment Retry와 Unsafe Payment Retry가 모두 있습니다. 그래도 더 많은 변형을 시험하면 흥미로울 것 같습니다.
• @sinarezaei — ‘재시도해야 하나요?’가 평가 단위로 적절하지 않은 경우도 있습니다. 논리적 요청에 남은 재시도 용량이 얼마나 되는지가 더 중요한 질문일 수 있습니다. API 게이트웨이, 주문 서비스, 결제 제공자 뒤에서 결제 요청이 처리된다고 해보겠습니다. 결제 클라이언트에 도착했을 때 마감까지 2초가 남았고 1.4초가 지났다면 남은 시간은 600ms입니다. 클라이언트가 재시도 세 번을 독립적으로 허용해도, 대기 시간이 남은 마감 시간을 넘으면 재시도는 의미가 없습니다. 요청 마감 시간과 재시도 예산을 시나리오에 넣으면 좋겠습니다. 게이트웨이와 서비스, 하위 클라이언트가 각각 재시도하면 실제 시도 횟수가 크게 늘어날 수도 있습니다. Google SRE도 재시도 증폭, 마감 시간 전파, 재시도 예산을 다룹니다. 다음 버전에서는 오류가 일시적인지 판단하는 데 그치지 않고, 호출 체인 전체에서 남은 지연 시간과 재시도 예산을 지키는지 평가할 수 있습니다.
• @xulingfeng — DeepSeek-R1은 좀 오래된 모델인데 왜 사용했나요? 최신 DeepSeek-V4.1 Flash를 시험해 보세요. 행운을 빕니다.
  • @gramli — 아쉽게도 Kaggle에는 DeepSeek-R1만 제공됩니다. 감사합니다.

원문: dev.to / 번역·요약: Trawling