우리가 컨퍼런스에 가면 입장하기 전 예매 확인을 하고 들여보냅니다. 하지만 들여보낸 뒤에는 컨퍼런스장 안에 있는 사람들을 대상으로 예매 확인이 제대로 진행됐는지 확인할 수 없습니다. 돈을 지불하지 않고 몰래 숨어서 들어온 사람들이 있을지도 모르는데도 말이에요.
그러면 어떻게 할까요? 컨퍼런스장에서는 참여자가 예매 확인을 했다는 정보를 담은 확인용 이름표를 부여합니다.
제 벨로그 주소입니다. 앞에 http(s)
가 붙어 있죠? 다른 웹 페이지 주소들도 마찬가지입니다. HTTP 프로토콜을 통해 통신한다는 의미입니다. 이 HTTP의 특성 중 하나가 무상태성(Stateless)입니다. 상태가 없기 때문에 클라이언트의 정보를 기억하고 있을 수 없죠. 로그인 정보, 유저 아이디, 유저 등급 등 여러 정보들을 모두 기억할 수 없습니다.
위의 사진처럼 유저 정보를 판별할 수 없기 때문에 서버는 블로그에 글을 올리고 싶은 클라이언트를 돌려보낼 수밖에 없죠.
그러면 어떻게 해야 할까요? 인증은 웹 사이트에서 거의 빠지지 않는 기능입니다. 우리는 해결책을 찾아야 합니다. 이건 어떨까요? 아까 말했던 컨퍼런스처럼 클라이언트의 정보를 확인할 수 있는 확인증을 부여하는 거예요!
위 사진처럼 말이죠.
실제 웹에서는 여러 가지 방법으로 확인증 역할을 수행합니다. 바로 이 글의 주제인 쿠키와 세션이 그중 하나입니다.
쿠키는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각입니다. HTTP 쿠키, 웹 쿠키, 브라우저 쿠키 모두 같은 말입니다. 동작 방식은 아래와 같습니다.
브라우저에서 서버에 HTTP요청을 보내면, 서버는 헤더에 쿠키를 담아 응답합니다. 브라우저는 서버로부터 받은 쿠키를 저장해 두었다가, 이후 HTTP 요청이 발생할 때마다 쿠키를 담아 요청합니다.
쿠키의 특징은 아래와 같습니다.
HTTP 세션은 해당 서버에 접근한 클라이언트를 식별하는 방법입니다. 동작 방식은 아래와 같습니다.
세션은 클라이언트를 식별하기 위해 세션 ID라는 것을 사용합니다. 인증된 클라이언트에게만 발급되는 열쇠죠. 브라우저가 세션 ID를 가지고 있지 않은 상태에서 서버에 HTTP 요청을 보내면, 서버는 세션 ID를 새로 생성하고, 이 세션 ID를 쿠키에 담아 응답합니다. 그 이후는 쿠키 작동 방식을 떠올리시면 됩니다. 브라우저는 쿠키로 전송된 세션 ID를 저장하고, 저장된 세션 ID 쿠키를 담아 HTTP를 요청하기 시작합니다. 세션은 클라이언트의 요청에 담긴 세션 ID를 확인하고 인증된 브라우저일 경우 응답해 줍니다.
세션 ID는 어디에 쓰이냐고요? 모든 정보들을 클라이언트에 저장하는 쿠키와 달리, 세션 방식은 서버에 저장해 둡니다. 대신 서버에 저장되어 있는 정보에 접근할 수 있는지 확인하는 세션 ID를 클라이언트에 발급해 줄 뿐이죠. 클라이언트는 열쇠만 가지고 있다가 정보가 필요할 때 가지고 있던 열쇠를 이용해 서버에 저장된 정보에 접근하는 방식인 것이죠.
세션의 특징은 아래와 같습니다.
여기서 잠깐 짚고 넘어갈 것이 있습니다. 위의 HTTP 세션 설명을 보면 서버가 해당 서버에 접근한 클라이언트를 식별하는 방법이라고 정리되어 있습니다. 세션은 쿠키를 이용한 하나의 '방법'입니다. 분명 쿠키를 사용한 방법과 차이는 있지만, 반대 개념이라고 할 수는 없습니다.
쿠키와 세션을 비교해 보자면 다음과 같습니다.
쿠키는 정보를 클라이언트에 저장하고, 세션은 정보를 서버에 저장합니다. 대신 세션 ID를 클라이언트에게 발급해 줍니다.
쿠키는 정보를 클라이언트에 저장하기 때문에 보안에 취약할 수밖에 없습니다. 세션은 쿠키의 취약점을 보완하기 위해 제시된 방법입니다.
쿠키는 주로 장바구니 같은 보안이 중요하지 않은 정보를 저장합니다. 세션은 아이디, 비밀번호 같은 보안이 중요한 정보를 저장해 둡니다. 뿐만 아니라 요즘 쿠키는 빅데이터에도 사용됩니다. 페이스북이나 구글과 같은 거대한 웹 페이지에서는 광고 서비스를 위해 사용자의 행동을 쿠키를 통해 수집합니다. 그렇게 쌓인 정보를 이용해 사용자에게 맞는 광고를 표시합니다.
와우 적절한 비유에 감탄했습니다! 👏