[Spring] Access Token vs Refresh Token 완벽 정리 + Redis 저장 이유까지

프로젝트를 진행하면서 JWT 인증 시스템을 직접 구현하는 과정에서 필요성을 느끼고 공부하고 정리한 내용을 담았다.
개발을 하다 보면 이런 질문이 자연스럽게 생긴다.

"Access Token이랑 Refresh Token, 이 둘은 도대체 뭐가 다르고, 어떻게 관리해야 할까?"

특히 Refresh Token을 어디에 저장해야 할지, Redis를 사용하는 이유는 뭔지 궁금증이 많았다.
그래서 Access Token과 Refresh Token 개념부터 Refresh Token을 서버, 특히 Redis에 저장해야 하는 이유까지 한 번에 깔끔하게 정리해보려고 한다.

 

🔑 Access Token이란?!

로그인하면 발급받는 짧은 수명의 토큰이다. (ex. 30분)
사용자는 매 요청마다 Access Token을 HTTP 헤더에 담아 보내고, 서버는 이 토큰을 검사해서
"이 사용자가 인증된 사용자인지" 확인한다.
Access Token은 수명이 짧기 때문에, 만료되면 다시 로그인해야 한다.

🎯 목적
"이 사용자가 인증된 사용자인지 판단하기 위해 사용한다."

 

🔑 Refresh Token이란?!

Access Token이 만료될 때마다 로그인하면 사용자 경험(UX)이 너무 나빠진다.
Refresh Token은 이런 불편을 해결하기 위해 등장했다.
👉  Access Token이 만료됐을 때, 새로운 Access Token을 발급받기 위한 토큰
👉  사용자에게 노출되지만, 서버에도 저장된다.
👉  수명이 길다. (7일 ~ 30일 이상)

🎯 목적
"Access Token이 만료됐지만, 사용자가 로그인 상태를 유지할 수 있게 한다."

 

Access Token vs Refresh Token

항목	Access Token	Refresh Token
용도	인증(Authentication)	Access Token 재발급
수명	짧음 (15~30분)	김 (7~30일)
저장 위치	브라우저 (메모리/쿠키)	브라우저 + 서버 (Redis 등)
노출 가능성	상대적으로 안전	탈취 시 위험 높음
보안 관리 방식	짧은 만료 시간으로 해결	서버 저장소를 통한 별도 관리 필수

 

그렇다면.. Refresh Token은 왜 필요한가?

간단하게 인증 흐름을 상상해 보자.
1. 사용자가 로그인 → Access Token 발급
2. 30분 뒤 Access Token 만료
3. 다시 로그인하려고 하면..? 너무 귀찮다.

그래서 Access Token이 만료되더라도, Refresh Token을 사용해서 자동으로 재발급하는 구조를 만든다.
그 덕분에 사용자는 로그인 상태를 유지할 수 있다!

 

Refresh Token 동작 흐름

[로그인 시]
  ⬇️
Access Token + Refresh Token 발급
  ⬇️
Access Token은 클라이언트에 저장
Refresh Token은 서버(예: Redis)에 저장
  ⬇️
[Access Token 만료 시]
  ⬇️
Refresh Token으로 Access Token 재발급 요청
  ⬇️
서버가 Redis에서 Refresh Token 검증 → 새 Access Token 발급

 

Refresh Token 도입 시 주의사항

👉  Redis 같은 저장소를 사용해서 서버에 Refresh Token을 저장해야 한다.
👉  Refresh Token 유효성 검사를 꼭 구현해야 한다.
👉  로그아웃 시 Refresh Token 삭제 처리도 필수다! (보안 문제 대비)

 

💻 코드 예시

JwtUtil : Refresh Token 생성

// Refresh Token 생성
public String createRefreshToken(Long memberId) {
    Date now = new Date();

    return BEARER_PREFIX + Jwts.builder()
        .setSubject(String.valueOf(memberId))
        .setIssuedAt(now)
        .setExpiration(new Date(now.getTime() + REFRESH_TOKEN_EXPIRATION))
        .signWith(key, signatureAlgorithm)
        .compact();
}

AuthService : 로그인 시 Access + Refresh 발급

public LoginResponse login(LoginRequest request) {
    Member member = memberRepository.findByEmail(request.email())
        .orElseThrow(() -> new NotFoundException(ErrorCode.MEMBER_NOT_FOUND));

    if (!passwordEncoder.matches(request.password(), member.getPassword())) {
        throw new UnauthorizedException(ErrorCode.INVALID_PASSWORD);
    }

    String accessToken = jwtUtil.createToken(
        member.getId(),
        member.getEmail(),
        member.getNickname(),
        member.getAuthority());

    String refreshToken = jwtUtil.createRefreshToken(member.getId());

    return LoginResponse.from(accessToken, refreshToken);
}

 

그럼.. Refresh Token은 어디다 저장해야 할까?

Access Token과 Refresh Token 개념을 이해했다면, 이제 이런 고민이 발생한다.

"Refresh Token은 클라이언트에만 저장해도 괜찮을까..?"

하지만 Refresh Token은 수명이 길고, 탈취될 경우 보안상 큰 문제가 될 수 있다.
그래서 많은 시스템에서는 Refresh Token을 Redis 같은 빠른 저장소에 안전하게 보관하는 방식을 택한다.

Refresh Token을 Redis에 저장해야 하는 이유

서버가 Refresh Token을 관리해야 한다.

Access Token은 클라이언트만으로 충분하지만, Refresh Token은 서버 저장이 필수이다.
서버에 저장하지 않으면 탈퇴한 사용자, 로그아웃한 사용자의 Refresh Token이 살아있을 수 있다. (보안 위험)

Redis가 적합한 이유

특징	설명
TTL 설정 가능	토큰 만료 시점에 맞춰 자동 삭제
Key-Value 구조	memberId → refreshToken 매핑이 간단
빠른 속도	in-memory 기반 조회/삭제
세션리스 서버 호환	JWT + Redis = 세션리스 구조 가능
복수 기기 지원	기기별 Refresh Token 관리 가능

DB에 저장하지 않는 이유

이유	설명
디스크 IO 부담	생성/삭제 잦아서 부하 큼
영속성 불필요	토큰은 임시 데이터
TTL 관리 복잡	DB는 자동 만료 관리가 어려움

 

프로젝트에 적용해 보면서 느낀 점

이번 프로젝트에서는 단순히 Access Token과 Refresh Token 개념만 공부한 게 아니라, 직접 JWT 인증 시스템을 설계하고 적용해 보는 경험을 할 수 있었다.
👉  Refresh Token을 단순 저장이 아니라 서버에서 별도로 관리해야 한다는 것
👉  DB 대신 Redis를 써야 하는 이유를 직접 체감

단순히 기능만 구현하는 개발자가 아니라, 보안과 운영까지 고민하는 개발자가 되어야겠다는 다짐을 하게 되었다!