멀티플레이어 크리에이터 월드를 위한 브라우저 3D 오픈 월드 기술

우리는 크리에이터들을 하나의 공유 오픈 월드에 모으고자 합니다. 로비도, 갤러리도 아닙니다. 사람들이 탐험하고, 만들고, 우연히 서로의 작품을 발견할 수 있는 살아 있는 3D 공간입니다. 브라우저 탭에서 로드되면서도 머물 가치가 있는 장소처럼 느껴지는 공간을 말합니다.

이는 어려운 문제입니다. Skyrim과 The Witcher 3는 월드를 구축하는 데 수억 달러를 들였지만, 여전히 수십 기가바이트의 디스크 공간과 전용 하드웨어가 필요합니다. 우리의 목표는 브라우저 탭에서 실행되고, 수백 명의 플레이어가 상태를 공유하며, 크리에이터들이 실제로 재구성할 수 있는 월드입니다.

이 가이드는 관련 기술을 조사하며 알아낸 내용을 정리합니다. 현재 가능한 것, 앞으로 가능해질 것, 그리고 목표를 실현할 수 있는 아키텍처를 살펴봅니다.

Skyrim과 The Witcher에서 배울 수 있는 것

기술을 선택하기 전에 가장 성공적인 두 오픈 월드가 실제로 어떻게 작동하는지 이해하면 도움이 됩니다. 이들이 사용하는 기법은 놀라울 정도로 브라우저의 제약 조건에도 잘 들어맞습니다.

Skyrim의 셀 시스템

Skyrim의 오픈 월드는 플레이어 주변의 5x5 셀 그리드를 스트리밍합니다. 멀리 있는 산은 저해상도 임포스터입니다. 플레이어는 이를 전혀 눈치채지 못합니다.

Skyrim은 월드를 57x37개의 외부 셀로 나누며, 각 셀은 4096x4096 게임 단위(약 59미터)입니다. 엔진은 언제나 플레이어 주변의 5x5 셀 그리드를 로드합니다. 플레이어가 이동하면 뒤쪽 가장자리의 셀은 언로드되고 앞쪽 가장자리의 셀은 스트리밍됩니다. 내부 공간(던전, 건물)은 문 트리거를 통해 로드되는 별도의 월드 공간입니다.

이 방식은 브라우저 월드에도 그대로 적용할 수 있습니다. 전체 맵을 로드하는 대신 플레이어 주변 지역만 로드하고, 이동에 따라 청크를 교체합니다. 핵심은 Skyrim이 멀리 있는 지형의 전체 디테일을 절대 보여주지 않는다는 점입니다. 대신 다중 해상도 방식을 사용합니다.

Skyrim의 LOD(디테일 수준) 단계:

• 1~2개 셀 이내(플레이어 바로 주변)는 전체 디테일로 표시
• 중간 거리에서는 단순화된 메시 사용(오브젝트의 작은 지오메트리 제거)
• 중간 거리 너머의 나무와 바위에는 빌보드 임포스터 사용
• 지형 LOD는 멀리 있는 경관에 미리 베이크된 저해상도 메시 사용
• 오브젝트별로 페이드 거리를 조정(풀은 가장 먼저 사라지고 건물은 가장 나중에 사라짐)

Skyrim의 경관은 셀마다 32x32 버텍스 패치를 갖는 높이 맵 기반 지형을 사용합니다. 각 패치에는 알파 맵으로 블렌딩된 서로 다른 텍스처를 적용할 수 있습니다. 이 방식은 저장 및 렌더링 비용이 낮습니다. 셀 하나의 지형 데이터는 메가바이트가 아니라 킬로바이트 단위입니다.

적용할 수 있는 요소: 청크 기반 스트리밍, 높이 맵 지형, 공격적인 LOD, 내부와 외부의 분리, 그리고 멀리 있는 지형은 기하학적으로 정확할 필요 없이 시각적으로 설득력만 있으면 된다는 발상입니다.

The Witcher 3의 스트리밍 아키텍처

The Witcher 3의 136km² 월드는 콘텐츠 인식형 스트리밍을 사용합니다. 200m보다 멀리 있는 나무는 평면 임포스터입니다. 건물은 지형과 별도로 스트리밍됩니다.

The Witcher 3의 월드는 Skyrim보다 크며(모든 지역을 합쳐 약 136km²), 더 정교한 스트리밍 시스템을 사용합니다. CD Projekt RED는 엄격한 그리드가 아니라 스트리밍 섹터로 월드를 나누는 커스텀 엔진(REDengine 3)을 개발했습니다.

각 섹터에는 콘텐츠 레이어의 계층 구조가 포함됩니다.

• 지형은 4단계 LOD를 갖는 패치 단위로 스트리밍
• 식생은 거리 기반 컬링과 GPU 인스턴싱 사용
• 정적 지오메트리(건물, 바위)는 지형과 별도로 스트리밍
• 게임플레이 오브젝트(NPC, 아이템, 트리거)는 퀘스트 상태와 거리에 따라 로드

렌더러는 물리 기반 머티리얼과 디퍼드 셰이딩을 사용합니다. 특히 주목할 만한 기법은 The Witcher 3가 임포스터를 적극적으로 사용한다는 점입니다. 200미터 떨어진 나무는 가지와 잎이 달린 3D 모델이 아닙니다. 항상 카메라를 향하는 텍스처가 입혀진 평면 쿼드입니다. 엔진은 여러 각도에서 임포스터를 미리 렌더링하고, 카메라가 움직이면 이를 교체합니다. 충분히 멀리 있기 때문에 플레이어는 이를 전혀 눈치채지 못합니다.

월드 구성: The Witcher 3의 오픈 월드는 여러 팀이 동시에 작업하는 레이어 방식으로 제작되었습니다. 지형 팀은 경관을 조형했고, 환경 아트 팀은 구조물을 배치했으며, 퀘스트 팀은 트리거와 NPC 경로를 연결했습니다. 이러한 레이어 기반 구성 시스템 덕분에 대규모 팀이 서로의 작업을 방해하지 않고 협업할 수 있었습니다.

적용할 수 있는 요소: 레이어 기반 월드 구성(크리에이터 플랫폼에 필수적), 멀리 있는 오브젝트를 위한 임포스터 렌더링, 많은 광원을 처리하기 위한 디퍼드 렌더링, 그리고 스트리밍은 콘텐츠를 인식해야 한다는 원칙입니다. 즉, 볼 수 없는 내부 공간은 로드하지 않고, 근처에 있지 않은 NPC는 스폰하지 않습니다.

Breath of the Wild의 케미스트리 엔진

BotW는 태블릿급 하드웨어에서 실행되면서도 놀라운 비주얼을 보여줍니다. 셀 셰이딩 스타일, 수채화 같은 원거리 안개, 스크립트 콘텐츠보다 시스템적 상호작용을 중시합니다. 스타일라이즈드 오픈 월드의 모범 사례입니다.

Nintendo의 오픈 월드 디자인 방식은 일반적인 공식을 뒤집었습니다. 월드를 스크립트 콘텐츠로 가득 채우는 대신 시스템적 규칙을 구축하고, 플레이어가 창발적 행동을 발견하도록 했습니다. 불은 풀로 번지고, 금속은 뇌우 속에서 전기를 전도하며, 바람은 오브젝트를 운반합니다. 모든 요소는 일관된 물리 및 화학 레이어를 통해 서로 상호작용합니다.

이는 크리에이터 월드에 중요한 시사점을 줍니다. 월드 자체가 개별 배치 오브젝트보다 더 흥미로울 수 있기 때문입니다. 크리에이터가 단순히 정적 메시를 배치하는 데 그치지 않고 머티리얼 속성과 상호작용 규칙을 정의할 수 있다면, 월드는 창발적 행동을 갖게 됩니다. 그 결과 아무도 명시적으로 디자인하지 않은 지역도 탐험할 가치가 생깁니다.

BotW에서 얻을 수 있는 기술적 교훈:

• 폴리곤 수와 해상도가 비교적 낮습니다(Switch 독 모드에서 900p). 스타일라이즈드 셀 셰이딩 외관이 낮은 정밀도를 감춰 줍니다. 오늘날 브라우저 월드도 이와 비슷한 시각적 품질을 구현할 수 있습니다.
• 원거리 렌더링에는 수채화 스타일의 스카이박스로 이어지는 툰 셰이딩 안개를 사용합니다. 렌더링 비용이 낮지만 실제로는 아름답게 보입니다. 이런 대기 원근법은 프래그먼트 셰이더에서 사실상 무료로 구현할 수 있습니다.
• 월드는 약 84km²로 넓지만 밀도가 낮습니다. 맵 대부분은 횡단 가능한 지형이며, 관심 지점이 곳곳에 분산되어 있습니다. 밀도 높은 콘텐츠는 마을과 사당에 집중됩니다. 이러한 "성기지만 흥미로운" 접근 방식은 인구가 밀집한 The Witcher 3의 Novigrad와 비교해 에셋 요구량을 크게 줄입니다.
• 물리 오브젝트에는 상호작용을 결정하는 머티리얼 태그(나무, 금속, 음식, 폭발물)가 있습니다. 실제 규칙의 수는 많지 않지만(상호작용 유형 약 20~30개), 이들이 조합되면서 무한하게 느껴지는 결과를 만듭니다.

GTA V의 월드 레이어링

GTA V의 Los Santos가 살아 있는 것처럼 느껴지는 이유는 교통, 보행자, 시간대, 날씨 같은 여러 겹의 앰비언트 시스템 덕분입니다. 멀리 있는 건물은 3D 모델이 아니라 사진을 합성한 것입니다.

Rockstar의 Los Santos 접근 방식은 또 다른 교훈을 줍니다. GTA V의 월드가 살아 있는 것처럼 느껴지는 이유는 모든 NPC에게 퀘스트가 있어서가 아니라 여러 겹의 앰비언트 시스템이 있기 때문입니다.

도시에는 도로망 위에서 수백 대의 차량을 시뮬레이션하는 교통 시스템이 있습니다. 보행자는 경로를 따라 걷고, 플레이어에게 반응하며, 서로 상호작용합니다. 시간대에 따라 인구 밀도, 등장하는 NPC 유형, 주변 활동이 달라집니다. 날씨는 운전 물리와 NPC 행동에 영향을 줍니다.

크리에이터 월드에서는 앰비언트 생명감이 박물관처럼 느껴지는 월드와 실제 장소처럼 느껴지는 월드를 구분합니다. 머리 위로 날아가는 새, 해안에 밀려드는 파도, 건물 사이를 걷는 NPC처럼 단순한 행동만으로도 살아 있는 월드라는 착각을 만들어 냅니다.

GTA V에서 얻을 수 있는 기술적 교훈:

• 맵은 75km²이며, 이동 속도에 따라 로드 범위를 조절하는 스트리밍 시스템과 공격적인 LOD를 함께 사용합니다. 빠르게 운전할 때는 걸을 때보다 더 먼 전방까지 로드합니다.
• GTA Online은 이 월드에 30명의 플레이어를 동시에 배치합니다. 30명만으로도 Rockstar는 공간 기반 관심도 관리가 필요하다는 사실을 확인했습니다. 가까운 플레이어의 업데이트는 자세히 받고, 멀리 있는 플레이어의 업데이트는 더 낮은 빈도로 받습니다. 같은 원칙은 우리의 목표인 200명 규모에도 적용됩니다.
• GTA V의 에셋 파이프라인은 지금까지 만들어진 것 중 가장 효율적인 축에 속합니다. 극단적인 텍스처 압축, 메시 공유, 절차적 디테일 덕분에 전체 게임이 약 80GB에 들어갑니다. 건물 내부는 모듈식 파츠를 광범위하게 재사용합니다.
• 게임은 멀리 있는 건물을 실제로는 여러 장의 평면 사진을 합성해 보여주는 정교한 임포스터 시스템을 사용합니다. 전환 거리가 특정 시야각에 맞춰 조정되어 있기 때문에 플레이어는 이를 전혀 눈치채지 못합니다.

Elden Ring의 심리스 오픈 월드

Elden Ring의 79km² 맵은 성긴 개방형 지형과 밀도 높은 수작업 던전을 결합합니다. 같은 환경 에셋이 서로 다른 구성으로 월드 곳곳에 등장합니다. 구성과 조명이 달라지면 반복은 눈에 띄지 않습니다.

FromSoftware는 Dark Souls와 같은 엔진을 기반으로 Elden Ring을 만들었지만, 이를 오픈 월드 규모로 확장했습니다. Rockstar나 CD Projekt와 비교해 상대적으로 작은 팀이 어떻게 대규모 오픈 월드를 만들 수 있는지 보여준다는 점에서 흥미로운 결과입니다.

비결은 밀도 변화입니다. Elden Ring의 맵은 약 79km²로 거대하지만, 상당 부분은 적과 관심 지점이 드문드문 배치된 개방형 지형입니다. 밀도 높은 수작업 콘텐츠(Stormveil Castle 같은 레거시 던전)는 오픈 월드 안에 포함되어 있으며, Skyrim과 동일한 내부 및 외부 분리 방식을 사용합니다.

Elden Ring에서 얻을 수 있는 기술적 교훈:

• 월드는 큰 타일 단위로 스트리밍됩니다. 말을 타면 아주 먼 곳까지 볼 수 있지만, 원거리 지형은 극도로 단순화되어 있습니다. 가까이에서는 Dark Souls 3와 비슷한 수준의 디테일을 보여줍니다.
• 로딩 화면은 빠른 이동을 하거나 특정 던전에 들어갈 때만 나타납니다. 오픈 월드 자체는 중단 없이 스트리밍됩니다.
• 게임은 환경 에셋을 광범위하게 재사용합니다. 같은 나무 모델, 암석 지형, 폐허 파츠가 서로 다른 구성으로 맵 곳곳에 등장합니다. 배치와 조명에 충분한 변화가 있으면 반복은 눈에 띄지 않습니다. 모듈식 파츠 라이브러리로 무한한 다양성을 만들어 낼 수 있는 크리에이터 월드에 직접 적용할 수 있는 방식입니다.
• 멀티플레이어는 영구 서버 방식이 아니라 세션 기반입니다. 다른 플레이어를 자신의 월드에 소환하는 방식입니다. 하지만 메시지, 혈흔, 다른 플레이어의 환영 같은 비동기 기능은 영구 서버의 네트워킹 오버헤드 없이도 공유된 세계에 존재한다는 느낌을 만듭니다. 이러한 앰비언트 멀티플레이어 기능은 브라우저 월드에도 저렴한 비용으로 추가할 수 있습니다.

No Man's Sky: 모든 것의 절차적 생성

공유 시드로 생성되는 1,800경 개의 행성. 서버에 저장하지 않아도 모든 플레이어가 같은 우주를 봅니다. 기지 건설 데이터는 파츠 ID와 트랜스폼만으로 간결하게 표현됩니다.

No Man's Sky는 절차적 생성의 극단적인 사례입니다. 공유 시드에서 1,800경 개의 행성이 생성되므로, 서버에 어떤 행성 데이터도 저장하지 않고 모든 플레이어가 동일한 우주를 볼 수 있습니다.

생성 파이프라인은 여러 단계로 작동합니다. 은하 수준의 시드가 별의 위치를 결정하고, 별 시드가 행성의 수와 유형을 결정하며, 행성 시드는 지형 생성(다중 옥타브 노이즈), 바이옴 할당, 동식물 종, 색상 팔레트, 자원 분포를 결정합니다. 모든 요소가 시드에서 결정론적으로 계산되므로, 두 플레이어가 동일한 좌표를 방문하면 행성 데이터를 전혀 교환하지 않아도 같은 행성을 보게 됩니다. No Man's Sky에서 얻은 기술적 시사점:

• 지형 생성에는 여러 노이즈 함수를 쌓아 올린 복셀 기반 마칭 큐브 방식이 사용됩니다. 덕분에 하이트맵 지형으로는 표현할 수 없는 동굴, 돌출 지형, 공중 섬을 만들 수 있습니다. 청크당 연산 비용이 더 높다는 단점이 있지만, 그만큼 시각적으로 더 흥미로운 지형을 얻을 수 있습니다.
• 기지 건설 시스템은 우리가 구상하는 방식과 가장 가깝습니다. 플레이어는 서버에 영구 저장되고 다른 플레이어에게도 보이는 구조물을 배치합니다. 기지 데이터는 위치와 회전값을 포함한 부품 목록으로 간결하게 구성되며, 누군가 해당 행성을 방문할 때 필요에 따라 스트리밍됩니다.
• 이 게임은 무한한 다양성에도 불구하고 출시 초기에는 콘텐츠가 반복적이라는 비판을 받았습니다. 시드 기반 생성은 무한한 지형을 만들 수 있지만, 놀라움의 폭은 제한적입니다. 여기서 얻을 수 있는 교훈은 절차적 생성은 캔버스를 만드는 데 효과적이지만, 장소에 설계 의도와 목적성을 부여하는 것은 크리에이터가 배치한 콘텐츠라는 점입니다.
• Hello Games는 출시 수년 후에 멀티플레이를 추가했습니다. 최대 32명의 플레이어가 한 세션에서 함께 건설하고 탐험할 수 있습니다. 네트워크 모델은 단순합니다. 한 플레이어가 호스트하고 나머지가 연결합니다. 영구 상태를 유지하는 브라우저 월드에는 서버 권한형 모델이 더 적합하지만, No Man's Sky는 공유형 절차 생성 월드가 충분히 구현 가능하다는 것을 입증합니다.

Minecraft: 크리에이터 월드의 청사진

3억 장 판매. 16x16 픽셀 텍스처. 완전히 편집 가능한 지형. 무한 생성. 멀티플레이. 크리에이터 월드를 위한 가장 중요한 참고 사례입니다. 브라우저 클론은 이 개념이 WebGL에서도 작동한다는 것을 입증합니다.

Minecraft는 화려한 AAA 타이틀보다도 우리가 만들려는 것에 가장 중요한 참고 사례입니다. 3억 장이 판매됐습니다. 월드는 무한히 생성되고 완전히 파괴할 수 있으며 멀티플레이를 지원합니다. Minecraft에서 크리에이터는 단순히 오브젝트만 배치하지 않습니다. 지형 자체를 바꿉니다.

Minecraft에서 얻은 기술적 시사점:

• 월드는 16x16x384 블록 크기의 청크로 나뉩니다. 플레이어 주변의 청크만 로드되며 렌더링 거리는 설정할 수 있습니다. 완전히 편집 가능한 지형이라는 점을 제외하면 Skyrim과 동일한 청크 스트리밍 패턴입니다.
• 각 청크는 블록 ID의 팔레트 압축 배열로 저장됩니다. 서로 다른 블록 유형이 5개뿐인 청크는 전체 블록 ID 대신 블록당 4비트 팔레트 인덱스를 저장합니다. 덕분에 청크 데이터가 매우 작아지며, 압축 후 청크당 일반적으로 10~50KB에 불과합니다.
• Minecraft의 멀티플레이 프로토콜은 문서화가 잘되어 있고 비교적 단순합니다. 서버는 플레이어가 이동할 때 청크 데이터를 전송합니다. 블록 변경 사항은 위치와 새 블록 유형으로 구성된 작은 델타 업데이트로 브로드캐스트됩니다. 크리에이터의 편집 내용을 처리할 때 우리가 사용할 모델과 정확히 같습니다.
• 이 게임은 Java로 실행되며, 현재는 C++ 기반의 Bedrock Edition도 있습니다. 브라우저 기반 Minecraft 클론(ClassiCube, eaglercraft)은 핵심 개념이 WebGL에서 작동한다는 것을 입증합니다. 일반적으로 60fps에서 8~12청크의 렌더링 거리를 처리하며, 약 200~400미터의 시야를 제공합니다.
• Minecraft의 진정한 해자는 모딩 생태계입니다. 모드는 새로운 블록, 엔티티, 생물군계, 게임플레이 시스템을 추가합니다. 이는 크리에이터 월드에서 확장성이 기본 경험만큼 중요하다는 점을 시사합니다. 크리에이터가 오브젝트를 배치하는 데 그치지 않고 새로운 상호작용 유형을 정의할 수 있다면, 월드는 시간이 지날수록 더 풍부해집니다.
• 레드스톤(Minecraft의 게임 내 배선 시스템)은 단순하고 조합 가능한 기본 요소를 제공하면 크리에이터가 복잡한 시스템을 만든다는 사실을 보여줍니다. 논리 게이트, 자동 농장, 계산기 등이 그 예입니다. 단순한 규칙 집합에서 놀라운 복잡성이 탄생합니다. BotW의 화학 엔진과 같은 교훈입니다.

AAA 오픈 월드에서 공통으로 나타나는 패턴

이 모든 타이틀을 살펴보면 같은 패턴이 계속 나타납니다.

공간 분할은 어디서나 사용됩니다. 셀(Bethesda), 섹터(CD Projekt), 청크(Mojang/Rockstar), 타일(FromSoftware) 등 어떤 방식이든 모든 오픈 월드는 공간을 로드 가능한 단위로 나눕니다. 월드 전체를 메모리에 담으려는 엔진은 없습니다.

모든 요소의 다중 해상도화. 지형, 메시, 텍스처는 물론 오디오까지 여러 품질 단계를 가집니다. 적용되는 해상도는 플레이어와의 거리와 오브젝트의 중요도에 따라 달라집니다.

오클루전 컬링은 원시 삼각형 처리량보다 더 중요합니다. 보이지 않는 것을 렌더링하지 않으면 보이는 것을 최적화하는 것보다 더 큰 성능 향상을 얻을 수 있습니다. Skyrim은 단순한 거리 기반 시스템을 사용합니다. The Witcher 3는 건물과 절벽 같은 대형 가림막을 활용하는 소프트웨어 오클루전을 사용합니다. UE5의 Nanite 같은 최신 엔진은 하드웨어 오클루전 쿼리로 이를 한 단계 더 발전시킵니다.

비동기 로딩은 전환을 감춥니다. 이러한 게임은 빠른 이동이나 실내 전환을 제외하면 오픈 월드에서 로딩 화면을 표시하지 않습니다. 백그라운드 스레드에서 콘텐츠를 로드하고, 병렬로 압축을 해제하며, 새 콘텐츠를 점진적으로 교체합니다.

폴리곤 수보다 아트 디렉션. Skyrim은 2011년에 출시됐고 당시 기준으로도 그래픽이 뛰어난 편은 아니었습니다. BotW는 태블릿급 칩에서 실행되면서도 아름답습니다. Minecraft는 16x16 픽셀 텍스처를 사용하지만 역사상 가장 쉽게 알아볼 수 있는 게임 중 하나입니다. 브라우저 월드에서는 이 점이 매우 중요합니다. 낮은 충실도라도 방향성이 뚜렷한 아트 스타일은 기술적으로는 앞서지만 예술적으로 밋밋한 월드보다 언제나 낫습니다.

시스템 중심 설계가 스크립트형 콘텐츠를 능가합니다. BotW의 화학 엔진, Minecraft의 블록 상호작용, GTA V의 교통 시스템은 모두 단순한 규칙에서 창발적 행동을 만들어냅니다. 이는 수작업으로 만든 스크립트 시퀀스보다 제작 및 실행 비용이 저렴하면서도 더 많은 플레이어 경험담을 만들어냅니다. 크리에이터 월드에서 시스템 중심 설계란 누군가 명시적으로 디자인하지 않은 지역도 계속 흥미롭게 유지된다는 의미입니다.

크리에이터가 배치한 콘텐츠에는 영속성과 가시성이 필요합니다. Minecraft의 기지, No Man's Sky의 기지, GTA Online의 부동산은 모두 세션이 바뀌어도 유지되며 다른 플레이어에게도 보입니다. 크리에이터 콘텐츠의 데이터 모델은 항상 간결하지만(부품 ID + 트랜스폼), 시각적 표현은 풍부합니다(클라이언트가 데이터를 완전한 3D 장면으로 확장).

렌더링: 브라우저는 실제로 어디까지 할 수 있는가?

Three.js

Three.js는 기반이 되는 기술입니다. 가장 큰 커뮤니티(GitHub 스타 10만 개 이상), 가장 많은 예제, 가장 폭넓은 호환성을 갖추고 있습니다. WebGL 2를 추상화하며 WebGPURenderer를 통해 실험적인 WebGPU 지원도 제공합니다.

Three.js가 오픈 월드에 제공하는 기능은 다음과 같습니다.

• 나뭇잎, 바위, 반복 지오메트리를 위한 인스턴스 렌더링(InstancedMesh)
• 내장된 LOD 시스템(THREE.LOD가 거리에 따라 메시를 교체)
• 오브젝트별 자동 절두체 컬링
• 커스텀 BufferGeometry 또는 하이트맵 기반 PlaneGeometry를 통한 지형
• MeshStandardMaterial과 MeshPhysicalMaterial을 통한 PBR 머티리얼
• EffectComposer를 통한 포스트 프로세싱(블룸, SSAO, 톤 매핑)
• 커스텀 코드로 캐스케이드 섀도 매핑을 구현할 수 있는 섀도 맵
• 기본 에셋 형식으로 사용하는 glTF/GLB(작고 GPU에서 바로 사용 가능)

Three.js에는 오픈 월드에 중요한 도구들로 이루어진 활발한 생태계도 있습니다. three-mesh-bvh는 복잡한 메시에서 레이캐스팅과 공간 쿼리를 가속합니다. postprocessing(vanruesc 제작)은 Three.js 내장 기능보다 성능이 뛰어난 포스트 프로세싱 스택을 제공합니다. three-gpu-pathtracing은 레퍼런스급 렌더링을 지원합니다.

오픈 월드에서의 한계: Three.js에는 대규모 스트리밍, LOD 관리, 공간 분할을 처리하는 내장 씬 그래프가 없습니다. 직접 구축해야 합니다. 내장 엔티티 컴포넌트 시스템(ECS), 물리 엔진, 지형 시스템도 없습니다. 엔진이 아니라 렌더러입니다. 메모리 레이아웃과 로딩 전략을 직접 제어할 수 있으므로 커스텀 오픈 월드에는 오히려 장점이지만, 초기 작업량이 더 많다는 뜻이기도 합니다.

const lod = new THREE.LOD();
lod.addLevel(highDetailMesh, 0);
lod.addLevel(mediumDetailMesh, 50);
lod.addLevel(lowDetailMesh, 200);
lod.addLevel(impostorSprite, 500);
scene.add(lod);

Babylon.js

Babylon.js는 또 하나의 주요 후보입니다. Microsoft가 지원하며, 오픈 월드라는 구체적인 문제에 대해 Three.js보다 더 풍부한 내장 기능을 제공합니다.

관련 내장 기능:

• 대규모 장면을 효율적으로 컬링하기 위한 옥트리 기반 장면 분할
• 대규모 인스턴스 렌더링을 위한 Solid Particle System
• 내장 LOD와 다중 텍스처 스플래팅을 지원하는 하이트맵 기반 지형
• 시각적 셰이더 제작을 위한 Node Material Editor
• WebGPU 지원(Babylon이 더 일찍 투자했기 때문에 Three.js보다 성숙함)
• Havok 물리 엔진 통합(Wasm으로 컴파일된 프로덕션급 기능)
• 점진적 로딩을 지원하는 glTF 스트리밍

Babylon의 DynamicTerrain 확장 기능은 하이트맵 데이터로 지형 청크를 즉석 생성하고, LOD를 자동 처리하며, 텍스처 스플래팅을 지원합니다. 기본 상태에서 Three.js가 제공하는 어떤 기능보다 Skyrim의 방식에 훨씬 가깝습니다.

const terrain = new BABYLON.DynamicTerrain("terrain", {
  terrainSub: 100,
  mapData: heightmapData,
  mapSubX: 1000,
  mapSubZ: 1000,
}, scene);
terrain.LODLimits = [4, 3, 2, 1];

절충점: Babylon.js는 더 큰 라이브러리입니다. 전체 빌드는 최소화 기준 약 1~2MB이며, Three.js는 약 600KB입니다. 하지만 오픈 월드라면 Three.js에도 상당한 양의 커스텀 코드를 추가하게 될 가능성이 높으므로 크기 차이는 미미해집니다. Babylon에는 자체 Node Material 시스템, 인스펙터, 개발 도구도 있어 반복 작업 속도를 높여줍니다.

Babylon.js 8.0(2025년 3월 출시)은 이 프로젝트의 엔진 코어로 채택할 근거를 더욱 강화했습니다. 이제 모든 핵심 엔진 셰이더가 GLSL과 WGSL로 함께 제공되므로 변환 레이어 없이 WebGPU가 작동하며, WebGPU 번들 크기도 이전의 약 절반으로 줄었습니다. 같은 릴리스에서 Havok의 완전한 캐릭터 컨트롤러, 영역 조명, 새로 구축한 오디오 엔진, 가우시안 스플래팅 개선 사항(SPZ 및 압축 PLY 형식, 구면 조화 함수, 더 낮은 메모리 및 CPU 사용량)도 추가됐습니다.

PlayCanvas

PlayCanvas는 프로덕션에서 가장 많이 검증된 웹 우선 3D 엔진이므로 언급할 가치가 있습니다. Snap, Facebook을 비롯한 수많은 광고 고객이 이를 사용해 복잡한 3D 경험을 출시했습니다. 엔진 크기는 약 1MB이고 빠르게 로드되며, 클라우드 에디터를 통해 협업형 월드 제작이 가능합니다.

특히 오픈 월드를 위해 PlayCanvas는 드로우 콜 최적화용 배치 그룹, 내장 라이트매퍼, 가우시안 스플래팅 지원을 제공합니다. 가우시안 스플래팅은 포토그래메트리로 캡처한 현실 환경에 유용합니다. 런타임은 간결하며 모바일 브라우저에 맞게 잘 최적화되어 있습니다.

WebGPU: 성능의 잠금을 해제하다

WebGPU는 브라우저 오픈 월드의 판도를 바꿉니다. 가장 중요한 기능은 두 가지입니다.

컴퓨트 셰이더를 사용하면 GPU에서 지형 생성, 식생 배치, 파티클 시뮬레이션은 물론 간단한 물리 연산까지 처리할 수 있습니다. WebGL 월드에서는 이 모든 작업이 JavaScript를 통해 CPU에서 실행됩니다. WebGPU를 사용하면 지형 패치를 GPU에서 완전히 생성하고, LOD 전환을 GPU에서 계산하며, 컬링 패스를 GPU에서 실행할 수 있습니다. 그 결과 CPU를 네트워킹, 게임 로직, 콘텐츠 스트리밍에 사용할 수 있습니다.

간접 렌더링을 사용하면 컴퓨트 셰이더 출력에 따라 GPU가 무엇을 그릴지 결정할 수 있습니다. 하나의 드로우 콜을 제출하면 GPU가 거리에 따라 각 LOD 단계에서 렌더링할 인스턴스 수를 결정합니다. 최신 엔진은 이 방식으로 수백만 개의 풀잎이나 나무를 처리합니다. WebGL이 지원하지 않는 간접 렌더링이 없으면 CPU가 모든 요소를 정렬하고 배칭해야 하므로 밀집된 장면에서는 병목이 됩니다.

이제 WebGPU는 모든 주요 브라우저에 탑재되어 있습니다. Chrome과 Edge는 버전 113부터 지원했고, Firefox는 Windows(141)와 Apple Silicon macOS(145)에서 지원을 추가했으며, Safari 26은 2025년 말 macOS, iOS, iPadOS, visionOS에 WebGPU를 도입했습니다. 그 결과 모바일을 포함한 전 세계 지원률이 약 82%에 달합니다. Android용 Chrome과 Samsung Internet도 지원합니다. WebGPU가 활성화되지 않은 구형 브라우저와 기기를 위해 WebGL 2 폴백을 유지해야 하지만, 격차는 빠르게 줄었습니다.

@compute @workgroup_size(64)
fn generateTerrain(@builtin(global_invocation_id) id: vec3<u32>) {
    let worldPos = vec2<f32>(f32(id.x), f32(id.y)) * cellSize + worldOffset;
    let height = fbmNoise(worldPos, octaves, persistence);
    heightmap[id.x + id.y * width] = height;
}

권장 렌더링 스택

데스크톱 크리에이터를 대상으로 하는 브라우저 오픈 월드의 권장 구성은 다음과 같습니다.

기본 구성: 지원되는 환경에서는 WebGPU 렌더러를 사용하는 Three.js 또는 Babylon.js를 채택하고 WebGL 2 폴백을 제공합니다. Babylon은 오픈 월드용 내장 기본 요소가 더 강력합니다. Three.js는 더 큰 커뮤니티와 높은 유연성을 갖추고 있습니다.

우리의 선택: 내장 지형 LOD, 옥트리 컬링, Havok 물리 엔진(Wasm), 성숙한 WebGPU 지원을 갖춘 Babylon.js를 엔진 코어로 선택합니다. Babylon에 없는 기능에는 Three.js 생태계의 도구를 사용합니다(예: 공간 쿼리용 메시 BVH). 전체를 커스텀 월드 스트리밍 레이어로 감쌉니다.

월드 스트리밍 아키텍처

이 부분이 가장 어렵습니다. 브라우저 탭이 사용할 수 있는 메모리는 데스크톱에서 약 2~4GB(브라우저가 적용하는 제한), 모바일에서는 약 1GB이며 디스크에 직접 접근할 수 없습니다. 모든 데이터는 네트워크를 통해 받아야 합니다. 플레이어가 이동할 방향의 콘텐츠를 미리 스트리밍하면서 보이는 월드를 메모리에 유지하는 아키텍처가 필요합니다.

청크 기반 월드 그리드

Skyrim의 셀 시스템처럼 월드를 규칙적인 청크 그리드로 나눕니다. 각 청크는 독립적으로 로드하고 렌더링하며 언로드할 수 있는 단위입니다.

청크 크기가 중요합니다. 너무 작으면 높은 오버헤드를 감수하며 끊임없이 로드하고 언로드해야 합니다. 너무 크면 각 청크를 다운로드하는 데 지나치게 오래 걸립니다. 일반적인 광대역 연결을 사용하는 브라우저 월드라면 다음 구성이 적합합니다.

• 지면 기준 64x64미터 청크
• 각 청크의 구성: 하이트맵 패치(2~4KB), 텍스처 스플랫 맵(압축 후 16~32KB), 인스턴스 참조 형태의 정적 메시(인스턴스 데이터 1~50KB), 매니페스트 형태의 크리에이터 배치 오브젝트(1~10KB)
• 로드 반경: 최고 디테일은 5x5청크(320m 시야), 중간 LOD는 9x9, 지형만 표시하는 범위는 17x17
• 목표: 각 청크의 최고 디테일 데이터를 200KB 미만으로 유지해 5x5 인접 영역 전체를 5MB 미만으로 구성

점진적 로딩 파이프라인

청크의 모든 데이터를 한꺼번에 로드하지 마세요. 우선순위 큐를 사용합니다:

1. 지형 지오메트리 우선(높이맵만 사용, 청크당 2~4KB). 플레이어는 100ms 이내에 지면을 볼 수 있습니다.
2. 지형 텍스처(스플랫 맵, 저해상도를 먼저 불러온 후 업그레이드). 지면에 200ms 이내로 색상이 입혀집니다.
3. 주요 구조물(건물, 큰 바위). 500ms 이내에 실루엣이 나타납니다.
4. 세부 오브젝트(식생, 작은 소품, 크리에이터 아이템). 1~2초에 걸쳐 월드가 채워집니다.
5. 고해상도 텍스처는 마지막에 업그레이드합니다. 멀리 있는 건물의 텍스처가 1초 늦게 표시되어도 아무도 알아차리지 못합니다.

이는 인간의 시각이 작동하는 방식과 일치합니다. 지면이나 대형 구조물이 없으면 알아차리지만, 풀이 없는 것은 잘 알아차리지 못합니다.

메모리 관리

브라우저 메모리는 유한하며, 가비지 컬렉터는 적입니다. 단 한 번의 GC 일시 중지로도 한 프레임 동안 60fps가 10fps로 떨어질 수 있습니다.

오브젝트 풀링은 필수입니다. 흔히 사용하는 오브젝트(나무, 바위, 풀 패치)의 풀을 미리 할당하고, 청크가 로드되거나 언로드될 때 이를 재활용하세요. 핫 패스에서는 절대 새로운 THREE.Mesh 또는 BABYLON.Mesh 인스턴스를 생성하지 마세요. 대신 풀링된 오브젝트의 지오메트리와 머티리얼 참조를 교체하세요.

텍스처 아틀라스는 드로우 콜과 메모리 파편화를 모두 줄여 줍니다. 모든 지형 텍스처를 몇 개의 대형 아틀라스에 패킹하세요. 크리에이터가 업로드한 텍스처는 서버에서 청크별 아틀라스로 패킹한 후 단일 이미지로 스트리밍하세요.

Draco 또는 Meshopt를 이용한 지오메트리 압축은 다운로드 크기를 5~10배 줄이며, 압축 해제는 Web Worker에서 실행되므로 메인 스레드를 차단하지 않습니다. 특히 지형에는 양자화된 높이맵(단순 델타 인코딩으로 압축된 16비트 값)이 범용 메시 형식보다 더 작습니다. 저희 GLB 최적화 도구는 브라우저에서 동일한 Meshopt 패스를 적용하므로 자신의 에셋으로 절감 효과를 먼저 측정해 볼 수 있습니다.

워커와 메인 스레드 간의 ArrayBuffer 소유권 이전을 사용하면 복사를 피할 수 있습니다. 워커가 메시의 압축을 해제하면 전송 가능한 객체와 함께 postMessage를 사용해 버퍼를 복사 없이 메인 스레드로 전송하세요.

에셋 전송

정적 월드 데이터에는 엣지 캐싱을 지원하는 CDN을 사용하세요. 자주 변경되지 않는 지형 청크, 기본 메시, 텍스처 아틀라스는 적극적으로 캐싱해야 합니다(Cache-Control: max-age=31536000, immutable).

콘텐츠 주소 지정 스토리지에서는 각 에셋 버전의 URL에 고유한 해시가 부여됩니다. 크리에이터가 청크를 수정하면 새 버전에는 새 해시가 부여되고, 이전 버전은 여전히 이를 보고 있는 사용자를 위해 캐시에 남습니다. 캐시 무효화가 필요하지 않습니다.

Basis Universal 압축을 사용하는 KTX2 텍스처를 활용하세요. 이는 기기에서 지원하는 GPU 형식(BC7, ASTC, ETC2 또는 RGBA 폴백)으로 압축 해제됩니다. 1024x1024 지형 텍스처의 용량은 압축하지 않았을 때 4MB에서 KTX2 사용 시 약 150KB로 줄어듭니다. 수천 개의 고유한 텍스처가 있는 월드에서는 이 압축이 실현 가능성을 좌우합니다.

모든 3D 에셋에는 **glTF Binary(GLB)**를 사용하세요. GLB는 3D 분야의 JPEG와 같습니다. 모든 브라우저 엔진에서 로드할 수 있고 크기가 작으며, 텍스처, 머티리얼, 애니메이션을 단일 파일에 포함할 수 있습니다. 메시 압축에는 Draco 또는 Meshopt 확장을 사용하세요. 크리에이터가 업로드한 에셋은 월드에 추가되기 전에 서버에서 최적화된 GLB로 처리됩니다.

멀티플레이어 네트워킹

수백 명의 크리에이터가 같은 월드에 참여하려면 실시간 이동, 영구적인 월드 상태, 크리에이터의 편집 작업을 과부하 없이 처리하는 네트워킹 아키텍처가 필요합니다.

서버 아키텍처

월드 상태에는 권한 서버를 사용합니다. 브라우저는 신뢰할 수 없습니다. 모든 중요한 작업(오브젝트 배치, 지형 수정, 청크 간 이동)은 서버 측에서 검증됩니다. 클라이언트는 로컬에서 결과를 예측하고 서버 상태와 조정합니다.

공간 샤딩은 월드를 여러 서버 인스턴스에 분할합니다. 각 샤드는 월드 그리드의 직사각형 영역을 담당합니다. 플레이어 밀도가 변하면 샤드를 분할하거나 병합할 수 있습니다. EVE Online이 하나의 우주에서 수천 명의 플레이어를 처리하는 방식이며, 더 작은 규모에서도 동일한 원리가 적용됩니다.

대부분의 상호작용이 로컬에서 이루어지는 크리에이터 월드(자신의 영역에서 제작하고 이웃이 그 결과를 볼 수 있는 경우)에는 공간 샤딩이 자연스럽게 작동합니다. 샤드 경계에 서 있는 플레이어는 양쪽 샤드의 콘텐츠를 모두 보게 되므로 샤드 간 가시성 쿼리가 필요하지만, 이는 이미 해결된 문제입니다.

서버 기술 옵션:

기술	장점	사용 사례
Cloudflare Durable Objects	엣지 배포, 자동 확장, 내장 영속성, WebSocket 지원	월드 샤드 상태, 청크별 권한 관리
Hathora / Rivet	관리형 게임 서버 호스팅, DDoS 방어, 글로벌 배포	전용 게임 서버 인스턴스
Colyseus	Node.js용 오픈 소스 게임 서버 프레임워크, 스키마 기반 상태 동기화	상태 차이 동기화를 사용하는 룸 기반 멀티플레이어
PartyKit	엣지 배포, WebSocket + WebRTC, Cloudflare Workers 기반	실시간 협업, 경량 멀티플레이어
Custom Rust/Go	최대 수준의 제어, 인스턴스당 최고의 성능	저지연 물리 처리가 필요한 고밀도 샤드

현재 환경(Cloudflare 인프라): Durable Objects가 자연스러운 선택입니다. 각 월드 청크는 해당 청크 콘텐츠의 권한 상태를 보유하는 Durable Object가 됩니다. 플레이어는 WebSocket을 통해 현재 청크를 담당하는 Durable Object에 연결합니다. 인접한 청크로 이동하면 해당 청크의 DO에 연결합니다. Durable Objects는 상태를 디스크에 자동으로 영속화하므로 서버가 재시작되어도 월드 데이터가 유지됩니다.

클라이언트-서버 통신

신뢰할 수 있고 순서가 보장된 메시지(채팅, 월드 편집, 인벤토리, 게임 상태)에는 WebSocket을 사용합니다. 플레이어가 볼 수 있는 활성 샤드마다 하나의 연결을 사용합니다(일반적으로 1~4개 연결).

신뢰성이 보장되지 않고 순서가 중요하지 않은 메시지(플레이어 위치, 애니메이션, 일시적 효과)에는 WebRTC DataChannel을 사용합니다. WebRTC는 P2P 통신이 가능하지만, 플레이어가 많은 월드에서는 N2 연결을 방지하기 위해 SFU(Selective Forwarding Unit)를 통해 통신해야 합니다. Cloudflare Calls 또는 LiveKit을 SFU로 사용할 수 있습니다.

상태 동기화에는 델타 압축을 사용합니다. 서버는 각 클라이언트가 확인한 상태를 추적하고 변경 사항만 전송합니다. 이는 크리에이터 월드에서 특히 중요합니다. 월드 상태(존재하는 오브젝트, 위치, 속성)는 플레이어 위치보다 훨씬 덜 자주 변경되기 때문입니다. 플레이어 위치는 20~30Hz로 업데이트하면서 월드 상태 업데이트는 2~5Hz로 전송해도 충분합니다.

interface WorldChunkState {
  version: number;
  terrain: TerrainPatch;
  objects: PlacedObject[];
  creators: CreatorPresence[];
}

interface DeltaUpdate {
  chunkId: string;
  fromVersion: number;
  toVersion: number;
  addedObjects: PlacedObject[];
  removedObjectIds: string[];
  modifiedObjects: Partial<PlacedObject>[];
  creatorMoves: CreatorPosition[];
}

크리에이터 편집의 충돌 해결

두 명의 크리에이터가 같은 영역을 동시에 수정한다면 충돌 해결 전략이 필요합니다. 이때 어떤 실시간 협업 모델을 선택하는지가 중요합니다.

마지막 쓰기 우선(Last-write-wins) 방식이 가장 단순합니다. 각 오브젝트에는 언제나 한 명의 소유자만 존재합니다. 누군가 건물을 편집하고 있다면 편집 권한을 해제할 때까지 다른 사람은 편집할 수 없습니다. 단순하고 충돌이 없지만 협업이 제한됩니다.

**운영 변환(Operational Transform, OT)**은 Google Docs에서 사용하는 방식입니다. 작업을 동시에 수행된 다른 작업에 맞춰 변환하여 일관된 결과를 만듭니다. 텍스트에는 잘 작동하지만 3D 공간 작업에서는 복잡해집니다. Figma는 2D 캔버스에 이 방식의 변형을 사용합니다.

**CRDT(Conflict-free Replicated Data Types)**는 조정 없이 동시에 수행된 편집이 항상 동일한 상태로 수렴하게 합니다. 개별 오브젝트마다 ID와 속성이 있는 월드에서는 각 속성에 Last-Writer-Wins Register를 사용하고 오브젝트 컬렉션에 Add-Wins Set을 결합하면 자동으로 수렴할 수 있습니다. Yjs와 Automerge는 JavaScript에서 프로덕션 용도로 사용할 수 있는 CRDT 라이브러리입니다.

권장 방식: 월드 오브젝트 상태(무엇이 존재하고, 어디에 있으며, 어떤 속성을 갖는지)에는 CRDT를 사용하고, 공간 검증(두 오브젝트가 같은 위치를 차지하지 않는지, 오브젝트가 월드 경계 안에 있는지)에는 권한 서버를 사용하세요. CRDT는 협업을 처리하고 서버는 물리 처리를 담당합니다.

확장성 처리: 플레이어는 몇 명까지 가능한가?

브라우저 MMO는 이미 존재합니다. Hordes.io는 브라우저의 단일 장면에서 200명 이상의 플레이어를 실행합니다. Mozilla의 실험작인 BrowserQuest는 단순한 타일 기반 월드로 수백 명을 처리했습니다. 중요한 질문은 브라우저가 멀티플레이어를 처리할 수 있는지가 아니라, 플레이어 수가 증가할 때 어느 수준의 시각적 품질을 유지할 수 있는지입니다.

플레이어 렌더링 예산: 화면에 보이는 각 플레이어에는 메시, 애니메이션, 그리고 경우에 따라 크리에이터가 커스터마이징한 외형이 필요합니다. 60fps에서는 프레임당 16ms가 주어집니다. 합리적인 예산은 다음과 같습니다.

• 근거리에서 완전한 애니메이션이 적용된 플레이어 50명: 애니메이션 + 스키닝에 약 2ms
• 중거리에서 플레이어 200명(단순화된 애니메이션, 인스턴싱): 약 1ms
• 미니맵에서 점/아이콘으로 표시되는 플레이어 500명 이상: 무시할 수 있는 수준

따라서 한 화면에 약 250명의 플레이어를 표시할 수 있으며, 이는 크리에이터 월드에 충분하고도 남습니다. World of Warcraft의 대도시에서도 한 번에 200명 이상의 캐릭터를 렌더링하는 경우는 드뭅니다.

네트워크 예산: 각 플레이어가 20Hz로 위치를 전송할 때 대략 40바이트 * 20 = 초당 800바이트가 필요합니다. 화면에 플레이어 200명이 있다면 위치 데이터만 초당 160KB입니다. 월드 상태, 채팅, 크리에이터 작업을 더하면 클라이언트당 초당 200~500KB가 필요합니다. 광대역 연결로 충분히 처리할 수 있는 수준이지만 압축할 가치는 있습니다.

지형 시스템

지형은 모든 오픈 월드의 기반입니다. 또한 지형은 어디에나 존재하고 항상 보여야 하므로 브라우저의 제약이 가장 크게 드러나는 부분이기도 합니다.

높이맵 기반 지형

Skyrim처럼 높이맵을 사용하세요. 높이 값으로 구성된 2D 그리드가 버텍스 셰이더를 통해 3D 지형을 생성합니다. 이는 임의의 메시 지형보다 훨씬 더 효율적입니다.

