수신: Oleg Sidorkin
관련: app.cinevva.com/blog/2026-03-04-sketch-to-animated-3d-character
대조 기준: cinevva-site repo (마케팅 사이트 + worker)

확인됨 ✓

• 도구 이름(Image Generator, Video Generator, 3D Model Generator)과 링크 /tools/hunyuan3d가 코드베이스와 일치합니다.
• 작성자(Oleg Sidorkin, CTO)가 정확합니다.
• 영상 워크플로: 시작 + 끝 프레임 보간, 9:16, 3~15초 길이, storyboard 모드 모두 지원됩니다.
• 3D 파이프라인: Hunyuan3D와 "3D Model Generator"가 정확하고, 자동 리깅(Tripo)과 "GLB 업로드 → 리깅된 모델 + 애니메이션 라이브러리"가 구현과 일치합니다.
• Cinevva Engine과 "2026년 초 기준 반영"이 정확합니다.

수정 필요

"Seedance 1.5 Pro" — 이 repo에서는 영상이 Seedance 1.5 Pro가 아니라 Kling 3.0 Pro (fal.ai)로 구현되어 있습니다:

• worker/src/genai/fal-video.ts는 fal-ai/kling-video/v3/pro/...를 사용합니다
• worker/src/index.ts는 비용을 model: 'kling-3.0-pro'로 기록합니다
• tools/video.md에는 이렇게 적혀 있습니다: "Generate short AI videos from text or images using Kling 3.0 Pro"

API/제품 이름은 "seedance"(예: /genai/seedance/generate)이지만, 실제 모델은 Kling 3.0 Pro입니다. Seedance 1.5 Pro는 다른 모델(ByteDance)입니다. 공개 자료에서는 Seedance 1.5 Pro를 보통 약 10초로 제한하는데, 여기서 15초가 지원되는 건 Kling을 쓰기 때문입니다.

권장 사항: 글에서는 영상 모델 이름을 "Kling 3.0 Pro"(또는 예: "Video Generator (Kling 3.0 Pro)")로 적어 마케팅 사이트 및 문서와 일치시키세요. 만약 앱 백엔드가 실제로 Seedance 1.5 Pro를 사용한다면, 앱 문구와 tools/video.md를 맞춰 같은 모델을 설명하도록 하세요.

repo에서 확인 불가

Cubcoats, Kali the Kitty, Mimi Chao 및 관련 비즈니스 주장은 외부 정보로, 확인하지 않았습니다.

Game Creator의 spike {{ spikeId }}(으)로 이동하고 있습니다. 자동으로 이동되지 않으면 여기서 열어 보세요.

Game Creator 열기.

← 시리즈 가이드로 돌아가기

글 Mariana Muntean, Cinevva CEO

솔직히 말하면 itch.io에 일주일을 통째로 쏟을 생각은 전혀 없었어요. 가벼운 리서치로 시작했는데... 뭐, 열두 시간쯤 지나서는 세는 걸 그만뒀습니다. 원래 목적은 바로 즐길 수 있는 게임을 찾는 거였어요. 다운로드도 없고, 백그라운드에서 끙끙대는 설치 프로그램도 없이요. 클릭하면 바로 게임 안입니다. 끝.

이게 그 관문을 통과한 게임들입니다.

최고 평점의 인터랙티브 경험

Adventures With Anxiety! — 인터랙티브 스토리 평점 6,500개가 넘는데 평균 4.9입니다. 불안과 정면으로 마주하게 만드는 게임에 이렇게 팬이 많다니 신기하죠? 좋은 의미로 불편해집니다. 오래도록 마음에 남는 그런 불편함이요. 여기서 플레이하세요

We Become What We Behold — 사회 논평 평점 7,600개에 4.8/5. 끝내는 데 10분. 머릿속에서 지우는 데 며칠. 여기서 플레이하세요

Six Cats Under — 퍼즐 어드벤처 아늑하고 영리합니다. 여기선 비주얼이 진짜 많은 일을 해내는데, 그게 게임에 유리하게 작용합니다. 6,400명 넘는 사람들에게서 4.8/5. 여기서 플레이하세요

Friday Night Funkin' — 리듬 게임 이건 이제 어디서나 볼 수 있죠. 평점 11,700개 이상, 4.7/5. 여기서 플레이하세요

Sort the Court! — 왕국 시뮬레이션 당신이 할 일은 오직 하나, 예 또는 아니오를 말하는 겁니다. 별거 아닌 것처럼 들리죠. 그러다 작은 왕국을 여전히 운영하는 사이에 두 시간이 사라집니다. 여기서 플레이하세요

Dragonsweeper — 퍼즐 로그라이크 지뢰찾기에 RPG 시스템을 섞어 버무렸습니다. 4.9/5. 어쩌면 이 목록 전체에서 가장 좋은 게임일지도 모릅니다. 여기서 플레이하세요

로그라이크 & 전략 (브라우저에서 플레이 가능)

Backpack Hero — 인벤토리 로그라이크 브라우저 버전은 무료입니다. 유료 버전에 더 많은 콘텐츠가 있지만, 무료 웹 빌드만으로도 충분히 완성도가 있습니다. 여기서 플레이하세요

Vampire Survivors — 불릿 헤븐 데모만 제공됩니다. 스테이지 하나, 캐릭터 일곱. 그래도 이 게임이 왜 모두의 여가 시간을 집어삼켰는지 알기엔 충분합니다. 여기서 플레이하세요

Dome Romantik — 채굴 디펜스 게임 잼 작품으로 시작했습니다. Dome Keeper가 됐고요. 그리고 크게 성공했습니다. 원조 프로토타입은 지금도 잘 버텨 줍니다. 여기서 플레이하세요

왜 하필 이 게임들일까요?

링크 하나하나 전부 직접 테스트했습니다. 대충 훑어본 게 아니라, 정말로 자리 잡고 앉아서 플레이했어요. 문제없이 로딩되고, 브라우저에서 이상하게 굴지도 않습니다. 수천 개의 평점은 다운로드 버튼 한 번 누른 적 없는 사람들에게서 나왔습니다. 클릭하고 바로 뛰어든 사람들이죠. "오, 흥미로운데"에서 실제로 플레이하기까지의 그 마찰 없는 경로요. 대부분의 사람은 그게 얼마나 많은 걸 바꾸는지 과소평가합니다.

더 많은 웹 게임 둘러보기

아직 더 하고 싶으신가요?

• itch.io 최고 평점 HTML5 게임
• 최고의 HTML5 플랫포머
• 2024-2025년 게임

주목할 만한 인디 게임 (다운로드 필요)

브라우저에서 돌아가지 않는 좋은 게임들도 있습니다. 이런 게임들은 그 추가 단계를 감수할 가치가 있습니다.

Slice & Dice — 주사위 로그라이크 Windows, Mac, Android에서 실행됩니다. itch.io에서 받기

Stacklands — 카드 마을 건설 Windows와 Mac. itch.io에서 받기

Luck be a Landlord — 슬롯머신 로그라이크 말장난 같은 콘셉트처럼 들리죠. 아닙니다. 슬롯머신이라는 겉모습 아래에 진짜 전략이 있습니다. itch.io

Patrick's Parabox — 재귀 퍼즐 머리가 지끈거릴 각오 하세요. 그래도 좋아하게 될 각오도요. itch.io

Dome Keeper — 채굴 디펜스 앞서 언급한 그 잼 프로토타입의 정식 출시판입니다. Steam에서 찾기

Brotato — 아레나 서바이버 Steam에서 이용 가능

게임을 만드는 사람이라면 한 번쯤 곱씹어 볼 게 있습니다. 브라우저 빌드는 플레이어와 당신의 작품 사이에 아무것도 두지 않습니다. 대기열에 걸린 채 잊혀 버릴 다운로드도 없고, 넘겨야 할 설치 화면도 없습니다. 클릭 한 번이면 플레이어는 이미 당신이 만든 것에 대해 의견을 형성하기 시작합니다. 그런 즉시성은 충분히 이야기되지 않지만, 모든 걸 바꿔 놓습니다.

당신의 게임에도 이걸 원하시나요? Cinevva 게임 크리에이터로 브라우저에서 바로 하나 만들 수 있고, 저희가 소개하는 게임들은 커뮤니티 아케이드에 실립니다.

• 게임 크리에이터를 위한 안내
• 빠르게 로딩되는 웹 게임 만들기

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

2026년에 브라우저에서 돌아가는 3D 게임을 출시하고 싶다면, 주류 선택지 네 가지와 더 새로운 것 몇 가지가 있습니다. 흔히 "웹 게임 엔진"으로 한데 묶이지만, 사실은 서로 다른 문제를 푸는 진짜로 다른 도구들입니다. 잘못 고르면 몇 달을 날립니다. 이 글은 최신 정보로 사실 확인을 거친 비교이며, 웹 3D 엔진을 만드는 일을 직업으로 삼고 직접 엔진을 만들기 전에 이 모든 것을 평가한 사람들이 썼습니다.

각 선택지가 실제로 무엇인지, 누구를 위한 것인지, 어디서 무너지는지를 살펴본 다음, 마지막에 짧은 결정 가이드를 드리겠습니다. 버전 번호를 언급하는 곳은 2026년 6월 기준으로 정확합니다.

빠른 비교

이 글의 나머지는 이 표를 설명합니다.

PlayCanvas

PlayCanvas는 웹에서 Unity 스타일 워크플로에 가장 가까운 물건입니다. 엔진은 MIT 라이선스의 오픈소스이며, 2026년 6월 5일 기준으로 v2.19.6입니다. 엔티티-컴포넌트 시스템을 쓰고, 게임 로직은 TypeScript나 JavaScript로 작성하며, 에셋은 GLB를 만들어 내는 서버 사이드 파이프라인을 거칩니다. 실제 상용 게임들이 이 위에서 돌아가고, 큰 회사들이 프로덕션에서 씁니다. Snap이 공개된 예입니다.

PlayCanvas에 대해 사람들이 흔히 잘못 아는 두 가지를 바로잡을 만합니다. 첫째, 엔진은 MIT 라이선스지만, 대부분의 팀이 실제로 쓰는 호스팅 비주얼 에디터는 오픈소스가 아니라 상용 제품입니다. 에디터 없이 엔진만 자유롭게 쓸 수 있지만, 에디터와 클라우드를 묶은 워크플로가 유료 부분입니다. 둘째, PlayCanvas는 WebGL2 우선입니다. WebGPU 경로가 있긴 하지만 기본 렌더러라기보다 아직 성숙해 가는 중이므로, 프로덕션용 WebGPU 컴퓨트 셰이더를 기대하고 오늘 PlayCanvas를 고르지는 마세요.

PlayCanvas가 진짜로 앞서는 곳은 3D 가우시안 스플래팅입니다. 팀이 오픈소스로 공개한 SuperSplat 에디터와 뷰어는 웹에서 스플랫 씬을 캡처하고 출시하는 데 있어 어디 내놔도 손꼽히는 도구이며, 대용량 캡처를 위한 WebGPU 기반 스트리밍을 갖췄습니다. 포토리얼하게 스캔한 환경이 목표라면, 여기서 시작할 진짜 이유가 됩니다.

PlayCanvas를 고르세요 브라우저용으로 Unity 같은 에디터와 관리형 에셋 파이프라인을 원하고, 스튜디오가 만들 법한 게임을 출시하려 한다면. 다른 곳을 보세요 오늘 당장 WebGPU 컴퓨트가 필요하거나, 호스팅형 상용 에디터를 피하고 싶다면.

Three.js

Three.js는 게임 엔진이 아닙니다. 렌더링 라이브러리이며, 이 분야에서 압도적인 차이로 가장 널리 쓰입니다. 씬 그래프, 카메라, 라이트, 머티리얼, 지오메트리, 로더, 렌더러를 주고 나서 거기서 멈춥니다. 에디터도, 물리도, 엔티티 시스템도 없고, 게임을 어떻게 구성해야 하는지에 대한 의견도 없습니다. 그건 직접 더하거나 생태계에서 끌어와야 합니다.

그 맞바꿈이 이야기의 전부입니다. 최대한의 제어와 웹 3D에서 가장 큰 커뮤니티를 얻는 대신, 렌더러 위의 모든 것을 직접 만들거나 조립해야 합니다. WebGPU 렌더러는 꾸준히 성장해 왔고 오늘날 쓸 만하지만, 다른 것들과 마찬가지로 WebGL2 경로가 여전히 성숙한 기본값입니다. Three.js는 MIT 라이선스입니다.

Three.js를 고르세요 완전한 제어와 최소한의 기반을 원하고, 그 위에 게임 시스템을 직접 구축할 엔지니어링 역량이 있다면. 다른 곳을 보세요 에디터와 게임 시스템을 손에 쥐여주길 원한다면.

Babylon.js

Babylon.js는 완전한 엔진으로, MIT 라이선스이며 Microsoft의 팀이 뒷받침합니다. Three.js와 달리, 직접 조립해야 할 부품들을 함께 제공합니다. 컴포넌트 모델, 통합된 Havok 물리 엔진, 무료 웹 기반 에디터, 에셋 파이프라인이 그것입니다. WebGPU 작업이 빠르게 진행돼 범용 엔진들 중에서도 더 앞선 축에 들지만, 여전히 넓은 호환성 경로로 WebGL2를 유지합니다.

"완전한 엔진과 포함된 물리를 원하고, 그 규약 안에서 작업하는 게 편하다"가 머릿속 그림이라면, Babylon은 강력한 기본 선택지이며 이 분야에서 가장 기능이 완비된 무료 옵션이라고 볼 만합니다.

Babylon.js를 고르세요 배터리가 포함된 것, 내장 물리, 무료 에디터를 원한다면. 다른 곳을 보세요 의존성 부담을 최소화하고 싶거나, 구체적으로 Unity 스타일 호스팅 워크플로를 원한다면.

Unity WebGL

Unity WebGL은 웹 엔진이 아닙니다. 내보내기 대상입니다. Unity 데스크톱 에디터에서 C#으로 빌드한 다음, WebAssembly를 통해 브라우저에서 돌아가는 WebGL 번들로 컴파일합니다. 그래서 한 가지 특정 경우에는 분명한 답이 됩니다. 이미 Unity 게임이 있고 그것의 브라우저 버전을 원할 때입니다.

웹 우선 프로젝트에는 진짜 비용이 따릅니다. 런타임과 다운로드 무게가 상당하고, 시작이 네이티브 웹 엔진보다 느리며, 모바일 브라우저 성능은 알려진 골칫거리입니다. Unity는 독점이고 그 WebGL 출력은 WebGL2를 대상으로 합니다.

Unity WebGL을 고르세요 브라우저로 가져올 기존 Unity 프로젝트가 있거나, 팀이 이미 Unity 안에서 산다면. 다른 곳을 보세요 중급 휴대폰에서의 즉시 로드가 양보 불가한 요구사항이거나, 처음부터 웹 우선으로 새로 시작한다면.

AI 네이티브와 월드 내 제작이 들어맞는 자리

위의 모든 것은 한 가지 가정을 공유합니다. 개발자가 책상에서, 에디터 안에서 게임을 만들고 런타임을 출시한다는 가정입니다. 그 가정은 대부분의 프로젝트에 맞고, 당신 프로젝트가 그렇다면 위의 넷 중에서 고르세요.

다만 그 가정이 더는 유일한 선택지가 아니라는 걸 알아둘 만합니다. 다른 범주가 떠오르고 있기 때문입니다. 우리는 Cinevva를 만듭니다. 게임이 월드 안에서 만들어지는 WebGPU 전용 월드 플랫폼입니다. 에디터를 여는 대신, 당신은 그 공간에 서 있는 아바타이고, 원하는 것을 말로 설명하면 AI 빌더가 당신이 거기 서 있는 동안 그것을 지형, 오브젝트, 동작으로 바꿔 줍니다. 제작과 플레이가 같은 세션입니다. 그 이면에서 이것은 컴퓨트 셰이더 지형으로 WebGPU 전용으로 가고, 범용 물리 엔진 대신 커스텀 캐릭터 솔버를 작성하고, 애니메이션과 리타게팅 시스템을 만든다는 뜻이었습니다. 이에 대해서는 우리가 직접 WebGPU 엔진을 만든 이유에 적어 두었습니다.

이것은 PlayCanvas나 Babylon을 대체하는 게 아닙니다. 특정 게임을 만드는 개발자라면 그것들이 맞는 도구입니다. Cinevva는 엔진 개발자가 아닌 사람들이 설명만으로 플레이 가능한 공간을 만들고 공유하게 한다는 다른 목표를 위한 것입니다. 여기서 언급하는 이유는 "어떤 웹 게임 엔진을 써야 하나"라는 질문에 점점 더 엔진이 아닌 다섯 번째 답이 생기고 있기 때문입니다.

전체 기능 매트릭스

맨 위의 빠른 표가 헤드라인입니다. 이건 서브시스템별로 묶은 상세 버전입니다. 읽는 법에 대한 솔직한 메모 몇 가지를 드립니다. "BYO"는 직접 준비(bring your own)를 뜻하는데, 엔진이 기본으로 제공하지 않지만 생태계나 직접 작성한 코드로 더할 수 있다는 말입니다. 이건 설계상 렌더링 라이브러리인 Three.js에서 가장 중요하므로, 여기서 "BYO"는 빈틈이 아니라 철학의 특징입니다. Unity의 "내보내기 전용(Export-only)"은 그 기능이 데스크톱 에디터에 존재하고 WebGL 빌드에 함께 따라온다는 뜻이지 웹 네이티브라는 뜻이 아닙니다. 경쟁 제품 칸은 2026년 중반 기준 기본 제공 기능과 잘 문서화된 동작을 반영합니다. Cinevva 칸은 우리가 출시한 빌드에서 돌아가는 것을 반영하며, "계획됨(planned)"은 설계됐지만 아직 구축되지 않은 것을 표시합니다.

렌더링

월드와 지형

물리와 캐릭터

애니메이션

멀티플레이어와 백엔드

제작과 저작

에셋과 배포

매트릭스의 패턴이 진짜 이야기입니다. 범용 엔진들은 강점을 수평으로 펼칩니다. 각자 대부분의 일을 능숙하게 해내고, 월드와 백엔드와 제작 흐름은 당신에게 맡깁니다. Cinevva는 수직으로 집중합니다. 더 적은 일을 하지만 렌더러에서부터 당신이 안에서 만드는 공유 월드까지 전 경로를 소유합니다. 추상적으로는 어느 모양이 더 낫지 않습니다. 서로 다른 질문에 답할 뿐입니다.

어떻게 고를까

기능 체크리스트가 아니라 상황에 도구를 맞추세요.

이미 Unity 게임이 있다면, Unity WebGL로 내보내고 무게를 감수하세요. 브라우저 게임에 에디터 주도 워크플로를 원하는 스튜디오라면, PlayCanvas를 쓰세요. 물리가 포함된 완전한 무료 엔진을 원한다면, Babylon.js를 쓰세요. 완전한 제어를 원하고 맨 렌더러 위에 구축할 팀이 있다면, Three.js를 쓰세요. 그리고 목표가 게임 하나를 만드는 게 아니라 사람들이 설명만으로 공유 월드 안에서 만들고 플레이하게 하는 것이라면, 그게 우리가 일하는 범주이고, Cinevva를 써 보세요.

무엇을 고르든, 커밋하기 전에 진짜 스파이크로 평가하세요. 이 각각은 진짜 게임을 떠받칠 수 있고, 중간에 갈아타는 비용은 출시에 쓰지 못한 그 몇 달입니다.

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

Cinevva World를 본 기술자라면 누구나 5분 안에 같은 질문을 합니다. 당신들은 작은 팀이다. 성숙한 웹 3D 엔진이 이미 존재한다. 그런데 왜 PlayCanvas나 Babylon 위에 올라타 더 빨리 출시하지 않고, 직접 렌더러를, 직접 캐릭터 물리를, 직접 애니메이션 시스템을 만들었나?

타당한 질문이고, "여기서 만든 게 아니라서(not invented here)"는 틀린 답입니다. 우리는 숙제를 했습니다. 기존 엔진들을 돌려봤고, 소스를 읽었고, 결정을 내리기 전에 그중 둘 위에 스파이크를 올려서 출시까지 해봤습니다. 이 글은 그 결정의 솔직한 버전입니다. 기성 옵션들이 진짜로 잘하는 것, 우리 요구가 직접 만드는 게 정당화될 만큼 크게 갈라진 네 곳, 그리고 우리를 따라 하기보다 그중 하나를 골라야 하는 상황을 다룹니다. 빌드 자체는 장기 연재인 브라우저 안의 오픈월드 엔지니어링 시리즈에 기록해 두었으니, 아래 주장에 작업 로그가 있는 경우에는 링크를 걸겠습니다.

우리가 실제로 평가한 옵션들

"웹 게임 엔진"이라고 불리는 네 가지가 있는데, 서로 같은 종류의 물건이 아닙니다.

Three.js는 게임 엔진이 아니라 렌더링 라이브러리입니다. 씬 그래프, 머티리얼, 로더, 렌더러를 주고 나서 길을 비켜줍니다. 에디터도, 물리도, 엔티티 시스템도, 게임을 어떻게 구성해야 하는지에 대한 의견도 없습니다. 그게 매력이자 비용입니다. 렌더러 위의 모든 것을 직접 만들어야 하지만, 그 무엇도 당신과 싸우지 않습니다. MIT 라이선스고, 이 분야에서 가장 큰 생태계를 갖고 있으며, 새벽 2시에 난해한 셰이더 버그를 만나도 답을 주는 포럼 글이 기다리고 있습니다.

Babylon.js는 씬 그래프, 물리 통합(Havok), 에셋 파이프라인, 웹 에디터를 갖춘 완전한 엔진입니다. MIT 라이선스고, Microsoft의 팀이 뒷받침하며, WebGPU 작업이 빠르게 진행돼 왔습니다. 배터리가 포함된 걸 원하고 엔진의 구조 안에서 사는 게 편하다면, 강력한 기본 선택지입니다.

PlayCanvas는 "웹용 Unity"에 가장 가까운 물건입니다. 이 글을 쓰는 시점에 엔진은 2026년 6월 5일에 출시된 v2.19.6이고, 엔진 자체는 MIT 라이선스의 오픈소스입니다. 다만 대부분의 사람이 실제로 쓰는 건 호스팅 비주얼 에디터이고, 그 에디터는 오픈소스가 아니라 상용 제품입니다. PlayCanvas는 엔티티-컴포넌트 시스템을 쓰고, TypeScript나 JavaScript로 스크립팅하며, 에셋은 서버 사이드 GLB 파이프라인을 거치고, 실제 상용 게임들이 이 위에서 출시됐습니다(Snap이 프로덕션 작업을 PlayCanvas로 돌리는 게 한 예입니다). 렌더러는 WebGL2로 돌아가고 WebGPU 경로는 기본값이라기보다 아직 성숙해 가는 중입니다. 그 마지막 디테일이 들리는 것보다 더 중요한데, 뒤에서 다시 다루겠습니다.

Unity WebGL은 애초에 웹 엔진이 아닙니다. 내보내기 대상입니다. Unity 데스크톱 에디터에서 빌드한 다음 WebGL 번들로 컴파일합니다. 이미 Unity 게임이 있고 그걸 브라우저에 넣고 싶을 때는 맞는 도구고, "중급 휴대폰의 탭에서 즉시 로드된다"가 강한 요구사항일 때는 틀린 도구입니다. 런타임과 다운로드 무게가 따라오기 때문입니다.

이 중 무엇이든 평범한 웹 게임의 합리적인 토대가 됩니다. 우리는 평범한 웹 게임을 갖고 있지 않았습니다.

결정 하나: WebGPU는 우리의 바닥이지 결승선이 아니다

우리를 모든 기성품에서 밀어내는 갈림은 이것입니다. 우리에게 WebGPU는 언젠가 도달할 기능이 아니라 요구사항입니다.

우리 지형은 정적 하이트맵이 아닙니다. 스트리밍되는 하이트맵 필드와, 부호 거리 필드(signed-distance field)로 뒷받침되는 마칭 큐브 청크의 하이브리드라서, 세계에 진짜 동굴과 오버행이 있을 수 있고 창작자가 실시간으로 조각할 수 있습니다. 조각 브러시, 식생 스캐터, 지형 메싱은 모두 컴퓨트 셰이더로 돌아갑니다. 컴퓨트를 빼면 세계는 품질이 떨어지는 게 아니라 아예 돌지 않습니다.

이건 오늘날 범용 엔진들이 서 있는 자리와 정반대입니다. 그들의 WebGPU 지원은 WebGL2 우선 렌더러 위에 얹은 점진적 향상으로 설계되어 있고, WebGPU가 없는 브라우저를 위한 폴백 경로를 둡니다. 특히 PlayCanvas는 WebGL2 우선이고 WebGPU는 아직 베타입니다. 그들에게는 그게 올바른 판단입니다. 그들의 일은 가능한 가장 넓은 게임 매트릭스를 가능한 가장 넓은 기기 매트릭스에서 돌리는 것이니까요. 우리 일은 더 좁고 깊어서, 우리는 반대로 판단했습니다. 스파이크 13에서 WebGPU 전용으로 갔고 다시는 뒤돌아보지 않았습니다. WebGPU가 없는 브라우저는 다운그레이드되는 게 아니라 미지원이고, 우리는 그걸 WebGL2 폴백이 설정 플래그 하나 거리에 있는 척하는 대신 도달률 수치로 추적합니다. 그건 설정 플래그 거리에 있지 않습니다. 우리 지형과 식생 단계의 부분 재작성이 될 겁니다.

WebGL2 우선 엔진 위에 짓는다는 건 모든 컴퓨트 기능마다 그 엔진의 폴백 가정과 싸우거나, 아니면 두 개의 렌더링 경로를 영원히 유지하거나 둘 중 하나를 뜻했을 겁니다. 렌더러를 소유하니 컴퓨트를 기준선으로 다룰 수 있었습니다.

결정 둘: 물리 엔진이 아니라 캐릭터 솔버

교과서적인 수는 물리 엔진을 끼워 넣는 것입니다. 우리도 해봤습니다. 초기 스파이크에서 워커 안의 Rapier를 검증했고, 괜찮게 느껴졌습니다.

그래도 우리는 직접 만들었고, 출시 빌드 어디에도 Rapier, Cannon, Ammo가 없습니다. 이유는 범위입니다. 우리는 강체, 조인트, 래그돌, 제약 솔버가 필요 없습니다. 캡슐 하나가 지형에 대해 올바르게 움직이면 되고, 걷기, 미끄러지기, 활공, 등반, 수영이 "내가 지면에 있는가, 어떤 표면 위에서, 어떤 각도로"에 대한 하나의 공유된 답에 동의하기만 하면 됩니다. 범용 물리 엔진은 이걸 더 쉽게가 아니라 더 어렵게 만듭니다. 그 모드들이 결국 엔진 내부의 스프링과 댐퍼와 싸우게 되기 때문입니다.

그래서 우리 캐릭터 컨트롤러는 플러그형 멀티채널 상태 머신입니다. 각 모드는 이번 프레임에 제어권을 원하는지 말하고, 이기면 속도와 방향을 쓰는 작은 유닛입니다. 이들은 자원, 자세, 이동이라는 세 채널에 걸쳐 우선순위로 중재하고, 모두 같은 지형 쿼리를 읽습니다. 충돌은 청크에 따라 하이트맵이나 부호 거리 필드에 대한 캡슐 프로브입니다.

제가 가장 자랑스러워하는 디테일은 화려하지 않습니다. 지면 검출은 SDF 기울기를 믿는 대신, 발밑 수직 기둥의 모든 표면을 스캔해 캡슐 이하에서 가장 높은 것을 고릅니다. 오버행 가장자리에서는 옆으로 가장 가까운 표면이 절벽 면이라, 기울기 기반 노멀은 "바닥"과 "벽" 사이를 깜빡거리고 유령 미끄러짐이 생깁니다. 기둥 쿼리는 턱 위에 서 있는 걸 지루하게 만드는데, 그게 바로 당신이 원하는 것입니다. 기성 하이트필드 콜라이더는 이걸 공짜로 주지 않았을 겁니다. 애초에 우리 지형을 볼 수 없기 때문입니다. 지형은 우리 포맷으로 GPU 위에 삽니다. 외부 엔진은 매 편집마다 우리가 필드 전체를 그 콜라이더 포맷으로 복사해 주지 않으면 거기에 충돌시킬 수 없습니다.

결정 셋: 리그를 가로질러 이동하는 애니메이션

아바타는 Synty POLYGON 리그를 쓰고, 우리 모션 클립은 큰 오픈 애니메이션 라이브러리에서 옵니다. 리그와 클립이 본 이름을 공유하기 때문에, 일반적인 경우엔 런타임 리타게팅이 필요 없고 트랙이 이름으로 그냥 바인딩됩니다. 전체 캐릭터 파이프라인은 범용 캐릭터에 정리해 두었습니다.

흥미로운 작업은 둘이 맞지 않는 경우입니다. 우리는 한 스켈레톤을 다른 스켈레톤에 매핑하는 리타게팅 패스를 만들었고, 이걸 제대로 하려면 세 가지 구체적인 문제를 풀어야 했습니다. 먼저 바인드 포즈를 정렬합니다. A-포즈를 T-포즈에 맞추면 조인트마다 약 30도가 조용히 더해지기 때문입니다. 루트 모션과 보폭은 두 개의 별도 비율로 스케일합니다. 수직은 엉덩이-바닥(hip-to-floor), 수평은 전체 비율입니다. 그리고 리타게팅된 클립을 고정 샘플 레이트로 원본과 비교 테스트해서, 회귀가 플레이어보다 먼저 드러나게 합니다. 그 파이프라인이 새 애니메이션 소스를, 그리고 언젠가는 창작자가 제공한 캐릭터를, 모든 클립을 손으로 고치지 않고 추가할 수 있게 해줍니다.

그 위에는 모션 상태에서 매 프레임 올바른 클립 패밀리를 고르는 애니메이션 상태 머신이 있습니다. 속도에 따른 점프 변형, 충격에 따른 착지 강도, 속도와 지형 기울기의 내적에서 나오는 경사 방향, 멈출 때 문워크하지 않도록 하는 발 위상 정확 정지, 그리고 벽에 부딪혀도 걷기와 떨어지기 사이에서 깜빡이지 않게 하는 100밀리초 디바운스. 이 중 무엇도 이국적이지 않지만, 그 레이어를 소유해야만 얻을 수 있는 종류의 것입니다.

결정 넷: 어떤 엔진도 출시하지 않는 부분

나머지 세 결정은 세계가 어떻게 돌아가는지에 관한 것입니다. 이 결정은 제품이 무엇인지에 관한 것이고, PlayCanvas와의 비교가 결국 범주 오류인 이유입니다.

PlayCanvas, Babylon, Unity, 그리고 직접 짠 Three.js 앱은 모두 같은 형태를 가정합니다. 당신은 책상에서, 2D 에디터 안에서, 세계를 바깥에서 들여다보며 게임을 만들고, 그다음 재생을 눌러 별도의 런타임을 출시합니다. 그들의 엔진 내 편집조차 워크스테이션 앞에 앉은 당신이 들여다보는 씬을 조작하는 것입니다.

Cinevva World는 그걸 뒤집습니다. 당신은 세계 안에서, 당신의 플레이어가 설 바로 그 공간에 선 아바타로서, 원하는 걸 묘사하고 그것이 나타나는 걸 지켜보며 만듭니다. 창작과 플레이는 런타임에 다리를 놓은 빌드 단계가 아니라 하나의 연속된 세션입니다. 가장 가까운 참조점은 웹 3D 엔진이 아니라 Roblox, Rec Room, Horizon Worlds이고, 그것들조차 창작 대부분을 책상에 둡니다. 마우스로 모는 에디터 없이 이걸 다룰 수 있게 만드는 건 AI 빌더인데, "여기에 등불 켜진 부두를 놓아"를 지오메트리와 배치로 바꿔줍니다.

이건 범용 엔진에 볼트로 조여 붙일 수 없습니다. 렌더링 기능이 아니기 때문입니다. 이건 스택 전체의 전제입니다. 지형이 런타임에 어떻게 편집 가능한지부터, 네트워크가 모든 오브젝트를 근처에 선 사람이 방금 만든 무언가로 어떻게 다루는지까지요.

우리가 한 일을 따라 하면 안 되는 경우

여기가 "우리가 직접 엔진을 만들었다" 장르가 보통 건너뛰는 부분입니다. 이번 분기에 브라우저 게임을 출시하고 싶다면, 우리를 따라 하지 마세요. Unity 스타일 에디터와 관리형 파이프라인을 원하면 PlayCanvas를 쓰세요. 물리가 포함된 완전한 엔진을 원하고 그 구조 안에서 편하면 Babylon을 쓰세요. 최대한의 제어와 최소한의 의견을 원하고 그 위에 쌓아 올릴 팀이 있으면 Three.js를 쓰세요. 이미 Unity 게임이 있으면 Unity에서 포팅하세요.

직접 렌더러, 물리, 애니메이션을 작성하는 건 제품의 전제가 기성품과 양립할 수 없을 때, 만들고 있는 게 엔진 위의 게임이 아니라 마침 엔진으로 만들어진 장소일 때에만 올바른 판단입니다. 우리에겐 그게 사실이었습니다. 당신에겐 아마 사실이 아닐 거고, 그래도 괜찮습니다. 평가를 솔직하게 하는 핵심은 첫 줄을 쓰기 전에 자신이 어느 경우에 속하는지 아는 것입니다.

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

이제 우리는 세계를 생성할 수 있습니다. 데모 영상 얘기가 아닙니다. 위 그림은 우리 에디터입니다. 누군가 채팅창에 "2층을 지어줘"라고 입력했고, AI가 바닥 데크를 깔고 앞벽과 옆벽, 뒷벽을 세운 뒤 계단과 지붕으로 계속 이어가겠다고 제안하는 걸 지켜봤습니다. 소품이 아니라, 텍스처가 아니라, 구조물 전체입니다. 그리고 그것이 다른 사람들도 걸어 들어올 수 있는 세계 안에 놓였습니다. 우리 파이프라인은 그 부품들도 이미 만듭니다. 3D 모델, 음악, 사운드, 머티리얼까지.

그래서 우리는 Cinevva World를 대중에게 공개하기 직전입니다. 그러기 전에, 나는 가서 부고들을 읽었습니다.

우리가 만들고 있는 것에는 불편한 진실이 있기 때문입니다. 지난 15년 동안 아주 똑똑하고 아주 자금이 넉넉한 팀들이 공유 창작 세계를 작동시키려 했습니다. 몇몇은 인류가 만든 가장 큰 것들 중 하나가 되었습니다. 대부분은 죽었습니다. 두 결과 사이의 간극은 재능도 아니고 돈도 아닙니다. 죽은 것들 중 일부는 우리가 평생 가질 것보다 더 많은 재능과 돈을 가졌으니까요. 그 간극은, 거의 아무도 첫 시도에 제대로 해내지 못하는 소수의 결정에 있습니다. 이것이 내가 발견한 것입니다.

무덤

실패 사례부터 시작하겠습니다. 성공담보다 더 솔직하기 때문입니다. 승자는 자기 역사를 깔끔한 서사로 다시 씁니다. 패자는 메모를 흘립니다.

Meta Horizon Worlds: 역사상 가장 비싼 빈 방

Meta는 메타버스 베팅에 수백억 달러를 썼습니다. Reality Labs는 2026년 초에 보고된 단일 분기 영업손실 60억 2천만 달러를 기록했고, 수년간 분기마다 수십억 달러씩 출혈해 왔습니다. 그 대표작이 Horizon Worlds였습니다. 그 돈이 산 것이 무엇인지 여기 있습니다.

Fortune와 Ryan Schultz가 보도한 유출된 내부 메모는, 크리에이터들이 만든 세계 중 50명 이상이 방문한 곳이 약 9퍼센트에 불과했음을 드러냈습니다. 대다수는 제작자 본인 외에는 방문이 0이었습니다. 한 메모는 이 참여도 문제를 이 분야의 모든 창업자가 문신으로 새겨야 할 한 문장으로 요약했습니다. "텅 빈 세계는 쓸쓸한 세계다." 활성 사용자를 설문하려던 연구자들은 겨우 514명밖에 찾지 못했습니다. 플레이어 기반이 그만큼 작았기 때문입니다.

리텐션 수치는 더 나빴습니다. 유출된 데이터는 첫 달 이후 돌아온 사용자가 약 10명 중 1명뿐이었음을 보여줬습니다. Meta는 2022년 자체 목표를 월 50만 명에서 20만 명으로 조용히 낮췄고, 그러고도 그 플랫폼은 VRChat보다, 그리고 2003년 게임인 Second Life보다 동시 접속자가 적었습니다. 내부 도그푸딩 대시보드는 Meta 자체 직원들조차 그걸 쓰지 않았음을 보여줬고, 이는 경영진이 관리자들에게 주간 로그인에 대한 책임을 묻기 시작하도록 만들었습니다. 한 VP는 팀을 그해 남은 기간 동안 "품질 락다운"에 들어가게 했고, 자신들이 제품-시장 적합성을 찾지 못한 제품을 만들고 있다고 글로 인정했습니다.

2026년 3월, Meta는 VR 지원을 완전히 종료한다고 발표하고 Horizon Worlds를 거의 전적으로 모바일 앱으로 전환했습니다. 헤드셋 없는 사람들을 위한 진입점이자, 그들 자신의 표현으로는 Roblox처럼 기능하는 것이었습니다. 역사상 가장 비싼 메타버스는, 첫날부터 그랬어야 했던 바로 그것이 되려 애쓰며 생을 마감했습니다.

교훈은 "VR이 너무 일렀다"가 아닙니다. 물론 너무 이르긴 했지만요. 교훈은 어떤 자본도 텅 빈 세계를 채우지 못한다는 것입니다. 콘텐츠 밀도는 마케팅 예산으로 살 수 있는 것이 아닙니다. 세계가 비어 있으면 사람들이 떠나고, 사람들이 떠나면 세계는 계속 비어 있습니다. 그 고리가 Meta를 산 채로 집어삼켰습니다.

Decentraland와 The Sandbox: 10억 달러짜리 유령 도시들

2022년 10월, 단 하나의 데이터 포인트가 크립토 세계에 불을 질렀습니다. DappRadar의 보도에 따르면 Decentraland의 일일 활성 사용자는 38명이었습니다. The Sandbox는 522명이었습니다. 이 두 프로젝트는 당시 각각 약 13억 달러의 시가총액을 짊어지고 있었습니다.

이제, 프로젝트 측은 반박했고 그 뉘앙스는 사실 비웃음보다 더 중요합니다. 38이라는 숫자는 하루에 온체인 거래를 한 고유 지갑만 셌습니다. DappRadar가 "payers"라고 부르는 것이지, 블록체인을 건드리지 않고 로그인해서 돌아다닌 사람들이 아닙니다. Decentraland는 월간 로그인 사용자가 56,697명이고 다른 추정으로는 일일 약 8,000명이라고 반박했습니다. The Sandbox는 알파 시즌 동안 일일 39,000명에, 14일차 리텐션 40퍼센트를 주장했습니다.

하지만 그 간극을 잠시 음미해 보세요. 이 글 전체에서 가장 중요한 숫자이기 때문입니다. 가장 후하게 잡은 수치를 받아들여도, 잘 봐줘야 일일 수천 명의 사용자 위에 10억 달러짜리 가치 평가가 얹혀 있는 셈입니다. 비교하자면, 조사 결과 같은 기간 블록체인이 아닌 Roblox는 일일 활성 사용자 5,200만 명에 월간 결제 사용자는 1,130만 명뿐이었습니다. 무료 가상 세계에 있는 대부분의 사람들은 거의 또는 전혀 거래하지 않습니다. 이건 양쪽 모두에 칼날을 들이댑니다. 38-DAU 비웃음이 부당했다는 뜻이기도 하고, 10억 달러짜리 가치 평가가 환상이었다는 뜻이기도 합니다. 둘 다 잘못된 숫자를 쟀습니다. 가치 평가는 토큰 투기를 쟀습니다. 비웃음은 지갑 거래를 쟀습니다. 어느 쪽도 누가 재미있어하는지는 재지 않았습니다.

그것이 가장 순수한 형태의 허영 지표 함정입니다. 가입 계정 수, 토큰 시가총액, 총 도달 가능 시장, 언론 노출 수. 그 어느 것도 당신의 세계가 살아 있는지 말해 주지 않습니다. 그걸 말해 주는 유일한 숫자는 얼마나 많은 사람이 다시 돌아오는지, 그리고 무언가를 만드는 사람들이 계속 만드는지뿐입니다.

Dreams: 아무도 머무를 수 없었던 가장 아름다운 도구

LittleBigPlanet을 만든 스튜디오 Media Molecule은 거의 10년을 들여 Dreams를 만들었습니다. 사람들이 그 안에서 플레이 가능한 게임과 애니메이션 단편 영화, 음악 앨범까지 만들 만큼 깊은 창작 도구였습니다. 비평가들은 그것을 사랑했습니다. 그리고 2023년 9월, 스튜디오는 라이브 서비스를 종료하며, 지속 가능한 비즈니스 모델을 찾지 못했다고 솔직히 말했습니다.

부검 결과는 스스로 자초한 상처의 체크리스트입니다. 그리고 나는 엄청난 존경심을 담아 이렇게 말합니다. 우리도 그 하나하나를 똑같이 저지를 수 있기 때문입니다. Dreams는 크리에이터가 자기 작업을 수익화하도록 결코 허락하지 않았습니다. 약속된 인게임 상점은 끝내 출시되지 않았습니다. 코스메틱도, 배틀 패스도, 아무것도 없었습니다. 도구를 플랫폼으로 바꾸는 부류의 진지한 크리에이터들에게는, 상방이 전혀 없는데 수년을 투자할 이유가 없었습니다. 그것은 PS4 전용으로 출시되었고, 출시 시점에 PC 버전도 네이티브 PS5 빌드도 없어서 가능한 관객 규모가 강하게 제한되었습니다. 그리고 공동 창업자 Mark Healey는 나중에 자신의 가장 큰 후회가 멀티플레이어에 집중하지 않은 것이었다고 말했고, 팀은 자신들의 창작물이 창작 도구보다 게임으로서 더 잘 작동한다는 것을 깨닫게 되었다고 했습니다.

그 마지막 부분을 다시 읽어 보세요. 지구상에서 가장 재능 있는 UGC 스튜디오가 사후에 내린 결론은, 그것이 도구이기보다 먼저 게임이었어야 했다는 것입니다. 그것이 이 연구 전체에서 가장 중요한 한 문장이고, 나중에 다시 돌아오겠습니다.

나머지 묘지

이 패턴은 음울할 정도로 일관되게 반복됩니다.

협업 UGC 창작 플랫폼 Crayta는 2023년 3월에 문을 닫았고 사용자들은 만든 것을 전부 잃었습니다. 그 개발사는 2021년에 Meta에 인수되었는데도 플랫폼은 결국 죽었습니다. 직접적인 원인은 이것입니다. Google Stadia에서 출시되었는데, Stadia가 죽자 Crayta도 함께 죽었습니다. 플랫폼 의존성은 자기 머리에 겨눈 장전된 총입니다.

Microsoft의 UGC 게임 메이커 Project Spark는 몇 해 전에 같은 궤적으로 문을 닫았습니다. 강력한 도구였지만 머무르는 사람이 충분치 않았습니다. Linden Lab이 Second Life의 VR 후계자로 내놓은 Sansar는 관객을 찾지 못하고 매각되었습니다. Second Life 창업자 Philip Rosedale 자신의 두 번째 메타버스 회사인 High Fidelity는 가상 세계에서 완전히 방향을 틀었습니다.

그리고 지금 당장 벌어지고 있어서 무시할 수 없는 신호로, Rec Room은 2026년 6월 1일부로 서비스를 종료한다고 발표하며 지속적인 수익성에 결코 도달하지 못했다고 밝혔습니다.

메타버스를 만드는 메타버스 회사의 창업자들이, 자기 자신의 메타버스에 머무를 수 없었습니다. 어려운 부분이 렌더링이라고 생각하는 사람이라면 누구든 이 사실에 겁을 먹어야 합니다.

생존자들, 그리고 정말로 그들을 구한 것

이제 살아 있는 것들입니다. 흥미로운 점은, 그 누구도 예상한 방식으로 이기지 않았다는 것이고, 여럿은 실패자들이 따랐던 규칙을 깨면서 이겼다는 것입니다.

Roblox: 12년에 걸친 하룻밤의 성공

모두가 Roblox를 모델로 인용합니다. 거의 아무도 실제로 일어난 일을 따라 하지 않습니다. 실제로 일어난 일은 12년간 실패처럼 보이는 것이었기 때문입니다.

Roblox의 2006년 베타는 동시 접속 정점 30~40명에 약 100명의 기술 애호가를 끌어모았습니다. 그 후 10년 넘게 묵묵히 앞으로 갈았습니다. 2016년 초 900만 명에서 2019년 9천만 명, 2023년 2억 1,400만 명까지 갔습니다. 창업자 David Baszucki는 2009년 Minecraft가 자신을 추월해 폭발했을 때조차 사용자 생성 콘텐츠 비전에서 방향을 틀기를 거부했습니다. 그는 그것을 의도적으로 느리게 굽는 과정으로 다뤘고, 결정적이었던 단 하나의 수는 게임을 사내에서 만드는 대신 커뮤니티가 모든 게임을 짓도록 맡긴 결정이었습니다. 그것이 콘텐츠 비용을 없애고 모든 크리에이터를 성장 엔진으로 바꿨습니다.

하지만 여기 카고 컬트 추종자들이 놓치는 부분이 있고, 그래서 나는 두 번째 출처를 항상 열어 둡니다. Matthew Ball의 2024년 분석은 Roblox가 막대한 규모에서도 잔혹한 적자로, 영업이익률이 대략 마이너스 38퍼센트로 운영되고 있으며, 한 달에 그 통화를 구매하는 사용자는 6퍼센트뿐이고 사용자당 매출은 콘솔 플랫폼의 일부에 불과함을 보여줍니다. Roblox는 세계에서 가장 큰 게임인데도 여전히 돈을 버는 데 고전합니다. 플라이휠은 진짜이고 경제성은 어렵습니다. 크리에이터 플랫폼이 돈 찍는 면허라고 말하는 사람이 있다면, 그는 당신에게 뭔가를 팔고 있는 겁니다.

그러나 더 깊은 교훈은 그 사용자 숫자 속에 빤히 숨어 있습니다. Roblox의 수억 명 사용자 중 압도적 다수는 아무것도 짓지 않습니다. 그들은 다른 사람들이 만든 수천만 개 게임 카탈로그를 플레이하러 옵니다. 그 카탈로그를 키우는 데 10년과 개발자 수익 분배 경제가 들었습니다. Roblox는 사람들이 어쩌다 플레이하는 건축 도구가 아닙니다. 일부 사람들이 어쩌다 짓는 놀이 장소입니다. 그 순서가 전부입니다.

Minecraft: 텅 빌 수 없었던 세계

Minecraft는 텅 빈 세계 문제를 겪은 적이 없고, 그 이유를 이해하는 것이 게임의 전부입니다.

Minecraft는 절차적 생성을 갖춘 생존 게임으로 출시되었습니다. 세계가 스스로를 무한히 짓고, 1분째에 당신은 무엇을 해야 할지 고민하며 빈 캔버스를 응시하고 있지 않습니다. 밤이 오고 있고 무언가가 당신을 죽이려 하니, 당신은 땅을 팝니다. 이 게임은 다른 사용자가 0명이고 사용자 생성 콘텐츠가 0이어도 한 사람에게 영원히 재미있습니다. 절차적 생성기가 고갈되지 않는 콘텐츠 기계이기 때문입니다. 모드, 서버, 커스텀 맵, 창작 생태계 전체, 그 모든 것은 이미 스스로 팔린 게임 위에서 자랐습니다. 크리에이티브 모드는 이미 수백만 명이 생존에 빠진 뒤에 나왔습니다. 입소문과 YouTube가 나머지를 했습니다.

Minecraft는 콜드 스타트를 아예 겪지 않음으로써 해결했습니다. 그것이 치트 코드이고, 우리는 그것을 훔칠 겁니다.

브라우저 게임: 유일한 해자가 된 배포

그리고 우리의 실제 전달 방식에 가장 가까운 장르, 다운로드 없는 브라우저 게임이 있습니다.

Agar.io는 2015년 출시 후 몇 주 만에 일일 약 500만 명의 플레이어에 도달했습니다. Slither.io는 모바일 다운로드 6,800만 회와 브라우저 플레이 6,700만 회를 쌓았습니다. 조사는 그 이유에 대해 단도직입적입니다. ".io 장르의 경쟁 해자는 게임 메커니즘이 아니라 배포 그 자체다." 링크를 클릭하면 곧바로 플레이 중입니다. 설치도, 계정도, 앱스토어도 없습니다. Agar.io의 온보딩은 클릭 한 번이었습니다. 이름을 입력하고 플레이를 누르면 들어가 있습니다. TikTok에서 영상이 퍼지듯 채팅 앱을 타고 퍼졌습니다.

하지만 이 선물에는 칼이 들어 있고, 그 칼은 우리 쪽도 벱니다. 다운로드가 없다는 건 약속이 없다는 뜻입니다. 누군가를 들여보내는 바로 그 무마찰성이 그를 나가게도 만듭니다. 탭을 닫는 데 아무 비용도 들지 않으니까요. 브라우저 바이럴은 진짜이고 동시에 기본적으로 얕습니다. .io 게임들은 첫 10초 안에 즉각적이고 명백하게 재미있어서 그것을 견뎌냈습니다. 죽은 브라우저 세계들은 들어가는 데 마찰이 없었고, 일단 도착하면 머무를 이유를 전혀 주지 않았습니다.

Among Us, Figma, Townscaper, VRChat: 이기는 네 가지 방법 더

빠르게 네 가지를 보겠습니다. 각각이 서로 다른 지렛대를 보여 주기 때문입니다.

Among Us는 2018년에 출시되어 2년 동안 상업적으로 아무것도 아니었습니다. 개발자들은 그것을 거의 포기할 뻔했습니다. 그러다 2020년 9월, 점점 더 큰 스트리머들의 사다리가 그것을 발견했고, 여러 시간에 걸친 Sodapoppin 방송에서 정점을 찍으며 전 세계적 현상이 되었습니다. 초기 산소는 itch.io 첫 페이지 피처와, 판매의 절반을 차지하게 된 한국 관객에게서 왔습니다. 교훈은, 발견될 만큼 오래 살아남는다면 돌파구는 출시 몇 년 뒤에, 당신이 계획하지 않은 채널에서 올 수 있다는 것입니다.

Figma는 약 3년간 스텔스 상태였고, 무료로 출시했으며, 과금을 시작하기까지 2년을 더 기다렸습니다. 그 활성화 순간은 멀티플레이어였습니다. 디자이너가 다른 누군가 같은 파일을 편집하는 것을 느낀 바로 그 순간이었습니다. 그리고 여기 중요한 부분이 있습니다. Figma의 무료 티어는 원래 협업자를 2명으로 제한했는데, 이는 제품을 팔리게 한 바로 그 마법 같은 순간을 목 졸랐습니다. 그들은 협업자를 무제한으로 만들어 사람들이 실제로 그것을 느끼게 함으로써 그것을 고쳤습니다. 그들은 Twitter에서 디자인 인플루언서를 직접 겨냥해 커뮤니티의 씨앗을 뿌렸습니다. 교훈은, 당신의 아하 순간을 찾은 뒤, 신규 사용자와 그 순간 사이의 모든 장애물을 치우라는 것입니다.

Townscaper는 스크린샷의 힘으로 히트한 작은 창작 장난감이었습니다. 그 개발자는 개발 도중 클립을 올리는 것만으로 자신의 Twitter 팔로워가 약 2만 명에서 9만 명으로 뛰는 것을 지켜봤고, 그것을 잘될 것이라는 초기 신호로 읽었습니다. 교훈은, 당신의 것이 아름답고 출시도 하기 전에 사람들이 시키지도 않았는데 공유한다면, 그것이 존재하는 가장 진짜인 검증이라는 것입니다.

그리고 VRChat은 Meta의 수십억 달러와 Rec Room이 둘 다 접은 바로 그 몇 달 동안, 동시 접속자 거의 16만 명이라는 기록을 세웠습니다. 그것은 커뮤니티 주도, 크리에이터 주도이며, 주변에서 죽어간 것들만큼 자금이 넉넉하지도 않습니다. VRChat은 자신의 생존을 자본보다 커뮤니티의 충성심과 창의성 덕으로 돌립니다. 교훈은, 생존자 자신의 입으로 말하건대, 몰입한 크리에이터의 열정이 돈보다 오래간다는 것입니다.

산 자와 죽은 자를 실제로 가르는 것

이야기들을 나란히 놓으면 패턴은 미묘하지 않습니다.

창작 세계를 죽이는 것은 빈 방입니다. Horizon Worlds, Decentraland, Dreams, Crayta, Project Spark, Sansar, 모두 같은 죽음을 맞았습니다. 사람이 충분치 않고, 콘텐츠가 충분치 않고, 돌아올 이유가 충분치 않은 것이, 스스로를 먹이로 삼는 고리 안에서 일어났습니다. 콜드 스타트 문제가 보스전입니다. 나머지는 전부 튜토리얼 레벨입니다.

그들을 구하는 것은 군중이 나타나기 전에 존재할 이유를 갖는 것입니다. Minecraft는 절차적 생존을 가졌습니다. Roblox는 10년간 인내심 있게 씨를 뿌린 게임들을 가졌습니다. .io 게임들은 10초의 재미를 가졌습니다. 모든 생존자는 카탈로그가 비어 있어도 당신의 시간을 쓸 가치가 있었습니다. 모든 희생자는 다른 사람들이 방문할 가치를 만들어 주기를 기다리는 아름다운 그릇이었습니다. 이것이 Dreams의 고백을 일반화한 것입니다. 먼저 게임을 짓고, 플랫폼은 그다음입니다. 플랫폼은 2막입니다. 사람들이 그 자체로 쓰는 무언가가 먼저 됨으로써 그것을 벌어야 합니다.

실제로 생존을 예측하는 지표는 보도자료에 있는 것들이 아닙니다. 조사는 여기서 일관됩니다. 제품-시장 적합성의 결정적 신호는 당신의 리텐션 곡선이 평평해지는 것입니다. 어떤 코호트의 사람들이 영원히 계속 돌아오는 것입니다. 0으로 떨어지는 곡선은, 깔때기 위쪽이 아무리 커도 적합성이 없다는 뜻입니다. 대략적인 업계 벤치마크는 1일차 40퍼센트, 7일차 20퍼센트, 30일차 10퍼센트 리텐션이고, 장기 건강을 예측하는 것은 30일차입니다. 그리고 크리에이터 측이 있는 모든 것에서, 당신이 죽는 곳은 공급 측입니다. 실패한 마켓플레이스의 약 67퍼센트가 수요가 아니라 공급에서 무너집니다. 크리에이터 리텐션이 활력 징후입니다. 가입 계정 수와 가치 평가는 허영입니다.

이야기들에서 떨어지는 몇 가지가 더 있습니다. 크리에이터를 수익화하라, 아니면 그들을 잃는다. Dreams가 재능 있는 사람들은 상방이 없으면 수년을 투자하지 않는다는 것을 증명했기 때문입니다. 멀티플레이어는 대개 기능이 아니라 핵심입니다. Media Molecule 자신의 후회가 그렇습니다. 당신을 쫓아낼 수 있는 플랫폼 위에 절대 집을 짓지 마라, Crayta가 그렇습니다. 그리고 다운로드 없음은 양날의 검입니다. 존재하는 최고의 획득 채널이자 가장 약한 약속 장치이므로, 부담은 전적으로 첫 60초가 좋아야 한다는 데 떨어집니다.

그 모든 것 아래의 함정

한 겹이 더 있고, 그것은 우리 시대에 특유한 것입니다. 우리에게는 죽은 자들이 결코 갖지 못한 도구가 있기 때문입니다. 우리는 AI로 세계를 생성할 수 있습니다. 그것은 내가 몇 주 동안 오락가락한 역설을 제기합니다.

AI라면, 모든 세계가 각 사람에게 맞춰 새로 생성된, 고유한 것이어야 하지 않을까요? 하지만 각 사람의 세계가 고유하다면, 공유된 순간이 공유된 장소를 요구한다는 점을 감안할 때, 도대체 누가 다른 누군가와 마주칠 수 있을까요? 그리고 어차피 세계가 공유되어야 한다면, 진짜 스튜디오처럼 아름다운 장소 하나를 손으로 만드는 대신 굳이 AI를 쓸 이유가 뭘까요?

그 각각의 끌림을 끝까지 따라가면, 작동하지 않는 무언가에 도달합니다. 오직 당신만을 위해 생성된 세계는 아무도 없는 세계입니다. Google의 Genie는 한 문장에서 플레이 가능한 환경을 띄울 수 있지만 1분 뒤에 사라집니다. 싱글 플레이어, 기억 없음, 이웃 없음. 그것이 쓸쓸한 막다른 길입니다. 하지만 고정된 세계 하나를 손으로 만드는 것도 막다른 길입니다. 2제곱킬로미터를 손으로 채우는 것은 100명이 여러 해를 들이는 일이고, 다 끝나면 그것은 얼어붙어, 백 번째 방문에도 첫 번째와 똑같이, 사람들이 도착해도 자라지 못합니다.

빠져나갈 길은 "세계"를 하나의 것으로 취급하기를 멈추는 것입니다. 그것은 세 겹이고, 고유함과 공유됨은 서로 싸우지 않고 서로 다른 겹에서 살 수 있습니다. 모두가 서 있는 땅은 하나의 공유된 세계, 높은 기준으로 큐레이션된 만남의 장소입니다. 당신이 거기에 가져오는 것, 당신의 AI 생성 에셋, 당신이 만든 건물은 굉장히 고유하고, 당신은 그것을 공유된 세계 안에 예치해 당신의 고유함이 다른 모두의 발견이 되게 합니다. 그리고 그것을 통과하는 당신의 경로, 당신이 받는 퀘스트, 그것이 당신을 가리키는 방향은 공짜로 개인화됩니다. 경로는 장소가 아니기 때문입니다. 거짓 선택지는 "개인화된 세계"였습니다. 그것은 멀티플레이어를 죽입니다. 반면 "공유된 세계를 통과하는 개인화된 경로"는 그것을 더 깊게 합니다. 우리는 두 번째를 원합니다.

그러니 AI의 일은 결코 각 사람에게 사적인 세계를 건네는 것이 아니었습니다. 그 일은 하나의 공유된 세계가 무한하고, 살아 있고, 통과하기에 개인적으로 느껴지게 만드는 것입니다. 고유함은 시간이 흐르며 그 안에 쌓이는 모든 것, 모든 크리에이터의 단 하나뿐인 기여에서 옵니다. 모든 Minecraft 서버는 고유합니다. 특정 서버에 있는 모두가 그것을 공유합니다. 그것은 모순이 아닙니다. 그것이 전체 트릭이고, 이 글 맨 위의 스크린샷, 다른 사람들도 걸어 들어올 수 있는 세계에 그대로 머무는 집을 AI가 짓는 그것이, 현실이 된 그 트릭입니다.

우리가 Cinevva World를 출시하는 방법

그래서 이 모든 것이 우리에게 무엇으로 바뀌는지 여기 있습니다. 마케팅 계획이 아닙니다. 다섯 가지 베팅이고, 이 글 전반부에서 모두를 죽인 다섯 가지에 의도적으로 맞서 놓은 것입니다. 그리고 각각을 증거가 실제로 얼마나 뒷받침하는지로 채점하겠습니다. 채점할 수 없는 계획은 그저 조명만 좋은 소원이기 때문입니다.

첫 번째 베팅, 내가 회사를 걸 그것: 우리는 플랫폼이 아니라 게임을 출시합니다. 이건 선호가 아니라, 이 연구 전체에서 가장 일관된 발견입니다. Minecraft, Roblox, Fortnite는 모두 할 재미있는 무언가로 시작했고 그 위에 크리에이터 층을 키웠습니다. 살아 있는 가장 재능 있는 창작 스튜디오 Media Molecule은 사후에 Dreams가 먼저 게임이었어야 했다고 결론지었습니다. 그래서 새로운 사람이 Cinevva World에서 처음 하는 일은 빈 부지를 응시하는 것이 아닐 겁니다. 그것은 목표가 있는 루프, 거의 아무도 온라인에 없는 화요일에도 거기 있을 이유일 겁니다. 나타나는 대부분의 사람은 플레이만 하고 결코 짓지 않을 것이며, 그것은 실패가 아니라 설계입니다. 그것이 Roblox의 실제 형태입니다. 플레이하는 수억 명이, 만드는 얇은 층 위에 앉아 있는 것입니다. 플라이휠은 2막이고, 우리는 그것을 벌어야 합니다. 이건 확신합니다. 무덤이 이미 그 실험을 돌렸기 때문입니다.

두 번째 베팅, 솔직히 도박인 그것: AI 덕분에 우리는 다른 모두가 기다리다 죽은 공급을 제조할 수 있습니다. 이것이 왜 보장이 아니라 베팅인지 정확히 말하고 싶습니다. 이 연구의 어떤 플랫폼도 생성형 AI로 부트스트랩된 적이 없기 때문입니다. 나에게는 메커니즘이 있지, 증명이 있는 게 아닙니다. 메커니즘은 이렇습니다. 양면 플랫폼의 대략 3분의 2가 수요 측이 아니라 공급 측에서 죽습니다. 전형적인 해법은 진짜가 될 때까지 공급을 가짜로 채우는 것입니다. DoorDash가 음식 자체를 운전해 나르고, Reddit 팀이 가짜 핸들로 글을 쓰고, Roblox 창업자들이 수년간 초기 게임을 손으로 지은 방식입니다. 우리는 그것을 생성으로, 그들 누구도 갖지 못한 비용과 속도로 할 수 있습니다. 하지만 여기 나를 정직하게 잡아 두는 부분, 즉 Decentraland 묘비명이 있습니다. Decentraland는 생성된 것으로 가득했고 하루에 약 서른 명을 끌어모았습니다. 예쁜 것이 시간을 쓸 가치가 있는 것과 같지 않기 때문입니다. 그러니 나는 AI가 세계를 재미있게 만든다고 베팅하는 게 아닙니다. 그건 못 합니다. 나는 AI가 에셋 병목을 없애서, 우리의 희소한 인간 노력의 모든 시간이 실제로 사람들을 붙잡아 두는 단 하나, 즉 루프에 들어가도록 베팅하는 겁니다. AI가 언덕을 싸게 짓습니다. 우리는 그 언덕을 오를 이유를 손으로 짓습니다. 그리고 우리는 합성 씨앗을 대략 30퍼센트로 제한하고, 약 60일 안에 진짜 크리에이터 콘텐츠로 전환합니다. 진짜가 되지 않는 가짜 공급은 누군가 알아채는 순간 신뢰를 깨뜨리기 때문입니다.

세 번째 베팅: 우리는 우리 자신의 중단 기준을 공개합니다. 이것이 근거 있는 계획과 희망적인 계획의 차이입니다. 모든 단일 사례에서 생존을 예측한 지표는 리텐션 곡선이 평평해지는지, 어떤 코호트가 0으로 쇠퇴하는 대신 계속 돌아오는지였습니다. 그래서 그것이 우리가 우리 자신에게, 소리 내어, 적용하는 시험입니다. 알파 7일차 리텐션이 평평해지지 않는다면, 결코 짓지 않는 플레이어들이 돌아오지 않는다면, AI가 씨 뿌린 콘텐츠가 그냥 지나쳐지고 무시당한다면, 그 가설은 틀린 것이고, 우리는 그것을 바꾸거나 멈춥니다. 우리는 플레이어와 크리에이터를 두 개의 분리된 깔때기, 두 개의 분리된 아하 순간으로 추적할 겁니다. 그들이 같은 사람이 아니라는 것이 데이터로 분명하기 때문입니다. 그리고 우리는 돈이 초기 일을 한다고 가장하지 않을 겁니다. 50명, 아니 천 명 단위에서도 팁과 마켓플레이스 수익은 0에 수렴하므로, 아직 아무도 붙잡지 못합니다. 초기 리텐션은 루프에서 오거나, 아예 오지 않거나입니다. Dreams가 그걸 거꾸로 한 영수증입니다.

네 번째 베팅: 우리는 의도적으로 좁게 시작합니다. 네트워크형 제품에 관한 조사는 만장일치입니다. 당신은 시장에 출시하는 게 아니라, "원자 네트워크", 즉 그 자체로 살아 있을 만큼 충분히 밀도 높은 가장 작은 그룹에 출시합니다. Facebook은 한 학교에서 시작했습니다. 우리 것은 이미 존재합니다. 3D 에셋, 음악, 사운드를 생성했고 이미 배치할 재고를 가진 Cinevva 크리에이터들입니다. 그들 중 50명이 같은 시간에 한 세계에, 목표와 개척지를 가지고 있는 것이, 흩어진 가입자 5만 명이 결코 될 수 없는 더 밀도 높고 더 살아 있는 것입니다. 증거가 이것을 강하게 뒷받침합니다.

다섯 번째 베팅, 가장 무른 것이고, 나도 그렇다고 말하겠습니다: 우리는 텅 빔을 숨기는 대신 그것에 관한 진실을 말합니다. 잘 다듬어진 조용한 세계는 죽은 것으로 읽히고, 실패자들은 모두 그것을 분위기 효과로 덮으려 했습니다. 우리는 그 반대를 시도할 겁니다. 이것이 다섯 중 가장 덜 입증된 수이고, 발견이라기보다 직감에 가깝습니다. 처음 들어오는 사람들은 미완성 제품을 방문하는 게 아닙니다. 그들은 일찍 왔기에 텅 빈 어떤 장소의 창립 시민이고, 그들이 짓는 것은 다음 천 명이 도착할 때도 여전히 서 있을 겁니다.

그것이 정직하게 채점한 계획입니다. 무덤이 강하게 뒷받침하는 네 가지 베팅, 그리고 죽은 자 누구도 갖지 못한 도구에 거는 진짜 도박 하나, 그들이 결여했던 바로 그 규율로 울타리를 친 것입니다. 우리는 언덕을 생성할 수 있습니다. 우리는 그 언덕을 처음 오르는 느낌이나, 정상에서 손 흔드는 낯선 사람을 생성할 수 없습니다. 우리의 일은 그 손짓을 가능하게 만들고, 그것을 리텐션 곡선 위에서 증명하고, 곡선이 아니라고 말하는 순간 우리 자신을 속이기를 멈추는 것입니다.

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

처음 오셨나요? 시리즈 가이드를 보세요. spike가 무엇인지 설명하고 모든 파트로 연결해 둡니다.

29부에서는 어떤 몸이든 구동하는 컨트롤러 하나를 얻었습니다. 이제 몸은 제대로 움직입니다. 걷고, 미끄러지고, 수영하고, 활공하고, 동굴로 기어 들어가고, 돌출부 아래로 몸을 숙입니다. 문제는 그것을 지켜보는 쪽입니다. 29개 파트 동안 카메라는 플레이어를 따라다니는 평범한 오빗 리그였고, 망신을 피하려고 딱 한 가지 영리한 짓만 했습니다. 지평선 아래로 기울지 않으려 했고, 그래서 평평한 땅 밑으로 미끄러져 들어갈 수 없었습니다. 그 클램프가 바로 증거입니다. 카메라가 세계의 지오메트리가 실제로 어디에 있는지 전혀 몰랐기 때문에 존재하는 것이고, 클리핑을 막을 유일한 방어책은 클리핑이 가장 일어나기 쉬운 각도를 아예 금지하는 것뿐이었습니다. 언덕으로 다가가면 카메라가 언덕 안에 들어가 앉았습니다. 7부의 마칭 큐브 동굴 하나로 발을 들이면 바위 속을 들여다보게 됐습니다. 16부의 저작 도구로 집을 짓고 방 안에 서면, 카메라는 벽 바깥으로 떠올라 외벽 마감재를 바라봤습니다. 이번 파트는 카메라에게도 몸이 이미 가진 것과 같은, 지오메트리에 대한 존중을 줍니다.

문제의 모양, 그리고 해법의 모양

3인칭 카메라에는 어려운 일이 하나 있고 쉬운 일이 열두 가지 있습니다. 쉬운 쪽은 따라가기, 부드럽게 보정하기, 오빗 입력이고, 이건 이미 다 갖고 있었습니다. 어려운 쪽을 학계 문헌에서는 가시성 제약(visibility constraint)이라 부르고, 모두가 인용하는 서베이인 Christie와 Olivier의 Camera Control in Computer Graphics는 분야 전체를 이것을 중심으로 정리합니다. 세계를 존중하면서도 피사체를 프레임 안에 두고 가려지지 않게 유지하라. 런타임에서 이것은 매 프레임 던지는 속아 넘어가기 쉬울 만큼 단순한 질문으로 줄어듭니다. 플레이어가 피벗입니다. 사용자가 회전하고 줌해서 그들 뒤 어느 정도 거리에 원하는 카메라 위치를 정했습니다. 그 선을 따라 카메라가 무언가 단단한 것에 찔리기 전에 실제로 얼마나 뒤로 앉을 수 있을까요? 이 질문에 정직하게 답하면 카메라는 언덕 앞으로 몸을 집어넣고, 구석으로 후진할 때 붐을 따라 미끄러져 내려오며, 동굴 천장을 뚫는 대신 거기서 멈춥니다.

이 질문에 답하는 패턴은 오래됐고 검증됐습니다. Unreal은 스프링 암이라 부르고, Godot는 SpringArm3D 노드를 제공하며, Unity의 Cinemachine은 그것을 3인칭 팔로우 리그와 디오클루더(deoccluder) 확장으로 나눠 둡니다. 발상은 늘 같습니다. 카메라를 피벗에 고정된 붐 끝에 매답니다. 길이 트여 있으면 원하는 길이로 잡아두고, 무언가 가로막으면 피벗 쪽으로 거둬들이며, 길이 트이면 다시 펴 줍니다. Metroid Prime의 카메라 리드가 쓴 Mark Haigh-Hutchinson의 Real-Time Cameras는 이것의 순진한 버전이 플레이어를 멀미 나게 만드는 실패 모드에 챕터 여러 개를 통째로 씁니다. 우리는 그 패턴을 가져와 한자리에서 다 읽을 수 있을 만큼 작은 우리만의 것을 public/world/src/camera-rig.mjs에 만들었습니다.

자기 길이만 책임지는 붐

리그를 작게 유지해 준 설계 규칙은 29부 컨트롤러 작업에서 빌려온 것입니다. 한 가지를 완전히 책임지고 나머지는 거절하라. 리그는 붐의 길이를 책임지고 그 외에는 아무것도 책임지지 않습니다. 요(yaw), 피치, 오빗 댐핑, 터치와 휠 제스처, 이 모든 것은 OrbitControls에 남겨 둡니다. OrbitControls는 이미 그것들을 잘 풀어내고 있고, 우리는 그걸 다시 쓸 생각이 전혀 없습니다. 그래서 리그는 카메라 컨트롤러가 아닙니다. 오빗 계산이 끝난 뒤에 돌면서 딱 한 숫자, 피벗에서 카메라까지의 거리만 보정하는 후처리입니다.

이 결정은 깔끔하게 들리지만 거의 곧바로 깨질 뻔했습니다. OrbitControls가 생각하는 방식 때문입니다. 매 업데이트의 맨 위에서 OrbitControls는 카메라의 현재 위치를 읽고 거기서 오빗 반지름을 끌어냅니다. 보통은 보이지 않는 동작입니다. 그런데 우리 리그가 벽을 피하려고 카메라를 짧게 당기는 순간, 다음 프레임에 OrbitControls가 그 짧아진 위치를 읽고 사용자가 줌인했다고 결론 내린 다음, 그 짧아짐을 사용자가 원한 줌에 구워 넣습니다. 그게 몇 프레임 이어지면 카메라는 플레이어 머리 위로 무너져 내리고 다시 나오지 않습니다. 해법은 오빗 업데이트를 앞뒤로 감싸는 호출 두 개이고, 통합은 그게 전부입니다. OrbitControls가 돌기 전에 beforeControls()가 카메라를 지난 프레임의 온전한, 짧아지지 않은 거리로 복원해서 오빗 계산이 항상 사용자의 진짜 줌을 읽게 합니다. OrbitControls가 돈 뒤에 afterControls(dt)가 방금 오빗된 원하는 위치를 읽어 충돌을 해결하고, 길이를 댐핑하고, 카메라가 실제로 렌더링되어야 할 곳에 씁니다. 사용자의 의도와 충돌 보정은 서로 절대 닿지 않고, 달리(dolly)는 리그가 존재하기 전과 정확히 똑같이 반응합니다. 리그를 위해 우리가 쓴 헤드리스 테스트가 이것을 정확히 못박습니다. 붐을 60프레임 동안 벽으로 밀어 넣고, 벽을 벗어나면 길이가 충돌 거리에 붙어 있는 대신 사용자의 온전한 줌인 10미터로 다시 튀어 나옵니다.

계약 하나, 콜라이더는 무엇이든

리그는 세계가 무엇으로 만들어졌는지 절대 묻지 않습니다. 콜라이더는 그저 probe 메서드를 가진 객체일 뿐이고, 리그는 거기에 레이, 최대 거리, 카메라의 프로브 반지름을 건네주고 숫자 하나를 돌려받습니다. 그 콜라이더가 막기 전에 카메라가 갈 수 있는 가장 먼 거리입니다. 리그는 등록된 모든 콜라이더에 질의하고 가장 가까운 히트를 택합니다. 그게 계약의 전부이고, 캐릭터 컨트롤러가 이동을 플러그인 가능한 동작으로 바꿨을 때 한 것과 같은 수입니다. 지형이 끼워지고, 소품이 끼워지고, 건물 셸이 끼워지는데, 각각이 같은 probe 뒤에 있고, 리그는 그 모두에 대해 무지한 채로 남습니다. 새로운 종류의 장애물을 더하는 일은 카메라를 고치는 게 아니라 콜라이더를 목록에 더하는 일입니다.

계약 안의 한 가지 디테일이 제 몫을 합니다. 바로 프로브 반지름입니다. 우리는 피벗에서 카메라로 가느다란 레이를 쏘지 않고, 카메라의 근평면을 담을 만큼 큰 구를 쏩니다. 단일 레이는 카메라 중심을 벽에서 멈추지만, 근평면에는 폭이 있어서 그 모서리들은 중심 레이가 히트를 보고하기도 전에 이미 벽에 파묻혀 있습니다. 레이 대신 작은 구를 휘둘러 쓰는 것은 출시된 모든 구현이 하는 일이고, Unreal은 그것을 프로브 크기로 노출합니다. 표면에 깨끗하게 가서 멈추는 카메라와 화면 가장자리에서 너머가 비쳐 보이게 두는 카메라의 차이가 바로 이것입니다.

우리는 그 반지름을 추측하지 않고 도출합니다. 카메라에서 근평면의 가장 먼 점은 그 모서리 중 하나이고, 거기까지의 거리는 투영에서 곧장 떨어져 나옵니다. 근평면 $n$과 수직 시야각 $\theta$에서, 절반 높이는 $h=n\tan (\theta /2)$, 절반 폭은 $w=h\cdot \text{aspect}$이고, 모서리는 다음 위치에 있습니다.

프로브 반지름은 그 모서리 거리에 작은 안전 여유를 곱한 값이고, 아주 좁은 절두체에서도 합리적인 최솟값 아래로 떨어지지 않도록 고정 하한을 둡니다. 시야각, 종횡비, 근평면이 바뀔 때마다 반지름을 다시 계산해서, 창 크기 변경이나 투영을 건드리는 줌이 프로브를 보호해야 할 모서리를 덮지 못할 만큼 조용히 작게 남겨 두는 일이 없게 합니다.

동굴을 아는 콜라이더

지형 콜라이더가 흥미로워지는 지점입니다. 우리 엔진의 지형은 하이트맵이 아니기 때문입니다. 7부 이후로 그것은 부호 거리 필드(signed distance field)였습니다. 공간의 임의의 점이 가장 가까운 단단한 표면에서 얼마나 떨어져 있는지, 그리고 바위 안쪽인지 바깥쪽인지를 돌려주는 함수입니다. 양수는 공기, 음수는 바위이고, 바로 그 단 하나의 사실이 우리 카메라가 하이트맵 카메라로는 구조적으로 불가능한 일을 할 수 있는 이유입니다. 하이트맵은 어떤 x와 z에서의 지면 높이를 압니다. 천장이라는 개념은 없습니다. 어떤 점 위에는 언제나 표면이 하나뿐이기 때문입니다. 그래서 하이트맵 카메라는 당신이 언덕으로 걸어 들어가는 것은 막을 수 있어도, 돌출부 입술이나 동굴 지붕이 피벗 위에 걸려 있다는 것은 전혀 모르고 둘 다 그대로 뚫고 지나갑니다. 거리 필드는 3차원의 모든 표면을 알기 때문에, 언덕 비탈에서 카메라를 멈추는 같은 프로브가 단 하나의 특수 처리도 없이 동굴 천장에서 카메라를 멈춥니다.

필드를 따라 프로브를 걷게 하는 것은 이름과 논문이 있는 기법입니다. 1996년 John Hart의 Sphere Tracing은 거리 필드에 대해 레이를 행진시키는 표준 방법이고, 비결은 필드가 무언가에 부딪혔는지만 알려주는 게 아니라 부딪히지 않고 전진할 수 있는 안전 거리를 알려준다는 점입니다. 그래서 작고 고정된 보폭으로 살금살금 가는 대신, 필드를 샘플링하고, 보고된 여유만큼 앞으로 나아가고, 반복합니다. 트인 공기 속에서는 성큼성큼 걷고 표면에 가까워질수록 짧고 조심스럽게 걷습니다.

다만 우리 지형이 강요하는 함정이 하나 있습니다. 진짜 거리 필드는 가장 가까운 표면까지의 실제 유클리드 거리를 보고하고, 그 여유만큼 한 걸음 통째로 가는 것은 언제나 안전합니다. 그런데 지형이 깎인 복셀이 아니라 아직 하이트맵인 곳에서는, 우리가 싸게 샘플링할 수 있는 필드가 진짜 거리가 아니라 수직 여유(vertical clearance), 곧장 아래 지면까지의 간격입니다. 비탈에서는 가장 가까운 바위가 바로 아래가 아니라 옆쪽에 있기 때문에, 그 숫자는 카메라가 실제로 움직일 수 있는 거리를 과대 보고합니다. 정직한 거리는 경사도에 따라 커지는 인자 $\sqrt{1+\Vert \mathrm{\nabla }h{\Vert }^2}$만큼 더 작아서, 보고된 여유에 맞춰 잡은 보폭은 과도하게 넘어가 능선을 깨끗이 뛰어넘어 버릴 수 있습니다. 해법은 과소 완화(under-relaxation)입니다. 보고된 여유 전부가 아니라 그 일부만큼만 전진하는 것으로, 대략 60도 경사까지 안전하게 유지되고 진짜 거리 복셀 영역에서는 샘플 몇 개를 더 쓰는 것 말고는 비용이 들지 않습니다. 여기에 보폭 하한을 짝지어, 한두 셀 두께의 동굴 벽이 깨끗이 건너뛰어지는 일이 없게 하고, 더 빡빡한 상한으로 행진을 싸게 유지합니다. 구가 마침내 표면에 닿으면 짧은 이분법으로 접촉점을 좁히고, 카메라는 자기 반지름만큼 물러나 거기에 머뭅니다.

써 놓고 보면, 붐은 피벗 $\mathbf{p}$에서 단위 방향 $\mathbf{d}$를 따라가는 레이 $\mathbf{r}(t)=\mathbf{p}+t\mathbf{d}$이고, 행진은 접촉에 이르기까지 필드 여유의 과소 완화된 일부만큼 전진하며 양 끝에서 클램프됩니다.

여기서 $\mathrm{\Phi }$는 부호 거리로 공기 중에서 양수이고 바위 안에서 음수, $r$은 프로브 반지름, $\lambda \in (0,1]$은 과대 보고하는 하이트맵 필드가 비탈을 뛰어넘지 못하게 막는 과소 완화 인자, $s_{min},s_{max}$는 얇은 벽이 건너뛰어지지 않고 행진이 너무 길어지지 않게 하는 보폭 클램프입니다. 접촉은 $\mathrm{\Phi }(\mathbf{r}(t))\le r$인 첫 번째 $t$로, 구의 표면이 바위에 도달했다는 뜻이고, 카메라는 그 호 길이에서 반지름을 뺀 지점에 머뭅니다.

콜라이더는 안전망으로 메서드 하나를 더 지닙니다. 침투 해소(depenetration)입니다. 충돌은 애초에 카메라를 단단한 것 바깥에 두어야 하지만, 몇몇 상황이 그것을 슬쩍 빠져나갑니다. 붐이 그 안에서 시작될 만큼 얇은 벽에 걸쳐 선 피벗, 카메라가 앉아 있던 바위가 지형 도구로 방금 깎여 동굴이 되어버린 경우, 카메라 둘레로 떨어뜨려진 건물 조각 같은 것들입니다. 그런 경우를 위해 콜라이더는 카메라가 단단한 것 안에서 프레임을 끝냈는지, 곧 $\mathrm{\Phi }(\mathbf{c})<r$인지를 확인하고, 그렇다면 필드의 그래디언트를 읽습니다. $\mathrm{\Phi }$는 바위를 벗어날수록 커지므로 그래디언트는 트인 공기 쪽을 곧장 가리킵니다. 그 방향을 따라 카메라를 밖으로 밀어냅니다.

이런 반복 몇 번이면 $r$-등위면으로 수렴하고, 이것이 바로 조각 도구가 카메라 발밑의 땅을 파내도 화면이 까매지는 대신 다음 프레임에 시야가 회복되게 만드는 것입니다.

빠르게 들어가고, 느리게 풀어주며, 울타리 기둥에 움찔하지 않기

매 프레임 충돌 거리로 그냥 점프하는 붐은 붐이 없느니만 못합니다. 세계는 카메라가 한 프레임 동안 뒤로 지나치는 얇은 것들로 가득하기 때문입니다. 울타리 기둥, 가로등, 나무줄기, 그리고 그 하나하나를 피하려 달려들었다가 다시 달려드는 카메라는 메스껍습니다. Haigh-Hutchinson의 책과 Itay Keren의 사랑받는 카메라 모션 강연은 둘 다 같은 직관에 도달합니다. 카메라는 위협과 위험에는 거기서 풀려나는 것보다 더 빨리 반응해야 한다는 것입니다. 그래서 댐핑은 일부러 비대칭입니다. 가림막이 나타나 붐이 짧아져야 할 때는 거의 즉시 들어옵니다. 한 프레임의 클리핑은 보기 흉하고, 플레이어는 빠른 끼워 넣기를 용서하기 때문입니다. 가림막이 사라져 붐이 늘어나려 할 때는 천천히 풀려 나오고, 그것도 연속해서 트여 있는 짧은 대기 타이머가 지난 뒤에야 그렇게 합니다. 그 대기가 움찔거림을 죽이는 히스테리시스입니다. 얇은 기둥 옆을 카메라로 휙 지나가면 기둥은 느린 확장을 촉발할 만큼 오래 트이는 법이 없어서, 카메라는 그것이 없는 것처럼 미끄러져 지나갑니다. 바로 당신의 눈이 원하는 것이죠. Cinemachine은 같은 발상을 충돌로 들어가는 댐핑과 충돌에서 나오는 댐핑이라는 별도의 값으로 노출하고, 이 비대칭이 그것을 스프링이 아니라 카메라 오퍼레이터처럼 느껴지게 만드는 부분입니다.

코드로는 변화의 부호에 따라 비율을 전환하는 지수 평활화 한 줄입니다. $\ell$이 현재 붐 길이, $a$가 이번 프레임 충돌이 허용하는 길이, $\mathrm{\Delta }t$가 프레임 시간이라면,

이고, 풀려 나오는 분기는 트인 상태가 대기 시간 $\tau$ 동안 유지된 뒤에만 돕니다. $1-e^{-k\mathrm{\Delta }t}$ 형태는 깔끔해 보이는 것 이상의 의미가 있습니다. 프레임 레이트와 무관하게 응답 시간 상수를 $1/k$로 고정해서, 카메라가 초당 30프레임에서도 144프레임에서도 똑같이 느껴지게 합니다. 순진한 상수 블렌드 $\ell \leftarrow \ell +\alpha (a-\ell )$였다면 빠른 기계에서는 더 빨리 끼워지고 느린 기계에서는 뭉개졌을 것입니다.

마지막 동작은 이 파트 전체를 시작하게 만든 좁은 실내를 위한 것입니다. 붐이 카메라가 플레이어 바로 위에 올 만큼 짧게 무너지면, 플레이어 자신의 아바타를 숨기고 시야가 1인칭에 가깝게 앉게 둡니다. 비좁은 사당에서 Breath of the Wild가 하는 일이고, 대부분의 3인칭 게임이 구석에서 기대는 동작입니다. 대안인 벽에 박혀 머리 뒤통수를 노려보는 카메라는 쓸모가 없기 때문이죠. 리그는 이를 위해 플래그 하나를 노출하고, 월드 루프는 그 플래그를 읽어 로컬 아바타의 가시성을 토글합니다. 붐이 1미터 아래면 당신은 사실상 1인칭이고, 벽은 존중되며, 공간이 있는 방으로 후진하는 순간 아바타가 다시 페이드 인되고 붐이 늘어납니다.

다음에 끼워질 것

지형 콜라이더는 오늘 출시되고, 어려운 절반입니다. 지형은 어디에나 있고 거리 필드는 프로브하기 까다로운 대상이기 때문입니다. 저작 spike에서 나온 소품과 건물 셸은 쉬운 절반이고, 계약은 이미 그들을 기다리고 있습니다. 두 번째 콜라이더인 레이캐스트 콜라이더는 피벗에서 카메라를 향해 메시 목록에 대고 레이를 쏘고, 지형 콜라이더와 똑같은 방식으로 가장 가까운 히트를 보고합니다. 싼 버전은 단일 레이를 쏘는데, 소품 수가 늘기 전까지는 괜찮고, 업그레이드는 그 레이를 three-mesh-bvh를 쓴 휩쓸린 구로 바꾸는 것입니다. Garrett Johnson의 라이브러리로, 메시를 바운딩 볼륨 계층으로 감싸 공간 질의가 무차별 대입 대신 로그 시간에 돌게 합니다. 어느 쪽이든 리그는 바뀌지 않습니다. 더 긴 콜라이더 목록에 질의하고 가장 가까운 히트를 택할 뿐이고, 그것이 계약을 먼저 만들고 콜라이더를 나중에 만든 일의 전체 핵심입니다.

이 챕터에서 참조한 기술

숫자 하나만 책임지는 붐. 카메라 리그는 OrbitControls를 대체하는 것이 아니라 그 위의 후처리입니다. 붐의 길이를 책임지고, 요, 피치, 줌, 제스처 처리는 이미 신뢰하던 오빗 컨트롤러에 남깁니다. 통합은 앞뒤로 감싸는 호출 두 개입니다. beforeControls()가 지난 프레임의 온전한 거리를 복원해 오빗 계산이 충돌 짧아짐을 달리인으로 착각하지 않고 사용자의 진짜 줌을 읽게 하고, afterControls(dt)가 충돌을 해결하고 렌더링 위치를 씁니다. 이 한 쌍이 없으면 카메라는 몇 프레임에 걸쳐 플레이어 위로 무너집니다.

플러그인 가능한 콜라이더 계약. 콜라이더는 "이 레이를 따라 피벗에서 당신이 막기 전까지 카메라가 얼마나 갈 수 있는가"에 답하는 probe를 가진 임의의 객체입니다. 리그는 모든 콜라이더에 질의하고 가장 가까운 히트를 택하며, 장애물이 지형인지 소품인지 벽인지 모릅니다. 플러그인 가능한 캐릭터 컨트롤러가 이동에 쓴 것과 같은 한 가지만 책임지는 규율입니다. 프로브는 가느다란 레이가 아니라 근평면을 담도록 크기를 맞춘 휩쓸린 구라서, 중심 레이가 놓칠 표면을 절두체 모서리가 절대 클리핑하지 않습니다. 그 반지름은 투영에서 도출됩니다. 근평면 모서리까지의 거리 $\sqrt{n^2+w^2+h^2}$에 안전 여유를 곱한 값이고, 시야각, 종횡비, 근평면이 바뀔 때마다 다시 계산됩니다.

돌출부와 동굴을 존중하는 부호 거리 지형 프로브. 지형이 하이트맵이 아니라 부호 거리 필드이기 때문에, 언덕 비탈에서 카메라를 멈추는 같은 프로브가 동굴 천장에서도 카메라를 멈춥니다. 하이트맵 레이캐스트로는 구조적으로 볼 수 없는 경우입니다. 행진은 Hart 방식의 스피어 트레이싱으로, 필드가 보고하는 여유의 과소 완화된 일부만큼 나아가며 양 끝에서 클램프됩니다. 하이트맵 영역은 진짜 거리가 아니라 수직 여유를 보고해서 비탈에서 카메라가 움직일 수 있는 거리를 과대 보고하므로, 한 걸음 통째로는 능선을 뛰어넘기 때문입니다. 그래디언트 기반 침투 해소 패스가 카메라 발밑의 땅이 깎여 나갔을 때 시야를 회복시키는 안전망입니다.

대기 타이머가 딸린 비대칭 댐핑. 붐은 가림막이 나타나면 빠르게 들어가고, 가림막이 사라지면 천천히, 그것도 연속해서 트인 짧은 구간이 지난 뒤에야 풀려 나옵니다. 그래서 울타리 기둥을 휙 지나가도 카메라가 절대 달려들지 않습니다. 무너짐 임계값 아래에서는 리그가 1인칭에 가깝다는 플래그를 세우고 월드 루프가 로컬 아바타를 숨깁니다. 벽에 파묻힌 카메라 대신 좁은 실내에 쓰는 표준적인 대안입니다.

참고 문헌

카메라 제어를 가시성 제약으로 바라보는 틀은 Marc Christie와 Patrick Olivier의 Camera Control in Computer Graphics (Computer Graphics Forum, 2008)에서 왔습니다. 거리 필드 행진은 John C. Hart의 Sphere Tracing: A Geometric Method for the Antialiased Ray Tracing of Implicit Surfaces (The Visual Computer, 1996)입니다. 스프링 암 패턴과 그 프로브 구 충돌은 Epic의 Spring Arm Component, Unity의 Cinemachine Deoccluder와 Third Person Follow에 문서화되어 있습니다. 모션과 댐핑 직관은 Mark Haigh-Hutchinson의 Real-Time Cameras (Morgan Kaufmann, 2009)와 Itay Keren의 Scroll Back: The Theory and Practice of Cameras in Side-Scrollers (GDC 2015)에서 왔습니다. 메시 콜라이더 업그레이드 경로는 Garrett Johnson의 three-mesh-bvh입니다.

30부 중 30부. 이전 글: 29부 - 컨트롤러 하나로 어떤 몸이든 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

처음 오셨나요? 시리즈 가이드를 보세요. spike가 무엇인지 설명하고 모든 파트로 연결해 둡니다.

28부에서는 풀과 오클루전을 다뤘습니다. 28개 파트가 안에 서 있을 수 있는 세계를 만들었습니다. 읽어낼 수 있는 지형, 수영할 수 있는 물, 지평선까지 버텨주는 식생, 당신이 바꾼 것을 기억하는 서버. 이번 파트는 그 모든 것을 가로질러 움직이는 그 무언가에 관한 것이고, 엔진 전체의 결실입니다. 목표는 플레이어 컨트롤러가 아니거든요. 자기가 어떤 몸을 구동하는지, 애니메이션이 어디서 왔는지, 운전대를 잡은 게 사람인지 AI인지 신경 쓰지 않는 컨트롤러입니다. Spike 58은 locomotion에 대해 아무것도 모르는 물리 엔진 위에 플러그인 가능한 동작들을 쌓아 올린 형태로 움직임을 만들고, 그런 다음 한 벌의 같은 엔진으로 서로 다른 세 가지 몸을 굴려 이 아키텍처를 증명합니다. Spike 59는 그 컨트롤러를 단 한 줄도 바꾸지 않고 진짜로 리타게팅한 아바타를 올립니다. Spike 60은 리타게팅이 전혀 필요 없는 다른 애니메이션 팩을 올리고, 클립 선택 로직을 끄집어내 실제로 테스트할 수 있는 무언가로 만듭니다.

걷기에 대해 아무것도 모르는 물리 엔진

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

이 설계 규칙은 가혹하고, 그게 핵심 전부입니다. capsule 엔진은 어떤 locomotion도 소유하지 않습니다. 걷기도, 달리기도, 점프도, 마찰도, 최고 속도 상한도 없고, 중력조차 없습니다. kinematic capsule을 지형에 대해 적분하는 것, 그뿐입니다. 모든 locomotion 동작, 즉 걷기, 미끄러지기, 활공, 등반, 수영, 웅크리기, stamina는 엔진에 등록된 자기완결적인 컨트롤러 안에 삽니다. 매 프레임마다 엔진은 모든 컨트롤러를 tick하고, 각각에게 제어권을 원하는지 묻고, 우선순위가 가장 높은 요구자가 velocity를 쓰게 합니다. 걷기에는 특별한 지위가 없습니다. 항상 yes라고 말하는 가장 낮은 우선순위의 컨트롤러일 뿐이라서, 다른 게 아무것도 발동하지 않을 때의 기본값이 됩니다. 컨트롤러는 작은 함수 여섯 개입니다. 활성화되지 않았을 때조차 매 프레임 자기 내부 상태를 갱신하는 tick, 그 프레임을 요구하는 순수한 wantsControl 술어, 승자만 실행하며 velocity를 쓰고 원한다면 자기 몫의 중력을 적용하는 applyForces, 그리고 선택적인 onEnter, onExit, stateName입니다. 수영은 applyForces에서 ownsCollision: true를 반환해 지형 처리를 넘겨받는데, 그렇지 않으면 부력 스프링이 엔진의 발 스냅과 싸우기 때문입니다.

locomotion이 아닌 것들조차 여전히 그 계약을 통해 새어 나오고, 그게 다음 아이디어를 끌어냈습니다. 이 아키텍처가 본전을 뽑게 해주는 부분은 channel입니다. 이전의 단일 channel 설계는 모든 것을 하나의 중재를 거쳐 돌렸는데, 이는 stamina 추적기나 웅크림 자세가 locomotion인 척하고 나서 자기 장부 기록을 돌리려고 wantsControl이 false를 반환하는 꼼수로 제어권을 거절해야 했다는 뜻입니다. 해결책은 컨트롤러를 독립적으로 중재하고 고정된 순서로 적용되는 이름 붙은 channel로 나눕니다. resource 다음 stance 다음 locomotion 순입니다. resource가 먼저 도는 이유는 stamina 감소 같은 그 쓰기를 다른 것들이 읽기 때문입니다. stance가 두 번째로 도는 이유는 웅크림이 capsule 높이를 줄이는 일이, 걷기가 그것을 읽어 최고 속도를 제한하기 전에 자리잡아야 하기 때문입니다. locomotion은 마지막으로 돌고 프레임별 velocity 쓰기를 소유합니다. 그래서 stamina 관찰자와 웅크림 수정자와 활성화된 수영 컨트롤러가 모두 각자 자기 channel 안에서 깔끔하게 공존하고, 어떤 컨트롤러도 자기가 무엇인지에 대해 거짓말할 필요가 없습니다. 데모는 활성 컨트롤러에 따라 색이 바뀌는 헐벗은 capsule로 이 모든 것을 시각화해서, 중재가 일어나는 걸 지켜볼 수 있습니다. 초록색 걷기가 가파른 비탈에서 미끄러지기가 넘겨받으며 주황색으로 바뀌고, 호수에서는 수영이 이기며 청록색으로, 공중에서 활공을 톡 누르면 크림색으로 바뀝니다.

엔진 하나, 몸 셋

"locomotion을 소유하지 않는다"의 진짜 시험은 플레이어가 아닙니다. 같은 엔진이, 손대지 않은 채로, 플레이어가 전혀 아닌 무언가를 구동할 수 있느냐입니다. createCapsuleEngine은 모듈 수준 상태도, 싱글톤도, 인스턴스별 부작용도 없는 순수한 factory라서, 이 spike는 그것을 세 번 인스턴스화합니다. 플레이어는 전체 컨트롤러 세트를 가진 한 인스턴스입니다. 탈 수 있는 말은 걷기 컨트롤러만 등록하는 두 번째 인스턴스인데, 이게 그 아이디어를 글자 그대로 구현한 것입니다. 한 몸의 움직임 어휘는 당신이 등록한 컨트롤러들 그 자체일 뿐이라서, 말은 평지에서 더 빠르고 등반, 수영, 활공은 물리적으로 못 합니다. 그 컨트롤러들이 애초에 추가되지 않았기 때문입니다. 자율 NPC는 세 번째 인스턴스로, 플레이어와 나란히 매 프레임 tick되고, 자기 입력을 합성하는 wander 컨트롤러가 구동해서 키보드에 손이 없는데도 몸이 스스로 방향을 잡습니다. 엔진은 자기 몸 중 하나가 말이라거나 다른 하나가 AI 구동이라는 걸 결코 알지 못합니다. 모두 컨트롤러 목록만 다른 똑같은 capsule 적분기입니다.

탑승은 의도적으로 엔진 바깥에 사는 한 조각입니다. 플레이어와 말 사이에 제어권을 바꾸는 건 두 엔진을 조율한다는 뜻이고, 컨트롤러는 한 엔진 안에서 돌며 그 경계 너머를 볼 수 없어서, 탑승 로직은 host 수준에 앉습니다. 이번 프레임에 어느 엔진을 스텝할지 결정하고, 다른 하나는 얼리고, 4분의 3초에 걸친 smoothstep으로 라이더를 안장 위로 부드럽게 올리고, 카메라에 어느 몸을 추적할지 알려주는 작은 상태 기계입니다. 엔진 factory는 이 중 무엇도 듣지 못합니다. 그게 아키텍처가 긋고 지키는 선입니다. 한 몸에 속하는 동작은 컨트롤러이고, 몸 사이의 조율은 host의 일이며, 그것들을 분리해 두는 것이 네 번째나 마흔 번째 몸을 추가해도 새로 드는 비용이 전혀 없는 이유입니다.

브라우저 없이 테스트하기

엔진은 어떤 window도, document도, Three.js도 손대지 않기 때문에 전체가 헤드리스로 돌아갑니다. 이 spike는 지형 인터페이스를 mock하고, 스크립트로 짠 입력으로 엔진을 프레임 단위로 구동하고, 결과 상태에 대해 단언하는 Node harness를 함께 출하해서, 플레이 테스트로 잡기에는 비참한 회귀들이 대신 스크립트 안에서 잡힙니다. 점프와 착지 전환, 수영 진입과 이탈 임계값, 표면이 평평해질 때 등반 자동 해제, stamina 소모율 같은 것들입니다. 같은 입력과 timestep 시퀀스를 두 번 먹이고 바이트 단위로 동일한 출력 상태를 확인하는 것이 엔진을 결정적인 것으로 못 박는데, 그건 네트워크 빌드가 결국 기대게 될 속성입니다. harness가 잡은 회귀 하나는 간직할 만합니다. 걸을 수 있는 땅에서 걷기보다 가파른 비탈로 올라서면, 예전에는 미끄러지기 컨트롤러가 작동해 플레이어를 언덕 위로 도로 튕겨 올렸습니다. 해결책은 하강 게이트였습니다. capsule이 실제로 비탈 위로 떨어지고 있을 때만 미끄러지기가 시작되도록 해서, 이제는 가파른 면으로 수평으로 걸어 들어가면 미끄러지지 않고 깔끔하게 막히고, "걸을 수 없는 비탈로 걸어 들어가면 플레이어가 막힌다"를 단언하는 테스트가 그걸 고정해 둡니다.

컨트롤러를 건드리지 않고 진짜 아바타 끼워 넣기

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

Spike 59는 컨트롤러 층이 정말로 몸과 분리되어 있는지에 대한 시험입니다. 색칠된 capsule을 진짜 스킨드 캐릭터로, 즉 Quaternius Universal Animation Library 클립을 리타게팅해 올린 3MIKE FBX rig로 바꾸는데, 컨트롤러는 전혀 바뀌지 않습니다. 이음매는 문자열 하나입니다. 각 컨트롤러는 이미 stateName을 통해 상태 이름을 보고합니다. idle, walk, run, jump, fall, land, slide, glide, swim, swimIdle이고, 아바타 층은 그 이름을 별칭 테이블을 통해 리타게팅한 클립으로 매핑하고 전환할 때 crossfade합니다. 걷기는 접지 더하기 수직 velocity 더하기 수평 속도로부터 자기 하위 상태를 동적으로 고르기 때문에, 단일 걷기 컨트롤러가 idle, walk, run, jump, fall, land를 구동하고, 아바타는 그저 보고된 이름을 따라갑니다. 이 spike는 싱글 플레이어라서, 아바타는 이전 네트워크 spike들의 wire-integer 간접 참조와 다중 캐릭터 추상을 떼어내고 상태 이름을 곧장 클립으로 매핑합니다. 증명은 capsule에서 rig를 가진 사람으로의 시각적 업그레이드 전체가 locomotion 코드를 0줄 건드렸다는 것이고, 그게 바로 플러그인 가능한 컨트롤러가 사주기로 한 것입니다.

리타게팅이 필요 없는 팩, 그리고 테스트할 수 있는 선택기

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

Spike 60은 세 번째 몸, Synty의 POLYGON Base Locomotion 팩을 끼워 넣는데, 로더는 거의 아무것도 아닙니다. 각 클립은 같은 Synty 스켈레톤의 내장 복사본 하나에 더해 베이크된 애니메이션 하나를 실은 독립 FBX로 출하되고, 캐릭터 rig와 모든 클립이 동일한 뼈 이름을 쓰기 때문에 fbx.animations[0]에서 클립을 집어 캐릭터의 mixer에서 바로 재생합니다. 루프 안에 리타게팅 라이브러리가 전혀 없습니다. Three.js는 애니메이션 track의 대상을 객체 정체성이 아니라 뼈 이름으로 해석하기 때문에, 맞는 rig에 맞춰 제작된 Synty나 Mixamo 스타일의 팩은 그냥 동작합니다. 그게 이전 spike의 UAL 경로와의 의도적인 대비인데, 그 경로는 소스 클립과 대상 rig가 서로 다른 스켈레톤에 맞춰 제작되었기 때문에 무거운 리타게팅이 필요합니다. 같은 컨트롤러, 같은 상태 이름 이음매, 그 뒤에 완전히 다른 두 애니메이션 파이프라인.

Spike 60의 다른 절반은 클립 선택 로직을 테스트 가능하게 만드는 것입니다. 어느 클립을 재생할지 고르는 일은 판단 임계값으로 가득하고, 그 로직은 아바타 층 안 FBXLoader와 DOM 옆에 묻혀 있어서 거기서는 굴려볼 수가 없었습니다. 이 spike는 선택기를 Three.js도 window도 손대지 않는 순수 함수로 추출합니다. 평범한 플레이어 레코드(velocity, 수평 속도, 향하는 방향, 접지, 지면 법선, 충격 velocity)와 clip-action 대역을 받아 클립 별칭 문자열을 반환합니다. 그러면 임계값들이 이름 붙고 단언된 상수로 살 수 있습니다. 점프는 걷기 컨트롤러의 실제 스프린트 임계값에 맞춘 속도 버킷으로 걷기, 달리기, 스프린트 변형으로 나뉘고, 착지는 충격 velocity로 부드러움, 중간, 강함으로 나뉘고, 오르막과 내리막 클립 변형은 약 7도 아래에 평평한 클립 데드존을 둔 비탈 투영 내적으로 발동하고, idle에서 locomotion으로 가는 다리는 항상 앞쪽으로 해석되어 멈춰 서서 출발할 때 클립을 거꾸로 재생하는 일이 결코 없으며, 멈춤 다리는 최소 루프 내 시간으로 게이트됩니다. Synty의 발 위상 멈춤 클립이 제작된 감속을 약 1초 담고 있어서, 플레이어가 거의 떼지 않은 걸음에 붙이면 우스워 보이기 때문입니다. 작은 상태 디바운서가 fall 상태를 몇 프레임 미뤄서, 이음매를 가로지를 때 한 프레임 지면 접촉이 끊겨도 애니메이션이 깜빡이지 않습니다. 이 모든 것을 렌더링 껍데기에서 빼낸다는 건 규칙을 GPU 없이 유닛 테스트할 수 있다는 뜻이고, spike 58에서 엔진 자체가 받은 것과 같은 헤드리스 규율이며, 이것이 짐작으로 조율하는 locomotion 감각과 못 박을 수 있는 locomotion 감각 사이의 차이입니다.

이 챕터에서 언급한 기술

locomotion 없는 물리 엔진. capsule 엔진은 kinematic 몸을 지형에 대해 적분하고, 걷기, 달리기, 점프, 마찰, 속도 상한, 중력을 소유하지 않습니다. 모든 동작은 tick, wantsControl, applyForces와 선택적인 onEnter/onExit/stateName을 노출하는 등록된 컨트롤러입니다. 걷기는 가장 낮은 우선순위의 항상 yes 기본값일 뿐이고, 컨트롤러는 ownsCollision: true를 반환해 지형 처리를 넘겨받을 수 있습니다(수영이 그렇게 해서 부력 스프링이 발 스냅과 싸우지 않습니다).

독립적인 중재 channel. 컨트롤러는 따로 중재하고 고정된 순서로 적용되는 이름 붙은 channel(resource, stance, locomotion)에 등록되어서, stamina 같은 관찰자와 웅크림 같은 수정자가 제어를 흉내 냈다가 거절하는 대신 활성 locomotion과 공존합니다. resource 쓰기(stamina)는 stance와 locomotion이 읽고, stance 쓰기(웅크림 capsule 높이)는 locomotion의 속도 상한이 읽고, locomotion은 마지막으로 돌며 velocity 쓰기를 소유합니다.

factory 하나, 몸 여럿. createCapsuleEngine은 싱글톤 없는 순수 factory라서, 같은 엔진이 플레이어, 걷기만 하는 탈 수 있는 말, 합성 입력을 먹는 스스로 방향 잡는 NPC를 구동합니다. 한 몸의 움직임 어휘는 정확히 그 등록된 컨트롤러 세트라서, 말은 그 컨트롤러들이 애초에 추가되지 않았기 때문에 등반이나 수영을 못 합니다. 탑승은 컨트롤러가 아니라 host 수준에 사는데, 서로를 가로질러 볼 수 없는 두 엔진을 조율하기 때문입니다. GPU 구동 LOD를 보세요.

헤드리스, 결정적 테스트. 엔진은 어떤 window, document, Three.js도 손대지 않아서, Node harness가 프레임 단위로 그것을 구동하고 점프와 착지, 수영 임계값, 등반 자동 해제, stamina 소모에 대해 단언합니다. 동일한 입력을 두 번 재생하고 동일한 출력을 확인하는 것이 결정성을 증명하고, 회귀 테스트가 가파른 면으로의 수평 걷기가 플레이어를 뒤로 미끄러뜨리는 걸 막는 하강 게이트를 고정합니다.

몸과 무관한 아바타 바인딩과 테스트 가능한 선택기. 컨트롤러는 상태 이름 문자열을 보고하고 시각 층이 그것을 클립으로 매핑해서, capsule을 리타게팅한 3MIKE + UAL 아바타로 바꿔도 locomotion 코드를 0줄 건드립니다. Synty POLYGON 클립은 rig와 뼈 이름을 공유해서 리타게팅 없이 재생되고(Three.js가 track을 뼈 이름으로 바인딩합니다), UAL 경로의 무거운 리타게팅과 다릅니다. 클립 선택기는 점프 속도 버킷, 착지 강도, 비탈 투영 변형, 항상 앞쪽인 idle 다리, 멈춤 다리 최소 시간 가드, fall 상태 디바운서를 위한 이름 붙은 상수와 함께 순수 함수로 추출되어서, locomotion 감각이 짐작이 아니라 유닛 테스트 가능합니다.

29부 / 30부. 이전: 28부 - 지평선까지의 풀, 그리고 스스로를 숨기는 땅 다음: 30부 - 벽을 존중하는 카메라 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

27부에서는 섬을 만들고 타일처럼 보이지 않는 지면을 입혔습니다. 이번 부분은 지형을 텅 빈 곳이 아니라 사람이 사는 곳처럼 느끼게 만드는 두 가지를 다룹니다. Spike 56은 풀, 즉 텍스처가 입혀진 비탈을 걸어 다니고 싶은 장소로 바꿔주는 표면 디테일이고, 여기서의 문제는 한 들판이 흩어진 줄무늬가 아니라 들판으로 읽히게 만드는 것입니다. Spike 57은 더 많이 그리는 것의 반대입니다. 언덕이 이미 가리고 있는 것을 그리지 않는 일이고, 흥미로운 결과는 그것을 검사하는 빠른 방법이 알고 보니 올바른 방법이기도 했다는 점입니다.

색종이 조각이 아니라 들판으로 읽히는 풀

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

핵심 결정은 기하학적입니다. 가늘고 끝이 좁아지는 풀잎 하나는 대부분의 카메라 각도에서 서브 픽셀이라, 50만 개의 납작한 풀잎은 들판이 아니라 듬성듬성한 초록색 색종이 조각으로 읽힙니다. 해결책은 교차 quad 덩어리입니다. 끝이 좁아지는 quad 세 개를 로컬 업 축을 기준으로 서로 60도씩 회전시켜 두면, 어느 시점 방향에서 보든 적어도 하나의 quad가 카메라에 거의 수직으로 서고 각 instance가 실제 화면 면적으로 대략 풀잎 세 개 너비를 덮습니다. 이것이 초록색 줄무늬가 보이느냐 풀이 보이느냐의 차이입니다.

WebGPU 컴퓨트 커널이 init 시점에 모든 덩어리를 한 번씩 배치합니다. instance 인덱스를 다섯 개의 비상관 랜덤 스트림으로 해싱하고, 패치 안에서 XZ 위치를 고르고, CPU 지면 mesh가 쓰는 것과 같은 FBM에서 지면 높이를 샘플링하고(부호를 보존하는 mod를 쓴 TSL 포팅이라 값이 정확히 일치하고, 풀잎이 위에 떠 있지 않고 표면에 앉습니다), 중심 차분 법선을 취하고, 덩어리별 너비, 높이, 색조를 굴려서 정합니다. 렌더 쪽은 instance 행렬을 완전히 우회해 곧장 클립 공간에 쓰는 TSL 정점 그래프입니다. 단위 교차 quad의 크기를 조절하고, Rodrigues 공식으로 로컬 업을 지면 법선 위로 회전시키고, 덩어리 위치로 평행 이동합니다. 거리 LOD는 컬링 패스 없이 공짜로 따라옵니다. 정점 그래프가 덩어리의 높이에 $1-\text{smoothstep}(\text{fadeNear},\text{fadeFar},\text{dist})$를 곱하기 때문에, 먼 덩어리는 높이가 0으로 납작하게 무너져 더 이상 fill 비용을 쓰지 않습니다. 바람은 덩어리의 월드 XZ에 시간을 더한 값에 대한 sin과 cos의 두 옥타브로, 수평으로 적용되고 높이 분수로 게이팅되어 밑동은 고정된 채 끝만 움직입니다. 그리고 작은 카메라 인식 기울기가 각 덩어리를 보는 사람 쪽으로 기울여 줘서, 납작한 카드처럼 읽히는 대신 원근감 있게 펼쳐집니다.

색상 레시피는 NedMakesGames의 Breath of the Wild URP 셰이더에서 빌려 왔습니다. 플랫 셰이딩에, 풀잎 색은 높이 분수를 따라 뿌리 톤에서 끝 톤으로 lerp 하고, 그 뿌리 톤과 끝 톤 자체는 덩어리별 색조 값에 따라 두 팔레트 사이에서 lerp 됩니다. 이것이 진짜 BotW 풀밭이 가진 얼룩덜룩한 투톤 룩을 만들어 냅니다. Diffuse는 지면 법선을 태양에 대고 환경광 바닥을 더해 씁니다. 교차 quad의 quad별 법선은 양식화된 룩으로 개별 셰이딩하기에는 너무 노이즈가 많기 때문입니다. 전체 들판은 한 번의 draw이고, 배치와 애니메이션 모두 GPU에서 이뤄집니다.

언덕이 가리고 있는 것을 컬링하는 네 가지 방법

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

Spike 57은 프로덕션 클라이언트가 스트리밍하는 것과 같은 절차적 월드에서 네 가지 컬링 경로를 벤치마킹하는데, 언덕이 실제로 식생을 가리도록 수직으로 1.8배 스케일을 키웠습니다. T0은 거리 전용으로, 출시된 chunk 가시성이 이미 하고 있는 것과 같습니다. T1은 frustum 컬링을 더합니다. 가장 큰 단일 저비용 이득으로, 시야 원뿔 밖의 모든 것을 떨궈냅니다. T2는 지형 인식 지평선 검사를 더합니다. 눈에서 각 instance로 광선을 march 시켜, 경로 어디에서든 높이맵이 광선 위로 솟으면 그 instance를 기각합니다. 그래서 능선 뒤의 나무는 frustum 안에 있더라도 컬링됩니다. T3은 같은 지평선 검사를 유지하되 최대 높이 피라미드로 가속하고, T4는 거리에 frustum에 지평선까지 더한 검사 전체를 TSL 컴퓨트 커널로 포팅합니다. 이 커널은 instance별 가시성 스케일을 쓰고, 식생 머티리얼이 그것을 읽어 가려진 정점을 무너뜨립니다. 두 프레임 동안 보이는 상태를 유지하는 카운터가 단일 프레임 깜빡임을 부드럽게 다듬는데, 이는 카메라가 살짝 움직일 때 샘플 지점이 어떤 texel의 안이나 밖에 아슬아슬하게 떨어질 때 생기는 것입니다. 일부러 짧게 유지하는데, 더 길게 잡으면 알고리즘 버그를 고치는 게 아니라 가려버리기 때문입니다.

피라미드는 이 spike가 제 값을 하는 부분이고, 교훈은 검사를 실제로 화면에 있는 것에 맞추는 일에 관한 것입니다. 렌더링되는 지형은 정점이 고정된 2미터 격자 위에 있는 삼각형 mesh이고, 정점 사이에서 래스터라이저가 선형 보간을 하므로, 어느 사각형 안에서든 실제 렌더링되는 높이는 그 안에 있는 정점들의 최댓값이지 그것들 사이의 연속 노이즈 봉우리가 결코 아닙니다. 만약 오클루전 피라미드가 더 촘촘한 격자에서 노이즈를 샘플링하면, mesh가 절대 표시하지 않는 유령 봉우리를 찾아내 카메라가 빤히 꿰뚫어 볼 수 있는 광선을 막기 시작합니다. 그래서 피라미드의 베이스 texel은 정확히 정점 격자 위에 앉아 각각 자기 네 모서리 정점의 최댓값을 저장하고, 상위 레벨은 교과서적인 2x2 최댓값 리덕션이라, 렌더링되는 mesh에 대해 정확해집니다. 단계별 광선 검사에서는 코드가 일부러 피라미드를 질의하는 대신 양선형 보간으로 mesh를 점 샘플링합니다. 서브 texel AABB 질의는 texel 전체의 최댓값을 반환해 가파른 능선에서 높이를 몇 미터씩 부풀리는데, 그것이 바로 보이는 prop을 가려버릴 과도한 오클루전이기 때문입니다.

놀라운 결과는 무차별 대입 기준점인 T2가 틀린 쪽이라는 것입니다. T2는 연속 노이즈를 직접 점 샘플링하기 때문에 렌더링되지 않는 mesh 정점 사이의 봉우리를 잡아내고, 그래서 약간 과도하게 가려서 플레이어가 실제로 볼 수 있는 식생을 숨깁니다. 피라미드 경로는 더 빠르고(chunk 수준 검사에 대해 $O(\log N)$의 AABB 리덕션 덕분), 동시에 기하학적으로 더 올바릅니다(mesh가 진짜로 표시하는 높이만 반환할 수 있기 때문). 그것이 이 spike의 요점 전부입니다. 가속 구조는 속도를 위해 받아들이는 품질 타협이 아니라, 현실과 일치하는 버전입니다. Chunk 컬링은 chunk마다 5점 검사를 돌리고(꼭대기 네 모서리에 chunk의 최대 높이에서의 중심을 더함) 각 chunk 자신의 풋프린트를 오클루더 집합에서 제외해 chunk가 자기 자신을 가리는 일이 없게 합니다. 권장하는 프로덕션 경로는 T4입니다. instance 메타데이터와 높이 필드를 storage buffer로 밀어 넣고 동일한 루프를 컴퓨트 셰이더에서 indirect draw로 돌리면 됩니다. 어차피 렌더러가 WebGPU로 옮겨가는 중이니까요.

이 장에서 언급한 기술

교차 quad GPU 풀. 덩어리마다 끝이 좁아지는 quad 세 개를 서로 60도씩 회전시키면 어느 각도에서든 거의 수직인 quad 하나가 보장되어, 50만 개의 instance가 서브 픽셀 색종이 조각이 아니라 들판으로 읽힙니다. 컴퓨트 커널이 모든 덩어리를 배치하고(CPU mesh와 같은 부호 보존 mod로 샘플링한 FBM 지면 높이, 중심 차분 법선, 덩어리별 크기와 색조), TSL 정점 그래프가 instance 행렬을 우회해 크기를 조절하고, Rodrigues 회전으로 법선 위에 올리고, 평행 이동하고, 높이 게이팅된 바람을 적용합니다. 거리 LOD는 공짜입니다. 덩어리는 $1-\text{smoothstep}(\text{fadeNear},\text{fadeFar},\text{dist})$에 따라 높이 0으로 무너집니다. 색상은 NedMakesGames의 BotW 레시피를 따라, 색조를 섞은 두 팔레트 위에 뿌리에서 끝으로 가는 그라데이션을 깝니다. GPU 주도 LOD를 보세요.

지형 지평선 오클루전 컬링. 프로덕션 월드에서 벤치마킹한 네 가지 경로: 거리, 거기에 frustum, 거기에 능선 뒤의 instance를 기각하는 높이맵 광선 검사, 거기에 그것을 가속하는 최대 높이 피라미드, 거기에 TSL 컴퓨트 포팅. 피라미드는 mesh가 테셀레이션하는 바로 그 2미터 정점 격자 위에서 샘플링하므로(베이스 texel = 네 모서리 정점의 최댓값, 위로 2x2 최대 리덕션), 래스터라이저가 실제로 표시하는 높이만 반환합니다.

가속되고 올바름, 타협이 아님. 연속 노이즈를 점 샘플링하면(무차별 대입 T2 경로) 절대 렌더링되지 않는 mesh 정점 사이의 봉우리를 찾아내 보이는 식생을 과도하게 가립니다. 정점 격자 피라미드는 더 빠르고($O(\log N)$ AABB 리덕션) 기하학적으로 정확해서, 단계별 광선 검사는 피라미드의 texel별 최댓값을 질의하는 대신 mesh를 양선형 샘플링합니다. 후자는 가파른 능선에서 높이를 몇 미터씩 부풀릴 테니까요. Chunk 컬링은 5점 검사를 쓰고 각 chunk 자신의 풋프린트를 제외해 절대 자기 자신을 가리지 않습니다. 프로덕션 경로는 메타데이터와 높이 필드를 storage buffer로 밀어 넣어 indirect draw로 컴퓨트 셰이더 컬을 돌립니다.

29부 중 28부. 이전: 27부 - 노이즈로 만든 섬, 지면처럼 보이는 지면 다음: 29부 - 컨트롤러 하나로 어떤 몸이든 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

26부는 세계에 물을 올렸습니다. 이번 부분은 그 아래의 땅을 만듭니다. 실제 장소가 만들어지는 과정을 그대로 따라가는 두 단계로요. Spike 54는 지형 그 자체입니다. 손으로 조각한 게 아니라 노이즈에서 키워낸 뒤, 물이 실제로 흘러간 곳이 가질 법한 배수로와 해안선을 가질 때까지 풍화시킨 것이죠. Spike 55는 그 지형 위에 입히는 피부입니다. 거의 모든 절차적 지면을 무너뜨리는 문제, 곧 타일 텍스처가 타일처럼 보인다는 문제를 해결합니다. 둘을 합치면 하나의 질문에 답하게 됩니다. 창작자가 아티스트의 손을 전혀 거치지 않고도 그럴듯한 섬과 땅처럼 읽히는 땅을 얻을 수 있는가, 그리고 답은 올바른 레시피를 베끼면 그렇다 입니다.

노이즈만으로는 얻을 수 없는 해안선

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

높이맵은 Red Blob Games 레시피를 따릅니다. 이건 작은 변환들을 쌓은 것으로, 각각이 원시 노이즈의 특정 결함 하나를 고칩니다. 프랙탈 브라운 운동은 Perlin 노이즈의 여러 옥타브를 더해서 지형이 넓은 언덕과 미세한 디테일을 둘 다 가지게 합니다. 하지만 순수 FBM은 흐물흐물하고 그리드에 정렬된 것처럼 보이기 때문에 샘플 지점을 먼저 도메인 워프합니다. 각 좌표를 다른 노이즈 필드로 옵셋하는 것이죠. $p^{\prime }=p+\text{noise}(p)\cdot s$. 이렇게 하면 능선이 축에 갇히는 대신 유기적인 무언가로 휘어집니다. 그다음 재분배는 고도를 거듭제곱 $e^k$로 올려서 중간 톤을 아래로 밀어냅니다. 그러면 세계는 모든 것이 똑같이 완만한 경사에 놓이는 대신 평평한 계곡과 날카로운 봉우리를 가지게 됩니다. 이것을 무한한 언덕이 아니라 섬으로 만드는 조각은 방사형 감쇠입니다. 중심으로부터의 유클리드 거리를 계산하고, $d=min(1,\sqrt{n_x^2+n_y^2})$, 고도를 $1-d$ 쪽으로 블렌딩하면 지형이 가장자리에서 바다로 떨어집니다. 두 번째 독립 노이즈 필드는 습도맵이 됩니다. 형태에는 아무것도 하지 않지만 나중의 생물군계 단계에 입력으로 들어갑니다.

이렇게 하면 형태가 나오지만, 그건 노이즈 형태입니다. 강도 없고, 물이 깎은 계곡도 없고, 퇴적 부채꼴도 없습니다. 그 위를 흐른 것이 아무것도 없었기 때문이죠. 해결책은 수력 침식으로, Sebastian Lague의 MIT 라이선스 구현에서 이식해 왔습니다. 수천 개의 물방울이 무작위로 생성되어 비탈을 따라 굴러 내려갑니다. 각각 관성을 지녀서 직각으로 꺾지 않고, 빨라지면 퇴적물을 집어 올리고 느려지거나 고이면 내려놓습니다. 미리 계산해 둔 원형 브러시가 각 침식 이벤트를 작은 반경에 펼쳐서 깎인 자국이 1픽셀짜리 긁힘이 아니라 매끄럽게 됩니다. 그리고 증발이 물방울을 수명 동안 은퇴시킵니다. 충분히 많은 물방울을 돌리면 지형은 노이즈가 흉내 낼 수 없는 것을 키워냅니다. 합류하는 배수망, 하류로 갈수록 넓어지는 계곡, 그리고 퇴적물이 가라앉은 평지죠.

GPU 위의 침식, 그리고 자기가 어디 있는지 아는 강

CPU 침식은 정확하지만 느립니다. 그래서 spike는 이것을 WebGPU 컴퓨트 셰이더로도 이식하는데, 흥미로운 부분은 GPU 원자 연산이 무엇을 강제하는가입니다. 높이는 백만 배율의 고정소수점 i32로 저장됩니다. WGSL에는 부동소수점에 대한 atomic add가 없고, 수천 개의 물방울이 같은 셀에 퇴적물을 내려놓고 제거하는 일을 경쟁 상태 없이 병렬로 할 수 있는 유일한 방법이 정수에 대한 atomicAdd와 atomicSub이기 때문입니다. 이 고정소수점 왕복은 셀이 무거운 동시 드래그 아래에서 가끔 살짝 음수가 될 수 있다는 뜻인데, 이건 무해하고 읽어들일 때 클램프됩니다. CPU 버전은 셀마다의 브러시 테이블을 미리 계산하지만 ${1001}^2$ 그리드에서 그 테이블은 약 100MB라서, GPU 이식은 각 물방울의 브러시를 그때그때 다시 계산합니다. 약간의 산술을 많은 메모리와 맞바꾸는 것이죠. 물방울 시작 위치는 여전히 Mulberry32 생성기를 통해 CPU에서 오므로 실행이 결정론적입니다.

두 패스가 더 있어 풍화된 지형을 읽을 수 있는 지도로 바꿉니다. 배수는 Red Blob D8 흐름 누적 방식을 씁니다. 모든 셀에 비 한 단위를 떨어뜨리고, 모든 셀을 고도 내림차순으로 정렬하고, 각 셀의 누적된 물을 그 셀의 단 하나뿐인 가장 낮은 이웃에게 넘깁니다. 그러면 물이 자연스러운 계곡을 따라 쌓이고, 누적량이 임계값을 넘는 셀은 강으로 표시됩니다. 함정은 침식된 높이맵에 구덩이가 있다는 것입니다. 내리막 출구가 없는 국소 함몰지죠. 구덩이로 들어간 물은 그냥 멈춰서 누적을 깨버립니다. 그래서 배수가 돌기 전에 Planchon-Darboux 구덩이 채우기가 각 구덩이를 가장 낮은 이웃보다 살짝 높게 올립니다. $\text{minNeighbour}+ϵ$. 모든 셀이 배수할 곳을 가질 때까지 스무 번 미만의 패스로 반복합니다. 마지막으로 생물군계는 Red Blob 방식으로 배정됩니다. 고도 대 습도의 두 축 룩업이라서 높고 건조한 셀은 바위가 되고 낮고 습한 셀은 늪이 됩니다. 그 위에 경사를 인식하는 오버라이드가 얹힙니다. 가파른 면은 습도와 상관없이 바위로 강제되고, 수면 띠는 해변이 되고, 가장 높은 고도는 눈을 입습니다. 결과는 한눈에 읽히는 섬이고, 두 개의 노이즈 시드에서 끝에서 끝까지 생성됩니다.

멈출 줄 모르고 반복되는 타일

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

지형에는 고작 몇 미터 너비의 텍스처로 수 킬로미터를 덮는 재질이 필요합니다. 그런데 타일을 키워서 땅을 덮는 순간 눈이 그 반복을 딱 붙잡습니다. Spike 55는 같은 지오메트리와 조명 위에서 네 가지 샘플링 모드를 비교하는 A/B 벤치라서, 유일한 변수는 텍스처를 어떻게 읽느냐입니다. 기준선은 plain입니다. 스케일된 UV에서 한 번 샘플링하는 것이죠. 몇 미터마다 명백하게 타일이 보이고, 이길 대상으로서만 존재합니다. 무료 PBR 레이어는 Poly Haven에서 그들의 CDN을 통해 옵니다. diffuse 더하기 패킹된 ARM 맵(앰비언트 오클루전, roughness, metalness) 더하기 GL normal, 전부 CC0이고, 이방성 8과 밉맵으로 로드됩니다.

흥미로운 세 가지는 반복에 대한 서로 다른 공격입니다. hex-linear 모드는 Heitz-Neyret 삼각형 격자입니다. 표면 위에 비스듬한 삼각 격자를 깔면 각 프래그먼트가 하나의 삼각형 안에 놓이고, 그 삼각형의 세 꼭짓점이 각각 무작위로 옵셋된 탭을 가져와 무게중심 가중치로 블렌딩합니다. 그러면 인접한 영역이 텍스처의 서로 다른 부분을 샘플링하고 큰 스케일의 타일링이 녹아 없어집니다. 하지만 세 탭의 순수 선형 블렌드는 삼각형 가장자리에서 색을 평균 내버려서 눈에 보이는 삼각형 무늬를 남깁니다. spike 48이 부딪혔던 바로 그 아티팩트죠. hex-vp 모드는 같은 2018년 논문에서 발표된 해결책입니다. 무게중심 합 이후에 텍스처의 평균 색을 빼고, 제곱 가중치 합의 역제곱근으로 다시 스케일해서 분산을 일정하게 유지한 다음, 평균을 도로 더합니다. 이렇게 하면 블렌드 전체에서 대비가 안정적으로 유지되어 삼각형이 사라집니다. 그래서 이 재질은 로드된 각 텍스처를 1×1로 읽어들여 평균 색을 미리 추정합니다. 네 번째 모드 iq-untiled는 Inigo Quilez의 Texture Repetition 기법 3입니다. 두 개의 옵셋된 탭을 저주파 변화 패턴으로 블렌딩하는데, 세 번이 아니라 두 번만 샘플링하고 애초에 삼각형 구조가 없는, 잘 버티는 저렴한 선택지입니다.

어떤 모드 위에든 선택적인 삼평면 투영을 얹을 수 있습니다. 이것이 같은 재질로 절벽을 늘어남 없이 감쌀 수 있게 해주는 것이죠. UV 하나 대신 셰이더는 세 개의 월드 축 투영을 샘플링합니다. X를 향한 표면은 YZ 평면을 읽고, Y는 ZX를, Z는 XY를 읽고, abs(normalWorld)를 4에서 8 사이의 샤프닝 거듭제곱으로 올려 블렌딩합니다. 그래야 45도 경사가 세 투영을 다 뭉개서 유령처럼 만들지 않습니다. 이 벤치는 절충을 분명하게 보여줍니다. 분산을 보존하는 hex 블렌딩이 품질 승자이고, Quilez의 두 탭이 성능을 의식한 쪽입니다. 둘 다 plain을 충분히 큰 차이로 이기므로, 어떤 창작자도 plain 타일을 출시해서는 안 됩니다.

이 장에서 다룬 기술

레시피를 쌓은 높이맵 생성. Red Blob Games 레시피는 원시 노이즈를 지형으로 조합합니다. 유기적인 능선을 위한 도메인 워프 FBM($p^{\prime }=p+\text{noise}(p)\cdot s$), 평평한 계곡과 날카로운 봉우리를 위한 $e^k$ 재분배, 그리고 가장자리를 바다로 떨어뜨려 섬을 만드는 $1-d$ 쪽으로 블렌딩되는 유클리드 방사형 감쇠. 두 번째 노이즈 필드는 생물군계 배정을 위한 습도맵입니다. 지형 생성을 보세요.

수력 침식, CPU와 GPU. Sebastian Lague의 물방울 모델(관성, 운반 용량, 미리 계산된 원형 퇴적 브러시, 증발)은 노이즈가 흉내 낼 수 없는 실제 배수로를 깎아냅니다. WebGPU 컴퓨트 이식은 높이를 백만 배율의 고정소수점 i32로 저장해서 물방울들이 같은 셀에 병렬로 atomicAdd/atomicSub할 수 있게 하고, ${1001}^2$에서 약 100MB짜리 테이블을 피하려고 각 물방울의 브러시를 그때그때 다시 계산하며, 결정론적인 Mulberry32 생성기로 시작 위치를 시드합니다.

구덩이 채우기를 포함한 D8 배수. Red Blob D8 흐름 누적은 셀마다 비 한 단위를 떨어뜨리고, 셀을 고도 내림차순으로 정렬하고, 물을 각 셀의 가장 낮은 이웃에게 넘기며, 임계값을 넘으면 강으로 표시합니다. Planchon-Darboux 구덩이 채우기가 먼저 모든 국소 함몰지를 $\text{minNeighbour}+ϵ$로 올려서(스무 번 미만의 패스로 반복) 물이 절대 갇히지 않고 누적이 연결된 채로 유지됩니다. 고도 대 습도의 두 축 룩업이 생물군계를 배정하고, 경사 오버라이드가 절벽에 바위를, 수면에 해변을, 봉우리에 눈을 강제합니다.

텍스처 타일링을 깨는 네 가지 방법. 동일한 지오메트리와 조명 위에서: plain(한 탭, 명백하게 타일이 보임), hex-linear(Heitz-Neyret 삼각형 격자, 선형 블렌드가 삼각형 무늬를 남김), hex-vp(평균을 빼고, 제곱 가중치의 역제곱근으로 다시 스케일하고, 평균을 도로 더하는 EGSR 2018 §3.3 분산 보존 해결책, 텍스처마다 1×1 평균 읽어들이기가 필요), 그리고 iq-untiled(Inigo Quilez 두 탭 기법 3). 삼평면 투영은 세 개의 월드 축 평면을 abs(normalWorld)의 4-8 거듭제곱으로 블렌딩해서 샘플링하므로 절벽이 늘어나지 않습니다. 분산 보존이 품질에서 이기고, 두 탭이 비용에서 이깁니다. 지형 재질을 보세요.

29부 중 27부. 이전: 26부 - 물을 만드는 세 가지 방법 다음: 28부 - 지평선까지 펼쳐진 풀, 그리고 자신을 숨기는 땅 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

25부에서는 아바타에게 옷을 입혔습니다. 이번 편은 물 이야기이고, spike가 세 개인 이유는 물이 바로 그런 표면이기 때문입니다. 값싼 지름길과 올바른 답이 스크린샷에서는 똑같아 보이지만 움직이면 완전히 달라지는 표면이죠. Spike 51은 스크린 스페이스 방식으로 반사를 만듭니다. 솔깃한 방식이지만 곧장 내장된 한계에 부딪칩니다. Spike 52는 출시되는 모든 게임이 실제로 쓰는 방법으로 바꿉니다. Spike 53은 완성된 물 라이브러리를 그대로 넣어서 "완성"이 지금 우리 위치에서 얼마나 떨어져 있는지 봅니다. 셋 다 굴절 레이어 하나를 공유하므로, 앞의 두 개 사이에서 변하는 유일한 변수는 반사를 어떻게 계산하느냐입니다.

이미 가지고 있는 화면에서 반사를 얻는다

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

스크린 스페이스 반사는 이미 렌더링한 프레임을 재활용합니다. 각 물 픽셀마다 시선 광선을 표면에서 반사시키고, 그 반사된 광선을 깊이 버퍼를 따라 진행시키다가, 광선이 기록된 어떤 표면 뒤로 지나가는 순간 물이 무엇을 반사하는지 찾아낸 것이고, 그 값을 컬러 버퍼에서 바로 샘플링합니다. 이 포팅은 three.js의 SSRNode를 한 줄 한 줄 그대로 따라갔고, 그쪽은 다시 lettier의 SSR 입문서를 따릅니다. 진행 과정은 스크린 스페이스에서의 DDA 워크입니다. 광선의 시작점과 끝점을 픽셀 좌표로 투영하고, 더 긴 축을 따라 한 픽셀당 한 번씩 탭하며 나아갑니다. 각 스텝에서 반사 광선의 깊이는 원근 보정 보간이 필요합니다. $\frac{1}{1/z_0+s(1/z_1-1/z_0)}$ 형태인데, view-Z를 선형 보간하는 것은 그냥 틀린 방법이고 엉뚱한 위치에 히트를 만들어내기 때문입니다.

두 가지가 이 방식을 슬라이드쇼가 아니라 쓸 만하게 만듭니다. 거친 진행은 64스텝으로 제한합니다. 천 픽셀에 걸쳐 투영되는 긴 광선은 그러지 않으면 프래그먼트마다 수백 번씩 반복하게 되고, 백만 개 프래그먼트짜리 물 평면에 수백 번 반복에 텍스처 샘플 몇 번을 곱하면 그건 30fps짜리 장면이 됩니다. 품질 설정은 반복 횟수가 아니라 그 한도 안에서의 실효 보폭을 조절합니다. 그리고 제한된 거친 진행은 눈에 보이는 계단형 밴딩을 남기므로, 6회 반복의 이진 정제가 마지막 미스와 히트 사이의 구간을 이등분합니다. 이는 64배 서브 스텝 정확도이고, 이웃한 물 프래그먼트들이 같은 거친 히트 위치에 들러붙는 것을 멈출 만큼 충분합니다. 마지막으로 점과 직선 사이의 거리 검사가, 후보가 단지 같은 깊이에 있을 뿐인지 아니면 정말로 반사 광선 위에 있는지를 확인합니다. 두께 허용치는 해당 깊이에서 한 픽셀의 view 공간 폭에 맞춰 자동으로 스케일링되어 가까이서는 더 빡빡하고 멀리서는 더 느슨해집니다.

이 spike의 솔직한 부분은 그 자신의 주석에 적혀 있습니다. SSR은 메인 카메라가 한 번도 샘플링하지 않은 것을 반사할 수 없습니다. 나무의 아랫면, 화면 밖의 무엇이든, 가려진 무엇이든, 그 어느 것도 버퍼에 존재하지 않으므로 반사에 나타날 수 없습니다. 그것이 바로 진행 품질을 아무리 높여도 고칠 수 없는 "잘못된 쪽 정보 손실"이고, 다음 spike가 존재하는 이유가 바로 이것입니다.

거짓말할 수 없는 거울

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

평면 반사는 물 평면을 기준으로 거울처럼 뒤집은 카메라에서 장면을 한 번 더 오프스크린 타깃에 렌더링하고, 물 셰이더가 그 타깃을 샘플링합니다. 이것이 정석적인 패턴이고, UE5 Water, three.js 자체의 WaterMesh, ABZÛ, Sea of Thieves가 모두 쓰는 방식입니다. 장면의 모든 픽셀을 그릴 재료로 가지고 있기 때문인데, SSR이 절대 볼 수 없는 지오메트리까지 포함합니다. TSL에서는 거의 김빠질 만큼 간단합니다. reflector()가 거울 헬퍼 카메라와 그 렌더 타깃을 할당하고, 그 타깃을 메시에 추가하면 매 프레임 갱신되며, 그 색을 샘플링하면 됩니다. 나중에 파도가 들어오면, 리플렉터의 UV 노드에 왜곡 오프셋을 더해서 반사가 일렁이게 됩니다. 이건 정확히 WaterMesh가 쓰는 그 라인입니다.

기록해 둘 만한 버그는 거울이 아니라 안전망에 있었습니다. 이전 버전은 리플렉터의 출력을 절차적 하늘과 폴백으로 블렌딩했는데, 반사 색의 크기에 따라 가중치를 줬습니다. 거의 0에 가까운 반사는 타깃에 아무것도 없다는 뜻이라는 이론에서였죠. 그런데 어두운 나무 그늘도 크기가 작아서, 클램프가 풀 강도에 도달하지 못했고 진짜로 어두운 그 픽셀들이 밝은 하늘과 섞여버렸습니다. 사용자가 잡아낸 증상은 정확했습니다. 디버그 모드에서 원본 거울 타깃은 완벽하게 어두운 나무를 보여주는데 합성된 렌더는 반사가 바래 있었고, 진단은 셰이더가 "어두운 색을 사라지게 한다"는 것이었습니다. 해결책은 삭제였습니다. 리플렉터 타깃은 첫 프레임 이후로 믿을 수 있으므로 폴백 자체가 필요 없습니다. 두 spike는 그 아래에 같은 굴절을 공유합니다. 표면 뒤의 장면을 샘플링하고, 각 픽셀이 수면 아래로 얼마나 깊이 있는지 재구성하고, 채널별 Beer-Lambert 소광을 적용해서 빨강은 몇 미터 안에 죽고 파랑은 살아남게 하며, 먼 평면 배경이 안개에 덮이지 않도록 하늘 마스크를 둡니다. Schlick Fresnel은 물을 똑바로 내려다볼 때의 굴절과 가로질러 볼 때의 반사를 섞어줍니다.

완성된 모습은 이렇다

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

Spike 53은 직접 만들 것인가 사 올 것인가를 확인하는 작업입니다. threejs-water-pro를 출시된 그대로 넣습니다. 열대 프리셋, 기본 바다 클립맵, 카메라 추적, Rayleigh 하늘까지 함께 넣고, 라이브러리 자체 데모가 쓰는 것과 같은 섬 glTF를 로드합니다. 핵심은 직접 짠 평면 물 셰이더와 완전한 바다 시스템 사이의 격차를 보는 것인데, 그 격차는 큽니다. 이쪽에는 배 선체 아래 여러 지점에서 파도 높이를 샘플링해 배가 그냥 위아래로 까딱이는 게 아니라 피칭과 롤링을 하게 하는 부력 시스템, 항적 생성기, 해안선과 표면 거품, 그리고 배 선체 안쪽의 물 렌더링을 억제해서 잔물결이 갑판을 통해 새어 나오지 않게 하는 마스크 패스가 있습니다.

통합 과정에서, README를 읽어서가 아니라 라이브러리를 실제로 써봐야만 배우게 되는 종류의 디테일들이 드러났습니다. 거품 텍스처는 프리셋에서 파일명으로 참조되지만 그것을 로드하는 일은 사용하는 쪽의 몫이고, 그게 없으면 해안선이 부서지는 파도가 아니라 딱딱한 수면 경계선으로 보입니다. 섬은 그 수중 지오메트리가 바다 바닥 아래로 떨어지도록 배치되어, 라이브러리의 바닥 메시가 모델의 바깥 테두리를 가려서 평면 가장자리가 보이지 않게 합니다. 이것이 라이브러리가 의도한 패턴입니다. 3D 모델을 가져오되 지형을 합성하지는 말라는 거죠. 그리고 안티앨리어싱은 렌더러에서 일부러 끄고 대신 후처리 FXAA 패스를 씁니다. MSAA는 깊이 인식 대기 안개가 돌기 전에 가장자리 프래그먼트를 배경과 블렌딩해서, 지오메트리와 안개가 만나는 곳마다 얇고 어두운 테두리를 남기기 때문입니다. 안개 전이 아니라 후에 앨리어싱을 해소하면 그 테두리가 사라집니다. 이것이 줄여주는 리스크는 결정 그 자체입니다. 프로덕션 바다는 크고 특화된 시스템이고, 그게 필요한 경우라면 항적과 부력과 거품을 처음부터 다시 만드는 것보다 유지보수되는 라이브러리를 도입하는 편이 낫습니다. 한편 spike 52의 평면 거울 셰이더는 크리에이터가 자기 월드에 두는 더 작은 내륙 물에는 여전히 옳은 답으로 남습니다.

이 장에서 언급한 기술

스크린 스페이스 반사 물. 반사된 시선 광선이 DDA로 스크린 스페이스에서 깊이 버퍼를 진행하며, 원근 보정 1/z 보간, 프래그먼트당 비용을 묶는 강한 스텝 제한, 그리고 제한된 진행이 남기는 밴딩을 없애는 이진 정제 패스를 씁니다. 깊이 스케일 두께를 적용한 점과 직선 확인이 거짓 히트를 걸러냅니다. 이 방식의 절대적 한계는 메인 카메라가 이미 샘플링한 지오메트리만 반사할 수 있다는 것이어서, 화면 밖이나 잘못된 쪽 표면은 절대 나타나지 않습니다. 지형 머티리얼을 참고하세요.

평면 거울 반사. 물 평면을 기준으로 거울처럼 뒤집은 헬퍼 카메라가 장면을 오프스크린 타깃에 렌더링하고 물 셰이더가 그것을 샘플링해서, SSR이 볼 수 없는 지오메트리까지 포함한 픽셀 단위로 완벽한 반사를 줍니다. 이것이 UE5 Water와 three.js WaterMesh가 쓰는 패턴이고, 파도 왜곡은 리플렉터의 UV 노드에 오프셋으로 적용됩니다. 크기 가중 하늘 폴백은 어두운 반사 픽셀을 잘못 지워버렸고, 리플렉터 타깃은 첫 프레임 이후 믿을 수 있으므로 폴백을 제거하는 것이 해결책이었습니다.

Beer-Lambert 깊이 틴트 굴절. 두 셰이더 모두 표면 뒤의 장면을 샘플링하고, 각 배경 픽셀의 수면 아래 깊이를 재구성하고, 채널별 지수 소광(빨강은 미터 단위로 죽고 파랑은 살아남음)을 적용해 물 안개 색 쪽으로 합성하며, 먼 평면이 안개에 덮이지 않도록 하늘 마스크를 둡니다. Schlick Fresnel은 수직 입사에서의 굴절과 스치는 각도에서의 반사를 섞습니다.

프로덕션 물 라이브러리 도입. threejs-water-pro는 바다 클립맵, Rayleigh 하늘, 배의 피칭과 롤링을 위한 다중 지점 부력, 항적, 거품, 그리고 선체 마스크 패스를 함께 제공합니다. 사용하는 쪽의 디테일이 중요합니다. 거품 텍스처는 명시적으로 로드해야 하고, 섬의 수중 지오메트리는 바다 바닥 아래로 떨어뜨려 바닥이 그 가장자리를 가리게 해야 하며, 지오메트리 가장자리의 어두운 안개 테두리를 피하려면 안티앨리어싱은 MSAA가 아니라 후처리 FXAA 패스로 돌려야 합니다.

29부 중 26부. 이전: 25부 - 골격 하나, 모든 의상 다음: 27부 - 노이즈에서 만든 섬, 땅처럼 보이는 땅 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

숲은 GPU에게 렌더링을 시킬 수 있는 것 중 가장 까다로운 대상 중 하나다. 잎 하나하나가 alpha 마스크로 잘라낸 텍스처 쿼드다. 그런 쿼드 수십 개가 시선 방향마다 겹겹이 쌓인다. 래스터라이저는 어떤 프래그먼트가 alpha 테스트를 통과할지 미리 알 방법이 없어서, 불투명 장면을 살려주는 표준 early-Z 최적화가 여기서는 대부분 꺼진다. 그 결과 하나의 화면 픽셀이 프레임이 정리되기 전까지 잎 셰이더를 10번이나 15번씩 돌리게 된다. 이게 바로 식생 overdraw다. 지난 10년 동안 출시된 어느 게임에서든 오픈월드 프레임에서 가장 비싼 단일 요소다.

좋은 소식은 이미 해결된 문제라는 점이다. 누군가 트릭 하나로 고쳤다는 뜻이 아니라, 일곱여덟 가지 기법을 묶으면 빽빽한 숲에서의 실효 overdraw를 8-15배에서 1-2배까지 끌어내릴 수 있다는 뜻이다. 모든 최신 엔진은 이 스택의 어떤 버전이든 탑재하고 있다. 그 안에 무엇이 들었는지, 각 조각이 왜 존재하는지, 그리고 각각의 정석 참고 자료를 정리한다.

1. 식생 overdraw가 왜 이렇게 괴로운가

전형적인 불투명 장면에서 GPU는 early depth rejection을 한다. 픽셀 셰이더가 돌기도 전에, 하드웨어가 기존 깊이 버퍼를 확인해서 이미 뒤에 가려진 프래그먼트를 건너뛴다. 이건 사실상 공짜고, 밀집된 지오메트리의 비용을 정상 범위로 유지해주는 핵심이다.

alpha-tested 식생은 이걸 깨뜨린다. 프래그먼트 셰이더가 실제로 돌면서 alpha 텍스처를 평가하고, 마스크로 가려진 픽셀에 discard(또는 clip)를 호출해야 한다. 하드웨어는 셰이더가 돌기 전까지 프래그먼트가 버려질지 알 수 없으므로, 대부분의 GPU에서는 셰이더 어딘가에 discard가 들어가 있으면 그 draw call의 early-Z가 통째로 꺼진다. 타일 기반 GPU(모바일, M 시리즈, 일부 콘솔)에서는 프레임 전체의 Hi-Z와 깊이 압축까지 꺼질 수 있다. 픽셀을 덮는 삼각형마다 픽셀 셰이더가 한 번씩 돌고, 그중 대부분은 discard로 끝난다.

잎 쿼드 10개를 하나의 화면 픽셀 앞에 쌓으면 잎 셰이더가 10번 돈다. 거기에 400만 픽셀을 곱하면 비용이 잔혹해진다. Marco Salvi의 글 To Early-Z, or Not To Early-Z는 이게 하드웨어 수준에서 왜 벌어지는지를 가장 부드럽게 설명한다. 한 번도 생각해본 적 없다면 여기서 시작하는 게 맞다.

2. 마스크 지오메트리를 위한 깊이 prepass

가장 큰 단일 이득이자 모든 최신 엔진이 탑재한 기법은 식생 드로를 두 패스로 쪼개는 것이다. 첫 번째 패스는 깊이만 쓴다. alpha 테스트를 하고, 마스크로 가려진 픽셀을 버리고, 그 외에는 아무것도 쓰지 않는 최소한의 셰이더를 쓴다. 두 번째 패스는 깊이 테스트를 "equal"로 설정하고 깊이 쓰기는 끈 채 완전한 머티리얼을 렌더링한다. 이제 뒤에 잎 쿼드가 몇 장 쌓여 있든, 보이는 픽셀 하나하나는 완전한 BRDF를 정확히 한 번만 셰이딩한다.

같은 삼각형을 두 번 건드리니 두 배 일하는 것처럼 들리지만, prepass 셰이더가 워낙 싸서(텍스처 샘플 한 번, discard 한 번, 깊이 쓰기 한 번) 메인 패스에서 아끼는 비용이 그 추가 부담을 훌쩍 넘는다. 빽빽한 숲에서 메인 패스는 픽셀당 잎 셰이더를 10-15번 돌리던 것에서 정확히 한 번 돌리는 것으로 바뀐다.

Unreal, Frostbite, Decima, 그리고 최신 Rage 및 Dunia 브랜치가 모두 이렇게 한다. 이런 엔진들에서 마스크 머티리얼이 여전히 반투명 머티리얼보다 싼 핵심 이유이기도 하다.

깊이 있게 읽을 자료:

• Pettineo, To Early-Z, or Not To Early-Z (discard가 Hi-Z 및 early-Z와 어떻게 상호작용하는지에 대한 정석 설명).
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, Frostbite의 깊이 prepass와 prepass 구동 컬링 아키텍처).
• Sanders, Between Tech and Art: The Vegetation of Horizon Zero Dawn (GDC 2018, Decima의 두 패스 식생 렌더링).
• Persson, A couple of notes about Z (depth-equal 테스트와 prepass 경제학을 가장 명료하게 설명한 글 중 하나).

3. 공격적인 LOD와 팔면체 임포스터

두 번째로 큰 이득은 그릴 필요가 없을 때 잎을 아예 그리지 않는 것이다. 식생 에셋은 여러 LOD 단계를 함께 담고 출시된다. 가장 가까운 단계는 잎 카드가 각각 들어 있는 완전한 메시다. 중간 거리에서는 잎들이 더 빽빽한 복합 카드로 합쳐진다(잎 30장 한 뭉치가 같은 실루엣을 가진 텍스처 카드 1장이 된다). 어떤 거리 임계값을 넘으면 나무 전체가 임포스터가 된다. 여러 각도에서 사전 렌더링한 나무의 뷰로 텍스처를 입힌 작은 지오메트리 조각이다.

최신 임포스터 포맷은 팔면체 임포스터다. 8개 면으로 된 지오메트리 조각에, 팔면체 매핑으로 구면 위 점들에서 캡처한 뷰들의 아틀라스를 텍스처로 입힌 것이다. 런타임에 셰이더는 카메라 방향에 따라 가장 가까운 사전 렌더링 뷰 두세 개를 고르고 그 사이를 블렌딩한다. 결과는 어느 각도에서 봐도 3D처럼 보이는, 삼각형 몇 개짜리 대역이다. 제대로 된 셰이딩, 노멀 맵, 심지어 바람 애니메이션까지 가질 수 있다. Ryan Brucks의 구현은 처음엔 커뮤니티 플러그인이었다가 이제 Unreal의 일부가 됐고, 이 분야의 참고 구현이다. Microsoft Flight Simulator의 수십억 그루 숲은 카메라 근처를 빼면 본질적으로 어디든 팔면체 임포스터다.

더 큰 구조적 이득은 임포스터가 먼 거리에서 불투명하거나 거의 불투명하다는 점이다. 잎 30장짜리 복합 카드는 쿼드 30장이 아니라 마스크 쿼드 1장이다. 나무 전체 임포스터는 수천 개가 아니라 몇 개의 면이다. 원거리 overdraw가 거의 0으로 줄어든다.

깊이 있게 읽을 자료:

• Brucks, Octahedral Impostors (수학과 UE 구현이 함께 있는 정석 참고 자료).
• Halen, Octahedral Impostors in Unreal Engine (UE에 통합된 워크플로).
• Häggström, Real-Time Rendering of Vegetation (LOD 체인, 임포스터, 그 배후의 수학을 다루는 깔끔한 논문).
• Crytek, SpeedTree integration in CryEngine 3 (GPU Gems 3, 나무 LOD 체인 입문으로는 여전히 최고).

4. 클러스터 및 GPU 구동 컬링

깊이 prepass가 있어도 prepass 자체에는 비용이 있다. 보이는(또는 잠재적으로 보이는) 나무마다 모든 삼각형을 여전히 건드려야 한다. 최신 엔진은 GPU 구동 클러스터 컬링으로 그 비용을 더 낮춘다. 래스터라이저가 보기도 전에 삼각형 무리 전체를 버린다.

파이프라인은 이렇게 생겼다. 모든 메시는 미리 삼각형 64개나 128개 단위의 클러스터로 쪼개지고, 각 클러스터는 꽉 맞는 경계 상자와 노멀 콘을 갖는다. 렌더링 시점에 compute 셰이더가 인스턴스 목록을 훑으며 각 인스턴스에 프러스텀 테스트를 하고, 보이는 인스턴스마다 모든 클러스터에 프러스텀 테스트를 한 다음, 살아남은 클러스터마다 직전 프레임의 깊이 피라미드에 대해 Hi-Z 오클루전 테스트를 한다. 언덕 뒤에 숨었거나 다른 나무 앞에 가려진 나무 가지 전체가 정점 셰이더가 돌기도 전에 컬링된다. 출력은 "이 클러스터들을 그려라"라는 인자들의 압축된 목록이고, 이게 단 한 번의 DrawIndirect 호출로 그대로 들어간다.

나무 1만 그루의 숲이 몇 초가 아니라 몇 밀리초 안에 렌더링되는 이유가 이것이다. Ubisoft의 어쌔신 크리드 유니티 발표가 이 파이프라인을 양산 형태로 처음 소개했고(삼각형 20-40% 컬링, 그림자 삼각형 30-80% 컬링, 화면상 인스턴스 수가 이전 세대 대비 10배), Wihlidal의 Frostbite 발표가 더 멀리 밀어붙였다. UE5 Nanite는 이 궤적의 눈에 보이는 종착점이다. 클러스터 컬링을 픽셀 단위까지 밀어붙인다.

깊이 있게 읽을 자료:

• Haar와 Aaltonen, GPU-Driven Rendering Pipelines (SIGGRAPH 2015, 어쌔신 크리드 유니티의 기초가 된 발표).
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, Frostbite의 GPU 구동 prepass).
• Karis, Stubbe, Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021, meshlet 단위의 클러스터 컬링).
• Liktor, Geometry Rendering Pipeline Architecture at Activision (콜 오브 듀티 버전의 클러스터 컬링, 2021).

5. 인스턴스와 클러스터의 앞에서 뒤로 정렬

prepass가 제 역할을 하기 시작하면 순서가 중요해진다. prepass는 깊이를 쓰지만 alpha 테스트를 통과한 프래그먼트에 대해서만 쓴다. 숲의 뒤쪽을 먼저 그리고 앞쪽을 나중에 그리면, 앞쪽 프래그먼트마다 뒤쪽 프래그먼트를 덮어쓰게 되고, prepass 셰이더는 뒤쪽을 위해 여전히 돈다. 앞에서 뒤로 그리면 연속된 draw call마다 더 작은 값으로 깊이 버퍼를 더 많이 채우고, Hi-Z는 셰이더가 돌기 전에 뒤쪽 프래그먼트를 점점 더 많이 걸러낸다.

거의 모든 최신 엔진이 prepass를 발행하기 전에 카메라까지의 거리로 식생 인스턴스를 정렬하는 이유가 이것이다. 정렬은 싸고(GPU에서 radix sort로 인스턴스 수십만 개를 한 번에 처리), prepass 자체를 스스로 가지치기하는 작업으로 바꿔준다. 클러스터 단위 컬링도 같은 이유로 meshlet 단위에서 정렬한다. 깊이 prepass와 앞에서 뒤로 순서는 각각이 좋고 조합하면 훌륭한 그런 한 쌍이다.

깊이 있게 읽을 자료:

• Persson, Depth in-depth (깊이 버퍼 순서, prepass 경제학, Hi-Z 동작에 대한 아키텍처 노트).
• Giesen, A trip through the graphics pipeline (Hi-Z 걸러내기 비율이 그리는 순서에 어떻게 의존하는지에 대한 깊은 기술적 설명).
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, Frostbite의 GPU 측 인스턴스 정렬 포함).

6. 디더링 LOD 전환과 hashed alpha

또 다른 큰 함정은 페이드다. 두 LOD 사이를 전환하거나(또는 카메라가 다가올 때 인스턴스를 페이드 인/아웃하는) 가장 순진한 방법은 alpha 블렌딩이다. 하지만 블렌딩된 지오메트리는 깊이 버퍼에 쓸 수 없어서, 페이드 중인 모든 나무를 느린 반투명 경로로 밀어넣고 prepass를 깨뜨린다. 해법은 지오메트리를 마스크 경로에 그대로 두고 alpha 테스트 안에서 페이드를 하는 것이다.

주요 기법 두 가지:

• 디더링 LOD 전환은 4x4 또는 8x8 Bayer 패턴(또는 화면 공간 블루 노이즈 텍스처)을 샘플링해서 픽셀별 컷오프 보정값으로 쓴다. 50% 블렌드 상태의 나무는 체커보드 형태로 픽셀이 살아남고, 빠진 픽셀은 다음 LOD의 상보적 체커보드가 채운다. TAA가 두세 프레임에 걸쳐 체커를 매끄러운 블렌드로 정리한다. 싸고, 안정적이고, 엔진의 다른 모든 것과 잘 어울린다.
• Hashed alpha testing (Wyman & McGuire, I3D 2017)은 고정된 0.5 alpha 임계값을 픽셀별 [0,1) 해시 임계값으로 바꾼다. 보통은 완전히 사라질 먼 거리 alpha 지오메트리(밉맵된 alpha가 0.5 아래로 떨어지기 때문)가 안정적으로 흩어진 채 살아남는 픽셀들을 유지한다. 여기서도 TAA가 정리를 맡는다.

두 기법 모두 식생을 깊이 prepass가 작동하는 불투명/마스크 경로에 유지하므로, 뭔가를 페이드 인하려고 반투명 렌더링 비용 전체를 치르지 않아도 된다. Alpha to coverage는 같은 아이디어의 MSAA 시대 사촌뻘이다. alpha를 서브픽셀 커버리지 마스크로 바꿔서, 마스크 경로를 떠나지 않고도 부분 투명을 얻는다. 함정은 A2C가 MSAA에서만 진가를 발휘한다는 점인데, 요즘 대부분의 최신 디퍼드 렌더러는 MSAA를 더 이상 쓰지 않는다.

깊이 있게 읽을 자료:

• Wyman과 McGuire, Hashed Alpha Testing (I3D 2017, hashed alpha의 정석 논문).
• Castaño, Computing Alpha Mipmaps (The Witness 블로그, 먼 거리의 나무가 사라지지 않도록 alpha-tested 텍스처를 밉맵하는 올바른 방법).
• Yuksel, Alpha Distribution for Alpha Testing (alpha 밉맵에 대한 더 최근의 개선).
• NVIDIA, Anti-Aliased Alpha Testing (A2C, hashed alpha, 디더링 대안에 대한 개관).

7. 마스크 픽셀의 셰이딩 비용 줄이기

완벽한 prepass와 완벽한 컬링이 있어도, 보이는 식생 픽셀마다 한 번은 셰이딩해야 한다. 엔진은 그 비용도 줄인다:

• 더 싼 BRDF. 식생은 무광이라 완전한 Cook-Torrance 스페큘러 경로가 사실 필요 없다. wrapped-Lambertian 디퓨즈에 한 줄짜리 스페큘러 근사면 충분하다.
• 저주파 노멀 맵. 잎은 이미 어수선하다. 보통 보는 거리에서는 256x256 노멀 맵이 1024x1024와 똑같아 보이고, 대역폭도 아낀다.
• 패럴랙스 없음, 이방성 없음, 클리어코트 없음. 잎에서는 PBR 기능 메뉴를 다 끈다.
• 완전한 서브서피스 산란 대신 양면 박막 투과. 잎은 뒤에서 빛을 투과시키는데, 역광 내적 하나로 흉내 낼 수 있다.
• 일부 엔진의 절반 해상도 셰이딩. 식생은 1/4 또는 1/2 픽셀 레이트로 셰이딩한 뒤 업스케일한다. TAA의 확률적 노이즈가 리샘플링을 가려준다.
• 마스크 머티리얼에서는 기본적으로 디테일 텍스처와 데칼 생략.

각각은 개별로 보면 작은 이득이다. 조합하면 마스크 식생 셰이더는 동등한 불투명 머티리얼보다 2-3배 빠르게 돌 수 있다.

깊이 있게 읽을 자료:

• Lagarde와 de Rousiers, Moving Frostbite to Physically Based Rendering 3.0, 식생과 투과에 관한 절 (SIGGRAPH 2014, 박막 양면 머티리얼을 위한 정석 PBR 조정).
• Jimenez, Next Generation Character Rendering (wrapped-Lambertian과 역광 투과 수학. 원래는 피부용이지만 잎으로 널리 이식됐다).
• Sanders, Between Tech and Art: The Vegetation of Horizon Zero Dawn (GDC 2018, Decima의 식생 셰이더 단순화).

8. 가시성 버퍼와 마스크 머티리얼을 위한 Nanite

overdraw에 대한 가장 깔끔한 답은 셰이딩을 래스터화에서 완전히 분리하는 것이다. 가시성 버퍼는 지오메트리를 얇은 버퍼(픽셀당 삼각형 ID와 인스턴스 ID만)로 래스터화한 다음, 그 가시성 버퍼를 읽어 픽셀마다 정확히 한 번 셰이딩하는 디퍼드 패스로 완전한 머티리얼을 돌린다. 구조상 셰이딩 단계에는 overdraw가 없다. Burns와 Hunt의 2013년 논문이 이 아이디어를 소개했고, UE5 Nanite는 그 양산 품질 구현이다. UE 5.5부터는 마스크 식생도 포함한다.

Nanite의 묘수는 이걸 클러스터 단위 가상화 지오메트리로 한다는 점이다. 그래서 래스터라이저 자체가 서브픽셀 삼각형에 대해 소프트웨어 경로로 돌면서 overdraw를 유계로 유지한다. Nanite의 마스크 머티리얼은 "programmable raster" 기능이 필요하다. alpha 테스트는 가시성 버퍼 패스 동안 돌지만, 머티리얼 셰이딩은 여전히 디퍼드 리졸브에서 보이는 픽셀마다 한 번씩 일어난다. 그 결과, 한때 마스크 머티리얼에서 느리기로 악명 높던 아주 빽빽한 Nanite 식생이 이제 불투명 머티리얼과 견줄 만하거나 오히려 더 싸졌다. 셰이딩 시점의 overdraw가 0이기 때문이다. 절충점이 하나 있다. 마스크 경로가 programmable-raster 비용을 더하기 때문에, 저폴리 마스크 카드 나무를 유지하기보다 고폴리 불투명 나무 지오메트리를 Nanite로 밀어넣는 게 나을 때가 많다.

깊이 있게 읽을 자료:

• Burns와 Hunt, The Visibility Buffer: A Cache-Friendly Approach to Deferred Shading (JCGT 2013, 원조 논문).
• Karis, Stubbe, Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021, 양산 아키텍처).
• Epic, Nanite GPU Driven Materials (GDC 2024, 마스크 머티리얼과 programmable-raster 파이프라인 포함).
• Notes from "Nanite GPU Driven Materials" (같은 발표를 깔끔하게 정리한 제3자 정리).

9. 식생을 위한 별도의 그림자 표현

alpha-tested 식생의 그림자 맵은 어느 오픈월드 프레임에서든 큰 캐스케이드 다음으로 두 번째로 비싼 그림자 문제다. 캐스케이드마다 자기만의 깊이 prepass가 필요하고, prepass마다 alpha 테스트를 돌리며, 그 비용이 캐스케이드 4개와 광원 프러스텀 수십 개를 거치며 빠르게 쌓인다. 그래서 대부분의 엔진은 식생 색을 렌더링하는 것과 같은 방식으로 식생 그림자를 렌더링하지 않는다.

흔한 대체 방식:

• 메시 거리장 그림자 (UE Lumen, 자체 엔진). 각 메시는 미리 계산된 signed distance field를 갖는다. SDF를 짧게 콘 트레이스하면 alpha-tested 메시를 전혀 건드리지 않고도 부드러운 그림자를 얻는다. 나무에 특히 좋다. SDF가 나뭇잎 하나하나의 디테일은 무시하고 수관 실루엣을 하나의 단단한 덩어리로 포착하기 때문이다.
• 식생용 저해상도 캐스케이드. 식생 그림자는 절반 해상도 슬라이스로 들어가고 엣지 인식 필터링으로 업샘플링된다. 그림자가 이미 부드러워서 눈은 해상도 저하를 알아차리지 못한다.
• MSAA를 곁들인 alpha-to-coverage 그림자 맵. 그림자 경로에 아직 MSAA가 있는 엔진에서는 A2C가 완전한 alpha 테스트 비용 없이 가장자리가 부드러운 식생 그림자를 만든다.
• 줄기와 큰 가지에는 캡슐 그림자, 수관에는 거리장, 완전한 alpha 테스트는 가장 가까운 캐스케이드에서만. 거리에 따라 다른 표현을 쓰고 라이팅 패스에서 블렌딩한다.
• WPO 비활성화 거리. 바람으로 구동되는 World Position Offset이 임계값을 넘으면 꺼져서, 캐싱된 그림자 데이터가 프레임 간에 유효하게 유지된다. UE의 Virtual Shadow Maps가 이걸 크게 활용한다.

깊이 있게 읽을 자료:

• Epic, Distance Field Soft Shadows in Unreal Engine (메시 DF 그림자에 대한 정석 UE 참고 자료).
• Wright, Lumen: Real-Time Global Illumination in Unreal Engine 5 (SIGGRAPH 2022, Lumen의 식생용 메시 SDF 통합).
• Epic, Virtual Shadow Maps (최신 UE5 그림자 아키텍처, 식생 전용 WPO 비활성화 및 캐싱 규칙 포함).
• Persson, Practical Cascaded Shadow Maps (alpha-tested 캐스터에 대한 노트를 담은, 여전히 정석인 CSM 참고 자료).

10. 바람, 애니메이션, 그림자 캐싱

미묘하게 연관된 문제가 하나 있다. 대부분의 식생은 움직인다. 바람으로 구동되는 정점 애니메이션(UE의 World Position Offset, Frostbite와 Decima의 대응 기능)은 식생 지오메트리가 프레임 간에 안정적이지 않다는 뜻이고, 이건 그림자 캐싱과 리프로젝션을 깨뜨린다. 최신 엔진은 두 가지 방식으로 이에 맞선다:

• 거리에서 WPO 제한. 임계값을 넘으면 바람 애니메이션 진폭이 매끄럽게 0으로 간다. 그 정도 멀어지면 어차피 눈으로 흔들림을 볼 수 없고, 그림자 캐시는 유효하게 유지된다.
• 바람을 클러스터 경계에 굽기. 클러스터 경계 상자를 최대 WPO 오프셋만큼 부풀려서, 프레임마다 다시 업로드하지 않고도 컬링이 보수적으로 유지되게 한다.
• 인스턴스별 위상 오프셋. 똑같은 나무들이 인스턴스별 랜덤 시드로 바람 위상을 어긋나게 해서, 나무마다 고유 애니메이션을 치르지 않으면서도 숲이 일사불란하게 흔들리지 않게 한다.

이런 종류의 디테일은 기법 목록에는 안 나오지만, 실전에서 3 ms 숲과 9 ms 숲을 가르는 차이다.

깊이 있게 읽을 자료:

• Sanders, Between Tech and Art: The Vegetation of Horizon Zero Dawn (GDC 2018, Decima의 바람 애니메이션 파이프라인과 그림자 캐싱).
• McAuley, Rendering the World of Far Cry 4 (GDC 2015, 식생을 위한 바람 그리드 샘플링 포함).
• Epic, Foliage and Virtual Shadow Maps (WPO 비활성화 거리와 VSM 캐싱에 대한 UE5 커뮤니티 안내).

11. 합쳐서 따져보는 계산

이 트릭들 중 어느 하나도 만능 해결책은 아니다. 흥미로운 건 이걸 쌓았을 때 무슨 일이 벌어지는가다:

• 빽빽한 숲 장면에서 순진한 마스크 식생 패스는 실효 overdraw가 8-15배로 측정된다. 보이는 픽셀마다 잎 셰이더를 8번에서 15번 돌린다.
• 깊이 prepass를 더하면 메인 패스의 overdraw가 ~1배로 떨어지지만, prepass 자체는 여전히 모든 걸 건드린다.
• 앞에서 뒤로 정렬을 더하면 prepass가 스스로 가지치기를 시작한다.
• 클러스터 단위 GPU 컬링을 더하면 prepass는 보일 가능성이 있는 것만 건드린다.
• LOD 체인과 임포스터를 더하면 30 m 너머에서 보이는 쿼드의 개수가 한 자릿수 차수만큼 떨어진다.
• 가시성 버퍼 / Nanite 경로를 더하면 빽빽하게 겹쳐도 셰이딩 단계가 진정 픽셀당 한 번만 돈다.
• 거리장 그림자를 더하면 그림자 비용이 더 이상 alpha 테스트에 비례해 늘지 않는다.

위에 링크한 발표들에서 반복되는 핵심 결론은 이렇다. 실효 overdraw가 8-15배에서 1-2배로 무너지고, 빽빽한 숲 장면에서 전체 식생 프레임 비용이 4-6배 떨어진다. 최신 오픈월드 게임이 소비자용 하드웨어에서 숲을 60+ fps로 렌더링할 수 있는 이유가 통째로 이것이다.

12. 이것이 브라우저에 갖는 의미

이 스택의 대부분은 WebGPU에 깔끔하게 매핑된다. 우리는 이미 오픈월드 브라우저 엔진에서 GPU 구동 컬링, 간접 디스패치, Hi-Z 오클루전, 앞에서 뒤로 정렬한 prepass를 출시했다. 마스크 지오메트리를 위한 깊이 prepass는 간단하다. WebGPU는 depth-equal 테스트와 프래그먼트 셰이더의 discard를 지원하고, early-Z에 관한 주의사항도 똑같다. 팔면체 임포스터는 기계적으로 이식된다. 수학은 그저 구면에서 팔면체로의 펼침과 아틀라스 인덱싱일 뿐이다.

더 어려운 건 최신 기법들이다. WebGPU의 가시성 버퍼는 32비트 삼각형 ID를 렌더 타깃에 쓰고 풀스크린 compute 패스에서 머티리얼을 리졸브하는 것을 뜻한다. 구성 요소는 다 있지만 조율이 까다롭다. 메시 거리장 그림자는 에셋당 3D 텍스처 하나와 짧은 콘 트레이스를 원하는데, 둘 다 WebGPU의 사정거리 안에 있다. Hashed alpha와 디더링 LOD는 각각 셰이더 함수 하나면 된다.

브라우저 식생이 나아갈 길은 이 스택의 다른 모든 것과 같다. 싸고 견고한 부품(prepass, 정렬된 인스턴스, LOD, 임포스터, hashed alpha)을 먼저 출시하고, 그 위에 무거운 기계장치(가시성 버퍼, 메시 SDF 그림자)를 얹는다. 브라우저 하드웨어 하한선이 마침내 충분히 높아져서, WebGPU 숲이 콘솔 숲처럼 보이고 돌지 못할 구조적 이유는 없다. 그저 엔지니어링상의 이유만 있을 뿐이고, 엔지니어링상의 이유는 우리가 좋아하는 종류다.

스택 전체에 걸친 더 읽을거리

이 모든 걸 하나로 엮은 자료를 원한다면, SIGGRAPH "Advances in Real-Time Rendering in Games" 아카이브(advances.realtimerendering.com)에 2014년까지 거슬러 올라가는 식생과 GPU 구동 렌더링의 정석 발표들이 있다. Adrian Courrèges의 GPU 프로파일링 글들에는 GTA V와 Horizon Zero Dawn의 프레임별 분석이 있어서, 여기서 다룬 모든 패스를 양산 순서대로 보여준다. alpha 테스트 수학 자체로는 Chris Wyman의 연구 페이지에 hashed alpha와 확률적 투명 논문이 참조 셰이더와 함께 있다. 그리고 Real-Time Rendering, 4th edition의 투명, 샘플링, 깊이 처리 장은 여전히 교과서적 출발점이다.

작성: Oleg Sidorkin, Cinevva CTO 겸 공동 창업자

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

24부에서는 세계를 영속적으로 만들고 식생에 바람을 입혔습니다. 이번 부분은 다시 그 안의 사람들 이야기인데, 이번엔 옷장 쪽에서 봅니다. 창작자가 기본 몸을 고르고, 옷을 바꾸고, 헤어스타일을 고르고, 아무 애니메이션이나 재생하는 것을, 전부 무료 에셋 팩 하나만으로, 리깅도 애니메이션 제작도 없이 할 수 있을까요? 커스텀 리그를 만드는 건 디리스크할 대상이 아닙니다. 답할 가치가 있는 질문은 CC0 팩 하나가 짐 전체를 짊어질 수 있느냐입니다.

애초에 서로 맞물리도록 만들어진 팩

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

Quaternius는 의심스러울 만큼 잘 들어맞는 에셋 네 개를 제공합니다. Universal Base Characters는 남성과 여성 몸에 헤어스타일 여덟 가지와 눈썹 세트 두 가지를 더한 것이고, Modular Character Outfits는 몸통, 팔, 다리, 발 부위로 나뉘며 견갑(pauldron)과 후드 같은 액세서리가 딸려 있고, Universal Animation Library 1번과 2번 팩은 도합 262개 클립으로 이동, 전투, 등반, 농사, 낚시, 대기 동작, 사교 동작을 다룹니다. 이들의 glTF를 살펴보니 왜 들어맞는지 드러났습니다. 네 팩의 모든 메시 하나하나가 똑같은 65개 관절의 UE5 스타일 골격에 리깅되어 있고, 관절 이름도 같고, 바인드 포즈도 같으며, root에서 pelvis, spine을 거쳐 head까지, 양쪽이 미러링된 팔에 각 측마다 손가락 관절 열다섯 개, 미러링된 다리까지 동일합니다. 리타기팅이 전혀 필요 없습니다. 이건 Spike 35의 세 골격 리타기팅 문제와 정확히 반대입니다. 거기서는 213개 뼈의 얼굴 리그가 65개 뼈의 Mixamo 리그와 대화해야 했죠. 여기서는 네 팩 모두 의도적으로 애니메이션 라이브러리의 골격 위에서 제작되었고, 결합이 정확합니다.

그래서 이 spike는 애니메이션 파이프라인 작업이 아니라 바인딩 작업이 되었습니다. 베이스 레이어는 몸 glTF를 불러오고, SkeletonUtils.clone으로 씬을 복제해 각 캐릭터가 로더의 캐시된 씬에 뼈 변형을 다시 흘려보내는 대신 새 골격 인스턴스를 받게 하며, 그 65개 뼈 골격을 애니메이션을 떠받치는 아마추어 객체와 함께 표준(canonical) 버전으로 캐싱합니다.

코트를 몸에 다시 바인딩하기

이 모든 걸 동작하게 하는 요령은, 의상의 메시를 그냥 씬에 다시 부모로 붙일 수 없다는 점입니다. 그 메시는 여전히 자기 glTF의 뼈를 참조하고 있고, 그 뼈들은 다른 서브트리에 자리 잡고 있기 때문입니다. 각 모듈식 부위, 농민의 몸이든 레인저의 다리든, 같은 아마추어의 자기 클론을 지닌 자기만의 SkinnedMesh로 도착합니다. 바인딩은 소스 골격의 뼈를 원래 순서대로 훑으면서 각 뼈를 표준 골격에서 이름으로 찾아내고, 그 재바인딩된 뼈들로 새 Skeleton을 만들면서 소스의 bind-inverse 행렬을 재사용한 다음, 소스의 단위 bind 행렬로 SkinnedMesh.bind를 호출합니다. 바인딩 후에는 메시가 소스 씬에서 분리되어 캐릭터 root 바로 아래에 부모로 붙습니다. bind 행렬이 바인드 시점의 월드 변환을 담고 있고 root가 단위 변환에 자리하므로, 메시 자신의 월드 변환은 결과에 전혀 영향을 주지 않으며 스키닝은 전적으로 이제 공유된 뼈를 통해 일어납니다.

머리카락과 눈썹도 슬롯이며, 이들은 잘못된 가정을 바로잡아 줬습니다. 폴더 구조에는 "head 뼈에 리깅됨"이라고 적혀 있었고, 이는 머리카락이 구운 오프셋으로 머리에 부모로 붙은 정적 메시일 거라고 암시했습니다. 그렇지 않았습니다. 모든 머리카락 파일은 65개 관절 전체에 걸쳐 가중치가 분포된 SkinnedMesh이며, 긴 머리의 가중치는 위쪽 spine과 목까지 번져 들어가 캐릭터가 고개를 숙일 때 머리가 드리워집니다. 그래서 머리카락도 다른 의상 부위와 똑같은 이름 기준 재바인딩 경로를 탑니다. 유일한 특수 사례는 의상의 몸통 슬롯입니다. 이게 부착되면 의상이 뚫고 나오지 않도록 베이스 몸 메시가 숨겨지고, 팔, 다리, 발, 액세서리는 그냥 쌓입니다. 팩이 옷이 피부를 드러내는 곳마다 베이스 몸이 비쳐 나오도록 공존하게 제작했기 때문입니다.

262개 애니메이션이 공짜로

골격이 공유되고 나면 애니메이션은 거의 김 빠질 만큼 싱겁습니다. 라이브러리 glb 두 개를 불러오면 그 클립들이 이름 붙은 하나의 목록으로 펼쳐지고, 그 클립 안의 트랙 이름들은 bone.position, bone.quaternion, bone.scale로 정확한 관절 이름을 참조합니다. 캐릭터의 아마추어에 뿌리내린 AnimationMixer가 그 뼈들을 이름으로 찾아 직접 구동하고, 전환 시 크로스페이드합니다. 뷰어의 오른쪽 패널은 262개 클립 전체를 필터링할 수 있는 목록이고 소스 표시 알약(pill)이 달려 있어서, "fish"를 검색하면 두 라이브러리에 걸친 모든 낚시 애니메이션이 떠오릅니다. 부드러운 그림자가 있는 표준 3점 조명, 발밑의 극좌표 그리드, ACES 톤 매핑이 스타일화된 베이스 텍스처를 읽기 좋게 유지하면서도 어두운 바디수트의 그림자를 으스러뜨리지 않습니다.

이것이 제품을 위해 디리스크하는 것은 큽니다. 아바타 커스터마이징 기능은 리깅 작업 제로, 애니메이션 제작 제로로 CC0 팩 위에서 출시할 수 있습니다. 네 팩을 넣고, 옷장 UI를 연결하면, 대략 의상 여섯 가지 곱하기 헤어스타일 여덟 가지 곱하기 성별 두 가지 곱하기 애니메이션 262개만큼의 변형이 박스째로 나옵니다. 65개 관절 골격은 충분히 작아서 GPU 스키닝 비용이 무시할 만하고, Spike 45의 배치 스키닝 작업이 이미 이 정도 규모의 리그에서 아바타 200개 이상을 처리합니다. CC0는 사용 제한이 전혀 없어서 유료 창작자 플랫폼에서 상업적으로 써도 괜찮습니다. 남은 미해결 질문은 사용자가 직접 업로드한 의상인데, 이는 Phase 3 문제로, 업로드 시점에 이 표준 골격으로 리타기팅하면 풀립니다. Spike 35의 런타임 리타기팅을 거꾸로 뒤집은 셈이죠. 에셋 용량은 디스크에서 약 147MB로 원본 2K PNG와 무압축 애니메이션 glb입니다. 프로덕션에서는 KTX2 텍스처 압축과 gltf-transform 한 번을 거치면 대략 30MB로 줄어듭니다.

이 장에서 다룬 기술

팩 전체에 걸친 표준 골격 하나. 네 개의 Quaternius 팩(베이스 몸, 모듈식 의상, 두 개의 애니메이션 라이브러리)은 전부 동일한 65개 관절의 UE5 스타일 골격에 리깅되어 있고 관절 이름과 바인드 포즈가 같아서, 이들을 조합하는 데 리타기팅이 필요 없습니다. SkeletonUtils.clone으로 베이스를 복제하면 로더의 캐시된 씬을 변형하는 대신 각 캐릭터가 새 골격 인스턴스를 받습니다.

이름 기준 골격 재바인딩. 각 모듈식 부위는 자기 아마추어를 참조하는 자기만의 SkinnedMesh를 가지고 옵니다. 재바인딩은 소스 뼈를 순서대로 훑으며 각각을 이름으로 표준 골격에 매핑하고, 소스의 bind-inverse를 재사용해 새 Skeleton을 만들고, 단위 bind 행렬로 SkinnedMesh.bind를 호출한 다음, 메시를 공유 캐릭터 root 아래에 부모로 붙여 스키닝이 전적으로 공유 뼈를 통해 돌아가게 합니다. 의상의 몸통 슬롯은 뚫림(clipping)을 피하려고 베이스 몸을 숨기고, 다른 슬롯은 그냥 쌓입니다.

스키닝 슬롯으로서의 머리카락. 머리카락은 head 뼈에 붙은 정적 부착물이 아니라 65개 관절 전체에 걸쳐 가중치가 분포된 SkinnedMesh이고, 긴 머리는 위쪽 spine과 목에 가중치가 들어가 고개를 숙일 때 드리워집니다. 의상 부위와 똑같은 재바인딩 경로를 탑니다.

이름 키 기반 애니메이션 리타기팅이 공짜로. Animation Library 클립은 관절을 정확한 이름으로 참조하므로, 공유 아마추어에 뿌리내린 AnimationMixer가 클립별 리타기팅 없이 크로스페이드로 262개 클립 전부를 직접 구동합니다. CC0 라이선스가 상업적 사용을 커버하고, 적은 관절 수 덕분에 GPU 스키닝이 충분히 저렴해서 Spike 45의 배치 스키닝 경로를 재사용할 수 있습니다. GPU 주도 LOD를 보세요.

29부 중 25부. 이전: 24부 - 세계를 저장하기, 그리고 눈에 보이는 바람 다음: 26부 - 모든 스케일에서 버티는 물 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

23부에서는 사람들을 월드 안에 넣고 목소리를 주었습니다. 이번 부분은 월드가 사람들이 자신에게 한 일을 기억하게 만들고, 아무도 건드리지 않을 때에도 살아 있는 느낌을 주는 이야기입니다. Spike 47은 영속화입니다. 창작자가 지형을 조각하고 소품을 배치하면, 그 편집이 다시 로드해도 살아남고, 다른 모든 peer로 동기화되고, 두 사람이 동시에 편집할 때 깔끔하게 중재됩니다. Spike 49는 바람입니다. 양식화된 자연 에셋 팩의 식생 셰이더를 이식해서 나무, 덤불, 풀이 아티스트가 의도한 대로 움직이게 했는데, 이건 수학보다는 셰이더 컴파일러와의 싸움에 더 가까워졌습니다.

기억하는 월드

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

설정은 공유 창작 세션입니다. 플레이어가 월드를 걸어 다니며 클릭으로 소품을 배치하고, 우클릭으로 제거하고, 브러시를 드래그해 지면을 조각합니다. 높이맵을 올리고 내리거나, 한 chunk를 marching cubes로 승격시키는 SDF 지형을 통해 부피 있는 동굴을 파냅니다. 이들이 하는 모든 것은 Cloudflare WorldChunkDO에 영속화됩니다. 자체 SQLite 저장소로 뒷받침되는, 서버 권위형 Durable Object입니다. 클라이언트는 상태를 직접 쓰지 않습니다. 클라이언트는 의도를 보내고, DO가 중재하고 결과를 브로드캐스트하며, DO가 유일한 진실의 원천이기 때문에 새로 들어온 사람은 스냅샷을 받아 다른 모든 사람이 보는 것과 정확히 같은 월드에 안착합니다.

두 가지 영속화 세부 사항이 제 몫을 해냈습니다. 지형은 들어올 때 다시 재생하는 이벤트 로그로 저장되지 않습니다. chunk별 바이너리 blob으로 저장되는데, 이 blob이 진실의 원천이고 스트로크가 끝날 때 업로드되므로, 들어온 사람은 수천 번의 브러시 샘플을 다시 돌리는 대신 커밋된 바이트를 직접 로드합니다. 그리고 그 blob은 큰 한 행이 아니라 chunk당 저장 키 하나로 살아 있습니다. 단일 SDF chunk가 168 KB이고 DO에는 행당 2 MB 제한이 있기 때문입니다. chunk 인덱스가 어떤 키가 존재하는지 추적하므로 DO는 깨어날 때 맵 전체를 다시 수화할 수 있습니다. 신원은 클라이언트에서 두 가지 저장소로 처리됩니다. 플레이어 id는 sessionStorage에 살아서 두 탭이 한 peer가 DO의 플레이어 맵에서 자기 자신을 덮어쓰는 게 아니라 서로 다른 두 peer가 되고, 표시 이름은 localStorage에 살아서 한 탭에서 이름을 바꾸면 모든 탭에 걸쳐 적용됩니다.

동시 편집을 수렴시키기

멀티플레이어 창작에서 정말로 어려운 부분은 두 사람이 같은 순간에 겹치는 지면을 편집할 때 무슨 일이 벌어지느냐입니다. 이 spike는 편집을 그 대수로 나눕니다. 덧셈 연산, 즉 높이맵에서의 올리기와 내리기, SDF에서의 더하기와 빼기는 가환입니다. 어떤 순서로 적용해도 같은 결과에 도달하므로, 이들은 낙관적-스탬프 경로를 탑니다. 각 클라이언트가 로컬에서 적용하고 스탬프를 보내면 DO가 조율 없이 그것을 모두에게 브로드캐스트합니다. 순서가 정말로 상관없으니 조율할 것이 없습니다.

순서에 의존하는 연산, 즉 스무딩과 평탄화가 흥미로운 경우였습니다. 첫 설계는 이들에게 영역 잠금을 주었습니다. 클라이언트가 포인터를 누를 때 잠금을 요청하면 DO가 허가하거나 거부하고, 클라이언트는 누르고 있는 동안 샘플을 버퍼링하며, 포인터를 뗄 때 DO가 스트로크 전체를 원자적으로 적용합니다. 작동하긴 하지만, 자체 잠금 TTL과 허가/거부 왕복을 가진 별개의 프로토콜입니다. 이를 대체한 더 깔끔한 답은 미리 계산된 delta입니다. 발신자가 스무딩이나 평탄화 브러시를 로컬에서 돌린 뒤 그 결과인 셀별 delta 목록을 보내면, 각 peer는 아무것도 다시 유도하지 않고 그 delta를 자기 셀에 더하기만 하면 됩니다. 이는 결과를 원천에서 얼려 버림으로써 순서 의존 연산을 가환 연산으로 바꿉니다. 그래서 편집 시스템 전체가 동일한 수렴 결과를 가진 하나의 균일한 가환 프로토콜 위에서, 잠금 없이 완전히 돌아갑니다. 소품 잠금은 다른 이유로 살아남았습니다. 레코드별 잠금이 소유자만 삭제 가능하던 방식을 대체해서, 누가 잠그지 않은 한 어떤 peer든 어떤 소품이든 삭제할 수 있고, 잠근 사람만 그것을 풀 수 있습니다. 실행 취소와 재실행은 클라이언트가 소품을 배치하기 전에 그 id를 직접 이름 짓게 함으로써 작동합니다. 그래서 서버 응답 이전에 id를 알고 자기 동작을 결정론적으로 되돌릴 수 있습니다. Hibernating WebSocket이 줄곧 유휴 방을 무료로 유지하는데, 이전 부분에서 avatar 릴레이를 저렴하게 만든 바로 그 성질입니다.

충실하게 이식한 바람, 그리고 시작된 싸움

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

Spike 49는 Quaternius의 Stylized Nature MegaKit을 가져와 그 바람을 우리 스택으로 이식합니다. 이 팩은 소스 Godot 셰이더 네 개를 함께 제공하는데, 올바른 선택은 재발명이 아니라 충실한 번역이었습니다. Bark는 빈 정점 함수를 가지므로 줄기는 강체입니다. 앞선 절차적 마스크 시도가 줄기를 흔들리게 만들고 있었는데, 해결책은 그냥 bark에 바람을 아예 적용하지 않는 것이었습니다. Leaves는 삼각 펄스 해시에서 정점별 무질서한 흔들림을 얻고, 높이로 마스킹되어 수관은 움직이고 밑동은 심긴 채로 있습니다. Base foliage는 월드 공간에서 노이즈로 변조된 sin/cos 흔들림을 얻습니다. Grass는 base foliage에 wind-line 흔들림을 더한 것으로, 거듭제곱 곡선을 통해 스크롤하는 노이즈 텍스처를 샘플링해서 텍스처의 밝은 띠만 기여하게 합니다. 이것이 초원을 가로질러 이동하는 눈에 보이는 잔물결을 만들어 냅니다. 디스패치는 팩 자체의 머티리얼 명명 규칙을 따르므로, Leaves_Birch라는 머티리얼은 leaves 경로로, Grass_Common은 grass 경로로 라우팅되며 추측할 필요가 없습니다.

이식에서 나온 놀라움은 잎 색이 텍스처에 없다는 점입니다. Quaternius는 잎의 외형을 전적으로 수직 그라디언트와 Fresnel 림으로 만듭니다. 알베도는 수관 아래쪽의 추가 색에서 위쪽의 잎 색으로 가는 혼합이며 높이로 키잉되고, 여기에 $(1-\mathbf{N}\cdot \mathbf{V}{)}^3$ Fresnel 항으로 스케일된 발광으로 더해진 표면하 산란 색조가 붙습니다. 평범한 텍스처 pass가 밋밋해 보였던 이유가 이것입니다. 색은 칠해진 맵이 아니라 그라디언트와 림에서 옵니다. 이식은 원시 로컬 Y 대신 베이크된 heightFactor 정점 속성을 읽으며, 로드 시점에 월드 공간 Y로부터 잎 그룹마다 정규화합니다. 그래서 FBX 임포트가 각 mesh의 로컬 축을 어떻게 회전시켰든 그라디언트와 바람 마스크가 모두 올바르게 동작합니다. Godot 색 상수는 sRGB로 태그되어 셰이더가 보기 전에 선형으로 변환되므로, 이식도 같은 변환을 합니다. 밝은 sRGB 수치를 선형인 양 그냥 먹여서 식생을 바래게 만드는 대신에요.

프레임률을 먹어 치운 재컴파일

이것이 완전한 바람 머티리얼을 .bak 파일에 따로 빼 두고 먼저 FBX 기준선으로 출시된 이유는, 장면을 약 1 fps로 떨어뜨린 프레임마다 일어나는 재컴파일 버그 때문입니다. 커스텀 TSL을 FBX로 로드된 머티리얼 위에 얹으면 Three.js가 프레임마다 셰이더 프로그램을 다시 빌드하도록 촉발했고, needsUpdate가 사실상 켜진 채로 막혀 있었습니다. 진단 규율은 각 식생 머티리얼을 커스텀 노드가 없는 평범한 텍스처 pass로 되돌려 놓고 재컴파일 루프가 계속되는지 보는 것이었습니다. 멈추면 커스텀 그래프가 범인이고, 계속되면 원인은 상류의 FBX 머티리얼 설정이나 Three.js 자체에 있었습니다. 진짜 셰이더를 되돌아오게 한 수정은 머티리얼별 차이인 잎 색, SSS 색, 강도, 블렌드를 전부 uniform으로 바인딩해서, 컴파일러가 고유한 색 조합마다 새 셰이더를 내뱉어 컴파일 큐를 들쑤시는 대신 모든 잎 에셋이 컴파일된 프로그램 하나를 공유하게 한 것입니다.

기록해 둘 만한 조각이 두 개 더 있습니다. 풀은 소스 파일마다 InstancedMesh 하나로 렌더링되고, sin 위상이 월드 위치를 키로 삼기 때문에 그 바람은 월드 공간에서 계산됩니다. 하지만 변위는 인스턴스 행렬이 돌기 전에 로컬 공간에서 적용해야 하는데, WGSL에는 호출할 inverse()가 없습니다. 평행이동, Y 회전, 균일 스케일로 이루어진 인스턴스 행렬의 경우 상단 3×3의 역은 그저 그것의 전치를 스케일 제곱으로 나눈 것입니다. 그래서 셰이더는 월드 변위에 전치된 모델 행렬을 곱하고 행렬 첫 열 길이의 제곱으로 나누어, 제곱근 없이 스케일을 복원합니다. 정점 변환이 행렬을 다시 적용한 뒤, 운동은 각 풀 다발의 회전이나 스케일과 무관하게 정확히 만든 대로 월드 공간에 안착합니다. 그리고 각 풀 다발은 정점별 GPU 절두체 컬링을 돌립니다. 인스턴스 중심을 클립 공간으로 투영하고, 여유를 두고도 절두체 밖에 떨어지면 모든 정점을 로컬 원점으로 붕괴시켜 각 삼각형의 세 정점이 일치하게 합니다. 그러면 래스터라이저가 퇴화 삼각형을 버리고, 화면 밖 풀에 대해서는 어떤 프래그먼트, 알파 테스트, 그림자 작업도 일어나지 않습니다. 이것은 Three.js가 이미 하는 거친 chunk별 바운딩 구 컬링 위에 쌓이며, 불리언이 아니라 부동소수점 step으로 만들어져 위치 혼합에 곧장 곱해집니다.

이 장에서 언급된 기술

서버 권위형 월드 영속화. WorldChunkDO Durable Object가 소품 배치와 지형 편집을 중재하고, chunk별 바이너리 blob을 진실의 원천으로 영속화하며(그래서 들어온 사람은 이벤트 로그를 재생하는 대신 커밋된 바이트를 로드합니다), DO의 행당 2 MB 제한 아래로 유지하기 위해 chunk당 저장 키 하나로 저장합니다. 플레이어 id는 sessionStorage에 살아서 탭이 서로 다른 peer가 되고, 표시 이름은 localStorage에 살아서 이름 변경이 탭 전체에 적용됩니다.

가환 편집 수렴. 덧셈 지형 연산(올리기/내리기, SDF 더하기/빼기)은 가환이며 조율 없이 낙관적-스탬프 경로를 탑니다. 순서 의존 연산(스무딩, 평탄화)은 영역 잠금을 얻는 대신 미리 계산된 셀별 delta를 보냄으로써 가환으로 만들어지므로, 시스템 전체가 잠금 없이 하나의 균일한 프로토콜 아래 수렴합니다. 레코드별 소품 잠금이 소유자만 삭제 가능하던 방식을 대체하고, 클라이언트가 이름 지은 객체 id가 서버 응답이 도착하기 전에 결정론적인 실행 취소/재실행을 가능하게 합니다. GPU 구동 LOD를 보세요.

Godot에서 TSL로의 충실한 셰이더 이식. Quaternius의 소스 바람 셰이더 네 개를 한 줄씩 번역합니다. 강체 bark, 높이로 마스킹된 잎 흔들림, 월드 공간 식생 흔들림, 그리고 스크롤하는 wind-line 흔들림을 가진 풀이며, 팩의 머티리얼 명명 규칙으로 디스패치됩니다. 잎 색은 텍스처가 아니라 높이 그라디언트에 Fresnel 구동 SSS 림을 더한 데서 오고, sRGB 제작 상수는 선형으로 변환되어 외형이 참조 렌더와 일치합니다.

프레임마다 일어나는 셰이더 재컴파일 피하기. 커스텀 TSL을 FBX 머티리얼 위에 얹으면 needsUpdate가 고정되어 프레임마다 프로그램을 다시 빌드하고, 약 1 fps로 붕괴할 수 있습니다. 머티리얼별 차이를 전부 uniform으로 바인딩하면 고유한 매개변수 집합마다 새 셰이더를 내뱉는 대신 모든 변형이 컴파일된 프로그램 하나를 공유합니다. 평범한 텍스처 진단 pass가 커스텀 그래프가 원인인지 상류 설정이 원인인지 격리해 줍니다.

인스턴스화된 식생의 월드 공간 바람. WGSL에 inverse()가 없기 때문에, 풀 바람은 월드 공간에서 계산되어 손으로 유도한 역(스케일 제곱으로 나눈 전치)으로 로컬로 변환됩니다. 정점별 GPU 절두체 컬링이 화면 밖 풀 다발을 퇴화 삼각형으로 붕괴시켜 어떤 프래그먼트나 그림자 작업도 돌지 않게 하며, Three.js의 chunk별 바운딩 구 컬링 위에 쌓입니다.

29부 중 24부. 이전: 23부 - 쉰 명의 avatar와 방 안의 목소리 다음: 25부 - 하나의 스켈레톤, 모든 의상 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

22부는 세계 위에 하늘을 덮었습니다. 이번 부분은 그 안에 사람을 넣습니다. 3인칭 오픈 월드는 어느 순간에든 50명이 넘는 캐릭터가 보이길 원하고, 바로 옆에 서 있는 사람들의 목소리도 들리길 원합니다. Spike 45는 렌더링 쪽입니다. 그 많은 애니메이션 아바타를 메인 스레드를 녹이지 않고 GPU에 올리는 일이죠. Spike 46은 오디오 쪽입니다. 위치에 따라 패닝되고 감쇠하는 P2P 음성을, 기술 데모가 아니라 평범한 화상 통화처럼 들리도록 튜닝했습니다.

댄서 50명에게 draw call 하나

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

기본 Three.js 경로는 캐릭터마다 자기 SkinnedMesh, 자기 AnimationMixer, 자기 본 행렬 업로드, 자기 draw call을 줍니다. 로컬 Mac에서 아바타 50개일 때 그건 GPU가 일을 하나라도 하기 전에 프레임당 약 13ms의 순수 JavaScript 오버헤드였습니다. 멀티플레이어 트랙 전체의 리스크 해소 질문은, 하나의 배치 스키닝 아키텍처가 이걸 통제하고 캐릭터 수에 따라 선형으로 확장될 수 있느냐였습니다.

답은 애니메이션을 어디서 계산하는가와 어디서 그리는가를 나누는 것입니다. 세 개의 캐릭터 클래스가 하나의 FBX 템플릿을 공유합니다. 로컬 플레이어는 평범한 Avatar로, 자기 mixer를 가진 완전한 스켈레톤 클론이며 표준 Three.js 경로를 따릅니다. 어차피 하나뿐이니까요. 모든 원격 peer는 VirtualSkeleton입니다. 마찬가지로 자기 mixer를 가지고 같은 클립을 돌리는 완전한 클론이지만, 모든 SkinnedMesh 노드는 클론 직후에 곧바로 벗겨내서 본만 남습니다. 그것은 절대 씬에 들어가지 않습니다. 매 프레임, mixer가 업데이트되고 행렬이 자리를 잡은 뒤에, 100개 본 전부의 (bone.matrixWorld × boneInverse)를 공유 Float32Array의 한 슬롯에 채워 넣습니다. 그러면 BatchSkinnedRenderer가 지오메트리 조각마다 하나의 InstancedMesh를 소유하고, 모두 maxInstances × numBones × mat4 크기의 단일 StorageBufferAttribute에서 본 행렬을 읽습니다. 즉 60 × 100 × 64 = 384 KB입니다. 커스텀 positionNode와 normalNode를 가진 MeshStandardNodeMaterial이 정점마다 네 개의 본 영향을 그 storage buffer에서 곧장 읽습니다. 결과는 군중 전체가 안에 몇 명이 있든 지오메트리 조각마다 storage 업로드 한 번과 draw call 한 번뿐입니다. 스키닝은 정점 셰이더 안에 살고, 아바타당 JavaScript 비용은 mixer를 돌리고 행렬 100개를 복사하는 수준으로 떨어집니다.

이걸 측정하는 HUD도 다시 만들어야 했습니다. 옛 버전은 전체 프레임 GPU 시간이 3ms를 넘으면 "예산 초과"라고 표시했지만, 프레임에는 항상 shadow map, 지면, 로컬 플레이어의 완전한 skinned mesh가 들어가고, 이들이 합쳐 실제 하드웨어에서 합성 peer가 몇 개든 상관없이 3~5ms를 돌립니다. 해결책은 스스로 보정하는 예산입니다. 배치 아바타가 없는 동안에는 빠른 EMA를 통해 실시간 GPU 시간을 기준선으로 잡고, 그 기준선을 동결한 다음 합성체가 나타나면 아바타가 추가될 때마다 0.06ms씩 예산을 선형으로 키웁니다. 모든 머신에서 유휴 상태일 때 PASS로 읽히고, 군중이 늘면 비례해서 조여집니다.

버그는 볼 수 없는 얼굴이었다

Chrome에서 첫 실행은 지면에 은색 그림자만 보이고 아바타는 하나도 없이, WGSL 파싱 오류를 냈습니다. cannot index type 'f32'였고, 스칼라로 선언된 uniform인데 object.nodeUniform2[i]로 첨자 접근을 시도하는 줄에서 났습니다. 이 이야기의 정직한 부분은, 첫 수정이 틀렸는데도 어쨌든 작동했다는 겁니다. 추측은 InstancedMesh의 인스턴스 행렬 경로가 그 나쁜 코드를 생성한다는 것이었고, StorageInstancedBufferAttribute로 바꿔 끼우니 Chrome에서 오류가 사라졌습니다. 하지만 그건 새 경로가 다른 셰이더 코드를 내보냈기 때문에 사라진 것이지, 원인을 다뤘기 때문이 아니었습니다. 가장 위험한 종류의 수정이죠.

진짜 범인은 morph target이었습니다. 3MIKE.fbx에는 blend-shape 표정이 딸려 오고, 클론된 지오메트리는 morphAttributes를 상속하며, Three.js의 MorphNode.setup()은 morphTargetInfluences를 스칼라 float로 선언한 다음 합성된 루프 안에서 그것을 .element(i) 하려 합니다. 이게 바로 컴파일러가 거부한 그 스칼라 첨자입니다. 수정은 한 줄로, morph를 쓰지 않는 지오메트리에서 geometry.morphAttributes = {}를 비워서 Three.js가 MorphNode를 아예 주입하지 않게 합니다. 그 우연한 Chrome 수정은 한동안 남아 있다가 되갚아 줬습니다. Safari에서 storage-instanced 경로가 Vertex buffer is not big enough를 256번이나 냈는데, Safari의 WebGPU 백엔드가 그걸 깔끔하게 변환하지 못하기 때문이었습니다. 되돌린 건 옳은 결정이었고, 생성된 인스턴스 경로가 아니라 코어 WebGPU인 평범한 본 행렬 storage buffer는 어디서나 잘 작동합니다. 새겨둘 만한 교훈은 이겁니다. 어떤 수정이 한 브라우저에서 작동하는데 그 메커니즘을 설명할 수 없다면, 당신은 증상에 반창고를 붙인 것이니 실제로 생성된 WGSL을 읽으세요. spike 후반에 추가한 getCompilationInfo() 심은 Three.js의 두루뭉술한 "module is not valid"를 진짜 Tint 오류로 바꿔 줘서, 그 값을 여러 번 톡톡히 했습니다.

그 옆에는 관련된 프레임워크 회피 트릭이 하나 있습니다. Three.js는 표준 skinIndex와 skinWeight 속성 이름을 감지하면, 커스텀 positionNode가 이미 스키닝을 하는 InstancedMesh에서도 자기 SkinningNode를 주입하려 듭니다. 그 속성들을 boneIndex와 boneWeight로 이름 바꾸면 프레임워크 눈에서 숨겨지고, 커스텀 TSL이 새 이름으로 그것들을 읽습니다.

말과 말 사이에 너를 잊는 릴레이

첫 버전은 BroadcastChannel로 peer를 동기화했습니다. 실제 와이어 포맷과 박자를 가진, 같은 브라우저 안의 대역이었고, 프로토콜 주석은 실제 전송으로 교체하는 게 한 줄이면 된다고 약속했습니다. 그 약속을 현금으로 바꾸는 건 AvatarRoomDO, 즉 36바이트 바이너리 프레임을 디코드조차 하지 않는 74줄짜리 Cloudflare Durable Object를 뜻했습니다. 그것은 각 메시지를 방 안의 다른 모든 peer에게 그대로 전달합니다. 발신자의 id가 프레임에 박혀 있고 각 수신자가 자기 echo를 클라이언트 쪽에서 걸러내기 때문입니다. 이 릴레이는 신원에 대한 인식이 전혀 없습니다. Hibernating WebSocket은 유휴 방을 공짜로 만듭니다. DO는 메시지 사이에 메모리에서 빠져나가고, 런타임은 다음 패킷에서 태그된 소켓을 복원합니다. peer당 초당 10개 이벤트면 그건 peer-시간당 36,000번의 DO 요청, 약 0.5센트이고, Cloudflare에서 egress가 공짜이며 동등한 AWS WebSocket 형태보다 대략 6~10배 저렴합니다.

이 교체는 간직할 만한 상태 기계 버그를 드러냈습니다. 한 원격 플레이어가 멈춘 뒤에도 계속 걸었습니다. 애니메이션 요청은 마지막으로 큐에 들어간 이름이 아니라 this._state, 즉 지금 재생 중인 클립을 기준으로 가드했습니다. 그래서 같은 tick에 두 네트워크 메시지가 도착해 먼저 walk 다음 idle이 오면, idle이 아직 전진하지 않은 상태와 비교되어 조용히 버려졌습니다. peer는 영원히 걷기에 갇혔는데, 미래의 idle 패킷이 변하지 않은 것으로 상류에서 중복 제거되었기 때문입니다. 수정은 대기 중인 이름을 항상 덮어쓰고, 진짜 같은 상태 요청에 대해서는 전환 헬퍼가 단락하도록 두는 것입니다. 헬퍼는 이미 그렇게 하고 있었죠. 이 부류의 버그는 일반적입니다. 잘못된 참조 값에 대한 중복 제거 검사는 정작 중요한 입력을 조용히 삼킵니다.

Safari는 가드 두 개를 더 필요로 했습니다. Chrome보다 WebSocket을 빨리 여는 탓에, 첫 인바운드 peer 메시지가 배치 렌더러 구성이 끝나기 전에 도착해 null을 역참조할 수 있었습니다. 렌더러가 없는 동안 메시지를 버리는 건 안전한데, peer가 100ms마다 다시 브로드캐스트하기 때문입니다. 그리고 'gpu' in navigator는 true를 반환하는데 requestAdapter()는 null을 반환해서, Three.js가 조용히 WebGL2로 폴백했고, 거기서는 storage-buffer 스키닝 체인에 유효한 변환이 없어 오류를 쏟아냈습니다. 진짜 adapter가 있는지 확인하고 백엔드가 실제로 WebGPU인지 단언하면, 망가진 렌더링을 명확한 로딩 화면 메시지로 바꿔 줍니다. WGSL 방언 격차마저 있었습니다. Three.js는 현대적인 두 인자 @interpolate(flat, either)를 내보내는데 WebKit의 컴파일러는 아직 출시하지 않았습니다. createShaderModule로 들어가는 길에 셰이더 소스를 다시 써서 두 번째 인자를 떨어뜨려 패치했고, 이건 공짜입니다. flat 보간은 어차피 모든 정점에서 같은 값을 나르니까요.

방과 함께 패닝되는 목소리

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

Spike 46은 근접 음성입니다. HRTF 공간 음향을 쓰는 P2P WebRTC로, 조용하거나 적당히 시끄러운 방에서 Google Meet와 Microsoft Teams 품질을 맞추는 것으로 명시적으로 범위를 좁혔습니다. VoiceRoomDO가 시그널링을 JSON 릴레이로 처리합니다. 새 peer마다 명단을 보내고, 입장과 퇴장을 알리고, 소켓 태그로 SDP와 ICE를 특정 peer 하나에게 라우팅하고, 공간 패너를 구동하는 위치 업데이트를 브로드캐스트합니다. 모든 메시지에 발신자 id를 찍어서 peer들이 서로를 사칭하지 못하게 하고, 오디오 자체는 절대 DO를 거치지 않습니다. 원격 peer마다 RTCPeerConnection 하나이며, 사전순으로 더 작은 peer id가 항상 offer를 보내서 완전한 perfect-negotiation 구현 없이도 양쪽이 누가 시작할지 합의합니다.

받는 쪽에서는 각 peer의 오디오가 HRTF에 역거리 롤오프로 설정된 PannerNode를 통과하고, AudioListener는 로컬 플레이어의 위치와 방향에서 매 프레임 forwardX = sin(facing), forwardZ = cos(facing)로 업데이트되는데, 이는 씬의 atan2(wx, wz) 방향 규약과 맞습니다. Chrome 특유의 버릇 하나가 한 시간을 잡아먹었습니다. Web Audio만 소비하는 MediaStream은 때때로 패킷을 끌어오지 않으므로, 각 스트림을 숨겨진 음소거 <audio> 요소에도 붙여서 디코더가 스케줄링하도록 강제합니다. 품질 쪽에서는 브라우저가 기본적으로 약 32 kbps 모노 Opus를 쓰므로, 이 spike는 모든 offer와 answer의 fmtp 줄을 손봐서 in-band FEC를 켜고 DTX를 끈 채 128 kbps로 올린 다음, 높은 최대 비트레이트로 setParameters를 호출해 인코더가 SDP가 광고한 값을 실제로 쓰도록 보장합니다. FEC는 비트레이트 향상 다음으로 두 번째로 큰 들리는 이득으로, 재협상 없이 패킷 손실에서 복구합니다.

깨끗한 오디오로 가는 삭제의 길

출시된 오디오 체인은 내가 시작했던 것보다 훨씬 작고, 그걸 줄인 것이 진짜 교훈이었습니다. 첫 버전에는 하이패스 필터, 키보드 소음을 잡으려고 튜닝한 클릭 리미터, 컴프레서, 노이즈 게이트, 그리고 wet-dry 크로스페이드가 있었고, 앞쪽엔 슬라이더가 열두 개도 넘는 떠다니는 패널이 붙어 있었습니다. 사용자가 들리는 키보드 클릭을 신고했을 때, 본능은 클릭 리미터를 더 세게 조이고 dry 믹스를 낮추는 것, 즉 반창고 더미였습니다. 구조적인 답은, 일단 체인에 ML 디노이저가 들어오면 클릭 리미터와 게이트와 하이패스 대부분이 전부 군더더기라는 것이었습니다. RNNoise는 정확히 키보드와 마우스와 타이핑 소음으로 학습되었고, 진폭 클리핑은 같은 일을 명백히 더 못하는 버전이기 때문입니다. 프로덕션 클라이언트는 ML 디노이즈, 에코 캔슬, 자동 게인, 그리고 레벨용 소프트 컴프레서를 출시하고 그 외엔 아무것도 안 합니다. 그래서 네 단계가 빠졌고, 슬라이더 패널이 빠졌고, "노이즈 감소를 골라라" 토글도 빠지면서, 고정된 파이프라인 하나가 남았습니다.

살아남은 단계마다 자기 자리를 벌었습니다. 브라우저 에코 캔슬은 켜진 채로 둡니다. RNNoise는 에코를 다루지 않고, 그게 없으면 스피커-마이크 피드백이 무한정이기 때문입니다. 브라우저 노이즈 억제는 끕니다. RNNoise 위에 그걸 쌓으면 마찰음에 아티팩트가 생기므로 디노이저는 하나만 고릅니다. 브라우저 자동 게인은 켜진 채로 둡니다. 그걸 끄면 신호가 너무 작아져 컴프레서가 작업할 게 없어지고, Web Audio의 DynamicsCompressorNode에는 이를 보정할 makeup-gain 파라미터가 없기 때문입니다. 브라우저의 넓은 레벨링과 spike의 빠른 컴프레서는 다른 시간 척도에서 작동하며 공존합니다. RNNoise는 92퍼센트 wet에 8퍼센트 dry를 섞어 돌리는데, s, sh, f 같은 무성 자음을 과하게 억제할 수 있기 때문입니다. 이런 음들은 voice 확률이 떨어지는데, 작은 dry 경로가 약간의 키 입력 누출을 대가로 그것들을 보존합니다.

두 기능이 마무리를 짓습니다. Push-to-talk는 track.enabled를 뒤집지 않습니다. 그러면 파이프라인 버퍼에 아직 남은 모든 걸 버리고 키를 뗄 때 마지막 음절을 잘라내기 때문입니다. 대신 꼬리 근처의 GainNode가 setTargetAtTime으로 램프하는데, 빠른 어택으로 첫 음절이 살아남고 느린 릴리스로 마지막 자음이 빠져나가며, 트랙은 영구히 켜둡니다. 그리고 라디오 스타일 기능으로 요청된 5초 방송 지연은, 바이패스 갈래와 DelayNode 갈래를 크로스페이드해서 함께 돌리고, 지연된 출력을 순간 무음으로 끊고 오디오가 돌아오기 전 HUD에서 카운트다운하는 덤프 버튼을 둡니다. 디노이저를 번들링하는 건 그 자체로 작은 무용담이었습니다. 발행된 RNNoise worklet은 어떤 CDN도 해석하지 못하는 bare-specifier 임포트를 쓰므로, 수정은 로컬 esbuild 번들로 WASM을 base64로 인라인한 자체 포함 1.9 MB 파일 하나를 만들어 리포에 커밋하고, 모듈에 상대적인 URL로 참조해서 개발 서버, VitePress 빌드, 커스텀 도메인 모두에서 해석되게 하는 것이었습니다. 혹시 worklet이 로드에 실패하면 체인은 여전히 평범한 하이패스와 컴프레서를 통해 오디오를 내고, HUD가 그 실패를 빨간색으로 보여줍니다.

이 장에서 다룬 기술

군중을 위한 배치 GPU 스키닝. 원격 아바타는 헤드리스 VirtualSkeleton(skinned mesh를 벗기고 본을 남긴, 자기 mixer를 가진 완전한 클론)을 돌려서 모든 본의 bone.matrixWorld × boneInverse를 공유 StorageBufferAttribute에 채웁니다. 지오메트리 조각마다 하나의 InstancedMesh가 그 행렬들을 커스텀 TSL positionNode/normalNode에서 읽으므로, 군중 전체가 조각당 storage 업로드 한 번과 draw call 한 번이 들고, 아바타당 CPU 작업은 mixer 업데이트 한 번과 행렬 복사 한 번으로 제한됩니다. GPU 구동 LOD를 보세요.

증상이 아니라 생성된 WGSL을 읽기. cannot index type 'f32' 컴파일 오류는 Three.js의 MorphNode가 morphTargetInfluences를 스칼라로 선언하고 첨자를 다는 데서 비롯됐고, morph를 쓰지 않는 지오메트리에서 morphAttributes를 비워 고쳤습니다. 어떤 셰이더 경로가 생성되는지만 바꾼 첫 수정은 원인을 가렸고 나중에 Safari를 깨뜨렸습니다. skinIndex/skinWeight를 boneIndex/boneWeight로 이름 바꾸면 Three.js의 자동 SkinningNode 주입에서 속성을 숨겨, 커스텀 스키닝 머티리얼이 수학을 소유합니다.

Hibernating Durable Object 릴레이. 순수 바이너리 AvatarRoomDO는 36바이트 프레임을 디코드하지 않고 다른 모든 peer에게 전달하며, 발신자 신원은 프레임에 박혀 있고 자기 echo는 클라이언트 쪽에서 걸러집니다. Hibernating WebSocket은 유휴 방을 공짜로 만들고, 이 형태는 10 Hz에서 peer-시간당 약 0.5센트로, 동등한 관리형 WebSocket 가격보다 훨씬 낮습니다. 마지막으로 큐에 들어간 상태가 아니라 재생 중인 애니메이션 상태와 비교한 중복 제거 가드는 정지 메시지를 조용히 버려서 원격 플레이어를 걷기 루프에 가두었습니다.

HRTF를 쓰는 WebRTC 근접 음성. peer마다 하나의 RTCPeerConnection으로 offer/answer 역할은 peer-id 순서로 결정하고, 오디오는 HRTF PannerNode를 통과하며 AudioListener는 플레이어 방향에서 매 프레임 업데이트되고, Opus는 회복력을 위해 in-band FEC와 함께 128 kbps로 손봤습니다. 음소거된 숨겨진 <audio> 요소가 Chrome이 Web Audio 전용 스트림에서 패킷을 끌어오게 강제합니다.

빼는 오디오 엔지니어링. Meet/Teams 품질을 맞추는 건 단계를 더하는 게 아니라 빼는 것이었습니다. ML 디노이즈 더하기 에코 캔슬 더하기 자동 게인 더하기 소프트 컴프레서, 게이트도 클릭 리미터도 없이. 키보드 소음으로 학습된 ML 디노이저가 진폭 클리핑을 군더더기로 만들기 때문입니다. Push-to-talk는 트랙을 뒤집는 대신 비대칭 엔벨로프로 꼬리 GainNode를 램프해서 음절이 잘리지 않게 하고, 디노이저 worklet은 bare-specifier 임포트 해석을 피하려고 단일 자체 포함 esbuild 번들로 출시됩니다.

29부 중 23부. 이전: 22부 - 빛을 줄 수 있는 구름, 그리고 먹여야만 하는 컬링 다음: 24부 - 세계를 저장하기, 그리고 눈에 보이는 바람 시리즈 안내: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

21부는 결과적으로 별 소득이 없었던 렌더링 기법에 관한 것이었습니다. 이번 부분에는 소득이 있었던 것 하나, 그리고 동작하게 만들려면 세심한 수정이 필요했던 것 하나가 있습니다. Spike 43은 하늘입니다. 물리 기반 대기와 볼류메트릭 구름, 즉 어떤 장면을 기술 데모가 아니라 하나의 장소로 읽히게 만드는 토대입니다. Spike 44는 meshlet 방식의 GPU 컬링이고, 거기서 얻은 교훈은 오클루전 테스트의 좋고 나쁨은 거기에 무엇을 먹이느냐에 달려 있다는 것입니다.

그래디언트가 아니라 물리에서 나온 하늘

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

거의 모든 영화적인 날씨 효과는 두 가지 기반 위에 놓입니다. 하나는 물리 기반 대기입니다. 하늘색과 태양색이 손으로 조정한 그래디언트가 아니라 물리로부터 시간대를 따라가게 합니다. 다른 하나는 볼류메트릭 구름 볼륨입니다. 하늘이 구운 큐브맵 대신 3D 구조를 갖게 합니다. Spike 43은 기존 WebGPU와 TSL 스택 위에 바로 이 한 쌍을 만들 뿐 그 이상은 하지 않습니다. 이 둘이 존재하고 나면 날씨 스택의 나머지(안개, 신의 광선, 젖은 표면, 눈)는 이미 알려진 더 작은 후속 작업들의 연속이 되기 때문입니다.

대기는 Hillaire 2020 모델입니다. WGSL 컴퓨트 셰이더에서 계산하는 룩업 테이블 묶음이죠. 투과율 테이블은 Rayleigh, Mie, 오존 밀도 프로파일을 통과하는 태양광을 적분하고 태양이 움직일 때만 다시 계산합니다. 스카이뷰 테이블은 매 프레임 다시 굽습니다. 게이팅하느라 코드를 쓸 가치가 없을 만큼 충분히 싸기 때문이며, 지평선 주변에서 밴딩을 피하려고 비선형 파라미터화를 씁니다. 다중 산란은 지금은 제대로 된 테이블 대신 해석적 피팅을 쓰는데, 노을이 제대로 읽히니 그 지름길이 잘 숨어 있는 셈입니다. 구름은 Schneider Nubis 방식으로 수평 슬래브를 가로지르는 레이 마치이고, 형태는 32³ Worley 텍스처로 침식된 128³ Perlin-Worley 텍스처에서 나오며, 둘 다 부팅 시 컴퓨트로 굽고 네트워크 요청은 없습니다. Beer 법칙 감쇠, 이중 로브 위상 함수, powder 근사로 빛을 줍니다. 핵심 결합은 구름의 태양색이 매 스텝마다 같은 투과율 테이블을 샘플링한다는 점입니다. 그래서 구름 조명이 두 번째 튜닝 패스 없이도 노을을 따라갑니다.

M1에서는 절반 해상도 구름 기준으로 전체가 1.1에서 2.0 ms에 들어옵니다. 6 ms 예산을 한참 밑돌고, GPU 메모리는 약 14 MB를 쓰며, 100 FPS를 넘겨 돌아갑니다. 두 가지 명제는 실전에서 모두 버텼습니다. 노을은 히어로 샷, 렌더러가 영화처럼 느껴지게 하는 그 순간이고, 시간대별 튜닝 없이 물리에서 떨어져 나옵니다. 그리고 행복한 우연도 있었습니다. 구름 슬래브를 800 m와 4000 m 사이로 파라미터화하니, 낮은 카메라에서 보면 지평선의 먼 구름이 어두운 산등성이처럼 읽힙니다. 누구도 배경 지형을 모델링하지 않았는데 세계에 배경 지형이 생긴 셈입니다.

기록해 둘 만한 아키텍처 메모가 하나 있습니다. 가장 자연스러운 형태는 하늘을 먼저 스왑 체인(swap chain)에 그린 다음 three.js가 autoClear = false로 그 위에 지오메트리를 그리게 하는 것입니다. 이건 r184의 WebGPU 렌더러에서는 살아남지 못합니다. 그 플래그가 WebGL에서처럼 컬러 load op를 게이팅하지 않아서 three.js가 매 프레임 하늘을 덮어 버리기 때문입니다. 해결책은 three.js를 오프스크린 타깃에 렌더링하고, 스왑 체인을 소유하는 우리 자신의 패스에서 최종 합성(mix(skyCloud, scene, scene.alpha) 다음 ACES 다음 sRGB)을 하는 것입니다.

오클루더만큼만 좋은 컬링

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

Spike 44는 네 가지 렌더링 모드를 서로 벤치마크합니다. 평범한 포워드, CPU 클러스터 컬링, GPU 컴퓨트 컬링, 그리고 Hi-Z 오클루전 컬링이 붙은 visibility buffer입니다. 흥미로운 건 Hi-Z 경로인데, 여기에 조용한 버그가 하나 있었습니다. HUD는 오클루전이 켜져 있다고 말했지만 "Hi-Z killed" 카운터는 영원히 정확히 0.0%에 머물렀습니다. 프러스텀 컬링은 동작했으니 컬 셰이더의 앞단은 문제가 없었습니다. 오클루전 쪽 절반이 풀 비용을 치르는 무동작이었던 겁니다.

Hi-Z 오클루전 테스트는 클러스터의 바운딩 박스를 화면에 투영하고, 화면 사각형이 약 2×2 텍셀이 되도록 깊이 피라미드의 mip 레벨을 고르고, 그 사각형 안에서 가장 깊은 오클루더 깊이를 샘플링한 뒤, 클러스터의 가장 가까운 점이 그 오클루더보다도 멀면 클러스터를 거부합니다. 깊이 피라미드는 매 프레임 만들어지는데, 불투명 깊이 프리패스로 mip 0을 시드한 다음 위로 max-reduce 합니다. 이 불투명 프리패스는 의도적으로 단단한 오클루더, 즉 지면과 나무별 줄기 프록시만 포함합니다. 알파 테스트된 잎은 구멍을 뚫어 max-reduce를 속이기 때문입니다.

버그는 기하학적이었지 논리적인 게 아니었습니다. 줄기 프록시는 0.5 m × 4 m × 0.5 m 박스였습니다. 30 m에서는 화면에 약 17픽셀로 투영됩니다. 그런데 전형적인 50 m 풀 클러스터는 mip 5를 고르고, 거기서는 텍셀 하나가 소스 픽셀 32개를 덮습니다. 17픽셀짜리 줄기는 단일 mip-5 텍셀을 완전히 덮지 못하므로, 줄기에 닿는 모든 텍셀은 주변 지면에도 닿습니다. 맨 처음의 2×2 max-reduce는 더 큰 깊이 값, 즉 줄기 뒤의 더 먼 지면을 고르고, 그래서 줄기의 깊이는 첫 번째 리덕션에서 지워집니다. mip 5에 이르면 피라미드는 거의 어디서나 지면 깊이를 들고 있고, 클러스터는 결코 지면보다 멀지 않으며, 그래서 어떤 것도 결코 오클루드되지 않습니다.

해결책은 프록시를 그것이 떨어지는 텍셀들을 지배할 만큼 충분히 크게, 나무의 목재가 아니라 실루엣에 맞춰 크기를 정하는 것입니다. 대략 2 m × 6 m × 2 m 프록시는 여전히 실제 수관보다 작아서 틈으로 보이는 잎이 과도하게 컬링되는 일은 없지만, 중요한 거리까지 max-reduce를 견딜 만큼은 크고, 그러자 오클루전 카운터가 즉시 0이 아니게 되었습니다. 이 교훈은 프로덕션 엔진을 위한 규칙으로 일반화됩니다. Hi-Z 오클루더로 신뢰받는 것은 무엇이든 물리적 본체가 아니라 화면상 실루엣에 맞춰 크기를 정해야 합니다. 트인 식생 장면에서 Hi-Z의 효과는 깊이 테스트 수식의 우아함이 아니라 해당 mip에서의 오클루더 커버리지가 좌우하기 때문입니다. 풀 대 풀 오클루전은 어차피 발동할 수 없습니다. 풀잎은 그 아래 지면과 같은 깊이에 있으니까요. 그래서 진짜 이득은 나무가 먼 식생을 가리는 것, 그리고 나무가 나무를 가리는 것입니다.

이 장에서 언급한 기술

Hillaire 2020 대기 LUT. 투과율 테이블(Rayleigh, Mie, 오존 프로파일을 통과하는 태양광)은 태양이 움직일 때만 다시 계산하고, 여기에 지평선 비선형 파라미터화를 곁들인 프레임별 스카이뷰 테이블을 더하면, 손으로 조정한 그래디언트 없이 시간대를 따라가는 물리 기반 하늘색과 태양색이 나옵니다. 어떤 아티팩트가 제대로 된 굽기를 강요하기 전까지는 해석적 다중 산란 피팅이 완전한 테이블을 대신합니다. 노을은 시간대별 튜닝 없이 물리에서 떨어져 나옵니다.

Schneider Nubis 볼류메트릭 구름. 수평 슬래브를 가로지르는 레이 마치로, 부팅 시 구운 128³ Perlin-Worley 텍스처를 32³ Worley 텍스처로 침식해 형태를 잡고, Beer 법칙 감쇠와 이중 로브 위상과 powder 항으로 빛을 줍니다. 매 스텝마다 같은 투과율 테이블에서 구름의 태양색을 샘플링하면 구름 조명이 일출과 일몰을 공짜로 따라갑니다. 절반 해상도 레이 마치는 전체 해상도보다 대략 4배 싸고, 전형적인 거리에서 눈에 띄는 품질 손실이 없습니다. 표준적인 프로덕션 트레이드오프죠.

r184에서 raw WebGPU와 three.js 합성하기. 하늘을 스왑 체인에 그린 다음 autoClear = false로 그 위에 three.js 지오메트리를 그리는 방식은 실패합니다. 그 플래그가 WebGPU 백엔드에서 컬러 load op를 게이팅하지 않기 때문입니다. three.js를 오프스크린 RGBA16F 타깃에 렌더링하고, 스왑 체인을 소유하는 패스에서 최종 mix 더하기 톤맵 더하기 sRGB를 하세요.

Hi-Z 오클루전 컬링과 오클루더 크기 정하기. max-reduce로 만든 깊이 피라미드는 GPU 컬 패스가 화면 사각형 내 가장 깊은 오클루더보다 가장 가까운 점이 뒤에 있는 클러스터를 거부하게 해줍니다. 오클루더가 선택된 mip에서 텍셀을 지배하기에 너무 작으면 이 테스트는 조용히 아무것도 하지 않습니다. 첫 max-reduce가 오클루더의 깊이를 그 뒤의 더 먼 배경으로 바꿔 버리기 때문입니다. 오클루더는 물리적 본체가 아니라 화면상 실루엣에 맞춰 크기를 정해야 합니다. GPU 주도 LOD를 보세요.

29부 중 22부. 이전: 21부 - 더 빠르지 않았던 더 빠른 렌더러 다음: 23부 - 아바타 쉰 명과 방 안의 목소리 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

20부에서는 평평한 쿼드 위에 표면 깊이를 가짜로 만들었습니다. 이번 부분은 렌더 아키텍처 결정에 관한 것이고, 교과서적인 정답이 우리 하드웨어에서는 틀린 것으로 드러난 바로 그 spike입니다. 질문은 이렇습니다. 3인칭 카메라 아래 영화 수준 밀도의 alpha-test 풀에 대해, 200명 밀도로 밀어붙이기 전에 visibility buffer가 필요한가? 통상적인 조언은 단호하게 "그렇다"입니다. 우리는 그것을 만들었고, 측정했고, 답은 "아니다"였습니다.

모두가 추천하는 그 기법

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

visibility buffer는 렌더링을 두 개의 pass로 나눕니다. Pass 1은 지오메트리를 래스터화하고 삼각형 ID와 인스턴스 ID만 깊이와 함께 압축된 정수 타깃에 쓰며, 셰이딩은 전혀 하지 않습니다. Pass 2는 풀스크린 pass로, 덮인 각 픽셀의 ID를 읽고 그 삼각형의 정점을 다시 가져와서 보간된 속성을 재구성하고, 보이는 각 픽셀을 정확히 한 번씩만 셰이딩합니다. 핵심 강점은 완벽한 overdraw 제거입니다. 깊이 테스트는 셰이딩 작업을 하나도 하지 않은 프래그먼트에 대해 실행되므로, 비싼 머티리얼은 당신이 실제로 보는 것에만 돌아갑니다.

이 spike는 한 캔버스, 한 device 위에서 두 경로를 돌려서 유일한 변수가 셰이딩이 어디에서 일어나는지가 되도록 합니다. forward 경로는 three.js를 통한 평범한 MeshStandardNodeMaterial입니다. vis-buffer 경로는 three.js 밖에서 도는 raw WebGPU 2-pass 파이프라인으로, three.js의 풀 텍스처를 백엔드에서 곧장 읽어 pass 1에서 (instanceId, triId)를 RG32Uint 타깃에 쓰고 pass 2에서 라이팅을 해석합니다. 둘은 하나의 ground-truth 라이팅 설정을 공유합니다.

기억해 둘 만한 구현 노트가 두 가지 있습니다. WebGPU는 프래그먼트 셰이더에서 여전히 이식 가능한 primitive_index 빌트인이 없어서, 정점별 삼각형 ID를 비인덱스 지오메트리에 구워 넣고 flat 보간으로 읽는 게 요령입니다. 이건 정점 수를 3배로 만들지만 12정점짜리 풀 카드에서는 무시할 만합니다. 그리고 three.js의 렌더러와 캔버스를 공유하는 일은, 컨텍스트를 다시 구성하지 않고 캔버스 크기를 건드리지 않는 한 거의 아무 일도 아닙니다. 둘 다 three.js가 관리하는 것이거든요. forward 경로의 시간을 재는 게 까다로운 부분이었는데, three.js가 자기 렌더 pass 안에 GPU 타임스탬프 쿼리를 주입할 훅을 노출하지 않기 때문입니다. 우회책은 그 작업 앞뒤로 no-op 타임스탬프 pass를 두 개 제출해 작업을 감싸는 것이고, GPU는 이들을 제출 순서대로 실행합니다.

숫자가 잘못된 방향으로 간다

M 시리즈 Mac에서 약 1080p, 80m 들판 위에 교차 카드 풀잎을 깔고 측정했습니다.

인스턴스 5만 개에서 vis-buffer 경로가 25% 이겼습니다. 4.13ms 대 forward의 5.51ms입니다. 10만 개에서는 비겼습니다. 20만 개에서는 forward가 44% 이겼습니다. 5.44ms 대 vis-buffer의 7.80ms입니다. 밀도가 올라갈수록 vis-buffer 경로는 상대적으로 더 나빠지는데, 이는 overdraw가 심할 때 바로 이긴다는 통설과 정확히 반대입니다.

forward가 버티는 이유

Apple Silicon GPU는 타일 기반 디퍼드 렌더러(TBDR)이고, 이것이 계산 전체를 바꿔 놓습니다. TBDR 위의 forward 셰이딩에는 프래그먼트 셰이더가 돌기 전에 실행되는 은면 제거(HSR) 단계가 있습니다. 래스터라이저가 한 타일에 매핑되는 모든 프래그먼트를 모아 깊이로 정렬하고, 살아남은 것들(alpha-test 통과 이후)만 프래그먼트 셰이더에 도달합니다. 그래서 forward 경로는 이미 하드웨어 안에서, 공짜로, visibility buffer의 "픽셀당 한 번만 셰이딩" 약속의 대부분을 이행하고 있습니다. 풀잎이 화면을 가득 채울수록 더 많은 프래그먼트가 셰이딩이 일어나기 전에 HSR에서 거절되고, forward의 실효 픽셀당 비용은 overdraw와 함께 늘어나는 대신 대체로 평평하게 유지됩니다.

vis-buffer 경로의 pass 1도 똑같은 TBDR 이점을 얻습니다. 문제는 전부 pass 2에 있습니다. Pass 2는 각 픽셀의 인스턴스 행렬을 버퍼에서 읽는데, 이 버퍼는 인스턴스 20만 개에서 12.8MB로, 어떤 GPU 캐시보다도 훨씬 큽니다. 화면에서 인접한 픽셀들은 대개 서로 다른 풀 인스턴스에 속하므로(scatter가 지터링된 그리드라서 이웃 풀잎들은 임의의 인스턴스 ID를 가집니다), 그 버퍼를 치는 모든 wave가 발산적으로 캐시를 놓칩니다. 이 비일관 랜덤 접근 하나만으로도 프레임당 약 4ms가 숨어 있습니다. forward는 이를 완전히 피하는데, 인스턴스 행렬이 정점과 함께 인스턴스별 속성 경로로 도착하기 때문입니다. 그래서 프래그먼트 셰이더가 돌 때쯤이면 변환된 정점 데이터가 이미 타일 로컬 레지스터에 있어서 메가바이트 규모의 랜덤 읽기가 필요 없습니다.

이것이 바로 Nanite의 머티리얼 분류 pass가 분산시키려고 존재하는 그 비용입니다. 픽셀을 인스턴스별로 분류하고 정렬된 compute wave를 디스패치해서 각 wave의 읽기가 일관되게 만드는 것이죠. 우리에게는 그게 없습니다. 대략 계산해 보면 픽셀을 인스턴스별로 정렬하면 그 4ms를 1.5에서 2ms 정도로 떨어뜨리고 교차점을 인스턴스 40만에서 50만 개로 밀어낼 수 있습니다. 하지만 그건 애초에 여기서 이기지 못하는 아키텍처 위에 최적화를 쌓는 일입니다.

솔직한 결론, 그리고 그것을 얻어 낸 감사

Apple Silicon WebGPU에서 alpha-test 교차 카드 식물에 대해서는, three.js TSL 파이프라인의 forward 경로가 이미 vis-buffer 비용에 맞먹거나 그보다 낮습니다. 그리고 vis-buffer 배선은 인스턴스 20만 개를 한참 넘어서기 전까지, 그것도 정렬이나 비닝 pass를 추가로 넣어야만 눈에 보이는 어떤 것도 사 주지 못합니다. 프로덕션 엔진에 대한 현실적인 판단은 앞선 spike들에서 만든 forward 더하기 LOD 더하기 imposter 스택을 유지하고, 두 가지 중 하나가 될 때까지는 vis-buffer 인프라에 투자하지 않는 것입니다. 하나는 우리가 별도의 NVIDIA나 AMD GPU를 주력 배포 대상으로 삼는 경우(거기서는 overdraw 비용이 더 선형적입니다)이고, 다른 하나는 vis-buffer가 어차피 자연스러운 출력이 되는 meshlet 아키텍처로 옮겨 가는 경우입니다.

이 결과가 직관에 반하기 때문에, 결론은 비교가 공정할 때만 가치가 있습니다. 그래서 이 spike는 전체 감사를 한 번 거쳤습니다. 실제 버그 몇 개가 드러나서 고쳐졌습니다. 두 경로를 조용히 어긋나게 하던 풀잎 스케일 슬라이더, 반평행 법선 때문에 forward 풀잎의 절반이 칠흑같이 어둡게 렌더되던 문제(법선을 위로 통일하는 정석적인 식물 기법으로 해결), 그리고 vis-buffer가 약 2배 너무 밝게 읽히던 문제입니다. 이는 에너지 보존 1/π 대신 손으로 고른 Lambert 인자, 하드코딩된 앰비언트 항, 누락된 톤 매핑 때문이었습니다. 수정은 three.js의 정확한 ACES filmic 곡선을 WGSL로 그대로 옮기고, 매 프레임 실제 씬 라이트에서 조명 색과 강도를 읽도록 했습니다. 남은 알려진 격차인 pass 2의 직접 스페큘러 누락은 비교를 vis-buffer 쪽으로 편향시킵니다. 즉 forward는 픽셀당 엄밀히 더 많은 일을 하면서도 고밀도에서 여전히 이기고 있다는 뜻입니다. 그래서 헤드라인 결론은 낙관적인 게 아니라 보수적입니다. 유효한 단서 하나는 이렇습니다. 이 모든 것은 M 시리즈에 특정한 이야기이고, 교차점은 별도 카드에서는 충분히 뒤집힐 수 있으므로, 비 Apple 대상에 스택을 확정하기 전에 다시 돌려 볼 가치가 있습니다.

이 장에서 언급한 기술

visibility buffer 렌더링. Pass 1은 지오메트리를 래스터화하고 삼각형 ID와 인스턴스 ID만 깊이와 함께 쓰며 셰이딩은 하지 않습니다. Pass 2는 풀스크린 해석으로, 덮인 픽셀마다 ID를 읽고 원본 삼각형을 다시 가져와 원근 보정된 무게중심 속성을 재구성하고, 보이는 각 픽셀을 한 번씩 셰이딩합니다. WebGPU에는 이식 가능한 프래그먼트 primitive_index가 없으므로, 삼각형 ID는 비인덱스 지오메트리 위에 flat 보간되는 정점별 속성으로 구워 넣습니다.

TBDR 은면 제거 대 디퍼드 해석. 타일 기반 디퍼드 GPU(Apple Silicon)에서는 forward 셰이딩이 프래그먼트 셰이더가 돌기 전에 이미 가려진 프래그먼트를 거절하므로, visibility buffer의 한 번만 셰이딩하는 이점 대부분을 공짜로 가져가고, 그 픽셀당 비용은 overdraw가 늘어도 대체로 평평하게 유지됩니다. 반면 vis-buffer 해석 pass는 큰 인스턴스별 버퍼(인스턴스 20만 개에서 12.8MB)로의 비일관 랜덤 접근에 비용을 치르는데, 이는 Nanite의 머티리얼 분류처럼 픽셀을 먼저 인스턴스별로 정렬하거나 비닝하지 않는 한 고밀도에서 지배적입니다.

three.js의 WebGPURenderer와 캔버스 공유. raw WebGPU 커맨드 버퍼는 context.configure()를 다시 호출하지 않고 canvas.width/height를 쓰지 않는 한 공유 큐 위에서 three.js 제출과 올바르게 교차됩니다. 둘 다 렌더러가 관리합니다. three.js가 훅을 노출하지 않는 forward 경로 GPU 타이밍은, 그 렌더 호출 앞뒤로 no-op 타임스탬프 렌더 pass를 두 개 제출해서 감쌀 수 있습니다. GPU가 커맨드 버퍼를 제출 순서대로 실행하기 때문입니다.

직관에 반하는 벤치마크 검증하기. 놀라운 성능 결과는 비교의 공정성만큼만 믿을 수 있습니다. 두 경로를 동일한 씬 콘텐츠와 셰이딩으로 감사하는 것(일치하는 ACES 톤 매핑, 에너지 보존 Lambert, 같은 오브젝트에서 읽은 라이트, 동일한 풀잎 스케일)이 바로 "vis-buffer가 더 느리다"를 그럴듯한 측정 잡음에서 방어 가능한 결론으로 바꿔 놓았고, 남은 한 가지 비대칭은 보수적인 방향으로 편향되어 있습니다.

29부 중 21부. 이전: 20부 - 평평한 면에 깊이를 가짜로 만들기 다음: 22부 - 뚫고 날아갈 수 있는 구름, 그리고 값을 하는 컬링 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

19부는 평평한 쿼드 하나로 멀리 있는 나무 전체를 흉내냈습니다. 이번 부는 평평한 쿼드 하나로 가까이에서 깊이를 흉내냅니다. 시차 차폐 매핑(parallax occlusion mapping), 추가 정점을 단 하나도 쓰지 않고 자갈길에 5cm 깊이로 들어간 줄눈이 있는 것처럼 보이게 만드는 기법입니다. 목표는 이걸 프로덕션 스택(Three.js r184, WebGPU, TSL)에 안착시켜서, 지형 디테일 머티리얼이 깊이가 중요한 곳에서는 그 깊이 착시를 가져가고 나머지 모든 곳에서는 평평한 텍스처 비용만 내도록 하는 것이었습니다.

깊이를 흉내내는 세 가지 방법, 나란히

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

이 spike는 평평한 5×5m 평면 세 개를 나란히 놓습니다. 모두 같은 머티리얼 골격을 쓰고, 다른 점은 샘플러에 들어가는 UV뿐입니다. Flat은 텍스처를 그대로 샘플링하는, 기준선이 되는 베이스라인입니다. 단일 샘플 시차는 그 지점의 높이만큼 시선 방향을 따라 UV를 한 번 밀어내는데, 저렴하고 낮은 진폭에서는 괜찮지만 비스듬한 각도에서는 출렁입니다. POM은 접선 공간에서 광선 행진(ray-march)을 합니다. 시선 광선을 따라 한 단계씩 나아가며 광선이 높이장 아래로 내려가는 첫 번째 층을 찾고, 그 교차점을 정교하게 다듬습니다. 모든 테스트 평면이 축에 정렬되어 있어서 접선 공간은 단순하게 유지됩니다. 그래서 시선 방향은 정점마다 필요한 완전한 TBN 행렬 대신 부호 몇 개만 뒤집으면 접선 공간으로 패킹됩니다. 텍스처 세트는 Polyhaven 파일 API에서 실시간으로 가져오는데, 17부의 모델 검색이 쓴 것과 같은 경로입니다.

WebGPU의 두 벽, 그리고 분기 없는 광선 행진

교과서적인 POM 루프는 첫 교차에서 검색을 빠져나옵니다. r184에서는 이게 통하지 않는데, 서로 별개인 두 가지 이유 때문입니다. If(...).and(...)는 오류 없이 컴파일됐지만 루프 본문이 절대 실행되지 않는 WGSL을 만들어내서, 루프 뒤의 정교화가 쓰레기 데이터 위에서 돌았고 평면이 거의 흰색으로 렌더링됐습니다. 그리고 독립 노드로서의 Break()는 r184 빌드에 아예 들어오지 않아서, If가 제대로 동작하더라도 "첫 교차에서 멈춰라"를 표현할 방법이 없었습니다. 둘 다 이 버전 구간에서 TSL 제어 흐름이 If와 Loop 경계를 넘어 과하게 최적화하는, three.js의 알려진 이슈들로 거슬러 올라갑니다.

다시 쓴 버전은 분기가 없습니다. 매 반복마다 무조건 텍스처를 샘플링하는데, 이렇게 하면 WGSL 명세가 원하는 대로 텍스처 접근을 균일한 제어 흐름 안에 유지하게 되고, 그런 다음 float으로 들고 있는 done 플래그를 통해 새 상태를 접어 넣습니다. done이 1로 뒤집히면 반복마다의 mix 호출은 "상태를 그대로 유지"로 퇴화하는데, 이것이 break의 분기 없는 등가물입니다. done 플래그는 0.5 + 0.5 × sign(x + ε)로 구현한 step 헬퍼로 만듭니다. 불리언에서 float으로의 강제 변환이 r18x 계열 전반에서 들쭉날쭉했던 반면 sign()은 어디서나 안전하기 때문입니다. 비용은 프래그먼트가 실제로 어디서 교차하든 모든 프래그먼트가 64회 반복을 전부 돈다는 것이지만, 프래그먼트 규모에서는 이게 맞는 거래입니다. 런타임이 어차피 최대 단계 수로 제한을 걸고, 진짜 GPU도 "진짜" break를 만나면 그것을 넘어 추측 실행을 했을 테니까요. 여기서는 깔끔한 폴백이 중요합니다. 마지막 mix(baseUV, refined, done) 덕분에, 진폭이 0일 때(거리 페이드의 먼 끝) 어떤 프래그먼트도 교차하지 않고 done은 0으로 남으며 POM 머티리얼은 flat과 비트 단위로 동일해집니다. 이것이 바로 거리-LOD 트릭의 핵심입니다. 효과가 어차피 서브픽셀인 곳에서는 비용을 평평한 비용으로 무너뜨리는 것이죠.

버그는 수학의 실패가 아니라 규율의 실패였다

분기 없는 버전은 돌긴 했지만 왜곡되어 보였습니다. 중간 진폭에서는 줄무늬 같은 수평 아티팩트가, 낮은 진폭에서는 "미묘하게 틀렸지만 또렷하지는 않은" 결과가 나왔습니다. 해결책은 한 줄짜리 프롬프트에서 나왔습니다. 정본 참조를 가서 읽어라. 이걸 떠올리게 한 LlamAcademy 튜토리얼은 그저 Unity ShaderGraph 노드 하나라서, 진짜 구현은 Unity의 PerPixelDisplacement.hlsl에 들어 있습니다. 한 줄 한 줄 읽으면서, 제가 모르고 들여놓은 세 가지 의미 차이가 드러났습니다. 광선 높이 베이스라인의 하나 차이 오류(Unity는 루프 전에 초기 전진을 한 번 해서, 제 기준 틀이 한 단계 통째로 위상이 어긋나 있었고 그래서 약 절반의 경우 교차점이 잘못된 층에 떨어졌습니다), 정교화 단계가 의존하는 최대 오프셋의 부호 관례, 그리고 제 정교화 수학을 더 힘들게 만들고 부호를 엉키게 한 누적 오프셋 대 누적 UV의 장부 기록 선택이었습니다.

근본 원인은 어느 한 가지 실수가 아니라 두 참조를 섞은 것이었습니다. 저는 LearnOpenGL의 POM 튜토리얼을 길잡이로 삼았는데, 거기는 비슷하지만 다른 부호 관례와 다른 정교화 공식을 씁니다. 결국 수학의 3분의 2는 한 출처와 맞고 3분의 1은 다른 출처와 맞는 잡종 상태에 빠졌습니다. 다시 쓴 버전은 Unity의 HLSL을 거의 한 글자 한 글자 TSL로 옮긴 것으로, 같은 변수 이름, 같은 초기 전진, 같은 정교화에 분기 없는 done 플래그를 위에 얹었습니다. 새겨둘 만한 교훈입니다. 다른 스택에서 검증된 셰이더를 이식할 때는, 먼저 같은 이름으로 한 줄 한 줄 옮긴 다음에 로컬 스타일에 맞게 리팩터링하세요. 이식 중간에 두 번째 참조에 대고 다시 유도하지 마세요.

거짓말을 할 수 없는 기준 평면

나란히 놓은 비교에는 가장 뻔한 것이 빠져 있었습니다. 실제 지오메트리 평면 말입니다. 그게 없으면 "POM이 꽤 괜찮아 보인다"는 반증할 수 없습니다. 꽤 괜찮다는 건 무엇과 비교해서요? 그래서 spike는 네 번째 평면을 추가했습니다. 같은 높이 맵을 실제 정점 위치로 밀어낸 것입니다. WebGPU에는 하드웨어 테셀레이션이 없어서(그냥 명세에 들어 있지 않고, Metal 호환성 때문에 잘려나갔습니다), 그 대체물은 정점 단계에서 정점 변위를 적용한 촘촘하게 분할된 평면(256×256 세그먼트, 131,072개 삼각형)입니다. 같은 진폭 uniform이 POM과 지오메트리 평면을 둘 다 구동하므로, 둘은 함께 페이드되고 비교는 모든 거리에서 같은 것끼리의 비교로 유지됩니다.

화면에 정답이 떠 있게 되자 정성적인 주장들이 측정 가능해졌습니다. 아래를 내려다보는 16° 궤도에서 POM과 테셀레이션된 평면은 내부 음영에서 일치합니다. 비스듬한 각도에서는 둘이 갈라져야 할 바로 그 지점에서 갈라집니다. POM은 지오메트리의 완벽하게 곧은 직사각형 가장자리에 클램프되는 반면, 진짜 메시는 빛을 받는 실제 봉우리와 골짜기들로 이루어진 울퉁불퉁한 지평선 윤곽을 보여줍니다. 그래서 POM의 가장자리 "출렁임"은 이제 텍스처나 조명의 아티팩트가 아니라 알고리즘에 본질적으로 내재한 것임이 증명됩니다. 두 가지 비용 형태도 분명해집니다. POM은 프래그먼트에 묶여 있고(비용이 덮인 픽셀에 비례), 테셀레이션된 평면은 정점에 묶여 있습니다(비용이 커버리지와 무관하게 메시 밀도에 비례). 이미 높이 맵으로 구동되는 평면의 정점 비용을 내고 있는 지형 청크에게는, 메시보다 작은 디테일에 대해서는 POM이 정답입니다.

기준 평면은 미묘한 UX 버그도 잡아냈습니다. 사용자는 진폭이 커질수록 표면이 가라앉는 것처럼 보인다는 걸 알아챘습니다. 이는 기하 평면을 높이장의 꼭대기로 취급하는 Unity의 관례로 거슬러 올라갑니다. 봉우리들이 딱 붙어 고정되고 나머지 모든 것이 아래로 시차 처리되면서, 평균 표면을 평평한 베이스라인 아래로 (1 − mean_h) × amplitude만큼 끌어내린 것이죠. 해결책은 관례를 다시 중앙에 맞춰 h = 0.5가 평면이 되고, 봉우리는 카메라 쪽으로 솟고 골짜기는 안으로 들어가게 한 것입니다. 알고리즘은 Unity가 규정한 그대로 돌아갑니다. spike는 그저 슬라이더를 끄는 사람에게 "진폭"이 의미해야 할 바에 맞추기 위해 출력을 절반 오프셋만큼 후처리할 뿐입니다.

기준 평면이 정리해 준 게 하나 더 있습니다. "Steps" 슬라이더가 아무것도 안 하는 것처럼 보였는데, 배관 버그처럼 읽혔지만 아니었습니다. 선형 검색 뒤의 세 번 할선법(secant) 정교화가 너무 좋아서(Tatarchuk의 2006년 POM 논문은 4단계 검색에 3단계 할선법을 더하면 64단계 검색과 시각적으로 구별할 수 없다고 적습니다), 매끄러운 높이 맵에서는 4부터 64까지 모든 단계 수가 같은 서브텍셀 UV로 수렴합니다. 해결책은 다시 배관하는 게 아니라 토글이었습니다. 할선법을 끄면 단계 슬라이더가 교차 정밀도를 다루는 유일한 컨트롤이 되어서, 4로 떨어뜨리면 자갈이 눈에 띄게 계단처럼 끊기고 64로 끌어올리면 다시 매끈해집니다. 이 토글은 0/1 uniform으로, 꺼져 있을 때 매 할선법 상태 갱신을 no-op으로 mix하므로, 토글해도 머티리얼을 절대 다시 만들지 않고 절대 끊기지 않습니다.

이 장에서 다룬 기술

TSL 안의 시차 차폐 매핑. POM은 접선 공간에서 높이장을 따라 시선 방향으로 광선 행진을 하고, 광선이 표면 아래로 떨어지는 첫 번째 층을 찾아 교차점을 정교화하여, 추가 지오메트리 없이 평평한 쿼드 위에 들어간 줄눈의 깊이를 만들어냅니다. 마지막 mix(baseUV, refined, done)은 어떤 프래그먼트도 교차하지 않을 때 머티리얼을 flat과 비트 단위로 동일하게 만들고, 이것이 거리-LOD 진폭 감쇠가 멀리서 비용을 평평한 텍스처 비용으로 무너뜨리게 해주는 핵심입니다. 지형 머티리얼을 보세요.

WebGPU 제어 흐름을 위한 분기 없는 루프. Three.js r184에서 TSL If(...).and(...)는 루프 본문이 절대 돌지 않는 WGSL로 컴파일될 수 있고, 독립 Break()는 쓸 수 없습니다. 이식 가능한 패턴은 반복마다 무조건 텍스처를 한 번 샘플링하고(WGSL 명세에 따라 텍스처 접근을 균일한 제어 흐름에 유지), float으로 들고 있는 done 플래그를 더해 한 번 설정되면 매 상태 갱신을 no-op으로 mix하는 것입니다. sign(x + ε)로 만든 step 헬퍼는 신뢰할 수 없는 불리언-float 강제 변환을 피합니다. 비용은 조기 종료 지점이 어디든 최대 반복 수를 도는 것이고, 이는 프래그먼트 규모에서 올바른 거래입니다.

한 글자 그대로 셰이더 이식. 다른 엔진에서 검증된 셰이더를 이식할 때는, 먼저 원본의 변수 이름으로 한 줄 한 줄 옮기고 그다음에 로컬 스타일에 맞게 리팩터링해야 합니다. 두 참조(Unity의 PerPixelDisplacement.hlsl과 LearnOpenGL 튜토리얼)를 섞으면 잡종이 나왔습니다. 광선 베이스라인의 하나 차이, 뒤집힌 오프셋 부호, 그리고 클램프가 범위 밖 가중치를 공간적 불연속으로 가려버린 정교화 공식이 나온 것이죠. 다시 유도하는 게 아니라 하나의 정본 정답이 답입니다.

정점 변위로 만든 정답 기준. WebGPU에 하드웨어 테셀레이션이 없으니, 정점 단계에서 변위시킨 촘촘하게 분할된 평면(256² 세그먼트)이 진짜 지오메트리를 대신해 프래그먼트 단계의 흉내를 검증합니다. 같은 진폭 uniform으로 둘 다 구동하면 비교가 거리 전반에서 정직하게 유지됩니다. POM은 프래그먼트에 묶여 있고(덮인 픽셀에 비례), 지오메트리 평면은 정점에 묶여 있어서(메시 밀도에 비례), 둘은 정확히 실루엣 가장자리에서 갈라지며, POM의 가장자리 출렁임이 아티팩트가 아니라 본질적인 것임을 증명합니다.

29부 중 20부. 이전: 19부 - 숲에서 살아남아야 하는 임포스터 다음: 21부 - 더 빠르지 않았던 더 빠른 렌더러 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

18부는 창작자에게 산비탈을 나무로 채우는 브러시를 줬습니다. 문제는 화면에 나무가 수만 그루 있을 때 그 나무들이 얼마나 비싸지는가입니다. 멀리 있는 나무는 픽셀 네 개를 채우려고 삼각형 2,000개를 쓸 필요가 없습니다. 이번 편은 가장 깊은 LOD입니다. 임포스터, 즉 나무 사진을 입은 평평한 quad, 그리고 "제대로 보이는 나무 한 그루"에서 GPU 위 백만 그루까지 가는 길입니다.

나무 하나는 빌보드 위 두 장의 텍스처

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

임포스터는 프롭을 시점 각도 격자에서 두 장의 텍스처 아틀라스로 미리 렌더링합니다. 하나는 색상용, 하나는 월드 공간 노멀용입니다. 그런 다음 런타임에는 현재 시점과 맞는 타일을 샘플링하는, 카메라를 향한 단일 quad 하나를 보여줍니다. 베이크는 타일마다 두 패스입니다. 디퓨즈는 무광 머티리얼로 굽기 때문에 조명이 텍스처에 구워지지 않고, 노멀은 normalWorld × 0.5 + 0.5로 인코딩하며 알파는 소스에서 그대로 가져와 실루엣이 픽셀 단위로 맞습니다. 런타임 머티리얼은 완전한 MeshStandardNodeMaterial이라서, 임포스터도 다른 표면과 똑같이 씬의 태양광과 IBL을 받습니다. 이득은 지오메트리에 있습니다. 삼각형 수천 개 대신 quad 하나, 그리고 디테일은 1 MB짜리 텍스처 안에 들어 있습니다.

이걸 별도 spike로 떼어낸 것 자체가 하나의 교훈이었습니다. 임포스터는 처음에 spike 37의 스캐터 시스템 안에서 가장 깊은 LOD였고, 베이크를 한 번 고칠 때마다 전체 스캐터 파이프라인을 거쳐 테스트해야 했습니다. 베이크의 정확성이 인스턴스 행렬 마이그레이션과 LOD 교체에 뒤엉켜 있었던 거죠. 이걸 떼어내 프롭 하나, quad 하나로 원본과 나란히 놓으니 반복 시간이 몇 분에서 몇 초로 줄었습니다.

교과서 정답이 오답일 때

첫 번째 구현은 옥타헤드럴 인코딩을 썼습니다. 구면 방향을 정사각형에 채우는 교과서적 매핑이죠. 수치 왕복 테스트는 통과했는데, 사용자는 임포스터가 정면이 아니라 약간 위에서 본 나무처럼 보이는 타일로 스냅됐다는 스크린샷을 계속 보냈습니다. 여섯 라운드의 수정이 이어졌습니다(quad별 시점 방향 uniform, 정사각형 베이크 종횡비, 디버그 머티리얼, 정적 빌보딩). 모두 진짜로 필요한 것이었지만, 그중 어느 것도 실제 버그는 아니었습니다. 수정은 "처음부터 다시 생각하자, KISS, 반창고는 그만"에서야 나왔습니다.

재작성은 옥타헤드럴 폴딩을 버리고 단순한 방위각 곱하기 고도각으로 갔습니다. az = atan2(dir.x, dir.z), el = asin(dir.y), uv = (az/2π, el/π + ½). 이게 인코딩의 전부입니다. L1 정규화도 없고, 부호가 0인 코너 케이스도 없습니다. 여기서 이게 더 나은 이유는 더 정확해서가 아니라(오히려 덜 균일한 구면을 샘플링합니다), CPU 셀 선택기와 GPU 셰이더가 같은 기본 연산을 써서 옥타헤드럴 쌍이 조용히 그랬던 것처럼 경계 방향에서 서로 어긋날 수가 없기 때문입니다. 아틀라스는 컨택트 시트처럼 읽힙니다. 열은 프롭 주위를 도는 각도, 행은 고도각이라서 오버레이에서 한눈에 분명합니다.

그 뒤에도 "약간 위에서 본 것 같다"는 불만은 살아남았고, 원인은 인코딩이 아니라 양자화 선택이었습니다. 4×4 격자에서는 행 중심이 ±22.5°와 ±67.5°에 떨어져서 정확히 0° 고도각인 행이 없습니다. 수평으로 보는 시청자는, 압도적으로 흔한 경우인데, 항상 기울어진 채로 구워진 행에 떨어집니다. 해법은 홀수 N입니다. 5×5 격자는 행 중심을 0°와 ±36°, ±72°에 놓아서 수평 시청자가 정확히 수평으로 구워진 타일을 받습니다. 같은 부류의 "반 셀 차이" 실수는 다음 편의 패럴랙스 작업에서 또 나타나고, 처방은 같은 질문입니다. 내 이산 샘플 점이 정규 입력에 대해 정말 내가 생각하는 자리에 떨어지는가?

두 가지가 더 중요했습니다. 빌보드는 카메라를 계속 향하는 게 아니라 구간별로 정적이어야 합니다. 임포스터는 특정 베이크 방향에서 찍은 평평한 사진이라서 런타임 quad의 이미지 평면이 그 베이크 카메라의 평면과 맞아야 합니다. 즉 한 셀이 선택된 채로 유지되는 호 구간 동안에는 방향을 유지하다가 경계에서 스냅합니다. 그리고 예산은 플레이어가 실제로 보는 쪽을 따라가야 합니다. 이후 한 패스에서 기울어진 탑다운 행들을 통째로 버리고 15° 간격의 수평 링 슬롯 24개에 정중앙 아래 타일 하나를 더한 구성으로 바꿨습니다. 나무는 거의 언제나 눈높이에서 보이기 때문입니다.

스냅, 그리고 블렌딩이 그걸 지운 방법

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

구간별로 정적인 빌보드는 멀리서는 보이지 않고 가까이서는 튀는데, 이건 궤도를 돌기 전까지는 괜찮습니다. Spike 42는 변형 네 개를 나란히 놓아(원본 프롭, az/el 5×5 기준선, 헤미옥타헤드럴 격자 둘) 깜빡임을 분리하고 없앴습니다. 두 가지 아티팩트가 스냅을 일으킵니다. 셀 팝은 프래그먼트 셰이더가 시점 방향을 25개 셀 중 하나로 양자화하기 때문에 일어납니다. 경계를 넘으면 같은 프레임에서 샘플링하는 타일이 바뀌고 quad가 다시 조준됩니다. 극점 퇴화는 탑다운 시점인데, 거기서는 모든 방위각이 한 점으로 무너지고 링과 상단 타일 사이의 다리가 아틀라스에서 가장 나쁜 전환입니다.

헤미옥타헤드럴 매핑은 둘 다 고칩니다. 상반구를 단위 정사각형 위로 연속적으로 매핑하기 때문에 인접한 3D 방향이 인접한 UV에 떨어지고, 극점 특이점도 없고 특수한 탑다운 타일도 필요 없습니다. 깜빡임의 처방은 양선형 셀 블렌딩입니다. 가장 가까운 타일로 스냅하는 대신, 인코딩된 방향을 감싸는 2×2 타일 묶음을 찾아 넷 모두를 블렌딩합니다. 텍스처 탭은 총 8회입니다(디퓨즈 4, 노멀 4). 인접한 시점들이 이제 팝 대신 크로스페이드합니다. 두 단위 벡터의 노멀 블렌드 자체는 단위 길이가 아니라서 다시 정규화하는데, 이웃 타일 사이의 작은 각도에 대해서는 slerp처럼 동작합니다. 비용은 실제로 듭니다(12×12 아틀라스는 약 9 MB로 az/el의 1.6 MB와 비교되고, 베이크는 288개 렌더 타깃 패스에서 대략 5배 더 오래 걸립니다). 하지만 베이크는 로드 시 한 번뿐이고, 블렌딩은 팝 없는 결과를 사 줍니다. 이게 바로 카메라가 실제로 움직이는 동안 임포스터를 쓸 만하게 만드는 것입니다.

나무 백만 그루, 프레임당 카메라 위치 복사 한 번

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

Spike 38의 런타임은 프레임마다 quad마다 CPU lookAt을 한 번 합니다. 나무 한 그루엔 괜찮지만 숲엔 치명적입니다. 나무 백만 그루면 프레임당 행렬 갱신과 인스턴스 버퍼 업로드가 모든 걸 압도합니다. Spike 41은 프레임당 파이프라인 전체를 GPU로 옮깁니다. 각 인스턴스의 중심, 요(yaw), 스케일은 빌드 시점에 인스턴스 attribute로 한 번 업로드되고 다시는 바뀌지 않습니다. 버텍스 셰이더는 월드 공간 시점 방향 camPos − center에서 빌보드 기저를 만들고 공유된 단위 quad를 월드 공간으로 펼칩니다. 프래그먼트 셰이더는 픽셀마다 헤미옥타헤드럴 인코딩과 양선형 블렌드를 합니다. 숲 전체에서 프레임당 유일한 CPU 작업은 카메라 위치 uniform을 갱신하는 Vector3.copy 한 번이고, 이건 나무 수에 전혀 비례하지 않습니다.

수학에서 멋진 한 부분은 인스턴스별 요가 노멀 디코드에서 상쇄된다는 것입니다. 베이크는 노멀을 베이크 카메라의 프레임에 저장하는데, 월드 업 축 둘레의 요 회전이 +Y를 보존하고 외적이 회전 등변이기 때문에, 월드 업 기준으로 만든 런타임 기저는 이미 회전된 베이크 기저와 같습니다. 그래서 셰이더는 인스턴스별 요를 전혀 건드리지 않고 런타임 기저 varying을 통해 노멀을 그대로 디코드합니다. 배치는 순수 랜덤 스캐터가 아니라 지터링된 격자를 씁니다. 영역을 셀로 나누고 셀마다 중심에 경계가 있는 오프셋을 더해 나무 하나를 떨어뜨리는데, 이렇게 하면 최소 간격이 보장되어(두 나무가 겹치지 않음) 동시에 여전히 자연스러운 숲으로 읽힙니다. 놓치기 쉬운 한 가지 디테일은 바운딩 스피어입니다. 지오메트리 템플릿은 그냥 단위 quad라서, 카메라가 원점에서 다른 방향을 보는 순간 three.js가 숲 전체를 프러스텀 컬링해 버립니다. 전체 영역에 quad 한 개분의 여유를 더해 덮는 명시적 바운딩 스피어를 설정하면 모서리의 나무들이 비스듬한 각도에서 잘려 나가지 않습니다.

이 장에서 다룬 기술

옥타헤드럴 및 방위각-고도각 임포스터 아틀라스. 임포스터는 프롭을 시점 방향 격자에서 디퓨즈 아틀라스 하나와 월드 공간 노멀 아틀라스 하나로 구운 뒤, 맞는 타일을 샘플링하는 단일 빌보드를 렌더링해 삼각형 수천 개를 두 장의 텍스처로 대체합니다. 교과서적인 옥타헤드럴 매핑은 균일한 구면 커버리지를 주지만 폴딩 경계에서 CPU/GPU가 어긋나기 쉽습니다. 단순한 방위각 곱하기 고도각 격자는 덜 균일한 구면을 샘플링하지만 구조적으로 셀 선택기와 셰이더가 일치하도록 보장합니다. 홀수 N을 써서 한 행이 정확히 0° 고도각에 떨어지게 하고, 프롭은 대부분 눈높이에서 보이므로 타일 예산을 수평 링에 쓰세요.

구간별 정적 빌보드 방향. 임포스터는 특정 베이크 방향에서 찍은 사진이라서 런타임 quad의 이미지 평면이 런타임 카메라를 계속 향하는 게 아니라 베이크 카메라의 평면과 맞아야 합니다. quad는 한 셀이 선택된 채 유지되는 호 구간 동안 방향을 유지하다가 경계에서 스냅하는데, 이건 임포스터 거리에서는 보이지 않고 임포스터를 쓰지 않는 가까운 거리에서만 튑니다.

양선형 셀 블렌드를 적용한 헤미옥타헤드럴 아틀라스. 상반구를 단위 정사각형 위로 연속적으로 매핑하면 극점 특이점과 특수한 탑다운 타일이 사라집니다. 스냅은 인코딩된 시점 방향을 감싸는 2×2 타일 묶음을 샘플링해 넷 모두를 양선형 블렌딩(8 탭)함으로써 없애므로 인접한 시점들이 크로스페이드합니다. 블렌딩된 노멀은 다시 정규화되어 타일 간의 작은 각도에 대해 slerp를 근사합니다. 비용은 더 큰 아틀라스(12×12에서 약 9 MB)와 더 긴 일회성 베이크이고, 그 대가로 카메라 움직임 아래에서 팝 없는 셰이딩을 얻습니다.

GPU 구동 인스턴스화 임포스터. 인스턴스별 중심, 요, 스케일은 인스턴스 attribute로 한 번 업로드됩니다. 버텍스 셰이더는 빌보드 기저를 만들고 공유된 단위 quad를 펼치며, 프래그먼트 셰이더는 픽셀마다 인코딩과 블렌딩을 합니다. 숲 전체에 대한 프레임당 CPU 비용은 카메라 위치 uniform 복사 한 번이고 인스턴스 수와 무관합니다. 인스턴스별 요는 노멀 디코드에서 상쇄되는데, 월드 업 둘레의 요가 외적 기저 구성에 의해 보존되기 때문입니다. 명시적인 숲 전역 바운딩 스피어는 카메라가 단위 quad 템플릿의 원점에서 다른 방향을 볼 때 three.js가 인스턴스화 메시 전체를 프러스텀 컬링하는 것을 막습니다. GPU 구동 LOD를 보세요.

29부 중 19부. 이전: 18부 - AI가 배치한 듯한 스캐터 브러시 다음: 20부 - 평평한 면에서 깊이 속이기 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

몇 주 전에 현대 AAA 게임이 실제로 출시하는 렌더링 기법에 대해 썼습니다. 그때 얇게 다루고 넘어간 영역 하나가 하늘과 날씨인데, 따로 한 편으로 다룰 만한 주제이기 때문입니다. 구름, 안개, 비, 눈은 지형 데모를 하나의 장소로 바꿔주는 시스템입니다. 그리고 이들은 보기보다 훨씬 많은 코드를 공유합니다. 볼류메트릭 구름, 지면 안개, 갓 레이는 모두 같은 레이 마칭입니다. 젖은 도로, 눈 쌓임, 발자국 흔적은 모두 같은 변위 더하기 PBR 기법입니다. 바람은 장면 안의 모든 것이 읽어 들이는 하나의 방향 벡터입니다.

여기 2026년에 큰 스튜디오들이 이걸 어떻게 만드는지에 대한 짧고 주관적인 둘러보기를 준비했습니다. 각 요소 뒤에 있는 논문과 엔진 발표 자료도 함께 실었습니다.

1. 물리 기반 하늘과 대기

대기 산란이 기초입니다. 하늘의 색, 지평선의 아지랑이, 먼 산이 파랗게 보이는 이유, 해 질 녘의 주황빛, 이 모든 것이 공기를 통과하는 빛의 산란에서 나옵니다. 현대 엔진은 이걸 물리에서 계산합니다. 파란색을 만드는 레일리 산란, 태양 주위의 아지랑이를 만드는 미 산란, 천정의 짙은 보라색을 만드는 오존 흡수가 그것입니다.

원래 2008년 Bruneton 방식은 모든 것을 4D 룩업 테이블에 미리 구워 넣었는데, 이 때문에 동적 시간 변화가 제약을 받았고 낮은 태양 각도에서 LUT 아티팩트가 생겼습니다. Sébastien Hillaire의 2020년 업데이트는 (UE5의 Sky Atmosphere 컴포넌트가 쓰는 바로 그것입니다) 고차원 LUT를 몇 장의 2D 텍스처와 프레임마다 갱신되는 다중 산란 근사로 대체했습니다. 휴대폰부터 고사양 PC까지 다 돌아갑니다.

자세히 보기:

• Hillaire, A Scalable and Production Ready Sky and Atmosphere Rendering Technique (EGSR 2020, 현대 표준이며 UE5에서 사용).
• Bruneton, Neyret, Precomputed Atmospheric Scattering (EGSR 2008, 원래의 LUT 접근).
• Bruneton, Precomputed Atmospheric Scattering: a New Implementation (오픈소스 참조 구현, 오존과 다중 행성 지원).
• Epic Games, Sky Atmosphere Component (UE5 문서).

2. Perlin-Worley 노이즈로 만드는 볼류메트릭 구름

현대 게임 볼류메트릭 구름의 기초 기법은 Andrew Schneider의 2015년 Horizon Zero Dawn 발표에서 시작됐습니다. 구름은 메시가 아닙니다. 구름은 계층화된 노이즈로 정의된 3D 밀도 함수입니다. 저주파 Perlin-Worley 혼합이 구름의 전체 형태를 만들고, 더 높은 주파수의 Worley 노이즈가 실루엣을 침식해 얇게 흩날리는 가장자리를 만듭니다. 날씨 맵(월드 XZ로 샘플링하는 2D 텍스처)이 지역별로 구름 양, 구름 종류, 강수를 제어합니다. 높이 기반 그래디언트가 고도에 따라 적운, 층운, 권운 프로파일 사이를 블렌딩합니다.

렌더러는 카메라에서 구름 볼륨을 가로질러 레이를 진행시키며 밀도와 산란을 누적합니다. 2017년의 "Nubis" 버전은 지역 규모의 저작과 애니메이션을 추가했고, 원래의 PS4 구현은 하늘 전체를 약 2ms에 처리했습니다. 오늘날 볼류메트릭 구름을 출시하는 대부분의 스튜디오는 여전히 그 혈통이 이 논문으로 거슬러 올라갑니다.

자세히 보기:

• Schneider, The Real-Time Volumetric Cloudscapes of Horizon Zero Dawn (SIGGRAPH 2015, 정전이라 할 만한 참고 자료).
• Schneider, Nubis: Authoring Real-Time Volumetric Cloudscapes with the Decima Engine (SIGGRAPH 2017, 지역 규모 후속편).
• Hillaire, Physically Based Sky, Atmosphere and Cloud Rendering in Frostbite (SIGGRAPH 2016, Frostbite 버전).
• Häggström, Real-time rendering of volumetric clouds (전체 셰이더 코드가 담긴 깔끔하고 접근하기 쉬운 논문).

3. 복셀 구름과 Nubis³

2023년의 Nubis 진화 버전은 2.5D 형상 표현을 완전히 버리고 진정한 3D 복셀을 택했습니다. 각 복셀이 구름 밀도를 직접 저장하므로, 아티스트가 지형을 조각하듯 구름 형태를 깎고 애니메이션할 수 있습니다. 더 조밀한 표현으로 옮겨가는 비용은, 압축된 부호 거리 필드를 이용한 레이 마칭 가속과 희소 복셀 데이터의 영리한 업레저로 되갚습니다.

그 결과는 기저의 트릭이 무너지는 게 보이지 않는 채로 통과해 날아다닐 수 있는 구름 풍경입니다. 대부분의 스튜디오에는 과한 수준이지만, 최상위가 향하고 있는 방향이기는 합니다.

자세히 보기:

• Schneider, Nubis³: Methods (and madness) to model and render immersive real-time voxel-based clouds (SIGGRAPH 2023, 복셀 구름 발표).
• Schneider, Nubis, Evolved (SIGGRAPH 2022, 2.5D와 완전한 3D 사이의 다리).
• Schneider, Real-time Volumetrics and VFX (Andrew의 개인 사이트, 강의 노트와 분석 포함).

4. 계층형 구름 렌더링과 2D 배경

모든 스튜디오가 풀 볼륨 구름을 감당할 수 있는 건 아니고, 모든 카메라 각도가 그걸 필요로 하는 것도 아닙니다. 많은 게임이 기법을 조합합니다. 고고도 권운은 스크롤하는 2D 레이어로, 중고도 적운은 볼류메트릭 레이로, 저고도 층운은 얇은 참여 매질 슬래브로 렌더링합니다. 지평선은 종종 미리 구워둔 하늘 큐브맵을 받고, 볼류메트릭 패스가 페이드 거리 너머에서 거기로 블렌딩됩니다.

이 계층화가 구름 예산을 정직하게 유지해 줍니다. 풀 퀄리티의 단일 구름 종류는 4~6ms를 먹어버릴 수 있는데, 구름 고도별로 서로 다른 퀄리티를 계층화하면 절반의 비용으로 같은 룩을 유지할 수 있습니다.

자세히 보기:

• Vos, The Real-Time Volumetric Cloudscapes of Horizon Zero Dawn (GDC 2016 영상, 계층화 분석은 후반부에).
• Bauer, Creating the Atmospheric World of Red Dead Redemption 2 (SIGGRAPH 2019, RDR2의 하늘/구름/볼류메트릭 통합 파이프라인).
• Hillaire, Volumetric clouds and mega particles in REDengine 4 (GDC 2025, Cyberpunk 2077의 구름 파이프라인).

5. 프록셀 그리드를 쓰는 볼류메트릭 안개

안개는 2D 화면 효과가 아니라 3D 필드입니다. 현대의 표준 접근은 프록셀 그리드입니다. 카메라 뷰 프러스텀에 정렬된 3D 텍스처로, 각 셀("froxel" = frustum + voxel)이 밀도와 조명된 색을 저장합니다. 컴퓨트 셰이더가 모든 광원으로부터 산란을 그리드에 주입하고, 뷰 레이를 따라 소광을 누적한 다음, 그 결과를 전체 화면 패스로 적용합니다.

이게 창문을 통과하는 광선, 점 광원 주위의 색깔 있는 안개, 폭발 주변의 보이는 볼륨을 만들어 줍니다. 또한 먼 물체를 공기 속으로 흐려지게 하는 "대기 원근"의 기반 기계장치이기도 합니다. 이 기법은 Assassin's Creed 4를 위해 Bart Wronski가 도입했고 Sébastien Hillaire가 Frostbite에서 표준화했습니다.

자세히 보기:

• Wronski, Volumetric Fog: Unified Compute Shader Based Solution to Atmospheric Scattering (SIGGRAPH 2014, 원래의 프록셀 그리드 논문).
• Hillaire, Physically Based and Unified Volumetric Rendering in Frostbite (SIGGRAPH 2015, 프로덕션 수준 구현).
• Kovalovs, Volumetric Effects of The Last of Us Part Two (SIGGRAPH 2020, 시간적 지터와 깊이 정합 합성에 대한 노트 포함).
• Wright et al., Lumen: Real-Time Global Illumination in Unreal Engine 5 (SIGGRAPH 2022, Lumen과 볼류메트릭 안개의 상호작용 포함).

6. 갓 레이와 박명 광선

안개 낀 공기 속에 보이는 햇살 광선은 별개의 효과가 아닙니다. 안개 밀도와 섀도 맵이 둘 다 같은 컴퓨트 셰이더에 제공되기만 하면, 같은 안개 시스템에서 자연스럽게 떨어져 나옵니다. 셰이더가 프록셀에 빛을 주입할 때, 그 프록셀의 월드 위치에서 섀도 맵을 샘플링합니다. 그림자 속 셀은 어둡게 유지되고, 빛 속 셀은 태양 색을 받아들입니다. 그 결과를 따라 카메라 레이를 진행시키면 밝은 셀들이 연속된 광선을 이룹니다.

더 저렴한 스크린 공간 변형(태양 위치에서 깊이 버퍼로의 방사형 블러)도 존재하고, 모바일이나 저사양 하드웨어에서는 여전히 올바른 선택입니다. 화면 밖 태양 위치는 놓치지만 비용이 거의 들지 않습니다.

자세히 보기:

• Mitchell, Volumetric Light Scattering as a Post-Process (GPU Gems 3, 스크린 공간 방사형 블러 접근).
• Engelhardt, Dachsbacher, Epipolar Sampling for Shadows and Crepuscular Rays in Participating Media (I3D 2010, 더 정확한 GPU 기법).
• Vos, Volumetric Light Effects in Killzone: Shadow Fall (SIGGRAPH 2014, 그림자 통합을 포함한 프로덕션 버전).

7. 번개와 확률적 날씨 이벤트

번개는 두 부분으로 이루어진 한 프레임짜리 효과입니다. 번개 줄기 메시, 그리고 장면 전체의 톤매핑과 조명 반응입니다. 줄기 자체는 보통 재귀적 선분 분할 알고리즘으로 만든 절차적 빌보드 메시로, 혼돈을 위해 지터를 주고 땅 쪽으로 갈수록 가늘어지게 합니다. 어떤 엔진은 이걸 스크린 공간 가산 섬광으로 렌더링하고, 어떤 엔진은 한 프레임짜리 점 광원 주입을 통해 세계에 빛을 드리우는 완전히 조명된 발광 지오메트리로 렌더링합니다.

흥미로운 부분은 그 나머지 전부입니다. 구름 밑면이 아래에서부터 밝아지고, 땅이 두 프레임 동안 밝아지며, 자동 노출 측광이 회복하는 데 몇 프레임이 걸리고, 거리에 따라 지연된 천둥 큐가 재생됩니다. 잘하면, 이게 16ms짜리 섬광을 5초짜리 시퀀스로 바꿔서, 날씨를 그저 위에서 일어나는 것이 아니라 세계 안에서 일어나는 무언가로 느끼게 합니다.

자세히 보기:

• Reed, Wyvill, Visual Simulation of Lightning (SIGGRAPH 1994, 다들 여전히 쓰는 재귀적 번개 줄기 알고리즘).
• Kim, Lin, Fast Animation of Lightning Using an Adaptive Mesh (IEEE TVCG 2007, 더 물리적으로 뒷받침된 방식).
• Bauer, Creating the Atmospheric World of Red Dead Redemption 2 (SIGGRAPH 2019, 번개 타이밍을 포함한 RDR2의 폭풍 파이프라인).

8. 비 파티클, 비 메시, 스크린 공간 빗방울

현대 게임의 떨어지는 비는 단순한 파티클인 경우가 드뭅니다. 저렴하면서도 설득력 있는 해법은, 수직이나 화면 정렬 쿼드에 걸쳐 늘인 소수의 스크롤 텍스처를 다른 모든 것과 같은 태양 및 하늘 프로브로 조명하는 것입니다. 카메라에 더 가까운 곳에서는 개별 줄무늬 파티클이 디테일을 더합니다. 카메라 렌즈 그 자체 위에서는, 물방울 텍스처, 흘러내리는 흔적, 충돌 잔물결이 "당신은 폭풍 속에 있다"는 느낌을 살려 줍니다.

바람이 비의 방향에 영향을 줍니다. 같은 바람 벡터가 구름 날씨 맵을 밀고, 풀을 휘게 하며, 비 쿼드를 기울입니다. 장면 전체에 걸친 하나의 벡터, 수십 개의 소비자입니다.

자세히 보기:

• Tatarchuk, Artist-Directable Real-Time Rain Rendering in City Environments (EGSR 2006, 정전이라 할 만한 계층형 비 참고 자료).
• Garg, Nayar, Photorealistic Rendering of Rain Streaks (SIGGRAPH 2006, 빗방울을 통과하는 빛의 물리).
• Wojciechowski, Rain in Cyberpunk 2077 (GDC 2021, 현대 프로덕션 둘러보기).

9. 젖은 표면, 물웅덩이, 잔물결

땅을 바꾸지 않는 비는 곧바로 가짜처럼 보입니다. 젖은 표면은 알베도를 어둡게 하고(물이 들어오는 빛을 흡수), 노멀을 평탄하게 하며(물의 막이 미세 표면을 매끄럽게 함), 거칠기를 낮춰서(물은 스치는 각도에서 거의 완벽한 거울임) 반응합니다. 셰이더 변경은 작지만, 시각적 변화는 큽니다.

물웅덩이는 마스크 기반입니다. 높이 기반 또는 버텍스 페인트 마스크가 "젖음" 파라미터가 올라감에 따라 물이 차오르는 낮은 지점을 정의합니다. 잔물결은 빗방울 충돌로 트리거되는 플립북 노멀 맵 텍스처입니다. 정말 좋은 구현은 젖음 상태를 시간에 걸쳐 쌓아 올려서, 긴 폭풍우는 세계를 천천히 적시고 잠깐의 소나기는 높은 지점만 어둡게 만듭니다.

자세히 보기:

• Lagarde, de Rousiers, Moving Frostbite to Physically Based Rendering 3.0, section 5.5 (SIGGRAPH 2014, 정전이라 할 만한 젖은 표면 PBR 조정).
• Lagarde, Adopting a Physically Based Shading Model (젖은 PBR 수학이 담긴 원래의 블로그 시리즈).
• Cyanilux, Rain Effects Breakdown (물웅덩이, 잔물결, 물방울에 대한 접근하기 쉬운 Shader Graph 둘러보기).

10. 눈 쌓임과 변형

눈은 비와 대칭을 이루는 문제입니다. 세계가 눈을 그저 받기만 하는 게 아니라 기억해야 합니다. 표준 접근은 하늘이 보이는 곳마다 시간에 걸쳐 쌓이는 위에서 내려다본 "눈 쌓임" 텍스처를 씁니다(위에서 내려다본 깊이 또는 섀도 맵에 대해 계산). 지형 셰이더가 이 마스크를 샘플링해서, 가려진 영역에는 눈 머티리얼을, 노출된 영역에는 깊은 눈 변위를 블렌딩합니다.

발자국과 타이어 자국은 플레이어를 중심으로 한 슬라이딩 변형 맵에 렌더링됩니다. 카메라가 움직이면 오래된 발자국은 밖으로 스크롤되고 텍스처가 둘러 감깁니다. 지형이나 눈 셰이더가 이 변형 맵을 샘플링해서, 기록된 곳의 버텍스를 아래로 밀어 넣습니다. Battlefield 5의 눈은 이걸 하드웨어 테셀레이션으로 합니다. 더 저렴한 접근은 버텍스 변위만 쓰는 고밀도 지형 메시를 씁니다.

자세히 보기:

• Barré-Brisebois, Hands-on with Battlefield 5: how the small things matter (Frostbite 눈의 프로덕션 정리).
• St-Amour, Real-time snow deformation (전체 GPU 구현 세부 사항이 담긴 논문).
• Andersson, Terrain Rendering in Frostbite Using Procedural Shader Splatting (눈 쌓임이 그 위에 올라타는 스플랫 시스템 기반).

11. 전역 시스템으로서의 바람

바람은 파티클 효과가 아닙니다. 프로덕션 엔진에서는 모든 동적 시스템이 자신의 버텍스 셰이더에서 읽어 들이는 하나의 전역 벡터(때로는 저해상도 3D 필드)입니다. 풀잎이 휘고, 나뭇가지가 흔들리고, 천이 펄럭이고, 나뭇잎이 떠다니고, 비가 기울고, 연기가 이류하고, 구름 날씨 맵이 스크롤합니다. 프레임마다 갱신되는 하나의 유니폼, 수십 개의 소비자입니다.

더 풍부한 버전은 월드 위치로 샘플링한 방향과 세기를 저장하는 "바람 그리드"로, 국소적인 돌풍이 부는 폭풍, 바람을 막아주는 골짜기, 건물 뒤의 후류를 가능하게 합니다. 식생은 또한 보통 저작 시점에 구워진 버텍스별 오프셋을 받아서, 똑같은 나무들이 발맞춰 흔들리지 않게 합니다. 그 결과는 같은 박자로 숨 쉬는 세계입니다.

자세히 보기:

• McAuley, Rendering the World of Far Cry 4 (GDC 2015, Far Cry 4의 식생용 바람 그리드 포함).
• Habel, Wimmer, Realistic Real-Time Rendering of Landscapes Using Billboard Clouds (오래됐지만 식생에 대한 바람 수학은 그대로).
• Frostbite, The Vegetation of Horizon Zero Dawn (SIGGRAPH 2017, 바람 시스템 아키텍처 포함).

12. 모래폭풍, 눈보라, 짙은 날씨

험한 날씨는 그 자체로 하나의 렌더링 범주입니다. 모래폭풍은 강한 방향 편향과 공격적인 거리 안개를 가진, 두껍고 불투명하며 지면에 정렬된 안개입니다. 눈보라는 카메라 근처 파티클 폭발과 줄어든 가시성을 더합니다. 화산재와 연기는 색만 다른 같은 아키텍처입니다.

이걸 살려 주는 것은 파티클이 아니라 연동입니다. 태양이 어두워지고, 하늘이 물들고, 후처리 컬러 그레이딩이 바뀌고, 환경음이 교체되고, 발소리가 달라지고, 플레이어에게 음성이 있다면 그 음성이 먹먹해집니다. 렌더러는 전령일 뿐이고, 몰입은 게임의 모든 시스템이 동시에 반응하는 데서 옵니다.

자세히 보기:

• Burley, The Real-Time Sky and Atmosphere of Uncharted: The Lost Legacy (GDC 2018, 짙은 날씨 합성에 대한 노트 포함).
• Khalifa, Atmospheric Weather Effects in Forza Horizon 5 (GDC 2022, 현대 오픈월드 날씨).
• Karis, The Technology Behind the Unreal Engine 5 "Lumen in the Land of Nanite" Demo (SIGGRAPH 2021, 동굴 먼지 장면의 볼류메트릭 스택).

13. 하루의 시간대와 동적 하늘

실시간 하루 시간대는 이 목록의 다른 모든 시스템을 출시할 가치가 있게 만들어 주는 곱셈 인자입니다. 태양 방향과 색이 24분 또는 24시간 주기에 걸쳐 갱신됩니다. 대기 LUT가 태양 각도에 따라 갱신됩니다. 구름 조명이 프레임마다 재계산됩니다. 섀도 캐스케이드가 다시 가리킵니다. 반사 프로브가 새로고침됩니다. 환경광 색이 바뀝니다. 후처리 노출이 적응합니다.

이걸 눈에 띄는 아티팩트 없이 해내는 것은 대체로 텍스처 캐싱과 시간적 안정성에 관한 이야기입니다. 빠른 기법은 고정된 태양 각도에서 하늘을 미리 계산하고 보간합니다. 느린 기법은 매 프레임 재계산합니다. Hillaire 2020 대기 모델은 재계산할 만큼 충분히 빠른데, 그래서 UE5가 그걸 채택했습니다. 구름 날씨 맵은 바람을 따라 스크롤하므로, 아무도 키프레임을 저작하지 않아도 구름 양이 자연스럽게 바뀝니다.

자세히 보기:

• Hillaire, A Scalable and Production Ready Sky and Atmosphere Rendering Technique (EGSR 2020, 동적 하루 시간대 논의 포함).
• Pesce, Real-Time Sky Rendering: Techniques and Tradeoffs (Ray Tracing Gems II 챕터, 현대적 개관).
• Bauer, Creating the Atmospheric World of Red Dead Redemption 2 (SIGGRAPH 2019, 24시간 파이프라인 포함).

14. 날씨 상태 머신

이 모든 것의 밑바닥에는 작은 상태 머신이 있습니다. 대부분의 게임은 4개에서 12개 사이의 날씨 상태(맑음, 부분적으로 흐림, 잔뜩 흐림, 약한 비, 강한 비, 뇌우, 안개, 눈, 눈보라, 모래폭풍)를 출시하고, 각각은 한 묶음의 파라미터로 정의됩니다. 구름 양과 종류, 풍속과 풍향, 강수 종류와 강도, 환경광 색조, 오디오 프로파일, 후처리 그레이드가 그것입니다.

전환은 30초에서 120초에 걸쳐 파라미터 묶음 사이를 선형 보간한 것입니다. 전환은 특수한 경우가 아니라, 그저 두 상태가 보간되는 것이며, 각 렌더링 하위 시스템이 그 프레임의 현재 파라미터 값을 읽습니다. 날씨는 스크립트로 짜일 수도 있고(컷신에 폭풍이 필요함), 시드로 정해질 수도 있고(지역별 게임 내 하루마다 결정적이어서 같은 세계의 두 플레이어가 같은 날씨를 봄), 지역 그리드에 완전히 저작될 수도 있습니다. 가장 깔끔한 파이프라인은 이 셋 모두를, 같은 파라미터 버퍼에 기록하는 서로 다른 스케줄러로 다룹니다.

자세히 보기:

• Bauer, Creating the Atmospheric World of Red Dead Redemption 2 (SIGGRAPH 2019, 날씨 상태 파이프라인 포함).
• Khalifa, Atmospheric Weather Effects in Forza Horizon 5 (GDC 2022, 파라미터 블렌드 접근 포함).
• Schneider, The Real-Time Volumetric Cloudscapes of Horizon Zero Dawn (SIGGRAPH 2015, 날씨 맵 기반 구름 진화 포함).

15. 영화적인 순간들

이 모든 스택은 몇몇 상징적인 순간을 위해 존재합니다. 폭풍 전선이 밀려올 때 능선 위에 서 있는 것. 숲지붕 사이 빈 곳을 햇살 광선이 태우며 지나가는 것을 바라보는 것. 동굴에서 나와 눈 속으로 걸어 들어가는 것. 적운 속을 날아 통과하며 그 안쪽의 빛을 보는 것.

이런 것들이 플레이어가 스크린샷을 찍는 순간입니다. 또한 위의 모든 시스템이 동시에 작동해야 하는 순간이기도 합니다. 구름 볼류메트릭, 대기 산란, 그림자 통합 안개, 젖은 PBR, 식생에 부는 바람, 하루 시간대 컬러 그레이딩, 그리고 날씨 상태 사이의 전환이 모두 하나의 프레임으로 합성됩니다. 이 중 하나라도 틀리면 마법이 깨집니다.

이것이 브라우저에 의미하는 것

이 기법들 대부분은 WebGPU로 깔끔하게 옮겨집니다. 우리는 오픈월드 브라우저 엔진에 기본 대기 안개, 등장방형 스카이박스 블렌딩, 스크린 공간 거리 아지랑이를 이미 출시했습니다. 더 어려운 부분(풀 볼류메트릭 구름, 프록셀 그리드 안개, 동적 물웅덩이가 있는 젖은 PBR, 눈 변형 맵)은 지형 파이프라인이 안정된 지금 명백한 다음 단계입니다. Spike 24의 스카이박스에서 프래그먼트별 안개 색을 샘플링하는 것이 이 퍼즐의 한 조각입니다. 같은 대기 LUT로 흘러 들어가는 컴퓨트 셰이더 구름 레이마처가 그다음입니다.

좋은 소식은 이제 브라우저 하드웨어의 하한선이 충분히 높아졌다는 것입니다. WebGPU 컴퓨트, 3D 텍스처, 간접 디스패치, 타임스탬프 쿼리가 모두 존재합니다. Hillaire 2020 대기는 WebGL로 여러 번 포팅됐습니다. Schneider의 Nubis는 GLSL 오픈소스 참조 구현이 있고, 이는 기계적인 수정만으로 WGSL로 옮겨집니다. 이제 브라우저 게임이 콘솔 게임과 같은 하늘을 가질 수 없는 렌더링상의 이유는 없습니다. 엔지니어링상의 이유만 있을 뿐이고, 엔지니어링상의 이유는 우리가 좋아하는 종류입니다.

스택 전체를 아우르는 더 읽을거리

이 모든 것을 한데 묶어주는 한 가지 출처를 원한다면, SIGGRAPH "Advances in Real-Time Rendering in Games" 아카이브(advances.realtimerendering.com)에 2014년까지 거슬러 올라가는 정전이라 할 만한 날씨와 대기 발표 자료가 있습니다. 특정 게임이 하늘과 날씨를 어떻게 렌더링하는지에 대한 프로덕션 분해는 Adrian Courrèges의 GPU 프로파일링 글에 GTA V, Horizon Zero Dawn, Doom Eternal의 프레임 단위 상세 분석이 담겨 있습니다. 하늘과 대기 수학 자체에 관해서는 scratchapixel.com의 볼륨 렌더링 챕터가 가장 부드러운 입문서이고, Hillaire의 오픈소스 구현 저장소가 프로덕션 품질의 참조입니다.

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

2026년 AAA 게임의 렌더링 파이프라인을 열어보면, 거기 들어있는 것들 대부분은 여러 스튜디오에 두루 쓰이는 한 줌의 기법으로 거슬러 올라갑니다. 엔진마다 이름은 달라도 아이디어는 같습니다. 화면에서 실제로 일을 하고 있는 기법들을 짧게 정리하고, 항목마다 그림 한 장과 깊이 있는 기술 레퍼런스 몇 개를 붙였습니다.

1. 물리 기반 렌더링 (PBR)

머티리얼은 albedo, roughness, metallic, normal, ambient occlusion 텍스처로 기술되고, 에너지 보존 셰이더(Cook-Torrance specular, Lambertian 또는 Disney diffuse)로 조명됩니다. 모든 최신 AAA 엔진이 전제로 깔고 가는 기준선입니다. 표면 하나가 햇빛 아래에서도, 램프 빛 아래에서도, 손전등 아래에서도 일관되게 보인다면 그건 PBR 덕분입니다.

더 깊이 보기:

• Burley, Physically-Based Shading at Disney (최초의 "Disney BRDF" 강의 노트, SIGGRAPH 2012).
• Karis, Real Shading in Unreal Engine 4 (SIGGRAPH 2013, UE4 PBR의 정석 같은 발표).
• Lagarde and de Rousiers, Moving Frostbite to Physically Based Rendering 3.0 (SIGGRAPH 2014, Frostbite 파이프라인 전체).
• Real-Time Rendering, 4th edition, chapter 9 (교과서 수준의 참고서).

2. 디퍼드 셰이딩과 비저빌리티 버퍼 셰이딩

지오메트리 단계가 먼저 속성(노멀, 머티리얼 ID, 깊이)을 G-buffer나 visibility buffer에 씁니다. 조명은 그 버퍼들을 읽어 각 픽셀을 한 번만 셰이딩하는 풀스크린 패스로 돌아갑니다. Visibility buffer(Nanite 등이 쓰는 방식)는 여기서 한 발 더 나아가, 삼각형 ID만 저장하고 머티리얼 파라미터는 나중에 픽셀별로 풀어냅니다. 덕분에 밀도 높은 지오메트리에서도 오버드로 비용이 저렴하게 유지됩니다.

더 깊이 보기:

• Engel, Deferred Shading (NVIDIA, 토대가 된 발표).
• Burns and Hunt, The Visibility Buffer: A Cache-Friendly Approach to Deferred Shading (JCGT 2013, 최초의 visibility buffer 논문).
• Wihlidal, "Optimizing the Graphics Pipeline with Compute" (GDC 2016, Frostbite의 compute 기반 디퍼드 경로).
• Karis, Stubbe, Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021, Nanite의 visibility buffer를 상세히 다룸).

3. 가상화 지오메트리 (Nanite 스타일)

메시는 클러스터 계층으로 미리 빌드됩니다. 런타임에 GPU가 각 픽셀에 맞는 해상도로 클러스터를 스트리밍하고 선택하기 때문에, 수동 LOD 없이도 서브픽셀 정밀도의 디테일을 얻습니다. Unreal의 Nanite가 가장 눈에 띄는 예입니다. 다른 엔진들도 이제 자체 변형판을 내놓고 있습니다. 실제 결과는 LOD 작업 없이도 영화 품질의 에셋을 실시간으로 돌리는 것입니다.

더 깊이 보기:

• Karis, Stubbe, Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021).
• Brian Karis, Nanite GDC 2021 talk (이해하기 쉬운 영상 설명).
• Liktor, Geometry Rendering Pipeline Architecture at Activision (클러스터 기반 렌더링, 2021).
• Schied et al., Spatiotemporal Variance-Guided Filtering (관련된 클러스터 컬링 기법).

4. 그림자, 반사, AO를 위한 실시간 레이 트레이싱

하드웨어 레이 트레이싱(DXR, Vulkan RT)은 매 프레임 빌드되는 BVH에 대해 그림자 광선, 미러 및 글로시 반사 광선, ambient occlusion 광선을 쏩니다. 픽셀당 광선이 몇 개에 불과해도 스크린 스페이스 기법이 할 수 있는 것보다 낫습니다. 특히 화면 밖 반사와 접촉 그림자에서 그렇습니다. 대부분의 게임은 이걸 모든 곳에 쓰지 않고 꼭 필요한 데만 외과적으로 씁니다.

더 깊이 보기:

• Microsoft, DirectX Raytracing (DXR) Functional Spec (API 레퍼런스).
• Wyman, Introduction to DirectX Raytracing (SIGGRAPH 강의 노트, 아주 접근하기 쉬움).
• Boksansky and Marrs, Ray Tracing Gems II, chapters 17-19 (무료 PDF, 최신 DXR 기법).
• Stachowiak, Stochastic Screen-Space Reflections (Frostbite, SSR에서 RT로 넘어가는 다리).

5. 소프트웨어 레이 트레이싱 (Lumen 스타일)

모든 플레이어가 RTX 카드를 가진 건 아니기 때문에, 엔진은 distance field나 surface cache 폴백도 함께 제공합니다. 예를 들어 Unreal의 Lumen은 signed distance field와 surface cache에 대해 트레이싱해 저렴한 diffuse GI를 얻고, 필요할 때만 하드웨어 광선으로 격상합니다. AAA 게임이 콘솔에서 "레이 트레이싱 같은 모습"을 내는 방식이 바로 이것입니다.

더 깊이 보기:

• Wright et al., Lumen: Real-Time Global Illumination in Unreal Engine 5 (SIGGRAPH 2022, Lumen 논문).
• Epic Games, Lumen Technical Details (공식 엔진 문서).
• Wright, Radiance Caching for Real-Time Global Illumination (SIGGRAPH 2021).
• Wright, Lumen GDC 2022 talk (영상 버전).

6. ReSTIR과 reservoir 샘플링

수천 개의 광원이 있는 직접 및 간접 조명에서는 ReSTIR(Reservoir Spatio-Temporal Importance Resampling)이 픽셀과 프레임 사이에서 광원 샘플을 재사용합니다. Cyberpunk 2077의 패스 트레이싱 같은 게임이 픽셀당 광선 한두 개로도 노이즈를 낮게 유지하는 방법입니다. 패스 트레이싱이 고사양 목표가 되면서 더 많은 엔진에서 보게 될 겁니다.

더 깊이 보기:

• Bitterli et al., Spatiotemporal Reservoir Resampling for Real-Time Ray Tracing with Dynamic Direct Lighting (SIGGRAPH 2020, 최초의 ReSTIR 논문).
• Ouyang et al., ReSTIR GI: Path Resampling for Real-Time Path Tracing (HPG 2021, 간접 조명용 ReSTIR).
• Lin et al., Generalized Resampled Importance Sampling (SIGGRAPH 2022, 수학적 토대).
• NVIDIA, Cyberpunk 2077 Path Tracing Tech Deep Dive (엔지니어링 블로그).

7. 볼류메트릭 구름, 안개, 대기

하늘은 3D 노이즈와 밀도 볼륨을 통과하며 ray march됩니다. 대기는 미리 계산한 산란 테이블(Bruneton 스타일)로 태양과 달의 전환을 처리합니다. 안개는 froxel 그리드(뷰 프러스텀에 정렬된 3D 텍스처라고 생각하면 됩니다)로, 국소 조명을 담아냅니다. 이 셋이 합쳐지면 skybox 한 장이 아니라 "하나의 시스템으로서의 날씨"가 됩니다.

더 깊이 보기:

• Schneider, The Real-Time Volumetric Cloudscapes of Horizon Zero Dawn (SIGGRAPH 2015, 구름의 정석 같은 레퍼런스).
• Hillaire, A Scalable and Production Ready Sky and Atmosphere Rendering Technique (EGSR 2020, UE5에서 쓰는 현대판 Bruneton 후계작).
• Wronski, Volumetric Fog: Unified Compute Shader Based Solution to Atmospheric Scattering (SIGGRAPH 2014, Assassin's Creed 4의 froxel 안개).
• Hillaire, Physically Based and Unified Volumetric Rendering in Frostbite (SIGGRAPH 2015).

8. 캐스케이드 섀도 맵과 가상 섀도 맵

태양 그림자의 경우, 캐스케이드 섀도 맵은 프러스텀을 여러 구간으로 나누고 각 구간을 적절한 해상도로 렌더링합니다. 가상 섀도 맵은 한 발 더 나아갑니다. 하나의 거대한 섀도 맵을 페이지로 쪼개고, 카메라에서 보이는 페이지만 렌더링합니다. AAA 게임이 막대한 메모리 비용 없이 플레이어 근처에서 또렷한 그림자를 유지하는 방법입니다.

더 깊이 보기:

• Dimitrov, Cascaded Shadow Maps (NVIDIA 백서, 표준 레퍼런스).
• Microsoft, Common Techniques to Improve Shadow Depth Maps (DirectX 문서).
• Wright, Virtual Shadow Maps in Fortnite Battle Royale Chapter 4 (SIGGRAPH 2023, UE5 VSM 발표).
• Epic Games, Virtual Shadow Maps documentation.

9. 스크린 스페이스 효과 (SSAO, SSR, SSGI, SSSSS)

깊이와 노멀 버퍼를 저렴하게 읽으면 ambient occlusion(SSAO), 반사(SSR), 한 번 반사하는 글로벌 일루미네이션(SSGI), 피부의 서브서피스 스캐터링(SSSSS)을 얻을 수 있습니다. 화면 밖 디테일을 놓치기 때문에 레이 트레이싱이 자리를 넘겨받고 있지만, 빠른 기준선으로는 여전히 어디에나 쓰입니다.

더 깊이 보기:

• Mittring, Finding Next Gen: CryENGINE 2 (SIGGRAPH 2007, 최초의 SSAO 논문).
• McGuire et al., Scalable Ambient Obscurance (HPG 2012, 현대판 SSAO).
• Stachowiak and Uludag, Stochastic Screen-Space Reflections (Frostbite, SSR 레퍼런스).
• Jimenez, Separable Subsurface Scattering (대부분의 AAA 엔진에서 피부에 쓰는 기법).
• Mara et al., Deep Screen Space (Activision, SSGI 계보의 하나).

10. 시간적 안티앨리어싱과 ML 업스케일링 (DLSS, FSR, XeSS)

프레임은 더 낮은 내부 해상도로 렌더링되고, 모션 벡터와 깊이, 히스토리를 이용해 재구성됩니다. ML 기반 업스케일러(DLSS 3/4, FSR 3, XeSS)는 그 위에 프레임 생성을 더해, 옵티컬 플로우로부터 중간 프레임을 보간합니다. 대부분의 AAA 타이틀은 이제 업스케일러가 켜져 있다고 전제하고 출시하며, 이는 프레임의 나머지 예산을 짜는 방식을 바꿔놓습니다.

더 깊이 보기:

• Karis, High Quality Temporal Supersampling (SIGGRAPH 2014, TAA의 정석 같은 발표).
• Salvi, An Excursion in Temporal Supersampling (NVIDIA, DLSS로 가는 길목).
• Edelsten, Truly Next-Gen: Adding Deep Learning to Games and Graphics (GDC 2019, DLSS 아키텍처).
• AMD, FidelityFX Super Resolution 3 technical details and Intel, XeSS technical paper.

11. GPU 주도 렌더링과 mesh shader

컬링, LOD 선택, 드로 제출이 모두 GPU에서 돌아갑니다. Mesh shader는 vertex/geometry/tessellation 파이프라인을, meshlet을 내보내는 더 유연한 compute 스타일 단계로 대체합니다. multi-draw indirect와 결합하면 오브젝트별 핫 루프에서 CPU를 완전히 빼낼 수 있습니다.

더 깊이 보기:

• Haar and Aaltonen, GPU-Driven Rendering Pipelines (SIGGRAPH 2015, 토대가 된 Assassin's Creed Unity 발표).
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, Frostbite의 GPU 주도 컬링).
• Kubisch, Introduction to Turing Mesh Shaders (NVIDIA, mesh shader 입문서).
• Pesce, A Whirlwind Tour of Mesh Shaders (그리고 Adrian Courrèges의 RenderDoc 분해에 모인 비슷한 엔지니어링 블로그들).

12. 머리카락, 옷감, 피부 렌더링

머리카락은 strand 기반 지오메트리에 Marschner 스타일의 이방성 셰이딩을 씁니다(NVIDIA HairWorks, AMD TressFX, 또는 엔진 자체 시스템). 옷감은 GPU에서 position-based dynamics로 시뮬레이션되고 이방성 스페큘러로 렌더링됩니다. 피부는 스크린 스페이스 서브서피스 스캐터링에 사전 적분된 wrap lighting을 더합니다. AAA와 인디 사이의 예산 격차가 드러나는 곳은 보통 이 세 가지입니다.

더 깊이 보기:

• Marschner et al., Light Scattering from Human Hair Fibers (SIGGRAPH 2003, 토대가 된 머리카락 모델).
• Chiang et al., A Practical and Controllable Hair and Fur Model for Production Path Tracing (Disney 2016, 실시간 근사에 널리 쓰임).
• Müller et al., Position Based Dynamics (옷감 시뮬레이션의 표준 레퍼런스).
• Jimenez et al., Separable Subsurface Scattering and Real-Time Realistic Skin Translucency.

13. 데칼, 가상 텍스처링, 머티리얼 레이어링

표면 변화는 깊이 버퍼에 투영되는 레이어드 데칼(탄흔, 먼지, 핏자국, 때)과, 고해상도 디테일을 적시에 스트리밍하는 가상 텍스처에서 나옵니다. 머티리얼 레이어링은 마스크와 triplanar 투영을 써서 픽셀마다 여러 PBR 세트를 블렌딩합니다. 바위 하나가 다섯 개처럼 보이는 이유입니다.

더 깊이 보기:

• Pranckevičius, Deferred Decals와 후속편들 (Aras의 고전 블로그 시리즈).
• Mittring, The Technology Behind the "Unreal Engine 4 Elemental Demo" (SIGGRAPH 2012, 가상 텍스처링 세부 내용 포함).
• van Waveren, id Tech 5 Challenges: From Texture Virtualization to Massive Parallelization (SIGGRAPH 2009, MegaTexture 발표).
• Williams, Material Layering in The Order: 1886 (GDC 2014, 레이어드 PBR 머티리얼).

14. 순서 무관 투명 (OIT)

머리카락, 식생, 파티클, 유리는 깔끔하게 정렬되지 않습니다. AAA 엔진은 weighted blended OIT, depth peeling, per-pixel linked list 같은 기법으로 CPU 정렬 단계 없이도 이들을 올바르게 렌더링합니다. 식생이 많은 장면에서는 한 프레임에서 조용히 가장 비싼 부분 중 하나입니다.

더 깊이 보기:

• McGuire and Bavoil, Weighted Blended Order-Independent Transparency (JCGT 2013, WBOIT 논문).
• Bavoil and Myers, Order Independent Transparency with Dual Depth Peeling (NVIDIA 백서).
• Yang et al., Real-Time Concurrent Linked List Construction on the GPU (per-pixel linked list 레퍼런스).
• Wyman, Exploring and Expanding the Continuum of OIT Algorithms (HPG 2016, 비교 서베이).

15. 뉴럴 래디언스 캐싱과 ML 디노이저

가장 최신의 레이어입니다. NVIDIA의 neural radiance cache는 장면별로 간접 조명을 학습하고, 광선을 더 쏘는 대신 그것을 조회합니다. ML 디노이저(OptiX, Intel Open Image Denoise, 자체 개발판)는 희소한 레이 트레이싱 신호를 밀리초 단위로 정리합니다. 이 범주는 앞으로 2년 동안 빠르게 커질 겁니다.

더 깊이 보기:

• Müller et al., Real-Time Neural Radiance Caching for Path Tracing (SIGGRAPH 2021, NRC 논문).
• Schied et al., Spatiotemporal Variance-Guided Filtering: Real-Time Reconstruction for Path-Traced Global Illumination (HPG 2017, SVGF).
• Chaitanya et al., Interactive Reconstruction of Monte Carlo Image Sequences using a Recurrent Denoising Autoencoder (SIGGRAPH 2017, 최초의 순환형 ML 디노이저).
• Intel, Open Image Denoise documentation (오픈소스 프로덕션 디노이저).

이것이 브라우저에 의미하는 것

우리는 이 기법들 중 몇 가지를 WebGPU로 우리의 브라우저 오픈 월드 엔진에 이미 적용했습니다. 캐스케이드 섀도 맵, GPU 주도 인스턴싱, triplanar PBR, 스크린 스페이스 안개, clipmap 기반 가상화 지형이 모두 탭 안에서 120 FPS로 돌아갑니다. 나머지(하드웨어 레이 트레이싱, mesh shader, ML 업스케일링)는 WebGPU 스펙이 따라잡으면서 웹으로 오고 있습니다. 더 깊이 보려면 브라우저 오픈 월드 기술과 지형 생성에 관한 가이드를 참고하세요.

전체 스택을 아우르는 더 읽을거리

책 한 권만 읽는다면, Real-Time Rendering, 4th edition이 위 주제 대부분을 다루는 표준 참고서입니다. 진행 중인 연구를 따라가려면, SIGGRAPH의 "Advances in Real-Time Rendering in Games" 강좌 아카이브(advances.realtimerendering.com)에 2006년까지 거슬러 올라가는 AAA 엔진 심화 분석 PDF가 무료로 있습니다. 특정 게임이 한 프레임을 어떻게 렌더링하는지에 대한 프로덕션 분해를 보려면, Adrian Courrèges의 GPU 프로파일링 글이 필독입니다.

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

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

17부에서는 플레이어에게 전투 수준의 애니메이션 세트와 CC0 모델이라면 무엇이든 월드로 끌어오는 방법을 줬습니다. 이번 부분은 다시 창작자 쪽으로 돌아갑니다. Spike 34의 팔레트는 클릭 한 번에 프롭 하나를 배치하는데, 주인공 오브젝트 하나를 세우는 데는 괜찮지만 숲을 만드는 데는 쓸모가 없습니다. Spike 37은 그 브러시입니다. 지형을 가로질러 드래그하면 나무가 있어야 할 곳에 나무가 채워집니다.

AI 없는 "AI 배치"

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

이 spike가 답하려는 질문은, 순수하게 휴리스틱으로 만든 브러시가 LLM을 건너뛸 만큼 충분히 똑똑하게 느껴지는가입니다. "AI 배치"에 대한 검증은 구체적입니다. 나무는 절벽을 피하고, 바위는 경사면 쪽으로 기울고, 해변 자갈은 물가에서 멈춥니다. 전부 첫 스트로크에서요. 우리는 경사와 고도 술어, 가중치 추첨, 패밀리별 간격으로 거기에 도달했고 모델 호출은 단 한 번도 없었습니다.

브러시는 손으로 다듬은 지형 특징을 가진 257×257 CPU 하이트맵 위에서 작동하므로 모든 프리셋이 내려앉을 곳을 갖습니다. 혼합 경사 선택용 북부 산악, 스크리(자갈)용 동쪽 절벽 띠, 해변과 초원용 남쪽 해안 평야, 남서쪽 호수 분지가 있습니다. 지형은 (altitude, slope) 바이옴 분류기로 정점 색을 굽기 때문에, 나무 한 그루를 칠하기도 전에 어떤 프리셋이 어디서 발동할지 볼 수 있습니다. 다섯 개 프리셋이 평면 데이터로 제공되며, 각각은 { category, weight, slopeMin, slopeMax, altMin, altMax, minSpacing, alignToSlope } 같은 선택 항목의 목록입니다. Cliff와 Scree는 slopeMin: 0.3으로 설정해 바위가 실제 경사면에만 떨어지게 하고, alignToSlope: true로 설정해 각 바위의 up 벡터가 표면 법선을 따르게 합니다.

각 스트로크마다 스캐터 엔진은 브러시 디스크 안에서 densityPerM2 × area 개의 후보 점을 샘플링하고, 후보마다 높이와 경사를 읽고, 프리셋의 선택 항목을 술어를 통과한 것들로 거른 뒤 가중치로 하나를 뽑고, 반경 내 공간 해시에 대해 간격 검사를 돌립니다. 전체가 결정적입니다. 시드를 줄 수 있는 Mulberry32 RNG가 모든 추첨을 소유하므로 (seed, brush events)가 어떤 세션이든 정확히 재현합니다. 부팅 지형에서 평탄한 초원 위 Mixed Forest 스트로크는 후보 158개 중 139개를 5ms에 배치했고, 같은 프리셋이 절벽 위에서는 226개 중 106개만 배치했으며 HUD는 그중 81개가 경사 때문에 거부됐다고 보고했습니다. 그 거부 내역이 곧 UX 전부입니다. 절벽이 왜 나무를 몇 그루만 받았는지 추측하지 않고 볼 수 있으니까요.

프리셋을 평면 데이터로 유지하는 핵심은, LLM 버전이 도착했을 때 그것이 재작성이 아니라 JSON 교체가 된다는 점입니다. paint({ preset })은 preset.picks가 손으로 다듬은 레시피에서 왔는지, "이끼 낀 바위가 있는 활엽수림"을 가중치로 펼친 워커에서 왔는지 신경 쓰지 않습니다. 엔진은 프롭 id도 절대 하드코딩하지 않으므로, 다른 카탈로그를 끼워 넣어도 엔진 변경이 필요 없습니다.

드로우 콜 300개에서 49개로

첫 번째 버전은 각 배치를 멀티 메시 그룹의 clone(true)로 렌더링했는데, 프롭이 몇백 개일 때는 괜찮지만 2,500개 상한에서는 드로우 콜이 수천 개로 치솟는 벽에 부딪힙니다. 우리는 그 벽에 닿기 전에 (propId, partIndex)당 버킷 하나를 두는 InstancedMesh로 바꿨습니다. 각 버킷은 두 배씩 늘려 성장합니다. 더 큰 InstancedMesh를 할당하고, 살아 있는 행렬을 복사하고, 씬 부모를 교체하고, 옛 속성을 폐기합니다. 지우기는 스왑 리무브라서, 버킷 크기와 상관없이 인스턴스 하나를 제거하는 일은 O(1)입니다. 교체가 전적으로 배치 레코드 아래에 살기 때문에 결정성, 간격, 거부 HUD가 모두 변경 없이 그대로 이어집니다.

MegaKit 팩에 대한 진단이 진짜 아키텍처 질문 하나를 정리해 줬습니다. 멀티 프리미티브 glTF 메시(줄기 + 잎)는 three.js에 두 가지 형태 중 하나로 도착할 수 있습니다. 배열 머티리얼과 geometry.groups를 가진 메시 하나거나, 각각 머티리얼 하나씩을 가진 별도의 형제 메시들이거나입니다. 이 팩에서는 로더가 두 번째 경로를 택합니다. 모든 파트가 빈 그룹을 가진 단일 머티리얼 메시입니다. 그게 스캐터에는 더 나은 형태인데, 프리미티브별로 버킷이 분리되면 줄기 버킷과 잎 버킷의 개수가 갈라질 때 서로 독립적으로 성장할 수 있기 때문입니다. 드로우 콜 수는 어느 쪽이든 같지만, 분리하면 메모리 형태가 더 좋습니다. 측정된 이득은 사실로 드러났습니다. ~300 드로우 콜이던 숲 스트로크가 49개가 됐고, 멀티 스트로크 세션 전체는 51 드로우 콜에서 75 FPS로 3,221개 인스턴스에 도달했습니다. 클론 경로로는 프레임 예산이 붕괴하기 전에 결코 닿을 수 없던 상한이죠.

거리 LOD, 그리고 그 안에 숨은 버그 네 개

인스턴싱이 드로우 콜은 줄였지만, 모든 인스턴스는 여전히 전체 삼각형 개수를 그렸습니다. 90m 밖에서 잎 디테일을 2픽셀 기여하는 나무까지요. 그래서 우리는 meshoptimizer로 프롭 파트마다 LOD 세 단계(full, 50%, 15%)를 굽고, 버킷 키를 (propId, partIndex, lod)로 확장하고, 배치를 형제 버킷 사이로 할당 없이 실어 나르는 move()를 추가했습니다. 거리 밴드는 0~30m, 30~90m, 그 너머이며, 각 경계 주위에 ±4m의 히스테리시스를 둬서 밴드 가장자리 근처를 맴도는 카메라가 배치를 앞뒤로 흔들며 매 프레임 행렬을 다시 업로드하지 않게 했습니다. 재평가는 4Hz로 상한이 걸려 있고 카메라가 실제로 움직였을 때만 게이트되므로, 정지한 카메라는 프레임당 제곱 거리 비교 한 번만 듭니다.

그 LOD 경로가 바로 교훈적인 버그들이 살던 곳입니다. 첫 번째는 카메라가 궤도를 돌 때 배치가 사라지거나 중복되는 모습으로 나타났고, 씬이 채워질수록 심해졌습니다. 원인은 공유 스크래치 행렬이었습니다. move()가 배치의 변환을 모듈 스코프의 _tmpMat로 읽어 들였는데, 원본 버킷의 스왑 리무브가 자기 내부 셔플에 같은 _tmpMat를 쓰면서, 목적지가 쓰기 전에 실어 나르던 행렬을 덮어쓴 것입니다. 이 버그는 옮겨지는 슬롯이 이미 버킷의 마지막일 때만 비켜갔는데, 대략 1/count 확률이고, 이게 정확히 플레이테스트에서 본 "씬이 커질수록 심해지는 드문 깜빡임"입니다. 수정은 move() 전용으로 예약한 _carryMat였습니다. 누적 1,274회 이동으로 스트레스 테스트했을 때 클러스터는 픽셀 단위로 동일하게 유지됐습니다.

두 번째 버그는 더 미묘했습니다. 모든 LOD 전환이 부드럽게 느껴졌는데 첫 번째만 예외였습니다. LOD1으로 넘어가는 나무는 실루엣이 거의 안 변하는데도 음영이 눈에 띄게 바뀐 반면, 사다리 뒤쪽의 더 큰 삼각형 감소는 멀쩡해 보였습니다. LockBorder를 쓰는 단순화기는 정점을 옮기거나 만들어내지 않으므로 살아남은 정점은 법선을 그대로 유지하는데, 그런데도 우리는 단순화 후마다 computeVertexNormals()를 호출하고 있었습니다. LOD0은 아티스트가 만든 원본 법선을 손대지 않고 반환하지만, LOD1 이상은 three.js의 일반적인 면 평균 재계산을 받았습니다. 0에서 1로 가는 경계가 사다리에서 법선 체계가 바뀌는 유일한 지점이었으니, 팝이 살던 곳도 거기였습니다. 그 방어적인 한 줄을 빼니 음영이 고쳐졌고, 덤으로 파트당 네 개 LOD에서 법선을 다시 계산하지 않게 되면서 프롭당 굽기 시간이 대략 절반으로 줄었습니다.

단순화기가 만들어낸 것을 감사하다 세 번째 이득이 떠올랐습니다. 각 LOD는 새 인덱스를 가진 original.clone()이었고, BufferGeometry.clone()은 모든 속성을 깊은 복사하므로, 다섯 개 LOD가 position, normal, UV, color 버퍼의 독립 복사본 다섯 개를 들고 있었고 그 값들은 전부 비트 단위로 동일했습니다. 우리는 속성 참조를 공유하고 LOD마다 전용 인덱스 버퍼만 소유하도록 리팩터링해서, 전형적인 나무 파트를 서로 다른 속성 아이덴티티 20개에서 9개로 줄이고 각 정점 버퍼를 GPU에 한 번만 업로드했습니다. 별칭(aliased) 저장에는 계약 두 가지가 따라옵니다. 어떤 한 LOD를 통해서도 속성 데이터를 변형하지 말 것, 그리고 LOD 하나의 지오메트리를 dispose()하지 말 것. 둘 다 그 버퍼를 공유하는 모든 형제에 영향을 주기 때문입니다.

네 번째 버그는 페인팅과는 아무 상관이 없었습니다. 버튼을 누르지도 않고 지형 위에서 그저 커서를 흔들기만 해도 프레임 레이트가 떨어졌습니다. pointermove 핸들러가 공간 구조가 없는 131,072 삼각형 평면인 지형 메시에 대해 레이캐스트를 했고, 그래서 three.js가 이벤트마다 초당 최대 1,000회까지 전체 인덱스 버퍼를 훑었습니다. 지형이 파라메트릭 하이트맵이라서 그 조회에는 메시가 전혀 필요 없었습니다. sampleHeight에 대한 적응형 레이 마치(표면 위로 높을 때는 큰 보폭, 가까울 때는 0.4m 바닥, 그다음 부호 전환에서 12회 이분법)는 광선당 131,072번의 삼각형 테스트 대신 대략 8~30개 샘플이 드는데, 약 세 자릿수만큼 더 싸고, 호버는 다시 프레임 상한을 유지합니다.

비용은 그냥 옮겨갈 뿐이다. 클릭에서 옮겨가게 하라

spike를 프로덕션 타깃인 three r184의 WebGPURenderer로 바꾼 뒤, DevTools 프로파일은 첫 페인트가 265ms 동안 막히고 그중 79%가 meshoptimizer WASM 안에 있다는 것을 보여줬습니다. 굽기는 실제 작업이었습니다. 콜드 프리셋에 대해 약 180회의 simplify 호출이었죠. 하지만 그게 클릭 핸들러 안에서 돌고 있었는데, preloadProps가 씬을 가져와 파싱만 했지 LOD 굽기를 전혀 촉발하지 않았기 때문입니다. 수정은 프리셋 선택이 배경에서 전체 굽기를 하게 만드는 것이었습니다. preloadProps는 이제 파트 해석 경로를 호출하고, 진행 중인 프로미스를 캐시해서 빠른 클릭이 중복을 만들지 않고 그것에 합류하게 하며, 단순화기가 파트당 네 번씩 다시 하던 지오메트리별 전처리를 메모이즈합니다. 첫 페인트는 HUD에서 209ms에서 4ms로 떨어졌습니다. WASM 시간은 사라지지 않았습니다. 그저 사용자의 임계 경로를 떠나, 사용자가 지형을 보며 어디를 칠할지 정하는 동안 돌 뿐입니다.

그게 이 spike의 되풀이되는 교훈입니다. 이 수정들 거의 어느 것도 브러시가 하는 일을 바꾸지 않았습니다. 그것들은 비용이 언제 내려앉는지를 바꿨습니다. 클릭에서, 호버에서, 카메라가 맴도는 경계에서 비용을 떼어냈죠. 즉각적으로 느껴지는 스캐터 도구는 일을 덜 하는 게 아니라, 사용자가 기다리지 않는 곳에서 그 일을 하는 것입니다.

이 장에서 언급한 기술

휴리스틱 적합도 스캐터. 브러시가 디스크 안에서 후보 점을 샘플링하고, 점마다 CPU 하이트맵에서 (height, slope)를 읽고, 경사와 고도 술어로 프리셋의 선택 항목을 거르고, 가중치로 하나를 뽑고, 공간 해시에 추적되는 패밀리별 최소 간격을 위반하면 거부합니다. 경사 정렬 선택은 up 벡터를 표면 법선으로 회전시킵니다. 이렇게 하면 학습된 가중치 없이도 의도적으로 읽히는 배치(나무는 절벽을 피하고, 바위는 경사 쪽으로 기울고, 자갈은 물가에서 멈춤)가 나오고, 프리셋을 평면 데이터로 유지해 LLM이 생성한 선택 목록을 그대로 끼워 넣을 수 있게 합니다.

비동기 로드 하의 결정적 배치. 시드를 줄 수 있는 Mulberry32 RNG가 모든 추첨을 소유하므로 (seed, brush events)가 세션을 정확히 재현합니다. RNG 추첨은 어떤 await보다 먼저 일어나고, 간격 예약은 glTF 클론이 해석되기 전에 공간 인덱스에 삽입되므로, 동시 후보들은 서로를 존중하고 비동기 에셋 로딩이 시퀀스를 교란할 수 없습니다.

O(1) 편집이 가능한 버킷형 InstancedMesh. (propId, partIndex, lod)당 InstancedMesh 하나이며, 살아 있는 행렬을 더 큰 버퍼로 복사해 요청에 따라 용량을 두 배로 늘립니다. 지우기와 FIFO 축출은 옮겨진 인스턴스의 인덱스를 패치하는 역참조 배열을 동반한 스왑 리무브라서, 버킷 크기와 상관없이 제거가 O(1)입니다. 한 진단이 glTF 파트가 단일 머티리얼 메시로 도착함을 확인했고, 이로써 프리미티브당 버킷 하나가 활성 경로가 되어 각 프리미티브에 독립적으로 성장 가능한 버킷을 줍니다.

히스테리시스와 공유 속성 버퍼를 쓰는 거리 LOD. 파트당 meshopt로 단순화한 세 단계를 ±4m 히스테리시스가 있는 거리 밴드로 선택해 경계 근처 카메라가 흔들리지 않게 하고, 상한이 걸린 비율로, 실제 카메라 움직임에 게이트해 재평가합니다. LockBorder 단순화는 정점을 절대 옮기지 않기 때문에, 모든 LOD가 하나의 position/normal/UV/color 버퍼 세트를 공유하고 전용 인덱스 버퍼만 다르며, 이로써 서로 다른 GPU 정점 버퍼를 대략 절반으로 줄입니다. 방어적인 computeVertexNormals 하나를 건너뛰면 아티스트 법선이 LOD 전반에 동일하게 유지되고 사다리에서 유일한 음영 불연속이 사라집니다. LOD와 meshoptimizer를 보세요.

고빈도 조회를 위한 해석적 하이트맵 레이캐스트. 131k 삼각형 평면 메시에 대한 pointermove 빈도의 커서 조회는 이벤트마다 전체 인덱스 버퍼를 훑습니다. 이것을 해석적 높이 함수에 대한 적응형 레이 마치(표면에서 멀 때는 큰 보폭, 가까울 때는 작은 바닥, $({\text{ray}}_y-{\text{terrain}}_y)$의 부호 전환에서 이분법)로 바꾸면 수만 번의 삼각형 테스트 대신 수십 개 샘플이 들어 약 세 자릿수만큼 더 싸고, 미리 할당한 출력 벡터가 핫 패스를 할당 없이 유지합니다.

상호작용의 임계 경로에서 작업을 떼어내라. 비싼 일회성 작업(meshopt LOD 굽기, WGSL 파이프라인 컴파일)은 클릭 핸들러 안이 아니라 유휴 틈에 돌아야 합니다. 프리셋 선택 시 활성 프리셋의 전체 굽기를 미리 로드하고, 진행 중인 프로미스를 캐시해 빠른 클릭이 포크가 아니라 합류하게 하고, 지오메트리별 전처리를 메모이즈한 결과, 전체 작업량을 전혀 줄이지 않고도 첫 페인트 지연을 209ms에서 4ms로 떨어뜨렸습니다.

29부 중 18부. 이전: 17부 - 리타기팅이 필요 없던 애니메이션, 그리고 실시간 에셋 검색 다음: 19부 - 숲에서 살아남아야 하는 임포스터 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

16부에서 우리는 물체를 배치할 수 있는 세계를 얻었습니다. 이번 부분은 그 안에서 플레이어가 할 수 있는 더 나은 것을 줍니다. 전투급 애니메이션 세트, 그리고 검색을 입력해서 수천 개의 CC0 모델 중 무엇이든 세계로 끌어오는 방법입니다.

262개 클립, 하나의 스켈레톤, 세 개의 리타기팅 수정

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

플레이어 릭은 CC4 스타일의 3MIKE 스켈레톤으로 213개의 본을 가지고 있고, 80개가 넘는 본의 얼굴 릭과 완전한 손가락 관절을 포함합니다. 애니메이션 소스는 여기에 맞지 않습니다. 첫 번째 버전은 손으로 고른 Mixamo 전투 클립을 리타기팅했지만, 소스 풀이 얇았고 이동 애니메이션은 Mixamo와 몇 개의 Kimodo BVH 대기 동작 사이에 어색하게 쪼개져 있었습니다. 진짜 성과는 소스 라이브러리를 Quaternius의 Universal Animation Library 두 팩으로 바꿨을 때 나왔습니다. 하나의 일관된 UE5 스타일 65본 마네킹 위에 총 262개의 클립입니다. 검 콤보, 활쏘기, 등반, 벽 달리기, 회피, 피격 반응, 이모트, 그리고 훨씬 깔끔한 이동 애니메이션 세트가 있습니다.

이건 65본 소스에서 213본 타깃으로 가는 것이고, 공유된 본 이름도, T-포즈 방향도, 팔다리 비율도 없습니다. 모든 클립은 세 단계로 리매핑됩니다. 본 이름 맵, 두 릭이 기준 방향을 공유하도록 하는 바인드 포즈 정렬, 그리고 더 짧은 소스 릭이 캐릭터를 바닥에 무릎까지 박아버리지 않도록 하는 위치 트랙 스케일링입니다. 이걸 제대로 맞추는 일은 각각 구체적인 무언가를 가르쳐 준 일련의 버그를 쫓는 것을 뜻했습니다.

캐릭터가 너무 비틀린 채로 나왔고, 모든 어깨와 팔꿈치가 약 30° 정도 과하게 회전했습니다. 원인은 포즈 불일치였습니다. UAL 소스는 진짜 T-포즈로 배포되고, CC4의 바인드는 A-포즈인데, 리타기터는 두 릭이 일치하는 기준 포즈에 있다고 가정했습니다. 그래서 A에서 T로의 차이가 매 프레임 델타마다 더해졌습니다. 수정은 바인드를 잡기 위해 CC4의 팔 체인을 진짜 T-포즈로 강제한 다음 리타기팅하는 것입니다. 그러면 델타가 작게 유지됩니다.

그다음에는 몸이 이동을 멈췄습니다. 넉백이 상체를 뒤로 젖혔지만 발은 바닥에 박힌 채로 남았습니다. UAL은 변위를 골반이 아니라 root 본에 둡니다. 그래서 골반 위치를 읽으면 거의 0에 가까운 움직임이 나왔습니다. 수정은 root.position과 pelvis.position을 더하고, 수평 부분을 스케일링한 다음, 하나의 엉덩이 위치 트랙으로 쓰는 것입니다. 이걸 하면서 우리는 수직 오프셋이 약 12% 어긋나 있는 것을 발견했습니다. 골반 높이는 엉덩이-바닥 비율이 필요한데 Y축에 전역 팔다리 비율을 썼기 때문이었습니다. 두 개의 비율, 두 개의 축입니다. Y에는 $\text{verticalRatio}=|\text{targetHipY}/\text{sourceHipY}|$, 수평에는 비율 자체를 씁니다. 오버슈트가 사라졌습니다. 그리고 RL_BoneRoot.position NaN 경고가 줄줄이 나왔는데, UAL의 root($Y=0$에 있음)를, 바인드 Y로 나눠서 정규화되는 위치 트랙을 가진 타깃 본에 매핑한 것이 원인이었습니다. 0으로 나누기, NaN, 조용히 버려지는 트랙입니다. 수정은 root 매핑을 통째로 빼는 것이었습니다. 그 평행이동은 이미 엉덩이 트랙 안에 살고 있기 때문입니다.

가장 작은 수정이 보기에는 가장 만족스러웠습니다. 캐릭터가 축 늘어진 바인드 포즈 손가락으로 검을 쥐고 있었는데, 본 맵에 손가락 항목이 없었고 리타기터는 매핑된 본에 대해서만 트랙을 쓰기 때문이었습니다. 손가락 본 30개(다섯 손가락, 세 마디, 두 손, 변형되지 않는 UAL의 네 번째 손끝 헬퍼는 제외)를 추가하니 손이 손잡이를 잡을 때 오므라지고 놓을 때 펴졌습니다.

262개 클립을 보지 않고 262개 클립을 증명하기

262개 클립 라이브러리를 눈으로 검증할 수는 없습니다. 그래서 우리는 오프라인 궤적 일치 테스트를 만들었습니다. 각 팩을 로드하고, 소스 스켈레톤을 60Hz로 샘플링하고, 리타기팅 파이프라인을 돌린 다음, 스케일링 후의 본별 월드 위치와 회전을 소스와 비교하는 헤드리스 Node 스크립트입니다. 골반 Y 드리프트는 최대 0.003 m로 나왔습니다. 손은 일정한 2.5° 오프셋을 보였는데, 처음에는 "손가락이 추적되지 않는다"로 읽혔습니다. 하지만 일정한 오프셋은 평평한 UAL 손과 약간 오므라진 CC4 바인드 사이의 바인드 델타이고, 클립 전체에서 변하지 않습니다. 진짜 애니메이션 오류는 프레임마다 달라지는 드리프트로 나타납니다. 이게 분명해지자 테스트는 한 방 회귀 검사가 되었습니다. 어떤 클립의 드리프트가 그 일정한 기준선을 유지하지 못하면, 최근의 변경이 리타기팅을 망가뜨린 것입니다.

나란히 놓인 참조 마네킹은 디버깅의 시각적 절반을 결정적으로 만들었습니다. 백슬래시를 누르면 현재 클립을 소유한 소스 릭이 플레이어 옆에 나타납니다. 그래서 "어깨가 비틀렸다"라는 질문이 "비틀림이 소스에 있나, 아니면 리타기팅이 더한 건가?"로 바뀝니다. 수치 테스트는 회귀를 잡고, 시각 참조는 숫자로 드러나지 않는 바인드 포즈 실수를 잡습니다. 둘이 함께 추측 게임을 은퇴시켰습니다.

파이프라인이 단단해지자, WASD/점프/수영 기준선을 Mixamo에서 UAL로 바꾸는 것은 얇은 별칭 맵에 불과했습니다. FSM은 여전히 idle이나 walk 같은 일반 상태 이름을 말하고, 재생 시점에 UAL 클립 이름으로 해석됩니다. 수영은 클립별 릭 오프셋이 필요했습니다. 자유형과 선헤엄 포즈가 골반을 서로 다른 해부학적 높이에 고정하기 때문입니다. 그래서 능동적으로 수영할 때는 릭을 반 미터 가라앉히고 선헤엄칠 때는 더 깊게 가라앉히면서, 부드러운 5Hz로 둘 사이를 블렌딩합니다.

단어를 입력하면 모델이 나온다

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

Spike 34는 CC0 팩을 손으로 큐레이션하느라 하루를 잡아먹었습니다. 장기적인 답은 검색 상자입니다. Polyhaven은 너그러운 JSON API와 결정론적 CDN 뒤에 약 1,100개의 CC0 모델을 게시합니다. 그리고 이 spike는 빌드 단계 없이 정적 페이지에서 전체 경로(쿼리, 썸네일, 로드, 렌더)를 약 300줄의 바닐라 JS에 three.js를 더해 연결합니다.

부팅할 때 전체 카탈로그를 한 번 가져옵니다. 약 600 KB입니다. 검색은 순수 클라이언트 측 점수 매기기(이름이 id를 이기고, id가 카테고리를 이기고, 카테고리가 태그를 이김)에 120 ms 디바운스를 걸고 상위 60개 카드를 렌더링합니다. 썸네일은 IntersectionObserver를 통해 지연 로드되므로 타이핑이 한 번에 60개 요청을 쏘지 않습니다. 흥미로운 부분은 로딩입니다. Polyhaven의 파일 엔드포인트는 GLB가 아니라 멀티파일 glTF를 노출하고, 텍스처는 해상도 간에 공유되며 별도 파일로 쪼개져 있고, 상대 경로에서 절대 CDN URL로 가는 include 맵을 돌려줍니다. JSON을 우리가 직접 내려받아 패치하는 대신, 그 맵을 LoadingManager.setURLModifier에 먹입니다. 이건 로더가 필요로 하는 모든 의존성(.bin, 각 텍스처)마다 발동되어 CDN을 통해 해석합니다. 한 번의 클릭, 겉보기엔 하나의 파일입니다. API와 CDN 둘 다 너그러운 CORS를 설정했고, 어떤 클라이언트 코드보다 먼저 curl로 검증했습니다. 그래서 프록시가 필요 없습니다. PBR 머티리얼은 RoomEnvironment와 ACES 톤 매핑 기본값으로 에셋별 보정 없이 올바르게 렌더링되고, 1k 텍스처는 일반적인 모델을 4k의 20에서 40 MB 대신 2에서 5 MB로 유지합니다.

meshoptimizer WASM 패스가 비파괴적 리듀서로 마무리합니다. 각 메시는 원본 지오메트리의 복제본을 보관하고, 비율을 바꾸면 누적적으로 단순화하는 대신 그 복제본에서 인덱스 버퍼를 다시 빌드합니다. 멀티 머티리얼 지오메트리는 그룹별로 단순화하고 geometry.groups를 다시 빌드해서 머티리얼 슬롯이 무너지지 않습니다. 안락의자 하나가 전체 정밀도 5,626 삼각형에서 절반 정밀도 2,812로 갑니다.

이 장에서 다룬 기술

바인드 포즈 정렬을 동반한 스켈레톤 리타기팅. 본 이름, 비율, 기준 포즈가 다른 한 스켈레톤에서 다른 스켈레톤으로 애니메이션을 매핑하려면 세 가지 보정이 필요합니다. 본 이름 맵, 두 릭이 기준 방향을 공유하도록 하는 바인드 포즈 정렬(타깃의 A-포즈 팔 체인을 소스의 T-포즈로 강제), 그리고 위치 트랙 스케일링입니다. 포즈 불일치는 A에서 T로의 회전을 매 프레임 델타에 더해 관절 회전을 두 배로 만듭니다. 매핑되지 않은 헬퍼 본은 반드시 버려야 합니다. $Y=0$에 있는 root 본은 위치 트랙 정규화에서 조용한 0으로 나누기를 일으키기 때문입니다.

한 릭을 위한 두 개의 스케일 비율. 수평 변위는 전역 팔다리 비율(전체 스켈레톤 크기)을 쓰지만, 수직 골반 오프셋은 엉덩이-바닥 비율 $|\text{targetHipY}/\text{sourceHipY}|$를 씁니다. 다리 대 몸통 비율이 두 릭 사이에서 다르기 때문입니다. 두 축에 하나의 비율을 쓰면 등반은 오버슈트하고 회복은 바닥 아래로 가라앉습니다. UAL 변위도 골반이 아니라 root 본에 살기 때문에, 넉백, 등반, 이동 클립 전반에서 움직임을 보존하려면 둘 다 하나의 엉덩이 위치 트랙으로 더해야 합니다.

오프라인 궤적 일치 테스트. 헤드리스 스크립트가 소스 스켈레톤을 60Hz로 샘플링하고, 리타기팅 파이프라인을 돌리고, 본별 월드 변환을 소스와 비교합니다. 일정한 프레임별 오프셋은 무해한 바인드 델타이고, 프레임마다 달라지는 드리프트는 진짜 오류입니다. 그래서 테스트는 변경이 트랙을 떨어뜨리거나 왜곡할 때 발동되는 회귀 검사가 됩니다. 팩별 GLB 격리(새로 로드하고, 다음 것 전에 해제)는 전체 스윕에 걸친 캐시 경합을 피합니다.

CDN glTF 그래프를 위한 LoadingManager.setURLModifier. CDN이 glTF를 상대 URI 그래프로, 동반하는 include 맵(상대 경로에서 절대 URL로)과 함께 배포할 때, setURLModifier는 JSON을 다시 쓰지 않고도 로더가 요청하는 모든 의존성을 CDN을 통해 해석합니다. 이것은 멀티파일, 멀티해상도 배포를 한 번의 클릭 로드로 접어 넣습니다. 다음 로드 전에 이전 모델의 지오메트리, 머티리얼, 텍스처 맵을 해제하면 탐색 세션 동안 수백 MB의 GPU 메모리가 쌓이는 것을 막습니다.

비파괴적 메시 단순화. 각 메시의 원본 지오메트리 복제본을 저장하고 단순화 비율마다 인덱스 버퍼만 다시 빌드하면 변경이 빠르게 유지되고 반복 단순화로 인한 누적 손상을 피합니다. geometry.groups 슬라이스별로 돌리고 그룹을 재구성하면 멀티 머티리얼 할당이 보존됩니다. 이것이 거리 기반 LOD에 어떻게 공급되는지는 LOD와 meshoptimizer를 보세요.

29부 중 17부. 이전: 16부 - 계속 자라나는 세계를 위한 구조 다음: 18부 - AI가 배치한 듯한 스캐터 브러시 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

글 Mariana Muntean, Cinevva CEO

낯선 사람들이 Cinevva에 대해 가장 흔히 하는 말은 그냥 AI 래퍼라는 것입니다. 홈페이지에 들어와서 "Describe your game"이라고 적힌 입력 상자 하나를 보고는 제품을 다 이해했다고 결론 내립니다. 그들이 이해한 건 정문입니다. 제품은 그 문장을 입력할 때 보이지 않는 모든 것이고, 이번 주부터는 거기에 더해 플레이어들이 당신의 게임을 찾으러 걸어 들어오는 오픈 월드까지입니다.

그 입력 뒤에는 완전한 게임 엔진이 있습니다. 타입이 정의된 26개의 도구를 가진 오케스트레이터, 생성 모델 한 무리, 11개 제공처에 걸친 통합 에셋 검색, 에이전트가 읽고 쓸 수 있는 실시간 게임 iframe, 그리고 같은 에이전트가 완성된 당신의 게임을 넘겨볼 수 있는 게임플레이 릴로 출시해 주는 스토어프런트가 있죠. 이 중 별난 건 하나도 없습니다. 전부 배관 작업입니다. 흥미로운 일은 무엇을 무엇에 연결할지 정하는 것이었습니다.

이 글은 그 기계를 위에서 아래로 훑습니다. 기술 투자자에게 들려주는 설명이자, 기여를 고민하는 개발자에게 들려주는 설명이기도 합니다. 둘 다 같은 답을 원합니다.

1. 프롬프트는 표면이지 시스템이 아니다

첫 번째 설계 결정은 사용자가 직접 발을 들이기 전까지 모든 걸 숨기는 것이었습니다. 홈페이지의 일은 하나뿐입니다. 문장 하나를 프로젝트로 바꾸는 것이죠. 우리는 경험을 공개되는 쪽(프롬프트, 쇼케이스, 스토어프런트 피드)과 창작자 쪽(IDE, 에셋 도구, 게시 흐름)으로 나눴습니다. 그냥 놀고 싶은 사람들은 조종석을 들여다볼 필요가 없도록요.

그래서 플레이스홀더가 "Make a snake game with neon graphics"나 "Top-down zombie shooter" 같은 문구로 돌아가는 것입니다. 이건 튜토리얼이 아닙니다. 허가증입니다. 사용자는 "이상한 아케이드 아이디어"도 합법적인 입력이라는 걸 알게 됩니다.

제출하는 순간 세 가지 일이 일어납니다. 시스템이 안정적인 ID를 가진 새 게임 프로젝트를 만듭니다. 빈 파일 트리(index.html, game.js, style.css, assets/, GDD.md)를 심습니다. 그리고 당신의 문장을, 그 빈 파일들을 가리키는 프로젝트 컨텍스트 창과 함께 오케스트레이터로 보냅니다. 이 순간부터 당신은 손을 가진 에이전트와 대화하게 됩니다.

2. 입력 뒤에는 완전한 브라우저 IDE

창작자 작업 공간은 전적으로 브라우저 안에서 돌아가는 3분할 IDE입니다. 왼쪽에 파일 트리, 가운데에 코드 편집기, 오른쪽에 실시간 게임 iframe, 아래쪽을 가로지르는 채팅 입력. 이 배치는 일부러 고른 것입니다. 이미 코드를 쓰는 사람은 한눈에 알아봅니다. 코드를 쓰지 않는 사람은 가운데 패널을 무시하고 채팅하고만 대화하면 됩니다.

파일 트리는 비유가 아닙니다. 모든 프로젝트는 실제로 HTML, JS, CSS, 생성된 이미지, GLB 모델, 오디오 파일로 이루어진 작은 정적 사이트이고, R2에서 Cloudflare Worker를 거쳐 바로 서빙됩니다. 빌드 단계가 없습니다. 이 점이 중요합니다. 에이전트가 당신이 실제로 출시할 파일들을 읽고 쓸 수 있다는 뜻이고, 같은 산출물이 iframe 안에서도, Capacitor로 감싼 휴대폰에서도, Tauri로 감싼 Steam에서도, Discord 안에서 Embedded Activity로도 돌아간다는 뜻입니다. 하나의 파일 시스템, 여섯 개의 배포 대상입니다.

우리가 생성하는 모든 게임은 window에 두 개의 함수를 노출해야 합니다. getGameState()는 실행 중인 게임을 설명하는 평범한 객체(플레이어 위치, 점수, 생명, 적, 타이머)를 반환합니다. setGameState(patch)는 부분 업데이트를 실시간 게임에 다시 적용합니다. 이 작은 API가 바로 에이전트가 다시 로드하지 않고도 실행 중인 게임을 들여다보고 수정하게 해 주는 계약입니다. 왜 그런지는 6절에서 다시 다룹니다.

3. 오케스트레이터, 진짜 엔진이 사는 곳

이걸 "AI 래퍼"라고 부르는 사람들이 놓치는 부분은, AI가 코드를 쓴다기보다는 작은 오케스트라를 지휘한다는 점입니다. 오케스트레이터는 프런티어 모델을 상대로 도는 tool-calling 루프로, 약 천 줄짜리 시스템 프롬프트와 26개 함수로 이루어진 타입 정의 도구 표면을 갖추고 있습니다. 그 도구 정의가 엔진입니다. 모델은 지휘자입니다.

26개의 도구는 다섯 가지 계열로 나뉩니다. 파일 시스템 도구(list_game_files, read_files, search_game_file, edit_files, write_files, delete_files, rename_files)는 에이전트가 당신의 게임을 다른 코드베이스처럼 다루게 해 줍니다. 프로젝트 도구(create_new_game, list_games, open_game, ask_user, game_ready)는 프로젝트의 수명 주기와 사람에게 다시 넘기는 단계를 처리합니다. 생성 도구(generate_image, generate_skybox, generate_music, generate_sfx, rig_model, apply_animation, list_animations, list_skybox_styles)는 다음 절에서 다룰 전용 모델들을 호출합니다. 지식 도구(search_fonts, list_library_docs, search_library_docs, list_generations)는 에이전트에게 환각이 아닌, 믿을 수 있고 색인된 사실의 출처를 줍니다. 그리고 런타임 도구(read_console_logs, execute_js)는 에이전트가 실시간 게임을 보고 만지게 해 줍니다.

전형적인 첫 턴은 대략 이렇습니다. 사용자가 "Make a neon space shooter"를 입력합니다. 모델은 설계를 설명하는 GDD.md와 함께 write_files 호출을 내보내고, 그다음 다시 write_files로 index.html, game.js, style.css를 내보냅니다. prompt="synthwave space shooter, 120 BPM, driving bassline"으로 generate_music을 호출하면 ElevenLabs Music에 대한 작업이 시작되고 R2 안의 MP3 URL이 돌아옵니다. 별이 빛나는 배경을 위해 Blockade Labs의 model 3 스타일로 generate_skybox를 호출합니다. game_ready(title, message)를 호출해 iframe을 새 빌드로 전환하고, 마지막으로 read_console_logs를 호출해 게임이 오류 없이 부팅됐는지 확인합니다. 스택 트레이스가 보이면, 사용자가 무언가를 보고하기 전에 edit_files로 돌아가 고칩니다.

이 설계의 흥미로운 속성은, 시스템 프롬프트와 도구 스키마만이 제품에 특화된 유일한 부분이라는 점입니다. 모델을 바꿔도 전부 그대로 작동합니다. 우리는 지난 한 해 동안 표면을 바꾸지 않고 세 개의 프런티어 모델 사이를 옮겨 다녔습니다. 그 표면이 우리 것이기 때문입니다.

4. 에셋 쪽: 모델 팬아웃

에이전트는 이미지, 음악, 사운드, 3D를 직접 생성하지 않습니다. 전문가들을 호출합니다. Cinevva의 에셋 쪽은 분야별 최고 모델들로 팬아웃한 다음, 하나의 출력이 다음 것의 유효한 입력이 되도록 붙여 놓은 구조입니다.

이미지와 스프라이트의 경우 generate_image가 Flux Pro 1.1을 호출하는데, 너비와 높이는 항상 32의 배수이고, 프롬프트가 투명도를 요구하면 출력 형식이 PNG로 전환됩니다. 곡 전체는 에이전트가 스타일 프롬프트와 초 단위 길이로 ElevenLabs Music을 호출합니다. 일회성 효과음은 ElevenLabs SFX가 "laser gun firing, sci-fi blaster" 같은 텍스트에서 5초에서 15초 사이의 클립을 만들어 냅니다. 360도 환경은 generate_skybox가 약 90가지 스타일 중 하나로 Blockade Labs를 호출하며, 기본값은 model 3 Digital Painting입니다. 3D 캐릭터의 경우 rig_model이 GLB를 Tripo로 보내 이족, 사족, 육족, 팔족, 뱀형, 또는 수생 생물로 스키닝하고 리깅하며, 그다음 apply_animation이 15개 프리셋(idle, walk, run, jump, climb, dive, slash, shoot, hurt, fall, turn, 그리고 비이족용 행진 동작) 중 아무거나 재생합니다.

이것들은 하나하나가 동기 호출이 아니라 작업입니다. 짧으면 몇 초, 길면 몇 분이 걸립니다. 오케스트레이터는 이들을 띄우고 곧바로 jobId와 함께 반환하며, 별도의 채널이 에셋이 준비되면 결과를 대화로 다시 흘려보냅니다. 이게 느낌을 완전히 바꿉니다. 3D 모델이 백그라운드에서 리깅을 끝내는 동안 에이전트는 계속 게임 로직을 만들 수 있습니다. 사용자는 단일 임계 경로에서 기다릴 일이 없습니다.

산출물은 모두 같은 곳에 떨어집니다. cdn.cinevva.com 뒤의 R2이고, 평범한 URL로 주소를 지정할 수 있습니다. 이 말은 에이전트의 다음 write_files 호출이 그냥 <audio src="https://cdn.cinevva.com/audio/abc.mp3">를 임베드하면 게임이 바로 작동한다는 뜻입니다. SDK도, asset bundler도, manifest도 없습니다.

5. 11개 제공처에 걸친 에셋 검색

생성은 특정한 무언가가 필요할 때 훌륭합니다. 검색은 이미 존재하는 무언가가 있을 때 더 빠릅니다. 에셋 라이브러리는 무료 및 라이선스 제공처 11곳에 걸친 연합 검색으로, 하나의 순위가 매겨진 피드로 반환됩니다.

제공처 레지스트리는 worker 안에 있으며, 각 쿼리를 PolyHaven, Sketchfab, Freesound, Kenney, AmbientCG, Quaternius, OpenGameArt, Smithsonian 3D 컬렉션, TurboSquid, Synty, Jamendo에 병렬로 던집니다. 각 제공처는 공통 인터페이스(search, getMetadata, isBrowsable, getSupportedTypes)를 구현하므로, 새 제공처를 추가하는 일은 TypeScript 파일 하나입니다. 집계 계층은 제공처마다 다른 페이지네이션 방식을 커서 기반으로 처리하고, 라이선스를 중복 제거하며, 에셋 타입을 공통 분류 체계(model, texture, audio, hdri, sprite)로 정규화하고, 각 에셋에 라이선스를 태그로 붙입니다. 그래서 에이전트는 재배포할 수 없는 것을 절대 고르지 않습니다.

지난 분기에 ChatGPT가 이 도구를 게임 개발자를 위한 최고의 무료 에셋 검색 도구 중 하나로 추천했을 때, 우리는 그 추천을 직접 읽어 봤습니다. 핵심에 대해서는 옳았습니다. 요점은 우리가 단일 라이브러리 위에 검색창을 얹었다는 게 아닙니다. 요점은 "stone wall texture"를 검색하는 인디 개발자가 PolyHaven과 AmbientCG의 결과를 나란히 받고, 그 옆에 Kenney의 양식화된 버전과 Smithsonian의 사진 측량 옵션까지 받는다는 것입니다. 쿼리 한 번에, 일관된 라이선스 메타데이터와 함께요. 에이전트도 같은 엔드포인트를 호출해서 사람과 똑같은 방식으로 에셋을 고를 수 있습니다.

엔진에서 자주 과소평가되는 부분이 바로 여기입니다. 대부분의 게임 AI 데모는 모든 걸 처음부터 생성해서, 결국 균일하고 번들거리며 살짝 기이한 룩으로 끝납니다. Cinevva에서 흥미로운 게임들은 생성된 에셋을 Smithsonian의 진짜 CC0 사진 측량물, 그리고 Quaternius의 손으로 만든 로우폴리 나무와 섞습니다. 오케스트레이터는 그걸 한 턴에 해낼 수 있습니다.

6. 에이전트가 게임을 플레이한다

우리가 보여 줄 때 대부분의 엔지니어를 놀라게 하는 부분이 바로 이것입니다. 에이전트는 단지 코드를 파일에 쓰는 데 그치지 않습니다. 샌드박스 iframe에서 게임을 실행하고, 콘솔을 읽고, UI와 3D 장면을 층으로 나눠 스크린샷을 찍고, 실시간 런타임 안에서 JavaScript를 실행해 상태를 검사하거나 바꿉니다.

read_console_logs는 iframe에서 나온 console.log, console.warn, console.error 그리고 잡히지 않은 예외의 마지막 50줄을 반환합니다. 모든 game_ready 호출 후에, 에이전트는 시스템 프롬프트에 의해 read_console_logs를 호출하고 사용자에게 다시 넘기기 전에 모든 오류를 고치도록 요구받습니다. 이 규칙 하나가 다른 도구들에 있는 "AI는 다 됐다고 했는데 화면이 까맣다" 류의 실패 대부분을 없앱니다.

execute_js는 더 강력한 쪽입니다. 게임의 전역 스코프 안에서 임의의 JavaScript를 실행합니다. 모든 게임이 getGameState와 setGameState를 구현하도록 요구받기 때문에, 에이전트는 JSON.stringify(getGameState())를 실행해 실행 중인 게임의 전체 상태를 읽고, setGameState({player: {x: 500, y: 100}})로 플레이어를 순간 이동시키거나, setGameState({lives: 99})로 무적을 부여하거나, setGameState({level: 3})로 앞으로 건너뛸 수 있습니다. 더 낮은 수준도 찔러 볼 수 있는데, scene.children.map(c => c.type)로 Three.js 장면 그래프를 검사하거나 document.querySelectorAll('canvas').length로 렌더러가 마운트됐는지 확인하는 식입니다.

이게 왜 중요한지 보일 겁니다. 사용자가 "2단계에서 플레이어가 벽에 끼인다"고 말하면, 에이전트는 추측할 필요가 없습니다. 2단계를 열고, getGameState()를 실행하고, 충돌 데이터를 살펴보고, execute_js 패치를 돌려 수정안을 테스트한 다음, 그제야 수정안을 디스크에 씁니다. 당신이 디버그하는 방식 그대로 디버그합니다. 우리는 iframe을 대상이 아니라 동료로 다룹니다.

7. 라이브러리 문서, 지루한 사실의 출처

우리는 게임이 실제로 쓰는 라이브러리(Three.js, Tone.js, Cannon, 그리고 늘어나는 중)의 공식 문서를 구조화되고 검색 가능한 JSON 저장소로 색인합니다. 에이전트는 열린 웹에 손을 뻗기 전에 search_library_docs("threejs", "Mesh")에 손을 뻗습니다. 더 빠르고, 버전이 관리되며, 두 마이너 릴리스 전에 이름이 바뀐 메서드를 절대 환각하지 않습니다.

이건 화려한 일이 아닙니다. 하지만 작동하는 코드를 만드는 AI와, 그럴듯해 보이지만 40번째 줄에서 죽는 코드를 만드는 AI의 차이입니다. Cinevva로 만든 게임의 눈에 보이는 품질 대부분이 이 한 가지 결정에서 나옵니다.

8. 플레이 가능에서 발견 가능으로: 릴과 스토어프런트

아무도 플레이하지 않는 게임은 개인 취미입니다. 인디 개발에서 풀리지 않은 가장 어려운 문제는 이제 게임을 만드는 게 아닙니다. 배포입니다. 그래서 엔진은 "플레이 가능"에서 멈추지 않습니다. "플레이어 앞에 있음"에서 멈춥니다.

Cinevva의 모든 프로젝트는 play.cinevva.com/{game-id} 같은 안정적인 공유 URL을 가지며, 이 URL은 게임의 최신 빌드를 전체 페이지 iframe으로 열고 좋아요와 공유를 위한 작은 오버레이를 띄웁니다. 에이전트가 game_ready를 호출하면, IDE 안의 미리보기만 전환하는 게 아닙니다. 15초짜리 게임플레이 릴을 Cinevva 스토어프런트에 게시하겠다고 제안하기도 합니다. 릴은 게임이 플레이되는 실제 녹화로, iframe에서 직접 캡처됩니다(우리는 에이전트가 게임 런타임에 주입하는 작은 레코더 스크립트를 함께 보냅니다). 그래서 시청자가 스크롤로 지나치는 것은 마케팅 편집물이 아니라 진짜 게임플레이입니다.

이게 개발자가 사는 루프를 바꿉니다. 옛 루프는 코드 작성, 빌드, 패키징, 업로드, Steam 페이지 작성, 알고리즘과 싸우기, 위시리스트 카운터 지켜보기였습니다. 새 루프는 문장 하나 입력, 에이전트가 만드는 걸 지켜보기, 게시 누르기, 당신의 게임이 다른 모든 것과 함께 같은 스와이프 피드에 나타나는 걸 지켜보기입니다. 발견은 창작이 일어나는 같은 제품 안에서, 같은 URL에서, 같은 로그인으로 일어납니다.

개발자 커뮤니티 독자라면 이 부분을 살펴보세요. 배포는 언제나 게임 엔진이 함께 출시하지 않는 해자였습니다. Unity는 에디터를 출시하고, 당신은 게임을 Steam에 출시합니다. Unreal은 에디터를 출시하고, 당신은 Epic Store에 출시합니다. Cinevva는 양쪽 다 출시합니다. 엔진과 스토어프런트는 게임을 만든 바로 그 오케스트레이터를 통해 서로 대화합니다.

9. Top Performers: 발견의 플라이휠

릴 피드는 플라이휠의 절반입니다. Top Performers 차트가 나머지 절반입니다. 이 차트는 게임을 trending, recent, all-time top으로 순위 매기는데, 가중치는 원시 클릭이 아니라 완주율(플레이어가 한 세션을 끝냈는가)로 둡니다. 완주율은 설치 수보다 조작하기 어렵습니다. 60초 동안 주의를 붙드는 게임이 열었다 닫히는 게임을 이깁니다.

모든 신호는 오케스트레이터의 다음 턴으로 되먹임됩니다. 에이전트가 "파워업을 추가하자"고 말할 때, 고정된 패턴 라이브러리에서 끌어오는 게 아닙니다. 이번 달 Cinevva에서 어떤 메커니즘이 실제로 플레이어를 붙잡는지 지켜본 모델에서 끌어옵니다. 플라이휠은 페이지 하단의 차트가 아닙니다. 엔진 전체의 학습 신호입니다.

투자자라면, 이것이 데이터 해자입니다. 우리는 단지 생성된 게임만 가진 게 아닙니다. 실제 세션 수준 참여 지표가 붙은 생성 게임을 가졌고, 그것을 만들어 낸 프롬프트에 붙어 있고, 에이전트가 내린 에셋 선택에 붙어 있고, 그걸 좋아한 플레이어에게 붙어 있습니다. 한 바퀴를 돌 때마다 다음 바퀴가 더 단단해집니다.

10. 엔진이 게임이 되다

여기가 제가 몇 달째 소셜에서 흘려 온 부분입니다. 1절부터 9절까지는 게임을 만드는 시스템을 설명합니다. 직접 보기 전까지 설명하기 더 어려운 것은, 그 시스템 자체가 하나의 장소가 될 때 무슨 일이 일어나는가입니다.

게임을 만드는 일은, 우리가 지금까지 출시한 모든 것을 가지고도 고된 작업입니다. 한 번도 게임을 만들어 본 적이 없다면, 당신은 갑자기 줄거리, 캐릭터, 세계, 메커니즘, 누가 무엇을 언제 하는지, 빛이 어떻게 움직이는지, 특수 효과가 어떻게 층층이 쌓이는지, 음악, 음향 효과, 카메라 움직임을 책임지게 됩니다. 양이 많습니다. 게다가 그 모든 것 위에, 결과물이 누군가 다른 사람의 도구가 뱉어낸 템플릿이 아니라 당신 것처럼 느껴지길 원하죠. 프롬프트와 오케스트레이터는 기계적인 작업 대부분을 당신 대신 해 줍니다. 그것들이 혼자서 못 하는 건, 완성된 당신의 것에 다른 사람들이 지켜보는 무대를 마련해 주는 일입니다.

그래서 우리는 무대를 지었습니다. 올해 대부분 동안 Oleg와 엔진 팀은 오픈 월드를 브라우저에 넣는 일에 대한 14부작 시리즈를 발행해 왔습니다. 실시간으로 깎을 수 있는 조각된 지형. 경사와 고도에 따라 스스로를 바위나 풀로 칠하는 바이옴. 컴퓨트로 생성된 지형 위에서 바람에 휘는 8만 개의 풀잎. 하이트맵 지형과 볼류메트릭 지형을 같은 발걸음으로 걷고, 질주하고, 점프하고, 활공하는 캐릭터. 그 무엇도 그 자체를 위한 기술 데모가 아니었습니다. 이것을 위한 기반이었습니다.

오늘 오픈 월드가 초기 형태로 라이브 상태입니다. 아바타를 입고 걸어 들어갑니다. 당신이 게시한 게임들이 당신 주변에 방문 가능한 공간으로 나타납니다. 스토어프런트 릴과 Top Performers 차트가 지금 그것들을 보여 주는 방식과 같지만, 이번엔 스와이프가 아니라 두 발로 도착합니다. 세계를 떠나지 않고도 낯선 사람의 게임 안으로 들어갈 수 있습니다. 방금 플레이한 것을 만든 사람 옆에 서서 다음에 무엇을 더하면 좋을지 말해 줄 수 있습니다. 방금 만난 사람과 함께 지형 한 조각을 깎아 새 프로젝트의 씨앗으로 만들 수 있습니다. 발견은 더 이상 피드가 아닙니다. 산책이 됩니다.

우리 엔진은 언제나 기술적 의미에서 게임 엔진이었습니다. 오늘은 문자 그대로의 의미에서도 게임 엔진이 됩니다. 당신의 게임을 만드는 그것이 이제 그 자체로 하나의 게임이고, 3절의 같은 오케스트레이터, 4절의 같은 에셋 레일, 6절의 같은 getGameState 계약, 8절의 같은 릴, 9절의 같은 차트가 모두 당신의 플레이어들이 걸어 다니는 하나의 장소로 합쳐집니다. 만드는 것과 노는 것 사이의 경계는 언제나 인위적이었습니다. 이제 그 경계는 사라졌습니다.

우리가 잘했다고 생각하는 것

첫 번째로 잘한 것은 프롬프트를 제품이 아니라 UI 어포던스로 다룬 것입니다. 제품은 오케스트레이터, 도구 표면, 에셋 레일, 그리고 스토어프런트입니다. 프롬프트는 사용자를 시스템 안으로 들이는 가장 값싼 방법입니다.

두 번째는 빌드 단계가 없는 평평한 브라우저 네이티브 파일 시스템을 고집한 것입니다. Cinevva 게임이 하나의 사실 출처에서 모바일, 데스크톱, Steam, Discord로 출시되는 이유가 이것입니다. 에이전트가 자기가 쓴 것을 읽을 수 있는 이유도 이것입니다.

세 번째는 모든 생성 게임이 getGameState와 setGameState를 구현한다는 계약입니다. 시스템 프롬프트의 그 한 줄이 에이전트를 코드 생성기가 아니라 협력자처럼 느껴지게 만드는 것입니다. 에이전트는 플레이할 수 있고, 플레이할 수 있는 시스템은 디버그할 수 있습니다.

네 번째는 스토어프런트를 엔진과 같은 루프에 연결한 것입니다. 우리는 원시 모델 품질로는 이기지 않을 겁니다. 오픈 웨이트 생성기보다 두 달 앞선다는 데에는 지킬 만한 우위가 없습니다. 우리는 당신의 게임을 만드는 바로 그 에이전트가 그것을 게시하고, 측정하고, 낯선 사람들이 어떻게 플레이했는지에서 배울 때 이깁니다.

기계 전체가 돌아가는 모습을 보고 싶다면, 홈페이지 프롬프트가 여전히 정문입니다. 문장 하나를 입력하세요. 그 뒤에서 무슨 일이 일어나는지 지켜보세요. 그런 다음 여기로 돌아와서 엔진의 어느 부분을 다음에 써 주면 좋을지 알려 주세요.

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

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

13부 이후 모든 spike는 같은 방식을 따랐습니다. 이전 모놀리스를 복사하고, 기능 하나를 더한다. spike 32가 끝날 무렵 그 모놀리스는 단일 <script type="module"> 안에 들어 있는 6,285줄짜리 index.html이었습니다. 코드 검색은 시끄러웠고, 기능을 어디에 추가할지 찾는 게 쓰는 것보다 오래 걸렸으며, 어떤 아키텍처 변경이든 머릿속으로 diff하기엔 너무 큰 파일을 건드려야 했습니다. 다음 기능을 추가하기 전에 우리는 구조라는 빚을 갚았습니다.

동작 변화 없이 모놀리스 쪼개기

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

제약은 엄격했습니다. 모든 분리는 재설계가 아니라 순수한 리팩터링이어야 했습니다. 모놀리스는 19개의 .mjs 파일과 151줄짜리 호스트 셸이 되었습니다. scene, water, grass, character, physics, multiplayer, UI를 위한 최상위 모듈들, 모든 WGSL 소스 문자열을 GPU 진실의 단일 출처로 쥐고 있는 wgsl.mjs, 그리고 heightmap, SDF, chunk, GPU buffer 래퍼, 브러시, LOD, 영속화를 담은 terrain/ 하위 트리로 나뉘었습니다. 전체 코드는 6,555줄이 나왔는데, 기본적으로 모놀리스에 import 보일러플레이트를 더한 것입니다. 분량의 순변화는 없었지만, 탐색 편의성의 변화는 컸습니다.

그런데 페이지가 검은 화면으로 로드됐습니다. 에러 메시지 두 개, 서로 무관한 근본 원인 두 개. 첫 번째는 0바이트 buffer 바인딩에 대한 WebGPU의 불평이었습니다. 모놀리스에서는 SDF 브러시 buffer가 첫 marching-cubes chunk가 나타날 때 지연 할당됐고, bind-group 팩토리는 마침 그 뒤, buffer가 존재한 다음에 돌았습니다. terrain/gpu.mjs를 terrain/brush.mjs에서 분리하면서 모듈 평가 순서가 바뀌었고, 이제 팩토리가 먼저 돌아 null 자리표시자를 바인딩하려 했습니다. 해법은 bind-group 생성을 첫 dispatch까지 미루는 getOrCreateBindGroup(chunk) 헬퍼였습니다. "모든 것을 미리 만들어 두는" 패턴은 모놀리스의 단일 초기화 경로가 남긴 흔적이었습니다.

두 번째 메시지는 무섭게 생긴 FBX 스켈레톤 경고였는데, 알고 보니 헛다리였습니다. spike 25부터 계속 찍혀 왔고 무해했습니다. 캐릭터가 사라진 건 단지 첫 번째 버그가 연쇄됐기 때문입니다. 모든 compute dispatch가 예외를 던졌고, heightmap이 끝내 쓰이지 않았으며, 높이 샘플이 0을 반환했고, 캐릭터가 원점에 스폰돼 세계를 뚫고 떨어졌습니다. buffer를 고치면 캐릭터는 경고를 다 달고도 멀쩡히 애니메이션됩니다.

이게 리팩터링의 진짜 교훈입니다. 모놀리스는 "X는 Y가 만들어지기 전에 존재해야 한다"는 모든 관계를 위에서 아래로 흐르는 스크립트 순서 안에 숨겼습니다. 모듈화가 그 순서를 뒤섞으면서 잠복해 있던 순서 버그 세 개가 더 드러났습니다. 풀이 heightmap 업로드 전에 흩뿌려지는 문제, 물 평면이 환경 맵 디코딩이 끝나기 전에 추가되는 문제, 영속화 로드가 첫 프레임 이후에야 완료되는 문제였습니다. 셋 다 한 줄 수정이었고, 분리하지 않았다면 하나도 잡히지 않았을 것입니다.

무엇도 키우지 않고 소품 백 개 추가하기

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

Spike 34는 그 구조가 값을 했는지 확인하는 시험이었습니다. 목표는 CC0 모델 팩에서 나무, 바위, 덤불, 버섯, 길을 배치하는 1인칭 팔레트였고, 지형 인식 정렬, 영속화, 멀티플레이어 동기화, 물리 콜라이더를 모두 조작을 벗어나지 않고 처리하는 것이었습니다. 새 코드는 한 줄도 빠짐없이 src/props/ 아래 다섯 개의 새 파일에 들어갔고, 기존 모듈은 어느 것도 연결용 코드 열 줄을 넘게 늘지 않았습니다.

에셋 작업은 기록해 둘 만한 우회로를 거쳤습니다. 이런 일은 하루를 통째로 잡아먹기 때문입니다. 우리는 Quaternius의 Ultimate Nature 팩으로 시작했는데, 텍스처가 내장되지 않은 FBX 라이브러리였습니다. FBX 머티리얼은 map 없는 MeshPhong으로 들어와서, 머티리얼 이름을 PNG에 매핑하는 표를 손으로 연결하고, Phong을 Standard로 변환하고, 색 공간을 일일이 설정했습니다. 머티리얼의 약 30%는 맞는 PNG가 없었고, 비슷한 나무들 사이에서 이름이 모호한 것도 몇 개 있었습니다. 두 번째 FBX 팩도 같은 구멍이 있었습니다. 해법은 매핑 표를 더 늘리는 게 아니라 더 잘 만들어진 팩이었습니다. Quaternius의 Stylized Nature MegaKit은 내장 PBR 머티리얼과 베이크된 노멀을 갖춘 완전한 glTF 116개를 제공합니다. FBXLoader를 GLTFLoader로 바꾸자 cm-to-meters 스케일링, 텍스처 표, Phong 변환이 사라졌고 library.mjs가 약 80줄 줄었습니다. 결론은 이렇습니다. PBR이 담긴 glTF는 그것을 제공하는 CC0 팩에 맞는 파이프라인이고, 수동 텍스처 매핑이 붙은 FBX는 코드는 두 배에 품질은 절반이었습니다.

glTF 경로에는 까다로운 부분 몇 가지가 따라왔습니다. 팔레트는 썸네일 116개를 렌더링하는데, WebGPU의 canvas.toDataURL()은 GPUCanvasContext 표면에 대해 빈 값을 반환합니다. 그래서 썸네일은 RenderTarget에 렌더링한 뒤 readRenderTargetPixelsAsync로 다시 읽어 와 2D canvas에 blit하면서 WebGPU의 256바이트 행 정렬을 챙깁니다. 고스트 프리뷰는 각 머티리얼을 복제해 초록색으로 물들이는데, material이 배열인 mesh에서 깨졌고 Array.isArray 분기로 고쳤습니다. 그리고 약 200 MB로 들어온 16비트 노멀 맵은 일회성 mogrify -depth 8로 약 32 MB까지 줄였는데, 어차피 브라우저가 업로드 시 다운샘플링하므로 시각적으로는 똑같습니다.

렌더링되는 지오메트리가 GPU에만 존재할 때

가장 배울 게 많았던 버그는 커서가 움직일 때 고스트 프리뷰가 1~2미터 단위로 툭툭 끊겨 붙는 것이었습니다. 지형 mesh는 정점 위치를 StorageBufferAttribute에 저장합니다. compute 파이프라인이 GPU에서 직접 그것들을 쓰기 때문에 three.js의 CPU Raycaster는 그것들을 볼 수 없고 아무것도 반환하지 않습니다. 폴백은 해석적 heightmap에 대한 거친 1.5 m 레이 마치였고, 그 고정 간격이 바로 사용자가 본 격자였습니다. 우리는 그것을 적응형 마치로 바꿨습니다. 표면 위로 높이 떨어져 있을 땐 간격 2.5 m, 표면 5 m 이내로 들어오면 0.4 m로 줄이고, 그다음 $({\text{ray}}_y-{\text{terrain}}_y)$의 부호가 바뀌면 14번 이분합니다. 이렇게 하면 한 번의 캐스트당 대략 넓은 스텝 30번에 이분 14번으로 1밀리미터 미만 정밀도에 도달합니다. 렌더링되는 지오메트리가 GPU에만 살 때는 raycaster와 싸우지 말고, 해석적 출처에 대고 마치하세요.

편집을 거쳐도 정직하게 남는 콜라이더

우리는 볼록 껍질이나 mesh 콜라이더 대신 프리미티브 프록시를 골랐습니다. Quaternius 소품은 둥글둥글하고 로우폴리이며 의미 있는 오목부가 없어서, 껍질을 쓰면 같은 플레이 경험을 위해 코드는 약 50배, 런타임 비용은 약 10배가 듭니다. 각 소품은 바운딩 박스에서 유도한 하나의 형태로 줄어듭니다. 나무와 선인장은 수직 캡슐, 바위는 구, 통나무는 긴 축을 따라 놓인 수평 캡슐, 장식용 덤불과 꽃은 아무것도 없음입니다. 바위와 통나무는 걸어다닐 수 있고(수직으로만 밀어내서 위에 올라설 수 있음), 나무와 선인장은 막힙니다(완전 3D 밀어내기라 줄기를 타고 오를 수 없음). 8 m 공간 해시가 프레임당 테스트를 플레이어의 3×3 이웃으로, 보통 소품 0~6개로 제한합니다.

두 가지 설계 결정이 시스템을 일관되게 유지했습니다. 지형 정렬은 코드에 하드코딩된 카테고리 열거형이 아니라 매니페스트 플래그입니다. 그래서 고스트 프리뷰와 확정된 배치가 같은 placement.alignToTerrain 값을 읽고 서로 어긋날 수 없습니다. 그리고 이미 배치된 소품은 헬퍼 하나를 통해 지형 편집에 반응합니다. 브러시 스트로크(로컬이든 피어에서 재생된 것이든) 이후 refreshPlacementsInRadius가 영향받은 원판 안에 있는 모든 소품 아래의 지면을 다시 샘플링하고, 정렬을 다시 적용하고, 콜라이더 끝점을 다시 유도합니다. 나무 아래에 언덕을 깎으면 나무가 함께 솟아오릅니다. 영속화와 멀티플레이어는 spike 31의 패턴을 그대로 재사용해, {uid, propId, x, y, z, rotY, scale}의 평탄한 목록을 저장하고 배치, 제거, 미세 조정 이벤트를 BroadcastChannel로 미러링합니다.

이 장에서 다룬 기술

WebGPU에서의 ES 모듈 분해. 모놀리식 <script type="module">을 베어 경로 .mjs import로 쪼개는 건, 모듈을 정적 에셋으로 제공할 때 번들러가 필요 없고, three.js TSL도 모듈 경계를 넘나들며 잘 작동합니다. 숨은 비용은 초기화 순서입니다. 모놀리스는 "X를 Y보다 먼저 만든다"를 위에서 아래로 흐르는 스크립트 순서에 인코딩하지만, 모듈은 import 순서로 평가되어 GPU bind-group 팩토리를 그 buffer가 존재하기 전에 돌릴 수 있습니다. 수정 패턴은 지연 초기화(첫 사용 시 getOrCreate...)와 선언 순서에 기대는 대신 올바른 promise를 await하는 것입니다.

내장 PBR이 담긴 glTF vs 수동 매핑이 붙은 FBX. glTF는 미터 단위로 들어오고, 자기 텍스처를 참조하며, MeshStandardMaterial을 곧바로 줍니다. 그래서 glTF로 만들어진 CC0 팩은 PBR 파이프라인에 바로 들어갑니다. 텍스처 바인딩 메타데이터가 없는 FBX 팩은 팩이 업데이트될 때마다 어긋나는, 손으로 유지하는 머티리얼 이름-PNG 표가 필요하고, 거기에 Phong-Standard 변환과 수동 색 공간 태깅까지 붙습니다. 식생 안전망은 alphaTest가 없는 transparent 머티리얼을 alphaTest: 0.5 컷아웃 카드로 승격시켜, 불투명 지오메트리 뒤에서 제대로 정렬되게 합니다.

WebGPU 오프스크린 썸네일. canvas.toDataURL()은 GPUCanvasContext 기반 canvas에 대해 빈 값을 반환합니다. 프레젠테이션 표면에서 2D 컨텍스트로 돌아오는 경로가 없기 때문입니다. RenderTarget에 렌더링하고, readRenderTargetPixelsAsync로 픽셀을 읽고, 2D canvas에 blit하는 방식은, blit이 WebGPU의 256바이트 정렬 읽기 간격을 따르는 한 잘 작동합니다. 결과는 버전 번호가 붙은 키 아래 localStorage에 캐시되므로 팩이 바뀌면 오래된 렌더가 무효화됩니다.

해석적 heightmap에 대한 적응형 레이 마치. 지형 정점이 GPU StorageBufferAttribute에 살 때 CPU raycaster는 그것들을 볼 수 없습니다. 해석적 높이 함수를 따라, 표면에서 멀 땐 큰 간격으로, 가까울 땐 작은 간격으로 마치하고, $({\text{ray}}_y-{\text{terrain}}_y)$의 부호 전환에서 이진 탐색으로 정밀화하면, 정해진 샘플 수 안에서 1밀리미터 미만의 커서 정밀도를 얻습니다. 같은 프리미티브가 브러시 커서와 소품 고스트를 모두 구동합니다.

공간 해시를 곁들인 프리미티브 캡슐 콜라이더. 각 소품은 바운딩 박스에서 카테고리 기반의 캡슐이나 구로 줄어들어 {kind, walkable, radius, p1, p2}로 기록되고, 겹치는 8 m 해시 버킷마다 등록됩니다. 프레임당 플레이어는 자신의 3×3 버킷 이웃에 있는 소품만 테스트하고, 각각 캡슐 대 캡슐 해소를 한 번씩 합니다. 걸어다닐 수 있는 프록시(바위, 통나무)는 수직으로만 밀어내고, 막는 프록시(나무)는 완전 3D 밀어내기를 받습니다. 이것이 기반으로 삼는 캡슐 수식은 SDF 지형 충돌을 참고하세요.

29부 중 16부. 이전: 15부 - 베이스라인을 교체한 다음, 동기화하기 다음: 17부 - 리타기팅이 필요 없던 애니메이션, 그리고 실시간 에셋 검색 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

글 Mariana Muntean, Cinevva CEO

2022년 5월, 나는 Ted Harrington의 팟캐스트 Tech Done Different과 인터뷰를 했다. 당시 정리된 글은 지금도 Medium에 살아 있다. 그때 나는 Cinevva를 한 2년쯤 운영하고 있었다. 다섯 명, 20만 달러 투자 유치, 벽에 걸린 Mozilla Builders 상, 그리고 게임 개발이 어디로 가고 있는지에 대한 잔뜩 쌓인 의견.

그 의견들은 2022년에 대부분 유행하던 생각이 아니었다. Web3가 시끄러웠고, AAA 스튜디오가 대화를 장악했고, GPT-3는 연구용 장난감이었고, WebGL은 취미로 잼 게임을 만드는 사람들이 쓰는 거였다. "어떤 창작자든 게임 개발자가 될 것이다"라고 소리 내어 말하면 정중한 끄덕임만 돌아왔고 수표는 없었다.

지난주에 나는 그 인터뷰를 다시 읽었다. 일부는 희망 섞인 망상처럼 읽힌다. 일부는 내가 타임머신을 가졌던 것처럼 읽힌다. 가장 잘 늙은 네 가지 베팅과, 그 옆에 놓인 2026년의 실제 모습을 정리한다.

베팅 1: 게임 엔진은 브라우저에 속한다

2022년에 내가 한 말:

WebGL 기술은 모바일 기기를 포함해 여러 플랫폼에서 쓸 수 있다. PC에만 제한될 수 있는 다른 API와 다르다. 그래서 집에서 편하게 있든 이동 중이든, 여전히 만들고 게시할 수 있다. WebGL 게임은 전통적인 PC 게임이 필요로 하는 CPU와 GPU 성능의 일부만 쓴다.

2022년에 이건 통념을 거스르는 베팅이었다. 큰 엔진들은 전부 다운로드, 설치, 패치 사이클을 전제했다. 브라우저 게임은 Flash 향수와 Friv를 뜻했다.

2026년에 우리 오픈 월드 엔진은 브라우저 탭에서 120 FPS로 돌아간다. 지형, 나무, 물리, 멀티플레이어 동기화, 전부 하나의 URL 안에서. 다운로드도, 앱 스토어도, 설치도 없다.

브라우저가 따라잡은 건 세 가지가 한꺼번에 자리를 잡았기 때문이다. WebGPU가 모든 주요 브라우저에 출시됐다. SharedArrayBuffer와 교차 출처 격리가 안정적으로 작동하게 됐다. WebAssembly가 Rust에서 컴파일한 진짜 물리 엔진을 돌릴 만큼 빨라졌다. 우리 팀은 그 각 단계가 실제로 무엇을 치르게 했는지 12부작 현장 일지로 발행했다. 요약하자면, 이제 브라우저는 진짜 게임 런타임이지, 진짜 게임의 데모를 올려놓는 곳이 아니다.

이 베팅 안에서 내가 놓친 베팅: 작업의 얼마나 많은 부분이 엔지니어링 문화 쪽에 있을지를 과소평가했다. 브라우저 게임 엔진은 더 이상 브라우저에 발목 잡히지 않는다. 진짜 게임에는 런처가 있어야 한다는 가정에 발목 잡힌다.

베팅 2: AI는 파이프라인의 일부지, 부가 기능이 아니다

2022년에 내가 한 말:

우리 플랫폼이 매끄럽게 작동하려면 오픈소스 게임 도구를 쓰지만, 동시에 자연어 처리, 컴퓨터 비전, 그리고 대화용 GPT3와 텍스트-이미지 생성용 DALL:E 같은 Open AI 솔루션을 활용해 우리만의 기술도 개발한다.

2022년 5월에 GPT-3는 대부분의 사람이 한 번도 써본 적 없는 유료 API였다. DALL·E는 나온 지 겨우 1년 넘었고 대기 명단이 있었다. 그것들을 프로덕션 게임 개발 도구로 쓰겠다고 말한 건, 잘 봐줘야 야심 찬 코스프레였다.

2026년에 진지한 창작 파이프라인에는 전부 언어 모델과 이미지 생성이 들어가 있다. 우리 것도 마찬가지다. 오늘 Cinevva 내부에는 사운드트랙용 ElevenLabs Music, 효과음용 ElevenLabs SFX, 에셋용 Hunyuan3D와 SAM3D, 비주얼용 Flux, 적응형 오디오용 Mubert, 악기 편성용 AceStep이 있다. 프롬프트가 들어가면 쓸 수 있는 에셋이 나오고, 이 모든 게 에디터 안에서 일어난다.

이 베팅의 증거는 GDC 2026 State of the Game Industry 보고서에 있다. 게임 회사의 52%가 생성형 AI가 프로덕션에서 쓰이고 있다고 말한다. 같은 52%의 개발자가 AI 사용이 업계에 부정적인 영향을 주고 있다고 말한다. 두 숫자 다 사실이다. 핵심은, 그 기반 기술이 누구도 인정하고 싶어 한 것보다 더 빨리 기본기가 됐다는 거다.

내가 틀린 것: 저항은 품질을 걱정하는 엔지니어에게서 올 거라고 생각했다. 대부분은 일자리를 걱정하는 아티스트에게서 왔다. 그 대화는 내가 예상한 것보다 훨씬 더 엉망이고, 이걸 깔끔한 승리로 취급하는 사람들은 제대로 보고 있지 않다.

베팅 3: 게임 개발에는 Google Docs 스타일의 협업이 필요하다

2022년에 내가 한 말:

소스 컨트롤과 앱 버전 작업은 흔히 원격 협업과 엮인다. 오늘 그걸 하려면 어디로 가야 하는지, 어떤 버전의 애플리케이션을 받아야 하는지 알아야 하고, 모두와 동기화돼 있어야 하고, 혹시라도 팀원 한 명이 잘못된 버전의 앱을 쓰고 있으면 문제가 된다. 우리는 Google doc 같은 거의 실시간에 가까운 경험을 목표로 한다. 간단하고, 힘들지 않고, 그러면서 재미있게.

코드 도구에서의 실시간 협업은 2022년에 변두리 아이디어였다. Replit은 그게 있었다. VS Code Live Share도 있었다. 대부분의 전문 엔진은 Perforce, VPN, 그리고 네 브랜치를 옆에서 봐주는 시니어 엔지니어를 필요로 했다.

2026년에 실시간 협업은 진지하게 받아들여지고 싶은 어떤 창작 도구든 기본값이다. Figma는 디자인에서 그걸 당연하게 만들었다. Cursor와 Bolt는 코드에서 그걸 당연하게 만들었다. Lovable은 앱 프로토타이핑에서 그걸 당연하게 만들었다. 게임 엔진은 선두가 아니라 뒤처진 쪽이었다.

우리 자체 엔진 안에서는 이제 멀티플레이어 동기화가 일급 스파이크로 작동한다. 브라우저 안에서 청크 스트리밍, 프레즌스, 공유 상태까지. 그 경험은 "Perforce 설정하고, Slack에 어떤 버전이 맞는지 물어보고, 런처 설치하기"보다 "링크 열고, 바로 들어가기"에 가깝다.

내가 과소평가한 부분: 게임에서 실시간 협업의 가장 어려운 부분은 네트워킹이 아니다. 창작 의도의 충돌 해소다. 두 사람이 같은 레벨을 동시에 편집하는 건 동기화 문제이기 전에 UX 문제이고, 대부분의 도구는 아직 이걸 풀지 못했다.

베팅 4: 미래는 인디다

2022년에 내가 한 말:

게임 콘텐츠를 만들지 못했던 창작자들이 만들 수 있게 될 것이다. 우리는 사람들이 창의성을 인식하고 표현하는 풍부한 새로운 방식을 발견하게 될 것이다. 이번엔 그 과정이 기업이나 대형 AAA 스튜디오만의 통제 아래 있지 않을 것이다. 미래는 인디다.

이건 그 인터뷰에서 가장 낭만적인 문장이었고, 2022년에 가장 무시하기 쉬운 문장이었다. AAA 예산은 그 어느 때보다 높았다. 인디 프로젝트는 그 어느 때보다 가시성을 얻기 어려웠다. 계산은 반대 방향으로 가는 것처럼 보였다.

2026년에 계산이 뒤집혔다. 우리는 A Breaker Belt를 사흘 만에, 두 사람이, 하나의 코드베이스로 웹, 모바일, PC에서 만들었다. 예전엔 작은 팀이 한 분기를 써야 했던 일이다. 솔로 개발자들이 vibing만 하는 게 아니라 진짜로 게임을 내고 있고, Steam Next Fest 2026에는 1인 팀의 출품이 역대 최다였다.

이상한 아이디어가 통하는지 알아내는 비용이 무너졌다. 그게 진짜 변화이고, 나머지 모든 것, 즉 파이프라인 속 AI, 런타임으로서의 브라우저, 실시간 협업은 그것에 봉사한다. 제대로 된 도구를 가진 솔로 개발자는 이제 2018년에 20명짜리 스튜디오가 가졌던 생산 역량을 가진다.

2022년에 내가 충분히 또렷하게 보지 못한 것: 병목이 생산에서 발견으로 옮겨간다. 누구나 게임을 낼 수 있게 되면, 찾아지는 게 어려운 문제가 된다. 그게 다음 베팅들이고, 우리는 그걸 거는 한가운데에 있다.

내가 일부러 틀린 것들

2022년의 몇몇 베팅은 아직 보류 중이거나 수정이 필요하다.

그 인터뷰에서 Web3 쪽은 그래야 했던 것보다 더 시끄러웠다. 암호화와 영지식 증명 부분은 콘텐츠 권리의 기본 요소로서 여전히 유효하다. 토큰과 마켓플레이스 식의 틀은 나쁘게 늙었고, 2022년에 거기에 쏟은 에너지의 많은 부분은 진짜 상승 여지가 있던 AI 도구 쪽에 쓰는 게 나았을 것이다.

나는 또한 "누구나 게임을 만들 수 있다"의 많은 부분이 도구 문제가 아니라 발견과 분배 문제라는 걸 과소평가했다. 만드는 건 이제 쉽다. 찾아지고 돈을 버는 건 여전히 어렵고, 오늘 우리 작업의 대부분은 거기로 간다.

그게 우리가 지금 걸고 있는 베팅이다. 우리는 cinevva.com/play에 TikTok 스타일의 릴스 피드를 막 출시했다. 실제 게임플레이의 세로 스와이프 클립, 각 15초, 예고편도 마케팅 영상도 없다. 뭔가 눈에 들어오면, 한 번 탭하면 브라우저에서 바로 플레이하게 된다. 다운로드도, 설치도, 너와 게임 사이를 막는 튜토리얼도 없다.

이게 인디 개발자에게 중요한 이유는 잔혹한 계산이다. Steam Next Fest 2026에는 역대 최다 출품이 있었는데, 게임당 주의력 예산을 따져보기 전까지는 멋지게 들린다. 대부분의 데모는 노출 1천 회 미만을 얻었다. 스토어 페이지 퍼널은 AI가 더 나쁘게 만들기 전에 이미 망가져 있었다. 게임플레이 자체가 광고인 스크롤-앤-스와이프 표면은 발견 루프를 하나의 동작으로 압축한다. 그건 TikTok이 무명 뮤지션을 청취자 앞에 놓는 것과 똑같은 방식으로 솔로 개발자를 플레이어 앞에 놓는다. 그게 "누구나 낼 수 있다"와 "누구나 성공할 수 있다" 사이에 빠져 있던 조각이다.

원본 인터뷰 전문을 보고 싶다면, 여기 있다. 다시 읽어보니 유용했다. 2022년에 우리가 소리 내어 말한 것의 대부분은 작동하는 로드맵으로 드러났다. 우리가 생각한 것보다 더 빠른 시계 위에서였을 뿐이다.

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

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

열두 부분 동안 우리는 바라볼 수 있는 지형 엔진을 만들었습니다. 그 위를 날아다닐 수 있고, 이음새가 갈라지지 않는 걸 감상할 수 있었죠. 이번에는 그걸 직접 만져보고 싶었습니다.

목표는 간단하게 들렸습니다. 플레이어가 브러시로 지형을 실시간으로 조각하되, 24개의 spike를 들여 쌓아 올린 어떤 시스템도 망가뜨리지 않게 하자. 결국 세 번의 시도, 렌더링 실패처럼 보였지만 사실은 데이터 모델 실패였던 버그 두 개, 그리고 지형 데이터가 어떻게 동작해야 하는지에 대한 근본적인 재고가 필요했습니다.

잘못된 출발 세 번

Spike 25는 쉬운 작업이어야 했습니다. 프로덕션 코드베이스에는 이미 지형 메시에 닿는 레이캐스터가 있었습니다. 배치 도구가 그걸로 오브젝트를 떨어뜨리죠. 브러시 도구도 같은 형태를 따르되, prefab을 생성하는 대신 heightmap 값을 수정할 뿐입니다. 간단합니다.

첫 번째 시도: 프로덕션 world/client/ TypeScript 코드에 직접 만들어 넣었습니다. 새 terrain-brush.ts, chunk.ts 수정, 프로토콜 변경, Vue 컴포넌트 업데이트. 한 시간 안에 어느 정도 동작하는 브러시가 생겼지만, chunk 경계에서 눈에 보이는 법선 불연속이 나타났습니다. 이 버그가 내 브러시 코드인지, 기존 chunk 봉합인지, 아니면 전체 렌더 루프와의 어떤 상호작용인지 구분할 수 없었습니다. spike 방법론이 막으려고 존재하는 게 바로 이 상황입니다. 규칙을 건너뛰었고 그 대가를 바로 치렀습니다. 전부 되돌렸습니다.

두 번째 시도: 독립 spike였지만, Three.js 0.170.0과 WebGL을 집어 들었습니다. 프로덕션 코드가 WebGL을 쓰니 자연스러워 보였죠. 하지만 Spike 13-24는 모두 WebGPU로 옮겨가 있었습니다. WebGL 브러시 spike를 만들면 우리가 옮겨가려는 렌더러가 아니라 레거시 렌더러에서 동작한다는 걸 증명하는 셈입니다. 방향이 틀렸습니다. 다시 시작했습니다.

세 번째 시도: WebGPU, WebGPURenderer, 정점 생성용 컴퓨트 셰이더, Spike 22 스택에 맞춤. 이번엔 아키텍처가 맞았습니다. 브러시 동작 다섯 개가 작동했습니다. 올리기, 내리기, 매끄럽게, 평탄화, 노이즈. 브러시 한 사이클 P95가 M1에서 4ms 아래였습니다.

그리고 이음새 버그는 여전히 있었습니다.

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

죽지 않는 이음새 버그

chunk 간 법선 계산의 표준 해법은 경계 중첩입니다. 각 chunk가 이웃의 데이터를 한 줄 더 저장해서, 경계에서의 법선 계산이 양쪽을 모두 샘플링할 수 있게 하는 거죠. 그렇게 구현했습니다. 이웃의 가장자리 데이터를 확장된 버퍼로 복사했죠. 이음새는 여전히 갈라졌습니다.

수학을 파고들었습니다. chunk A(cx=-1)와 chunk B(cx=0)의 경계에서, 두 chunk 모두 공유 정점에서 같은 법선을 계산해야 합니다. chunk A의 셰이더는 mix(own_col31, own_col32, 0.85)를 샘플링했습니다. chunk B는 mix(neighbor_edge, own_col0, 0.85)를 샘플링했죠. 이건 서로 다른 데이터를 지나는 서로 다른 쌍선형 보간 경로입니다. 경계 데이터가 정확해도, 두 chunk는 같은 점에서 다른 법선을 계산합니다.

바로 이 순간 경계 복사가 진짜 버그가 아니라는 걸 깨달았습니다. 진짜 버그는 데이터 모델이었습니다.

1번부터 24번까지 모든 spike는 height_at()라는 절차적 수학 함수를 썼습니다. 월드 좌표를 넣으면 높이가 나오죠. 깔끔하고, 전역적이고, 상태가 없습니다. 브러시는 수학 함수를 수정할 수 없어서, 그 위에 displacement 버퍼를 얹었습니다. 지형은 이제 height_at(x,z) + displacement[i]가 됐습니다. GPU 셰이더에는 기본 지형용 노이즈 함수 30줄과 변위 오버레이용 쌍선형 보간 코드가 박혀 있었습니다. 평탄화 브러시는 목표 높이를 만들어낼 변위 값을 알아내려고 height_at()를 빼야 했습니다. 두 시스템이 서로 위에 쌓여서, 서로 다른 샘플링 전략으로 서로 다른 걸 계산하고 있었던 겁니다.

이건 실제 게임이 동작하는 방식이 아닙니다. 프로덕션에서는 제작된 지형이 버퍼에 저장된 샘플 데이터입니다. 절차적 함수는 초기 spike에서 편하게 쓴 대역일 뿐이었습니다. 제 역할은 다 했죠. 이제는 적극적으로 버그를 만들어내고 있었습니다.

그걸 죽였습니다.

이제 각 chunk는 실제 높이 값을 담은 heightmap Float32Array를 직접 소유합니다. 생성 시 절차적 노이즈가 그걸 채웁니다. 그 후로 노이즈 함수는 다시는 호출되지 않습니다. 브러시는 저장된 높이를 직접 수정합니다. GPU 셰이더는 하나의 버퍼에서 하나의 함수로 읽습니다. hm_at(i,j). 법선은 같은 데이터에 격자 정렬 중심 차분을 써서 구합니다. 쌍선형 보간의 모호함도 없고, 두 시스템 간 불일치도 없습니다. 셰이더가 90줄에서 40줄로 줄었습니다.

이음새는 저절로 고쳐졌습니다. 공유 가장자리에 있는 두 chunk가 이제 각자의 버퍼에서 같은 이산 높이 값을 읽습니다(경계 중첩에 정확한 이웃 내부 점을 담아서). 같은 데이터가 들어가면 같은 법선이 나옵니다.

이건 브러시에 관한 교훈이 아니었습니다. 브러시가 드러낸 데이터 아키텍처에 관한 교훈이었습니다.

폭발한 메시

Spike 26은 볼류메트릭 쪽 대응물이었습니다. 64세제곱 SDF 볼륨을 브러시로 수정하고, marching cubes로 다시 메싱하기. Spike 25와 같은 질문이지만 3D에서요.

처음 실행했을 때 메시가 폭발했습니다. 긴 가시들이 사방으로 뻗어 나갔죠. 하루를 망친 성게 같았습니다.

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

내가 생성한 MC 케이스 테이블에는 4096개 대신 3840개의 항목이 있었습니다. 전체 테이블은 $256\text{cases}\times 16\text{slots}=4096$인데, 나는 $256\times 15=3840$만 가지고 있었습니다. case 112부터 시작해서 16개 행이 빠진 거죠. 그 인덱스 이후의 모든 조회가 어긋나서, case 번호가 삼각화 데이터와 더는 맞지 않았습니다. marching cubes가 잘못된 항목을 읽으면, 두 끝점이 표면의 같은 쪽에 있는 엣지를 만들어냅니다. 실제로 교차하는 엣지에서는 보간 매개변수

가 $[0,1]$ 안에 떨어집니다. $v_a$와 $v_b$의 부호가 반대이기 때문이죠. 가짜 엣지에서는 둘의 부호가 같아서 $v_b-v_a$가 0에 가깝거나 부호가 뒤집히고, $t$가 $[0,1]$ 밖으로 튀어 정점을 볼륨 한참 바깥에 둡니다. 거기에 잘못된 셀 수백 개를 곱하면 고슴도치가 나오는 겁니다.

해법은 어이없을 만큼 단순했습니다. Spike 12에서 검증된 테이블을 바이트 단위로 그대로 복사하기. 교훈을 얻었습니다. 검증된 사본이 있을 때는 절대 룩업 테이블을 다시 생성하지 마라.

두 번째 버그는 더 미묘했습니다. 매끄럽게 다듬는 브러시는 지형 특징을 부드럽게 만들어야 했습니다. 그런데 날카로운 주름을 만들어냈죠. 문제는 이거였습니다. 나는 모든 SDF 값을 0(등위면)을 향해 끌어당기고 있었습니다. 그러면 매끄러워질 것 같지만, 사실은 거리장을 붕괴시킵니다. 표면 위아래의 복셀이 모두 0으로 몰려서, 브러시 반경 안의 모든 걸 평평하게 눌러버립니다. 경계에서는 매끄럽게 다듬어진 복셀이 다듬어지지 않은 복셀을 만나 단단한 계단이 생깁니다. "매끄럽게" 브러시가 주름 생성기였던 겁니다.

해법은 제대로 된 라플라시안 평활화였습니다. 각 값을 0으로 끌어당기는 대신, 직접 이웃한 6개의 평균을 향해 끌어당기는 거죠.

괄호 안의 항은 이산 라플라시안이고, $\lambda \in (0,1]$는 평활화 강도입니다. 이건 가까운 지오메트리를 평균 내어 표면 형태를 부드럽게 만들면서, 거리장을 붕괴시키는 대신 그 기울기를 보존합니다.

전부 한꺼번에

Spike 27은 통합 관문이었습니다. Spike 24의 전체 파이프라인(heightmap 패치, MC chunk, Transvoxel 이음새, geomorph LOD)을 Spike 25의 샘플 데이터 모델, 그리고 두 가지 브러시 타입과 결합하기.

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

제일 먼저 한 일은 모든 셰이더에서 height_at()를 뜯어내는 것이었습니다. 세 개의 컴퓨트 셰이더(SDF 채우기, heightmap 패치, Transvoxel 이음새)가 이제 같은 129x129 heightmap GPU 버퍼를 바인딩하고, 공유 WGSL 프리앰블을 통해 같은 hm_sample() 쌍선형 보간 함수를 씁니다. 하나의 데이터 소스, 여러 소비자. Spike 1부터 모든 셰이더에 살고 있던 절차적 노이즈 함수가 사라졌습니다.

그러고 나서 흥미로운 문제들이 시작됐습니다.

SDF 브러시가 한 chunk를 MC 모드로 잠그면, 그 chunk와 heightmap 이웃 사이의 Transvoxel 이음새는 heightmap이 아니라 SDF 볼륨에서 샘플링해야 합니다. 이음새 셰이더에 추가 스토리지 버퍼 바인딩과 chunk별 MC 플래그를 더했습니다. 처리할 경계 조합은 네 가지였습니다. HM-HM, HM-MC, MC-HM, MC-MC.

LOD는 또 다른 퍼즐이었습니다. 앞선 spike에서는 MC chunk를 더 낮은 LOD로 전환한다는 게 더 거친 해상도로 SDF를 다시 채운다는 뜻이었습니다. 그걸 스트라이드 기반 샘플링으로 바꿨습니다. SDF 데이터는 전체 해상도(격자 점 65개)를 유지합니다. MC 셰이더는 격자 크기와 셀 개수의 비율로 스트라이드를 계산합니다. LOD0에서는 스트라이드가 1입니다. LOD1에서는 스트라이드가 2가 되어 한 칸 건너 복셀을 샘플링합니다. chunk는 SDF 데이터를 건드리지 않고 자유롭게 LOD를 바꿀 수 있습니다.

가장 만족스러웠던 해법은 동적 수직 chunk 생성이었습니다. chunk 꼭대기 위로 위쪽으로 조각하면, 그 위에 MC 전용 chunk가 새로 나타나고 그 SDF는 아래 chunk의 경계면에서 초기화됩니다. 아래쪽으로 조각해도 마찬가지입니다. 월드가 편집에 맞게 자라납니다.

마지막 함정은 heightmap 브러시가 MC로 잠긴 chunk에 아무 일도 안 하면서 조용히 넘어가는 것이었습니다. HM 브러시는 heightmapCPU를 수정하고 다시 업로드합니다. MC chunk는 더 이상 heightmap에서 읽지 않습니다. 그 SDF가 heightmap으로 채워진 뒤에 따로 갈라졌기 때문이죠. syncHeightmapToSdf()를 추가했습니다. heightmap이 바뀐 뒤, 브러시 반경 안의 MC chunk에 대해 SDF 열을 다시 파생시키고 새 값을 업로드합니다. 이제 두 브러시 타입 모두 두 chunk 타입에서 동작합니다.

우리가 실제로 배운 것

브러시 spike들은 성능 질문에 답하려는 것이었습니다. 조각이 프레임 예산 안에서 돌아갈 수 있는가? 가능합니다. 그게 쉬운 부분이었습니다.

어려운 부분은, 24개 spike 동안 height_at()를 지형의 진실로 써온 게 보이지 않는 의존성을 만들어냈고, 우리가 뭔가를 편집하려는 순간 그게 깨진다는 걸 발견한 것이었습니다. 그 절차적 함수는 깨끗하고 전역적이고 상태가 없었습니다. 더는 지형이 아니게 되기 직전까지는요.

우리가 적어두었고 잊지 않을 규칙들:

1. 지형 높이는 샘플 데이터에서 나온다. chunk가 자신의 버퍼를 소유한다.
2. 절차적 생성은 초기 데이터를 채운다. 그것은 런타임의 진실이 아니다.
3. 브러시는 chunk 데이터를 직접 수정한다. 변위 오버레이를 쓰지 않는다.
4. 법선은 같은 데이터에서 격자 정렬 중심 차분으로 나온다.
5. 경계 중첩(이웃 내부에서 1셀)이 chunk 간 법선을 처리한다.
6. 검증된 사본이 있을 때는 절대 룩업 테이블을 다시 생성하지 않는다.

14부에서는 디버그 지오메트리를 조각하는 걸 멈추고, 그것을 실제 장소처럼 보이고 느껴지게 만들기 시작합니다.

이 장에서 언급한 기술

샘플 heightmap 아키텍처. 지형을 런타임에 절차적 함수로 평가하는 대신, chunk별로 소유하는 데이터로 저장합니다. 각 chunk는 실제 높이 값이 담긴 Float32Array를 가집니다. 절차적 노이즈가 생성 시점에 초기 데이터를 채우고, 그 후로 함수는 다시 호출되지 않습니다. 이로써 수학 기반 지형과 편집 오버레이 사이의 이중 시스템 불일치가 사라지고, 브러시 동작이 단순해지며(저장된 값을 직접 편집), GPU 셰이더가 아주 단순해집니다(버퍼에서 읽고, 격자 정렬 중심 차분으로 법선 계산). 스트리밍이 있는 오픈 월드에서는 이웃에서 1셀 경계 중첩을 가진 chunk별 소유가 표준 방식입니다. 우리의 지형 생성 가이드를 보세요.

SDF 브러시 동작. 부호 있는 거리장을 수정해서 지형을 조각합니다. 더하기(팽창)는 구 주위의 스무스 스텝 감쇠를 씁니다. 빼기(파내기)는 같은 형태를 음수로 합니다. 매끄럽게 다듬기는 라플라시안 평균을 씁니다. 직접 이웃 6개를 읽고 평균을 계산해 그 평균을 향해 끌어당깁니다. 0을 향해 끌어당기는 단순한 방식은 거리장을 붕괴시켜 날카로운 모서리를 만듭니다. 라플라시안 평활화는 특징을 부드럽게 하면서 장의 기울기를 보존합니다. SDF 지형 표현을 보세요.

혼합 데이터 소스를 가진 Transvoxel. MC chunk와 heightmap chunk 경계의 전환 셀은 양쪽에서 서로 다른 데이터를 샘플링해야 합니다. 이음새 셰이더는 네 가지 조합(HM-HM, HM-MC, MC-HM, MC-MC)을 모두 처리하기 위해 chunk별 플래그와 버퍼 바인딩을 가집니다. 한쪽이 MC로 잠겨 있으면, 셰이더는 heightmap을 샘플링하는 대신 SDF 버퍼를 삼선형 보간합니다.

marching cubes를 위한 스트라이드 기반 LOD. chunk의 현재 LOD 레벨과 상관없이 SDF 데이터는 전체 해상도로 저장합니다. MC 셰이더는 SDF 격자 점 수와 MC 셀 수의 비율로 샘플링 스트라이드를 계산합니다. 전체 해상도에서는 스트라이드가 1, 절반 해상도에서는 2입니다. 이로써 SDF 데이터가 LOD 변경에서 분리되어, chunk는 SDF를 다시 만들지 않고 자유롭게 LOD를 전환할 수 있습니다.

14부 중 13부. 이전: 12부 - 링, 하늘 안개, 그리고 다시 해볼 것들 다음: 14부 - 세계가 살아난다 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

처음 오셨나요? 시리즈 가이드를 보세요. spike가 무엇인지 설명하고 모든 파트로 연결됩니다.

13부 이후 우리에겐 조각 기능이 생겼습니다. 지형을 올리고, 동굴을 파고, 절벽을 매끄럽게 다듬는 일을 전부 실시간으로, 이음새가 멀쩡한 채로 할 수 있었죠. 하지만 세계는 기술 데모처럼 보였습니다. 디버그 색으로 칠해진 플랫 셰이딩, 와이어프레임 오버레이, 청크를 구분하려고 LOD 색을 입힌 회색 지오메트리. 편집은 할 수 있었습니다. 느낄 수는 없었죠.

세 개의 spike가 그것을 바꿨습니다. 아키텍처가 바뀐 게 아닙니다. 13부와 똑같은 파이프라인, 버퍼, 이음새 스티칭을 그대로 썼습니다. 우리는 그저 지형이 하나의 장소처럼 느껴지게 하는 레이어를 더했을 뿐입니다. 형태에 반응하는 표면, 그 표면 위에서 자라나는 생명, 그리고 그 위를 걷는 몸 말입니다.

"기술적으로 작동한다"와 "여기 계속 있고 싶다" 사이의 차이는 놀라울 만큼 작았습니다.

절벽을 조각하면 바위로 변하는 걸 지켜보세요

Spike 28은 좁은 질문 하나를 던졌습니다. 트라이플래너 매핑을 쓰는 4레이어 머티리얼이 컴퓨트로 생성한 지형 위에서 프레임 예산을 잡아먹지 않고 돌아갈 수 있을까? 답은 그렇다였지만, 흥미로운 부분은 그다음에 벌어진 일이었습니다.

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

네 개의 절차적 텍스처(풀, 바위, 모래, 눈)를 시작 시점에 FBM 노이즈로 생성합니다. 외부 파일도, 에셋 파이프라인도 없이 그냥 수학과 DataTexture 하나만 씁니다. 머티리얼 가중치는 표면 자체에서 나옵니다. 경사와 고도죠. 수목한계선 아래의 평평한 지역은 풀이 됩니다. 가파른 면은 바위가 됩니다. 낮은 땅은 모래가 됩니다. 높은 봉우리는 눈이 됩니다. 각 원시 가중치는 경사와 고도에 smoothstep을 적용해 나오고, 그다음 프래그먼트마다 정규화되어 $\sum _i{w}_i=1$ 이 되며, 최종 색은 가중 혼합 $\sum _i{w}_i{c}_i$ 일 뿐입니다. 정규화는 바이옴이 겹치는 곳에서 표면이 어두워지거나 과하게 밝아지는 걸 막아줍니다. 트라이플래너 매핑은 삼각형에 의미 있는 UV 좌표가 없는 MC 청크의 UV 투영을 처리합니다.

확신을 준 순간은 이랬습니다. 브러시로 지형을 올려 가파른 절벽을 만들면, 같은 프레임 안에 새 면 위로 바위 텍스처가 나타납니다. 다시 평평하게 누르면 풀이 그 표면을 되찾습니다. 머티리얼은 브러시에 대해 알지 못합니다. 그저 월드 좌표와 표면 법선을 읽을 뿐이고, 그건 지오메트리가 만들어질 때 쓴 것과 같은 데이터입니다. 조각에서 시각으로 이어지는 피드백 루프는 즉각적이고 스크립트로 짠 게 아닙니다.

Spike 8은 한 달 반 전에 WebGL 위의 정적 메시로 지형 머티리얼 비용을 테스트했습니다. Spike 28은 그것이 전체 조각 파이프라인을 깔고 있는 동적 컴퓨트 생성 지형 위에서도 작동한다는 걸 증명합니다. 우리는 이걸 예산에 잡아뒀지만, 모든 게 돌아가는 상태에서 60fps를 유지하는 걸 보는 건 그래도 안심이 됐습니다.

풀 더미 8만 개와 동굴 천장 하나

Spike 29는 게임 개발 본능이 발동한 지점입니다.

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

우리는 젤다의 전설 야생의 숨결 같은 풀을 원했습니다. 폴리곤 수가 아니라 그 느낌이요. 적절한 곳을 덮고, 바람에 흔들리고, 그 사이를 뛰어가고 싶게 만드는 풀 말입니다.

풀 더미 하나는 60도 각도로 교차하는 세 개의 쿼드로 이루어지고, 휘어짐을 위해 수직 세그먼트가 네 개 들어갑니다. 어느 각도에서 봐도 입체적으로 보이는 십자 모양이고 빌보드 트릭은 쓰지 않습니다. 청크당 InstancedMesh 하나, 세계 전체에 8만 더미, 통틀어 대략 240만 개의 풀 정점입니다.

중요한 건 배치입니다. CPU가 각 청크에 걸쳐 흔들린 격자(jittered grid)를 훑으면서 GPU 머티리얼 셰이더가 쓰는 것과 똑같은 경사/고도 로직을 평가합니다. 머티리얼 시스템이 "풀"이라고 하는 곳에 풀이 자랍니다. 바위나 모래가 우세한 곳에서는 밀도가 0으로 떨어집니다. 바닥에 깔린 smoothstep 가중치가 바이옴 경계에서 연속적인 그라데이션을 만들기 때문에 감쇠가 매끈합니다. 경계가 없으니 경계를 알아채지 못합니다.

그다음 작동할지 확신하지 못했던 일을 했습니다. SDF 표면 위의 풀이요. 스캐터 함수는 SDF 볼륨의 각 컬럼을 훑으면서 인접 복셀 사이의 영점 교차를 찾습니다. SDF가 음수에서 양수로 넘어가는 곳에 표면이 있습니다. 표면 법선은 필드의 정규화된 그래디언트 $\hat{n}=\frac{\mathrm{\nabla }\varphi }{\Vert \mathrm{\nabla }\varphi \Vert }$ 일 뿐이고, 복셀 차이로 계산합니다. 경사는 $\arccos (\hat{n}\cdot \hat{y})$, 즉 수직으로부터의 각도입니다. 그게 충분히 완만하면 풀을 놓습니다.

Spike 27에서 SDF 브러시로 동굴을 팝니다. Spike 29로 돌아오면 동굴 천장 위에 풀이 자라고 있습니다. 스캐터 코드는 동굴이 뭔지 모릅니다. 그저 적절한 고도에서 적절한 경사를 가진 표면을 볼 뿐입니다. 그게 오픈 월드 시스템을 만드는 일을 만족스럽게 하는 종류의 창발적 동작입니다.

바람은 TSL 버텍스 셰이더 안의 사인파이고, 잎의 V 좌표로 변조되어 끝은 흔들리고 뿌리는 박혀 있습니다. V를 토글하면 약하게, 강하게, 끄기를 순환합니다. 바람은 전적으로 버텍스 셰이더 안에서 돌기 때문에 8만 더미 전부에서 동시에, CPU 비용 없이 작동합니다.

Spike 7은 5만 개의 풀 인스턴스를 테스트했고 우리는 한계에 부딪힐까 봐 긴장했습니다. Spike 29는 컴퓨트 지형, 이음새 스티칭, 멀티 머티리얼 텍스처링, 브러시 위에 8만 개를 돌립니다. 잎당 정점 수를 줄이는 것보다 InstancedMesh 드로우를 더 적게 묶는 게 여전히 더 중요합니다. Spike 7의 교훈은 그대로 통했습니다.

미뤄둔 게 하나 있습니다. 풀 아래를 조각해도 풀은 갱신되지 않습니다. 인스턴스 행렬은 스캐터 시점에 설정됩니다. 언덕을 골짜기로 조각하면 G를 눌러 다시 스캐터할 때까지 풀이 공중에 떠 있습니다. spike로는 충분합니다. 프로덕션에서는 더티 청크 재스캐터가 필요할 겁니다.

첫 발자국

Spike 30은 제가 계속 다시 찾게 되는 것입니다.

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

물리 라이브러리는 쓰지 않습니다. 120Hz 고정 타임스텝의 커스텀 캡슐입니다. 프로덕션 코드베이스는 웹 워커에서 Rapier를 씁니다(Spike 2가 지연 시간이 괜찮다는 걸 증명했죠). 하지만 이 spike는 충돌 쿼리 자체를 증명해야 했습니다. 캐릭터가 하이트맵 지형을 가로질러 걷고, 조각한 SDF 지형으로 올라서고, 바닥을 뚫고 떨어지지 않을 수 있을까?

핵심은 terrainQuery(x, y, z) 라는 함수입니다. 그 위치가 MC로 잠긴 청크 안에 들어가는지 확인합니다. 그렇다면 CPU SDF 미러를 삼선형 보간하고 그래디언트를 표면 법선으로 반환합니다. 아니라면 중앙 차분 법선을 쓰는 하이트맵 조회로 갑니다. 캐릭터는 자기가 어떤 지형 시스템 위에 서 있는지 모릅니다. 그저 바닥을 묻고 답을 받을 뿐입니다.

SDF 충돌은 어려울 거라 예상했던 부분입니다. 캡슐 둘레의 일곱 개 프로브 포인트(바닥, 중심, 위, 네 개의 기본 방향 오프셋). 위치 $\mathbf{x}$ 의 프로브는 $\varphi (\mathbf{x})<r$ 일 때 침투하고 있으며, 침투 깊이는 $p=r-\varphi (\mathbf{x})$, 밀어내는 방향은 필드 그래디언트 $\hat{n}=\frac{\mathrm{\nabla }\varphi }{\Vert \mathrm{\nabla }\varphi \Vert }$ 입니다. 캡슐이 표면으로 다시 들어가는 걸 막기 위해, 속도를 투영해 안쪽 성분을 상쇄합니다.

이렇게 하면 표면을 따라 미끄러지는 성분만 남습니다. 물리 엔진이 아닙니다. 지오메트리 쿼리와 단순한 반응입니다. 하지만 형태마다 특수 케이스 코드를 하나도 안 쓰고 동굴, 돌출부, 조각한 터널을 다 처리합니다. 10초 전에 판 동굴로 걸어 들어가면 캡슐이 천장 윤곽을 정확히 따라갑니다.

이동 모델은 실용적으로 시작했다가 재미있어졌습니다. 걷기, 달리기, 전력 질주, 점프, 45도 이상에서의 경사 미끄러짐. 그다음 야생의 숨결식 패러글라이더를 넣었더니 spike가 닫고 싶지 않은 무언가로 변했습니다.

공중에서 스페이스를 누릅니다. 중력이 -30에서 -4로 떨어집니다. 낙하 속도는 -3에서 한계가 잡힙니다. 캡슐에서 델타윙 메시가 스케일 보간으로 펼쳐집니다. 왼쪽으로 기울이면 날개가 기웁니다. 캡슐이 향하는 방향이 속도 벡터 쪽으로 자동 정렬되어 항상 가는 곳을 바라봅니다. 스페이스를 놓으면 떨어집니다. 땅에 닿으면 다시 달리고 있습니다.

카메라는 3인칭으로 당겨집니다(P로 토글). 요(yaw) 스무딩과 함께 플레이어 뒤를 따라옵니다. 플레이어에서 카메라까지 레이마치가 20스텝으로 지형을 테스트합니다. 동굴로 날아 들어가면 카메라 암이 바위를 뚫고 들어가는 대신 매끄럽게 짧아집니다. 반대편으로 나오면 다시 늘어납니다.

이 spike를 가치 있게 만든 순간이 여기 있습니다. 하이트맵 브러시로 높은 절벽을 조각합니다. 3인칭 카메라로 전환합니다. 가장자리까지 달립니다. 점프합니다. 글라이더를 펼칩니다. 방금 조각한 지형 위로 왼쪽으로 기울이는데, 아래에는 Spike 29에서 키운 풀이 흔들리고, 절벽 면에는 Spike 28의 바위 텍스처가 깔려 있고, 모든 청크 경계에서 Transvoxel 이음새가 버티고 있습니다. 반대편에 착지합니다. 하나의 브라우저 탭 안에서 모든 게 함께 작동합니다.

내 발밑을 조각하기

확신하지 못했던 게 하나 있습니다. 캐릭터가 서 있는 지형을 조각하면 어떻게 될까? 하이트맵 변경은 terrainQuery()가 CPU 버퍼를 직접 읽기 때문에 즉시 전파됩니다. SDF 변경은 CPU SDF 미러를 통해 전파됩니다. 캡슐은 다음 물리 틱에 침투를 해소하는데, 120Hz에서 그건 $\frac{1}{120}\approx 8.3$ ms 안입니다.

그냥 작동합니다. 플레이어 아래 땅을 올리면 함께 올라갑니다. 땅을 파내면 떨어집니다. 특별한 처리는 없습니다. 물리가 충분히 빠르게 돌아서 단일 프레임의 지형 변경이 큰 침투를 만들지 않습니다. 이건 타임스텝을 120Hz로 고른 데서 온 행복한 우연이었습니다. 우리는 매끄러운 이동을 위해 그걸 골랐는데, 덤으로 지형 편집이 안전해졌습니다.

spike 30개를 지나

우리는 이 시리즈를 평평한 하이트맵과 큐브 500개로 시작했습니다. 이제는 입체적인 동굴이 있는 조각된 지형, Transvoxel 이음새 스티칭, 표면 형태에 반응하는 멀티 머티리얼 텍스처링, 바람에 흔들리는 풀 더미 8만 개, 그리고 그 위를 걷고 전력 질주하고 점프하고 활공하는 캐릭터를 갖췄습니다.

이 중 무엇도 아직 프로덕션에 들어가지 않았습니다. world/client/ 코드베이스는 여전히 단순한 하이트맵 청크로 WebGL을 돌립니다. 이 30개 spike의 모든 것은 독립적인 HTML 페이지 안에 살고 있습니다. 다음은 통합 작업입니다. WebGPURenderer로 마이그레이션하고, 하이브리드 HM/MC 정책을 청크 매니저에 연결하고, 브러시와 머티리얼 시스템을 멀티플레이어에 잇는 일이요.

하지만 이제 렌더링 시스템은 위험이 아닙니다. 열린 질문은 데이터 흐름에 관한 것입니다. 편집 영속성, 브러시 스트로크의 네트워크 동기화, 협업 조각. 삼각형 사이가 아니라 플레이어 사이에서 벌어지는 것들이죠.

1부부터 이 시리즈를 따라오셨다면, 지저분한 부분까지 함께해 주셔서 고맙습니다. 방금 발견하셨다면 1부로 돌아가세요. 잘못 든 길에 교훈이 있습니다.

이 챕터에서 언급한 기술

TSL (Three Shading Language). WebGPU 렌더러를 위한 Three.js의 노드 기반 셰이더 시스템입니다. 머티리얼은 자바스크립트의 함수 합성을 써서 노드(positionWorld, normalWorld, smoothstep, triplanarTexture)로 구성됩니다. 셰이더 그래프는 런타임에 WGSL로 컴파일됩니다. TSL은 WebGPU 타깃에서 원시 GLSL ShaderMaterial을 대체하고, 표준 Three.js 머티리얼 기능(라이트, 그림자, 안개)과 커스텀 프래그먼트별 로직 사이의 상호 운용을 제공합니다.

트라이플래너 매핑. 텍스처를 세 번(XY, XZ, YZ 평면) 샘플링하고 표면 법선 방향에 따라 혼합하는 텍스처 투영 기법입니다. 임의의 메시 지오메트리에서 UV 늘어짐을 없애는데, 이는 삼각형에 의미 있는 UV 좌표가 없는 마칭 큐브 출력에 핵심적입니다. TSL은 triplanarTexture()를 내장 노드로 제공합니다.

교차 쿼드 잎으로 만든 인스턴스 식생. 풀 더미 하나는 60도 각도로 교차하는 쿼드 3개로, 어느 시점에서 봐도 입체적으로 보이게 합니다. 쿼드당 수직 세그먼트 4개가 바람 애니메이션을 위한 매끄러운 휘어짐을 가능하게 합니다. 전체 필드는 청크당 단일 InstancedMesh로 렌더링됩니다. 용량은 25% 초과 할당되어, 지형을 편집할 때 GPU 버퍼를 재할당하지 않고도 새 인스턴스가 예약된 슬롯을 채울 수 있습니다. 식생에 관한 우리 랜드스케이프 생성 가이드를 보세요.

캡슐 대 SDF 충돌. 물리 엔진 없이 입체 지형에 대한 캐릭터 충돌입니다. 캡슐을 SDF에 대해 여러 지점에서 프로브합니다. 필드 값이 캡슐 반지름보다 작은 곳에서, 그래디언트가 바깥쪽 법선을 주고 그 차이가 침투 깊이를 줍니다. 이는 형태별 코드 없이 동굴, 돌출부, 터널을 처리합니다. SDF 지형 충돌을 보세요.

고정 타임스텝 캐릭터 컨트롤러. 물리는 프레임 레이트와 무관하게 120Hz로 스텝을 밟으며, 실제 시간을 누적해 고정 크기 스텝으로 소비합니다. 최대 서브스텝 횟수가 느린 프레임에서 죽음의 나선(spiral-of-death)을 막습니다. 그라운드 스내핑이 경사 이동 중에 캡슐을 붙여둡니다. 고정 타임스텝은 향후 멀티플레이어 리플레이를 위한 결정론적 동작을 보장합니다.

29부 중 14부. 이전: 13부 - 지형 조각과 수학 함수의 죽음 다음: 15부 - 베이스라인을 교체한 다음 동기화하기 시리즈 가이드: /blog/2026-02-25-open-world-browser-series-guide

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

처음 보시나요? 시리즈 가이드를 보세요. 스파이크가 무엇인지 설명하고 모든 부분을 링크해 두었습니다.

앞선 열네 개 부분은 스파이크 1부터 30까지를 다뤘습니다. 그 흐름은 실시간으로 조각할 수 있는 지형 시스템과, 그 위를 걷고 활공하고 떨어질 수 있는 캐릭터로 마무리됐습니다. 이번 부분은 스파이크 31에서 시리즈를 다시 이어갑니다. 그리고 우리가 가장 먼저 결정해야 했던 건 기술적인 게 아니었습니다. 그 수많은 스파이크 코드를 어떻게 할 것인가였습니다.

"교체하라, 백포트하지 마라"는 결정

우리에겐 각각 하나의 고립된 개념을 증명하는 독립 HTML 파일 30개가 있었고, 통합은 전혀 되어 있지 않았습니다. 프로덕션의 world/client/는 여전히 옛 스택이었습니다. WebGL, 단순한 heightmap, 75줄짜리 캐릭터 컨트롤러, 메시지 타입이 아홉 개인 MessagePack 프로토콜. 편집도, WebGPU도, 머티리얼도, 식생도 없었습니다.

뻔한 계획은 스파이크 결과물을 그 프로덕션 코드베이스에 하나씩 백포트하는 것이었습니다. 우리는 그걸 버렸습니다. 스파이크 30은 이미 world/client/가 도달했던 그 어떤 것보다도 나은 지형, 물리, 머티리얼, 식생, 카메라를 갖고 있었습니다. 옛 WebGL 코드에 백포트한다는 건 처음부터 끝까지 그 코드와 싸운다는 뜻이었습니다. 그래서 우리는 결정을 내렸습니다. 가장 성공적인 스파이크로 월드 구현을 교체하고 거기서부터 앞으로 만들어가기로요. 스파이크 30이 새 기준선이 되었고, world/client/는 죽은 코드가 됐습니다.

이 결정이 남은 작업을 다시 짰습니다. "멋진 싱글플레이어 기술 데모"에서 "제품"으로 가려면 멀티플레이, 영속성, 무한 월드 스트리밍, 오브젝트 배치가 필요했습니다. 멀티플레이 지형 동기화를 먼저 했습니다. 그것이 아키텍처를 강제하는 작업이기 때문입니다. 그것이 답하는 질문은 묻기는 쉽고 틀리면 비싼 질문입니다. 플레이어 A가 조각할 때, 실제로 회선을 타고 가는 건 무엇인가?

픽셀 동기화가 아닌 브러시 파라미터 재생

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

네트워크 코드를 한 줄 쓰기 전에, 우리는 브러시 스트로크 하나가 정확히 무엇을 하는지 따라가 봤습니다. heightmap 브러시는 커서 주변 반경을 CPU의 Float32Array에서 돌면서 smoothstep 감쇠를 적용하고, 더하거나 빼거나 부드럽게 하거나 평평하게 만듭니다. SDF 브러시는 복셀 구체 위에서 3D로 같은 일을 합니다. 두 경로 모두 순수한 CPU 배열 연산입니다. 루프 안에 GPU 컴퓨트도 없고, 무작위성도 없고, 비결정적 부동소수점도 없습니다. 같은 입력 배열에 같은 파라미터면 모든 기계에서 같은 출력입니다.

이게 비결의 전부입니다. 우리는 편집된 지형을 보내지 않습니다. 브러시 파라미터를, 스트로크 틱당 56바이트를 보내고, 모든 클라이언트가 같은 결정적 함수를 재생합니다. 동기화 프로토콜은 네 가지 메시지 타입입니다. 피어 발견, 브러시 메시지 {op, wx, wy, wz, radius, strength, flattenTarget}, 그리고 20Hz의 플레이어 위치 메시지.

이 스파이크에서는 서버를 아예 건너뛰고 BroadcastChannel을 썼습니다. 동일 출처 탭 간 메시징을 위한 브라우저 API입니다. 탭 두 개를 열면 서로 통신합니다. 인프라는 전혀 없습니다. 이렇게 하면 동기화 문제를 지연, 인증, Durable Object 배선에서 떼어내 격리할 수 있습니다. 파라미터 재생이 탭 사이에서 수렴한다면, WebSocket 너머에서도 수렴할 겁니다.

재생이 어긋날 수 있는 유일한 지점은 순서에 의존하는 연산입니다. 올리기와 내리기는 교환 가능해서, val + strength * falloff는 누가 먼저 적용했든 같은 자리에 떨어집니다. 부드럽게 하기와 평평하게 하기는 이웃 값을 읽기 때문에, 두 클라이언트가 정확히 같은 지점을 같은 순간에 부드럽게 하면 틱당 수천분의 1밀리미터씩 어긋날 수 있습니다. 실제로는 그런 일이 절대 발생하지 않고, 프로덕션에서의 수정 방법은 이미 분명합니다. 편집을 DO로 라우팅하고, DO가 단조 증가하는 시퀀스 번호를 할당하게 하고, 클라이언트에서는 낙관적으로 적용하고, 권위 있는 시퀀스가 다르면 순서를 바로잡으면 됩니다. 전형적인 낙관적 동시성 제어이고, 어차피 DO는 자연스러운 직렬화 지점입니다.

계속 사라지던 피어 캡슐

편집은 첫 시도에 동기화됐습니다. 원격 플레이어의 캡슐은 아니었습니다. 다른 탭에서 있다가 없다가 깜빡였고, 그것이 견고하게 남도록 만드는 데 서로 다른 버그 세 개를 잡아야 했습니다.

캡슐은 월드 원점에서 스폰됐는데, 그곳은 지형 아래에 묻혀 있습니다. join 메시지가 어떤 위치 데이터보다도 먼저 도착하기 때문입니다. 수정: 숨긴 상태로 시작하고 첫 위치 업데이트에서 드러나게 합니다. 위치 브로드캐스트는 렌더 루프 안에 있었는데, Chrome은 포커스가 없는 탭에서 requestAnimationFrame을 스로틀링합니다. 그래서 다른 탭의 만료 검사가 피어를 거둬가고 다음 메시지가 그것을 다시 만들어냈습니다. 수정: 브로드캐스트를 setInterval로 옮깁니다. 이건 보이는 탭에 대해 스로틀링되지 않습니다. 그리고 만료 타임아웃이 5초로 너무 공격적이어서 어떤 GC 일시정지에도 걸렸습니다. 수정: 30초로 올리고 정상 종료에는 깔끔한 leave 메시지에 의존합니다.

영속성과 늦은 합류, 같은 포맷

우리는 영속성을 새 스파이크를 띄우는 대신 같은 스파이크 안에 접어 넣었습니다. 목적지가 IndexedDB든 다른 탭이든 직렬화 포맷이 동일하기 때문입니다. 스냅샷 하나는 전체 heightmap(129×129 Float32Array, 약 66 KB)에, 편집된 SDF 청크(각 ${65}^3$, 약 1.1 MB)만, 그리고 marching-cubes 모드로 잠긴 청크 ID 목록을 더한 것입니다. 디바운스된 저장이 마지막 편집 2초 뒤에 IndexedDB에 씁니다. 로드 시에는 절차적 지형이 동기적으로 생성되고, 그다음 저장된 상태가 첫 의미 있는 프레임 전에 그것을 덮어씁니다. 늦은 합류는 정확히 같은 바이트를 재사용합니다. 새 탭이 합류하면 편집이 있는 기존 탭이 자기 상태를 직렬화해 새로 온 쪽을 겨냥해 보내고, 5분 전에 당신이 조각한 산이 그들의 화면에 나타납니다.

첫 영속성 테스트가 괜찮은 순서 버그를 드러냈습니다. 풀은 초기화 때 절차적 높이를 써서 동기적으로 흩뿌려지는데, IndexedDB 복원은 비동기이고 그 후에 heightmap을 덮어씁니다. 그래서 모든 풀잎이 공중에 뜨거나 가라앉았습니다. 수정은 refreshAllGrass() 패스로, 각 인스턴스 아래의 높이를 다시 샘플링하고 이제 나쁜 경사나 고도에 놓인 풀잎을 숨깁니다. 같은 함수가 로드와 늦은 합류 둘 다를 맡습니다.

경사 연속극

조각된 지형은 매끈한 절차적 기준선보다 거칠어서, 옛 지형이 절대 일으킬 수 없던 물리 버그 세 개를 드러냈습니다. 똑바로 언덕을 올라가면 캡슐이 옆으로 미끄러졌습니다. 원인은 이동을 지면에 접하도록 유지하려던 속도 투영이었는데, 법선의 수평 성분만으로 작성되어 있었습니다. 법선이 $(-0.3,0.9,-0.3)$인 대각선 경사에서 북쪽으로 걸으면 난데없이 옆 방향 속도가 주입됐습니다. 지면 스냅이 이미 플레이어를 표면에 붙여두기 때문에, 우리는 그냥 그 투영을 지웠습니다.

드리프트는 두 번째 원인에서 계속 이어졌습니다. SDF 충돌 프로브는 침투 깊이만큼 그래디언트 방향으로 몸을 밀어냅니다. 어떤 경사에서든 그래디언트는 수평 성분을 가지므로, 15° 경사에서 0.1 m 침투는 한 스텝당 옆으로 약 0.026 m를 밀고, 120Hz에서는 대략 3 m/s의 보이지 않는 드리프트가 됩니다. 수정: 경사에 따라 반응을 나눕니다. 걸을 수 있는 지면(${\text{grad}}_y$가 걷기 임계값 위)에서는 밀어내기가 수직 방향만입니다. 벽과 절벽에서는 완전한 3D 밀어내기를 유지합니다. 거기가 바로 튕겨나가고 싶은 곳이기 때문입니다. 우리는 또 걸을 수 있는 한계를 $\cos 45°$에서 $\cos 60°$로 올려서, 브러시로 만든 언덕이 젤다 야생의 숨결에서처럼 오를 만하게 느껴지도록 했습니다.

세 번째 버그는 청크 경계에서 캡슐을 얼어붙게 했습니다. 충돌 프로브가 단일 청크의 SDF만 샘플링하다가 프로브가 이웃으로 넘어가면 "공중 깊숙이"라는 센티넬 값을 받았기 때문입니다. 수정은 sdfSampleWorld(wx, wy, wz)와 sdfGradientWorld(...)였습니다. 이들은 임의의 월드 위치에 대해 올바른 청크를 찾고, SDF가 없는 곳에서는 heightmap 거리 추정으로 폴백합니다. 이제 SDF에서 heightmap으로의 충돌 전환은 연속적입니다.

물이 월드를 완성한다

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

여기까지의 모든 스파이크는 "물 위의 땅"이었습니다. 스파이크 32는 바다를 추가했고, 그와 함께 새 이동 동사를 추가했습니다. 우리는 대략 8에서 58까지 범위인 지형에서 수위를 22로 설정했습니다. 이렇게 하면 낮은 골짜기가 잠기고, 물가에 해변이 남고, 놀기에 충분한 마른 땅이 남습니다.

수면은 TSL로 만든 MeshStandardNodeMaterial로, 지형과 같은 노드 방식입니다. 서로 다른 주파수의 겹쳐진 사인파 세 개가 정점을 변위시키고, 표면 법선은 메시 법선이 아니라 그 파동들의 해석적 코사인 도함수에서 나옵니다. 색은 $[0,1]$로 클램프된 깊이 추정값 $(\text{level}-y+\text{wave})\times 0.12$를 써서 청록색 얕은 물에서 짙은 틸색 깊은 물로 섞이고, 그 추정값이 물가에서 0에 가까워지는 곳에서 거품이 일어나며, 알파는 깊이를 따라가서 얕은 물은 투명하게 깊은 물은 거의 불투명하게 보입니다.

수영은 부력 스프링입니다. 발이 수위 아래로 내려가고 몸 중심이 표면으로부터 캡슐 반높이 이내에 있을 때 플레이어가 수영 모드에 들어갑니다. 스프링이 몸을 표면 바로 아래의 목표로 끌어당기고, 부력 상수 12 대 물 감쇠 4면 플레이어가 머리를 내놓은 채 흔들림 없이 안정적으로 둥실거립니다. 수영 속도는 걷기보다 느리고 둥실거리는 가속과 항력이 붙으며, 수면 근처에서 점프하면 정상 점프 속도의 60%로 물 밖으로 솟구치고, 입수 시 하강 속도를 -5 m/s로 막아 곤두박질치지 않게 합니다. 지형 충돌은 물속에서도 여전히 작동하므로, 호수 바닥이 수영 목표보다 위로 올라온 곳에서는 걸을 수 있습니다. 수영 플래그는 위치 브로드캐스트에 함께 실려서 피어들이 당신이 수영하는 걸 볼 수 있고, 카메라가 수면 아래로 잠기면 HTML 그래디언트 오버레이가 화면을 물들입니다.

이 장에서 다룬 기술

결정적 브러시 파라미터 재생. 편집된 지형을 스트리밍하는 대신, 각 클라이언트는 브러시 파라미터만 보내고 같은 CPU 함수를 재생합니다. heightmap과 SDF 브러시 둘 다 무작위성이나 GPU 비결정성이 없는 순수한 Float32Array 연산이라서 동일한 입력이 어디서나 비트 단위로 동일한 출력을 만들어내기 때문에 가능합니다. 페이로드는 스트로크 틱당 56바이트입니다. 교환 가능한 연산(올리기, 내리기)은 순서와 무관하게 수렴하고, 이웃을 읽는 연산(부드럽게 하기, 평평하게 하기)은 수렴을 보장하기 위해 직렬화 지점이 필요한데, 이는 프로덕션의 Durable Object가 단조 시퀀스 번호로 제공합니다.

WebSocket 대역의 BroadcastChannel. 서버가 전혀 없는, 동일 출처 탭 간 메시징용 브라우저 API입니다. 여기서는 동기화 프로토콜을 네트워크 지연과 인증에서 격리해 테스트하는 데 썼습니다. 직렬화 포맷(원본 Float32Array heightmap 더하기 편집된 SDF 청크 더하기 MC로 잠긴 청크 ID)은 IndexedDB 영속성과 늦은 합류 상태 전송에 쓰이는 바로 그 바이트라서, 한 포맷이 세 가지 일을 담당합니다.

경사 분할 SDF 충돌 반응. 캡슐 프로브가 볼류메트릭 지형을 침투할 때, 순진한 수정은 침투 깊이만큼 SDF 그래디언트 방향으로 몸을 밀어냅니다. 경사에서는 그 그래디언트가 수평 성분을 가져 측면 드리프트를 주입합니다. 반응을 나눠서 걸을 수 있는 표면(${\text{grad}}_y$가 임계값 위)은 수직 방향만 밀어내고, 가파른 표면은 완전한 3D 밀어내기에 속도 투영까지 유지하면, 벽 충돌을 잃지 않으면서 드리프트를 제거합니다. SDF 지형 충돌을 보세요.

해석적 파동 법선을 쓰는 TSL 물. 바다는 정점이 합산된 사인파 세 개로 변위되는 노드 머티리얼입니다. 변위 후 메시 법선을 다시 계산하는 대신, 표면 법선은 파동 함수의 코사인 도함수에서 해석적으로 유도합니다. 이게 더 저렴하고, 거친 그리드에서 유한 차분 법선이 만드는 아티팩트를 피합니다. 깊이 기반 색, 물가 거품, 깊이 기반 투명도는 모두 단 하나의 깊이 추정값에 기반합니다.

부력 스프링 수영. 수영 물리는 몸을 표면 바로 아래의 목표로 끌리는 감쇠 스프링으로 모델링합니다. 부력 상수 12, 감쇠 4면 플레이어가 흔들림 없이 수면에 자리를 잡습니다. 별도의 이동 상수(더 느린 속도, 둥실거리는 가속, 무거운 항력)가 수영에 걷기와 다른 느낌을 주고, 기존의 캡슐 대 지형 충돌이 물속에서도 계속 작동합니다.

29부 중 15부. 이전: 14부 - 세계가 살아난다 다음: 16부 - 계속 자라는 세계를 위한 구조 시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

스케치-비디오-3D 파이프라인과 Kali the Kitty(Cubcoats)를 기반으로 합니다. 라이선싱, 블로그, 또는 파트너 피칭용.

PDF로 공유하기: 이 페이지를 연 다음 브라우저의 파일 → 인쇄 → PDF로 저장을 사용하세요.

Golden Tree — 전체 원페이저

태그라인: 당신과 함께 자라는 세계. 방문하고, 물을 주고, 지켜보세요. 레벨도 없고, 부담도 없습니다.

무엇인가

현실 세계의 시간에 맞춰 변화하는 차분하고 수집 가능한 세계입니다. 하나의 공유된 "시즌"(예: 봄 섬): 아이들이 돌아다닐 수 있는 단일 3D 섬입니다(플레이 가능한 Kali 데모처럼). 전통적인 레벨이나 점수는 없습니다. 진행은 당신의 나무에 새 가지가 자랐어요, 12개의 순간을 봤어요, 누군가 당신의 씨앗에 물을 줬어요 같은 식입니다.

방문할 때마다 아이는 다음을 할 수 있습니다. 식물 하나에 물 주기, 소원 하나 남기기(텍스트나 이모지), 숨어 있는 Cubcoats 캐릭터 하나 찾기, 또는 30초짜리 "순간" 하나 보기(예: 황금 나무 아래의 Kali). 새로운 순간과 작은 이야기 단락은 매주 공개됩니다(에피소드형). 선택적인 은은한 언어: "오늘 Kali가 말했어요: [영어와 중국어로 한 줄]."

학습과 성장은 잠재적으로 이루어집니다. 주제(친절, 인내, 다시 도전하기)는 수업이 아니라 글과 그림 속에 담겨 있습니다. 이 경험은 학교가 아니라 장난감이나 함께하는 공간처럼 느껴집니다.

핵심 루프

1. 섬을 방문합니다(브라우저나 앱).
2. 방문할 때마다 부드러운 행동 하나를 합니다. 물 주기, 소원 빌기, 캐릭터 찾기, 또는 순간 보기.
3. 며칠에서 몇 주에 걸쳐 세계가 변하는 것을 봅니다(새로운 꽃, 새로운 캐릭터 포즈, 새로운 짧은 클립).
4. 친구에게 씨앗을 공유하거나 "친구의 섬을 방문"해서 성장이 사회적으로 느껴지게 합니다.

이 글의 파이프라인과 캐릭터를 어떻게 활용하는가

• 3D 플레이 가능한 세계: Kali 데모와 같은 파이프라인입니다. T-pose → 3D Model Generator → 리깅 → Cinevva Engine. 섬과 캐릭터는 탐험 가능하고, 3인칭이며, 부담이 적습니다.
• 황금 나무: 글에서 직접 가져왔습니다(Kali의 "두려움에서 희망으로" 단락과 마법 같은 황금 나무). 이 나무는 시즌의 감정적이고 시각적인 중심입니다.
• 짧은 "순간": 글의 세로형 숏폼처럼 제작합니다. 시작 프레임 + 끝 프레임 + 모션 프롬프트 → Video Generator (Kling 3.0 Pro), 9:16, 약 15초. 매주 공개되는 각 콘텐츠는 하나의 작은 이야기 단락입니다.
• Cubcoats IP: Kali와 나머지 일곱 캐릭터, 섬 세계, 그리고 따뜻하고 둥근 아트 스타일. 디지털 에피소드형 제품과 함께 라이선싱 중심의 재출시(2026)에 잘 맞습니다.

왜 바이럴이 될 수 있는가

• 낮은 진입 장벽: 링크 하나, 복잡한 온보딩 없음. "친구에게 씨앗을 보내세요"는 간단한 공유입니다.
• 차분하고 아름다운 클립: 짧은 순간들은 그 자체로 공유하기 좋습니다(소셜, "이 15초만 봐"). 긍정적인 방식으로 밈이 되기 좋습니다.
• 에피소드형: "이번 주에 뭐가 새로 나왔지?"가 재방문과 대화를 만듭니다.
• 잠재적: 부모는 "차분하고, 창의적이고, 광고 없고, 스트레스 없음"을 봅니다. 아이는 명시적으로 배우지 않으면서도 루틴, 인내, 그리고 잔잔한 놀라움을 얻습니다.

가능한 Cinevva 블로그 앵글

"우리는 Kali를 스케치에서 비디오로, 그리고 돌아다닐 수 있는 캐릭터로 만들었습니다. Golden Tree는 다음 단계입니다. 실시간으로 자라는 세계에서 아이들이 방문하고, 물을 주고, 짧은 순간을 봅니다. 레벨도 없고, 부담도 없습니다. 같은 파이프라인. 새로운 형식."

Kali's Word Island — 한눈에 보기

핵심 아이디어: Cubcoats 섬은 캐릭터 구역으로 나뉩니다(Kali의 숲, 다른 캐릭터의 해변). 아이들은 영어/중국어를 이해하고 만들어내야 하는 짧은 과제를 하며 캐릭터를 돕습니다. 진행은 "씨앗 → 묘목 → 나무 → 황금 나무"입니다(구역의 나무가 다 자라면 다음 구역이 열림). 매일 하는 "랜턴" 런, 수집 가능한 문구 카드, 캐릭터 "기분" 바, 선택적인 부모 대시보드. 짧은 이야기 순간(시작/끝 프레임 스타일)은 구역을 완성하면 열립니다. 파이프라인: 캐릭터와 감정적 단락을 위한 동일한 3D + 비디오 파이프라인.

Cubcoats: Island Stories — 한눈에 보기

핵심 아이디어: 아이들이 분기를 선택하는 에피소드형 내러티브(Kali는 뭐라고 말할까? 어디로 갈까?). 주된 활동은 리믹스입니다. 캐릭터, 장소, 2–3개의 단락을 골라서 짧은 "에피소드"를 만듭니다(대본 + 간단한 비주얼, 또는 이후에는 AI 생성 숏폼). 학습은 잠재적입니다(대사와 선택 속의 어휘와 패턴). 소셜: 당신의 에피소드를 공유하고, 다른 사람의 버전을 플레이하고, "친절함 / 재미 / 의외성"을 평가합니다. 파이프라인: 사용자가 만든 "순간"을 위한 동일한 캐릭터 룩 + 두 프레임 비디오 파이프라인; 캐릭터/세계 일관성을 위한 3D.

참조한 Cinevva 도구: Image Generator, Video Generator (Kling 3.0 Pro), 3D Model Generator, 자동 리깅, Cinevva Engine. "스케치에서 비디오, 그리고 플레이 가능한 3D까지"(2026-03-04)에서 설명한 파이프라인을 반영합니다.

글 Mariana Muntean, Cinevva CEO

Cinevva 팀은 최근 게임 개발 분야에서 보기 드물게 투명한 엔지니어링 일지 중 하나를 공개했습니다. 멀티플레이어 오픈 월드를 전적으로 브라우저 안에서 돌리려는 우리의 시도를 기록한 12부작 시리즈입니다. 다운로드도 없고, 앱스토어도 없습니다. 그냥 URL 하나면 됩니다.

이 프로젝트는 우리가 "spike"라고 부르는 24개의 기술 실험으로 이어졌습니다. 각각은 위험한 질문 하나에 답하도록 설계된 짧고 집중적인 프로토타입입니다. 모든 spike는 지금 당장 브라우저에서 열어 실행할 수 있는 실제 소스 코드와 함께 공개되었습니다. 이 시리즈는 Cinevva의 CTO이자 공동 창업자인 Oleg Sidorkin이 썼고, 마케팅 글이라기보다 2026년의 브라우저가 실제로 무엇을 할 수 있는지를 최전선에서 적은 현장 일지에 가깝습니다.

이 시리즈가 읽을 가치가 있는 이유는, 설령 지형 시스템을 만들 계획이 전혀 없더라도, 그 밑에 깔린 방법에 있습니다. 비싼 데 발을 들이기 전에 야심 찬 프로젝트의 위험을 어떻게 줄일 수 있는지 보여 주는 사례 연구입니다.

가장 어려운 질문부터 시작하기

대부분의 오픈 월드 프로젝트는 예측 가능한 순서로 죽습니다. 먼저 멋진 콘셉트가 나옵니다. 그다음 예쁜 장면이 나옵니다. 그러고 나서 게임플레이가 존재하기도 전에 프레임 예산이 이미 다 소진됐다는 걸 발견합니다.

우리 팀은 순서를 뒤집었습니다. 첫 번째 spike는 일부러 투박하게 만들었습니다. 512미터 지형 메시, 인스턴스화된 오브젝트 500개, 절차적 높이 노이즈, 물 평면, 그리고 안개. 그림자도 없고 미술 패스도 없었습니다. 유일한 질문은 카메라가 그 안을 이동하는 동안 브라우저가 안정적인 프레임 레이트를 유지할 수 있는가였습니다.

가능했습니다. 그리고 그 "예"는 Oleg가 "베이스라인 계약"이라고 부르는 것을 확립했습니다. 최소한의 장면에 대한 측정된 기준 비용으로, 이후의 모든 기능은 이에 비추어 스스로를 정당화해야 했습니다. 새로운 효과가 멋져 보여도 프레임 예산을 터뜨리면, 그건 출시되지 않았습니다. 적어도 아직은 아니었죠.

이런 종류의 규율은 당연한 소리처럼 들립니다. 하지만 실제로는, 모두가 다음 시각적 성과에 들떠 있는 빠르게 움직이는 프로토타입 환경에서는 드뭅니다.

물리라는 도박

두 번째 실험은 브라우저 게임 개발자들 사이에서 의견이 갈리는 아키텍처 논쟁을 다뤘습니다. 물리는 더 간단한 메인 스레드에서 돌려야 할까요, 아니면 렌더링을 막지 않는 Web Worker에서 돌려야 할까요?

Worker 기반 물리는 서류상으로는 더 깔끔합니다. 실제로 두려운 건 지연입니다. 모든 입력 이벤트는 메시지 경계를 두 번 넘어야 합니다. 한 번은 Worker에 도달하기 위해, 한 번은 결과를 가져오기 위해. 그 왕복이 너무 느리면, 키를 누르고 캐릭터가 움직이는 걸 보는 것이 굼뜨게 느껴질 겁니다.

팀은 Rapier 물리 엔진(Rust에서 WebAssembly로 컴파일됨)을 전용 Worker에 통합하고, 메시지 파이프라인을 연결한 뒤 측정했습니다. 오버헤드는 무시할 만한 수준이었습니다. 조작은 여전히 즉각적으로 느껴졌습니다. 하지만 우리는 보편적인 규칙이 아니라 특정한 시나리오 하나를 검증한 것이라는 점을 신중히 기록해 두었습니다. 나중에 GPU 부하와 스트리밍 복잡도가 바뀌면, 그 가정들은 다시 점검해야 할 터였죠.

프로젝트를 구한 따분한 spike들

시리즈의 3부에는 스크린샷이 하나도 없습니다. 화려해 보이지 않지만 제품 수준의 결과를 안고 있던 세 가지 실험을 다룹니다.

첫 번째는 Cloudflare Durable Objects가 게임 수준의 틱 레이트로 실시간 위치 브로드캐스트를 처리할 수 있는지 시험했습니다. 멀티플레이어의 근간이죠. 이것이 실패했다면, 전체 네트워크 아키텍처는 단일 아일랜드 소유 방식 대신 일찌감치 샤딩이 필요했을 겁니다.

두 번째는 모바일 품질 프로파일을 검증했습니다. 이름만 바꾼 데스크톱 프리셋이 아니라, 같은 지형 베이스라인에서 나온 명시적인 저비용 렌더링 경로였습니다. 질문은 렌더러를 다시 쓰지 않고도 모바일 GPU 제약 아래에서 월드가 읽기 좋고 반응성 있게 유지될 수 있는가였습니다.

세 번째는 크리에이터 워크플로를 위한 AI 생성 동작 스크립트가 프로덕션에 쓸 만큼 신뢰할 수 있는지 평가했습니다.

이 중 어느 것도 데모 영상을 만들어내지 않았습니다. 셋 다 이후의 모든 아키텍처 결정을 형성한 단단한 경계를 세웠습니다. Oleg는 이 "화려하지 않은 spike들이 시각적 spike들보다 더 빠르게 아키텍처를 바꿨다"고 씁니다.

스트리밍: 예쁜 프로젝트가 무너지는 지점

정지된 한 프레임에는 많은 것을 숨길 수 있습니다. 하지만 달리는 도중 청크 경계를 넘을 때 생기는 40밀리초의 끊김은 숨길 수 없습니다.

팀은 고급 지형을 만들기 전에 스트리밍을 시험하며 관심사를 의도적으로 분리했습니다. Spike 6은 단순한 콘텐츠로 이웃 청크 로딩을 검증했습니다. 그 깨끗한 신호를 얻은 뒤에야 Spike 11이 점진적 정제 방식의 압축 하이트맵 스트리밍을 도입했습니다. 먼저 17 샘플 해상도로 지형을 로드하고, 그다음 33, 그다음 전체 65 샘플 그리드 순서로요.

순서가 예상보다 더 중요했습니다. 만약 압축 높이 청크부터 곧장 시작했다면, 모든 끊김이 모호했을 겁니다. 디코드 문제였을까, 텍스처 업로드 지연이었을까, 아니면 지오메트리 업데이트 문제였을까? 단순한 스트리밍을 먼저 시험한 덕분에 불확실성의 한 범주 전체를 제거할 수 있었습니다.

실용적인 교훈 하나가 나왔습니다. 업로드 지연은 평균 FPS를 통해서가 아니라 직접 측정하라는 것입니다. 평균은 프레임 스파이크를 숨기고, 플레이어가 실제로 느끼는 건 바로 그 프레임 스파이크입니다.

비주얼 예산 전쟁

세 개의 별도 실험이 렌더링 비용을 한데 묶지 않고 따로따로 공략했습니다. 식생 밀도와 바람 애니메이션. 절벽 면을 위한 삼면 매핑(triplanar mapping)이 적용된 멀티 레이어 지형 머티리얼. 현실적인 지형 부하 아래의 캐스케이드 섀도 맵.

식생 spike는 인스턴스를 더 적은 메시로 배칭하는 것이 잎 하나당 폴리곤 수를 줄이는 것보다 더 중요하다는 점을 드러냈습니다. 머티리얼 spike는 수직면에 대한 삼면 투영이 GPU 비용을 들일 가치가 있지만, 다섯 번째 텍스처 스플랫 레이어를 추가하는 건 그렇지 않다는 걸 알아냈습니다. 섀도 spike는 1024 해상도의 캐스케이드 3개가 2밀리초의 GPU 시간을 넘기지 않으면서 받아들일 만한 접촉 그림자를 제공한다고 판단했습니다.

팀은 단도직입적인 규칙을 채택했습니다. 어떤 기능은 측정된 프레임 타임 데이터로 자기 비용을 설명할 수 있을 때만 앞으로 나아간다는 것이죠. 초기에 정해 둔 그 제약 덕분에, 볼류메트릭 지형과 클립맵을 둘러싼 이후의 아키텍처 결정이 훨씬 깔끔해졌습니다.

프로젝트의 궤도를 바꾼 전환점

Spike 10 이전까지 우리의 머릿속 모델은 "더 큰 월드는 더 많은 지오메트리를 뜻한다"였습니다. Spike 10 이후에는 "일정한 지오메트리 예산, 카메라 중심의 링 업데이트"가 됐습니다.

지오메트리 클립맵, 즉 카메라를 중심으로 한 동심원 형태의 지형 링들이고 각 링은 점점 거칠어지는데, 이는 그리기 거리와 상관없이 삼각형 수가 대체로 일정하게 유지된다는 뜻이었습니다. 실용적인 요령은 링 경계에서의 지오모핑이었습니다. 셰이더에서 정점 높이를 부드럽게 섞어, 해상도 레벨 간의 전환이 움직이는 중에는 보이지 않게 하는 거죠.

미묘한 교훈은 테스트 방법에서 나왔습니다. 클립맵은 스크린샷에서는 멀쩡해 보입니다. 그 아티팩트는 링 경계를 가로지르는 지속적인 카메라 이동 아래에서만 드러납니다. 팀은 일정한 속도로 이동하며 시간적 노이즈를 살피는 데 시간을 들였습니다. "스크린샷은 거짓말을 했다"고 Oleg는 씁니다. "진실을 말한 건 움직임이었다."

지하로 내려가기

하이트맵은 동굴을 표현할 수 없습니다. 그리드의 한 점마다 하나의 고도 값만 저장하니까요. 터널, 돌출부, 깎인 암벽이 필요한 순간, 볼류메트릭 지형이 필요해집니다.

Spike 12는 WebGPU 컴퓨트 셰이더를 사용해 GPU에서 marching cubes를 구현했고, 3D 부호 거리장(signed distance field)에서 삼각형 메시를 추출했습니다. 64 큐브 청크 네 개가 애니메이션되는 SDF 편집으로부터 프레임마다 메시를 갱신하며 동시에 돌아갔습니다. 컴퓨트 셰이더가 모든 것을 처리했습니다. 필드 평가, 셀 분류, 정점 방출까지, CPU 리드백 없이요.

도전은 그걸 동작시키는 게 아니었습니다. 다른 모든 것과 함께 동작시키는 것이었습니다. Three.js 씬 그래프와의 통합, 버퍼 수명 관리(WebGPU 버퍼는 크기를 변경할 수 없습니다), 아직 처리 중인 GPU 리소스를 파괴하지 않기 위한 펜스 처리. 시리즈는 우리가 "점진적 강화(incremental hardening)"라고 부르는 것에 두 개의 전체 부를 할애합니다. 한 번에 하나의 기능을 추가하고, 추가할 때마다 이전 레이어가 여전히 동작하는지 확인하는, 화려하지 않은 과정 말이죠.

이음매 악몽

시리즈에서 기술적으로 가장 험난한 부분은 9부에서 11부에 걸쳐 있고, 서로 다른 해상도의 지형 청크가 만날 때 무슨 일이 벌어지는지를 다룹니다.

고해상도 청크가 저해상도 청크 옆에 놓이면, 독립적으로 생성된 두 메시는 경계에서 맞아떨어지지 않습니다. 그 결과 눈에 보이는 균열, 깜빡이는 가장자리, 그리고 빛이 새어 드는 T자 접합이 생깁니다. Transvoxel 알고리즘은 해상도 차이를 잇는 특수한 전환 셀로 이를 해결합니다. 하지만 모든 청크 구성에 걸쳐, 일관된 와인딩 순서, 적절한 버퍼 관리, 정확한 그리기 범위로 그것을 올바르게 구현하는 일은 여섯 개의 별도 실험을 잡아먹었습니다.

팀에서 가장 기억에 남는 디버깅 이야기는 이렇습니다. 이틀 동안 우리가 전환 로직 탓이라고 믿었던 이음매 아티팩트를 쫓았습니다. 진짜 범인은 오래된 데이터였습니다. GPU 컴퓨트 셰이더가 버퍼에 N개의 정점을 썼는데, 그리기 호출은 여전히 이전 프레임의 N+M개 정점을 렌더링하도록 설정돼 있었습니다. 그 여분의 정점들이 쓰레기 값을 담고 있어서 면도날처럼 얇은 삼각형들이 깜빡였던 거죠. 한 줄 수정으로 해결됐습니다. 그리기 범위를 원자 카운터의 활성 정점 수로 잘라낸 것입니다.

"렌더링 버그는 흔히 메싱 버그인 척한다"고 Oleg는 짚습니다. "지오메트리는 처음부터 내내 맞았다."

혼돈에서 거버넌스로

이음매 전투를 치른 뒤, 팀은 임시방편의 청크 동작을 명시적인 정책 시스템으로 대체했습니다. 이제 중앙 함수가 각 청크의 LOD 레벨, 렌더링 모드(하이트맵인지 marching cubes인지), 그리고 어느 면에 전환 셀이 필요한지를 결정합니다. 거리 링이 기본 LOD를 정했습니다. 인접성 제약이 이웃한 두 청크가 해상도 레벨에서 하나 이상 차이 나지 않도록 보장했습니다. 편집 비트맵은 크리에이터 수정이 담긴 볼류메트릭 청크를 거리와 상관없이 marching-cubes 모드로 유지했습니다.

색으로 구분한 디버그 오버레이, 즉 하이트맵 청크는 초록, marching cubes는 파랑, 전환 면은 주황으로 표시한 것은 "저 능선 근처 어딘가에서 버그를 봤다"를 "버그가 북서쪽을 향한 (142, 12, -67) 위치에서 나타난다"로 바꿔 놓았습니다.

"정책이 복잡도를 줄이지는 않았다"고 Oleg는 씁니다. "복잡도를 정리했다."

이 모든 것이 만들어낸 결과

마지막 spike는 클립맵 링, 프래그먼트별 하늘 안개(각 지형 프래그먼트 방향의 실제 스카이박스 색을 샘플링), 그리고 Three.js 모듈 배선을 하나의 통합된 데모로 결합했습니다. 그 결과는, 근거리 볼류메트릭 편집, 중거리 하이트맵 청크, 원거리 클립맵 링을 모드와 LOD와 전환을 다스리는 정책 레이어 아래에 겹쳐 놓은 지형 시스템입니다.

시리즈는 Oleg가 앞으로 어떤 프로젝트에서든 반복하겠다고 말하는 교훈들로 마무리됩니다.

• 기능 작업에 앞서 위험 spike부터 시작하라. 콘텐츠 파이프라인에 투자하기 전에 "우리가 이걸 할 수나 있나?"라는 질문부터 처리하라.
• 통합 점프 전에 검증된 베이스라인을 동결하라. 깨끗한 체크포인트를 세우는 데 들인 하루는, 나중에 회귀를 이분 탐색하는 여러 날을 아껴 준다.
• 최적화 마라톤 전에 정책과 관측 가능성을 강제하라. 트리거 규칙이 있는 이름 붙은 조건은 매번 정체불명의 버그를 이긴다.
• 스크린샷이 아니라 움직임 속에서 테스트하라. 팝, 깜빡임, 스트리밍 끊김은 모두 정지된 프레임 안에 숨는다.
• 평균 FPS가 아니라 기능별 프레임 타임을 측정하라. 평균은 사용자가 실제로 느끼는 스파이크를 숨긴다.
• 지저분한 부분을 공개하라. 잘못 든 길, 헛다리, 엉뚱한 시스템을 탓한 이틀. 사람들이 실제로 배울 수 있는 건 바로 그런 부분이다.

이것이 Cinevva를 넘어 왜 중요한가

이 시리즈는 한 회사의 지형 파이프라인을 넘어서는 세 가지 이유로 의미가 있습니다.

첫째, WebGPU 컴퓨트 셰이더, WebAssembly 물리, 그리고 엣지에 배포된 Durable Objects가 어떤 문턱을 넘었음을 보여 줍니다. 볼류메트릭 지형, 실시간 편집, 스트리밍 LOD를 갖춘 멀티플레이어 오픈 월드가 2026년에 브라우저 탭 안에서 아키텍처적으로 실현 가능합니다. 2년 전에는 사실이 아니었습니다.

둘째, spike 방법론, 즉 각각이 위험한 질문 하나를 살아 있고 측정 가능한 결과로 답하는 작고 집중된 실험들은, 잘 안 될 수도 있는 무언가를 시도하는 어느 팀에게나 하나의 템플릿을 제공합니다. 투자하기 전에 측정하고, 통합하기 전에 베이스라인을 세우고, 최적화하기 전에 엣지 케이스에 이름을 붙이는 규율은 지형 시스템을 훌쩍 넘어서 적용됩니다.

셋째, 그 과감한 투명성이 바로 핵심입니다. 막다른 길과 이틀짜리 디버깅 우회로까지 포함해 24개 실험 전부의 소스 코드를 공개한 것은, 이것을 단순한 기술 블로그 이상으로 만듭니다. 독자를 고객이 아니라 동료로 대하는 공개 엔지니어링 노트인 셈이죠.

전체 시리즈는 우리 시리즈 가이드에서 볼 수 있고, 모든 spike가 브라우저에서 실시간으로 돌아갑니다.

이 글은 원래 Medium에 게시되었습니다.

글쓴이 Oleg Sidorkin, Cinevva CTO

평면 스케치 속 캐릭터를 플레이 가능한 3D 게임으로 만들려면 예전에는 콘셉트 아티스트, 3D 모델러, 리거, 애니메이터, 그리고 그 모든 걸 엔진에서 엮어 줄 사람이 필요했습니다. 우리는 그 파이프라인 중 얼마만큼을 Cinevva의 창작 도구가 스스로 처리할 수 있는지 보고 싶었습니다. 그 결과는 다음과 같습니다.

캐릭터는 Cubcoats의 Kali the Kitty입니다. Cubcoats는 Nordstrom, Amazon, Disney Store를 통해 100만 개가 넘는 봉제 인형 후디를 판 어린이 브랜드입니다. Cubcoats에는 뚜렷한 성격을 가진 여덟 명의 오리지널 캐릭터와 가상의 섬 세계, 그리고 14건의 특허가 있습니다. 이들은 2026년에 라이선싱 우선 플랫폼으로 다시 출발하는데, 우리는 그 IP가 실물 제품을 넘어설 때 어떤 모습이 되는지 보여 주고 싶었습니다. 세로형 영상 숏폼과 브라우저에서 직접 걸어 다닐 수 있는 리깅된 3D 캐릭터죠. 아래의 모든 것은 그 탐색에서 나온 실제 결과물입니다.

3D 뷰어를 드래그하면 캐릭터 주위를 돌려 볼 수 있습니다. 필름 스트립을 스크롤하면 세로형 숏폼이 첫 프레임에서 마지막 프레임까지 어떻게 움직이는지 볼 수 있습니다.

평면 책 아트에서 돌려 볼 수 있는 캐릭터로

Cubcoats에는 이미 아름다운 2D 일러스트가 있었습니다. Mimi Chao의 아트 디렉션은 모든 캐릭터에 따뜻하고 둥글고 손으로 그린 듯한 느낌을 주었고, 이는 후디나 그림책에 완벽하게 어울립니다. 하지만 평면 아트는 3D 파이프라인에 먹이로 들어가지 못합니다. 우리는 영상 생성, 메시 제작, 리깅을 위한 참고용으로 버틸 수 있는 고품질 캐릭터가 필요했고, 그 모든 것을 같은 얼굴 하나에서 뽑아내야 했습니다.

먼저 원본 책 일러스트를 이미지 생성기에 넣고 같은 캐릭터의 3D 렌더링 버전을 만들어 달라고 했습니다.

비율이 유지되고, 성격이 살아나고, 부드러운 3D 카툰 느낌이 이후 모든 도구에 일관된 기준점을 주었습니다. 거기서부터 정확한 포즈와 구도를 반복해 다듬어, 고정된 히어로 레퍼런스를 확보했습니다.

T-포즈가 중요한 이유는 리깅이 팔이 몸통에서 떨어져 있기를 기대하기 때문입니다. 이걸 건너뛰면 자동 리거가 팔을 몸에 붙여 버리고 포기합니다. 우리는 고정한 같은 캐릭터 룩에서 T-포즈를 생성해, 모든 단계에서 실루엣과 비율이 일관되게 유지되도록 했습니다.

무엇이든 생성하기 전에 먼저 스토리를 써라

영상 도구를 건드리기 전에 우리는 쉬운 말로 비트 시트를 썼습니다. Cubcoats 세계관에서 Kali의 성격 특성은 "긍정적"입니다. 모두가 소속감을 느끼게 해 주고, 상황이 어려워져도 밝음을 잃지 않는 캐릭터죠. 그래서 그 특성을 중심으로 10초짜리 흐름을 짰습니다.

Kali가 작고 빛나는 랜턴을 들고 밤의 어둡고 안개 낀 숲으로 걸어 들어간다. 겁이 난 Kali는 혼자 주저앉아 거의 포기하려 한다. 그때 뒤에서 마법 같은 황금빛 나무가 빛나기 시작하는 것을 발견한다. 경이로움, 기쁨, 쏟아져 내리는 황금빛 입자들. 한 호흡 사이에 두려움에서 희망으로.

전체 줄거리는 이게 다입니다. 복잡할 필요가 없습니다. 하나의 감정 전환을 하나의 연속된 샷에 담아내야 시작 프레임과 끝 프레임이 실제로 이어질 수 있습니다.

전체를 양 끝에서 받쳐 주는 두 프레임

그 줄거리에서 이미지 생성기로 핵심 스틸 두 장을 생성했습니다. 세로형 숏폼에 맞춘 세로 비율로요. 프롬프트는 같은 캐릭터를 서로 다른 두 순간에 묘사합니다.

시작 프레임 프롬프트:

3D animated Pixar-style render of Kali, a small pink kitty character with large round dark eyes, pink pointed ears, a light pink belly, and a cheerful round face. She is standing at the edge of a dark misty forest at night, holding a tiny glowing lantern in both paws. Her ears are slightly flattened and her expression is nervous but determined. Cinematic lighting with cool blue moonlight from above and warm orange glow from the lantern. Dense fog between dark tree trunks in the background. Camera angle: medium shot, slightly low looking up at her. No text, no watermark.

끝 프레임 프롬프트:

3D animated Pixar-style render of Kali, a small pink kitty character with large round dark eyes, pink pointed ears, and a light pink belly. She is standing in front of a massive magical tree covered in glowing golden flowers, arms outstretched wide, beaming with a huge joyful smile. Golden petals float in the air around her. The tree radiates warm golden light that illuminates the entire forest clearing. Starry night sky visible above. Camera angle: wide shot from slightly below, epic reveal composition. No text, no watermark.

Seedance가 이 두 양 끝점 사이를 보간합니다. 캐릭터 묘사를 두 프롬프트에서 동일하게 유지해, 모델이 같은 인물임을 알도록 했습니다. 바뀌는 것은 장면, 감정, 카메라뿐입니다.

영상은 예상보다 더 잘 나왔다

두 프레임을 모두 Cinevva의 영상 생성기에 불러오고, Seedance 1.5 Pro를 골라, 9:16 비율과 15초로 설정하고, 줄거리를 모션 프롬프트에 입력한 다음 Generate를 눌렀습니다.

클립은 두 양 끝점 사이를 보간합니다. 네이티브 오디오는 같은 패스에서 함께 생성됐습니다. 타임라인을 따라 샘플링한 프레임들입니다.

왼쪽에서 오른쪽으로: 생성된 세로형 숏폼의 진행.

정확한 마무리 포즈를 맞추는 게 중요할 때는 시작 프레임에 끝 프레임을 더하는 방식이 맞았습니다. 더 긴 감정 흐름에는 영상 생성기의 Kling 3.0 Pro 스토리보드 모드에서 단일 레퍼런스에 프롬프트를 더하는 방식이 잘 통했습니다. 작업마다 다른 설정을 쓰는 거죠.

같은 캐릭터, 이번엔 3D로

여기서부터 흥미로워집니다. 영상 레퍼런스와 같은 계열의 T-포즈 스틸을 우리의 3D 모델 생성기에 넣어 이미지-투-3D 생성을 돌렸습니다. 게임 메시를 영상과 픽셀 단위로 맞추는 게 아닙니다. 맞추는 건 플레이어의 기억입니다. 게임 속 캐릭터가 릴 속 캐릭터와 같은 성격으로 느껴져야 합니다. 그리고 시작 단계에서 하나의 시각적 정체성을 고정해 두었기 때문에, 실제로 그렇게 됐습니다.

3D 모델 생성기는 텍스처가 입혀진 GLB를 출력합니다. 게임에 바로 쓸 수준은 아니지만 누가 봐도 Kali입니다. 실루엣이 맞았습니다. 재질도 비슷했습니다. 다음 단계로 넘어가기에 충분했습니다.

직접 돌려 보세요

3D 모델 생성기의 원본 출력입니다. 리그 없이 텍스처가 입혀진 메시뿐입니다. 그 옆은 같은 캐릭터를 자동 리깅하고 걷기 애니메이션을 베이크한 결과입니다.

리깅과 애니메이션

3D 모델 생성기는 메시를 줍니다. 그 메시를 움직이게 하려면 스켈레톤과 애니메이션이 필요합니다. 우리 플랫폼은 리깅을 자동으로 처리합니다. GLB를 업로드하면 전체 애니메이션 라이브러리가 딸린 리깅된 모델을 돌려받습니다. 걷기 사이클, 가만히 숨 쉬기, 점프 등 게임 캐릭터에 필요한 모든 것이요.

기본 걷기 애니메이션은 거의 맞아 보였지만, 완전하지는 않았습니다. Kali의 팔이 몸에 너무 가까이 붙었고 머리가 살짝 어긋난 각도로 기울었습니다. 둘 다 일반적인 휴머노이드에는 말이 되지만 둥근 카툰 고양이에게는 어색했습니다. 그래서 게임 코드에 런타임 본 보정을 추가했습니다. 팔을 바깥으로 밀어내는 어깨 오프셋과 기울기를 펴 주는 머리 회전 보정이요. 작은 손질이지만 차이가 컸습니다. 이게 없으면 Kali는 뻣뻣하고 로봇 같아 보였습니다. 적용하니 다시 Kali처럼 보였습니다.

브라우저에서 캐릭터 플레이하기

리깅된 모델을 Cinevva Engine에 떨어뜨렸습니다. 3인칭 카메라, WASD 이동, 곳곳에 흩어진 수집 아이템, 가만히 있을 때 도는 오빗 카메라. 애니메이션 블렌딩을 제대로 맞추는 데는 반복이 필요했습니다. 대기와 걷기 사이 크로스페이드, 높이 정규화, 전방 축 수정, 본 오프셋 조정이요. 캐릭터 뒤를 따르는 3인칭 카메라가 스케치에서 직접 걸어 다닐 수 있는 무언가까지의 고리를 닫아 줍니다.

직접 해 보세요. WASD로 이동합니다.

내일 이걸 해 볼 사람에게 해 주고 싶은 말

생성 도구를 건드리기 전에 캐릭터 룩 하나를 먼저 고정하세요. 그 레퍼런스를 제대로 잡는 데 쓰는 1분이 나중에 일관성을 쫓느라 쓸 한 시간을 아껴 줍니다.

먼저 짧은 줄거리를 쓰세요. 그런 다음 이미지 생성기로 시작 프레임과 끝 프레임을 생성하세요. 레퍼런스 이미지는 API 크기 제한 안에 두세요. 3D 모델 생성기에 넣을 때는 같은 디자인 체계에서 나온 T-포즈를 쓰세요.

두 프레임을 모두 영상 생성기에 넣고 보간하게 하세요. 게임 메시는 플랫폼을 통해 모델을 리깅하고, 기본 애니메이션이 캐릭터 비율에 잘 맞지 않으면 런타임에 본 오프셋을 손보세요.

2년 전에는 이 파이프라인이 존재하지 않았습니다. 팀과 예산이 필요했죠. 지금은 스케치 한 장과 Cinevva의 창작 도구만 있으면 됩니다. 누가 캐릭터에 생명을 불어넣을 수 있는가에 있어 의미 있는 변화라고 생각합니다.

사용한 Cinevva 도구: 이미지 생성기, 영상 생성기, 3D 모델 생성기, 자동 리깅, 그리고 Cinevva Engine. 2026년 초 기준입니다.

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

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

우리는 전적으로 브라우저에서 돌아가는 멀티플레이어 오픈 월드를 만들고 있습니다. 설치도 없고, 앱 스토어도 없고, 그냥 URL 하나뿐입니다. 처음부터 가장 큰 위험은 분명했습니다. 브라우저가 게임플레이, 물리, 네트워킹을 위한 여유를 남겨두면서 지속적인 3D 월드를 플레이 가능한 프레임 레이트로 렌더링할 수 있을까?

대부분의 오픈 월드 프로젝트는 예측 가능한 순서로 실패합니다. 먼저 괜찮은 콘셉트가 나옵니다. 그다음 예쁜 장면이 나옵니다. 그러다 게임플레이가 존재하기도 전에 프레임 예산이 이미 다 떨어졌다는 걸 깨닫습니다.

우리는 다른 어떤 것에도 투자하기 전에 렌더 예산이라는 질문에 먼저 답하고 싶었습니다. 그래서 Spike 1은 예쁜 트레일러를 건너뛰고 곧장 측정으로 갔습니다.

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

설정은 의도적으로 단순하게 했습니다. 512미터 지형 mesh, 층을 쌓은 sine 노이즈에 섬 감쇠를 더한 절차적 높이, 수면 평면, 대기 안개, 그리고 인스턴스화된 객체 500개. 평범한 WebGL과 Three.js, ACES 톤 매핑을 썼고, 그림자는 켜지 않았습니다.

우리는 그것이 어떻게 보이는지에는 관심이 없었습니다. 카메라가 장면 안을 움직일 때 장면이 안정적으로 유지되는지에 관심이 있었습니다.

이 spike에서 두 가지가 나왔고, 그것이 프로젝트 전체를 만들었습니다.

첫째, 첫 패스를 절제 있게 유지하면 데스크톱에서는 진짜 여유가 있다는 걸 확인했습니다. 덕분에 나중에 더 어려운 지형 아키텍처를 시도할 자신감이 생겼습니다.

둘째, 기준선 계약을 만들었습니다. 이후의 모든 spike는 이 장면 대비 자신의 비용을 설명해야 했습니다. 새 기능이 보기에는 좋아도 비용이 너무 크면 승격되지 못했습니다.

그 기준선 규율은 나중에 우리가 이음새 아티팩트, 혼합 LOD 전환, 컴퓨트 기반 메싱에 부딪혔을 때 결정적인 역할을 했습니다. 안정적인 기준이 없으면 모든 버그가 실제보다 더 커 보입니다.

2부에서는 렌더링에서 입력 감각으로 넘어갑니다. Worker 물리는 아키텍처 문서에서는 멋지게 들립니다. 하지만 그건 키를 눌렀을 때 캐릭터가 여전히 즉각적으로 느껴질 때에만 의미가 있습니다.

이 장에서 다룬 기술

Heightmap 지형. 각 셀이 높이 값 하나를 저장하는 2D 격자입니다. GPU가 버텍스 셰이더에서 평평한 mesh를 변위시켜 지형 표면을 만듭니다. Heightmap은 작고(65x65 chunk가 16비트에서 약 8 KB), GPU 친화적이며 렌더링이 빠릅니다. 한계는 동굴, 돌출부, 또는 자기 위로 접히는 어떤 표면도 표현할 수 없다는 점입니다. heightmap 제약과 그 이후에 무엇이 오는지에 대한 배경은 지형 생성 가이드를 보세요.

Three.js. 이 프로젝트 전반에서 사용한 렌더링 라이브러리입니다. Three.js는 WebGL 2(이후에는 WebGPU)를 카메라, 조명, 머티리얼, 지오메트리 객체가 있는 씬 그래프로 추상화합니다. 같은 지오메트리의 여러 복사본을 단일 draw call로 렌더링하는 InstancedMesh, 프러스텀 컬링, PBR 머티리얼, 후처리를 제공합니다. GitHub의 Three.js를 보세요. Three.js가 브라우저 오픈 월드 스택에 어떻게 들어맞는지는 브라우저 3D 기술 가이드를 보세요.

InstancedMesh. 같은 지오메트리의 복사본 N개를 단일 draw call로 렌더링하는 Three.js 기능으로, 각각 다른 위치/회전/스케일을 갖습니다. 인스턴스별 변환은 행렬 속성 버퍼에 저장됩니다. 이것이 Spike 1에서 별도의 draw call 500개 없이 객체 500개를 렌더링한 방식입니다. 대규모 식생을 위해서는 GPU 기반 인스턴스 컬링이 이를 한 단계 더 밀어붙입니다. GPU 식생 컬링에 관한 지형 가이드를 보세요.

프레임 예산. 60 fps에서 각 프레임은 모든 것을 위해 $\frac{1000\text{ms}}{60}\approx 16.7$ ms를 가집니다. JavaScript 로직, 물리, 렌더링, 합성까지요. "예산 점검" spike는 기준 장면이 그중 얼마를 소비하는지 측정합니다. 그래서 이후에 추가하는 모든 것에 남는 여유는 $t_{\text{features}}=16.7-t_{\text{baseline}}$가 됩니다. 기준선이 이미 12 ms를 먹는다면, 게임플레이와 물리, 네트워킹을 모두 합쳐 약 4.7 ms만 남습니다. 이 접근은 AAA 오픈 월드 개발에서 왔으며 GTA V, Skyrim, Elden Ring 모두 고정된 프레임 예산 안에 머물기 위해 공격적인 LOD와 스트리밍을 사용합니다.

12부 중 1부.
다음: 2부 - Worker 물리와 입력 지연에 대한 두려움
시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

브라우저 멀티플레이어를 충분히 오래 만들다 보면 결국 이 논쟁을 만나게 됩니다.

"물리를 worker에 두면 아키텍처가 깔끔하다. 물리를 메인 스레드에 두면 더 안전하게 느껴진다."

둘 다 맞을 수 있습니다. 정말 중요한 건 실제 입력에서의 조작감과 지연입니다.

Spike 2는 의견이 아니라 측정으로 그 질문에 답하기 위해 만들었습니다.

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

우리는 Spike 1의 지형을 재사용하고 Rapier를 전용 module worker에 통합했습니다. 입력 상태를 매 프레임 worker로 보내고, 시뮬레이션은 그쪽에서 한 스텝 진행했으며, 권위 있는 위치를 렌더러로 다시 받아왔습니다.

핵심 지표는 입력부터 눈에 보이는 움직임까지의 지연, 그리고 물리 스텝 타이밍이었습니다. 또한 일반 이동, 스프린트 버스트, 점프 케이던스에서 지터가 생기는지도 지켜봤습니다.

결과는 예상보다 좋았습니다. 우리의 메시지 형태와 케이던스에서는 worker 경계가 지연을 좌우하지 않았습니다. 조작은 여전히 즉각적으로 느껴졌고, 그것이 플레이어가 신경 쓰는 유일한 부분이었습니다.

이 단계에서 한 가지 어려움은 해석의 위험이었습니다. 성공적인 결과가 나오면, 팀은 종종 지나치게 일반화해서 아키텍처 질문이 영원히 끝났다고 가정합니다. 그렇지 않습니다. 우리는 구체적인 시나리오 하나와 하드웨어 프로필 하나만 검증했을 뿐입니다. 이후의 spike들은 GPU와 스트리밍 압력이 바뀌었을 때 여전히 가정을 다시 점검해야 했습니다.

이 spike는 또한 프로세스를 한 단계 끌어올려 주었습니다. 우리는 인터랙티브 spike에서 기본으로 HUD에 타이밍 텔레메트리를 노출하기 시작했습니다. 그 덕분에 팀 대화가 "뭔가 이상하다"에서 "이 경로가 1.2 ms를 더했다"로 바뀌었습니다.

3부에서는 나중에 값비싼 사고를 막아준, 덜 화려한 실험들을 다룹니다. 브로드캐스트 부하, 모바일 제약, 행동 생성 신뢰성입니다.

이 장에서 언급된 기술

Rapier. Rust로 작성되어 브라우저 사용을 위해 WebAssembly로 컴파일되는 물리 엔진입니다. 리지드 바디, 콜라이더, 조인트, 캐릭터 컨트롤러, 레이캐스팅을 네이티브 대비 2-3배 성능으로 처리합니다. 오픈 월드에서 Rapier는 플레이어 캐릭터 컨트롤러(지형 위 걷기, 계단 오르기, 경사면 미끄러지기), 오브젝트 충돌, 상호작용을 위한 레이캐스팅, 트리거 볼륨을 제공합니다. Rapier 문서와 물리에 관한 브라우저 3D 기술 가이드를 보세요.

Web Workers. 메인 스레드와 별개로 JavaScript(또는 Wasm)를 실행하는 브라우저 스레드입니다. 물리 시뮬레이션을 worker에 두면 무거운 world.step() 호출이 렌더링을 막지 않습니다. 메인 스레드는 매 프레임 postMessage로 입력 상태를 worker에 보내고 권위 있는 위치를 돌려받습니다. 지연 비용은 두 번의 메시지 홉입니다(데스크톱에서 각각 약 0.1-0.5 ms). 이점은 렌더 스레드가 충돌 감지에서 절대 멈추지 않는다는 것입니다. Transferable 객체(ArrayBuffer 전송)는 큰 위치 배열의 복사 오버헤드를 없앱니다.

WebAssembly (Wasm). 브라우저에서 네이티브에 가까운 속도로 실행되는 바이너리 명령 형식입니다. Rapier, Havok, Recast 모두 Wasm으로 컴파일됩니다. Rapier-Wasm의 물리 스텝은 수백 개의 바디에 대해 보통 0.5-2 ms인데, 같은 작업을 JavaScript로 하면 5-15 ms입니다. Wasm 모듈은 JavaScript 글루 코드와 함께 .wasm 파일로 가져옵니다. WebAssembly 명세를 보세요.

입력부터 화면까지의 지연. 키 입력과 그 결과로 화면에 나타나는 시각적 변화 사이의 시간입니다. 움직임이 "즉각적"으로 느껴지려면 이 값이 약 80 ms 아래로 유지되어야 합니다. worker 물리 구성에서 이 사슬은 누적됩니다.

keydown 이벤트(메인 스레드), worker로 갔다 오는 postMessage($2t_{\text{msg}}$), 물리 스텝, 렌더러가 새 위치를 적용하는 단계, 그다음 다음 vsync입니다. 각 항은 그 자체로는 작지만(데스크톱에서 메시지 홉당 약 0.1-0.5 ms) 쌓입니다. 그래서 아키텍처 다이어그램을 믿는 대신 $L$을 직접 측정했습니다.

12부 중 2부.
이전: 1부 - 우리는 그것을 부수려는 시도부터 시작했다
다음: 3부 - 우리를 구한 화려하지 않은 spike들
시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

글쓴이 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. 실시간 위치 업데이트를 한 서버에서 연결된 많은 클라이언트로 분배하는 것입니다. 클라이언트당 하향 대역폭은 보이는 군중 규모에 선형으로 비례합니다.

게임 수준의 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

글쓴이 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

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

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

이번 장은 시각적 야심이 산수와 부딪힌 장이다.

우리는 렌더링 비용을 별도의 spike로 쪼개서 측정했다. 묶어서 나온 결과는 진단하기 어렵기 때문이다. 한 번에 전부 켜면, 알게 되는 건 딱 하나다. 프레임이 느리다는 것. 어떤 기능이 예산을 먹었는지는 알 수 없다.

Spike 7은 식생 밀도와 애니메이션 비용을 겨냥했다. 방식은 지형 chunk마다 32x32 밀도 맵에서 런타임으로 흩뿌리고, 큰 InstancedMesh 세트에 넣어주는 것이었다. 풀잎 하나하나와 관목 덩어리마다 스크롤하는 노이즈 텍스처로 구동되는 버텍스 셰이더 바람을 입혔다. 우리가 지켜본 핵심 수치는 삼각형 개수가 아니라 중급 GPU에서의 draw call 오버헤드와 버텍스 처리량이었다. 인스턴스를 더 적은 mesh로 batch하는 게 잎 하나당 폴리곤 수를 줄이는 것보다 더 중요하다는 걸 알게 됐다.

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

Spike 8은 지형 머티리얼의 복잡도를 밀어붙였다. 경사 각도와 고도로 가중치를 준 다층 블렌딩, 절벽 면에 선택적으로 적용하는 triplanar 투영, 그리고 레이어별 노멀 맵. 셰이더는 네 개의 텍스처 레이어로 경사 기반 splatting을 하고 있었고, 각 레이어마다 diffuse와 normal 샘플이 필요했다. 그러니까 조명을 더하기 전에 이미 프래그먼트당 $4\times 2=8$번의 텍스처 페치가 들어가고, 이 개수는 레이어에 따라 선형으로 늘어난다. 다섯 번째 레이어를 넣으면 픽셀마다 10번 페치라는 뜻이다. 바닥값을 찾으려고 일부러 내장 Intel GPU에서 프로파일링했다. 결론은, 수직 면에서의 triplanar 투영은 그 비용을 들일 만했지만, 다섯 번째 splat 레이어를 추가하는 건 그렇지 않았다는 것이다.

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

Spike 9는 현실적인 지형과 오브젝트 부하 아래에서의 캐스케이드 섀도우 맵 비용에 집중했다. 세 개의 캐스케이드를 쓰는 CSM이 기준선이었다. 일부러 낮은 각도의 태양 위치로 테스트했는데, 거기가 캐스케이드 압박이 가장 심해지는 지점이기 때문이다. 가장 먼 캐스케이드는 거대한 절두체 조각을 덮고, 섀도우 디테일은 텍셀 밀도 $\rho \approx \frac{R^2}{A}$로 정해진다 (해상도 $R$의 섀도우 맵을 지면 면적 $A$에 걸쳐 늘린 것). 맵 하나로 시야 거리 전체를 덮으면 $A$가 엄청나게 커지고 $\rho$가 붕괴한다. 캐스케이드는 절두체를 쪼개서 각 조각이 작은 $A$ 위에 자기만의 $R\times R$ 맵을 갖게 함으로써 이걸 해결하고, 가까운 곳부터 먼 곳까지 $\rho$를 대체로 일정하게 유지한다. 우리는 두 개와 네 개 캐스케이드 사이의 GPU 시간 차이를 재고, 다음으로 1024와 2048 섀도우 맵 해상도 사이의 차이를 쟀다. 결과는, 1024에서 캐스케이드 세 개가 목표 하드웨어에서 GPU 시간 2ms를 넘지 않으면서 카메라 근처의 접촉 섀도우를 받아들일 만한 수준으로 제공했다는 것이다.

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

이 단계에서 어려웠던 건 제품 규율이었다. 어떤 효과들은 아주 훌륭해 보였지만, 시각적 영향에 비해 프레임 예산을 너무 많이 먹어서 결국 제약을 걸어야 했다.

우리의 규칙은 단순해졌다. 어떤 기능은 측정된 프레임 시간 데이터로 자기 비용을 설명할 수 있을 때만 앞으로 나아간다.

당연한 얘기처럼 들린다. 하지만 다음 시각적 성과에 다들 들떠 있는 빠른 프로토타입 사이클에서는 흔한 일이 아니다. 이 규칙을 일찍부터 지킨 덕분에 나중에 clipmap과 볼류메트릭 존을 둘러싼 아키텍처 결정이 훨씬 깔끔해졌다. 같은 16ms를 두고 경쟁하는 모든 것의 기능별 비용을 우리가 이미 알고 있었으니까.

6부에서는 geometry clipmap으로 첫 번째 주요 지형 아키텍처 전환을 맞는다.

이 장에서 언급한 기술

InstancedMesh와 GPU 식생. Three.js의 InstancedMesh는 같은 지오메트리의 N개 복사본을 draw call 한 번으로 렌더링한다. 식생의 경우, 밀도 맵 (chunk당 32x32)이 풀잎과 관목 덩어리를 인스턴스 버퍼로 런타임에 흩뿌리는 작업을 구동한다. 바람 애니메이션은 스크롤하는 노이즈 텍스처를 써서 버텍스 셰이더에서 돌아간다. 규모가 커지면, WebGPU의 ComputeInstanceCulling이 래스터화 전에 화면 밖과 먼 거리의 인스턴스를 제거하고, IndirectBatchedMesh가 여러 식생 타입을 하나의 버퍼에 담아 multi-draw indirect로 그린다. GPU 식생 컬링에 관한 지형 가이드를 보라.

Triplanar mapping. 표준 UV 매핑 텍스처는 가파른 경사에서 UV 좌표가 압축되기 때문에 늘어난다. Triplanar mapping은 세 축(X, Y, Z) 모두를 따라 텍스처를 투영하고 표면 노멀을 기준으로 블렌딩한다. 절벽 면은 X 또는 Z 투영(늘어남 없음)을 받고, 평평한 지면은 Y 투영을 받는다. 블렌딩은 부드럽고 자동이며 UV 언랩이 필요 없다. PBR 지형의 경우, 같은 블렌딩 가중치가 albedo, normal, roughness, ambient occlusion 채널에 그대로 적용된다. triplanar mapping 세부 사항을 보라.

경사와 고도 기반 머티리얼 splatting. 손으로 그린 splat 맵 대신, 머티리얼은 지형 속성을 기준으로 프래그먼트 셰이더에서 절차적으로 할당된다. 낮은 고도의 평지는 풀을 받고, 가파른 경사는 바위를, 높은 고도는 눈을(쌓일 만큼 충분히 평평한 표면에서만), 해수면 근처는 모래를 받는다. 전환은 부드러운 블렌딩을 위해 smoothstep을 쓴다. 우리 구현에서는 각 지형 chunk가 네 개의 텍스처 레이어를 레이어당 diffuse와 normal 샘플로 평가하므로, 조명 전에 프래그먼트당 여덟 번의 텍스처 페치가 일어난다. 경사와 고도 기반 머티리얼 할당을 보라.

캐스케이드 섀도우 맵 (CSM). CSM은 카메라의 뷰 절두체를 3~4개의 거리 구간(캐스케이드)으로 쪼갠다. 각 캐스케이드는 그 거리에 맞춘 해상도로 태양 시점에서 섀도우 맵을 렌더링한다. 가까운 캐스케이드는 고해상도 섀도우(나무와 건물 아래의 정밀한 접촉 섀도우)를 받고, 먼 캐스케이드는 낮은 해상도(넓은 산 그림자)를 받는다. 지형 셰이더는 모든 캐스케이드를 샘플링하고 프래그먼트마다 적절한 것을 고른다. 성능 비용: 1024x1024로 3~4개 캐스케이드는 섀도우 맵 렌더링에 약 0.5~1 ms, 샘플링에 약 0.2~0.3 ms를 더한다. 지형 섀도우를 보라.

12부 중 5부.
이전: 4부 - 화려한 지형보다 먼저 스트리밍
다음: 6부 - Clipmap이 줄거리를 바꿨다
시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

Spike 10 이전까지 우리의 머릿속 모델은 여전히 "세계가 커지면 지오메트리도 많아진다"였습니다. Spike 10 이후 그 모델은 "지오메트리 예산은 고정, 카메라 중심의 링 업데이트"로 바뀌었습니다. 이 전환이 프로젝트의 방향을 바꿨습니다.

지오메트리 클립맵의 아이디어는 단순합니다. 지형을 카메라를 중심으로 한 동심원 링 묶음으로 렌더링합니다. 가장 안쪽 링이 정점 밀도가 가장 높습니다. 바깥으로 한 링 $k$씩 갈 때마다 정점 간격이 두 배가 되어 $s_k=s_0\cdot 2^k$가 되고, 그래서 안쪽 링보다 $4\times$ 넓은 지면을 덮습니다.

이 두 배가 핵심 전부입니다. 시야 거리는 링 개수에 따라 기하급수적으로 늘어나는데 $d_{\text{view}}\approx s_0\cdot 2^L$, 정점 비용은 선형으로만 늘어납니다.

$N\times N$ 정점짜리 링 $L$개에 대해 그렇습니다. 얼마나 멀리 볼 수 있는지를 두 배로 늘리는 비용은 링 하나가 더 드는 것이지, 지오메트리가 네 배로 드는 게 아닙니다. 세계 크기와 상관없이 삼각형 수는 대체로 일정하게 유지됩니다. 항상 같은 $L$개의 링을 같은 해상도로 렌더링하기 때문입니다.

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

실전에서의 요령은 링 경계에서의 geomorphing이었습니다. 한 정점이 어떤 LOD 링에서 다음 링으로 넘어갈 때, 그 높이는 고해상도 샘플과 저해상도 샘플 사이에서 부드럽게 섞여야 합니다. 그게 없으면 카메라가 움직여 링이 이동할 때마다 눈에 띄는 pop이 생깁니다. 우리는 정점이 링 가장자리에서 떨어진 거리에 기반한 블렌드 계수로 이를 처리했고, 정점 셰이더에서 높이를 보간했습니다.

여기서 $d$는 정점이 카메라에서 떨어진 거리입니다. 링 안쪽($d\le d_{\text{near}}$)에서는 정점이 풀해상도 높이를 쓰고, 다음 링에 도달할 무렵($d\ge d_{\text{far}}$)에는 이미 그 링이 쓸 거친 높이로 옮겨가 있어서 pop이 일어날 게 남아 있지 않습니다.

미묘한 교훈 하나는 카메라 이동 테스트에서 나왔습니다. 정적 스크린샷으로 클립맵을 판단하면서 전환 아티팩트를 놓치기는 쉽습니다. 우리는 링 경계를 일정한 속도로 가로질러 다니며 시간 축의 노이즈를 살피는 데 시간을 들였습니다. 스크린샷은 거짓말을 했습니다. 움직임이 진실을 말했습니다.

이 spike는 또 깔끔한 아키텍처 경계도 줬습니다. 근거리 지형은 시간이 지나며 동적이고 비싸질 수 있습니다. 볼류메트릭 편집, 더 높은 머티리얼 복잡도, 물리 상호작용이 더해지면서요. 원거리 지형은 안정적이고 예측 가능하고 저렴하게 유지될 수 있습니다. 그 분리가 이 시점부터 모든 아키텍처 결정의 척추가 됐습니다.

자기 프로젝트에 클립맵을 검토하고 있다면, 예쁜 컷이 아니라 스트레스 루프를 테스트하세요. 긴 이동 경로, 변하는 카메라 고도, 반복되는 경계 횡단이야말로 진짜 문제를 드러내는 것들입니다.

7부에서는 볼류메트릭 메싱을 더해 "표면으로서의 지형"에서 "편집 가능한 볼륨으로서의 지형"으로 넘어갑니다. 이 프로젝트가 렌더러이기를 그만두고 월드 에디터가 되기 시작한 지점이 바로 거기였습니다.

이 장에서 언급한 기술

지오메트리 클립맵. Losasso와 Hoppe가 SIGGRAPH 2004에서 소개했으며(논문), 지오메트리 클립맵은 지형을 카메라를 중심으로 한 동심 정사각형 링으로 렌더링합니다. 각 링은 이전 링의 두 배 면적에 정점 해상도는 절반입니다. 전체 정점 수는 일정합니다. 대략 $N^2\cdot L$입니다. $N=256$에 $L=8$ 레벨이면 세계 크기와 상관없이 ${256}^2\times 8\approx \mathrm{524,000}$개 정점입니다. CPU는 카메라가 움직일 때 각 링의 heightmap 데이터를 업데이트합니다. 정점 셰이더는 텍스처에서 높이를 읽어 평평한 그리드를 변위시킵니다. 지오메트리 클립맵에 관한 우리 지형 가이드와 GPU Gems 2, 2장을 보세요.

Geomorphing. 지형 LOD에서 가장 큰 시각적 아티팩트는 popping입니다. 패치가 LOD 레벨을 바꿀 때 정점이 갑자기 튀는 것이죠. Geomorphing은 전환 구간에 걸쳐 LOD 레벨 사이에서 정점 위치를 블렌딩해 이를 없앱니다. 각 정점은 현재 LOD 높이와 한 단계 거친 LOD 높이를 둘 다 저장합니다. 카메라 거리에 기반한 모프 계수가 둘 사이를 부드럽게 보간합니다. morphedHeight = mix(fineLodHeight, coarseLodHeight, smoothstep(lodNear, lodFar, distance)). 전환 구간은 보통 각 링의 바깥쪽 20%입니다. 정상적인 카메라 속도에서 전환은 보이지 않습니다. geomorphing 세부 내용을 보세요.

CDLOD(쿼드트리 적응형 클립맵). Strugar가 고정 링 클립맵을 개선한 것입니다(2014, 논문). 균일한 해상도의 동심 링 대신, CDLOD는 지형 복잡도에 적응하는 쿼드트리를 씁니다. 평평한 지역은 거친 노드를 쓰고, 디테일이 높은 지역(절벽, 능선)은 더 세밀하게 분할합니다. 이는 청크마다 복잡도가 크게 다른 창작자 세계에서 중요합니다. 우리 지형 가이드의 CDLOD를 보세요.

12부 중 6부.
이전: 5부 - 예쁜 것들에 예산 배정하기
다음: 7부 - 마칭 큐브와 첫 진짜 동굴들
시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

Oleg Sidorkin, Cinevva의 CTO 겸 공동 창업자

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

하이트맵은 오버행이 필요해지기 전까지는 훌륭합니다.

깎아낸 터널, 떠 있는 바위 턱, 동굴 천장을 원하는 순간, 순수 하이트필드 파이프라인은 당신을 막기 시작합니다. 하이트맵은 XZ 좌표마다 Y 값을 하나만 저장합니다. 자기 위로 접혀 돌아오는 표면은 물리적으로 표현할 수가 없습니다. 우리에게는 볼류메트릭 표현이 필요했습니다.

Spike 12는 WebGPU 컴퓨트 셰이더를 사용해 GPU에서 마칭 큐브를 구현했습니다. 이 알고리즘은 3D 그리드에서 부호 거리장(SDF)을 평가하고, 값이 0이 되는 지점의 표면에서 삼각형 메시를 추출합니다. 각 셀은 8개의 코너를 가지며, 각 코너는 표면 안쪽이거나 바깥쪽이라서 $2^8=256$가지 부호 패턴이 나옵니다. 룩업 테이블이 각 패턴을 삼각형 집합으로 매핑합니다. 정점은 셀의 모서리에서 값이 0을 가로지르는 지점에 놓입니다. 코너 $a$와 $b$ 사이의 모서리에서 값이 각각 $f_a$, $f_b$라면, 선형 보간으로 정점을 다음 위치에 놓습니다.

이는 모서리를 따라 값이 0에 닿는 지점의 비율입니다. 가로지르는 모서리에서 $f_a$와 $f_b$는 부호가 반대이므로, $t$는 항상 $[0,1]$ 안에 들어옵니다. 우리는 이것을 동시에 활성화된 64-큐브 청크 4개에서 돌렸고, 프레임마다 리메시하는 애니메이션 SDF 편집을 테스트했습니다.

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

첫 번째 수확은 컴퓨트 파이프라인 자체에 대한 자신감이었습니다. 단 한 번의 디스패치로 CPU 리드백 없이 SDF를 평가하고, 셀을 분류하고, 정점을 GPU 버퍼에 내보낼 수 있었습니다. 두 번째 수확은 "된다"가 얼마나 빨리 아티팩트 사냥으로 바뀌는지 알게 된 것입니다. 사라진 삼각형은 마칭 큐브 이론의 문제인 경우가 드물었습니다. 테이블 인덱스 불일치이거나, 활성 정점 개수를 넘어서 읽는 잘못된 드로우 범위이거나, 이웃 SDF 샘플을 쓸 수 없는 청크 경계 근처의 엣지 케이스 상호작용이었습니다.

이 spike는 우리가 구역 단위로 생각하게 만들었습니다. 카메라 가까이에서는 플레이어가 깎고, 파고, 동굴을 볼 수 있도록 볼류메트릭 자유도가 필요합니다. 카메라에서 멀리에서는 평평한 하이트맵이 더 싸고 완벽하게 충분한 클립맵 효율이 필요합니다. 이 이원성은 Spike 13 이후로 우리가 계속 다듬어온 아키텍처의 척추가 되었습니다.

내가 가장 좋아한 디버깅 순간 중 하나는 편집이 돌아가는 와중에 와이어프레임을 토글한 것이었습니다. 위상 구조가 실시간으로 만들어지고 녹아 사라지는 것을 지켜보니 품질의 트레이드오프가 곧바로 눈에 보였습니다. 정점 밀도가 충분히 높은 곳, 너무 거칠어진 곳, 그리고 결국 균열을 피하려면 LOD 전환에 Transvoxel 지원이 어디서 필요할지 정확히 볼 수 있었습니다.

8부에서는 통합 과제를 다룹니다. 원시 컴퓨트 기반 메시와 Three.js 씬 그래프 로직을 안정적인 렌더링 파이프라인 하나에 담아두는 것은 따로 떼어낸 데모가 암시한 것보다 더 어려웠습니다.

이 장에서 언급한 기술

마칭 큐브. 3D 스칼라 장에서 삼각형 메시를 추출하는 알고리즘입니다(Lorensen and Cline, 1987). 규칙적인 3D 그리드의 각 셀은 8개의 코너에서 장을 샘플링해 분류됩니다. 부호 패턴이 케이스 인덱스(0-255)를 만들고, 룩업 테이블이 각 케이스를 삼각형 집합으로 매핑합니다. 정점은 두 코너 사이를 보간해서 그리드 모서리에 놓입니다. 각 셀이 독립적으로 처리되기 때문에 이 알고리즘은 엄청나게 병렬적이고, GPU 컴퓨트에 이상적입니다. 우리의 SDF와 마칭 큐브에 관한 지형 가이드를 보세요.

부호 거리장(SDF). 3D 공간의 모든 점에 가장 가까운 표면까지의 부호 있는 거리를 저장하는 볼류메트릭 표현입니다. 양수 값은 바깥쪽, 음수 값은 안쪽이고, 0을 가로지르는 지점이 표면입니다. SDF는 임의의 3D 형태를 표현할 수 있습니다. 동굴, 아치, 오버행, 그리고 하이트맵이 표현하지 못하는 떠 있는 지오메트리까지요. 편집은 장에 대한 자연스러운 집합 대수입니다. 재료 추가(두 형태의 합집합)는 $d=min(d_1,d_2)$이고, 제거(파내기)는 깎아내는 형태를 음수로 만든 $d=max(d_1,-d_2)$이며, 부드러운 블렌드는 다음과 같은 소프트 최솟값을 사용합니다.

여기서 $k$는 블렌드 반경을 제어합니다. $k\to 0$이 되면 다시 단단한 $min$으로 무너집니다. SDF 지형 표현을 보세요.

WebGPU 컴퓨트 셰이더. 래스터화 파이프라인에 묶이지 않고 범용 계산을 수행하는 GPU 프로그램입니다. 컴퓨트 셰이더는 병렬로 실행되는 스레드 워크그룹을 디스패치합니다. 마칭 큐브에서는 각 스레드가 그리드 셀 하나를 처리합니다. SDF를 샘플링하고, 셀을 분류하고, 삼각화를 룩업하고, 모서리 정점을 보간하고, 아토믹 카운터를 사용해 메시 버퍼에 추가합니다. 출력 버퍼가 렌더링용 정점 데이터로 직접 쓰이기 때문에 CPU 리드백이 필요 없습니다. Will Usher의 webgpu-marching-cubes는 브라우저에서 실시간 256^3 그리드 처리를 보여줍니다. 우리의 WebGPU 기반 LOD에 관한 지형 가이드를 보세요.

하이트맵 + SDF 하이브리드 아키텍처. 브라우저 지형의 실용적인 접근법입니다. 하이트맵은 세계 전체를 덮고(싸고 컴팩트함), SDF 볼륨은 동굴, 오버행, 또는 창작자가 깎아낸 특징이 필요한 청크에만 존재합니다(청크의 5-10%). 카메라 가까이에서는 볼류메트릭 자유도가 깎기와 동굴을 가능하게 합니다. 멀리에서는 하이트맵이 효율적인 평평한 지형을 제공합니다. 하이브리드 지형 표현을 보세요.

12편 중 7편.
이전: 6부 - 클립맵이 줄거리를 바꿨다
다음: 8부 - 기준선을 잃지 않고 통합하기
시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

처음 보시나요? 시리즈 가이드를 보세요. spike가 무엇인지 설명하고 모든 부분으로 연결해 줍니다.

통합은 프로젝트가 엉망이 되는 지점입니다. 따로 떼어 놓으면 잘 도는 부분들이 있습니다. 그것들을 연결하면 갑자기 모든 버그가 어디에나 있을 수 있는 것처럼 보입니다.

Spike 13과 14는 그 함정에 대한 우리의 답이었습니다. Spike 13은 깨끗한 Three.js WebGPU 기준선을 세웠습니다. renderer 하나, scene 하나, camera 하나, 그리고 단순한 mesh 하나뿐이었습니다. 지형도, compute도, 이펙트도 없었습니다. 우리는 Three.js의 WebGPU 백엔드가 제대로 초기화되는지, 렌더 루프가 안정적인지, TSL(Three.js Shading Language) 노드 머티리얼이 기대대로 동작하는지 확인했습니다. 그 체크포인트를 통과한 뒤에야 계층을 추가하기 시작했습니다.

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

Spike 14는 점진적 강화였습니다. 한 번에 하나의 기능씩 추가했습니다. 먼저 카메라 컨트롤, 그다음 조명, 그다음 marching cubes 파이프라인에서 compute로 생성한 mesh, 그다음 GPU 출력을 Three.js 지오메트리 속성에 직접 연결하는 buffer 배선. 추가할 때마다 이전 계층이 여전히 제대로 동작하는지 확인했습니다.

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

느려 보입니다. 딱 하루 느렸고, 곧이어 seam 로직과 정책 전환이 복잡해졌을 때 며칠을 아껴 줬습니다.

이 규율이 정당했음을 증명한 특정 버그 부류는 머리카락처럼 가는 아티팩트였습니다. 지오메트리 손상처럼 보이는 얇은 조각이었지만 사실은 과거 데이터였습니다. compute shader는 buffer에 N개의 정점을 쓰는데, draw call은 여전히 이전 프레임의 N+M개 정점을 렌더링하도록 설정되어 있었습니다. 그 여분의 정점에는 이전 dispatch에서 남은 쓰레기 값이 들어 있었습니다. 시각적 결과는 예측할 수 없이 나타났다 사라지는, 깜빡이는 면도날처럼 얇은 삼각형이었습니다.

이런 부류의 버그는 직관으로 이기는 게 아닙니다. 마지막으로 잘 돌던 상태와 지금 망가진 상태 사이에 정확히 무엇이 바뀌었는지 아는, 통제된 델타로 이깁니다.

WebGPU 통합은 buffer 생명주기에 대해서도 가르쳐 줬습니다. WebGPU의 GPU buffer는 특정 usage로 매핑되고 나면 불변입니다. marching cubes 출력이 커져서 vertex buffer를 키워야 한다면, 새 buffer를 만들고 바인딩을 갱신해야 합니다. realloc은 없습니다. 그 생명주기를 제대로 하는 것, 즉 진행 중인 GPU 작업과 경쟁하지 않으면서 옛 buffer를 파괴하는 것은 WebGL에 없는 명시적 fence 관리를 필요로 했습니다.

9부에서는 Transvoxel seam 작업으로 들어갑니다. 그 장은 의도적으로 스캐폴드에서 시작합니다. 이 시점에 우리는 통합을 서두르면 미스터리가 생기고, 통제된 셋업은 디버깅 가능한 문제를 만든다는 교훈을 완전히 체화한 상태였습니다.

이 장에서 다룬 기술

WebGPU. WebGL의 후속으로, 브라우저에서 compute shader와 indirect rendering을 갖춘 저수준 GPU 접근을 제공합니다. 오픈 월드에 중요한 WebGPU의 두 가지 핵심 기능은 이렇습니다. compute shader는 GPU 측 지형 생성, 식생 배치, 컬링을 가능하게 하고, indirect rendering은 GPU가 compute 출력을 바탕으로 무엇을 그릴지 결정하게 해서 밀집된 장면에서 CPU 병목을 없앱니다. 데스크톱의 Chrome, Edge, Firefox에서 쓸 수 있습니다. 성능 면에서의 WebGPU를 보세요.

Three.js Shading Language (TSL). Three.js의 노드 기반 셰이더 시스템으로, 날것의 GLSL/WGSL을 조합 가능한 JavaScript 표현식으로 대체합니다. texture(), positionWorld, smoothstep(), fog() 같은 TSL 노드는 런타임에 셰이더 그래프를 만들고 적절한 백엔드(WebGL의 GLSL이나 WebGPU의 WGSL)로 컴파일됩니다. TSL 덕분에 머티리얼 로직을 한 번 작성하고 두 렌더러 모두를 대상으로 삼을 수 있습니다. 노드 그래프는 프레임마다 평가되므로 동적 uniform과 조건 분기가 자연스럽게 동작합니다.

WebGPU의 GPU buffer 생명주기. WebGPU buffer는 특정 usage 플래그(VERTEX, STORAGE, COPY_DST 등)와 함께 생성되며 생성 후에는 크기를 바꿀 수 없습니다. 한 번의 marching cubes dispatch가 buffer가 담을 수 있는 것보다 많은 정점을 만들어 내면, 새 buffer를 만들고 바인딩을 갱신하고 옛것을 파괴해야 합니다. 진행 중인 GPU 명령이 아직 참조하는 buffer를 파괴하면 오류가 납니다. 명시적 fence 관리(device.queue.onSubmittedWorkDone()를 통해)는 GPU가 다 쓸 때까지 옛 buffer가 파괴되지 않도록 보장합니다. 이런 생명주기 규율은 드라이버가 메모리를 암묵적으로 관리하는 WebGL에는 없습니다.

점진적 강화. 통합을 위한 프로세스 규율입니다. 검증된 기준선을 세우고, 한 번에 한 기능씩 추가하고, 추가할 때마다 이전 계층이 여전히 동작하는지 확인합니다. 이 접근은 하루는 더 느리지만 나중에 디버깅할 때 며칠을 아껴 줍니다. 각 회귀를 구체적이고 통제된 변경 하나로 추적할 수 있기 때문입니다. 기준선을 먼저 세우고 점진적으로 늘려 가는 패턴은 AAA 오픈 월드 개발에서 흔하며, 거기서는 위험을 관리하기 위해 시스템을 특정 순서로 통합합니다.

12부 중 8부.
이전: 7부 - Marching cubes와 첫 진짜 동굴
다음: 9부 - Transvoxel은 스캐폴드에서 시작했다
시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

이음새는 확신이 죽으러 가는 곳이다.

두 해상도가 만나기 전까지는 모든 게 안정적으로 보일 수 있다. LOD 0 chunk가 LOD 1 chunk 옆에 놓인다. 두 mesh는 독립적으로 생성된다. 둘이 경계를 공유하는 지점에서는 저해상도 chunk의 그리드 밀도가 절반이기 때문에 정점 위치가 맞지 않는다. 그 결과로 눈에 보이는 균열, T 자 교차점, 깜빡이는 가장자리가 생긴다.

Transvoxel 알고리즘은 서로 다른 해상도의 두 chunk 사이 경계면을 따라 특수한 전이 cell을 생성해서 이 문제를 해결한다. 이 cell들은 고해상도 그리드와 저해상도 그리드에서 동시에 샘플링해서 두 표면을 꿰매 붙이는 삼각형을 만들어 낸다. 알고리즘은 일반 marching cubes 테이블과는 별개로 자체 룩업 테이블을 쓰며, 512가지 전이 cell case를 가진다.

이 시점쯤 우리는 구현을 서두르면 안 된다는 걸 알 만큼 통합으로 생긴 흉터가 충분히 있었다.

Spike 15에는 임무가 하나뿐이었다. 전체 알고리즘을 건드리기 전에 믿을 수 있는 이음새 테스트 장치를 만드는 것. 우리는 알려진 SDF 데이터를 가진 두 chunk를 서로 다른 해상도로 나란히 놓은 통제된 환경을 세팅했고, 메인 mesh, 이음새 mesh, wireframe, 법선을 각각 독립적으로 토글하는 시각화 컨트롤을 붙였다.

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

테스트 장치가 안정되자 Spike 16은 테이블 기반 전이 cell 생성을 단일 면에서 검증했다. 우리는 축에 정렬된 면 하나(+X 경계)를 골라서 그 면만 전이 cell 평가를 구현했고, 출력을 Transvoxel 논문의 참조 데이터와 비교했다.

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

우리는 일부러 한 번에 한 면씩 테스트했는데, 전이 테이블 배선에는 독립적인 실패 모드가 많기 때문이다. case 인덱스 계산은 두 그리드 양쪽에서 올바른 정점을 샘플링하는 데 달려 있다. 전이 cell 안의 정점 인덱싱은 일반 marching cubes cell과 다른 번호 매김 방식을 쓴다. 와인딩 순서는 메인 mesh와 일관돼야 하며, 그렇지 않으면 백페이스 컬링이 당신의 이음새 삼각형을 잡아먹는다. 여섯 면을 한꺼번에 테스트하면 모든 증상이 무작위로 보인다. 한 면을 철저히 테스트하면 의미 있고 디버그 가능한 실패를 얻는다.

이 단계에서 얻은 또 다른 미묘한 성과는 도구에 대한 투자였다. 우리는 가시성 토글, 이음새 전용 렌더링, 색상으로 구분한 LOD 표시기를 일찍 만들었다. 당시에는 이 컨트롤들이 부담처럼 느껴졌다. 나중에 코너 케이스가 험해졌을 때, 정확히 어떤 이음새 cell이 말썽인지 격리할 수 있었기 때문에 이 컨트롤들은 거듭거듭 본전을 뽑았다.

이 장이 끝날 때 우리는 "이음새를 끝낸" 상태가 아니었다. 우리는 이음새 버그를 두려워하는 대신 추론할 수 있는 위치에 있었다.

10부에서 진짜 롤러코스터가 시작된다. 혼합 LOD 코너, 와인딩 뒤집힘, 부분 overdraw 잔상, 그리고 알고리즘이 틀렸다고 확신했다가 사실 버그는 draw 범위가 활성 정점 수 너머를 읽고 있었던 것임을 발견하는 순간들.

이 장에서 언급한 기술

Transvoxel 알고리즘. Eric Lengyel이 설계했고(transvoxel.org), Transvoxel은 볼류메트릭 지형 LOD에서 가장 어려운 문제를 해결한다. 바로 서로 다른 해상도의 chunk 사이 이음새다. 고해상도 chunk가 저해상도 chunk 옆에 놓이면 marching cubes mesh가 경계에서 정렬되지 않아 눈에 보이는 균열이 생긴다. Transvoxel은 경계면을 따라 특수한 전이 cell을 끼워 넣어 양쪽에 맞는 추가 삼각형으로 해상도 차이를 메운다. 알고리즘은 (일반 marching cubes와 별개인) 자체 룩업 테이블을 쓰며 512가지 전이 cell case를 가지는데, 이는 73개의 등가 클래스로 줄어든다. 특허가 없으며 출시된 게임들(Space Engineers, Astroneer)에서 쓰였다. Transvoxel에 관한 지형 가이드를 참고하라.

전이 cell. 두 LOD 레벨 사이의 면에서 생성되는 특수한 cell. 한 그리드에서 8개의 모서리를 샘플링하는 일반 marching cubes cell과 달리, 전이 cell은 고해상도와 저해상도 그리드에서 동시에 샘플링한다. 고해상도 면은 $3\times 3=9$개의 샘플 지점을 가지고, 저해상도 면은 $2\times 2=4$개를 가진다. 이 9개의 샘플이 알고리즘에 $2^9=512$가지 원시 case를 주는데, 회전과 반사를 접어 내면 73개의 고유한 삼각화로 무너진다. cell 분류와 삼각화는 양쪽 해상도의 정점을 잇는 삼각형을 만들어 내는 전용 테이블을 쓴다. 정점 번호 매김 방식이 일반 MC cell과 달라서 흔한 구현 버그의 원인이 된다.

LOD 전이 이음새. 위상 불일치가 시각적 아티팩트를 일으키는 두 mesh 해상도 사이의 경계. 꿰매지 않으면 LOD 0 chunk(1m 그리드)가 LOD 1 chunk(2m 그리드) 옆에 놓일 때 T 자 교차점이 생긴다. 미세한 mesh는 경계를 따라 정점을 가지지만 거친 mesh는 그걸 공유하지 않아서, 빛이 새어 들어오는 균열이 생긴다. Transvoxel, 지오모핑, 스커트 지오메트리가 이 이음새를 고치는 세 가지 접근법이다. 볼류메트릭 지형에서는 지오모핑이 heightmap에만 통하기 때문에 Transvoxel이 표준 해법이다. 볼류메트릭 지형의 LOD를 참고하라.

12부 중 9부.
이전: 8부 - 기준선을 잃지 않고 통합하기
다음: 10부 - 이음새 혼돈과 코너 보스전
시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

앞부분이 차근차근 진행되는 느낌이었다면, 이 챕터는 전투 같았습니다.

Spike 17부터 22까지는 우리의 코너 케이스 시대였습니다. 듀얼 LOD marching cubes, heightmap에서 MC로 넘어가는 경계 이음새, 세 개나 네 개의 LOD 레벨이 만나는 혼합 해상도 코너 chunk, GPU 이음새 생성, 그리고 폴백 모드 동작. 각 spike는 우리가 마주쳤거나 예상했던 특정 실패 시나리오를 다뤘습니다.

Spike 17은 두 개의 LOD 레벨이 동시에 활성화된 상태의 듀얼 marching cubes를 테스트했습니다. 어려운 점은 하나의 chunk의 이웃들이 면마다 서로 다른 해상도일 수 있다는 것이었습니다. Spike 16에서 만든 전이 셀 로직은 한 번에 한 면에 대해서는 잘 작동했지만, chunk가 여러 면에 전이 셀이 필요할 때는 정점 버퍼 관리가 복잡해졌습니다. 각 면의 전이 셀은 다른 면을 덮어쓰지 않으면서 생성되고 추가되어야 했습니다.

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

반복해서 등장한 첫 번째 악당은 와인딩 순서였습니다. 여러 번 우리는 토폴로지 문제라고 생각했지만 알고 보니 방향 문제였습니다. 백페이스 컬링이 유효한 이음새 삼각형을 먹어 치우고 있었는데, 와인딩이 메인 메시 기준으로 뒤집혀 있었기 때문입니다. 같은 근본 원인인데 카메라 각도에 따라 시각적 증상이 달랐습니다. 해결책은 전이 셀 방출 코드에서 일관된 와인딩 규칙을 강제하고, 양면 머티리얼 토글로 그것을 검증하는 것이었습니다.

두 번째 악당은 부분적인 정확성에서 오는 잘못된 확신이었습니다. 이음새가 한 카메라 각도에서는 완벽해 보이다가, 고해상도와 저해상도 chunk 사이에서 LOD 역할이 바뀌면 깨질 수 있었습니다. 전이 셀은 비대칭입니다. 고해상도 쪽과 저해상도 쪽을 서로 다르게 샘플링합니다. 어떤 구성에서 "어느 쪽이 고해상도인가" 로직을 거꾸로 하면, 카메라가 특정 위치로 움직일 때만 그 버그가 보입니다.

그다음에는 우리가 가장 좋아하는 복구 중 하나가 있었습니다. 우리는 heightmap 타일에서 이음새가 잘리는 아티팩트를 쫓으면서 전이 로직을 탓하고 있었습니다. 거기에 이틀을 태웠습니다. 진짜 범인은 오래된 오버드로였습니다. 이전 프레임의 고해상도 지오메트리가, chunk가 더 낮은 LOD로 다운스케일된 뒤에도 버퍼 꼬리에 그대로 남아 있었습니다. 드로 범위는 여전히 예전의 더 큰 정점 수로 설정되어 있었죠. compute shader의 atomic counter가 보고하는 활성 정점 수로 드로 범위를 잘라내자, 그 "정체불명의 이음새 문제"가 사라졌습니다.

이건 렌더링 버그가 종종 메싱 버그로 위장한다는 좋은 일깨움이었습니다. 지오메트리는 처음부터 끝까지 옳았습니다. 드로 콜이 유효한 데이터의 끝을 지나서까지 읽고 있었을 뿐입니다.

Spike 22에 이르러서는 하이브리드 폴백을 테스트하고 있었습니다. chunk가 특정 조건에서 marching cubes에서 heightmap 모드로 전환할 수 있는 방식인데, 예를 들어 chunk에 볼류메트릭 편집이 없고 카메라에서 충분히 멀리 떨어져 있을 때입니다. 이것은 전부 아니면 전무 정책보다 더 실용적인 길을 줬습니다. 근거리의 편집된 chunk는 볼류메트릭 자유를 위해 MC를 씁니다. 원거리의 편집되지 않은 chunk는 효율을 위해 heightmap을 씁니다.

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

이 챕터는 롤러코스터의 가파른 낙하였습니다. 짜증나면서도 동시에 생산적이었습니다. 개별 수정 다수는 작았고, 어떤 때는 비교 연산자 하나나 오프셋 하나를 바꾸는 한 줄이었습니다. 하지만 그것들이 만들어낸, LOD 전이와 버퍼 관리와 드로 범위가 어떻게 상호작용하는지에 대한 이해는 결코 작지 않았습니다.

11부에서는 혼란 뒤에 온 안정화 레이어를 다룹니다. 정책 기반 chunk 모드, 그리고 반응적인 버그 수정에서 명시적인 시스템 규칙으로의 전환입니다.

이 챕터에서 언급된 기술

듀얼 LOD marching cubes. marching cubes를 두 개의 해상도 레벨에서 동시에 돌리면서, 전이 셀로 경계를 꿰매는 것입니다. 어려운 점은 하나의 chunk의 이웃들이 면마다 서로 다른 해상도일 수 있어서, 면마다 독립적인 전이 셀 생성이 필요하다는 것입니다. 각 면의 전이 셀은 다른 면을 덮어쓰지 않으면서 정점 버퍼에 추가됩니다. atomic counter가 모든 면에 걸친 총 활성 정점 수를 추적합니다.

와인딩 순서(winding order). 각 삼각형 안의 정점 순서가 어느 쪽이 "앞" 면인지 결정합니다. 일관된 와인딩(보통 바깥에서 봤을 때 반시계 방향)은 백페이스 컬링에 필요합니다. 전이 셀이 삼각형을 방출할 때 와인딩은 메인 메시의 규칙과 일치해야 합니다. 거꾸로 하면 백페이스 컬링이 유효한 이음새 삼각형을 먹어 치우는데, 이는 특정 카메라 각도에서 표면이 사라진 것처럼 보입니다. 흔한 디버깅 기법은 머티리얼에서 side: THREE.DoubleSide를 토글해서, 아티팩트가 와인딩 문제인지 진짜 토폴로지 구멍인지 확인하는 것입니다.

Heightmap-to-MC fallback. 하이브리드 chunk 모드로, 멀거나 편집되지 않은 chunk는 heightmap 지형(저렴하고 평평한 표면)을 쓰고, 가깝거나 편집된 chunk는 marching cubes(볼류메트릭, 동굴 지원)를 씁니다. 폴백 결정은 카메라로부터의 거리와 chunk에 SDF 편집이 있는지에 달려 있습니다. heightmap chunk와 MC chunk 사이의 이음새는 자체 전이 지오메트리가 필요한데, Transvoxel과 비슷하지만 두 개의 LOD 레벨이 아니라 두 개의 서로 다른 표현을 잇는다는 점이 다릅니다. 하이브리드 heightmap + 볼류메트릭 오버레이를 보세요.

드로 범위와 atomic counter. GPU 주도 메시 생성에서는 compute shader가 정점을 버퍼에 쓰고, 몇 개의 정점이 방출되었는지 추적하기 위해 atomic counter를 증가시킵니다. 드로 콜은 버퍼 용량이 아니라 이 counter를 정점 수로 써야 합니다. 드로 범위가 활성 카운트로 잘리지 않으면, 이전 프레임의 오래된 정점들(여전히 버퍼 꼬리에 남아 있는)이 잔상 지오메트리를 만듭니다. 얇은 조각과 깜박이는 삼각형인데, 토폴로지 오류처럼 보이지만 사실은 유효한 데이터를 지나서 읽어서 생긴 렌더링 아티팩트입니다.

12부 중 10부.
이전: 9부 - Transvoxel은 스캐폴드로 시작했다
다음: 11부 - 하드코딩 모드가 아니라 정책 모드
시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

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

이음매 혼돈 챕터가 끝난 뒤, 우리는 반응하기를 멈추고 다스리기를 시작해야 했습니다.

Spike 23은 즉흥적인 동작을 명시적인 정책 규칙으로 바꿨습니다. chunk가 각자의 로컬 상태가 시키는 대로 아무렇게나 움직이는 대신, 이제 중앙 정책 시스템이 결정을 내립니다. 이 chunk는 어떤 LOD 레벨을 받을까? heightmap으로 렌더링될까, marching cubes로 렌더링될까? 전환 cell이 필요할까, 그렇다면 어느 면에서? 그 답은 카메라까지의 거리, 편집 이력, 이웃의 해상도 상태를 평가하는 정책 함수에서 나왔습니다.

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

거리 기반 LOD 할당은 카메라를 중심으로 한 동심원 링을 사용했습니다. clipmap 개념과 비슷하지만 chunk 그리드에 적용한 것이죠. 링 0의 chunk는 전체 해상도 MC를 받습니다. 링 1은 절반 해상도 MC를 받습니다. 링 2 이상은 heightmap 모드로 갑니다. 인접 제약이 핵심이었습니다. 이웃한 두 chunk에 대해 우리는 $|L_i-L_j|\le 1$을 요구합니다. 한 면을 가로지르는 해상도 비율은 $2^{|L_i-L_j|}$이고, Transvoxel 전환 테이블은 2:1 경우($|L_i-L_j|=1$)에 대해서만 정의되어 있습니다. 2레벨 점프는 테이블이 표현할 수 없는 4:1 전환이 필요하므로, 정책은 제약이 충족될 때까지 더 낮은 디테일의 chunk를 업그레이드하도록 강제합니다.

HM/MC 전환 로직은 각 chunk의 편집 비트맵을 확인했습니다. chunk에 볼류메트릭 편집(동굴, 터널, 지형 조각)이 하나라도 있으면, 거리와 관계없이 MC 모드에 남았습니다. 편집되지 않은 chunk는 충분히 멀어지면 heightmap 모드로 내려갈 수 있었습니다. 이 하이브리드 방식 덕분에 중요한 곳에서는 볼류메트릭 자유를, 그렇지 않은 곳에서는 효율을 얻었습니다.

이 spike는 밖에서 보기엔 이전의 몇몇보다 작아 보였습니다. 실제로는 개발 편의성에서 큰 개선이었습니다.

시스템이 chunk가 왜 모드를 바꿨는지 설명할 수 있으면, 추측에 쓰는 시간이 줄어듭니다. 우리는 색상으로 구분한 오버레이를 추가했습니다. heightmap chunk는 녹색, MC chunk는 파란색, 전환이 활성화된 면은 주황색입니다. 이음매 가시성에 전용 렌더 제어가 있으면, 시각적 디버깅의 모호함이 줄어듭니다. draw 범위가 정책 시스템의 활성 정점 수에 명시적으로 묶여 있으면, 오래된 지오메트리 잔상이 오후 시간을 갉아먹는 일이 사라집니다.

이 spike에서 우리는 카메라 동작도 대폭 손봤습니다. 이전 spike들의 단순한 orbit 컨트롤은 스크린샷에는 괜찮았지만 버그 재현에는 쓸모가 없었습니다. Spike 23은 속도 조절이 가능한 WASD 비행 카메라, 고도 잠금 토글, 위치 표시를 추가했습니다. 사소하게 들립니다. 하지만 이것은 "저 능선 근처 어딘가에서 버그를 봤다"와 "버그는 북서쪽을 바라보는 위치 (142, 12, -67)에서 나타난다"의 차이를 의미했습니다.

이 챕터의 핵심 통찰은 정책이 복잡도를 줄이지 않았다는 것입니다. 정책은 복잡도를 조직했습니다. 같은 수의 엣지 케이스가 그대로 존재했습니다. 하지만 이제 각 엣지 케이스에는 이름이 있고, 트리거 조건이 있고, 브레이크포인트를 걸 수 있는 코드상의 자리가 있습니다. 이것은 다른 종류의 승리이고, 시스템이 계속 진화할 수 있는지 아니면 제 무게에 짓눌려 무너지는지를 결정하는 요소입니다.

Spike 23이 끝날 무렵, 우리에게는 상호작용 버그에 대한 끊임없는 두려움 없이 원거리 clipmap 링 전략에 연결할 수 있을 만큼 예측 가능한 근거리 동작 레이어가 생겼습니다.

12부에서는 Spike 24를 다룹니다. 링 전환, 스카이박스 안개, Three.js 버전 수준의 셰이더 통합이 이 프로젝트의 이 챕터를 마무리합니다.

이 챕터에서 언급한 기술

거리 기반 LOD 정책. 카메라까지의 거리, 편집 이력, 이웃 상태를 바탕으로 각 chunk에 LOD 레벨과 렌더링 모드를 할당하는 중앙 함수입니다. 동심 거리 링이 기본 LOD를 결정합니다. 링 0 = 전체 해상도 MC, 링 1 = 절반 해상도 MC, 링 2+ = heightmap 모드. 정책 함수는 카메라가 움직임에 따라 프레임마다 실행되며 chunk 전환을 트리거합니다. 이것은 즉흥적인 chunk별 결정을 예측 가능하고 디버깅 가능한 규칙 시스템으로 바꿉니다. compute shader 등가물은 GPU 기반 LOD 선택을 보세요.

인접 제약. Transvoxel 알고리즘은 2:1 해상도 비율만 처리합니다. 이웃한 두 chunk가 한 LOD 레벨을 초과해 차이 나면(예: LOD 0 옆에 LOD 2), 전환 테이블이 유효한 이음매 지오메트리를 만들 수 없습니다. 정책 시스템은 LOD 차이가 1을 넘을 때 더 낮은 디테일의 chunk를 업그레이드해 이를 강제합니다. 이 제약 전파는 연쇄될 수 있습니다. 한 chunk를 업그레이드하면 그 이웃들도 업그레이드를 강제할 수 있습니다. 구현은 단순한 반복 패스이며, 일반적인 그리드 구성에서 2-3회 반복이면 수렴합니다.

모드 선택을 위한 편집 비트맵. 각 chunk는 볼류메트릭 SDF 편집(동굴, 터널, 조각)을 포함하는지 기록하는 비트맵을 유지합니다. 편집이 하나라도 있는 chunk는 거리와 관계없이 marching cubes 모드에 남아 창작자의 수정을 보존합니다. 편집되지 않은 chunk는 카메라에서 충분히 멀어지면 heightmap 모드로 내려가 연산과 메모리를 아낍니다. 비트맵은 chunk당 단일 플래그이지만, 더 세분화된 모드 결정을 위해 편집 밀도를 추적하도록 확장할 수 있습니다.

디버그 시각화 오버레이. 색상으로 구분한 chunk 렌더링으로, 녹색 = heightmap 모드, 파란색 = MC 모드, 주황색 = 전환이 활성화된 면입니다. LOD 레벨 숫자, 모드 라벨, wireframe 토글이 달린 chunk별 오버레이도 있습니다. 이것들은 출시 기능이 아니라 개발 도구이지만, LOD 전환과 이음매 아티팩트를 디버깅할 때 거듭 본전을 뽑습니다. 정확한 월드 위치를 알려주는 WASD 비행 카메라와 결합하면, "어딘가에서 버그를 봤다"가 "버그는 이 LOD 구성에서 (142, 12, -67)에 나타난다"로 바뀝니다.

12부 중 11부.
이전: 10부 - 이음매 혼돈과 코너 보스전
다음: 12부 - 링, 하늘 안개, 그리고 다시 한다면 할 일
시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

처음이신가요? 시리즈 가이드를 보세요. spike가 무엇인지 설명하고 모든 파트를 링크해 둡니다.

Spike 24는 원래 "지형에 clipmap 링을 추가"하는 작업이어야 했습니다. 그런데 렌더링, 셰이더, 모듈 인프라, 비주얼 통합을 한꺼번에 건드린 본격적인 피날레가 되어 버렸습니다.

핵심 지형 작업은 버텍스 셰이더에서 카메라를 중심으로 한 동심원 clipmap 링을 생성하는 것이었습니다. 각 링은 카메라를 중심으로 한 평면 그리드 메시이고, 버텍스는 heightmap 샘플로 변위됩니다. 가장 안쪽 링은 최대 해상도를 씁니다. 바깥쪽으로 갈수록 링마다 버텍스 간격이 두 배가 되고 더 넓은 영역을 덮습니다. 까다로운 부분은 링 사이의 경계입니다. 고해상도 링이 저해상도 링과 만나는 곳에서, 더 촘촘한 메시의 가장자리 버텍스는 더 성긴 메시 가장자리의 중점으로 스냅되어야 합니다. 우리는 경계 버텍스(링 가장자리를 따라 그리드 좌표가 홀수인 버텍스)를 감지해 그 높이를 양쪽 짝수 이웃의 중점으로 스냅하는 방식으로 2:1 가장자리 모핑을 했습니다. $h=\frac{1}{2}(h_{\text{left}}+h_{\text{right}})$. 이게 정확히 성긴 링의 한 가장자리가 놓이는 지점이라서, 촘촘한 가장자리와 성긴 가장자리가 같은 선을 그립니다. 이렇게 하면 전환용 지오메트리 없이도 빈틈없는 이음새가 만들어집니다.

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

그다음은 안개와 하늘 통합이었습니다. 우리는 멀리 있는 지형이 평평한 상수 색이 아니라 실제 하늘 색으로 페이드되길 원했습니다. 그러려면 안개 셰이더가 각 프래그먼트의 방향에서 하늘이 어떤 색일지 알아야 했습니다. 우리는 equirectangular HDR 스카이박스 텍스처를 로드하고, 카메라에서 프래그먼트로 향하는 뷰 방향으로 프래그먼트 셰이더에서 샘플링했습니다. 이때 TSL의 equirectUV 노드로 equirectangular UV 좌표로 변환했습니다. 안개 계수는 카메라 공간 깊이를 위한 positionView.z.negate()를 써서 거리 기반으로 구하고, 가까운 거리와 먼 거리 사이를 smoothstep으로 블렌딩했습니다.

모듈 배선은 어떤 지오메트리보다도 더 성가신 일이었습니다. 우리는 Three.js 0.183.1로 올렸는데, 이게 빌드 출력물 구조를 바꿔 놨습니다. three/tsl import는 three.tsl.js로 해석되어야 했고, TSL은 내부적으로 three/webgpu를 bare specifier로 import했습니다. 두 매핑 모두 HTML import map에 명시되어야 했습니다. 어느 하나라도 빠지면 어떤 매핑이 잘못됐는지 전혀 알려주지 않는 "does not provide an export" 또는 "failed to resolve module specifier" 같은 알쏭달쏭한 오류가 났습니다. 둘 다 import map에 들어가고 나니 셰이더 그래프가 제대로 로드됐습니다.

스카이박스 방향 문제도 있었는데, 텍스처가 위아래가 뒤집혀 렌더링됐습니다. 해결책은 equirectangular 텍스처에 flipY = true를 주는 것이었습니다. 이건 로드된 텍스처에 대한 Three.js 기본값이지만, 우리 초기 코드에서는 false로 설정되어 있었습니다.

원래 안개 구현은 거의 상수에 가까운 방향에서 하늘을 샘플링해서, 자연스러운 그라디언트 대신 지평선 색의 얇은 띠를 만들어 냈습니다. 해결책은 픽셀마다 실제 카메라-프래그먼트 월드 방향을 positionWorld.sub(cameraPosition).normalize()로 계산해, 그걸 equirectUV에 넘겨 안개 색을 조회하는 것이었습니다. 이렇게 하니 지형 프래그먼트가 실제로 그 뒤에 있는 하늘 색으로 페이드돼서, 어느 카메라 각도에서 봐도 맞아 보였습니다.

개별 수정들 아래에서, 핵심 결과는 유지됐습니다. 이제 우리는 근거리 볼류메트릭 편집(marching cubes에 Transvoxel 이음새), 중거리 heightmap 청크, 원거리 clipmap 링을 결합한 지형 시스템을 갖췄고, 이 모두가 모드, LOD, 전환 동작을 결정하는 정책 레이어의 관리를 받습니다.

다음 프로젝트에서 다시 쓸 패턴을 꼽으라면, 이런 것들입니다.

기능 작업에 들어가기 전에 리스크 spike부터 시작하세요. Spike 1은 콘텐츠 파이프라인에 투자하기 전에 "우리가 충분히 빠르게 렌더링이라도 할 수 있나"라는 질문을 먼저 정리해 줬습니다.

통합 점프 전에 검증된 안정 베이스라인을 동결하세요. Spike 13과 14는 회귀를 이분 탐색하느라 날릴 며칠을 아껴 줬습니다.

최적화 마라톤 전에 정책과 관측 가능성을 강제하세요. Spike 23은 정체불명의 버그를 트리거 규칙이 붙은 이름 있는 조건으로 바꿔 줬습니다.

스크린샷이 아니라 움직임 속에서 테스트하세요. clipmap 팝, 이음새 깜빡임, 스트리밍 끊김은 전부 정지 프레임에 숨어 있습니다.

평균 FPS가 아니라 기능별 프레임 시간 비용을 측정하세요. 평균은 사용자가 실제로 느끼는 스파이크를 가립니다.

그리고 지저분한 부분을 공개하세요. 잘못 든 길, 오래된 버퍼 유령 사냥, 실제로는 draw range가 잘못됐는데 전환 로직을 탓하며 보낸 이틀. 사람들이 정말로 배울 수 있는 건 바로 그런 부분입니다.

외부 현실 점검: Vuntra City 개발 일지

이 시리즈를 끝낸 뒤, 우리는 우리 오픈 월드 가정에 대한 외부 구현 점검으로 @VuntraCity 개발 일지를 살펴봤습니다. 그건 브라우저 스택이 아니라 네이티브 UE5 프로젝트지만, 시스템 패턴이 꽤 잘 대응돼서 비교가 쓸모 있었습니다.

첫 번째 신호는 이동 속도가 게임플레이만이 아니라 스트리밍 제어로 다뤄져야 한다는 것입니다. Vuntra City에서는 고속 이동이 의도적으로 대부분의 실내 위로 우회되고, 스폰 churn과 정체를 피하려고 디테일 범위가 이동 속도에 맞춰 조정됩니다(교통 시스템, 성능 기법). 이건 우리 정책 레이어 방향과 일치합니다. 이동 모드는 청크 반경, 실내 활성화, 프레임당 허용 작업량에 직접 영향을 줘야 합니다.

두 번째 신호는 아키텍처입니다. 그들의 맵과 주소 시스템은, 로드되지 않은 영역에 대해서도 전역 쿼리가 돌 수 있도록 월드 토폴로지를 렌더링되는 오브젝트와 분리해야 했습니다(맵과 주소). 이건 브라우저에서 월드 검색, 퀘스트 라우팅, 모더레이션 스캔, POI 인덱싱을 렌더링에 묶인 데이터 경로를 강제하지 않고 하기 위해 우리에게도 필요한 바로 그 분리입니다.

세 번째 신호는 시뮬레이션 티어링입니다. 그들의 백만 NPC 설계는 거친 스케줄 상태는 저렴하고 전역적으로 유지하면서, 비싼 행동 예산은 플레이어 근처에서만 씁니다(백만 NPC 개요, 시스템 심층 분석). 이건 우리 AOI 우선 시뮬레이션 모델을 뒷받침합니다. 근거리 충실도와 원거리 결정론은 별도의 예산을 가진 별개의 관심사입니다.

그리고 네 번째 신호는 순수한 규모가 아니라 디자인 품질입니다. 그들의 가장 강렬한 탐험 순간은 끊임없는 UI 오버레이가 아니라 가중 분포, 희귀한 이상치, 디제틱한 길찾기 단서에서 나옵니다(절차적 환경 노트, 미니맵 없는 루프). 우리에게 이건, 기술 시스템이 단순히 최대 처리량이 아니라 발견 가능한 다양성을 만들어 내도록 튜닝되어야 한다는 점을 일깨워 줍니다.

이 챕터에서 언급한 기술

Clipmap 링 지오메트리. 각 링은 카메라를 중심으로 한 평면 그리드 메시이고, 버텍스는 heightmap 샘플로 변위됩니다. 가장 안쪽 링은 최대 해상도를 씁니다. 바깥쪽으로 갈수록 링마다 버텍스 간격이 두 배가 되고 더 넓은 영역을 덮습니다. 까다로운 부분은 경계입니다. 고해상도 링이 저해상도 링과 만나는 곳에서, 더 촘촘한 메시의 가장자리 버텍스는 더 성긴 메시 가장자리의 중점으로 스냅됩니다. 이 기법은 Losasso와 Hoppe의 SIGGRAPH 2004 논문(PDF)에서 비롯됐고 GPU Gems 2, 2장에서 자세히 다룹니다. 우리의 지오메트리 clipmap에 관한 지형 가이드를 보세요.

2:1 가장자리 모핑. 두 clipmap 링 사이의 경계에서, 더 촘촘한 링은 더 성긴 링이 공유하지 않는 위치에 버텍스를 가집니다. 링 가장자리를 따라 그리드 좌표가 홀수인 경계 버텍스를 감지하고, 그 높이를 이웃한 두 짝수 버텍스 사이에서 보간합니다. 이렇게 하면 전용 전환 지오메트리 없이도 빈틈없는 이음새가 만들어집니다. 보간은 버텍스 셰이더에서 실행됩니다. 경계 버텍스에 대해 morphedHeight = mix(heightLeft, heightRight, 0.5)이며, 우리 가이드에서 설명한 것과 같은 지오모핑 프레임워크를 씁니다.

Equirectangular 스카이박스 매핑. 경도-위도 투영으로 하늘 방향의 완전한 구면을 매핑하는 하나의 2D 이미지입니다. 가로축은 0~360도를 덮고, 세로축은 0~180도를 덮습니다. 정규화된 뷰 방향 $\hat{d}=(d_x,d_y,d_z)$는 그 경도와 위도를 읽어 UV 좌표로 변환됩니다.

Three.js에서는 texture.mapping = EquirectangularReflectionMapping을 SRGBColorSpace와 함께 설정하면 이걸 씬 배경으로 활성화합니다. TSL에서는 equirectUV(direction)이 같은 변환을 적용해, 3D 뷰 방향을 텍스처 샘플링용 2D UV 좌표로 바꿉니다.

하늘에서 가져오는 프래그먼트별 안개 색. 표준 안개는 프래그먼트를 하나의 상수 색으로 블렌딩합니다. 디테일한 스카이박스가 있는 씬에서는 하늘 색이 방향마다 다르기 때문에 이게 잘못돼 보입니다. 해결책은 픽셀마다 카메라-프래그먼트 월드 방향(positionWorld.sub(cameraPosition).normalize())을 계산하고, 그 방향에서 스카이박스를 샘플링해 안개 색으로 쓰는 것입니다. 각 프래그먼트는 실제로 그 뒤에 있는 하늘 색으로 페이드돼서, 어느 카메라 각도에서도 올바르게 블렌딩됩니다. 안개 계수는 카메라 공간 깊이를 위한 positionView.z.negate()와 함께 smoothstep(nearDist, farDist, viewDepth)을 씁니다.

ES 모듈용 import map. bare 모듈 specifier(three/tsl 같은)를 실제 URL로 매핑하는 브라우저 네이티브 메커니즘(<script type="importmap">)입니다. Three.js 0.183.1이 빌드 출력물을 재구성하면서, three/tsl은 three.tsl.js로 해석되어야 했고 TSL은 내부적으로 three/webgpu를 bare specifier로 import했습니다. 두 매핑 모두 import map에 명시되어야 했고, 그렇지 않으면 브라우저가 "does not provide an export" 또는 "failed to resolve module specifier" 오류를 냈습니다.

더 읽을거리

이 시리즈 전반에서 사용한 기술을 더 깊이 다룬, 우리 동반 가이드를 보세요.

• 브라우저 오픈 월드를 위한 동적 LOD와 스트리밍 기반 지형 생성은 heightmap, SDF, marching cubes, Transvoxel, 지오메트리 clipmap, 지오모핑, 스트리밍 아키텍처, 지형 머티리얼, 식생 렌더링을 다룹니다.
• 멀티플레이어 크리에이터 월드를 위한 브라우저 3D 오픈 월드 기술은 렌더링 스택, WebGPU, 물리, 네트워킹, 멀티플레이어 아키텍처, 그리고 Skyrim, The Witcher 3, Breath of the Wild, GTA V에서 얻은 교훈을 다룹니다.

12부에 걸친 이 여정을 따라와 주셔서 감사합니다.

1부: 우리는 그걸 부수려는 것부터 시작했다
2부: 워커 물리와 입력 지연 공포
3부: 우리를 구한 화려하지 않은 spike들
4부: 화려한 지형보다 스트리밍 먼저
5부: 예쁜 것들에 예산 책정하기
6부: Clipmap이 줄거리를 바꿨다
7부: Marching cubes와 첫 진짜 동굴
8부: 베이스라인을 잃지 않고 통합하기
9부: Transvoxel은 뼈대부터 시작했다
10부: 이음새 혼돈과 코너 보스전
11부: 하드코딩 모드가 아니라 정책 모드

14부 중 12부.
이전: 11부 - 하드코딩 모드가 아니라 정책 모드
다음: 13부 - 지형 조각과 수학 함수의 죽음
시리즈 가이드: /ko/blog/2026-02-25-open-world-browser-series-guide

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

이 페이지는 시리즈 전체를 위한 길잡이 허브입니다.

어쩌다 한 편만 보고 들어왔다면 여기서 시작하세요.

2026년 3월 업데이트: Part 12에 Vuntra City 개발 일지에서 가져온 외부 구현 교차 점검을 추가했고, 같은 발견을 담아 자매편 브라우저 오픈 월드 기술 가이드를 확장했습니다.

2026년 4월 업데이트: Part 13-14는 지형 조각(Spike 25-27)과 비주얼/게임플레이 레이어, 즉 멀티 머티리얼 텍스처링, 인스턴스드 식생, HM+SDF 충돌이 들어간 character controller(Spike 28-30)를 다룹니다.

2026년 5월 업데이트: 시리즈는 29부까지 갔습니다. Part 15-29는 빌드의 긴 중반을 다룹니다. 멀티플레이어 지형과 물, 코드 구조 리팩터, 애니메이션과 AI 산포, 임포스터와 패럴랙스, 결국 본전을 못 뽑은 가시성 버퍼, 구름과 메시렛 컬링, 배치 처리한 아바타와 근접 음성, 월드 영속성과 GPU 바람, 유니버설 캐릭터, 물을 만드는 세 가지 방법, 절차적 섬, 풀과 오클루전, 그리고 어떤 몸체든 구동하는 플러그형 character controller(Spike 31-60)까지 이어집니다.

2026년 6월 업데이트: Part 30은 충돌을 인식하는 카메라를 추가합니다. 플러그형 콜라이더 계약을 가진 스프링암 붐과, 언덕뿐 아니라 돌출부나 동굴 천장에도 시점이 막히게 하는 부호 거리 프로브를 다룹니다.

이 시리즈에서 "spike"가 뜻하는 것

spike는 짧고 집중된 실험입니다.

각 spike는 위험한 질문 하나를 테스트합니다. 범위를 좁게 유지하고, 정말 중요한 것을 측정한 다음, 다음에 무엇을 할지 결정합니다. 잘 다듬어진 기능이 아니라 학습 도구라고 생각하면 됩니다.

이 프로젝트에서 spike는 대부분 /spikes/* 아래에 있는 독립 페이지로, 직접 실행해 볼 수 있습니다.

시리즈를 순서대로 읽기

1. Part 1: 우리는 그것을 부수려는 시도부터 시작했다
2. Part 2: Worker 물리와 입력 지연에 대한 두려움
3. Part 3: 우리를 구한 화려하지 않은 spike들
4. Part 4: 화려한 지형보다 먼저 스트리밍
5. Part 5: 예쁜 것들에 예산 매기기
6. Part 6: Clipmap이 줄거리를 바꿨다
7. Part 7: Marching cubes와 첫 진짜 동굴들
8. Part 8: 베이스라인을 잃지 않고 통합하기
9. Part 9: Transvoxel은 골격부터 시작했다
10. Part 10: 이음새 혼돈과 모서리 보스전
11. Part 11: 하드코딩 모드가 아니라 정책 모드
12. Part 12: 링, 하늘 안개, 그리고 다시 할 것들
13. Part 13: 지형 조각과 수학 함수의 죽음
14. Part 14: 세계가 살아난다
15. Part 15: 베이스라인을 교체하고, 그다음 동기화하기
16. Part 16: 계속 자라는 세계를 위한 구조
17. Part 17: 리타게팅이 필요 없던 애니메이션, 그리고 실시간 에셋 검색
18. Part 18: AI가 배치한 듯한 산포 브러시
19. Part 19: 숲에서 살아남아야 하는 임포스터
20. Part 20: 평평한 면에서 깊이 속이기
21. Part 21: 더 빠르지 않았던 더 빠른 렌더러
22. Part 22: 조명을 줄 수 있는 구름, 그리고 먹여 줘야 하는 컬링
23. Part 23: 아바타 쉰 명, 그리고 방 안의 목소리
24. Part 24: 세계를 저장하기, 그리고 눈에 보이는 바람
25. Part 25: 골격 하나, 모든 의상
26. Part 26: 물을 만드는 세 가지 방법
27. Part 27: 노이즈에서 나온 섬, 땅처럼 보이는 땅
28. Part 28: 지평선까지 뻗는 풀, 그리고 스스로 숨는 땅
29. Part 29: 컨트롤러 하나, 어떤 몸체든
30. Part 30: 벽을 존중하는 카메라

라이브 spike 지도

기술 타임라인을 직접 클릭해 보고 싶다면 이것들로 시작하세요.

Spike 1 지형과 인스턴싱 · 소스
Spike 2 worker 물리 · 소스
Spike 3 Durable Object 브로드캐스트 부하 테스트는 독립 페이지가 아니라 서비스 스크립트로 실행됨
Spike 4 모바일 품질 제약, Spike 1의 query 파라미터로 테스트함
Spike 5 LLM 동작 신뢰성, 독립 페이지가 아니라 스크립트로 실행됨
Spike 6 chunk 로드와 교체 · 소스
Spike 7 밀도 맵에서 만든 식생 · 소스
Spike 8 지형 머티리얼 비용 · 소스
Spike 9 캐스케이드 섀도 예산 · 소스
Spike 10 clipmap과 geomorphing · 소스
Spike 11 heightmap chunk 스트리밍 · 소스
Spike 12 WebGPU marching cubes · 소스
Spike 13 WebGPU 통합 베이스라인 · 소스
Spike 14 점진적 강화 · 소스
Spike 15 이음새 골격 · 소스
Spike 16 첫 Transvoxel 면 · 소스
Spike 17 듀얼 MC LOD · 소스
Spike 18 heightmap 이음새 · 소스
Spike 19 혼합 해상도 모서리 · 소스
Spike 20 GPU 모서리 이음새 · 소스
Spike 21 GPU MC 모서리 이음새 · 소스
Spike 22 MC에서 HM으로의 fallback · 소스
Spike 23 정책 기반 chunk 모드 · 소스
Spike 24 clipmap 링과 하늘 안개 · 소스
Spike 25 샘플링한 데이터 위의 heightmap 브러시 · 소스
Spike 26 GPU compute를 통한 SDF 브러시 · 소스
Spike 27 HM + MC + 브러시 통합 · 소스
Spike 28 멀티 머티리얼 텍스처링 · 소스
Spike 29 식생과 셰이더 풀 · 소스
Spike 30 지형 물리와 character controller · 소스
Spike 31 멀티플레이어 지형 동기화 · 소스
Spike 32 물과 수영 · 소스
Spike 33 코드 구조 리팩터 · 소스
Spike 34 월드 내 오서링 · 소스
Spike 35 전투 애니메이션과 리타게팅 · 소스
Spike 36 실시간 Poly Haven 에셋 검색 · 소스
Spike 37 AI 보조 소품 산포 · 소스
Spike 38 팔면체 임포스터 · 소스
Spike 39 패럴랙스 오클루전 매핑 · 소스
Spike 40 가시성 버퍼 렌더러 · 소스
Spike 41 숲 속의 임포스터 · 소스
Spike 42 임포스터 깜빡임 수정 · 소스
Spike 43 대기와 볼류메트릭 구름 · 소스
Spike 44 메시렛 Hi-Z 컬링 · 소스
Spike 45 배치 아바타 스키닝과 네트워크 동기화 · 소스
Spike 46 근접 음성 채팅 · 소스
Spike 47 서버 권위 월드 영속성 · 소스
Spike 48 아바타 리그 통합, 이후 spike들이 공유 코드로 재사용함(독립 페이지 없음)
Spike 49 소품과 잎사귀 위의 GPU 바람 · 소스
Spike 50 유니버설 캐릭터와 착용물 · 소스
Spike 51 스크린 스페이스 리플렉션 물 · 소스
Spike 52 평면 거울 물 · 소스
Spike 53 프로덕션 물 라이브러리 · 소스
Spike 54 절차적 섬 생성 · 소스
Spike 55 지형 셰이딩과 타일링 깨뜨리기 · 소스
Spike 56 GPU 교차 쿼드 풀 · 소스
Spike 57 지형 오클루전 컬링 · 소스
Spike 58 플러그형 character controller · 소스
Spike 59 실제 아바타가 붙은 컨트롤러 · 소스
Spike 60 Synty 폴리곤 애니메이션 · 소스

글 Mariana Muntean, Cinevva CEO

우리는 뱀이 패들이 되고 벽돌이 반격하는 게임을 만들었습니다. 웹, 모바일, PC에 모두 출시했습니다. 두 사람이 약 사흘 동안 만들었습니다. 짬짬이, 무리하지 않고요. 그리고 정말로 재미있습니다.

바로 그 마지막 부분이 주목할 만한 지점입니다.

아무도 부탁하지 않은 그 조합

스네이크는 성장과 공간 감각에 관한 게임입니다. 아르카노이드는 반사 신경과 각도 예측에 관한 게임입니다. 둘은 완전히 다른 설계 철학에서 나왔고, 이 둘을 한데 섞는다는 건 정중하게 거절당할 만한 제안처럼 들립니다.

하지만 A Breaker Belt는 그걸 해냅니다. 당신은 우주 뱀, 표류하는 금속 척추와 혜성 실로 엮인 살아있는 네온 전류의 호가 되어, 깨지는 블록으로 가득한 소행성 지대를 누빕니다. 당신의 머리는 패들입니다. 점점 길어지는 꼬리는 가장 강력한 무기이자 가장 끊임없는 위협입니다. 구체는 당신의 몸에 튕겨 벽돌을 부수지만, 한 번이라도 방향을 잘못 틀어 자기 꼬리를 들이받으면 끝입니다.

이건 보통 아무도 플레이해보기 전에 죽어버리는 그런 이상한 장르 교차 실험입니다. 이상한 아이디어가 통하는지 알아내는 개발 비용이 전통적으로 "개월" 단위로 측정되기 때문이죠. 여기서는 "오후" 단위로 측정됐습니다.

실제로 출시된 것

규모가 이걸 흥미롭게 만듭니다. 자리만 채운 사각형과 소리도 없는 게임 잼 프로토타입이 아닙니다.

게임은 50개 웨이브까지 깊게 이어집니다. 똑같은 벽돌 벽의 50가지 변형이 아닙니다. 진형은 부드러운 입문용 호에서 시작해, 측면 틈으로 비스듬한 샷을 요구하는 요새 고리로 진화하고, 다시 한 칸 너비의 입구를 통과하려면 정밀한 조향이 필요한 다층 대각선 미로로 발전합니다. 폭발 벽돌은 이웃을 함께 날려버립니다. 유령 벽돌은 존재와 비존재 사이를 깜빡입니다. 재생 벽돌은 깨고 나면 다시 회복돼서, 왼쪽에서 오른쪽으로 쓸어내는 대신 목표의 우선순위를 정하게 만듭니다. 포털 벽돌은 당신의 구체를 경기장 반대편으로 순간이동시킵니다. 중력 우물은 당신의 샷을 느리게 휘어지는 찬송가로 구부립니다. 레이저 방출기는 허공에 붉은 선을 그립니다. 미믹 벽돌은 해롭지 않아 보이다가, 해롭지 않기를 그만두기로 마음먹습니다. 15번째 웨이브쯤 되면 당신이 헤쳐 나가는 건 퍼즐이라기보다 당신의 습관을 학습하는 살아있는 시스템처럼 느껴집니다.

음악은 루프가 아닙니다. 당신의 플레이와 함께 쌓여가는 반응형 사운드트랙입니다. 바탕 시스템은 E 단조 140 BPM으로 베이스 라인, 리드 신스, 패드, 킥, 스네어, 하이햇을 돌리고, 액션이 격해질수록 추가 타악기와 신스 레이어가 페이드인합니다. 웨이브 사이에 분위기가 가라앉으면 앰비언트 패드가 넘겨받습니다. 음악이 당신과 함께 호흡합니다. 전담 작곡가라면 그런 반응성을 다듬는 데 몇 주를 쓸 겁니다. 여기서는 그게 창작 흐름의 일부였습니다.

음향 효과는 무료 팩에서 끌어온 샘플이 아닙니다. 모든 벽돌 부서짐, 파워업 획득, 구체 튕김, 충돌이 실시간으로 합성됩니다. 머리 접촉과 꼬리 접촉은 음높이가 다릅니다. 우주적인 느낌을 위한 따뜻한 리버브. 거슬리지 않으면서도 만족스럽게 유지하는 로우패스 필터링. 콤보를 연결하면 화면보다 소리가 먼저 알려줍니다.

그리고 스토리텔링이 있습니다. 각 웨이브는 AI로 생성된 음성이 전하는 서사의 한 박자로 시작합니다. 글에는 진짜 개성이 있습니다. 첫 번째 웨이브: "그들은 그것을 Breaker Belt라 부른다. 오래된 별을 경고처럼 도는, 설계된 잔해의 띠다." 38번째 웨이브쯤이면: "이 Belt는 벽처럼 느껴지기를 멈추고 정신처럼 느껴지기 시작한다. 그것은 너의 반사 신경이 아니라 너의 습관을 시험한다. 너는 습관을 깬다. Belt는 알아차린다." 당신이 왜 우주에서 벽돌을 깨는 뱀인지 마음 쓰게 만드는 50장의 우주 신화입니다.

배경도 진화합니다. 초반 웨이브는 부드러운 유성우가 내리는 차분한 남색 별밭입니다. 중반에 이르면 오로라 띠와 성운 구름이 나타납니다. 후반은 완전히 Ion Storm 스타일로, 거의 검은 우주를 가로지르는 날카로운 청록색 줄무늬가 펼쳐집니다. 15번째 웨이브와 그 이후로는 Event Horizon의 영역입니다. 느리게 움직이는 성운 필라멘트와 희미한 블랙홀 렌즈 효과가 점점이 박힌 깊은 허공이죠. 게임은 난이도만큼이나 분위기로 진행 상황을 전달합니다.

이 모든 게 키보드, 게임패드, 터치스크린에서 돌아갑니다. 하나의 코드베이스에서 웹, 모바일, PC로 출시됐습니다. 별도 빌드도, 포팅도 없습니다.

필요 없었던 팀

여기가 게임 개발자라면 누구든 잠시 멈춰야 할 부분입니다.

이 정도 콘텐츠 깊이의 게임이라면 보통 게임 디자이너, 프로그래머 두어 명, 2D 아티스트, 사운드 디자이너, 작곡가, 레벨 디자이너, 서사 작가, 그리고 QA가 필요합니다. 여덟아홉 명이죠. 적당한 인디 속도로 본다면 서너 달에서 여섯 달의 협업이 걸립니다. 스탠드업, Jira 티켓, 에셋 파이프라인, 플랫폼별 디버깅까지요.

우리 둘이 Cinevva Engine에서 긴 주말 한 번에 이걸 만들었습니다.

필요한 재능이 바뀐 게 아닙니다. 창작 의도와 구현 부담 사이의 비율이 바뀐 겁니다. 시간은 게임이 어떤 느낌이어야 하는지 정하는 데 쓰였지, 그걸 만들려고 도구와 싸우는 데 쓰이지 않았습니다.

당신이 무언가를 만든다면 이게 왜 중요한가

흥미로운 질문은 AI 도구가 게임을 더 빨리 만드는 데 도움이 되느냐가 아닙니다. 그건 이미 답이 나왔습니다. 흥미로운 질문은, 예전에는 시도하기엔 너무 위험했던 아이디어들에 무슨 일이 생기느냐입니다.

"스네이크인데 당신이 아르카노이드 경기장의 패들"이라는 건 프로듀서가 승인할 만한 게 아닙니다. 몇몇 인디 개발자가 itch.io에서 이 조합의 변형을 시도해봤지만(BreakSnake, SnakeOut, Snake Break), 모두 작은 게임 잼 실험입니다. 이 장르 융합은 반응형 음악, AI 내레이션, 수십 종의 벽돌, 50개 웨이브의 점증하는 레벨 디자인을 갖춘 진짜 제작 단계를 거쳐본 적이 없습니다. 전통적인 개발에서 위험한 콘셉트에 그만한 완성도를 들이는 일은 아무도 코드 한 줄 쓰기 전에 회의에서 죽습니다.

이상한 걸 시도하는 비용이 한 분기 예산이 아니라 오후 한나절이 되면, 이상한 아이디어들이 실제로 만들어집니다. 그중 일부는 정말로 괜찮은 것으로 드러납니다. A Breaker Belt가 그중 하나입니다.

플레이하세요. 아니면 직접 만드세요.

A Breaker Belt는 지금 바로 웹, 모바일, PC에서 플레이할 수 있습니다. 뭔가 만들고 싶어진다면 Cinevva Engine은 무료로 쓸 수 있습니다. 원하는 걸 설명하고, 돌아온 결과물을 다듬고, 준비되면 출시하세요. 음악, 음향 효과, 아트, 3D 모델이 모두 내장돼 있습니다.

당신의 이상한 게임 아이디어가 존재하기까지 사흘밖에 안 남았을지도 모릅니다.

A Breaker Belt 플레이하기 | 직접 게임 만들기 | 커뮤니티 게임 둘러보기

관련 글:

• 바이브 코딩은 새로운 게임 잼이다 — AI 도구가 아이디어와 프로토타입 사이의 간극을 어떻게 좁히는가
• 게임 잼 & 해커톤 — 이상한 조합을 가능하게 하는 잼 형식
• 웹 게임 엔진 비교 — 웹, 모바일, PC로 출시하기 위한 엔진

Mariana Muntean, Cinevva CEO

Cinevva 플랫폼에는 음악 생성기가 있습니다. 게임 창작자들이 라이선스 문제로 골치 아플 일 없이 게임 사운드트랙과 효과음을 만들 수 있게 하려고 만든 것이죠. 그런데 그다음에 벌어진 일은 우리 계획에 없던 거였습니다. 사람들이 그냥 음악을 만들고 싶어서 음악을 만들기 시작했습니다. 게임이나 프로젝트를 위해서가 아니라요. 순수하게 음악 제작이었습니다.

Bella Bay는 2주 만에 100곡 넘게 만들었습니다

과장이 아닙니다. 우리 창작자 중 한 명인 Bella Bay는 약 2주 만에 100곡이 넘는 트랙을 생성했습니다. Cinevva Radio에서 그 곡들을 쭉 들어 보면 발전 과정이 들립니다. 초반 트랙들은 실험입니다. 후반 트랙들은 자기 스타일을 찾은 사람의 작품처럼 들립니다. 이런 식의 창작 가속은 도구와 씨름하고 있을 때는 일어나지 않습니다. 도구가 비켜 줄 때 일어납니다.

Bella Bay는 마음가짐에서 예외적인 게 아니라 양에서만 예외적입니다. 플랫폼 전반에서 사람들이 음악 생성기를 게임 에셋용 도구가 아니라 창작 악기로 다루기 시작했습니다. 한 번도 시도하지 않았던 장르를 실험하는 프로듀서들. 딱 맞아떨어질 때까지 한 사운드를 계속 다듬는 사람들. 제대로 된 제작 도구를 한 번도 써 본 적 없던 침실 아티스트들이 갑자기 그 도구를 손에 넣고 전력을 다했습니다.

그래서 라디오를 만들었습니다

안 만들 수가 없었습니다.

이 모든 트랙이 각자의 계정 안에 모여 있을 공간 없이 흩어져 있었습니다. 다른 사람들이 뭘 만들고 있는지 발견할 방법도 없었고요. 당신의 오후를 바꿔 놓을 트랙을 우연히 마주칠 방법도 없었습니다.

Cinevva Radio가 이제 문을 열었습니다. 여덟 개 방송국. 362곡의 커뮤니티 창작 트랙이 있고 매일 늘어나고 있습니다. 모든 곡이 플랫폼에 있는 누군가가 만든 것입니다. 열면 뭔가가 흘러나옵니다. 검색할 필요도 없고 고를 필요도 없습니다. 그냥 들으면 됩니다.

**Soundstage**는 우리의 가장 큰 방송국입니다. 영화 같고 웅장한 스코어 111곡. 솔직히 이건 예상 못 했습니다. 사람들은 드라마틱한 영화풍 음악 만드는 걸 정말 좋아하더군요.

**Discovery**는 어떤 장르에도 깔끔하게 들어맞지 않는 것들을 다 담았습니다. 78곡. 라틴 비트 옆에 Afrobeats, 그 옆에 컨트리, 또 그 옆에 뭐라 설명할 수 없는 무언가. 이 방송국은 정말 거칩니다.

**Main Stage**는 팝과 보컬 트랙입니다. 완전한 가사와 보컬이 들어간 56곡. 사람들이 러브송, 이별 노래, 워십 음악, 발라드를 쓰고 있습니다. 일부는 진짜로 귀에 꽂힙니다.

**Voltage**는 록과 메탈입니다. 53곡. 기타 리프, 펑크의 에너지, 그런지, 하드 록. 저는 일할 때 이걸 틀어 둡니다.

**Lo-Fi Cafe**는 이름 그대로입니다. 공부하거나 일하거나 그냥 분위기 즐기기 좋은 차분한 앰비언트 트랙 25곡.

**Electric Dreams**에는 전자 음악과 신스 트랙 22곡이 있습니다. Synthwave, techno, EDM, drum and bass.

**Ivory Tower**는 클래식과 오케스트라입니다. 10곡. 피아노곡, 현악 편곡, 교향곡풍 작품들. 작지만 커 가고 있습니다.

**The Cipher**는 힙합과 랩입니다. 아직 7곡. 가장 새로운 방송국이고 여전히 자기 색깔을 찾는 중입니다.

들을 때 보이는 것

Cinevva Radio를 열면 라이브 스트림입니다. 플레이리스트 앱이라기보다 실제 라디오 방송국에 더 가깝다고 생각하시면 됩니다. 트랙이 끊김 없이 계속 재생됩니다. 실시간으로 반응하고, 다른 청취자들과 채팅하고, 각 트랙을 누가 만들었는지 볼 수 있습니다.

창작자는 자기 트랙이 재생되는 동안 화면에 크레딧으로 표시됩니다. 이름, 프롬프트, 장르까지요. 마음에 드는 곡을 들으면 누가 만들었는지 알 수 있습니다. 커뮤니티가 만든 콘텐츠 위에 발견 레이어를 한 겹 얹은 것입니다. 무엇이 들을 만한지 알고리즘이 정하지 않습니다. 문지기도 없습니다. 당신이 트랙을 하나 만들면 그 장르에 맞는 방송국에 올라가고, 사람들이 듣습니다.

이건 하나의 기능보다 큽니다

수십 년 동안 음악 제작에는 값비싼 소프트웨어, 여러 해의 훈련, 그리고 대부분의 사람이 살 수 없는 장비가 필요했습니다. 우리가 지금 보고 있는 건 다른 종류의 창작자입니다. 음표와 박자표가 아니라 묘사와 감정으로 사고하는 사람들이죠.

"고장 난 피아노로 연주하는 비 오는 밤의 재즈"는 하나의 창작 방향입니다. 그 프롬프트를 쓴 사람은 예술적 선택을 한 것입니다. 분위기, 악기 편성, 감정의 결을 연출했습니다. 단지 피아노를 칠 줄 모를 뿐이죠.

저는 그게 그 사람의 결과물을 덜 정당하게 만든다고 생각하지 않습니다. "음악가"라는 정의가 넓어지고 있다는 뜻이라고 봅니다. 그리고 Bella Bay 같은 사람이 2주 만에 0에서 100곡까지 가는 걸 보면, 창작 욕구는 늘 거기 있었다는 걸 알 수 있습니다. 도구가 없었을 뿐입니다.

다음 단계

우리는 프로듀서들이 자기 카탈로그를 보여 주고 팬을 모을 수 있는 커뮤니티 프로필을 만들고 있습니다. 차트 페이지는 이미 모든 도구에 걸친 커뮤니티 창작물을 보여 주고 있는데, 우리는 바로 그 에너지를 음악에도 똑같이 가져오고 싶습니다.

하지만 지금 당장, 라디오는 열려 있습니다. 들으러 가세요. 그리고 직접 트랙을 만들고 싶다면 음악 생성기는 무료로 쓸 수 있습니다. 당신의 트랙이 전파를 탈지도 모릅니다.

Cinevva Radio 듣기 | 음악 만들기 | 커뮤니티 창작물 둘러보기

관련 글:

• 최전선 오픈소스 생성형 AI 모델 — 뒤에서 돌아가는 AI 음악 및 오디오 모델
• 게임을 위한 Web Audio API — 브라우저에서 인터랙티브 오디오 만들기
• Vibe coding은 새로운 game jam이다 — 의도를 묘사하는 것이 어떻게 주된 창작 입력이 되는가

글 Mariana Muntean, Cinevva CEO

AI는 사실상 순수한 논리와 계산 능력을 흔한 상품으로 만들어버렸다. 우리가 떠받들던 능력들, 암산, 패턴 인식, 복잡한 알고리즘을 끈질기게 풀어내는 능력, 이 모든 걸 이제 AI가 한다. 더 빠르게, 더 잘, 지치지도 않고. 그래도 우리가 그걸 알아야 할까? 당연히 그렇다. 하지만 인식은 바뀐다. 이제 모두가 새로운 시대에 맞춰가야 한다. 직관적인 상호작용과 결과의 시대 말이다.

NVIDIA CEO 젠슨 황에 따르면, 이제 중요한 건 "분위기"를 감지하고 데이터가 나타나기 전에 모퉁이 너머를 내다보는 능력이다. 기술적 소양과 깊은 공감이 만나는 지점. 실리콘이 닿을 수 없는 직관적인 이해.

그만큼 신뢰받는 사람이 내 인생 전체의 궤적을 이렇게까지 직접적으로 인정해주는 말을 한 적은 한 번도 들어본 적이 없다.

SAT, 그리고 나를 위해 만들어지지 않은 시스템

몇 년 전 나는 SAT를 봤고 떨어졌다. 자랑스럽지는 않지만, 다시 보지도 않았다. 그 모든 게 근본적으로 뭔가 잘못됐다는 느낌이었고, 사람들이 아무리 그냥 더 열심히 공부해서 다시 보라고 해도 그 느낌을 떨칠 수가 없었다.

돌이켜보면, 내가 맞았다고 생각한다.

SAT는 미국 교육 시스템을 위해 설계됐다. 당연한 말처럼 들리지만 그 함의는 깊다. 미국 고등학교는 특정한 패턴, 문제 유형, 문제를 구성하는 방식에 맞춰 가르친다. 학생들은 초등학교 때부터 그런 식의 표준화 시험에 푹 절어서 자란다. SAT를 칠 무렵이면 그 리듬이 이미 몸에 배어 있다.

국제 학생에게는 그런 이점이 없다. 우리는 교육 철학이 다른 시스템에서 왔다. 유럽 학교는 폭보다 깊이를, 객관식보다 논술형 시험을, 답안지보다 구술 시험을 강조하는 경우가 많다. 아시아 시스템에는 자체 표준화 시험이 있지만, 다른 것을 다른 방식으로 측정한다. 남미, 아프리카, 중동의 교육 전통도 각자의 논리를 지니고 있다.

국제 학생을 SAT 앞에 떨어뜨려 놓으면, 단지 그 사람의 지식을 시험하는 게 아니다. 낯선 시험 문화에 얼마나 빨리 적응하면서 동시에 내용을 얼마나 잘 익혔는지를 보여줄 수 있는지를 시험하는 것이다. 학업 능력만큼이나 문화적 적응 능력을 시험하는 셈이다.

나는 여름 한 철 동안 이걸 준비해서 만점에 가깝게 받아낼 거라 기대받았다. 시험 문화 한 세트를 통째로 배우고, 내 교육적 본능을 버리고, 미국 입학 사정관을 감동시킬 수준으로 해내라는 거였다. 그것도 몇 달 만에.

나는 그렇게 하지 않기로 했다.

어릴 때는 다른 방식으로 똑똑하다. 직관적인 방식으로. 그때 나는 나 자신을 위한 길을 내고 있었다. 정확히 왜 그러는지 말로 설명하지는 못했지만 말이다. 내 안의 무언가가 알고 있었다. 이 시스템은 내 것이 아니라는 걸.

대신 창작의 실을 따라가다

나는 게임 개발과 디자인을 공부했다. 창의력과 시각 효과로 사람들이 직접 플레이하고 상호작용할 수 있는 가상 세계를 만든다는 발상이 좋았기 때문이다. 예술과 기술이 만나는 지점, 이야기와 상호작용이 만나는 지점이 좋았다.

내가 발견한 것은 충격적이었다.

게임에는 진지한 기술적 깊이가 필요하다. 물리 시뮬레이션, 충돌 감지, 벡터 수학, 조명 계산, 최적화. 이건 들어가기 전부터 알고 있었다. 수학과 공학은 게임 개발의 장애물이 아니다. 게임이 작동하게 만드는 일부다.

문제는 창작의 비전과 구현 사이의 간극이었다. 업계를 지배하는 엔진과 도구들은 엔지니어가 엔지니어를 위해 설계한 것이었다. 모든 게 "if"와 "then", 그리고 노드 기반 블루프린트로 돌아갔다. 소용돌이 효과를 원한다고? 셰이더 프로그래밍을 배워라. 특정한 조명 분위기를 원한다고? 머티리얼 그래프를 파고들어라. 캐릭터 움직임이 자연스럽게 느껴지길 원한다고? 캐릭터 컨트롤러나 물리 파라미터를 몇 시간씩 디버깅해라.

당신이 시각적인 사람이라면, 생생한 색과 움직이는 이미지로 생각한다면, 아이디어가 소리와 질감과 감정의 무게까지 갖춘 완성된 장면으로 떠오른다면, 그 모든 걸 일단 기술 언어로 번역해야만 무언가를 만들기 시작할 수 있었다. 머릿속에 조명과 분위기, 캐릭터가 공간을 가로질러 움직이는 방식까지 완성된 세계가 보인다. 그러고는 컴퓨터 앞에 앉아 다음 여섯 시간 동안 왜 캐릭터가 바닥을 뚫고 떨어지는지를 디버깅하며 보낸다.

기술적 토대는 중요하다. 하지만 도구들은 창작자가 그 복잡성을 추상화해 치워버리는 대신 구현 세부사항 속에서 살게 만들었다. 게임 제작은 이야기를 들려주거나, 사람들이 참여할 수 있는 영화를 연출하는 것처럼 느껴져야 한다. 그게 이 매체의 마법이다. 그런데 그건 시작하기도 전에 공학 시험을 치르는 것처럼 느껴졌다.

영화감독은 자기 비전을 표현하기 위해 물리 엔진을 몇 년씩 배우지 않는다. 예산과, 기술적 실행을 맡아줄 팀을 받는다. 하지만 인디 게임 개발에서는 예산이 있는 경우가 드물다. 당신이 가진 건 시간과 도구에 대한 접근권뿐이다. 그리고 당신이 기술적인 사람이라면, 끝내주는 게임을 만들 수 있다. 단, 그럴 때만.

이렇게 해서 Limbo 같은 작품이 나왔다. 작은 팀이 하나의 독특한 예술적 비전과 그것을 실행할 기술적 역량을 갖추고 만든 게임이다. 또는 Undertale, 창의적 직관과 프로그래밍 능력의 적절한 조합을 마침 갖춘 한 사람이 거의 혼자 만든 게임이다. 또는 Stardew Valley, Eric Barone이 픽셀 아트부터 작곡, C# 프로그래밍까지 모든 걸 몇 년에 걸쳐 독학한 게임이다.

이 게임들은 엄청난 역경을 뚫고 성공했다. 하지만 Limbo 하나당, 도구가 창작자가 갖출 수 없는 기술적 능숙함을 요구하는 바람에 사라진 창작의 비전이 수백만 개는 있다. 인디 게임 개발자 중 의미 있는 성공을 거두는 사람은 3%도 안 된다. "if"와 "then"의 벽에 부딪혀 포기한 창작자들 때문에 끝내 만들어지지 못한 멋진 게임은 또 얼마나 많을까?

진입 장벽은 창의력이 아니었다. 도구 자체에 내장된 기술적 문지기였다.

원래 있었어야 할 것을 만들다

그래서 5년 전 나는 다른 무언가를 만들기 시작했다.

제안은 단순했다. 게임 개발은 창의적 비전을 가진 누구에게나 열려 있어야 한다. 상호작용 매체로 자신을 표현하기 위해 컴퓨터 공학 학위가 필요해서는 안 된다. 도구가 창의적인 사람들이 실제로 생각하는 방식에 맞춰야지, 그 반대가 되어서는 안 된다.

Sequoia, Pear, Draper를 비롯한 수십 곳의 VC들이 안 될 거라고 했다. B2C라서. 시장이 없어서. 인디 개발자들은 아무것도 결제하지 않아서. 능력을 희생하지 않고는 게임 개발을 단순화할 수 없어서. 게이머는 복잡한 게임을 원하고, 복잡한 게임에는 복잡한 도구가 필요해서. 시장 분석으로 포장된 수백만 가지 변명이었다.

사람들은 내가 미쳤다고 했다. 어쩌면 그랬는지도 모른다. 하지만 나는 계속 같은 질문으로 돌아왔다. 왜 수백만 달러짜리 예산이 창의적 표현의 전제 조건이어야 하는가? 영화감독과 유명 게임 프로듀서에게는 팀과 자원이 있다. 나머지 모두에게는 코드 에디터 하나와 기도 한 마디뿐이다. 나는 그 간극을 메우는 것을 만들고 싶었다. 원하는 걸 설명하면, 그게 눈앞에서 일어난다. 내 안의 모든 부분이 이게 옳다는 걸 알았다. 온몸의 모든 세포로 그걸 느낄 수 있었다.

오늘날 수천 명이 매일 Cinevva로 3D 게임 에셋, 게임, 음악, 레벨, 경험을 만든다. 지금까지 만들어진 프로젝트의 조회수는 수백만에 이른다. 매일같이 늘어난다. Sand Hill Road를 향한 2분짜리 피치는 "나는 SAT에 떨어졌지만 내 직관을 믿어달라"에 딱 맞는 형식은 아니다.

직관이 진짜 의미하는 것

황이 한 말은 단지 철학적인 이야기가 아니었다. 그는 무엇이 가치 있는 지능을 이루는가에 대한 진짜 변화를 묘사하고 있었다.

수십 년 동안 우리는 잘못된 것을 위해 최적화했다. 암기와 계산에 보상을 주는 교육 시스템을 만들었다. 이전에 본 문제와의 패턴 일치를 측정하는 표준화 시험을 설계했다. 4년간의 학문적 문지기를 견뎌냈음을 증명하는 자격증을 보고 사람을 채용했다. AI는 그 모든 걸 그저 덜 특별하게 만들어버렸다.

AI가 할 수 없는 것은, 적어도 아직은, 무엇이 빠졌는지를 감지하는 것이다. 뭔가 어긋났을 때 그걸 느끼는 것. 사람들이 스스로 말로 표현하기도 전에 그들이 무엇을 필요로 하는지 직관하는 것. 분위기를 읽는 것. 어떤 데이터셋에도 담기지 않은 맥락을 이해하는 것.

나는 내 시간, 국제적인 삶의 경험, 돈, 그리고 직관적인 지식을 Cinevva를 만드는 데 쏟아부었다. 이건 대학에서 얻기 어려운 조합이다. SAT로 시험하기 어렵다. AI가 순수한 인지적 처리 능력을 흔하게 만들기 전에 설계된 어떤 자격증 체계로도 담아내기 어렵다.

16년 혹은 20년 전, 컴퓨터 과학자들이 도구가 어떤 모습이어야 하고 어떻게 작동해야 하는지를 결정했다. 그들은 자신들을 위해, 자신들처럼 생각하는 사람들을 위해 만들었다. 나머지 우리는 거기에 적응할 것으로 기대됐다. 그 시대는 끝나가고 있다. 다음에 올 것을 만들어갈 사람들은 인간이 진짜로 무엇을 원하는지 이해하는 사람들이다. 무언가 잘못됐을 때와 옳을 때를 느낄 수 있는 사람들. 기술적 우아함이 아니라 사람을 위해 만드는 사람들.

나는 시스템이 가치 없다고 말한 내 안의 무언가를 믿었다. 그리고 내가 옳았다.

관련 글:

• 채용 시장이 바뀌고 있다 — 자격증에서 역량으로
• 온라인 게임 개발 강좌 — 전통적인 문지기를 우회하는 역량 우선 경로
• 이제 모두가 AI 게임 엔진이 되고 싶어 한다 — 사람들이 생각하는 방식에 맞추는 도구로 향하는 업계의 변화

글 Oleg Sidorkin, Cinevva CTO

게임 속 AI는 2024년 중반 어디쯤에서 진짜 지뢰밭이 됐다. 일자리가 사라진다. 다음은 내 차례라고 확신하는 사람들. 변호사들조차 풀어내지 못하는 저작권 문제. 끝없이 제자리를 맴도는 미학 논쟁. 아무도 원하지 않은 것들로 넘쳐나는 Steam. 그리고 그 모든 것 아래, 이제 모든 창작자가 품게 된 이 거슬리는 걱정. "내가 지금 뭔가를 만들고 있는 건가, 아니면 그냥... 프롬프트를 치고 있는 건가?"

우리는 플랫폼을 운영한다. 그 일을 하다 보면 한 가지를 빠르게 배운다.

누구도 속았다는 기분을 좋아하지 않는다.

이 수치들은 우리도 놀랐다

AI 도입이 늘어날 거라고는 예상했다. 하지만 이 정도는 아니었다. 2025년 말 기준으로 상황이 이렇게 정리됐다.

출처: Tom's Hardware / Totally Human Media 분석, GDC 2025 개발자 설문, Unity 2025 게이밍 리포트

플레이어들이 이렇게까지 회의적이 된 이유

이건 갑자기 생긴 게 아니다. 실제로 일이 잘못됐다. 그리고 사람들은 기억한다.

성우들은 자신이 복제됐다는 걸 알았다 — 출시 당일에

Tomb Raider 4-6 Remastered는 원본 음성 연기의 AI 생성 버전을 담아 출시됐다. 성우들은 다른 모두와 똑같은 순간에 그 사실을 알았다. 출시 당일이었다. 법적 압박이 쌓이자 퍼블리셔는 결국 패치로 그 음성을 제거했다. 11개월간 이어진 SAG-AFTRA 파업? 바로 이 시나리오가 그걸 끌고 갔다.

"AI slop"은 이제 사람들이 쓰는 말이 됐다

Call of Duty: Black Ops 6는 Steam 페이지에 슬그머니 AI 공개 문구를 추가했다. 이미 출시된 다음에. 플레이어들은 그 이상함을 알아챘다. 여기저기 흩어진 시각적 결함들. 한 로딩 화면 캐릭터는 손가락이 여섯 개였다. "AI slop"은 뭔가... 어딘가 어긋난 것을 가리키는 줄임말이 됐다. 텅 빈 느낌. 아무도 제대로 확인할 만큼 신경 쓰지 않은 것 같은.

어워드 후보 지명이 사라졌다

Clair Obscur: Expedition 33는 Indie Game Awards에서 올해의 게임 후보 지명이 철회됐다. 그런데 출시된 게임은 AI를 쓰지 않았다. 문제는 개발 중에 쓴 AI 플레이스홀더였다. 플레이어에게는 한 번도 전달되지 않은 내부 자료였다. 최종 에셋은 전부 사람이 만든 것이었다. 그래도 소용없었다. 선이 정확히 어디여야 하는지를 두고 몇 주간 논쟁이 이어졌다.

AI를 전혀 손대지 않은 팀들이 그걸 증명해야 했다

Chessplus와 Peak 둘 다 AI 의혹에 휩싸였다. 둘 다 쓰지 않았다. 둘 다 어워드 후보였다. 두 개발팀은 결국 자기들 작업이 수작업이라는 걸 보여주려고 옛날 스크린샷과 레이어 파일을 뒤져야 했다. Peak 팀이 가장 잘 표현했다. "우리는 slop일지 몰라도, 사람이 만든 지역 생산 수제 slop이다."

스튜디오들은 완전히 반대 방향으로 갔다

SNK — Fatal Fury: City of the Wolves 트레일러에 AI 같은 비주얼이 등장하자 Discord 모더레이터들이 떠났다. Games Workshop — 모든 Warhammer 자산에서 AI를 전면 금지했다. Larian Studios — Baldur's Gate 3에서 AI는 아주 초기 콘셉트 스케치에만 썼고 최종 게임에는 전혀 없다고 밝혔다. Tim Sweeney — Steam의 AI 라벨이 쓸모없다며 없애버리라고 선언했다. Valve — AI 라벨에 불평하는 개발자들은 대개 자기 작업이 "성의 없어" 보일까 걱정하는 거라고 받아쳤다.

게임을 찾는 일이 신뢰 문제가 됐다

이제는 누구든 제대로 평가할 수 있는 속도보다 더 빠르게 물건이 만들어진다. 질문이 바뀌었다.

내가 지금 보고 있는 게 도대체 뭐지? 누가 만들었지? 여기에 시간을 쓰면 후회하게 될까? 이게 트레일러가 약속한 거랑 맞기는 한 건가?

거창한 해결책 같은 건 아마 오지 않을 거다. AI 대 수작업에 대한 결정적 판결도 없을 거다.

더 가능성 높은 것은 이것이다. 필터, 진짜 투명성, 그리고 정직함 쪽으로 밀어붙이는 인센티브 구조.

이 한가운데 끼인 작은 스튜디오들

인디 개발자들은 묘한 자리에 놓였다.

좋은 점은 솔직히 무시하기 어렵다. 반복 작업이 더 빨라진다. 네 명이 모든 걸 만들 때 비용이 떨어진다. 1인 개발자가 이제 실제로 작업을 끝낼 수 있다. 현지화가 예산 전체를 잡아먹는 일이 사라진다.

나쁜 점도 그만큼 진짜다. 밋밋하게 느껴지는 결과물. 변호사들이 아직 손대지 않으려는 학습 데이터와 IP 문제. 완전히 이해하지 못하는 시스템을 출시하는 것. 어떤 사람들은 이걸 이해 부채라고 부른다. 성의 없는 출시물의 홍수에 한데 묶이는 것. 설문에 응한 개발자의 거의 절반이 AI가 전반적으로 게임을 더 나쁘게 만든다고 본다.

Unity의 2025년 리포트는 개발자의 79%가 AI 도구에 긍정적이라고 말한다. 꽤 확정적으로 들린다. 현실은 더 지저분하다. 이걸 잘 해내는 팀들은 AI를 지루한 부분에 쓰는 경향이 있다. 막노동, 거친 초안, QA의 따분함. 창작 방향은? 그건 사람의 몫으로 남는다.

Cinevva의 입장: AI에 중립, 정직함에는 엄격

우리는 AI를 썼다는 이유로 게임을 돌려보내지 않는다. 그렇다고 특별 대우를 해주지도 않는다.

규칙은 단순하다. AI가 관여했다면, 그렇다고 밝혀라. 무엇에 신경 쓸지는 플레이어가 정한다. 그러면 필터가 실제로 작동한다.

• AI 생성 콘텐츠 정책

필터는 논쟁보다 더 잘 작동한다

게임 속 AI 논쟁은 당분간 합의에 도달하지 못한다. 아마 영영 못 할 거다. 하지만 개인의 취향은? 그건 충분히 분명하다.

어떤 플레이어는 사람이 방향을 잡은 아트를 콕 집어 원한다. 사람에게서 나온 글. 눈에 보이는 장인정신.

다른 사람들은 정말로 신경 쓰지 않는다. 재밌으면 재밌는 거다.

필터는 두 집단 모두가 찾는 걸 찾게 해준다. 누구도 이길 필요가 없다.

결제 모델은 누구의 의견보다 더 중요하다

매출이 판매 수량이 아니라 플레이 시간에 묶이면, 이런 식으로 돈을 번다.

플레이어를 빠르게 빠져들게 한다. 그들의 관심을 붙잡는다. 마케팅에서 말한 그대로를 전달한다.

품질이 당연한 길이 된다. 어떻게 만들었는지는 덜 중요해진다.

트레일러에서 과하게 약속했다고? 플레이어는 즉시 떠난다. 리텐션이 곤두박질친다. 그들이 받게 될 걸 정확히 보여줬다고? 그들은 머문다. 플레이 시간이 쌓인다. 매출이 따라온다. 경제는 알아서 정리된다.

2026년이 가져올 가능성이 큰 것들

더 많은 규칙 — EU AI Act는 계속 확장된다. 미국의 음성과 초상권 보호는 SAG-AFTRA 이후 특히 커지고 있다.

전문화된 도구 — 작은 팀을 위해 특별히 만들어진 AI. 사람이 키를 잡도록 설계된 것.

더 똑똑한 라벨 — "Made with AI"는 너무 거칠다. AI 보조 워크플로와 AI 생성 최종 에셋을 구분하는 흐름을 예상하라.

갈라지는 관객 — 어떤 플레이어는 일부러 전통적으로 만든 게임을 찾아 나선다. 다른 사람들은 신경조차 쓰지 않는다. 두 집단 모두 게임을 만들 만큼 충분히 크다.

플랫폼 경쟁 — 스토어가 투명성과 발견을 어떻게 다루는지가 진짜 차별점이 된다.

실제로 상황을 앞으로 나아가게 하는 것

논쟁으로는 AI 문제가 정리되지 않는다. 정리하는 건 이것이다.

1. 플레이어가 자신에게 진짜 중요한 것을 기준으로 고르는 것
2. 창작자가 자신이 어떻게 작업하는지 정직하게 밝히는 것
3. 플랫폼이 두 집단이 서로를 찾도록 돕는 도구를 만드는 것

그게 포스트 AI 경제다. 서로 싸우는 진영이 아니라. 신뢰가 그 전체를 붙들어 준다.

관련 글:

• AI 생성 콘텐츠 정책
• 게임 창작자를 위해
• FAQ
• 프런티어 오픈소스 생성 AI 모델 — 구체적인 모델들과 그 작동 방식
• 오픈소스에는 AI 오염 문제가 있다 — AI 결과물이 오픈소스 프로젝트에 넘쳐날 때 벌어지는 일

글쓴이 Oleg Sidorkin, Cinevva CTO

저는 2023년에 사촌이 우등으로 졸업하는 걸 지켜봤습니다. 괜찮은 주립대학교의 컴퓨터공학 학위, 탄탄한 학점. 그는 일자리를 구하기까지 열네 달 동안 지원서를 넣었습니다. 반면 2학년 때 자퇴하고 인디 게임을 만들던 친구는 일자리를 찾기로 마음먹은 지 한 달 만에 세 군데에서 제안을 받았습니다.

이건 더 이상 예외가 아닙니다. 이게 패턴입니다.

우리가 느껴온 것을 마침내 숫자가 따라잡았다

2025년까지 **HR 책임자의 90%**가 전통적인 4년제 학위 밖에서 채용했다고 답했습니다 (Fortune). 미국 기업의 4분의 1은 학사 학위 요건을 완전히 없앴습니다 (HR Dive). 그리고 막 학자금 대출을 다 갚은 사람이라면 따끔하게 느껴질 대목이 있습니다. 고용주의 94%는 역량 기반으로 채용한 사람이 학력으로 채용한 사람보다 더 좋은 성과를 낸다고 말합니다 (Forbes).

Verizon은 이제 자사 직무의 99%가 학위를 요구하지 않는다고 말합니다. Sergey Brin은 Google이 학사 학위 없는 사람들을 "엄청나게" 많이 채용한다고 인정했습니다. IBM은 "New Collar" 프로그램을 통해 미국 채용 공고의 절반을 학위 선택 사항으로 만들었습니다.

이건 기업이 자선을 베푸는 게 아닙니다. 학위가 누가 실제로 일을 잘할지를 예측하지 못한다는 사실을 깨달은 겁니다.

옛 시스템이 무너진 이유

솔직한 답은 이렇습니다. 학위는 게으른 필터가 되어버렸습니다.

지원서가 400장 들어왔을 때 학사 학위를 요구하면 그 더미가 절반으로 줄어듭니다. 하지만 누가 실제로 일을 해낼 수 있는지는 알려주지 않습니다. 4년 동안 교실에 앉아 있을 돈과 시간, 그리고 가정의 안정을 가졌던 사람이 누구인지를 알려줄 뿐입니다. 학위와 능력의 상관관계는 우리가 인정한 척했던 것보다 항상 약했습니다.

그리고 이제 세 가지 일이 동시에 일어났습니다.

역량이 너무 빠르게 움직였다. 게임 엔진, AI 도구, 웹 프레임워크. 커리큘럼 위원회가 어떤 주제에 관한 강의를 승인할 즈음이면 그건 이미 구식이 됩니다. 4년제 학위는 4년 전의 이론을 가르칩니다. 기술 분야에서 그건 까마득한 옛날이야기입니다.

포트폴리오는 부정할 수 없게 됐다. GitHub를 볼 수 있는데 굳이 누군가 코딩을 할 수 있는지 추측할 이유가 있을까요? itch.io 페이지에 플레이어 리뷰가 달린 완성된 프로젝트가 다섯 개나 있는데, 그 사람이 게임을 출시할 수 있을지 궁금해할 이유가 있을까요?

기업이 절박해졌다. 인재 부족은 실제 상황입니다. 학위 없는 사람을 모두 배제하면 정확히 당신이 필요로 하는 사람을 배제하게 됩니다. 일부 채용 담당자는 독학한 개발자가 학위를 가진 채용자들을 완전히 압도하는 걸 본 뒤에 이 사실을 어렵게 깨달았습니다.

게임 업계는 이걸 미리 봤다

게임 업계가 이 부분에서는 앞서 있었다고 생각합니다. 그 이유를 이해할 가치가 있습니다.

스튜디오는 당신이 어느 학교를 나왔는지 별로 신경 쓴 적이 없습니다. 무엇을 출시했는지를 신경 썼죠. 잘 다듬은 48시간 잼 게임 하나가 4년제 게임 디자인 학위보다 채용 담당자에게 더 많은 것을 말해줍니다. 압박 속에서 일을 끝낼 수 있다는 걸 증명합니다. 범위에 관한 어려운 결정을 내렸다는 걸 증명합니다. 그 게임이 이론에 그치지 않고 실제로 플레이할 수 있다는 걸 증명합니다.

2026년에 게임 업계에 진입하려 한다면 실제로 중요한 건 이것입니다 (Dice, CombineGR). 잘 다듬은 플레이 가능한 데모 두세 개. 무엇을 왜 했는지 설명하는 사례 연구. 당신이 일을 끝낸다는 증거. 실제 프로젝트로 보여주는, 적어도 하나의 주요 엔진에 대한 능숙함.

채용 담당자는 잠재력을 찾는 게 아닙니다. 증거를 찾습니다.

아무도 말하지 않는 불편한 부분

연구를 파고들면서 저를 답답하게 만든 게 있습니다.

Harvard/Burning Glass 연구에 따르면 학위 요건을 없앤 기업들이 실제로는 학위 없는 지원자를 더 많이 채용하지는 않은 경우가 많았습니다. 증가폭은 약 3.5%포인트에 그쳤습니다 (Forbes). 정책은 바뀌었지만 채용 관행은 뒤처졌습니다.

비전통적인 경로로 간다면 여전히 더 열심히 해야 한다는 뜻입니다. 문은 예전보다 더 열려 있지만 아직 동등한 조건으로 들어가는 건 아닙니다. 당신의 포트폴리오는 부정할 수 없어야 합니다. 당신의 프로젝트가 다른 사람의 학력보다 더 크게 말해야 합니다.

공정하지 않습니다. 하지만 이걸 아는 것이 준비하는 데 도움이 됩니다.

지금 막 시작하는 사람에게 해주고 싶은 말

학교에 다니고 있다면 그만두지 마세요. 다만 학위만으로는 더 이상 충분하지 않다는 걸 이해하세요. 틈틈이 무언가를 만드세요. 게임 잼에 참가하세요. Google Career Certificate나 Unity 인증을 받으세요. 학위를 여러 자격 중 하나로 여기되, 유일한 자격으로 여기지 마세요.

학위를 추구하지 않는다면 다른 길이지만 반드시 더 어려운 길은 아닙니다. 적극적으로 만드세요. 출시하세요. 모든 걸 기록하세요. 당신의 GitHub, 당신의 itch.io 페이지, 당신의 개인 사이트. 그게 이제 당신의 자격입니다.

어느 쪽이든 자신의 작업을 설명하는 연습을 하세요. 무엇을 만들었는지뿐 아니라 왜 그런 선택을 했는지도요. 다시 한다면 무엇을 다르게 할지. 무엇을 배웠는지. 면접관은 자기 생각을 또렷하게 풀어내는 사람을 기억합니다.

이건 채용보다 더 큰 이야기다

지금 벌어지는 일은 단지 기업이 자리를 채우는 방식의 변화가 아닙니다. 우리가 다 함께 무엇을 가치 있게 여기는지에 대한 변화입니다.

수십 년 동안 학력은 필터 역할을 했습니다. 비싸고 시간이 많이 들지만 읽어내기 쉬웠죠. 누군가 학위를 가졌다면 어떤 것들을 가정할 수 있었습니다. 그건 직접적인 측정이 아니라 신호였지만 그래도 충분히 쓸만했습니다.

이제 그 신호가 무너지고 있습니다. 기술 덕분에 누군가 실제로 무엇을 할 수 있는지 볼 수 있게 됐습니다. 원격 근무는 어디에 앉아 있었느냐보다 결과물이 더 중요하다는 걸 증명했습니다. AI는 이론적 지식을 실무 적용보다 덜 가치 있게 만들고 있습니다.

전환이 어수선하더라도 저는 이것이 진심으로 희망적이라고 느낍니다. 예전 질문은 "어디서 공부했나요?"였습니다. 이제는 "무엇을 만들 수 있나요?"입니다.

그게 더 나은 질문입니다.

출처

• Fortune: HR 책임자의 90%가 전통적 학위 밖에서 채용
• Forbes: 기업의 90%가 역량 기반으로 더 나은 채용 결정
• Forbes: 학위 요건을 없애지만 학위 없는 인력은 거의 채용하지 않는 기업들
• HR Dive: 학위 요건을 없애는 고용주들
• Computerworld: 신규 채용에서 대학 요건을 멀리하는 기술 기업들
• Dice: 2025년 게임 디자이너를 꿈꾸는 이들에게
• CombineGR: 2025년 글로벌 게임 채용 전망

관련 글:

• 게임 잼에서 성공하는 법
• 온라인 게임 개발 강좌 — 모든 예산에 맞는 역량 우선 학습 경로
• 에이전트형 AI 코드 도구 — 어떤 역량이 중요한지를 다시 짜고 있는 도구들
• 직관적인 마음 — 학력보다 직관이 더 중요한 이유