네x버 웹툰 "쿠키" 아님,
울랄라 "세션" 아님.

👋 머릿말

개발 공부를 하면서 어렵다고 느꼈던 것 중 하나가 로그인 페이지 구현 입니다.
회원가입, 로그인 인증, 비밀번호 찾기, 회원 정보 변경, 할 수 있다면 메일 시스템 구축까지 만들어야 하죠. 쇼핑몰이라면 장바구니에, 결제 화면이나 배송 정보도 구현 해야 하니 개발 코린이로서는 앞이 캄캄할 따름이죠.

저는 토큰 방식을 선호하는데요. JWT 를 자주 이용하고 있습니다. 관련 이슈나 사례도 찾기 편하고, 무엇보다 이거 외엔 할 줄 아는 게 없어서 그렇죠. 언젠가는 세션도 공부해야지, 공부해야지 하면서 1년을 미루고 있었네요. 많이 늦었지만 이젠 공부해야겠죠?

🍪 쿠키

쿠키는 웹 사이트 서버에서 유저의 컴퓨터로 보내는 작은 임시 파일입니다. 해당 웹에 필요한 정보들을 가지고 있다가 필요한 이벤트에 데이터를 반환합니다.

처음 쿠키가 만들어진 건, 정확한 통계 값을 구하기 위해서 였다고 합니다. 방문자가 이전에도 왔던 방문자인지, 처음 온 방문자인지를 확인하기 위함이었다고 해요. 쿠키가 없던 이전에는 한 명의 유저가 index 페이지를 100번 reload 하면 100명이 방문했던 것으로 표현되었다고 해요. 방문자를 확인하는 데이터를 통해 우리는 이를 구분할 수 있게 된 거죠. 먹고 남은 쿠키 부스러기 마냥 작은 파일들이라 하여 cookie라는 이름이 붙었다고 합니다.

이렇게 만들어진 cookie는 단순히 통곗값만 내는 것으로 끝나지 않았습니다. 웹사이트에서 로그인이 지속 되는 것도, 하루 동안 광고 글을 숨기는 것도, 장바구니의 상품들이 계속 저장되어 있는 것도 모두 cookie 를 통해 이루어지는 것이죠. 유저가 사용한 검색정보나 구매 아이템을 저장해둔다면 유저가 어떤 것을 많이 찾고 있는지, 무엇을 좋아하는 지 등을 알 수 있겠죠? 그만큼 웹 페이지에서 cookie 는 매우 중요하고 유용한 것입니다.

하지만 cookie 에도 단점은 존재했습니다. cookie 의 파일들은 모두 유저의 웹 브라우저에 저장이 됩니다. 즉 유저가 원한다면 삭제도 하고, 변경하는 것도 가능하게 되는 거죠. 단순 데이터야 그렇다 치더라도 개인정보 등의 민감한 데이터를 cookie 에 둘 수 없게 된 거죠. 그렇게 session 과 cookie 를 함께 병용하여 쓰는 세션 쿠키 방식이 구현되었습니다.

䷍ 세션

session 역시 필요한 데이터를 저장해둔다는 점에서는 cookie 와 같습니다.
cookie 가 client-side 의 데이터 저장소라면, session 은 server-side 의 데이터 저장소이죠.

개인정보와 같은 민감한 데이터는 session 에 모아두고 인증 절차가 완료되면 서버와 클라이언트에 절차가 완료되었다는 확인 데이터를 남기는 것이죠. 물론 cookie 에는 누구도 알아보지 못하도록 해시화 된 값으로요. 이를 통해 cookie 의 장점은 계속 이어가면서, 단점을 보완할 수 있게 되었습니다.

	쿠키	세션
저장위치	클라이언트	서버
저장형식	text	object
리소스	클라이언트의 메모리	서버
보안	취약	비교적 안전
속도	빠름	비교적 느림

session 은 메모리나 하드디스크 혹은 데이터베이스 등 다양하게 저장하는 것이 가능하지만 모두 장단점이 존재했어요. 데이터베이스로 갈수록 용량 문제는 해결되지만 요청-응답에 걸리는 시간이 늘어납니다. 메모리는 반대로 요청-응답은 빠르지만 많은 요청은 처리할 수가 없죠.

이러한 문제를 개선하기 위해 나타난 것이 JWT 와 같은 token 방식입니다. token 은 인증 과정은 세션 쿠키와 비슷하지만, 서버에 확인 데이터를 남기지 않습니다. 로그인이 완료되면 이후 인증 과정은 cookie 에 남겨진 해시 토큰만으로도 확인이 가능하므로 요청-응답 속도가 훨씬 빨라집니다.

🤔 그럼 이제 JWT만 쓰면 되는가.

아니요. 일단 JWT 를 통해 cookie 만으로 장기적인 로그인 유지가 가능하지만, 이것도 완벽하다고 볼 수는 없습니다.

넷플릭스를 생각해볼까요? 스마트폰으로 보던 것을 좀 더 큰 화면에서 보기 위해 태블릿으로 프로필 접속을 했다고 합시다. 넷플릭스는 유저의 환경에 변화가 있음을 캐치하고 태블릿의 접속이 완료됨과 동시에 모바일은 로그아웃 화면으로 변하게 되죠. 이러한 앱에서는 server 에 환경이 변화되었다는 데이터를 남겨야 하기 때문에 JWT 보다는 세션-쿠키 방식이 훨씬 적합합니다. 어떻게 해서 token 데이터가 탈취된다면 server 에서 컨트롤 할 수 있는 부분이 없기 때문에 데이터의 만료날짜가 마냥 기다릴 수 밖에 없는 것도 단점입니다. 이러한 경우는 세션-쿠키server 에서 제어가 가능합니다.

	세션-쿠키	토큰
요청-응답	느림	빠름
서버영역	제어	제어 불가능
확장	가능. 단, 비용이 큼	가능 (매우 우수)
보안	쿠키 단독에 비해 우수	비교적 높음. 단, 정보 탈취시 취약
서버부하	세션 저장소 사용으로 부하 있음	적음
네트워크부하	낮음	토큰이 길수록 세션-쿠키에 비해 부하 큼

최근에는 메모리형 데이터베이스나 access, refresh 토큰 등을 통해 해당 인증과정의 부족한 부분들을 차츰 개선하고 있는 상황입니다. 물론 명확한 단점 문제가 해결된 것은 아니기에 각 인증 방식을 이론적으로 공부하고 구현하는 앱에 맞는 방식을 채택하여 사용하는 것이 가장 중요하다고 생각되네요.

역시 쉬운 건 없는 건 하나도 없는 거 같습니다. 이것저것 쓰다 보니 긴 글이 되어버렸네요. 누군가에게 참고가 되는 글이였음 좋겠는데 말이죠. 잘못된 부분이 있다면 댓글로 지적해주시고요.

그럼 이만 👋.

REFERENCE
쿠키
https://terms.naver.com/entry.naver?docId=3577813&cid=59088&categoryId=59096
쿠키 세션 차이점
http://blog.kurien.co.kr/544
얄박한코딩사전 - 세션,쿠키, JWT
https://www.youtube.com/watch?v=1QiOXWEbqYQ&t=741s
인증 방식 - Cookie & Session vs JWT
https://tecoble.techcourse.co.kr/post/2021-05-22-cookie-session-jwt/