공용 API를 위한 레이트 리밋: 실용적 쿼터와 잠금 흐름

레이트 리밋이 실제로 해결하는 문제

공용 API에 대한 레이트 리밋은 사용자를 벌주는 것이 아닙니다. 트래픽이 이상해질 때(그 "이상"이 악의적이든 단순한 클라이언트 버그든) 서비스를 이용 가능하게 유지하는 안전장치입니다.

"남용"은 처음엔 정상처럼 보이기도 합니다. 모든 엔드포인트를 훑어 데이터를 긁어가는 스크레이퍼, 무차별 로그인 시도, 인증 경로에 대한 토큰 스터핑, 타임아웃 후에 같은 요청을 빠르게 반복 재시도하는 통제 불능 클라이언트 등입니다. 때로는 아무도 당신을 공격하지 않습니다. 모바일 앱 업데이트가 잘못된 캐시 규칙을 포함해 각 기기가 매초 API를 폴링하게 될 수도 있습니다.

목표는 간단합니다: 정상적인 사용자를 차단하지 않으면서 가동 시간을 보호하고 비용을 제어하는 것. 백엔드가 사용량 기반(컴퓨트, 데이터베이스, 이메일/SMS, AI 호출 등)이라면 한 명의 시끄러운 액터가 비용 폭증을 초래할 수 있습니다.

레이트 리밋만으로는 충분하지 않습니다. 모니터링과 명확한 오류 응답이 없다면 무언의 실패, 혼란스러운 고객, "API가 다운된 것 같다"는 지원 티켓이 쌓입니다.

완전한 안전장치는 보통 몇 가지 별도 요소로 구성됩니다:

• 레이트 리밋: 스파이크를 막는 단기 창(caps).
• 쿼터: 사용량을 예측 가능하게 하는 장기 허용량(일간/월간).
• 락아웃(잠금): 명백한 남용 패턴에 대한 임시 차단.
• 예외: 신뢰되는 통합, 내부 도구, VIP 고객을 위한 허용목록.

AppMaster 같은 플랫폼으로 API 백엔드를 만들더라도 이러한 규칙은 중요합니다. 깔끔한 코드가 생성되더라도, 한 클라이언트의 문제로 전체 서비스를 잃지 않도록 기본 보호 설정이 필요합니다.

주요 용어: 레이트 리밋, 쿼터, 스로틀링, 락아웃

이 용어들은 섞여 쓰이지만 서로 다른 문제를 해결하고 사용자에게 다르게 느껴집니다.

레이트 리밋, 쿼터, 동시성 제한의 의미

레이트 리밋은 속도 제한입니다: 짧은 창(초당, 분당)에 클라이언트가 보낼 수 있는 요청 수입니다. 쿼터는 예산입니다: 더 긴 기간(일간, 월간)에 허용되는 총 사용량입니다. **동시성 제한(concurrency limit)**은 동시에 처리 중일 수 있는 요청 수를 제한하는데, 요청률이 정상이더라도 비용이 큰 엔드포인트에 유용합니다.

어디에 제한을 적용하느냐가 중요합니다:

• IP별: 간단하지만 공유 네트워크(사무실, 학교, 이동통신사)를 처벌할 수 있습니다.
• 사용자별: 로그인 앱에 적합하지만 신뢰할 수 있는 식별에 의존합니다.
• API 키별: 공용 API에 흔한 방식으로, 소유권이 명확하고 메시지 전달이 쉽습니다.
• 엔드포인트별: 한 경로가 다른 경로보다 훨씬 무거울 때 유용합니다.

스로틀링과 차단, 락아웃의 위치

소프트 스로틀링은 클라이언트를 늦춰서(지연, 버스트 용량 축소) 복구할 수 있게 합니다. 하드 블로킹은 요청을 즉시 거부하며 보통 HTTP 429를 사용합니다.

