[ 문제 설정 ] 게임 진행 중 상태 동기화 실패

처음 방이 생성되고, 첫 게임에서는 준비 상태가 비디오 피드에 잘 반영되었습니다. 하지만 게임이 끝나고 다시 대기 상태로 넘어갔을 때, 새로운 준비 상태가 비디오 피드에 반영되지 않는 현상이 발생했습니다. 동시에 방장이 나갔을 때 새로운 방장이 제대로 반영되지 않는 문제가 있었습니다.

[ 1차 해결 시도 ] 전역 상태와 로컬 상태의 일관성에 대한 고민

처음에는 전역 상태와 로컬 상태의 관리 방식에 문제가 있다고 판단했습니다. 여러 사용자가 동일한 게임 단계에서 같은 데이터를 공유해야 하므로, 어떤 데이터를 전역 상태로 관리하고, 어떤 데이터를 지역 상태로 유지할지 명확히 정리해야 했습니다.

전역 상태와 로컬 상태의 구분 기준

• 전역 상태로 관리할 값
  • 여러 컴포넌트에서 공유되어야 하며, 동기화가 중요한 값
  • ex) readyUsers (모든 사용자의 준비 상태), isHost (방장 여부)
• 로컬 상태로 관리할 값
  • 특정 컴포넌트 내에서만 사용되거나, UI에만 영향을 미치는 값
  • ex) 특정 버튼의 활성화 상태, 임시 입력값

초기 설계

처음에는 준비 상태(readyUsers)를 로컬 상태로 관리하고, 서버에서 브로드캐스트된 준비 상태를 기준으로 클라이언트의 UI를 업데이트하는 방식으로 설계했습니다. 이는 클라이언트가 준비 버튼을 누르면 서버가 모든 사용자의 준비 상태를 계산해 브로드캐스트하고, 이를 다시 클라이언트에서 받아와 로컬 상태를 업데이트하는 흐름을 따랐습니다. 이를 통해 준비 상태를 클라이언트별로 독립적으로 유지하며, 불필요한 전역 상태의 의존성을 줄이고자 했습니다.

설계의 한계

하지만 준비 상태는 모든 참가자의 UI에 실시간으로 동기화되어야 하는 값이었기 때문에, 전역 상태로 관리하는 것이 더 적합하다는 점이 드러났습니다. 지역 상태로 관리할 경우 다음과 같은 문제가 발생할 가능성이 있었습니다:

1. 데이터 동기화 지연 : 서버에서 브로드캐스트된 준비 상태가 클라이언트 간 비동기적으로 수신될 경우, 각 클라이언트의 준비 상태가 일치하지 않는 상황이 발생할 수 있었습니다.
2. 불필요한 재연산 : 모든 클라이언트가 개별적으로 준비 상태를 로컬에서 관리하면, 동일한 상태를 업데이트하기 위해 각 클라이언트에서 중복 작업이 이루어질 가능성이 있었습니다.
3. UI 불일치 : 특히, 게임 종료 후 다시 대기 상태로 전환되었을 때 로컬 상태의 초기화가 누락되거나 지연되면, 준비 상태가 잘못 반영되는 문제가 발생할 수 있었습니다.

결론적으로, 준비 상태처럼 공유된 상태는 전역으로 관리하여 클라이언트 간 동기화와 상태 업데이트의 일관성을 유지하는 것이 더 적합하다고 판단되었습니다.

[ 2차 해결 시도] 상태가 전역으로 관리되었음에도 불구하고 동작하지 않음