인프런 커뮤니티 질문&답변

HTTP 세션에 인증 정보를 저장하면 그만큼 오브젝트를 생성해서 유지해야 하므로 메모리 사용하고, 매번 그 정보를 꺼내오는 부하가 더 든다는 건 틀린 말은 아닙니다. 서버가 재시작 되더라도 세션 내용을 유지하기 위해서 그 정보를 영속화하는 기능까지 켜져있다면 그만큼의 부하도 더 들겠죠. 그러면 그게 http 세션을 쓰지 않아야 하는 이유가 되는가하면, 그건 또 따져봐야 합니다.

근본적으로 애플리케이션 서버 단에 session으로 인증을 관리하는 경우 몇 가지 문제가 있습니다.

세션 안에 인증 정보를 담은 오브젝트를 저장해두고 만료시간까지 유지하는 것이 부담이 될 수는 있습니다. 하지만 세션으로 인증 관리하는 것은 그보다는, 서버 크래시 이후 재시작 시에 세션이 날라가는 문제, 그리고 여러 대의 서버로 확장하는 경우 세션 정보가 다른 서버에는 존재하지 않아서 인증을 실패하는 문제, 이걸 해결하기 위해 세션 공유를 하면 각 서버마다 부하가 커지는 문제 등등 애플리케이션 서버에 인증 정보를 세션으로 담아두는 건 사용자가 많아지면 꽤 많은 문제를 발생시킵니다.

그래서 인증 정보를 http 세션 말고 더 뒤에 있는 DB나 캐시 등에 담아두는 방법을 쓰기도 하고, 아예 인증정보를 암호화해서 클라이언가 직접 들고 있는 JWT 같은 걸 쓰는 거죠.

JWT가 꽤 편리한 면이 있긴합니다. 반면 주의해야 할 많은 사항이 있는데 그걸 잘 지키지 못하면 오히려 서버에 부하를 더 주거나, 보안에 심각한 문제를 일으키기도 합니다.

http session과 JWT 외에도 또 다른 선택지들이 있습니다. 여러가지를 비교해보시고, 개발하는 시스템의 조건에 맞는 것을 선택하셔야 합니다.

사내에서 수백명 정도가 간헐적으로 사용하는, 서버를 하나만 사용해도 충분한 시스템이라면 일단 저는 http session을 쓰겠습니다. 하지만 대외적으로 빠르게 성장하고 있고, 접속자가 많으며, 인증정보가 잘 유지되야야 하는데, 보안도 매우 중요하다면? 그러면 또 다른 선택지를 찾겠습니다.

이번 강의에서는 관련된 내용을 전혀 언급하지 않았는데.. 아무튼 질문을 하셔서 답변을 드렸습니다. 앞으로 스프링 부트 웹과 스프링 시큐리티 등을 다루는 강의를 하게 되면 좀 더 자세히 설명드릴 수 있겠네요.