레이트 리미팅이란? 앱 빌더를 위한 쉬운 가이드

레이트 리미팅은 정해진 시간 안에 누군가가 시스템에 보낼 수 있는 요청 수를 제한하는 규칙입니다. 예를 들어 분당 로그인 시도 5회, 또는 시간당 API 호출 100회입니다. 한도에 도달하면 시간 창이 초기화될 때까지 추가 요청은 거부됩니다(보통 429 Too Many Requests 오류 코드로 응답합니다). 이를 통해 앱은 남용으로부터 보호되고, 한 명의 과도한 사용자가 모두의 속도를 떨어뜨리는 것을 막으며, 비용이 통제 불능으로 늘어나는 것을 막을 수 있습니다.

레이트 리미팅은 두 방향에서 만나게 됩니다. 여러분이 호출하는 서비스는 여러분을 제한하고, 여러분의 앱은 자신의 사용자를 제한해야 합니다.

AI로 만들 때 레이트 리미팅이 중요한 이유

AI로 만든 앱은 종종 AI 모델, 이메일, SMS, 지도 같은 유료 서비스에 연결되며, 각 호출에는 돈이 듭니다. 그래서 레이트 리미팅은 보안 기능이자 예산 기능입니다.

• 비용 통제. 앱에 'AI에게 묻기' 입력창이 있고 제한이 없다면, 봇이 밤새 수천 번 요청할 수 있습니다. 요청마다 돈을 내게 됩니다.
• 보안. 로그인 폼에 제한이 없으면 공격자가 계정 하나에 수천 개의 비밀번호를 시도할 수 있습니다. 분당 몇 번으로 제한하면 그것이 비현실적이 됩니다.
• 온라인 상태 유지. 잘못 동작하는 스크립트 하나, 때로는 여러분의 코드가 무한 루프에 빠진 것만으로도 데이터베이스가 과부하되어 앱이 멈출 수 있습니다.
• 외부 서비스의 제한 존중. 앱이 외부 API를 너무 자주 호출하면 여러분이 429 오류를 받고, 사용자에게 기능이 깨집니다.

AI 빌더는 요청한 것을 만들어 줍니다. 제한을 언급하지 않으면 자주 빠집니다.

일상적인 비유

커피숍의 무료 리필 정책을 생각해 보세요. "손님 한 명당 방문 시 리필 한 번."

• 커피를 즐기는 것을 막지는 않습니다.
• 한 사람이 카운터에 하루 종일 서서 사무실 전체를 위해 보온병을 계속 채우는 것을 막습니다.
• 네 번째 리필을 요청하면 바리스타가 "지금은 안 돼요"라고 정중히 말합니다. 그것이 429입니다.

좋은 레이트 리밋은 평범한 손님에게는 보이지 않고, 특이한 행동을 하는 사람에게만 눈에 띕니다.

레이트 리미팅의 작동 방식

레이트 리미터에는 세 가지가 필요합니다.

요청이 도착하면 앱은 그 "누구"의 카운트를 확인합니다. 한도 이하이면 요청이 통과하고 카운트가 올라갑니다. 한도를 넘으면 요청은 거부됩니다.

흔한 계산 방식은 몇 가지 있습니다.

카운트는 빠르고 공유되는 곳에 저장되어야 합니다. 작은 서버 한 대라면 메모리로 충분합니다. 앱이 여러 대의 기계에서 돌아간다면, 카운터는 보통 Redis 같은 공유 저장소나 데이터베이스에 있어야 합니다. 그렇지 않으면 각 기계가 따로 세어서, 실제 한도가 몇 배로 높아집니다.

제한된 응답의 모습

요청이 한도를 넘으면 잘 설계된 API는 다음과 같이 응답합니다.

• 상태 코드 429 Too Many Requests.
• 보통 Retry-After 헤더가 함께 와서, 몇 초를 기다려야 하는지 알려 줍니다.
• 때로는 한도와 이 시간 창에서 남은 요청 수를 보여주는 헤더도 옵니다(이름은 제공업체마다 다릅니다).

앱은 429를 받으면 기다렸다가 나중에 다시 시도해야 합니다. 가능하면 지수 백오프를 사용하세요. 실패할 때마다 조금씩 더 오래 기다리는 방식입니다(1초, 그다음 2초, 그다음 4초). 실패한 요청을 서비스에 연타하지 않기 위해서입니다.

실제 예시: AI 글쓰기 도우미

사용자가 텍스트를 붙여넣으면 AI가 다시 써 주는 앱을 만들었다고 해봅시다.

