AI에게 만드는 법 대신 실패하는 법을 묻다: 포토그래퍼의 수천 명 동시 접속 게임 만들기

문제 상황

• 수천 명이 동시에 QR로 접속하는 100% 라이브 행사 게임에서 로딩 지연, 화면 전환 끊김, 접속 실패가 발생할 수 있는 상황
• WebSocket 활용과 같은 익숙한 방식은 배포 제약과 일정상 불안정해, 제한된 3주 안에 다른 구조를 찾아야 하는 상황

원인 분석

• 여러 Pod에 분산된 참가자 상태를 단일 요청만으로는 동시에 갱신할 수 없어, 운영 패널 변경이 일부 참가자에게만 반영되는 구조적 문제
• 실제 행사 환경의 저사양 랩톱과 WebGL, 파티클, 크로마키 영상 재생이 결합되며 전광판 렌더링이 급격히 느려지는 문제

해결 방법

• 게임 결과만 서버에 제출하고, 서버는 단계 신호와 결과 집계에 집중하는 방식으로 구조 단순화
• Redis pub/sub와 SSE로 Pod 간 상태를 동기화하고, 접속·제출 시 랜덤 지연을 둬 동시 요청 집중 완화
• 봇 기반 부하 테스트와 현장 리허설 후 Canvas 2D 전환, 파티클 제거, 엔딩 영상 하드코딩으로 성능 대응

성능/운영 포인트

• Pod 여러 대 환경에서 상태 공유용 중간 채널이 필요하며, Redis 단일 구성의 장애 대비책도 함께 고려 필요
• 실제 행사 장비 성능이 개발 환경과 다를 수 있어, 리허설에서 렌더링 비용과 FPS를 반드시 확인해야 함

적용해볼 점

• AI에게 구현을 맡기기보다 실패 가능성과 병목부터 질문하며 구조를 좁혀가는 접근
• 실사용 환경과 유사한 봇·리허설 테스트를 통해 운영 리스크를 사전에 드러내는 방식