큐 기반 토큰 재발급

큐 기반 토큰 재발급 | hijjoy

🥹 로그인 상태가 풀려 보이는 문제를 마주하다

서비스를 개발하면서 가장 난감했던 순간 중 하나가 바로 로그인이 풀린 것처럼 보이는 현상이었습니다. 원래는 로그인된 유저라면 오른쪽 화면, 비로그인 유저라면 왼쪽 화면이 보여야 합니다.

그런데 access token이 만료된 뒤,

어떤 경우에는 정상적으로 로그인 상태가 유지되었고,

또 어떤 경우에는 “로그인 후 이용해주세요” 화면이 뜨며 로그인이 풀린 것처럼 보였습니다.

항상 발생하는 문제가 아니었기에 원인을 찾는 데 오랜 시간이 걸렸습니다.

기존 로직

axios interceptors를 통해 access token 만료 시 refresh token으로 재발급
실패했던 요청을 새 토큰으로 다시 실행
프로필 요청 성공 시 Context에서 isAuthenticated = true

즉, 토큰 갱신 + 프로필 요청을 기반으로 로그인 상태를 유지하는 구조였습니다.

원인 파악 과정

문제를 해결하기 위해서는 문제에 대한 원인을 알아내야 했고, 2가지 단서로 원인을 찾아내기 시작했습니다.

단서 1. '로그인 후 이용해주세요' 화면을 클릭해 로그인 화면으로 넘어갔다가 다시 뒤로 돌아가면 갑자기 데이터가 다 뜬다.

단서 2. 아래 이미지를 보면 챌린지 리스트 데이터는 뜨지 않아 _'로그인 후 이용해주세요'_가 보이지만, 날짜 위에 색이 있는 부분과 상태바를 보면 색상이 들어가 있는 것을 보아 그 두 가지 요청은 제대로 가고 있다.

이 두 가지 단서를 가지고 원인을 생각해보았고,

단서 1에 따르면 실제로 로그인은 풀려있지만 로그인 후 이용해주세요가 뜨는 것이므로 refresh token을 발급받는 로직에 오류가 있을 수 있다고 판단하였습니다.

확인해보니 생긴 문제

일단 토큰을 임의로 유효하지 않은 토큰으로 바꿔치기 하는 버튼 하나를 만들어서

refresh token을 사용하여 새로운 access token을 발급받을 수 있도록 확인해보았습니다.

이렇게 두 번 말고도 여러 번 버튼을 눌러 확인을 해본 결과 문제를 2가지 발견하게 되었습니다.

리프레시 요청이 한 번이 아니라 여러 번 전송된다.
401 → 리이슈 요청 → 다시 401이 뜬 요청을 보냄 이 과정을 해야 하는데, 실패한 요청들이 재시도되는 방식이 매번 달라진다.

여기서 로그인이 풀려보이는 정확한 원인을 파악할 수 있었습니다.

2번에 쓴 것처럼 리이슈 이후 다시 요청을 보내야 하는데 만약 프로필을 가져오는 요청을 다시 하지 않았다면,

auth context에서 인증 상태를 프로필을 가져와야 true로 설정하였기 때문에,

토큰은 있음에도 불구하고 isAuthenticated가 false가 되어 _'로그인 후 이용해주세요'_가 보이게 된 것 입니다.

첫 화면에서 나의 경우 5개 정도의 요청을 보내는데 여러 요청을 동시에 보내는 상황에서 access token이 만료된 경우 interceptors가 실행됩니다.

이때, 5개의 요청에서 모두 저 과정이 발생하면서 5번 리이슈 요청을 보내고 실패한 요청을 다시 전송하는 과정에서 꼬이게됩니다.

예를 들면

동시에 만료된 토큰으로 요청 A와 B를 보냄

A 요청이 먼저 인터셉터에 잡혀서 리프레시를 시도

거의 동시에 B 요청도 리프레시를 시도

서버는 또다시 유효한 리프레시 토큰을 확인해 새로운 B 요청에 대한 토큰을 발급하고, A의 요청으로인해 방금 만든 토큰을 무효화합니다.

A 요청이 재시도를 하려 하지만 이미 만료된 토큰을 쓰게 됨

이런식으로 반복되면 무한 루프를 돌 수 있으며, 5개의 요청을 보냈다고 해서 실패했던 5개의 요청이 다시 200으로 성공할 것이라는 보장이 사라집니다.

해결방법

참고 블로그 이 블로그에서 해결 방법을 찾을 수 있었습니다.

리이슈 요청이 여러번 가는 것을 방지하기 위해 isRefreshing 플래그를 두어 이미 interceptors로 인한 리이슈 요청을 하고있을 경우 요청이 가지 않도록 막고, 모든 실패 요청을 큐에 저장해놓고 토큰이 재발급 된 이후 그 큐에 담긴 요청들을 모두 다시 요청을 보낸다.

이 구조를 적용하면서,

리프레시 요청은 항상 1회만 발생
실패했던 요청들이 모두 재시도

되는 안정적인 패턴을 만들 수 있었습니다.

마치며

큐 기반 재발급–재시도 로직을 적용하게되면서 리프레시 요청 1회 → 큐에 쌓인 모든 요청 일괄 재시도라는 명확한 흐름으로 로그인이 풀려보이는 이슈를 해결 할 수 있었습니다.

원인을 찾는 것이 조금 힘들었지만, 큐 기반 재발급–재시도 로직이라는 새로운 방법을 알 수 있어서 좋은 경험이 된 것 같고,

큐 기반 재시도 패턴은 이번 사례뿐 아니라, 앞으로도 여러 API 통신 안정성 문제에 활용할 수 있을 것이라 생각합니다.