제한이 없을 때: 누군가 밤새 20,000번 요청하는 스크립트를 돌립니다. AI 제공업체 청구서가 치솟고, 계정이 제공업체 자체의 레이트 리밋에 걸려서, 아침 내내 실제 사용자들이 오류를 봅니다.

합리적인 제한이 있을 때:

1. 로그인한 사용자별: 무료 요금제는 시간당 재작성 30회, 유료 요금제는 300회. 한도를 넘으면 사용자에게 "이번 시간의 한도에 도달했습니다. 12분 후에 다시 시도하거나 업그레이드하세요."라고 보입니다.
2. 가입 폼의 IP 주소별: 시간당 가입 5회. 봇이 사용자별 한도를 피하려고 무료 계정을 수천 개 만드는 것을 막기 위해서입니다.
3. AI 제공업체 대시보드에서 설정한 지출 상한. 다른 모든 것이 실패했을 때의 최후 방어선입니다.
4. 제공업체의 한도 처리: AI 제공업체가 429를 반환하면, 서버는 한두 번 기다렸다가 재시도하고, 그래도 안 되면 "지금은 바쁩니다. 다시 시도해 주세요"라는 친절한 메시지를 보여 줍니다.

제한은 서버에서 확인되어야 합니다. 브라우저에서만 존재하는 제한, 예를 들어 30번 클릭하면 버튼을 비활성화하는 방식은 API를 직접 호출하는 누구에게나 우회될 수 있습니다.

핵심 용어

흔한 오해

• "레이트 리미팅은 큰 앱에만 필요하다." 작은 앱도 표적이 됩니다. 봇은 열린 폼과 AI 엔드포인트를 인터넷 전체에서 찾아 스캔하기 때문입니다. 남용의 비용은 앱 규모와 무관합니다.
• "버튼을 숨기면 충분하다." 브라우저 쪽 제한은 편의일 뿐 보호가 아닙니다. 실제 제한은 서버에서 강제되어야 합니다.
• "IP별 제한은 항상 공정하다." 많은 사람이 하나의 IP 주소를 공유할 수 있습니다. 사무실, 학교, 모바일 네트워크가 그렇습니다. 사용자가 로그인한 뒤에는 사용자별 제한이 더 공정합니다.
• "429는 서비스가 고장 났다는 뜻이다." 그것은 여러분이 너무 자주 호출하고 있다는 뜻입니다. 코드에 루프가 없는지 확인하고, 자주 바뀌지 않는 결과는 캐시하세요. 캐싱이란을 참고하세요.
• "레이트 리미팅이 지출 상한을 대신한다." 둘 다 사용하세요. 앱 안의 제한에도 버그가 있을 수 있습니다. 제공업체의 지출 상한이 최후의 안전장치입니다.

AI 빌더에게 요청할 것

• "로그인, 가입, 비밀번호 재설정, AI 엔드포인트에 서버 측 레이트 리미팅을 추가해 주세요. 합리적인 한도를 제안해 주세요."
• "로그인한 사용자마다 AI 요청을 시간당 [N]회로 제한하고, 한도에 도달하면 대기 시간을 보여 주는 명확한 메시지를 띄워 주세요."
• "외부 API가 429를 반환하면, 최대 3번까지 지수 백오프로 재시도한 뒤 친절한 오류 메시지를 보여 주세요."
• "레이트 리밋 카운터는 어디에 저장되나요? 앱이 여러 대의 기계에서 돌아가도 제대로 작동하나요?"
• "사용자나 IP가 한도에 걸릴 때마다 기록해서 남용을 발견할 수 있게 해 주세요."
• "이 앱이 호출하는 외부 서비스는 무엇이며, 각 서비스의 레이트 리밋은 얼마인가요?"

Mythex의 레이트 리미팅

Mythex 문서는 AI 기능에 대해 분명히 말합니다. 여러분이 만든 앱의 레이트 리밋, 안전 및 비용 통제는 여러분이 설계해야 합니다. AI 앱 만들기를 참고하세요. 기능을 요청하는 같은 메시지에서 에이전트에게 제한도 추가해 달라고 하세요. Pro 요금제에서는 트래픽이 많을 때 게시된 서비스가 최대 세 대의 기계에서 돌아갈 수 있으므로(호스팅 제한 참고), 한 서버의 메모리가 아니라 데이터베이스에 있는 카운터를 요청하세요.

관련 자료: API란 무엇인가, LLM API 사용법, AI로 만든 앱의 보안 체크리스트

자주 묻는 질문