락아웃은 일반적인 429보다 강력합니다. 429는 "곧 다시 시도하세요"라는 의미인 반면, 락아웃은 "어떤 조건이 충족될 때까지 중지하세요"라는 의미입니다(예: 쿨다운 기간, 수동 검토, 키 재설정). 락아웃은 자격 증명 충돌 시도, 공격적 스크레이핑, 반복된 잘못된 인증 등 명백한 남용 신호에만 예약해 두세요.

AppMaster 같은 도구로 API를 만든다면 이들을 별개의 제어 수단으로 다루세요: 버스트를 흡수하는 단기 제한, 비용을 관리하는 장기 쿼터, 반복된 나쁜 행동에만 락아웃을 적용하는 방식입니다.

무작정 추측하지 않고 실용적인 한도 정하기

좋은 한도는 한 가지 목표에서 시작합니다: 정상 사용자가 작업을 끝낼 수 있도록 하면서 백엔드를 보호하는 것. 첫날에 완벽한 숫자가 필요하진 않습니다. 안전한 기준선을 정하고 조정 방법을 마련하세요.

간단한 출발점은 API 유형에 맞춘 키별 제한입니다:

• 낮은 트래픽: 키당 분당 60–300 요청
• 중간 트래픽: 키당 분당 600–1,500 요청
• 높은 트래픽: 키당 분당 3,000–10,000 요청

그다음 엔드포인트 유형별로 한도를 나눕니다. 읽기 요청은 보통 저렴하므로 더 높은 한도를 줄 수 있습니다. 쓰기는 데이터를 변경하고 추가 로직을 트리거하므로 더 엄격한 제한이 필요합니다. 흔한 패턴은 GET에는 분당 1,000, POST/PUT/DELETE에는 분당 100–300 같은 구분입니다.

또한 비용이 큰 엔드포인트를 별도로 식별하세요. 검색, 리포트 생성, 내보내기, 파일 업로드, 여러 테이블을 조회하거나 무거운 비즈니스 로직을 실행하는 작업은 다른 경로보다 작은 버킷을 가져야 합니다. 시각적 워크플로우(예: Business Process 흐름)를 사용하는 백엔드는 단계가 늘어날수록 부하가 배가됩니다.

버스트를 대비해 두 개의 창을 계획하세요: 빠른 스파이크를 흡수할 단기 창과 지속적 사용을 억제할 장기 창. 흔한 조합은 10초 창과 10분 창입니다. 이렇게 하면 사용자가 빠르게 클릭할 때는 대응하고, 스크레이퍼에게 무제한 속도를 주지 않습니다.

마지막으로 클라이언트가 한도를 초과했을 때의 동작을 결정하세요. 대부분의 공용 API는 명확한 재시도 시간과 함께 HTTP 429를 반환합니다. 작업을 지연해도 안전하다면(예: 내보내기) 하드 블로킹 대신 큐잉을 고려해 실제 사용자가 결과를 얻을 수 있게 하세요.

공정하게 느껴지는 키별 쿼터 설계

키별 쿼터는 보통 고객 사용 방식과 가장 잘 맞기 때문에 공정한 접근입니다: 하나의 계정, 하나의 API 키, 책임이 명확합니다. IP 기반 제한은 여전히 유용하지만 무고한 사용자를 처벌하기 쉽습니다.

공유 IP가 문제입니다. 한 사무실 전체가 하나의 공용 IP를 통해 나갈 수 있고, 이동통신사는 수천 기기를 소수의 IP 뒤에 둘 수 있습니다. IP별 제한만 의존하면 한 명의 시끄러운 사용자가 모두를 느리게 만듭니다. 키별 쿼터는 이를 피할 수 있고, 명백한 플러드를 잡기 위해 가벼운 IP별 제한을 보조수단으로 둘 수 있습니다.

쿼터를 공정하게 느끼게 하려면 고객 등급과 연결하되 신규 사용자를 가두지 마세요. 무료 또는 트라이얼 키는 실사용 테스트에 충분히 동작해야 하지만 규모가 커서 피해를 주지는 않아야 합니다. 한 가지 간단한 패턴은 관대한 버스트, 적당한 지속률, 요금제에 맞는 일간 쿼터입니다.

예측 가능한 키별 정책:

• 짧은 버스트 허용(페이지 로드, 배치 임포트), 이후 안정된 비율 적용
• 스크레이핑과 무한 루프를 제한하기 위한 키별 일일 한도 추가
• 요금제별로 한도 증대, 하지만 구조는 동일하게 유지해 행동이 일관되게 함
• 새로 생성된 키에는 낮은 상한을 두어 좋은 이력을 쌓을 때까지 제한
• 명백한 플러드를 잡기 위한 소규모 IP별 한도 유지

키 공유와 자동 가입을 억제하기 위해 과도한 감시가 필요하진 않습니다. 비정상적인 지리적 이동, 한 키에 대한 시간당 지나치게 많은 서로 다른 IP, 동일 출처에서 생성된 많은 신규 키 같은 간단한 검사로 시작하세요. 먼저 플래그를 올리고 속도를 늦춘 뒤 반복 신호가 있을 때만 락아웃하세요.

익명 트래픽에는 더 엄격한 한도가 합리적입니다. 트라이얼 키를 제공한다면 엄격히 제한하고 기본 검증 단계(예: 이메일 확인) 없이 한도를 높이지 마세요. 공개 폼을 파워하는 API가 있다면 익명 엔드포인트를 별도로 두어 나머지 백엔드를 보호하세요.

AppMaster로 API를 구축하면 인증, 비즈니스 규칙, 응답 처리가 한곳에 모여 키별 로직을 일관되게 유지하기가 더 쉽습니다.

클라이언트 친화적 응답과 헤더(사용자가 복구할 수 있게)

레이트 리밋은 장기적으로 클라이언트가 무슨 일이 일어났는지 이해할 수 있어야 효과적입니다. 상태 코드, 필드, 의미를 엔드포인트 전반에 걸쳐 일관되게 유지하세요.

클라이언트가 한도에 도달했을 때는 HTTP 429(Too Many Requests)와 명확한 메시지, 구체적인 대기 시간을 반환하세요. 가장 빠른 개선은 Retry-After 헤더를 추가하는 것입니다. 간단한 클라이언트도 이를 보고 올바르게 일시중지할 수 있습니다.

몇 가지 헤더를 일관되게 포함하면 한도를 스스로 설명할 수 있습니다. 성공 응답과 429 응답 모두에 포함해서 클라이언트가 스스로 속도를 조절하거나 복구하게 하세요:

• Retry-After: 재시도까지 기다려야 할 초
• X-RateLimit-Limit: 현재 창의 허용 요청 수
• X-RateLimit-Remaining: 현재 창에서 남은 요청 수
• X-RateLimit-Reset: 창이 재설정되는 시각(에포크 초 또는 ISO 시간)
• X-RateLimit-Policy: "60 requests per 60s" 같은 짧은 정책 설명

오류 본문은 성공 응답만큼 구조화하세요. 흔한 패턴은 안정된 code, 사람이 읽을 수 있는 message, 그리고 복구 힌트를 포함한 오류 객체입니다.

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Too many requests. Please retry after 12 seconds.",
    "retry_after_seconds": 12,
    "limit": 60,
    "remaining": 0,
    "reset_at": "2026-01-25T12:34:56Z"
  }
}

클라이언트에 429이 발생했을 때 백오프 방법을 알려주세요. 지수적 백오프는 기본으로 좋습니다: 1초, 그다음 2초, 그다음 4초, 그리고 상한(예: 30–60초)을 둡니다. 또한 언제 재시도를 멈춰야 하는지도 명확히 하세요.

쿼터 가까이 갔을 때 놀라지 않도록 하세요. 키가 한도에 근접(예: 80–90%)하면 경고 필드나 헤더를 포함해 클라이언트가 실패하기 전에 속도를 늦출 수 있게 하세요. 하나의 스크립트가 여러 경로를 빠르게 호출해 예산을 빨리 소진할 수 있으므로 이런 경고는 특히 중요합니다.

