목차

1. 문제 정의

수이, 머핀 안녕하십니까- 전에 말씀드렸던 rate limit 방어 코드를 완성해서 해결 과정 문서 공유합니다😃

발단: 픽잇의 무한 루프로 인한 API 무한 호출 사건

픽잇은 react-router v7 의 비긴급 업데이트와 Suspense 의 startTransition 시 fallback 표시 안함 의 조합으로 인해 백그라운드에서 조용히 API 를 무한 호출한 사건이 있었어요.

(자세한 트러블 슈팅은 여기에서)

해당 사건은 해결이 됐지만, 백그라운드에서 사용자 몰래 조용히 API 가 초에 수십번 요청됐던 버그는 저희의 서버 비용 폭탄!으로 이어질 수 있던 심각한 버그였죠.

그래서 이런 비정상적인 서버 요청에 대해 서버 측 뿐만 아니라 프론트엔드에서도 방어 조치가 있으면 좋을 것 같다는 생각이 들었어요.

또 언제 문제가 될 수 있을까?

목표: 클라이언트의 무한 루프에 따른 API 무한 요청 방어 - rate limit

그래서 핵심 문제 해결의 목표는 위와 같이 정의했어요.

DoS 공격이나 서버의 과부하에 초점을 맞춘 해결 과정은 아닙니다! 앞으로 예기치 못한 클라이언트의 무한 루프가 발생했을 때 적절한 대처를 즉시할 수 있도록 고안하는 글이에요.

프론트엔드에서 rate limit 도입의 이점

제가 구상한 rate limit 방법은 **‘수 초내 수십번의 요청이 갈 경우 비정상적인 API 요청이라고 판단, 에러 토스트 안내 후 에러 페이지로 이동’**이에요.

그런데 백엔드에서도 429 Too Many Request 로 방어해주시기로 했는데요, 서버에서 이미 막아주고 있는데 프론트에서도 막으면 좋을 이유는 뭘까요?