[Html + Javascript] Client Side Storage VS Server Side Storage

 오늘은 웹 개발을 한다면 알아둬야 할 가장 중요한 쿠키와 세션 그리고 웹스토리지에 대해 나름대로 알고 있는 내용과 잡담을 모아 적어볼까 한다.

 가볍게 읽기를 바란다.

 

---

1. Client Side Storage VS Server Side Storage

 

 우리가 소위 웹개발, 인터넷이나 인트라넷 상 올라가거나 주소를 통해 확인이 가능한 어떠한 프로그램을 개발한다고 하면 반드시 알아둬야 할 것들이 있다. 그중 하나가 Server Side Storage, Client Side Storage가 있다.

 

 정확한 명칭이 어떤지는 모르겠다.

 왜냐하면 내가 학교에서 교재로 배울때는 그저 쿠키 VS 세션이었지 이렇게 분류하지는 않았고, 그렇게 배우지도 않았기 때문이다.

 

 그러나 이제와서 이러한 상세한 분류를 하고자 함은 이제는 단순히 세션, 쿠키 이렇게 두 개의 구도가 아니기 때문이다.

 

  1) Client Side Storage

 

 Client Side Storage 는 그 뜻 그대로 사용자 측에서 저장되는 것을 뜻한다.

 한 가지 예시를 들자면 쿠키가 여기에 속하는 것이다.

 

 예를들어 불특정 회원 A가 애플리케이션 메인 화면에 팝업이 보기 싫어서 "오늘 하루 더 이상 보지 않기" 버튼을 눌렀다고 하자.

 

 해당 어플리케이션이 만일 서버 측에 내용을 저장해야 한다면, 버튼을 누름과 동시에 불특정 회원 A에 대한 관측이 발생한다. 여기서 관측이란, 불특정 회원 A에 대한 개인정보를 수집하여 특정 회원으로 인식하는 과정을 포함한다.

 말이 어려운데 간단하게 생각하면, 김철수와 김영희를 구분하기 위한 조건을 서버가 알아야 한다는 것이다. 이 과정에서 김철수의 특징들을 수집할 수 밖에 없다. 예를 들면 남자인지 여자인지, 생김새나 집주소, 나이, 이름, 심지어는 주민번호까지 말이다. 이러한 특정 구분이 없다면 서버는 1초 전 접속한 김철수와 1초 뒤 접속한 철수 옆집 김영희를 구분할 방법이 없다.

 

 물론 말을 하기위해 극단적 상황에 비교를 했다. 그러나 실제로 서버에 겨우 구분자 하나를 그것도 사용자 맘대로 매일 생겨나는 데이터를 넣기 위해 사용한다면 굉장한 리소스 낭비가 발생할 것이다. "오늘 하루 더 이상 보지 않기" 버튼을 눌렀는지 안 눌렀는지 여부 하나를 저장하기 위해 (매일 접속 회원수) X (서버 구동 일자) X (접속 회원을 특정하기 위한 구분) 데이터가 매일 쌓여갈 것이다. 물론 일간 배치나 데몬으로 삭제하면 되겠지만, 트래픽은 어쩔 것인가.

 

 결국 나온 좋은 대안이 Client Side Storage이다.

 클라이언트측에서는 접속기기가 불특정 회원 A임은 보장이 된다고 본다. (짱구 엄마가 쇼핑몰 결제하려다가 짱구 와서 잠깐 거실에 간 사이, 짱아가 결제 버튼 누르는 이런 거는 동일한 회원으로 본다.) 이때, 특정 서버 접속 시 해당 팝업에 대한 노출여 부만 저장하면 된다. 다른 기기로 접속한 불특정 회원들에 대해서는 클라이언트가 다르니 당연히 저장된 데이터도 달라 앞선 문제에 대해 서버만큼 복잡해지지 않는다.

 

 Client Side Storage는 특정할 필요가 없고 혹시나 사용자단에서 저장하고 엑세스 하더라도 큰 문제가 되지 않는 데이터를 사용할 때 이용된다. 

 

  2) Server Side Storage

 

 Client Side Storage 가 클라이언트측에서 저장되는 것이라면 당연히 서버에서만 저장되고 액세스 되어야 할 것들도 존재할 것이다. 물론 일부 개발자는 세션이나 디비에서만 처리되어도 좋을 값을 구태여 꺼내어 와서 클라이언트 측에 히든 값으로 노출하는데 그러한 행위는 코딩에는 좋을지 몰라도 보안에 취약한 프로그래밍이라 할 수 있다.

 

 예를들어 계좌이체를 한다고 하자. 김철수 씨는 누이 되는 자의 항암치료를 위해 급하게 자신의 계좌에서 200만 원을 누이 계좌로 보내려 한다. 은행은 사용자 김철수의 어떤 정보들을 가지고 있어야 할까? 매번 이체 때마다 내 이름, 내 은행명, 내 은행 계좌번호, 이체할 금액, 받을 사람 이름, 받는 사람 은행명, 받을 사람 은행 계좌번호 등등 매번 이거를 다 받을 것인가? 심지어 로그인을 위한 김철수 정보는 어디에 저장할 것인가?

 

 만일 이를 클라이언트측에 저장한다면 대단한 보안 위협이다. 아니면 암호화에 자신이 있든지.

 개인정보나 로그인정보등은 절대 절대 절대 클라이언트 측에 저장하지 않도록 한다. 혹시나 어쩔 수 없는 상황에서는 팀장이나 프로젝트 개발 담당자 (PM)에게 가서 다른 방법을 먼저 물어보고 이러한 방법을 사용해도 되는지 물어보고 써라. (제발) 

 

 Server Side Storage는 서버측에 저장되는 모든 저장 방식을 의미한다. 즉 세션만을 이야기하는 것이 아니다. 회원가입 당시 저장된 데이터를 로그인만 하면 서버 측에서만 처리하도록 하면 구태여 개인정보를 클라이언트 측으로 노출할 필요조차 없다. Client Side Storage는 반드시 로컬 컴퓨터 어딘가에 차곡차곡 쌓여가지만 Server Side Storage는 사용자에게 주지도 않으니 중간에서 가로채거나(인터셉팅) 사용자 컴퓨터를 해킹하더라도 알아낼 수가 없다.

 