단계별: 한도와 쿼터 롤아웃 계획

한도를 제품 행동으로 다루면 롤아웃이 원활합니다. 목표는 동일합니다: 정상 고객은 움직일 수 있게 하고 백엔드를 보호하세요.

간단한 인벤토리로 시작하세요. 모든 엔드포인트를 나열하고 각 엔드포인트를 비용(CPU, DB 작업, 서드파티 호출)과 위험(로그인, 비밀번호 재설정, 검색, 파일 업로드)으로 표시하세요. 이것은 모든 곳에 하나의 일괄 제한을 적용하는 실수를 막습니다.

롤아웃 순서(대부분의 경우 문제를 피함):

• 엔드포인트를 비용과 위험으로 태깅하고, 더 엄격한 규칙이 필요한 경로(로그인, 대량 내보내기)를 결정
• 아이덴티티 키 우선순위 결정: 먼저 API 키, 그다음 사용자 ID, IP는 폴백
• 버스트와 스크립트를 막기 위한 단기(10초 또는 1분) 제한 추가
• 지속 사용을 제한하기 위한 장기(시간별 또는 일별) 쿼터 추가
• 운영이 차단되지 않도록 내부 도구와 신뢰 시스템을 위한 허용목록 추가

첫 출시에서는 보수적으로 시작하세요. 나중에 느슨하게 하는 것이 분노한 사용자를 해제하는 것보다 쉽습니다.

모니터링과 튜닝, 그리고 정책 버전 관리도 필수입니다. 얼마나 많은 요청이 한도에 걸리는지, 어떤 엔드포인트가 트리거하는지, 얼마나 많은 고유 키가 영향을 받는지 추적하세요. 수치를 변경할 때는 API 변경처럼 문서화하고 점진적으로 배포하며 이전 규칙과 새 규칙을 분리해 빠르게 롤백할 수 있게 하세요.

AppMaster로 API를 만들면 엔드포인트와 비즈니스 로직 옆에서 규칙을 계획해 각 워크플로우의 실제 비용에 맞게 한도를 맞출 수 있습니다.

사용자에게 부담을 주지 않는 락아웃 워크플로우

락아웃은 안전벨트와 같습니다. 명백한 남용을 빠르게 막아야 하지만, 문제가 생겼을 때 정상 사용자가 복구할 길을 분명히 제공해야 합니다.

평정심을 유지하는 방식은 점진적 제재입니다. 클라이언트가 악의적이라기보다 잘못 구성되었을 가능성을 가정하고, 같은 패턴이 반복될 때만 단계적으로 강화하세요.

간단한 점진적 단계

설명과 구현이 쉬운 소수 단계만 사용하세요:

• 경고: 한도에 접근 중임을 알리고 재설정 시각 제공
• 지연: 해당 키에 대해 짧은 지연이나 초당 제한 강화
• 임시 잠금: 몇 분간 차단하고 정확한 해제 시각 제공
• 장기 잠금: 여러 창에 걸쳐 반복되는 경우에만 적용
• 수동 검토: 의도적이거나 계속 발생하는 패턴에 대해 수동 검토

무엇을 잠그느냐가 중요합니다. 키별 잠금이 보통 가장 공정합니다. 계정별 잠금은 사용자가 키를 교체할 때 유용합니다. 익명 트래픽에는 IP별이 도움이 될 수 있지만 NAT, 사무실, 이동통신사 때문에 오탐이 발생합니다. 심각한 남용 시에는 신호를 조합하세요(예: 키를 잠그고 해당 IP에 대해 추가 확인 요구). 단, 영향 범위는 작게 유지하세요.

락아웃은 시간 기반으로 하고 단순한 규칙을 쓰세요: "14:05 UTC까지 차단" 또는 "30분의 정상 행위 이후 해제" 같은 방식. 자동 시스템에는 영구 차단을 피하세요. 잘못된 클라이언트는 빠르게 한도를 소진하므로 제재는 시간에 따라 서서히 사라지도록 설계하세요. 장기간 낮은 비율의 사용은 제재 수준을 낮춰야 합니다.

