AI와 함께한 3주, 수천 명 동시 접속 게임 개발 회고.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

3주라는 짧은 기간 동안 AI의 도움을 받아 수천 명 규모의 실시간 게임을 개발하고 운영하며 겪은 기술적 도전과 교훈을 다룬다. WebSocket의 대안으로 SSE와 Redis Pub/Sub을 활용해 서버 간 상태 동기화 문제를 해결했으며, K8s Job을 이용한 봇 테스트로 운영 안정성을 검증했다. 행사 당일 저사양 하드웨어 환경에서 발생한 렌더링 문제를 Canvas 2D 전환과 하드코딩으로 극복했으나, 실시간 동기화 지연이라는 한계도 경험했다. AI를 단순 코드 생성 도구가 아닌 아키텍처 판단과 실패 예측의 파트너로 활용한 점이 핵심이다.

빠른 이해

새로운 점

AI를 단순 코드 생성 도구가 아닌, 아키텍처 결정과 실패 시나리오 예측을 위한 파트너로 활용하여 3주라는 짧은 기간 내에 대규모 실시간 게임을 성공적으로 배포했다.

핵심 메커니즘

클라이언트의 REST POST 결과 제출과 서버의 SSE 기반 상태 푸시, Redis Pub/Sub을 통한 다중 Pod 간 상태 동기화 파이프라인.

핵심 수치

개발 기간: 3주
전광판 시각 요소: 3,000개
전광판 동기화 지연: 최대 1분

섹션별 상세

실시간 게임을 위한 아키텍처 설계

수천 명의 동시 접속자를 처리하기 위해 WebSocket을 고려했으나 3주라는 개발 기간 내 구현이 어려워 대안을 선택했다. REST POST로 결과를 제출하고 SSE로 게임 단계를 푸시하는 방식을 채택했다. K8s 환경에서 여러 Pod가 독립적으로 동작하여 상태 동기화가 불가능했던 문제는 Redis Pub/Sub을 도입해 해결했다. 이를 통해 모든 Pod가 실시간으로 게임 상태를 공유하며 일관된 경험을 제공할 수 있게 되었다.

봇 테스트를 통한 운영 안정성 확보

실제 행사 환경에서의 부하를 예측하기 위해 K8s Job을 활용한 봇 테스트를 수행했다. 실제 사용자의 네트워크 지연, 이탈, 새로고침 등 다양한 행동 패턴을 시나리오로 구성하여 대량의 봇을 실행했다. 이 과정에서 Redis 네트워크 부하 문제를 사전에 발견하고 스펙을 조정했다. 완벽한 검증은 불가능했으나, 잠재적 장애 요인을 미리 파악하여 운영 안정성을 높였다.

하드웨어 제약과 렌더링 최적화

행사 당일 송출용 랩톱이 저사양 내장 그래픽 환경임을 확인하고 WebGL 기반의 렌더링이 불가능함을 인지했다. Canvas 2D로 전환하고 파티클 효과를 제거하는 등 연산을 최적화했다. 또한, 실시간 집계 수치와 무관하게 화면을 가득 채우는 하드코딩된 시각적 피드백을 적용하여 하드웨어 제약 속에서도 게임의 핵심 경험을 유지했다.

용어 해설

서버 전송 이벤트(SSE): — Server-Sent Events의 약자로, 클라이언트의 요청 없이 서버가 실시간으로 데이터를 푸시할 수 있는 웹 기술이다. 본문에서는 게임 단계와 카운트다운을 모든 참가자에게 동시에 전달하는 용도로 사용되었다.
레디스 퍼블리시/구독(Redis Pub/Sub): — Redis에서 제공하는 메시지 브로커 패턴으로, 특정 채널에 메시지를 발행하면 구독 중인 모든 클라이언트가 이를 수신한다. 다수의 서버 Pod 간에 게임 상태를 동기화하는 데 활용되었다.
쿠버네티스 파드(K8s Pod): — 쿠버네티스에서 실행되는 가장 작은 배포 단위로, 컨테이너를 포함한다. 본문에서는 수천 명의 접속자를 분산 처리하기 위해 여러 개의 Pod를 띄워 관리했다.

기술

K8s
Redis
SSE
Claude Code
GPT
Canvas 2D

언급된 리소스

문서원문 링크