---

 

2. Client Side Storage

 

 클라이언트측 리소스 저장에는 쿠키가 있었는데, 이게 너무 옛날 방식이라 새로운 구조(Hash/Dictionary)로 고려된 web-storage도 생겨 났다.

 

  1) Cookie

 

Cookie는 web-storage가 나오기 전까지 애용되던 클라이언트 측 저장 방식이다.

4KB까지 저장되는 문자열 데이터라고 보면 된다.

브라우저별, 주소(도메인 + 경로지정 가능) 별 날짜를 제한하여 사용한다. 기한을 주는 형식으로 영구적 사용은 불가능하다.

MDN에서 쿠키 번역된 거 보면 영속적(?)이라고 하는데 말이 너무 어렵고 무슨 말인지도 모르겠다. 간단히 말하면 브라우저가 꺼진다고 해도 안 사라지고 지정날짜까지는 남는다는 것이다. 무슨 무당도 아니고 영구적으로 안 사라지는 것도 아니고 영속이라니 이거는 단어 선택이 좀 그렇다.

쿠키는 문자열을 파싱 하여 사용을 하는 편이다.

 

예시 1) 티스토리 쿠키의 예시

포맷은 [key = value] + ;

예를 들어 agent-name이라는 쿠키값에 Google Chrome을 삽입한다고 하면 다음과 같은 문자열이 추가된다.

 

agent-name=Google Chrome;

 

클라이언트 측 저장이라 할지라도 클라이언트 언어로만 처리하는 것은 아니고 서버사이드 언어로도 충분히 작성이 가능하다. 

하나의 화면에서 생성된 쿠키는 헤더에 추가되어 파생 화면에 전달된다.

 

 

  2) Web storage

 

Web storage는 쿠키하고 비슷하다. 다만 사용방법과 사용할 수 있는 범위에 차이가 있다.

용량은 5MB니 10MB니 해도 결국 브라우저별 지원 용량이 다르고, 또 방법을 찾아내는 자에게는 추가가 가능하니 용량 이야기는 배제하겠다.

 

    [1] local-Storage

 

쿠키의 문제점은 정말 많은데 우선 헤더에 포함되어 송수신이 되므로 정보 탈취의 위험이 따른다.

그런데 이거는 헤더에도 없지만 로컬의 값을 파생 화면에 전달해준다.

쿠키처럼 클라이언트 쪽에서 저장하고 사용한다. 

다만 일자나 기한을 설정하지 않아 삭제하지 않는 이상 계속 남아 있다.

 

쿠키는 또한 문자열로 별도 파싱을 해서 값을 가져와야만 했다.

그래서 이거는 setItem, getItem이라고 해서 메서드를 제공한다.

 

예시 2) localStorage 입력 방법

 

    [2] session-Storage

 

session-Storage는 local-Storage 하고는 아주 약간 매우 근소한 차이로 다르다.