16비트 정밀도의 4096x4096 높이맵은 압축하지 않았을 때 32MB입니다. 하지만 전체를 한 번에 로드할 필요는 없습니다. 각 64m 청크는 높이맵의 65x65 영역을 사용합니다(16비트 기준 약 8.4KB). 이를 델타 인코딩과 zlib으로 압축하면 청크당 2KB 미만으로 줄어듭니다.

텍스처 스플래팅은 블렌드 맵을 사용해 여러 지형 머티리얼(풀, 바위, 흙, 모래)을 칠합니다. 각 청크에는 4채널 RGBA 스플랫 맵이 있으며, 각 채널은 하나의 머티리얼에 대한 블렌드 가중치를 제어합니다. 스플랫 맵마다 4개의 텍스처를 사용하고 청크별로 스플랫 맵을 다르게 구성할 수 있으므로 월드 전체에 시각적 다양성을 줄 수 있습니다.

최신 지형 렌더러는 가상 텍스처링(id Software가 Rage에서 사용한 기술에서 유래한 메가텍스처라고도 함)을 사용합니다. 런타임에 스플래팅하는 대신 블렌딩된 지형 텍스처를 고해상도로 미리 렌더링하고, 카메라 이동에 따라 타일을 스트리밍합니다. 이는 저장 공간을 늘리는 대신 런타임 성능을 높이는 방식입니다. WebGPU의 컴퓨트 셰이더는 가상 텍스처링에 필요한 피드백과 페이지 테이블 관리를 처리할 수 있습니다.

클립맵 또는 지오클립매핑

