[개발일지] 일시적인 게임 데이터, 어디에 저장할까?

1. 배경

숫자 야구 웹 게임을 구현하던 중, 플레이어가 선택한 비밀 숫자를 어디에, 어떻게 저장할지 고민하게 되었다. 데이터베이스에 저장하는 방법도 떠올렸지만, 이 숫자는 게임이 끝나면 사라져도 되는 일시적인 데이터이고, 매번 예측 요청이 들어올 때마다 DB를 조회하는 것도 비효율적이라고 판단해 빠르게 후보에서 제외했다.

그 대신,

• 프론트엔드에서 전역 상태 관리로 들고 갈지
• 백엔드에서 캐시를 활용해 관리할지

두 가지 방식 사이에서 고민하게 되었다.

이번 글에서는 이 두 접근 방식 중 하나를 선택하기까지 어떤 기준으로 비교하고 고민했는지 정리해 보고자 한다.

2. 문제 구체화

위 이미지와 같이, 게임방에 두 플레이어가 접속하고 게임을 시작하면, 각자 고유의 비밀 번호를 설정할 수 있다. 비밀 번호의 요구 사항은 다음과 같이 정의할 수 있다.

• 게임 진행동안만 유지되어야 한다.
• 게임이 끝나면 영구적으로 저장할 필요 없다.
• 번호 예측 결과를 신뢰할 수 있어야 한다.

이에 따라, 영속적인 DB 보다는 일시적인 저장소 후보를 보게 되었고, 그중에서 프론트엔드 전역 상태, 백엔드 캐시 두 가지를 비교하고자한다.

3. 프론트엔드 전역 상태로 관리하기

필자는 프론트엔드 개발자기에, 프론트엔드 전역 상태로 관리하는 방법을 처음으로 생각했다. 그러면 어떻게 구현할 수 있을까? 기술 스택은 React + Zustand를 사용하고, 실시간 통신을 위해 웹소켓으로 연결되어 있다고 가정하자.

구현 방식

1. 플레이어가 입력한 숫자를 전역 스토어에 저장한다.
2. 매 턴마다 플레이어가 추측한 숫자를 보내면, 웹소켓으로 통해 서버는 추측 숫자만 전송한다.
3. 상대 플레이어가 추측 숫자를 전달 받으면, 전역 스토어에 저장된 비밀 숫자와 비교한다.
4. strike/ball/out을 계산한 결과를 전송한다.

장점

1. 직관적이고 빠른 구현: 전역 스토어에 비밀 숫자를 저장하고, 추측 숫자를 받을때마다 계산 결과를 반환하면 끝
2. 단순한 API 설계: 서버는 비밀 숫자 저장/관리를 신경쓰지 않고 판정 결과만 신경써도 됨

한계

1. 신뢰성 없는 판정 결과: 상대 클라이언트에서 결과를 판정하기 때문에, 서버 입장에서는 신뢰성 없는 결과를 받게된다. 클라이언트에서 요청을 조작하여 보낼 수도 있기 때문이다.

채택하지 않은 이유

진짜 서비스로 운영한다면 판정 결과에 신뢰성이 있어야한다고 생각했다. 그렇게 하기 위해서는 서버에서 직접 상대 플레이어의 비밀 번호를 확인하고 판정 결과를 반환하는 것이 옳다고 생각했다.

4. 백엔드 캐시(Redis)로 관리하기

프론트엔드 전역 상태 관리 방식의 한계점을 깨닫고, 두 번째로 생각한 후보이다. DB에 저장하고 조회하는 것 보다는 캐시를 통한 접근이 성능이 좋기에, 캐시로 관리하기로 했다. 캐시는 다중 서버로 확장될 가능성을 고려하여 Redis를 사용했고, 어떻게 구현할 수 있는지 알아보자.

구현 방식

1. 플레이어가 숫자를 입력하면 백엔드 서버로 비밀 숫자를 전송한다.
2. 서버는 Redis에 플레이어의 비밀 숫자를 저장한다.
3. 플레이어가 추측 번호를 서버로 전송한다.
4. 서버는 Redis에 저장되어 있는 상대 플레이어의 비밀 숫자와 비교하여 판정 결과를 전송한다.

장점

1. 공정성과 신뢰성: 비밀 숫자는 서버가 관리하므로, 클라이언트가 값을 조작해도 게임의 진실이 바뀌지 않는다.
2. 확장성: 게임 결과와 관련된 기능(리플레이, 통계 등) 확장에 용이하다.
3. DB 대비 성능 이점: 캐시는 메모리 기반이라 조회가 매우 빠르다.

단점

1. 복잡도 증가: Redis 설치 및 운영을 위한 인프라가 추가되고, 캐시 키/TTL/삭제 시점과 같은 운영 관점 고민거리가 추가된다.

선택 기준

두가지를 고민한 결과 백엔드 캐시로 관리하기로 했으며, 내가 어떤 기준으로 결정하게 되었는지 작성해봤다.

1. 추측 결과를 판단하는 역할

게임 흐름에 있어, 2명의 클라이언트가 게임 참가자고, 서버가 심판 역할을 하는 것이 자연스럽다. 번호 추측을 클라이언트가 하고, 추측 결과를 판단하는 것은 심판 역할을 부여받은 서버가 하는 것이 옳다. 그래서 두 플레이어의 비밀 번호도 서버가 가지고 있어야 한다.

2. 확장성

게임 진행 및 결과와 관련된 기능이 확장되는 경우를 고려하면 서버가 비밀 번호를 가지고 있고, 서버가 결과를 판단할 수 있어야 한다고 생각했다.

그래서 이번 숫자 야구 프로젝트에서는 게임의 진실은 서버가 들고 간다는 기준으로, 백엔드 캐시를 활용하는 구조를 선택했다.