또, local-Storage하고는 달리 이거는 브라우저를 껐다가 켜면 저장이 안 된다.

뿐 아니라 같은 브라우저 같은 url이라고 해도 tab이 다르면 다른 거다.

이 때문에 좀 많은 사람들이 local-Storage만 쿠키에 대응하여 사용 가능하다 하고 이거는 넘어가던데, 반대로 생각해야 한다. 이게 더 중요하다.

 

일단 먼저 사용방법도 보면 local-Storage와 다를 게 없다.

 

예시 3) sessionStorage 사용 방법 및 value는 문자열이 되는 부분.

 

우선 동일한 주소로 브라우저에서 두 페이지를 모두 열고, 콘솔을 열어 대기한다.

Tab 중 하나에 다음 코드를 붙여 넣어 실습한다.

// localStorage 테스트
// 1. 존재하는지
console.log(localStorage);
// 2. 저장
localStorage.setItem('123',234);
// 3. 이제 존재하는지
console.log(localStorage);

// sessionStorage 테스트
// 1. 존재하는지
console.log(sessionStorage);
// 2. 저장
sessionStorage.setItem('456',789);
// 3. 이제 존재하는지
console.log(sessionStorage);

 

넣고 나면 각각 아래와 같이 출력될 것이다.

 

실습 1) session-Storage VS local-Storage

이제 다른 Tab에 동일한 주소에서 콘솔에 값들이 존재하는지 확인해보자.

 

// localStorage 테스트
// 1. 존재하는지
console.log(localStorage);

// sessionStorage 테스트
// 1. 존재하는지
console.log(sessionStorage);

 

그러나 결과는 아래와 같을 것이다.

 

실습 2) session-Storage VS local-Storage

tab을 하나의 작업이라 본다면, session-storage는 이러한 작업공간에서만 유휴 한 자원이 된다는 것이다.

 

  3) etc...

 

사실 웹 브라우저만 따져본다면 위와 같은 쿠키, session-Storage, local-Storage, indexedDB가 있겠지만 안드로이드 어플 다른 특정 앱들도 고려한다면, 로컬에 저장해둔 sqlite 나 txt 파일... 기타 등등 클라이언트 측에서 두고 사용하는 모든 것을 Client Side Storage로 본다.

 

---

 

3. Server Side Storage

  1) Session

 

세션은 서버사이드 언어로 작성되며 클라이언트측에서 알 수가 없다는 것이 큰 이점이다.

구태여 클라이언트측에 공개하지 않는 이상 확인도 할 수가 없다.

 

주로 로그인, 임시 저장된 개인정보, 결제 직전 결제정보, 장바구니 등에서 활용되며 사용자에게 전달하면 안 되는 정보나 임의의 수정이나 변경이 발생하면 안되는 글로벌 값을 사용할 때도 활용된다. 예를 들면 김철수가 김영희를 좋아해서 김영희의 네이버 계정으로 로그인을 시도할 수 있다. Client Side Storage라면 로컬에 저장된 데이터를 수정하여 자신을 김철수가 아닌 김영희로 둔갑하는 것이 어렵지 않다. 그러나 Server Side Storage에서는 특별한 상황이 아니고서는 클라이언트 측에서 값을 수정할 수 없다.

 

그러나 세션은 하나의 서버에서 다수의 클라이언트의 값을 저장하므로 오래 저장해 둘 수 없다.

물론 세션 또한 쿠키처럼 기한을 제공하고 있으며, 지정한 기한 동안 연결 요청을 하지 않은 클라이언트를 끊어낸다.

또한 동시 접속자가 무수히 많아질 경우, 서버의 허용 용량까지만 세션 저장은 가능하고 그 이후는 저장이 안 된다. 예를 들어 서버 파일 시스템이 풀이 나서 더 이상 읽고 쓰고 가 불가능하다면 당연히 기존 파일을 정상적으로 읽고 쓸 수 없을 것이다.

 

또한 세션에는 쿠키나 web-storage와는 달리 특별한 객체(리스트, 배열, 트리, 그래프 등)들을 쓰고 읽을 수 있다.

 

  2) etc...

 

Client Side Storage에서마찬가지로 디비, 외부 연동 서버, 서버에 올려둔 파일 등 서버에서 관리하는 모든 저장되는 자원을 Server Side Storage라고 할 수 있다.

 

---

 

 

 

 

참고 1 : https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Client-side_storage

Client-side storage

참고 2 : https://ko.wikipedia.org/wiki/Indexed_Database_API

Indexed Database API - 위키백과, 우리 모두의 백과사전