지난 [공부정리] Refresh Token Rotation 도입 및 Token 관리 전략 소개에서 알 수 있듯이, 프로젝트에 redis를 이용하여 Refresh Token을 저장하였다. [생각정리] JWT의 Stateless 고찰에서 JWT에 대한 생각정리를 끝내고, 너무 당연하게 진행한 작업이다. 하지만 redis의 사용도 비용이라는 생각이 들었고, 이번 게시글에서 생각을 정리하고자 한다.

1. Redis의 장점

Redis를 사용하는 주요 장점으로는 다음과 같은 점들이 있다.

• 데이터 만료 설정 가능: Redis에서는 TTL(Time-To-Live) 기능을 사용하여 데이터의 만료일을 설정할 수 있다. 이를 통해, 토큰이 만료될 때 자동으로 데이터를 삭제하게 함으로써, 데이터 관리를 더욱 효율적으로 할 수 있다.

• 빠른 접근 속도: JWT Access Token을 갱신하기 위해서는 Refresh Token이 필요하다. Refresh Token 같은 자주 호출되는 데이터는 In-Memory DB인 Redis에 저장함으로써 빠른 접근 속도를 얻고, 토큰 재발급 로직의 병목 현상을 방지할 수 있다.

• 속도와 안정성의 트레이드 오프: RDB와 비교했을 때, In-Memory DB는 빠른 조회 속도의 이점있다. 하지만 휘발성 메모리를 사용하기 때문에 전원이 꺼지면 데이터가 손실될 위험이 있다.

2. 생각 정리

Redis의 장점을 고려했을 때, 몇 가지 고려해야 할 점들이 있다.

• 트랜잭션 관리의 복잡성: Redis와 RDB를 함께 사용할 경우, 트랜잭션 관리가 복잡해질 수 있다.
• 비용과 속도의 최적화: WAS와 같은 위치에 Redis를 배치하여 속도의 이점을 극대화하려 하지만, 이는 WAS를 스케일 아웃할 때 Redis 데이터의 동기화 문제를 낳는다.

이러한 측면에서 보았을 때 Refresh Token 저장에 Redis를 사용하는 것은 고려야할 점이 많다고 생각한다. 그래서 오직 Access Token 갱신을 위해 Redis의 사용에서 발생하는 오버헤드가 크다는 결론에 도달했다.
이에 따라, O2O-Automatic-Store_Object-Detection_Demo 프로젝트에서 사용된 Redis 기반의 Access Token 재발급 로직을 수정할 계획이다. 또한 숙련도가 낮은 Redis를 적용하면서 코드의 응집도가 나빠졌다. 다음 글에서는 이러한 수정 사항에 대해 자세히 다룰 예정이다.

기술을 선택할 때 그 이유를 항상 고민하고, 그 선택이 정말 필요한지를 평가하는 것은 매우 중요하다.