AppMaster로 API를 구축하면 이 계단식 접근을 카운터 저장과 비즈니스 프로세스로 쉽게 매핑해 허용, 지연, 차단을 결정하고 키의 해제 시각을 기록할 수 있습니다.

반복 위반자에 대해서는 수동 검토 경로를 마련하세요. 사용자와 불필요하게 다투지 마세요. 요청 ID, 타임스탬프, API 키 이름을 요청하고 증거에 따라 결정하세요.

오탐을 일으키는 일반적 실수

오탐(false positive)은 방어 장치가 정상 사용자를 차단할 때 발생합니다. 대개 규칙이 실제 사용 방식에 비해 단순할 때 생깁니다.

전형적인 실수는 모든 것에 하나의 전역 한도를 적용하는 것입니다. 저렴한 읽기 엔드포인트와 비싼 내보내기를 동일하게 취급하면, 저렴한 쪽을 과도하게 보호해 사용자를 짜증나게 하거나 비싼 쪽을 충분히 보호하지 못해 위험해집니다. 엔드포인트 비용별로 한도를 나누고 무거운 경로에는 더 엄격하게 하세요.

IP 전용 제한도 함정입니다. 많은 실제 사용자가 하나의 공용 IP를 공유합니다(사무실, 학교, 이동통신사). 한 명의 무거운 사용자가 모두를 차단할 수 있어 무작위 다운처럼 보입니다. 우선 API 키별 제한을 적용하고 IP는 보조 신호로 사용하세요.

제한 저장소(limiter store)가 다운되면 실패 방식도 오탐의 원인입니다. "닫힘(fail closed)"은 전체 API를 끊을 수 있고, "열림(fail open)"은 스파이크를 초대할 수 있습니다. 분명한 폴백 동작을 선택하세요: 엣지에서 작은 비상 한도를 유지하고 비핵심 엔드포인트에서 우아하게 저하하세요.

클라이언트 처리도 대부분의 팀이 예상하는 것보다 중요합니다. 일반적인 429만 반환하면 사용자가 더 격렬히 재시도해 더 많은 차단을 유발합니다. 항상 Retry-After를 보내고 오류 텍스트는 구체적으로 유지하세요("이 키의 요청이 너무 많습니다. 30초 후에 다시 시도하세요.").

가장 피하기 쉬운 문제는 비밀성입니다. 숨겨진 한도는 고객이 처음으로 프로덕션 부하를 만났을 때 버그처럼 느껴집니다. 간단한 정책을 공유하고 안정적으로 유지하세요.

오탐을 피하기 위한 빠른 체크리스트:

• 비용이 큰 엔드포인트와 저렴한 엔드포인트에 대한 분리된 한도
• IP만이 아닌 API 키를 통한 기본 제한
• 리미터가 사용 불가일 때의 정의된 동작
• Retry-After가 포함된 명확한 429 응답
• 집행 전 한도 문서화 및 공지

AppMaster로 API를 만들면 보통 엔드포인트별로 다른 캡을 설정하고 일관된 오류 페이로드를 반환해 클라이언트가 추측 없이 백오프하도록 할 수 있습니다.

도움이 되는 모니터링과 알림

레이트 리밋은 실시간으로 무슨 일이 일어나는지 볼 수 있어야만 효과가 있습니다. 목표는 모든 스파이크를 잡는 것이 아니라 장애나 화난 사용자로 이어질 패턴을 파악하는 것입니다.

볼륨과 의도를 설명하는 소수의 신호로 시작하세요:

• 분당 요청 수(전체 및 키별)
• 429 비율(스로틀된 요청) 및 5xx 비율(백엔드 문제)
• 반복되는 401/403 폭증(잘못된 키, 자격 증명 채우기, 잘못 구성된 클라이언트)
• 볼륨별 및 비용별 상위 엔드포인트(느린 쿼리, 무거운 내보내기)
• 상위 10위에 새로 등장한 예기치 않은 엔드포인트

