레이트 리밋, 429 오류, 티어 업그레이드
업데이트 September 1, 2026 · 최초 게시 September 1, 2026
서비스가 429 응답을 돌려주기 시작하면 가용성 장애로 취급하려는 반사적 반응이 나옵니다. 한도를 올리고, 티어를 업그레이드하고, 재시도를 추가해 처리량을 되찾는 것이죠. 이것이 맞을 때도 있습니다. 그러나 동시에 폭주하는 루프가 다섯 자리 청구서로 바뀌는 경로이기도 합니다. 그 루프를 막고 있던 유일한 장치를 방금 제거했기 때문입니다.
429가 실제로 알려주는 것
시스템이 허용량보다 빠르게 지출하려 한다는 뜻입니다. 원인은 두 가지로 크게 다르고, 대응도 정반대입니다. 실제 수요 증가(사용자 증가, 출시, 시즌 피크)라면 한도가 정말 낮은 것이므로 올리는 것이 실제 매출을 지키는 길입니다. 폭주(재시도 폭풍, 루프에 빠진 에이전트, 제한 없이 도는 백필, 운영 키를 겨눈 테스트 스위트)라면 한도가 제 역할을 정확히 하고 있는 것입니다.
두 경우는 오류율만으로는 구분되지 않습니다. 작업 단위당 비용을 보면 쉽게 구분됩니다. 실제 성장이라면 볼륨이 늘어도 이 비율은 대체로 유지되고, 폭주라면 완료된 작업 하나당 어제보다 훨씬 많이 쓰면서 비율이 무너집니다. 이 비율이 모든 티어 업그레이드의 판단 기준이 되어야 합니다.
재시도가 조용히 상황을 악화시킨다
지수 백오프와 지터 없이 429에 대해 단순 재시도를 하면, 한 번의 한도 초과가 동기화된 폭풍으로 바뀝니다. 성공한 요청은 과금되고, 실패한 요청 상당수도 이미 입력 처리에 자원을 소모합니다. 게다가 재시도는 보통 애플리케이션 코드가 아니라 클라이언트 라이브러리에 구현되어 있어서, 이 증폭은 기능의 설계 문서 어디에도 나타나지 않습니다.
한도를 의도적으로 설정하라
제공자의 상한보다 낮게, 환경별·기능별로 자체 한도를 설정하세요. 그러면 가장 먼저 깨지는 것이 우리 쪽 한도가 되고, 그다음 일어날 일을 우리가 통제할 수 있습니다. 비운영 환경은 엄격하게 제한하세요. 실패한 테스트 빌드는 값이 싸지만, 상한이 걸린 고객 경로는 그렇지 않습니다. 알림은 오류 건수가 아니라 작업당 비용 비율을 기준으로 설정하세요. 그리고 티어를 올릴 때는 담당자가 명확한 지출 결정으로 다뤄야 합니다. 실제로 그런 결정이니까요.
관련 글
관련 글
이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 →