[TIL/React] 2023/10/14
reference: 1)https://www.youtube.com/watch?v=tosLBcAX1vk2)https://developer.mozilla.org/ko/docs/Web/API/Web_Storage_API3)https://kyoung
reference: 1)https://www.youtube.com/watch?v=tosLBcAX1vk 2)https://developer.mozilla.org/ko/docs/Web/API/Web_Storage_API 3)https://kyounghwan01.github.io/blog/React/redux/redux-persist/#소개-사용하는-이유 4)https://velog.io/@dorazi/쿠키-웹-스토리지-로컬-스토리지-세션-스토리지
Cookie 🍪
서버가 만든 쿠키~ 클라이언트를 위해 구웠지~
사이트에 방문하면 브라우저는 서버에 요청(request)을 보낸다. 서버는 응답(response)을 할 것이고, 응답에는 각종 데이터와 방문자가 찾던 페이지 정보가 있을 것이다. 또한 브라우저에 저장하고자 하는 쿠키가 있을 수 있다. 방문자가 브라우저에 쿠키를 저장하면 해당 웹사이트를 방문할 때마다 브라우저는 해당 쿠키를 요청과 함께 보내게 될 것이다. 한마디로 쿠키는 정보 저장 tool이다.

가령, 웹사이트 1)언어설정을 한국어에서 영어로 변경하면, 2)서버에서는 쿠키를 생성한 후 3)'영어'라는 언어설정에 대한 내용을 저장해서 쿠키를 다시 반환한다. 다음에 5)사용자가 해당 사이트를 방문하면 당연스럽게 6)모든 언어가 영어로 바뀌어 있을 것이다.
HTTP 프로토콜, stateless ☝️

HTTP는 위에서 설명한 요청과 응답에 대한 통신규약이다. 문제는 stateless가 무엇인지를 알아야, 후술할 세션과 토큰 등의 개념을 이해할 수 있다.
stateless란 서버로 가는 모든 요청이, 이전 요청과 독립적으로 다뤄진다는 개념이다. 한마디로 '알빠노'다. 요청간의 연결이 존재하지 않는다는 뜻이고, 서버는 사용자가 누군지 잊어버린다. 따라서 우리는 서버에 요청할 때마다 우리가 누군지 알려줘야 할 필요가 있다. 이제 세션(Session)을 학습할 준비가 됐다.
Session 💽
세션은 다른게 아니라 일련의 상호작용을 뜻하는 말이다. 다음 예시의 상호작용이 그 자체로 세션이다.
1) 로그인을 하기 위해 id(민관123)와 password(1234)를 입력했다. 2) 서버로 해당 정보를 보낸다. 3) password가 일치하면 서버는 세션 DB에 '민관123'이라는 유저를 생성한다. 4) 해당 세션에는 별도의 ID가 존재한다. 5) 그 별도의 ID는 쿠키를 통해 브라우저로 돌아오고 저장된다. 6) 같은 웹사이트의 다른 페이지로 이동하면 위의 세션ID를 갖고있는 쿠키를 서버에 보낸다. 7) 서버는 다시 세션ID와 함께 오는 쿠키를 확인한다. (-> 이때까지도 서버는 우리가 누군지 모른다. 세션ID가 있는 쿠키를 지닌 요청이 있다는 것만 알 뿐이다.) 8) 세션DB를 확인해서 해당 ID가 '민관123'이라는 것을 확인한다. (-> 이후에는 동일한 프로세스 반복)
=> 서버에 요청할 때마다 우리가 누군지 알려주는 일련의 상호작용이 세션이다. 기억해야 할 것은, 중요한 유저 정보는 모두 서버에 있다는 것이다. 유저가 갖고있는 것은 세션ID일 뿐이다. 유저 정보와 혼동해서는 안 된다. 이 과정에서 쿠키는 그저 세션ID를 전달하기 위한 매개체에 불과했던 점 역시 잊지말자.
Token 🔑, JWT
iOS나 Android에서는 쿠키를 사용할 수 없다. 쿠키는 브라우저에만 있는 것이다. 토큰은 쿠키 대체제라고 볼 수도 있다. 토큰은 그저 이상하게 생긴 string이다.
어쨌든, 사이트에 로그인한 유저가 많을수록 그 모든 세션ID를 DB에 저장하게 된다. 유저가 늘어남에 따라 DB 리소스가 더 필요하게 되는 것이다. 그 보완책으로 JWT가 등장한다.
Web Storage 💻
사실 redux persist를 사용하다가 궁금해진, 'web storage' 개념을 학습하는 것이 오늘의 목적이었다. 당장은 token과 JWT를 더 깊게 학습할 필요는 없을 것 같다.

쿠키보다 더 좋은 매커니즘이 Web Storage라고 한다. 뭣이 그렇게 좋은지 특징을 개조식으로 나열해봤다.
- 클라이언트에 데이터를 저장할 수 있도록 HTML5부터 새롭게 지원하는 저장소이다.
- 키(Key)와 값(Value)의 쌍 형태로 데이터를 저장한다.
- 쿠키와 달리, 서버에 전송되지 않으므로 서버에 부담이 가지 않는다. (명시적으로만 전송 가능)
- 쿠키와 달리, 필요한 경우에만 꺼내 쓰는 것이므로 자동 전송의 위험성이 없다. 다른 도메인에서 요청하는 경우에는, 꺼내 쓰고 싶어도 도메인 단위로 접근이 제한되는 특성 덕분에 값을 꺼내 쓸 수 없다.
- 쿠키와 달리, 대략 5MB까지의 데이터를 저장할 수 있으며 유효 기간이 존재하지 않는다.
- 종류로는 로컬 스토리지(Local Storage) 와 세션 스토리지(Session Storage) 가 있다. 데이터 보존 기간이라는 기준에 의해 구분된다.
GPT에게 부조리를 가해 표를 얻어냈다.

데이터의 영속성이라는 큰 틀을 제외하고는 별다른 차이가 없다.
정리 📝
1. 프로젝트 진행 중 store에 저장한 state가 새로고침에 의해 날아간다는 문제점을 확인
2. 해당 문제에 대한 해결책으로 redux-persist라는 키워드가 있다는 점을 인지
3. persist 사용 중 local storage에 데이터를 저장한다는 것을 보고 web storage를 학습하겠다고 결심함
4. 쿠키에 대한 개념 이해가 선행되어야 한다고 판단
5. 쿠키는 클라이언트와 서버의 통신에서 사용되는 정보 저장 도구
6. 관련해서 HTTP 프로토콜에서의 stateless를 체크, 클라이언트가 서버로 보내는 여러번의 요청간의 '알빠노'였음
7. 그러한 모르쇠를 막는 일련의 상호작용이 세션이었음
8. 어쩌다가 token, JWT까지 급발진해서 다시 web storage로 돌아옴
9. web storage는 클라이언트에 있는 데이터 저장소인데 쿠키보다 여러모로 훌륭함
10. 데이터의 영속성이라는 기준에 의해 local storage와 session storage로 나뉨
11. 결론적으로 내가 persist를 사용해서 데이터를 저장한 곳이 바로 local storage였다는 것을 알게 됨
12. 그래서 새로고침을 해도 데이터가 날아가지 않을 수 있게 된 것임
More to read
Amazon VPC Architecture 이해하기
새로운 프로젝트를 기획하며, 개발에서 무엇을 가장 먼저 고민해야 하는지 다시 돌아보게 되었습니다.한때는 프론트엔드가 모든 설계의 출발점이라고 믿었습니다. 유저가 무엇을 보고, 어떤 흐름에서 머무르고 이탈하는지에 대한 이해 없이 서비스를 만든다는 건 불가능하다고 생각했기
'원사이트'프론트엔드 관점으로 알고리즘 이해하기
오랜만에 방법론에 관한 글을 쓰게 되었습니다. 최근 상황은 이렇습니다. SSAFY에서는 하루에 엄청난 양의 알고리즘 문제들을 과제로 수행하게 됩니다. 그 과정에서, '구현력'이 매우 떨어진다는 생각이 들었습니다. 완전히 어려운 문제라면 '아쉬움'이라는 감정조차 느끼지
SubnetVPC 설계의 시작: IP와 Subnet
반복되는 루틴 속에서 얻은 안정감을 발판 삼아, 이제는 기술적 스펙트럼을 넓히기 위한 개인 프로젝트에 착수하고자 합니다.이번 프로젝트의 목표는 단순한 포트폴리오 구축을 넘어, 실제 서비스 수준의 블로그 시스템 구현과 다국어 처리 적용 등 실무에 가까운 역량을 한 단계