JWT와 Session의 차이 / 그리고 지금은 뭘 쓰는지

인터넷에 이 둘의 장단점에 대한 많은 글이 있지만, 그래서 뭘 써야 하는지 결론은 없어서, 뇌피셜을 적는다.

토큰과 세션의 차이

예전에는 서버가 모든 걸 해주었다. 결혼식 방명록을 session이라고 해보자. session은 방명록처럼, "유저 1이 왔다 갔습니다." 라고 적는 방식이다. 이 때, 서버의 유저 수가 몇 천, 몇 만을 넘으면 어떻게 될까?

 

모든 걸 기록 하는 방식인 세션에서는 "야, 저번에 축의금 낸 사람 누구지?" 라는 질문에 답하기 위해서, 로그를 뒤져봐야 하는 수고를 해야 한다. 세션은 유저의 인증을 위함인데, 이 인증 자체가 서버에 큰 부하를 주게 된다. 물론, 이 경우 서버의 수를 늘리면 해결할 수 있다. 하지만 여러 명이 방명록을 나눠 적는 셈이니, 서로의 기록이 달라지게 된다. 즉, "A가 축의금 냈어?" 라는 질문에, 사촌 동생 하나가 "아니요." 라고 말할 수 있지만, 다른 사촌 동생은 냈다고 말할 수도 있는 것이다. 따라서 하나에게만 질문해선 안 되고, 방명록을 적는 사람 ( 여기서는 서버 ) 에게 모두 질문을 던져, 서로 자신의 기록물을 대조해보게 만들어야 한다.

 

이런 복잡한 문제를 없애기 위해, 요즘에는 더욱 간단한 방법을 사용한다. "야, 방명록 적은 사람은 그냥 식권 주고, 식권 있으면 우리 하객이라고 생각하자.", 여기서의 식권이 바로 우리가 흔히 쓰는 토큰이 된다. 서버의 부하나 복잡성을 줄이기 위해, 인증의 결과물을 유저들에게 맡긴 셈이다. 대신에 누군가 이 식권, 토큰을 잃어버리거나 뺏길 경우, 진짜 유저와 악성 유저를 구분할 수 없는 문제가 생긴다. 최소한의 방책으로, 이 토큰에는 뺏겨도 괜찮을 정도의 정보만을 담는다.

 

예전이라면, 둘 모두 좋은 방법이라고 했겠지만, 요즘은 작은 서비스에도 유저의 수가 많아지고, 서비스의 흥행에 따라 로드 밸런싱을 도입해야 할 때가 당겨질 수도 있다. 로드 밸런싱이란, 유저 수를 감당하기 위해 여러 개의 서버를 띄우고, 유저를 서버가 적절히 분배해서 대응하도록 하는 것인데, 이 시기가 당겨진다는 것은 세션으로는 다루기 힘든 복잡한 상황이, 금새 찾아올 수 있다는 뜻이 된다. 어차피 세션과 토큰 방식은 구현 난이도에 있어 큰 차이가 없기 때문에, 굳이 세션을 사용하기 보다 토큰을 사용하는 쪽이 훨씬 서버 개발에 용이한 것 같다.