"나쁜 트래픽"과 "우리 배포했음"을 구분하려면 대시보드에 문맥을 추가하세요: 배포 시간, 기능 플래그 변경, 마케팅 발송 등. 트래픽이 배포 직후 상승하고 429/5xx 비율이 양호하면 보통 성장이지 남용이 아닙니다. 트래픽 상승이 한 키, 한 IP 범위, 또는 무거운 엔드포인트에 집중되어 있다면 의심해보세요.

알림은 단조롭게 만드세요. 동일한 이벤트로 매분 알람을 받지 않도록 임계값과 쿨다운을 사용하세요:

• 10분 동안 429 비율이 X% 초과하면 시간당 한 번 알림
• 5분 동안 5xx가 Y% 초과하면 즉시 페이징
• 한 키가 15분 동안 쿼터를 Z% 초과하면 조사를 시작
• 분당 N건 이상의 401/403 폭증은 남용 가능성으로 플래그

알림이 울리면 짧은 인시던트 노트를 남기세요: 변경된 사항, 관찰된 것(상위 키/엔드포인트), 조정한 사항(한도, 캐시, 임시 차단). 시간이 지나면 이런 노트가 실제 플레이북이 됩니다.

예: 새로운 검색 엔드포인트를 출시하고 트래픽이 두 배가 되었다고 가정합시다. 호출이 많은 키들에 걸쳐 대부분 그 엔드포인트에 집중된다면 키별 쿼터를 약간 올리고 엔드포인트를 최적화하세요. 한 키가 내보내기를 무한히 호출해 지연을 올린다면 해당 엔드포인트를 별도로 제한하고 소유자에게 연락하세요.

출시 전후의 빠른 체크리스트

잘 동작할 때는 지루한 설정이 좋습니다. 이 체크리스트는 보통 오탐을 만들거나 눈에 띄는 구멍을 남기는 문제를 잡습니다.

새 엔드포인트 출시 전

스테이징과 출시 직후에 다음을 확인하세요:

• 아이덴티티: 리미터가 올바른 키(우선 API 키, 폴백은 사용자나 IP)를 기준으로 작동하는지, 키 회전 시 이전 제재가 상속되지 않는지 확인
• 한도: 기본 키별 쿼터를 설정한 뒤 엔드포인트 비용(저렴한 조회 vs 비싼 쓰기)에 따라 조정
• 응답: 상태와 복구 정보를 명확히 반환(재시도 시각, 남은 예산, 안정된 오류 코드)
• 로그: 누가 제한되었는지(키/사용자/IP), 어떤 라우트에서 어떤 규칙이 발동했는지, 지원을 위한 요청 ID 기록
• 예외: 모니터와 신뢰 통합을 위한 비상 허용목록 유지

AppMaster를 사용하면 각 신규 API 엔드포인트를 비용 등급 결정으로 취급하세요: 단순 조회는 관대하게, 무거운 비즈니스 로직을 트리거하는 작업은 초기부터 엄격하게.

인시던트 발생 시(남용 또는 갑작스런 트래픽)

정상 사용자가 복구할 수 있게 백엔드를 보호하세요:

• 위험도가 낮은 경로(보통 읽기)에 대해서만 일시적으로 상한을 올리고 오류율을 관찰
• 조사하는 동안 알려진 우수 고객을 위한 짧은 허용목록 추가
• 전역 한도 완화 대신 특정 위험 경로를 더 엄격히 제한
• 공유 네트워크를 차단하지 않도록 인증 강화(API 키 요구, IP 의존도 축소)
• 샘플 캡처: 상위 키, 상위 IP, 유저 에이전트, 정확한 페이로드 패턴

고객에게 한도를 늘려주기 전에 정상 요청 패턴, 엔드포인트 구성, 배치 또는 백오프 추가 가능성을 확인하세요. 또한 하나의 키를 여러 앱에서 공유하는지 여부를 확인하세요.

월별로 검토하세요: 상위 제한된 엔드포인트, 한도에 걸린 트래픽 비율, 새로 발견된 고비용 경로, 쿼터가 실제 사용에 맞는지 여부.

