Refresh Token을 Redis에 저장한 이유

개요

---

프로젝트를 개선 과정에서, JWT 인증 로직을 리팩터링 하고자 했습니다.

 

JWT와 관련된 자료를 찾아보던 중, Refresh Token을 Redis에 저장하는 사례를 많이 찾아볼 수 있었습니다.

 

하지만 대부분의 글에서 제시하는 Redis 사용 근거는 비슷했습니다.

 

Access Token 만료 시, Refresh Token을 RDB에서 조회하는 것보다 Redis에서 조회하는 것이 빠르다.

 

 

하지만, 단순한 성능 개선만으로는 "토큰 조회를 위한 Redis 도입"의 충분한 이유가 되지 않는다고 판단했습니다.

 

프로젝트 상황

---

프로젝트에서는 Refresh Token과 Access Token을 사용하고 있습니다.

 

Refresh Token이 RDB에서 조회되는 경우는 토큰 재발급 상황입니다.

 

토큰 재발급 플로우

1. Access Token 만료 시 클라이언트가 재발급 요청
2. 서버는 기존 Refresh Token을 RDB에서 꺼내 검증
3. 검증이 완료되면 기존 토큰은 삭제하고 새로운 토큰을 발급
4. 새 토큰을 DB에 저장

토큰 유효기간

• Access 토큰의 유효기간 : 1시간
• Refresh Token의 유효기간 : 2주

프로젝트는 콘서트 예매 서비스로, 특정 시간대에 요청이 몰릴 수 있습니다.

 

다만, 프로젝트 규모가 크지 않고, 트래픽이 몰리더라도 Access Token의 유효기간이 1시간이기 때문에, 재발급 요청이 동시에 집중될 가능성은 낮을 것으로 판단했습니다.

 

물론, 캐싱을 도입하여 디스크 I/O를 줄인다면 토큰 재발급 과정에서 발생할 수 있는 성능을 개선할 수는 있습니다.

 

Redis를 활용하여 다른 장점을 가져갈 수는 없을까요?

 

 

TTL을 활용한 토큰 자동 만료

---

프로젝트를 다시 살펴보던 중, 중요한 문제를 발견했습니다.

 

사용자가 명시적으로 로그아웃하지 않는 경우, RDB에 저장된 Refresh Token이 삭제되지 않고 계속 남아있었습니다.

 

실제로 필자도 다른 서비스를 이용하면, 로그아웃 하지 않고 브라우저를 닫습니다.

 

 

이는 곧, 만료되었지만 삭제되지 않은 Refresh Token들이 계속해서 누적되고 있음을 의미했습니다.

 

서비스가 장기 운영될수록 불필요한 데이터가 증가하고 DB 공간이 낭비될 수 있습니다.

 

 

RDB를 사용하면서 만료된 토큰을 삭제하기 위해서는 스케줄러를 통해 주기적으로 관리해야 했습니다.

 

이는 관리 비용이 높고 구현이 번거롭다고 생각했습니다.

 

 

반면 Redis는 TTL(Time To Live)이라는 기능을 제공하여,

 

토큰 저장 시 만료 시간을 설정해 두면 해당 시간이 지났을 때 데이터를 자동으로 삭제할 수 있었습니다.

 

즉, 별도로 만료된 토큰 삭제 로직을 작성하지 않더라도 토큰을 관리할 수 있었습니다.

 

결론

---

프로젝트에서는 이미 조회 API의 캐싱을 위해 Redis를 사용하고 있었습니다.

 

따라서 새로운 인프라의 학습 없이, 쉽게 적용해 볼 수 있다고 판단하고 Redis에 토큰을 저장하도록 수정했습니다.

 

또한, Redis를 적용하기로 한 세 가지 이유를 정리하면 다음과 같습니다.

1. TTL 토큰 자동 만료
2. 확정성 - 블랙리스트, 세션 무효화 등 추가 기능 구현
3. 성능 향상

성능 향상이라는 주제로 Redis 사용을 고려했지만, 추가적인 학습과 고민을 통해 토큰의 생명주기를 더 쉽게 관리할 수 있게 되었습니다.