브라우저에서 오픈월드 만들기, 3부: 우리를 구한 화려하지 않은 spike들

글쓴이 Oleg Sidorkin, Cinevva CTO 겸 공동 창업자

처음 오셨나요? 시리즈 가이드를 보세요. spike가 무엇인지 설명하고 모든 편을 링크해 둡니다.

이번 편은 번쩍이는 스크린샷이 더 적고 아키텍처 보험이 더 많습니다.

Spike 1과 2를 마친 뒤, 우리는 작아 보이지만 제품 수준의 영향이 있는 위험 점검 세 가지를 돌렸습니다.

첫 번째는 Durable Objects를 이용한 브로드캐스트 fan-out이었습니다. 게임 수준의 tick 비율에서 여러 클라이언트로 위치를 분배하는 것을 테스트하고 지연 분포, tick당 CPU, 전달 무결성을 추적했습니다. 이게 실패했다면 우리는 단일 섬 소유권 대신 이른 샤딩으로 옮겼을 겁니다.

두 번째는 모바일 제약 검증이었습니다. 데스크톱 프리셋의 이름만 모바일로 바꾼 게 아니라, 같은 기준 지형에서 출발한 명확한 저비용 프로필이었습니다.

새 탭에서 모바일 프로필 열기 ↗ · 소스 보기

우리는 세그먼트 밀도, 오브젝트 수, 렌더 해상도 부담, 안개 범위를 줄였습니다. 질문은 단순했습니다. 렌더러 전체를 다시 쓰지 않고도 이 세계가 모바일 수준의 제약에서 읽히고 반응할 수 있을까.

세 번째는 창작자 워크플로를 위한 행동 생성 신뢰성이었습니다. 유효한 JSON 비율, 기대하는 primitive에 대한 의미적 정확성, 응답 지연을 평가했습니다. 이게 실패했다면 우리는 엄격한 폼 기반 행동 작성으로 옮겼을 겁니다.

이 장의 핵심 통찰은 이런 화려하지 않은 spike들이 시각적 spike보다 더 빠르게 아키텍처를 바꿨다는 점입니다. 그것들은 네트워크 토폴로지, 모바일 약속, 도구 UX에 단단한 경계를 세웠습니다.

4부에서는 다시 눈에 보이는 지형 작업으로 돌아가, 정적인 로딩 스크린샷이 아니라 이동 중 스트리밍 동작을 테스트합니다.

이 장에서 언급한 기술

Cloudflare Durable Objects. 내장 영속성과 WebSocket 지원을 갖춘, 엣지에 배포되는 상태 보존형 서버리스 인스턴스입니다. 각 Durable Object는 하나의 월드 shard(또는 chunk)에 대한 권위 있는 상태를 보관합니다. 플레이어는 WebSocket으로 연결해 같은 shard에 있는 다른 플레이어들로부터 위치 브로드캐스트를 받습니다. 플레이어가 인접한 chunk로 이동하면 그 chunk의 Durable Object에 연결합니다. Durable Object는 상태를 자동으로 디스크에 영속화하고 수천 개의 동시 인스턴스로 확장됩니다. Cloudflare Durable Objects 문서와 우리의 멀티플레이어 네트워킹에 관한 브라우저 3D 기술 가이드를 보세요.

공간 샤딩. 지리적 영역에 따라 세계를 서버 인스턴스들에 나누는 것입니다. 각 shard는 월드 그리드의 직사각형 영역을 소유합니다. 플레이어 밀도가 바뀌면 shard는 분할되거나 병합될 수 있습니다. shard 경계 근처에 있는 플레이어는 cross-shard 가시성 쿼리를 통해 두 shard의 콘텐츠를 모두 봅니다. EVE Online이 하나의 우주에서 수천 명의 플레이어를 다루는 방식이 바로 이것입니다.

WebSocket 브로드캐스트 fan-out. 실시간 위치 업데이트를 한 서버에서 연결된 많은 클라이언트로 분배하는 것입니다. 클라이언트당 하향 대역폭은 보이는 군중 규모에 선형으로 비례합니다.

$$B_{\text{client}}=N_{\text{visible}}\times b_{\text{player}}$$

게임 수준의 tick 비율(20-30 Hz)에서 각 플레이어는 초당 약 $b_{\text{player}}\approx 800$ 바이트의 위치 데이터를 만들어 내므로, 시야에 200명의 플레이어가 있으면 클라이언트당 $200\times 800=160$ KB/s가 듭니다. 단순한 all-to-all 서버 비용은 그보다 나쁘고 $N^2$처럼 커지는데, 바로 그래서 관련성 필터링(공간 관심 관리)이 tick 예산 안에서 각 연결로 밀어내기 전에 $N_{\text{visible}}$을 제한합니다. 델타 압축과 업데이트 빈도의 트레이드오프는 우리의 네트워킹 가이드를 보세요.

모바일 렌더링 제약. 모바일 GPU는 데스크톱 GPU의 1/5에서 1/10 처리량, 약 1 GB 메모리 한계(데스크톱은 2-4 GB), 그리고 지속 부하에서의 발열 스로틀링을 갖습니다. 모바일 품질 프로필은 세그먼트 밀도, 오브젝트 수, 렌더 해상도, 그리기 거리, 그림자 품질을 줄입니다. 목표는 데스크톱과의 동등함이 아니라 읽힘과 반응성을 유지하는 것입니다. 실제 GPU 벤치마크는 브라우저 3D 성능 수치를 보세요.

---

12편 중 3편.
이전: 2부 - Worker 물리와 입력 지연에 대한 두려움
다음: 4부 - 화려한 지형보다 먼저 스트리밍
시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide