[기술 검토 및 선정] 사용자 세션 관리로 Redis 선택 이유

무상태(Spring Stateless) API 서버에서는 클라이언트가 Access Token(AT)을 요청마다 헤더에 담아 전송하며, AT의 짧은 유효기간으로 인한 불편을 줄이고 보안을 유지하기 위해 보통 Refresh Token(RT)을 함께 사용한다.

Refresh Token은 재발급 요청 시 서버가 유효성을 검사할 수 있어야 하므로 서버 측 저장소가 반드시 필요하다. 이에 따라 RT의 저장소로는 MySQL, Redis 등의 선택지가 존재한다.

🧐 그럼 어떤 걸 써야 할까?

• MySQL은 영속성이 보장되고 관계형 데이터베이스의 안정성을 기반으로 RT를 저장하는 데 사용할 수 있다. 하지만 RT는 보통 짧은 생명 주기를 가지며, 로그인/로그아웃/재발급 등에서 빠른 응답성과 효율적인 만료 관리가 요구된다.
• Redis는 메모리 기반의 NoSQL 캐시 저장소로, RT와 같은 짧고 빈번하게 사용되는 토큰의 저장에 최적화되어 있다. TTL(Time To Live)을 활용해 자동 만료 처리를 할 수 있고, 요청에 대한 응답 속도가 매우 빠르다.

👉 Redis는 메모리 기반으로 마이크로초 단위의 응답 속도를 제공하며, 키마다 TTL을 지정해 자동 만료가 가능해 관리가 간편하다. 또한 키-값 구조로 RT 저장/조회/삭제 로직이 직관적이며, 인증·캐시 등 고속 처리를 위한 전용 서버로도 활용 가능하다. 반면 MySQL은 디스크 기반으로 상대적으로 느리고, 만료 관리를 위해 별도 컬럼과 배치 처리가 필요하며, 테이블 설계 및 성능 튜닝 등 유지보수 부담이 크고, RT까지 함께 처리할 경우 비즈니스 DB에 불필요한 부하가 발생할 수 있다. 이러한 점에서 Redis는 RT 저장에 더 적합하다고 판단했다.

 

끝.