API에 제한을 붙일 때 가장 먼저 떠오르는 문장은 ‘분당 몇 번 허용할까’입니다. 하지만 같은 분당 열 번이라도 읽기 요청과 파일 변환 요청의 비용은 다릅니다. 제한값 하나를 정하기 전에 정책의 목적을 분리해야 합니다.이번 글에서는 ASP.NET Core의 Rate Limiting 미들웨어를 특정 값의 정답이 아니라 정책 선택 도구로 읽어 보겠습니다. 실제 값은 부하 테스트와 사용자 행동을 보고 조정해야 합니다.제한의 목적을 네 가지로 나눕니다Rate Limiting은 악성 요청만 막는 기능이 아닙니다. 공정 사용량을 보장하고, 백엔드 자원을 보호하고, 외부 비용을 통제하고, 동시 작업 수를 제한하는 데 사용할 수 있습니다. 목적이 다르면 관찰할 지표와 실패 응답도 달라집니다.저는 엔드포인트마다 ‘무엇..

회원가입을 요구하지 않는 서비스는 진입 장벽이 낮다는 장점이 있습니다. 대신 한 사람이 반복 요청을 보내도 누구인지 구분하기 어렵고, 공격과 정상 사용을 구분할 정보가 부족합니다.저는 처음부터 복잡한 인증을 붙이기보다 서비스가 감당할 수 있는 행동의 범위를 정했습니다. 이번 글에서는 경로별 제한, 사용자 식별, 실패 응답, 관찰 지표를 최소 구성으로 나눠 보겠습니다.막아야 할 행동을 먼저 정의합니다스팸은 사용자라는 사람이 아니라 행동의 패턴으로 나타납니다. 짧은 시간에 같은 요청을 반복하거나, 파일 크기가 비정상적으로 크거나, 실패한 요청만 계속 보내는 식입니다. 무엇을 막을지 정하지 않고 방어 도구부터 붙이면 정상 사용도 함께 막힙니다.저는 엔드포인트마다 비용과 피해를 적습니다. 읽기 요청과 데이터 생..

개인 프로젝트는 처음에 사용자가 적어 비용도 작습니다. 그래서 사용량 제한을 나중에 붙이려 합니다. 하지만 공개 주소가 알려지거나 자동화된 요청이 들어오면 비용과 장애가 동시에 커질 수 있습니다.저는 기능을 추가하기 전에 요청을 세고, 상한을 넘으면 알려 주고, 더 넘으면 안전하게 거절하는 흐름을 만들기로 했습니다. 이번 글에서는 숫자 자체보다 제한 정책을 정하는 순서를 설명합니다.API마다 비용과 위험이 다릅니다모든 엔드포인트에 같은 제한을 걸면 사용자는 불편하고 운영자는 중요한 기능을 구분하지 못합니다. 읽기 요청은 캐시로 흡수할 수 있지만, 외부 AI 호출이나 파일 변환은 한 번의 요청도 비용이 큽니다.저는 먼저 엔드포인트를 비용·시간·데이터 변경 여부로 나눕니다. 그 다음 사용자별 제한과 전체 제..