# 토큰 인증 시 Redis 캐싱 전략

### 소개
JWT 토큰 인증 시 매 요청마다 회원 데이터를 DB에서 조회하는 과도한 비용 문제 해결

### 원인
토큰 호출 시마다 loadUserByUsername을 통해 userRepository에서 사용자 정보를 조회하여 성능 저하 발생

### 해결방안
1. Redis를 활용한 사용자 정보 캐싱 구현
2. @Cacheable 어노테이션을 통한 회원 정보 캐싱
3. 캐시 만료 시간을 토큰 유효기간과 동일하게 설정
4. @CacheEvict를 통한 회원 정보 수정/탈퇴 시 캐시 삭제 처리

### 해당 해결방안을 쓴 이유
통신마다 DB 조회 감소로 서비스 응답 시간 개선 및 시스템 부하 감소를 목적으로 함

### 구현 과정 문제점 및 고려사항
1. 캐시 삭제 시점 관리 (로그아웃, 토큰 만료, 정보 수정, 회원 탈퇴)
2. 토큰 만료와 캐시 만료 시간 동기화 문제
3. 직렬화/역직렬화를 위한 Serializable 구현 필요

### 결과
1. 응답 평균 시간: 485ms → 190ms
2. 최대 응답 시간: 2707ms → 1348ms
3. 표준 편차 감소: 517.85 → 284.50
4. 약 2배의 성능 개선 달성

### 키워드
- Redis 캐싱
- JWT 토큰 인증
- 성능 최적화
- @Cacheable
- @CacheEvict
- 캐시 만료 관리

문제?

• 토큰 호출 시마다 데이터를 검증

  • 호출 시마다 DB에 있는 member data를 가지고 옴
  • 통신할 때마다 이를 검증하는 것은 과도한 비용을 발생시킴

• 현재 구현 상황

  • 언제나 loadUserByUsername를 통해 userRepository 안의 user를 가지고 옴
  • 그 이후 UserDetails를 상속받고, user를 멤버 객체로 가지는 SecurityUser를 반환받음

우리 시스템에서는 JWT 토큰 인증 방식을 사용하고 있는데, 매 요청마다 토큰 검증을 위해 데이터베이스에서 회원 정보를 조회하는 과정에서 성능 저하 문제가 발생했다.

구체적으로는 모든 토큰 호출 시마다 loadUserByUsername 메소드를 통해 userRepository에서 사용자 정보를 가져오는 과정이 반복되었다. 이로 인해 통신이 빈번할수록 데이터베이스 부하가 증가하고 응답 시간이 지연되는 현상이 예상되었다.

현재 구현 상태에서는 언제나 loadUserByUsername을 호출하여 userRepository에서 사용자를 조회한 후, UserDetails를 상속받고 사용자 객체를 멤버로 가지는 SecurityUser를 반환하는 방식이었다.