목차
웹에서는 다양한 방식을 통해 반복해서 사용되는 데이터와 정보를 저장하고 재활용합니다. 웹 자동화를 위해서는 이와 관련된 개념들을 이해하고 사용하는 것이 중요합니다. 이 포스트를 통해 필요한 정보를 활용해보세요. 😀
쿠키(Cookie, HTTP Cookie, Web Cookie)
인터넷을 하다보면 쿠키 설정에 대해 동의를 구하는 문구를 흔하게 접하게 됩니다. 이러한 쿠키는 웹을 사용할 때 사용자의 상태를 저장해서(ex. 쇼핑몰 쇼핑 카트에 저장된 품목) 사이트의 사용성을 높이기 위해 활용되기도 하지만, 디지털 광고를 통해 활용되기도 하죠. 이러한 쿠키는 무엇일까요?
쿠키는 사용자가 웹에서 검색을 하거나 사용하는 동안 웹 서버에서 생성한 텍스트 조각입니다. 이러한 데이터 블록은 크롬이나 사파리와 같은 웹 브라우저에 저장됩니다. 이러한 브라우저는 사용자의 컴퓨터에 설치된 프로그램이기 때문에 쿠키는 사용자가 가지고 있는 정보입니다.
쿠키가 중요한 이유는 사용자 인증을 위한 쿠키(Authentication Cookie)로 활용되기도 하기 때문인데요. 인증 쿠키는 일반적으로 사용자가 로그인을 했는지 확인하거나, 로그인한 계정을 인증하는데 사용됩니다. 만약 브라우저에 이러한 인증 쿠키를 저장해놓지 않는다면 사용자는 사이트에서 인증이 필요한 활동을 할 때마다 매번 로그인을 해줘야할 것 입니다. 브라우저에 저장된 모든 쿠키를 삭제할 경우 잘 사용하던 사이트에 다시 로그인을 해줘야하는 하는 이유도 이 때문입니다.
그리고 트래킹 쿠키(Tracking Cookie)의 경우 개인의 웹 검색 기록을 추적하기 위해 사용됩니다. 검색 기록을 리타게팅이나 맞춤 타케팅 같은 광고에 사용되기도 하죠. 유럽과 같은 외국의 사이트에서는 개인정보 보호 문제로 필수 쿠키 이외의 쿠키를 수집해 사용할 경우 사용자의 동의를 얻어야 합니다.
웹 스토리지(Web Storage)
웹 스토리지는 HTML5부터 나온 새로운 방식의 데이터 저장소로 로컬 스토리지(Local Storage)와 세션 스토리지(Session Storage)가 존재합니다. key-value 형태로 데이터가 저장되며, 로컬 스토리지는 데이터 영구 저장이 가능, 세션 스토리지는 브라우저 탭이 닫히면 스토리지가 초기화 되는 특성이 있습니다. 일반적으로 쿠키는 상대적으로 가벼운 용도의 데이터(오늘 다시 보지 않음 창) 저장이 필요할 때, 스토리지의 경우 지속적인 데이터(자동 로그인) 저장이 필요할 때 많이 사용됩니다.
세션(Session, HTTP Session)
HTTP는 상태를 저장하지 않는 ‘Stateless’한 프로토콜 입니다. 사용자가 네이버에 로그인을 하고 메일을 보낸 뒤 블로그에 포스팅을 한다고 예시를 들어봅시다. 똑같은 사용자가 네이버 서버에 메일을 보내는 행동을 하고, 포스팅을 올리는 요청을 하는 것이지만 네이버 서버에서는 이 두 개의 요청이 동일한 사람이 한 요청인지를 인식하지 못하는 것입니다. 따라서 HTTP 프로토콜에서는 사용자가 로그인한 ‘상태’라는 것을 서버에 알려주지 못하면 매 요청마다 로그인을 해줘야합니다.
이러한 번거로움을 해결하기 위한 것이 ‘세션’입니다. 세션은 로그인한 동일한 사용자라는 것을 알려주기 위한 ‘인증서’ 역할을 합니다. 사용자가 로그인한 순간 서버에서는 세션 아이디를 만들고, 서버의 메모리에 이 아이디가 해당 사용자의 것임을 저장합니다. 브라우저는 서버에서 응답으로 제공받은 세션 아이디를 위에서 설명한 쿠키나 로컬 스토리지에 저장하고, 다음에 필요한 요청을 할 때 같이 전달합니다. 그리고 서버는 이러한 세션 아이디가 해당 사용자의 것이 맞는지 확인합니다. 그리고 요청에 따라 필요한 작업을 진행하게 됩니다.
세션의 경우 서버에 저장되기 때문에 강제로 로그아웃이 필요하다면 서버측에서 직접 세션 정보를 지워 처리할 수 있는 장점이 있기도 합니다.
토큰(Token)
토큰은 이러한 세션처럼 ‘인증’ 역할을 하지만, 세션 정보가 서버의 메모리에 저장된다면 토큰 정보는 클라이언트가 저장하는 것이라고 할 수 있습니다. 사용자가 많아진다는 것은 서버의 메모리에 저장할 세션 아이디가 많아지는 것과 동일한 의미이기도 합니다. 동시 접속자 수가 많다면 서버에 부하가 올수도 있겠죠. 이러한 한계를 극복하는 것이 바로 토큰입니다.
서버는 사용자가 로그인을 할 경우 자신들의 토큰 생성 알고리즘을 통해 생성된 토큰을 제공하고, 브라우저는 이를 쿠키나 로컬 스토리지에 담아 저장합니다. 사용자는 요청을 할 때 토큰을 같이 전달하고 서버는 토큰 검증 알고리즘을 통해 유효한 요청인지를 확인합니다.
이러한 저장, 관리 위치의 차이 때문에 보안 상의 문제가 발생할 수 있습니다. 따라서 토큰은 유효 기간을 짧게 설정해 위험에 대비합니다. 토큰이 만료되면 다시 새로 유효한 토큰을 발급 받아야하는데, 서버는 갱신 요청을 위한 리프레쉬 토큰(refresh token)을 같이 제공하기도 합니다.
또한 토큰의 장점이 또 있는데요. 대부분의 웹 서비스는 다수의 사용자들로부터 전달되는 요청들을 로드밸런서를 통해 여러대의 서버에 분산해서 저장합니다. 만약 세션 정보가 메모리에 저장되지 않은 서버로 사용자의 요청이 전달될 경우 세션을 확인할 수 없겠죠. 모든 서버에 세션을 공유하는 방식도 있겠지만 이러한 비용보다 클라이언트에 토큰을 전달하고, 토큰 생성/검증 알고리즘을 모든 서버가 공유하는 비용이 더 적을 것 입니다. 이러한 이유 때문에 최근에는 토큰 방식을 더 선호하게 되었습니다.
캐시(Cache)
컴퓨터 과학에서 캐시란 자주 사용하는 데이터를 특정 공간에 저장해놓고, 필요할 때 마다 꺼내 써서 더 빠른 작업을 할 수 있도록 하는 하드웨어/소프트웨어 구성 요소입니다. 현대인들이 가장 자주 접하는 캐시가 바로 브라우저 캐시일 것 같은데요. 사용자가 웹 서핑을 할 때 서버로 부터 받은 데이터는 브라우저에 캐시로 저장됩니다. 같은 페이지를 여러 번 방문할 때 매번 모든 데이터를 받아올 필요가 없이 특정 데이터는 재사용을 해서 데이터 전송량을 줄일 수 있습니다.
어떻게 보면 쿠키와 같이 필요한 정보를 재활용하는 기술이라고 할 수 있습니다. 하지만 브라우저의 캐시는 서버와 클라이언트 간의 데이터 전송량을 줄이고, 서비스 이용 속도를 향상시키는 역할을 합니다.
최근에는 유튜브나 넷플릭스와 같은 글로벌 스트리밍 서비스의 등장으로 데이터 전송량이 예전보다 많아졌기 때문에, 이러한 캐시의 개념을 사용한 CDN(Content Delivery Network, Content Distribution Network)이 등장했습니다. 전세계에 지리적으로 분산된 캐시 서버가 존재하여 데이터를 가지고 있고, 사용자는 자신과 가장 가까운 서버에서 더 빠르고 안정적으로 필요한 데이터를 받는 것 입니다.