API 오류와 재시도 — 잘못 짜면 요금이 폭주한다

API를 쓰다 보면 오류가 납니다. 그때 어떻게 다시 시도하느냐가 요금과 직결됩니다. 잘못 짜면 재시도가 무한 반복에 빠져 하루 만에 예상 밖의 금액이 나옵니다.

이 글은 오류 종류를 나누고 각각에 맞게 대응하는 방법을 정리합니다.

먼저: 다시 시도하면 안 되는 오류가 있다

모든 오류를 똑같이 재시도하면 안 됩니다. 크게 두 종류로 나뉩니다.

두 번째를 재시도하면 같은 오류가 무한히 반복됩니다. 요청 형식이 틀렸는데 백 번 보낸다고 맞아지지 않습니다.

그런데 이 경우에도 요금이 붙을 수 있습니다. 요청이 처리되다가 실패했다면 그만큼의 사용량이 발생합니다.

재시도를 짤 때의 원칙

1. 횟수에 상한을 둡니다. 3회 정도가 일반적입니다. 무한 재시도는 사고의 가장 흔한 원인입니다.
2. 간격을 점점 늘립니다. 1초, 2초, 4초 식으로. 바로 다시 보내면 같은 이유로 또 실패합니다.
3. 재시도할 오류만 재시도합니다. 고쳐야 할 오류는 즉시 중단하고 알립니다.
4. 전체 시도 시간에도 상한을 둡니다. 횟수 제한이 있어도 대기가 길면 오래 매달립니다.
5. 로그를 남깁니다. 무엇이 몇 번 실패했는지 기록해야 원인을 찾습니다.

2번이 중요한 이유

요청이 몰려서 거절된 상황이라면, 바로 다시 보내는 것은 상황을 악화시킵니다. 간격을 늘려 가며 기다리는 방식이 표준으로 쓰이는 이유입니다.

여기에 약간의 무작위 지연을 더하는 방법도 씁니다. 여러 요청이 동시에 실패하면 재시도도 동시에 몰리기 때문입니다.

요금 관점에서 특히 위험한 패턴

• 반복문 안의 무한 재시도. 1,000건을 처리하는 반복문에서 각 건이 무한 재시도하면 상한이 없습니다.
• 시간 초과 없는 호출. 응답이 안 와도 계속 기다리면 다음 처리가 막힙니다.
• 실패를 성공으로 처리. 오류를 무시하고 넘어가면 문제를 알아채지 못한 채 사용량만 쌓입니다.
• 재시도할 때 입력을 다시 만드는 구조. 앞부분이 매번 달라지면 캐시가 걸리지 않아 요율이 10배가 됩니다.

마지막은 덜 알려져 있는데 실제 영향이 큽니다. 고정 지시문을 그대로 재사용하면 캐시가 유지되지만, 재시도마다 타임스탬프 같은 값이 앞부분에 들어가면 매번 정가입니다.

실패한 건을 다시 처리하는 방법

1,000건을 처리하다 50건이 실패했다면, 처음부터 다시 돌리지 마시길 권합니다. 성공한 950건을 다시 처리하면 그만큼 요금이 또 나갑니다.

• 성공한 것을 기록해 둡니다. 어디까지 됐는지 알면 그 지점부터 이어서 할 수 있습니다.
• 실패한 것만 따로 모읍니다. 실패 목록을 만들어 두면 그것만 다시 돌리면 됩니다.
• 중간 결과를 저장합니다. 처리하면서 바로 저장하면 중단돼도 잃지 않습니다.

이 구조를 미리 만들어 두면 재처리 비용이 20분의 1로 줄어듭니다.

확인 범위

이 글은 일반적인 원칙을 다룹니다. 서비스별 오류 코드의 의미, 요청 제한 수치, 재시도 권장 방식은 각 서비스 API 문서에 따로 정해져 있습니다.

또한 실패한 요청에 요금이 붙는지는 실패 시점과 서비스 정책에 따라 다릅니다. 저희가 이를 원문으로 확정하지 못했으므로 단정하지 않습니다. 소량으로 시험해 사용량 대시보드에서 확인하시는 편이 확실합니다.