브라우저에서 오픈 월드 만들기, 4부: 화려한 지형보다 먼저 스트리밍

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

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

스트리밍은 "보기 좋은" 프로젝트가 보통 무너지는 지점입니다.

정지 화면에서는 많은 것을 숨길 수 있습니다. 하지만 chunk 경계를 넘을 때 발생하는 40 ms 끊김은 숨길 수 없습니다.

우리는 고급 지형 표현을 만들기 전에 일부러 스트리밍부터 테스트했습니다. 그 덕분에 로드와 언로드 동작에 대한 깨끗한 신호를 얻었습니다.

Spike 6은 단순한 chunk 콘텐츠로 주변 영역 교체를 검증했습니다.

새 탭에서 Spike 6 열기 ↗ · 소스 보기

그다음 Spike 11에서 실제 지형 경로로 넘어갔습니다. worker 쪽 디코드를 사용하는 높이 chunk 스트리밍, 그리고 17에서 33, 65 샘플 그리드로 이어지는 점진적 정밀화입니다.

새 탭에서 Spike 11 열기 ↗ · 소스 보기

순서를 정하는 일이 우리가 예상한 것보다 더 중요했습니다. 처음부터 압축된 높이 chunk로 바로 시작했다면, 모든 끊김이 모호했을 겁니다. 디코드 문제인지, 텍스처 업로드 문제인지, 지오메트리 업데이트 문제인지 알 수 없죠. Spike 6은 Spike 11이 복잡도를 더하기 전에 불확실성 한 겹을 먼저 걷어냈습니다.

이 장에서 얻은 실용적인 교훈 하나가 이후 spike들로 이어졌습니다. 업로드 정체는 평균 FPS에서 추론하지 말고 직접 측정해야 합니다. 평균 FPS는 프레임 스파이크를 가리고, 사용자가 실제로 느끼는 건 바로 그 프레임 스파이크입니다.

5부에서는 식생, 지형 셰이더, 캐스케이드 섀도가 같은 프레임 예산을 두고 경쟁하는 시각 비용 장으로 들어갑니다.

이 장에서 다룬 기술

Chunk 기반 스트리밍. 월드는 독립적인 chunk들의 그리드로 나뉩니다(보통 64x64 미터). 플레이어가 움직이면 뒤쪽 가장자리의 chunk는 언로드되고, 앞쪽 가장자리의 chunk가 스트리밍되어 들어옵니다. Skyrim의 cell 시스템이 이렇게 동작합니다. 플레이어 주변에 5x5 cell 그리드를 로드하고, 움직일 때마다 교체합니다. 브라우저 버전은 여기에 네트워크 지연이 더해지므로, 플레이어 속도에 기반한 예측 선읽기가 매우 중요해집니다. 우리의 스트리밍 아키텍처 가이드를 보세요.

점진적 heightmap 정밀화. 지형을 먼저 낮은 해상도로 보낸 다음 정밀화합니다. 그리드 크기는 임의로 정한 게 아닙니다. 각 레벨은 $(2^k+1)\times (2^k+1)$ 그리드라서 $17=2^4+1$, $33=2^5+1$, $65=2^6+1$이 됩니다. $+1$ 덕분에 모든 경계에 공유 샘플이 하나씩 유지되어 이웃끼리 딱 맞아떨어지고, 단계마다 샘플 수가 대략 네 배가 됩니다(변의 길이가 두 배가 되면 $n^2$이 그렇게 늘어납니다). 17x17 그리드(4m 간격일 때 64m chunk의 최소값)는 압축 후 약 200 바이트이고, 눈에 보이는 표면을 즉시 렌더링합니다. 그다음 33x33 정밀화를 스트리밍하고, 이어서 완전한 65x65 해상도를 보냅니다. 각 레벨은 이전 데이터를 대체하지 않고 샘플을 더합니다. 이는 먼 지형에는 저해상도 데이터를, 가까운 지형에는 완전 해상도를 쓰는 지오메트리 clipmap LOD 링에 그대로 대응됩니다. 점진적 chunk 로딩을 보세요.

델타 인코딩과 압축. 인접한 셀들의 값이 비슷하기 때문에 heightmap 데이터는 압축이 잘 됩니다. 델타 인코딩은 각 셀과 그 예측값(이웃들의 평균)의 차이를 저장해서 값들을 0 근처로 모읍니다. zlib나 brotli와 결합하면 65x65 chunk는 원본 8.4 KB에서 압축 후 1-2 KB로 줄어듭니다. 먼 chunk에 대해 정밀도를 낮추면(16-bit 대신 8-bit) 0.5-1 KB가 됩니다. 지형 데이터 압축을 보세요.

예측 선읽기. 플레이어가 도착하기 전에 chunk를 로드합니다. 선행 거리는 chunk가 로드되는 동안 플레이어가 이동하는 거리를 감당해야 하므로 $d_{\text{prefetch}}=v\cdot t_{\text{load}}$가 되고, 속도에 따라 늘어납니다. 걷는 속도(5 km/h)에서는 앞쪽 2개 chunk(128m)를 미리 가져오고, 달리는 속도(15 km/h)에서는 4개를 가져옵니다. 로드 링은 속도 방향에 따라 이동합니다. 우선순위 큐가 대기 중인 요청을 긴급도순으로 정렬하고, 플레이어가 이미 멀어진 chunk에 대한 요청은 취소합니다. 예측 선읽기를 보세요.

---

12부 중 4부.
이전: 3부 - 우리를 구한 화려하지 않은 spike들
다음: 5부 - 예쁜 것들에 예산 배정하기
시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide