session storage

세션 스토리지에 userInfo 값 저장하던 것의 문제점

베팅방을 새로 생성하면 세션 스토리지에 userInfo라는 키로 회원 정보가 저장 된다. 이는 한 명이 여러 베팅에 동시 참여할 수 없고, 베팅방을 실수로 나가도 해당 베팅방으로 돌아갈 수 있게 하려고 설정해놓은 값이다. 하지만 이렇게 세션 스토리지를 사용하는 것에는 몇 가지 문제점이 있는데, 그 중 가장 큰 문제점은 세션 스토리지가 브라우저 탭 단위로 동작한다는 것이었다. 다른 탭을 열어서 베팅방에 들어가게 되면 동일 계정임에도 불구하고 아래와 같이 참여 중인 베팅 방이 뜨지 않는다.

세션 스토리지란?

세션 스토리지는 웹 브라우저에서 제공하는 클라이언트 측 저장소다. 브라우저가 닫히거나 새로고침 되지 않는 한에, 동일 탭 내에서 데이터를 저장하고 사용할 수 있는 기능을 제공한다. localStorage와도 비슷하지만 탭(Session) 단위로 동작한다는 차이가 있다.

세션 스토리지의 특징

1. 탭 단위의 스토리지: 같은 도메인에서 열더라도 탭이 다르면 세션 스토리지를 공유하지 않는다.
2. 생명 주기: 새로고침 해도 데이터가 유지되지만, 탭을 닫으면 삭제된다.
3. 데이터 크기 제한: 일반적으로 브라우저마다 약 5-10MB 정도의 데이터를 저장할 수 있다.
4. 동기화 범위: 같은 탭 내에서만 데이터를 공유한다. 다른 탭이나 브라우저 윈도우와는 독립적이다.

이와 같은 특징 때문에 세션 스토리지는 임시 데이터 저장에 적합하다. 예를 들어, 현재 탭에서만 사용되는 폼 입력 혹은 일시적인 사용자 작업 상태를 저장하는 데에만 적합하다.

물론 베팅방 참여 상태가 일시적인 임시 데이터에 속하기는 한다. 하지만 베팅방 참여 상태는 사용자가 새 탭을 열거나 다른 기기에서 접근해도 항상 동일하게 유지되어야 하는, 동기화가 필요한 데이터다. 따라서 이런 경우에는 기존의 세션 스토리지 방식이 적합하지 않다. 세션 스토리지는 앞서 설명했듯이 탭 간, 브라우저 간 독립적으로 동작하기 때문이다.

동기화가 필요한 데이터의 저장 방법

이렇게 동기화가 필요한 데이터는 서버 중심의 저장 방법을 사용하는 것이 적합하다. 몇 가지 방법이 있는데, 다음과 같다.

1. 서버에서 사용자 세션을 관리하고 세션ID를 쿠키에 저장해 사용자 요청 시 세션 상태를 확인한다.
2. 사용자의 베팅방 참여 상태를 데이터베이스에 저장하고 이를 기반으로 동기화한다.
3. Redis와 같은 메모리 기반 캐시 서버를 사용해 베팅방 참여 상태를 관리한다.
4. JWT 활용
5. Socket 활용

위의 방법 중 첫 번째 방법을 활용하기로 했다. 영구적으로 관리할 필요 없는 일시적이고 임시적인 데이터기 때문에 데이터베이스까지는 필요 없을 것 같고, 실시간 관리 또한 필요하지 않으며, 베팅방 ID는 링크에서도 충분히 유추할 수 있으므로 보안이 필요한 데이터도 아니기 때문이다.

구현을 위한 사전 지식

쿠키와 세션의 차이

구분	쿠키 (Cookie)	세션 (Session)
저장 위치	클라이언트(브라우저)에 저장	서버에 저장
수명	쿠키에 설정된 만료 시간에 따라 지속됨 (지속 쿠키: 브라우저 종료 후에도 유지)	일반적으로 브라우저 종료 시 세션이 만료됨
보안	클라이언트에 저장되므로 보안에 취약할 수 있음 (민감한 정보 저장 금지)	서버에 저장되므로 상대적으로 보안이 우수함
용량 제한	쿠키 1개당 최대 4KB, 도메인당 최대 20개 정도	서버에 저장되므로 용량 제한은 서버의 설정에 따름
속도	클라이언트에서 바로 확인 가능하므로 빠름	서버 요청이 필요하므로 상대적으로 느릴 수 있음
사용 목적	사용자 상태 저장(예: 로그인 상태, 사용자 설정, 방문 기록)	로그인 상태 유지, 민감한 데이터 저장 및 서버 기반 인증 처리
전송 방식	HTTP 요청 시 쿠키 데이터가 항상 자동으로 전송됨	서버에서 세션 ID를 쿠키 또는 URL 파라미터로 전송하여 확인
관리 방법	클라이언트(브라우저)에서 직접 수정 가능	서버에서만 관리 가능 (클라이언트는 세션 ID만 보유)
적용 사례	사이트 방문 기록, 기본 언어 설정, 광고 추적 등	사용자 인증, 장바구니 데이터 유지, 로그인 세션 관리 등
취약점	CSRF 및 XSS 공격에 취약	세션 고정(Session Fixation) 공격에 취약 (보안 설정으로 보완 가능)

현재 상황에서 쿠키를 활용해야 하는 이유

베팅방 참여 상태는 모든 탭이나 브라우저에서 동기화되어야 한다. 쿠키는 동일한 도메인에서는 모든 탭과 브라우저에서 공유되므로 사용자의 베팅방 참여 상태를 유지하고 동기화 할 수 있다. 또한 쿠키는 HTTP 요청 시 자동으로 서버로 전송되기에 서버가 사용자의 상태를 확인하거나 업데이트하기 쉽다.

작동 흐름

1. 베팅방 참여 요청: 사용자가 베팅방에 참여하면 서버에서 해당 사용자의 세션을 생성하고 상태를 저장한다. 이때, 세션ID는 쿠키에 저장된다.
2. 새 탭에서 베팅방 접근시: 쿠키에 세션ID가 요청에 포함되어 서버로 전달되고, 서버가 확인 후 베팅방 참여 정보를 반환한다.
3. 베팅 취소시: 서버가 세션 데이터를 삭제하고 상태를 초기화하면, 이후 요청에는 베팅방 참여 상태를 확인할 수 없다.

고려 사항

베팅방 ID는 URL에도 노출되는 정보라 전혀 민감한 정보가 아니다. 이런 경우 로컬 스토리지에 저장하는 것이 좀 더 간단하고 효율적일 수 있다.

하지만 동기화가 필요하기에 세션+쿠키 방식을 고려한 것인데, 로컬 스토리지의 경우 디바이스 간 동기화가 되지 않는다는 단점이 있다. 이를 극복하고 오버헤드를 줄일 수 있는 방법을 추가적으로 고려해봐야 한다.

FE 개발자가 할 수 있는 역할

• 사용자가 베팅방에 참여 중인지 여부에 따라 다른 UI를 보여줘야 한다. (이미 참여 중인 베팅방이 있는 경우 사용자에게 안내)
• 세션 만료 시 처리
• 필요한 경우에 세션 데이터 일부를 localStorage에 저장하여 사용