Redis를 사용한다면 Session 대신 JWT를 사용할 필요가 있을까?

배경

나는 사용자 인증 관리를 JWT로 구성했었다. 그 배경에는 세션이 멀티 서버 환경에서는 중간 미들웨어가 있어야 한다는 단점이 있었기 때문이다. (물론 Sticky Session을 활용한다면 미들웨어를 사용하지 않아도 되지만 멀티 서버의 장점을 발휘하지 못하기 때문에 고려하지 않았다.)

하지만 팀원이 캐싱 관리를 위해 Redis를 도입하게 되면서 Redis 활용이 가능해졌고 이러면 사용자 인증 관리를 Redis + 세션을 활용한 방식으로도 구성이 가능해졌다.

그래서 기존의 JWT 방식을 유지할지, 하니면 JWT를 제거하고 세션을 활용하는 방식으로 사용자 인증을 관리할지 다시 고민하게 되었다.

 

 

---

 

고민

확장성

JWT는 사용자 식별 정보를 토큰에 담아서 헤더에 넣어주기 때문에 Stateless 구성이 가능하다. 따라서 확장성에 매우 좋다고 볼 수 있다. 각각의 서버에서 토큰의 유효성만 검증하면 된다.

Session 방식은 어떨까?? JWT가 등장하게 된 배경을 살펴보면 이전에 Session 방식은 서버 확장성이 떨어질 것 같다. 하지만 Redis의 등장으로 이러한 단점이 많이 보완되었다고 생각한다. 세션 관리를 각각의 서버에서 하는 것이 아닌, Redis를 통해 하게 되었다. 따라서 서버를 증설한다고 Redis 서버를 통해 인증을 관리하기에 서버 확장에 큰 문제가 되지 않는다.

따라서 결론적으로 JWT와 Session 방식 모두 확장성 있게 구성할 수 있다. 하지만 Session 방식의 경우 Redis를 통해 유저 식별 정보를 조회하는 작업이 추가로 있다는 리소스가 있다.

 

 

❓ Stateless한게 왜 확장성에 도움이 될까?

Stateless 하다는 말은 서버에서 이전 요청에 대한 정보를 유지하지 않아도 된다는 말이다. 서버에서는 이전 요청에 대한 정보를 유지할 필요가 없게 되고 멀티 서버인 경우 이전에 A서버에 요청을 보냈어도 다음 요청에는 B서버에 요청을 보내도 된다는 것이다(왜냐하면 어차피 이전 정보를 모르기 때문). 따라서 필요에 따라 서버의 대수가 변해도 상관이 없고 이는 서버 확장성에 큰 도움이 된다고 말할 수 있다

 

 

유지보수

JWT는 발급하는 순간 세션 만료 등의 관리는 더 이상 서버의 주관이 아니다. 서버 입장에서는 단순히 토큰이 만료되었는지, 위변조가 없는지 등에 대해서만 확인하면 된다. 즉, 구현과 유지보수가 단순해진다.

반면 Session의 경우 Redis로 구성하게 된다면 Redis 서버에서 관리해야 한다. 각각 서버에서 토큰 유효성을 확인하는 JWT와는 다르게 Redis 서버에서 모든 세션을 관리하기에 Redis 서버의 부담이 커질 수 있다. 따라서 고가용성을 위해 Redis를 클러스터링으로 구성해야 할 가능성이 높다.

결론적으로 JWT를 활용하는 것이 유지보수 측면에서 더 리소스 적은 방식이라고 생각이 든다.

 

보안성

JWT는 Payload를 누구나 확인할 수 있다. 유저의 중요한 정보는 암호화해서 넣어두거나 가능한 넣어두지 않도록 구성해야한다. JWT는 서명을 통해 데이터 위변조를 확인할 수 있어 악의적으로 누군가 유저 정보를 변경해서 요청을 보내도 쉽게 변조 여부를 확인할 수 있다.

Session의 경우 서버에서 발급한 고유의 세션 키를 유저와 주고 받고 서버에서는 유저한테 받은 키를 통해 유저의 식별 정보 한다. 따라서 유저 식별 정보를 주고받지 않기 때문에 중간에 탈취당해도 유저 정보를 유출하는 위험은 발생하지 않는다.

결론적으로 보안성은 두 방식 모두 높게 유지할 수 있다. JWT는 유저 식별 정보를 암호화 작업을 해줘야 한다는 부분에서 리소스가 조금 들어간다는 측면에서 Session 방식이 조금은 유리한 선택이 될 수 있다.

 

---

정리

항목	JWT	Session (Redis)
확장성	사용자 식별 정보를 토큰에 담아 헤더에 포함시킴으로써 Stateless한 구성이 가능해, 각 서버가 토큰 유효성만 검증하면 됨.	Redis를 통해 중앙에서 세션을 관리하므로 서버 증설 시 문제가 없지만, Redis 조회 작업이라는 추가 리소스가 필요함.
유지보수	토큰 발급 후 만료 및 위변조 여부만 확인하면 되어 구현 및 관리가 단순하고 리소스 부담이 적음.	모든 세션을 Redis에서 관리해야 하므로 Redis 서버 부하가 증가할 수 있어, 고가용성을 위해 클러스터링 고려 필요.
보안성	Payload가 누구나 확인할 수 있어 중요한 정보는 암호화해야 함. 다만, 서명을 통해 위변조 여부는 확인 가능함.	서버에서 발급한 고유 세션 키를 사용해 사용자 정보를 관리하므로, 민감 정보 노출 위험이 상대적으로 낮음.

표로 정리하면 위와 같다.

 

내 결론은?

우선은 JWT 방식을 유지하기로 결정했다. JWT와 Session을 활용한 방식은 각각의 장단점이 있고 어느 한 방식을 활용할 만큼의 필요성이 느껴지지 않았다. 어떠한 방식을 활용하든 트레이트 오프 포인트가 있는 것 같다.

따라서 두 방식 간에 큰 차이점이 없다면, 굳이 JWT에서 Session 방식으로 코드를 변경할 필요성을 느끼지 못하겠다. 현재는 기존의 JWT 방식을 유지하고, 이후에 Session 방식으로 변경할 필요성이 제기된다면 그때 변경하는 것이 좋을 것 같다.