간단한 소셜 로그인 방법 설명!

• 사용자 인증 후 발급하는 Access Token은 일반적으로 n분~n시간의 짧은 수명을 가짐
• Refresh Token을 사용하여 새로운 Access Token을 재발급받음(Refresh Token은 nn일~1달 정도) → 이때 Refresh Token을 관리할 안전하고 빠른 저장소가 필요함
  

---

Refresh Token을 테이블에 저장하면 안될까?

물론 가능하지만 토큰 관리 관점에서 Redis를 사용했을 때의 이점이 많다.

✅ RDB vs Redis

Redis는 인메모리 기법을 사용한다.

• 모든 데이터를 시스템의 메인 메모리에 보관 → 데이터 액세스 및 처리 시간이 대폭 단축되어 응답 지연 시간이 매우 짧음
• 높은 처리량 : 특정 기간 동안의 읽기(읽기 처리량) 또는 쓰기(쓰기 처리량) 작업 수가 높음
• 높은 확장성 : 인 메모리 데이터베이스를 가변적으로 관리할 수 있음. 성능에 악영향을 미치지 않으면서 쓰기 크기와 읽기 크기를 모두 조정할 수 있으며 데이터베이스는 크기 조정 중에도 온라인 상태를 유지하며 읽기 및 쓰기 작업을 지원

항목	RDB	Redis
속도	디스크 기반. 토큰 확인/삭제 쿼리 실행 시간 있음	인메모리. O(1) 수준의 빠른 읽기/쓰기
TTL 지원	별도 배치 작업이나 수동 컬럼 검사 필요	기본 기능으로 TTL 자동 만료 처리 가능
스케일링	부하 증가 시 성능 저하	고속 캐시 시스템. 수평 확장(Redis 클러스터와 같은 서버를 추가, key 기반 분산 처리가 잘 되어 있음)
복잡성	SQL JOIN, 인덱스 설계 등 구조 복잡도 ↑	단순한 key-value 구조, 관리 쉬움
자원 효율성	불필요한 만료 토큰도 계속 저장됨	TTL 지나면 자동 삭제, 공간 효율 ↑

✅ 이렇게 사용할 수 있다!

1. 로그인/인증 요청이 많은 서비스

• Access/Refresh Token 검증이 매우 빈번 → DB 부하를 줄이고 빠르게 응답하기 위해 Redis 사용
  

2. 토큰 만료가 자동으로 필요한 서비스

• Redis는 EXPIRE 명령으로 TTL 자동 만료 → RDB에선 정기적으로 만료 토큰 삭제하는 작업을 직접 구현해야 함
  

3. 보안 정책에 따라 빠르게 Token 무효화가 필요한 경우

• Redis에서 key만 지우면 즉시 무효화됨 → RDB에서는 UPDATE 쿼리나 조건 검증이 추가적으로 필요
  

4. 수많은 사용자 / 다중 디바이스 로그인 환경

• 사용자 1명당 여러 디바이스에 토큰 저장 필요 → Redis는 key 구조가 유연해서 refresh:userId:deviceId처럼 구성이 가능함! → 조회, 삭제, 갱신이 빠르고 편리
  

---

결론

Redis를 써야만 구현 가능한 것은 아니지만, 사용 시 훨씬 효율적이다.

Redis를 캐시가 아닌 상태 저장소 측면으로 활용하는 것인데, 이를 통해

> 고속 응답 + 자동 만료 + 부하의 분산 + 유연한 구조 < 를 갖춘 토큰 시스템 구현이 가능하다.