session storage
베팅방을 새로 생성하면 세션 스토리지에 userInfo라는 키로 회원 정보가 저장 된다. 이는 한 명이 여러 베팅에 동시 참여할 수 없고, 베팅방을 실수로 나가도 해당 베팅방으로 돌아갈 수 있게 하려고 설정해놓은 값이다.
하지만 이렇게 세션 스토리지를 사용하는 것에는 몇 가지 문제점이 있는데, 그 중 가장 큰 문제점은 세션 스토리지가 브라우저 탭 단위로 동작한다는 것이었다. 다른 탭을 열어서 베팅방에 들어가게 되면 동일 계정임에도 불구하고 아래와 같이 참여 중인 베팅 방이 뜨지 않는다.
세션 스토리지는 웹 브라우저에서 제공하는 클라이언트 측 저장소다. 브라우저가 닫히거나 새로고침 되지 않는 한에, 동일 탭 내에서 데이터를 저장하고 사용할 수 있는 기능을 제공한다. localStorage와도 비슷하지만 탭(Session) 단위로 동작한다는 차이가 있다.
- 탭 단위의 스토리지: 같은 도메인에서 열더라도 탭이 다르면 세션 스토리지를 공유하지 않는다.
- 생명 주기: 새로고침 해도 데이터가 유지되지만, 탭을 닫으면 삭제된다.
- 데이터 크기 제한: 일반적으로 브라우저마다 약 5-10MB 정도의 데이터를 저장할 수 있다.
- 동기화 범위: 같은 탭 내에서만 데이터를 공유한다. 다른 탭이나 브라우저 윈도우와는 독립적이다.
이와 같은 특징 때문에 세션 스토리지는 임시 데이터 저장에 적합하다. 예를 들어, 현재 탭에서만 사용되는 폼 입력 혹은 일시적인 사용자 작업 상태를 저장하는 데에만 적합하다.
물론 베팅방 참여 상태가 일시적인 임시 데이터에 속하기는 한다. 하지만 베팅방 참여 상태는 사용자가 새 탭을 열거나 다른 기기에서 접근해도 항상 동일하게 유지되어야 하는, 동기화가 필요한 데이터다. 따라서 이런 경우에는 기존의 세션 스토리지 방식이 적합하지 않다. 세션 스토리지는 앞서 설명했듯이 탭 간, 브라우저 간 독립적으로 동작하기 때문이다.
이렇게 동기화가 필요한 데이터는 서버 중심의 저장 방법을 사용하는 것이 적합하다. 몇 가지 방법이 있는데, 다음과 같다.
- 서버에서 사용자 세션을 관리하고 세션ID를 쿠키에 저장해 사용자 요청 시 세션 상태를 확인한다.
- 사용자의 베팅방 참여 상태를 데이터베이스에 저장하고 이를 기반으로 동기화한다.
- Redis와 같은 메모리 기반 캐시 서버를 사용해 베팅방 참여 상태를 관리한다.
- JWT 활용
- Socket 활용
위의 방법 중 첫 번째 방법을 활용하기로 했다. 영구적으로 관리할 필요 없는 일시적이고 임시적인 데이터기 때문에 데이터베이스까지는 필요 없을 것 같고, 실시간 관리 또한 필요하지 않으며, 베팅방 ID는 링크에서도 충분히 유추할 수 있으므로 보안이 필요한 데이터도 아니기 때문이다.
| 구분 | 쿠키 (Cookie) | 세션 (Session) |
|---|---|---|
| 저장 위치 | 클라이언트(브라우저)에 저장 | 서버에 저장 |
| 수명 | 쿠키에 설정된 만료 시간에 따라 지속됨 (지속 쿠키: 브라우저 종료 후에도 유지) | 일반적으로 브라우저 종료 시 세션이 만료됨 |
| 보안 | 클라이언트에 저장되므로 보안에 취약할 수 있음 (민감한 정보 저장 금지) | 서버에 저장되므로 상대적으로 보안이 우수함 |
| 용량 제한 | 쿠키 1개당 최대 4KB, 도메인당 최대 20개 정도 | 서버에 저장되므로 용량 제한은 서버의 설정에 따름 |
| 속도 | 클라이언트에서 바로 확인 가능하므로 빠름 | 서버 요청이 필요하므로 상대적으로 느릴 수 있음 |
| 사용 목적 | 사용자 상태 저장(예: 로그인 상태, 사용자 설정, 방문 기록) | 로그인 상태 유지, 민감한 데이터 저장 및 서버 기반 인증 처리 |
| 전송 방식 | HTTP 요청 시 쿠키 데이터가 항상 자동으로 전송됨 | 서버에서 세션 ID를 쿠키 또는 URL 파라미터로 전송하여 확인 |
| 관리 방법 | 클라이언트(브라우저)에서 직접 수정 가능 | 서버에서만 관리 가능 (클라이언트는 세션 ID만 보유) |
| 적용 사례 | 사이트 방문 기록, 기본 언어 설정, 광고 추적 등 | 사용자 인증, 장바구니 데이터 유지, 로그인 세션 관리 등 |
| 취약점 | CSRF 및 XSS 공격에 취약 | 세션 고정(Session Fixation) 공격에 취약 (보안 설정으로 보완 가능) |
베팅방 참여 상태는 모든 탭이나 브라우저에서 동기화되어야 한다. 쿠키는 동일한 도메인에서는 모든 탭과 브라우저에서 공유되므로 사용자의 베팅방 참여 상태를 유지하고 동기화 할 수 있다. 또한 쿠키는 HTTP 요청 시 자동으로 서버로 전송되기에 서버가 사용자의 상태를 확인하거나 업데이트하기 쉽다.
- 베팅방 참여 요청: 사용자가 베팅방에 참여하면 서버에서 해당 사용자의 세션을 생성하고 상태를 저장한다. 이때, 세션ID는 쿠키에 저장된다.
- 새 탭에서 베팅방 접근시: 쿠키에 세션ID가 요청에 포함되어 서버로 전달되고, 서버가 확인 후 베팅방 참여 정보를 반환한다.
- 베팅 취소시: 서버가 세션 데이터를 삭제하고 상태를 초기화하면, 이후 요청에는 베팅방 참여 상태를 확인할 수 없다.
베팅방 ID는 URL에도 노출되는 정보라 전혀 민감한 정보가 아니다. 이런 경우 로컬 스토리지에 저장하는 것이 좀 더 간단하고 효율적일 수 있다.
하지만 동기화가 필요하기에 세션+쿠키 방식을 고려한 것인데, 로컬 스토리지의 경우 디바이스 간 동기화가 되지 않는다는 단점이 있다. 이를 극복하고 오버헤드를 줄일 수 있는 방법을 추가적으로 고려해봐야 한다.
- 사용자가 베팅방에 참여 중인지 여부에 따라 다른 UI를 보여줘야 한다. (이미 참여 중인 베팅방이 있는 경우 사용자에게 안내)
- 세션 만료 시 처리
- 필요한 경우에 세션 데이터 일부를
localStorage에 저장하여 사용