업무 연동 API가 429를 반환하면 바로 다시 요청해도 될까요?

업무 연동 API가 429를 반환하면 즉시 반복 요청하기보다 제공자의 제한 조건과 Retry-After 응답을 확인해야 합니다. 대기 시간과 재시도 횟수, 중복 처리 위험을 나눠 정하는 편을 권합니다.

429는 서버가 멈췄다는 뜻인가요?

MDN의 429 설명은 일정 시간 안에 너무 많은 요청을 보냈다는 HTTP 응답으로 설명합니다. 제한 범위는 구현마다 다릅니다. 서버 전체, 개별 자원, 사용자나 인증된 애플리케이션에 따라 다를 수 있으므로, 한 작업이 멈췄다고 곧바로 회사의 모든 연동을 같은 간격으로 반복해서는 안 됩니다.

탱탱소프트는 외부 서비스에서 자료를 가져오는 자동화가 이런 응답을 받았다면 대상 API, 응답 시각, 해당 서비스가 공개한 제한 조건부터 대조하도록 권합니다. 아래 데이터센터 이미지는 요청을 처리하는 서버의 개념 장면이며 고객사의 장비나 실제 장애 증거는 아닙니다.

AI로 생성한 개념 이미지. 실제 사업장 사진이 아닙니다.

Retry-After가 있으면 어떻게 읽나요?

MDN의 Retry-After 설명은 대기값을 HTTP 날짜 또는 응답을 받은 뒤 기다릴 초 단위 정수로 제시합니다. 가령 Retry-After: 120은 응답 수신 뒤 기다릴 초를 나타내는 가상 예입니다. 날짜 형태를 초 숫자로만 읽거나, 헤더가 없는데 임의의 대기값을 제공자의 지시처럼 기록하면 안 됩니다.

429에는 이 헤더가 포함될 수 있지만 반드시 있다고 단정할 수는 없습니다. 탱탱소프트는 값이 없거나 해석할 수 없는 경우의 처리도 별도로 정하도록 권합니다. 제공자의 문서를 확인한 뒤 제한된 횟수로 대기하거나 담당자에게 넘기는 정책을 선택할 수 있습니다. 헤더가 있다고 모든 클라이언트가 저절로 기다리는 것도 아니므로 실제 연동 코드의 동작을 시험해야 합니다.

시간이 지났으면 같은 요청을 다시 보내도 안전한가요?

대기 시간은 다음 요청 시점에 관한 정보이지 업무 처리 결과에 대한 증명은 아닙니다. 특히 주문 생성이나 외부 메시지 전송처럼 부작용이 있는 연동은 조회와 구분해야 합니다. 탱탱소프트는 결과를 알 수 없는 쓰기 요청을 대기 시간만 보고 재전송하지 말고, 제공자가 지원하는 상태 조회와 멱등 처리 계약을 먼저 확인하도록 권합니다. 이 부분은 운영 제안이며 429가 항상 부분 처리됐다는 주장은 아닙니다.

여러 작업이 같은 인증 계정으로 연결되는 가상 상황이라면 개별 작업이 각각 대기한 뒤 한꺼번에 몰리지 않는지도 살펴볼 수 있습니다. 아래 연결망은 여러 요청 경로를 떠올리기 위한 개념 삽화이며 실제 시스템 구성도는 아닙니다.

AI로 생성한 개념 이미지. 실제 사업장 사진이 아닙니다.

자동화 의뢰서에 어떤 종료 조건을 넣을까요?

재시도 대상 응답, 대기값을 읽는 방법, 최대 횟수, 중단 후 알림 대상을 적습니다. 청주·충북 기업이 반복 조회 업무를 자동화한다면 업무가 완료됐는지와 다음 시도를 기다리는지를 관리자 화면에서 구분하는 것도 검토할 만합니다. 인증 토큰이나 고객 자료를 그대로 로그에 남길 필요는 없습니다.

탱탱소프트는 회사 홈페이지와 웹서비스, 업무·AI 자동화를 구축하는 청주 기반 스튜디오입니다. 의뢰 범위를 정할 때 정상 처리뿐 아니라 제한 응답과 중단·인계 조건을 함께 합의하는 편을 권합니다. 이 글은 특정 API의 사용 한도나 장애 복구 시간을 정한 계약이 아닙니다.

참고 자료

• MDN Web Docs: 429 Too Many Requests
• MDN Web Docs: Retry-After header