Rate limiting과 세션 문제 배포 전 확인

로그인 시스템에 rate limiting을 추가했을 때, 배포 후에 사용자들이 갑자기 로그인을 못 하는 문제가 생길 수 있다. 로컬에서는 잘 작동했는데 운영 환경에서 문제가 나는 이유는 대부분 환경의 차이 때문이다.

배포 전 체크리스트

배포 전에 다음을 반드시 확인해야 한다:

1. Rate limiting의 임계값이 운영 환경에 맞게 설정되어 있는가?
2. 세션 저장소(Redis, 메모리 등)가 제대로 연결되어 있는가?
3. 같은 IP에서 여러 요청이 들어올 때 정말로 제한되는가?

로컬과 운영의 차이

로컬 환경에서는 항상 같은 IP(127.0.0.1)에서 요청이 온다. 하지만 운영 환경에서는 프록시, 로드 밸런서, 게이트웨이를 거치면서 IP가 변할 수 있다. 따라서 rate limiting이 IP 기반이라면 실제 환경에서는 전혀 다르게 작동할 수 있다:

// 잘못된 예
const ip = req.connection.remoteAddress; // 항상 같을 수 있음

// 올바른 예
const ip = req.headers['x-forwarded-for'] || req.connection.remoteAddress;

이벤트 흐름 추적

로그인 요청이 rate limiting에 걸렸을 때 실제로 무슨 일이 일어나는지 추적해야 한다:

npm run build

빌드 후 개발자 도구의 Network 탭에서 로그인 요청을 보면 상태 코드가 429(Too Many Requests)로 돌아올 것이다. 이 경우 몇 초 뒤에 다시 시도해야 한다는 응답 헤더를 확인해야 한다.

세션 상태 점검

Rate limiting에 걸려도 세션이 유지되어야 한다. 만약 세션이 끊기면서 로그아웃되는 문제가 있다면 더 큰 문제다:

app.use(rateLimit({
  store: redisStore, // Redis로 세션 저장
  max: 5, // 5번 시도
  windowMs: 15 * 60 * 1000, // 15분
  // 제한 도달 시에도 세션은 유지되어야 함
}));

모바일 시뮬레이션

모바일 환경에서는 네트워크가 불안정할 수 있어서 같은 요청이 여러 번 들어올 수 있다. 이 경우 rate limiting이 너무 엄격하면 사용자가 로그인을 시도할 때마다 제한에 걸릴 수 있다.

실패 시 대체 전략

만약 로그인이 계속 실패한다면:

1. 캐시(Redis, Memcached)가 정상인지 먼저 확인한다.
2. Rate limiting 값을 임시로 늘려서 테스트해본다.
3. 공개 화면에서 실제로 로그인이 되는지 여러 번 시도해본다.

기록과 모니터링

Rate limiting이 발동될 때마다 로그를 남겨두면 나중에 문제를 분석하기 좋다. 특히 정상 사용자가 실수로 제한에 걸리지 않도록 임계값을 적절히 조정하는 것이 중요하다.

이런 배포 전 확인들이 번거로워 보일 수 있지만, 운영 중에 사용자가 로그인을 못 하면 훨씬 더 큰 문제가 된다.