브라우저에서 대규모 지형을 렌더링하려면 CDLOD(C. Dick's LOD) 또는 지오클립매핑 방식이 적합합니다. 지형은 카메라를 둘러싼 여러 개의 동심원 링으로 렌더링되며, 각 링의 해상도는 이전 링의 절반입니다. 카메라에 가까운 곳에서는 최고 해상도의 지형을 볼 수 있고, 멀리서는 더 거친 버전이 표시됩니다. 지오메트리가 레벨 사이에서 모핑되므로 전환이 부드럽습니다.

이 기술은 GPU 친화적이고(링당 드로우 콜 1회), 일정한 메모리로 무한한 지형을 처리하며, WebGL 2에서도 작동합니다. Flight Simulator와 대부분의 최신 오픈 월드 게임이 어떤 형태로든 사용하는 방식입니다.

크리에이터가 수정할 수 있는 지형

크리에이터가 지형을 조형할 수 있다면 기본 높이맵 위에 수정 사항을 저장하고 스트리밍하는 방법이 필요합니다. 두 가지 접근 방식이 있습니다.

델타 높이맵은 기본 지형과 수정된 지형의 차이를 저장합니다. 월드의 대부분은 수정되지 않으므로 델타 값은 0이며, 그 결과 압축 효율이 매우 높습니다. 청크를 로드할 때 기본 지형 위에 델타를 적용합니다.

더 극적인 수정(동굴, 돌출부, 아치)에는 복셀 오버레이를 사용합니다. 높이맵은 하나의 지점에 두 개의 높이가 있는 지형을 표현할 수 없습니다. 수정된 청크에만 저장되는 희소 복셀 그리드로 이를 처리할 수 있습니다. Marching Cubes 또는 Dual Contouring으로 메시를 생성합니다. 비용이 더 많이 들지만 Minecraft 스타일의 지형 편집이 가능합니다.

AI 기반 월드 생성

이 영역에서 Cinevva의 기존 생성형 AI 기능은 강력한 시너지를 발휘합니다. 크리에이터는 모든 바위와 나무를 직접 만드는 대신 AI에 월드 배치를 지시할 수 있습니다.

신경장을 활용한 지형 생성

신경망 지형 생성에 관한 최근 연구(NVIDIA의 GET3D, Terragen의 신경망 모드, “Terrain Generation Using Procedural Models” 같은 논문)는 학습된 모델이 텍스트 프롬프트나 스케치 입력으로 그럴듯한 지형을 생성할 수 있음을 보여 줍니다. 크리에이터가 대략적인 해안선을 그리고 “바위 해안과 맞닿은 숲이 우거진 언덕”이라고 입력하면 적절한 침식 지형, 식생 마스크, 머티리얼 할당이 포함된 높이맵을 얻을 수 있습니다.

브라우저로 전송할 때는 서버 측에서 생성을 실행하고 결과를 스트리밍하면 됩니다. 생성 모델을 브라우저에서 실행할 필요는 없습니다. 모델이 생성한 높이맵과 스플랫 맵은 브라우저의 표준 지형 파이프라인으로 렌더링할 수 있습니다.

3D 에셋 생성

Hunyuan3D, Meshy, Tripo, Rodin 같은 모델은 텍스트나 이미지에서 3D 메시를 생성할 수 있습니다. 크리에이터 월드의 작업 흐름은 다음과 같습니다.

1. 크리에이터가 원하는 것을 설명하거나 스케치합니다(“이끼 낀 석조 아치” 또는 “미래적인 가로등”).
2. 서버가 생성 모델을 실행하여 하이 폴리 메시를 만듭니다.
3. 서버가 자동으로 후처리합니다. 웹에 적합한 폴리곤 수로 단순화하고, LOD를 생성하며, 텍스처를 아틀라스에 베이크한 후 Draco 압축을 적용한 GLB로 내보냅니다.
4. 에셋이 크리에이터의 인벤토리에 나타나며, 즉시 월드에 배치할 수 있습니다.

이 파이프라인을 구성하는 기능들은 이미 Cinevva에 부분적으로 존재합니다. 아직 필요한 부분은 LOD/최적화 단계와 월드 배치 시스템입니다.

절차적 배치

AI로 생성한 에셋이 있더라도 숲의 모든 나무를 직접 배치하는 작업은 번거롭습니다. 절차적 분산 배치 규칙을 사용하면 크리에이터가 구역을 정의하고(“이 영역은 울창한 숲”, “이 경사면은 바위가 많은 너덜지대”) 시스템이 자동으로 오브젝트를 배치할 수 있습니다.

GPU 컴퓨트 셰이더는 브라우저에서 분산 배치를 실행할 수 있습니다. 밀도 맵과 규칙 집합(최소 간격, 경사 제약, 높이 범위)이 주어지면 한 번의 컴퓨트 패스로 전체 청크의 인스턴스 위치를 1ms 이내에 생성할 수 있습니다. 밀도 맵을 수정하면 식생이 즉시 다시 생성됩니다.

엔티티 컴포넌트 시스템(ECS)

수천 개의 오브젝트가 존재하는 오픈 월드에는 효율적인 엔티티 관리 시스템이 필요합니다. ECS 패턴은 Unity의 DOTS와 Bevy 이후 게임 엔진에서 널리 사용되고 있으며 JavaScript에도 잘 맞습니다.

bitECS는 형식화 배열과 비트 연산을 사용하는 고성능 JavaScript용 ECS입니다. 엔티티는 단순한 정수입니다. 컴포넌트는 연속된 형식화 배열이며, 컴포넌트 유형마다 하나씩 존재합니다. 시스템은 배열을 순차적으로 순회하므로 JavaScript에서도 캐시 효율이 좋습니다.

import { createWorld, defineComponent, Types, defineQuery, addEntity, addComponent } from 'bitecs';

const Position = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const Velocity = defineComponent({ x: Types.f32, y: Types.f32, z: Types.f32 });
const ChunkRef = defineComponent({ chunkX: Types.i16, chunkZ: Types.i16 });

const world = createWorld();
const movingQuery = defineQuery([Position, Velocity]);

function movementSystem(world) {
  const entities = movingQuery(world);
  for (let i = 0; i < entities.length; i++) {
    const eid = entities[i];
    Position.x[eid] += Velocity.x[eid] * dt;
    Position.y[eid] += Velocity.y[eid] * dt;
    Position.z[eid] += Velocity.z[eid] * dt;
  }
  return world;
}

오픈 월드에서 ECS는 플레이어 캐릭터, 배치된 오브젝트, NPC, 파티클, 트리거, 월드 소품 등 모든 것을 처리합니다. 청크가 언로드되면 해당 엔티티가 ECS에서 제거됩니다. 청크가 로드되면 엔티티가 추가됩니다. ECS는 공간 구성에 관여하지 않고 컴포넌트만 처리합니다.

물리

WebAssembly 덕분에 브라우저 물리 엔진의 수준은 놀라울 만큼 향상되었습니다.

Rapier(Rust -> Wasm)

Rapier는 Rust로 작성되어 WebAssembly로 컴파일되는 물리 엔진입니다. 강체, 콜라이더, 조인트, 캐릭터 컨트롤러, 레이캐스팅을 처리합니다. 일반적인 게임 워크로드에서 성능은 네이티브 Bullet/PhysX 대비 2~3배 이내입니다.

오픈 월드에서 Rapier는 다음을 처리합니다.

• 플레이어 캐릭터 컨트롤러(지형 위 걷기, 계단 오르기, 경사면에서 미끄러지기)
• 오브젝트 간 충돌(배치된 오브젝트, 발사체)
• 플레이어 상호작용을 위한 레이캐스팅(오브젝트를 클릭해 선택)
• 트리거 볼륨(영역에 진입하면 이벤트 발생)

Rapier는 Web Worker에서 실행되므로 물리 시뮬레이션이 렌더링을 차단하지 않습니다. 매 프레임 위치를 렌더러에 보내고 입력 이벤트를 돌려받습니다.

웹용 Havok(Babylon.js 경유)

Babylon.js를 선택하면 Havok 물리 엔진이 Wasm 모듈로 기본 제공됩니다. Havok은 대부분의 AAA 게임(Half-Life 2, Skyrim, Breath of the Wild)에 사용된 물리 엔진입니다. Wasm 빌드는 프로덕션 품질이며 Babylon의 씬 그래프에 최적화되어 있습니다.

지형 충돌

물리 엔진에는 지형의 충돌 지오메트리가 필요합니다. 보이는 지형 전체에 대해 최대 해상도의 트라이메시를 생성하면 비용이 많이 듭니다. 대신 플레이어 주변 청크, 즉 가장 가까운 3x3 또는 5x5 청크에만 충돌 높이 필드를 생성하고 나머지에는 단순화된 충돌을 사용하세요. Rapier의 높이 필드 콜라이더는 바로 이러한 용도로 설계되었습니다.

오디오

사운드는 3D 공간을 시각적 데모에서 실제 장소처럼 느껴지는 공간으로 바꿉니다. Web Audio API는 브라우저 공간 음향에 필요한 모든 기능을 제공합니다.

HRTF(머리전달함수)를 사용하는 공간 음향은 사운드를 3D 공간에 배치합니다. 왼쪽에 있는 폭포 소리는 실제로 왼쪽에서 들리는 것처럼 느껴집니다. 가까이 다가가면 더 커지고, 건물 뒤로 이동하면 추가 처리를 통해 소리가 먹먹해집니다.

환경음 구역은 오디오용 텍스처 스플래팅처럼 작동합니다. 숲, 동굴, 해안, 도시 등의 구역을 정의하고 플레이어가 그 사이를 이동할 때 주변 사운드스케이프를 크로스페이드합니다. Skyrim이 숲을 살아 있는 것처럼 들리게 만드는 방식입니다. 바람, 새, 나뭇잎이 바스락거리는 소리, 멀리 있는 동물 소리를 여러 층으로 쌓습니다. 각각은 복잡하지 않지만 모두 공간성을 가집니다.

Web Audio 성능은 수십 개의 공간 음원을 동시에 재생하기에 충분합니다. 일반적으로 병목은 처리 성능이 아니라 에셋 크기입니다. 압축 오디오에는 Opus 또는 AAC를 사용하고, 긴 환경음 트랙은 스트리밍하며, 짧은 효과음(발소리, 상호작용음)은 미리 로드하세요.

물, 날씨, 대기

기억에 남는 모든 오픈 월드에는 물과 날씨가 있습니다. 이러한 시스템은 분위기를 결정하고 월드에 생동감을 더합니다. 놀랍게도 브라우저에서도 충분히 구현할 수 있습니다.

물 렌더링

브라우저 3D에서 물은 세 단계의 복잡도로 구현할 수 있으며, 가장 단순한 단계부터 출시한 뒤 나중에 업그레이드할 수 있습니다.

레벨 1: 반사 평면. 수면 높이에 반사 및 굴절 머티리얼을 적용한 평면 메시를 놓습니다. 장면을 뒤집어 텍스처에 렌더링하고(평면 반사), 파란색 색조와 혼합한 뒤, 스크롤하는 노멀 맵으로 파도의 움직임을 표현합니다. Skyrim의 기본 물 셰이더가 사용하는 방식입니다. Three.js에서는 공식 저장소의 Water 예제가 이를 구현합니다. Babylon.js에서는 WaterMaterial이 이 기능을 기본 제공합니다. 비용은 반사용 렌더 패스 1회 추가(절반 해상도로도 충분)와 수면 드로우입니다. 중급 GPU에서는 프레임당 2~3ms가 추가됩니다.

레벨 2: 스크린 공간 반사 + 깊이 기반 효과. 별도의 반사 렌더 패스 대신 기존 프레임 버퍼를 샘플링해 반사(SSR)를 만듭니다. 깊이에 따른 색 흡수 효과(물이 깊을수록 어두워짐), 깊이 비교를 이용한 해안선 거품, 수중 지형에 투영되는 코스틱을 추가합니다. The Witcher 3에서 사용하는 방식입니다. SSR은 Three.js의 포스트 프로세싱 스택과 Babylon.js의 렌더링 파이프라인 모두에서 사용할 수 있습니다. 비용은 SSR에 1~2ms이며 깊이 효과의 비용은 미미합니다.

레벨 3: FFT 해양 시뮬레이션. 외해에는 고속 푸리에 변환을 사용해 GPU에서 파랑 스펙트럼을 시뮬레이션합니다. Jerry Tessendorf의 논문 "Simulating Ocean Water"(2001)는 모든 주요 게임 엔진이 사용하는 기반 기술입니다. FFT는 WebGPU의 컴퓨트 셰이더로 실행되며, 매 프레임 디스플레이스먼트 맵과 노멀 맵을 생성합니다. 결과로 만들어지는 바다는 놀라울 정도로 사실적입니다. Sea of Thieves, Assassin's Creed Black Flag, Uncharted 4에서 사용하는 방식입니다. WebGPU에서 256x256 FFT 해양은 데스크톱 GPU에서 1ms 이내에 실행됩니다.

@compute @workgroup_size(16, 16)
fn fftOceanDisplacement(@builtin(global_invocation_id) id: vec3<u32>) {
    let k = vec2<f32>(f32(id.x) - N/2.0, f32(id.y) - N/2.0);
    let omega = sqrt(length(k) * gravity);
    let phase = omega * time;
    let h = spectrum[id.xy] * vec2<f32>(cos(phase), sin(phase));
    displacement[id.xy] = h;
}

크리에이터 월드에서는 레벨 1(반사 평면)로 시작하고 렌더러가 성숙하면 레벨 2로 업그레이드하세요. 월드에 외해가 있는 경우에만 레벨 3이 필요합니다.

날씨 시스템

Skyrim과 BotW의 날씨는 전환 기능이 있는 상태 머신으로 구동됩니다. 맑음 > 흐림 > 비 > 폭풍 > 맑음 순입니다. 각 상태는 스카이박스, 안개 밀도, 주변광 색상, 파티클 효과(비/눈), 오디오(바람, 비), 게임플레이 속성(BotW에서는 젖은 표면이 미끄러움) 등 여러 시스템을 동시에 변경합니다.

브라우저 월드의 날씨 시스템은 세 계층으로 구성됩니다.

하늘 렌더링. 절차적 하늘 셰이더는 스카이박스 텍스처보다 저렴하고 유연합니다. Preetham 또는 Hosek-Wilkie 하늘 모델은 태양 위치만으로 물리적으로 타당한 하늘색을 계산합니다. 평면을 따라 스크롤하는 3D 노이즈로 구름 레이어를 추가하세요. Babylon.js에는 절차적 하늘 머티리얼이 내장되어 있습니다. Three.js에는 Sky 예제가 있습니다. 둘 다 GPU 비용이 거의 들지 않으면서도 설득력 있는 결과를 만듭니다. 단일 전체 화면 쿼드만 사용하기 때문입니다.

파티클 효과. 비는 위에서 떨어지는 수천 개의 얇은 쿼드로 구성된 파티클 시스템입니다. 눈도 비슷하지만 더 느리고 흩날리는 궤적을 가집니다. 안개는 깊이에 따라 장면을 안개색과 혼합하는 포스트 프로세싱 패스입니다. 모두 표준 WebGL 효과입니다. 비용은 파티클 수에 따라 달라지며, 빗방울 파티클 10,000개는 프레임당 약 0.5ms를 추가합니다.

환경 반응. 젖은 표면은 정반사율이 증가합니다. 눈이 쌓이면 위쪽을 향한 표면에 흰색이 더해집니다. 오목한 지형에는 웅덩이가 생깁니다. 이는 지오메트리 변경이 아니라 셰이더 기법입니다. "wetness" 유니폼은 머티리얼의 거칠기를 변경합니다. "snow cover" 유니폼은 노멀이 위쪽을 향하는 표면에 흰색을 혼합합니다. GTA V와 The Witcher 3도 정확히 이 방식을 사용합니다.

동기화된 날씨. 멀티플레이어 월드에서는 모든 클라이언트의 날씨가 일치해야 합니다. 가장 간단한 방법은 서버가 전환 진행도를 포함한 날씨 상태를 1Hz로 브로드캐스트하는 것입니다. 클라이언트는 로컬에서 보간합니다. 날씨는 천천히 변하므로(맑음에서 비로 전환하는 데 30~60초 소요) 업데이트가 지연되어도 부드럽게 보입니다.

대기 원근법

월드를 광활하게 느끼게 만드는 가장 효과적인 시각 기법이며, 비용도 거의 들지 않습니다. 대기의 광산란 때문에 멀리 있는 오브젝트는 더 흐리고 푸르며 대비가 낮게 보입니다. 모든 오픈 월드가 이 기법을 사용합니다.

프래그먼트 셰이더에서 깊이에 따라 멀리 있는 픽셀을 대기색과 혼합합니다.

float fogFactor = 1.0 - exp(-distance * fogDensity);
vec3 finalColor = mix(objectColor, atmosphereColor, fogFactor);

BotW는 이를 더 발전시켜 수채화풍의 원경으로 전환되는 회화적인 안개를 사용합니다. 안개색은 시간대와 날씨에 따라 바뀝니다. 이 셰이더 효과 하나가 아무리 많은 지형 디테일보다도 규모감을 더 효과적으로 전달합니다.

스타일라이즈드 아트 방향의 브라우저 월드라면 대기 원근법을 가장 먼저 구현해야 합니다. LOD 전환을 숨기고(디테일이 낮은 원거리 오브젝트도 안개를 통하면 자연스럽게 보임), 스트리밍 콘텐츠의 눈에 띄는 팝인을 줄이며, 월드가 완전히 채워지기 전에도 스크린샷을 보기 좋게 만들어 줍니다.

아바타 시스템

플레이어에게는 몸이 필요합니다. 크리에이터 월드에서 아바타는 직접 만든 창작물과 더불어 자신을 표현하는 주된 수단입니다. 시스템은 개인화에 충분히 유연하면서도 200명 이상의 플레이어를 동시에 표시할 수 있을 만큼 렌더링 비용이 낮아야 합니다.

아바타 아키텍처

기본 메시 + 커스터마이징 레이어. 공유 휴머노이드 기본 메시(몸체 기준 1,500~3,000개 삼각형)로 시작합니다. 커스터마이징은 다음 방식으로 이루어집니다.

• 유니폼 변경을 통한 색상/텍스처 변형(피부색, 머리색). 추가 지오메트리가 필요 없습니다.
• 기본 메시의 일부를 대체하는 교체형 메시 파츠(헤어스타일, 의상, 액세서리). 각 파츠는 별도의 작은 메시(200~500개 삼각형)입니다.
• 머티리얼 매개변수 변경을 통한 속성 변형(금속 갑옷과 천 튜닉 등).

Roblox, Fortnite, VRChat이 아바타를 처리하는 방식입니다. 커스터마이징과 관계없이 기본 비용은 일정하게 유지됩니다.

Ready Player Me와 Avaturn은 모든 3D 엔진과 호환되는 glTF 모델을 출력하는 브라우저 기반 아바타 생성 기능을 제공합니다. 사진을 이용한 얼굴 스캔, 신체 비율, 의상을 처리합니다. 출력 모델은 실시간 렌더링에 최적화되어 있으며, 일반적으로 10K~20K개의 삼각형으로 구성되고 원거리 렌더링용으로 3K~5K개까지 줄일 수 있습니다.

브라우저의 스켈레탈 애니메이션

화면에 보이는 모든 플레이어에게는 대기, 걷기, 달리기, 점프, 감정 표현 등의 애니메이션이 필요합니다. 스켈레탈 애니메이션은 매 프레임 본 트랜스폼 집합으로 메시를 구동합니다.

성능을 위해 GPU 스키닝은 필수입니다. Three.js와 Babylon.js 모두 기본적으로 GPU에서 스키닝을 수행합니다. 본 행렬은 유니폼 버퍼 또는 텍스처로 업로드되고, 버텍스 셰이더가 본 트랜스폼을 적용합니다. CPU 비용은 애니메이션 클립에서 본 트랜스폼을 계산하는 데서 발생합니다. 30fps로 작동하는 60본 스켈레톤의 경우 캐릭터당 약 0.01ms입니다. 캐릭터 200명이라면 총 2ms로, 허용 가능한 수준입니다.

애니메이션 블렌딩은 블렌드 가중치를 사용해 여러 애니메이션(걷기 + 손 흔들기, 대기 + 주위 둘러보기)을 혼합합니다. Three.js(AnimationMixer)와 Babylon.js(AnimationGroup) 모두 이를 지원합니다. 블렌딩은 혼합된 결과가 GPU로 전달되기 전에 CPU에서 본 트랜스폼을 보간하는 방식으로 이루어집니다.

인스턴스 애니메이션은 많은 캐릭터를 효율적으로 렌더링하는 핵심입니다. 각 캐릭터를 별도 메시로 그리는 대신 애니메이션 프레임을 텍스처, 즉 버텍스 애니메이션 텍스처(VAT)에 베이크합니다. 텍스처의 각 행은 한 프레임의 본 트랜스폼을 저장합니다. 컴퓨트 셰이더 또는 버텍스 셰이더가 캐릭터의 애니메이션 시간에 따라 올바른 행을 읽습니다. 이 방법을 사용하면 단일 인스턴스 드로우 콜로 수백 개의 캐릭터를 렌더링할 수 있습니다. The Witcher 3와 Assassin's Creed가 군중 렌더링에 사용하는 방식입니다.

WebGPU에서 인스턴스 애니메이션 캐릭터는 다음과 같습니다.

@vertex
fn vs_main(@builtin(instance_index) instanceIdx: u32, @location(0) position: vec3<f32>) -> @builtin(position) vec4<f32> {
    let animFrame = instances[instanceIdx].animationFrame;
    let boneIdx = vertexBoneIndices[vertexIdx];
    let boneTransform = textureLoad(animTexture, vec2<i32>(i32(boneIdx), i32(animFrame)), 0);
    let worldPos = instances[instanceIdx].transform * boneTransform * vec4<f32>(position, 1.0);
    return viewProjection * worldPos;
}

50미터보다 멀리 있는 플레이어는 빌보드 임포스터로 전환합니다. 현재 시야각에서 캐릭터를 미리 렌더링한 스프라이트를 표시하는 평평한 쿼드입니다. Skyrim이 멀리 있는 나무에 사용하는 것과 같은 기법을 캐릭터에 적용한 것입니다. 먼 거리에서는 전환을 알아차리기 어렵습니다.

상호작용을 위한 역운동학

캐릭터가 오브젝트를 집거나 문손잡이에 손을 뻗거나 무언가를 가리킬 때 절차적 IK를 사용하면 동작이 자연스러워집니다. FABRIK(Forward And Backward Reaching Inverse Kinematics)은 실시간으로 잘 작동하는 단순하고 빠른 IK 솔버입니다. Three.js는 CCDIKSolver를 통해, Babylon.js는 BoneIKController를 통해 내장 IK를 지원합니다.

크리에이터 월드에서 IK를 사용하면 캐릭터가 배치된 오브젝트와 자연스럽게 상호작용할 수 있습니다. 크리에이터가 배치한 의자에 앉거나, 난간에 기대거나, 아이템을 집을 수 있습니다. 각 오브젝트별 애니메이션은 필요하지 않습니다. IK 시스템이 오브젝트 위치에 맞춰 캐릭터의 포즈를 조정합니다.

고급 네트워킹

기본 아키텍처(WebSocket + WebRTC)는 앞에서 다뤘습니다. 여기서는 프로토콜, 압축, 최신 전송 옵션을 더 자세히 살펴봅니다.

바이너리 메시지 프로토콜

WebSocket에서 JSON을 사용하면 바이너리 인코딩에 비해 대역폭을 10배나 낭비합니다. 실시간 멀티플레이어 월드에서는 모든 메시지를 바이너리로 전송해야 합니다. FlatBuffers(Google 제공)는 게임 네트워킹에 가장 적합합니다. Protocol Buffers와 달리 FlatBuffers는 직렬화된 데이터에 제로 카피로 접근할 수 있습니다. 메시지를 JavaScript 객체로 디코딩하지 않고 버퍼에서 직접 필드를 읽습니다. 따라서 핫 패스에서 Protocol Buffers가 유발할 할당과 GC 부담을 없앨 수 있습니다. FlatBuffers는 JavaScript/TypeScript 코드 생성기를 제공합니다.

FlatBuffers로 표현한 플레이어 위치 업데이트:

// Schema: PlayerUpdate { id: uint16, x: float32, y: float32, z: float32, yaw: float16, pitch: float16, animState: uint8 }
// Total: 17 bytes per player update
// vs JSON: {"id":42,"x":103.5,"y":12.3,"z":-47.8,"yaw":1.57,"pitch":0.2,"animState":3} = 80+ bytes

플레이어 200명에게 초당 20회 업데이트를 보낼 경우, 200 * 17 * 20 = 68KB/s(바이너리)인 반면 200 * 80 * 20 = 320KB/s(JSON)입니다. 바이너리는 4.7배 더 작으며 핫 루프에서 발생하는 JSON.parse 할당도 피할 수 있습니다.

MessagePack은 FlatBuffers보다 단순하지만(스키마와 코드 생성이 필요 없음) 여전히 JSON보다 30~50% 작습니다. 스키마를 관리하지 않고 바이너리를 사용하려는 경우 좋은 절충안입니다.

위치 양자화와 델타 압축

플레이어 위치에는 32비트 부동소수점 정밀도가 필요하지 않습니다. 월드가 4km x 4km라면 16비트 부호 없는 정수로 6cm 정밀도(4000m / 65536)를 얻을 수 있습니다. 대부분의 게임에서는 완전한 정밀도와 구별할 수 없는 수준입니다. 이를 통해 위치 데이터 크기를 절반으로 줄일 수 있습니다.

델타 압축은 마지막으로 확인된 상태와의 차이만 전송합니다. 플레이어가 마지막 업데이트 이후 0.5미터 이동했다면 델타는 압축이 잘되는 작은 숫자입니다. 가변 길이 인코딩과 결합하면(작은 델타에 더 적은 바이트 사용) 일반적인 델타 압축 위치 업데이트는 12바이트 대신 3~6바이트만 사용합니다.

**추측 항법(Dead reckoning)**은 업데이트 빈도를 줄입니다. 위치를 초당 20회 전송하는 대신 위치와 속도를 함께 전송합니다. 클라이언트는 업데이트 사이의 위치를 외삽합니다. 실제 위치가 예측 위치에서 임계값 이상 벗어날 때만 보정값을 전송합니다. 직선으로 이동하는 플레이어의 위치 업데이트 대역폭을 60~80% 줄일 수 있으며, 대부분의 이동이 여기에 해당합니다.

RuneScape는 이 방식의 극단적인 형태를 사용합니다. 플레이어 이동이 타일 기반이므로 이동 명령은 목적지 타일 하나면 충분합니다. 클라이언트가 걷기 경로를 로컬에서 애니메이션으로 재생합니다. 연속적인 3D 월드에서는 부드러운 추측 항법을 사용하겠지만 원리는 같습니다.

WebTransport

WebTransport는 게임 네트워킹에서 WebSocket과 WebRTC DataChannel을 모두 대체할 수 있는 최신 프로토콜입니다. HTTP/3(QUIC) 위에서 작동하며 다음 기능을 제공합니다.

• 신뢰성 있는 순서 보장 스트림(WebSocket과 비슷하지만 다중화되므로 한 스트림의 지연이 다른 스트림을 차단하지 않음)
• 신뢰성 없는 데이터그램(UDP와 비슷하며, 지연되는 즉시 쓸모없어지는 위치 업데이트에 적합)
• 다중화 스트림(HOL 차단 없이 채팅, 월드 상태, 위치에 별도의 스트림 사용)

이는 게임 네트워킹에 정확히 필요한 기능입니다. WebSocket은 신뢰성과 순서를 보장하지만 HOL 차단 때문에 위치 업데이트의 지연 시간이 크게 늘어납니다. WebRTC DataChannel은 신뢰성 없는 전송을 제공하지만 설정이 복잡하고 ICE/STUN이 필요합니다. WebTransport는 하나의 연결을 통해 두 가지 방식을 모두 제공합니다.

브라우저 지원 현황: Chrome, Edge, Firefox는 이미 한동안 WebTransport를 지원해 왔으며 Safari 26.4도 2026년 3월부터 지원하기 시작했습니다. 이에 따라 WebTransport는 Baseline 상태가 되었으며, 모든 브라우저가 WebKit을 사용하는 iOS를 포함해 이제 모든 주요 브라우저에서 작동합니다. 이전 Safari 버전을 위해 WebSocket 폴백을 유지할 가치는 있지만, 현재 WebTransport는 폭넓게 사용할 수 있습니다.

Cloudflare는 Workers를 통해 WebTransport를 지원하므로 우리의 인프라와도 잘 맞습니다.

대규모 관심 영역 관리

플레이어가 200명 이상일 때의 네트워킹 문제는 플레이어당 대역폭이 아닙니다. 문제는 N 제곱으로 증가한다는 점입니다. 모든 플레이어가 다른 모든 플레이어에게 업데이트를 전송한다면 플레이어 200명은 틱당 200 * 199 = 39,800개의 업데이트 메시지를 의미합니다. 서버에서 이를 필터링해야 합니다.

관심 영역(Area of Interest, AOI) 관리란 각 플레이어가 자신의 시야 범위 안에 있는 엔티티의 업데이트만 받게 하는 방식입니다. 구현에는 청크 시스템과 동일한 공간 그리드를 사용합니다. 플레이어의 위치가 청크 (3, 7)에 매핑된다면 3x3 인접 영역인 청크 (2-4, 6-8)의 업데이트를 받습니다. 이 범위 밖의 엔티티는 전송하지 않습니다.

AOI 내의 우선순위 기반 업데이트는 중요한 엔티티에 더 많은 대역폭을 할당합니다. 자신을 향해 달려오는 플레이어는 초당 20회 업데이트합니다. 200미터 떨어진 곳에 가만히 서 있는 플레이어는 초당 2회 업데이트합니다. 아무것도 하지 않는 NPC는 초당 0.5회 업데이트합니다. 서버는 클라이언트별 우선순위 큐를 유지하고 엔티티의 관련성(거리, 속도, 상호작용 가능성)에 따라 대역폭을 할당합니다.

휴면 상태. N초 동안 상태가 변하지 않은 엔티티는 휴면 상태에 들어가 네트워크 트래픽을 완전히 중단합니다. 클라이언트는 깨우기 이벤트가 도착할 때까지 마지막으로 알려진 상태를 유지합니다. 배치된 객체 대부분이 정적인 크리에이터 월드에서는 휴면 상태를 통해 잠재적인 네트워크 트래픽의 대부분을 없앨 수 있습니다.

Slither.io의 가변 틱 레이트(먼 곳은 5Hz, 가까운 곳은 30Hz)는 이를 단순화한 버전입니다. EVE Online의 '시간 지연(time dilation)'은 극단적인 버전입니다. 한 영역에 너무 많은 플레이어가 모이면 일관성을 유지하기 위해 서버가 게임 틱 레이트를 낮춥니다. 우리의 사용 사례에는 휴면 상태를 결합한 우선순위 기반 AOI가 가장 적절한 균형점입니다.

가우시안 스플래팅과 최신 렌더링 기술

전통적인 메시 렌더링(삼각형 + 텍스처)만이 브라우저 3D의 유일한 선택지는 아닙니다. 몇 가지 최신 기술이 실제 서비스에 사용할 수 있는 수준에 도달하고 있습니다.

3D 가우시안 스플래팅

3D 가우시안 스플래팅(SIGGRAPH 2023): 사진으로부터 사실적인 장면을 재구성하고 브라우저에서 실시간으로 렌더링합니다. 크리에이터는 휴대전화로 현실 세계의 객체를 스캔한 뒤 월드에 바로 배치할 수 있습니다.

3D 가우시안 스플래팅(3DGS)은 장면을 수백만 개의 색이 있는 3D 가우시안(방향과 색을 지닌 타원체)으로 표현해 사진에서 3D 장면을 재구성합니다. 렌더러는 삼각형 대신 이러한 스플랫을 정렬하고 래스터화합니다.

이 기술이 크리에이터 월드에 중요한 이유:

• 포토그래메트리 캡처가 매우 간단해집니다. 크리에이터가 휴대전화로 현실 세계의 객체나 장소를 사진 50장으로 촬영합니다. 서버 측 처리(Nerfstudio나 gsplat 같은 도구 사용)를 거치면 몇 분 만에 가우시안 스플랫 장면이 생성됩니다. 이 장면은 브라우저에서 로드되며 어느 각도에서 보더라도 사실적으로 보입니다.
• 브라우저 렌더링 문제가 해결되었습니다. 여러 오픈 소스 구현체가 WebGL과 WebGPU에서 가우시안 스플랫을 렌더링합니다. PlayCanvas에는 스플랫 렌더링이 내장되어 있습니다. Luma AI에는 Three.js 호환 뷰어가 있습니다. gsplat.js는 독립형 라이브러리입니다. 성능도 우수합니다. 데스크톱 GPU에서 100만~300만 개의 스플랫을 30~60fps로 렌더링할 수 있습니다.
• 데이터 형식이 작습니다. 방 하나의 가우시안 스플랫 장면은 압축 시 약 10~30MB일 수 있습니다. 개별 객체는 1~5MB입니다. 이는 텍스처가 적용된 메시 에셋과 비슷한 수준입니다.

단점은 스플랫 장면이 정적이라는 것입니다. 쉽게 애니메이션하거나 수정할 수 없습니다. 사실적인 나무, 현실의 조각상을 캡처한 모델, 스캔한 건물 외벽처럼 환경을 꾸미는 데는 적합하지만 상호작용 가능한 게임 객체에는 적합하지 않습니다. 하이브리드 접근 방식은 환경 디테일에 스플랫을 사용하고 상호작용 가능한 객체에는 전통적인 메시를 사용하는 것입니다.

크리에이터 월드에서의 활용: 크리에이터가 휴대전화 사진으로 현실 세계의 객체를 캡처하고, 서버 측에서 가우시안 스플랫으로 처리한 뒤 월드에 배치할 수 있게 합니다. 이는 AI 생성 에셋과 현실 세계 객체 사이의 간극을 메웁니다. 크리에이터는 자신의 미술 작품, 가구, 건축물을 스캔해 공유 월드에 바로 배치할 수 있습니다.

신경 방사장(NeRF)에서 메시로 변환

NeRF는 임의의 3D 지점에 대한 색상과 밀도를 출력하는 신경망으로 장면을 표현합니다. 사진으로부터 놀라운 시각적 품질을 만들어내지만 렌더링 비용이 많이 듭니다. 프레임마다 각 픽셀에 대해 전체 신경망 순전파를 실행해야 하기 때문입니다.

브라우저에서 실용적인 접근 방식은 사진으로 NeRF를 학습한 다음 밀도 필드에 마칭 큐브를 적용해 메시를 추출하는 것입니다. 그 결과 어떤 브라우저 엔진에서도 렌더링할 수 있는 베이크된 텍스처를 갖춘 전통적인 삼각형 메시가 생성됩니다. Instant-NGP, Nerfstudio, Neuralangelo 같은 도구가 이 파이프라인을 자동화합니다. NeRF를 직접 렌더링하는 것만큼 품질이 높지는 않지만 표준 렌더링 파이프라인과 호환됩니다.

이는 모델링 기술이 없는 크리에이터가 현실 세계의 객체를 브라우저 월드로 가져올 수 있는 또 다른 방법입니다.

메시 셰이더와 Nanite 스타일 렌더링

UE5의 Nanite 시스템은 메시 셰이더, GPU 주도 렌더링, 가상 지오메트리(화면 점유율에 따라 클러스터 단위로 삼각형 스트리밍)를 사용해 수십억 개의 삼각형을 렌더링합니다. WebGPU는 아직 메시 셰이더를 지원하지 않지만 기본 원리인 컴퓨트 기반 컬링과 LOD 선택을 활용한 GPU 주도 렌더링은 구현할 수 있습니다.

WebGPU 컴퓨트 셰이더는 다음 작업을 수행할 수 있습니다.

1. 모든 메시 클러스터의 바운딩 박스 읽기(약 64개 삼각형으로 구성된 그룹)
2. 각 클러스터를 뷰 프러스텀 및 오클루전 버퍼와 대조해 검사
3. 화면 공간 크기에 따라 적절한 LOD 단계 선택
4. 보이는 클러스터를 간접 드로 버퍼에 기록
5. 단일 간접 드로 콜로 모든 항목 렌더링

이 '가상 지오메트리' 접근 방식은 일정한 CPU 비용으로 수백만 개의 삼각형을 처리합니다. 장면의 복잡도와 관계없이 CPU는 드로 콜 하나만 제출합니다. 이는 브라우저 렌더링이 궁극적으로 대규모 오픈 월드를 처리하게 될 방식입니다. 구현은 복잡하지만 필요한 구성 요소는 현재 WebGPU에 이미 존재합니다.

스타일리시한 오픈 월드를 위한 셰이더 기법

스타일리시한 아트 디렉션에는 특정한 셰이더 기법이 필요합니다. 다음은 GPU 사이클당 시각적 효과가 가장 큰 기법들입니다.

식생 바람 애니메이션

바람에 흔들리는 나무와 풀은 월드에 생동감을 줍니다. 기법은 간단합니다. 버텍스 셰이더에서 월드 위치와 시간을 기준으로 한 여러 사인파를 조합해 정점 위치에 오프셋을 적용합니다.

vec3 windOffset = vec3(
    sin(worldPos.x * 0.5 + time * 2.0) * windStrength,
    0.0,
    cos(worldPos.z * 0.3 + time * 1.5) * windStrength
);
float heightFactor = localPos.y / meshHeight;
finalPos += windOffset * heightFactor * heightFactor;

heightFactor는 나무 밑동을 땅에 고정한 채 꼭대기가 가장 많이 흔들리게 합니다. 사인 함수에 월드 위치를 사용하면 인접한 나무들이 조금씩 다른 위상으로 흔들려 숲 전체에 자연스러운 물결 효과가 생깁니다. BotW, Skyrim을 비롯해 식생이 있는 모든 오픈 월드가 이 기법을 사용합니다.

풀에도 같은 원리를 적용하되 더 높은 주파수와 짧은 파장을 사용합니다. 인스턴스별로 무작위 위상 오프셋을 적용한 GPU 인스턴싱 풀잎(수천 개의 얇은 쿼드)은 최소한의 비용으로 그럴듯한 초원을 만들어냅니다. WebGPU 컴퓨트 셰이더는 밀도 맵에서 풀잎의 위치와 방향을 생성하고, 프레임마다 인스턴스 트랜스폼에 바람 효과를 반영할 수 있습니다.

툰/셀 셰이딩

아트 디렉션이 스타일리시하다면(정황상 그렇게 되어야 합니다) 셀 셰이딩이 핵심 기법입니다. 부드러운 그라데이션 대신 조명을 불연속적인 단계로 양자화하는 방식입니다.

float NdotL = dot(normal, lightDir);
float toonShading = step(0.3, NdotL) * 0.5 + step(0.6, NdotL) * 0.5;
vec3 color = baseColor * (ambient + toonShading);

이를 통해 고전적인 2톤 또는 3톤 스타일을 만들 수 있습니다. 만화책 같은 효과를 원한다면 외곽선 패스를 추가합니다. 후면을 약간 확장해 렌더링하거나 화면 공간 에지 감지 후처리를 사용할 수 있습니다.

BotW의 셰이딩은 순수한 셀 셰이딩보다 더 섬세합니다. 부드러운 그라데이션을 사용하면서 그림자 경계에는 약간의 단계를 주고, 따뜻한 색에서 차가운 색으로 전환되는 효과도 더합니다. 그림자는 푸른색을 띠고 빛을 받는 영역은 따뜻한 색을 띱니다. 이 하이브리드 접근 방식은 스타일리시한 인상을 유지하면서도 엄격한 툰 셰이딩보다 자연스럽게 보입니다. 모든 브라우저 3D 엔진에서 커스텀 셰이더로 구현할 수 있습니다.

스타일리시한 물 셰이더

스타일리시한 월드의 물에는 사실적인 파도 시뮬레이션이 필요하지 않습니다. 스크롤되는 노멀 맵, 가장자리 거품 감지, 깊이 기반 색상을 조합하면 BotW 스타일의 아트 디렉션과 시각적으로 일관된 결과를 얻을 수 있습니다.

float depth = texture(depthTexture, screenUV).r - fragDepth;
vec3 shallowColor = vec3(0.2, 0.7, 0.8);
vec3 deepColor = vec3(0.05, 0.15, 0.3);
vec3 waterColor = mix(shallowColor, deepColor, saturate(depth * 2.0));

float foam = step(0.05, depth) * (1.0 - step(0.15, depth));
foam *= texture(foamNoise, worldUV * 3.0 + time * 0.1).r;
waterColor = mix(waterColor, vec3(1.0), foam * 0.8);

이 기법은 깊이에 따른 색상 변화(얕은 물은 더 밝게 표현), 노이즈에 따라 움직이는 해안선 거품을 제공하며 전체 효과가 단일 프래그먼트 셰이더 패스로 실행됩니다.

화면 공간 앰비언트 오클루전(SSAO)

SSAO는 모서리와 틈새, 표면이 맞닿는 영역을 어둡게 합니다. 비용이 많이 드는 전역 조명 없이도 장면에 깊이감과 안정감을 더합니다. Three.js와 Babylon.js 모두 SSAO 구현을 내장하고 있습니다.

스타일리시한 월드에서는 평면적인 셰이딩만으로 접촉 그림자가 자연스럽게 드러나지 않으므로 SSAO가 사실적인 렌더링에서보다 더 중요합니다. 가벼운 SSAO 패스(절반 해상도로도 충분함)는 부족한 깊이 단서를 보완합니다. 데스크톱 GPU에서의 비용은 1~2ms입니다.

더 심층적인 월드 생성

기본 글에서는 절차적 지형을 개괄적으로 다뤘습니다. 여기서는 알고리즘의 세부 내용을 살펴봅니다.

지형을 위한 노이즈 함수

모든 절차적 지형은 노이즈에서 시작합니다. 노이즈 함수는 공간에서 부드럽게 변화하는 의사 난수 값을 생성합니다. 여러 옥타브(주파수)를 겹치면 자연스러운 결과를 얻을 수 있습니다.

Perlin 노이즈는 고전적인 방식입니다. Simplex 노이즈는 더 빠르고 방향성 아티팩트가 적습니다. OpenSimplex 2는 JavaScript에서 성능이 좋은 최신 변형입니다. WebGPU 컴퓨트 셰이더의 경우 WGSL로 Simplex 노이즈를 구현하는 것도 어렵지 않습니다. 약 50줄의 수학 코드면 충분합니다.

**프랙탈 브라운 운동(fBm)**은 여러 옥타브의 노이즈를 겹칩니다:

height = 0
amplitude = 1.0
frequency = baseFrequency
for each octave:
    height += amplitude * noise(position * frequency)
    frequency *= lacunarity (typically 2.0)
    amplitude *= persistence (typically 0.5)

6~8개의 옥타브를 사용하면 fBm은 실제 지형처럼 대규모 산맥, 중간 규모의 언덕, 미세한 거칠기를 갖춘 지형을 생성합니다. persistence 매개변수는 지형의 거친 정도를 제어합니다(0.3은 완만하고 부드러운 구릉을, 0.7은 험준한 산악 지형을 생성합니다).

도메인 워핑은 한 노이즈 함수의 출력을 다른 노이즈 함수의 입력 좌표로 사용합니다. 이를 통해 균일하게 울퉁불퉁한 지형이 아니라 침식된 듯 자연스러운 지형을 생성할 수 있습니다. 도메인 워핑을 2~3개 레이어로 적용하면 지질학적 과정으로 형성된 듯한 지형이 만들어지기 시작합니다.

수력 침식 시뮬레이션

가공되지 않은 노이즈 지형은 구겨진 종이처럼 보입니다. 실제 지형은 백만 년 동안 비를 맞은 구겨진 종이처럼 보입니다. 수력 침식 시뮬레이션은 노이즈로 생성한 지형을 지질학적으로 그럴듯한 형태로 바꿉니다.

알고리즘은 다음과 같습니다.

1. 높이 맵의 무작위 위치에 물 입자를 떨어뜨립니다
2. 입자가 내리막으로 흐릅니다(지형의 기울기를 따릅니다)
3. 각 단계에서 입자는 속도와 경사에 따라 지형의 퇴적물을 흡수합니다
4. 입자가 느려지면(지형이 평평해지거나 물이 고이면) 퇴적물을 내려놓습니다
5. 100,000~500,000개의 입자에 대해 반복합니다

그 결과 하천 계곡, 충적 선상지, 자연스러운 능선, 논리적으로 이어지는 완만한 경사를 갖춘 지형이 만들어집니다. 이 알고리즘은 1024x1024 높이 맵에서 JavaScript로 약 2~5초가 걸리며, WebGPU 컴퓨트 셰이더에서는 100ms 이내에 실행됩니다.

Sebastian Lague의 구현체(GitHub에서 이용 가능)는 게임 개발자를 위한 표준 참고 자료입니다. 수작업으로 조형한 결과물에 필적하는 지형을 생성합니다. 크리에이터 월드에서는 서버 측 처리 단계에서 AI 생성 지형에 침식을 적용하여 절차적으로 생성된 풍경을 수작업으로 만든 것처럼 보이게 할 수 있습니다.

바이옴 할당

실제 세계에는 숲, 사막, 툰드라, 습지 같은 바이옴이 있습니다. 바이옴 할당은 기후 매개변수를 지형 구역에 매핑합니다.

Minecraft의 접근 방식은 참고할 만합니다. 온도와 습도를 축으로 하는 2D 그리드에 바이옴을 정의합니다. 고도와 위도가 높아질수록 온도는 내려갑니다. 습도는 물과의 거리 및 주풍 방향에 따라 달라집니다. 각 그리드 셀에는 바이옴(숲, 사막, 툰드라 등)이 할당되며, 이에 따라 지형 텍스처, 식생의 종류와 밀도, 환경음, 날씨 패턴이 결정됩니다.

크리에이터 월드에서는 바이옴 경계를 페인팅할 수 있어야 합니다. 시스템이 지형 속성을 바탕으로 기본 바이옴을 생성하되, 크리에이터가 자신이 소유한 구획에 바이옴 영역을 칠해 할당을 재정의할 수 있어야 합니다. 이 하이브리드 방식은 월드에 자연스러운 기본 모습을 제공하면서도 크리에이터가 자신의 비전을 표현할 수 있게 합니다.

구조물용 파동 함수 붕괴

파동 함수 붕괴(WFC)는 인접 제약 조건이 있는 타일 세트로 구조물(건물, 던전, 도로)을 생성합니다. 모듈식 건축 부품 세트와 어떤 부품끼리 연결할 수 있는지에 관한 규칙이 주어지면 WFC로 마을 전체, 성의 배치, 던전 맵을 생성할 수 있습니다.

크리에이터 월드에서 WFC로 가능한 기능은 다음과 같습니다.

• 크리에이터가 꾸미기 전에 월드에 기본 콘텐츠를 채워 넣는 자동 생성 마을
• 크리에이터가 몇 개의 부품을 배치하면 WFC가 빈 공간을 채우는 건축 보조(Townscaper와 비슷하지만 3D 건축 블록 사용)
• 크리에이터가 구성할 수 있는 인터랙티브 경험을 위한 던전 생성(테마, 난이도, 크기를 설정하면 WFC가 레이아웃을 생성)

Oskar Stalberg(Townscaper와 Bad North의 제작자)는 WFC 기반 생성이 사용자에게 마법처럼 느껴질 수 있음을 보여주었습니다. 사용자가 블록 몇 개를 배치하면 시스템이 그 주변에 미적으로 일관된 구조물을 생성합니다. 이는 크리에이터 플랫폼에서 성공하는 “간단한 도구, 풍부한 결과물” 원칙과 정확히 일치합니다.

콘텐츠 모더레이션 아키텍처

크리에이터가 다른 사람에게 보이는 임의의 3D 콘텐츠를 배치할 수 있는 월드에서 모더레이션은 선택 사항이 아닙니다. 핵심 인프라 구성 요소입니다.

자동 심사 파이프라인

월드에 들어오는 모든 에셋은 다른 플레이어에게 표시되기 전에 여러 단계의 파이프라인을 거칩니다.

1. 지오메트리 분석. 학습된 분류기로 메시를 스캔하여 해부학적으로 노골적인 형태를 찾습니다. 이를 통해 명백히 부적절한 3D 모델 대부분을 탐지할 수 있습니다. 여러 상용 API(Azure Content Safety, Google Cloud Vision for 3D)가 이를 처리합니다. 분류기는 여러 각도에서 본 메시의 실루엣을 대상으로 실행되므로 연산 비용이 낮습니다.

2. 텍스처 분석. 각 텍스처를 표준 이미지 콘텐츠 모더레이션 API(업로드된 사진에 사용하는 것과 동일한 API)에 통과시킵니다. 이를 통해 겉보기에는 무해한 지오메트리에 텍스처로 적용된 부적절한 이미지를 탐지합니다.

3. 텍스트 감지. 오브젝트에 텍스트가 포함되어 있다면(텍스처에 있거나 3D 텍스트 메시인 경우) OCR을 실행하고 콘텐츠 정책에 따라 검사합니다. 이를 통해 혐오 발언, 비하 표현, 기타 텍스트 기반 위반 사항을 탐지합니다.

4. 자동 승인. 모든 검사를 통과하면 에셋이 즉시 표시됩니다. 하나라도 문제가 감지되면 에셋은 검토 대기열로 이동합니다.

5. 사람의 검토. 표시된 에셋은 모더레이터가 검토합니다. 소규모 플랫폼이라면 팀에서 직접 처리할 수 있습니다. 규모가 커지면 소셜 미디어 콘텐츠를 검토하는 것과 같은 전문 모더레이션 서비스에 위탁할 수 있습니다.

공간 모더레이션

개별 에셋은 각각 문제가 없더라도 오브젝트의 공간적 배치가 부적절할 수 있습니다. 이는 자동으로 탐지하기가 더 어렵습니다. 현실적인 접근 방식은 다음과 같습니다.

• 플레이어 신고. 모든 플레이어가 위치를 신고할 수 있습니다. 신고에는 해당 좌표에서 자동으로 촬영한 스크린샷과 신고한 플레이어의 계정 정보가 포함됩니다. 신고가 접수되면 사람이 검토합니다.
• 히트맵. 어떤 구역에서 신고가 발생하는지 추적합니다. 특정 크리에이터의 구획에서 지속적으로 신고가 발생하면 검토 단계로 상향합니다. 크리에이터의 위반이 반복적으로 확인되면 편집 권한을 제한합니다.
• 구획 등급. Second Life처럼 크리에이터가 자신의 구획에 직접 등급을 지정하게 합니다. 기본 보기에서는 “전체 이용가”보다 높은 등급의 구획을 숨깁니다. 플레이어는 성인용 콘텐츠 표시를 직접 선택할 수 있습니다. 위반 자체를 막지는 못하지만 노출은 줄일 수 있습니다.

지연 시간 고려 사항

에셋 하나를 자동 심사하는 데 5~10초가 걸리면 크리에이터가 오브젝트를 배치한 시점과 다른 플레이어에게 표시되는 시점 사이에 눈에 띄는 지연이 발생합니다. 선택지는 다음과 같습니다.

• 낙관적 로컬 표시. 크리에이터에게는 배치 결과를 즉시 보여줍니다. 다른 플레이어에게는 승인 후 표시됩니다. 에셋이 거부되면 사라지고 크리에이터에게 알림이 전송됩니다.
• 사전 승인된 에셋 라이브러리. 대부분의 배치에는 플랫폼 라이브러리에서 사전 심사된 에셋을 사용합니다(생성 과정에서 심사된 AI 생성 에셋 포함). 사용자 지정 업로드만 심사를 거칩니다. 따라서 대부분의 배치는 즉시 반영됩니다.
• 신뢰도 기반 신속 처리. 승인된 콘텐츠를 꾸준히 제작해 온 크리에이터의 새 배치는 자동 승인합니다. 신규 크리에이터나 신고된 크리에이터는 전체 심사를 거칩니다.

브라우저 3D 성능: 실제 수치

이론적인 예산도 유용하지만 실제로 측정한 성능은 더욱 유용합니다. 다음은 상용 하드웨어에서 실행되는 브라우저 3D 장면의 실제 수치입니다.

렌더링 벤치마크

인스턴싱된 오브젝트 10,000개가 있는 Three.js 장면(나무, 바위, 각각 500개 삼각형):

• MacBook Pro M1(Chrome, WebGL2): 58~60fps
• RTX 3060 데스크톱(Chrome, WebGL2): 60fps 고정
• Intel UHD 620 노트북(Chrome, WebGL2): 25~35fps
• iPhone 13(Safari, WebGL2): 30~40fps

인스턴싱된 풀잎 100,000개가 있는 Three.js 장면(각각 6개 삼각형, 총 600K개 삼각형):

• M1 MacBook: 55fps
• RTX 3060: 60fps
• Intel UHD 620: 12fps
• iPhone 13: 15fps

1M개 삼각형, 4단계 LOD, Havok 물리 엔진을 사용하는 Babylon.js 지형:

• M1 MacBook(WebGPU): 60fps
• M1 MacBook(WebGL2): 45fps
• RTX 3060(WebGPU): 60fps
• RTX 3060(WebGL2): 55fps

가우시안 스플랫 장면, 2M개 스플랫(gsplat.js 사용):

• M1 MacBook(WebGL2): 30fps
• RTX 3060(WebGL2): 45fps
• RTX 3060(WebGPU): 60fps

메모리 측정치

Three.js 최소 장면(스카이박스, 지형, 오브젝트 100개): GPU 메모리 80~120 MB, JS 힙 150~200 MB Havok 물리 엔진을 사용하는 Babylon.js: GPU 메모리 200~300 MB, JS 힙 250~350 MB(Havok Wasm이 약 50 MB 추가) 브라우저 탭 메모리 제한(문서가 아닌 실측 기준):

• Chrome 데스크톱: 일반적으로 약 4 GB에서 비정상 종료
• Chrome Android: 일반적으로 약 1~1.5 GB에서 비정상 종료
• Safari iOS: 일반적으로 약 1 GB에서 비정상 종료
• Firefox 데스크톱: 일반적으로 약 3~4 GB에서 비정상 종료

네트워크 측정치

WebSocket 왕복 지연 시간(브라우저에서 Cloudflare 엣지까지):

• 같은 대륙: 10~30ms
• 대륙 간: 80~200ms
• Cloudflare Durable Objects 사용 시: 첫 요청에서 DO가 깨어나는 데 5~10ms 추가

WebRTC DataChannel 지연 시간(TURN을 통한 브라우저 간 통신):

• 같은 도시: 5~15ms
• 같은 대륙: 20~50ms
• 대륙 간: 100~250ms

**WebTransport(HTTP/3 QUIC)**의 지연 시간은 WebSocket과 비슷하지만 헤드 오브 라인 블로킹이 없으므로 P99 지연 시간이 훨씬 우수합니다(패킷 하나가 손실되어도 전체가 멈추지 않음).

로드 시간 측정치

Three.js 빈 장면(라이브러리만 포함): 첫 프레임까지 350ms Babylon.js 빈 장면: 첫 프레임까지 500ms fetch 및 파싱을 통한 1 MB GLB 모델 로드: 광대역에서 200~400ms KTX2 텍스처, 1024x1024, Basis Universal: GPU 디코딩에 50~100ms Draco 압축 메시, 50K개 삼각형: Web Worker에서 디코딩하는 데 30~80ms

이 수치는 아키텍처 섹션의 성능 예산을 달성할 수 있음을 보여줍니다. 중급 데스크톱에서도 복잡한 오픈 월드 장면을 60fps로 렌더링할 수 있습니다. 제약이 되는 것은 모바일입니다. 휴대폰에서 30fps를 유지하려면 적극적인 LOD와 더 짧은 가시거리가 필요합니다.

전체 기술 스택

이 모든 것을 종합하면 브라우저 기반 멀티플레이어 크리에이터 오픈 월드의 아키텍처는 다음과 같습니다.

클라이언트(브라우저)

계층	기술	역할
렌더러	Babylon.js (WebGPU + WebGL2 fallback)	장면 렌더링, 지형, LOD, 후처리
지형	Custom heightmap system + Babylon DynamicTerrain	스플래팅을 사용하는 청크 기반 스트리밍 지형
물리	Rapier (Wasm) or Havok (via Babylon)	캐릭터 컨트롤러, 충돌, 레이캐스팅
ECS	bitECS	모든 월드 오브젝트의 엔티티 관리
네트워킹	WebSocket + WebRTC DataChannel	상태 동기화, 위치 업데이트, 음성 채팅
상태	Yjs (CRDT)	공동 월드 편집, 충돌 해결
오디오	Web Audio API	공간 오디오, 환경음, 음악
UI	HTML/CSS overlay	HUD, 인벤토리, 채팅, 크리에이터 도구
워커	Web Workers	에셋 압축 해제, 물리 연산, 지형 생성

서버

계층	기술	역할
월드 샤드	Cloudflare Durable Objects	청크별 권위 상태, WebSocket 엔드포인트
에셋 저장소	Cloudflare R2	GLB 모델, KTX2 텍스처, 높이 맵, 오디오
에셋 CDN	Cloudflare CDN (R2 public bucket)	엣지에 캐시된 월드 에셋 전송
AI 생성	GPU instances (Hetzner/Lambda/RunPod)	3D 모델 생성, 지형 생성, 텍스처 생성
에셋 파이프라인	Cloudflare Queue + Workers	LOD 생성, 메시 최적화, 형식 변환
인증	Auth0	크리에이터 ID, 권한
데이터베이스	Cloudflare D1	월드 메타데이터, 크리에이터 인벤토리, 권한
실시간 처리	Cloudflare Durable Objects + Pub/Sub	플레이어 접속 상태, 채팅, 이벤트 브로드캐스트

데이터 흐름

1. 플레이어가 브라우저에서 월드를 엽니다
2. 클라이언트가 인증한 뒤 스폰 청크에서 가장 가까운 Durable Object에 연결합니다
3. DO가 현재 청크 상태(지형 + 오브젝트 + 주변 플레이어)를 전송합니다
4. 클라이언트가 렌더링을 시작하고 R2/CDN에서 인접 청크를 요청합니다
5. 플레이어가 이동하면 클라이언트는 인접 DO에 연결하고 멀어진 DO와의 연결을 해제합니다
6. 크리에이터가 오브젝트를 배치합니다. 클라이언트가 편집 내용을 DO로 보내면 DO가 이를 검증하고 CRDT 델타를 통해 연결된 모든 클라이언트에 브로드캐스트합니다
7. DO는 각 편집 시 청크 상태를 저장소에 영속화합니다(디바운싱 적용)
8. 다른 플레이어는 100~200ms 이내에 새 오브젝트가 나타나는 것을 확인합니다

성능 예산

중급 데스크톱(RTX 3060 / M1 Mac / 16GB RAM)에서 60fps를 구현하기 위한 예산은 다음과 같습니다.

리소스	예산	참고
드로 콜	프레임당 < 500	배칭, 인스턴싱, LOD
삼각형	프레임당 < 2M	LOD로 한도 유지
텍스처 메모리	< 512 MB	KTX2 압축, 스트리밍, 아틀라스 풀링
지오메트리 메모리	< 256 MB	공유 버퍼, 풀링, 적극적인 언로드
JavaScript 힙	< 512 MB	ECS에서 오브젝트 대신 타입 배열 사용
네트워크	지속적으로 < 500 KB/s	델타 압축, 공간 관련성 필터링
초기 로드	< 10 MB, < 5초	점진적 로딩, 지형 우선
청크 로드	< 200 KB, < 200ms	인접 청크 프리페치

성공한 브라우저 게임과 그들이 입증한 것

브라우저 게임은 틈새시장이 아닙니다. 가장 큰 게임 시장 중 하나입니다. Poki는 매달 1억 명 이상의 플레이어에게 서비스를 제공합니다. CrazyGames, Newgrounds, itch.io에도 수백만 명 이상의 플레이어가 방문합니다. 브라우저에서 성공하는 게임에는 연구할 가치가 있는 특정 아키텍처 패턴이 있습니다.

현재 서비스 중인 브라우저 3D 게임

Hordes.io: 200명 이상의 플레이어가 참여하는 지속형 3D 브라우저 MMO. 커스텀 WebGL, 로우 폴리 스타일, 5초 이내 로딩. 개발자 한 명이 제작했습니다.

**Hordes.io**는 가장 관련성 높은 브라우저 MMO입니다. 한 명의 개발자가 커스텀 WebGL 렌더링으로 제작했으며, 200명 이상의 플레이어가 실시간 전투, 길드, 클래스, PvP를 갖춘 영속적인 3D 세계에서 함께 플레이합니다. 게임 전체가 5초 이내에 로드됩니다. 세계는 여러 구역으로 나뉘며 적극적인 컬링이 적용됩니다. 플레이어 모델은 단순하지만(플랫 셰이딩을 사용한 로우 폴리), 파티클 효과와 애니메이션 덕분에 전투의 반응성이 뛰어납니다. Hordes.io는 세 가지를 입증합니다. 브라우저 MMO는 하나의 장면에서 수백 명의 동시 접속자를 처리할 수 있고, 1인 개발자도 이를 만들 수 있으며, 브라우저에서는 사실적인 그래픽보다 스타일화된 그래픽이 더 나은 성능을 발휘합니다.

Krunker.io: 월간 플레이어 1,000만 명, Three.js 기반, 완전한 브라우저 내 맵 에디터와 사용자 제작 콘텐츠 마켓플레이스 제공.

Krunker.io는 월간 플레이어 수가 1,000만 명을 넘어서며 정점을 찍었고 FRVR에 인수되었습니다. 완전한 맵 에디터, 커스텀 게임 모드, 사용자 제작 콘텐츠, 마켓플레이스를 갖춘 브라우저 기반 FPS입니다. Three.js로 제작되었으며, 블록형 아트 스타일과 적극적인 최적화 덕분에 저사양 하드웨어에서도 60fps 이상으로 실행됩니다. 특히 레벨 에디터가 주목할 만합니다. 플레이어는 복셀과 유사한 블록 시스템으로 맵을 만들고 마켓플레이스에 공유하며, 다른 플레이어는 그 맵을 플레이합니다. 이는 크리에이터 세계의 선순환을 축소해 놓은 형태입니다. 무언가를 만들고 공유하면 다른 사람들이 그것을 경험합니다. Krunker는 제작 도구가 충분히 단순하다면 사용자 제작 3D 콘텐츠가 브라우저에서도 성공할 수 있음을 입증했습니다.

ev.io는 Babylon.js로 제작된 브라우저 FPS입니다. 대부분의 하드웨어에서 원활하게 실행되고 커스텀 맵을 지원하며, Babylon의 WebGL 렌더러가 브라우저 탭에서 빠른 속도의 3D 액션을 처리할 수 있음을 보여줍니다. 이 게임은 성능 예산을 지키기 위해 적극적인 텍스처 압축과 로우 폴리 환경을 사용합니다.

Shell Shockers(월간 플레이어 500만 명 이상)는 달걀 캐릭터로 플레이하는 3D 멀티플레이어 슈팅 게임입니다. Three.js로 제작되었으며, 브라우저에서 반응성 높은 피격 판정과 실시간 멀티플레이를 처리합니다. 만화풍 아트 스타일을 활용해 에셋 요구 사항을 최소화하면서도 세련된 외관을 유지합니다.

Townscaper: 클릭해 건물을 배치하면 시스템이 거리, 아치, 계단을 자동으로 생성합니다. 메뉴도, 목표도 없습니다. 순수한 창작의 즐거움만으로 100만 장 이상 판매되었습니다.

Townscaper는 브라우저 게임은 아니지만, 세계 구축 방식은 매우 관련성이 높습니다. 플레이어가 수면 위를 클릭해 건물을 배치하면 게임이 배치 패턴을 바탕으로 건축 디테일, 거리, 아치, 계단을 자동 생성합니다. 메뉴도, 설정도, 목표도 없습니다. 그저 클릭해서 건설할 뿐입니다. 이 게임은 100만 장 이상 판매되었습니다. 여기서 얻을 수 있는 교훈은 때로 가장 단순한 창작 도구가 가장 몰입도 높은 경험을 만든다는 것입니다. 세계에 오브젝트를 배치하는 과정을 Townscaper만큼 즉각적으로 느껴지게 만들 수 있다면, 크리에이터들은 몇 시간씩 제작에 몰두할 것입니다.

A-Frame / 8th Wall 경험. A-Frame(Three.js 기반)은 수천 개의 웹 기반 3D 경험을 구동합니다. Niantic이 인수한 장수 WebAR 플랫폼 8th Wall은 복잡한 카메라 기반 AR이 플러그인 없이 모바일 브라우저에서 실행될 수 있음을 보여주었습니다. 다만 Niantic은 2025년 말에 서비스 종료 절차를 시작한다고 발표했습니다(호스팅된 경험은 2027년까지 계속 제공됩니다). 이들은 게임은 아니지만, 물리와 상호작용을 포함한 복잡한 3D 렌더링이 플러그인 없이 브라우저 탭에서 작동한다는 사실을 입증합니다. 이러한 경험 중 다수는 2~3초 만에 로드되며 중급형 스마트폰에서도 실행됩니다.

Vuntra City: 실제로 운영되는 절차적 도시 연구소

Vuntra City는 브라우저 게임이 아니라 네이티브 UE5 프로젝트이므로, 우리 기술 스택의 직접적인 성능 벤치마크는 아닙니다. 그래도 실제 제작 압박 속에서 발생하는 시스템 설계의 절충점을 개발 로그가 이례적으로 구체적으로 다루기 때문에, 오픈 월드 아키텍처에 참고할 수 있는 가장 유용한 공개 사례 연구 중 하나입니다.

가장 중요한 교훈 중 하나는 이동 속도를 고려한 디테일 정책입니다. 이동 및 최적화 영상에서는 고속 이동 경로를 옥상 위로 배치하고, 속도가 높아질수록 세계의 디테일 수준을 낮춰 스트림 관리자가 실내 공간의 잦은 전환으로 과부하되지 않게 합니다(고속 이동, 최적화 기법). 이는 속도가 프리페치 반경, 실내 활성화 범위, 프레임당 스폰 예산을 직접 제어해야 한다는 우리의 브라우저 계획에 그대로 적용할 수 있습니다.

또 다른 교훈은 토폴로지 데이터와 렌더링되는 오브젝트를 엄격하게 분리하는 것입니다. 지도 및 주소 구현에서는 로드되지 않은 지역에 대해서도 위치와 주소 쿼리에 응답할 수 있는 전역 토폴로지 컨트롤러를 사용합니다(지도와 주소). 이는 서버 권위형 경로 탐색, POI 조회, 그리고 특정 클라이언트가 현재 메모리에 보유한 데이터에 의존해서는 안 되는 세계 수준 쿼리에 정확히 필요한 패턴입니다.

NPC 관련 작업 역시 매우 밀접한 관련이 있습니다. 백만 NPC 시스템은 전역적으로 대략적인 스케줄 상태를 계산한 다음, 플레이어와 인접한 공간에서만 비용이 큰 행동을 시뮬레이션합니다(백만 명의 영속적 NPC, 비하인드 스토리). 이는 우리에게 2단계 시뮬레이션 모델의 필요성을 다시 확인시켜 줍니다. 원거리에서는 저비용의 결정론적 상태를 사용하고, AOI 내부의 근거리에서는 풍부한 행동을 구현하는 방식입니다.

마지막으로 Vuntra City의 환경 설계는 기술 계획에서 놓치기 쉬운 사실을 강조합니다. 분포 설계도 콘텐츠 설계라는 점입니다. 이 프로젝트는 균일한 무작위 배치를 피하고, 놀라움을 주기 위해 가중치가 적용된 이상치를 사용하며, 어디에나 표시되는 미니맵 마커 대신 세계관 내 지도와 주소를 통해 발견을 유도합니다(절차적 환경이 지루할 필요는 없다, 우리가 가는 곳에는 미니맵이 필요 없다).

대규모 성공을 거둔 브라우저 게임

Agar.io(2015)는 브라우저 멀티플레이어 게임이 수백만 명에게 도달할 수 있음을 입증했습니다. 전성기에는 여러 서버를 합쳐 동시 접속자가 10만 명을 넘었습니다. 게임은 2D이고 작은 세포를 흡수해 성장하는 단순한 메커니즘을 갖고 있지만, 네트워크 아키텍처는 공간 분할을 통해 대규모 동시 접속을 처리합니다. 각 서버는 게임 세계의 한 지역을 실행합니다. 플레이어는 자신의 시야에 있는 엔티티에 관한 업데이트만 받습니다. 이는 2D로 구현되었을 뿐, 3D 오픈 월드에 필요한 것과 동일한 관심 영역 관리 패턴입니다.

Slither.io는 Agar.io의 성공을 기반으로 이 모델이 확장 가능함을 입증했습니다. 전성기 월간 활성 사용자는 6,700만 명에 달했습니다. 게임은 실시간 위치 동기화에 WebSocket을 사용하고, 공간 분할로 네트워크 트래픽을 제한합니다. 주목할 만한 세부 사항이 하나 있습니다. Slither.io의 서버 측 충돌 판정은 가까운 플레이어보다 먼 플레이어에 대해 더 낮은 틱 레이트로 실행됩니다(근거리 30Hz, 원거리 5Hz). 거리에 따른 이 가변 틱 레이트는 3D 오픈 월드에도 적용할 수 있습니다.

Surviv.io는 Kongregate에 인수되기 전 월간 플레이어 5,000만 명을 달성한 브라우저 기반 배틀 로얄 게임입니다. 실시간 네트워크 물리, 파괴 가능한 환경, 아이템 획득을 포함한 80인 배틀 로얄 매치 전체를 브라우저에서 실행했습니다. 맵은 사전 설계된 건물 템플릿을 절차적으로 배치해 구성했으며, 이는 크리에이터가 배치하는 구조물에 활용할 수 있는 패턴입니다.

Zombs Royale은 빠른 로드 시간과 반응성 높은 네트워킹으로 브라우저에서 100인 배틀 로얄을 실행했습니다. Surviv.io와 마찬가지로, 실시간 브라우저 게임의 대규모 플레이어 수용이 기술적으로 가능할 뿐만 아니라 상업적으로도 실현 가능하다는 점을 입증했습니다.

이 모든 인기 브라우저 게임의 공통점은 빠르게 로드되고(5초 이내), 모든 기기에서 작동하며, 아트 스타일이 단순하지만 일관되고, 특정 게임플레이에 맞게 네트워킹이 최적화되어 있다는 것입니다. 여기에는 공간 분할, 가변 업데이트 빈도, 원거리 상태의 적극적인 컬링이 포함됩니다.

RuneScape: 브라우저로 옮겨간 MMO

RuneScape: 20년 이상의 콘텐츠를 브라우저 탭에서 실행하는 완전한 MMO. 커스텀 바이너리 프로토콜, 타일 기반 스트리밍, 서버당 동시 접속자 2,000명. 브라우저 MMO가 대규모로 작동한다는 증거입니다.

RuneScape는 실제로 이를 해냈기 때문에 브라우저 기반 오픈 월드에서 가장 중요한 사례 연구입니다. Jagex는 20년 분량의 콘텐츠를 갖춘 MMO 전체를 브라우저로 옮겼습니다.

RuneScape는 원래 Java 애플릿으로 실행되었습니다. 브라우저가 Java 지원을 중단하자 Jagex는 클라이언트를 C++로 다시 만들었고, 완전한 기능을 갖춘 HTML5/WebGL 클라이언트도 출시했습니다. 현재 Old School RuneScape(복고풍 버전)는 Emscripten을 통해 WebAssembly로 컴파일된 클라이언트로 브라우저에서 완전히 실행됩니다. 이 게임은 대규모 영속 세계, 서버당 수백 명이 참여하는 실시간 멀티플레이, 실제로 작동하는 그랜드 익스체인지(경매장)를 갖춘 경제, 깊이 있는 성장 시스템을 갖춘 23가지 스킬을 처리합니다.

중요한 기술적 세부 사항:

• 세계는 맵 스퀘어(64x64 타일 지역)로 나뉩니다. 클라이언트는 플레이어 주변의 13x13 지역 그리드를 로드합니다(104x104 타일 표시). 이 그리드 밖의 지역은 완전히 컬링됩니다.
• 지형은 각 타일 모서리의 높이 값을 사용하는 타일 기반 구조입니다. 지형 오버레이(길, 물가, 해변 전환부)는 도형마다 12개의 회전 변형이 있는 도형 시스템을 사용합니다. 이는 높이맵보다 제약이 많지만 매우 압축 효율이 높고 빠르게 스트리밍할 수 있습니다.
• 네트워크 프로토콜은 WebSocket 기반 커스텀 바이너리 형식입니다. 각 패킷 유형에는 정의된 구조가 있습니다. 플레이어 위치 업데이트는 맵 스퀘어 좌표에 2바이트를 사용하고, 이동 유형에는 가변 길이 인코딩을 사용합니다. 채팅, 거래, 전투 이벤트는 각각 자체적인 압축 바이너리 형식을 갖습니다. 전체 프로토콜은 대역폭을 최소화하도록 고도로 최적화되어 있습니다.
• 오브젝트 렌더링은 서버가 모델 ID를 보내면 클라이언트가 캐시된 모델을 렌더링하는 모델 시스템을 사용합니다. 대부분의 모델은 한 번 로드된 뒤 재사용됩니다. 즉, 세계는 지오메트리 대신 메타데이터(어떤 모델을 어디에 배치할지) 형태로 스트리밍됩니다.
• 각 서버 인스턴스는 전체 게임 세계에서 동시 접속자 2,000명을 처리합니다. 세계는 공간적으로 샤딩되지 않습니다. 단일 서버 프로세스가 600ms 게임 틱으로 모든 플레이어, 모든 NPC, 모든 게임 로직을 관리합니다. 틱마다 처리하는 게임 로직이 단순하기 때문에 가능합니다. 플레이어 행동 처리, NPC AI 업데이트, 전투 판정, 상태 변경 브로드캐스트를 수행합니다.

RuneScape가 우리 사례에 입증하는 것: 영속적인 세계 상태, 수천 명의 플레이어, 복잡한 게임 시스템, 실제 경제를 갖춘 완전한 MMO가 브라우저 탭에서 실행될 수 있습니다. 클라이언트 다운로드 용량은 50MB 미만이고 몇 초 만에 로드되며 노트북에서도 실행됩니다. 20년 된 Java MMO가 전환에 성공할 수 있었다면, 처음부터 브라우저용으로 설계된 세계는 제약이 훨씬 적습니다.

RuneScape의 접근 방식이 맞지 않는 부분: RuneScape의 렌더링은 1인칭 또는 3인칭 3D가 아니라 아이소메트릭 고정 카메라 방식입니다. 시각적 완성도는 현대 기준으로 낮습니다. 또한 세계를 크리에이터가 편집할 수 없습니다. 하지만 네트워크 아키텍처, 타일 기반 스트리밍, 브라우저 MMO가 수십 년 동안 플레이어를 유지할 수 있다는 증거는 모두 직접적인 관련이 있습니다.

Habbo Hotel: 25년간 지속된 소셜 공간

Habbo Hotel은 2000년에 출시되어 지금도 운영되고 있습니다. 사용자가 방을 만들고 꾸미며, 다른 사람의 방을 방문하고 교류하는 2D 아이소메트릭 소셜 세계입니다. 전성기에는 월간 사용자 수가 900만 명에 달했습니다. 전체 경험은 Flash에서 실행되었으며, Flash 지원 종료 이후 현재는 HTML5로 전환되었습니다.

Habbo가 중요한 이유는 크리에이터 커뮤니티를 오랫동안 유지해 왔기 때문입니다. 방 시스템은 사실상 우리가 만드는 것의 2D 버전입니다. 사용자는 그리드에 가구 오브젝트를 배치하고 레이아웃을 꾸민 뒤 다른 사람을 초대합니다. 사용자가 실제 돈으로 가상 가구를 구매하는 경제 모델은 누적 10억 달러 이상의 매출을 창출했습니다.

Habbo가 주는 교훈:

• 제작 도구가 단순하고 소셜 기능이 강력하다면, 사용자가 만든 인테리어를 갖춘 방 기반 공간은 수십 년 동안 소셜 플랫폼으로 기능할 수 있습니다.
• 가상 가구 경제는 장기적인 참여를 유지합니다. 사용자는 아이템을 구매하고, 거래하고, 수집합니다. 이 아이템에는 게임플레이상 효용이 없습니다. 순수한 자기표현과 지위의 수단입니다.
• 소셜 공간의 운영 관리는 지속적인 투자가 필요합니다. Habbo는 여러 차례 운영 관리 위기를 겪었습니다. 자동 콘텐츠 필터링, 인간 관리자의 검토, 커뮤니티 신고를 모두 결합하는 것이 최소한의 실용적 접근 방식입니다.
• Flash에서 HTML5로의 전환(2020~2021년경 완료)은 대규모 소셜 세계가 커뮤니티를 잃지 않고 렌더링 기술을 이전할 수 있음을 입증했습니다. 사용자가 중요하게 여기는 것은 기반 기술이 아니라 자신의 방과 친구입니다.

Among Us와 공간형 소셜 게임

Among Us는 오픈 월드가 아니지만, 그 성공은 멀티플레이어 공간에 관한 중요한 사실을 드러냈습니다. 플레이어는 단순히 같은 게임을 하는 것이 아니라, 같은 장소에 함께 있기를 원합니다. 큰 인기를 끈 공간 근접 음성 채팅 모드는 방향성 오디오와 함께 같은 가상 공간에 있는 경험이 멀티플레이를 게임 메커니즘에서 소셜 경험으로 바꾼다는 점을 보여주었습니다. 크리에이터 월드를 향상시키는 공간형 소셜 기능:

• 근접 음성 채팅은 거리가 멀어질수록 음량이 줄어든다. 누군가에게 다가가 대화하고, 멀어지면 상대의 목소리가 점차 들리지 않게 된다. 음성 채널을 관리하지 않아도 자연스럽게 소셜 그룹이 형성된다.
• 이모트 및 제스처 시스템을 사용하면 플레이어가 음성 없이 자신을 표현할 수 있다. 손 흔들기, 춤추기, 가리키기 같은 동작이다. 구현 비용은 적지만(플레이어 아바타에 애니메이션 적용) 소셜 참여도를 크게 높인다.
• 메뉴가 아니라 월드 안에서 이루어지는 공동 활동은 공간을 사람들이 모이는 장소로 바꾼다. 두 크리에이터가 가상 테이블에 앉아 함께 3D 모델을 볼 수 있다면, 그 월드는 정적인 콘텐츠를 전시하는 것 이상의 존재 이유를 갖게 된다.

Poki와 CrazyGames에서 대규모로 성장한 브라우저 게임

Poki와 CrazyGames는 합쳐서 월간 플레이어 1억 5천만 명 이상에게 서비스를 제공한다. 이 플랫폼에서 가장 좋은 성과를 내는 게임을 살펴보면 브라우저에서 특히 효과적인 요소가 무엇인지 알 수 있다.

브라우저 게임 포털에서 성과가 좋은 패턴:

• 즉시 플레이(3초 이내에 상호작용 가능). 로그인도, 튜토리얼도 필요 없어야 한다. 접속한 지 5초 안에 게임을 이해할 수 있어야 한다.
• 유연한 세션. 플레이어는 2분만 즐길 수도 있고 2시간 동안 머물 수도 있다. 게임은 두 경우를 모두 지원한다. 크리에이터 월드라면 세션에 시간을 투자하겠다고 결심하지 않아도 탐험할 수 있어야 한다. 돌아다니며 멋진 것을 보고 떠날 수도 있고, 몇 시간 동안 머물며 만들 수도 있어야 한다.
• 모바일 호환성. Poki 트래픽의 60% 이상이 모바일에서 발생한다. 데스크톱에서만 작동하는 브라우저 월드는 잠재 방문자의 대다수를 놓치게 된다.
• 친구가 없어도 이용할 수 있는 소셜 기능. 리더보드, 다른 플레이어의 콘텐츠에 대한 반응, 비동기 기능(동시에 접속하지 않아도 다른 플레이어가 만든 것을 볼 수 있는 기능) 등이다.

이 포털에서 가장 성공한 3D 게임들(예: Shell Shockers, 1v1.LOL, Smash Karts)은 폴리곤 수를 낮게, 텍스처를 단순하게, 프레임률을 높게 유지한다. 경험이 매끄럽고 반응성이 뛰어나다면 플레이어가 단순한 그래픽도 받아들인다는 것을 보여준다.

브라우저 기반 크리에이터 플랫폼

Hubs by Mozilla(현재 커뮤니티에서 유지 관리). Three.js와 A-Frame으로 제작된 브라우저 기반 다중 사용자 3D 공간이다. 음성 채팅, 아바타, 공유 오브젝트를 지원한다. 오픈 월드는 아니고 방 기반이지만, 네트워킹 및 렌더링 아키텍처는 참고할 만하다. Mozilla가 호스팅 서비스를 종료하기 전에 오픈 소스로 공개했으므로 전체 코드베이스를 살펴볼 수 있다. GitHub.

Hyperfy. 전적으로 브라우저에서 실행되는 웹 기반 메타버스 플랫폼이다. Three.js 렌더링, 멀티플레이어, 아바타 커스터마이징, 월드 빌딩을 지원한다. 크리에이터 도구를 강조한다는 점에서 Hubs보다 우리의 목표에 더 가깝다. 별도의 다운로드 없이 브라우저 탭에서 월드가 로드된다. hyperfy.io.

Ethereal Engine(이전 XREngine). Three.js와 bitECS로 제작된 다중 사용자 월드용 오픈 소스 엔진이다. WebXR, 공간 오디오, 월드 편집을 지원한다. ECS 아키텍처, 네트워킹 레이어, 에디터 도구가 내장되어 있다. 여기서 설명하는 개념과 가장 가까운 기존 오픈 소스 프로젝트다. 엔티티 관리를 위해 bitECS와 Three.js를 통합하는 방식과 네트워킹에서 공간 상태를 처리하는 방식을 살펴볼 가치가 있다. GitHub.

Dusk(이전 Rune). 웹 게임용 멀티플레이어 게임 SDK다. 네트워킹 레이어를 처리해 개발자가 게임플레이에 집중할 수 있도록 한다. 상태 동기화에는 예측 상태와 서버 조정을 결합한 방식을 사용하며, 이는 반응성이 뛰어난 멀티플레이어에서 표준적인 모델이다. SDK가 롤백 넷코드의 복잡성을 추상화한다. 개발자 경험을 살펴볼 가치가 있다.

Niantic Studio. 다른 사람들이 브라우저에서 방문할 수 있는 3D 및 XR 경험을 제작하기 위한 브라우저 기반 비주얼 에디터이자 웹 게임 엔진으로, 8th Wall 도구의 후속 제품이다. 도구가 친숙하다면 기술 지식이 없는 크리에이터도 브라우저에서 3D 장면을 제작할 수 있음을 보여준다. (Niantic은 지리 공간 사업을 Niantic Spatial로 분사했고, Pokemon GO를 포함한 게임 사업을 2025년에 Scopely에 매각했다.)

PlayCanvas Editor. 그 자체가 게임은 아니지만, PlayCanvas의 클라우드 기반 3D 에디터는 협업형 월드 빌딩 도구를 브라우저에서 실행할 수 있음을 보여준다. 여러 팀원이 같은 장면을 동시에 편집할 수 있다. 에디터는 실시간 동기화 레이어를 통해 변경 사항을 전달한다. 게임 에디터 대신 우리의 월드를 캔버스로 사용한다는 점을 제외하면, 이것이 바로 우리에게 필요한 협업형 제작 모델이다.

네이티브 크리에이터 플랫폼(브라우저를 위한 교훈)

이 플랫폼들은 네이티브 앱으로 실행되지만, 크리에이터 도구, 월드 지속성, 소셜 역학에 관한 설계 결정은 브라우저에도 직접 적용할 수 있다.

Roblox: 일일 사용자 8천만 명 이상, 2023년 크리에이터에게 7억 4천만 달러 지급. 제작은 엔진 안에서 이루어지고, 콘텐츠 탐색은 소셜 관계를 통해 이루어진다. 크리에이터 플랫폼이 자생할 수 있음을 입증한 비즈니스 모델이다.

Roblox는 크리에이터 월드를 위한 가장 중요한 단일 참고 사례다. 일일 활성 사용자 수는 8천만 명 이상이다. 크리에이터는 다른 플레이어가 방문하는 완전한 3D 경험(게임, 소셜 공간, 상점)을 제작한다. 플랫폼이 호스팅, 네트워킹, 콘텐츠 탐색, 수익화를 처리한다.

Roblox가 잘하는 점:

• 제작이 엔진 안에서 이루어진다. Roblox Studio는 플레이어가 경험하는 것과 동일한 환경이다. 크리에이터는 자신의 작업을 즉시 테스트할 수 있다. 내보내기, 업로드, 대기로 이어지는 과정이 없다. 브라우저 월드에서는 에디터 자체가 월드여야 한다.
• 스크립팅의 진입 장벽이 낮다. Lua(Roblox의 스크립팅 언어)는 어린이도 배울 수 있을 만큼 간단하다. 복잡한 동작도 구현할 수 있지만 필수는 아니다. 진입 장벽은 낮고 확장 가능성은 높다.
• 콘텐츠 탐색이 소셜 관계를 통해 이루어진다. 친구가 플레이하고 있기 때문에 새로운 경험을 발견하게 된다. 홈페이지에는 인기 경험이 표시된다. 브라우저 월드에서는 월드 자체가 콘텐츠 탐색 화면이다. 돌아다니며 탐험하는 과정에서 무언가를 발견한다.
• 수익화가 실제로 작동한다. 크리에이터는 실제 돈을 번다(Roblox는 2023년에 크리에이터에게 7억 4천만 달러를 지급했다). 이는 진지한 창작 활동을 끌어낸다. 경제적 인센티브가 없으면 크리에이터 플랫폼은 점차 쇠퇴하는 취미 프로젝트가 된다.
• Roblox의 렌더링 엔진은 자체 개발되었으며 브라우저가 아닌 네이티브 앱에서 실행된다. 하지만 경험별 에셋 용량은 현대적인 기준에서 크지 않다(권장 최대 100MB). 성공한 Roblox 경험 대부분은 로우 폴리 스타일의 아트를 사용하며, 이는 브라우저 렌더링 제약과 잘 맞는다.

Fortnite Creative / UEFN(Unreal Editor for Fortnite). Epic은 Unreal Engine의 전체 에디터를 Fortnite 크리에이터에게 제공했다. 그 결과 전문 도구를 사용해 아일랜드(독립적인 월드)를 제작할 수 있는 플랫폼이 탄생했다. Fortnite가 호스팅, 멀티플레이어, 배포를 처리한다.

관련 인사이트:

• 전문 도구는 전문적인 콘텐츠를 끌어낸다. 크리에이터가 UE5의 모든 기능을 사용할 수 있기 때문에 UEFN에서는 시각적으로 뛰어난 경험이 제작된다. 그 대가는 복잡성이다. UEFN의 학습 곡선은 가파르다.
• 아일랜드 기반 인스턴싱(각 창작물이 별도의 월드)은 하나의 공유 월드에서 발생하는 관리 및 충돌 문제를 방지한다. 하지만 크리에이터가 탐험을 통해 서로의 작품을 자연스럽게 발견하지 못한다는 뜻이기도 하다. 걸어서 찾아가는 대신 메뉴를 통해 아일랜드를 방문한다.
• 비즈니스 모델이 작동한다. Fortnite의 크리에이터 프로그램은 참여도를 기준으로 보상한다. 최상위 크리에이터들은 연간 수백만 달러를 번다. 여기에서도 경제적 인센티브가 품질을 끌어올린다.

Dreams(Media Molecule / PlayStation). Dreams는 콘솔 플레이어에게 완전한 3D 제작 도구 모음(모델링, 애니메이션, 음악, 로직, 레벨 디자인)과 창작물을 공유할 플랫폼을 제공했다. 도구의 깊이라는 측면에서는 지금까지 제작된 가장 야심 찬 크리에이터 플랫폼이다.

관련 인사이트:

• 폴리곤 편집 대신 조형 기반 모델링을 사용한다. 크리에이터는 ZBrush와 비슷하지만 더 직관적인 이동, 잡기, 다듬기 도구로 부드러운 볼륨을 빚는다. 학습 곡선이 완만하다. 버텍스와 UV 맵을 이해할 필요가 없으므로 이 접근법은 브라우저 내 제작에 잘 맞는다.
• 모든 것이 공유 에셋이다. 누군가 나무 모델을 만들면 누구나 출처를 표시하고 자신의 창작물에 사용할 수 있다. 각 창작물이 플랫폼의 가치를 더 높이는 복합적인 창작 생태계를 형성한다.
• Dreams는 평단의 호평에도 불구하고 상업적으로 고전했다. 문제는 배포였다. PlayStation에만 제한되었고 제작 도구가 워낙 깊어서 대부분의 플레이어는 콘텐츠 소비에서 제작으로 넘어가지 않았다. 여기서 얻을 수 있는 교훈은 소수만 진지한 빌더가 되더라도 대다수 사용자가 한 번쯤 시도할 만큼 제작 도구가 간단해야 한다는 것이다.

Core(Manticore Games). Unreal Engine을 기반으로 간소화된 에디터를 제공하며 멀티플레이어 게임을 만들고 즐길 수 있는 무료 플랫폼이다. Core의 에디터는 네이티브 앱으로 실행되지만 그 철학은 참고할 만하다. 초보자는 템플릿과 커뮤니티 공유 스크립트를 이용해 미리 만들어진 컴포넌트로 게임을 조립할 수 있다. 숙련된 크리에이터는 Lua 스크립트로 커스텀 동작을 구현할 수 있다. Core는 많은 사용자를 확보하는 데 어려움을 겪었는데, 부분적으로는 Core 런처를 통해서만 게임을 플레이할 수 있었기 때문이다. 브라우저 기반 버전이라면 이런 마찰이 없을 것이다.

VRChat과 Rec Room은 크리에이터가 다른 사람들이 방문할 공간을 만드는 소셜 플랫폼이다. VRChat은 Unity를 사용하며 PC와 VR에서 실행된다. Rec Room은 모바일을 포함한 거의 모든 환경에서 실행된다. 두 플랫폼 모두 사용자 제작 3D 월드가 대규모 커뮤니티를 유지할 수 있음을 입증한다. VRChat은 기술적으로 더 인상적이다(커스텀 셰이더, 복잡한 아바타). Rec Room은 접근성이 더 좋다(앱 내 제작 도구, 단순한 그래픽, 폭넓은 플랫폼 지원). 브라우저 월드에는 VRChat의 외부 도구 워크플로보다 Rec Room의 간단한 앱 내 제작 도구 방식이 더 적합하다.

Second Life: 2003년에 출시되어 지금도 일일 사용자 20만 명 이상과 함께 운영되고 있다. 전적으로 사용자가 제작한다. 구획 기반 소유권과 연간 약 5억 달러 규모의 가상 경제를 갖추고 있다. 지속성과 운영 관리에 관한 20년의 교훈이 축적되어 있다.

Second Life는 모든 크리에이터 월드의 원조다. 2003년에 출시되었고 지금도 일일 활성 사용자 수가 20만 명 이상이다. 월드 전체가 사용자에 의해 만들어진다. 토지를 소유하고 거래할 수 있다. 크리에이터는 오브젝트, 의류, 건물을 판매한다. 월드 내 스크립팅 언어(LSL)를 통해 인터랙티브 콘텐츠를 만들 수 있다.

Second Life가 20년 넘게 전해주는 교훈:

• 지속성은 그래픽보다 중요하다. Second Life의 비주얼은 오래되었지만 월드는 지속된다. 창작물은 배치한 자리에 그대로 남는다. 관계와 역사가 축적된다. 사람들이 계속 돌아오게 만드는 것은 바로 이 지속성이다.
• 경제가 창작을 이끈다. Second Life의 GDP는 연간 5억 달러로 추정된다. 크리에이터는 판매할 수 있기 때문에 만든다. 경제적 인센티브가 없으면 크리에이터 콘텐츠의 양과 품질이 떨어진다.
• 사용자 제작 콘텐츠에는 운영 관리 인프라가 필요하다. Second Life는 20년 동안 운영 관리 문제를 겪어왔다. 사용자가 공유 공간에 임의의 콘텐츠를 배치할 수 있는 모든 플랫폼에는 자동 스캔, 신고 도구, 사람의 검토가 필요하다.
• 토지 기반 공간 구성이 효과적이다. Second Life는 월드를 사용자가 소유하는 구획으로 나눈다. 각 구획에는 프림(오브젝트) 제한이 있다. 이를 통해 한 명의 크리에이터가 모든 리소스를 소모하는 일을 자연스럽게 방지한다. 브라우저 월드에서는 청크 기반 소유권과 청크별 오브젝트 예산이 이에 해당하는 패턴이다.

비교 분석: 각 게임에서 얻을 수 있는 교훈

게임	핵심 교훈	적용 가능한 기술	무시할 경우의 위험
Skyrim	셀 그리드를 활용한 청크 기반 스트리밍	높이맵 지형, LOD 단계, 실내/실외 분리	월드가 브라우저 메모리에 들어가지 않음
The Witcher 3	서로 다른 팀이 제작한 요소를 계층적으로 조합하는 월드 구성	콘텐츠 인식형 스트리밍, 임포스터 렌더링	크리에이터가 독립적으로 작업할 수 없음
Breath of the Wild	스크립트 콘텐츠보다 시스템 규칙이 더 강력함	재질 상호작용 시스템, 물리 기반 게임플레이	월드가 정적이고 생명력 없이 느껴짐
GTA V	주변의 일상이 월드를 현실적으로 만듦	NPC 행동 시스템, 교통, 시간대 변화	크리에이터의 월드가 텅 빈 박물관처럼 느껴짐
Elden Ring	밀도 변화와 에셋 재사용	모듈형 에셋 라이브러리, 저밀도 + 고밀도 구역	지나치게 비어 있거나 채우는 비용이 너무 커짐
No Man's Sky	절차적 생성은 캔버스를 만들고, 크리에이터 콘텐츠는 영혼을 불어넣음	시드 기반 지형, 간결한 기지 데이터 모델	무한하지만 지루한 지형
Minecraft	완전히 편집 가능한 월드, 단순한 도구, 무한한 깊이	청크 스트리밍, 팔레트 압축, 블록 편집 프로토콜	크리에이터가 월드 자체를 바꿀 수 없음
Roblox	엔진 안에서 창작하고, 경제가 품질을 견인함	월드 내 편집기, 크리에이터 수익화	만들 이유가 없어 아무도 제작하지 않음
Krunker.io	단순한 도구로도 브라우저 UGC를 대규모로 운영할 수 있음	Three.js 렌더링, 복셀 기반 편집기, 마켓플레이스	창작 도구가 일반 크리에이터에게 너무 복잡함
Hordes.io	브라우저 3D에서 200명 이상을 지원하며 1인 개발도 가능함	커스텀 WebGL, 공간 컬링, 스타일라이즈드 아트	멀티플레이어 계층을 과도하게 설계함
Vuntra City(네이티브 참고 사례)	속도 인식형 스트리밍과 2단계 월드 시뮬레이션으로 거대한 절차 생성 도시의 일관성을 유지함	속도 연동 LOD 정책, 토폴로지 쿼리 계층, 원거리 일정 시뮬레이션 + 근거리 행동	고속 이동 시 팝인과 시뮬레이션 부하 급증이 발생함
Agar.io / Slither.io	공간 분할로 대규모 동시 접속이 가능해짐	거리에 따른 가변 틱 레이트, 관심 영역 관리	규모가 커지면 네트워크가 붕괴함
Second Life	지속성과 경제가 20년 이상 이어지는 커뮤니티를 지탱함	필지 기반 소유권, 오브젝트 예산, 마켓플레이스	장기 리텐션이 없음
Dreams	조각 방식의 창작이 폴리곤 편집보다 직관적임	볼륨 기반 모델링, 공유 에셋 라이브러리	창작 도구가 CAD 프로그램처럼 느껴짐
Fortnite Creative	전문가용 도구가 전문적인 콘텐츠를 끌어들임	플랫폼 내 완전한 편집기 기능	콘텐츠 품질의 상한이 너무 낮음
RuneScape	Wasm과 바이너리 프로토콜을 통해 브라우저에서도 완전한 MMO를 구현할 수 있음	Emscripten, 커스텀 바이너리 WebSocket 프로토콜, 타일 스트리밍	브라우저의 처리 능력을 과소평가함
Habbo Hotel	단순한 방 꾸미기가 25년간 커뮤니티를 유지함	그리드 기반 배치, 가상 가구 경제	창작 도구를 지나치게 복잡하게 만듦

브라우저 기반, 크리에이터 중심, 멀티플레이어라는 우리의 구체적인 상황에서 가장 중요한 게임은 Minecraft(편집 가능한 월드, 간결한 데이터), Roblox(엔진 내 창작, 경제), Krunker(대규모 브라우저 UGC), Hordes.io(브라우저 MMO 아키텍처)다. AAA 타이틀(Skyrim, BotW, Witcher 3)은 렌더링과 스트리밍을 가르쳐 준다. 브라우저 히트작(Agar.io, Slither.io, Surviv.io)은 대규모 네트워킹을 가르쳐 준다. 크리에이터 플랫폼(Roblox, Dreams, Second Life)은 커뮤니티의 역학을 가르쳐 준다. Vuntra City는 현대적인 절차 생성 도시에서 속도 인식형 스트리밍, 세계관에 자연스럽게 녹아든 내비게이션, 백만 개 에이전트 시뮬레이션 패턴을 구현하는 최신 참고 사례를 제공한다.

Skyrim과 The Witcher를 브라우저로 구현하면 어떤 모습일까

구체적으로 살펴보자. Skyrim의 Whiterun을 브라우저용으로 다시 만든다면 다음과 같다.

지형: Whiterun 주변 지역은 대략 2km x 2km다. 우리의 청크 크기(64m)를 적용하면 약 32x32 = 1024개 청크가 된다. 청크당 높이맵이 2~4KB라면 지형 데이터는 2~4MB다. 잔디, 흙, 바위, 눈으로 구성된 지형 텍스처를 KTX2 아틀라스 타일로 만들면 약 5MB가 추가될 수 있다. 전체 지역의 총 지형 데이터는 10MB 미만이다.

건축물: Whiterun 자체에는 약 40~50채의 건물이 있다. 각 건물을 최적화된 GLB(LOD 3단계)로 만들면 최고 디테일 기준 200~500KB 정도다. 하지만 완전한 디테일이 필요한 것은 가장 가까운 건물 5~10채뿐이다. 나머지는 중간 또는 낮은 LOD로 표시되며 각각 50~100KB 정도다. 어느 순간이든 화면에 보이는 건축물의 총용량은 2~5MB다.

식생: Whiterun 주변의 Skyrim 나무와 풀은 모두 인스턴싱된다. 고유한 나무 모델은 약 10개면 충분하며, 각 모델은 전체 LOD에서 200KB, 빌보드 임포스터에서는 20KB 정도다. 풀잎은 밀도 맵을 바탕으로 GPU에서 생성하는 시스템을 사용한다. 전체 식생 에셋은 2~3MB다. 5x5 청크 영역의 인스턴싱 데이터(위치, 회전, 크기)는 500KB 미만이다.

NPC: Whiterun에는 경비병 외에도 이름이 있는 NPC가 약 70명 있다. 중간 품질의 아바타 하나는 100~200KB다. 하지만 한 번에 보이는 NPC는 10~20명뿐이다. 전체 NPC 렌더링 데이터는 2~4MB다.

어느 순간이든 화면에 보이는 Whiterun 규모 지역의 총데이터는 15~25MB다. 브라우저에서 충분히 실현 가능한 수준이다. 광대역 인터넷에서는 최초 로딩 후 3~5초 안에 지형과 주요 건축물을 표시하고, 이후 몇 초 동안 세부 요소를 채워 넣을 수 있다.

The Witcher 3의 Novigrad는 더 크고 밀도가 높지만 동일한 원칙을 적용할 수 있다. 더 적극적인 LOD와 스트리밍이 필요하겠지만, 어느 순간이든 화면에 보이는 전체 데이터는 브라우저 메모리 한도 내에 유지된다.

가장 먼저 만들 것

완전한 오픈 월드는 여러 해가 걸리는 프로젝트다. 크리에이터가 실제로 사용할 수 있는 무언가를 빠르게 제공하기 위한 경로는 다음과 같다.

1단계: 공유 섬(3개월). 높이맵 지형, 물, 기본 식생, 낮과 밤의 순환을 갖춘 단일 지형 청크(512x512m 섬)다. Durable Objects를 통해 멀티플레이어를 제공한다(동시 사용자 최대 50명). 크리에이터는 기존 Cinevva 라이브러리에서 AI로 생성한 3D 에셋을 배치할 수 있다. 공유 디오라마라고 생각하면 된다.

2단계: 확장 가능한 월드(3개월). 4x4km 월드를 위한 청크 스트리밍을 구현한다. 크리에이터가 소유하고 편집 권한을 갖는 필지를 제공한다. 지형과 오브젝트에 LOD 시스템을 적용한다. 월드 상태를 영구 보존한다. 월드 전체에서 최대 200명의 동시 사용자를 지원한다.

3단계: 살아 있는 월드(6개월). AI 지원 지형 조형 기능을 제공한다. 절차적으로 식생과 분위기를 생성한다. 크리에이터가 정적인 장면뿐 아니라 상호작용형 경험도 만들 수 있도록 퀘스트/이벤트 시스템을 추가한다. 음성 채팅과 아바타 커스터마이징도 제공한다. 월드는 데모가 아니라 사람들이 찾아오는 공간이 된다.

미해결 질문

아트 스타일. 스타일라이즈드(로우 폴리, 셀 셰이딩) 방식은 렌더링 비용이 낮고 AI 생성 에셋의 품질 편차도 더 자연스럽게 수용한다. 사실적인 스타일에는 더 높은 품질의 에셋과 더 많은 렌더링 예산이 필요하다. Skyrim은 그래픽이 오래된 뒤에도 일관된 아트 디렉션 덕분에 성공적으로 보였다. BotW는 셀 셰이딩 스타일로 낮은 폴리곤 수를 감추기 때문에 태블릿급 하드웨어에서도 아름답다. Minecraft는 16x16 텍스처를 사용하면서도 역사상 가장 인지도 높은 게임 중 하나다. Krunker.io와 Hordes.io도 브라우저에서 단순한 스타일라이즈드 그래픽으로 성공했다. 브라우저 월드에는 스타일라이즈드 방향이 훨씬 유리하다는 증거가 압도적이다. 초기에 구체적인 시각적 정체성을 정하고 모든 AI 생성 에셋에 일관되게 적용해야 한다.

월드 지속성 대 인스턴싱. 모두가 하나의 월드를 공유할 것인가(MMO나 Second Life처럼), 아니면 각 크리에이터가 다른 사람들이 방문할 수 있는 자체 인스턴스를 가질 것인가(Minecraft 서버나 Fortnite Islands처럼)? 기술적으로는 두 방식 모두 지원할 수 있지만 사회적 역학은 완전히 다르다. Second Life의 영구적인 공유 월드에서는 걸어 다니다가 다른 사람의 작품을 우연히 발견할 수 있다. Fortnite의 인스턴스형 섬에는 발견을 위한 메뉴나 포털 시스템이 필요하다. Roblox는 허브 기반 방식을 사용한다. 게임은 분리되어 있지만 공유 인터페이스를 통해 탐색하고 발견한다. 하이브리드 방식도 가능하다. 크리에이터가 Second Life의 필지처럼 구역을 소유하는 영구 공유 오버월드를 만들고, 포털을 통해 독립적인 경험으로 들어갈 수 있게 하는 것이다.

창작 도구의 깊이. Dreams는 깊이 있는 창작 도구가 평론가에게 깊은 인상을 주지만 사용자를 위축시킬 수 있다는 점을 입증했다. Townscaper는 최소한의 도구로도 100만 장을 판매할 수 있음을 보여줬다. Roblox Studio는 그 중간에 있다. 어린이도 사용할 만큼 간단하면서 전문가가 활용할 만큼 깊이 있다. Krunker의 복셀 편집기는 이보다도 단순하다. 브라우저 월드에서는 Townscaper 수준의 단순함(오브젝트를 배치하면 자동으로 맞물리고 연결되는 방식)으로 시작하고 시간이 지나면서 깊이를 더해야 한다. 사용자가 월드에 첫 오브젝트를 배치하는 최초 경험은 30초 이내에 완료되어야 한다.

경제. Roblox, Second Life, Fortnite Creative는 모두 경제적 인센티브가 장난감을 플랫폼으로 바꾸는 핵심임을 입증한다. 크리에이터가 자신의 작업으로 수익을 얻을 방법이 없다면 가장 재능 있는 크리에이터는 다른 곳에서 만들 것이다. 첫날부터 출시할 필요는 없지만 아키텍처는 이를 지원해야 한다(오브젝트 소유권, 방문 추적, 크리에이터 귀속 표시).

모바일. 모바일 WebGPU가 안정적으로 자리 잡으려면 아직 몇 년이 더 필요하다. 모바일 경험은 더 단순한 지형, 더 적은 오브젝트, 더 짧은 가시 거리를 사용하는 축소판이어야 한다. 적응형 품질로 모든 기기에서 실행하는 Rec Room의 접근 방식은 연구할 가치가 있다. 또는 모바일에는 네이티브 앱을 출시하고 브라우저에는 완전한 경험을 유지할 수 있다.

모더레이션. 누구나 무엇이든 배치할 수 있는 오픈 월드는 모더레이션의 악몽이다. Second Life는 20년 동안 이 문제를 다뤄 왔다. 배치된 모든 에셋은 다른 사용자에게 표시되기 전에 자동 콘텐츠 검토를 거쳐야 한다. 이는 창작 과정에 지연을 더하지만 타협할 수 없는 요구 사항이다. 크리에이터가 콘텐츠의 범위를 선택할 수 있도록 필지 기반 콘텐츠 등급(Second Life의 General/Moderate/Adult 시스템과 같은 방식)도 고려해야 한다.

시스템적 상호작용. BotW와 Minecraft는 모두 재질 기반 상호작용 시스템이 정적인 오브젝트 배치보다 기하급수적으로 흥미로운 월드를 만든다는 사실을 보여준다. 한 크리에이터가 나무다리를 배치하고 다른 크리에이터가 근처에 불을 피우면 다리가 타야 할까? 누군가 댐을 설치하면 그 뒤로 물이 고여야 할까? 이런 상호작용은 월드에 생명력을 불어넣지만, 모든 크리에이터 콘텐츠에 일관된 물리 및 재질 규칙을 적용해야 한다. 시스템 설계를 어디까지 확장할지는 초기에 내려야 할 아키텍처 결정이다.

핵심 요점

브라우저 3D 오픈 월드는 현재 실현 가능하다. Hordes.io는 브라우저의 3D 환경에서 200명 이상의 플레이어를 지원한다. Krunker.io는 완전한 3D 맵 편집기를 제공하면서 월간 플레이어 1,000만 명을 달성했다. .io 게임들은 브라우저 멀티플레이어가 수백만 명 규모로 확장될 수 있음을 입증했다. 이 기술은 가설이 아니다.

렌더링 기술은 준비되어 있다. Three.js와 Babylon.js는 2010년대 초반 AAA 게임에 준하는 3D 장면을 처리한다. WebGPU는 지형과 식생을 위한 컴퓨트 셰이더를 가능하게 한다. Wasm 물리 엔진은 네이티브 대비 2~3배 이내의 성능으로 실행된다. Whiterun 규모의 지역은 15~25MB의 가시 데이터로 표현할 수 있다.

네트워킹 기술도 준비되어 있다. Cloudflare Durable Objects를 사용하면 엣지에서 청크별 권위 서버를 운영할 수 있다. CRDT는 충돌 없는 공동 편집을 처리한다. Agar.io부터 Skyrim까지 모든 게임에서 검증된 공간 분할은 동시 접속자가 수백 명이어도 네트워크 트래픽을 관리 가능한 수준으로 유지한다.

AAA 오픈 월드(Skyrim, Witcher 3, BotW, Elden Ring, Minecraft, No Man's Sky)는 단순한 그래픽 벤치마크가 아니다. 이들은 청크 스트리밍, LOD 관리, 절차적 생성, 시스템 설계, 월드 구성에 관한 교과서다. 이들이 사용하는 모든 기술에는 브라우저 호환 방식이 존재한다.

크리에이터 플랫폼(Roblox, Second Life, Fortnite Creative, Dreams)은 사회적·경제적 교훈을 준다. 창작은 외부 도구가 아니라 월드 안에서 이루어져야 한다. 경제적 인센티브가 품질을 견인한다. 지속성은 애착을 만든다. 단순한 도구가 강력한 도구보다 더 많은 크리에이터에게 도달한다.

크리에이티브 파이프라인은 Cinevva가 우위를 가진 영역이다. 우리는 이미 3D 에셋, 텍스처, 오디오를 생성하고 있다. 부족한 부분은 이 파이프라인을 월드 배치 시스템에 연결하는 것이다. AI 생성 콘텐츠가 월드를 채우고, 크리에이터의 큐레이션과 배치가 그곳에 영혼을 불어넣는다.

최종 결과물은 브라우저 속 Skyrim이 아니다. 편집 가능한 월드인 Minecraft, 크리에이터 경제를 갖춘 Roblox, 시스템적 상호작용을 제공하는 BotW의 교차점에 더 가깝다. AI 기반 창작 도구와 함께 브라우저 탭에서 실행되는 형태다. 이를 구축할 기술은 이미 존재한다. 남은 문제는 실행력이다.

연구 논문 및 학술 참고 자료

이 가이드의 기술은 처음부터 새로 발명한 것이 아니다. 수십 년에 걸친 연구에 기반한다. 다음은 각 하위 시스템에서 가장 중요한 논문과 브라우저 오픈 월드에 적용하는 방법에 관한 설명이다.

지형 생성 및 렌더링

"An Image Synthesizer" -- Ken Perlin (SIGGRAPH 1985). DOI. Perlin 노이즈를 소개한 논문이다. 1985년 이후 모든 게임의 모든 절차적 지형 생성기는 이 연구에 뿌리를 두고 있다. 이 노이즈 함수는 부드러운 무작위성을 생성하며, 이를 여러 옥타브로 중첩하면(프랙셔널 브라운 운동) 자연스러운 높이맵을 만들 수 있다. Simplex 노이즈(Perlin, 2001)는 더 빠른 후속 기법이다. 이것이 우리 지형 파이프라인의 기반이다. 노이즈 기반 높이맵 생성은 WebGPU 컴퓨트 셰이더에서 상호작용 가능한 속도로 실행된다.

"Texturing and Modeling: A Procedural Approach" -- Ebert, Musgrave, Peachey, Perlin, Worley (1994, 3rd edition 2003). 절차적 생성에 관한 교과서다. 침식과 유사한 특징을 갖는 다중 프랙털 지형을 비롯해 Musgrave가 집필한 지형 모델링 장은 현대 게임 지형 생성기의 직접적인 기반이다. 여기서 설명하는 fBm 매개변수(라쿠나리티, 지속성, 옥타브 수)는 크리에이터에게 지형 커스터마이징용으로 제공할 수 있는 것과 동일하다.

"Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids" -- Losasso and Hoppe (SIGGRAPH 2004). DOI. 이 논문은 동심형 LOD 링인 클립맵을 사용해 거대한 지형을 상호작용 가능한 속도로 렌더링하는 방법을 제시했다. 지형 메시는 카메라를 중심으로 배치된 고정된 중첩 그리드 집합이다. 카메라가 움직이면 그리드도 이동하며 업데이트된다. 이는 지형 섹션에서 WebGL 2용으로 권장한 기술이며, 월드 크기와 관계없이 GPU 작업량이 일정하기 때문에 효과적이다. 원래 구현은 WebGL보다 앞서 등장했지만 WebGL에 그대로 대응시킬 수 있다. "GPU 기반의 고속 수력 침식 시뮬레이션 및 시각화" -- Mei, Decaudin, Hu (2007). PDF. CPU 중심의 오프라인 작업이었던 수력 침식을 실시간 GPU 연산으로 전환했다. 이 논문의 천수 시뮬레이션 모델은 물을 높이 필드로 취급하고 그리드 셀 사이의 흐름을 계산하며, 컴퓨트 셰이더에서 실행된다. 우리 파이프라인에서는 서버 측 GPU 침식을 통해 노이즈로 생성한 지형을 1초 이내에 지질학적으로 그럴듯한 경관으로 변환할 수 있어, AI 생성 지형이 수작업으로 조형된 것처럼 보이게 할 수 있다.

"절차적으로 생성된 행성의 실시간 렌더링" -- No Man's Sky의 GDC 강연과 Sean Murray의 설명에서 제시된 하이브리드 접근법. 단일 논문은 아니지만, Innes McKendrick(Hello Games)의 GDC 2017 강연 "수학으로 세계 만들기"에서는 No Man's Sky가 중첩된 노이즈 함수, 마칭 큐브를 사용하는 복셀 표현, GPU 측 생성을 통해 행성 규모의 지형을 생성하는 방식을 자세히 설명한다. 이는 우리 절차적 지형 접근법과 직접적인 관련이 있으며, 특히 높이맵으로 표현할 수 없는 지형 요소인 동굴과 아치를 생성하는 데 유용하다.

"C-DBLOD: 지형 렌더링을 위한 하이브리드 LOD" -- Filip Strugar (2014). 논문. 카메라 위치 주변에서 적응성을 높이기 위해 쿼드트리 기반 선택을 추가한 지오메트리 클립맵 개선 기법이다. 핵심은 고정된 동심원 링 대신 쿼드트리를 사용해 서로 다른 해상도의 지형 패치를 선택하는 것이다. 일부 영역이 다른 영역보다 더 많은 디테일을 필요로 하는 불규칙한 지형을 순수 클립맵보다 효과적으로 처리한다. 작은 CPU 측 쿼드트리 순회만으로 WebGL 2에서 구현할 수 있다.

3D 가우시안 스플래팅과 뉴럴 렌더링

"실시간 방사장 렌더링을 위한 3D 가우시안 스플래팅" -- Kerbl, Kopanas, Leimkühler, Drettakis (SIGGRAPH 2023). 프로젝트 페이지. 가우시안 스플래팅 혁명을 촉발한 논문이다. 장면은 각각 위치, 공분산(형상), 불투명도, 구면 조화 색상 계수를 가진 수백만 개의 3D 가우시안으로 표현된다. 렌더링 과정에서는 스플랫을 깊이순으로 정렬하고 2D 가우시안으로 래스터화한다. 이 접근법은 NeRF보다 학습 속도가 100~1,000배 빠르며 실시간으로 렌더링된다. 여러 WebGL/WebGPU 구현이 존재한다. 우리 플랫폼에서는 크리에이터가 휴대폰 사진으로 현실 세계의 사물을 캡처해 브라우저 월드에 배치할 수 있게 해준다.

"NeRF: 뷰 합성을 위한 뉴럴 방사장 기반 장면 표현" -- Mildenhall et al. (ECCV 2020). 프로젝트 페이지. 뉴럴 장면 표현의 토대를 마련한 논문이다. 신경망이 3D 좌표를 색상과 밀도로 매핑하여 입력 사진 세트로부터 사실적인 새로운 시점의 영상을 합성한다. NeRF는 픽셀마다 신경망을 평가해야 하므로 브라우저에서 직접 렌더링하기에는 연산 비용이 너무 크지만, NeRF를 학습한 뒤 밀도 필드에 마칭 큐브를 적용하는 NeRF-메시 추출 파이프라인을 사용하면 사진으로부터 고품질 텍스처 메시를 만들 수 있다.

"다중 해상도 해시 인코딩을 활용한 즉시 뉴럴 그래픽 프리미티브" -- Müller, Evans, Schied, Keller (SIGGRAPH 2022). 프로젝트 페이지. 공간 인코딩에 다중 해상도 해시 테이블을 사용하여 NeRF 학습 시간을 수 시간에서 수 초로 단축했다. 이를 통해 NeRF를 실제 제작 환경에서 활용할 수 있게 되었다. 해시 인코딩 기법은 브라우저 월드의 다른 공간 데이터에도 적용할 수 있다. 예를 들어 대규모 3D 데이터세트에서 빠른 조회를 구현할 수 있다.

"Neuralangelo: 고정밀 뉴럴 표면 재구성" -- Li et al. (CVPR 2023). 프로젝트 페이지. 다중 해상도 해시 인코딩과 SDF(부호 거리 함수) 추정을 위한 수치 미분을 사용해 뉴럴 표현에서 고품질 삼각형 메시를 추출한다. 출력 메시는 브라우저 3D 엔진에서 직접 사용할 수 있다. 우리 에셋 파이프라인에서는 Neuralangelo 또는 NeuS2 같은 유사 도구를 통해 NeRF 캡처를 깔끔한 지오메트리와 베이크된 텍스처를 갖춘 웹용 GLB 파일로 변환할 수 있다.

멀티플레이어 네트워킹과 상태 동기화

"대규모 멀티플레이어 온라인 게임의 관심 영역 관리" -- Boulanger, Kienzle, Verbrugge (2006). DOI. MMO를 위한 관심 영역(AOI) 관리 기법을 포괄적으로 조사한 연구다. 공간적 관련성을 기준으로 네트워크 업데이트를 필터링하는 그리드 기반, 오라 기반, 하이브리드 접근법을 다룬다. 우리 청크 시스템에 대응하는 그리드 기반 접근법은 밀도가 균일한 월드에서 가장 효율적이다. 엔티티별 영향 반경을 사용하는 오라 기반 접근법은 밀도가 가변적인 환경에서 더 효과적이다. AOI 내부에서 우선순위 기반 업데이트 주기를 적용하는 청크 기반 AOI 권장안은 이 연구를 바탕으로 한다.

"추측 항법: 네트워크 게임의 지연 은폐" -- Pantel and Wolf (2002). DOI. 네트워크 게임에서 마지막으로 알려진 속도를 바탕으로 엔티티 위치를 예측하는 추측 항법을 정식화했다. 이 논문은 예측 임계값이 높을수록 대역폭은 줄지만 위치 보정 시 눈에 띄는 오차가 커진다는 상충 관계를 정량화한다. 지연 시간이 50~200ms인 브라우저 게임에서는 예측 임계값을 0.5~1.0미터로 설정하면 위치 업데이트 대역폭을 60~80% 줄이면서도 보정이 눈에 띄지 않게 유지할 수 있다.

"충돌 없는 복제 데이터 타입" -- Shapiro, Preguiça, Baquero, Zawirski (2011). DOI. CRDT의 토대를 마련한 논문이다. 조정 없이도 동일한 상태로 수렴하는 상태 기반 및 연산 기반 CRDT를 정의한다. 우리 월드 편집 시스템과 관련된 CRDT는 위치, 회전, 색상처럼 단일 값을 갖는 객체 속성을 위한 LWW-Register(최종 작성자 우선 레지스터)와, 청크 안의 객체 컬렉션을 위한 OR-Set(관찰 후 제거 집합)이다. OR-Set은 동시에 발생하는 추가와 제거를 충돌 없이 처리한다. Yjs는 이를 JavaScript에서 효율적으로 구현한다.

"Time Warp: 분산 시뮬레이션을 위한 메커니즘" -- Jefferson (1985). DOI. 낙관적 분산 시뮬레이션을 처음 제시한 논문이다. Time Warp 자체는 브라우저 게임에 적용하기에는 너무 복잡하지만, 이벤트를 낙관적으로 처리한 뒤 다른 노드에서 충돌이 전달되면 롤백한다는 핵심 개념은 서버 조정을 수반하는 현대적인 클라이언트 측 예측의 기반이다. 모든 반응성 높은 멀티플레이어 게임이 이 방식으로 작동한다. 클라이언트는 로컬에서 결과를 예측하고 행동을 서버로 전송한 뒤, 서버의 결과가 다르면 이를 보정한다.

"TRIBES 엔진 네트워킹 모델" -- Frohnmayer and Gift (GDC 1999). 관심 영역 관리, 우선순위 기반 상태 업데이트, 대역폭 예산을 포함하는 클라이언트-서버 게임 네트워킹을 최초로 실용적으로 설명한 자료 중 하나다. "고스트 관리자" 개념은 서버가 각 클라이언트가 알고 있는 정보의 뷰를 유지하고 그 뷰와의 차이만 전송하는 것으로, 우리 청크 기반 Durable Object 아키텍처가 구현하는 방식과 정확히 일치한다. 이 GDC 강연은 현대 게임 네트워킹 대부분의 지적 선구자다.

"Source 멀티플레이어 네트워킹" -- Valve (2009). 개발자 문서. Half-Life 2, CS:GO, Team Fortress 2에 사용된 Source 엔진 네트워킹 모델에 관한 Valve의 문서다. 클라이언트 측 예측, 엔티티 보간, 지연 보상, 그리고 서버가 일정한 간격으로 전체 월드 상태를 전송하고 클라이언트가 스냅샷 사이를 보간하는 "스냅샷" 시스템을 다룬다. 권위적 서버 네트워킹의 모범 사례이며 우리 아키텍처에 직접 적용할 수 있다.

절차적 생성

"모델 합성: 범용 절차적 모델링 알고리즘" -- Merrell (2007). DOI. 웨이브 함수 붕괴의 전신 중 하나다. 예제 모델에서 지역적 제약 조건을 전파하여 3D 구조물을 생성한다. 이 알고리즘은 가능한 상태가 가장 적은 셀을 반복적으로 확정하는 최소 엔트로피 휴리스틱을 통해 전역 일관성을 보장한다. Townscaper와 유사한 생성기가 간단한 사용자 입력으로 일관성 있는 구조물을 만드는 방식이 바로 이것이다.

"WaveFunctionCollapse" -- Maxim Gumin (2016). GitHub. 전통적인 논문은 아니지만 방대한 문서를 갖춘 기념비적인 오픈 소스 프로젝트다. 이 알고리즘은 작은 예제 이미지나 타일셋을 입력받아 입력과 지역적으로 유사한 더 큰 결과물을 생성한다. 크리에이터 월드에서 WFC는 크리에이터가 정의한 소규모 규칙 세트로 건물 배치, 도로망, 던전 맵, 지형 디테일을 생성할 수 있다. 여러 JavaScript 구현이 존재한다.

"웨이브 함수 붕괴는 실전 제약 조건 해결이다" -- Karth and Smith (FDG 2017). DOI. WFC와 제약 충족 문제의 관계를 명확히 밝히고 이를 분석하고 확장하는 방법을 보여주는 학술 연구다. WFC가 교착 상태에 빠져 백트래킹이 필요할 수 있다는 한계와 이러한 문제를 방지하는 타일셋 설계법을 이해하는 데 유용하다.

"중첩 원리와 게임 콘텐츠 절차적 생성에 대한 함의" -- Sandhu et al. (2022). 절차적 콘텐츠 생성에 양자역학에서 영감을 받은 중첩 개념을 활용하는 방안을 탐구한다. 추측적인 연구이기는 하지만, 최종 구성으로 "붕괴"하기 전에 여러 가능한 상태를 유지하는 수학적 프레임워크는 WFC의 작동 방식과 정확히 같으며, 더 정교한 생성 시스템을 설계하는 데 참고할 수 있다.

실시간 렌더링 기법

"실시간 렌더링" -- Akenine-Möller, Haines, Hoffman (4판, 2018). 이 분야의 표준 교과서다. 특히 19장(가속 구조), 20장(효율적인 셰이딩), 21장(가상 현실과 증강 현실)이 관련성이 높다. 여기서 설명하는 절두체 컬링, 오클루전 컬링, LOD 알고리즘은 Three.js, Babylon.js를 비롯한 모든 게임 엔진이 구현하는 기법이다. 논문은 아니지만 가장 권위 있는 참고 자료다.

"실시간 뷰 합성을 위한 뉴럴 방사장 베이킹 연구 동향" -- Reiser et al. (2023). DOI. NeRF를 실시간 렌더링 가능한 형식인 메시, 텍스처, 희소 복셀 그리드로 변환하는 방법을 조사한다. 서버 측 뉴럴 캡처를 브라우저에서 렌더링 가능한 결과물로 변환해야 하는 우리 에셋 파이프라인과 직접적인 관련이 있다.

"3D 가우시안 스플래팅을 사용한 확장 가능하고 정확한 온라인 특징 매칭" -- 여러 연구 그룹 (2024-2025). 최근 여러 논문이 가우시안 스플랫을 활용한 편집, 합성, 동적 장면을 탐구하고 있다. 크리에이터 월드에서는 여러 스플랫 장면, 즉 각 크리에이터가 캡처한 객체를 하나의 일관된 장면으로 합성해야 하므로 관련성이 높다. 스플랫 편집 방법인 색상 변경, 변형, 합성은 활발히 연구되고 있는 분야다.

"효율적인 GPU 화면 공간 광선 추적" -- McGuire and Mara (JCGT 2014). DOI. 물 렌더링 섹션에서 사용하는 화면 공간 반사의 기반이 된 논문이다. 전체 광선 추적에 드는 비용 없이 근사 반사를 만들기 위해 깊이 버퍼를 따라 광선을 추적한다. 최소-최대 깊이 밉맵을 사용하는 "계층적 추적" 변형은 WebGL 2에서 효율적으로 실행된다.

"해양 수면 시뮬레이션" -- Jerry Tessendorf (2001). PDF. FFT 기반 해양 시뮬레이션의 토대를 마련한 논문이다. 해양 파도의 통계적 모델인 Phillips 스펙트럼과 역 FFT를 통해 이를 공간 변위 맵으로 변환하는 방법을 설명한다. 사실적인 바다를 구현한 모든 주요 게임인 Sea of Thieves, Assassin's Creed, Uncharted에서 사용된다. FFT 연산은 WebGPU 컴퓨트 셰이더에 자연스럽게 대응한다.

"사전 계산된 대기 산란" -- Bruneton and Neyret (EGSR 2008). DOI. 물리적으로 정확한 하늘 렌더링의 기반이 된 논문이다. 대기 산란을 룩업 테이블에 사전 계산하고 프래그먼트 셰이더가 실시간으로 샘플링하도록 한다. 제1원리만으로 정확한 하늘 색상, 대기 원근법, 즉 멀리 있는 물체가 푸르스름하고 흐릿하게 보이는 현상과 일출 및 일몰 색상을 구현한다. 사전 계산된 테이블은 수백 KB 정도로 작고 런타임 셰이더의 연산 비용도 낮다. Three.js의 Sky 셰이더와 Babylon.js의 절차적 하늘은 모두 이 접근법을 단순화한 버전이다.

"앰비언트 오클루전 볼륨" -- McGuire (HPG 2010) 및 "확장 가능한 앰비언트 옵스큐런스" -- McGuire, Mara, Luebke (HPG 2012). PDF. 현대적인 SSAO 구현의 기반이 된 논문들이다. SAO는 픽셀당 한 번만 깊이 버퍼를 샘플링하므로 효율적이고 그럴듯한 접촉 그림자를 만들 수 있어 브라우저 3D 엔진에서 가장 흔히 구현되는 변형이다. 이 알고리즘은 각 픽셀 주변의 깊이 버퍼를 샘플링해 인근 지오메트리에 의해 얼마나 "가려져" 있는지 추정한다. Three.js와 Babylon.js 모두 SAO에서 파생된 SSAO를 구현한다.

군중 렌더링과 애니메이션

"GPU 군중 렌더링" -- Dudash (2007) 및 인스턴싱 기반 군중 렌더링을 다룬 이후의 GDC/SIGGRAPH 발표들. 핵심 기법은 스켈레탈 애니메이션 프레임을 텍스처인 정점 애니메이션 텍스처로 베이크한 뒤, 각 인스턴스가 현재 프레임을 기준으로 애니메이션 텍스처에서 본 변환을 읽도록 하여 군중을 인스턴스 메시로 렌더링하는 것이다. 이를 통해 애니메이션 평가와 드로 콜을 분리하여 단 하나의 인스턴스 드로 콜로 서로 다른 애니메이션을 재생하는 수백 명의 캐릭터를 렌더링할 수 있다.

"위치 기반 동역학" -- Müller et al. (2007). DOI. 현대 게임 엔진에서 천, 머리카락, 연체를 시뮬레이션하는 방식인 PBD의 토대를 마련한 논문이다. 우리가 권장하는 Wasm 물리 엔진인 Rapier는 PBD에서 파생된 솔버를 사용한다. 망토, 흩날리는 머리카락, 헐렁한 의상 같은 아바타 커스터마이징 요소에 PBD를 적용하면 게임 프레임 속도에서도 반응성 높은 시뮬레이션을 구현할 수 있다. Wasm 구현을 사용하면 이 연산을 메인 JavaScript 스레드 밖에서 처리할 수 있다. "FABRIK: 역운동학 문제를 위한 빠른 반복형 솔버" -- Aristidou와 Lasenby(2011). DOI. 아바타 섹션에서 권장한 IK 솔버의 기반이 된 논문입니다. FABRIK은 말단 작동기에서 루트로, 다시 루트에서 말단 작동기로 번갈아 도달하는 방식으로 작동하며 3~5회 반복 후 수렴합니다. 야코비안 기반 IK보다 빠르고 관절 제약을 자연스럽게 처리하며, 구현도 간단합니다(기본 솔버는 약 50줄의 코드). Three.js와 Babylon.js의 IK 구현은 모두 FABRIK에서 파생되었습니다.

가상 세계와 협업 환경

"대규모 다중 사용자 온라인 게임: 최신 기술 현황 조사" -- Yahyavi와 Kemme(2013). DOI. 클라이언트-서버 모델, 피어 투 피어 접근 방식, 관심 영역 관리, 일관성 모델, 확장성 기법, 부정행위 방지 등을 다루는 MMO 아키텍처 종합 조사입니다. 일관성 모델 분류(강한 일관성, 최종 일관성, 인과적 일관성)는 벡터 시계를 통한 인과적 순서를 갖춘 최종 일관성이라는 우리의 CRDT 기반 접근 방식과 연결됩니다.

"인터넷상의 멀티플레이어 상호작용형 애플리케이션을 위한 분산 아키텍처" -- Diot와 Gautier(1999). DOI. 핵심적인 긴장 관계를 규명한 분산 가상 환경에 관한 초기 연구입니다. 강한 일관성에는 조정이 필요해 지연 시간이 늘어나지만, 약한 일관성은 반응성을 높이는 대신 눈에 띄는 불일치가 발생할 위험이 있습니다. 이 논문은 절충안으로 원격 업데이트가 도착할 시간을 확보하기 위해 로컬 표시를 약간 늦추는 "로컬 지연"을 제안합니다. 오브젝트 배치 같은 월드 편집에서 100~200ms의 로컬 지연은 체감하기 어려우면서도 서버가 검증할 시간을 제공합니다.

"세컨드 라이프 그리드: 준현대적 오픈 소스 가상 세계의 아키텍처" -- Linden Lab 기술 문서 및 커뮤니티 리버스 엔지니어링. 단일 논문은 아니지만 세컨드 라이프 아키텍처에 대한 기술 분석은 광범위하게 문서화되어 있습니다. 핵심 통찰은 다음과 같습니다. 각 256x256m 지역은 전용 서버 인스턴스에서 실행됩니다. 오브젝트는 변환, 텍스처, 스크립트를 가진 기본 도형인 "프리미티브" 트리로 저장됩니다. 뷰어는 필요에 따라 오브젝트 설명과 텍스처를 스트리밍합니다. 오브젝트별 영속성을 갖춘 이 구획 기반 모델은 우리가 구축하는 것과 가장 가까운 기존 아키텍처이며, 세컨드 라이프가 20년 넘게 운영되었다는 사실은 이 모델의 확장성을 입증합니다.

웹 그래픽과 브라우저 성능

"WebGPU: 웹을 위한 고성능 그래픽 API" -- W3C GPU for the Web Working Group(2023~현재). 명세. WebGPU의 공식 명세입니다. 연구 논문은 아니지만 브라우저 GPU 프로그래밍을 위한 가장 권위 있는 기술 문서입니다. 컴퓨트 셰이더 명세(섹션 23)는 이 가이드 전반에서 설명하는 지형 생성, 식생 배치, 파티클 시스템과 특히 관련이 깊습니다.

"WebAssembly: 브라우저에서 컴파일된 코드를 실행하기 위한 프레임워크" -- Haas 외(PLDI 2017). DOI. 브라우저 공급업체들이 발표한 최초의 WebAssembly 논문입니다. Wasm이 연산 집약적 워크로드에서 네이티브 성능의 2배 이내 수준을 달성한다는 점을 보여줍니다. 이는 브라우저 오픈 월드에 Wasm으로 컴파일된 물리 엔진(Rapier, Havok)을 사용하라는 우리의 권장 사항을 뒷받침합니다. 논문의 성능 분석에 따르면 오버헤드는 주로 컴파일 모델 자체가 아니라 경계 검사와 간접 함수 호출에서 발생합니다.

"그렇게 빠르지는 않다: WebAssembly와 네이티브 코드의 성능 분석" -- Jangda 외(USENIX ATC 2019). PDF. Wasm과 네이티브 성능을 엄밀하게 비교한 벤치마크입니다. SPEC CPU 벤치마크 제품군 전체에서 Wasm이 평균적으로 네이티브 C보다 1.45~1.55배 느리다는 결과를 제시합니다. 게임 물리처럼 부동소수점 연산 비중이 높고 시스템 호출이 적은 경우에는 오버헤드가 더 낮은 수준인 약 1.3배입니다. 이는 브라우저의 Wasm 물리가 실시간 게임 워크로드에 충분히 실용적이라는 점을 확인해 줍니다.

"WebAssembly로 웹 성능 끌어올리기" -- Rossberg 외(2018). DOI. WebAssembly의 설계 근거와 형식 의미론을 설명합니다. 특히 메모리 안전성 보장에 관한 논의(섹션 3)는 네이티브 플러그인의 보안 위험 없이 Wasm 모듈이 JavaScript와 브라우저 탭을 안전하게 공유할 수 있는 이유를 설명한다는 점에서 중요합니다. 덕분에 전통적으로 C++ 라이브러리였던 물리 엔진을 브라우저에서 안전하게 실행할 수 있습니다.

AI 기반 콘텐츠 생성

"2D 및 3D 사전 지식을 모두 사용하는 양방향 확산 기반 텍스트-투-3D 생성" -- 여러 연구 그룹(2023~2025). 여러 최신 논문(DreamFusion, Magic3D, ProlificDreamer, MVDream, Zero-1-to-3++)은 2D 확산 모델을 3D 최적화의 사전 지식으로 활용해 텍스트 프롬프트로부터 3D 에셋을 생성하는 방법을 탐구합니다. 품질은 2023년 초의 뭉툭한 형태에서 2025년의 디테일하고 텍스처가 적용된 메시로 크게 향상되었습니다. 우리 플랫폼에서는 GPU 서버에서 실행되는 이러한 모델이 크리에이터 에셋 파이프라인의 "AI 생성" 단계를 담당합니다.

"DreamFusion: 2D 확산을 활용한 텍스트-투-3D" -- Poole 외(ICLR 2023). 프로젝트 페이지. 사전 학습된 2D 확산 모델로 3D 최적화를 유도하는 점수 증류 샘플링(SDS)의 기반이 된 논문입니다. 핵심 통찰은 기존 2D 모델로 3D 오브젝트의 렌더링된 뷰가 텍스트 프롬프트와 일치하는지 평가할 수 있다면 3D 학습 데이터가 필요하지 않다는 것입니다. 이는 텍스트-투-3D 생성의 길을 열었으며, 품질과 속도를 향상한 후속 연구(Magic3D, ProlificDreamer)의 기반이 되었습니다.

"LRM: 단일 이미지에서 3D를 생성하는 대규모 재구성 모델" -- Hong 외(ICLR 2024). 프로젝트 페이지. 단일 GPU에서 하나의 이미지로부터 5초 만에 3D 모델을 재구성합니다. 모델은 메시로 변환할 수 있는 NeRF 유사 표현을 출력합니다. 크리에이터 월드에서는 크리에이터가 현실의 어떤 사물이든 사진을 찍어 몇 초 안에 3D 모델을 얻을 수 있다는 의미입니다. 이 속도라면 배치 프로세스가 아닌 상호작용형 도구로 활용할 수 있습니다.

"머신러닝을 통한 절차적 콘텐츠 생성(PCGML)" -- Summerville 외(2018). DOI. 게임의 절차적 콘텐츠 생성에 머신러닝을 활용하는 방법을 조사한 논문입니다. 레벨 생성, 아이템 생성, 서사 생성, 월드 생성을 다룹니다. 특히 디자이너가 상위 수준의 매개변수를 설정하면 ML 모델이 세부 사항을 채우는 "제어 가능한 생성"에 대한 논의가 중요합니다. 이것이 바로 AI 보조 월드 빌딩의 패러다임입니다. 크리에이터가 의도("이 지역을 으스스한 숲으로 만들어 줘")를 정하면 AI가 지오메트리, 텍스처, 오브젝트 배치를 채웁니다.

이 논문들이 우리 아키텍처와 연결되는 방식

이 연구들은 다음과 같이 우리 아키텍처의 각 계층에 대응합니다.

지형 파이프라인: Perlin/심플렉스 노이즈(Perlin 1985, 2001)가 기본 높이 맵을 생성합니다. 수력 침식(Mei 외 2007)이 지질학적 사실성을 더합니다. 지오메트리 클립맵(Losasso와 Hoppe 2004) 또는 CDLOD(Strugar 2014)가 브라우저에서 지형을 효율적으로 렌더링합니다. 대기 산란(Bruneton과 Neyret 2008)은 멀리 있는 지형을 자연스럽게 보이게 합니다.

에셋 파이프라인: 텍스트-투-3D(DreamFusion 외)와 이미지-투-3D(LRM)가 서버 측에서 에셋을 생성합니다. 가우시안 스플래팅(Kerbl 외 2023)은 포토그래메트리 캡처를 지원합니다. Neuralangelo(Li 외 2023)는 신경망 기반 캡처에서 깔끔한 메시를 추출합니다. 모든 출력은 브라우저에서 바로 사용할 수 있는 GLB/KTX2로 처리됩니다.

렌더링: SSAO(McGuire 2012)가 깊이감을 더합니다. 스크린 공간 반사(McGuire와 Mara 2014)가 물 표현을 구현합니다. FFT 해양 시뮬레이션(Tessendorf 2001)이 물을 시뮬레이션합니다. 버텍스 애니메이션 텍스처(Dudash 2007)가 군중을 렌더링합니다. FABRIK(Aristidou와 Lasenby 2011)이 캐릭터 IK를 구동합니다.

네트워킹: 관심 영역 관리(Boulanger 외 2006)가 공간적 관련성에 따라 업데이트를 필터링합니다. 추측 항법(Pantel과 Wolf 2002)이 대역폭 사용량을 줄입니다. CRDT(Shapiro 외 2011)가 협업 편집을 처리합니다. 서버 조정이 결합된 클라이언트 예측(Jefferson 1985, Valve Source Networking)이 뛰어난 반응성을 제공합니다.

월드 생성: WFC(Gumin 2016, Karth와 Smith 2017)가 구조물과 레이아웃을 생성합니다. PCGML(Summerville 외 2018)은 크리에이터가 의도를 설정하고 모델이 세부 사항을 채우는 AI 보조 생성의 프레임워크를 제공합니다.

이 연구 분야는 이미 성숙했습니다. 이러한 기법 대부분은 수년 동안 출시된 게임에서 사용되어 왔습니다. 이를 브라우저로 가져오는 데 필요한 혁신은 알고리즘 자체가 아닙니다. 핵심은 브라우저의 메모리, GPU, 네트워크 제약 안에서 작동하도록 엔지니어링하는 것이며, 이 가이드의 나머지 부분에서는 바로 그 내용을 다룹니다.

더 읽어보기

• 2026년 웹 게임 기술 스택에서는 WebGL, WebGPU, WebAssembly의 기초를 다룹니다
• 웹 게임 엔진 비교에서는 브라우저 배포에 적합한 엔진을 비교합니다
• Three.js + USDC 기술 보고서에서는 브라우저에서 3D 에셋을 로드하는 방법을 설명합니다
• 최첨단 오픈 소스 생성형 AI 모델에서는 AI 생성 파이프라인을 다룹니다
• 협동 게임 디자인에서는 플레이어의 몰입을 유지하는 멀티플레이어 디자인 패턴을 설명합니다
• 브라우저 오픈 월드를 위한 경관 생성 — 지형, 침식, 식생 렌더링
• WebSocket 멀티플레이어 기초 — 브라우저 멀티플레이어 네트워킹 시작하기
• WebGPU 시작하기 — 차세대 브라우저 3D를 위한 렌더링 API
• 스트리밍 에셋 로딩 — 대규모 3D 월드를 위한 점진적 로딩 패턴

지금 바로 해보세요지금 바로 브라우저에서 오픈 월드를 체험해 보세요

한 문장을 입력하면 걸어 다닐 수 있는 3D 월드가 만들어집니다.

무료로 만들기 →무료입니다. 설치 없이 브라우저에서 바로 실행됩니다.