예시 시나리오: 사용자를 깨뜨리지 않고 공용 API 보호하기

당신이 운영하는 공용 API를 고객 포털(고빈도, 꾸준한 트래픽)과 내부 관리자 도구(저빈도지만 강력한 작업) 두 앱이 사용한다고 가정합시다. 둘 다 API 키를 사용하고 포털에는 엔드유저용 로그인 엔드포인트도 있습니다.

어느 날 파트너가 버그 있는 통합을 배포해 실패한 요청을 타이트 루프로 재시도하면서 하나의 API 키로 초당 200개의 요청을 보내기 시작합니다. 방치하면 그 하나의 키가 다른 모든 사용자를 밀어낼 수 있습니다.

키별 한도는 영향 범위를 제한합니다. 버그 키가 분당 한도에 걸리면 429 응답을 받고 다른 고객은 계속 서비스 이용이 가능합니다. 또한 내보내기 같은 비용이 큰 엔드포인트에는 별도의 더 낮은 한도를 두면 "허용된" 트래픽이라도 데이터베이스를 과부하시키지 못합니다.

동시에 무차별 로그인 시도가 인증 엔드포인트를 두드리고 있다면 전체 IP 범위를 차단하는 대신, 이를 느리게 하고 행동 기반으로 잠금합니다: 계정별 실패 시도 수와 짧은 창에서의 IP별 실패 합계를 결합합니다. 공격자는 점점 더 긴 대기 시간을 겪다가 임시 잠금에 걸립니다.

몇 번 비밀번호를 잘못 입력한 실제 고객은 다음 때문에 복구할 수 있습니다:

• 429과 함께 Retry-After가 있어 클라이언트가 언제 다시 시도할지 알 수 있음
• 짧은 잠금 창(예: 10–15분), 영구 차단이 아님
• 계정 존재 여부를 노출하지 않는 일관된 오류 메시지

수정 확인을 위해 몇 가지 지표를 관찰합니다:

• API 키와 엔드포인트별 429 비율
• 인증 실패율과 락아웃 횟수
• 사고 동안의 P95 지연과 데이터베이스 CPU
• 영향을 받은 고유 키 수(작아야 함)

이것이 정상 사용자를 벌주지 않으면서 백엔드를 보호하는 레이트 리밋의 모습입니다.

다음 단계: 작은 정책을 마련하고 반복하세요

첫날 완벽한 모델이 필요하지 않습니다. 작고 명확한 정책으로 시작해 실제 사용자를 관찰하며 개선하세요.

신뢰할 만한 첫 버전은 보통 세 부분으로 구성됩니다:

• 대부분 엔드포인트를 커버하는 키별 기본값(분당 요청 수)
• 비용이 큰 엔드포인트(검색, 내보내기, 파일 업로드, 복잡한 리포트)에 대한 더 엄격한 상한
• 클라이언트가 다음에 무엇을 해야 하는지 알려주는 짧은 메시지가 포함된 명확한 429 응답

남용 위험이 높고 의도를 추론하기 쉬운 곳에만 락아웃을 추가하세요. 가입, 로그인, 비밀번호 재설정, 토큰 생성은 전형적인 후보입니다. 잠금은 처음엔 짧게(분 단위), 점진적 마찰을 선호하세요: 느리게 한 뒤 임시 차단, 그다음 더 강한 확인 요구.

정책을 비전문가도 설명할 수 있게 쉬운 언어로 문서화하세요. 무엇을 제한하는지(키별, IP별, 계정별), 재설정 창, 고객이 복구하는 방법을 포함하세요.

새 백엔드를 구축하면서 이를 구현한다면 AppMaster는 실용적인 선택이 될 수 있습니다: API를 생성하고 비즈니스 워크플로(카운터와 락아웃 결정 포함)를 시각적으로 정의한 뒤 클라우드에 배포하거나 필요하면 생성된 소스 코드를 내보낼 수 있습니다.