위시리스트, 데모, 타이밍에 대해 데이터가 말해주는 것. 200개 이상의 게임에서 나온 실제 수치.

캘린더를 기준으로 계획을 세우고 있다면, Steam은 2026년에 Next Fest를 세 번 진행합니다. 2월 23일부터 3월 2일까지(이미 끝남), 6월 15일부터 22일까지, 그리고 10월 19일부터 26일까지입니다. 6월과 10월 행사는 시작일 오전 10시 PDT부터 종료일 오전 10시 PDT까지 진행되며, 여름 세일과 겨울 세일 직전에 자리합니다(2월 행사도 태평양 시간 기준으로 진행됐고, 서머타임 적용 전이었습니다). 게임은 평생 단 한 번만 Next Fest에 참가할 수 있으니, 출시 일정에 맞는 회차를 고르세요. 데모는 행사가 시작될 때 누구나 플레이할 수 있도록 공개돼 있어야 하고, 행사가 끝나기 전까지는 게임을 출시할 수 없습니다.

Next Fest에 대해 한 가지 짚고 넘어가자면, 다들 이걸 복권처럼 취급합니다. 데모를 던져 넣고, 손가락을 꼬고, 알고리즘이 미소 지어주기를 바라죠. 그런 식으로 돌아가는 게 아닙니다.

저는 포스트모템을 강박적으로 읽어왔습니다. 2025년 한 해에 나온 것만 수백 개입니다. 패턴이 너무 일관돼서 거의 지루할 정도입니다. Next Fest에서 "이기는" 게임들은 행사 기간에 성공을 발견하는 게 아닙니다. 이미 쌓아둔 모멘텀을 증폭시키는 겁니다.

무슨 말인지 보여드리겠습니다.

아무도 듣고 싶어 하지 않는 공식

이전 위시리스트 × 2 = 얻게 될 위시리스트

이 비율은 포스트모템마다 반복해서 등장합니다.

Eilean Mor는 2025년 10월에 위시리스트 2,117개를 가지고 들어갔습니다. 행사 기간에 2,082개를 얻었죠. 거의 정확히 2배입니다.

[IMAGE: Eilean Mor trailer screenshot or embed - https://www.youtube.com/watch?v=jFv7SjsQEws]

Dice of Kalma는 위시리스트 335개를 가지고 들어가서 659개를 얻었습니다. 2배에 약간 못 미칩니다. 개발자는 이렇게 적었습니다. "위시리스트가 거의 세 배가 됐는데, 정말 멋진 일이지만 아직 할 일이 많습니다."

이게 불편한 진실입니다. Next Fest는 이미 가진 것을 두 배로 만들어 줍니다. 가진 게 없으면, 그 두 배인 아무것도 얻지 못합니다.

위시리스트 2,000개의 절벽

2025년 2월 208개 게임의 데이터는 위시리스트 2,000개 지점에서 뚜렷한 변곡점을 보여줍니다.

그 조사에 참여한 한 개발자는 이렇게 말했습니다. "Steam Next Fest 이전에 위시리스트가 2000개 이상인 게임은 얻는 위시리스트가 얼마나 치솟는지 정말로 눈에 보이기 시작합니다."

이건 정확히 알고리즘 문제는 아닙니다. 검증의 문제입니다. 위시리스트 2,000개는 당신이 마케팅에 대해 뭔가를 파악했다는 뜻입니다. 사람들에게 다가가는 법을 안다는 거죠. 그 능력은 행사 기간에 복리로 불어납니다.

첫 48시간이 전부다

Valve는 1일차와 2일차에 모두에게 기회를 줍니다. 그다음부터는 성과를 바탕으로 알고리즘이 누가 더 많은 노출을 받을지 결정합니다.

브론즈 등급 게임이요? 3일차에 노출 수가 절벽처럼 떨어집니다. 다이아몬드 등급 게임이요? 노출 수가 세 배가 됩니다.

1~2일차: 모든 걸 쏟아부으세요. 스트리밍하고, 글을 올리고, 크리에이터와 협업하세요. 3일차 이후: 알고리즘은 이미 결정을 내렸습니다. 당신은 흐름에 몸을 맡길 뿐입니다.

2025년에 실제로 이긴 게임들

Do No Harm (2025년 2월)

[IMAGE: Do No Harm trailer screenshot or embed - https://www.youtube.com/watch?v=GBlOHAL1LkY]

수치: Next Fest 기간에 위시리스트 45,655개 획득. 52,102개로 시작.

그들이 한 것:

• 1월 29일 GameTrailers에 예고편 공개(Next Fest 몇 주 전)
• 예고편에 맞춰 PR 진행
• 2월 4일 데모 공개
• 유기적 모멘텀을 증폭하기 위한 유료 광고

이게 정석입니다. 그들은 Next Fest가 자신들을 발견해 주기를 기대하지 않았습니다. 이미 얻어둔 관심을 곱하는 데 Next Fest를 활용했죠.

Cairn (2025년 10월)

[IMAGE: Cairn trailer screenshot or embed - https://www.youtube.com/watch?v=x6KWhvvk3bM]

1일차에 인기 출시 예정작 5위에 올랐습니다. 2일차에는 인기 데모와 인기 출시 예정작에 진입했습니다.

그들이 한 것:

• 2024년 12월 데모 출시(자신들의 Next Fest 10개월 전)
• 행사 전 팔로워 32,000명
• Next Fest 이전에 18개 행사에 선정
• The Game Bakers(Furi, Haven) - 실적이 있는 자리 잡은 스튜디오

그들에겐 Next Fest가 필요 없었습니다. 그래도 활용했죠. 이미 할 일을 다 해뒀을 때는 무료 증폭이니까요.

YAPYAP (2025년 10월)

[IMAGE: YAPYAP gameplay screenshot or embed - https://www.youtube.com/watch?v=7d8Fd9XXAtQ]

"friend slop" 현상입니다. 마법사가 되어 탑을 부수고 다니는 협동 호러 게임이죠. 소셜 미디어에서 입소문이 나더니 Next Fest를 장악했습니다.

예고편은 2025년 8월 25일에 공개됐습니다. Next Fest 한 달 전이죠. 조회수 434K를 기록했습니다. 그게 변곡점이었습니다. 그 이후로는 그냥 파도를 타는 일이었죠.

2026년 2월이 확인해 준 것

2026년 2월 회차는 정석을 바꾸지 않았습니다. 오히려 굳혔죠. 행사는 게임 3,500개를 넘겼고, 전년 대비 51% 증가했습니다. 중간 수준의 게임은 위시리스트 약 200개와 신규 팔로워 11명을 챙겨 떠났습니다. 게임은 더 많아졌고, 한 조각은 더 얇아졌습니다. 상위 5%는 약 7,000개의 위시리스트를 얻었는데, 이는 1년 전 약 10,000개에서 줄어든 수치입니다. 그러니 승자들조차 더 붐비는 파이를 나눠 갖고 있는 셈입니다. 협동 게임은 계속 우위를 지켰고, "행사 직전에 데모를 깜짝 출시하라"는 발상은 다시 한번 틀렸음이 드러났습니다. 분석한 상위 수익 게임 열 개 중 데모를 며칠 전에 출시한 건 단 하나뿐이었습니다. 나머지는 한 달 이상 데모를 공개해 둔 상태였죠. 먼저 관객을 만들어라, 모든 회차가 같은 말을 반복하고 있습니다.

계속 이기는 장르들

2025년 2월 다이아몬드 등급에서:

• 호러 (×2) - Steam은 호러를 사랑합니다. 늘 그래왔죠.
• 전략/경영 (×4) - "제작하고 건설하고 시뮬레이션하는" 분위기
• 협동 "friend slop" - Lethal Company가 물꼬를 텄습니다
• 포인트 앤 클릭 (×2) - 하지만 둘 다 기존 관객이 있는 속편이었습니다

포인트 앤 클릭 부분이 흥미롭습니다. Beholder: Conductor는 시리즈의 네 번째 작품이었습니다. Duck Detective는 속편이었고요. 이들에겐 이미 확보된 관객이 있었습니다. 첫 포인트 앤 클릭 개발자들은 그런 결과를 보지 못합니다.

작은 게임들이 하는 말

모두가 다이아몬드 등급을 좇는 건 아닙니다. 2025년 10월에 더 작은 규모의 개발자들이 보고한 내용입니다.

"방문에서 위시리스트로의 전환율 62%. 스토어 페이지 자체는 잘 작동하는 것 같습니다. 하지만 노출은 많았는데 사람들이 클릭하지 않았습니다. 캡슐 아트를 업데이트해야 합니다."

"스토어 방문자의 57%가 우리 데모를 플레이했습니다. 높게 들리나요? 하지만 플레이한 사람 중 15%만 위시리스트에 추가했습니다. 뭔가 기대에 못 미친 거죠."

"우리 게임이 아늑하다고 느꼈는지 물었다가 r/cozygames에서 영구 차단됐습니다. 항상 규칙을 지키려고 하는데 이건 꽤 놀라웠습니다."

이 고된 작업은 진짜입니다. 이 개발자들은 캡슐 아트를 테스트하고, 태그를 손보고, 서브레딧에서 차단당하고 있습니다. 화려하지 않습니다.

더 강해진 패턴이 하나 있습니다. 협동 "friend slop" 게임은 엄청난 데모 플레이 수를 쌓지만, 그중 위시리스트로 전환되는 플레이어 비율은 더 낮습니다. 찾아오는 관객이 캐주얼하고 친구들과 어울리려고 온 사람들이지, 출시를 추적하려는 사람들이 아니기 때문입니다. 플레이 수가 많다고 해서 자동으로 위시리스트가 많아지는 건 아닙니다.

솔직한 정석

Next Fest 몇 달 전:

1. 데모를 일찍 출시하세요. 정말로, 한참 일찍요. 승자들은 6~12개월 동안 데모를 공개해 뒀습니다.
2. 작은 장르 행사에 먼저 참가하세요. 다듬는 연습으로 쓰세요.
3. 위시리스트 2,000개 이상을 쌓으세요. 그게 진짜 임계점입니다.

Next Fest 기간:

1. 1~2일차가 성패를 가릅니다. 모든 걸 쏟아부으세요.
2. 가능하면 스트리밍하세요. 페이지에 "라이브"로 표시됩니다.
3. 스트리머와 협업하세요. 필요하면 비용을 지불하세요.
4. 데모를 별도의 Steam 페이지에 올려 리뷰를 모을 수 있게 하세요.

Next Fest 이후:

1. 곧바로 출시하지 마세요. 몇 주 뒤가 실제로 성과가 더 좋습니다.
2. 그 모멘텀을 실제 출시 마케팅에 활용하세요.

건너뛰어야 할 때

솔직히 말해서, Next Fest가 모두를 위한 건 아닙니다.

다음 경우라면 건너뛰세요:

• 위시리스트가 1,000개 미만이다(3일차면 보이지 않게 됩니다)
• 데모가 다듬어지지 않았다(첫인상은 단 한 번뿐입니다)
• 생애 첫 행사다(작은 행사를 먼저 하세요)
• 직후에 출시할 예정이다(몇 주 기다리세요)

매달 수십 개의 작은 행사가 있습니다. 더 집중된 관객. 더 적은 경쟁. 목록은 howtomarketagame.com/festivals에서 확인하세요.

Next Fest가 기본값인 건 Valve가 모두에게 참가하라고 안내하기 때문입니다. 하지만 최고의 마케팅은 모두가 하라고 안내받는 그런 것이 아닙니다.

저자 소개

Oleg Sidorkin은 인디 게임 개발자를 위한 도구를 만듭니다. 그는 무엇이 과대 포장됐는지가 아니라 무엇이 실제로 통하는지 이해하기 위해 게임 마케팅 데이터와 개발자 포스트모템을 연구해 왔습니다.

Notes for Game Developer editors:

IMAGE PLACEMENTS:

1. After "Almost exactly 2×" paragraph - Eilean Mor video embed or screenshot
2. After "Do No Harm (February 2025)" header - Do No Harm video embed or screenshot
3. After "Cairn (October 2025)" header - Cairn video embed or screenshot
4. After "YAPYAP (October 2025)" header - YAPYAP video embed or screenshot

VIDEO URLS:

• Eilean Mor: https://www.youtube.com/watch?v=jFv7SjsQEws
• Do No Harm: https://www.youtube.com/watch?v=GBlOHAL1LkY
• Cairn: https://www.youtube.com/watch?v=x6KWhvvk3bM
• YAPYAP: https://www.youtube.com/watch?v=7d8Fd9XXAtQ

STEAM LINKS (for reference/linking):

• Eilean Mor: https://store.steampowered.com/app/3871570/Eilean_Mor_The_Lost_Keepers/
• Do No Harm: https://store.steampowered.com/app/3138780/Do_No_Harm/
• Cairn: https://store.steampowered.com/app/1588550/Cairn/
• YAPYAP: https://store.steampowered.com/app/3834090/YAPYAP/

마지막 업데이트: 2026년 7월.

사운드트랙은 한때 1인 개발자가 그냥 건너뛰던 부분이었습니다. 게임을 무음으로 내보내거나, 이미 다른 게임 오십 개가 쓴 무료 루프를 가져다 썼죠. 작곡가를 고용하는 비용이 프로젝트의 나머지 전부를 합친 것보다 컸으니까요. AI 음악이 그 계산을 바꿔놨습니다. 한 문장으로 분위기를 설명하면 1분도 안 돼 완성된 트랙이 돌아옵니다.

2026년의 어려운 지점은 음질이 아닙니다. 이 도구들 대부분은 그대로 출시해도 될 만큼 좋게 들립니다. 문제는 라이선스입니다. 게임은 상업 제품이고, 인기 있는 음악 생성기의 절반은 무료 등급에서 상업적 사용을 막거나, 학습 데이터를 둘러싼 정리되지 않은 소송을 안고 있습니다. 잘못 고르면 법적 문제를 게임 파일 안에 담아 출시하는 셈이 됩니다.

우리도 여기에 발을 담그고 있습니다. Cinevva는 자체 음악 도구를 운영하고 있고, 그 뒤에 놓을 엔진을 고를 때 세 개보다 훨씬 많은 후보를 시험했습니다. 최종적으로 ElevenLabs Music, ACE-Step, Mubert로 정했는데, 결정적 요인은 블라인드 청취 테스트에서 무엇이 이겼느냐가 아니었습니다. 창작자가 정말 중요한 단 하나의 질문을 던졌을 때 우리가 어떤 라이선스를 떳떳하게 뒷받침할 수 있느냐였죠. "이 트랙을 넣은 게임을 팔아도 되나요?" 이 질문이 아래 내용 전체를 관통합니다.

프롬프트에서 트랙까지가 대략 이런 소리입니다. 도구 안에서 쓰는 것과 같은 흐름입니다.

짧은 AI 생성 클립. 분위기를 설명하면 거기에 맞는 트랙이 나옵니다.

이 가이드는 게임에 실제로 쓸 만한 AI 음악 생성기를, 어떻게 쓰게 될지에 따라 분류해 비교합니다. 보컬이 있는 풀 송 도구, 제품용으로 만들어진 로열티 프리 생성기, 그리고 직접 돌릴 수 있는 오픈 모델입니다. 각각에서 가장 중요한 것을 맨 앞에 둡니다. 그 출력물을 당신이 파는 게임에 합법적으로 넣을 수 있나요?

빠른 선택

짧은 버전을 원한다면, 각 도구가 누구에게 맞는지 정리했습니다.

보컬이 있는 풀 송 생성기

텍스트 프롬프트에서, 종종 노래까지 포함한 완성 트랙을 써내는 도구들입니다. 대부분의 사람이 "AI 음악"이라고 할 때 떠올리는 것이 이들이고, 테마곡, 메뉴 트랙, 예고편용 보컬 곡이 필요할 때 알맞은 선택입니다.

ElevenLabs Music

상업용 게임을 출시하면서 라이선스 걱정을 그만하고 싶다면 여기서 시작하세요. ElevenLabs는 2025년 8월 Eleven Music을 출시했고, 경쟁작들과 달리 라이선스된 프로덕션 음악으로 모델을 학습시키고 Merlin, Kobalt와 계약을 맺어 권리자가 대가를 받도록 했습니다. 출력물은 폭넓은 상업적 사용이 허가되어 있고, 약관에 게임이 이름으로 명시되어 있습니다.

대가는 지켜야 할 몇 가지 가드레일입니다. 실제 아티스트 이름, 곡 제목, 가사로 프롬프트를 넣을 수 없고 일부 분야는 제외되므로, 이를 중심으로 개발하기 전에 음악 약관을 읽으세요. 게임 사운드트랙에는 이런 제한이 걸리는 일이 드뭅니다. 그 대신 얻는 것은 2026년 다른 어떤 보컬 생성기도 줄 수 없는 단 하나, 누가 물어도 가리킬 수 있는 깨끗한 라이선스 사슬입니다. 이는 우리 자체 음악 도구 뒤에 있는 세 엔진 중 하나이며, 그 이유가 바로 라이선스가 정리되어 있기 때문입니다.

Suno

Suno는 완성된 보컬 곡에 이르는 가장 빠른 길이고, v5.5 모델(2026년 3월)에 오면서 보컬이 어떤 생성기보다 자연스럽습니다. 게임에 대해서는 규칙이 단순하고 엄격합니다. 무료 등급은 비상업용, 그것으로 끝입니다. 월 10달러(연간 결제 시 월 8달러)의 Pro 플랜이 필요한데, 상업적 권리와 다운로드 가능한 파일, 대략 500곡 분량의 크레딧, 그리고 v5.5 모델 접근권을 줍니다. 월 30달러의 Premier 플랜은 Suno Studio를 더하는데, 트랙을 스템으로 분리해 여러 게임 상황에 맞게 다시 믹스할 수 있게 해주므로 게임에 중요합니다.

두 가지를 분명히 해두세요. 첫째, 상업용 라이선스는 저작권 소유가 아닙니다. Suno의 약관 자체가 상업적 사용 권리 부여는 소유권 이전과 다르다고 말하고, 미국 법은 대체로 완전한 저작권을 위해 인간 저작자를 요구합니다. 따라서 당신이 쥔 것은 트랙을 사용할 라이선스이지 철벽 같은 저작권이 아닙니다. 둘째, Suno는 2025년 11월 워너와 합의했지만, 소니와 유니버설 소송은 2026년 7월 약식 판결 심리를 앞두고도 여전히 진행 중이었습니다. Suno는 또한 2026년 후반에 현재 모델을 레이블과 라이선스한 새 모델로 교체할 계획이라고 밝혔으므로, 정확히 어떤 모델인지와 다운로드 규칙이 발밑에서 바뀔 수 있습니다. 아직 하급 사용자에게 책임을 물은 법원은 없고 인디에게 실질적 위험은 낮지만, 이를 토대로 시리즈를 세우기 전에 알아둘 만한 꼬리 위험입니다. 각 트랙을 생성할 때 구독 중이었다는 증거로 결제 영수증을 보관하세요.

Udio

Udio는 아름다운 오디오를 만들지만, 2026년에는 게임에 넣을 수 없습니다. 2025년 10월 유니버설 뮤직과 합의한 뒤 모든 다운로드와 스템을 비활성화하고 스트리밍 전용 담장 안 정원이 되었습니다. 앱 안에서 만들고 듣고 리믹스할 수는 있지만 파일을 내보낼 수는 없습니다. 게임 개발에는 이것이 실격 요건인데, 요점 자체가 오디오 파일을 엔진에 넣는 것이기 때문입니다. 유니버설이 2026년용 라이선스 Udio 플랫폼을 공동 개발 중이라 이는 바뀔 수 있지만, 지금 시점에서는 Udio를 사운드트랙을 구하는 곳이 아니라 노는 곳으로 대하세요.

제품용으로 만들어진 로열티 프리 생성기

이 그룹은 음악가보다는 창작자와 기업을 겨냥합니다. 트랙은 보통 연주곡이고, 인터페이스는 더 단순하며, 세일즈 포인트는 라이선스 안전성입니다. 몇몇은 API를 제공하는데, 플레이어가 게임 안에서 스스로 음악을 만들게 하려면 이 길입니다.

Mubert

Mubert는 제품용으로 만들어졌고 게임이 핵심 용도 중 하나입니다. 프롬프트, 분위기, BPM, 활동으로 로열티 프리이자 DMCA 문제가 없는 음악을 생성하며, 라이선스 및 파트너 콘텐츠로 학습되었습니다. 중요한 세부는 플랜 구조인데, 이것이 당신이 합법적으로 할 수 있는 일을 정하기 때문입니다. Startup 플랜에서는 음악이 앱 안에서 재생되지만 사용자가 내보낼 수는 없어, 배경 음악이 있는 모바일 게임에 맞습니다. 플레이어가 만든 트랙을 내보내거나 공유하게 하려면 Startup+ 이상이 필요하며, 여기에는 서브라이선스가 추가됩니다. 무료 등급은 비상업용입니다. Mubert 역시 우리 음악 도구 뒤에 있는 엔진 중 하나이며, 그래서 앱 내 생성이 나중에 덧붙인 기능이 아니라 일급 경로입니다.

Soundraw

Soundraw는 저작권 문제를 비껴가기 위해 전적으로 자체 라이선스 카탈로그로 학습한 로열티 프리 생성기의 베테랑입니다. 장르, 분위기, 테마를 고른 다음 편곡을 미세 조정합니다. 개인 사용 구독으로 월 약 17달러이며, 생성 기능을 임베드하려는 게임 개발자와 창작자 도구가 쓰는 API를 제공합니다. 연주 배경 음악과 퍼블리셔에게 설명할 수 있는 라이선스 근거를 원할 때 안전하고 튀지 않는 선택입니다.

Beatoven, Loudly, AIVA

특정 필요에 대해 알아둘 만한 셋이 더 있습니다. Beatoven.ai는 예산형 선택으로, 상업적 권리를 포함해 월 약 2.50달러라 깨끗한 배경 음악만 필요하다면 이기기 어렵습니다. Loudly는 조금 더 높아 월 약 6달러이고 커스터마이즈와 협업 제어에 힘을 줍니다. AIVA는 전문가입니다. 영화적, 오케스트라 스코어링을 위해 만들어졌으므로, 게임이 팝 루프가 아니라 웅장한 교향 테마를 원할 때 손을 뻗을 도구입니다. 셋 모두 유료 등급에서 상업적 권리를 주고 무료에서는 막는데, 이 카테고리 전체에 걸친 패턴입니다.

직접 돌릴 수 있는 오픈 모델

구독도, 트랙당 요금도 없고, 미공개 프로젝트 오디오에 대한 완전한 통제를 원한다면, 모델을 당신 하드웨어에서 돌리세요. 오픈 오디오 모델은 빠르게 따라잡았고, 2026년에는 여럿이 정말 좋습니다. 규칙 하나: 코드가 아니라 웨이트의 라이선스를 확인하세요. 둘은 종종 다릅니다.

Stable Audio 3

Stable Audio 3(2026년 5월)은 게임을 위한 가장 강력한 오픈 옵션이고, 그 이유는 라이선스에 도달 범위를 더한 것입니다. Stability는 완전히 라이선스된 데이터로 학습한 오픈 웨이트 모델 셋을 공개했습니다. Small-Music과 Small-SFX는 둘 다 CPU에서 돌아 GPU가 필요 없고, Medium은 소비자용 GPU에서 돌며 더 높은 품질을 냅니다. Large 모델만 API 전용입니다. Stability AI Community License에 따라 당신은 출력물을 소유하고 자유롭게 상업화할 수 있으며, 스튜디오 연매출이 100만 달러를 넘어서면 법적 면책까지 더해주는 Enterprise 라이선스로 넘어갑니다.

게임에는 이것이 두 가지 필요를 한 번에 충족합니다. 음악 모델은 최대 약 6분의 가변 길이 트랙을 생성하고, Small-SFX는 실제로 출시할 수 있는 최고의 오픈 사운드 이펙트 모델입니다. 또한 당신 자신의 오디오 폴더로 이들 중 무엇이든 LoRA 미세 조정할 수 있는데, 이것이 게임의 소리 스타일을 가르치는 방법입니다. 그런 다음 하나의 스코어처럼 들리는 메뉴 루프, 전투 스팅어, 앰비언스를 맞춰 생성하세요.

ACE-Step

ACE-Step은 보컬이 있는 풀 트랙을 위해 알아둘 오픈 모델입니다. 1.5 라인(2026년 1월)은 MIT 라이선스로 최대한 허용적이며, 19개 언어에 걸쳐 몇 분 분량의 음악을 빠르게 생성하고 음성 클로닝, 리믹스, 가사 편집이 내장되어 있습니다. 파이프라인을 빌리기보다 소유하고 싶은 팀에게는 Suno의 셀프 호스팅 답이고, 우리 음악 도구 뒤에 있는 세 번째 엔진입니다.

나머지 오픈 진영

필요에 따라 몇 개 더 있습니다. YuE(Apache 2.0)는 가사지에서 보컬이 있는 완성 곡을 생성하며 이를 처음으로 잘 해낸 오픈 모델이었습니다. DiffRhythm 2(Apache 2.0, 2026년 2월)는 빠른 풀 송 생성을 위해 만들어졌습니다. Meta의 MusicGen은 프로토타이핑에는 여전히 무난하지만 웨이트가 CC-BY-NC라서 스케치 도구일 뿐입니다. MusicGen 트랙을 당신이 파는 게임에 절대 넣지 마세요. 최종 버전에서는 ACE-Step이나 Stable Audio로 옮기세요.

Google의 Magenta RealTime(코드 Apache 2.0, 웨이트 CC-BY)은 별종이지만, 게임에는 가장 좋은 방향의 별종입니다. 완성 파일을 렌더링하는 대신, 재생되는 동안 당신이 조종하는 음악을 실시간으로 생성합니다. 이는 플레이어가 전투에 들어가거나 보스가 등장할 때 바뀌는 적응형 사운드트랙의 바로 그 형태입니다. 다른 어떤 오픈 모델도 실시간 조종을 위해 만들어지지 않았으니, 인터랙티브 음악이 목표라면 이것이 출발점입니다.

음악만이 아니라 사운드 이펙트

사운드트랙은 일의 절반입니다. 게임에는 발소리, UI 클릭, 폭발음, 앰비언스도 필요하고, 같은 AI 라이선스 규칙이 적용됩니다. 두 옵션이 두드러집니다. Stable Audio 3 Small-SFX는 로컬에서 돌며 필요할 때 이펙트를 생성하고, 음악 형제들과 같은 상업적으로 안전한 Community License로 나옵니다. ElevenLabs에는 Eleven Music과 같은 상업적 사용 허가 태세를 가진 전용 사운드 이펙트 생성기가 있으며, 그래서 우리 자체 SFX 도구가 음악 도구와 나란히 존재합니다. 전통적 경로로는, 주머니에 넣어둘 만한 CC0 라이브러리를 다룬 우리 무료 사운드 이펙트와 음악 가이드가 있습니다.

게임의 라이선스 현실

이 절은 당신을 게시 중단 통보에서 구해주므로, 출시할 계획인 무언가를 생성하기 전에 읽으세요.

"로열티 프리"는 "저작권 프리"가 아니고, 소유권도 아닙니다. 로열티 프리는 트랙이 재생될 때마다 요금을 내지 않는다는 뜻입니다. 누가 음악을 소유하는지, 학습 데이터가 깨끗했는지에 대해서는 아무 말도 하지 않습니다. 세 가지 다른 개념이며, 마케팅 문구에서 자주 뒤섞입니다.

무료 등급은 상업용 게임에 거의 결코 안전하지 않습니다. Suno, Mubert, Soundraw, Beatoven, Loudly 전반에서 무료 플랜은 개인용이자 비상업용입니다. 당신이 파는 게임은, 심지어 광고나 유료 DLC가 있는 무료 게임도 상업 프로젝트입니다. 유료 플랜이나 허용적으로 라이선스된 오픈 모델을 쓰고, 무료 등급 트랙을 출시하지 마세요.

학습 데이터 소송을 주시하세요. Suno와 Udio 둘 다 대형 레이블의 활발한 소송에 직면해 있습니다. 아직 하급 사용자에게 책임을 물은 법원은 없고 인디의 실질적 노출은 낮지만, 이는 실재하며, 2026년 가장 깨끗한 선택이 라이선스된 데이터로 학습한 도구들인 이유입니다. ElevenLabs Music, Stable Audio, Mubert, Soundraw, AIVA입니다.

영수증을 보관하세요. Suno 같은 도구의 상업적 권리는 당신이 구독 중일 때 생성한 트랙에 적용됩니다. 생성 시점에 구독이 유효했다는 증거를 저장해, 만들 때 그 트랙이 라이선스되어 있었음을 보일 수 있게 하세요.

플랫폼이 요구하는 곳에서 공개하세요. itch.io와 Steam은 각자의 AI 콘텐츠 공개 규칙이 있고, 여기서의 정직함은 값싼 보험입니다. 공개를 어떻게 다루는지는 우리 AI 생성 콘텐츠 정책을, 음악 라이선스가 아트 및 코드와 어떻게 함께 놓이는지는 우리 게임 에셋 라이선스 가이드를 보세요.

그냥 트랙이 아니라, 게임에 맞는 음악 만들기

3분짜리 팝송은 게임 사운드트랙이 아닙니다. 게임에는 이음매가 들리지 않는 루프, 장면이 바뀔 때 믹스할 수 있는 스템, 플레이어를 따라가는 분위기 전환이 필요합니다. 워크플로 메모 몇 가지입니다.

루프는 조금 더 긴 곡을 생성해 깨끗한 루프 지점으로 잘라내거나, 이어쓰기와 인페인팅 기능(Stable Audio와 Suno 둘 다 있습니다)으로 끝을 처음에 다시 잇습니다. 스템은 Premier 플랜의 Suno Studio와 ACE-Step의 리믹스 모드 둘 다 트랙을 파트로 나누므로, 잠입 구간에서는 드럼을 빼고 추격 장면에서 다시 넣을 수 있습니다. 플레이어의 행동에 반응하는 적응형, 실시간 음악에는 Magenta RealTime이 딱 맞게 만들어져 있고, Mubert의 분위기별 무한 스트림은 앱 안의 앰비언트나 무한 배경 레이어에 잘 맞습니다.

나라면 실제로 무엇을 쓸까

오늘 게임에 음악을 넣는다면, 내가 손을 뻗을 조합은 이렇습니다.

라이선스가 빈틈없어야 하는 상업 게임을 출시하나요? 보컬과 리드 트랙에는 ElevenLabs Music을, 연주 베드와 사운드 이펙트에는 Stable Audio 3을 쓰세요. 둘 다 라이선스 데이터로 학습하고 출력물을 상업용으로 허가하는데, 우리 자체 도구의 세 엔진 중 둘이 바로 이 갈래에서 온 이유가 정확히 그것입니다.

빠른 반복과 최고의 보컬이 필요한가요? 답은 Suno Pro입니다. 단, 영수증을 보관하고 작은 소송 꼬리 위험을 받아들이는 조건입니다. 마음에 드는 것을 Suno Studio로 넘겨 스템을 뽑으세요.

완전한 통제와 무구독을 원하나요? 보컬 트랙은 ACE-Step을, 연주와 SFX는 Stable Audio 3을 셀프 호스팅하고, 당신 자신의 오디오로 Stable Audio를 LoRA 미세 조정해 전부가 하나의 스코어처럼 들리게 하세요.

앱 안의 배경 음악이나 플레이어가 스스로 생성하게 하려면, 사용자가 내보낼 수 있는지에 맞는 플랜 등급으로 Mubert나 Soundraw API를 연결하세요. 그리고 게임 플레이에 반응하는 적응형 스코어를 원한다면, Magenta RealTime으로 프로토타이핑부터 시작하세요.

흔한 실수는 하나의 도구로 모든 것을 하려는 것입니다. 음악, 스템, SFX, 적응형 레이어는 서로 다른 일이고, 정답은 보통 각자 하나씩 잘하는 두세 개의 도구입니다. 그 모두의 요점은 같습니다. 사운드트랙이 더는 당신이 잘라내는 구석이 아니게 되는 것입니다.

자주 묻는 질문

상업 게임에 가장 좋은 AI 음악 생성기는 무엇인가요?

깨끗한 라이선스로는 ElevenLabs Music과 Stable Audio 3이 2026년을 이끕니다. 둘 다 라이선스 데이터로 학습하고 출력물을 상업용으로 허가하기 때문입니다. 최고의 보컬을 빠르게 원한다면, 진행 중인 소니 소송을 작은 꼬리 위험으로 받아들일 경우 Suno Pro가 됩니다. 출시할 무엇에도 무료 등급과 비상업용 웨이트는 피하세요.

내가 파는 게임에 AI 생성 음악을 합법적으로 쓸 수 있나요?

대개 그렇습니다. 유료 플랜이나 허용적으로 라이선스된 오픈 모델에서라면요. 다만 세부가 중요합니다. 무료 등급은 거의 항상 비상업용이고, 상업용 라이선스는 저작권 소유와 같지 않으며, 라이선스되지 않은 데이터로 학습한 도구는 소송 위험을 안습니다. 구체적 라이선스를 확인하고, 구독 증거를 보관하고, 플랫폼이 요구하는 곳에서 AI 콘텐츠를 공개하세요.

어떤 AI 음악 생성기를 내 하드웨어에서 돌릴 수 있나요?

Stable Audio 3(Small 모델은 CPU에서, Medium은 소비자용 GPU에서), ACE-Step, YuE, DiffRhythm 2, Magenta RealTime은 모두 오픈이고 셀프 호스팅이 가능합니다. 코드가 아니라 웨이트의 라이선스를 확인하세요. MusicGen의 웨이트는 비상업용이지만, ACE-Step(MIT)과 Stable Audio(Community License)는 상업적 사용을 허용합니다.

게임을 위한 루핑 또는 적응형 음악은 어떻게 얻나요?

더 긴 트랙을 생성해 이음매 없는 루프로 잘라내거나, 이어쓰기와 인페인팅으로 양 끝을 잇습니다. 스템은 Suno Studio나 ACE-Step의 리믹스 모드를 쓰세요. 게임 플레이에 반응하는 실시간 음악에는 Magenta RealTime이 실시간 조종을 위해 만들어졌고, Mubert의 분위기 기반 스트림은 무한 배경 레이어에 알맞습니다.

더 읽을거리

• 게임을 위한 최고의 오픈소스 생성형 AI 모델, 비디오, 이미지, 3D, 오디오, 음성을 아우르는 전체 오픈 모델 정리
• 게임을 위한 최고의 AI 에셋 생성기, 3D 모델, 텍스처, 오디오 생성을 한자리에
• 게임을 위한 무료 사운드 이펙트와 음악, AI 생성과 함께 쓸 CC0 라이브러리
• 게임 에셋 라이선스 완전 정리, 음악 라이선스가 아트 및 코드와 어떻게 맞물리는지
• AI 생성 콘텐츠 정책, 우리가 AI 공개를 다루는 방식

마지막 업데이트: 2026년 6월.

2026년 캐주얼 게임의 이야기는 "붐이 계속된다"가 아닙니다. "붐이 성숙해졌다"입니다. 플레이어들은 여전히 이 게임들을 더 자주 열지만, 새 게임은 더 적게 설치하고 있습니다. 그리고 돈은 3년 전에 이겼던 게임과는 다른 종류의 게임에 보상을 주는 방향으로 움직이고 있습니다. 우리는 Sensor Tower의 2025년 연간 수치, AppMagic(Gamesforum Intelligence와 GameRefinery 경유), 그리고 Deconstructor of Fun과 PocketGamer.biz의 애널리스트들을 파고들어 진짜 변화와 과장을 구분했습니다. 실제로 벌어지고 있는 일은 다음과 같습니다.

짧게 요약하면 캐주얼 게임 시장은 2025년에 성숙해졌습니다. 인앱 매출은 약 817억 5천만 달러로 겨우 1.3% 늘었고 다운로드는 7.2% 줄어 504억 건이 됐습니다. 그래서 이제 성장은 새로운 설치가 아니라 플레이어가 더 많이 쓰는 데서 나옵니다. 하이브리드 캐주얼은 인앱 매출이 늘어난 유일한 세그먼트로, 20% 증가한 42억 달러를 기록했고 하이브리드 캐주얼 퍼즐이 단연 돋보였습니다. 수익화는 광고만 붙이는 물량 플레이부터 5억 달러 넘게 버는 광고 없는 게임까지 넓은 스펙트럼으로 퍼졌고, 생성형 AI는 스튜디오에서 실험 단계를 넘어 표준 도구가 됐습니다.

시장은 설치 기반 성장을 멈췄다

모바일 게임은 2025년에 인앱 구매로 약 817억 5천만 달러를 벌어들였지만, 2025년 연간 수치에 따르면 이는 2024년 대비 1.3% 증가에 그쳤습니다. 다운로드는 반대로 움직여 7.2% 줄어든 504억 건이 됐고, 2년 연속 감소입니다. 참고로 스토어 전체의 모든 앱 인앱 지출은 건강하게 10.6% 늘어 1,670억 달러가 됐습니다. 그러니까 평평해진 것은 모바일 커머스 전반이 아니라 게임 그 자체입니다.

그 격차가 이야기의 전부입니다. 참여도는 여전히 오르고 있지만(전년에는 세션이 12%, 사용 시간이 7.9% 늘었습니다) 신규 설치는 줄고 있습니다. 이제 성장은 새 플레이어를 확보하는 데서가 아니라 이미 있는 플레이어에게서 더 많은 돈을 얻는 데서 나옵니다. 저렴한 유저 확보의 시대는 끝났습니다.

같은 분화를 캐주얼 카테고리 안에서도 볼 수 있습니다. Gamesforum Intelligence 캐주얼 리포트(AppMagic 데이터)에 따르면 상위 1,000개 캐주얼 게임에서 인앱 구매 매출은 2022년 174억 7천만 달러에서 2024년 219억 9천만 달러로 올랐고 2025년은 229억 9천만 달러로 전망되는데, 다운로드는 160억 건 근처에서 거의 평평하게 유지됐습니다. 매출은 더 늘고, 다운로드 수는 그대로입니다. 플레이어들은 그냥 설치 한 건당 더 많이 쓰고 있는 것입니다.

하이퍼캐주얼의 광고 전용 모델이 무너졌고, 그건 괜찮다

여기저기서 많이 보게 될 헤드라인은 "하이퍼캐주얼이 죽어간다"입니다. 절반은 맞습니다. 무너진 것은 경제성이지 게임이 아닙니다. 몇 년 동안 하이퍼캐주얼은 하나의 트릭으로 돌아갔습니다. 설치를 싸게 사서 광고를 띄우고 그 차익을 챙기는 것입니다. 확보 비용이 광고로 회수할 수 있는 선을 넘어 오르자, 그 순수한 광고 전용 모델은 작동을 멈췄습니다.

게임 자체는 잘 지내고 있습니다. Game World Observer에 따르면 하이퍼캐주얼은 2025년에도 220억 5천만 건의 설치로 다운로드를 지배했고 사용 시간도 계속 늘렸습니다. PocketGamer.biz는 선두 타이틀들이 전년보다 월 매출을 대략 3배 더 벌었다고 보고하지만, 이 수치는 낮은 기저에서 나온 것이고 재분류된 하이브리드 캐주얼 게임을 일부 반영한 것입니다. 결론은 간단합니다. 이 포맷은 광고만으로 사는 대신 광고 위에 인앱 구매를 얹어서 살아남습니다.

진짜 승자는 하이브리드 캐주얼이다

2026년을 규정하는 트렌드 하나를 꼽으라면 하이브리드 캐주얼입니다. Game World Observer가 분석하듯, 지난해 인앱 구매 매출이 늘어난 유일한 캐주얼 세그먼트로 20% 증가한 42억 달러를 기록했고, 상위 10개 타이틀은 전년 대비 인앱 구매 성장률이 67%에서 100% 사이였습니다. 하이브리드 캐주얼은 하이퍼캐주얼의 짧게 즐기는 광고 친화적 루프를 가져와 진짜 캐주얼 게임의 메타 진행과 지출 깊이를 붙입니다. 쉬운 설치는 그대로 두고 돈을 쓸 이유를 더합니다.

성장은 하이브리드 캐주얼 퍼즐에 집중돼 있습니다. GameRefinery의 2025년 12월 리뷰는 Match3 같은 기성 서브장르를 "극도로 포화됐다"고 부르는 반면, 더 새로운 퍼즐 타이틀 무리가 최고 매출 차트로 올라왔습니다. Color Block Jam, Pixel Flow, Screwdom, Magic Sort, All in Hole입니다. Color Block Jam 하나만 해도 한 분기에 설치 2,180만 건으로 약 4,200만 달러의 매출을 올렸습니다. 2026년에 어떤 종류의 캐주얼 게임을 만들지 정하고 있다면, "포화된 Match3 클론"과 "신선한 하이브리드 캐주얼 퍼즐"은 아주 다른 베팅입니다.

수익화는 이제 하나의 모델이 아니라 스펙트럼이다

더 이상 단일한 "캐주얼 수익화 모델"은 없습니다. 시장은 뚜렷한 스펙트럼으로 갈라졌고, 게임이 어디에 자리하는지는 그 게임이 무엇이냐에 달려 있습니다. 여러 트래커에서 일관되게 읽히는 것은 인앱 구매와 광고를 섞는 것이 최적화된 중간 전략이 됐다는 점입니다. 하지만 양 극단은 여전히 크게 이깁니다.

교훈은 "하나를 골라라"가 아닙니다. 모델이 게임을 따라가야 한다는 것입니다. 도달 범위가 큰 순수 퍼즐 장난감은 광고로 살 수 있습니다. 수집, 진행, 소셜 훅이 있는 게임은 결제 플레이어에게 광고를 보여주면 돈을 테이블에 남겨두는 셈입니다. 그 사이의 대부분은 둘을 섞을 때 가장 잘 됩니다. 여기의 수치는 Gamesforum Intelligence 캐주얼 리포트(AppMagic 데이터)에서 가져왔습니다.

돈은 어디로 움직이고 있나

지역적으로 캐주얼 게임은 서구 시장에서 가장 큰 성장을 이끌었습니다. 북미가 절대 성장이 가장 컸고 유럽이 비율 면에서 더 빠르게 성장한 반면, 아시아는 인앱 구매 매출이 실제로 감소한 유일한 지역이었습니다. 아시아의 하락 일부는 강달러 효과지만 방향은 분명합니다. 캐주얼 지출이 늘고 있는 곳은 서구입니다.

가장 눈에 띄는 2025년 이정표는 게임 바로 바깥에 있습니다. Deconstructor of Fun이 설명하듯, 처음으로 게임이 아닌 앱이 모바일 인앱 구매에서 게임을 앞질렀습니다. 약 856억 달러 대 818억 달러였고, 그 이동의 큰 부분은 생성형 AI 구독 앱에서 나왔습니다. 게임은 한때 소유했던 스토어에서 최고 자리를 잃었고, 그 일부는 AI 제품에게 넘어갔습니다. 곱씹어볼 만한 일입니다.

캐주얼 게임을 만드는 방식에서 AI가 바꾸고 있는 것

AI는 방정식의 양쪽에 다 나타납니다. 지출 쪽에서는 위에서 언급했듯 AI 앱이 이제 예전에 게임으로 흘러가던 돈을 끌어당기고 있습니다. 제작 쪽에서는 생성형 AI가 실험 단계를 넘어 표준 도구가 됐습니다. GDC의 오래된 State of the Game Industry 설문은 개발자의 52%가 조직 어딘가에서 생성형 AI를 쓰는 회사에서 일하고, 36%는 자기 업무에서 이 도구들을 쓴다는 것을 발견했습니다.

다만 계속 우상향은 아닙니다. 더 최근의 Game Developer Collective 설문은 개인 사용이 29%로 떨어졌음을 발견해, 일부 팀이 AI 도구를 써보고 물러났음을 시사합니다. 2026년의 솔직한 판단은 AI가 게임 스튜디오에서 확실히 주류지만 여전히 진짜 도움이 되는 지점을 찾아 자리를 잡아가는 중이라는 것입니다. 캐주얼 게임에서 그것은 게임 전체를 손대지 않고 출시하는 것이 아니라 빠른 프로토타이핑, 에셋 생성, 라이브 옵스 콘텐츠를 뜻합니다.

솔로 창작자와 소규모 창작자에게는 이곳이 가장 흥미로운 전선입니다. AI 앱 카테고리를 만든 것과 똑같은 프롬프트-투-게임 접근이 이제 게임 자체를 만드는 데 겨눠지고 있습니다. 캐주얼은 AI가 가장 잘 다루는 장르입니다. 루프가 촘촘하고 규모가 작기 때문이며, 바로 그 때문에 Cinevva 같은 도구가 문장 한 줄을 받아 브라우저에서 바로 즐길 수 있는 게임을 건네줄 수 있습니다.

캐주얼 게임을 만들고 있다면 이것이 무슨 뜻인가

종합하면 2026년의 전략은 2022년과 다릅니다. 이제 저렴한 설치를 따내려고 경주하지 않습니다. 그 게임은 끝났으니까요. 더 작은 청중이 실제로 붙잡고 돈을 쓸 무언가를 만들려고 하는 것입니다. 그러려면 아래에 깊이가 받쳐주는 분명한 훅, 광고를 보는 사람과 결제하는 사람 양쪽을 존중하는 하이브리드 수익화, 그리고 천 번째 Match3 클론이 아니라 검증된 루프에 대한 신선한 해석이 유리합니다. 서구 청중은 돈을 쓰고 있고, 퍼즐은 정상부는 붐비지만 새로운 메커닉에는 활짝 열려 있으며, 이제 AI가 첫 플레이 가능 버전을 만들어줄 수 있으니 아이디어를 시도하는 비용은 무너졌습니다.

바로 그 마지막 부분이 진짜 기회입니다. 프로토타입이 주말이 아니라 몇 분 걸릴 때, 예전에 하나 만드는 데 들던 노력으로 열 개의 하이브리드 캐주얼 훅을 테스트할 수 있습니다. 시장은 붙는 아이디어에 보상을 주고, 그것을 찾는 가장 빠른 길은 계획이 아니라 만들고 플레이하는 것입니다. 프롬프트에서 하나 시작해 무엇이 버티는지 보세요.

자주 묻는 질문

2026년에 캐주얼 게임 시장은 줄어들고 있나요?

아니요, 하지만 다운로드 기반 성장은 멈췄습니다. 인앱 매출은 2025년에 약 817억 5천만 달러로 여전히 조금 올랐지만 다운로드는 7.2% 줄었습니다. 시장이 성숙하고 있어서 성장은 새 설치가 아니라 플레이어가 더 많이 쓰는 데서 나옵니다.

하이브리드 캐주얼이 무엇이고 왜 중요한가요?

하이브리드 캐주얼은 하이퍼캐주얼의 쉽고 광고 친화적인 루프에 완전한 캐주얼 게임의 더 깊은 진행과 구매를 섞습니다. 2025년에 인앱 매출이 늘어난 유일한 캐주얼 세그먼트로 20% 증가한 42억 달러를 기록했고, 그래서 지금 연구해야 할 카테고리입니다.

지금 뜨고 있는 캐주얼 게임은 무엇인가요?

신규 히트 쪽에서는 Color Block Jam, Pixel Flow, Screwdom, Magic Sort 같은 하이브리드 캐주얼 퍼즐 타이틀이 2025년에 빠르게 성장했습니다. 기존 거인들 중에서는 Royal Match와 Monopoly Go!가 매출을 이끌고, Block Blast!가 다운로드를 이끕니다.

제 게임은 광고를 써야 하나요, 인앱 구매를 써야 하나요?

게임에 따라 다릅니다. 도달 범위가 큰 장난감은 광고로 살 수 있고, 깊은 메타 게임은 광고 없이 구매로 가는 것이 가장 좋으며, 그 사이의 대부분은 둘을 섞을 때 더 많이 법니다. 모델이 디자인을 따라가야지 그 반대가 아닙니다.

AI는 캐주얼 게임 개발을 어떻게 바꾸고 있나요?

생성형 AI는 이제 스튜디오에서 표준이며, 개발자의 52%가 이를 쓰는 회사에 있습니다. 특히 캐주얼 게임에서는 프로토타이핑, 에셋 제작, 라이브 옵스를 빠르게 하고, 프롬프트-투-게임 도구는 이제 창작자가 설명만으로 플레이 가능한 캐주얼 게임을 만들 수 있게 해줍니다.

2026년 캐주얼 게임 시장 규모는 얼마나 큰가요?

모바일 게임은 2025년에 인앱 구매로 약 817억 5천만 달러를 벌어 2024년 대비 겨우 1.3% 늘었고, 상위 1,000개 캐주얼 게임이 그중 대략 230억 달러를 차지합니다. 다운로드는 7.2% 줄어 504억 건이 됐으니, 시장은 새 설치가 아니라 플레이어당 지출로 성장하고 있습니다.

2026년에 하이퍼캐주얼은 죽었나요?

아니요. 무너진 것은 광고 전용 비즈니스 모델이지 게임이 아닙니다. 하이퍼캐주얼은 2025년에도 220억 5천만 건의 설치로 모든 다운로드를 이끌었고, 이 포맷은 광고 위에 인앱 구매를 얹는 하이브리드 수익화로 옮겨가고 있습니다.

관련 글

• 2026년 최고의 AI 게임 생성기 — 프롬프트에서 캐주얼 게임을 만들어주는 도구들
• AI로 게임 만드는 법 (코딩 없이) — 단계별 제작
• 바이브 코딩 게임: 무엇이고 어떻게 시작하나 — 이 시장이 보상하는 프로토타이핑 마인드셋
• 원클릭으로 만들 수 있는 AI 게임 프롬프트 — 빠르게 테스트할 캐주얼 훅
• itch.io에서 플레이 수를 늘리는 법 — 붙어 있는 청중 찾기

원하는 것을 입력하면 Cinevva가 브라우저 안에서 플레이 가능한 게임을 만들고, 그다음 채팅으로 게임을 바꿔 나갑니다. 이게 전체 흐름입니다. 어려운 건 도구가 아니라 무슨 말을 해야 하는지 아는 것입니다.

우리는 일주일치 실제 세션을 읽으면서, 누군가 계속 간직하는 게임이 되는 프롬프트와 첫 빌드 직후에 버려지는 프롬프트를 가르는 차이가 무엇인지 살펴봤습니다. 패턴은 분명했고, 어느 것도 복잡하지 않았습니다. 효과가 있는 방법을 정리했습니다.

명확한 한 문장으로 시작하세요

가장 좋은 시작은 게임의 종류와 그 게임을 재미있게 만드는 한 가지를 짚어 주는 한두 문장입니다. "손전등과 제한된 탄약을 들고 다니는 탑다운 좀비 생존 게임"이라고 하면 AI에게 장르, 카메라 앵글, 핵심 긴장감, 그리고 중심으로 삼을 제약을 함께 줍니다. AI는 무엇을 만들지 정확히 압니다.

이를 "플랫포머"나 "슈팅 게임"과 비교해 보세요. 이런 건 우리가 매일 보는 실제 시작 문구입니다. Cinevva는 여기서도 뭔가를 만들지만, 그게 여러분 머릿속에 있던 그 무언가인지는 반반의 도박입니다. 첫 문장이 구체적일수록 첫 빌드가 원하던 것에 더 가깝게 나옵니다.

유명한 게임이 아니라 느낌을 설명하세요

많은 사람이 게임 제목 하나로 시작합니다. 포켓몬. GTA. 마인크래프트. 좋아하는 Roblox 게임. 이해합니다, 여러분이 게임을 만들고 싶게 만든 게 바로 그 게임들이니까요. 문제는 그 게임들은 스튜디오 전체가 몇 년에 걸쳐 만든 것이고, 브라우저 탭 하나에 담기지 않는다는 점입니다.

그러니 대신 실제로 원하는 부분을 짚어 주세요. GTA라고 하면 아마 "열린 도시를 돌아다니며 미션을 수행한다"는 뜻일 겁니다. 마인크래프트라고 하면 "끝없는 격자 위에 블록을 놓고 부수며 무언가를 짓는다"는 뜻일 수 있습니다. 메커니즘을 풀어서 설명하면 Cinevva는 프랜차이즈 전체를 내놓지는 못해도 그 느낌은 담아낼 수 있습니다. 경험을 설명하는 것이 브랜드 이름을 대는 것보다 언제나 낫습니다.

작게 만들게 두고, 그다음 키우세요

Cinevva는 첫 턴에 일부러 플레이 가능한 조각을 만듭니다. 결국 사랑하는 게임을 손에 넣는 창작자들은 시작 프롬프트에 모든 걸 욱여넣으려 하지 않습니다. 실행되는 걸 눈으로 확인한 다음, 메시지마다 한 가지씩 추가합니다.

"교통 차량을 추가해줘." "점프를 더 높게 해줘." "두 번째 레벨을 만들어줘." "체력바를 추가해줘." 각 변경은 작고, 빠르고, 확인하기 쉬우며, 이것들이 쌓여 진짜 게임이 됩니다. 첫 턴에 열 가지 기능을 밀어넣으려 하면 보통 그 열 가지 모두가 불안정한 버전으로 나옵니다. 한 번에 하나씩 명확하게 바꾸는 것이 좋은 게임이 만들어지는 방식입니다.

뭔가 잘못됐을 때는 정확히 무엇인지 말하세요

도움이 안 되는 가장 흔한 메시지는 "작동 안 해요" 또는 그냥 "고쳐줘"입니다. AI는 여러분의 화면을 볼 수 없어서 추측할 수밖에 없습니다.

세 가지를 말해 주세요. 무엇을 했는지, 무슨 일이 벌어졌는지, 무엇을 기대했는지. "스페이스를 누르면 새가 겨우 깡충 뛰는데, 더 높이 날갯짓하길 원했어요"라고 하면 첫 시도에 제대로 된 수정을 받습니다. "차가 벽에 부딪혀 멈추지 않고 벽을 통과해요"는 곧장 충돌 감지를 가리킵니다. 열 단어를 더 쓰면 오가는 대화 세 번을 아낍니다.

모양새는 구체적으로 말하세요

Cinevva는 그려낼 것을 줬을 때 비주얼을 잘 만듭니다. 색, 형태, 분위기, 캐릭터 디테일. 한 창작자는 자기 주인공을 "흰 망토, 흰 장갑, 빛나는 흰 눈을 가진 어두운 형상"이라고 설명했고 정확히 그대로 받았습니다.

"더 멋지게 만들어줘"는 AI에게 작업할 거리를 주지 않습니다. 대신 색 팔레트, 분위기(네온, 아늑함, 레트로, 호러, 손그림), 그리고 여러분에게 중요한 핵심 캐릭터나 세계관 디테일을 짚어 주세요. 구체적인 몇 단어가 전체 모양새를 바꿉니다.

여러분의 아트를 가져오세요

AI가 그리는 것에만 매여 있지 않아도 됩니다. 자신의 이미지를 채팅에 바로 넣으면 텍스처, 스프라이트, 배경으로 사용합니다. 아니면 에셋 라이브러리를 열어 저작자 표시 걱정 없는 무료 3D 모델을 가져오세요. 특정한 모양새를 염두에 두고 있다면, 그것을 설명하려 애쓰기보다 참고 이미지를 건네는 편이 종종 더 잘 통합니다.

첫 빌드가 느린 것이고, 작업은 저장됩니다

첫 빌드는 Cinevva가 여러분의 게임 전체를 처음부터 작성하기 때문에 가장 오래 걸립니다. 그다음부터는 수정이 몇 초 만에 돌아옵니다. 그러니 그 첫 기다림을 견뎌 주세요, 정말로 세션에서 겪을 가장 긴 기다림입니다.

그리고 네, 여러분의 게임은 저장됩니다. 탭을 닫고, 내일 다시 와서, 내 게임을 열면, 떠났던 그 자리에서 그대로 이어서 할 수 있습니다. 나갈 때 사라지는 건 없습니다.

처음부터 끝까지, 좋은 프롬프트 하나

이 모든 걸 합치면 강한 시작 문구는 이렇게 생겼습니다.

"탑다운 트윈스틱 슈터. 나는 네온 아레나 속의 작은 로봇이고, 적들이 물결처럼 몰려오며, 나는 피하고 쏘며 살아남는다. 빠르고 아케이드 느낌으로 만들어줘."

장르, 캐릭터, 배경, 핵심 루프, 그리고 느낌까지 짧은 네 문장 안에 다 담았습니다. 만들고, 실행되는 걸 지켜보고, 그다음 추가하기 시작하세요. 다섯 웨이브마다 보스. 시프트 키로 대시. 콤보에 점수 배수. 이렇게 한 문장이 실제로 공유하고 싶은 게임으로 바뀝니다.

써보고 싶으세요? 크리에이터를 열고 무료로 만들기 시작하기 →

마지막 업데이트: 2026년 6월.

코드 없이 2D 게임을 만드는 건 몇 년 전부터 가능했습니다. 하지만 코드 없이, 브라우저에서 돌아가는 3D 게임을 만드는 건 의외로 어려웠고, 대부분의 가이드는 그냥 2D 도구를 보여주면서 이 문제를 슬쩍 피해 갑니다. 이 글은 그러지 않습니다. 2026년 "브라우저에서 코딩 없이 3D"의 솔직한 현재 상태와, 지금 실제로 통하는 길을 알려드립니다.

노코드 3D에 관한 불편한 진실

고전적인 노코드 게임 빌더는 압도적으로 2D입니다. 브라우저에서 돌아가던 순수 노코드 3D 도구 몇 개는 대부분 사라졌거나 방향을 틀었습니다.

• Struckd는 웹에서 진짜 드래그 앤 드롭 3D에 가장 가까웠던 도구였지만, 2026년 8월에 스튜디오를 종료합니다.
• Crayta는 2023년에 이미 문을 닫았습니다.
• Core는 노코드 3D를 지원하지만 다운로드 전용 클라이언트라서 브라우저 게임이 아닙니다.
• PlayCanvas는 훌륭한 웹 3D 엔진이지만 JavaScript를 직접 작성하도록 되어 있어서, 사실 노코드가 아닙니다.

여기서 진짜 공백이 생깁니다. 브라우저에서, 코드 없이 3D를 원한다면, 고전적인 비주얼 빌더 세계에는 예외 하나를 빼면 내놓을 게 거의 없습니다.

고전적인 예외 하나: GDevelop

GDevelop은 브라우저에서 돌아가는 무료 오픈소스 비주얼 게임 빌더로, 2025년 후반부터 3D에 크게 투자해 왔습니다. 코드 대신 비주얼 이벤트 시트로 로직을 만들고, 전용 3D 에디터와 3D 물리를 갖췄으며, gd.games에서 공유 링크와 함께 웹으로 퍼블리싱합니다. 기본적으로는 2D 도구에 3D가 점점 붙어 가는 형태라서 전용 3D 엔진에는 못 미치지만, 진짜 노코드로 브라우저 3D를 하려면 가장 강력한 고전 선택지입니다. 여기에 AI 에이전트까지 추가됐는데, 이게 다른 길로 이어집니다.

2026년에 실제로 통하는 길: AI 프롬프트-투-게임

여기서 흐름이 바뀝니다. 2026년에 코딩 없이 3D 브라우저 게임을 만드는 가장 현실적인 방법은 비주얼 에디터가 아니라, AI에게 게임을 설명하고 웹 엔진 위에 진짜 3D 게임을 만들게 하는 겁니다. 이걸 바이브 코딩이라고 부르기도 하는데, 특히 3D에서는 고전적인 노코드 3D 도구가 시들해지는 동안 조용히 믿을 만한 경로가 됐습니다.

이걸 하는 도구가 몇 개 있습니다.

• Cinevva는 Three.js 기반 엔진 위에서 텍스트 프롬프트로 진짜 3D, 브라우저 플레이 가능한 게임을 만듭니다. 3D 모델, 이미지, 음악, 스카이박스 생성이 내장돼 있고 즉시 공유할 수 있는 링크를 줍니다.
• Rosebud는 프롬프트-투-게임을 하며 2D와 점점 늘어나는 3D를 모두 지원하고, 브라우저에서 호스팅됩니다.
• Nilo는 브라우저 기반 AI 3D로, Roblox 익스포트에 강점이 있고 더 어린 사용자층을 겨냥합니다.

이 중 어떤 것에서도 코드를 쓰지 않습니다. 게임을 설명하고, 결과를 플레이하고, 변경을 요청하며 다듬습니다. 각 도구가 어떻게 다른지는 전체 AI 게임 생성기 비교를 참고하세요.

AI로 3D 브라우저 게임 만드는 법, 단계별로

1. 작은 3D 게임을 설명하세요

장르, 눈에 띄는 디테일 하나, 그리고 목표를 정하세요. 3D는 콘셉트가 단순하고 공간적일 때 가장 잘 먹힙니다. 예를 들면:

떠다니는 섬 사이를 뛰어넘으며 타이머와 경주해 끝까지 가는 1인칭 파쿠르 게임을 만들어 줘.

빈 프롬프트에서 시작하거나 원클릭 3D 프롬프트를 가져다 손봐도 됩니다.

2. 플레이해 보고, 딱 한 가지만 바꾸세요

플레이 가능한 3D 장면을 받게 됩니다. 플레이해 보고 가장 큰 문제 하나를 고르세요. 그 한 가지 변경을 요청하세요. "점프가 더 멀리 닿게 해줘", "떨어지면 리스폰되게 추가해줘", "플레이어를 더 빠르게 해줘". 바꾸고, 플레이하고, 반복하세요. 이 루프가 전부입니다.

3. 3D 에셋을 추가하세요

원하는 모델과 룩을 요청하세요. "플레이어를 로우폴리 로봇으로 해줘", "노을 스카이박스를 써줘", "섬은 돌로 하고 위에 잔디를 깔아줘". 도구에 CC0 에셋 라이브러리가 있다면, 퍼블리싱할 것에는 그걸 적극 활용하세요. 무료 게임 에셋 가이드에서 출처와 라이선스를 설명합니다.

4. 게임답게 느껴지도록 만드세요

3D에서 플레이어가 알아채는 마무리를 더하세요. 명확한 카메라, 반응 좋은 조작, 눈에 보이는 목표, 핵심 동작에 붙는 사운드, 그리고 승리 또는 패배 상태. 타이틀 화면과 다시 시작 버튼도 요청하세요.

5. 링크를 퍼블리싱하세요

브라우저 도구는 클릭 한 번으로 공유 가능한 URL을 줍니다. 여기저기 보내 보고, 사람들이 어디서 이탈하는지 확인하고, 그걸 다음 변경 라운드로 만드세요.

직접 손으로 만드는 건 어떨까?

코드를 조금 배울 마음이 있다면 웹 3D 세계는 풍부합니다. Three.js, Babylon.js, PlayCanvas 모두 뛰어난 브라우저 3D를 만들고, Godot 같은 엔진도 웹으로 익스포트합니다. 그건 노코드가 아니지만, 그 선을 넘고 나면 천장이 아주 높다는 걸 알아두는 게 좋습니다. 웹 게임 엔진 비교에서 이 선택지들을 다룹니다. 진짜 노코드로 남고 싶다면, GDevelop 아니면 AI 프롬프트-투-게임 도구가 답입니다.

자주 묻는 질문

코딩 없이 브라우저에서 3D 게임을 만들 수 있나요?

네, 하지만 선택지가 좁습니다. GDevelop은 진짜 브라우저 3D를 지원하는 대표적인 고전 노코드 도구이고, Cinevva, Rosebud, Nilo 같은 AI 프롬프트-투-게임 도구는 코딩 대신 게임을 설명해서 3D 브라우저 게임을 만들게 해줍니다. 오래된 순수 노코드 3D 도구 몇 개(Struckd, Crayta)는 문을 닫았기 때문에, 2026년의 현실적인 길은 GDevelop 아니면 AI 경로입니다.

경험이 전혀 없을 때 3D 게임을 만드는 가장 쉬운 방법은?

AI 프롬프트-투-게임 도구에 게임을 설명하고 대화하며 다듬는 겁니다. 설치할 엔진도 코드도 없이 몇 분 만에 플레이 가능한 3D 게임을 얻고, 한 번에 하나씩 개선해 나갑니다. 완전 초보자에게 가장 마찰이 적은 출발점입니다.

GDevelop은 3D에 좋은가요?

GDevelop은 기본적으로 2D 엔진이지만, 2025년 후반부터 전용 3D 에디터, 3D 물리, 3D 기능을 추가했고, 무료에 오픈소스이며 웹 퍼블리싱까지 되는 브라우저 기반입니다. 전용 3D 엔진에는 못 미치지만, 무료 노코드로 브라우저 3D를 하려면 가장 강력한 고전 선택지입니다.

3D 브라우저 게임을 만들려면 강력한 컴퓨터가 필요한가요?

아니요. 브라우저 기반 AI 도구와 GDevelop은 무거운 작업을 서버나 브라우저 안에서 처리하므로 게이밍 PC나 전용 GPU가 필요 없습니다. 적당히 최신인 컴퓨터와 요즘 브라우저만 있으면 만들고 플레이하기에 충분합니다.

관련 글

• 2026년 최고의 AI 게임 생성기 — 프롬프트로 3D를 만드는 도구들
• AI로 게임 만드는 법 (코딩 없이) — 초보자용 전체 워크플로
• 바이브 코딩 게임: 무엇이고 어떻게 시작하나 — 프롬프트 기반 접근법 설명
• 원클릭으로 만드는 AI 게임 프롬프트 — 3D 출발점
• 2026년 최고의 웹 게임 엔진 — 코드를 조금 배우기로 했다면
• 무료 게임 에셋 찾는 곳 — 3D 모델과 텍스처

마지막 업데이트: 2026년 6월.

2026년에는 게임 에셋을 생성하는 것이 알맞은 무료 에셋을 찾는 것보다 더 빠른 경우가 많습니다. 소품을 설명하면 1분 안에 텍스처가 입혀진 3D 모델을 얻습니다. 분위기를 입력하면 음악이 나옵니다. 이 가이드는 3D, 텍스처, 오디오 전반에 걸친 게임용 최고의 AI 에셋 생성기와 각각 무엇을 잘하는지, 그리고 출시 전에 반드시 확인해야 할 라이선스 함정을 다룹니다.

라이선스 함정 (먼저 읽으세요)

대부분의 호스팅형 AI 생성기는 무료로 만들게 해주지만 상업적 권리는 유료 플랜 뒤에 두고, 무료 등급의 결과물은 비상업용인 경우가 많습니다. 직접 호스팅하는 오픈 모델은 보통 상업적 사용에 가장 깔끔하지만, 각 모델마다 고유한 라이선스가 있습니다(일부는 특정 지역을 제외합니다). AI가 만든 것을 출시하기 전에 그 모델의 결과물 권리 조건을 확인하세요. 확신이 서지 않으면 허용적인 라이선스를 가진 오픈 모델이나 상업적 권리를 부여하는 유료 등급을 사용하세요.

3D 모델 생성기

호스팅형 (가장 빠르게 시작)

• Meshy — 텍스트 또는 이미지에서 PBR 재질이 적용된, 리깅 가능한 텍스처드 3D 메시로. 무료 등급은 비상업용이고 상업적 사용은 Pro에서 가능합니다. 가장 인기 있는 올라운더입니다. meshy.ai
• Tripo — 텍스트 또는 이미지에서 4K PBR과 자동 리깅이 되는 3D로. 무료 등급은 비상업용. 게임에 초점을 맞춘 탄탄한 결과물을 냅니다. tripo3d.ai
• Rodin / Hyper3D — 깔끔한 쿼드 토폴로지, 생성은 무료이고 다운로드는 유료. 메시 토폴로지를 중요하게 여길 때 좋습니다. hyper3d.ai
• Sloyd — 게임에 초점을 맞춘 파라메트릭 및 AI 생성, 유료 등급에서 상업적 사용 가능. sloyd.ai

오픈 (직접 호스팅, 상업적 사용에 유리)

• Hunyuan3D 2.1 (텐센트) — 오픈 가중치와 학습 코드, 프로덕션급 PBR 텍스처링. 라이선스가 EU, 영국, 대한민국을 제외한다는 점에 유의하세요. 이들 지역에서 출시하기 전에 확인해야 합니다. Cinevva는 이를 3D 모델 생성기로 운영합니다.
• TRELLIS.2 (마이크로소프트) — MIT 라이선스, 현재 오픈 이미지-투-3D의 선두주자, 네이티브 PBR.
• SAM 3D (메타) — 사진 한 장에서 3D로, 객체와 사람 몸에 모두 사용. Cinevva는 이를 가우시안 스플랫을 출력하는 브라우저 내 이미지-투-3D 객체 캡처로 운영합니다.
• Roblox Cube 3D — 오픈소스로 공개된 텍스트-투-메시.

텍스처 및 이미지 생성기

타일링 텍스처, 스프라이트, 컨셉 아트, UI를 위한 도구입니다.

• FLUX.2 (Black Forest Labs) — 강력한 텍스트-투-이미지와 편집 기능. 자유롭게 상업적으로 쓸 수 있는 오픈 옵션은 klein 4B(Apache 2.0)입니다.
• Qwen-Image (알리바바) — 오픈, Apache 2.0, 업계 최고 수준의 텍스트 렌더링(간판과 라벨에 아주 좋습니다).
• Stable Diffusion 3.5 — 깊이 있는 커스터마이징을 위한 성숙한 생태계(ControlNet, 인페인팅, LoRA).

이 모델들은 게임에 바로 넣을 수 있는 이음매 없는 텍스처와 2D 아트를 생성합니다. 전체 라인업과 라이선스는 오픈소스 생성형 AI 모델 가이드를 참고하세요.

오디오 생성기 (음악과 SFX)

• Stable Audio 3.0 — Small 모델의 오픈 가중치와 함께 라이선스된 데이터로 학습한 전용 오픈 사운드 이펙트 모델(법적 근거가 깔끔합니다). 게임 SFX를 위한 가장 강력한 오픈 선택지입니다.
• ACE-Step 1.5 — 오픈, MIT 라이선스의 음악 생성으로, 여러 언어를 지원하고 보이스 클로닝도 됩니다.
• ElevenLabs — SFX와 음악을 위한 가장 강력한 호스팅형 옵션. 유료 플랜에서 상업적 권리를 얻습니다.

리깅과 애니메이션

자동 리깅은 성숙해졌습니다. UniRig(MIT), NVIDIA SOMA-X(Apache 2.0) 같은 오픈 모델은 메시에 맞는 스켈레톤과 스키닝을 생성합니다. 이제 불안정해진 Mixamo의 믿을 만한 대체재입니다. Tripo와 Meshy 같은 호스팅형 도구도 자동 리깅을 지원합니다. Cinevva의 Auto Rigger는 이를 브라우저에서 처리합니다. GLB, FBX, OBJ를 올리면 선택적 프리셋 애니메이션이 포함된 리깅된 모델을 돌려줍니다.

비교

올인원 옵션

이 도구들을 이어 붙이는 것도 되지만, 결국 파이프라인이 됩니다. 어떤 게임 창작자들은 생성 기능을 에디터 안에 묶어둡니다. Cinevva는 텍스트-투-3D, 이미지, 음악, 스카이박스 생성을 기본으로 내장하고 있어서, 도구 사이를 내보내고 가져올 필요 없이 에셋을 생성해 바로 게임에 넣을 수 있습니다. 무료로 사용해 보세요.

자주 묻는 질문

게임에 가장 좋은 AI 3D 모델 생성기는 무엇인가요?

호스팅형 도구로는 Meshy와 Tripo가 선두 올라운더(텍스트 또는 이미지에서 리깅 가능한 텍스처드 메시로)이며, 유료 플랜에서 상업적 권리를 제공합니다. 직접 호스팅할 수 있는 오픈 모델로는 Hunyuan3D 2.1과 마이크로소프트의 TRELLIS.2가 2026년 가장 강력합니다. 최선의 선택은 빠른 호스팅형 도구를 원하는지, 상업적 사용에 유리한 오픈 가중치를 원하는지에 달려 있습니다.

AI로 생성한 에셋을 상업용 게임에 쓸 수 있나요?

가능한 경우가 많지만, 라이선스를 확인하세요. 직접 호스팅하는 오픈 모델이 보통 가장 깔끔합니다(Hunyuan3D는 일부 지역을 제외한다는 점에 유의하세요). 호스팅형 도구는 대개 상업적 권리를 유료 플랜 뒤에 두고, 무료 등급 결과물은 비상업용인 경우가 잦습니다. 항상 모델의 결과물 권리 조건을 확인하고, 플랫폼이 요구하는 경우 AI 콘텐츠임을 밝히세요.

무료 AI 에셋 생성기가 있나요?

많은 도구에 무료 등급이 있지만, 대개 사용량을 제한하고 상업적 권리는 제외합니다. TRELLIS.2, FLUX.2 klein, Qwen-Image, Stable Audio 같은 오픈 모델은 하드웨어만 있으면 상업적 사용에 유리한 라이선스로 직접 무료로 돌릴 수 있습니다. 위 비교표에서 어떤 것이 오픈이고 어떤 것이 호스팅형인지 확인하세요.

AI가 게임 음악과 사운드 이펙트를 만들 수 있나요?

가능합니다. Stable Audio 3.0은 전용 사운드 이펙트 모델을 포함한 오픈 가중치를 제공하고, ACE-Step은 MIT 라이선스로 음악을 생성하며, ElevenLabs는 유료 플랜에서 상업적 권리를 주는 강력한 호스팅형 옵션입니다. 이들은 게임의 전체 사운드스케이프를 위한 음악과 SFX를 모두 포괄합니다.

관련 글

• 게임을 위한 최고의 오픈소스 생성형 AI 모델 — 심층 기술 정리
• 무료 게임 에셋을 찾는 곳 — 미리 만들어진 무료 에셋
• 게임을 위한 최고의 무료 3D 모델 사이트 — 생성 대신 검색
• 게임을 위한 무료 사운드 이펙트와 음악 — 미리 만들어진 오디오
• 게임 에셋 라이선스 설명 — 조건 이해하기

마지막 업데이트: 2026년 6월.

문장 하나를 입력하면 AI가 게임을 만들어 줍니다. 그게 약속이고, 2026년에는 실제로 가능해졌습니다. 하지만 이걸 해내는 도구들은 내부적으로 서로 완전히 다릅니다. 어떤 도구는 브라우저에서 잘 다듬어진 2D 아케이드 게임을 만듭니다. 어떤 도구는 완전히 소유할 수 있는 프로젝트를 내주는 데스크톱 엔진입니다. 어떤 도구는 게임도 만들 수 있는 범용 코드 어시스턴트입니다. 잘못된 도구를 고르면 주말 하나를 통째로 날립니다.

이 가이드는 2026년에 알아둘 만한 AI 게임 생성기들을 비교합니다. 각 도구가 실제로 무엇을 만들어 내는지, 게임을 소유하고 익스포트할 수 있는지, 비용은 얼마인지 다룹니다. 우리 도구가 잘하는 부분과 못하는 부분을 포함해, 각 도구가 어디서 이기는지 솔직하게 쓰려고 했습니다.

"AI 게임 생성기"의 네 가지 종류

대부분의 "최고의 AI 게임 메이커" 목록은 이것들을 뒤섞어 놓기 때문에 헷갈립니다. 실제로는 네 가지 범주가 있습니다.

1. 프롬프트-투-게임 빌더는 설명으로부터 플레이 가능한 게임을 만듭니다. Rosebud, Gameer, Astrocade, Nilo, Cinevva가 여기에 속합니다.
2. 엔진 통합형 AI 에이전트는 기존 엔진 안에 AI 어시스턴트를 추가합니다. GDevelop AI, Buildbox 4, Unity AI가 여기에 해당합니다.
3. 범용 코드 빌더인 Replit 같은 도구는 어떤 웹 앱이든 만들 수 있으니 게임도 만들 수 있지만, 게임 네이티브는 아닙니다.
4. 아이디어 구상 및 에셋 도구인 Ludo.ai 같은 도구는 기획과 에셋 생성을 돕지만 완성된 게임을 만들어 내지는 않습니다.

원하는 범주가 무엇인지 알면 선택지가 빠르게 좁혀집니다.

빠른 추천

• 브라우저에서 가장 빠르게 플레이 가능한 결과: Rosebud 또는 Cinevva.
• 코드를 소유하고 Steam에 출시하고 싶다면: Summer Engine.
• 인터랙티브 픽션과 비주얼 노벨: Gameer.
• 무료이면서 웹 호스팅이 되는 오픈소스: GDevelop AI.
• 프롬프트로 만든 3D 게임을 링크로 즉시 공유: Cinevva 또는 Nilo.
• 이미 Unity나 웹 개발자라면: Unity AI 또는 Replit.

비교표

가격은 대략적인 수치이고 자주 바뀌니 결제 시점에 확인하세요. 무료 티어는 보통 상업적 권리를 제한하니, 판매할 무언가를 출시하기 전에 약관을 확인하세요.

도구별 살펴보기

Rosebud AI

Rosebud는 프롬프트를 브라우저에서 플레이 가능한 게임으로 바꿔 주며 2D에서 가장 강하고, 3D와 복셀 지원도 커지고 있습니다. 내부적으로는 JavaScript(3D는 Three.js, 2D는 Phaser)를 생성하기 때문에 원칙적으로 결과물을 이식할 수 있습니다. 어시스턴트와 대화하며 반복 작업하고, 어시스턴트가 스프라이트와 NPC를 만들어 주며, Rosebud가 호스팅하는 공유 가능한 URL로 게시합니다. 무료 티어는 상업적 권리 없이 주당 몇 개의 프롬프트를 제공하고, 유료 플랜에서 상업적 사용이 열립니다. 2D 링크까지 가장 빠른 경로를 원하는 초보자, 교육자, 잼 참가자에게 가장 좋습니다.

Summer Engine

Summer는 실제 게임을 출시하고 판매하며 모든 것을 소유하고 싶을 때의 선택지입니다. Godot 4를 그대로 대체할 수 있게 자리 잡은, 데스크톱 기반의 AI 네이티브 엔진이라 프로젝트가 표준 Godot 파일(GDScript 또는 C#)이고 종속이 없습니다. 채팅으로 장면과 로직을 설명하면 코드와 에셋을 생성하고, Windows, macOS, Linux, 모바일, 웹, Steam으로 익스포트하면서 수익은 전부 여러분이 가져갑니다. 브라우저 도구와의 절충점이라면, 스토어 출시를 겨냥한 데스크톱 앱이지 즉석 공개 링크는 아니라는 점입니다. Summer를 1위로 꼽는 "최고의 AI 게임 메이커" 정리글 다수를 Summer가 직접 게시한다는 점도 알아두고, 그런 글은 감안해서 받아들이세요.

Gameer

Gameer는 평문 프롬프트로부터 몇 분 만에 코드 없이 영화 같은 인터랙티브 스토리와 비주얼 노벨 게임을 만듭니다. 멀티 에이전트 시스템이 서사, 비주얼, 메커니즘을 처리합니다. 즉시 공유 가능한 링크를 받지만, 게임은 Gameer의 런타임에 종속됩니다. 실시간 액션이나 3D가 아니라 분기형 픽션을 원하는 작가, 교육자, 마케터를 위해 만들어졌습니다.

GDevelop AI

GDevelop는 에디터 내 AI 에이전트를 추가한 무료 오픈소스 엔진입니다. 기능이나 게임 전체를 만들어 달라고 요청하면, 편집 가능한 프로젝트에 이벤트와 동작을 작성해 줍니다. 2D와 커지고 있는 3D를 지원하고, 웹, Android, iOS, 데스크톱으로 익스포트하며, gd.games에서 공유 링크와 함께 무료 공개 호스팅을 제공합니다. AI는 월간 크레딧 한도로 동작하고, 유료 티어에서 더 늘어납니다. 크레딧 한도와 약간의 반복 작업을 감수할 수 있다면 강력한 무료 오픈 옵션입니다.

Replit

Replit의 Agent는 게임 엔진이 아니라 범용 풀스택 빌더이지만, 설명으로부터 웹 게임을 만들어 공개 URL에 배포할 수 있습니다. 스프라이트, 음악, 사운드를 생성하지는 않으므로 에셋은 직접 가져와야 하고, 2D 쪽으로 기웁니다. 이미 AI 코딩 도구를 다루는 데 익숙하고 완전히 자기 통제 아래 웹에서 플레이 가능한 결과를 원하는 사람에게 가장 좋습니다.

Unity AI

Unity는 기존 Muse 제품을 Unity AI로 교체했고, 2026년 5월 기준 오픈 베타입니다. Unity 6 안의 에디터 내 에이전트로, 프런티어 모델을 사용해 C# 코드, 플레이스홀더 에셋, 장면을 생성합니다. 자기 Unity 프로젝트 안에 머물면서 게임을 소유하고, WebGL을 비롯한 여러 타깃으로 익스포트합니다. 문장 하나로 게임을 원하는 초보자가 아니라, 이미 Unity에서 작업하며 AI 지원을 원하는 사람을 위한 것입니다.

Buildbox 4, Astrocade, Nilo

Buildbox 4는 AI 에셋 및 노드 생성을 추가한, 주로 하이퍼캐주얼 모바일용 노코드 엔진입니다. HTML5로 익스포트하지만 엔진에 종속됩니다. Astrocade는 자금이 넉넉한 즉시 공유형 소셜 플랫폼으로, 3D 마케팅에도 불구하고 실제 결과물은 2D 쪽으로 기울고, 강한 종속과 코드 익스포트 부재가 특징입니다. Nilo는 우리가 만드는 것에 가장 가까운 브라우저 기반 AI 3D 도구로, 강력한 Roblox 익스포트 각도와 더 어린 타깃 층을 가지고 있습니다. 현재 무료 베타입니다.

선택하는 법

세 가지 질문을 던져 보세요. 첫째, 3D가 필요한가요, 아니면 2D로 충분한가요? 대부분의 도구는 2D에서 가장 강하고, 프롬프트로부터 믿을 만한 3D를 뽑아내는 것은 소수만 넘는 어려운 관문입니다. 둘째, 코드를 소유하고 익스포트해야 하나요, 아니면 호스팅 링크로 충분한가요? Summer, GDevelop, Unity AI, Cinevva는 모두 프로젝트를 익스포트할 수 있게 해 줍니다(Cinevva는 완성된 게임을 다운로드해 어디에나 호스팅할 수 있게 합니다). Rosebud, Gameer, Astrocade는 즉시 공유 링크에 기댑니다. 셋째, Steam과 앱 스토어에 출시하나요, 아니면 친구들과 링크를 공유하나요? 스토어는 데스크톱 엔진에 유리하고, 링크는 브라우저 도구에 유리합니다.

Cinevva의 위치

솔직하게 말하겠습니다. 시장에서 붐비는 부분은 브라우저 안의 2D입니다(Rosebud, Astrocade, Gameer, Replit). Cinevva는 훨씬 덜 붐비는 자리에 있습니다. 채팅으로 구동되고, 2D와 진짜 3D 게임을 모두 만들며, 실제 Three.js 기반 엔진으로 브라우저에서 플레이 가능하고, 링크로 즉시 공유되며, 다운로드해 어디에나 호스팅할 수 있는 완성된 게임으로 익스포트되고, 텍스트-투-3D, 이미지, 음악, 스카이박스 생성과 CC0 에셋 라이브러리가 기본 내장되어 있습니다. 그 코드 익스포트가 중요한 이유는, 즉시 공유형 경쟁자 여럿(Astrocade, Gameer)이 게임을 자기 런타임에 묶어 두기 때문입니다. 그 교차점에 가장 가까운 도구는 Nilo인데, 3D 에셋을 Roblox로 익스포트하는 쪽으로 기울고 더 어린 층을 겨냥하니, 공유도 하고 다운로드도 할 수 있는 자체 호스팅 웹 게임이 우리가 집중하는 빈틈입니다.

솔직한 단서는, "프롬프트로부터 진짜 3D"가 이 범주에서 가장 어려운 주장이며 리뷰어들이 회의적인 것도 당연하다는 점입니다. 우리 것을 포함해 이런 도구를 공정하게 판단하는 방법은 무언가를 만들어 링크를 공유해 보는 것입니다. 프롬프트로 3D 게임을 무료로 만들어 결과가 어디에 안착하는지 보거나, 빈 상자를 마주하기 싫다면 원클릭 프롬프트로 시작해 보세요.

자주 묻는 질문

2026년 최고의 AI 게임 생성기는 무엇인가요?

도구마다 다른 목표를 위해 만들어졌기 때문에 단 하나의 최고는 없습니다. 2D 브라우저 게임을 빠르게 만들려면 Rosebud가 훌륭합니다. 즉시 공유할 수 있는 3D 브라우저 게임이라면 Cinevva나 Nilo입니다. 소유하고 Steam에 출시할 게임이라면 Summer Engine입니다. 무료 오픈소스라면 GDevelop AI입니다. 2D인지 3D인지, 코드를 소유해야 하는지, 링크를 공유하는지 스토어에 출시하는지를 기준으로 고르세요.

AI가 정말 프롬프트로 완전한 게임을 만들 수 있나요?

작고 캐주얼한 게임, 특히 2D라면 그렇습니다. AI가 이동, 충돌, 물리, 기본 아트를 처리해 주니 아이디어에서 플레이 가능한 상태까지 몇 분 만에 갈 수 있습니다. 더 크거나 더 다듬어진 게임은 여전히 반복 작업과 사람의 설계가 필요하고, 3D는 2D보다 AI가 제대로 해내기 더 어렵습니다. 첫 생성물은 완성품이 아니라, 다듬어 나갈 강력한 출발점으로 여기세요.

AI 게임 생성기로 만든 게임을 제가 소유하나요?

도구에 따라 다릅니다. Summer, GDevelop, Unity AI 같은 엔진 기반 도구는 소유하고 익스포트할 수 있는 실제 프로젝트를 줍니다. 호스팅형 프롬프트-투-게임 플랫폼은 제각각입니다. 코드를 익스포트하게 해 주는 곳도 있고, 게임을 자기 런타임에 묶는 곳도 있고, 상업적 권리를 유료 플랜 뒤에 두는 곳도 많습니다. 무언가를 판매하기 전에 항상 약관을 읽으세요.

AI로 생성한 게임은 무료로 만들 수 있나요?

대부분의 도구에는 시험해 볼 만큼 괜찮은 무료 티어가 있지만, 무료 티어는 보통 생성량을 제한하고 상업적 권리를 제외하는 경우가 많습니다. 상업적으로 게시하거나, 많이 생성하거나, 익스포트하려면 비용을 지불하게 될 것입니다. 위 비교표에 각 도구의 무료 티어와 최저 유료 플랜이 정리되어 있습니다.

관련 글

• AI로 게임 만드는 법 (2026 가이드) — 전체 노코드 워크플로우를 단계별로
• 코딩 없이 3D 브라우저 게임 만드는 법 — 3D에 특화된 경로
• 바이브 코딩 게임: 무엇이고 어떻게 시작하나 — 용어, 워크플로우, 함정
• 원클릭으로 만들 수 있는 AI 게임 프롬프트 — 시도해 볼 출발점
• 2026년 최고의 웹 게임 엔진 — 직접 손으로 만들고 싶다면
• 게임용 최고의 오픈소스 생성형 AI 모델 — AI 에셋 생성을 뒷받침하는 모델들

마지막 업데이트: 2026년 6월.

처음 시작할 때 가장 좋은 엔진은 요금이나 복잡한 코드의 벽 없이 플레이 가능한 게임까지 가장 빨리 데려다주는 엔진입니다. 2026년의 좋은 소식은 가장 강력한 초보자용 선택지들이 완전히 무료라는 점입니다. 코드를 얼마나 쓰고 싶은지에 따라 정리한 추천 목록과, 여기에 더해 새로 등장한 "AI에게 설명하기" 방식을 함께 소개합니다.

시작 지점별 빠른 추천

• 코드는 전혀 싫고, 오늘 게임을 만들고 싶다면: GDevelop, 또는 AI 프롬프트-투-게임 도구.
• 코드를 조금 쓰면서 제대로 배우고 싶다면: Godot.
• JavaScript를 조금 안다면: Phaser.
• 잘 다듬어진 에디터로 비주얼 스크립팅을 하고 싶다면: Construct(무료 등급) 또는 GDevelop.

최고의 무료 엔진

GDevelop

무료 오픈소스이고, 브라우저나 데스크톱 앱으로 실행되며, 코드 대신 비주얼 이벤트 시트로 로직을 만듭니다. 2D를 지원하고 3D도 점점 늘려가고 있으며, 웹, 모바일, 데스크톱으로 익스포트하고 gd.games에서 공유 링크와 함께 무료 호스팅을 제공합니다. 심지어 프롬프트로 기능을 만들어주는 AI 에이전트까지 추가되었습니다. 대부분의 초보자에게 비용 부담 없이 게임을 출시할 수 있는 최고의 노코드 출발점입니다.

Godot

MIT 라이선스로 배포되는 무료 오픈소스이고, 요금이나 매출 상한이 영원히 없습니다. Godot는 2D와 3D를 모두 지원하고, 접근성을 염두에 두고 설계된 부담 없는 스크립팅 언어(GDScript)와 방대한 무료 튜토리얼 라이브러리를 갖추고 있습니다. 현재 버전은 4.7입니다(2026년 6월). 라이선스 걱정 없이 실제 게임 프로그래밍을 배우고 싶다면 최고의 선택이며, 첫 프로젝트부터 완성작 출시까지 여러분과 함께 성장합니다. 한 가지 참고할 점은 C# 프로젝트는 웹으로 익스포트할 수 없으니, 웹이 목표라면 GDScript를 쓰세요.

Phaser

MIT 라이선스 아래 무료인 Phaser는 가장 인기 있는 HTML5 게임 프레임워크로, 가장 큰 커뮤니티와 2D 웹 게임을 위한 가장 많은 튜토리얼을 갖추고 있습니다. 버전 4가 2026년에 출시되었습니다. 코드 우선(JavaScript 또는 TypeScript) 방식이라, 웹 개발을 조금 알고 비주얼 에디터 대신 코드를 쓰며 배우고 싶은 초보자에게 잘 맞습니다.

Construct (무료 등급)

Construct는 코딩 없이 브라우저에서 실행되는 비주얼 이벤트 시트 엔진입니다. 무료 등급으로 2D 게임을 만들어 웹에 퍼블리시할 수 있으며, 프로젝트가 커지면 넘어서게 되는 제한(이벤트와 레이어 수 상한)이 있습니다. 잘 다듬어진 안내형 에디터를 원하는 완전 초보자에게 아주 좋고, 규모가 커질 때만 구독이 필요합니다.

AI / 노코드 방식

새로 등장한 선택지입니다. 게임을 AI 프롬프트-투-게임 도구에 설명하고 대화하며 다듬으면 되고, 설치할 엔진이 없습니다. 아이디어에서 공유 가능한 플레이 게임까지 가장 빠른 길이며, 특히 기존 노코드 도구가 약한 3D에서 강점을 보입니다. AI로 게임 만드는 법과 AI 게임 생성기 비교를 참고하세요.

비교

첫 엔진 고르는 법

너무 깊게 고민하지 마세요. 코드를 얼마나 쓰고 싶은지에 엔진을 맞추고, 작게 시작하세요. 코드가 부담스럽다면 GDevelop로 시작해 이번 주에 작은 게임 하나를 출시해 보세요. 디자인과 함께 프로그래밍도 배우고 싶다면 Godot로 시작해 수많은 초보자 튜토리얼 중 하나를 따라 하세요. 이미 JavaScript를 안다면 Phaser가 자연스럽게 느껴질 겁니다. 그리고 아이디어를 최대한 빨리 플레이 가능한 형태로 보고 싶다면 AI 방식을 먼저 시도한 뒤, 프로젝트가 커지면 코드나 비주얼 엔진으로 옮겨가세요. 초보자가 저지르는 가장 큰 실수는 무거운 프로 엔진을 골랐다가 벅차서 그만두는 것입니다. 간단한 엔진으로 완성한 작은 게임이, 방치된 큰 게임보다 훨씬 많은 것을 가르쳐 줍니다.

자주 묻는 질문

초보자에게 가장 쉬운 무료 게임 엔진은 무엇인가요?

GDevelop가 가장 쉬운 무료 출발점입니다. 노코드(비주얼 이벤트 시트)이고, 브라우저에서 실행되며, 웹에 무료로 퍼블리시됩니다. Construct도 무료 등급이 있어 비슷하게 초보자 친화적입니다. 설정이 아예 필요 없기를 원한다면, AI 프롬프트-투-게임 도구가 설명만으로 플레이 가능한 게임을 만들어 줍니다.

Godot는 초보자에게 좋은가요?

네. Godot는 무료 오픈소스이고, 초보자 친화적인 스크립팅 언어(GDScript)와 방대한 무료 튜토리얼 라이브러리를 갖추고 있습니다. 실제 게임 프로그래밍을 배우고 싶다면 최고의 무료 선택이며, 2D와 3D를 모두 지원합니다. 다만 C# 프로젝트는 웹으로 익스포트할 수 없으니, 브라우저가 목표라면 GDScript를 쓰세요.

게임을 만들려면 코딩을 알아야 하나요?

아니요. GDevelop나 Construct 같은 노코드 엔진은 비주얼 로직으로 게임을 만들 수 있게 해주고, AI 프롬프트-투-게임 도구는 평범한 문장 설명으로 게임을 만들어 줍니다. 코딩은 더 많은 제어를 열어주고 결국 배워둘 가치가 있지만, 코딩 없이도 오늘 진짜 게임을 만들어 퍼블리시할 수 있습니다.

2026년에 어떤 무료 엔진을 배워야 하나요?

코드를 얼마나 쓰고 싶은지로 고르세요. 노코드라면 GDevelop나 AI 도구, 프로그래밍을 배우려면 Godot, JavaScript를 안다면 Phaser입니다. 모두 상업용 게임을 무료로 출시할 수 있습니다. 여러분에게 문턱을 가장 낮춰주는 것으로 시작해 작은 게임 하나를 끝내고, 거기서 한 단계씩 올라가세요.

관련 글

• 2026년 최고의 웹 게임 엔진 — 실력이 늘었을 때 참고할 전체 목록
• 2026년 최고의 2D 게임 엔진 — 첫 게임이 2D라면
• AI로 게임 만드는 법 (코딩 없이) — 노코드 AI 방식
• 코딩 없이 3D 브라우저 게임 만드는 법 — 초보자를 위한 3D
• itch.io에 게임 출시하는 법 — 첫 게임 퍼블리싱

마지막 업데이트: 2026년 6월.

모든 걸 직접 모델링할 필요도, 돈을 낼 필요도 없습니다. 무료로 쓸 수 있는 게임용 3D 모델은 정말 많고, 그중에서도 가장 좋은 건 CC0입니다. 출처 표기 없이 상업적으로 써도 된다는 뜻이죠. 2026년에 북마크해 둘 만한 사이트를 실제 사용 방식에 따라 정리하고, 라이선스도 명확히 짚어드립니다.

빠른 선택 가이드

• 게임 바로 사용, 일관된 스타일, 번거로움 제로: Kenney, Quaternius (둘 다 CC0).
• 사실적인 모델, 텍스처, HDRI: Poly Haven (CC0).
• 가장 다양한 종류, 복잡한 모델: Sketchfab (라이선스 혼합, 각각 확인).
• 로우폴리, Google Poly 아카이브: Poly Pizza, Icosa Gallery (대부분 CC-BY).

CC0 기본 출처 (출처 표기 불필요, 상업용 안전)

Kenney

가장 좋은 시작점입니다. Kenney는 3D 모델, 스프라이트, UI, 오디오에 걸쳐 게임 바로 사용 가능한 에셋 수만 개를 제공하는데, 전부 CC0이고 서로 섞어 쓸 수 있는 일관된 아트 스타일로 되어 있습니다. 모든 게 게임에 맞게 최적화되어 있죠. 빠르게 통일감 있는 룩을 잡고 싶다면 여기서 시작하세요. kenney.nl

Quaternius

귀엽고 양식화된 로우폴리 3D 모델을 전부 CC0로 제공하며, 테마별 팩(캐릭터, 환경, 탈것, 몬스터)과 범용 애니메이션 라이브러리로 정리되어 있습니다. 사랑스러운 로우폴리 감성을 원하는 인디 게임에 딱 맞습니다. quaternius.com

Poly Haven

사실적인 3D 모델, PBR 텍스처, HDRI를 전부 CC0로 제공하고, 여러 해상도와 키 없이 바로 다운로드할 수 있는 API를 갖췄습니다. 에셋이 2,000개가 넘고 계속 늘어나고 있죠. 사실적인 소품, 환경, 조명에 가장 좋습니다. polyhaven.com

대형 라이브러리 (라이선스 혼합, 각각 확인)

Sketchfab

가장 큰 3D 모델 라이브러리로, 수백만 개의 모델과 다운로드 전 3D 미리보기를 제공합니다. 라이선스가 모델마다 다르니 다운로드 가능 + CC0 또는 CC-BY로 필터링하세요. 2026년에 알아둘 만한 한 가지 주의점이 있습니다. Sketchfab 스토어가 Epic의 Fab으로 옮겨갔고, CC-BY와 Fab Standard 콘텐츠만 그쪽으로 이전됩니다. CC0와 그 밖의 Creative Commons 모델은 Sketchfab에서 계속 다운로드할 수 있지만, 서서히 줄어드는 CC0 출처로 여기고 필요한 건 지금 확보해 두세요. sketchfab.com

Poly Pizza와 Icosa Gallery

Google Poly는 2021년에 문을 닫았지만, 그 로우폴리 카탈로그는 살아남았습니다. Poly Pizza는 아카이브된 "Poly by Google" 컬렉션(약 2,294개 모델)과 커뮤니티가 새로 올린 수천 개를 함께 호스팅하고, 비영리 단체 Icosa Gallery가 그 오픈 정신을 이어가고 있습니다. 대부분 CC-BY(제작자 출처 표기 필요)이고 일부는 CC0입니다. Kenney와 Quaternius 룩에 잘 어울리는 빠르고 양식화된 소품에 좋습니다. poly.pizza

Fab (Epic)

Epic의 통합 마켓플레이스로, Unreal Marketplace, Quixel Megascans, Sketchfab 스토어의 후계 서비스입니다. 매력은 1,500개가 넘는 Megascans 스타터 팩이 영구 무료라는 점, 그리고 2주마다 바뀌는 무료 배포입니다. 전체 Megascans 라이브러리는 이제 유료입니다. 각 항목의 라이선스를 확인하세요. fab.com

AI로 모델 생성하기

2026년이면 모델을 검색하는 것보다 생성하는 게 더 빠를 수 있습니다. Meshy와 Tripo 같은 도구는 텍스트나 이미지를 텍스처가 입혀진 3D 메시로 바꿔주고, Hunyuan3D와 TRELLIS.2 같은 오픈 모델은 직접 호스팅할 수 있습니다. 대부분의 호스팅 도구는 상업적 권리를 유료 플랜에 묶어두니 약관을 확인하세요. 전체 개요는 게임용 최고의 AI 에셋 생성기 가이드를 참고하세요. 그리고 Cinevva에는 사진이나 텍스트 프롬프트를 모델로 바꿔주는 3D 모델 생성기가 내장되어 있습니다.

30초 만에 보는 라이선스

• CC0: 퍼블릭 도메인. 상업적 사용, 수정 가능, 출처 표기 불필요. 가장 안전한 선택.
• CC-BY: 상업적 사용 무료지만 제작자 출처를 표기해야 함.
• 로열티 프리: 한 번 결제(또는 무료)하면 사용 건당 요금 없이 쓸 수 있지만, 원본 파일을 재판매할 수는 없음.
• CC-BY-NC / 에디토리얼: 상업적 사용 불가. 판매할 게임에는 쓰지 마세요.

헷갈릴 땐 CC0를 우선하세요. 자세한 내용은 게임 에셋 라이선스 가이드를 참고하세요.

자주 묻는 질문

게임용 무료 3D 모델은 어디서 찾을 수 있나요?

Kenney, Quaternius, Poly Haven이 가장 좋은 시작점이고, 전부 CC0라 출처 표기 없이 상업적으로 쓸 수 있습니다. 더 다양한 걸 원한다면 Sketchfab에 라이선스가 섞인 수백만 개의 모델이 있고, Poly Pizza는 아카이브된 Google Poly 카탈로그를 호스팅합니다. 출시 전에는 항상 개별 모델의 라이선스를 확인하세요.

3D 모델에서 CC0는 무슨 뜻인가요?

CC0는 모델이 퍼블릭 도메인이라는 뜻입니다. 상업용 게임에 쓸 수 있고, 수정할 수 있으며, 제작자를 표기하지 않아도 됩니다. 가장 자유롭고 위험이 낮은 라이선스입니다. 게임 에셋의 주요 CC0 출처는 Kenney, Quaternius, Poly Haven, AmbientCG입니다.

무료 3D 모델을 상업용 게임에 써도 되나요?

대부분 괜찮지만 라이선스에 따라 다릅니다. CC0 에셋은 항상 안전합니다. CC-BY는 제작자 표기가 필요합니다. CC-BY-NC와 에디토리얼 전용 모델은 판매하는 게임에 쓸 수 없습니다. 각 모델의 라이선스를 확인하고, 크레딧에 출처 표기 요건을 남기지 않으려면 CC0를 우선하세요.

대신 AI로 3D 모델을 생성할 수 있나요?

네. Meshy와 Tripo 같은 도구는 텍스트나 이미지로 텍스처가 입혀진 메시를 만들고, Hunyuan3D와 TRELLIS.2 같은 오픈 모델은 직접 호스팅할 수 있습니다. 호스팅 도구의 상업적 권리는 보통 유료 플랜이 필요하니 약관을 확인하세요. AI 생성은 딱 맞는 무료 모델을 찾아 헤매는 것보다 점점 더 빨라지고 있습니다.

관련 글

• 무료 게임 에셋을 찾을 수 있는 곳 — 20곳 이상을 담은 전체 출처 가이드
• Sketchfab vs Poly Haven vs Kenney — 인기 출처 세 곳 정면 비교
• 게임용 최고의 AI 에셋 생성기 — 검색 대신 생성하기
• 게임 에셋 라이선스 설명 — CC0, CC-BY, 그 외
• 게임용 무료 사운드 이펙트와 음악 — 오디오 쪽

마지막 업데이트: 2026년 6월.

오디오는 게임의 느낌을 절반쯤 좌우하는데, 예산이 없어도 충분히 구할 수 있습니다. 음향 효과와 음악 모두 훌륭한 무료 출처가 있지만, 라이선스가 제각각이고 일부 인기 사이트는 비상업용 전용이라 판매할 게임을 조용히 망칠 수도 있습니다. 2026년에 어디를 봐야 하는지, 그리고 정확히 무엇을 게임에 실을 수 있는지 정리했습니다.

가장 안전한 CC0 선택 (출처 표기 불필요, 상업용 안전)

• Kenney 오디오 — 완전 CC0, 출처 표기 없음, 상업용 OK. 게임에 바로 쓸 수 있는 깔끔한 UI 클릭음, 충격음, 레트로/8비트 SFX. 가장 강력한 선택 중 하나입니다. kenney.nl
• Pixabay Music — Pixabay 콘텐츠 라이선스로 무료, 상업용 가능, 출처 표기 없음. 번거로움 없이 쓸 수 있는 좋은 배경 음악과 루프가 있습니다. (파일 자체를 재판매할 수는 없지만, 게임에 사용하는 건 괜찮습니다.) pixabay.com
• Sonniss GDC Game Audio 번들 — 매년 공개되며, 상업용으로 로열티 프리, 출처 표기 없음, 여러 해에 걸친 아카이브에 전문가급 SFX가 수백 기가바이트 쌓여 있습니다. (제약 하나: AI/ML 학습 금지.) sonniss.com
• **Freesound (CC0 필터)**와 OpenGameArt (CC0 항목) — 둘 다 CC0 콘텐츠를 제공하니, 필터로 걸러 쓰면 안전합니다.

음향 효과

Freesound

가장 큰 무료 SFX 라이브러리로, 수십만 개의 사운드가 있습니다. 라이선스가 사운드마다 다르므로(약 72%가 CC0, 나머지는 CC-BY 또는 CC-BY-NC) 파일마다 확인하세요. CC0는 크레딧이 필요 없고, CC-BY는 출처 표기가 필요합니다. 특정한 일회성 효과음과 현장 녹음에 가장 좋습니다. freesound.org

Sonniss와 Kenney

대량으로 구하려면 Sonniss의 GDC 번들이 깔끔한 로열티 프리 라이선스로 스튜디오급 SFX를 제공합니다. 빠르고 통일감 있는 게임 사운드를 출처 표기 없이 쓰려면 Kenney의 CC0 오디오 팩이 완벽합니다. 이 둘만으로도 게임 사운드스케이프 대부분을 안전하게 채울 수 있습니다.

ZapSplat

프리미엄 모델로 운영되는 넓은 SFX 라이브러리입니다. 무료 등급은 개인용과 상업용 모두 무제한이지만 "ZapSplat" 크레딧 표기가 필요합니다. 일부 사운드는 CC0 또는 CC-BY입니다. 유료 Gold 등급은 출처 표기를 없애고 WAV를 열어줍니다. 크레딧을 넣을 수 있을 때 좋은 선택입니다. zapsplat.com

음악

Incompetech (Kevin MacLeod)

CC-BY 4.0로 제공되는 2,000곡 이상의 완성 음악 트랙으로, 필수 출처 표기 문구("Music by Kevin MacLeod... Licensed under Creative Commons: By Attribution 4.0")를 넣으면 무료입니다. 트랙별로 출처 표기가 필요 없는 라이선스를 구매할 수도 있습니다. 다양한 분위기의 완성된 배경 트랙에 가장 좋습니다. incompetech.com

Pixabay Music과 Uppbeat

Pixabay Music은 번거로움 없는 선택입니다. 무료, 상업용, 출처 표기 없음. Uppbeat은 프리미엄 방식으로, 무료 등급(월 10회 다운로드, 출처 표기 필요, 제한된 상업용)과 이런 제한을 없애는 유료 등급이 있습니다. 그래서 판매용 상업 게임에는 업그레이드하지 않는 한 약한 선택입니다. uppbeat.io

Free Music Archive와 OpenGameArt

FMA는 장르를 넘나드는 방대한 카탈로그가 있지만 라이선스가 크게 다양하니(상당수가 비상업용) 트랙마다 신중히 확인하세요. OpenGameArt은 CC0, CC-BY, 또는 GPL로 인디/RPG 음악과 칩튠을 제공합니다(GPL 오디오는 법적으로 까다로우니 다른 걸 우선하세요). freemusicarchive.org

라이선스 함정 주의

인기 있는 두 출처는 상업용 게임에 안전하지 않습니다.

• BBC Sound Effects 아카이브는 무료지만 RemArc 라이선스가 비상업용 전용입니다. 프로토타입과 학생 프로젝트에는 쓰되, 판매하는 게임에는 쓰지 마세요.
• Internet Archive 오디오는 항목마다 크게 다르고, 일부는 권리자 동의 없이 업로드된 것도 있습니다. 항목마다 권리 필드를 확인하세요. 여기서 가장 위험도가 높은 출처입니다.

AI로 오디오 생성하기

SFX와 음악을 직접 생성할 수도 있습니다. Stable Audio(전용 오픈 음향 효과 모델 포함)와 ACE-Step 같은 오픈 모델은 상업 친화적인 라이선스로 사운드와 음악을 다루고, ElevenLabs는 가장 강력한 호스팅 옵션입니다(유료 플랜에서 상업적 권리 제공). 오픈 생성형 AI 모델 가이드에서 이들을 다루며, Cinevva에는 음악 생성이 내장되어 있습니다.

라이선스 빠른 참조

자주 묻는 질문

게임용 무료 음향 효과는 어디서 구하나요?

Freesound가 가장 큰 라이브러리를 갖췄고(라이선스는 사운드마다 다르며 대부분 CC0), Kenney는 출처 표기가 필요 없는 완전 CC0 오디오 팩을 제공하며, Sonniss GDC 번들은 전문가급 로열티 프리 SFX를 대량으로 줍니다. 상업용 게임이라면 CC0나 확실히 로열티 프리인 출처를 우선하고, 파일마다 라이선스를 확인하세요.

게임에 가장 좋은 무료 음악은 무엇인가요?

출처 표기 없는 음악으로는 Pixabay Music이 가장 쉬운 상업용 안전 선택입니다. Incompetech은 크레딧 문구를 넣으면 CC-BY로 2,000곡 이상을 제공합니다. Free Music Archive는 종류가 방대하지만 라이선스가 섞여 있으니 트랙마다 확인하세요. BBC Sound Effects는 라이선스가 비상업용 전용이니 상업용 게임에는 피하세요.

무료 게임 오디오에 크레딧을 꼭 넣어야 하나요?

라이선스에 따라 다릅니다. CC0와 Pixabay 라이선스 오디오는 크레딧이 필요 없습니다. CC-BY(Incompetech 같은)와 무료 등급 ZapSplat이나 Uppbeat은 출처 표기가 필요합니다. CC-BY-NC와 BBC RemArc 라이선스는 상업적 사용을 완전히 금지합니다. 게임에서 출처 표기 요건을 피하려면 CC0를 우선하세요.

AI로 게임 사운드와 음악을 생성해도 되나요?

됩니다. Stable Audio(전용 음향 효과 모델 포함)와 ACE-Step 같은 오픈 모델은 상업 친화적인 라이선스로 오디오를 생성하고, ElevenLabs는 유료 플랜에서 상업적 권리를 주는 강력한 호스팅 옵션입니다. 상업적으로 무언가를 출시하기 전에 모델의 출력 권리 조건을 확인하세요.

관련 글

• 무료 게임 에셋 구하는 곳 — 전체 에셋 가이드
• 게임용 최고의 무료 3D 모델 사이트 — 비주얼 쪽
• 게임 에셋 라이선스 설명 — CC0, CC-BY, 로열티 프리
• 게임용 최고의 오픈소스 생성형 AI 모델 — AI 오디오 생성
• Tone.js 게임 오디오 — 브라우저에서 오디오 재생하기

최종 수정: 2026년 6월.

itch.io에 업로드하는 건 쉽습니다. 어려운 건 플레이되는 것이죠. itch.io는 큰 포털처럼 관객을 알아서 안겨주지 않기 때문에, 플레이는 탄탄한 페이지, 브라우저 플레이 빌드, 개발 일지, 잼, 그리고 직접 끌어오는 트래픽에서 나옵니다. itch.io의 발견 방식이 실제로 어떻게 작동하는지에 기반해, 2026년에 진짜로 성과를 내는 방법을 정리했습니다.

itch.io 발견은 실제로 어떻게 작동하는가

노력의 방향을 잡아줄 몇 가지 사실입니다.

• Popular 정렬은 과거 활동과 최근 활동을 조합한 비공개 알고리즘으로, 최근 활동에 더 큰 가중치를 둡니다. 확인된 입력값은 자연 유입 조회수, 다운로드, 플레이입니다. 어느 하나라도 조작하면 목록에서 제외됩니다.
• Most Recent는 처음 게시할 때 한 번만 노출됩니다. 재게시로 다시 발동시킬 수 없습니다(itch는 게시 날짜를 바꿔주지 않습니다).
• 첫 페이지는 사람이 직접 큐레이션하며, 알고리즘이 아니라 스태프가 손수 고릅니다. 편법으로 올라갈 수는 없지만, 훌륭한 페이지와 실제 반응은 확률을 높여줍니다.
• 색인에 잡히려면 페이지가 공개 상태여야 하고, 커버 이미지가 있어야 하며, 플레이하거나 다운로드할 수 있어야 합니다. 빈 임시 페이지는 색인되지 않고, 새 판매자 계정은 짧은 검토 대기열을 거칩니다.

실전적인 결론은 이렇습니다. itch는 초반에 집중된 진짜 활동과 완성된 페이지를 보상합니다. 잔재주는 보상하지 않습니다.

브라우저에서 플레이할 수 있게 만들기

이건 페이지 안에서 할 수 있는 가장 효과가 큰 조치입니다. HTML5 빌드(index.html이 들어 있는 ZIP)를 업로드해서 사람들이 다운로드 대신 바로 플레이할 수 있게 하세요. 브라우저 플레이 게임은 마찰이 없기 때문에 다운로드 전용 게임보다 훨씬 높은 참여를 얻습니다. itch 창업자도 훨씬 높은 전환율을 언급한 바 있고, 분석 데이터는 브라우저 게임의 참여가 대략 3배, 전체 페이지 조회의 절반 정도가 플레이로 전환되는 경우가 많다고 봅니다. 엔진이 웹으로 내보낼 수 있다면 그렇게 하세요.

페이지를 제대로 만들기

• 커버 이미지: 필수이며 630x500을 권장합니다. 페이지에서 가장 중요한 그래픽이고, 애니메이션 GIF 커버가 지원되며 권장됩니다. 게임의 핵심 재미를 보여주는 움직임을 앞세우세요.
• 스크린샷과 트레일러/GIF: itch는 동영상 임베드(YouTube, Vimeo)를 스크린샷 위에 표시하며, 특히 게임에는 권장됩니다. 설명하지 말고 보여주세요.
• 짧은 설명: 모든 목록에 표시되므로, 명확하고 구체적인 후크로 만드세요.

태그와 메타데이터

자기만의 태그를 만들지 말고 제안된 태그를 쓰고, 동의어를 피하고, 태그를 남발하지 마세요. 남발하면 둘러보기(browse)에서 제외됩니다. 태그는 최대 10개에 장르 하나까지 쓸 수 있습니다. 실제로 테스트한 빌드가 있는 플랫폼(Windows/Mac/Linux)만 체크하세요. 잘못 분류하면 목록에서 제외됩니다.

개발 일지 활용하기

개발 일지를 게시하면 모든 팔로워의 피드와 사이트 전체 개발 일지 피드에 올라가서, 팔로워를 넘어선 곳까지 도달합니다. 팔로워는 또한 새 프로젝트를 출시하거나 세일에 올릴 때도 알림을 받습니다. 그러니 개발 일지를 올리면 팔로워가 늘고, 그 팔로워는 다음 출시 때 알림을 받습니다. 개발 일지를 나중으로 미루는 일이 아니라 반복적인 트래픽과 관객 형성 도구로 다루세요.

게임 잼에 참가하기 (진짜 발견 엔진)

잼은 itch.io에서 단연 가장 큰 자연 발견 동력으로, 잼을 위해 만들어진 게임이 수십만 개에 이릅니다. 잼은 기본 관객, 마감 기한, 그리고 상호성 메커니즘을 줍니다. 다른 참가작에 평점을 매기고 댓글을 달면(그리고 자기 게임을 제출했다면), 댓글 아래에 내 게임 링크가 자동으로 붙어서 플레이를 다시 끌어옵니다. GMTK 같은 큰 잼은 수만 명의 참가자를 모읍니다. 잼이 Popular 알고리즘을 마법처럼 끌어올려 주진 않지만, 다른 방법이 통하지 않을 때 실제 사람들의 눈길을 게임에 끌어옵니다.

플레이를 위한 가격 책정

itch의 가격은 언제나 원하는 만큼 내기 방식입니다. 정해진 가격은 최소값이고 구매자는 더 낼 수 있습니다(쓰인 돈의 약 30%가 최소값 위의 추가금입니다). 플레이를 최대로 늘리려면 무료나 원하는 만큼 내기가 모든 마찰을 없애면서도 팬이 팁을 줄 여지를 남깁니다. HTML5 게임은 결제를 기부 형태로만 받을 수 있다는 점을 유의하세요. 상시 세일은 피하세요. itch는 이를 진짜 세일이 아니라고 보고 색인에서 제외할 수 있습니다.

직접 트래픽 끌어오기 (대부분의 플레이가 여기서 나온다)

itch는 추천 게임을 빠르게 순환시키고 Steam처럼 발견을 오래 유지해 주지 않기 때문에, 진짜 플레이는 외부 트래픽에서 나옵니다.

• 스트리머와 유튜버는 효과가 가장 큰 채널입니다. 크리에이터 한 명이 다른 노력을 몇 달 쏟은 것보다 더 많은 설치를 이끌 수 있고, 이들은 무료 데모를 itch에서 적극적으로 찾아다닙니다.
• 숏폼 영상(TikTok, Reels, Shorts)에 담은 실제 게임플레이 클립은 이제 인디 바이럴의 핵심 동력입니다.
• Reddit(r/IndieGaming, r/playmygame 등)에서는 커뮤니티 글과 자기 홍보의 대략 9대 1 규칙을 지키세요.
• 플레이테스터와 리텐션을 위한 Discord, 그리고 GIF와 함께 올리는 X #screenshotsaturday.

예산 없이 진행하는 더 넓은 플레이북은 예산 없이 인디 게임 홍보하는 법을 참고하세요.

흔한 실수

웹 빌드가 가능한데도 다운로드 전용으로 두기, 약하거나 없는 커버, 트레일러나 GIF 없음, 빈약한 설명, 나쁘거나 남발된 태그, 게시한 뒤 잠수(개발 일지 없음), 알고리즘이나 추천이 알아서 해주길 기대하기, 데모 없음, 지표 조작(목록에서 제외됩니다). 이것들부터 고치세요. 전부 공짜입니다.

자주 묻는 질문

itch.io에서 플레이 수를 어떻게 늘리나요?

브라우저에서 플레이할 수 있는 HTML5 빌드를 업로드하고(다운로드보다 훨씬 높은 참여를 얻습니다), 애니메이션 커버와 트레일러로 탄탄한 페이지를 만들고, 정확한 제안 태그를 쓰고, 개발 일지를 올려 팔로워에게 도달하고, 기본 발견을 위해 게임 잼에 참가하고, 스트리머와 숏폼 영상과 커뮤니티에서 외부 트래픽을 끌어오세요. itch는 잔재주가 아니라 진짜 활동과 완성된 페이지를 보상합니다.

itch.io가 대신 게임을 홍보해 주나요?

별로 그렇지 않습니다. 첫 페이지는 스태프가 손수 큐레이션하고, Popular 정렬은 실제 최근 활동을 기준으로 빠르게 순환합니다. itch는 도구와 기본 관객을 주지만, 지속적인 발견은 당신이 하는 것에서 나옵니다. 플레이 가능한 빌드, 개발 일지, 잼, 그리고 스트리머와 영상과 커뮤니티에서 끌어오는 트래픽이죠.

itch.io에서 웹 게임이 다운로드보다 플레이가 많나요?

네, 상당히 그렇습니다. 브라우저 플레이 게임은 다운로드의 마찰을 없애고, 데이터상 다운로드 전용 게임의 대략 3배 참여를 보이며 페이지 조회 중 상당수가 플레이로 전환됩니다. 엔진이 HTML5로 내보낼 수 있다면, 플레이 가능한 웹 빌드를 게시하는 것이 플레이를 늘리는 단연 최고의 조치입니다.

플레이를 얻으려고 게임 잼에 참가할 가치가 있나요?

아주 그렇습니다. 잼은 itch.io에서 가장 큰 자연 발견 동력입니다. 기본 관객과 마감 기한을 주고, 다른 참가작에 평점을 매기면 내 게임이 자동으로 링크되어 플레이를 끌어옵니다. 알고리즘을 직접 끌어올리진 않지만, 다른 방법으로는 관객이 없을 때 실제 플레이어를 게임에 데려옵니다.

관련 글

• itch.io에서 게임 출시하는 법 — 설정 기초
• 2026년 웹 게임을 게시하기 좋은 곳 — itch.io와 포털 비교
• 예산 없이 인디 게임 홍보하는 법 — 더 넓은 플레이북
• 게임 잼과 해커톤 — 참가할 잼 고르기
• Steam Next Fest 전략 — Steam으로도 가져간다면

마지막 업데이트: 2026년 6월.

몇 년 전만 해도 게임을 만들려면 뭔가 플레이할 수 있는 게 나오기 전에 엔진, 프로그래밍 언어, 아트 파이프라인부터 배워야 했습니다. 2026년에는 게임을 평범한 말로 설명하기만 하면 몇 분 안에 동작하는 버전을 얻을 수 있습니다. 창의적인 결정은 여전히 당신이 내리지만, 이동, 충돌, 물리, 임시 아트, 사운드 같은 반복 작업은 AI가 처리합니다.

이 가이드는 첫 프롬프트부터 퍼블리시된 게임까지 코딩 없이 전 과정을 안내합니다. 예시는 브라우저 기반 AI 게임 생성기를 사용하지만, 이 워크플로는 대부분의 프롬프트-투-게임 도구에 적용됩니다.

무엇이 필요한가

많지 않습니다. 브라우저, 아이디어, 도구 하나면 됩니다. 엔진 설치도, GPU도, 아트도 필요 없습니다. 도구부터 고르고 싶다면 AI 게임 생성기 비교를 보세요. 그냥 바로 시작하고 싶다면 지금 생성기를 열고 아이디어를 입력하면 됩니다.

1단계: 명확하고 작은 아이디어로 시작하기

초보자가 가장 흔히 저지르는 실수는 "멀티플레이어가 되는 오픈월드 RPG"를 프롬프트로 넣는 것입니다. AI 도구는 나중에 확장할 수 있는 작고 구체적인 핵심에서 최고의 결과를 만듭니다. 세 가지를 정하세요.

• 게임의 종류. 플랫포머, 레이싱, 슈터, 퍼즐, 서바이벌, 아늑한 시뮬레이션.
• 당신만의 것으로 만드는 한 가지. 빛나는 효과, 규칙을 살짝 비트는 요소, 배경 설정.
• 목표. 플레이어가 무엇을 하려는가.

"떠 있는 섬들을 가로질러 타이머와 경쟁하는 1인칭 파쿠르 게임"은 "재미있는 3D 어드벤처"보다 훨씬 나은 시작 프롬프트입니다. 앞의 것은 AI에게 만들 형태를 주고, 뒤의 것은 AI가 추측하게 만듭니다.

2단계: 첫 프롬프트 쓰기

한두 문장으로 짧게 유지하세요. 사양서를 쓰는 게 아니라 대화를 시작하는 겁니다. 좋은 첫 프롬프트는 장르, 목표, 느낌을 담습니다.

좁은 원뿔 모양으로만 비추는 손전등, 제한된 탄약, 점점 어려워지는 웨이브가 있는 탑다운 좀비 서바이벌 게임을 만들어 줘.

그런 다음 도구가 만들게 두세요. 종종 완벽하지 않은 플레이 가능한 첫 버전이 나오는데, 그게 바로 원하는 것입니다. 진짜 작업은 반복이기 때문입니다. 빈 입력창이 막막하다면 미리 만들어진 프롬프트에서 시작해 단어 하나만 바꿔 보세요.

3단계: 대화하며 반복하기

게임이 실제로 만들어지는 지점이 여기입니다. 첫 버전을 플레이하고, 가장 거슬리는 한 가지를 찾아, 그 한 가지 변경만 요청하세요. 작고 구체적인 요청이 크고 막연한 요청을 이깁니다.

• "플레이어가 더 빨리 움직이고 더 높이 점프하게 해 줘."
• "적들이 너무 공격적이야, 느리게 하고 체력을 줄여 줘."
• "우측 상단에 점수 카운터를 추가하고 게임오버 화면을 넣어 줘."

한 가지를 바꾸고, 플레이하고, 반복합니다. 변경이 오히려 나빠지게 만들면 되돌리거나 이전 상태로 복원해 달라고 하세요. 코딩이 아니라 연출이라고 생각하세요. 당신은 원하는 결과를 설명하고 그 결과를 판단합니다.

4단계: 필요한 에셋 생성하기

요즘 AI 게임 도구는 아트와 오디오를 필요할 때 생성해 주기 때문에 회색 상자에 갇혀 있지 않아도 됩니다. 도구에 따라 3D 모델, 텍스처, 스프라이트, 음악, 효과음을 요청하거나 내장된 무료 에셋 라이브러리에서 가져올 수 있습니다. 분위기에 맞는 것을 요청하세요. "플레이어에게 로우폴리 로봇 모델을 줘", "경쾌한 신스 음악을 추가해 줘", "사막 스카이박스를 써 줘." 도구에 CC0 에셋 라이브러리가 있다면, 퍼블리시할 계획이 있는 모든 것에 대해 그게 가장 안전한 출처입니다. 무료 게임 에셋 가이드에서 이것들이 어디서 오는지와 라이선스가 어떻게 작동하는지 다룹니다.

5단계: 느낌 다듬기

기술 데모와 게임의 차이는 느낌입니다. 핵심 루프가 동작하고 나면, 플레이어가 실제로 알아채는 것들에 반복 작업을 쓰세요. 반응 좋은 조작감, 뭔가 일어났을 때의 명확한 피드백, 눈에 보이는 목표, 그리고 승리나 패배 상태. 타이틀 화면, 재시작 버튼, 주요 동작에서의 사운드, 난이도 곡선을 요청하세요. 이런 작은 손질들이 게임을 완성된 느낌으로 만듭니다.

6단계: 퍼블리시하고 공유하기

플레이할 수 있게 되면 퍼블리시하세요. 브라우저 기반 도구는 클릭 한 번으로 공유 가능한 링크를 주는데, 이게 피드백을 얻는 가장 빠른 방법입니다. 친구들과 공유하고, 당신의 관객이 모이는 곳에 올리고, 사람들이 어디서 막히거나 그만두는지 지켜보세요. 그 피드백이 다음 반복 라운드입니다. 더 나아가고 싶다면 itch.io 출시 가이드에서 웹 게임을 더 넓은 관객에게 배포하는 방법을 다룹니다.

AI 게임 제작이 잘 되게 하는 팁

• 작게 시작하고, 그다음에 키우기. 기능을 추가하기 전에 작지만 완성된 게임을 먼저 내보내세요. 완성된 작은 게임이 미완성된 큰 게임을 이깁니다.
• 한 번에 하나씩 변경하기. 요청을 묶으면 AI가 헷갈리고 무엇이 효과가 있었는지 알기 어려워집니다.
• 구현이 아니라 결과를 설명하기. "중력을 20으로 설정해"가 아니라 "점프가 붕 뜨는 느낌이야, 더 딱딱 끊기게 해 줘"라고 말하세요.
• 정상 동작하는 버전을 기억해 두기. 큰 변경 전에 현재 상태가 잘 동작한다는 것을 기록해 두면 그 상태로 돌아올 수 있습니다.
• 지루한 부분에 AI 쓰기. 반복 작업과 변형은 AI가 처리하게 두고, 당신은 게임을 당신 것으로 만드는 결정에 시간을 쓰세요.

AI가 잘하는 것과 못하는 것

AI는 아무것도 없는 상태에서 플레이 가능한 프로토타입까지 빠르게 데려다주고, 임시 에셋은 물론 최종 에셋까지 생성하며, 게임의 기계적인 연결 작업을 처리하는 데 정말 뛰어납니다. 크고 시스템이 복잡한 설계, 세밀한 밸런싱, 그리고 일관된 장기적 비전이 필요한 것에는 약한데, 그건 여전히 당신의 몫입니다. 2026년의 현실적인 기대치는 이렇습니다. AI는 주말치 세팅을 오후 반나절로 압축해 주고, 신뢰할 만한 결과는 방대한 게임보다는 작거나 중간 규모의 게임에 몰려 있습니다.

자주 묻는 질문

코딩 경험이 전혀 없어도 정말 게임을 만들 수 있나요?

네. 2026년의 프롬프트-투-게임 도구는 평범한 말로 된 설명에서 코드, 아트, 로직을 대신 생성해 주기 때문에, 코드를 한 줄도 쓰거나 읽지 않고도 플레이 가능한 게임을 만들고 퍼블리시할 수 있습니다. 당신은 원하는 것을 설명하고 결과를 다듬으면서 게임을 연출합니다.

AI로 게임을 만드는 데 얼마나 걸리나요?

간단하고 플레이 가능한 게임은 몇 분에서 한 시간이면 됩니다. 아트, 사운드, 메뉴, 난이도 곡선까지 갖춘 작지만 잘 다듬어진 게임은 오후 반나절에서 주말 동안의 반복 작업에 가깝습니다. 더 크거나 복잡한 게임은 여전히 시간이 더 걸리는데, 작업의 무게가 세팅에서 설계와 다듬기로 옮겨 가기 때문입니다.

AI는 어떤 종류의 게임을 만들 수 있나요?

AI는 작고 캐주얼한 게임을 가장 잘 다룹니다. 플랫포머, 러너, 아케이드 슈터, 퍼즐, 레이싱, 서바이벌, 아늑한 시뮬레이션 같은 것들이요. 브라우저 도구는 2D와 3D를 모두 할 수 있지만, 2D가 더 안정적인 편입니다. 대형 RPG나 전략 게임처럼 크고 시스템이 복잡한 게임은 여전히 깔끔하게 생성하기 어렵고 사람의 연출이 많이 필요합니다.

AI로 게임을 만들려면 돈을 내야 하나요?

대부분의 도구에는 게임을 만들고 시험해 보기에 충분한 무료 등급이 있습니다. 보통 더 무거운 생성, 상업적 권리, 또는 익스포트를 원할 때 비용을 냅니다. AI 게임 생성기 비교에서 무료 등급과 가격을 나란히 정리했습니다.

AI로 만든 게임을 판매할 수 있나요?

대체로 가능하지만 두 가지를 확인하세요. 도구의 상업적 이용 약관(일부는 상업적 이용을 유료 플랜 뒤에 두기도 합니다)과 생성했거나 가져온 에셋의 라이선스입니다. 많은 플랫폼은 AI로 생성된 콘텐츠를 밝히도록 요구하기도 합니다. 안전하게 가려면 CC0 에셋과 도구의 상업 등급을 고수하세요.

관련 글

• 2026년 최고의 AI 게임 생성기 — 먼저 알맞은 도구 고르기
• 코딩 없이 3D 브라우저 게임 만드는 방법 — 3D에 특화된 안내
• 바이브 코딩 게임: 무엇이고 어떻게 시작하는가 — 프롬프트 기반 제작의 사고방식
• 클릭 한 번으로 만들 수 있는 AI 게임 프롬프트 — 시작점
• 무료 게임 에셋 찾는 곳 — 게임을 위한 아트와 오디오
• itch.io에 게임 출시하는 방법 — 플레이어 모으기

마지막 업데이트: 2026년 6월.

멀티플레이어는 작은 게임을 널리 퍼지게 만드는 기능이고, 2026년에는 직접 데이터 센터를 돌리지 않고도 브라우저 게임에 이 기능을 넣을 수 있습니다. 어려운 부분은 플레이어를 연결하는 게 아니라, 게임을 동기화하고 공정하게 유지하는 겁니다. 이 가이드는 중요한 선택들(전송 방식, 서버 모델, 넷코드)과 이걸 다룰 만하게 만들어 주는 도구들을 다루고, 그다음에 합리적인 출발 스택을 알려 드립니다.

먼저, 솔직하게 범위를 잡으세요

멀티플레이어 난이도는 게임이 얼마나 빠르고 경쟁적인지에 따라 급격히 올라갑니다.

• 쉬움: 턴제 게임(카드, 보드게임), 2~8명의 작은 방, 공유 커서, 로비, 채팅, 캐주얼 협동. 순수 WebSocket이나 백엔드가 필요 없는 도구면 충분합니다.
• 어려움: 빠른 실시간 액션(슈터, .io 이동), 동시 접속자가 많은 경우, 그리고 치팅이 문제가 되는 경쟁적인 게임 전부. 이런 건 권위 있는 서버, 예측, 그리고 세심한 넷코드가 필요합니다.

쉬운 쪽부터 시작하세요. 잘 돌아가는 턴제나 작은 방 게임 하나가 어려운 문제로 넘어가기 전에 전체 파이프라인을 가르쳐 줍니다.

전송 방식: 데이터가 오가는 길

• WebSocket이 현실적인 기본값입니다. TCP 기반이고, 양방향이며, 성숙했고, 어디서나 지원됩니다. 유일한 약점은 head-of-line 블로킹입니다. 패킷 하나가 유실되면 그 뒤의 모든 게 멈추는데, 이게 빠른 액션 게임에는 좋지 않습니다. 대부분의 게임은 WebSocket으로 출시하세요.
• WebRTC는 UDP 같은 데이터 채널을 나릅니다(head-of-line 블로킹 없음). 빠른 액션이나 피어 투 피어에 좋지만, 설정이 훨씬 복잡합니다(시그널링, STUN/TURN). P2P가 필요하거나 릴레이 서버를 피해야 할 때만 손을 대세요.
• WebTransport는 더 새로운 선택지입니다(HTTP/3 + QUIC, UDP 방식의 데이터그램). 앞으로 향하는 방향이지만, 2026년에도 브라우저 지원이 아직 자리를 잡는 중이라, 오늘 출시하려는 초보자가 단독 전송 방식으로 쓰기엔 안전하지 않습니다.

경험칙: 지금 출시하려면 WebSocket, 나중에 필요하면 WebTransport, P2P나 미디어에는 WebRTC.

서버 모델: 무슨 일이 일어났는지 누가 결정하나

• 권위 있는 서버: 클라이언트가 입력을 보내면 서버가 시뮬레이션을 돌리고 결과를 브로드캐스트합니다. 경쟁적인 게임의 표준인데, 서버가 자연스럽게 안티치트 경계선이 되기 때문입니다. 클라이언트를 절대 믿지 마세요.
• 피어 투 피어: 운영 비용은 싸지만 치팅을 막기 어렵고 연결이 불안정합니다. 캐주얼 협동이나 신뢰할 수 있는 작은 로비에는 괜찮습니다.

작은 게임이라도 권위 있는 서버는 "진실의 원천"을 단순하게 유지해 줍니다. 아래 도구 대부분이 이 모델을 기본값으로 씁니다.

넷코드 기초 (필요할 때만)

빠른 실시간 게임에서는 있는 그대로 상태를 동기화하면 렉이 느껴집니다. Gabriel Gambetta의 고전 시리즈에 잘 설명된 표준적인 해결책은 이렇습니다.

• 클라이언트 예측: 클라이언트가 서버 왕복을 기다리지 않고 입력을 즉시 적용해, 움직임이 즉각적으로 느껴집니다.
• 서버 조정(reconciliation): 권위 있는 상태가 도착하면, 클라이언트가 대기 중이던 입력들을 다시 적용해서 어긋난 부분을 바로잡습니다.
• 엔티티 보간(interpolation): 다른 플레이어를 아는 상태들 사이에서 약간 과거 시점으로 렌더링해 움직임을 부드럽게 만듭니다.
• 랙 보상(lag compensation): 서버가 총알이 발사된 순간에 대상이 있던 위치로 되감아, 명중 판정이 공정하게 처리됩니다.

이걸 처음부터 만들지 마세요. 움직임이 실제로 나쁘게 느껴질 때만 넣으세요. 턴제나 느린 게임에서는 그럴 일이 없습니다.

2026년 도구 지형

추천하는 초보자 스택

2026년 작은 실시간 브라우저 게임을 위해서라면 이렇게 하세요.

• 전송 방식: WebSocket(지금 바로 쓸 수 있는 호환성).
• 서버 모델: 작은 게임이라도 권위 있는 서버. 그래야 치팅과 "진실의 원천"이 단순하게 유지됩니다.
• 프레임워크: Colyseus. MIT 라이선스에 셀프 호스트는 무료고, 방, 매치메이킹, 자동 상태 동기화를 기본으로 제공하며, 서버를 직접 돌리고 싶지 않을 땐 매니지드 클라우드(월 약 $15부터)도 있습니다. 캐주얼 게임에 백엔드를 아예 안 두고 싶다면 Playroom이 더 빠른 선택지고, 이미 Cloudflare를 쓰고 있다면 PartyKit이나 Durable Objects가 자연스럽게 맞습니다.
• 넷코드: 예측 없이 시작하세요. 움직임이 렉으로 느껴지기 시작할 때만 Gambetta 스타일의 예측과 보간을 넣으세요.

자주 묻는 질문

멀티플레이어 브라우저 게임을 만드는 가장 쉬운 방법은?

Colyseus 같은 프레임워크나 Playroom 같은 백엔드 없는 도구를 통해 WebSocket으로 턴제나 작은 방 게임부터 시작하세요. 이런 도구들이 방, 참여, 상태 동기화를 대신 처리해 주기 때문에, 넷코드를 짜거나 직접 서버를 돌리지 않고도 잘 돌아가는 멀티플레이어 게임을 출시할 수 있습니다. 빠른 실시간 액션은 더 단순한 걸 먼저 출시한 뒤로 미루세요.

내 게임에는 WebSocket을 써야 할까요, WebRTC를 써야 할까요?

대부분의 게임은 WebSocket입니다. 단순하고, 성숙했고, 어디서나 지원됩니다. WebRTC는 피어 투 피어 연결이 필요하거나 빠른 액션을 위해 가장 낮은 지연 시간이 필요할 때만 쓰세요. 설정이 훨씬 복잡하니까요. WebTransport는 유망한 미래의 선택지지만 2026년에도 브라우저 지원이 아직 자리를 잡는 중입니다.

멀티플레이어에 내 서버가 꼭 필요한가요?

꼭 그렇진 않습니다. Colyseus Cloud, Playroom, PartyKit, Photon 같은 매니지드 도구가 실시간 부분을 대신 호스팅해 줍니다. 완전한 통제를 원한다면 Colyseus나 Nakama 같은 오픈 소스 프레임워크를 직접 셀프 호스트할 수도 있습니다. 작은 게임이라면 매니지드 서비스가 가장 빠른 길이고, 대개 무료거나 저렴하게 시작할 수 있습니다.

멀티플레이어 게임에서 치팅을 어떻게 막나요?

권위 있는 서버를 쓰세요. 클라이언트는 자기 입력만 보내고, 실제로 무슨 일이 일어나는지는 서버가 모든 걸 검증하며 결정합니다. 게임의 결과를 클라이언트에게 절대 맡기지 마세요. Colyseus, Nakama, Photon 같은 프레임워크가, 특히 경쟁적인 게임에서, 서버 권위 모델을 기본값으로 두는 이유가 바로 이것입니다.

관련 글

• 2026년 최고의 웹 게임 엔진 — 당신의 멀티플레이어 게임이 돌아갈 엔진
• 초보자를 위한 최고의 무료 게임 엔진 — 어디서 시작할까
• WebSocket 멀티플레이어 기초 — 직접 해 보는 입문
• itch.io에 게임 출시하는 법 — 멀티플레이어 게임 배포하기

마지막 업데이트: 2026년 6월.

브라우저용 2D 게임에서는 서로 다른 강점을 가진 두 엔진이 선두를 달립니다. 가장 인기 있는 HTML5 프레임워크인 Phaser, 그리고 가장 작고 로딩이 빠른 웹 빌드를 만드는 엔진인 Defold입니다. 둘은 서로 다른 개발자에게 맞습니다. 어느 쪽을 고를지 돕기 위해 2026년 기준 비교를 준비했습니다.

빠른 결론

• 가장 작고 로딩이 빠른 웹 빌드와 잘 다듬어진 올인원 에디터: Defold.
• 가장 큰 커뮤니티, 가장 많은 튜토리얼, 코드 우선 JavaScript 프레임워크: Phaser.

둘 다 무료입니다. 진짜 선택 기준은 워크플로(시각적 에디터 vs 코드 프레임워크), 언어(Lua vs JavaScript), 그리고 로딩 시간과 커뮤니티가 얼마나 중요한지입니다.

비교

Phaser 4

Phaser는 가장 인기 있는 HTML5 게임 프레임워크이고, 4.0 버전은 2026년 4월에 안정 버전으로 출시됐습니다(4.2 같은 포인트 릴리스가 빠르게 뒤따랐습니다). WebGL2 렌더러를 바닥부터 새로 작성하면서 노드 기반 아키텍처를 새로 도입했고, 익숙한 v3 API는 그대로 유지했습니다. JavaScript나 TypeScript로 코드를 쓰면 물리, 입력, 오디오, 씬, 에셋 로딩을 기본으로 얻습니다. 프레임워크 자체는 작지만(약 500 KB), 최종 크기는 여러분의 에셋에 따라 달라집니다. 가장 큰 장점은 거대한 커뮤니티, 산더미 같은 튜토리얼과 예제, 그리고 여러분이 완전히 제어하는 표준 웹 코드를 작성한다는 점입니다. 참고로 Phaser 4는 WebGPU가 아니라 WebGL2 엔진입니다. WebGPU는 아직 출시된 기능이 아니라 미래를 위한 기반 작업입니다.

Defold

Defold는 원래 King(Candy Crush)에서 나왔고, 작고 로딩이 빠른 웹 게임을 위해 만들어졌습니다. 빈 HTML5 빌드가 약 1.06 MB이고 기본적으로 WebAssembly를 사용해, 인기 웹 게임을 다룬 연구들에서 가장 로딩이 빠른 엔진 중 하나로 꼽힙니다. 완전한 패키지로 제공됩니다. 내장 에디터, 씬 도구, 그리고 Poki 같은 플랫폼으로의 원클릭 퍼블리싱까지 포함됩니다. 최신 안정 릴리스는 1.12.4(2026년 5월)이고, 로열티 없이 무료입니다. 단점은 Phaser보다 작은 커뮤니티와 Lua 스크립팅 및 Defold의 컴포넌트 모델을 익혀야 하는 학습 곡선입니다. 주로 2D 엔진이지만 3D 기능을 적극적으로 추가하고 있습니다.

어떻게 고를까

이미 JavaScript를 알고, 가장 많은 튜토리얼과 도움을 원하며, 자신만의 툴체인을 직접 조립하는 걸 좋아한다면 Phaser를 고르세요. 가장 작고 로딩이 빠른 빌드, 잘 다듬어진 올인원 에디터, 내장 퍼블리싱을 원하고 Lua를 배우는 게 괜찮다면 Defold를 고르세요. 로딩 시간이 중요한 모바일 웹 게임이라면 Defold가 확실히 유리하고, 학습과 커뮤니티 지원이라면 Phaser를 이기기 어렵습니다.

PixiJS, Construct, GDevelop까지 포함한 더 넓은 비교가 궁금하다면 2026년 최고의 2D 게임 엔진을 참고하세요.

자주 묻는 질문

2D 웹 게임에는 Phaser와 Defold 중 어느 쪽이 나은가요?

둘 다 훌륭하고, 서로 다른 개발자에게 맞습니다. Phaser는 가장 큰 커뮤니티와 가장 많은 학습 자료를 갖춘 코드 우선 JavaScript 프레임워크입니다. Defold는 내장 에디터를 갖추고 가장 작고 로딩이 빠른 웹 빌드를 만드는 완전한 엔진입니다. 커뮤니티와 JavaScript를 원하면 Phaser, 로딩 시간과 올인원 워크플로를 원하면 Defold를 고르세요.

어느 쪽이 더 작고 로딩이 빠른 웹 빌드를 만드나요?

Defold입니다. 빈 HTML5 빌드가 약 1.06 MB이고 WebAssembly를 사용해, 웹 게임에서 가장 로딩이 빠른 엔진 중 하나입니다. Phaser의 프레임워크는 약 500 KB지만, 이는 전체 빌드가 아니라 프레임워크이고 실제 크기는 여러분의 에셋에 크게 좌우됩니다. 로딩 시간이 민감한 게임이라면 Defold가 유리합니다.

Phaser와 Defold는 WebGPU를 지원하나요?

2026년 기준으로 출시된 기능으로는 아닙니다. Phaser 4는 WebGL2로 재작성됐고 WebGPU는 미래를 위한 기반 작업일 뿐입니다. Defold의 HTML5 백엔드는 WebGL이고 WebGPU 작업은 실험 단계입니다. 2D 게임에서는 이 점이 거의 중요하지 않습니다. 일반적인 2D 렌더링에는 WebGL2로도 충분하고 남습니다.

Phaser와 Defold는 상업용 게임에 무료인가요?

네. Phaser는 MIT 라이선스로 무료이고, Defold는 로열티나 매출 기준 없이 무료이자 오픈소스입니다. 어느 쪽도 상업용 게임 출시에 요금을 받지 않습니다. 다만 Phaser는 별도의 선택형 에디터 제품을 판매합니다.

관련 글

• 2026년 최고의 2D 게임 엔진 — 2D 분야 전체
• 2026년 최고의 웹 게임 엔진 — 2D와 3D를 함께
• 초보자를 위한 최고의 무료 게임 엔진 — 어디서 시작할지
• itch.io에 게임 출시하는 방법 — 완성한 2D 게임 퍼블리싱

최종 수정: 2026년 6월.

게임을 마케팅하는 데 광고비가 꼭 필요한 건 아닙니다. 필요한 건 시간, 명확한 훅, 그리고 일찍 시작하는 것입니다. 2026년의 냉정한 진실은 문제가 수요가 아니라 발견이라는 점입니다. 2024년 Steam에는 약 19,000개의 게임이 출시됐지만 대부분은 의미 있는 판매에 도달하지 못했습니다. 다행인 건 인디에게 효과가 있는 채널 대부분이 무료라는 점이죠. 그 채널들을 어떻게 쓰는지 정리했습니다.

Steam 페이지부터 시작하세요 (Steam에 낸다면)

게임이 Steam과 조금이라도 연관된다면, 할 수 있는 가장 가치 있는 무료 작업은 "출시 예정(Coming Soon)" 페이지를 일찍 올리는 것입니다. 출시 6개월 이상 전에 페이지를 올린 게임은 마지막 달까지 미룬 게임보다 훨씬 더 많이 팔렸습니다. 위시리스트는 만료되지 않으니, 스크린샷 몇 장과 짧은 클립만 준비되면 곧바로 페이지를 올리세요.

위시리스트가 실제로 하는 일은 이렇습니다. 위시리스트에 담은 사람은 출시 시점과 할인 때마다 알림을 받고, 이는 쌓인 관심을 출시 첫날 판매 급증으로 바꿉니다. 또 출시 마지막 주에 "인기 출시 예정(Popular Upcoming)" 탭을 밀어주는 역할도 하죠. 출시가 유효하다고 볼 수 있는 대략적인 최소선은 약 7,000개의 위시리스트입니다. 마법 같은 숫자는 아니고, 그 주에 상위 출시작이 된다는 의미일 뿐입니다. 스토어 페이지도 제대로 채우세요. 정확한 태그(Steam은 태그로 분류합니다)와 더 많은 지원 언어는 둘 다 Steam이 당신을 노출하는 빈도를 높여줍니다.

Next Fest 데모 루프

Steam Next Fest는 가장 큰 무료 위시리스트 이벤트지만, 관객을 새로 만들어주기보다 이미 있는 관객을 증폭시킵니다. 얻게 되는 위시리스트는 당신이 데려온 위시리스트에 강하게 비례하니, 페스트 전에 관객을 쌓은 다음 그 흐름을 타세요. 좋은 데모-위시리스트 전환율은 약 16-20%입니다.

스스로 팔리는 게임을 만드세요

가장 큰 마케팅 결정은 어떤 마케팅보다도 먼저 일어납니다. 바로 장르와 콘셉트죠. 콘셉트가 강렬한 게임은 첫 스크린샷부터 퍼져나가고, 사람들의 흥미를 끄는 데 한두 문장이면 충분합니다. 클립 몇 초 안에 왜 이 게임이 흥미로운지 보여주지 못하면 시장은 그냥 스크롤하며 지나갑니다. 그러니 훅을 앞세우세요. 트레일러와 클립은 첫 몇 초 안에 흥미로운 지점에 도달해야 하고, 기능 나열이 아니라 장르, 훅, 콘텐츠 순으로 보여줘야 합니다.

2026년에 효과가 있는 무료 채널

• 숏폼 영상(TikTok, Reels, YouTube Shorts)은 가장 레버리지가 큰 무료 채널입니다. 알고리즘이 당신을 팔로우하지 않는 사람에게도 클립을 밀어주기 때문이죠. 자연 도달이 줄어든 X와는 다릅니다. 클립 하나가 트윗을 훨씬 앞지를 수 있습니다. 솔직하게 짚어둘 점 하나는, 2025-2026년 들어 숏폼 영상의 자연 도달이 더 어려워졌다는 겁니다. 그러니 꾸준히 올릴 각오를 하고, 클릭 전환도 잘되는 YouTube Shorts를 안정적인 선택지로 삼으세요.
• 개발 일지, 트레일러, GIF, 캡슐 아트: 반복 노출은 위시리스트로 이어지는 친숙함을 쌓고, 꾸준한 클립은 어떤 훅이 먹히는지 무료로 테스트하는 역할도 겸합니다.
• Reddit: 관련 서브레딧(r/IndieGaming, r/IndieDev, r/indiegames, r/playmygame, 그리고 틈새 서브들)에 올리되, 대략 10대 1 규칙을 지키세요. 게시물 열 개 중 하나 정도만 직접적인 게임 홍보여야 합니다. 스팸성 자기 홍보는 밴으로 이어집니다.
• Discord: 서버는 관심 있는 플레이어를 계속 데워두고, 플레이테스터를 확보해주며, 출시 때 나타날 코어 팬층을 만들어줍니다.

예산 없이 하는 언론과 스트리머 대응

이제 스트리머와 유튜버가 전통적인 언론보다 인디 발견을 더 안정적으로 이끌고, 잘 맞는 크리에이터 두어 명이 당신의 모든 언론 아웃리치를 합친 것보다 나은 성과를 내기도 합니다. 이들은 무료 데모를 적극적으로 찾아다닙니다. 도달 범위보다 타깃팅이 중요합니다. 당신의 장르와 관객이 맞는 크리에이터를 골라, 왜 그들을 골랐는지 알려주세요.

언론용 피치는 짧게 유지하세요(대부분의 기자는 200단어 미만을 선호합니다). 훅, 장르, 프레스 킷 링크, 트레일러, 키를 담고, 개인화하세요. 팩트시트, 고해상도 스크린샷, 트레일러, 로고를 담은 한 페이지짜리 프레스 킷을 올려두세요. 당신이 없애주는 마찰 하나하나가 확률을 높입니다. 리뷰용 사본은 출시 약 2주 전에 보내고, 스트리머에게는 출시 약 1주 전에 키를 주세요. 가장 큰 아웃리치 실수는 누군가 관심을 보인 뒤 침묵해 타이밍을 놓치는 것입니다.

현실적인 기대치

기준선은 냉정합니다. 2024년에 출시된 Steam 게임의 중앙값은 겨우 수백 달러의 매출을 올렸고, 매출은 승자독식 구조입니다. 하지만 그건 수요 문제가 아니라 발견 문제입니다. 이제 인디는 Steam 매출과 판매량의 대략 절반을 차지합니다. 관객은 어마어마하게 크고, 당신이 할 일은 발견될 수 있게 되는 것입니다. 가장 흔한 실수는 조용히 만들다가 마지막 주에 마케팅을 시작하는 것입니다. 완전한 침묵은 완벽하지 않은 게임을 보여주는 것보다 더 위험합니다.

예산 없는 타임라인

• 6-12개월 전: Steam "출시 예정" 페이지를 올리고, 클립과 개발 일지를 올리기 시작하고, Discord를 키우기 시작하세요.
• 3-6개월 전: 꾸준한 숏폼 영상, 위시리스트 수집, Next Fest 준비.
• 4-6주 전: 언론과 크리에이터 아웃리치, 트레일러와 프레스 킷 마무리.
• 출시 주간: Reddit, 소셜, 언론을 같은 날 아침에 맞춰 진행하고, 스트리머에게는 일주일 전에 키를 주세요.

자주 묻는 질문

돈 없이 인디 게임을 어떻게 마케팅하나요?

일찍 시작하고 무료 채널에 기대세요. 몇 달 전에 Steam 페이지를 올려 위시리스트를 모으고, 훅을 담은 숏폼 영상 클립을 올리고, 개발 일지를 쓰고, 관련 Reddit과 Discord 커뮤니티에 공유하고, 스트리머와 작은 언론사에 피치하세요. 핵심은 마케팅 예산이 아니라 오랜 시간의 꾸준함과 명확하고 빠른 훅입니다.

Steam 출시 전에 위시리스트가 몇 개 필요한가요?

마법 같은 숫자는 없지만 대략적인 최소선은 약 7,000개이고, 7,000-10,000개면 인기 출시 예정 탭을 노려볼 만합니다. 많을수록 좋습니다. 위시리스트는 알림을 통해 출시 첫날 판매로 전환되니까요. 더 깊은 요점은 그 주의 상위 출시작 중 하나가 되는 것이고, 이는 대부분 페이지와 마케팅을 일찍 시작하는 데서 나옵니다.

2026년 인디 게임에 가장 좋은 무료 마케팅 채널은?

실제 게임플레이를 담은 숏폼 영상(TikTok, Reels, YouTube Shorts)입니다. 알고리즘이 팔로우하지 않는 사람에게도 클립을 밀어줘서, 기존 관객 없이도 도달을 얻을 수 있기 때문이죠. 스트리머와 유튜버도 레버리지가 매우 큽니다. 숏폼 영상의 자연 도달은 몇 년 전보다 어려워졌으니, 한 번의 바이럴 대박을 기대하기보다 꾸준히 올리세요.

가장 큰 인디 마케팅 실수는?

조용히 만들다가 마지막 주에 마케팅을 시작하는 것입니다. 마케팅은 위시리스트와 관객을 모으는 데 몇 달의 리드 타임이 걸립니다. 그래서 훌륭한 게임이라도 위시리스트가 0인 상태로, 트레일러도 없고 스토어 페이지도 부실한 채 냉정하게 출시되면 묻혀버립니다. 완벽하지 않더라도 게임을 일찍 보여주고, 출시 훨씬 전부터 관심을 모으기 시작하세요.

관련 글

• Steam Next Fest 전략 — 데모와 위시리스트 이벤트를 깊이 있게
• 인디 게임을 위한 Kickstarter — 크라우드펀딩 방식을 택한다면
• itch.io에서 게임 출시하는 법 — itch에서 출시하기
• itch.io에서 플레이 수 늘리는 법 — 웹 게임 트래픽 끌어오기
• 2026년 웹 게임을 게시하기 좋은 곳 — 웹 게임을 어디에 올릴까

최종 수정: 2026년 6월.

웹 게임을 다 만들었습니다. 이제 뭘 해야 할까요? 어디에 게시하느냐에 따라 얼마나 많은 사람이 플레이하는지, 수익을 얻는지, 얼마나 많은 통제권을 유지하는지가 달라집니다. 플랫폼은 즉시 무료로 셀프 게시할 수 있는 곳부터, 수백만 명의 플레이어를 거느리고 문턱이 높은 큐레이션 포털까지 다양합니다. 실제로 중요한 트레이드오프와 함께 2026년 정리를 소개합니다.

비교

두 대형 포털에 관한 참고: Poki와 CrazyGames는 관객이 가장 크지만 문턱이 가장 높고 SDK가 필수입니다. itch.io는 자유도가 가장 높고 수익 배분이 가장 좋지만 트래픽은 직접 끌어와야 합니다. Kongregate는 건너뛰세요. 2020년에 신규 게임 접수를 중단했고 지금은 아카이브 상태입니다.

먼저 셀프 게시: itch.io

대부분의 인디에게 itch.io는 기본 출발점입니다. HTML5 빌드(index.html이 담긴 ZIP)를 업로드하면 iframe에 임베드되고, 승인 심사 없이 몇 분 만에 라이브됩니다. 수익 배분율을 직접 설정하고(기본값은 개발자에게 90%), 유료로 팔거나 후원을 받거나 무료로 풀 수 있습니다. 함정은 itch 자체가 지속적인 트래픽을 많이 안겨주지는 않는다는 점입니다. 플레이어는 직접 끌어와야 합니다. 이 부분은 itch.io에서 플레이 수 늘리는 법 가이드에서 다루고, 기본기는 itch.io 출시 가이드에서 다룹니다.

대형 포털: CrazyGames와 Poki

수천만 명의 내장 관객을 원한다면 캐주얼 포털이 답이지만, 선별적입니다.

• CrazyGames(월간 약 3,500만 명)는 HTML5/WebGL 게임을 받습니다. 기본 등록에는 요구 사항이 거의 없지만, 수익화가 있는 정식 출시에는 SDK와 QA 통과가 필요합니다. 여기에는 광고 차단기 대응과 바로 게임플레이로 진입하는 것도 포함됩니다. 지급은 €100부터 시작합니다.
• Poki(월간 약 1억 명)는 가장 엄격합니다. 플레이테스트가 있는 다단계 파이프라인으로, 품질, 플레이어 적합성, 기술적 완성도를 기준으로 게임을 심사합니다. SDK가 필수이고, 수익 조건은 누가 플레이어를 데려오느냐에 달려 있습니다(직접 데려오면 100%, Poki가 데려오면 50%).

이들은 다듬어지고 고도로 최적화된 캐주얼 게임에 적합하며, 이들의 프로세스를 거치는 것은 실제로 만만치 않은 작업입니다.

커뮤니티 플랫폼: Newgrounds, GameJolt, gd.games

• Newgrounds는 커뮤니티 중심으로, 포털 투표 시스템과 광고 수익 배분이 있습니다. 무료 브라우저 게임과 아트/애니메이션 계층에 좋습니다.
• GameJolt은 마켓플레이스 수수료를 최대 10%로 제한하며, 팔로우와 팬층 구축을 중심으로 설계되어 있습니다.
• gd.games는 GDevelop 사용자에게 세션 기반 광고 수익과 에디터에서의 원클릭 게시가 가능한 무료 호스팅을 제공합니다.

배포 네트워크: GameDistribution, GameMonetize

이들은 HTML5 업로드 하나를 여러 파트너 사이트에 신디케이션해 수동적 도달을 만들어 주며, 그 대가로 더 큰 수수료와 필수 SDK를 요구합니다. GameDistribution은 더 큰 몫을 가져가고, GameMonetize는 더 높은 배분율과 빠르고 문턱 낮은 지급을 제공합니다. 배분율보다 볼륨이 더 중요한 캐주얼, 퍼즐, .io 게임에 좋습니다.

셀프 호스팅도 잊지 마세요

HTML5 게임은 그냥 정적 파일이므로 GitHub Pages, Cloudflare Pages, Netlify, Vercel에서, 또는 직접 소유한 도메인에서 무료로 호스팅할 수 있고, 수익 수수료를 떼이지 않으며 SEO와 애널리틱스를 완전히 통제할 수 있습니다. 단점은 내장 관객이 전혀 없다는 것입니다. 흔한 방식은 이렇습니다. 자기 브랜드와 SEO를 위해 정본 버전은 셀프 호스팅하고, 도달을 위해 itch.io와 포털 한두 곳에도 게시하는 것이죠. 게임을 Cinevva 같은 크리에이터로 만들었다면 링크로 즉시 공유하고 쇼케이스에도 제출할 수 있습니다.

어떻게 고를까

목표에 맞춰 플랫폼을 고르세요. 최대한의 자유와 최고의 배분을 원하나요? itch.io에 셀프 호스팅을 더하세요. 가장 큰 관객을 원하고 다듬어진 캐주얼 게임이 있나요? Poki 또는 CrazyGames입니다. 완성된 고품질 게임에 선지급을 원하나요? Armor Games에 피치하세요. 수동적인 신디케이션 도달을 원하나요? 배포 네트워크입니다. 대부분의 인디는 여러 곳에 동시에 게시합니다. 홈 베이스로 itch.io, 도달을 위해 포털, 통제를 위해 자기만의 링크를 함께 씁니다.

자주 묻는 질문

HTML5 게임은 어디에 게시해야 하나요?

itch.io로 시작하세요. 즉시, 무료이고, 최고의 수익 배분을 주며, 유료로 팔거나 무료로 풀 수 있습니다. 더 큰 관객을 원한다면 다듬어진 캐주얼 게임을 CrazyGames나 Poki에 제출하세요(둘 다 선별적 심사와 필수 SDK가 있습니다). 대부분의 개발자는 여러 곳에 게시합니다. itch.io에 포털, 그리고 자기만의 셀프 호스팅 링크를 더하는 식이죠.

어느 웹 게임 플랫폼이 가장 많이 벌어주나요?

트래픽과 모델에 따라 다릅니다. itch.io는 최고의 배분을 주지만(기본값으로 90% 이상을 가져감) 관객은 직접 데려와야 합니다. Poki와 CrazyGames는 거대한 내장 관객이 있지만 자기들 조건으로 광고 수익을 나눕니다. Armor Games는 품질 좋은 게임에 선지급 스폰서십 비용을 냅니다. 단 하나의 최선은 없습니다. 트래픽이 낮은 높은 배분율은 수백만 플레이어가 있는 낮은 배분율보다 적게 벌 수 있습니다.

웹 게임을 게시하려면 SDK가 필요한가요?

itch.io, Newgrounds, GameJolt에서는 필요 없고, 그냥 업로드하면 됩니다. 대형 포털(Poki, CrazyGames)과 배포 네트워크(GameDistribution, GameMonetize)에서는 수익화와 정식 출시에 SDK가 필요합니다. SDK는 광고와 플랫폼 기능을 처리합니다. 어디에 게시할지 고를 때 그 통합 작업을 감안하세요.

같은 웹 게임을 여러 플랫폼에 게시할 수 있나요?

독점 계약에 동의하지 않는 한(예를 들어 Poki의 더 높은 수익 배분은 웹 독점을 요구할 수 있습니다) 대개 가능합니다. 셀프 호스팅에 itch.io, 그리고 비독점 포털을 더하는 건 흔한 조합입니다. 독점과 수익 배분은 서로 엮여 있는 경우가 많으니 각 플랫폼의 약관을 읽어 보세요.

관련 글

• itch.io에서 게임 출시하는 법 — 단계별 안내
• itch.io에서 플레이 수 늘리는 법 — 라이브 후 트래픽 끌어오기
• 예산 없이 인디 게임 홍보하는 법 — 0달러로 하는 마케팅
• Steam Next Fest 전략 — Steam에도 진출한다면
• 2026년 최고의 웹 게임 엔진 — 먼저 게임을 만들기

마지막 업데이트: 2026년 6월.

무료 3D 에셋을 찾을 때 늘 등장하는 세 이름이 있습니다. Sketchfab, Poly Haven, Kenney입니다. 사실 서로 경쟁 관계라기보다 각자 잘하는 게 다릅니다. 하나는 라이선스가 뒤섞인 거대한 마켓플레이스이고, 하나는 사실적인 CC0이며, 하나는 스타일라이즈드 게임용입니다. 2026년 기준으로 이 셋이 어떻게 다른지, 그리고 언제 어떤 걸 골라야 하는지 정리했습니다.

한눈에 보기

Kenney: 통일감 있고 바로 쓸 수 있는

Kenney는 일관된 룩의 게임을 가장 빨리 만드는 방법입니다. 수만 개의 에셋이 전부 CC0이고 (출처 표기 불필요, 상업 사용 가능), 팩끼리 섞어 써도 어울리는 일관된 스타일이며, 전부 게임에 맞게 최적화되어 있습니다. 대신 범위가 아쉽습니다. 사실적이라기보다 스타일라이즈드하고 깔끔한 쪽이라, 특정한 초고밀도 프롭 하나를 찾기는 어렵습니다. 게임 전체가 하나로 어울려 보이길 원하고, 라이선스 걱정 없이 빠르게 가고 싶을 때 Kenney를 쓰세요.

Poly Haven: 사실적이고 CC0

Poly Haven은 리얼리즘 전문가입니다. PBR 텍스처를 입힌 3D 모델, 고해상도 텍스처, 조명용 HDRI가 모두 CC0이고, 해상도도 여러 종류에 키 없는 API로 바로 다운로드할 수 있습니다. 2,000개가 넘고 계속 늘어나는 중입니다. 카탈로그는 방대한 마켓플레이스라기보다 더 작고 초점이 분명한 편입니다 (프롭, 환경 오브젝트, 재질, 조명). 사실적인 재질, 환경 꾸미기, 제대로 된 HDRI 조명을 출처 표기 없이 쓰고 싶을 때 Poly Haven을 쓰세요.

Sketchfab: 다양성, 대신 라이선스 확인은 필수

Sketchfab은 거인입니다. 수백만 개의 모델, 다운로드 전 3D 미리보기, 그리고 어마어마하게 넓은 스타일과 주제를 갖췄습니다. 함정은 라이선스가 모델마다 다르다는 점입니다. 그래서 다운로드 가능 + CC0 또는 CC-BY로 필터링하고 하나하나 확인해야 합니다. 2026년의 주의점 하나는 Sketchfab의 스토어가 Epic의 Fab으로 옮겨갔고, CC-BY와 Fab Standard 콘텐츠만 이전할 수 있다는 것입니다. CC0와 다른 크리에이티브 커먼즈 모델은 당분간 Sketchfab에서 계속 다운로드할 수 있지만, 서서히 줄어드는 CC0 출처로 보고 필요한 것을 미리 챙겨두세요. 다른 곳에 없는 특정하거나 흔치 않은 모델이 필요하고 라이선스를 확인할 각오가 되어 있을 때 Sketchfab을 쓰세요.

어떤 걸 써야 할까?

• 게임 전체의 통일감, 빠르게, 출처 표기 없이: Kenney.
• 사실적인 프롭, 재질, 조명, CC0: Poly Haven.
• 특정하거나 흔치 않은 모델, 가장 넓은 선택지: Sketchfab (라이선스 확인).

실제로 많은 개발자가 셋을 다 씁니다. 기본 세트와 UI는 Kenney, 사실적인 텍스처와 HDRI는 Poly Haven, 일회성 히어로 에셋은 Sketchfab이라는 식이죠. 사실적인 Poly Haven 재질을 스타일라이즈드한 Kenney 모델에 섞으면 충돌할 수 있으니, 아트 디렉션을 먼저 정하고 거기에 맞는 출처를 고르세요.

세 곳 너머

이게 유일한 선택지는 아닙니다. Quaternius는 스타일라이즈드 로우폴리를 위한 또 하나의 훌륭한 CC0 출처이고, AmbientCG는 CC0 텍스처를 전문으로 하며, Poly Pizza는 아카이브된 Google Poly 카탈로그를 호스팅합니다. AI로 모델을 생성할 수도 있습니다. 전체 지형을 보려면 무료 3D 모델 사이트와 무료 게임 에셋 가이드를 참고하세요.

자주 묻는 질문

무료 3D 모델에는 Sketchfab, Poly Haven, Kenney 중 뭐가 제일 좋나요?

각자 잘하는 게 다릅니다. Kenney는 통일감 있고 게임용인 스타일라이즈드 에셋에 가장 좋고 전부 CC0입니다. Poly Haven은 사실적인 모델, 텍스처, HDRI에 가장 좋고 전부 CC0입니다. Sketchfab은 다양성과 특정하거나 디테일한 모델에 가장 좋지만 라이선스가 제각각이라 하나하나 확인해야 합니다. 많은 개발자가 셋을 함께 씁니다.

Poly Haven과 Kenney가 정말 상업용 게임에 무료인가요?

네. 둘 다 완전히 CC0라서 모든 에셋이 퍼블릭 도메인입니다. 상업 사용 무료, 수정 가능, 출처 표기 불필요라는 뜻이죠. 그래서 세 곳 중 위험이 가장 낮은 두 출처입니다. 반면 Sketchfab은 모델마다 라이선스가 뒤섞여 있어서 상업 사용 전에 확인해야 합니다.

이 사이트들의 에셋에 출처를 표기해야 하나요?

Kenney나 Poly Haven은 전부 CC0라 표기가 필요 없습니다. Sketchfab은 개별 모델의 라이선스에 따라 다릅니다. CC0는 표기가 필요 없고, CC-BY는 출처 표기가 필요하며, 일부 모델은 아예 상업적으로 쓸 수 없습니다. 출시 전에 Sketchfab 모델마다 라이선스를 꼭 확인하세요.

세 곳의 에셋을 한 게임에 섞어 써도 되나요?

기술적으로는 되고 라이선스도 허용하지만, 아트 디렉션에 주의하세요. Kenney의 스타일라이즈드한 룩과 Poly Haven의 사실적인 재질은 아무렇게나 섞으면 충돌할 수 있습니다. 비주얼 스타일을 먼저 정하고 거기에 맞는 에셋을 가져오면서, CC0 출처에 없는 특정 조각만 Sketchfab에서 채우세요.

관련 글

• 게임용 최고의 무료 3D 모델 사이트 — 더 넓은 판
• 무료 게임 에셋을 찾을 수 있는 곳 — 20곳 이상, 모든 종류
• 게임용 최고의 AI 에셋 생성기 — 대신 생성하기
• 게임 에셋 라이선스 완전 정리 — CC0, CC-BY 그리고 나머지
• 게임용 무료 효과음과 음악 — 오디오 쪽

마지막 업데이트: 2026년 6월.

브라우저에서 돌아가는 3D 게임을 만들고 싶다면 가장 자주 거론되는 엔진이 셋 있습니다. Unity, Godot, PlayCanvas입니다. 이들은 웹에 도달하는 방식이 서로 아주 다릅니다. Unity는 WebGL로 익스포트하는 데스크톱 강자이고, Godot는 무료 오픈소스 만능 엔진이며, PlayCanvas는 처음부터 웹을 위해 만들어졌습니다. 2026년 브라우저 3D에 한정해 이 셋이 어떻게 비교되는지 살펴봅니다.

빠른 결론

• 웹 우선 3D, 가장 작은 빌드, 최고의 WebGPU: PlayCanvas.
• 무료 오픈소스, 2D와 3D 모두, 웹과 네이티브를 하나의 코드베이스로: Godot.
• 이미 Unity 프로젝트가 있거나, 콘솔과 고사양 네이티브도 필요하다면: 더 큰 웹 다운로드를 감수하는 Unity.

비교

Unity (WebGL)

Unity는 플레이 가능한 WebGL 빌드를 익스포트하며, 그 생태계(Asset Store, 툴링, 문서)는 따라올 상대가 없습니다. 다만 웹에 한해 걸리는 점이 있습니다. 빈 빌드가 약 8 MB에서 시작하고, 로딩 시간이 웹 네이티브 엔진에 뒤처지며, 모바일 브라우저 메모리가 빠듯할 수 있습니다. WebGPU가 있긴 하지만 실험적이고 기본으로 꺼져 있으며, 실질적인 타겟은 WebGL2입니다. 현실적인 함정은 Unity가 브라우저에 올리기에는 가장 무거운 선택지라는 점입니다. 그래서 데스크톱, 모바일, 콘솔로도 출시하는 게임에서 웹이 부차적인 타겟일 때 빛을 발합니다. 에디터 안에서 AI 도움을 받고 싶다면 Unity는 Muse AI 도구를 Unity AI(2026년 오픈 베타)로 대체하기도 했습니다.

Godot (4.7)

Godot는 MIT 라이선스의 무료 오픈소스로 매출 상한이나 시트 요금이 없고, 2D와 3D를 모두 잘 다룹니다. 4.7 버전(2026년 6월)은 WebAssembly SIMD를 기본으로 탑재했고, 기존 4 GB 메모리 상한을 없애는 wasm64 익스포트 옵션을 추가했습니다. 웹 렌더링은 여전히 WebGL 2.0(Compatibility 렌더러)만 지원하며, Godot에는 아직 WebGPU 지원이 없습니다. 웹과 관련해 남아 있는 주의점이 둘 있습니다. C# 프로젝트는 웹으로 익스포트할 수 없고(GDScript만 가능), SharedArrayBuffer 스레딩에는 특정 COOP/COEP 서버 헤더가 필요한데 일부 호스트에서는 이게 걸림돌이 될 수 있습니다. 라이선스 걱정 없이 웹과 네이티브를 아우르는 엔진 하나를 원하는 인디 개발자에게 Godot는 확실한 무료 선택지입니다.

PlayCanvas

PlayCanvas는 첫날부터 웹을 위해 설계됐습니다. 런타임이 아주 작고(~1-2 MB), 셋 중 로딩이 가장 빠르며, 어떤 웹 엔진보다 실전에 가장 잘 준비된 WebGPU 렌더러를 갖췄습니다. 여기에는 v2.20(2026년 6월) 기준 컴퓨트 기반 3D 가우시안 스플랫 렌더링도 포함됩니다. 에디터는 클라우드 기반이고 협업형이라 팀에는 잘 맞지만 모두의 워크플로에 들어맞지는 않습니다. 3D 우선이라 복잡한 2D에는 덜 어울립니다. 다운로드 크기와 웹 성능이 최우선이라면 PlayCanvas는 바로 그 목적에 맞춰 만들어진 엔진입니다.

어떻게 고를까

당신의 진짜 제약을 기준으로 고르세요. 가장 작고 로딩이 빠른 3D 웹 빌드와 좋은 WebGPU가 필요하다면 PlayCanvas를 고르세요. 2D와 3D를 모두 다루고 하나의 코드베이스에서 데스크톱과 모바일로도 익스포트하는 무료 오픈 엔진을 원한다면 Godot를 고르세요. 게임이 이미 Unity에 자리 잡고 있거나 Unity의 고사양 렌더링과 콘솔 익스포트가 정말로 필요하다면, WebGL 빌드를 출시하고 더 큰 다운로드를 감수하세요.

엔진을 아예 건너뛰고 3D 웹 게임을 AI에게 설명하고 싶다면, 그건 다른 길이며 코딩 없이 3D 브라우저 게임 만드는 법에서 다룹니다.

자주 묻는 질문

3D 브라우저 게임에 가장 좋은 엔진은?

PlayCanvas가 2026년 가장 강력한 웹 우선 선택지입니다. 아주 작은 런타임, 가장 빠른 로딩, 가장 성숙한 WebGPU 렌더러를 갖췄습니다. Godot는 최고의 무료 오픈소스 옵션이고 네이티브로도 익스포트합니다. Unity는 게임이 이미 이를 쓰고 있거나 그 고사양 기능이 필요할 때만 최선인데, 웹 빌드가 가장 크기 때문입니다. 최선의 선택은 빌드 크기, 네이티브 익스포트 필요 여부, 그리고 예산에 달려 있습니다.

Unity와 Godot는 C# 게임을 웹으로 익스포트할 수 있나요?

흔한 함정입니다. Godot는 C# 프로젝트를 웹으로 전혀 익스포트할 수 없습니다(GDScript만 가능). Unity의 웹 익스포트는 C#을 쓰지만 Wasm을 거쳐 WebGL로 컴파일하며, 그 결과 빌드가 큽니다(빈 빌드 ~8 MB+). PlayCanvas는 JavaScript나 TypeScript를 네이티브로 쓰는데, 그 웹 빌드가 그토록 작은 이유 중 하나입니다.

브라우저에서 가장 빨리 로딩되는 건?

PlayCanvas가 큰 차이로 앞섭니다. 웹을 위해 특별히 만든 ~1-2 MB 런타임 덕분입니다. Godot의 빈 빌드는 gzip 기준 약 9 MB이고, Unity는 약 8 MB부터 시작해 그 이상입니다. 웹 게임에서는 총 다운로드 크기가 실제로 로딩을 기다리는 플레이어 수에 크게 영향을 줍니다. 그래서 이는 사소한 디테일이 아니라 진짜 선택 요인입니다.

이 엔진들은 WebGPU를 지원하나요?

PlayCanvas가 가장 성숙한 WebGPU 렌더러를 갖췄습니다. Godot의 웹 익스포트는 여전히 WebGL2만 지원하며 WebGPU 지원은 아직 없습니다. Unity는 WebGPU를 실험적으로 유지하며 기본은 WebGL2입니다. 이 트레이드오프를 더 깊이 보려면 WebGPU vs WebGL 가이드를 참고하세요.

관련 글

• 2026년 최고의 웹 게임 엔진 — 엔진 11종 전체 비교
• 게임을 위한 WebGPU vs WebGL — 렌더링 API 트레이드오프
• PlayCanvas vs Three.js — 웹 3D를 위한 엔진 vs 라이브러리
• 웹 게임을 위한 Godot vs Unity — 두 대형 풀 엔진의 정면 대결

마지막 업데이트: 2026년 6월.

"바이브 코딩"은 트윗 하나에서 시작해 1년도 안 되어 콜린스 사전의 올해의 단어가 됐습니다. 게임에서는 지금 가장 재미있게 만드는 방법 중 하나입니다. 원하는 걸 설명하면 AI가 코드를 쓰고, 여러분은 문법이 아니라 감으로 방향을 잡습니다. 이 용어가 실제로 무엇을 뜻하는지, 게임을 바이브 코딩하는 방법, 그리고 어디서 잘 통하고 어디서 발목을 잡는지 정리했습니다.

이 용어는 어디서 왔나

이 표현은 OpenAI 공동 창립 멤버인 Andrej Karpathy가 2025년 2월에 올린 글에서 나왔습니다. 그는 "바이브에 완전히 몸을 맡기고, 지수적 성장을 받아들이고, 코드가 존재한다는 사실조차 잊어버리는 새로운 방식의 코딩"이라고 표현했습니다. AI 코딩 모델이 충분히 좋아져서 "그냥 뭔가를 보고, 뭔가를 말하고, 뭔가를 실행하고, 뭔가를 복사-붙여넣기 하면 대체로 잘 작동하기" 때문에 가능해진 일입니다. 그는 이걸 버려도 되는 주말 프로젝트용으로 규정했는데, 이 점은 기억해 둘 만합니다.

개발자 Simon Willison은 정의를 더 날카롭게 다듬었습니다. 진짜 바이브 코딩이란 LLM이 쓰는 코드를 검토하지 않고 소프트웨어를 만드는 것입니다. 모든 줄을 읽고, 테스트하고, 이해한다면 그건 AI를 타이핑 보조 도구로 쓰는 것이고, 조금 다른 이야기입니다. 2025년 말에는 이 용어가 충분히 퍼져서 콜린스가 올해의 단어로 뽑았습니다.

게임에는 이게 깔끔하게 들어맞습니다. 게임을 설명하면 AI가 만들고, 여러분은 플레이하면서 수정을 요청하고, 코드는 대체로 보지 않습니다. 그게 게임을 바이브 코딩하는 것입니다.

게임이 여기에 잘 맞는 이유

게임은 시각적이고 즉시 테스트할 수 있는데, 이건 바이브 코딩이 보상해 주는 바로 그 루프입니다. 점프 감이 괜찮은지, 적이 너무 빠른지 2초면 확인할 수 있으니 "말하고, 실행하는" 사이클이 짧고 만족스럽습니다. 그리고 그 유명한 증거 사례가 바로 게임입니다. 2025년 초에 인디 개발자 Pieter Levels는 게임 개발 배경 없이 AI 코드 에디터와 Three.js로 몇 시간 만에 브라우저 3D 비행 시뮬레이터를 바이브 코딩했고, 이건 입소문을 타며 크게 히트했습니다. (그의 수익 수치는 본인이 밝힌 것이니 금액은 어느 정도 걸러 들어야 하지만, 결과물 자체는 실재하고 잘 기록되어 있습니다.)

게임을 바이브 코딩하는 두 가지 방식

얼마나 직접 손대고 싶은지에 따라 두 갈래가 있습니다.

범용 AI 코딩 도구. Cursor, Claude Code, GitHub Copilot을 쓰면 Karpathy가 설명한 방식대로 게임을 만들 수 있습니다. AI 코딩 에이전트에게 프롬프트를 주고, 보통 Three.js 같은 웹 프레임워크와 함께 반복합니다. 코드를 읽을 필요는 없지만, 프로젝트는 어디로든 가져갈 수 있는 진짜 코드베이스입니다. 가장 유연하고 강력한 경로이면서, 동시에 스스로 발목을 잡을 여지도 가장 많습니다.

게임 전용 프롬프트-투-게임 도구. Cinevva, Rosebud, Summer, Replit, Nilo는 이 루프 전체를 목적에 맞게 만든 환경으로 감싸 놓았습니다. 게임을 설명하면 플레이 가능한 게임을 만들어 주고, 채팅으로 다듬으며, 에셋도 대신 생성해 줍니다. 가장 진입하기 쉽고 공유 가능한 결과물까지 가장 빠르게 도달하는 방법입니다. 어느 도구가 어떤 종류인지는 AI 게임 생성기 비교에서 정리해 두었습니다.

게임을 바이브 코딩하는 단계별 방법

1. 작은 아이디어를 고르세요. 바이브 코딩은 주말 규모의 범위에서 빛을 발합니다. 장르 하나, 반전 하나, 목표 하나를 정하세요.
2. 한 문장짜리 프롬프트를 쓰세요. "커질수록 빨라지는 네온 스네이크 게임을 만들어 줘." 도구가 첫 버전을 만들게 하세요. 빈 화면을 건너뛰고 싶다면 원클릭 프롬프트를 써 볼 수 있습니다.
3. 플레이한 다음 한 가지만 바꿔 달라고 하세요. "더 빠르게 해 줘", "점수를 추가해 줘", "조작이 뻑뻑하니 좀 더 경쾌하게 만들어 줘." 바꾸고, 플레이하고, 반복하세요.
4. 요청만으로 에셋을 생성하세요. "로우폴리 느낌으로 만들어 줘", "경쾌한 음악을 넣어 줘", "사막 스카이박스를 써 줘."
5. 링크를 공유하세요. 브라우저 도구는 클릭 한 번으로 공유됩니다. 사람들 앞에 내놓고 그 반응이 다음 라운드를 이끌게 하세요.

직접 해 보며 배우고 싶다면 지금 바로 브라우저에서 무료로 3D 게임 바이브 코딩을 시작할 수 있습니다.

함정 (그리고 피하는 법)

바이브 코딩은 강력하지만, 2026년의 솔직한 그림에는 진짜 경고 신호가 있습니다.

• "거의 맞는데, 완전히는 아닌" 개발자 3분의 2가 이걸 AI에 대한 최대 불만으로 꼽습니다. 게임에서의 해법은 작고 구체적인 요청, 그리고 수정이 상황을 나쁘게 만들었을 때 되돌릴 각오입니다.
• 보안과 품질 부채. 2025년 연구들은 AI가 생성한 코드 샘플 중 상당수가 보안 결함을 들여왔고, 중복되고 리팩터링되지 않은 코드가 늘고 있다는 걸 발견했습니다. 버려도 되는 게임에서는 이게 거의 문제가 되지 않지만, 사용자 데이터나 돈을 다루는 무언가라면 코드를 검토하거나 검토할 수 있는 사람을 두세요.
• 될 때까지는 되다가 안 될 때가 온다. 널리 보도된 한 사건에서는 AI 코딩 에이전트가 코드 프리즈 중에 프로덕션 데이터베이스를 삭제했습니다. 교훈은 이렇습니다. 백업을 유지하고, 실험을 중요한 것과 분리하고, 잃어선 안 되는 시스템에 바이브 코딩 에이전트를 겨누지 마세요.

Karpathy 본인도 나중에 원래 글을 "버려도 되는 트윗"이라고 부르며 진지한 작업에는 더 신중한 표현을 씁니다. 요점은 바이브 코딩이 나쁘다는 게 아니라, 프로토타입과 소규모 게임에는 훌륭하지만 정확해야 하는 것들에 대한 유일한 방법으로 삼기엔 위험하다는 것입니다.

바이브 코딩은 "진짜" 게임 개발일까

특히 프로토타입, 잼, 소규모 게임에서는 실재하고 유용한 제작 방식이고, 많은 사람이 처음으로 게임에 발을 들이는 방법이기도 합니다. 판돈이 클 때 자신이 무엇을 만드는지 이해하는 것을 대체하지는 못합니다. 2026년에 가장 생산적인 태도는 바이브 코딩으로 빠르게 탐색하고 프로토타이핑한 다음, 속도를 늦춰 신뢰성이 필요한 부분을 이해하는 것입니다. 대부분의 브라우저 게임에서는 그 경계선이 여러분에게 편안하게 유리한 쪽에 놓여 있습니다.

자주 묻는 질문

바이브 코딩이란 무엇인가요?

바이브 코딩은 원하는 것을 AI에게 설명하고, 코드를 직접 검토하지 않은 채 AI가 코드를 쓰게 해서 소프트웨어를 만드는 것입니다. 이 용어는 Andrej Karpathy가 2025년 2월에 만들었고 2025년 콜린스 올해의 단어로 뽑혔습니다. 게임에서는 코드를 쓰는 대신 게임을 평이한 언어로 설명하고 채팅으로 다듬는 것을 뜻합니다.

게임 바이브 코딩은 어떻게 시작하나요?

작은 아이디어를 고르고, 프롬프트-투-게임 도구나 AI 코드 에디터에 한 문장으로 설명하고, 첫 버전을 플레이한 다음 한 번에 하나씩 수정을 요청하세요. 브라우저 기반 AI 게임 생성기는 플레이 가능한 게임을 만들어 주고 설정 없이 바로 공유할 수 있어서 가장 쉬운 출발점입니다.

바이브 코딩은 게임 만들기에 좋은가요?

네, 특히 프로토타입과 소규모 또는 캐주얼 게임에는 빠른 설명-플레이-다듬기 루프가 아주 잘 맞습니다. 크고 복잡하거나 정확성이 중요한 프로젝트에는 약한데, 검토하지 않은 AI 코드가 버그와 보안 문제를 들여올 수 있기 때문입니다. 빠르게 움직이는 데 쓰되, 신뢰성이 필요한 것은 코드를 검토하세요.

사람들은 게임을 바이브 코딩할 때 어떤 도구를 쓰나요?

두 종류입니다. Cursor, Claude Code, GitHub Copilot 같은 범용 AI 코딩 도구(웹에서는 흔히 Three.js와 함께)와 Cinevva, Rosebud, Summer, Replit, Nilo 같은 게임 전용 프롬프트-투-게임 도구입니다. 게임 전용 도구가 진입하기 더 쉽고, 코딩 도구가 더 유연합니다.

관련 글

• 2026년 최고의 AI 게임 생성기 — 도구 비교
• AI로 게임 만드는 법 (코딩 없이) — 단계별 워크플로
• 코딩 없이 3D 브라우저 게임 만드는 법 — 3D 경로
• 원클릭으로 만들 수 있는 AI 게임 프롬프트 — 시작할 프롬프트
• 2026년 최고의 웹 게임 엔진 — 전통적인 방식으로 만들기

최종 업데이트: 2026년 6월.

10년 넘게 WebGL은 브라우저에 제대로 된 그래픽을 넣을 수 있는 유일한 방법이었습니다. WebGPU는 그 후계자이고, 2026년은 WebGPU가 마침내 어디서나 실제로 쓸 만해진 해입니다. 웹 게임을 만들면서 어느 쪽을 겨냥할지 고민 중이라면, 여기 솔직한 비교가 있습니다. 무엇이 바뀌었고, 각각 어디서 유리하며, 당신의 엔진이 이미 무엇을 쓰고 있는지 살펴봅니다.

짧게 요약하면

WebGL은 OpenGL ES를 기반으로 한 그래픽 API로, 그리기에 초점을 맞춰 만들어졌습니다. WebGPU는 Vulkan, Metal, Direct3D 12를 본떠 만든 최신 API로, 그리기와 범용 GPU 컴퓨트를 모두 목표로 합니다. WebGPU는 무거운 장면에서 더 빠르고, 컴퓨트 셰이더(파티클, 시뮬레이션, GPU에서의 컬링)를 열어 주며, API도 더 깔끔합니다. WebGL은 더 오래됐고, 더 단순하며, 사실상 존재하는 거의 모든 기기에서 지원됩니다.

2026년에 바뀐 것

핵심은 이겁니다. WebGPU가 드디어 크로스 브라우저가 됐습니다. Safari 26(2025년 9월)이 macOS, iPadOS, iOS, visionOS 전반에 WebGPU를 탑재하면서 마지막 큰 걸림돌을 없앴습니다. 그 전까지는 "Safari와 iOS가 WebGPU를 지원하지 않으니 그냥 WebGL을 써라"가 맞는 조언이었습니다. 이제는 아닙니다. Chrome과 Firefox는 이미 지원하고 있었으므로, 2026년 기준 WebGPU는 모든 주요 브라우저에서 돌아갑니다.

그렇다고 WebGPU가 어디서나 기본값이라는 뜻은 아닙니다. 대부분의 엔진에서 여전히 선택 사항이거나 실험 단계이고(아래에서 더 자세히), WebGL2는 안전한 기준선으로 남아 있습니다. 하지만 WebGPU 도입을 가로막던 브라우저 지원의 벽은 사라졌습니다.

정면 비교

WebGPU가 유리할 때

• 오브젝트나 드로우 콜이 많을 때. WebGPU는 CPU 오버헤드가 낮고 멀티 드로우 같은 기능을 갖춰서, WebGL이 드로우 콜 수 때문에 버벅이기 시작하는 지점에서도 프레임 레이트를 유지합니다.
• GPU 컴퓨트. 파티클 시스템, 물리, 컬링, 절차적 생성, 3D 가우시안 스플래팅을 컴퓨트 셰이더로 GPU에서 돌릴 수 있습니다. WebGL은 이걸 아예 할 수 없습니다.
• 미래 대비. WebGPU는 플랫폼이 나아가는 방향이고, 새로운 엔진 기능은 점점 더 이쪽에 먼저 들어옵니다.

WebGL이 여전히 맞는 선택일 때

• 오래되거나 저사양 기기에서 최대한 넓은 도달. WebGL2는 아직 WebGPU 경로가 제대로 동작하지 않을 수 있는 하드웨어와 브라우저 버전에서도 돌아갑니다.
• 단순한 2D와 가벼운 3D. 게임이 GPU를 밀어붙이지 않는다면 WebGL만으로 충분하고, 최신 드라이버의 예외 상황을 피할 수 있습니다.
• 오늘 기준 가장 안전한 기준선을 원할 때. 폴백 로직 없이 WebGL2로 출시하는 것은 여전히 넓은 사용자층을 겨냥할 때 가장 위험이 낮은 선택입니다.

대부분의 게임을 위한 실용적인 2026년 답은 이겁니다. 둘 다 지원하는 엔진 위에서 빌드하고, 가능한 곳에서는 WebGPU를 쓰되 자동으로 WebGL2로 폴백하게 하세요. 렌더러를 두 개 짜지 않고도, 되는 곳에서는 속도를 얻고 안 되는 곳에서는 호환성을 얻습니다.

당신의 엔진이 이미 쓰는 것

웹 게임 엔진 비교에서 가져온, 2026년 주요 웹 엔진들의 WebGPU 현황입니다.

• PlayCanvas는 웹 엔진 중 가장 프로덕션에 가까운 WebGPU 렌더러를 갖췄고, 컴퓨트 기반 가우시안 스플랫 렌더링도 포함합니다.
• Three.js는 자동 WebGL2 폴백을 갖춘 무설정 WebGPU 렌더러(three/webgpu)를 제공합니다. 다만 기본 export는 아직 WebGL입니다.
• Babylon.js는 WebGPU를 지원합니다(WebGPUEngine으로 옵트인). 버전 8은 WebGPU 빌드 크기도 절반으로 줄였습니다.
• Godot는 아직 WebGPU를 지원하지 않습니다. 4.7의 웹 익스포트는 여전히 WebGL2만 지원하며, 다만 wasm64 빌드가 기존 4 GB 메모리 상한을 없앴습니다.
• Cocos Creator는 새로운 렌더 파이프라인을 통해 실험적 WebGPU를 제공합니다.
• Unity는 WebGPU를 실험 단계로 유지하고 WebGL2를 기본 웹 타깃으로 둡니다.
• Phaser 4는 WebGL2 재작성 버전으로 아직 WebGPU가 없습니다. PixiJS는 WebGPU를 지원하지만 기본값은 WebGL입니다.

그래서 실제로는 엔진이 대개 WebGPU냐 WebGL이냐를 대신 정해 주고, 좋은 엔진은 자동으로 폴백합니다.

브라우저 지원 스냅샷 (2026)

넓은 사용자층을 겨냥한다면 항상 Safari/iOS에서 테스트하고, 오래된 기기의 롱테일을 위해 WebGL2 폴백을 유지하세요.

자주 묻는 질문

게임에서 WebGPU가 WebGL보다 나은가요?

까다로운 게임이라면 그렇습니다. WebGPU는 CPU 오버헤드가 낮고, 더 많은 오브젝트를 처리하며, WebGL이 못 하는 효과를 위한 컴퓨트 셰이더를 더합니다. 단순한 2D나 가벼운 3D라면 WebGL2만으로 충분하고 오래된 기기에서 지원 범위가 더 넓습니다. 2026년의 최선은 가능한 곳에서 WebGPU를 쓰고 자동으로 WebGL2로 폴백하는 엔진입니다.

2026년에 WebGPU가 Safari와 iOS에서 동작하나요?

네. 2025년 9월에 나온 Safari 26이 macOS, iPadOS, iOS, visionOS에 WebGPU를 추가했습니다. 그것으로 마지막 큰 공백이 메워졌고, 이제 WebGPU는 Chrome, Firefox, Safari 전반에서 모바일을 포함해 동작합니다. 오래된 기기와 브라우저 버전에는 여전히 없을 수 있으니 WebGL2 폴백을 유지하세요.

WebGPU와 WebGL 중 무엇을 먼저 배워야 하나요?

게임 엔진을 쓴다면 보통 둘 다 직접 짜지 않고 엔진이 처리합니다. 그래픽 코드를 손으로 쓴다면 WebGPU가 미래 대비 측면에서 더 나은 API지만, 지금은 WebGL 쪽 튜토리얼과 예제가 더 많습니다. 많은 개발자가 여전히 WebGL이나 Three.js 같은 라이브러리로 시작하는데, Three.js는 이제 준비가 되면 WebGPU 렌더러를 제공합니다.

WebGPU가 WebGL을 대체하게 될까요?

결국 대부분의 신규 개발은 WebGPU를 겨냥하겠지만, WebGL이 곧 사라지지는 않습니다. 오래된 하드웨어를 위한 보편적 기준선으로 남아 있고, 기존 도구와 콘텐츠에 깊이 박혀 있습니다. 엔진들이 둘 다 지원하며 런타임에 선택하는 긴 공존기가 이어질 겁니다.

관련 글

• 2026년 최고의 웹 게임 엔진 — 엔진별 WebGPU 현황이 담긴 전체 목록
• 2026년 웹 게임 기술 스택 — API 수준에서 본 WebGL, WebGPU, Wasm
• Unity WebGL vs Godot vs PlayCanvas — 3대 3D 웹 엔진
• PlayCanvas vs Three.js — 웹 3D를 위한 엔진 대 라이브러리

바이브 코딩은 지금 게임을 만드는 가장 빠른 방법입니다. 원하는 것을 평범한 말로 설명하면 AI가 만들어 줍니다. 설치할 엔진도, 작성할 코드도, 뒤져야 할 에셋 스토어도 없습니다.

아래는 우리가 좋아하는 프롬프트 12가지입니다. 아무거나 클릭하면 그 아이디어가 이미 입력된 채로 Cinevva가 열리고, 편집할 수 있는 플레이 가능한 3D 게임을 만들기 시작합니다. 전부 브라우저에서 돌아가고 전부 무료로 써볼 수 있습니다. 그대로 가져다 쓰거나, 단어 하나를 바꾸거나, 직접 써보세요.

직접 써보는 방법

위 프롬프트들이 짧은 건 일부러 그렇게 한 것입니다. 모든 규칙을 일일이 적을 필요는 없습니다. 어떤 종류의 게임인지, 당신만의 한 가지 특징, 그리고 목표를 정하세요. 나머지는 AI가 채우고, 게임이 돌아가기 시작하면 무엇을 바꿀지 알려주면 됩니다.

대신 백지에서 시작하고 싶나요? 크리에이터 열기에서 직접 아이디어를 입력하세요.

오픈소스 게임 엔진은 독점 엔진이 줄 수 없는 것을 줍니다. 출시한 뒤에도 바뀌지 않는 라이선스죠. 좌석당 요금도, 매출 기준선도, 갑작스러운 가격 인상도 없습니다. 소스를 읽고, 포크하고, 원래 팀이 떠나더라도 계속 만들어갈 수 있습니다. Unity 런타임 수수료 사태 이후 많은 팀이 애초에 오픈소스로 옮긴 이유가 바로 그 안정성입니다.

이 글은 2026년에 쓸 만한 오픈소스 게임 엔진을 용도별로 묶은 전체 목록입니다. 웹 빌드가 꼭 필요하다면 어떤 엔진이 브라우저로 익스포트되는지 표시해 두었고, 최고의 웹 게임 엔진 비교에서 더 깊이 살펴볼 수 있습니다.

빠른 비교

단 하나의 "최고" 오픈소스 엔진은 없습니다. 어떤 게 맞는지는 2D냐 3D냐, 사용하는 언어, 그리고 웹을 타깃으로 하는지에 따라 달라집니다.

풀 2D 및 3D 엔진

Godot

"오픈소스 게임 엔진"이라고 하면 대부분 떠올리는 엔진이 Godot입니다. MIT 라이선스이고, 2D와 3D를 모두 다루며, 어떤 종류의 수수료나 매출 상한도 없습니다. 작은 웹 빌드(압축 시 약 5 MB)를 내놓고, 4.3 버전부터는 싱글 스레드로 익스포트해서 iOS와 Safari를 깔끔하게 지원할 수 있습니다. 웹에서 유일한 주의점은 C# 프로젝트가 아직 브라우저로 익스포트되지 않고 GDScript만 된다는 점입니다. 독점 엔진을 떠나는 대부분의 팀에게 Godot은 가장 가까운 올라운드 대체재입니다. 직접 비교는 웹 게임을 위한 Godot vs Unity를 보세요.

Cocos Creator

Cocos Creator는 무료 에디터와 오픈소스(MIT) 런타임을 함께 제공합니다. 2D와 3D를 다루고, WebGL, WebGPU, Wasm을 지원하며, 빌드 크기가 중요한 WeChat이나 TikTok 같은 미니게임 플랫폼에서 특히 강합니다. 빌드는 약 2~4 MB 정도로 나옵니다.

웹용 3D 라이브러리 및 엔진

Three.js

Three.js는 웹에서 가장 널리 쓰이는 3D 라이브러리로, MIT 라이선스이며 코어가 약 150 KB입니다. 풀 엔진이 아니라 렌더링 라이브러리이기 때문에, 게임 시스템이나 그 위에 얹을 프레임워크를 직접 추가해야 합니다. 그게 트레이드오프입니다. 직접 더 많이 작성하는 대신 최대한의 제어와 가장 작은 용량을 얻습니다. 우리가 Cinevva Engine을 만든 기반이 바로 Three.js이고, 그 위에 게임 시스템을 다시 얹어서 빈 캔버스에서 시작하지 않아도 되게 했습니다.

Babylon.js

Babylon.js는 물리 엔진, 애니메이션, 씬 인스펙터를 내장하고 WebGPU와 WGSL을 잘 지원하는 풀 오픈소스 3D 엔진(Apache 2.0)입니다. Three.js와 비교하면 더 큰 용량으로 더 많은 기능을 기본 제공합니다. 어느 쪽이 프로젝트에 맞는지는 Three.js vs Babylon.js를 보세요.

2D 프레임워크

Phaser

Phaser는 가장 인기 있는 오픈소스 HTML5 게임 프레임워크로, MIT 라이선스이며 2D 웹에서 가장 큰 커뮤니티와 생태계를 갖고 있습니다. 빌드는 약 500 KB입니다. 게임이 2D이고 JavaScript를 쓴다면 이기기 어렵습니다.

PixiJS

PixiJS는 빠른 2D WebGL 렌더러(MIT)로 약 200 KB입니다. 3D의 Three.js처럼 풀 엔진이 아니라 렌더러이기 때문에 게임 로직은 직접 가져와야 합니다. 커스텀 2D 렌더링과 아주 작은 용량을 원할 때 선택하세요.

Excalibur.js

Excalibur.js는 TypeScript로 작성된 친근한 BSD 라이선스 2D 엔진으로, 약 300 KB이며 순수 렌더러보다 더 많은 게임 기능을 기본 제공합니다. 타입과 부드러운 진입 경로를 원한다면 잘 맞습니다.

LÖVE (Love2D)

LÖVE는 Lua로 스크립팅하는 오래된 zlib 라이선스 2D 프레임워크입니다. 데스크톱에서 빠른 프로토타이핑과 게임잼에 사랑받습니다. love.js를 통한 웹 익스포트가 있긴 하지만 제한적이라, LÖVE는 데스크톱 우선 도구로 보는 게 맞습니다.

Rust, C++, 대규모 엔진

Bevy

Bevy는 Rust로 작성된 현대적인 데이터 주도 엔진으로, MIT와 Apache 2.0 이중 라이선스입니다. 엔티티-컴포넌트-시스템 구조가 큰 매력이고, 브라우저 빌드를 위해 WebAssembly로 컴파일됩니다. 다른 엔진들보다 젊고 빠르게 움직이므로 버전 간 호환성 깨짐을 각오해야 하지만, 2026년 현재 강한 추진력을 갖고 있습니다.

Open 3D Engine (O3DE)

O3DE는 대규모 고해상도 3D를 겨냥한 Linux Foundation 프로젝트(Apache 2.0)로, AWS 등이 후원합니다. AAA 야망과 그에 걸맞은 자원을 가진 팀을 위한 진지하고 무거운 엔진입니다. 브라우저를 타깃으로 하지는 않습니다.

어떻게 고를까

• 거의 모든 걸 다룰 무료 엔진 하나를 원한다면? Godot.
• 2D 웹 게임을 만든다면? Phaser, 또는 커스텀 렌더링이라면 PixiJS/Excalibur.js.
• 웹 3D를 만든다면? 제어와 용량은 Three.js, 기능이 다 갖춰진 건 Babylon.js.
• 가능한 한 작은 웹 빌드? Defold.
• 미니게임 플랫폼을 타깃으로? Cocos Creator.
• Rust와 ECS를 좋아한다면? Bevy.
• 대규모 고해상도 3D? O3DE.

웹이 타깃이라면 위 엔진 중 O3DE와 (대체로) LÖVE를 제외하면 모두 브라우저 빌드를 내놓을 수 있습니다. 웹에 특화된 전체 분석은 웹 게임 엔진 비교와 웹 게임을 위한 Unity 대안 가이드를 보세요.

자주 묻는 질문

2026년 최고의 오픈소스 게임 엔진은?

대부분에게는 Godot입니다. MIT 라이선스에 매출 상한 없이 무료이고, 2D와 3D 모두 능하며 웹 익스포트도 깔끔합니다. 2D 웹에 한정하면 Phaser가 가장 인기 있는 오픈소스 선택지이고, 웹 3D는 Three.js(라이브러리) 또는 Babylon.js(풀 엔진)입니다. 최선의 선택은 차원, 언어, 플랫폼에 따라 달라집니다.

Godot은 정말 무료인가요, 함정은 없나요?

네. Godot은 MIT 라이선스로 배포됩니다. 즉 수수료도, 로열티도, 매출 기준선도, 좌석 요금도 절대 없습니다. 상업용 게임에 쓸 수 있고 엔진 자체를 수정할 수도 있습니다. 이 프로젝트는 개발자에게 요금을 받는 게 아니라 기부와 후원으로 운영됩니다.

오픈소스 게임 엔진이 상업용 게임에 충분히 좋은가요?

네. 상업적으로 성공한 게임이 오픈소스 엔진으로 많이 출시되고, 오픈소스라는 건 신경 쓸 매출 상한이 없다는 뜻입니다. 트레이드오프는 보통 내장 에셋 마켓플레이스가 더 작고, 일부 엔진의 경우 대형 독점 엔진보다 즉시 쓸 수 있는 기능이 적다는 점입니다. 특히 웹 게임에서는 오픈소스 엔진이 더 작고 빠른 빌드를 만들어내는 경우가 많습니다.

Unity나 Unreal은 오픈소스인가요?

아니요. Unity는 클로즈드 소스이고 구독 기반입니다. Unreal Engine은 소스 공개(계정이 있으면 코드를 읽고 수정할 수 있음)지만 오픈소스는 아니며 매출 기준선을 넘으면 로열티 모델을 적용합니다. 오픈소스 엔진을 꼭 원한다면 Godot이 Unity에 가장 가까운 대안이고, 나머지는 Unity 대안 가이드에서 다룹니다.

웹에 가장 좋은 오픈소스 게임 엔진은?

올라운드 2D/3D 엔진은 Godot, 2D는 Phaser, 3D는 Three.js나 Babylon.js입니다. Defold는 풀 엔진 중 가장 작은 웹 빌드를 내놓습니다. 모두 무료이고 오픈소스입니다. 웹 게임 엔진 비교에서 빌드 크기, 로드 시간, 브라우저 지원으로 순위를 매겼습니다.

관련 글

• 2026년 최고의 웹 게임 엔진 (비교) — 빌드 크기, 로드 시간, 비용으로 순위 매김
• 웹 게임을 위한 Unity 대안 — Unity를 떠나는 팀을 위한 오픈소스 선택지
• 웹 게임을 위한 Godot vs Unity — 가장 가까운 오픈소스 대체재 직접 비교
• 2026년 최고의 2D 게임 엔진 — 게임이 2D라면
• Three.js vs Babylon.js — 두 거대 오픈소스 웹 3D 라이브러리
• Cinevva Engine — Three.js 위에 만든 우리의 오픈소스 웹 우선 엔진

Unity도 웹으로 익스포트할 수 있지만, WebGL 빌드가 무겁고, 2023년 이후 가격 정책이 개발자들을 휘둘러 왔으며, 브라우저 우선 게임에는 가장 가벼운 길이 되는 경우가 드뭅니다. 웹 게임만을 위한 Unity 대안을 찾고 있다면, 이 가이드는 2026년에 실제로 작고 빠른 브라우저 빌드를 내놓는 엔진들과, Unity를 떠나는 이유에 따라 어느 것을 고를지를 다룹니다.

전체 판도를 나란히 보고 싶다면 2026년 최고의 웹 게임 엔진 비교부터 시작하세요. 이 페이지는 웹에서 Unity를 대체하는 구체적인 경우를 위한 것입니다.

개발자들이 Unity 대안을 찾는 이유

몇 가지 이유가 거듭 등장합니다.

• 가격 신뢰. Unity 런타임 수수료는 2024년 9월에 철회되어 돌아오지 않았지만, 많은 팀에게 "약관이 또 바뀌면 어떡하지?"라는 질문을 염두에 두고 계획하게 만들었습니다. 라이선스 가격을 다시 매길 수 없는 엔진은 그 위험을 없애 줍니다.
• 웹 빌드 크기. Unity의 빈 WebGL 빌드는 약 8~11 MB에서 시작합니다. 웹 네이티브 엔진은 1~5 MB 범위로 나오며, 이는 로딩 시간에서 플레이어가 직접 체감하는 부분입니다.
• 모바일 브라우저 지원. 휴대폰에서 Unity WebGL은 역사적으로 불안정했습니다. 웹을 위해 만들어진 가벼운 엔진들은 모바일 Safari와 Chrome에서 더 잘 동작합니다.
• 오픈 소스. 어떤 팀은 벤더에 의존하지 않고 읽고, 포크하고, 의지할 수 있는 코드베이스를 원합니다.

좋은 소식은, 웹에 한해서는 대안들이 강력하고 그중 여럿이 영원히 무료라는 점입니다.

빠른 비교

"Unity 대체품" 하나로 정해지는 건 없습니다. 알맞은 선택은 3D가 필요한지, 코드를 작성하는지, 그리고 Unity가 왜 맞지 않았는지에 달려 있습니다.

Godot: 가장 두루 쓰이는 대체 엔진

Godot는 전직 Unity 개발자 대부분이 정착하는 대안입니다. 풀 2D/3D 엔진이고, MIT 라이선스로 무료이며 시트, 로열티, 매출 상한이 없고, 웹 익스포트가 탄탄합니다. 빌드 크기는 Brotli 압축으로 약 5 MB여서 기본값 기준 Unity보다 작습니다. Godot 4.3부터는 SharedArrayBuffer 요구 사항을 없앤 싱글스레드 웹 빌드를 익스포트할 수 있는데, 이것이 예전의 iOS 및 Safari 재생 문제도 해결했습니다.

웹에서 한 가지 걸림돌은, Godot의 C#(.NET) 프로젝트는 아직 브라우저로 익스포트할 수 없고 GDScript만 가능하다는 점입니다. C# 코드베이스를 옮기려 한다면 이건 중요합니다. 세부적인 절충점은 웹 게임을 위한 Godot vs Unity에서 다룹니다.

가장 Unity에 가까운 두루 쓰이는 엔진을 원하고, 영원히 무료이며, 깔끔한 2D/3D 웹 경로를 원한다면 Godot를 고르세요.

PlayCanvas: 에디터를 갖춘 웹 우선 3D

PlayCanvas는 처음부터 브라우저를 위해 만들어졌습니다. 런타임은 대략 1~2 MB이고, WebGL2와 WebGPU를 모두 지원하며, Unity의 씬 워크플로를 좋아했다면 익숙하게 느껴질 협업형 클라우드 에디터를 갖추고 있습니다. 게임은 JavaScript로 스크립팅합니다. 브라우저에서 실시간 3D가 필요하고 코드만 다루는 라이브러리가 아니라 비주얼 에디터를 원할 때 강력한 선택지입니다.

Unity 스타일의 3D 씬 편집을 원하면서도 작은 웹 빌드를 원한다면 PlayCanvas를 고르세요.

Three.js와 Cinevva: 최대한의 제어, 가장 작은 용량

가능한 한 가장 가벼운 웹 빌드와 렌더링에 대한 완전한 제어를 원한다면 Three.js가 표준입니다. 코어 라이브러리는 약 150 KB이고 웹상의 3D 가운데 상당한 비중을 떠받치고 있습니다. 풀 엔진이라기보다 렌더링 라이브러리이므로, 게임 시스템을 직접 만들거나 그 위에 프레임워크를 올려야 합니다.

바로 그래서 우리는 Cinevva Engine을 Three.js 위에 만들었습니다. 오픈 소스이고, 웹 우선이며, 게임 시스템이 얹혀 있어 빈 캔버스에서 시작하지 않아도 됩니다. 하나의 코드베이스로 브라우저, 모바일, 데스크톱, Steam, Discord로 출시합니다. 시트도, 설치 비용도, 게임을 다 만든 뒤에 바뀔 수 있는 약관도 없습니다. 바로 런타임 수수료 사건이 사람들에게 중요하게 만든 그 지점입니다.

웹 네이티브 3D, 오픈 소스, 가장 작은 용량을 원하고 JavaScript나 TypeScript가 편하다면 Three.js나 Cinevva를 고르세요.

Defold: 가장 작고 빠른 2D 웹 빌드

Defold는 모든 풀 엔진 가운데 가장 작은 웹 빌드인 약 1.14 MB로 나오고 빠르게 로딩됩니다. 2D와 가벼운 3D를 다루고, Lua로 스크립팅하며, 매출 기준치 없이 무료입니다. 당신의 Unity 게임이 2D이고 로딩 시간이 우선이라면, 웹에서 Defold를 이기기는 어렵습니다.

매 킬로바이트가 중요한 캐주얼 및 모바일 웹 게임에는 Defold를 고르세요.

Cocos Creator: 미니게임과 아시아 시장

Cocos Creator는 WebGL, WebGPU, Wasm을 지원하는 풀 2D/3D 엔진으로, 2~4 MB 범위로 빌드되고 TypeScript로 스크립팅합니다. Unity의 크기가 애초에 불가능한 미니게임 플랫폼(WeChat, TikTok, Taobao)에서 특히 강합니다. 무료입니다.

미니게임을 만들거나 아시아 웹 생태계를 겨냥한다면 Cocos Creator를 고르세요.

Phaser: 2D 웹 표준

게임이 2D이고 JavaScript를 작성한다면, Phaser는 가장 인기 있는 HTML5 게임 프레임워크로 가장 큰 커뮤니티와 생태계를 갖추고 있습니다. 빌드는 약 500 KB입니다. MIT 라이선스로 무료입니다. 2D 웹 게임에는 Unity가 이뤘던 어떤 시절보다도 더 잘 맞는 경우가 많습니다. Defold, Construct, GDevelop과 어떻게 비교되는지는 2026년 최고의 2D 게임 엔진을 보세요.

코드, 커뮤니티, 작은 빌드를 원하는 2D 웹 게임에는 Phaser를 고르세요.

Construct와 GDevelop: 코드 없이 Unity 떠나기

Unity에 답답함을 느낀 이유 중 일부가 코드와 설정의 양이었다면, 비주얼 엔진이 진짜 대안입니다. Construct와 GDevelop 둘 다 프로그래밍 없이 2D 게임을 만들고 깔끔한 웹 빌드를 내보냅니다. GDevelop은 무료 등급이 있고 오픈 소스 친화적이며, Construct는 구독 기반에 잘 다듬어진 에디터를 갖췄습니다.

코드를 거의 또는 전혀 쓰지 않고 웹 게임을 비주얼하게 만들고 싶다면 둘 중 하나를 고르세요.

Unity를 떠나는 이유별로 선택하는 법

• 가격이나 신뢰 때문에 떠났나요? 오픈 소스로 가세요. Godot, Defold, Phaser, Three.js, 또는 Cinevva. 어느 것도 당신 발밑에서 가격을 다시 매길 수 없습니다.
• 브라우저에서 3D가 필요한가요? PlayCanvas(에디터 포함), 또는 Three.js와 Cinevva(제어와 가장 작은 크기).
• 2D를 만드나요? 가장 작은 빌드는 Defold, 가장 큰 커뮤니티는 Phaser.
• 코드를 쓰고 싶지 않나요? Construct 또는 GDevelop.
• 미니게임 플랫폼을 겨냥하나요? Cocos Creator.

무엇을 고르든, 웹은 작은 빌드와 빠른 로딩에 보상합니다. 골랐다면 빠르게 로딩되는 웹 게임 출시하기를 보세요.

자주 묻는 질문

웹 게임에 가장 좋은 Unity 대안은 무엇인가요?

대부분의 팀에게는 Godot입니다. 무료, 오픈 소스, 풀 2D/3D 엔진이며 Unity보다 작은 웹 빌드와 iOS 및 Safari를 위한 깔끔한 싱글스레드 익스포트 경로를 갖췄습니다. 브라우저 우선 3D가 특별히 필요하다면 PlayCanvas나 Three.js가 더 가볍습니다. 최선의 선택은 3D가 필요한지와 코드를 작성하는지에 달려 있습니다.

Unity의 무료 대안이 있나요?

네, 여럿 있습니다. Godot, Defold, Phaser, PixiJS, Excalibur.js, Three.js는 모두 매출 상한이나 시트 비용 없이 무료이고 오픈 소스입니다. Cocos Creator와 GDevelop에도 무료 옵션이 있습니다. 특히 웹 게임에 한해서는, 이 무료 엔진들이 Unity보다 더 작고 빠른 빌드를 내놓는 경우가 많습니다.

웹 게임을 위해 Unity에서 갈아타는 이유는 무엇인가요?

흔한 이유는 빌드 크기(Unity의 빈 WebGL 빌드는 약 8~11 MB에서 시작하는 데 비해 웹 네이티브 엔진은 1~5 MB), 모바일 브라우저 안정성, 2023년 런타임 수수료 사건 이후의 가격 신뢰, 그리고 오픈 소스 선호입니다. 웹이 주요 타깃이라면, 웹 우선 엔진이 대개 더 나은 결과를 줍니다.

Unity를 오픈 소스 엔진으로 대체할 수 있나요?

네. Godot는 일반적인 2D와 3D에서 가장 가까운 오픈 소스 대안이며 MIT 라이선스로 비용이 없습니다. 웹 네이티브 3D에는 Three.js(그리고 Cinevva처럼 그 위에 만들어진 엔진들)도 오픈 소스입니다. 가장 큰 이전 비용은 새로운 언어로 다시 만드는 것인데, 엔진마다 자체 스크립팅 방식이 있기 때문입니다.

어떤 Unity 대안이 가장 작은 웹 빌드를 갖나요?

풀 엔진 중에서는 Defold가 약 1.14 MB로 가장 작습니다. 라이브러리인 Three.js는 코어가 약 150 KB로 더 작지만, 게임 코드는 직접 추가해야 합니다. Godot는 압축 시 약 5 MB로, 여전히 Unity의 8 MB 이상이라는 시작점보다 훨씬 아래입니다.

관련 글

• 2026년 최고의 웹 게임 엔진 (비교) — 순위까지 매긴 전체 판도
• 2026년 최고의 오픈 소스 게임 엔진 — 무료로 직접 포크할 수 있는 옵션들을 한곳에
• 웹 게임을 위한 Godot vs Unity — 가장 가까운 대안, 정면 대결
• Unity 런타임 수수료 철회: 공식 전말 — 가격 신뢰가 결정적 요인이 된 이유
• 2026년 최고의 2D 게임 엔진 — 게임이 2D라면
• PlayCanvas vs Three.js — 웹 3D를 위한 엔진 대 라이브러리
• Cinevva Engine — Three.js 위에 만든 우리의 오픈 소스 웹 우선 엔진

2026년에도 2D는 건재하고, 좋은 엔진은 그 어느 때보다 많습니다. 어떤 엔진이 맞는지는 코딩을 하는지 안 하는지, 웹으로 출시할 것인지, 빌드를 얼마나 작게 만들어야 하는지에 달려 있습니다. 주요 선택지들이 어떻게 비교되고 각각 누구에게 맞는지 정리했습니다.

3D나 풀 크로스 플랫폼 엔진까지 함께 고민하고 있다면 더 폭넓은 웹 게임 엔진 비교를 참고하세요.

한눈에 보기

엔진들

Godot

오픈소스 진영의 인기 엔진이자, 진짜로 훌륭한 2D 엔진입니다. Godot 4.7(2026년 6월)은 전용 2D 렌더러, 가벼운 에디터, 입문자 친화적인 GDScript를 갖췄습니다. MIT 라이선스로 무료이고 로열티도 없습니다. 웹 익스포트는 WebGL2에서 탄탄하지만, 브라우저로 익스포트되는 건 GDScript뿐이고 C#은 안 된다는 점은 알아두세요. 훌륭한 2D와 괜찮은 3D를 둘 다 해내는 무료 도구 하나를 원한다면 이게 기본 선택지입니다.

추천 대상: 올라운드 2D, 오픈소스 프로젝트, 픽셀 아트.

GameMaker

Undertale 같은 히트작과 오랜 상업용 2D 게임 계보를 만들어 낸 엔진입니다. 자체적으로 빠른 스크립팅 언어인 GML을 사용하고, 무료 티어에서도 HTML5 익스포트를 제공합니다. 가격 정책이 친근한 모델로 바뀌었습니다. 비상업용은 무료이고, 상업용 작업은 구독 대신 1회 결제 $99.99의 Pro 라이선스를 씁니다.

추천 대상: 빠르게 출시하고 싶은 상업용 2D, 픽셀 아트.

Construct

이벤트 시스템을 중심으로 만들어진 브라우저 기반 노코드 엔진입니다. 프로그래밍 없이 시각적으로 게임을 만들고, HTML5 네이티브라서 웹 익스포트가 우수합니다. 가격은 구독제로, 티어에 따라 대략 월 $5에서 $39이고 제한된 무료 옵션도 있습니다.

추천 대상: 입문자, 노코드 창작자, 웹 우선 2D.

Defold

전직 King 개발자들이 만든 무료 엔진으로, 놀라울 만큼 작은 웹 빌드를 만들어 냅니다. 흔히 gzip 기준 2 MB 미만입니다. 그래서 로딩 시간이 전부인 캐주얼 웹 게임과 미니게임 플랫폼에 이상적입니다. Lua를 사용하고 Defold License로 소스가 공개되어 있습니다.

추천 대상: 가장 작고 가장 빠르게 로드되는 웹 게임.

Phaser

가장 인기 있는 HTML5 게임 프레임워크이자 코드 우선 엔진입니다. Phaser 4(2026년 4월 출시)는 바닥부터 새로 만든 WebGL 렌더러를 들고 왔습니다. 무료에 오픈소스이고, JavaScript나 TypeScript로 작성하며, 웹 프레임워크라서 별도의 "익스포트" 단계가 없습니다. 게임이 이미 브라우저에서 돌아갑니다.

추천 대상: 코드 우선의 웹 네이티브 2D 프레임워크를 원하는 개발자.

GDevelop

오픈소스이면서 노코드인 GDevelop은 가장 입문자 친화적인 엔진 중 하나입니다. 무료이고 월 $5부터 시작하는 선택형 프리미엄 티어가 있으며, HTML5 빌드를 무제한으로 익스포트합니다. 노코드를 원하면서 오픈소스도 원한다면 좋은 중간 지점입니다.

추천 대상: 무료 노코드 2D.

Unity

Unity의 2D 도구 세트는 성숙했고, 생태계와 에셋 스토어는 따라올 곳이 없습니다. 작은 2D 게임에는 과하지만, 크로스 플랫폼 도달을 원하거나 3D로 확장할 계획이라면 제값을 합니다. 매출 $200K 미만이면 Personal이 무료이고, Pro는 시트당 연 약 $2,200입니다. Godot과 달리 Unity의 C#은 웹으로 익스포트됩니다.

추천 대상: 생태계나 크로스 플랫폼 도달을 원하는 팀.

LÖVE (Love2D)

미니멀한 Lua 프레임워크이고, 풀 에디터는 아닙니다. 코드를 작성하면 실행됩니다. LÖVE 11.5가 현재 안정 버전이고 12.0이 개발 중입니다. 웹 익스포트는 서드파티 love.js를 통해 가능하지만 일급 기능은 아닙니다. 코드 작성을 좋아하고 게임 루프와 나 사이에 거의 아무런 추상화도 두고 싶지 않다면 LÖVE를 골라 보세요.

추천 대상: 코드 중심 취미 개발자와 가벼운 프로토타입.

어떻게 고를까

• 코딩을 하고 싶지 않다면: Construct 또는 GDevelop. 웹으로 출시한다면 Construct, 오픈소스를 원한다면 GDevelop.
• 가장 작고 빠른 웹 빌드를 원한다면: Defold.
• 코드를 작성하고 웹을 노린다면: Phaser.
• 모든 걸 다 하는 무료 엔진 하나를 원한다면: Godot.
• 상업용 2D 게임을 출시한다면: GameMaker 또는 Unity.
• 가장 큰 생태계가 필요하거나 3D를 추가할 계획이라면: Unity.

무엇을 고르든 아트와 오디오가 필요합니다. 바로 가져다 쓸 수 있는 소스는 무료 게임 에셋을 찾을 수 있는 곳을 참고하세요.

자주 묻는 질문

2026년 최고의 2D 게임 엔진은 무엇인가요?

대부분의 사람에게는 Godot이 가장 무난한 올라운드 2D 엔진입니다. 무료에 오픈소스이고 일급 2D 렌더러를 갖췄습니다. 코딩을 하고 싶지 않다면 Construct(웹 우선)나 GDevelop(오픈소스)이 더 낫습니다. 상업용 2D에는 GameMaker와 Unity가 검증되어 있습니다. "최고"가 무엇인지는 코딩을 하는지, 어디로 출시하는지에 달려 있습니다.

입문자에게 가장 좋은 2D 게임 엔진은?

Construct과 GDevelop이 가장 입문자 친화적입니다. 노코드라서 프로그래밍 대신 시각적 이벤트 시스템으로 만들기 때문입니다. GDevelop은 무료에 오픈소스이고, Construct은 구독제이지만 웹 익스포트가 가장 매끄럽습니다. 그 과정에서 코딩도 배우고 싶다면, GDScript를 쓰는 Godot이 코드 기반 엔진 중 가장 부담 없습니다.

최고의 무료 2D 게임 엔진은?

Godot은 비용도 로열티도 없는 가장 강력한 무료 오픈소스 2D 엔진입니다. GDevelop은 최고의 무료 노코드 옵션이고, Defold는 무료이면서 가장 작은 웹 빌드를 만들며, Phaser는 코딩을 한다면 무료 오픈소스 프레임워크입니다. GameMaker는 비상업용은 무료이고, 상업용 프로젝트는 1회 결제 $99.99 라이선스입니다.

가장 작은 웹 게임을 만드는 2D 엔진은?

Defold가 가장 작은 웹 빌드를 만듭니다. 흔히 gzip 기준 2 MB 미만이고, 로딩 시간이 플레이어가 남느냐 떠나느냐를 가르는 캐주얼·미니게임 플랫폼에서 인기 있는 이유입니다. Phaser와 Godot도 무난하지만, 순수 용량에서는 Defold가 앞섭니다.

관련 글

• 2026년 최고의 웹 게임 엔진 (비교) — 2D와 3D, 전체 라인업
• 웹 게임을 위한 Godot vs Unity — 두 대형 엔진 정면 비교
• Construct vs GDevelop — 두 노코드 2D 엔진 비교
• 무료 게임 에셋을 찾을 수 있는 곳 — 2D 게임을 위한 아트와 오디오
• Canvas 2D 게임 루프 — 엔진 없이 2D 게임 만들기
• Cinevva Engine — 우리의 오픈소스, 웹 우선 엔진

코드를 쓰지 않고 게임을 만들고 싶다면 이 둘이 선두를 달립니다. 둘 다 프로그래밍 대신 시각적 이벤트 로직으로 게임을 만들고, 둘 다 웹으로 내보낼 수 있습니다. 가장 큰 차이는 철학과 가격입니다. Construct는 잘 다듬어진 구독 제품이고, GDevelop는 무료 오픈소스입니다. 2026년 기준으로 둘을 비교해 봤습니다.

코드 기반 엔진까지 포함한 더 넓은 비교는 웹 게임 엔진 비교와 2026년 최고의 2D 게임 엔진을 참고하세요.

빠른 결론

노코드, 두 가지 방식

두 엔진 모두 시각적 조건과 액션을 쌓아 게임을 만들 수 있고, 프로그래밍이 필요 없습니다. Construct는 "이벤트 시트"를 사용하는데, 스프레드시트처럼 깔끔한 흐름이라 프로토타이핑 속도가 빠르다는 평가를 널리 받습니다. GDevelop는 비슷한 이벤트 시스템을 사용하며 초보자에게도 똑같이 접근하기 쉽습니다.

가장 중요한 차이는 이겁니다. Construct는 유료의 비공개 소스 제품이고, GDevelop는 MIT 라이선스의 무료 오픈소스입니다. 오픈소스나 무료 비용이 우선이라면 그것만으로 결정이 날 수 있습니다.

가격

Construct 3은 구독제로 운영됩니다. 제한적인 무료 에디션이 있고, Personal 플랜은 월 약 $15.99 또는 연 약 $129.99이며, 그 위로 Education과 Business 등급이 있습니다. 잘 다듬어지고 활발히 개발되는 제품에 비용을 내는 셈입니다.

GDevelop의 엔진은 무료 오픈소스입니다. 선택형 프리미엄 등급(월 약 $7.99 Silver, $13.99 Gold, $39.99 Pro이며 연간 결제 시 약 40% 저렴)은 클라우드 빌드와 온라인 서비스를 추가해 주지만, 게임을 완전히 무료로 만들고 내보낼 수 있습니다. 2026년 1월 신규 구독자 대상으로 가격이 20% 올랐고 기존 구독자는 종전 가격이 유지됩니다.

취미로 만드는 사람이나 비용에 민감한 사람에게는 GDevelop의 무료 등급을 반박하기 어렵습니다. 다듬어진 상용 도구를 원하는 스튜디오에는 Construct의 구독료가 합리적입니다.

3D, 스크립팅, 멀티플레이어

3D: 여기서는 GDevelop가 앞서나갔습니다. 5.6 릴리스(2025년 12월)에는 Jolt 기반 물리, 그림자, 애니메이션 모델, 3D 파티클, 그리고 바로 쓸 수 있는 캐릭터와 차량 동작을 갖춘 완전한 실시간 3D 에디터가 들어갔고, 이후 5.6 업데이트에서 3D 점 조명과 스포트라이트가 추가됐습니다. Construct도 따라잡는 중입니다. r487 안정 버전(2026년 5월)은 기존의 3D 카메라와 glTF 모델 지원에 더해 기즈모가 있는 3D 에디터 모드와 3D 총알 동작을 추가했습니다. 실질적인 진전이지만, 여전히 근본적으로 2D인 엔진 위에 얹은 형태입니다.

스크립팅: 이벤트만으로 부족해지면 둘 다 코드로 내려갈 수 있습니다. Construct는 이벤트 시트와 함께 JavaScript와 TypeScript를 지원합니다. GDevelop는 이벤트와 확장 기능을 통해 JavaScript를 지원합니다. 둘 다 노코드 경로를 우선으로 둡니다.

멀티플레이어: Construct는 P2P 게임을 위한 WebRTC 데이터 채널 기반의 내장 Multiplayer 객체를 제공합니다. GDevelop는 온라인 서비스를 통해 로비 기반의 내장 멀티플레이어를 제공하며, 무료 플랜은 4인 로비 1개로 제한되고 유료 플랜은 8인으로 늘어납니다.

어느 쪽을 골라야 할까

무료 오픈소스, 크로스 플랫폼 내보내기, 그리고 더 강력한 실시간 3D 에디터를 원한다면 GDevelop를 고르세요. 취미 창작자, 학생, 그리고 자신의 도구를 직접 소유하고 싶은 사람에게 더 잘 맞습니다.

가장 다듬어진 이벤트 시트 워크플로, 성숙하고 안정적인 HTML5 내보내기, 내장 WebRTC 멀티플레이어를 원하고, 다듬어진 상용 제품에 대한 구독이 괜찮다면 Construct를 고르세요.

어느 쪽이든 아트와 오디오가 필요합니다. 바로 쓸 수 있는 소스는 무료 게임 에셋을 찾는 곳을 참고하세요.

자주 묻는 질문

초보자에게는 Construct와 GDevelop 중 어느 쪽이 더 좋나요?

둘 다 초보자를 위해 설계되었고 코딩 없이 시각적 이벤트 로직을 사용합니다. GDevelop는 비용 면에서 앞서고(무료 오픈소스), 이제 더 강력한 3D 에디터를 갖췄습니다. Construct는 워크플로의 완성도와 내장 멀티플레이어에서 앞섭니다. 예산이 중요하다면 GDevelop로 시작하세요. 가장 다듬어진 2D 이벤트 워크플로를 원한다면 Construct의 무료 에디션을 먼저 써 보세요.

GDevelop는 정말 무료인가요?

네. GDevelop 엔진은 MIT 라이선스의 무료 오픈소스이며, HTML5 게임을 무료로 빌드하고 내보낼 수 있습니다. 선택형 프리미엄 등급(월 약 $7.99부터)은 클라우드 빌드와 온라인 서비스를 추가하지만, 게임을 만들고 출시하는 데 꼭 필요하지는 않습니다.

Construct와 GDevelop로 3D 게임을 만들 수 있나요?

둘 다 3D가 있지만 GDevelop가 더 앞서 있습니다. GDevelop 5.6(2025년 12월)은 물리, 그림자, 애니메이션 모델을 갖춘 완전한 실시간 3D 에디터를 추가했습니다. Construct는 r487(2026년 5월)에서 3D 카메라와 glTF 모델 지원에 더해 자체 3D 에디터 모드를 추가했지만, 여전히 주로 2D 엔진입니다. 3D에 무게를 두는 프로젝트라면 GDevelop가 더 강한 노코드 선택지입니다.

Construct와 GDevelop는 웹으로 내보낼 수 있나요?

네, 둘 다 브라우저에서 실행되는 HTML5 게임을 내보냅니다. Construct는 HTML5 네이티브로 성숙하고 안정적인 웹 내보내기를 제공합니다. GDevelop는 로컬을 포함해 무제한 HTML5 빌드를 무료로 내보냅니다. 둘 다 브라우저 게임에 탄탄한 선택지입니다.

관련 글

• 2026년 최고의 2D 게임 엔진 — 코드와 노코드를 포함한 2D 전체 비교
• 2026년 최고의 웹 게임 엔진 (비교) — 2D와 3D
• 무료 게임 에셋을 찾는 곳 — 게임을 위한 아트와 오디오
• itch.io에 게임을 출시하는 법 — 플레이어 앞에 게임을 내놓기
• Cinevva — 웹 우선의 AI 도구로 게임 만들기

Godot와 Unity 둘 다 게임을 브라우저로 내보낼 수 있습니다. 다만 거기에 도달하는 방식이 아주 다르고, 특히 웹에 한해서는 일반적인 "Godot vs Unity" 논쟁이 말하는 것보다 둘 사이의 격차가 더 또렷합니다. 이 가이드는 웹 빌드를 실제로 좌우하는 요소들, 즉 다운로드 크기, 렌더링, 언어 지원, 모바일 브라우저, 비용을 기준으로 둘을 비교합니다.

모든 브라우저 엔진을 아우르는 더 넓은 그림을 원한다면 웹 게임 엔진 비교부터 시작하세요. 이 페이지는 풀 기능 엔진이라는 두 가지 큰 선택지에 초점을 맞춥니다.

빠른 결론

가장 큰 결정 요인 하나는 이겁니다. 당신의 게임이 C#로 작성됐다면 Unity는 그걸 웹으로 내보낼 수 있고 Godot는 여전히 못 합니다. 나머지는 전부 여기서 갈립니다.

빌드 크기와 로딩 시간

다운로드 크기는 웹 플레이어가 가장 먼저 체감하는 부분입니다. Godot의 웹 익스포트는 엔진을 WebAssembly 바이너리로 내보내는데, 압축 해제 시 약 40 MB지만 Brotli로 압축하면 대략 5 MB가 됩니다. 이 크기는 미리 빌드된 템플릿이 엔진 전체(3D 렌더러, 오디오, 네트워킹)를 담고 있기 때문입니다. 게임이 어떤 기능을 쓸지 미리 알 수 없으니까요.

Unity의 빈 웹 빌드는 Unity 6에서 Brotli로 측정했을 때 2D built-in 파이프라인 프로젝트는 약 7.7 MB, 3D URP 템플릿은 약 10.7 MB 정도입니다. 공격적으로 최소화한 빌드는 약 2 MB까지 줄일 수 있습니다. 그래서 잘 다듬은 Unity 2D 빌드는 Godot의 용량에 근접할 수 있지만, Godot는 기본값이 더 작고 손도 덜 갑니다.

두 엔진 모두 보통은 에셋이 엔진 바이너리보다 훨씬 큽니다. 텍스처와 오디오를 압축하고 가능한 건 스트리밍하면, 엔진 선택보다 에셋 예산이 더 중요해집니다.

C# 제약 (선택하기 전에 꼭 읽어 보세요)

이 부분에서 팀들이 발목을 잡힙니다. 2026년 기준, C#(.NET)로 작성한 Godot 프로젝트는 공식적으로 웹으로 익스포트할 수 없습니다. GDScript는 문제없이 익스포트됩니다. 2025년 5월 GodotCon Boston에서 Mono를 정적 링크해 동작하는 C# 웹 프로토타입을 시연했지만, 페이로드가 컸고 팀은 출시 일정을 확정하지 않았습니다.

반면 Unity는 C#를 WebAssembly로 컴파일하며 수년간 C#를 브라우저로 내보내 왔습니다. 그러니 기존 C# 코드베이스가 있거나 팀이 C#만 안다면, 웹에서는 Unity가 현실적인 선택입니다. 새로 시작하는 데다 GDScript가 편하다면 Godot의 웹 경로가 깔끔합니다.

렌더링: WebGL2 vs WebGPU

Godot의 웹 익스포트는 Compatibility 렌더러를 통해 WebGL2를 타깃으로 합니다. 더 광범위한 WebGPU 작업은 아직 웹 익스포트용으로 프로덕션 준비가 안 됐습니다. Godot 4.5(2025년 9월)는 WebAssembly SIMD를 추가했는데, 코드 변경 없이 웹 성능을 끌어올려 줍니다.

Unity 6는 실험적 WebGPU 백엔드를 추가해 WebGL2를 넘어서는 컴퓨트 셰이더와 최신 GPU 기능을 노출했고, WebGL2는 여전히 안전한 폴백으로 남아 있습니다. WebGPU는 아직 모든 브라우저에서 쓸 수 있는 건 아니니(현재 지원 현황은 웹 게임 기술 스택 가이드 참고) 기본값이 아니라 업그레이드 경로로 다루세요. Unity 6는 WebAssembly 힙을 4 GB로 올렸고 Wasm SIMD와 네이티브 예외도 추가했습니다.

오늘 브라우저에서 컴퓨트 셰이더나 더 무거운 3D가 필요하다면 Unity의 WebGPU 경로가 앞서 있습니다. WebGL2 위의 2D와 가벼운 3D라면 둘 다 괜찮습니다.

스레딩, iOS, 그리고 호스팅의 골칫거리

Godot 4는 원래 SharedArrayBuffer가 필요했는데, 브라우저는 페이지가 cross-origin isolated일 때만(COOP과 COEP 헤더) 이걸 노출합니다. 이건 호스팅에서 골칫거리고, itch.io에서는 Chrome에서만 동작합니다. Godot 4.3부터는 싱글스레드 빌드를 내보내 이 요구 사항을 완전히 없앨 수 있고, 그 변경 덕분에 오래된 iOS와 Safari 재생 문제도 해결됐습니다. 웹 우선 Godot 게임이라면 보통 싱글스레드 익스포트가 더 안전한 기본값입니다.

Unity의 웹 빌드도 WebAssembly를 쓰며, 모바일 웹 지원은 Unity 6부터 시작됩니다. 폭넓은 모바일 브라우저를 노린다면 두 엔진 모두 실제 기기에서 일찌감치 테스트하세요. 웹 빌드는 거기서 가장 먼저 깨지니까요.

가격

Godot는 MIT 라이선스로 무료입니다. 시트도, 로열티도, 매출 상한도, 수수료도 없습니다. 영원히요.

Unity는 2024년 9월 Runtime Fee를 취소한 뒤 시트 기반 구독으로 돌아갔습니다(Runtime Fee는 다시 돌아오지 않았습니다). Unity Personal은 매출 또는 투자금이 $200K에 이를 때까지 무료로 유지되고, "Made with Unity" 스플래시는 Unity 6에서 선택 사항이 됐습니다. Unity Pro는 시트당 연간 약 $2,200이며, 2026년 초에 유료 등급이 대략 5% 인상됐습니다. 상한 아래에 있는 1인 개발자나 소규모 팀이라면 두 엔진 모두 사실상 무료로 출시할 수 있습니다.

무엇을 언제 골라야 하나

무료에 용량이 작은 2D나 가벼운 3D 브라우저 게임을 원하고, 싱글스레드 익스포트를 통한 매끄러운 iOS와 Safari 지원을 원하며, GDScript 작성이 편하다면 웹에서는 Godot를 고르세요.

WebGPU를 통한 더 무거운 3D나 컴퓨트 셰이더가 필요하거나, 더 큰 에셋 생태계를 원하거나, C# 팀이고, 더 큰 빌드와 실험적 WebGPU라는 단서를 받아들일 수 있다면 웹에서는 Unity를 고르세요.

어느 쪽이든 당신의 빌드는 여전히 빠르게 로드되고 휴대폰에서 돌아가야 합니다. 선택을 마쳤다면 빠르게 로드되는 웹 게임 출시하기를 참고하세요.

자주 묻는 질문

Godot는 C# 게임을 웹으로 익스포트할 수 있나요?

2026년 기준으로는 공식적으로 불가능합니다. Godot의 웹 익스포트는 GDScript에서는 동작하지만, C#(.NET) 프로젝트는 아직 브라우저로 내보낼 수 없습니다. 2025년 5월 GodotCon Boston에서 프로토타입이 공개됐지만 확정된 출시일은 없습니다. 웹에서 C#가 필요하다면 둘 중 현재 그걸 지원하는 건 Unity뿐입니다.

웹 빌드는 Godot와 Unity 중 어느 쪽이 더 작나요?

Godot의 빈 웹 빌드는 Brotli로 압축하면 약 5 MB입니다. Unity 6의 빈 빌드는 2D는 약 7.7 MB, 3D는 약 10.7 MB이며, 공격적으로 최소화한 Unity 빌드는 약 2 MB까지 줄일 수 있습니다. 기본값으로는 Godot가 더 작지만, 잘 튜닝한 Unity 2D 빌드는 근접할 수 있습니다. 보통은 엔진 바이너리보다 당신의 에셋이 더 중요합니다.

Unity는 브라우저에서 WebGPU를 지원하나요?

네, Unity 6는 컴퓨트 셰이더와 최신 GPU 기능을 갖춘 실험적 WebGPU 백엔드를 추가했고, WebGL2가 폴백입니다. 실험적이라고 표시돼 있고 모든 브라우저에서 지원되는 건 아니니, WebGL2를 기본값으로 출시하고 WebGPU는 향상 요소로 다루세요.

브라우저 게임에는 Godot와 Unity 중 어느 쪽이 더 나은가요?

무료에 가벼운 2D나 가벼운 3D 게임을 iOS 지원까지 잘 갖추려면, GDScript를 쓴다는 전제에서 Godot가 더 깔끔한 웹 경로입니다. 더 무거운 3D, 컴퓨트 셰이더, 더 큰 생태계, 또는 기존 C# 코드베이스가 있다면 웹에서는 Unity가 이깁니다. 보통은 C# 문제가 결정타입니다.

관련 글

• 2026년 최고의 웹 게임 엔진 (비교) — 이 둘을 넘어선 전체 라인업
• 웹 게임을 위한 Unity 대안 — Unity를 떠나는 이유별로 고른 모든 웹 대응 옵션
• 2026년 최고의 2D 게임 엔진 — 게임이 2D라면 여기서 시작하세요
• 2026년 웹 게임 기술 스택 — WebGL, WebGPU, Wasm 설명
• 빠르게 로드되는 웹 게임 출시하기 — 빌드 크기와 로딩 시간 전술
• Cinevva Engine — Three.js 기반의 오픈소스, 웹 우선 엔진

사람들은 이 둘을 라이벌로 놓고 비교하지만, 사실 같은 종류의 도구가 아닙니다. PlayCanvas는 비주얼 에디터를 갖춘 풀 게임 엔진입니다. Three.js는 코드로 직접 쌓아 올리는 렌더링 라이브러리고요. 둘 중 무엇을 고를지는 결국 얼마나 많은 걸 알아서 챙겨 받고 싶은지, 아니면 얼마나 많은 걸 직접 통제하고 싶은지의 문제입니다. 2026년 웹 3D 기준으로 정리해 보겠습니다.

더 넓은 범위가 궁금하다면 웹 게임 엔진 비교를 참고하세요.

한눈에 보는 결론

엔진 대 라이브러리

이 한 줄에 모든 이야기가 담겨 있습니다. PlayCanvas는 게임 엔진을 줍니다. 엔티티-컴포넌트 시스템, 물리, 애니메이션, 오디오, 입력, 그리고 에셋 파이프라인까지 전부 서로 연결된 상태로 제공하고, 거기에 팀이 실시간으로 함께 씬을 만들 수 있는 브라우저 기반 에디터도 따라옵니다 (3D를 위한 디자인 도구처럼 협업 편집이 된다고 보면 됩니다).

Three.js는 렌더러를 줍니다. 씬 그래프, 카메라, 조명, 머티리얼, 그리고 빠른 WebGL/WebGPU 렌더러를 제공합니다. 에디터도 없고, 물리도 없고, 게임 루프에 대한 정해진 방식도 없습니다. 물리는 Rapier나 cannon-es 같은 걸로 직접 붙이고, 게임 로직 구조도 스스로 짜고, 필요한 도구도 직접 만들어야 합니다. 그만큼 자유롭지만 일도 더 많죠.

그러니 진짜 질문은 "어느 쪽이 더 나은가"가 아니라 "나는 엔진이 필요한가, 렌더러가 필요한가"입니다.

렌더링과 WebGPU

GPU 측면에서는 둘 다 현대적입니다. PlayCanvas는 WebGL2와 WebGPU를 함께 쓰는 듀얼 백엔드로 돌아갑니다. v2.0 릴리스 (2024년 8월)에서 WebGL1을 완전히 버렸고, 최근 엔진 빌드에는 3D 가우시안 스플랫을 위한 컴퓨트 기반 WebGPU 경로가 추가됐습니다. Three.js는 r171 무렵 (2025년 9월)에 거의 설정이 필요 없고 WebGL2 자동 폴백을 갖춘 프로덕션급 WebGPURenderer를 내놓았고, 셰이더를 한 번 작성해 두 백엔드를 모두 겨냥할 수 있는 TSL (Three.js Shading Language)도 함께 제공합니다.

2026년의 대부분 프로젝트에서는 둘 다 아름답게 렌더링됩니다. WebGPU는 양쪽 모두의 업그레이드 경로고, WebGL2는 안전한 기준선입니다. 현재 브라우저 지원 상황은 웹 게임 기술 스택 가이드를 참고하세요.

워크플로, 라이선스, 비용

PlayCanvas의 간판 기능은 에디터입니다. 에셋 파이프라인을 갖춘, 호스팅형 협업 씬 에디터죠. 엔진은 MIT로 오픈소스이고, 에디터 프론트엔드도 2025년에 오픈소스로 공개됐습니다. 호스팅 에디터에는 등급이 나뉘어 있는데, 무료 플랜, 월 $15가량의 Personal 플랜, seat당 월 $50가량의 Organization 플랜이 있고, 주로 저장 용량과 비공개 프로젝트 한도에서 차이가 납니다.

Three.js는 MIT에 무료, 그게 전부입니다. 돈을 낼 에디터가 없습니다. 에디터 자체가 없으니까요. 여기서의 "비용"은 PlayCanvas가 알아서 챙겨 주는 구조를 직접 쌓는 데 드는 엔지니어링 시간입니다.

언제 무엇을 고를까

다음과 같다면 PlayCanvas를 고르세요. 완성된 엔진과 비주얼 에디터를 바로 쓰고 싶고, 팀이 씬 작업을 함께 협업해야 하며, 처음부터 만들기보다 설정하는 쪽을 선호한다면요. 제품 컨피규레이터, 인터랙티브 3D, 그리고 빠르게 출시하려는 팀에 특히 강합니다.

다음과 같다면 Three.js를 고르세요. 렌더링과 아키텍처를 완전히 통제하고 싶고, 자기만의 스택을 직접 조립하는 게 편하거나, 엔진이 정해 둔 방식이 오히려 방해가 될 만큼 맞춤형인 걸 만들고 있다면요. 생태계도 더 크고, 웹 3D에서 가장 수요가 많은 기술이기도 합니다. 우리는 바로 그 이유로 Cinevva Engine을 Three.js 위에 만들었습니다. 웹 우선, 개방형, 그리고 우리가 커스터마이즈할 수 있는 범위에 천장이 없으니까요.

자주 묻는 질문

웹 게임에는 PlayCanvas와 Three.js 중 어느 게 더 나은가요?

어느 한쪽이 무조건 낫다기보다 서로 다른 도구입니다. PlayCanvas는 비주얼 에디터를 갖춘 풀 엔진이라 구조가 잡힌 게임이나 인터랙티브 앱을, 특히 팀 단위로 더 빨리 출시할 수 있습니다. Three.js는 완전한 통제권을 주지만 게임 시스템은 직접 만들 것을 전제하는 렌더링 라이브러리고요. 턴키를 원하면 PlayCanvas, 커스텀을 원하면 Three.js를 고르세요.

Three.js는 게임 엔진인가요?

아닙니다. Three.js는 3D 렌더링 라이브러리입니다. 씬 그래프, 카메라, 조명, 머티리얼, 그리고 WebGL2 또는 WebGPU를 통한 렌더링을 처리하지만, 내장 물리, 오디오, 입력, 게임 루프는 없습니다. 그런 건 다른 라이브러리로 (예를 들어 물리는 Rapier로) 붙이거나 직접 만들어야 합니다. 반면 PlayCanvas는 풀 엔진입니다.

PlayCanvas와 Three.js는 WebGPU를 지원하나요?

네, 2026년 기준으로 둘 다 지원합니다. PlayCanvas는 WebGL2/WebGPU 듀얼 백엔드로 돌아갑니다. Three.js에는 (r171 무렵부터 안정화된) 프로덕션급 WebGPURenderer가 있고, WebGL2 자동 폴백과 교차 타깃 셰이더용 TSL을 갖췄습니다. WebGL2를 기준선으로 출시하고 WebGPU는 성능 업그레이드로 다루세요.

PlayCanvas는 무료인가요?

PlayCanvas 엔진은 MIT 라이선스로 무료 오픈소스이고, 에디터 프론트엔드도 2025년에 오픈소스로 공개됐습니다. 호스팅형 클라우드 에디터에는 무료 등급과 함께 유료 플랜이 있는데 (Personal 월 $15가량, Organization seat당 월 $50가량), 주로 저장 용량과 비공개 프로젝트를 더해 줍니다. Three.js는 돈을 낼 에디터가 없으니 완전히 무료입니다.

관련 글

• 2026년 최고의 웹 게임 엔진 (비교) — 전체 비교
• Three.js vs Babylon.js — 웹 3D 라이브러리로 범위를 좁혔다면
• 웹 게임을 위한 Godot vs Unity — 라이브러리 대신 풀 엔진
• 2026년 웹 게임 기술 스택 — WebGL, WebGPU, Wasm
• Cinevva Engine — Three.js 위에 만든 우리의 오픈소스 엔진

이 둘은 웹 3D의 양대 산맥이고, 둘 중 무엇을 고를지는 결국 철학의 문제로 귀결됩니다. Three.js는 여러분이 직접 확장하는 가벼운 렌더러입니다. Babylon.js는 도구가 처음부터 상자 안에 들어 있는 풀 엔진입니다. 둘 다 훌륭하고, 둘 다 무료이며, 둘 다 2026년에 WebGPU를 지원합니다. 어떻게 고를지 정리해 봤습니다.

대신 2D 엔진이나 풀 게임 엔진을 찾고 있다면 웹 게임 엔진 비교를 참고하세요.

한눈에 보는 결론

라이브러리 vs 프레임워크

Three.js는 코어를 작게 유지하고 나머지는 여러분과 커뮤니티에 맡깁니다. 훌륭한 렌더러, 씬 그래프, 머티리얼을 제공하고, 물리나 후처리, 컨트롤이 필요하면 애드온을 가져다 씁니다. 가장 인기 있는 웹 3D 라이브러리이고 생태계가 가장 크기 때문에 예제도, 튜토리얼도, 채용 가능한 인력 풀도 더 많습니다.

Babylon.js는 마이크로소프트가 뒷받침하는 더 완성된 엔진입니다. 물리, GUI 시스템, 애니메이션, 씬을 디버깅하는 내장 Inspector, 코드를 공유하는 온라인 Playground, 셰이더를 시각적으로 만드는 Node Material Editor를 함께 제공합니다. 직접 조립하기보다 도구와 구조가 갖춰져 있길 원한다면 Babylon이 첫날부터 더 많은 걸 손에 쥐여 줍니다.

2026년의 WebGPU

이제 둘 다 WebGPU에 진지합니다. Babylon.js 8.0 (2025년 3월)은 모든 코어 엔진 셰이더를 GLSL과 WGSL 양쪽으로 제공하게 했고, 이로 인해 수 메가바이트짜리 변환 레이어가 사라져 WebGPU를 타깃으로 할 때 엔진 크기가 대략 절반으로 줄었습니다. Babylon.js 9.0 (2026년 3월)은 클러스터드 라이팅, 컴퓨트 셰이더 기반 볼류메트릭 라이팅, 프레임 그래프, 에어리어 라이트로 한발 더 나아갔습니다.

Three.js에는 WebGL2로 자동 폴백되는 프로덕션 준비가 된 WebGPURenderer가 있고, TSL을 쓰면 두 백엔드용 셰이더를 한 번만 작성하면 됩니다. 최근 릴리스마다 이걸 계속 다듬고 있습니다.

요약하면 WebGPU는 둘 다 탄탄합니다. Babylon은 컴퓨트 셰이더 기반 기능에 무게를 싣고, Three.js는 렌더러를 가볍고 유연하게 유지합니다.

TypeScript, 번들 크기, 생태계

Babylon.js는 거의 전부 TS로 작성된 TypeScript 우선 엔진이라, 큰 코드베이스를 다루는 많은 팀이 선호합니다. Three.js는 JavaScript이고 별도의 타입 정의가 함께 제공되는데, 잘 작동하긴 하지만 진실의 원천(source of truth)은 아닙니다.

크기 면에서는 Three.js의 코어가 더 작고 트리 셰이킹이 잘 되기 때문에 최소한의 씬은 더 적은 코드를 내보냅니다. Babylon은 더 크지만 범위가 나뉜 패키지로 모듈화되어 있고, WGSL 네이티브 경로가 WebGPU에서의 격차를 좁혔습니다.

생태계는 순수한 규모와 커뮤니티 산출물 면에서 Three.js의 손을 들어 줍니다. 기본 포함된 도구는 Babylon이 앞섭니다.

무엇을 언제 고를까

가볍고 유연한 렌더러, 가장 큰 생태계, 그리고 원하는 방식대로 구조를 짤 자유를 원한다면 Three.js를 고르세요. 커스텀 웹 3D 작업의 기본 선택지이고, 가장 폭넓게 통용되는 기술입니다.

강력한 내장 도구(Inspector, Playground, Node Material Editor), TypeScript 우선 개발, 기업이 뒷받침하는 안정성을 원하고, 모든 것이 포함된 대가로 번들 크기를 조금 양보해도 괜찮다면 Babylon.js를 고르세요.

둘 다 좋은 선택입니다. 우리는 Cinevva Engine에 Three.js를 택했는데, 직접 다듬을 수 있는 가볍고 웹 우선적인 토대를 원했기 때문입니다.

자주 묻는 질문

Three.js와 Babylon.js 중 어느 쪽이 더 좋나요?

둘 다 훌륭하고 무료입니다. Three.js는 생태계가 가장 큰 미니멀 렌더러로, 유연함을 원하고 직접 구조를 만들고 싶을 때 가장 좋습니다. Babylon.js는 물리, GUI, Inspector, Playground를 내장한 더 완성된 엔진으로, 도구가 갖춰진 환경과 TypeScript 우선 개발을 원할 때 가장 좋습니다. 품질의 격차가 아니라 철학의 선택입니다.

Three.js와 Babylon.js는 WebGPU를 지원하나요?

네, 2026년에 둘 다 WebGPU를 지원합니다. Three.js에는 WebGL2 폴백과 크로스 타깃 셰이더용 TSL을 갖춘 프로덕션 준비가 된 WebGPURenderer가 있습니다. Babylon.js 8.0은 코어 셰이더를 WGSL 네이티브로 만들었고(WebGPU에서 번들 크기를 줄였습니다), 9.0은 볼류메트릭 라이팅 같은 컴퓨트 셰이더 기능을 추가했습니다. WebGL2를 기준선으로 내보내고 가능한 곳에서 WebGPU를 쓰세요.

Babylon.js는 게임 엔진이고 Three.js는 아닌가요?

대체로 그렇습니다. Babylon.js는 풀 엔진입니다. 물리, GUI 시스템, 애니메이션, Inspector, 에디터 스타일의 도구를 포함합니다. Three.js는 3D를 그리는 데 집중한 렌더링 라이브러리라서, 물리, 컨트롤, 게임 시스템은 다른 패키지나 직접 작성한 코드로 추가합니다. 이게 둘 사이의 핵심 차이입니다.

Three.js와 Babylon.js 중 어느 쪽이 더 작나요?

Three.js의 코어가 더 작고 트리 셰이킹이 잘 되기 때문에 최소한의 씬은 더 적은 JavaScript를 내보냅니다. Babylon.js는 전체적으로 더 크지만 범위가 나뉜 패키지로 모듈화되어 있고, 8.0의 WGSL 네이티브 셰이더가 WebGPU를 타깃으로 할 때 크기를 대략 절반으로 줄였습니다. 가장 작은 번들을 원한다면 여전히 Three.js가 이깁니다.

관련 글

• PlayCanvas vs Three.js — 비교에 비주얼 에디터를 더하기
• 2026년 최고의 웹 게임 엔진 (비교) — 전체 진영
• 2026년 웹 게임 기술 스택 — WebGL, WebGPU, Wasm
• 브라우저에서의 Three.js + USDC — Three.js에서 USD 3D 에셋 불러오기
• Cinevva Engine — Three.js 위에 구축한 우리의 오픈소스 엔진

게임을 켜면서 "부호 거리 함수에 Hermite 보간을 적용한 부드러운 감쇠 함수를 쓰고 싶다"고 생각하는 사람은 없습니다. 사람들이 생각하는 건 "동굴을 파고 싶다"거나 "산을 쌓고 싶다"거나 "강을 만들고 싶다"입니다.

지형을 빚는 일의 기술적인 면(마칭 큐브, SDF 브러시, 트랜스복셀 이음매)은 우리의 짝꿍 리서치 가이드에서 다룹니다. 이 가이드는 문제의 나머지 절반을 다룹니다. 어떻게 하면 빚는 힘을 캐주얼 플레이어의 손에 쥐여주면서, 3D 모델링 도구가 아니라 놀이처럼 느껴지게 만들 수 있는가입니다.

은유 문제

플레이어가 지형을 다시 빚게 해주고 실제로 출시된 게임은 모두 같은 디자인 문제를 풀었습니다. 날것 그대로의 빚기 매개변수(반지름, 강도, 감쇠, 연산 종류)는 대부분의 플레이어에게 아무 의미가 없습니다. 해법은 늘 똑같습니다. 브러시를 플레이어가 이미 이해하고 있는 은유로 감싸는 것입니다.

Minecraft: 보편적 은유로서의 블록

Minecraft의 천재성은 지형 편집이 그냥 인벤토리 관리라는 데 있습니다. 블록을 깹니다. 블록을 얻습니다. 블록을 놓습니다. "브러시"는 단일 복셀이고, "감쇠"는 이진(영향을 받거나 안 받거나)이며, "연산"은 더하기 아니면 빼기입니다.

TNT는 이걸 키웁니다. 화약과 모래(플레이하면서 이미 모아둔 재료들)로 제작하고, 다른 블록처럼 놓고, 부싯돌과 부시로 불을 붙이면 지형에서 구를 깎아냅니다. 폭발 반경은 4~7블록입니다. 폭발 저항은 재질마다 다릅니다. 흙과 모래는 산산이 부서지고, 돌은 일부만 살아남고, 흑요석은 면역입니다. 물은 블록 파괴를 무효화하지만 엔티티 피해는 막지 못합니다.

플레이어는 폭발 반경을 매개변수로 생각하지 않습니다. "TNT는 세고, 흑요석은 단단하고, 물은 방패다"라고 생각합니다. 지형 편집 시스템 전체가 플레이어가 이미 아는 재료와 아이템을 통해 온전히 표현됩니다.

Valheim: 농부의 도구 상자

Valheim은 다른 길을 택합니다. 블록 대신, 산업화 이전 농경에서 따온 도구들을 플레이어에게 줍니다.

괭이(나무 5 + 돌 2, 처음 10분 안에 확보 가능)는 네 가지 모드가 있습니다. 지면 평탄화(서 있는 높이로 평평하게), 지면 융기(흙을 더함, 사용마다 돌 2 소모), 길(잔디 제거), 포장(자갈 깔기)입니다. 평탄화 메커니즘이 기발합니다. 원하는 지면 높이에 직접 서면, 괭이가 주변 전부를 그 높이에 맞춥니다. 숫자 입력이 없습니다. 당신의 발이 기준입니다.

경작기(청동 5 + 핵심 목재 5, 제련 필요)는 심기를 담당합니다. 흙을 갈고, 씨앗을 심고, 풀을 키우고, 식생을 되살립니다. 지형을 빚지는 않지만 지형을 꾸밉니다. 괭이로 산비탈을 평평하게 만든 뒤, 그곳을 경작해 숲을 심습니다. 지형이 이야기를 들려줍니다. 누군가 여기 있었고, 이 땅을 일궜다는 이야기입니다.

곡괭이는 파괴하는 쪽을 맡습니다. 지형을 파고들며, 괭이의 융기와 정반대입니다. 세 도구가 함께(곡괭이는 파고, 괭이는 올리고/평평하게 하고, 경작기는 심고) 현실 세계의 농경 동작에 대응하는 완전한 어휘를 이룹니다.

비용 모델이 중요합니다. 지면을 올리는 데는 돌이 듭니다. 편집 하나하나의 무게를 느끼게 됩니다. 산을 공짜로 변형하지 않습니다. 자원 비용은 빚기를 체크박스가 아니라 하나의 결정으로 만듭니다.

Animal Crossing: 벌어서 얻는 지형 변형

Animal Crossing: New Horizons는 지형 변형을 별 3개 섬 평점 뒤에 가둡니다. 캠프장을 짓고, 주민을 초대하고, 주택 부지를 만들고, 며칠(게임 시간이 아니라 실제 며칠) 동안 섬을 발전시켜야 너굴이 섬 디자이너 앱을 건네줍니다. 지형 변형을 해금할 즈음이면 당신은 그 섬을 이해하고 있습니다. 강이 어디 있는지, 어떤 절벽이 좋아하는 경치를 가리는지, 무엇을 바꾸고 싶은지 알게 됩니다.

도구 자체는 허가증 시스템을 씁니다. 길은 무료입니다. 물길 조성(강, 연못, 폭포 만들기)은 마일리지 6,000이 듭니다. 절벽 공사는 또 6,000이 듭니다. 추가 길 종류는 각각 2,000입니다. 플레이로 벌어들인 화폐를 써서 창작 도구함을 넓히는 것입니다.

편집은 타일 기반입니다. 한 번에 한 칸씩입니다. 반지름 슬라이더가 없습니다. 강도 매개변수가 없습니다. 절벽 한 타일을 밀어 올리거나 강 한 타일을 파냅니다. 이 제약이 접근성을 만듭니다. 저지를 수 있는 최악의 실수도 버튼 한 번으로 되돌립니다. 이 디자인은 계획(커뮤니티는 레이아웃을 미리 짜는 브라우저 도구 Happy Island Designer를 만들었습니다)과 시간을 두고 조금씩 다듬는 작업을 장려합니다.

절벽은 최대 3단까지 올라갑니다. 강은 바다와 이어져야 합니다. 특정 랜드마크(공항, 안내소)는 옮길 수 없습니다. 이 제약들은 한계가 아닙니다. 디자인입니다. 자유 형식 편집기에서 캐주얼 참여를 죽이는 "빈 캔버스 마비"를 막아줍니다.

No Man's Sky: 멀티툴

No Man's Sky는 지형 조작을 총에 얹습니다. 지형 조작기는 멀티툴 업그레이드로 네 가지 모드가 있습니다. 채굴(구 모양으로 지형을 제거), 생성(구나 정육면체 모양으로 지형을 추가), 복원(원래 생성된 상태로 되돌림), 평탄화(넓은 영역을 고름)입니다.

은유는 손에 쥐는 SF 장치입니다. 겨누고 쏘면 세계를 편집합니다. T와 R 키로 구의 크기를 세 가지 프리셋(소, 중, 대) 사이에서 바꿉니다. 숫자 반지름은 없습니다. 세 가지 크기. 그게 UI 전부입니다.

이 도구는 첫 번째 임무에서 소개됩니다. 탐험을 시작할 즈음이면 이미 동굴을 파거나 착륙장을 평평하게 만드는 법을 알고 있습니다. 생성 모드는 지형 종류(바위, 흙 등)를 고르게 해주는데, 이는 내부적으로 스플랫 맵 텍스처 블렌딩에 대응합니다.

에너지 소모가 빚기를 적당히 억제합니다. 노멀 모드에서는 넉넉합니다. 서바이벌 모드에서는 편집 하나하나가 의미 있는 자원을 소모합니다. 같은 도구가 두 난이도에서 캐주얼한 조형가와 자원에 신경 쓰는 생존주의자 모두를 만족시킵니다.

Astroneer: 진공 총

Astroneer는 가능한 한 가장 단순한 은유를 택합니다. 흙을 빨아들이는 진공청소기입니다. 지형을 겨누고 방아쇠를 당기면 흙을 빨아들입니다. 빈 공간을 겨누면 흙을 다시 뿜어냅니다. 지형이 커서 주위로 실시간으로 변형됩니다.

증강 장치가 동작을 바꿉니다. 정렬 모드는 행성 곡률에 맞춰 표면을 평평하게 만듭니다. 부스트 모드는 속도를 높입니다. 와이드 모드는 영향 범위를 넓힙니다. 억제 모드는 지형을 전혀 변형하지 않고 자원만 모으게 해줍니다.

천재성은 지형이 동시에 자원이라는 점입니다. 빨아들인 흙은 통을 채웁니다. 통에 든 흙은 토양 원심분리기에서 재료로 가공할 수 있습니다. 세계를 빚는 것과 자원을 모으는 것이 같은 행동입니다. 동굴을 원해서 파는 게 아닙니다. 합성물을 만들 흙이 필요해서 팝니다. 동굴은 나중에 쓸모 있어지는 부수 효과입니다.

Deep Rock Galactic: 팀워크로서의 채굴

Deep Rock Galactic은 지형 파괴를 클래스 역할에 대응시킵니다. 드릴러는 팔뚝에 장착한 강력한 드릴로 초당 가로 2m, 세로 2.2m, 깊이 1m씩 바위를 갉아냅니다. 드릴은 지속해서 쓰면 과열되고(빨간색까지 5.5초, 냉각 8초) 제한된 연료로 돌아갑니다. 모든 드워프는 정밀 작업용 곡괭이를 가지고 있습니다.

드릴러의 일은 길을 내는 것입니다. 단단한 바위를 뚫고 A 지점에서 B 지점까지 터널을 깎습니다. 팀이 뒤따릅니다. 지형 편집은 창작 도구가 아니라 임무 목표(추출 포드에 도달하기)를 위해 작동합니다. 하지만 부수 효과로, 팀이 지나가는 모든 동굴 시스템은 그들의 결정에 따라 독특하게 빚어집니다. 똑같이 생긴 플레이는 둘도 없습니다.

협동 구조는 빚기를 사회적인 일로 만듭니다. 드릴러는 혼자 파지 않습니다. 스카우트는 조명탄으로 동굴을 밝힙니다. 엔지니어는 드릴러가 드러낸 벽에 발판을 놓습니다. 거너는 터널 입구를 지킵니다. 지형 편집은 공유된 문장 속 하나의 동사입니다.

Teardown: 퍼즐로서의 파괴

Teardown은 지형 파괴를 강도 계획으로 감쌉니다. 준비할 시간은 무제한입니다. 벽을 부수고, 차로 건물을 들이받고, 폭발물을 놓고, 경사로를 만듭니다. 그러다 경보가 울리면 60초 안에 모든 목표를 처리하고 탈출해야 합니다.

모든 도구에는 물리적 정체성이 있습니다. 큰 망치는 가까이서 부숩니다. 토치는 강철을 자릅니다. 폭발물은 벽을 날립니다. 소화기는 불을 끕니다. 차량은 구조물을 들이받습니다. 플레이어는 추상적으로 "지형을 편집"하지 않습니다. 벽에 망치를 휘두르면 벽이 부서집니다.

물리가 이걸 진짜처럼 느끼게 합니다. 지지대가 사라지면 구조물이 무너집니다. 불이 번집니다. 연기가 방을 채웁니다. 파편이 떨어집니다. 피드백 고리가 즉각적이고 물리적입니다. 무언가를 치고, 부서지는 걸 보고, 결과가 줄줄이 이어지는 걸 봅니다. 캐주얼 플레이어도 이걸 이해합니다. 현실에서 망치를 휘둘러봤거나(혹은 휘두르고 싶었거나) 하기 때문입니다.

Eco: 게임 디자인으로서의 결과

Eco는 지형 편집에 영구적이고 공유되는 결과가 따르는 드문 게임입니다. 나무를 너무 많이 베면 대기질이 떨어집니다. 너무 거칠게 채굴하면 지하수를 오염시킵니다. 남획하면 종이 멸종합니다. 생태계가 온전히 시뮬레이션됩니다.

플레이어는 법을 발의하고 투표할 수 있습니다. "강에서 200m 이내 벌목 금지"나 "입방미터당 금화 10의 채굴세" 같은 식입니다. 거버넌스 시스템은 지형 편집을 정치적 행위로 만듭니다. 원하는 곳을 마음대로 팔 수 없습니다. 커뮤니티가 막을 수도 있습니다.

이것이 게임화의 극단입니다. 빚기 시스템 자체가 핵심 게임 루프가 됩니다. 지형은 모든 플레이어 행동이 영향을 미치는 공유 자원입니다. 빚기는 창작 도구가 아닙니다. 게임의 중심 긴장입니다.

Cinevva를 위한 디자인 패턴

이 게임들은 우리가 쓸 수 있는 패턴 도구함을 시사합니다. 한꺼번에 다 쓰는 게 아닙니다. 가장 접근하기 쉬운 것부터 시작해 가장 복잡한 것으로 쌓아 올리며, 층층이 쓰는 것입니다.

패턴 1: 오브젝트 기반 빚기 (TNT 패턴)

플레이어에게 브러시를 주지 마세요. 사용하면 지형을 다시 빚게 되는 오브젝트를 주세요.

TNT / 다이너마이트: 플레이어가 폭발물을 제작하거나 발견합니다. 세계에 놓습니다. 도화선에 불을 붙이거나(혹은 던집니다). 지형 한 구가 빠집니다. 반지름은 폭발물 종류에 따라 다릅니다. 작은 폭죽은 반지름 2m. 표준 다이너마이트는 5m. 메가 폭탄(희귀 드롭)은 15m. 플레이어는 "지형을 편집"하는 게 아니라 무언가를 날려버리고 있는 것입니다.

곡괭이 / 삽 / 드릴: 특성이 서로 다른 휴대용 도구입니다. 곡괭이는 바위를 깎아냅니다(작은 반지름, 빠름, 단단한 재질에 작동). 삽은 흙을 퍼냅니다(중간 반지름, 무른 땅에서는 빠름, 바위에서는 무용). 드릴은 터널을 뚫습니다(좁고 깊으며, 매끄러운 원통형 구멍을 남김). 각 도구는 내부적으로 서로 다른 SDF 브러시 연산에 대응하지만, 플레이어는 이들을 서로 다른 피드백을 주는 별개의 물리적 오브젝트로 경험합니다.

양동이 / 물뿌리개: 지형에 물을 부으면 내리막으로 흘러 수로를 깎습니다. 침식 브러시가 지형 기울기를 자동으로 따라갑니다. 플레이어는 브러시를 겨누지 않습니다. 물을 붓고 강이 생기는 걸 봅니다. 내부적으로는 지형 경사에 치우친 부드러운 낮추기 연산입니다.

씨앗 / 묘목: 심으면 지형이 자랍니다. 평평한 땅에 놓은 씨앗 봉지는 시간이 지나며(몇 초에 걸쳐 애니메이션과 함께) 작은 언덕으로 싹틉니다. 맨바위에 놓은 나무 묘목은 밑동 주위에 흙더미를 만들어냅니다. 지형을 "키우는" 것은 자연 스킨을 입힌 올리기 브러시일 뿐입니다.

지형 변형 비콘: 비콘을 놓으면 시간이 지나며 반지름 안의 모든 것을 목표 높이로 천천히 평평하게 만듭니다. 건축 부지에 좋습니다. 플레이어는 오브젝트를 놓고 자리를 뜹니다. 평탄화 브러시가 지면이 비콘 높이에 맞을 때까지 낮은 강도로 자동 실행됩니다.

패턴 2: 도구 진행 (Stardew 패턴)

작은 편집만 하는 약한 도구로 플레이어를 시작시키세요. 플레이를 통해 업그레이드하게 하세요.

1단계 (무료, 즉시): 맨손. 작은 돌출부를 두드려 다질 수 있음(미세 평탄화, 반지름 0.5m). 흙 한 줌을 퍼낼 수 있음(미세 낮추기, 반지름 0.3m). 영향은 미미합니다. 시스템이 존재한다는 걸 가르칩니다.

2단계 (기본 재료로 제작): 돌 삽, 나무 곡괭이. 작은 편집에 쓸 만함. 캠프장을 평평하게. 얕은 도랑을 파기. 반지름 1~2m. 대부분의 캐주얼 플레이어가 머무는 곳입니다.

3단계 (탐험이나 거래 필요): 금속 도구. 더 큰 반지름(3~5m). 새 연산 해금. 괭이로 지형 올리기, 끌로 매끄러운 곡선 깎기.

4단계 (엔드게임 / 희귀 드롭): 동력 공구, 폭발물, 지형 변형 장치. 반지름 10~20m. 동굴 뚫기. 산 쌓기. 장기 플레이어에게 보상하는 볼거리 도구입니다.

업그레이드 경로는 튜토리얼을 겸합니다. 각 단계가 새 개념 하나를 소개합니다. 4단계에 다다를 즈음이면 튜토리얼 화면이 아니라 점진적 노출을 통해 지형 편집의 어휘를 몸에 익히게 됩니다.

패턴 3: 맥락에 맞는 도구 (Valheim 패턴)

지형이 필요로 하는 것이 아니라 플레이어가 하려는 것에 도구를 맞추세요.

건축 모드: 플레이어가 건축 모드일 때(벽, 바닥, 지붕을 놓을 때), 기초 아래 지형이 자동으로 평평해집니다. 별도의 평탄화 도구가 필요 없습니다. 건축 시스템이 처리합니다. Valheim의 건축이 이렇게 작동합니다. 바닥을 놓으면 지면이 맞춰집니다.

농사 모드: 작물을 심을 때, 경작기가 흙을 갈고(표면 재질을 바꿈) 작은 돌출부를 고릅니다. 플레이어는 농사를 짓는 것이지 지형을 변형하는 게 아닙니다. 지형 편집은 농경 행동의 부수 효과입니다.

채굴 모드: 지형에서 자원을 캘 때(광맥, 점토층, 광물 노드), 채취가 구멍을 남깁니다. 지형 편집은 자원 채집의 부수 효과입니다. Astroneer가 이걸 완벽하게 합니다. 흙을 빨아들이고, 자원을 얻고, 동굴을 남깁니다.

전투 모드: 무기 폭발이 분화구를 만듭니다. 불이 식생을 태웁니다. 산이 바위를 녹입니다. 지형 피해는 전투의 부수 효과입니다. Deep Rock Galactic의 드릴이 이렇게 작동합니다. 무기이면서 동시에 지형 도구입니다.

패턴 4: 사회적 빚기 (Eco 패턴)

공유 세계에서는 편집 하나하나가 사회적 행위입니다. 그걸 염두에 두고 디자인하세요.

보이는 작성자: 플레이어가 지형을 빚으면 누가 했는지 은근한 표시를 남깁니다. 희미한 빛. 편집된 표면에 입힌 플레이어 색조. 작은 깃발. 다른 플레이어가 누군가 여기 있었고 지형을 바꿨다는 걸 볼 수 있습니다.

협업 프로젝트: 점유된 영역 안의 지형 편집이 공유 목표를 향해 쌓입니다. "산에서 호수까지 강을 파라." 영역 안 모두에게 진행 막대가 보입니다. 완료되면 강에 물이 찹니다. 빚기가 공유 보상이 있는 그룹 활동이 됩니다.

승인 구역: 보호 구역에서는 지형 편집에 땅 주인의 승인이나 근처 플레이어의 투표가 필요합니다. 빚기를 끄지 않고도 그리핑을 막습니다. 편집은 승인될 때까지 고스트(투명, 윤곽선)로 미리 보입니다.

합의에 의한 되돌리기: 어떤 플레이어든 지형 편집의 되돌림을 발의할 수 있습니다. 근처 플레이어가 충분히 동의하면 편집이 몇 초에 걸쳐 사라집니다. No Man's Sky의 복원 모드인데, 사회적으로 작동하는 버전입니다.

패턴 5: 자연의 힘 (침식 패턴)

직접 브러시질하는 대신, 플레이어가 자연 과정을 촉발하게 하세요.

비 소환: 언덕 위에 구름을 놓으면 비가 옵니다. 비가 시간이 지나며 산비탈을 침식해 수로를 내고 모서리를 부드럽게 합니다. 플레이어는 비가 어디에 내릴지, 얼마나 오래 갈지를 조절합니다. 침식 셰이더가 빚기를 합니다.

지진 장치: 국지적 지진을 일으켜 지면을 갈라지게 하고, 틈을 만들고, 영향 영역의 지형을 낮춥니다. 플레이어는 어디인지를 고릅니다. 물리 시뮬레이션이 어떻게인지를 정합니다.

용암 흐름: 한 지점에서 용암을 풀면 내리막으로 흘러 골짜기를 채우고 굳어 바위가 됩니다. 자연 은유로 만들어진 새 지형입니다. 내부적으로는 바위 재질로 지형 경사를 따라가는 올리기 브러시입니다.

바람 조형기: 무른 지형(모래, 흙)을 바람 방향으로 미는 선풍기나 송풍 장치입니다. 시간이 지나며 사구와 매끄러운 비탈을 만듭니다. 방향 치우침이 있는 부드럽게 하기 브러시입니다.

동결 / 해동: 강의 물을 얼려 얼음 다리를 만듭니다. 얼어붙은 산비탈을 녹여 진흙 사태를 일으킵니다. 온도를 지형 편집 매개변수로 삼아 날씨 아이템으로 표현합니다.

패턴 6: 발견과 놀라움 (Infinite Craft 패턴)

실험에 보상하세요.

조합 효과: 물 근처의 TNT는 온천을 만듭니다(분화구 + 물 채움 + 증기 파티클). TNT 분화구에 심은 씨앗은 더 빨리 자랍니다(분화구에 "비옥한 흙"이 있음). 얼어붙은 강을 다이너마이트로 터뜨리면 아래 동굴이 드러납니다.

숨은 재료: 충분히 깊이 파면 서로 다른 지형 층이 드러납니다. 표토, 점토, 돌, 수정, 용암. 각 층은 성질과 모습이 다릅니다. 더 깊이 파는 플레이어는 아무도 못 본 것을 봅니다.

화석과 유물: 무작위 지형 편집이 가끔 묻혀 있던 물건을 캐냅니다. 화석, 고대 유물, 보물 상자, 희귀 씨앗. 빚는 행위가 탐험 메커니즘이 됩니다. 동굴만 보고 파는 게 아닙니다. 뭔가 찾을지도 몰라서 팝니다.

지형 기억: 편집된 지형은 자신에게 무슨 일이 있었는지 기억합니다. TNT로 날아간 영역에는 그을음과 탄 모서리가 있습니다. 씨앗으로 키운 영역에는 더 진한 흙색이 있습니다. 비에 침식된 영역에는 매끄럽고 물에 닳은 텍스처가 있습니다. 지형이 자신의 역사를 들려줍니다.

브러시와 은유의 대응

플레이어가 다루는 모든 은유는 우리의 빚기 파이프라인에 있는 기술적 브러시 연산에 대응합니다. 다음은 변환표입니다.

곡괭이 / 삽은 작은 반지름, 높은 강도, 날카로운 감쇠를 가진 낮추기 브러시(하이트맵이나 SDF에서 빼기)에 대응합니다. 도구 애니메이션이 동일한 Chunk.applyBrush() 호출을 촉발합니다.

TNT / 폭발물은 큰 반지름, 최대 강도, 구 감쇠를 가진 낮추기 브러시에 대응합니다. 폭발 이벤트 하나가 폭발 지점을 중심으로 한 번의 브러시 스트로크를 적용합니다. 재질별 폭발 저항은 브러시의 강도 배수에 대응합니다.

괭이 / 평탄기는 중간 반지름, 부드러운 감쇠를 가진 평탄화 브러시에 대응합니다. 목표 높이는 도구가 활성화될 때 플레이어의 발 위치에서 샘플링됩니다. Valheim과 똑같습니다.

씨앗 / 성장은 작은 반지름, 부드러운 감쇠를 가진 올리기 브러시가 여러 프레임에 걸쳐(애니메이션 성장으로) 적용되는 것에 대응합니다. 각 프레임이 작은 증가분을 적용합니다. 애니메이션이 은유를 팔고, 브러시가 형상을 처리합니다.

물뿌리개 / 비는 방향 치우침이 있는 부드럽게 하기 브러시에 대응합니다. 치우침은 ChunkManager.getNormal()에서 나온 지형 경사 기울기를 따릅니다. 브러시 중심보다 아래에 있는 점이 위에 있는 점보다 더 낮아져 자연스러운 침식 수로를 만듭니다.

지형 변형 비콘은 수렴할 때까지 매 프레임 낮은 강도로 적용되는 평탄화 브러시에 대응합니다. 비콘의 월드 공간 위치가 목표 높이를 정합니다. 반지름은 비콘의 영향 범위입니다.

드릴은 구 대신 광선 방향을 따라 투사되는 낮추기 브러시에 대응합니다. 플레이어의 조준 방향에서 쏜 광선이 각 깊이 단계에서 브러시 중심을 정해 원통형 터널을 만듭니다.

진행과 경제

플레이어가 얻는 것

도구 해금: 손으로 시작합니다. 흔한 재료로 기본 도구를 제작합니다. 탐험, 거래, 퀘스트 완료를 통해 고급 도구의 레시피를 발견합니다.

용량 업그레이드: 더 큰 폭발물. 더 넓은 괭이. 더 빠른 드릴. 브러시 반지름과 강도가 단계에 따라 커집니다. 삽을 나무에서 철로 업그레이드하면 반지름이 두 배가 됩니다.

재질 종류: 플레이어가 바이옴을 탐험할수록 새 지형 재질이 해금됩니다. 마주친 지형 종류만 "생성"할 수 있습니다. 사막을 방문해 모래 생성을 해금하세요. 화산을 방문해 현무암을 해금하세요. 탐험으로 가둔 No Man's Sky의 생성 모드입니다.

레시피: 조합 효과는 주어지는 게 아니라 발견됩니다. TNT 분화구에 씨앗을 심어 "비옥한 폭발"을 발견하세요. 용암 지형에 물을 부어 "흑요석 형성"을 발견하세요. 발견 하나하나가 도감에 기록되고 공유 가능합니다.

비용으로 드는 것

자원: 모든 지형 편집은 재료를 소모합니다. 지형을 올리면 흙/돌/모래(놓이는 재료)가 듭니다. 지형을 낮추면 재료가 나옵니다(인벤토리로 들어감). 평탄화는 재분배합니다. 자원 흐름이 경제를 지형 시스템과 이어줍니다.

에너지 / 내구도: 도구에는 내구도나 에너지 한계가 있습니다. 곡괭이는 N번 쓰면 부서집니다. 지형 변형 비콘은 연료로 돌아갑니다. 이는 무한 편집을 막고 자연스러운 세션 경계를 만듭니다. 플레이어는 보급을 위해 쉬어 갑니다.

시간: 어떤 연산은 즉시입니다(곡괭이질). 다른 것은 느립니다(비콘 평탄화, 씨앗 성장, 비 침식). 느린 연산은 인내에 보상하고 스팸을 막습니다. 보기에도 더 좋습니다. 씨앗이 언덕으로 싹트는 걸 지켜보는 게 "올리기" 버튼을 클릭하는 것보다 만족스럽습니다.

남들이 보는 것

편집 흔적: 모든 지형 변경에는 시각적 서명이 있습니다. TNT 분화구에는 어둡고 갈라진 모서리가 있습니다. 괭이로 평평해진 영역에는 매끄럽게 일군 흙 텍스처가 있습니다. 키운 지형에는 진하고 유기적인 색이 있습니다. 비에 침식된 수로에는 물자국이 있습니다. 플레이어가 지형의 역사를 읽을 수 있습니다.

작성자 태그: 편집된 지형에 마우스를 올리면 누가 언제 바꿨는지 보입니다. "@PlayerName이 2시간 전에 빚음." 이는 작성자로서의 자부심과 사회적 책임감을 만듭니다.

전후 비교: 지형을 편집 이력의 어느 시점이든 보여주는 "타임랩스" 뷰입니다. 타임라인 슬라이더를 문질러 지형이 변해가는 걸 봅니다. 기술 가이드의 3단계에 나온 CSG 편집 트리가 모든 연산을 순서대로 저장하기 때문에 가능합니다.

무엇을 먼저 만드는가

기술 아키텍처의 1단계는 기존 WebGL 렌더러에서 하이트맵 빚기로 작동합니다. 그 위에 얹어 출시할 수 있는 캐주얼 도구들은 다음과 같습니다.

1. 삽 (낮추기 브러시, 작은 반지름). 가장 기본적인 도구. 지형을 클릭하면 구멍을 팝니다. 흙 자원이 나옵니다.
2. 괭이 (평탄화 브러시, 중간 반지름). 원하는 지면 높이에 서서 괭이를 쓰면 지형이 발 높이로 평평해집니다.
3. TNT (낮추기 브러시, 큰 반지름, 한 방). 재료로 제작하고, 놓고, 점화하고, 폭발을 봅니다. 잔해가 나옵니다.
4. 씨앗 (올리기 브러시, 프레임에 걸친 애니메이션). 평평한 땅에 심으면 지형이 작은 언덕으로 솟고 위에 식생이 나타나는 걸 봅니다.
5. 물뿌리개 (경사 치우침이 있는 부드럽게 하기 브러시). 비탈에 부어 침식시킵니다. 자연스러워 보이는 수로를 만듭니다.

다섯 도구. 다섯 가지 별개의 은유. 하나의 바탕 브러시 시스템. 각 도구는 플레이어가 제작하고, 장착하고, 기존 PlacementTool과 동일한 상호작용 모델로 사용하는 아이템에 감싸인 (반지름, 강도, 감쇠, 연산, 애니메이션)의 서로 다른 구성입니다.

우리는 플레이어가 월드를 빚기를 바랍니다. 그리드 위에 프리팹을 놓는 게 아니고, 블록을 켜고 끄는 것도 아닙니다. 실제로 지형을 다시 만드는 것입니다. 강을 깎고, 산을 솟아오르게 하고, 절벽면을 매끄럽게 다듬고, 동굴을 파는 것이죠. ZBrush와 Blender의 스컬프트 모드가 아티스트를 위해 해주는 그런 작업을, 멀티플레이어 브라우저 게임 안에서 60fps로 돌리는 것입니다.

이건 데이터 표현, 메시 추출, GPU 컴퓨트, 브러시 수학, 네트워크 동기화에 걸친 어려운 엔지니어링 문제입니다. 이 가이드는 우리가 찾아낸 모든 것을 정리합니다.

지형 표현의 두 세계

모든 스컬프팅 시스템은 지형 데이터를 어떻게 저장할지에 대한 선택에서 시작합니다. 그 선택이 어떤 종류의 편집이 가능한지, 얼마나 빠르게 실행되는지, 메모리를 얼마나 쓰는지를 결정합니다.

하이트맵

하이트맵은 그리드 점마다 높이 값 하나를 저장합니다. 밝기가 곧 고도인 그레이스케일 이미지라고 생각하면 됩니다. 우리의 현재 world/client 지형이 바로 이렇게 작동합니다. noise.ts가 FBM 값 노이즈로 높이를 생성하고, 각 Chunk가 Float32Array 하이트맵을 저장해 PlaneGeometry에 투영합니다.

하이트맵은 빠릅니다. 샘플링은 양선형 보간을 곁들인 배열 조회 한 번입니다. LOD는 그리드 해상도를 낮추기만 하면 되니 간단합니다. splat 기반 텍스처 블렌딩은 UV 그리드에 그대로 매핑됩니다. 물리 충돌은 높이 쿼리로 줄어듭니다.

한계는 토폴로지입니다. 하이트맵은 (x, z) 좌표당 높이 하나만 표현할 수 있습니다. 동굴도, 오버행도, 아치도, 터널도 안 됩니다. 플레이어가 안쪽으로 접히는 절벽을 깎아내면 하이트맵은 그걸 저장할 수 없습니다. 대부분 완만한 언덕과 산으로 이루어진 지형에는 괜찮습니다. 하지만 플레이어가 땅을 파고들 수 있는 자유 형식 스컬프팅에는 막다른 길입니다.

볼류메트릭(3D 스칼라 필드)

대안은 3D 공간의 모든 점에 값을 저장하는 것입니다. 그 값이 고체 재질 안에서 음수이고 바깥에서 양수라면(또는 그 반대라면) Signed Distance Field(SDF)를 가진 것입니다. 그 값이 그냥 밀도라면(어떤 임계값 위는 고체, 아래는 비어 있음) 밀도 필드를 가진 것입니다.

볼류메트릭 표현은 어떤 토폴로지든 처리합니다. 동굴, 오버행, 떠 있는 섬, 산을 관통하는 터널. 대가는 메모리와 복잡도입니다. 32비트 부동소수점을 쓰는 256^3 그리드는 64 MB가 듭니다. 512^3 그리드는 512 MB입니다. 그것도 단일 chunk에 대해서요. 이걸 실용적으로 만들려면 희소 데이터 구조(옥트리, brick map)가 필요합니다.

메시 추출 단계도 만만치 않습니다. 정점 Y 위치를 설정하고 끝낼 수는 없습니다. 스칼라 필드를 읽어서 필드가 0을 가로지르는 표면을 근사하는 삼각형 메시를 만드는 알고리즘이 필요합니다.

메시 추출: Marching Cubes, Surface Nets, Dual Contouring

Marching Cubes

Marching Cubes는 가장 오래되고 가장 널리 구현된 등치면 추출 알고리즘입니다. 1987년 Lorensen과 Cline이 발표했고, 각 코너에 스칼라 값을 가진 복셀 그리드의 모든 큐브를 검사하는 식으로 작동합니다. 일부 코너가 표면 안(음수)에 있고 일부가 바깥(양수)에 있으면, 그 큐브 안에 삼각형 메시 패치가 배치됩니다.

각 큐브는 8개의 코너를 가지고, 각각 안 또는 밖이므로 256가지 가능한 구성(2^8)이 나옵니다. 대칭성으로 이것이 15가지 고유 케이스로 줄어듭니다. 룩업 테이블이 각 케이스를 삼각형 집합에 매핑합니다. 부호가 바뀌는 에지를 따라 선형 보간으로 에지 교점을 찾습니다.

최근 GPU 구현들은 Marching Cubes를 실시간 스컬프팅에 충분히 빠르게 만들었습니다. 2025년 UE5에서의 한 구현은 각 GPU 스레드에 큐브 하나를 할당해 수천 개를 동시에 처리합니다. 핵심 통찰은 각 큐브의 삼각화가 이웃과 독립적이라는 것으로, 이 덕분에 알고리즘이 민망할 만큼 병렬적입니다.

MCHex(arxiv 2511.02064, 2025)는 Marching Cubes를 양의 야코비안 값을 보장하는 적응형 육면체 메시 생성으로 확장해, 시뮬레이션 메시의 경계 근사를 개선합니다.

rupMC는 CPU/GPU 이종 아키텍처를 사용해 직렬 구현보다 수십 배 빠르고, 병렬 DMC 변형보다 4배 빠른 성능을 달성합니다.

주된 한계는 Marching Cubes가 날카로운 특징에 약하다는 점입니다. 90도 에지가 매끄러운 곡선으로 둥글려집니다. 지형 스컬프팅에는 보통 받아들일 만하지만(자연 지형은 대부분 매끄러움), 건축적 특징에는 문제입니다.

Surface Nets

Surface Nets는 이산 스칼라 필드에서 더 매끄러운 메시를 만드는 더 새로운 알고리즘 계열입니다. Marching Cubes처럼 정점을 큐브 에지에 놓는 대신, Surface Nets는 표면을 포함하는 큐브마다 정점 하나를 놓고, 인접한 정점들을 연결해 쿼드를 만듭니다.

결과는 자연스럽게 더 매끄럽습니다. 2024년 논문(arxiv 2401.14906)은 순차 알고리즘보다 한두 자릿수 빠르게 돌아가는 고성능 병렬 Surface Nets 구현을 시연했습니다. fast-surface-nets Rust 크레이트는 작은 룩업 테이블과 SIMD 가속을 사용해 단일 2.5 GHz 코어에서 초당 약 2천만 개의 삼각형을 생성합니다.

bevy-sculpter(v0.18.0, 2026년 1월)는 Surface Nets를 주요 메싱 전략으로 사용합니다. 이 크레이트는 SDF 기반 볼류메트릭 스컬프팅을 네 가지 브러시 타입과 함께 제공합니다. 하드 CSG(즉시 추가/제거), 매끄러운 연속(누른 입력용), 블러(표면 매끄럽게 하기), 평탄화(목표 높이로 설정). 또한 편집 후 올바른 부호 거리 필드 속성을 복원하기 위해 Fast Sweeping Method를 통한 SDF 재거리화도 포함합니다.

Surface Nets는 Marching Cubes(단순하고 빠르지만 이진 데이터에서 계단 현상이 있는 메시를 만듦)와 Dual Contouring(특징 보존이 되지만 복잡함) 사이의 좋은 중간 지점입니다.

Dual Contouring

Dual Contouring은 Marching Cubes와 Surface Nets가 할 수 없는 날카로운 특징을 보존합니다. 각 코너에서의 필드 부호뿐 아니라 에지 교점에서의 기울기(법선)까지 사용함으로써 이를 해냅니다. QEF(Quadratic Error Function, 이차 오차 함수) 최소화가 모든 에지 교점 제약을 가장 잘 만족하는 위치에 각 셀 안의 정점을 놓습니다.

결과는 추출된 메시에서 날카로운 에지와 코너가 보존되는 것입니다. 수직면을 가진 큐브는 큐브로 남습니다.

대가는 복잡도입니다. QEF 풀이에는 셀 간 의존성이 있어 GPU 병렬화가 어렵습니다. 비매니폴드 메시(둘 이상의 폴리곤이 공유하는 에지)를 만들 수 있습니다. 구현도 Marching Cubes보다 더 까다롭지만, Johannes Jendersie는 작동하는 Dual Contouring 구현이 약 200줄이고 견고한 Marching Cubes는 500줄 이상이라고 언급합니다.

**Cubical Marching Squares(CMS)**가 중간 지점으로 제안되었습니다. 셀 간 독립적(GPU 친화적)이면서도 어느 정도 특징 보존을 제공합니다.

어느 것을 쓸까

브라우저에서 플레이어를 위한 지형 스컬프팅이라면:

Surface Nets가 가장 강력한 후보입니다. Marching Cubes가 이진 데이터에서 보이는 계단 현상 없이 매끄러운 메시(자연스러워 보이는 지형)를 만듭니다. 실시간 재메싱에도 충분히 빠릅니다. 그리고 Dual Contouring보다 구현이 더 간단합니다.

Marching Cubes는 GPU 병렬성이 우선일 때(모든 큐브가 독립적임)나 가장 넓은 라이브러리 지원이 필요할 때 여전히 견실한 선택입니다. Reinder Nijhoff의 WebGPU SDF Editor(2026년 1월)는 추출 파이프라인에서 Marching Cubes와 Surface Nets를 둘 다 구현하며, 전부 GPU에서 돌아갑니다.

Dual Contouring은 건축적 정밀도가 성능보다 더 중요한 경우에 쓰는 게 가장 좋습니다. 브라우저 환경에서의 실시간 지형 스컬프팅에는 이상적이지 않습니다.

Transvoxel 알고리즘: LOD 이음매 해결

복셀 지형을 서로 다른 해상도(플레이어 가까이는 LOD0, 멀리는 LOD2)로 메싱하면 경계에서 균열이 생깁니다. 하이트맵에는 간단한 문제입니다. 에지 정점을 보간해 더 낮은 해상도의 이웃에 맞추면 됩니다. 우리의 현재 chunk.ts는 stitchEdge()에서 바로 이렇게 합니다.

볼류메트릭 지형에는 문제가 훨씬 어렵습니다. LOD0의 동굴 입구가 경계에서 삼각형 30개를 만들 수 있습니다. 같은 영역이 LOD1에서는 완전히 다른 토폴로지의 삼각형 8개를 만들 수 있습니다. 둘 사이를 선형 보간할 간단한 방법은 없습니다.

Eric Lengyel의 Transvoxel 알고리즘(2009)은 "전이 셀(transition cell)"로 이를 해결합니다. 두 LOD 레벨 사이의 경계에서, 알고리즘은 (8개의 큐브 코너 대신) 9개의 고해상도 샘플을 고려해 512가지 가능한 구성을 만들고, 이것이 73개의 동치류로 나뉩니다. 각 류는 두 해상도 사이의 간극을 완벽하게 채우는 미리 정의된 삼각형 패턴에 매핑됩니다.

이 알고리즘은 로컬 복셀 데이터에서 작동하므로, 수정된 영역을 다시 삼각화하는 게 빠릅니다. 이것이 실시간 스컬프팅에 결정적입니다. 플레이어가 LOD 경계 근처 지형을 편집할 때 전이 셀만 다시 만들면 됩니다.

Rust 구현이 transvoxel 크레이트로 존재합니다. 원본 룩업 테이블은 transvoxel.org에서 받을 수 있습니다.

브러시 수학

스컬프팅 브러시는 목표 점 주위 반경 안의 스칼라 필드 값을 수정하는 함수입니다. Blender부터 언리얼 엔진, 런타임 게임 시스템까지, 모든 구현에서 수학은 놀랄 만큼 비슷합니다.

감쇠 함수

브러시 감쇠는 편집 강도가 중심에서 가장자리로 가면서 어떻게 줄어드는지를 결정합니다. Blender 5.1은 다음 표준 프로파일을 정의합니다.

Smooth: f(d) = 3d^2 - 2d^3 (Hermite 보간, noise.ts의 것과 같은 smoothstep)

Sphere: 중심에서 강하고 경계 근처에서 가파르게 감쇠. f(d) = sqrt(1 - d^2)로 근사.

Sharp: f(d) = (1 - d)^n에서 n > 2. 미세한 점을 만듭니다.

Linear: f(d) = 1 - d, 여기서 d는 중심으로부터의 정규화된 거리(중심에서 0, 가장자리에서 1).

Constant: d < 1일 때 f(d) = 1, 브러시 경계에서 하드 컷오프.

Inverse Square: smooth와 sphere 사이의 하이브리드로 자연스러운 "점토 같은" 느낌.

모든 경우에 d = distance_to_center / brush_radius이고 [0, 1]로 클램프됩니다. 감쇠 값이 브러시 강도에 곱해져 각 점에서의 실제 필드 수정량을 만듭니다.

감쇠 공간

Blender는 sphere 감쇠(3D 월드 공간에서 거리 계산)와 projected 감쇠(2D 화면 공간에서 거리 계산)를 구분합니다. projected 감쇠는 화면에서 가까워 보이는 두 점이 월드 공간에서 깊이가 매우 다르더라도 서로 똑같이 영향을 준다는 뜻입니다. 지형 스컬프팅에는 보통 3D 월드 공간 감쇠가 더 직관적입니다.

핵심 브러시 연산

Raise/Lower(디스플레이스먼트): 브러시 반경 안에서 감쇠로 가중해 스칼라 필드에 더하거나 뺍니다. 하이트맵의 경우: height[i] += strength * falloff(d). SDF의 경우: sdf[i] -= strength * falloff(d) (빼면 재질이 더 단단해져 표면이 올라감).

Smooth(라플라시안): 각 값을 이웃의 평균으로 대체하되 감쇠로 가중합니다. 디테일을 지우고 노이즈를 줄입니다. 라플라시안 필터는 작은 커널(하이트맵은 3x3, 볼륨은 3x3x3)을 샘플링해 평균 쪽으로 블렌딩합니다. HC(Humphrey's Classes) 스무딩은 원시 라플라시안보다 부피를 더 잘 보존하는 변형입니다.

Flatten: 필드 값을 목표 높이(또는 SDF 공간에서의 거리)로 설정하되 감쇠로 블렌딩합니다. 목표는 보통 스트로크가 시작될 때 브러시 중심에서 샘플링한 다음 고정해 둡니다. 평평한 고원을 만듭니다.

Pinch/Inflate: 표면 법선을 향해 또는 그 반대로 정점을 이동시킵니다. SDF 공간에서는 기울기 방향을 따라 변위시키는 것과 같습니다.

Grab: 점토를 잡아당기듯 필드의 한 영역을 평행이동합니다. 변위 벡터는 월드 공간으로 투영된 마우스 델타이고, 반경 안의 필드 값에 적용됩니다.

Noise: 브러시 반경 안에서 필드에 절차적 노이즈를 더합니다. 매끄러운 표면을 거칠게 만들 때 유용합니다.

Stamp: 2D 그레이스케일 이미지를 디스플레이스먼트로 적용해 커서 아래 표면에 투영합니다. 언리얼 엔진의 Landscape 도구가 지형 브러시에 대해 이를 지원합니다.

적응형 테셀레이션

sculpt-3D(React + Three.js 브라우저 스컬프팅)는 적응형 테셀레이션을 구현합니다. 브러시가 메시 위를 움직이면 브러시 중심 근처 삼각형이 세분화되어 변형에 쓸 정점을 더 많이 제공합니다. 이것은 거친 메시가 스컬프팅으로 일그러지는 "로우폴리 늘어남" 문제를 막아줍니다. 세분화는 균일한 삼각형 품질을 위해 대칭 분할을 사용합니다.

볼류메트릭 시스템에서는 메시가 필드에서 재생성되기 때문에 같은 방식의 적응형 테셀레이션이 필요하지 않습니다. 대신 편집 근처에서 복셀 해상도를 국소적으로 높일 수 있어(적응형 옥트리) 같은 효과를 냅니다.

SDF 스컬프팅: Dreams의 접근

Media Molecule의 Dreams(PS4, 2020)는 출시된 게임 내 스컬프팅 시스템 중 가장 야심 찬 것입니다. Alex Evans가 SIGGRAPH 2015에서 기술적 접근을 발표했습니다.

표현

Dreams는 지오메트리를 83^3 fp16 볼륨 텍스처 블록 안의 복합 SDF 함수로 저장합니다. 각 스컬프트는 1개에서 100,000개의 "편집"으로 이루어진 목록이며, 각 편집은 원시 형상(구, 큐브, 실린더, 콘, 타원체, 토러스 등)과 블렌드 모드를 가진 CSG 연산(추가, 빼기, 색칠)입니다.

블렌드 모드는 soft-max와 soft-min 함수를 씁니다. "소프트" 블렌드는 원시 형상 사이에 둥근 전이를 만듭니다(서로 눌러 붙인 점토처럼). "하드" 블렌드는 깔끔한 불리언 절단을 만듭니다. 블렌드 반경은 사용자가 조절할 수 있습니다.

렌더링

Dreams는 삼각형 메시를 추출하지 않습니다. 대신 커스텀 포인트 클라우드 렌더러("flecks")로 SDF에서 직접 렌더링합니다. 각 fleck은 표면 법선을 따라 배향된 작은 원반입니다. SDF를 샘플링해 표면을 찾고, fleck들을 그 위에 분포시킵니다. 이것은 메시 추출 병목을 통째로 피하지만 커스텀 렌더러가 필요합니다.

Three.js/WebGL 월드에는 이 접근을 직접 적용할 수 없습니다. 우리는 메시를 추출해야 합니다. 하지만 CSG 편집 목록 개념은 실행 취소/다시 실행과 네트워크 동기화에 매우 관련이 깊습니다.

Mike Turitzin의 동적 SDF 엔진(2026)

Mike Turitzin이 현재 개발 중인 게임 엔진은 동적 SDF를 핵심 표현으로 사용합니다. 이 엔진은 다음을 지원합니다.

게임플레이 중 세밀한 수정: 물질을 매끄럽게 또는 날카로운 에지로 추가하고 제거합니다. 구멍을 옮기거나 플레이어 뒤에서 사라지는 임시 터널을 만드는 등 비파괴적 변경.

Brick map과 brick atlas로 희소 캐싱. 전체 SDF 필드를 조밀한 3D 그리드에 저장하는 대신, 필드를 "브릭"(작은 3D 타일)으로 나눕니다. 표면 경계를 포함한 브릭만 할당됩니다. 이는 대부분 비어 있거나 채워진 공간으로 된 장면의 메모리를 극적으로 줄입니다.

Geometry clipmap(Losasso & Hoppe, SIGGRAPH 2004)으로 LOD를 처리. 해상도가 점점 높아지는 중첩된 정규 그리드가 카메라 위치를 둘러쌉니다. 가장 안쪽 그리드가 가장 세밀하고, 바깥 그리드는 점점 거칠어집니다. 이것은 광대한 공간을 지원하면서 메모리를 크게 줄여줍니다. Clipmap은 카메라가 움직이면 점진적으로 업데이트되어, 스트리밍 오픈 월드에 효율적입니다.

물리와 충돌은 SDF에 직접 작동합니다. Sphere-tracing(SDF 거리를 스텝 크기로 쓰는 레이 마칭)이 효율적인 레이캐스팅을 제공합니다. 충돌 감지는 SDF 기울기를 표면 법선으로, 거리 값을 침투 깊이로 사용합니다.

Teardown: 규모 있는 복셀 파괴

Teardown(Voxagon)은 스펙트럼의 다른 쪽 끝을 대표합니다. 월드의 모든 오브젝트가 조각조각 파괴할 수 있는 복셀 볼륨입니다.

아키텍처

오브젝트는 규칙적 간격의 복셀 그리드로 저장됩니다. 엔진은 렌더링에 Marching Cubes나 SDF를 쓰지 않습니다. 대신 OpenGL 3.3 위에 구축된 프래그먼트 셰이더에서 개량된 DDA(Digital Differential Analyzer) 알고리즘으로 복셀을 직접 레이트레이싱합니다. 밉맵이 조밀한 옥트리 구조를 이루어 레이 교차 중 빈 공간 순회를 가속합니다.

각 오브젝트에 대해 엔진은 그 배향된 경계 상자(OBB)를 래스터화하고 그것을 관통하는 레이를 추적해 복셀 교점을 찾습니다. OBB의 뒷면만 렌더링하므로 카메라가 경계 볼륨 안으로 클립해 들어갈 수 있습니다.

파괴 동기화(멀티플레이어)

Teardown의 2026년 3월 멀티플레이어 업데이트는 준결정론적 접근을 씁니다. 구조적 파괴(구멍 뚫기, 소유권 변경, 조인트 재연결)는 신뢰성 있는 네트워크 스트림에서 고정소수점 정수 연산으로 처리됩니다. 모든 클라이언트가 동일한 결정론적 명령을 실행해 동일한 월드 상태에 도달합니다. 비구조적 변화(파편, 파티클)는 비신뢰 상태 동기화를 씁니다.

이것은 우리 멀티플레이어 월드에 중요한 통찰입니다. 지형 편집은 결정론적이어야 합니다. 플레이어 A가 산을 빚으면, 모든 클라이언트는 동일한 필드 데이터에서 동일한 메시를 만들어야 합니다. 편집 명령(브러시 위치, 반경, 강도, 연산 타입)이 결과 메시가 아니라 권위 있는 데이터여야 합니다.

ALICE-SDF: 압축과 CSG 트리

ALICE-SDF(Adaptive Lightweight Implicit Compression Engine, v1.3.0 2026년 3월)는 폴리곤 메시 대비 10-1000배 압축을 제공하는 SDF 기반 공간 데이터의 Rust 구현을 제공합니다. 다음을 지원합니다.

126개의 빌딩 블록: 원시 형상 72개, 연산 24개, 변환 7개, 모디파이어 23개. 매끄러운 블렌드 연산(합집합, 차집합, 교집합), 하드 에지 베벨과 계단식 CSG 전이를 위한 chamfer 및 stairs 블렌드.

CSG 트리 diff/patch로 실행 취소/다시 실행과 네트워크 동기화를 처리. 이것이 멀티플레이어 스컬프팅의 핵심 기능입니다. 전체 필드 상태를 보내는 대신 두 CSG 트리 사이의 구조적 diff를 보냅니다. 클라이언트는 patch를 적용해 새 상태를 재구성합니다. 이것은 원시 복셀 데이터를 델타 압축하는 것보다 훨씬 대역폭 효율적입니다.

CSG 트리 최적화에는 항등 변환 제거, 중첩 변환 병합, 모디파이어 강등이 포함됩니다. 편집이 쌓이는 동안 트리를 간결하게 유지합니다.

메시 생성은 Marching Cubes와 Dual Contouring 둘 다로 가능합니다. 물리 충돌 감지는 SDF에 직접 작동합니다.

WebAssembly 지원으로 브라우저 통합이 가능합니다. 엔진은 Rust로 작성되고 WASM 바인딩이 있어, Three.js 애플리케이션의 현실적인 선택지가 됩니다.

지형을 위한 WebGPU Compute

WebGPU는 2025년 말부터 모든 주요 브라우저에서 사용할 수 있습니다. Chrome 113+, Edge 113+, Firefox 141+, Safari 26+가 모두 활성화된 채로 출시됩니다. 이것은 이전에는 GPU 전용이던 컴퓨트 셰이더 파이프라인을 열어줍니다.

성능

WebGPU 컴퓨트 셰이더는 대규모 병렬화를 통해 CPU 방식보다 약 100배 빠르게 지형을 생성합니다. GPU는 수천 개의 계산을 동시에 실행하며, 지형 생성은 거의 완전히 병렬적입니다(각 정점/복셀이 독립적임).

작업은 세 단계로 구성됩니다. Dispatch Level(GPU 전반의 작업량 분배), Workgroup Level(처리 단위 내 공유 메모리), Thread Level(개별 계산). WGSL(WebGPU Shading Language)이 셰이더 언어입니다.

실시간 지형 스컬프팅 파이프라인

WebGPU 스컬프팅 파이프라인은 이렇게 생겼을 것입니다.

1. 브러시 적용(컴퓨트 셰이더): 브러시 반경 안의 스칼라 필드 값을 업데이트합니다. 각 스레드가 복셀 하나를 처리합니다. uniform buffer에서 브러시 매개변수(위치, 반경, 강도, 감쇠 타입, 연산)를 읽어 수정을 적용합니다.

2. 메시 추출(컴퓨트 셰이더): 수정된 영역에 Surface Nets나 Marching Cubes를 실행합니다. Nijhoff의 WebGPU SDF Editor는 이것을 다단계 파이프라인으로 구현합니다. 16,384개 셀에 걸친 공간 분할, 옥트리 기반 셀 분할, 그다음 표면 추출.

3. 정점 버퍼 업데이트(GPU 측): 추출된 정점을 CPU 메모리를 거치지 않고 렌더 버퍼에 직접 씁니다.

4. 법선 계산(컴퓨트 셰이더): 메시나 SDF 기울기에서 정점 법선을 계산합니다.

5. 렌더링(표준 파이프라인): 표준 PBR 머티리얼로 메시를 그립니다.

1단계부터 4단계까지는 데이터가 JavaScript로 돌아가지 않고 전부 GPU에서 돌릴 수 있습니다. CPU는 매 프레임 브러시 매개변수만 보내면 됩니다.

WebGPU SDF Editor

Reinder Nijhoff의 WebGPU SDF Editor(2026년 1월)는 이 접근을 Chrome에서 돌아가는 모습으로 시연합니다. 원시 형상 6개(cone, cylinder, capsule, torus, box, sphere), 구성 가능한 매끄러운 블렌딩을 갖춘 블렌드 연산 3개(union, subtraction, intersection), 계층적 장면 그래프를 지원합니다. 각 원시 형상은 단일 GPU 버퍼에서 112바이트를 차지합니다.

렌더링 파이프라인은 앰비언트 오클루전과 시간적 안티에일리어싱에 1,024개의 섀도 맵을 씁니다. 이것이 고급 GPU에서 인터랙티브 프레임레이트로 돌아갑니다.

하이트맵 스컬프팅: 더 단순한 길

동굴과 오버행 지원이 필요 없다면, 하이트맵 스컬프팅은 볼류메트릭 파이프라인 전체를 피합니다. 대부분의 출시된 게임이 지형 편집을 처리하는 방식이 이것입니다.

런타임 구현 패턴

Unity Runtime Terrain(JohannHotzel, 2026년 1월)은 표준 패턴을 보여줍니다.

1. 마우스 위치를 통해 카메라에서 레이캐스트해 지형 충돌 점을 찾습니다.
2. 충돌 점을 하이트맵 좌표로 매핑합니다.
3. 감쇠로 가중해 가까운 하이트맵 값에 브러시를 적용합니다.
4. 수정된 하이트맵에서 정점 Y 위치를 설정해 메시를 업데이트합니다.
5. 새 메시에 맞게 물리 콜라이더를 다시 만듭니다.

우리의 Three.js 지형에서는 1단계부터 4단계가 기존 아키텍처에 그대로 매핑됩니다. Chunk 클래스는 이미 하이트맵을 저장하고 그것으로 메시를 만듭니다. 스컬프팅을 추가한다는 것은 다음을 의미합니다.

• chunk 메시에 대한 레이캐스팅 시스템(Three.js Raycaster)
• chunk.heightmap 값을 수정하는 브러시 적용 함수
• 메시 정점 업데이트(Y 위치 설정, 법선 재계산)
• 영향받은 영역의 splat map 재계산(텍스처 블렌딩이 새 경사/높이를 반영하도록)
• 기존 WebSocket 프로토콜을 통해 편집(브러시 위치, 반경, 강도, 연산)을 다른 클라이언트로 브로드캐스트

Clipmap 접근

Landow.dev는 하이트맵 지형을 위한 "wandering clipmap"을 설명합니다. 플레이어를 따라다니는, 가변 세분화 밀도를 가진 단일 메시입니다. 하이트맵을 서로 다른 LOD 레벨의 별도 메시로 청크화하는(우리가 지금 하는 것) 대신, clipmap은 카메라 가까이에서 조밀하고 가장자리에서 거친 연속적인 메시입니다.

이것은 LOD 이음매를 완전히 없앱니다. 메시는 필요한 곳에 삼각형이 더 많고 필요 없는 곳엔 더 적을 뿐입니다. 대가는 스컬프팅이 개별 chunk가 아니라 단일 큰 메시를 업데이트해야 한다는 점인데, 큰 편집에는 비용이 클 수 있습니다.

비파괴적 SDF 하이트맵

Landow.dev는 하이트맵 자체가 SDF 구성에서 생성되는 기법도 설명합니다. 형상 인스턴스(구, 박스, 노이즈 함수)가 컴퓨트 셰이더에서 CSG 연산으로 합성되고, 그 출력이 하이트맵으로 샘플링됩니다. 이것은 하이트맵 렌더링의 단순함을 유지하면서 비파괴적 편집(언제든 어떤 형상 인스턴스도 옮기거나 지울 수 있음)을 제공합니다.

이건 매력적인 하이브리드입니다. 데이터 표현은 볼류메트릭(SDF CSG 트리)이지만, 렌더링 경로는 표준 하이트맵 메시입니다. SDF 쪽에서 실행 취소/다시 실행과 네트워크 친화적인 편집 연산을 얻고, 하이트맵 쪽에서 단순한 렌더링과 물리를 얻습니다. 한계는 남습니다. 동굴이나 오버행은 안 됩니다.

대형 월드를 위한 희소 복셀 옥트리

조밀한 3D 그리드는 확장되지 않습니다. 한 변이 1 km이고 해상도가 0.5m인 월드는 80억 개의 복셀이 필요합니다. 희소 복셀 옥트리(SVO)는 공간을 재귀적으로 세분화하고 표면 경계를 포함한 옥탄트에만 스토리지를 할당함으로써 이를 해결합니다.

SVO는 자연스럽게 계층적 LOD를 제공합니다. 어떤 점에서의 트리 깊이가 유효 해상도를 결정합니다. 플레이어 가까이에서는 트리가 완전히 펼쳐집니다(최대 디테일). 멀리서는 더 거친 레벨에서 잘립니다.

렌더링에는 SVO를 직접 레이트레이싱할 수 있습니다(메시 추출이 필요 없음). GPU 레이 마처가 각 트리 레벨에서 축 정렬 박스와 레이를 교차시키며 빈 서브트리를 통째로 건너뜁니다. 이것은 chunk 기반 렌더링의 오버드로 문제를 없애고 greedy meshing 아티팩트를 피합니다.

AdamYuan의 Vulkan 기반 SVO 빌더는 상당한 성능을 보여줍니다. GTX 1660 Ti에서 2^10 해상도의 Crytek Sponza를 19ms 빌드 시간으로 처리합니다.

스컬프팅에는 SVO 수정이 효율적입니다. 브러시 반경 안의 리프 노드만 업데이트하면 되고, 트리 구조가 변하는 해상도를 자연스럽게 처리합니다. 플레이어가 스컬프팅하는 곳에 디테일을 추가하고(노드를 더 높은 해상도로 분할), 매끄럽게 하는 곳에서 디테일을 제거하는 것(노드를 더 낮은 해상도로 병합)이 데이터 구조에서 저절로 나옵니다.

브라우저 배포의 과제는 WebGL이 컴퓨트 셰이더를 지원하지 않는다는 점이고, WebGPU는 지원하지만 SVO 구축과 순회 알고리즘이 WGSL로 구현하기에 복잡하다는 점입니다.

멀티플레이어 스컬프팅을 위한 네트워크 동기화

우리 월드는 이미 Cloudflare Durable Objects(world-chunk-do.ts)를 통해 멀티플레이어를 갖췄습니다. 스컬프팅을 추가한다는 것은 연결된 모든 클라이언트에 걸쳐 지형 수정을 동기화하는 것을 의미합니다.

델타 압축

원시 복셀 데이터를 보내는 건 비쌉니다. Oulu 대학의 2024년 연구는 델타 인코딩과 DEFLATE 압축을 결합해 페이로드를 2-8배 개선했고, 복셀 업데이트를 복셀당 1바이트 미만으로 압축했습니다. SDEC 코덱은 비트 패킹 델타 인코딩으로 일반 직렬화의 1114바이트 대비 평균 259바이트 패킷을 만드는 것을 시연했습니다.

연산 기반 동기화(권장)

필드 상태를 동기화하는 대신 연산을 동기화하세요. 각 스컬프팅 동작이 메시지가 됩니다.

interface TerrainEditMsg {
  t: MsgType.TerrainEdit
  brush: {
    position: [number, number, number]
    radius: number
    strength: number
    falloff: 'smooth' | 'linear' | 'sharp' | 'constant'
    operation: 'raise' | 'lower' | 'smooth' | 'flatten' | 'noise'
    targetHeight?: number
  }
}

서버가 이것을 모든 클라이언트에 브로드캐스트하고, 각 클라이언트는 로컬 지형 데이터에 동일한 결정론적 브러시 연산을 적용합니다. 이것은 Teardown이 구조적 파괴에 쓰는 것과 같은 접근입니다. 신뢰성 있는 스트림에서의 결정론적 명령.

ALICE-SDF의 CSG 트리 diff/patch는 이를 더 밀고 나갑니다. 개별 브러시 스트로크 대신, diff가 전체 CSG 트리의 구조적 변화를 나타냅니다. 이것은 네트워크에 걸친 효율적인 실행 취소/다시 실행을 가능하게 하고(역 patch를 전송), 늦게 합류하는 클라이언트는 연산 로그를 재생해 전체 월드 상태를 재구성할 수 있습니다.

우선순위와 스로틀링

연결된 플레이어 가까이의 지형 편집은 고우선순위여야 합니다(즉시 브로드캐스트). 어떤 플레이어와도 먼 편집은 배치로 묶어 더 낮은 빈도로 보낼 수 있습니다. Enshrouded의 복셀 네트워킹이 이 패턴을 씁니다. 플레이어 근처 지형은 60Hz 업데이트, 배경 영역은 10Hz.

회선상의 ZSTD 압축은 지형 업데이트 메시지의 패킷 크기를 최대 60%까지 줄입니다.

협업 스컬프팅: 동시 편집

여러 플레이어가 같은 영역을 동시에 스컬프팅할 때는 충돌 해결이 필요합니다. cSculpt(CNR Visual Computing Lab, 2016)는 다중 해상도 병합 알고리즘으로 이를 해결했습니다. 각 편집이 여러 스케일로 표현되고, 동시에 겹치는 편집은 그 다중 해상도 표현을 블렌딩해 병합됩니다.

우리 목적에는 더 단순한 접근이 통합니다. 서버 순서를 곁들인 last-write-wins. Durable Object가 각 편집에 타임스탬프를 찍고 순서대로 브로드캐스트합니다. 모든 클라이언트가 같은 순서로 편집을 적용합니다. 브러시 스트로크는 작고 국소적이며 가산/감산적이므로, 약간 순서가 뒤바뀐 동시 편집의 시각적 결과는 보통 "올바른" 순서와 구별되지 않습니다.

INST-Sculpt: 신경망 SDF 편집(연구 최전선)

INST-Sculpt(arxiv 2502.02891, 2025년 2월)는 신경망 SDF의 스트로크 기반 편집을 가능하게 합니다. 사용자가 표면에 스트로크를 그리면, 시스템이 스트로크 경로 주위의 관 모양 근방을 따라 기저 신경망 필드를 변형합니다. 커스텀 브러시 프로파일(구성 가능한 단면)이 변형의 형태를 제어합니다.

이것은 AI 생성 지형에 흥미롭습니다. 기저 월드가 신경망 SDF(3D 좌표를 부호 거리로 매핑하는 작은 신경망)로 표현된다면, 스컬프팅은 명시적 복셀 데이터가 아니라 네트워크 가중치를 수정합니다. 표현은 극도로 간결하지만(월드 전체가 몇 MB) 평가는 룩업 테이블보다 비쌉니다.

이것은 연구 단계 기술입니다. 소비자 하드웨어에서 신경망 SDF의 추론 비용은 오늘날 실시간 게임에 쓰기엔 너무 높습니다. 하지만 특히 WebGPU 셰이더 능력이 향상되고 모델 추론이 빨라지면서 지켜볼 가치가 있습니다.

World Creator 2026.3: 상업용 지형의 현재 수준

World Creator(BiteTheBytes, 2026년 3월)는 지형 저작 도구의 상업적 현재 수준을 대표합니다. 2026.3 버전은 GPU 기반 지형 생성, 자동 지형 적응(지형이 배치된 오브젝트에 맞춰짐), LOD 최적화를 위한 카메라 중심 오브젝트 분포, 실제 고도 데이터 가져오기(GeoTIFF, HGT, DTED)를 추가했습니다.

그 후 World Creator 2026.4(2026년 4월 28일)는 숫자 필드의 수식, 히어로 오브젝트를 표면에 안착시키는 지형 법선 블렌딩, 전체 데칼 지원, 사용 가능한 GPU 메모리에 맞춰 최대 오브젝트 수를 조정하는 VRAM 스케일링을 추가했습니다. BiteTheBytes는 기능은 완전하지만 내보내기가 비활성화된 무료 Community Edition도 출시했는데, 사실상 무제한 트라이얼입니다.

그들의 접근은 모든 지형 연산에 GPU 컴퓨트를 씁니다. 침식 시뮬레이션, 강 깎기, 텍스처 페인팅. 브러시 도구는 GPU 가속되고 실시간 뷰포트 피드백을 갖춥니다. 이것은 위에서 설명한 WebGPU 컴퓨트 파이프라인과 일치하며, 데스크톱 GPU에서 돌아갑니다.

우리가 이미 만든 것: 24개의 스파이크와 프로덕션 월드

world/spikes/ 디렉터리에는 24개의 자체 완결형 프로토타입이 있습니다. 이것들은 장난감 데모가 아닙니다. 각 스파이크가 특정 문제를 해결하고, 목표 대비 벤치마크하고, 다음 것에 정보를 준 점진적 R&D 파이프라인입니다. 스컬프팅 시스템은 후반의 볼류메트릭 것들뿐 아니라 이 모두 위에 세워집니다.

프로덕션 하이트맵 지형(world/client/)

라이브 월드는 Three.js WebGL의 청크화된 하이트맵 시스템을 씁니다.

• noise.ts는 결정론적 terrainHeight(wx, wz) 함수로 FBM 값 노이즈를 통해 지형 높이를 생성합니다(언덕에 5 옥타브, 능선에 4, 미세 디테일에 3)
• chunk.ts는 Float32Array 하이트맵에서 3개 LOD 레벨(64 단위 chunk당 32/8/4 세그먼트)로 PlaneGeometry 메시를 만들고, 시드 기반 랜덤 배치와 오브젝트별 콜라이더로 인스턴스화된 나무/빌보드를 놓습니다
• chunk-manager.ts는 플레이어 주위에 링 형태로 chunk를 스트리밍하고(LOD0 반경 1, LOD1 반경 3, LOD2 반경 6), stitchEdge()에서 선형 보간으로 에지 이음매를 처리하며, 물리 레이어에 getHeight(), getNormal(), resolveCollisions()를 제공합니다
• terrain-material.ts는 MeshStandardMaterial.onBeforeCompile을 통해 경사 및 높이 기반 가중치로 4레이어 splat 기반 텍스처 블렌딩(잔디/바위/모래/흙)을 하고, 레이어별 노멀 맵 블렌딩도 합니다
• character-controller.ts는 중력, 접지, 경사 거부(최대 경사 cos 50도)를 위해 매 프레임 지형 높이를 샘플링합니다. 스컬프팅은 수정된 높이를 이 시스템에 즉시 넣어야 하며, 그러지 않으면 플레이어가 편집된 지형을 뚫고 떨어집니다
• placement.ts는 오브젝트 배치 도구를 위해 이미 chunk 메시를 맞히는 Raycaster를 가지고 있습니다. 브러시 도구는 레이캐스팅을 처음부터 만드는 대신 바로 이 패턴을 따라야 합니다
• protocol.ts는 world-chunk-do.ts Durable Object를 통한 멀티플레이어 동기화를 위해 MessagePack으로 인코딩된 메시지를 정의하며, 현재 PlayerState, PlaceObject, RemoveObject, Snapshot 메시지를 처리합니다. 지형 편집에는 새 메시지 타입이 필요합니다
• world-chunk-do.ts(Cloudflare Worker)는 배치된 오브젝트를 Durable Object 스토리지에 지속시키고 50ms 간격으로 연결된 플레이어에게 브로드캐스트합니다. 아직 지형 수정 개념은 없습니다

스파이크 01-11: 기반 레이어

이 스파이크들은 스컬프팅이 의존하게 될 핵심 시스템을 검증했습니다. 이것들을 건너뛰면 스컬프팅 시스템이 지켜야 할 제약을 놓치게 됩니다.

스파이크 01(지형 + 인스턴싱): Three.js의 첫 지형 프로토타입. chunk.ts가 여전히 쓰는 PlaneGeometry + 하이트맵 패턴과 인스턴스화된 오브젝트 배치를 확립했습니다.

스파이크 02(Rapier 물리 Worker): Web Worker에서 ColliderDesc.heightfield() 콜라이더로 돌아가는 Rapier 3D. autostep, 경사 제한, 바닥 스냅을 갖춘 키네마틱 캐릭터 컨트롤러를 만들었습니다. 이 스파이크는 물리가 메인 스레드 바깥에서 하이트필드에 대해 돌 수 있음을 증명했습니다. 지형을 스컬프팅하면, 물리 하이트필드를 다시 만들거나 MC chunk에 대해 trimesh 콜라이더로 교체해야 합니다.

스파이크 05(LLM 동작): 지형과 직접 관련은 없지만 게임 오브젝트의 JSON 동작 스키마를 확립했습니다. 스컬프팅한 지형 특징이 동작을 촉발할 수 있어(예: 깎아낸 강이 물 효과를 생성) 관련이 있습니다.

스파이크 06(Chunk 스트리밍): 플레이어가 움직이면 동적으로 로드하는 첫 chunk 로드/스왑 시스템. chunk-manager.ts가 쓰는 패턴을 확립했습니다. 로드되고 언로드되는 색칠된 영역. 스컬프팅은 chunk가 언로드되고 다시 로드될 때 편집 상태를 보존해야 합니다.

스파이크 07(밀도 맵에서의 GPU 식생): 지형 높이와 경사를 샘플링하는 밀도 맵으로 배치되는 인스턴스화된 잔디와 나무. 스컬프팅은 식생 배치를 무효화합니다. 지형 높이가 바뀌면 나무가 떠 있거나 묻힐 수 있습니다. 편집된 chunk에 대해 밀도 맵을 다시 생성해야 합니다.

스파이크 08(지형 머티리얼 셰이더 비용): 트라이플래너 투영, 노멀 맵, 4레이어 블렌딩을 벤치마크했습니다. 각 기능의 정확한 ms 비용을 측정했습니다. 트라이플래너 + 노멀 + 4레이어가 45+ FPS에서 예산 안에 머문다는 것을 알아냈습니다. 이 예산은 스컬프팅한 지형에 중요합니다. "편집된 토양"을 위해 5번째 레이어를 추가하거나 깎아낸 표면의 블렌딩을 바꾸면, 여유가 정확히 얼마인지 압니다.

스파이크 09(CSM 섀도 예산): 1024^2 해상도 캐스케이드 3개를 가진 캐스케이드 섀도 맵. 섀도 비용을 약 1.5ms로 측정했습니다. 스컬프팅한 지형은 섀도 맵을 바꾸지만, 비용은 지형 형태와 관계없이 일정합니다.

스파이크 10(Geometry Clipmap + Geomorphing): 팝인을 없애기 위해 LOD 레벨 사이를 geomorphing하는 중첩 clipmap 링. 일정한 삼각형 수가 예측 가능한 GPU 비용을 뜻합니다. Geomorphing은 스컬프팅에 중요합니다. 플레이어가 LOD 경계 근처를 스컬프팅하면, LOD 레벨 사이의 모핑이 편집을 반영해야 합니다. 편집이 고해상도 링에만 있으면 geomorph 목표가 틀립니다.

스파이크 11(하이트맵 chunk 스트리밍): LOD 레벨별로 로드됨/로드 중/언로드됨 상태를 보여주는 시각적 그리드를 갖춘 더 고급 chunk 스트리밍. 스트리밍 예산을 확립했습니다. 프레임당 최대 로드 chunk 수, LOD 업그레이드가 필요한 chunk의 우선순위. 스컬프팅은 새 우선순위 신호를 추가합니다. 플레이어가 적극적으로 편집 중인 chunk는 절대 언로드되면 안 됩니다.

스파이크 12-14: WebGPU + Three.js 통합

스파이크 12(WebGPU Marching Cubes): 첫 볼류메트릭 스파이크. 애니메이션 구 동굴을 가진 네 개의 64^3 SDF chunk가 전부 GPU에서 돌아갑니다. 원시 WebGPU를 씁니다. SDF 평가용 컴퓨트 파이프라인, Twinklebare 케이스 테이블(256개 구성, 각각 16개 항목)을 가진 MC 추출, 원자적 정점 카운터, 인다이렉트 드로우. 성능 목표는 chunk당 <4ms, 4개 전부 <12ms였습니다. 이것은 GPU MC가 브라우저에서 실시간 재메싱에 충분히 빠르다는 것을 검증했습니다. 이후의 모든 볼류메트릭 스파이크가 여기 정의된 MC 케이스 테이블과 WGSL 셰이더를 재사용합니다.

스파이크 13(스파이크 12에서 기준선 리셋): 스파이크 12의 원시 WebGPU 드로우 경로를 Three.js의 WebGPURenderer 안에서 돌도록 이식해, 백엔드의 device에 직접 접근합니다. 렌더 파이프라인은 여전히 원시 WebGPU를 씁니다(struct Vertex vec4+vec4를 가진 drawIndirect). 이것은 커스텀 컴퓨트와 Three.js 장면 렌더링이 같은 GPU 디바이스에서 공존할 수 있음을 증명했습니다.

스파이크 14(Three.js WebGPU 점진적 견고화): 원시 렌더 파이프라인을 위치와 법선용 Three.js StorageBufferAttribute로 교체했습니다. MC 컴퓨트가 GPU에 상주하는 이 버퍼에 직접 씁니다. drawIndirect 버퍼가 Three.js가 그리는 정점 수를 제어합니다. 이것이 이후 모든 스파이크가 쓰는 패턴입니다. 컴퓨트는 원시 WebGPU로 두고, 렌더링은 Three.js 장면 그래프를 거칩니다. 이 스파이크들 전반에서 Three.js 버전은 WebGPU 백엔드가 안정화되면서 0.170.0에서 0.172.0으로 발전했습니다.

스파이크 15-17: Transvoxel LOD 이음매

스파이크 15(Transvoxel 이음매 스캐폴드): 세 구역 아키텍처를 추가했습니다. MC chunk(볼류메트릭 중심), 전이 스트립(MC 경계와 하이트맵 사이의 이음매), 지형 링(둘러싼 하이트맵). 셋 모두 하나의 머티리얼 패스를 공유합니다. 이 단계에서 전이 스트립은 진짜 Transvoxel 셀이 아니라 자리표시 메시입니다.

스파이크 16(공유 하이트맵을 가진 Transvoxel +X 면): 한 스파이크에 두 가지 핵심 돌파구. 첫째, SDF의 평평한 지형 평면을 공유 Perlin 하이트맵으로 교체했습니다. 257x257 Float32Array를 스토리지 버퍼로 GPU에 업로드하고 SDF 컴퓨트 셰이더에서 양선형 보간으로 샘플링합니다. 이제 MC 표면과 하이트맵 메시가 같은 기준값에 동의합니다. 둘째, GitHub에서 Eric Lengyel의 참조 데이터 테이블(transitionCellClass, transitionVertexData, transitionCellData)과 npm transvoxel-data 패키지를 가져와 +X 면에 대한 진짜 Transvoxel 전이 셀을 구현했습니다. CPU는 9샘플 전이 셀(512개 구성, 73개 동치류)을 평가하고, 그리드 점에서 SDF 값을 보간해 정점을 놓으며, 미러링된 케이스의 와인딩 반전을 처리합니다.

스파이크 17(Dual MC 1x/2x LOD): 서로 다른 해상도의 MC chunk 두 개를 나란히. 고해상도: cell_scale=1.0의 62 셀. 저해상도: cell_scale=2.0의 31 셀. MC 셰이더가 cell_scale과 grid_points uniform을 얻었습니다. transition_shrink를 도입했습니다. 저해상도 chunk의 face-0 경계 정점이 cell_scale의 15%만큼 안쪽으로 당겨져, Transvoxel 전이 셀이 z-fighting 없이 채우는 얇은 간극을 만듭니다. 이것이 프로덕션 시스템에 필요한 LOD 모델입니다. 가까운 chunk는 전체 해상도, 먼 chunk는 절반 해상도, 모든 경계에 Transvoxel.

스파이크 18-21: Transvoxel 코너 케이스와 GPU 가속

이 네 스파이크는 각각 Transvoxel 구현의 특정 실패 케이스를 해결했습니다. 묶어 버리면 별개의 문제들이 가려집니다.

스파이크 18(하이트맵 2:1 이음매): 한쪽이 다른 쪽의 두 배 해상도인 순수 하이트맵 경계에 Transvoxel을 적용했습니다. MC는 관여하지 않습니다. 62 셀과 31 셀 하이트맵 chunk 사이의 이음매가 15% 저면 수축을 곁들인 Transvoxel 전이 테이블에서 생성됩니다. 이것은 Transvoxel이 MC뿐 아니라 하이트맵만 있는 경우에도 작동함을 검증했습니다.

스파이크 19(64/32/32/16 코너 그리드): 가장 어려운 이음매 케이스. 서로 다른 해상도(64, 32, 32, 16 셀)의 chunk 네 개가 코너 점에서 만납니다. 이음매 시스템은 네 에지(A-B, A-C, B-D, C-D)를 따라 각 방향에 올바른 와인딩으로 전이 셀을 생성해야 합니다. 이 스파이크는 Transvoxel 테이블이 커스텀 케이스 로직 없이 다중 해상도 코너를 처리함을 증명했습니다.

스파이크 20(GPU Transvoxel 코너): 64/32/32/16 코너 레이아웃의 Transvoxel 전이 셀 생성을 GPU로 옮겼습니다. 애니메이션 지형을 위해 매 프레임 전이 셀을 다시 생성할 때 CPU가 병목이었습니다. GPU 컴퓨트가 MC 추출과 같은 패스에서 이음매 정점을 생성합니다.

스파이크 21(GPU MC + Transvoxel 코너): 전체 GPU MC 추출과 GPU Transvoxel 이음매 생성을 단일 컴퓨트 디스패치 시퀀스로 결합했습니다. MC chunk와 네 이음매 모두 GPU에서 생성되고, 정점 수는 원자적 카운터로 관리되며 drawIndirect로 그려집니다. 이것이 매끄러운 LOD 전이를 갖춘 다중 해상도 볼류메트릭 지형의 완전한 GPU 파이프라인입니다.

스파이크 22-24: 하이브리드 아키텍처

스파이크 22(하이브리드 MC/하이트맵 정책): 핵심 아키텍처 스파이크. chunk는 기본적으로 하이트맵입니다. 애니메이션 변형 구가 어떤 chunk의 AABB와 교차하면, 그 chunk가 MC 모드로 전환됩니다. 나머지는 정적 하이트맵 메시로 남습니다. 레이아웃: 서로 다른 해상도의 64, 32/32, 16 셀 chunk. Transvoxel 이음매가 MC-하이트맵 전이를 포함한 모든 경계를 처리합니다. 스파이크는 MC chunk 수 대 HM chunk 수와 프레임당 정점 오버플로를 추적합니다.

스파이크 23(정책 주도 chunk 모드): 스파이크 22 위에 패치로 로드됩니다. 카메라 거리 히스테리시스(카메라가 임계값 근처에 있을 때 chunk가 모드 사이를 깜빡이지 않음)와 편집 마스크(변형된 chunk는 변형 소스가 멀어져도 MC 모드를 유지)를 추가했습니다. 이것이 스컬프팅에 필요한 "끈끈한 편집" 동작입니다. 플레이어가 동굴을 깎으면, 그 chunk는 영원히 볼류메트릭으로 남습니다.

스파이크 24(정책 + Clipmap 링): 가장 고급 스파이크. 스파이크 23의 근거리 정책 시스템과 스파이크 10의 원거리 geometry clipmap 링을 결합합니다. Three.js 0.183.1로 업그레이드했습니다. 근거리는 64/32/16 해상도에서 Transvoxel 이음매를 가진 HM/MC 하이브리드를 씁니다. 원거리는 카메라를 따라가는 정적 중심 clipmap 링을 씁니다. 이것이 완전한 지형 렌더링 아키텍처입니다. 필요한 곳에서는 청크화된 볼류메트릭 스컬프팅, 그 외 모든 곳에서는 저렴한 clipmap 지형.

왜 Surface Nets가 아니라 Marching Cubes인가

이 가이드의 외부 연구 섹션은 Surface Nets가 브라우저 지형 스컬프팅의 가장 강력한 후보라고 제안합니다. 하지만 파이프라인의 모든 스파이크가 Marching Cubes를 씁니다. 우연이 아닙니다.

MC의 결정적 강점은 민망할 만큼의 병렬성입니다. 각 큐브가 완전히 독립적입니다. 스파이크 12-24의 WGSL 컴퓨트 셰이더는 큐브당 스레드 하나를 디스패치하며 셀 간 통신이 전혀 없습니다. 원자적 카운터가 정점 할당을 처리합니다. 이것은 GPU 워크그룹에 완벽하게 매핑됩니다.

Surface Nets는 표면을 포함하는 셀마다 정점 하나를 놓은 다음 이웃을 연결합니다. 그 이웃 연결성이 셀 간 의존성입니다. fast-surface-nets 크레이트는 세심한 반복 순서로 CPU에서 이를 처리합니다. GPU에서는 2패스 접근(정점 찾기, 그다음 연결)이나 워크그룹 내 공유 메모리가 필요합니다. 둘 다 WebGPU에서 가능하지만 복잡도를 더합니다.

실질적 권고: 스컬프팅 파이프라인에는 Marching Cubes를 유지하세요. 우리 코드베이스에서 검증되었고, WGSL 셰이더가 존재하며 벤치마크되었고, Transvoxel 이음매 시스템이 MC의 에지 기반 정점 배치를 중심으로 구축되었습니다. MC의 이진 데이터에서의 계단 현상이 눈에 띄는 문제가 되면 Surface Nets를 다시 검토할 가치가 있지만, 값이 매끄러운 기울기인 SDF 지형에서는 MC가 깔끔한 결과를 만듭니다.

스컬프팅을 위한 실질적 아키텍처

스파이크 시퀀스는 렌더링 파이프라인을 해결했습니다. 남은 것은 브러시 시스템, 게임 시스템 전반에 걸친 부수 효과 연쇄, 멀티플레이어 동기화입니다. 다음은 계획이며, 모든 스파이크 위에 세웁니다.

1단계: 하이트맵 스컬프팅(최소 변경, 최대 도달)

프로덕션 world/client/ 코드에 chunk 하이트맵을 수정하는 브러시 도구를 추가합니다. 이것은 기존 WebGL 렌더러 안에서 작동하며 WebGPU가 필요 없습니다.

브러시 입력: placement.ts의 PlacementTool 패턴을 따릅니다. 이미 chunkManager.getChunkMeshes()를 맞히는 Raycaster가 있고 충돌 점에서 고스트 메시를 추적합니다. TerrainBrushTool은 같은 레이캐스트를 하되 오브젝트를 놓는 대신 chunk 하이트맵을 수정합니다. World.onMouseDown 핸들러는 이미 도구 상태에 따라 디스패치합니다.

Chunk 수정(Chunk.applyBrush): 브러시 월드 위치를 하이트맵 그리드 좌표로 매핑합니다. 브러시 반경 안의 각 그리드 점에 대해 감쇠 가중 변위를 계산해 하이트맵 값에 더하거나 뺍니다. 그다음 메시를 업데이트합니다. 수정된 하이트맵에서 정점 Y 위치를 설정하고, 중심 차분으로 법선을 재계산하고(chunk.ts 155-158줄에서 이미 쓰는 것과 같은 terrainHeight(wx +/- eps, wz) 패턴), terrain-material.ts의 createSplatMap()로 영향받은 영역의 splat map을 재생성해 경사 기반 텍스처 블렌딩을 업데이트합니다.

캐릭터 컨트롤러: CharacterController.update()는 접지를 위해 매 프레임 getHeight()를 호출합니다. ChunkManager.getHeight()는 Chunk.sampleHeight()에 위임하고, 이것은 chunk의 heightmap Float32Array에서 읽습니다. 우리가 그 배열을 직접 수정하므로, 캐릭터 컨트롤러는 추가 배선 없이 다음 프레임에 변화를 받아들입니다.

오브젝트 무효화: chunk.ts의 나무 인스턴스는 생성 시점에 terrainHeight()를 샘플링해 배치됩니다. 스컬프팅 후, 영향받은 영역의 나무가 잘못된 높이에 있을 수 있습니다. 1단계는 이것을 미룰 수 있습니다(작은 편집에서는 나무가 약간 떠 있음). 2단계는 높이를 다시 샘플링하고 인스턴스 행렬을 다시 만드는 chunk.invalidateObjects()가 필요합니다. resolveCollisions()에 쓰는 콜라이더도 마찬가지입니다.

Rapier 물리(통합된 경우): 스파이크 02는 하이트필드 콜라이더가 작동함을 증명했습니다. Rapier가 활성 상태라면, 수정된 chunk의 하이트필드 콜라이더를 다시 만들거나 패치해야 합니다. Rapier의 ColliderDesc.heightfield()는 평평한 Float32Array를 받으므로, 직접 교체입니다.

네트워크 동기화: protocol.ts에 MsgType.TerrainEdit = 10을 추가합니다.

interface TerrainEditMsg {
  t: MsgType.TerrainEdit
  cx: number
  cz: number
  brush: {
    wx: number
    wz: number
    radius: number
    strength: number
    falloff: number
    operation: number
  }
}

WorldChunkDO는 이것을 모든 클라이언트에 브로드캐스트하고 Durable Object 스토리지에 저장된 chunk별 편집 로그에 덧붙입니다. 늦게 합류하는 클라이언트는 Snapshot 메시지에서 편집 로그를 받아 재생해 지형 상태를 재구성합니다. 모든 클라이언트가 동일한 결정론적 브러시 함수를 적용하므로, 동일한 하이트맵으로 수렴합니다.

Chunk 언로드/리로드: 스파이크 06과 스파이크 11이 스트리밍 패턴을 확립했습니다. chunk가 언로드되고 나중에 다시 로드될 때, 그 chunk의 편집 로그가 기저 절차적 하이트맵에 대해 재생되어야 합니다. 편집 로그는 서버 측(Durable Object)에 저장되고 Snapshot 메시지에 포함됩니다.

2단계: 스파이크 22-24 아키텍처를 쓴 볼류메트릭 스컬프팅

스파이크 24 파이프라인을 프로덕션 월드에 이식합니다. 플레이어가 표면 아래를 스컬프팅하면(동굴 깎기, 터널 파기), 영향받은 chunk가 하이트맵 모드에서 MC 모드로 전환됩니다.

WebGPU 렌더러 마이그레이션: 스파이크 13-14는 Three.js의 WebGPURenderer가 장면 그래프와 나란히 커스텀 컴퓨트를 호스팅할 수 있음을 증명했습니다. 프로덕션 월드는 MC chunk에 StorageBufferAttribute를 쓰며 WebGLRenderer에서 WebGPURenderer로 옮깁니다. WebGPU를 쓸 수 없을 때는 1단계의 하이트맵 전용 경로로 폴백합니다.

Chunk별 SDF 할당: 스파이크 22의 하이브리드 패턴을 따릅니다. 각 chunk는 하이트맵으로 시작합니다. 첫 볼류메트릭 브러시 스트로크에서 64^3 Float32Array를 할당하고, 하이트맵을 샘플링해 초기화하고(각 점의 SDF 값은 world.y - heightmap_value), MC 렌더링으로 전환합니다. 스파이크 23의 정책 시스템이 그 chunk를 영구적으로 MC 모드로 유지함을 보장합니다(편집 마스크의 "끈끈한 편집" 동작).

SDF 셰이더의 공유 하이트맵: 스파이크 16의 height_at() 함수. chunk의 하이트맵을 GPU 스토리지 버퍼에 업로드합니다. SDF 컴퓨트 셰이더는 max(height_sdf, edit_sdf)를 평가하며, 여기서 height_sdf = world.y - height_at(world.xz)이고 edit_sdf는 브러시 수정을 담습니다. MC와 하이트맵 chunk는 경계에서 기준값에 동의합니다.

Transvoxel 이음매: 스파이크 15-21의 전체 스택. MC-하이트맵 경계는 수축 간극을 가진 전이 셀을 씁니다. 서로 다른 해상도의 MC-MC 경계는 스파이크 17의 듀얼 LOD 패턴을 씁니다. 스파이크 19의 코너 케이스가 4방향 교차를 처리합니다. 스파이크 21의 GPU 컴퓨트가 같은 디스패치에서 모든 이음매 지오메트리를 생성합니다.

Clipmap 원거리: 스컬프팅 범위 밖 지형을 위한 스파이크 24의 clipmap 링. 스컬프팅은 이 링들을 절대 건드리지 않습니다. 이들은 기저 절차적 하이트맵을 샘플링합니다.

Geomorphing: 스파이크 10의 geomorphing이 LOD 전이의 팝인을 없앱니다. 편집된 chunk에 대해서는 geomorph 목표가 편집을 포함해야 합니다. chunk가 LOD0에서 MC이고 그 LOD1 이웃이 하이트맵이면, geomorph가 두 표현 사이를 블렌딩합니다. 이것은 더 낮은 LOD에서도 편집 로그를 샘플링해야 함을 뜻합니다.

머티리얼 예산: 스파이크 08은 45+ FPS에서 4레이어 트라이플래너 + 노멀을 벤치마크했습니다. MC chunk도 같은 머티리얼이 필요합니다. splat map은 하이트맵 경사 대신 SDF 기울기에서 생성할 수 있습니다(가파름 = 바위, 평평함 = 잔디). 이것은 4레이어 예산 안에 머뭅니다.

식생 무효화: 스파이크 07의 밀도 맵 식생은 지형 높이와 경사에 의존합니다. chunk가 MC 모드로 전환되면, SDF 표면을 샘플링해 나무 인스턴스를 다시 생성해야 합니다. 오버행이나 동굴 안의 나무는 컬링해야 합니다. chunk.ts의 인스턴스화된 메시 행렬을 새 표면에서 다시 만듭니다.

3단계: 실행 취소/다시 실행과 네트워크 동기화를 위한 CSG 편집 트리

원시 SDF 변형을 CSG 연산 트리로 교체합니다. 각 브러시 스트로크가 연산(추가, 빼기, 매끄러운 블렌드)을 가진 원시 형상(구, 캡슐, 박스)을 덧붙입니다. SDF는 트리에서 다시 계산됩니다.

이점:

• 비파괴적: 어떤 편집이든 트리에서 제거해 실행 취소 가능
• 네트워크 효율적: 원시 필드 값이 아니라 CSG 연산을 브로드캐스트
• 결정론적: 모든 클라이언트가 동일한 연산 시퀀스에서 동일한 SDF를 구축
• ALICE-SDF의 CSG 트리 diff/patch가 네트워크 전반의 대역폭 효율적 동기화와 실행 취소/다시 실행을 제공

Durable Object 스토리지: chunk별 편집 트리가 1단계의 평평한 편집 로그를 대체합니다. WorldChunkDO는 원시 하이트맵 델타가 아니라 CSG 트리 구조를 저장합니다. Snapshot 메시지는 트리를 포함하고, 늦게 합류하는 클라이언트는 그것을 평가해 로컬 SDF를 만듭니다.

4단계: 협업 스컬프팅

서버 순서의 연산 재생으로 동시 편집 지원을 추가합니다. Durable Object가 각 편집에 타임스탬프를 찍고 순서대로 브로드캐스트합니다. 늦게 합류하는 클라이언트는 연산 로그를 받아 월드 상태를 재구성합니다. 기존 Snapshot 메시지 타입이 chunk별 지형 편집 이력을 포함하도록 확장됩니다.

브러시 스트로크는 작고 국소적이며 가산/감산적이므로, 약간 순서가 뒤바뀐 동시 편집의 시각적 결과는 보통 "올바른" 순서와 구별되지 않습니다. 서버 순서의 last-write-wins로 충분합니다. Durable Object의 tick() 함수(현재 플레이어 상태를 위해 50ms 간격으로 돌아감)가 같은 루프에 지형 편집 브로드캐스트를 추가합니다.

주요 참고 자료

알고리즘:

• Lorensen & Cline, "Marching Cubes" (1987)
• Eric Lengyel, "Transvoxel Algorithm" (2009), transvoxel.org
• Losasso & Hoppe, "Geometry Clipmaps" (SIGGRAPH 2004)
• "A High-Performance SurfaceNets Discrete Isocontouring Algorithm" (arxiv 2401.14906, 2024)
• MCHex (arxiv 2511.02064, 2025)

구현:

• bevy-sculpter v0.18.0 (Rust, Surface Nets + SDF 브러시)
• fast-surface-nets (Rust, 2천만 tri/sec)
• ALICE-SDF v1.3.0 (Rust + WASM, CSG 트리 diff/patch)
• WebGPU SDF Editor (Nijhoff, 2026년 1월)
• SculptingPro (Unity 런타임 스컬프팅 API)
• TerraBrush (Godot 지형 스컬프팅 GDExtension)

게임:

• Dreams (Media Molecule, SDF + 포인트 클라우드 렌더링, SIGGRAPH 2015)
• Teardown (Voxagon, 복셀 DDA 레이트레이싱, 결정론적 멀티플레이어 파괴)
• Mike Turitzin의 SDF 엔진 (brick map + geometry clipmap, 2026년 1월)

네트워크:

• "Optimizing payload size for voxel state synchronization" (Oulu, 2024)
• Teardown 멀티플레이어 (준결정론적 파괴 동기화, 2026년 3월)
• cSculpt (다중 해상도 병합을 갖춘 협업 메시 스컬프팅)

마지막 업데이트: 2026년 7월.

이제 10초짜리 클립을 만드는 건 쉽습니다. 주요 모델이라면 다 합니다. 진짜 질문은 이거죠. 첫 번째 분과 여덟 번째 분에서 캐릭터가 똑같아 보이는 5분, 10분짜리 일관된 비디오를 만들 수 있느냐? 수백 프레임에 걸쳐 장면이 흐트러지지 않고 유지되느냐?

그게 어려운 문제입니다. 그리고 이 부분이 빠르게 바뀌고 있습니다. 이 가이드는 우리가 찾은 모델 중 장편 비디오를 네이티브로 생성하거나, 참조 이미지를 통해 일관된 캐릭터로 장편 콘텐츠를 만드는 데 필요한 워크플로를 지원하는 모든 모델을 다룹니다. 셋으로 나눴습니다. 분 단위 비디오를 직접 생성하는 모델, 참조 이미지 지원이 강력해서 이어붙이기로 확장하는 모델, 그리고 직접 돌릴 수 있는 오픈소스 옵션입니다.

1단계: 네이티브 장편 생성 (분 단위 이상)

이 모델들은 초가 아니라 분 단위로 측정되는 비디오를 생성합니다. 긴 시퀀스에 걸친 시간적 일관성을 위해 처음부터 설계됐습니다.

LongCat Video

메이투안은 2025년 말 LongCat Video를 공개했습니다. 136억 파라미터의 디퓨전 트랜스포머이며, 최대 15분 길이의 일관된 비디오를 안정적으로 생성할 수 있는 최초의 모델입니다.

이 모델은 텍스트-투-비디오, 이미지-투-비디오, 비디오 이어붙이기를 하나의 통합 파이프라인에서 지원합니다. I2V 모드에서는 입력 이미지가 비디오의 첫 프레임 그 자체가 됩니다. 어느 장면에나 배치할 수 있는 느슨한 캐릭터 참조가 아닙니다. 모델은 그 시작 프레임에서 앞으로 애니메이션을 진행하면서 "Cross-Chunk Latent Stitching"을 사용해 생성 내내 원본 이미지를 계속 참조하고, 색상 드리프트를 막으며 긴 시퀀스에 걸쳐 시각적 일관성을 유지합니다. 2026년 업데이트 버전은 립싱크가 포함된 오디오 구동 아바타 생성을 추가해 5분 이상의 토킹 헤드 비디오를 만들 수 있습니다.

내부적으로 LongCat은 거친 단계에서 정교한 단계로 가는 생성 방식과 Block Sparse Attention을 사용해 엄청난 시퀀스 길이를 처리합니다. RLHF 튜닝으로 모션 품질을 높였습니다. VBench 2.0 벤치마크에서는 Google Veo 3와 Shengshu의 Vidu Q1에 이어 전체 3위에 올랐습니다.

이용 방법: MIT 라이선스로 오픈소스. fal.ai API를 통해 생성 1초당 $0.04에 제공됩니다(720p 기준 15분 비디오가 $36). LongCat 자체 플랫폼에서도 크레딧 기반 가격으로 이용할 수 있습니다.

Seaweed APT2

바이트댄스의 Seaweed APT2는 다른 접근을 택합니다. 완성된 비디오를 미리 생성하는 대신, 단일 H100에서 프레임당 단 0.16초의 지연으로 24fps에서 프레임을 자기회귀 방식으로 만들어냅니다. 그 결과는 최대 5분까지 안정적으로 유지되는, 시간적 일관성을 갖춘 비디오입니다.

기술적 핵심은 Autoregressive Adversarial Post-Training (AAPT)으로, 사전 학습된 양방향 비디오 디퓨전 모델을 단방향 자기회귀 생성기로 변환합니다. 프레임당 단일 네트워크 순전파 평가. 이것이 실시간 생성을 가능하게 하는 비결입니다.

이 모델이 단순한 길이를 넘어 흥미로운 점은 인터랙티브함입니다. 비디오가 렌더링되는 동안 카메라를 제어하고, 포즈 감지로 캐릭터에 동작을 입히고, 장면을 조작할 수 있습니다. "비디오를 생성한다"기보다 "비디오를 실시간으로 조종한다"에 가깝다고 생각하면 됩니다.

이용 방법: 연구 단계 전용. 아직 공개되지 않았습니다. 7B 베이스 모델(Seaweed-7B)은 논문이 발표됐지만 APT2 가중치는 아직 공개되지 않았습니다.

Helios

Helios는 베이징대학교에서 나왔으며 Wan 2.1 위에 구축됐습니다. 140억 파라미터 모델로, 단일 H100에서 19.5 FPS로 분 단위 비디오를 생성합니다. 핵심 혁신은 장편 비디오의 드리프트를 다루는 방식입니다. self-forcing이나 키프레임 샘플링 같은 기존 드리프트 방지 기법을 쓰는 대신, Helios는 학습 중에 드리프트를 시뮬레이션해서 모델이 스스로 보정하도록 학습시킵니다.

텍스트-투-비디오, 이미지-투-비디오, 비디오-투-비디오 작업을 네이티브로 지원합니다. I2V 모드는 참조 이미지를 받아 생성의 시드로 삼습니다.

이용 방법: Apache 2.0 라이선스로 완전 오픈소스. 2026년 3월 공개. 코드와 가중치는 GitHub에 있습니다(PKU-YuanGroup/Helios). Diffusers, SGLang, vLLM-Omni에 통합돼 있습니다. HuggingFace Spaces에 Gradio 데모가 있습니다.

SkyReels V2 / V3

Skywork의 SkyReels 라인은 무제한 길이 비디오를 목표로 합니다. V2는 AutoRegressive Diffusion-Forcing 아키텍처를 사용해 고정된 길이 상한 없이 비디오를 생성합니다. 2026년 1월에 공개된 V3는 참조 이미지-투-비디오, 비디오-투-비디오 확장, 오디오 기반 아바타 생성을 하나의 모델로 통합했습니다.

V3는 1~4장의 참조 이미지를 받아 생성된 비디오 전반에 걸쳐 피사체의 정체성을 유지합니다. 비디오-투-비디오 모드는 매끄러운 단일 샷 이어붙이기와 영화적 전환이 들어간 멀티샷 전환을 가능하게 합니다.

Skywork는 2026년 2월 25일 SkyReels V4를 출시했습니다. 최대 1080p/32fps로 비디오와 오디오를 하나의 듀얼 스트림 패스에서 함께 생성하는 최초의 오픈소스 모델입니다. 텍스트, 이미지, 비디오 클립, 마스크, 오디오를 컨디셔닝 입력으로 받고 생성, 인페인팅, 편집을 하나의 프레임워크로 통합하면서, V2/V3의 참조 후 확장 라인에 네이티브 사운드를 더했습니다. 현재 Artificial Analysis 텍스트-투-비디오 아레나 상위권에 자리 잡고 있습니다.

이용 방법: 완전 오픈소스. 13억에서 140억 파라미터까지의 모델. 540p와 720p로 제공. 코드와 가중치는 GitHub와 HuggingFace에 있습니다.

2단계: 강력한 참조 + 확장이 있는 짧은 클립

이 모델들은 8~60초 클립을 생성하지만 강력한 참조 이미지 지원과 비디오 확장 기능을 제공합니다. 장편 콘텐츠를 만들려면 모델의 이어붙이기 또는 확장 엔드포인트를 사용해 클립을 연결합니다. 캐릭터 일관성은 여러 생성에 걸쳐 유지되는 참조 이미지에서 나옵니다.

이것이 1분을 넘는 콘텐츠를 위해 오늘날 대부분의 창작자가 쓰는 실용적인 워크플로입니다. 클립당 품질은 네이티브 장편 모델보다 높은 경우가 많습니다.

Kling 3.0 Omni (콰이쇼우)

Kling은 모든 비디오 모델 중 가장 완성도 높은 참조 이미지 시스템을 갖췄습니다. 참조 입력을 세 가지 별개 범주로 나누고, 각 범주는 서로 다른 목적을 가집니다.

참조 이미지 (image_urls): 스타일과 외관 안내를 위한 최대 4장. 프롬프트에서 @Image1, @Image2 등으로 태그합니다. 첫 프레임이 되지 않으면서 전체적인 룩, 장면 스타일, 환경에 영향을 줍니다.

요소 (elements): 전용 캐릭터/오브젝트 입력. 각 요소는 frontal_image_url(선명한 정면 사진) 하나와 선택적인 reference_image_urls(추가 각도)를 받습니다. 프롬프트에서 @Element1, @Element2로 참조합니다. 모델은 캐릭터의 정체성을 추출해 당신이 묘사하는 어떤 장면에든 배치합니다. 이것이 모험 영화 스타일 콘텐츠의 핵심 기능입니다. 캐릭터 사진을 업로드한 다음 그가 숲을 걷거나, 용과 싸우거나, 무엇이든 원하는 장면을 묘사하면 됩니다.

시작/끝 프레임 (start_image_url, end_image_url): 특정 이미지를 첫 프레임 또는 마지막 프레임으로 고정합니다. 이건 말 그대로 프레임이지 스타일 가이드가 아닙니다.

세 범주를 합친 총량은 최대 7개 참조 입력입니다(참조 비디오도 함께 쓰면 4개로 줄어듭니다). "@Element1 and @Element2 are having dinner at this table on @Image1" 같은 단일 프롬프트로 캐릭터와 장면 참조를 결합할 수 있습니다.

장편 콘텐츠의 경우 Kling은 두 가지 경로를 제공합니다. 멀티샷 모드는 한 번의 호출로 최대 6개 장면을 생성하며, 각 장면은 자체 프롬프트와 길이(각 3~15초)를 가집니다. 캐릭터 요소는 모든 샷에 걸쳐 자동으로 일관성을 유지합니다. 확장 API는 완성된 비디오가 끝난 지점에서 이어 생성하며, 이어붙인 확장을 통해 약 3분에 이릅니다. V2V 편집 모드는 기존 비디오(3~10초)를 받아 요소 참조와 텍스트 프롬프트로 변환하는데, 소스의 카메라 움직임과 캐릭터 배치를 보존하면서 당신의 참조에 따라 캐릭터와 환경을 다시 스타일링합니다. 덕분에 Kling은 저충실도 3D 렌더를 포함해 기존 푸티지를 향상시키는 데 특히 유용합니다.

Kling 3.0 Omni는 텍스트-투-비디오, 이미지-투-비디오, 참조-투-비디오, 비디오 편집을 하나의 모델로 통합하며 네이티브 오디오 생성과 립싱크를 지원합니다. 2026년 6월 17일, 콰이쇼우는 Kling 3.0 Turbo를 추가했습니다. 720p와 1080p에서 오디오가 번들된 더 빠르고 저렴한 변형으로(정가 약 $0.11~0.14/초), Omni의 편집 파이프라인이 4K 비디오를 입력하고 출력하도록 업그레이드했습니다.

이용 방법: 콰이쇼우, fal.ai($0.084~0.112/초), Replicate를 통한 상업용 API. 웹 인터페이스는 klingai.com.

Grok Imagine (xAI)

xAI는 2026년 초 Grok Imagine의 Reference-to-Video 모드를 1~7장의 참조 이미지 지원과 함께 출시했습니다. 문서는 이를 이미지-투-비디오와 명확히 구분합니다. "소스 이미지가 시작 프레임이 되는 이미지-투-비디오와 달리, 참조 이미지는 첫 프레임을 고정하지 않으면서 비디오에 등장하는 내용에 영향을 줍니다."

프롬프트에서 이미지를 <IMAGE_1>, <IMAGE_2> 등으로 태그합니다. "the model from <IMAGE_1> walks onto the runway wearing the shirt from <IMAGE_2>" 같은 프롬프트는 인물 참조와 의상 참조를 결합합니다. 모델은 가상 피팅, 제품 배치, 그리고 여러 장면에 걸친 캐릭터 일관 스토리텔링을 처리합니다.

한 가지 제약이 있습니다. 같은 요청에서 참조 이미지와 이미지-투-비디오를 결합할 수 없습니다. 첫 프레임 모드이거나 참조 모드이거나 둘 중 하나이지, 둘 다는 안 됩니다.

Grok Imagine에는 기존 비디오 끝에 새 푸티지를 추가하는 비디오 확장 엔드포인트도 있습니다. duration 파라미터는 새로 추가되는 부분만 제어합니다. 확장을 이어붙여 더 긴 콘텐츠를 만들 수 있습니다.

xAI는 2026년 6월 3일 Grok Imagine 1.5를 API 프리뷰로 공개한 뒤, 6월 16일 grok-imagine-video-1.5로 정식 출시했으며, Fast 변형이 소비자 앱에 순차 배포되고 있습니다. 한 장의 정지 이미지를 카메라 무빙, 분위기, 물리, 그리고 같은 추론 패스에서 네이티브로 생성된 동기화 오디오와 함께 영화적인 모션으로 살려내는 이미지-투-비디오 모델입니다. 일관된 장면을 이어붙이는 멀티샷 시퀀싱을 지원하고, 6초 720p 클립을 약 25초 만에 생성하며, 현재 Artificial Analysis 이미지-투-비디오 아레나에서 3위에 올라 있습니다. 가격은 480p에서 $0.08/초, 720p에서 $0.14/초이며, 입력 이미지 한 장당 $0.01이 추가됩니다.

이용 방법: xAI API(2026년 1월 출시), fal.ai, Replicate. Python SDK, JavaScript/AI SDK, REST API. 720p 오디오 포함 $0.05/초. X Premium 구독자에게도 제공됩니다.

Seedance 2.0 (바이트댄스)

바이트댄스의 Seedance 2.0은 모든 모델 중 가장 많은 참조 입력을 받습니다. 최대 9장의 이미지, 3개의 비디오, 3개의 오디오 파일을 포함해 동시에 최대 12개 파일까지. 이 모델은 8개 이상의 언어에서 음소 단위 립싱크가 들어간 네이티브 오디오-비디오 생성을 지원합니다.

개별 이미지는 각각 최대 30MB까지 가능합니다. 참조 비디오는 2~15초여야 합니다. 모델은 참조를 캐릭터 외관, 장면 스타일링, 모션 안내에 사용합니다.

다음 도약은 이미 예정돼 있습니다. 바이트댄스는 2026년 6월 23일 볼케이노 엔진 FORCE 콘퍼런스에서 Seedance 2.5를 발표했습니다. 한 번의 패스로 네이티브 30초 단일 클립을 만들고, 멀티모달 참조 파일을 기존 12개에서 최대 50개까지 받습니다. 먼저 Dreamina와 Jimeng을 통해 순차 배포되며, API는 2026년 7월 16일 BytePlus에서 열립니다. 시연대로 출시된다면 이 가이드가 설명하는 클립 이어붙이기 상당 부분을 없애게 됩니다.

이용 방법: 바이트댄스 공식 API(Volcengine를 통해, 2026년 2월 출시) 및 서드파티 API 제공자. API로는 480p~720p 출력, 플랫폼을 통해서는 최대 2K 시네마 해상도.

Runway Gen-4.5

Runway Gen-4.5는 1,247 ELO로 Artificial Analysis 텍스트-투-비디오 리더보드 1위에 올라 당시 Veo 3와 Sora 2 Pro를 앞섰습니다. 2026년 중반에는 아레나 순위가 재편됐지만(현재 Gemini Omni Flash가 선두), Gen-4.5는 영화적 품질과 제어 가능한 액션 면에서 여전히 최상위 모델입니다. 이 모델은 텍스트-투-비디오에서 2~10초 클립을 생성하고, 멀티샷 시퀀싱을 통해 최대 1분까지 캐릭터 일관 장편 비디오를 지원합니다.

이미지-투-비디오는 2026년 1월에 추가됐으며 모든 화면비에서 참조 이미지를 지원합니다. 이 모델은 디퓨전 아키텍처 안에 뉴럴 래디언스 필드와 가우시안 스플래팅을 통합해, 단순한 픽셀 단위 예측이 아니라 3D 기하 이해 능력을 갖췄습니다. 덕분에 오브젝트 지속성이 좋아지고 물리적으로 그럴듯한 모션이 나옵니다.

이용 방법: 상업용 API와 웹 인터페이스. Node와 Python용 SDK. Replicate에서도 제공.

Google Veo 3.1

Google의 Veo 3.1은 4초, 6초, 8초 클립을 네이티브로 생성합니다. "Extend Video" 기능(현재 프리뷰)은 클립을 이어붙여 약 1~2.5분에 이르지만, 긴 시퀀스에서는 일관성이 흐트러질 수 있습니다.

"Ingredients to Video" 기능은 최대 3장의 참조 이미지를 입력으로 받습니다. 애니메이션을 입힐 캐릭터, 배경, 재질 텍스처를 줄 수 있습니다. 참조 이미지를 사용하면 모델이 당신의 시각 참조에 더 가깝게 따라가고 무작위 변형을 덜 합니다. 한 가지 제약이 있습니다. 참조 이미지 모드는 8초 길이 옵션에서만 작동합니다.

2026년 1월 기준, Veo 3.1은 Vertex AI에서 참조 기반 생성에 세로 비디오(9:16)와 4K 업스케일링을 추가했습니다.

이용 방법: Google Vertex AI API, Gemini API, Google Flow. Google Cloud 계정이 필요합니다.

Google Gemini Omni Flash

Google은 2026년 5월 I/O에서 Gemini Omni 제품군을 발표하고 그 첫 모델로 Gemini Omni Flash를 출시했습니다. 이 모델은 곧바로 Artificial Analysis 아레나에서 Veo 3.1을 제치고 1위를 차지했습니다. 핵심은 대화형 비디오입니다. 텍스트, 이미지, 또는 비디오로 10초짜리 클립을 생성한 뒤, 서로 위에 쌓이는 후속 지시로 편집합니다. 조명을 바꾸고, 의상을 교체하고, 카메라를 조정하는 것을 전부 처음부터 다시 생성하지 않고 할 수 있습니다.

참조 지원 면에서 Omni Flash는 이미지와 짧은 비디오 클립을 스타일, 모션, 이펙트 참조로 받으며 오디오 참조는 예정돼 있습니다. 캐릭터 일관성은 대화형 편집에 걸쳐 유지되지만, Google 자체 문서도 장면 전환과 카메라 팬에서는 흐트러질 수 있다고 밝히니 캐릭터 비중이 큰 출력물은 내보내기 전에 검토하세요.

이용 방법: API(gemini-omni-flash-preview)는 2026년 6월 30일 Google AI Studio와 Gemini API를 통해 퍼블릭 프리뷰로 열렸으며, 출력 1초당 약 $0.10입니다. 모든 클립에는 SynthID 워터마크가 들어갑니다. 소비자용 접근은 Gemini 앱, Google Flow, YouTube Shorts를 통해 제공됩니다.

OpenAI Sora 2 / Sora 2 Pro

단종 예정(2026): OpenAI가 Sora를 접고 있습니다. 소비자용 Sora 앱은 2026년 4월 26일에 닫혔고, Sora 2 API는 2026년 9월 24일에 종료되며 후속작 발표는 없습니다. 아래 기능들은 여전히 주목할 만하지만, Sora 위에 새 파이프라인을 구축하지는 마세요. 대신 Kling, Grok Imagine, 또는 오픈 모델을 쓰세요.

Sora 2 Pro는 최대 20초 클립을 생성합니다. Characters API는 Kling이나 Grok과 다른 접근을 씁니다. 정적 이미지를 업로드하는 대신, API를 비디오 클립(1~3초 타임스탬프 범위 포함)에 가리켜서 character_id를 만듭니다. Sora는 비디오 프레임을 분석해 얼굴 구조, 신체 비율, 의상 스타일, 그 밖의 식별 특징을 추출합니다. 그 character_id는 무기한 유지되며 이후 무제한 생성에 걸쳐 재사용할 수 있습니다.

생성당 최대 2개의 업로드된 캐릭터를 참조할 수 있습니다. 2026년 3월 기준, 캐릭터 참조는 사람뿐 아니라 오브젝트와 동물에도 작동합니다. 비디오 확장은 초기 클립 전체를 이어붙이기의 컨텍스트로 사용합니다.

캐릭터 시스템은 캐릭터를 만들려면 비디오 입력(정적 이미지가 아님)이 필요합니다. 사진만 있다면 먼저 짧은 비디오를 생성한 다음 거기서 캐릭터를 추출해야 합니다.

이용 방법: 프로덕션 워크플로를 위한 Batch API 지원이 포함된 OpenAI API.

MiniMax Hailuo 02

Hailuo 02는 출시 당시 Artificial Analysis 벤치마크에서 전 세계 2위에 올라 Veo 3를 앞섰습니다. 네이티브 1080p로 10초 클립을 생성하며 이 분야 최고 수준의 물리 시뮬레이션을 갖췄습니다. 모델은 체조나 곡예 같은 극한 동작도 무너지지 않고 처리합니다.

얼굴 인식과 신체 추적을 통한 강력한 캐릭터 일관성으로 이미지-투-비디오 생성을 지원합니다. Noise-aware Compute Redistribution 아키텍처는 장면 복잡도에 따라 연산을 동적으로 배분합니다.

이후 MiniMax는 Hailuo 02를 넘어 Hailuo 2.3 패밀리(Standard, Pro, Fast, Fast Pro)로 넘어갔으며, 물리적 동작, 스타일라이제이션, 캐릭터 미세 표정을 개선했습니다. 1080p에서 6초 또는 768p에서 10초를 출력하며 MiniMax 플랫폼과 fal.ai를 통해 제공됩니다.

이용 방법: 상업용 API. MiniMax 플랫폼, fal.ai, Replicate를 통해 제공. 비디오당 $0.28.

Luma Ray3.2

Luma의 Ray2는 Ray3 제품군으로 대체됐습니다. Ray3(2025년 9월)는 정체성 고정을 위한 Character Reference와 Modify 비디오-투-비디오 모드를 추가했고, Ray3.2(2026년 6월 9일)는 클립당 최대 16개 키프레임의 프레임 단위 제어, Reframe 기능, 최대 20초 클립, 그리고 Ray3 라인 최초의 퍼블릭 API를 더했습니다. 출력은 네이티브 1080p이며 Hi-Fi 업스케일로 4K를 쓸 수 있습니다. 이미지-투-비디오는 참조 이미지를 시작 또는 끝 키프레임으로 받습니다.

이용 방법: Luma API와 웹 인터페이스.

Pika 2.5

Pika는 Pikaframes로 키프레임 기반 접근을 택합니다. 2~5개의 키프레임(핵심 순간의 참조 이미지)을 업로드하면 모델이 그 사이를 매끄럽게 전환합니다. 총 길이는 20~25초에 이릅니다.

Pikascenes는 최대 10장의 참조 이미지를 받아 하나의 비디오로 결합합니다. 모델은 이미지 인식을 사용해 각 참조의 역할(캐릭터, 배경, 소품)을 자동으로 파악합니다.

이용 방법: Pika 웹 플랫폼과 API. 무료부터 Pro까지의 구독 플랜.

3단계: 자체 호스팅 워크플로를 위한 오픈소스 모델

이 모델들은 더 짧은 클립을 생성하지만 완전히 개방돼 있습니다. 자체 하드웨어에서 돌리고, 파인튜닝하고, API 의존 없이 커스텀 확장 파이프라인을 만들 수 있습니다.

Wan 2.1 (알리바바)

Wan 2.1은 여러 다른 모델(Helios 포함)이 기반으로 삼는 토대입니다. Wan-VAE 아키텍처는 시간 정보를 보존하면서 어떤 길이든 1080p 비디오를 인코딩하고 디코딩합니다. 모델은 480p와 720p의 I2V 변형, 그리고 두 참조 이미지 사이에 비디오를 생성하는 첫-끝 프레임-투-비디오 모델로 제공됩니다.

Wan-Edit은 특정 구조나 캐릭터 포즈를 유지하면서 참조 이미지를 사용한 스타일 및 콘텐츠 전이를 가능하게 합니다. Wan 2.2(2025년 7월)는 더 새로운 오픈 릴리스로, 단일 RTX 4090에서 돌아가는 5B 변형을 갖춘 Mixture-of-Experts 모델이며 여전히 Apache 2.0입니다. 자체 호스팅 사용자를 위한 중요한 주의점 하나: Wan은 2.5에서 비공개로 돌아섰습니다. 더 새로운 Wan 2.5, 2.6, 그리고 이제 2.7(2026년 중반 Artificial Analysis 오디오 포함 아레나에서 3위)은 동기화 오디오와 더 높은 해상도를 더했지만 공개 가중치 없이 API 전용이라, 2.2가 여전히 오픈의 상한입니다. Wan 2.7 가중치를 다운로드할 수 있다고 주장하는 SEO 페이지는 무시하세요. 공식 GitHub 조직과 Hugging Face 계정은 2.2까지가 최대입니다.

HunyuanVideo (텐센트)

텐센트의 130억 파라미터 모델은 2025년 대부분의 기간 동안 오픈소스 비디오 생성의 선두였습니다. HunyuanVideo-I2V는 사전 학습된 MLLM과 함께 토큰 교체 기법을 사용해 참조 이미지 정보를 통합합니다. 2025년 11월에 공개된 HunyuanVideo-1.5는 효율을 개선했습니다. HunyuanCustom은 멀티모달 기반 커스텀 비디오 생성을 가능하게 합니다.

LTX-2 (Lightricks)

Lightricks는 2026년 1월 LTX-2를 전체 가중치, 추론 코드, 학습 코드와 함께 오픈소스로 공개했습니다. DiT 기반 모델로 비디오와 동기화된 오디오를 한 번의 패스에서 함께 생성하며, 네이티브 4K에 최대 50fps, 클립은 최대 20초입니다. 이미지-투-비디오와 멀티 키프레임 컨디셔닝이 기본 내장돼 있어, Pikaframes처럼 클립의 여러 지점에 참조 정지 이미지를 고정할 수 있습니다.

라이선스가 관건인데, 규모에 따라 걸림돌이 될 수도 아닐 수도 있습니다. LTX-2는 연구용과 연 매출 $10M 미만의 상업적 사용에 무료입니다. 그 이상이면 상업 라이선스가 필요하므로, 엄밀히 말해 오픈소스라기보다 오픈 웨이트입니다. 현재 체크포인트인 LTX-2.3은 오디오와 프롬프트 준수가 개선된 220억 파라미터 업데이트입니다. 가중치는 8스텝 증류 변형, LoRA 어댑터, ComfyUI 및 Diffusers 통합과 함께 Hugging Face에 있으며, 호스팅 API는 LTX 플랫폼, fal.ai, Replicate에서 돌아갑니다.

CogVideoX (칭화/Zhipu AI)

CogVideoX는 3D causal VAE를 사용해 시퀀스 길이를 줄이고 깜빡임을 방지합니다. 적응형 LayerNorm 트랜스포머는 텍스트-비디오 정렬을 개선합니다. 2B(Apache 2.0)와 5B(연구 라이선스) 변형으로 제공되며 Diffusers에 네이티브로 통합됩니다.

클립은 720x480에서 6~10초입니다. 짧지만 품질 대비 연산 비율이 좋고 12GB GPU에서 돌아갑니다.

첫 프레임 vs 진짜 참조: 핵심 차이

모든 "참조 이미지" 지원이 똑같지는 않습니다. 이 차이를 이해하는 것이 올바른 모델을 고르는 데 결정적입니다.

첫 프레임 모델(LongCat, Helios, Hailuo, Luma Ray2, HunyuanVideo)은 당신의 이미지를 말 그대로 오프닝 프레임으로 다룹니다. 모델은 그 정확한 화면에서 앞으로 애니메이션을 진행합니다. 캐릭터 헤드샷을 업로드한 뒤 다른 장면에서 그를 묘사할 수 없습니다. 이미지가 곧 장면입니다.

진짜 참조 모델(Kling, Grok Imagine, Seedance, SkyReels V3)은 당신의 이미지에서 정체성을 추출해 그 캐릭터/오브젝트를 당신이 묘사하는 어떤 장면에든 배치합니다. 한 사람의 사진을 업로드한 다음 "그 사람이 해질녘 숲을 걷는다"라고 프롬프트하세요. 캐릭터가 완전히 새로운 환경에 등장하면서도 정체성을 유지합니다. 모험 영화처럼 여러 장면으로 이뤄진 서사 콘텐츠에 필요한 것이 바로 이겁니다.

캐릭터 ID 모델(Sora 2 Pro)은 정적 이미지가 아니라 비디오 클립에서 정체성을 추출합니다. 지속적인 캐릭터 ID를 한 번 만들어 두면 이후 무제한 생성에 걸쳐 재사용합니다.

스타일/재료 모델(Veo 3.1)은 참조 이미지를 사용해 특정 캐릭터 정체성을 추출하기보다 시각 스타일, 텍스처, 전체적인 룩에 영향을 줍니다. 프로젝트 전반의 시각 일관성을 유지하는 데 좋지만, 개별 캐릭터 제어에는 덜 정밀합니다.

10분 비디오를 위한 진짜 워크플로

2026년 중반 현재 상황에 대한 솔직한 평가입니다. 한 번에 일관되고 고품질인 10분 비디오를 단일 모델로 안정적으로 생성하는 모델은 없습니다. LongCat Video가 15분을 주장하며 가장 근접하지만, 그 길이에서는 품질과 일관성 편차가 큽니다. Helios와 SkyReels V2는 각각 "분 단위"와 "무제한 길이" 비디오를 생성하지만, 출력물은 세심한 프롬프트가 필요하고 여러 번 시도해야 하는 경우가 많습니다.

5~15분 비디오를 만드는 대부분의 창작자에게 실제로 통하는 워크플로는 여러 접근을 결합합니다.

토킹 헤드 / 아바타 콘텐츠: LongCat Video의 2026년 오디오 구동 모드나 SkyReels V3의 아바타 생성은 일관된 말하는 캐릭터를 5분 이상 만들 수 있습니다. "버튼 하나 누르면 긴 비디오가 나온다"에 가장 가까운 방법입니다.

여러 장면이 있는 서사 콘텐츠(모험 영화 스타일): Kling 3.0, Grok Imagine, Seedance 2.0을 진짜 캐릭터 참조 이미지와 함께 사용하세요. 각 10~15초짜리 개별 샷을 생성합니다. 모든 생성에 걸쳐 같은 @Element 또는 <IMAGE> 참조를 써서 캐릭터 정체성을 유지하세요. 멀티샷 모드(Kling은 호출당 6샷 지원)나 확장 API로 샷을 이어붙이세요. 이 워크플로에서 가장 검증된 것은 Kling입니다. Grok Imagine은 "참조 모드"와 "첫 프레임 모드"를 명시적으로 분리해 강력한 대안이 됩니다. Seedance 2.0은 가장 많은 참조 입력(12개 파일)을 받지만 더 새롭고 덜 검증됐습니다.

여러 클립에 걸친 캐릭터 일관성: Sora 2 Pro의 지속적 character_id 시스템은 아주 긴 프로젝트에 가장 깔끔한 방법입니다. 짧은 비디오에서 캐릭터를 한 번 추출한 뒤, 그 ID를 참조하는 수십 개의 클립을 생성하세요. 캐릭터 정체성은 매번 이미지에서 다시 해석되는 게 아니라 지속적인 임베딩으로 저장되기 때문에 시간이 지나도 저하되지 않습니다.

스타일 전이 콘텐츠: fal.ai의 Lucy Restyle은 기존 비디오를 최대 30분까지 처리해 모션을 보존하면서 AI 스타일 변환을 적용합니다. 소스 푸티지가 있다면 이 방법은 생성 길이 문제를 완전히 비껴갑니다. 소스 비디오 1초당 $0.01.

오픈소스 파이프라인: Wan 2.1이나 Helios 위에 비디오 이어붙이기 루프를 구축하세요. 클립을 생성하고, 마지막 프레임을 다음 클립의 시작 프레임으로 쓰고, 반복합니다. ComfyUI 워크플로가 이를 자동화합니다. 반복이 많아지면 일관성이 떨어지지만 무료이고 제어 가능합니다.

핵심 과제는 여전합니다. 진짜 참조 이미지 지원이 있어도 캐릭터 드리프트는 수십 개의 클립에 걸쳐 누적됩니다. 얼굴 특징, 머리카락, 의상, 피부톤이 서서히 변합니다. 우회책(고품질 참조 사진, 일관된 프롬프트, 샷 배치 처리)이 꼭 필요합니다. 하지만 Kling과 Grok Imagine처럼 캐릭터 정체성과 장면 구성을 분리하는 모델은 첫 프레임 전용 모델보다 이를 훨씬 쉽게 만듭니다.

3D 스캐폴드 접근: 낮게 렌더하고, 높게 변환하라

장편 생성 문제 대부분을 완전히 비껴가는 워크플로가 주목받고 있습니다. AI 모델에게 처음부터 10분짜리 비디오를 생성하라고 하는 대신, 올바른 카메라 워크, 캐릭터 블로킹, 타이밍이 들어간 저충실도 3D 컷신을 렌더한 뒤, 참조 이미지와 향상 프롬프트와 함께 비디오-투-비디오 모델에 통과시킵니다. 3D 엔진이 구조를 담당하고, AI가 미학을 담당합니다.

이것이 통하는 이유는 V2V 변환이 완전 생성보다 더 좁은 문제이기 때문입니다. 모델은 카메라 모션, 캐릭터 배치, 장면 구성을 만들어낼 필요가 없습니다. 그저 당신의 시각 참조를 따라가며 기존 푸티지를 사실적으로 보이게 하면 됩니다. 그게 훨씬 다루기 쉽고, 당신의 3D 엔진이 렌더할 수 있는 어떤 길이로도 확장됩니다.

왜 통하는가

당신의 3D 엔진은 AI 비디오 모델이 여전히 어려워하는 모든 걸 줍니다. 정밀한 카메라 제어, 프레임 전반에 걸친 정확한 캐릭터 배치, 올바른 물리 상호작용, 그리고 수 분의 푸티지에 걸친 일관된 타이밍. 달리 줌, 트래킹 샷, 신호에 맞춰 화면에 들어오고 나가는 캐릭터, 이 모든 게 3D 엔진에서는 사소하지만 텍스트 프롬프트 생성에서는 불안정합니다. V2V 모델의 유일한 일은 당신이 이미 정의한 기하와 모션을 보존하면서 재질, 조명, 텍스처를 사실적인 출력으로 변환하는 것입니다.

캐릭터 일관성도 더 쉬워집니다. 50번의 개별 AI 생성에 걸친 정체성 드리프트와 싸우는 대신, 모든 프레임에서 같은 3D 캐릭터를 모델에 보여주는 겁니다. 참조 이미지는 그 캐릭터가 최종 출력에서 어떻게 보여야 하는지를 모델에 알려줍니다. 매번 처음부터 일관된 캐릭터를 생성하는 것보다 더 단순한 문제죠.

그리고 길이는 더 이상 제약이 아닙니다. Lucy Restyle은 단일 호출로 30분을 처리합니다. ComfyUI의 Wan 2.1은 청크 단위로 어떤 길이든 처리할 수 있습니다. 푸티지가 이미 존재하기 때문에 "10분을 어떻게 생성하나" 문제와는 아예 싸우지 않습니다.

RealMaster (Meta / 텔아비브 대학교)

RealMaster는 이 워크플로를 위해 특별히 만들어진 연구 시스템입니다. 2026년 3월 Meta Reality Labs와 텔아비브 대학교가 발표했으며, 렌더된 3D 비디오를 소스와 완전한 기하 정렬을 유지하면서 사실적인 비디오로 변환합니다.

이 방법은 3D 렌더에서 엣지 맵을 추출해 구조와 모션을 보존한 뒤, 비디오 디퓨전 모델(VACE/Wan 아키텍처 기반)을 적용해 나머지 전부를 사실적인 출력으로 변환합니다. 경량 IC-LoRA 어댑터가 파이프라인을 단일 추론 패스로 증류해, 앵커 프레임이 필요 없고 시퀀스 중간에 나타나는 오브젝트도 처리합니다.

GTA-V와 CARLA 시뮬레이터 시퀀스에서 테스트한 결과, RealMaster는 범용 비디오 편집 베이스라인을 크게 능가합니다. 사실화 변환 위에 텍스트 프롬프트("비를 내리게 해", "눈을 내리게 해")로 날씨 효과를 입힐 수도 있습니다. 모델은 재학습 없이 시뮬레이터를 넘나들며 일반화됩니다. GTA-V 데이터로 학습한 가중치가 추가 튜닝 없이 CARLA 출력에서 작동합니다.

이용 방법: 연구 전용. 아직 공개 가중치나 API 없음.

오늘 이용할 수 있는 프로덕션 V2V 도구

요소 참조가 포함된 Kling 3.0 V2V가 가장 완성도 높은 프로덕션 옵션입니다. fal.ai의 Edit Video와 Reference V2V 엔드포인트는 3~10초 소스 비디오 클립과 함께 요소 참조(@Element1, @Element2, 정면 및 다각도 사진 포함), 그리고 향상 프롬프트를 받습니다. 모델은 소스의 모션 궤적과 카메라 패턴을 분석한 뒤, 원래의 배치와 카메라 워크를 보존하면서 당신이 지정한 캐릭터 외관과 시각 스타일로 푸티지를 다시 생성합니다. 최대 7개 참조 입력. 1080p 출력. 컷신을 10~15초 청크로 처리하되, 모든 청크에 같은 요소 참조를 써서 캐릭터 일관성을 유지하세요.

Lucy Restyle 2는 단일 API 호출로 최대 30분의 소스 비디오를 입력 1초당 $0.01에 처리합니다. 텍스트 프롬프트와 스타일 안내용 선택적 참조 이미지를 받습니다. Kling 같은 캐릭터별 요소 참조는 없지만, 전체 길이 3D 렌더의 전반적인 영화적 스타일 전이라면 가장 단순하고 저렴한 길입니다. 완성된 렌더와 목표 룩을 묘사하는 프롬프트를 넣으면 됩니다. 수천 프레임에 걸친 시간 일관성과 함께 720p로 출력됩니다.

ComfyUI의 Wan 2.1 VACE는 오픈소스 경로입니다. 14B VACE 모델은 참조 기반 V2V를 합니다. 소스 비디오와 스타일 참조 이미지를 입력하면 구조와 모션을 보존한 재스타일링 버전을 출력합니다. 엣지 맵 컨디셔닝이 구조 충실도를 높입니다. 일관된 스타일 참조로 어떤 길이든 청크 단위로 처리하는 루프를 만들 수 있습니다. 무료이며 자체 하드웨어에서 로컬로 돌아갑니다.

Grok Imagine V2V는 참조 모드에서 소스 비디오와 1~7장의 참조 이미지를 받습니다. 720p에서 1초당 $0.05. 참조 모드와 첫 프레임 모드의 명시적 분리 덕분에 참조가 소스 비디오의 구조를 덮어쓰지 않으면서 캐릭터 외관을 안내합니다.

당신의 3D 렌더에 필요한 것

렌더 품질의 하한선이 중요합니다. 맨 와이어프레임으로는 V2V 모델이 작업할 거리가 부족합니다. 하지만 프로덕션급 재질이나 조명이 필요한 것도 아닙니다.

올바른 비율과 기하. 참조 이미지가 제대로 매핑되려면 캐릭터 모델에 대략 올바른 신체 비율과 얼굴 구조가 필요합니다. 올바른 비율을 가진 기본 휴머노이드 기하면 충분합니다. 막대기 인간으로는 알아볼 수 있는 캐릭터가 나오지 않습니다.

기본적인 조명 방향. 장면의 전체 조명을 잡아주는 단일 방향광이 모델이 의도한 분위기를 이해하는 데 도움이 됩니다. AI가 디테일을 향상시키고 더하지만, 장면이 밝은 대낮인지 어두운 실내인지는 알아야 합니다.

부드러운 카메라 모션. 안정적이고 의도적인 카메라 움직임이 잘 변환됩니다. 불규칙하거나 극도로 빠른 움직임은 V2V 모델을 혼란스럽게 할 수 있습니다. 가상 카메라가 실제 카메라처럼 동작하게 하세요.

와이어프레임보다 플랫 셰이딩. 단순한 플랫 셰이딩이나 로우폴리 기하가 와이어프레임이나 텍스처 없는 모델보다 결과가 좋습니다. 표면에 기본 단색이라도 있으면 모델이 재질 경계를 이해하는 데 도움이 됩니다.

비용과 규모

10분짜리 컷신을 여러 도구로 처리할 때:

전체 길이 처리에 가장 저렴한 건 Lucy Restyle입니다. 요소 참조를 활용한 캐릭터별 향상에는 Kling이 가장 정밀합니다. Wan 2.1은 하드웨어가 있다면 무료입니다(720p 14B 모델은 약 60GB VRAM, 더 낮은 품질의 1.3B 변형은 8GB 필요).

비교표

앞으로의 방향

2026년의 궤적은 분명합니다. LongCat Video는 일관성을 갖춘 분 단위 생성이 오픈 모델에서 가능함을 증명했습니다. Helios는 그것이 실시간으로 일어날 수 있음을 보여줬습니다. Seaweed APT2는 인터랙티브 장편 생성을 시연했습니다. 그리고 진짜 참조 모델들(Kling, Grok, Seedance)은 캐릭터 정체성이 임의의 장면에 걸쳐 지속될 수 있음을 입증했습니다.

다음 단계는 이 역량들을 결합하는 것입니다. 진짜 캐릭터 참조 지원이 들어간 네이티브 장편 생성. 지금은 둘 중 하나를 골라야 합니다. 한 모델이 수십 번의 장면 전환에 걸쳐 참조 이미지의 캐릭터를 유지하면서 5분짜리 비디오를 생성할 수 있게 되면, 클립을 이어붙이는 워크플로는 한물갑니다. Seedance 2.5가 발표한 사양(네이티브 30초 클립, 최대 50개 참조 파일, 2026년 7월 16일 API 개방)이 그 방향의 첫 실질적 발걸음입니다.

2026년 7월 중순 기준, (오디오 포함) Artificial Analysis 텍스트-투-비디오 아레나는 Google의 Gemini Omni Flash(약 1,240 Elo)가 이끌고 있으며, Seedance 2.0, 알리바바의 API 전용 Wan 2.7, 그리고 HappyHorse 모델들이 뒤를 잇고, Kling 3.0 변형, SkyReels V4, Veo 3.1이 바짝 따라옵니다. 리더보드는 자주 재편되므로 어떤 단일 순위든 고정된 서열이 아니라 한 시점의 스냅숏으로 받아들이세요.

3D 스캐폴드 접근은 평행한 궤적을 제시합니다. V2V 모델이 구조 보존과 사실성을 개선하면서, 저충실도 3D 렌더를 향상시키는 것이 완전한 프로덕션에 점점 더 현실적이 됩니다. Meta의 RealMaster는 이미 게임 엔진 출력에 대해 연구급 시뮬레이션-투-현실 변환을 달성합니다. 이 역량이 참조 이미지 지원과 함께 프로덕션 API에 도달하면, 기본 3D 기술이 있는 누구든 카메라, 배치, 캐릭터 배치를 완전히 제어하며 어떤 길이로도 사실적인 장편 비디오를 만들 수 있게 됩니다.

지금으로서는, 실용적인 답은 당신의 용도에 따라 달라집니다.

다중 캐릭터 참조에 최적: Kling 3.0(요소 + 스타일 분리 시스템으로 최대 7개 참조) 또는 Seedance 2.0(최대 12개 멀티모달 입력, Seedance 2.5 API가 2026년 7월 16일 열리면 50개로 증가).

참조-투-비디오 API에 최적: Grok Imagine(깔끔한 API, 명시적 참조 모드, $0.05/초) 또는 fal.ai를 통한 Kling($0.084~0.112/초).

여러 클립에 걸친 지속적 캐릭터에 최적: Kling 3.0의 요소 참조 또는 SkyReels V3의 참조 후 확장. (Sora 2 Pro의 캐릭터 ID 시스템이 가장 깔끔했지만, 2026년에 단종되므로 새 작업을 시작하지 마세요.)

오픈소스에 최적: SkyReels V3(1~4장 진짜 참조 이미지, 무제한 길이) 또는 Helios(실시간, Apache 2.0).

순수 길이에 최적: LongCat Video(약 15분, 단 첫 프레임 전용).

3D 렌더 향상에 최적: Kling 3.0 V2V(캐릭터별 요소 참조, 1080p) 또는 Lucy Restyle 2(30분 입력, $0.01/초).

자주 묻는 질문

긴 비디오에 가장 좋은 AI 비디오 모델은?

순수 길이로는 LongCat Video가 네이티브로 약 15분을 생성하지만 첫 프레임 전용입니다. 일관된 캐릭터가 있는 긴 비디오라면, 2026년의 실용적인 답은 참조 후 확장 워크플로입니다. 참조 지원이 강력한 모델(Kling 3.0, Runway Gen-4.5, 오픈소스 SkyReels V3)로 클립을 생성한 뒤 이어붙이는 거죠. 길게도 돌아가면서 캐릭터 정체성도 완벽하게 유지하는 단일 모델은 없으므로, 대부분의 프로덕션 작업은 이들을 결합합니다.

어떤 AI 비디오 모델이 참조 이미지를 지원하나요?

상업용 옵션 중에서는 Kling 3.0 Omni, Runway Gen-4.5, Seedance 2.0, Google Veo 3.1, Gemini Omni Flash가 모두 참조 이미지를 지원합니다. 오픈소스 쪽에서는 SkyReels V2/V3, Wan 2.1, LTX-2가 직접 돌릴 수 있는 참조 입력을 받습니다. 지원 품질은 편차가 크며, 그래서 위 가이드에서 단계별로 나눈 것입니다.

AI가 긴 비디오 전반에 걸쳐 일관된 캐릭터를 생성할 수 있나요?

가능하지만 한 번에는 아닙니다. 믿을 만한 방법은 하나 이상의 참조 이미지로 캐릭터를 고정하고, 짧은 클립을 생성한 뒤, 같은 참조를 다시 넣어가며 확장하거나 이어붙이는 것입니다. 여기서는 진짜 참조 지원(모델이 새 생성에 걸쳐 정체성을 유지)이 오프닝 프레임만 시드하는 첫 프레임 컨디셔닝보다 훨씬 중요합니다.

첫 프레임 지원과 진짜 참조 이미지 지원의 차이는 무엇인가요?

첫 프레임 컨디셔닝은 당신의 이미지를 클립의 말 그대로 오프닝 프레임으로 사용하며, 비디오가 진행되면서 드리프트합니다. 진짜 참조 지원은 이미지를 모델이 생성 내내 따르는 정체성 앵커로 다뤄, 캐릭터나 스타일이 클립 전체와 별개의 클립들에 걸쳐 일관되게 유지됩니다. 위 섹션이 어떤 모델이 어느 쪽인지 정리해 줍니다.

더 읽을거리

• 프런티어 오픈소스 생성 AI 모델 — 비디오, 이미지, 3D, 오디오 등을 위한 오픈소스 생성 AI 실용 가이드
• 비디오 생성기 — Kling 3.0 Pro로 구동되는 우리의 비디오 생성 도구
• 스케치에서 애니메이션 3D 캐릭터로 가는 법 — 캐릭터 애니메이션을 위한 이미지 및 비디오 생성 활용

Perlin 노이즈를 입힌 하이트맵은 절차적 지형의 기본 출발점입니다. fBm을 몇 옥타브 쌓고 컬러 그라디언트를 적용하면 지형처럼 보이는 무언가가 나옵니다. 거의 모든 튜토리얼이 여기서 끝납니다. 하지만 진짜 풍경은 쌓아 올린 노이즈처럼 보이지 않습니다. 진짜 풍경에는 물이 깎아낸 강 계곡, 응력 균열이 빚어낸 절벽면, 수백만 년의 침식이 만든 동굴과 아치가 있습니다. 또한 지오메트리를 빚어낸 바로 그 물리 과정에서 함께 나오는 상관된 텍스처(평지의 풀, 가파른 경사의 바위, 수목한계선 위의 눈)도 있습니다.

이 가이드는 노이즈 다음에 오는 것을 다룹니다. 물리에 기반한 생성 방법, 동굴과 오버행을 다루는 볼류메트릭 표현, 디퓨전 기반 뉴럴 지형 합성, 그리고 이 모든 것을 브라우저 탭에서 60fps로 렌더링하는 데 필요한 GPU 구동 LOD와 스트리밍 파이프라인입니다.

여기 나오는 모든 내용은 우리의 구체적인 제약을 겨냥합니다. WebGL 2 / WebGPU에서 동작하고, 네트워크로 스트리밍되며, 크리에이터가 편집할 수 있는 멀티플레이어 오픈 월드입니다.

하이트맵으로 충분하지 않은 이유

하이트맵은 격자점마다 높이 값 하나를 저장합니다. 2D 함수입니다. (x, z)가 주어지면 y를 돌려줍니다. 이 표현은 작고, GPU 친화적이며, 렌더링이 빠릅니다. 하지만 크리에이터 월드에 중요한 근본적 한계가 있습니다.

동굴이나 오버행이 없습니다. 하이트맵은 한 점이 서로 다른 두 높이를 갖는 지형을 표현할 수 없습니다. 동굴, 아치, 절벽 오버행, 터널, 떠 있는 섬은 모두 불가능합니다. Minecraft, No Man's Sky, Deep Rock Galactic이 모두 이 때문에 볼류메트릭 지형을 필요로 합니다.

수직 피처가 없습니다. 하이트맵에서 수직 절벽면은 거의 무한대에 가까운 경사라서 극단적인 텍스처 늘어짐과 충돌 아티팩트를 만듭니다. 진짜 절벽에는 하이트맵이 표현할 수 없는 수평 피처(턱, 틈새)가 있습니다.

노이즈는 노이즈처럼 보입니다. fBm을 8옥타브 쓰고 도메인 워핑을 더해도 지형에는 인공적인 느낌이 남습니다. 진짜 지질의 방향성 구조, 즉 능선, 배수망, 퇴적층, 구조 습곡이 빠져 있습니다. 이런 패턴은 물리 과정에서 나오는 것이지 노이즈 함수에서 나오는 것이 아닙니다.

크리에이터 편집이 제한됩니다. 크리에이터가 높이만 수정할 수 있다면 터널을 파거나, 동굴을 만들거나, 지하 공간을 지을 수 없습니다. 크리에이터가 진짜로 빚을 수 있는 월드라면 지형 표현이 더하기뿐 아니라 빼기도 지원해야 합니다.

해결책은 하이트맵을 완전히 버리는 것이 아닙니다. 단순한 표면인 90%의 지형에는 하이트맵이 여전히 최선의 표현입니다. 해결책은 하이브리드 방식입니다. 하이트맵 기반 지형에, 복잡한 지오메트리가 필요한 곳에는 볼류메트릭 오버레이를 얹고, 사실적인 지형을 위해 물리적으로 정확한 생성을 쓰고, 노이즈로는 얻을 수 없는 다양성을 위해 뉴럴 합성을 더합니다.

빠른 답: 우리가 실제로 만들 것

깊이 들어가기 전에 의사결정 프레임워크를 먼저 제시합니다. 글의 나머지는 각 부분을 설명합니다.

지형 표현

하이브리드 하이트맵 + SDF 시스템을 씁니다. 하이트맵은 월드 전체를 덮습니다(싸고, 작고, 검증됨). SDF 볼륨은 동굴, 오버행, 또는 크리에이터가 깎아낸 피처가 필요한 곳에만 존재합니다(아마 청크의 5-10%). 이렇게 하면 월드의 90%는 하이트맵 비용으로 유지하면서, 필요한 곳에서는 임의의 지오메트리를 지원합니다.

생성 파이프라인

서버 측에서 연쇄 프로세스로 실행합니다.

1. Terrain Diffusion(또는 텍스트 프롬프트용 MESA)이 시드로부터 기반 하이트맵을 생성합니다. 노이즈를 실제 고도 데이터로 학습한 지질적으로 사실적인 지형으로 대체합니다.
2. 해석적 침식(stream power law)이 강 네트워크와 능선으로 하이트맵을 밀리초 단위로 다듬습니다.
3. TerraFusion 또는 Geodiffussr가 하이트맵으로부터 상관된 텍스처를 생성합니다(또는 WebGL 2 폴백에서는 절차적 경사/고도 규칙 사용).
4. 생태계 시뮬레이션이 식생 밀도 맵을 만듭니다.
5. Arenite 스타일 침식이 지형이 요구하는 곳에 절벽면, 아치, 동굴을 위한 SDF 볼륨을 생성합니다.
6. 청크로 나누고, 압축하고, CDN에 업로드합니다. 평균 청크: 2-8 KB. 볼류메트릭 데이터가 있는 복잡한 청크: 20-100 KB.

크리에이터는 파라미터를 조정하거나("더 습하게", "더 산악으로", "동굴 추가"), 의도를 스케치하거나, 브러시와 SDF 도구로 직접 조각하며 이 파이프라인과 상호작용합니다.

LOD 전략

두 경로 모두 팝 없는 전환을 위해 버텍스 셰이더에서 geomorphing을 씁니다. 둘 다 멀리 있는 식생에는 빌보드 임포스터를 씁니다. WebGPU 경로가 더 빠르지만(지형 예산 3.5ms) WebGL 2 경로도 쓸 만합니다(6.5ms).

스트리밍

점진적 로딩: 지형 지오메트리 먼저(<100ms), 텍스처 다음(<300ms), 식생 셋째(<1s), 볼류메트릭 데이터 넷째(<3s). 플레이어 속도를 기준으로 미리 가져옵니다. 메모리 예산: 지형 전체 256 MB.

편집

표면 조각을 위한 하이트맵 브러시(올리기, 내리기, 부드럽게, 침식). 볼류메트릭 편집을 위한 SDF 프리미티브(동굴 깎기, 아치 추가). 둘 다 로컬에서는 즉시 반영되고, 100-300ms 안에 서버로 동기화되며, 델타 업데이트로 다른 플레이어에게 전파됩니다.

무엇을 어떤 순서로 만들까

1-2개월차: geometry clipmap이 적용된 하이트맵 지형. WebGL 2만. CDN에서 스트리밍. 절차적 경사/고도 머티리얼. 이렇게 하면 모든 브라우저에서 지형이 화면에 나옵니다. 생성에는 노이즈 + 해석적 침식을 씁니다(Terrain Diffusion은 나중에 해도 됨).

3-4개월차: 식생과 대기. 밀도 맵에서 나오는 GPU 인스턴스 풀과 나무. 낮/밤 사이클이 있는 절차적 하늘. 대기 안개. 캐스케이드 섀도 맵. 월드가 하나의 장소처럼 느껴지기 시작합니다.

5-6개월차: 크리에이터 편집. 하이트맵 브러시 도구. 멀티플레이어 지형 편집을 위한 델타 기반 동기화. 동시 편집을 위한 공간 잠금. 이때 크리에이터가 월드를 빚기 시작합니다.

7-9개월차: 볼류메트릭 지형과 WebGPU 경로. 동굴과 오버행을 위한 SDF 오버레이. WebGPU compute의 marching cubes. LOD 경계를 위한 Transvoxel. SDF 조각 도구. 이것으로 완전한 창작 도구 모음이 열립니다.

10-12개월차: 뉴럴 생성과 다듬기. 기반 하이트맵을 위한 Terrain Diffusion 또는 MESA. 텍스처를 위한 TerraFusion/Geodiffussr. 마이크로 디테일을 위한 phasor noise. 반복 방지를 위한 hex-tiling. 가상 텍스처링. 라플라시안 블렌딩. 지형이 프로덕션 품질에 도달합니다.

이 순서대로면 2개월 후에는 플레이 가능한 것이, 4개월 후에는 아름다운 것이, 6개월 후에는 편집 가능한 것이, 12개월 후에는 최신 수준의 것이 존재하게 됩니다.

글의 나머지는 각 결정 뒤에 있는 리서치입니다.

하이트맵을 넘어선 지형 표현

부호 있는 거리장(SDF)

부호 있는 거리장은 3D 공간의 모든 점에서 가장 가까운 표면까지의 거리를 저장합니다. 양수는 바깥, 음수는 안쪽이며, 영교차점이 곧 표면 자체입니다. SDF는 동굴, 아치, 떠 있는 지오메트리를 포함한 임의의 3D 형상을 표현합니다.

SDF를 메시로 렌더링하려면 marching cubes(또는 그 변형)를 실행해 영교차점을 삼각형으로 추출합니다. 메시 해상도는 격자 해상도에 따라 달라집니다. 256x256x256 SDF 격자는 1미터 해상도에서 대략 청크 하나 분량의 지형을 만듭니다.

브라우저 구현: WebGPU marching cubes는 compute 셰이더를 통해 전적으로 GPU에서 돌아갑니다. Will Usher의 webgpu-marching-cubes 구현은 브라우저에서 256^3 격자를 실시간으로 처리하며 네이티브 속도를 냅니다. 알고리즘은 당황스러울 만큼 병렬적이라(각 셀이 독립적으로 처리됨) GPU compute에 이상적입니다.

@compute @workgroup_size(4, 4, 4)
fn marchingCubes(@builtin(global_invocation_id) id: vec3<u32>) {
    let sdfValues = sampleSDF(id);
    let caseIndex = classifyCell(sdfValues);
    if (caseIndex == 0u || caseIndex == 255u) { return; }
    let triangles = lookupTriangulation(caseIndex);
    let vertices = interpolateEdges(sdfValues, triangles);
    appendToMeshBuffer(vertices);
}

저장 비용: 8비트 양자화 정밀도의 256^3 SDF는 압축하지 않으면 16 MB입니다. 하지만 볼륨 대부분은 비어 있습니다(표면에서 멀리 떨어져 있음). 런렝스 인코딩이나 희소 옥트리 저장을 쓰면 보통 청크당 100-500 KB로 줄어드는데, 이는 하이트맵 지형과 비슷합니다.

편집: SDF 지형은 본질적으로 편집 가능합니다. 머티리얼을 더하는 것은 거리장에 대한 min() 연산입니다. 머티리얼을 제거하는 것(파기)은 부호를 뒤집은 형상에 대한 max()입니다. 형상 사이의 부드러운 블렌딩은 smoothMin()을 씁니다. 이 연산들은 compute 셰이더에서 인터랙티브한 속도로 돌아갑니다.

Dual Contouring

Marching cubes는 정점을 격자 모서리에 놓아 부드러운 표면을 만들지만 날카로운 피처(절벽 모서리, 바위 모서리)를 잃습니다. Dual contouring은 셀마다 그 셀 안의 표면을 가장 잘 대표하는 위치에 정점 하나를 놓아 날카로운 모서리와 코너를 보존합니다.

이 알고리즘은 각 격자점에서 거리장 값과 표면 법선(SDF의 그래디언트)을 모두 필요로 합니다. 셀마다 작은 최소제곱 문제를 풀어 최적 정점 위치를 찾습니다. 결과는 부드러운 지형과 날카로운 암석 피처를 모두 담아내는 메시입니다.

Neural Dual Contouring(Chen et al., 2022, arXiv:2202.01999)은 최소제곱 솔버를 최적 정점 위치와 모서리 교차점을 예측하는 신경망으로 대체합니다. 특히 복잡한 자연 암석 형성에서 더 나은 표면 재구성 정확도와 피처 보존을 달성합니다.

Transvoxel 알고리즘

볼류메트릭 지형에서 가장 어려운 문제는 메시 생성이 아닙니다. LOD 전환입니다. 고해상도 청크가 저해상도 청크 옆에 놓이면 경계에서 메시가 맞지 않아 눈에 보이는 균열이 생깁니다.

Eric Lengyel이 설계한 Transvoxel 알고리즘(transvoxel.org)은 해상도 간 경계에 특수 전환 셀을 끼워 넣어 이를 해결합니다. 이 셀들은 양쪽을 정확히 맞추는 추가 삼각형으로 해상도 차이를 잇습니다. 알고리즘은 복잡한 경계 문제를 73개의 등가 클래스로 줄입니다(무차별 대입 방식의 약 120만 가지와 대조됨).

Transvoxel은 복셀 데이터가 동적으로 바뀌는(크리에이터 편집, 침식, 채굴) 실시간 응용을 위해 특별히 설계되었습니다. 특허가 없고 출시된 게임(Space Engineers, Astroneer)에서 쓰였습니다. 편집 가능한 볼류메트릭 지형이 있는 브라우저 월드에서 Transvoxel이 곧 LOD 해법입니다.

하이브리드: 하이트맵 기반 + 볼류메트릭 오버레이

브라우저 오픈 월드를 위한 실용적인 방식은 레이어로 나눈 시스템입니다.

레이어 1: 하이트맵 지형이 월드 전체를 덮습니다. 완만한 언덕, 계곡, 산을 위한 싸고 작은 표현입니다. 청크당 작은 하이트맵 패치로 스트리밍됩니다(각각 2-4 KB). 렌더링은 GPU 비용이 일정한 geometry clipmap을 씁니다.

레이어 2: 볼류메트릭 오버레이는 복잡한 지오메트리가 필요한 청크에만 존재합니다. 동굴, 절벽면, 아치, 크리에이터가 깎은 터널, 지하 공간이 희소 SDF 볼륨으로 저장됩니다. 볼류메트릭 데이터가 있는 청크만 SDF 저장과 marching cubes 비용을 치릅니다.

레이어 3: 크리에이터 수정은 기반 레이어 위의 SDF 편집으로 저장됩니다. 터널을 파는 크리에이터는 그 터널의 SDF 형상을 저장합니다. 렌더링 시스템은 하이트맵 표면을 볼류메트릭 빼기/더하기와 합쳐 최종 메시를 만듭니다.

이 하이브리드는 평지에는 거의 비용이 들지 않고(하이트맵만), 복잡함이 존재하는 곳에서만 확장됩니다. 전형적인 월드에서는 아마 청크의 5-10%만 볼류메트릭 데이터가 필요합니다.

물리적으로 정확한 지형 생성

노이즈는 무작위 지형을 만듭니다. 물리는 사실적인 지형을 만듭니다. 차이는 눈에 보입니다. 노이즈 지형은 구조가 없지만(어디나 무작위로 울퉁불퉁함), 물리 지형에는 침식과 지각 운동에서 나오는 강 네트워크, 능선, 충적 선상지, 절벽 띠가 있습니다.

수력 침식: 기초

물은 경사를 따라 흐르고, 퇴적물을 들어 올리고, 느려지면 그것을 내려놓습니다. 수백만 가상 년에 걸쳐 시뮬레이션되는 이 단일 과정이 특징 없는 노이즈를 알아볼 수 있는 지질 피처가 있는 지형으로 바꿉니다.

입자 기반 방식은 하이트맵에 시뮬레이션된 빗방울을 떨어뜨립니다. 각 방울은 경사를 따라 흐르며(그래디언트를 따라), 속도와 경사에 따라 물질을 침식하고, 퇴적물을 용해 부하로 운반하며, 속도가 줄거나 용량을 초과하면 퇴적물을 내려놓습니다. 20만-50만 개의 입자가 지난 뒤 지형은 다음을 발달시킵니다.

• 최대 수류 경로를 따르는 강 계곡
• 배수 분지를 나누는 능선
• 가파른 계곡이 평원으로 열리는 곳의 충적 선상지
• 산악 지형의 V자 계곡, 빙하 지형의 U자 계곡

GPU 구현: 입자 시뮬레이션은 병렬화할 수 있습니다. 각 입자는 독립적입니다(근사가 입자 간 상호작용을 무시하는데, 침식에는 문제없음). WebGPU compute 셰이더는 60fps에서 프레임당 1만 개의 입자를 처리해, 실제 시간으로 약 3초 만에 20만 개를 완료합니다.

Sebastian Lague의 오픈소스 구현(GitHub)이 표준 출발점입니다. C#에서 단일 스레드로 돌아가며 1024x1024 하이트맵을 몇 초 만에 처리합니다. GPU 버전은 50-100배 빠릅니다.

열 침식

물만이 침식력은 아닙니다. 온도 변화는 암석을 갈라지고 부서지게 합니다(열 풍화). 두 지형 점 사이의 경사가 물질의 안식각을 넘으면 물질이 높은 점에서 낮은 점으로 떨어집니다. 이것은 다음을 만듭니다.

• 절벽 밑의 테일러스 사면(떨어진 바위 더미)
• 시간이 지나며 부드러워진 능선
• 물질에 따른 단면(단단한 암석은 가파른 경사를 유지하고, 무른 흙은 완만한 각도로 무너짐)

열 침식은 수력 침식보다 단순합니다. 국소 연산입니다. 각 셀마다 이웃과의 높이 차이를 비교합니다. 경사가 임계값을 넘으면 물질을 경사 아래로 옮깁니다. 반복마다 단일 compute 셰이더 패스로 돌아가며 50-100회 반복 만에 수렴합니다.

수력과 열 침식을 합치면 어느 한쪽만 쓸 때보다 훨씬 자연스러워 보이는 지형이 나옵니다. 물은 계곡을 깎고, 열 침식은 그 사이의 능선을 부드럽게 하며 계곡 바닥을 잔해로 채웁니다.

Stream Power Law: 해석적 침식

최근 연구는 입자 기반 시뮬레이션의 대안을 제시합니다. stream power law(침식률을 배수 면적과 경사에 연결하는 지형학 방정식)는 반복적으로 시뮬레이션하는 대신 해석적으로 풀 수 있습니다.

Cordonnier et al. (2024, HAL)은 해석적 stream power law를 산사태 및 사면 확산 과정과 결합합니다. 그 결과는 물리에 기반하면서도 시간 시뮬레이션이 아니라 수학 함수로 돌아가는 지형 생성입니다. 노이즈 기반 하이트맵과 파라미터(강수율, 암석 경도, 지각 융기율)를 입력하면 밀리초 단위로 침식된 지형을 얻습니다.

이 해석적 방식은 브라우저 월드에 이상적입니다. 반복적으로가 아니라 지형 생성 중 서버 측에서 한 번 돌기 때문입니다. 파라미터는 크리에이터가 조정할 수 있습니다("이 지역을 더 산악으로"는 융기율을 올리고, "더 습하게"는 강수를 늘려 계곡을 깊게 합니다).

Arenite: 다중 물리 침식 (SIGGRAPH 2025)

Arenite(프로젝트 페이지)는 단순한 초기 조건으로부터 아치, 알코브, 후두, 뷰트를 생성하는 물리 기반 사암 시뮬레이터입니다. 사용자가 침식성 맵(무른 암석 대 단단한 암석 층)과 식생을 칠하면, 시스템이 다음을 시뮬레이션합니다.

• 암석 기둥을 통한 응력 분포
• 노출된 무른 물질을 우선 제거하는 풍식
• 수류로 인한 하천 침식
• 새 형성을 만드는 입자 퇴적

GPU 구현은 데스크톱 GPU에서 복잡한 형성을 5분 이내에 처리합니다. 실시간 브라우저 사용에는 너무 느리지만 서버 측 생성에는 충분히 빠릅니다. 크리에이터가 무른/단단한 암석 층이 있는 절벽면을 정의하면 몇 분 안에 사실적인 아치 형성을 얻을 수 있습니다.

출력은 3D 복셀 필드이며, 이는 우리의 SDF/marching cubes 파이프라인에 바로 들어맞습니다.

표현을 넘나드는 유연한 침식

IRIT-STORM의 2024년 논문("Flexible Terrain Erosion," Springer)은 실용적인 문제를 해결합니다. 대부분의 침식 방법은 하이트필드에서만 동작합니다. 지형이 복셀, SDF, 또는 층상 머티리얼을 쓴다면 각각에 별도의 침식 코드가 필요합니다.

유연한 침식 방법은 침식을 두 개의 독립적인 과정으로 분해합니다. 지형 변경(표면에서 물질 제거)과 물질 운반(기본 물리에 따라 움직이는 입자로 퇴적물 이동)입니다. 각 입자는 크기, 밀도, 반발 계수, 퇴적 용량을 설정할 수 있습니다. 선택적 벡터 필드가 사실적인 유체 역학을 위해 입자 운동을 제어합니다.

입자가 통합된 물질 변경 인터페이스를 통해 지형과 상호작용하기 때문에, 같은 시뮬레이션이 하이트필드, 복셀 격자, 음함수 표면, 층상 머티리얼 스택에서 모두 동작합니다. 우리의 하이브리드 지형(하이트맵 기반 + SDF 오버레이)에서는 침식 시스템 하나가 두 표현을 모두 처리한다는 뜻입니다. 입자 시뮬레이션은 GPU에서 병렬로 돌아갑니다.

강 네트워크와 배수 분지

침식은 강을 깎지만, 설득력 있는 강 네트워크를 생성하려면 물을 경사 아래로 흘리는 것 이상이 필요합니다. 두 가지 접근이 더 나은 결과를 냅니다.

배수 우선 생성(Amit Patel, Red Blob Games, 프로젝트)은 고도를 배정하기 전에 강 네트워크를 구축합니다. 그래프(보로노이 또는 삼각형 메시)로 시작합니다. 모서리를 능선(흐름 없음), 입구(물이 흘러 들어옴), 출구(물이 흘러 나감)로 분류합니다. 이렇게 하면 작은 지류가 큰 수로로 모이는 사실적인 배수 위계가 만들어지며, 서로 다른 강 유형에 대한 Rosgen 분류 체계(평지의 망상 하도, 산악의 좁은 협곡)를 따릅니다.

흐름 누적은 각 지형 셀을 얼마나 많은 물이 지나가는지 추적합니다. 시뮬레이션된 비를 고르게 떨어뜨리고, 경사 아래로 흘리고, 셀당 방문 횟수를 셉니다. 누적이 높은 셀은 강 하도입니다. 누적이 중간인 셀은 계절성 개울입니다. 누적 맵은 침식 강도(물이 많을수록 침식이 많음)와 식생 분포(강둑이 더 습해 다른 식물 종을 지지함)도 좌우합니다.

크리에이터 월드에서는 강 네트워크가 지형 생성 중 서버 측에서 생성되어 청크당 2D 흐름 방향 맵과 물 누적 맵으로 저장됩니다. 브라우저 클라이언트는 이 맵들을 써서 물 표면(강 하도에서 올바른 높이의 평평한 평면)을 렌더링하고 식생 분포(물가가 더 무성함)를 좌우합니다.

해안과 해안선 생성

해안선은 지형이 물과 만나는 곳이며, 표준 침식이 만들지 못하는 특징적인 피처가 있습니다. 해식애, 해변 퇴적물, 갯벌, 시 스택, 파식대입니다.

NEWTS1.0 (2024, MIT)은 두 가지 침식 메커니즘으로 암석 해안선의 진화를 모델링합니다. 균일 후퇴(일정한 침식률)와 파도 구동 침식(취송 거리와 입사 파각의 함수로서의 침식률)입니다. 모델은 수천 시뮬레이션 년에 걸쳐 돌아가며 실제 해안 지형과 일치하는 곶, 만, 시 스택, 아치를 만듭니다.

브라우저 월드에서는 해안 피처가 월드 생성 중 미리 생성됩니다. 파라미터(우세 파향, 해안을 따른 암석 경도 변화)로 크리에이터가 자기 해안선의 성격을 제어합니다. "노르웨이 피오르드" 설정은 가파른 입구를 만듭니다. "열대 환초" 설정은 석호가 있는 낮은 모래 해안을 만듭니다.

동굴과 지하 생성

동굴은 완전한 볼류메트릭 지형(SDF 또는 복셀)을 필요로 합니다. 하이트맵은 폐쇄 공간을 표현할 수 없기 때문입니다. 생성 방식은 다음과 같습니다.

3D 노이즈 임계화가 가장 단순한 방법입니다. 복셀마다 3D Perlin 또는 심플렉스 노이즈를 샘플링합니다. 임계값 아래는 고체, 위는 빈 공간입니다. 임계값과 노이즈 파라미터를 조정해 터널 직경, 연결성, 챔버 크기를 제어합니다. 이것은 Minecraft를 연상시키는 유기적이고 벌레 굴 같은 동굴 시스템을 만듭니다.

PLUME (Procedural Layer Underground Modeling Engine) (2024, arXiv:2508.20926)은 층상 절차적 규칙을 써서 사실적인 동굴과 용암 동굴 환경을 생성합니다. 원래 우주 탐사 연구를 위해(화성 용암 동굴 시뮬레이션) 만들어졌으며, 종유석, 기둥, 챔버 시스템이 있는 지질적으로 그럴듯한 지하 구조를 만듭니다.

메타볼 조각이 적용된 L-system 터널은 L-system 문법으로 지형을 통과하는 분기 터널 경로를 키운 뒤, 메타볼 음함수 표면으로 실제 터널 지오메트리를 깎습니다. 메타볼은 부드럽고 둥근 동굴 벽을 만듭니다. 서로 다른 파라미터로 여러 패스를 돌리면 주 통로, 측면 챔버, 좁은 연결 터널이 생깁니다.

크리에이터 월드에서는 동굴 생성이 SDF 오버레이 시스템에 연결됩니다. 기반 지형은 하이트맵입니다(동굴 없음). 청크에 동굴이 필요할 때(절차적 생성이든 크리에이터 설계든) 기반 지형에서 동굴 지오메트리를 빼는 SDF 볼륨이 생성됩니다. marching cubes 파이프라인이 합쳐진 표면을 렌더링합니다.

물리 과정으로서의 식생

게임의 식생은 보통 "2000m 아래는 풀, 1500m 아래는 나무, 3000m 위는 눈" 같은 규칙으로 절차적으로 배치됩니다. 이건 빠르지만 균일하고 비현실적인 분포를 만듭니다.

물리에 기반한 식생 시뮬레이션은 각 식물을 자원(빛, 물, 토양 양분)을 두고 경쟁하는 것으로 모델링합니다. 시뮬레이션은 이렇습니다.

1. 씨앗이 지형 전체에 뿌려집니다
2. 각 식물은 가용 자원에 따라 자랍니다(물은 수력 침식 시뮬레이션에서 흐르고, 햇빛은 경사와 향에 달려 있으며, 토심은 침식 이력에 달려 있음)
3. 식물이 경쟁합니다. 나무가 풀을 그늘로 덮고, 빽빽한 수관이 새 묘목을 막습니다
4. 시뮬레이션 시간이 지나며 생물군계가 자연스럽게 나타납니다. 물이 있는 계곡에는 숲, 바람 부는 능선에는 성긴 식생, 물이 고이는 곳에는 습지

Deussen et al.의 생태계 시뮬레이션(논문)은 실세계 생태 패턴과 일치하는 숲 분포를 생성합니다. 시뮬레이션은 2D 격자에서 돌아가며(지형 청크당 셀 하나) 렌더링 시스템이 GPU 인스턴스 식생 배치에 쓰는 밀도 맵과 종 배정을 만듭니다.

브라우저 월드에서는 식생 시뮬레이션이 월드 생성 중 한 번(서버 측) 돌아갑니다. 출력은 청크당 밀도 맵 세트입니다. 나무 밀도, 풀 밀도, 꽃 밀도, 바위 잔해 밀도. 브라우저 클라이언트는 이 맵들을 GPU 인스턴싱과 함께 써서 런타임에 식생을 뿌립니다.

디퓨전 기반 지형 합성

이 분야는 여기서 가장 빠르게 움직이고 있습니다. 디퓨전 모델(이미지용 Stable Diffusion 뒤에 있는 바로 그 기술)이 지형 생성에 적용되고 있으며, 결과는 노이즈 기반 방법보다 상당히 더 사실적입니다.

Terrain Diffusion: Perlin 노이즈의 후계자

Terrain Diffusion (Goslin, 2025, arXiv:2512.08309, 프로젝트 페이지)은 1985년 Perlin 노이즈 이래 절차적 지형 생성에서 가장 의미 있는 진전입니다. 이 연구는 이후 SIGGRAPH 2026에 채택되었고, 정식 arXiv 제목은 이제 "InfiniteDiffusion: Bridging Learned Fidelity and Procedural Utility for Open-World Terrain Generation"입니다. InfiniteDiffusion 알고리즘과 Terrain Diffusion 프레임워크는 같은 논문의 두 절반입니다.

핵심 혁신은 InfiniteDiffusion으로, 디퓨전 샘플링을 무한 도메인에 맞게 재정식화한 알고리즘입니다. 전통적인 디퓨전 모델은 고정 크기 출력(예: 512x512 하이트맵)을 생성합니다. InfiniteDiffusion은 다음을 갖춘 무한 범위의 지형을 생성합니다.

• 시드 일관성: 같은 시드는 항상 같은 지형을 만듭니다. Perlin 노이즈처럼요.
• 상수 시간 랜덤 액세스: 이웃 영역을 먼저 생성하지 않고도 임의의 점에서 높이를 질의할 수 있습니다.
• 경계 아티팩트 없음: 눈에 보이는 이음매나 반복 없는 무한 생성.

이 시스템은 디퓨전 모델의 위계적 스택을 씁니다. 최상위 레벨은 행성 규모 피처(대륙, 산맥)를 잡아냅니다. 이후 각 레벨은 더 미세한 디테일(개별 봉우리, 계곡, 소규모 거칠기)을 더합니다. 작은 라플라시안 인코딩이 해수면에서 히말라야 봉우리에 이르는 거대한 동적 범위에 걸쳐 출력을 안정화합니다.

성능: 생성이 실시간 탐험과 보조를 맞춥니다. 논문은 궤도 속도(약 7,700 m/s)라는 이론적 극단에서도 지형 합성이 소비자용 GPU에서 이동보다 9배 빠르게 돌아간다고 보고합니다. 프로젝트에는 실시간 지형 합성을 시연하는 Minecraft 통합이 포함됩니다.

이것이 우리에게 중요한 이유: Terrain Diffusion은 실세계 고도 데이터(지구의 실제 지형)로 학습한 풍경을 만듭니다. 출력에는 손으로 조정한 노이즈 파라미터가 아니라 학습 데이터에서 나오는 강 네트워크, 산맥, 해안 피처, 고원 구조가 있습니다. 크리에이터가 "스코틀랜드 고지대 같은 지형을 생성해"라고 말하면 디퓨전 모델이 올바른 지질 성격을 가진 무언가를 만들어 냅니다.

모델은 월드 생성 중 서버 측에서 돌아갑니다. 출력은 다른 지형 데이터처럼 브라우저로 스트리밍되는 표준 하이트맵입니다. 생성 방법은 클라이언트에게 보이지 않습니다.

TerraFusion: 지오메트리와 텍스처 동시 생성

TerraFusion (2025, arXiv:2505.04050)은 하이트맵과 지형 텍스처를 동시에 생성하며 한 걸음 더 나아갑니다. 핵심 통찰은 지형 지오메트리와 표면 외형이 상관되어 있다는 것입니다(강바닥은 모래, 절벽면은 바위, 평지는 풀). 따로 생성하면 불일치가 생깁니다.

TerraFusion은 하이트맵과 텍스처용 별도 VAE를 가진 잠재 디퓨전 모델을 써서 그것들의 결합 분포를 모델링하도록 학습됩니다. 시스템은 다음을 지원합니다.

• 무조건 생성: 일치하는 텍스처가 있는 무작위의 그럴듯한 지형
• 스케치 조건 생성: 크리에이터가 대략적인 맵(여기 계곡, 저기 능선, 이 가장자리를 따라 절벽)을 그리면 모델이 스케치에 맞는 상세한 지오메트리와 텍스처를 생성

크리에이터 월드에서 이건 강력합니다. 크리에이터가 자기 부지의 전반적 배치를 스케치하면 시스템이 적절한 표면 머티리얼이 있는 지질적으로 그럴듯한 지형을 채워 넣습니다. 하이트맵 페인팅도, 텍스처 스플래팅도, 수동 머티리얼 배정도 없습니다.

MESA: 텍스트에서 지형으로

MESA (2025, arXiv:2504.07210, CVPR 2025 Workshop)는 텍스트 설명으로부터 지형을 생성합니다. Copernicus 프로그램의 글로벌 원격탐사 데이터로 학습되어 모든 유형의 육상 풍경에 노출되어 있습니다.

"가파른 화강암 벽을 가진 피오르드가 바위투성이 해안으로 열린다" 같은 프롬프트는 적절한 지질 구조를 가진 하이트맵을 만듭니다. "완만한 언덕과 넓은 강 계곡이 있는 굽이치는 농지"는 완전히 다른 것을 만듭니다.

MESA는 위성 이미지를 전 세계 디지털 고도 모델과 짝짓는 Major TOM Core-DEM 확장 데이터셋을 도입합니다. 이 학습 데이터는 모델에게 실제 지형이 모든 규모와 모든 기후대에서 어떻게 보이는지에 대한 이해를 줍니다.

Geodiffussr: 텍스트로 안내하는 지형 텍스처링

Geodiffussr (2025, arXiv:2511.23029)는 기존 하이트맵을 받아 고도 데이터를 존중하면서 텍스트 설명으로 안내하는 텍스처를 생성합니다. "가을 숲"은 중간 경사에 주황과 금빛 단풍을, 가파른 면에는 맨바위를 만듭니다. "열대 해안"은 낮은 지대에 야자 식생을, 해수면에는 산호 모래를 만듭니다.

이 시스템은 다중 스케일 콘텐츠 집계를 써서 텍스처 배정이 고도를 존중하도록 합니다. 눈은 물리적으로 그럴듯한 고도 이상에서만 나타나고, 물 피처는 움푹한 곳에 앉으며, 식생은 고도에 따라 성겨집니다.

크리에이터 월드에서는 지오메트리를 바꾸지 않고도 텍스트 프롬프트로 지형 텍스처를 다시 생성할 수 있다는 뜻입니다. 크리에이터가 원하는 지형을 조각한 뒤 분위기를 설명하면("어두운 화산 황무지" 또는 "무성한 온대림") 시스템이 적절한 표면 머티리얼을 생성합니다.

브라우저 지형을 위한 동적 LOD

큰 지형을 어디서나 풀 해상도로 렌더링하는 것은 브라우저에서 불가능합니다. 4 km x 4 km 월드를 1미터 해상도로 하면 지형만 1600만 정점입니다. 동적 LOD는 이것을 월드 크기와 무관하게 일정하고 다룰 만한 정점 수로 줄입니다.

Geometry Clipmaps

Geometry clipmap (Losasso and Hoppe, SIGGRAPH 2004, 논문)은 하이트맵 지형 LOD의 황금 표준으로 남아 있습니다. 아이디어는 지형을 카메라를 중심으로 한 동심 정사각형 링들의 집합으로 렌더링하는 것입니다. 각 링은 이전 링의 두 배 면적이지만 절반 해상도입니다.

카메라 가까이(가장 안쪽 링): 풀 해상도, 1미터 격자 간격. 한 링 바깥: 2미터 간격, 4배 면적 커버. 다음 링: 4미터 간격, 16배 면적 커버. 이런 식으로 6-8 레벨, 가장 바깥 링이 가시 거리 전체를 덮을 때까지 이어집니다.

총 정점 수는 일정합니다. 대략 N^2 * 레벨 수이며, N은 링 너비(정점 단위)입니다. N=256에 8 레벨이면 총 약 50만 정점입니다. 월드가 1 km든 100 km든 똑같이 렌더링됩니다.

브라우저 구현: Geometry clipmap은 표준 버텍스 버퍼 업데이트만 필요해서(compute 셰이더 없음) WebGL 2에서 동작합니다. 카메라가 움직이면 CPU가 각 링의 하이트맵 데이터를 적절한 해상도로 지형을 샘플링해 업데이트합니다. 버텍스 셰이더는 텍스처에서 높이 값을 읽어 평평한 격자를 변위시킵니다.

모핑: LOD 레벨 사이 전환은 순진하게 처리하면 눈에 보이는 "팝핑"을 만듭니다. Geomorphing(아래 별도 절에서 자세히)은 버텍스 셰이더에서 전환 구간에 걸쳐 레벨 간 정점 위치를 블렌딩해, 추가 드로우 콜 비용 없이 부드럽고 팝 없는 전환을 만듭니다.

CDLOD: 쿼드트리 적응형 Clipmap

CDLOD (Strugar, 2014, 논문)는 고정된 동심 링 대신 쿼드트리를 써서 geometry clipmap을 개선합니다. 쿼드트리는 지형에 적응합니다. 평지는 거친 노드를 쓰고, 디테일이 높은 영역(절벽, 능선)은 더 세밀한 분할을 받습니다.

이건 크리에이터 월드에 중요합니다. 청크마다 복잡도가 다르기 때문입니다. 평평한 초원은 최소 해상도면 됩니다. 절벽과 동굴이 있는 산악 지역은 최대 디테일이 필요합니다. CDLOD는 해상도를 중요한 곳에 할당합니다.

CPU 측 쿼드트리 순회는 가볍고(노드 수백 개) 어떤 지형 패치를 어떤 해상도로 그릴지 결정합니다. GPU는 각 패치를 패치별 LOD 유니폼이 있는 인스턴스 격자로 렌더링합니다.

Concurrent Binary Trees: 행성 규모 테셀레이션

Concurrent Binary Trees(CBT)는 적응형 지형 테셀레이션을 위한 GPU 친화적 자료구조로, Benyoub과 Dupuy가 제시했습니다(Intel, HPG 2024, 논문, GitHub).

핵심 아이디어는 지형을 각 노드가 삼각형인 이진 트리로 표현하는 것입니다. 적응형 분할은 카메라에 가까운 삼각형을 쪼개고 멀리 있는 삼각형을 병합합니다. 이진 트리는 1D 배열(이진 힙)로서 전적으로 GPU 메모리에 존재하며, 분할/병합 연산은 compute 셰이더로 돌아갑니다.

2024년 논문은 CBT를 정사각형 하이트맵 도메인에서 임의의 다각형 메시로 확장합니다. 즉, 구(행성 렌더링용)나 임의의 기반 메시(비사각형 경계가 있는 게임 월드용)를 테셀레이션할 수 있습니다. 핵심 개선은 CBT를 암시적 인코딩 대신 메모리 풀 관리자로 쓰는 것으로, 훨씬 높은 분할 레벨을 허용합니다.

성능: 콘솔급 하드웨어에서 0.2ms 미만에 행성 규모 지형 테셀레이션. 알고리즘은 프로세서 수에 따라 선형으로 확장됩니다. WebGPU에서는 이것이 브라우저에서 행성 규모 지형 렌더링으로 가는 경로를 제공하지만, 구현 복잡도는 높습니다.

WebGPU를 활용한 GPU 구동 LOD

WebGPU는 LOD 결정에서 CPU 개입을 없애는 완전 GPU 구동 지형 파이프라인을 가능하게 합니다.

1. Compute 패스 1: 프러스텀 및 오클루전 컬링. compute 셰이더가 각 지형 패치의 바운딩 박스를 뷰 프러스텀과 오클루전 버퍼(이전 프레임의 다운샘플링된 깊이 버퍼)에 테스트합니다. 보이지 않는 패치는 통째로 버립니다.

2. Compute 패스 2: LOD 선택. 보이는 패치에 대해 화면 공간 크기를 계산하고 적절한 LOD 레벨을 선택합니다. LOD 레벨과 패치 ID를 간접 드로우 버퍼에 씁니다.

3. Compute 패스 3: 메시 생성(볼류메트릭 지형용). SDF 데이터가 있는 청크에 대해 선택된 LOD 해상도로 marching cubes를 실행해 메시를 생성합니다.

4. 간접 드로우. 단일 drawIndexedIndirect() 호출이 모든 지형 패치를 렌더링합니다. GPU가 모든 것을 결정합니다. 무엇을, 어떤 해상도로, 어떤 순서로 그릴지를요.

이 파이프라인은 월드 크기나 복잡도와 무관하게 CPU 비용이 일정합니다(compute 셰이더 디스패치와 간접 드로우 콜). GPU가 모든 패치별 결정을 처리합니다.

@compute @workgroup_size(64)
fn lodSelection(@builtin(global_invocation_id) id: vec3<u32>) {
    let patchIdx = id.x;
    let bounds = patchBounds[patchIdx];

    if (!frustumTest(bounds, viewProjection)) { return; }
    if (occlusionTest(bounds, depthPyramid) == OCCLUDED) { return; }

    let screenSize = projectedSize(bounds, viewProjection, screenDimensions);
    let lod = clamp(u32(log2(maxScreenSize / screenSize)), 0u, MAX_LOD);

    let drawIdx = atomicAdd(&drawCount, 1u);
    drawArgs[drawIdx] = DrawArgs(patchIdx, lod, indexCount[lod], indexOffset[lod]);
}

Geomorphing: 팝 없는 LOD 전환

지형 LOD에서 가장 큰 시각적 아티팩트는 팝핑입니다. 패치가 LOD 레벨을 바꿀 때 정점이 갑자기 새 위치로 점프하는 것입니다. Geomorphing은 전환 구간에 걸쳐 LOD 레벨 사이 정점 위치를 부드럽게 보간해 이를 없앱니다.

구현은 전적으로 버텍스 셰이더에 있습니다. 각 정점은 현재 LOD 위치와 다음 더 거친 LOD 위치를 모두 저장합니다. 카메라 거리가 전환 임계값을 넘으면 모프 팩터가 둘 사이를 블렌딩합니다.

float morphFactor = smoothstep(lodNear, lodFar, distanceToCamera);
float morphedHeight = mix(fineLodHeight, coarseLodHeight, morphFactor);
gl_Position = viewProjection * vec4(worldPos.x, morphedHeight, worldPos.z, 1.0);

Hoppe의 geometry clipmap 논문(GPU Gems 2, 2장)이 clipmap 링에 대한 전체 구현을 설명합니다. 모프 구간은 각 링의 바깥쪽 20%입니다. 이 구간 안에서 정점들이 다음 링의 해상도로 부드럽게 수렴합니다. 시각적 효과는 지형 지오메트리가 디테일 레벨 사이를 끊기듯 바뀌는 게 아니라 "녹아내리는" 것입니다. 보통의 카메라 속도에서 전환은 보이지 않습니다.

이미지 공간 블렌딩(Scherzer et al., 논문)은 두 LOD 레벨의 렌더링된 이미지를 화면 공간에서 블렌딩하는 대안입니다. 더 극단적인 LOD 차이(예: 메시-빌보드 전환)를 다루지만 전환 구간에 대해 추가 렌더 패스 비용이 듭니다.

GPU 구동 식생 컬링

식생(나무, 풀, 바위)은 오픈 월드에서 흔히 드로우 콜의 가장 큰 원천입니다. 순진한 방식은 매 프레임 모든 식생 인스턴스를 그립니다. 이제 WebGPU를 통해 Three.js에서 쓸 수 있는 GPU 구동 컬링은 보이지 않는 인스턴스가 래스터라이저에 도달하기 전에 제거합니다.

Three.js의 ComputeInstanceCulling(문서)은 인스턴스 메시에 프러스텀 및 LOD 컬링을 제공하며, 인스턴스 수가 많을 때 10-100배 성능 향상을 냅니다. 파이프라인은 이렇습니다.

1. compute 셰이더가 모든 인스턴스 바운딩 구를 읽습니다
2. 각각을 카메라 프러스텀에 테스트합니다(6평면 테스트)
3. 거리 기반 LOD를 적용합니다. 임계값 너머의 인스턴스는 낮은 디테일로 전환되거나 통째로 컬링됩니다
4. 살아남은 인스턴스는 버퍼로 압축되어 drawIndirect로 그려집니다

CPU는 인스턴스별 작업을 전혀 하지 않습니다. 초기 설정 이후 비용은 식생 유형당 compute 디스패치 하나에 간접 드로우 콜 하나이며, 인스턴스 수와 무관합니다.

더 빽빽한 식생에는 Three.js의 IndirectBatchedMesh(문서)가 여러 지오메트리 유형(나무, 덤불, 바위)을 단일 버퍼에 묶어 multi-draw indirect로 그립니다. 청크 안의 모든 식생에 대해 드로우 콜 하나입니다.

우리 식생 시스템의 밀도 맵 기반 산포와 결합하면 이렇게 됩니다. 밀도 맵이 compute 셰이더에서 5만 개의 풀잎 위치를 생성하고, 컬링 패스가 화면 밖이거나 너무 먼 70%를 제거하고, 간접 드로우 콜 하나가 살아남은 1만 5천 개의 잎을 렌더링합니다. 총 CPU 비용은 무시할 만합니다.

볼류메트릭 지형을 위한 LOD

볼류메트릭 지형(SDF + marching cubes)은 메시가 미리 만들어진 게 아니라 생성되기 때문에 자체 LOD 시스템이 필요합니다. 방식은 이렇습니다.

다해상도 SDF 저장. SDF를 밉맵 같은 위계로 여러 해상도에 저장합니다. 레벨 0은 풀 해상도(1미터 복셀)입니다. 레벨 1은 2미터 복셀(데이터 8배 적음)입니다. 레벨 2는 4미터 복셀입니다. 각 레벨에서 SDF는 최소 절댓값 거리를 취해 다운샘플링됩니다.

LOD 선택형 marching cubes. 원하는 LOD에 맞는 SDF 레벨에서 marching cubes를 실행합니다. 가까운 청크는 레벨 0을 씁니다. 먼 청크는 레벨 2나 3을 씁니다. Transvoxel 알고리즘이 서로 다른 레벨 사이 경계를 처리합니다.

캐싱. 생성된 메시는 SDF가 바뀌거나(크리에이터 편집) LOD 레벨이 바뀔 때까지(카메라가 크게 이동) 캐시됩니다. 정적 지형에서는 메시가 한 번 생성되고 재사용됩니다.

지형을 위한 스트리밍 아키텍처

청크 데이터 포맷

각 지형 청크(64x64미터)는 작은 바이너리 패키지로 스트리밍됩니다.

ChunkPacket {
  header: {
    chunkX: i16, chunkZ: i16,
    version: u32,
    flags: u8  // hasHeightmap | hasVolumetric | hasVegetation
  }
  heightmap: {
    resolution: u8,      // 풀은 65x65, 절반은 33x33, 1/4은 17x17
    quantizedHeights: u16[resolution * resolution],  // 델타 인코딩, zlib 압축
    splatMap: u8[4 * resolution * resolution]         // RGBA 블렌드 가중치, LZ4 압축
  }
  volumetric?: {         // flags.hasVolumetric일 때만 존재
    sdfResolution: u8,   // 보통 32 또는 64
    sparseOctree: bytes  // 런렝스 인코딩된 희소 SDF
  }
  vegetation?: {         // flags.hasVegetation일 때만 존재
    treeDensityMap: u8[16 * 16],    // 4m 해상도 밀도 격자
    grassDensityMap: u8[32 * 32],   // 2m 해상도 밀도 격자
    rockDensityMap: u8[16 * 16]
  }
  creatorObjects: {
    count: u16,
    objects: PlacedObject[]   // assetId + 트랜스폼 + 속성, 각각 ~40바이트
  }
}

전형적인 크기:

• 하이트맵만 있는 청크(평지): 압축 2-4 KB
• 하이트맵 + 식생: 4-8 KB
• 하이트맵 + 볼류메트릭 + 식생(복잡한 청크): 20-100 KB
• 5x5 풀 디테일 이웃: 총 50-500 KB

점진적 청크 로딩

청크는 거리, 이동 방향, 데이터 유형에 따른 우선순위 순서로 로드됩니다.

우선순위 1(즉시, <100ms): 플레이어가 막 들어가려는 청크의 하이트맵 지오메트리. 지형 표면이 먼저 나타납니다. 가장 낮은 해상도(청크당 17x17)에서도 땅은 거기 있습니다.

우선순위 2(빠름, <300ms): 스플랫 맵과 지형 텍스처. 땅에 색이 입혀집니다.

우선순위 3(스트리밍, <1s): 풀 해상도 하이트맵 업그레이드. 식생 밀도 맵. GPU 인스턴싱이 나무와 풀을 생성합니다.

우선순위 4(백그라운드, <3s): 동굴/오버행이 있는 청크의 볼류메트릭 SDF 데이터. marching cubes가 Web Worker에서 메시를 생성하고 버퍼를 메인 스레드로 전송합니다.

우선순위 5(지연, <10s): 크리에이터가 배치한 오브젝트. 구조물의 고해상도 텍스처. 꽃, 작은 바위, 잔해 같은 디테일 오브젝트.

예측 선반입

플레이어가 청크에 들어갈 때까지 기다렸다가 로드하지 마세요. 속도를 기준으로 어디로 갈지 예측해 미리 로드합니다.

• 걷기 속도(5 km/h): 2 청크 앞(128m)을 미리 가져옵니다. 전형적인 광대역 지연에서 이건 200-400ms의 여유 시간입니다.
• 달리기/탈것(15 km/h): 4 청크 앞을 미리 가져옵니다. 로드 링이 속도 방향에 따라 이동합니다.
• 비행/빠른 이동: 전환 중 렌더링을 멈춥니다. 목적지 청크를 최고 우선순위로 스트리밍합니다. 첫 프레임에 충분한 데이터가 존재하면 렌더링을 재개합니다.

선반입 시스템은 어떤 청크가 캐시에 있는지, 어떤 게 전송 중인지(요청했으나 아직 도착 안 함), 어떤 게 필요한지 추적합니다. 우선순위 큐가 대기 중 요청을 긴급도순으로 정렬합니다. 플레이어가 멀어진 청크의 요청은 취소합니다.

메모리 예산과 축출

브라우저 탭은 데스크톱에서 2-4 GB를 받습니다. 지형 시스템은 그 일부 안에서 살아야 합니다(나머지는 렌더링, 물리, 네트워킹, JavaScript 힙용).

목표 예산: 모든 지형 데이터에 256 MB.

전형적인 청크 크기로 보면 이렇습니다.

• 풀 디테일 캐시 청크: 약 100개(10x10 이웃), 각 5-100 KB = 원시 데이터 5-10 MB
• GPU 지형 지오메트리: 약 50 MB(가시 지형의 버텍스 버퍼, 인덱스 버퍼)
• 지형 텍스처: 약 100 MB(KTX2 압축, 아틀라스 패킹)
• 식생 인스턴스 버퍼: 약 50 MB(GPU 인스턴싱용 위치, 회전, 스케일)
• SDF 볼륨과 캐시된 marching cubes 메시: 약 50 MB

가시 범위 너머의 청크는 GPU 메모리에서 먼저 축출되고(텍스처, 버텍스 버퍼), 그다음 CPU 캐시에서 축출됩니다. 원시 하이트맵 데이터는 가장 마지막에 사라집니다. 유지 비용이 가장 싸고, 플레이어가 돌아설 때 가지고 있는 게 가장 중요하기 때문입니다.

생물군계 전환과 타일링 방지

부드러운 생물군계 경계

진짜 풍경은 생물군계 사이에 딱딱한 가장자리가 없습니다. 숲이 한 선에서 멈추고 사막이 되지 않습니다. 그라디언트가 있습니다. 빽빽한 숲이 흩어진 나무로 성겨지고, 다음엔 관목지, 다음엔 성긴 사막 식생입니다. 이걸 제대로 하면 월드가 타일처럼이 아니라 연속적으로 느껴집니다.

AutoBiomes(Kötter et al., 논문)는 절차적 지형 생성을 단순화된 기후 시뮬레이션과 결합합니다. 온도, 습도, 고도가 각 점의 생물군계 유형을 결정합니다. 생물군계 사이에서 머티리얼 가중치와 식생 밀도가 전환 구간(보통 50-100미터 너비)에 걸쳐 보간됩니다. 전환 너비는 생물군계 쌍에 따라 달라집니다. 숲-초원은 넓고 점진적이고, 절벽-물은 좁고 급격합니다.

크리에이터 월드에서는 생물군계 배정이 거친 격자에서 돌아갑니다(16x16미터 영역당 생물군계 샘플 하나). 지형 셰이더가 현재 프래그먼트와 이웃의 생물군계 값을 읽어 전환 구간에서 머티리얼 가중치를 보간하고 텍스처를 그에 맞게 블렌딩합니다. 식생 산포도 같은 보간 밀도 값을 쓰므로 숲 가장자리에서 나무 밀도가 점진적으로 옅어집니다.

크리에이터 제어: 크리에이터가 자기 부지에 생물군계 오버라이드를 칠하게 합니다. 시스템은 지형 속성에서 기본 생물군계를 생성하지만, 크리에이터가 그것을 오버라이드할 수 있습니다. 낮은 지대에 "늪"을 칠하면 머티리얼이 탁한 물, 이끼, 죽은 나무로 바뀝니다. 생물군계 페인트 맵은 청크당 16x16 생물군계 ID 격자(256바이트)이며 절차적 배정을 오버라이드합니다.

Hex-Tiling: 텍스처 반복 제거

지형 렌더링에서 가장 흔한 시각적 아티팩트는 텍스처 반복입니다. 1미터 풀 텍스처를 100미터 초원에 타일링하면 눈에 보이는 격자 패턴이 생깁니다. 두 기법이 이를 해결합니다.

Hex-tiling(Mikkelsen, 데모)은 정사각형 타일링 격자를 육각형 격자로 대체합니다. 각 육각형 타일은 무작위 오프셋과 회전으로 텍스처를 샘플링합니다. 육각형 경계는 이음매를 숨기도록 블렌딩됩니다. 결과는 타일처럼이 아니라 균일하게 무작위로 보이는 표면입니다. 비용: 프래그먼트당 약 3번의 추가 텍스처 샘플. 이 기법은 프로덕션 게임에서 널리 쓰이며 어떤 프래그먼트 셰이더에서든 돌아갑니다.

확률적 텍스처 필터링(Pharr et al., NVIDIA, 2024, 논문)은 셰이딩 전이 아니라 후에 확률적 샘플링을 써서 필터링을 적용합니다. 확률적 샘플링의 오차는 미미하며 시공간 디노이징으로 잘 처리됩니다. 이것은 더 정확한 필터링 결과를 내고 압축/희소 텍스처와 함께 동작합니다. 지형에서는 타일링 아티팩트와, hex-tiling이 때때로 전환부에 도입하는 필터링 아티팩트를 모두 없앱니다.

브라우저 월드에서는 hex-tiling이 실용적인 선택입니다(어떤 셰이더에서든 동작함). 확률적 필터링은 더 많은 인프라가 필요하지만 시간적 디노이징이 가용하다면(TAA가 있는 WebGPU 경로에서는 그럴 것) 더 나은 결과를 냅니다.

지형 머티리얼 시스템

Triplanar 매핑

표준 UV 매핑 텍스처는 가파른 경사에서 끔찍하게 늘어납니다. UV 좌표가 압축되기 때문입니다. Triplanar 매핑은 세 축(X, Y, Z)을 따라 텍스처를 투영하고 표면 법선에 따라 블렌딩합니다.

vec3 blending = abs(normal);
blending = normalize(max(blending, 0.00001));
blending /= (blending.x + blending.y + blending.z);

vec4 xaxis = texture(material, worldPos.yz * scale);
vec4 yaxis = texture(material, worldPos.xz * scale);
vec4 zaxis = texture(material, worldPos.xy * scale);

vec4 color = xaxis * blending.x + yaxis * blending.y + zaxis * blending.z;

절벽면은 X 또는 Z 투영을 받습니다(늘어남 없음). 평지는 Y 투영을 받습니다. 블렌딩은 부드럽고 자동입니다. UV 언래핑이 필요 없습니다.

Babylon.js에는 내장 TriPlanar Material이 있습니다. Three.js는 커스텀 셰이더가 필요하지만 구현은 GLSL 약 30줄입니다.

PBR 지형에서는 모든 채널에 triplanar 매핑을 적용합니다. 알베도, 노멀, 러프니스, 앰비언트 오클루전. 같은 블렌딩 가중치가 각 채널에 적용됩니다.

경사 및 고도 기반 머티리얼 배정

스플랫 맵을 손으로 칠하는 대신 지형 속성에 따라 절차적으로 머티리얼을 배정합니다.

float slope = acos(dot(normal, vec3(0, 1, 0)));
float altitude = worldPos.y;

float grassWeight = smoothstep(0.3, 0.0, slope) * smoothstep(2000.0, 1500.0, altitude);
float rockWeight = smoothstep(0.2, 0.5, slope);
float snowWeight = smoothstep(2500.0, 3000.0, altitude) * smoothstep(0.4, 0.1, slope);
float sandWeight = smoothstep(5.0, 0.0, altitude) * smoothstep(0.15, 0.0, slope);

낮은 고도의 평지는 풀을 받습니다. 가파른 경사는 바위를 받습니다. 높은 고도는 눈을 받습니다(단, 눈이 쌓일 만큼 평평한 표면에서만). 해수면 근처는 모래를 받습니다. 전환은 부드럽고 물리적으로 동기 부여됩니다.

크리에이터 월드에서는 고도 임계값과 블렌드 구간을 청크당 칠할 수 있는 파라미터로 노출합니다. 크리에이터는 수목한계선을 위아래로 옮기거나, 눈 덮임을 확장하거나, 자기 부지의 머티리얼 규칙을 조정해 풀 언덕을 모래 사막으로 바꿀 수 있습니다.

GPU 친화적 라플라시안 텍스처 블렌딩

표준 텍스처 블렌딩(레이어 간 선형 보간)은 눈에 보이는 이음매나 흐릿하고 대비가 낮은 결과를 만듭니다. 라플라시안 피라미드 블렌딩이 이를 해결하지만 전통적으로 비싼 사전 계산이 필요합니다.

Wronski (NVIDIA, 2025, JCGT)는 사전 계산도 추가 메모리도 없이 실시간 셰이더에서 동작하는 GPU 친화적 변형을 제시합니다. 이 기법은 표준 밉맵 체인을 라플라시안 피라미드의 근사로 씁니다. 텍스처를 현재 밉 레벨과 더 거친 레벨에서 모두 샘플링하고, 그 차이(라플라시안)를 계산하고, 각 레이어의 라플라시안 기여를 블렌딩합니다.

결과는 날카로운 국소 피처(개별 풀잎, 바위 균열)를 보존하면서 더 큰 스케일에서 부드럽게 블렌딩합니다. 비용은 프래그먼트당 몇 번의 추가 텍스처 탭입니다. 픽셀당 4개 이상의 머티리얼 레이어를 블렌딩하는 지형에서는 선형 블렌딩보다 눈에 띄게 나은 결과를 냅니다. 특히 풀, 바위, 모래 사이의 전환부에서요.

침식 디테일을 위한 Phasor 노이즈

표준 지형은 가까이서 보면 종종 평평해 보입니다. 침식 시뮬레이션이 하이트맵 해상도(1미터 격자)에서 동작하기 때문입니다. 진짜 지형에는 센티미터 규모의 미세한 침식 패턴(릴, 거얼리, 풍화 균열)이 있습니다.

Grenier et al. (2024, CGF)은 phasor 노이즈를 써서 지형 마이크로 디테일을 실시간으로 더합니다. Phasor 노이즈는 주기 함수에 입력되는 확률적 위상장을 정의해 구조화된 패턴을 합성합니다. 지형에 적용하면 공간적으로 변하는 침식 패턴을 만듭니다.

• 좁은 릴을 스케일에 걸쳐 더 큰 거얼리로 단계적으로 발전시킵니다
• 지형 경사에 자동으로 정렬됩니다(침식 패턴이 최대 경사선을 따름)
• 최대 32배 증폭을 달성합니다(하이트맵 해상도의 32배로 디테일 추가)
• 전적으로 프래그먼트 셰이더에서 인터랙티브한 프레임 속도로 돌아갑니다

브라우저 월드에서는 phasor 노이즈가 지형 셰이더에서 디테일 레이어로 돌아갑니다. 하이트맵이 큰 스케일 형태를 제공합니다. Phasor 노이즈는 지오메트리 복잡도를 늘리지 않고 프래그먼트 셰이더에서 설득력 있는 미세 침식을 더합니다. 파라미터(패턴 빈도, 진폭, 방향)는 생물군계마다 달라질 수 있습니다. 맨바위의 깊은 릴, 모래언덕의 잔잔한 물결, 마른 진흙의 거친 나무껍질 같은 질감입니다.

지형을 위한 가상 텍스처링

큰 스케일에서는 지형 텍스처 아틀라스가 다루기 힘들어집니다. 4 km x 4 km 월드를 센티미터당 1텍셀로 하면 400,000 x 400,000 픽셀 텍스처가 필요합니다. 당연히 불가능합니다.

가상 텍스처링(메가텍스처라고도 하며, id Software의 Rage에서 유래)은 지형 텍스처를 페이지화된 구조로 다뤄 이를 해결합니다. 전체 텍스처는 개념적으로 존재하지만 화면에 보이는 타일만 GPU 메모리에 로드됩니다.

파이프라인은 이렇습니다.

1. 피드백 패스: 각 픽셀이 어떤 텍스처 타일을 필요로 하는지(타일 ID와 밉 레벨) 출력하는 셰이더로 지형을 렌더링합니다. 이것을 CPU로 읽어 옵니다(또는 compute 셰이더로 처리합니다).
2. 타일 로딩: 요청된 타일을 CDN에서 로드하거나 스플랫 맵 데이터에서 절차적으로 생성합니다.
3. 인디렉션 텍스처: 작은 텍스처가 가상 타일 좌표를 텍스처 아틀라스의 물리 타일 좌표로 매핑합니다.
4. 렌더 패스: 지형 셰이더가 인디렉션 텍스처를 조회해 올바른 물리 타일을 찾은 뒤 아틀라스에서 머티리얼 텍스처를 샘플링합니다.

WebGPU의 compute 셰이더는 피드백 분석과 페이지 테이블 관리를 전적으로 GPU에서 처리할 수 있습니다. CPU는 타일 I/O만 관리합니다.

결과: 텍스처 메모리 폭발 없이 임의의 해상도로 고유 텍스처가 입혀진 지형. 카메라에서 먼 타일은 낮은 해상도로 로드됩니다. 가까운 타일은 높은 해상도로 로드됩니다. 총 메모리 사용량은 고정 예산 안에 머뭅니다(보통 128-256 MB의 텍스처 아틀라스).

동적 지형 효과

물웅덩이와 젖음

비는 그냥 내리기만 하지 않습니다. 쌓입니다. 움푹한 곳에 물웅덩이를 만듭니다. 표면에 젖은 윤기를 만듭니다. 가파른 경사에서는 흘러내립니다. 이걸 시뮬레이션하면 날씨가 순전히 시각적 오버레이가 아니라 지형과 연결된 것처럼 느껴집니다.

셰이더 기반 방식은 유체 역학을 시뮬레이션하지 않습니다. 지형 하이트맵을 써서 물이 고이는 곳을 결정합니다.

float concavity = heightCenter * 4.0 - heightLeft - heightRight - heightUp - heightDown;
float puddleDepth = max(0.0, concavity * rainIntensity - evaporationRate * timeSinceRain);
float wetness = smoothstep(0.0, 0.02, puddleDepth);

vec3 wetColor = baseColor * 0.7;
float wetRoughness = baseRoughness * 0.3;
vec3 finalColor = mix(baseColor, wetColor, wetness);
float finalRoughness = mix(baseRoughness, wetRoughness, wetness);

오목한 영역(하이트맵의 음의 라플라시안)이 물을 모읍니다. 오목함이 깊을수록 물웅덩이가 큽니다. 젖은 표면은 어두워지고 더 반사적이 됩니다(러프니스 낮아짐). 효과는 비가 멈춘 뒤 시간이 지나며 옅어집니다.

완전한 물웅덩이 반사를 위해서는 물웅덩이 표면에 평면 반사 패스를 더합니다. 또는 더 싸고 Three.js와 Babylon.js 후처리 스택에 이미 있는 화면 공간 반사(SSR)를 씁니다.

물웅덩이 표면의 빗방울은 피드백 텍스처에서 단순한 2D 파동 방정식을 씁니다(Saurel, 2026, 블로그). 각 빗방울은 바깥으로 퍼지며 감쇠하는 잔물결을 만듭니다. 파동 텍스처가 물웅덩이 노멀 맵을 변조해 60fps로 설득력 있는 잔물결 패턴을 만듭니다.

발자국과 지형 변형

플레이어가 무른 지형(모래, 눈, 진흙)을 걸을 때 발자국은 물리적 존재감을 더합니다. 기법은 이렇습니다. 청크당 작은 변형 텍스처(64x64 픽셀 = 4 KB)를 유지해 높이 오프셋을 저장합니다. 캐릭터가 무른 지형을 밟으면 발자국 형상을 변형 텍스처에 찍습니다.

지형 버텍스 셰이더가 변형 텍스처를 읽어 높이에서 오프셋을 뺍니다. 지형 프래그먼트 셰이더가 발자국 영역을 어둡게 하고(다져진 흙은 더 어두움) 러프니스를 높입니다(흐트러진 표면).

발자국은 변형 텍스처를 점진적으로 0으로 만들어 시간이 지나며 옅어집니다(눈이 메우고, 비가 진흙 자국을 씻어 냄). 옅어지는 속도는 날씨에 달려 있습니다. 비 올 때는 빠르고, 건조할 때는 느립니다.

멀티플레이어 월드에서 발자국 데이터는 일시적이고 로컬입니다. 각 클라이언트가 보이는 플레이어를 위해 발자국을 생성합니다. 변형 텍스처는 클라이언트 간 동기화가 필요 없습니다(누구나 자기 버전의 일시적 발자국을 봄). 이렇게 하면 모든 발걸음을 브로드캐스트하는 네트워킹 비용을 피합니다.

절차적 하늘과 낮/밤 사이클

하늘은 어떤 오픈 월드에서든 가장 큰 가시 표면입니다. 지형 전체의 분위기를 정합니다.

Three.js에는 절차적 해/달, 낮/밤 사이클, 구름, 별, 렌즈 플레어를 포함하는 완전한 하늘 시스템이 있습니다. Three.js 내장 Sky 예제(WebGPU에서도 가용)는 Preetham의 해석적 하늘 모델을 구현합니다.

물리적으로 더 정확한 결과를 위해서는 webgpu-sky-atmosphere가 Hillaire의 대기 모델을 WebGPU 후처리로 구현합니다. 다중 산란 위상 함수를 지원하며 올바른 공중 원근(먼 지형이 더 뿌옇게 보임), 해/일몰 색, 하늘 그라디언트를 제1원리에서 만듭니다.

TerrainView7은 사전 계산된 대기 산란으로 WebGPU에서 전체 규모 행성 렌더링을 시연하며, 물리적으로 정확한 대기 렌더링이 브라우저에서 돌아간다는 것을 증명합니다.

크리에이터 월드에서는 하늘 파라미터(해 위치, 구름 덮임, 안개 밀도)가 서버의 월드 시계로부터 모든 클라이언트에 동기화됩니다. 하늘 셰이더는 각 클라이언트에서 로컬로 돌아가며 모든 플레이어에 걸쳐 일관된 조명을 만듭니다.

지형 조명: 간접 조명

직사 햇빛은 섀도 맵이 처리합니다. 하지만 그늘에 있는 지형의 색과 밝기(앰비언트/간접광)도 시각적 품질에 똑같이 중요합니다. 순수한 검정 그림자는 잘못 보입니다. 그림자는 하늘 색으로 물들어야 합니다(맑은 날엔 파랑, 흐린 날엔 회색).

브라우저 월드에서 실용적인 방식은 이렇습니다.

가시성 비트마스크를 사용한 화면 공간 간접 조명(Jimenez et al., 2023, 논문)은 픽셀당 32개의 방향성 가시성 섹터를 추적해 표준 SSAO를 개선합니다. 이것은 한 점이 얼마나 가려졌는지뿐 아니라 가림의 방향성도 잡아냅니다. 얇은 표면은 반대편에서 빛이 올바르게 통과하도록 합니다. 결과는 전역 조명 인프라 없이 주변 지오메트리에 반응하는 간접 조명입니다.

비용은 SSAO와 비슷합니다(1-2ms). 시각적 개선은 상당합니다. 협곡의 지형이 협곡 벽에서 반사광을 받습니다. 오버행의 아랫면이 지면 반사로 밝아집니다. 이 효과는 하늘 셰이더의 대기 산란과 결합해 물리적으로 동기 부여된 앰비언트 조명을 만듭니다.

지형 물리 통합

Rapier 하이트필드 콜라이더

Rapier의 WASM 물리 엔진은 지형에 최적화된 네이티브 하이트필드 콜라이더를 제공합니다. 지형 콜라이더를 만드는 건 간단합니다.

const heights = new Float32Array(65 * 65);
// 하이트맵 데이터로 채우기...
const groundCollider = RAPIER.ColliderDesc.heightfield(
  64, 64, heights, new RAPIER.Vector3(64.0, 100.0, 64.0)
);
world.createCollider(groundCollider);

하이트필드 콜라이더는 효율적인 브로드페이즈 질의를 위해 구조화된 격자를 씁니다. 하이트필드에 대한 레이캐스팅은 삼각형 메시의 O(n)이 아니라 O(log n)입니다. 65x65 청크에서 충돌 질의는 마이크로초 단위로 해결됩니다.

볼류메트릭 지형이 있는 청크(SDF 오버레이)에서는 marching cubes 출력에서 삼각형 메시를 생성하고 trimesh 콜라이더를 씁니다. 이건 하이트필드 콜라이더보다 비싸지만 임의의 지오메트리를 처리합니다. 플레이어에게 가장 가까운 3-5개 청크에만 trimesh 콜라이더를 생성합니다. 먼 청크는 물리가 필요 없습니다.

성능: 65x65 청크에 대한 Rapier의 하이트필드 콜라이더는 캐릭터 컨트롤러 질의에 물리 스텝당 약 0.1ms를 더합니다. 하이트필드 콜라이더가 있는 활성 청크 5개: 0.5ms. 볼류메트릭 청크용 trimesh 콜라이더 하나: 0.2-0.5ms. 총 지형 물리 예산: 1ms 미만으로, 월드 전체의 2-3ms 물리 예산에 충분히 들어갑니다.

지형 인식 캐릭터 컨트롤러

캐릭터 컨트롤러는 지형 속성에 반응해야 합니다.

• 경사 제한: 캐릭터는 최대 45도 경사까지 걸을 수 있습니다. 더 가파른 경사는 미끄러짐을 일으킵니다. 이것은 캐릭터 위치의 지형 법선을 씁니다(하이트맵 그래디언트에서 싸게 계산됨).
• 표면 머티리얼 반응: 바위 위를 걷는 것은 모래나 진흙 위를 걷는 것과 다른 발소리와 이동 속도를 냅니다. 지형의 스플랫 맵이 임의의 점에서 표면 머티리얼을 제공합니다.
• 단 오르기: 캐릭터는 최대 0.5미터의 턱을 오를 수 있습니다. Rapier의 KinematicCharacterController가 설정 가능한 단 높이로 이를 자동으로 처리합니다.

브라우저에서의 인터랙티브 지형 편집

크리에이터 월드에서 지형은 생성되기만 하는 게 아닙니다. 플레이어가 조각하고, 수정하고, 다시 빚습니다. 편집 도구는 반응적이어야 하고(즉각적인 시각 피드백) 네트워크화되어야 합니다(다른 플레이어가 몇 초 안에 변화를 봄).

WebGPU SDF Editor

Reinder Nijhoff의 WebGPU SDF Editor는 풀 기능 SDF 모델링이 오늘날 브라우저에서 동작함을 시연합니다. 이 에디터는 다음을 지원합니다.

• 여섯 가지 프리미티브 형상(구, 박스, 원뿔, 원기둥, 캡슐, 토러스)과 위치, 회전, 스케일
• 불리언 연산(합집합, 차집합, 교집합)과 부드러운 블렌딩 및 설정 가능한 블렌드 반경
• 위계적 씬 그래프와 그룹 및 중첩 연산
• 실시간 렌더링, 다중 GPU compute 셰이더 단계, 16,384개 격자 셀에 걸친 옥트리 기반 공간 분할, marching cubes 또는 surface nets를 통한 표면 추출 사용
• 시간적 안티에일리어싱과 앰비언트 오클루전, 섀도 맵을 통해

각 프리미티브는 단일 GPU 버퍼에 28개의 float(112바이트)로 저장됩니다. 이 작은 표현은 복잡한 지형 편집(동굴 입구, 아치, 깎은 절벽면을 정의하는 수십 개의 SDF 프리미티브)이 5 KB 미만이고 다른 플레이어에게 즉시 동기화됨을 뜻합니다.

크리에이터 월드에서 SDF 편집 워크플로는 이렇게 보입니다.

1. 크리에이터가 조각 도구를 선택합니다(구 추가, 박스 빼기, 부드러운 블렌드)
2. 월드에서 클릭/드래그해 SDF 프리미티브를 배치하고 크기를 정합니다
3. 클라이언트가 즉시 수정된 SDF에 marching cubes를 돌려 로컬 메시를 업데이트합니다(피드백 <16ms)
4. SDF 편집(프리미티브 유형 + 트랜스폼 + 블렌드 모드, ~100바이트)이 서버로 전송됩니다
5. 서버가 편집을 검증하고(크리에이터 부지 안인지, 보호 구역과 겹치지 않는지) 주변 플레이어에게 브로드캐스트합니다
6. 다른 플레이어의 클라이언트가 SDF 편집을 적용하고 로컬 메시를 다시 생성합니다

편집이 다른 사람에게 보이기까지의 총 왕복: 네트워크 지연에 따라 100-300ms. 크리에이터는 서버 확인 전에 로컬에서 적용되므로 자기 편집을 즉시 봅니다.

브러시 기반 하이트맵 편집

하이트맵 레이어(볼류메트릭 피처가 필요 없는 90%의 지형)에는 더 단순한 편집 모델이 동작합니다. 크리에이터가 브러시로 높이 수정을 칠합니다.

• 올리기/내리기: 감쇠가 있는 반경 안에서 높이를 더하거나 뺍니다
• 부드럽게: 반경 안의 높이를 평균 내어 날카로운 피처를 제거합니다
• 평탄화: 반경 안의 모든 높이를 목표 값으로 설정합니다
• 침식 브러시: 브러시 반경 안에서 수력 침식 몇 단계를 로컬로 적용합니다

하이트맵 편집은 델타입니다. 기반 지형 위에 얹히는 작은 높이 변화 패치입니다. 델타 패치는 아주 작고(16비트 높이 오프셋 32x32 격자 = 2 KB) 단일 메시지로 다른 플레이어에게 동기화됩니다. 여러 델타 패치가 청크당 누적되며 주기적으로 서버 측에서 청크의 영구 하이트맵으로 병합됩니다.

협업 편집 제약

여러 크리에이터가 같은 청크를 동시에 편집할 때 시스템에는 규칙이 필요합니다.

• 공간 잠금: 한 번에 한 크리에이터만 주어진 8x8미터 하위 영역을 편집할 수 있습니다. 크리에이터가 편집 스트로크를 시작하면 잠금을 얻고 브러시를 떼면 풉니다. 잠금은 10초 비활동 후 만료됩니다.
• 겹치지 않는 편집: 두 크리에이터가 같은 청크의 다른 부분을 편집하면 두 편집 모두 충돌 없이 적용됩니다(서로 다른 하이트맵 셀이나 SDF 영역을 수정함).
• 겹치는 편집: 두 크리에이터가 같은 위치를 편집하면 서버가 도착 순서로 편집을 직렬화합니다. 두 클라이언트는 조정 후 같은 최종 결과를 봅니다.

이것은 배치된 오브젝트에 쓰는 완전한 CRDT 방식보다 단순합니다. 지형 편집이 이산적 오브젝트 상태가 아니라 연속장(높이, SDF 거리)에 대한 가산 연산이기 때문입니다.

WebGPU의 Nanite 스타일 가상 지오메트리

언리얼 엔진 5의 Nanite는 빌드 타임에 클러스터 DAG(방향성 비순환 그래프)를 만들고 런타임에 화면 공간 오차를 기준으로 클러스터별로 올바른 LOD를 선택해 수십억 개의 삼각형을 렌더링합니다. 전체 파이프라인이 GPU에서 돌아갑니다. 이 방식이 WebGPU로 이식되었습니다.

Nanite WebGPU

Scthe의 Nanite WebGPU(GitHub 1.1k+ 스타)는 Nanite 핵심 아키텍처의 완전한 브라우저 구현입니다.

• meshoptimizer의 클러스터 생성으로 오프라인에서 구축한 Meshlet LOD 위계
• WGSL compute 셰이더로 구현한 소프트웨어 래스터라이저(하드웨어 래스터화가 클러스터별 드로우를 효율적으로 할 수 없는 WebGPU의 제약 안에서 동작)
• 프러스텀 및 오클루전 테스트를 쓰는 인스턴스별 및 meshlet별 컬링
• 극히 먼 오브젝트를 위한 빌보드 임포스터
• 텍스처 및 정점별 노멀 지원

파이프라인: 메시가 약 128개 삼각형의 클러스터로 나뉩니다. 이웃 클러스터가 그룹화되고, 각 그룹은 공유 경계를 보존하면서(meshoptimizer를 써서) 단순화됩니다. 이것은 전체 메시가 단일 클러스터로 붕괴할 때까지 재귀합니다. 런타임에 compute 셰이더가 DAG를 순회하며 현재 화면 해상도에서 1픽셀 미만의 오차를 내는 그룹별 가장 거친 클러스터를 선택합니다.

THREE-Nanite는 떠오르는 Three.js 구현으로, 수십만 개의 삼각형을 다루면서 내장 그래픽 하드웨어에서 20-40fps를 달성합니다. Nanite 스타일 렌더링이 저사양 브라우저 하드웨어에서도 쓸 만함을 보여 줍니다.

meshoptimizer: LOD 파이프라인의 기초

meshoptimizer(Arseny Kapoulkine 제작)는 대부분의 브라우저 호환 LOD 파이프라인 뒤에 있는 라이브러리입니다. 1.0 버전(2025)이 제공하는 것은 이렇습니다.

• 오차 지표가 있는 메시 단순화(형상이 얼마나 바뀌었는지, LOD 선택에 사용)
• Nanite 스타일 meshlet 위계를 위한 클러스터 생성
• GPU 친화적 삼각형 정렬을 위한 버텍스 캐시 최적화
• 픽셀 셰이더 비용을 줄이는 오버드로 최적화
• 더 작은 다운로드를 위한 버텍스 양자화 및 압축

meshoptimizer 1.0(2025년 12월 출시)은 Nanite 스타일 연속 LOD를 직접 구현하는 새로운 단일 헤더 clusterlod.h를 제공합니다. 점진적으로 그룹화되고 단순화되는 클러스터 위계를 만들며, 그대로 쓰거나 커스텀 파이프라인의 참조로 쓸 수 있습니다. 이것이 바로 지형 파이프라인이 SDF/marching-cubes 메시 LOD에 필요로 하는 클러스터 DAG 프리미티브입니다.

우리 지형 파이프라인에서는 meshoptimizer가 SDF 지형의 marching cubes 출력을 LOD 위계가 있는 최적화된 클러스터 메시로 처리합니다. 오프라인 처리는 서버 측에서 돌아갑니다. 브라우저는 미리 클러스터화된 메시를 받아 런타임에 GPU 구동 LOD 선택을 수행합니다.

LOD 생성을 위한 meshoptimizer와 런타임 선택을 위한 WebGPU compute의 조합은 브라우저 지형에 Nanite와 같은 아키텍처 패턴을, 웹 제약에 맞게 적응시켜 제공합니다.

지형 인식 레벨 디자인

지형은 그저 위를 걷는 표면이 아닙니다. 그 형태가 플레이어 이동을 안내하고, 주의를 끌고, 탐험의 감정적 리듬을 만듭니다. 최고의 오픈 월드는 지형을 디자인 도구로 씁니다.

시선과 랜드마크

The Level Design Book의 길찾기 장은 지형 고도가 플레이어가 무엇을 보고 어디로 가는지를 어떻게 제어하는지 기록합니다. 능선은 그 너머를 숨겨 호기심을 만듭니다. 계곡은 이동을 가장 낮은 지점으로 깔때기처럼 모읍니다. 멀리서 보이는 높은 랜드마크(탑, 산봉우리, 특이한 나무)는 플레이어에게 걸어갈 목표를 줍니다.

크리에이터 월드에서 이건 지형 생성이 자연스러운 길찾기 피처를 만들어야 한다는 뜻입니다. 능선은 시선을 끊어 플레이어가 언덕을 넘어 새 영역을 볼 때 "드러나는 순간"을 만들어야 합니다. 계곡은 흥미로운 위치로 모여야 합니다. 크리에이터가 멀리서 보이는 랜드마크를 배치할 수 있는 높은 지점이 존재해야 합니다.

호기심 주도 탐험

퍼듀 대학교의 연구(논문)는 네 가지 공간 탐험 트리거를 밝혀냅니다.

1. 극단 지점 도달(가장 높은 봉우리, 가장 먼 가장자리, 가장 깊은 동굴). 지형은 도달을 보상하는 명확한 극단을 가져야 합니다.
2. 시각적 가림 해소(저 절벽 뒤에 뭐가 있지? 저 동굴 안에는?). 시야를 막는 지형은 숨겨진 것을 찾도록 이동을 유발합니다.
3. 어울리지 않는 오브젝트(황야의 구조물, 어둠 속의 빛). 자연 지형에 대비되는 크리에이터 배치 오브젝트가 주의를 끄는 대비를 만듭니다.
4. 공간적 연결 이해(이 계곡이 저 해안과 어떻게 이어지지?). 읽기 쉬운 지리를 만드는 지형은 지도 읽기와 경로 계획을 장려합니다.

PlotMap: AI 보조 POI 배치

PlotMap(arXiv:2309.15242)은 서사 요구사항(이 퀘스트는 강 근처에 마을이 필요하고, 저 퀘스트는 언덕 위에 폐허가 필요함)을 받아 공간 제약을 만족하는 지형 위치를 찾아 관심 지점 배치를 자동화합니다. 크리에이터 월드에서는 비슷한 시스템이 지형 속성에 따라 구조물 배치를 제안할 수 있습니다. "이 언덕 정상은 망루에 좋은 시선을 가졌다", "이 아늑한 계곡은 마을에 어울린다".

흐르는 물과 폭포

강과 폭포는 시각적 매력을 환경음 및 게임플레이 어포던스(장벽, 자원, 경로로서의 물)와 결합하는 지형 피처입니다.

강 렌더링

오픈 월드의 강은 보통 지형 표면을 따르는 텍스처 스트립으로 렌더링됩니다. 스트립 메시는 강 스플라인(컨트롤 포인트로 저장됨)에서 생성되어 지형 하이트맵에 투영됩니다. 강 셰이더는 다음을 적용합니다.

• 강 방향으로 스크롤하는 흐름 정렬 UV, 흐르는 물의 외형을 만듭니다
• 강이 둑과 만나는 곳의 가장자리 거품(깊이 기반, 해안선 거품과 유사)
• 하도 너비에 따른 속도 변화(좁은 구간은 빠르게 흐르고, 넓은 구간은 느려짐)
• 깊이 기반 색이 있는 투명도(얕으면 맑고, 깊으면 어두움)

브라우저 월드에서 강 데이터는 작습니다. 스플라인(강 구간당 20-50개 컨트롤 포인트, ~400바이트)에 너비와 흐름 속도 파라미터를 더합니다. 클라이언트는 스플라인을 자기 지형 표면에 투영해 강 메시를 로컬로 생성합니다.

폭포 렌더링

강이 절벽면에서 떨어지는 곳에서는 폭포 파티클 시스템이 평평한 강 표면을 대체합니다. 실시간 물 시뮬레이션 연구의 하이브리드 방식(EG): 높이장으로 표현할 수 없는 영역(폭포, 물보라)이 유체 시뮬레이션과 질량 및 운동량을 교환하는 물보라, 튀김, 거품 파티클로 변환됩니다.

브라우저 월드에서 폭포는 더 단순합니다. 강 스플라인이 지형 높이 불연속을 가로지르는 곳을 감지해, 그 지점에 하향 속도를 가진 파티클 시스템을 생성하고, 밑부분에 거품 튀김을 더합니다. 파티클은 스크롤하는 알파 텍스처가 있는 GPU 인스턴스 쿼드입니다. 폭포당 500개 파티클, 드로우 콜 하나. 떨어지는 물소리는 거리 감쇠가 있는 Web Audio API를 씁니다.

먼 지형 피처를 위한 임포스터

나무, 바위, 건물, 그 밖의 지형 피처는 멀리서 아주 작아집니다. 이것들을 완전한 3D 메시로 렌더링하는 것은 GPU 사이클을 낭비합니다. 임포스터는 먼 오브젝트를 카메라를 향하는 미리 렌더링된 평평한 이미지로 대체합니다.

팔면체 임포스터 아틀라스

팔면체 임포스터는 3D 오브젝트의 외형을 여러 시야각에서 포착해 텍스처 아틀라스에 저장합니다. 런타임에 셰이더가 현재 시야 방향을 기준으로 아틀라스를 샘플링하며, 가장 가까운 두 포착 각도 사이를 보간합니다.

반팔면체 아틀라스(나무를 아래에서 볼 일이 드물어 위쪽 반구 시야만)는 같은 텍스처 크기로 완전한 팔면체 아틀라스의 두 배 각도 해상도를 제공합니다. Unity의 임포스터 시스템은 1,600개의 나무 인스턴스를 실제 메시(각 14만 삼각형)에서 임포스터로 전환할 때 프레임 시간이 111ms에서 5.78ms로 떨어진다고 보고합니다.

브라우저 월드에서 임포스터 파이프라인은 이렇습니다.

1. 서버 측: 각 에셋을 16-32개 시야각에서 렌더링해 색, 노멀, 깊이를 포착합니다
2. 아틀라스 텍스처로 패킹합니다(에셋당 아틀라스 하나, ~256x256 픽셀, KTX2로 <100 KB)
3. 런타임: 임포스터 거리 너머의 인스턴스(보통 100-200m)는 아틀라스를 샘플링하는 빌보드로 렌더링됩니다
4. 전환을 숨기기 위해 20m 전환 구간에 걸쳐 메시와 임포스터를 크로스페이드합니다

빌보드 스플래팅 (BBSplat)

빌보드 스플래팅(2024, arXiv:2411.08508)은 학습 가능한 텍스처 평면 프리미티브를 써서 한 걸음 더 나아갑니다. 미리 렌더링된 시야 대신, BBSplat은 어떤 각도에서든 3D 오브젝트를 가장 잘 표현하도록 빌보드 위치와 텍스처를 최적화합니다. 이것은 시야 의존적 외형을 유지하면서 3D Gaussian Splatting 대비 최대 17배 압축을 달성합니다. 브라우저 월드의 먼 지형 피처에서 BBSplat은 각도 커버리지를 개선하면서 에셋당 임포스터 저장량을 줄일 수 있습니다.

전문 지형 도구와 그것이 가르치는 것

지형 파이프라인을 맨바닥부터 만들기 전에, 전문 오프라인 도구가 무엇을 하는지 이해할 가치가 있습니다. 이 도구들은 수십 년의 지형 생성 연구를 프로덕션 워크플로로 증류한 것입니다.

Gaea(QuadSpinner)는 GPU 가속이며 변화에 거의 즉각적인 피드백을 줍니다. 변당 최대 200만 픽셀까지의 타일 빌드, 자동 LOD 메시 익스포트, 그리고 각 노드가 물리 과정(침식, 퇴적, 융기, 열 풍화)인 노드 기반 그래프를 지원합니다. Gaea의 침식 노드는 손으로 조각한 듯 보이는 지형을 만듭니다. 일반적인 노이즈가 아니라 구체적인 물리 과정을 모델링하기 때문입니다. 핵심 통찰: Gaea는 단일 침식 알고리즘을 쓰지 않습니다. 하천 침식(강 깎기), 열 침식(절벽 부서짐), 해안 침식(파도 작용), 풍식(모래언덕 형성)에 별도의 노드를 제공합니다. 이것들을 그래프에서 조합하면 특정 기후의 지질 성격을 가진 지형이 나옵니다.

World Machine은 지형 거시 구조에 초점을 둔 비슷한 그래프 방식을 취합니다. "레이아웃 제너레이터"는 아티스트가 지형 피처의 대략적 형태(여기 산, 저기 계곡, 이 가장자리를 따라 해안선)를 스케치하면 시스템이 물리적으로 그럴듯한 디테일을 채워 넣게 합니다. 이것이 바로 우리가 원하는 크리에이터 워크플로입니다. 의도를 스케치하면 지질을 얻습니다.

World Creator는 편집 중 실시간 미리보기와, 지형을 분석해 배수 분석을 기준으로 흐름 경로를 자동 계산하는 내장 강 생성으로 차별화합니다.

이 도구들에서 우리가 가져가는 것: 물리 과정을 조합하는 노드 그래프 방식은 어떤 단일 알고리즘보다 강력합니다. 우리의 서버 측 생성 파이프라인은 연쇄를 지원해야 합니다. 노이즈 기반 > 지각 융기 > 수력 침식 > 열 풍화 > 해안 침식 > 식생. 크리에이터가 각 단계의 파라미터를 제어합니다. 파이프라인은 서버 측에서 몇 초 안에 돌아가 하이트맵, 스플랫 맵, 식생 밀도 맵을 만듭니다.

SoilMachine: 오픈소스 지형학

SoilMachine은 여러 침식 시스템(수력, 열, 바람)을 퇴적물 운반 및 퇴적과 결합하는 오픈소스 모듈식 지형학 시뮬레이터입니다. C++와 GPU compute로 만들어졌으며, 전문 도구가 쓰는 다중 과정 침식 방식의 참조 구현을 제공합니다.

관련된 soillib(C++20, MIT 라이선스)는 바탕 지형학 시뮬레이션 프리미티브를 재사용 가능한 라이브러리로 제공합니다. 그리고 hydro-gen은 OpenGL compute 셰이더에서 격자 기반(천수)과 입자 기반(빗방울) 수력 침식을 모두 구현하며 실시간 파라미터 조정을 지원합니다.

이 오픈소스 도구들은 우리의 서버 측 생성 파이프라인에 적응시킬 수 있습니다. compute 셰이더 구현은, 실시간 크리에이터 피드백을 위해 브라우저에서 침식을 돌리고 싶어진다면, WebGPU로 바로 옮겨집니다.

다층 지형 머티리얼

진짜 지형은 단일 표면이 아닙니다. 층입니다. 바닥의 기반암, 그 위의 토양, 표면에 쌓이는 눈이나 모래. 동적 레이어링은 계절, 날씨, 크리에이터 행동에 따라 지형의 시각적 성격을 바꿉니다.

층상 하이트필드 표현

단일 하이트맵 대신 격자 셀당 여러 높이 레이어를 씁니다.

Cell {
  bedrock_height: f16,    // 영구 암석 표면
  soil_height: f16,       // 기반암 위에 쌓인 토양/퇴적물
  snow_height: f16,       // 동적 눈 누적
  water_height: f16       // 고인 물 깊이
}

합계: 셀당 8바이트(단일 하이트맵의 2바이트 대비). 65x65 청크면 압축 전 34 KB입니다. 여전히 작습니다.

시각적 표면은 bedrock + soil + snow입니다. 지형 셰이더가 모든 레이어를 읽어 머티리얼을 그에 맞게 블렌딩합니다. 토양이 얇은 곳은 바위가 비쳐 나옵니다. 눈이 쌓인 곳은 표면이 하얗습니다. 물이 고인 곳은 물웅덩이나 호수가 됩니다.

동적 누적

눈은 강설 동안 평평하고 위를 향한 표면에 쌓입니다. 누적률은 표면 법선(가파른 경사는 눈을 머금지 못함), 온도(고도 의존적), 차폐(오버행 아래 영역은 깨끗하게 유지됨)에 달려 있습니다. compute 셰이더 패스가 날씨 틱당 한 번(몇 초마다) 눈 레이어를 업데이트합니다.

모래 누적도 바람 구동 퇴적으로 비슷하게 동작합니다. 바람이 노출된 표면에서 입자를 운반해 장애물 뒤와 차폐된 영역에 퇴적합니다.

크리에이터 월드에서 동적 누적은 지형이 날씨마다 다르게 보인다는 뜻입니다. 눈보라 동안 눈이 월드를 덮고 맑은 시기에 녹습니다. 비가 움푹한 곳을 물로 채웁니다. 이렇게 하면 크리에이터가 아무것도 하지 않아도 월드가 반응적으로 느껴집니다.

다층 침식

2024년 논문 "3D Real-Time Hydraulic Erosion Simulation using Multi-Layered Heightmaps"(EG)는 침식을 레이어를 가로질러 동작하도록 확장합니다. 물은 토양을 기반암보다 빠르게 침식합니다. 퇴적물은 새 토양 레이어로 쌓입니다. 시뮬레이션은 레이어 무결성을 유지하면서(기반암이 토양 아래에 머묾) 오버행 같은 복잡한 피처(기반암이 아래 침식된 토양 위로 돌출)를 가능하게 합니다.

성능: RTX 3070에서 2048x2048 해상도로 시뮬레이션 스텝당 약 6ms. 이건 서버 측 생성에는 충분히 빠르지만 프레임당 브라우저 시뮬레이션에는 너무 느립니다. 층상 표현은 정적 지형 생성에 동작하고, 동적 눈/물 누적은 더 싼 프레임당 셰이더로 돌아갑니다.

풀, 바위, 디테일 렌더링

풍경은 지형 지오메트리와 텍스처 이상이 필요합니다. 바람에 흔들리는 풀잎, 경사에 흩어진 바위, 그리고 가까이서 봤을 때 자연스러워 보이게 하는 꽃, 자갈, 떨어진 나뭇가지 같은 작은 디테일이 필요합니다.

GPU 인스턴스 풀

브라우저 기반 풀 렌더링은 Three.js에서 잘 검증되어 있으며 GPU 인스턴싱으로 동작합니다. al-ro의 풀 데모의 방식은 InstancedBufferGeometry를 써서 10만 개의 풀잎을 단일 드로우 콜로 렌더링합니다.

각 풀잎은 단순한 쿼드(4-8 삼각형)입니다. 인스턴스별 속성이 위치, 높이, 휘는 방향, 색 변화, 바람 위상을 정의합니다. 버텍스 셰이더는 이렇습니다.

1. 인스턴스별 트랜스폼을 읽습니다
2. 월드 위치와 시간에 맞춘 사인파로 바람 애니메이션을 적용합니다
3. 바람 세기에 따라 잎을 휩니다(끝은 더 많이, 밑은 안 휨)
4. 색 그라디언트를 적용합니다(밑은 더 어둡고, 끝은 표면하 산란을 위해 더 밝음)

Codrops의 풍성한 풀 튜토리얼(2025, 튜토리얼)은 셸 텍스처링 방식을 시연합니다. 지면을 점점 커지는 오프셋으로 여러 번 렌더링하고, 각 레이어가 노이즈 텍스처를 샘플링해 빽빽한 풀 볼륨의 외형을 만듭니다. 이건 아주 빽빽한 커버리지에는 개별 잎 인스턴싱보다 싸지만 가까이서는 덜 사실적입니다.

크리에이터 월드에서 풀 밀도는 청크당 식생 밀도 맵에서 나옵니다. GPU가 렌더 타임에 밀도 맵에서 잎 위치를 뿌립니다. 잎별 데이터는 저장하거나 스트리밍하지 않습니다. 밀도 맵은 청크당 32x32 격자(1 KB)이며, GPU가 거기서 수천 개의 잎 인스턴스를 생성합니다.

절차적 바위와 절벽 디테일

절벽면과 바위 지형은 기반 하이트맵이나 SDF가 합리적인 해상도로 제공할 수 없는 기하학적 디테일이 필요합니다. 두 방식이 서로 보완합니다.

GPU 메시 셰이더 재표면화(Raad et al., Eurographics 2025, 논문)는 렌더 타임에 거친 컨트롤 메시에서 절차적 지오메트리를 생성합니다. 메시 셰이더가 기반 지형 표면을 읽어 디테일 지오메트리를 메모리에 저장하지 않고 변위, 균열, 돌출을 더합니다. 이것은 VRAM 사용을 줄이고 동적 LOD를 가능하게 합니다.

인스턴스 바위 산포는 GPU 인스턴싱을 써서 가파른 경사와 절벽 가장자리에 미리 만든 바위 메시를 배치합니다. compute 셰이더가 지형 법선과 경사를 읽어 경사가 임계값을 넘는 곳에 바위 인스턴스를 뿌립니다. 각 인스턴스는 무작위 회전과 스케일이 있는 작은 메시(200-500 삼각형)입니다. 1만 개의 흩뿌린 바위는 인스턴싱으로 무시할 만한 렌더링 비용을 더합니다.

도로와 길

크리에이터가 배치한 도로, 오솔길, 길은 지형에 맞추고 표면 머티리얼을 수정(풀을 흙이나 돌로 대체)해야 합니다.

모든 주요 게임 엔진이 쓰는 방식: 길을 스플라인(일련의 컨트롤 포인트)으로 정의합니다. 스플라인을 지형 표면에 투영합니다. 스플라인을 따르며 지형보다 약간 위에 앉는 스트립 메시를 생성합니다. 스트립에 도로 텍스처를 적용합니다. 지형 셰이더에서 투영 텍스처나 데칼을 써서 지형 머티리얼을 스플라인 너비 안의 도로 머티리얼로 블렌딩합니다.

브라우저 월드에서는 크리에이터가 지형에 길을 그립니다. 클라이언트가 컨트롤 포인트를 생성해 서버로 보냅니다(수십 개의 vec3 값). 서버가 스플라인을 저장합니다. 모든 클라이언트가 스플라인을 자기 지형 메시에 투영해 도로 스트립을 로컬로 렌더링합니다. 도로 데이터는 작지만(길 스플라인 포인트, 아마 200바이트) 시각적 영향은 큽니다. 크리에이터 건물을 잇는 길은 월드가 사람이 사는 곳처럼 느껴지게 합니다.

지형을 위한 그림자

지형 그림자는 가독성(지형 형태 이해)과 분위기(시간대 무드)에 핵심입니다. 오픈 월드에서 태양은 가시 지형 전체에 그림자를 드리웁니다.

캐스케이드 섀도 맵 (CSM)

CSM은 뷰 프러스텀을 3-4개 거리 범위(캐스케이드)로 나눕니다. 각 캐스케이드는 그 거리에 맞는 해상도로 태양 시점에서 섀도 맵을 렌더링합니다. 가까운 캐스케이드: 고해상도(나무와 건물 아래의 상세한 그림자). 먼 캐스케이드: 저해상도(넓은 산 그림자).

Three.js와 Babylon.js 모두 CSM을 지원합니다. 지형의 핵심 최적화: 섀도 맵에는 지형만 렌더링하고 개별 풀잎이나 작은 디테일은 렌더링하지 않습니다. 풀은 자기 것이 아니라 지형의 섀도 맵을 써서 자기 그림자를 만듭니다.

성능 예산: 각 1024x1024인 3-4개 섀도 캐스케이드. 섀도 맵에 지형을 렌더링하는 비용은 0.5-1ms입니다(지형 지오메트리는 이미 GPU 메모리에 있음). 지형 셰이더에서 4개 캐스케이드를 샘플링하는 것은 0.2-0.3ms를 더합니다.

하이트맵에서의 지형 자기 그림자

CSM이 비싸지는 아주 큰 지형에서는 지평선 맵을 사전 계산합니다. 각 지형 셀마다 8개 나침반 방향의 최대 고도각을 저장합니다. 렌더 타임에 태양 각도를 지평선 맵과 비교해 한 점이 그림자 안에 있는지 판단합니다. 이것이 Skyrim이 먼 지형(CSM 범위 너머)의 지형 자기 그림자를 처리하는 방식입니다.

지평선 맵은 하이트맵에서 서버 측으로 계산되고(몇 초의 처리) 청크당 128x128 텍스처로 스트리밍됩니다(압축 16 KB). 시각적 영향은 상당합니다. 산골짜기가 극단적인 시야 거리에서도 사실적으로 어두워집니다.

스트리밍을 위한 지형 데이터 압축

네트워크가 브라우저 월드의 병목입니다. 지형 데이터에서 아낀 모든 바이트가 더 빠른 로드 시간입니다.

하이트맵 압축

원시 16비트 하이트맵은 인접 셀이 비슷한 값을 가져 잘 압축됩니다. 파이프라인은 이렇습니다.

1. 델타 인코딩: 각 셀과 그 예측값(이웃의 평균)의 차이를 저장합니다. 델타 값은 작고 0 근처에 모입니다.
2. 양자화: 먼 청크에는 정밀도를 16비트에서 12비트나 8비트로 줄입니다. 500미터 떨어진 곳에서 8비트 높이 정밀도(100m 높이 범위에서 0.4m 해상도)는 16비트와 구별할 수 없습니다.
3. 엔트로피 코딩: 델타 인코딩된 스트림에 zlib나 brotli 압축을 적용합니다. 전형적인 압축률: 4-8배.

결과: 16비트 65x65 청크가 원시 8.4 KB에서 압축 1-2 KB로 줄어듭니다. 8비트 축소 정밀도에서는 0.5-1 KB입니다.

점진적 하이트맵 스트리밍

지형을 먼저 낮은 해상도로 보낸 뒤 정제합니다. 17x17 하이트맵(4m 셀 간격의 64m 청크에 대한 최소값)은 원시 578바이트, 압축 200바이트 미만입니다. 지형이 즉시 보입니다. 그다음 33x33 정제(홀수 행/열 샘플 추가)를 스트리밍합니다. 그다음 65x65 풀 해상도. 각 레벨은 이전 데이터를 대체하지 않고 디테일을 더합니다.

이것은 geometry clipmap LOD 링에 매핑됩니다. 먼 지형은 저해상도 버전(17x17)을, 중거리는 중간(33x33)을, 가까운 곳은 풀(65x65)을 씁니다. 스트리밍 우선순위가 렌더링 LOD와 일치합니다.

SDF 볼륨 압축

희소 SDF 볼륨은 대부분의 복셀이 표면에서 멀리(빈 공간) 떨어져 있어 극적으로 압축됩니다. 옵션은 이렇습니다.

런렝스 인코딩: 같은 값(빈 복셀)의 런을 인코딩합니다. 전형적인 SDF 볼륨은 95% 이상이 비어 있어 RLE가 10-50배 압축을 달성합니다.

희소 옥트리: 표면 교차 복셀을 포함하는 옥트리 노드만 저장합니다. 빈 공간에는 노드가 없습니다. 동굴 터널 하나가 있는 64^3 SDF 볼륨은 점유 노드가 2,000-5,000개뿐일 수 있으며(총 262,144 복셀 대비), 각각 1-2바이트로 저장됩니다.

엔트로피 주도 점진적 압축(2024, HAL)은 엔트로피 최적화 평면과 적응형 양자화로 공간을 재귀적으로 분할해 3D 공간 데이터에 적용됩니다. 이것은 레이트-디스토션 트레이드오프에 최적화된 정제 스트림을 만들며, 특히 네트워크 스트리밍의 낮은 비트레이트에서 유익합니다.

종합하기: 브라우저 지형 파이프라인

이 글 맨 위의 전략 개요는 빠른 의사결정 프레임워크와 단계별 빌드 계획을 줍니다. 이 절은 서버 측 생성 파이프라인과 브라우저 렌더링 파이프라인 모두에 대한 완전한 기술 디테일을 제공합니다.

생성 파이프라인 (서버 측)

생성 파이프라인은 Gaea와 World Machine의 노드 그래프 방식에서 영감을 받아 물리 과정의 방향성 그래프로 돌아갑니다. 각 단계는 이전 단계의 출력을 받아 정제합니다. 크리에이터가 각 단계의 파라미터를 제어합니다.

새 4x4 km 월드는 15-90초 만에 생성됩니다. 크리에이터 편집(조각, 파라미터 변경)은 영향받은 청크에 대해 영향받은 단계만 다시 돌리며, 보통 5초 미만에 완료됩니다.

렌더링 파이프라인 (브라우저)

60fps(프레임당 16.6ms)에서 지형 시스템은 WebGPU에서 프레임 예산의 21%, WebGL 2에서 39%를 씁니다. 나머지는 플레이어 아바타, 크리에이터 오브젝트, UI, 네트워킹, 후처리에 가용합니다.

이것이 브라우저에서 동작하는 이유

전체 파이프라인은 세 가지 브라우저 제약을 중심으로 설계되었습니다.

메모리(최대 2-4 GB): 256 MB 지형 예산이 들어맞습니다. 하이트맵 청크가 각 2-8 KB(델타 인코딩)이고, SDF 볼륨이 희소하며(볼류메트릭 청크당 100-500 KB), 식생이 1 KB 밀도 맵에서 런타임에 생성되고, 텍스처가 KTX2 압축(1024x1024당 150 KB)을 쓰기 때문입니다. 어느 순간이든 브라우저에 보이는 월드는 총 50-200 MB입니다.

디스크 접근 없음: 모든 것이 네트워크로 스트리밍됩니다. 점진적 로딩은 플레이어가 <100ms에 지형(저해상도 하이트맵)을, <300ms에 텍스처가 입혀진 지형을, <3s에 풀 디테일을 본다는 뜻입니다. 속도 기반 선반입이 보통의 탐험 중 로드 시간을 숨깁니다.

GPU가 천차만별: WebGPU 경로는 고사양 데스크톱을 다룹니다. WebGL 2 폴백은 모바일을 포함한 그 밖의 모든 것을 다룹니다. 같은 청크 데이터가 두 경로를 모두 구동합니다. 차이는 렌더링 기법이지 데이터 포맷이 아닙니다. WebGL 2를 돌리는 Chromebook은 WebGPU를 돌리는 RTX 4090과 같은 월드를 봅니다. 단지 디테일이 낮고 시야 거리가 짧을 뿐입니다.

연구 논문

지형 표현과 메시 생성

"Marching Cubes: A High Resolution 3D Surface Construction Algorithm" -- Lorensen and Cline (SIGGRAPH 1987). DOI. 볼류메트릭 데이터에서 삼각형 메시를 추출하는 기초 알고리즘. 38년이 지난 지금도 가장 널리 쓰이는 등치면 추출 방법입니다. GPU 병렬 구현은 WebGPU compute 셰이더에서 실시간으로 돌아갑니다.

"Dual Contouring of Hermite Data" -- Ju, Losasso, Schaefer, Warren (SIGGRAPH 2002). DOI. marching cubes가 둥글려 버리는 날카로운 피처(절벽 모서리, 바위 코너)를 보존하는 메시를 만듭니다. 거리 값에 더해 표면 법선을 필요로 합니다.

"Neural Dual Contouring" -- Chen et al. (2022). arXiv:2202.01999. dual contouring의 최소제곱 정점 배치를 학습된 예측기로 대체합니다. 복잡한 자연 피처에 더 나은 표면 품질.

"The Transvoxel Algorithm" -- Lengyel (2009, 2024 갱신). transvoxel.org. 복셀 지형을 위한 이음매 없는 LOD 전환. 73가지 전환 셀 유형으로 해상도 경계의 균열을 없앱니다. 특허 없음, 실시간 응용을 위해 설계됨.

지형 LOD와 렌더링

"Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids" -- Losasso and Hoppe (SIGGRAPH 2004). 논문. 동심 LOD 링으로 일정 비용 지형 렌더링. 40 GB 지형을 인터랙티브한 속도로 처리합니다. 대부분의 브라우저 지형 렌더러의 기초.

"CDLOD: Hybrid LOD for Terrain Rendering" -- Strugar (2014). 논문. geometry clipmap에 대한 쿼드트리 적응형 개선. 거리만이 아니라 지형 복잡도에 따라 해상도를 할당합니다.

"GPU-Driven Rendering Pipelines" -- Ubisoft (SIGGRAPH 2015), Wihlidal and Hoppe. compute 셰이더가 컬링, LOD 선택, 드로우 콜 생성을 처리하는 GPU 구동 방식을 정식화했습니다. 우리 WebGPU 지형 파이프라인의 아키텍처 패턴.

물리 지형 생성

"Physically-Based Analytical Erosion for Fast Terrain Generation" -- Cordonnier et al. (2024). HAL. 반복 시뮬레이션을 피하는 해석적 stream power law 침식. 밀리초 단위로 물리적으로 그럴듯한 지형을 생성합니다.

"Fast Hydraulic Erosion Simulation and Visualization on GPU" -- Mei, Decaudin, Hu (2007). HAL. 천수 시뮬레이션을 쓰는 GPU 병렬 수력 침식. 대부분의 게임 엔진 침식 구현의 기반.

"Arenite: A Physics-Based Sandstone Simulator" -- SIGGRAPH 2025. 프로젝트. 응력과 침식 시뮬레이션으로 아치, 후두, 알코브를 생성하는 다중 물리 침식. 데스크톱 GPU에서 5분 미만에 돌아갑니다.

"Efficient Debris-flow Simulation for Steep Terrain Erosion" -- Purdue CGVLAB (2024). 논문. 사실적인 산악 지형 피처를 만드는 GPU 가속 토석류 및 급경사 침식.

"Flexible Terrain Erosion" -- IRIT-STORM (2024). Springer. 통합 인터페이스로 하이트필드, 복셀 격자, 음함수 표면, 층상 머티리얼을 가로질러 동작하는 입자 기반 침식. 하이브리드 지형 표현을 위한 단일 침식 시스템을 가능하게 합니다.

지형 디테일과 텍스처링

"GPU-Friendly Laplacian Texture Blending" -- Wronski (NVIDIA, 2025). JCGT. 사전 계산 없는 지형 머티리얼 실시간 라플라시안 피라미드 블렌딩. 이음매 아티팩트를 없애면서 날카로운 피처를 보존합니다. 프래그먼트당 몇 번의 추가 텍스처 탭.

"Real-time Terrain Enhancement with Controlled Procedural Patterns" -- Grenier et al. (2024). CGF. 최대 32배 하이트맵 해상도의 phasor 노이즈 기반 미세 침식 디테일. 경사 정렬 패턴이 전적으로 프래그먼트 셰이더에서 돌아갑니다.

적응형 테셀레이션

"Concurrent Binary Trees for Large-Scale Game Components" -- Benyoub and Dupuy (Intel, HPG 2024). 논문. 적응형 지형 테셀레이션을 위한 GPU 친화적 이진 트리 자료구조. 행성 규모 지오메트리를 0.2ms 미만에 렌더링합니다. 정사각형 도메인에서 임의의 다각형 메시로 확장됨.

동굴과 지하 생성

"PLUME: Procedural Layer Underground Modeling Engine" -- 2024. arXiv:2508.20926. 층상 절차적 규칙으로 사실적인 동굴과 용암 동굴 환경을 생성하는 오픈소스 프레임워크. 원래 우주 탐사 로보틱스를 위해 만들어졌습니다.

뉴럴 지형 합성

"InfiniteDiffusion: Bridging Learned Fidelity and Procedural Utility for Open-World Terrain Generation" -- Goslin (2025, SIGGRAPH 2026). arXiv:2512.08309. 라플라시안 인코딩이 있는 위계적 디퓨전 모델을 쓰는 무한, 시드 일관 지형 생성. 소비자용 GPU에서 베이스라인보다 9배 빠름.

"TerraFusion: Joint Generation of Terrain Geometry and Texture" -- 2025. arXiv:2505.04050. 스케치 조건이 있는 동시 하이트맵 및 텍스처 합성을 위한 잠재 디퓨전.

"MESA: Text-Driven Terrain Generation" -- CVPR 2025 Workshop. arXiv:2504.07210. Copernicus 원격탐사 학습 데이터를 쓰는 텍스트에서 지형으로.

"Geodiffussr: Generative Terrain Texturing with Elevation Fidelity" -- 2025. arXiv:2511.23029. 흐름 매칭을 써서 고도 데이터를 존중하는 텍스트 안내 지형 텍스처 생성.

"Sketch2Terrain: AI-Driven Real-Time Terrain Sketch Mapping" -- 2025. 프로젝트. 증강 현실에서의 스케치에서 지형으로. 수동 매핑 대비 38% 효율 향상.

식생과 생태계 시뮬레이션

"GPU-Based Real-Time Procedural Distribution of Vegetation on Large-Scale Virtual Terrains" -- SBGames 2018. 논문. GPU에서 생물/비생물 인자를 쓰는 쿼드트리 기반 식생 산포.

"Procedural Generation and Rendering of Forests" -- 2022. 논문. 사실적인 숲 분포를 위한 L-system 나무 생성과 생태계 경쟁 시뮬레이션의 결합.

"Real-Time Procedural Generation with GPU Work Graphs" -- AMD GPUOpen 2024. 논문. 7.9만 개 이상의 식생 인스턴스를 4ms 미만에 생성하는 GPU work graph.

브라우저 GPU 기술

"GSWT Renderer" -- SIGGRAPH Asia 2025. GitHub. 동적 LOD와 스트리밍이 있는 무한 3D 지형을 위해 Gaussian Splatting Wang Tiles를 쓰는 WebGPU + Rust/Wasm 렌더러.

"GPU Compute in the Browser at the Speed of Native: WebGPU Marching Cubes" -- Usher (2024). 블로그. WebGPU compute가 병렬 메시 생성 알고리즘에 네이티브 속도 성능을 달성함을 시연합니다.

복셀 렌더링과 대규모 씬

"Aokana: A GPU-Driven Voxel Rendering Framework for Open World Games" -- 2025. arXiv:2505.02017. 수백억 개의 복셀이 있는 씬을 위한 LOD와 스트리밍이 있는 희소 복셀 DAG. 이전 최신 기술 대비 9배 메모리 감소와 4.8배 빠른 렌더링. 게임 엔진 통합을 위해 설계됨.

절차적 지오메트리와 재표면화

"Real-time Procedural Resurfacing using GPU Mesh Shaders" -- Raad et al. (Eurographics 2025). 논문. 메시 셰이더를 써서 렌더 타임에 거친 컨트롤 메시에서 상세한 기하학적 표면을 생성합니다. 고해상도 지오메트리를 메모리에 저장하지 않는 동적 LOD를 가능하게 합니다.

지형 그림자

"Optimizing Terrain Shadows" -- AMD GPUOpen. 블로그. 대규모 지형을 위한 실용적 CSM 최적화. 캐스케이드 분할, GPU 효율적 섀도 맵 렌더링, 지형 특화 최적화를 다룹니다.

가상 지오메트리와 메시 최적화

"Nanite WebGPU" -- Scthe (2024). GitHub, Demo. UE5 Nanite 아키텍처의 완전한 브라우저 구현: meshlet LOD 위계, WGSL의 소프트웨어 래스터라이저, meshlet별 컬링, 빌보드 임포스터.

"Billions of Triangles in Minutes" -- Kapoulkine (2025). 블로그. 위계적 클러스터 LOD 생성을 위한 Meshoptimizer v1.0. 대규모 메시를 Nanite 스타일 클러스터 DAG로 효율적으로 처리합니다.

"Billboard Splatting (BBSplat)" -- 2024. arXiv:2411.08508. 신규 시야 합성을 위한 학습 가능한 텍스처 평면 프리미티브로 3D Gaussian Splatting 대비 17배 압축 달성.

지형 조명과 전역 조명

"Global Illumination in Once Human" -- GDC 2025. Session. 16km 오픈 월드를 위한 하이브리드 GI: 신경망 압축 프로브(69:1 비율), ML 기반 실내/실외 누출 해결, 동적 프로브 반응.

"GI with AMD FidelityFX Brixelizer" -- GDC 2024. 논문. 화면 공간 프로브가 있는 compute 기반 희소 거리장 캐스케이드. 하드웨어 레이트레이싱 불필요.

"Radiance Cascades" -- 2024. 블로그. 시간 누적 없이 캐스케이드 라디언스 구조를 쓰는 노이즈 없는 실시간 전역 조명.

레벨 디자인과 탐험

"PlotMap: Automated Layout Design for Building Game Worlds" -- 2023. arXiv:2309.15242. 지형에서 서사 공간 제약을 만족하는 AI 보조 POI 배치.

"Spatial Exploration Triggers" -- Purdue University (FDG 2022). 논문. 플레이어 탐험을 이끄는 네 가지 디자인 패턴: 극단 지점, 시각적 가림, 어울리지 않는 오브젝트, 공간 연결.

데이터 압축과 스트리밍

"Entropy-driven Progressive Compression of 3D Point Clouds" -- SGP 2024. 논문. 적응형 양자화가 있는 재귀적 공간 분할을 쓰는 레이트-디스토션 최적화 점진적 압축. 가변 대역폭 네트워크 스트리밍에 맞는 정제 스트림을 만듭니다.

인터랙티브 편집

"WebGPU SDF Editor" -- Nijhoff (2026). 프로젝트. 실시간 marching cubes, 불리언 연산, 부드러운 블렌딩, 옥트리 공간 분할이 있는 브라우저 풀 기능 SDF 모델링. 프리미티브당 112바이트.

강과 해안 생성

"Procedural River Drainage Basins" -- Patel (Red Blob Games). 프로젝트. 보로노이/삼각형 메시 모서리 분류를 쓰는 배수 우선 강 생성. 지형 고도를 배정하기 전에 강 위계를 구축합니다.

"NEWTS1.0: Numerical Model of Coastal Erosion by Waves and Transgressive Scarps" -- MIT (2024). 논문. 균일 후퇴와 파도 구동 침식을 쓰는 단순화된 해안 침식 모델. 실제 지형과 일치하는 곶, 만, 시 스택, 아치를 생성합니다.

더 읽을거리

• 브라우저 3D 오픈 월드 기술은 브라우저에서 멀티플레이어 크리에이터 월드의 전체 아키텍처를 다룹니다
• 2026년 Web 게임 기술 스택은 WebGL, WebGPU, WebAssembly 기초를 다룹니다
• Three.js + USDC 기술 보고서는 브라우저에서 3D 에셋 로딩에 관한 것입니다
• 프런티어 오픈소스 생성 AI 모델은 AI 생성 파이프라인을 위한 것입니다
• WebGPU 시작하기 -- GPU 구동 지형을 위한 compute 셰이더
• 게임 로직을 위한 Web Workers -- 지형 생성을 Worker로 오프로딩하기
• 게임 물리 라이브러리 -- 지형 상호작용과 하이트필드 콜라이더를 위한 물리
• 무료 게임 에셋을 찾는 곳 -- 지형 렌더링을 위한 텍스처와 머티리얼 소스

우리는 크리에이터를 공유 오픈 월드에 넣고 싶습니다. 로비가 아닙니다. 갤러리도 아닙니다. 사람들이 탐험하고, 짓고, 서로의 작업물을 우연히 마주칠 수 있는 살아있는 3D 공간입니다. 브라우저 탭에서 로드되고 머물 만한 장소처럼 느껴지는 무언가입니다.

이건 어려운 문제입니다. Skyrim과 The Witcher 3는 세계를 만드는 데 수억 달러를 썼고, 그러고도 수십 기가바이트짜리 디스크 용량과 전용 하드웨어에서 출시됩니다. 우리가 노리는 건 브라우저 탭, 수백 명 플레이어에 걸친 공유 상태, 그리고 크리에이터가 실제로 다시 빚을 수 있는 세계입니다.

이 가이드는 우리가 기술을 연구하며 찾아낸 것을 기록합니다. 오늘 가능한 것, 다가오는 것, 그리고 어떤 아키텍처가 우리를 거기로 데려다줄지를 다룹니다.

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

기술을 고르기 전에, 가장 성공한 두 오픈 월드가 실제로 어떻게 작동하는지 이해하면 도움이 됩니다. 그들의 기법은 의외로 브라우저 제약에 잘 들어맞습니다.

Skyrim의 Cell 시스템

Skyrim은 세계를 57x37개의 외부 cell 그리드로 나누며, 각 cell은 4096x4096 게임 단위(대략 59미터)입니다. 엔진은 어느 순간이든 플레이어 주변 5x5 cell 그리드를 로드합니다. 걸어가면 뒤쪽 가장자리의 cell이 언로드되고 앞쪽 가장자리의 cell이 스트리밍되어 들어옵니다. 내부 공간(던전, 건물)은 문 트리거로 로드되는 별도의 worldspace입니다.

이건 브라우저 월드에 그대로 적용됩니다. 전체 맵을 로드하지 않습니다. 플레이어 주변 동네를 로드하고 그가 움직임에 따라 청크를 교체합니다. 핵심 통찰은 이렇습니다. Skyrim은 멀리 있는 지형의 전체 디테일을 절대 보여주지 않습니다. 다중 해상도 방식을 씁니다.

Skyrim의 LOD(Level of Detail) 단계:

• 1-2 cell 안에서 전체 디테일(플레이어 바로 주변 영역)
• 중거리에서 단순화된 메시(물체는 작은 지오메트리를 잃음)
• 중거리 너머의 나무와 바위는 빌보드 임포스터
• 지형 LOD는 먼 풍경에 미리 구운 저해상도 메시를 사용
• 물체 페이드 거리는 물체별로 튜닝(풀이 가장 먼저 사라지고 건물이 가장 마지막)

Skyrim의 풍경은 cell당 32x32 정점 패치를 가진 하이트맵 기반 지형을 씁니다. 각 패치는 알파 맵으로 블렌딩한 다른 텍스처를 가질 수 있습니다. 이건 저장과 렌더링이 저렴합니다. 단일 cell의 지형 데이터는 메가바이트가 아니라 킬로바이트 단위로 측정됩니다.

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

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

The Witcher 3의 세계는 Skyrim보다 큽니다(전 지역 합쳐 대략 136 km2). 더 정교한 스트리밍 시스템을 씁니다. CD Projekt RED는 세계를 엄격한 그리드가 아니라 스트리밍 섹터로 나누는 커스텀 엔진(REDengine 3)을 만들었습니다.

각 섹터는 콘텐츠 레이어의 계층 구조를 담습니다:

• 지형은 4개의 LOD 레벨을 가진 패치로 스트리밍됩니다
• 식생은 GPU 인스턴싱과 거리 기반 컬링을 씁니다
• 정적 지오메트리(건물, 바위)는 지형과 독립적으로 스트리밍됩니다
• 게임플레이 오브젝트(NPC, 아이템, 트리거)는 퀘스트 상태와 근접도에 따라 로드됩니다

렌더러는 물리 기반 머티리얼을 사용하는 디퍼드 셰이딩을 씁니다. 특히 관련 있는 한 가지 트릭이 있습니다. The Witcher 3는 임포스터를 공격적으로 씁니다. 200미터 떨어진 나무는 가지와 잎이 있는 3D 모델이 아닙니다. 항상 카메라를 향하는 평평한 텍스처 쿼드입니다. 엔진은 이 임포스터를 여러 각도에서 미리 렌더링하고 카메라가 움직이면 교체합니다. 충분히 멀리 있어서 여러분은 전혀 눈치채지 못합니다.

월드 구성: The Witcher 3의 오픈 월드는 별도의 팀이 동시에 작업하며 레이어로 구축했습니다. 지형 팀은 풍경을 조각했습니다. 환경 아트 팀은 구조물을 배치했습니다. 퀘스트 팀은 트리거와 NPC 경로를 연결했습니다. 이 레이어 구성 시스템 덕분에 대규모 팀이 서로 방해하지 않고 작업할 수 있었습니다.

우리가 적용할 수 있는 것: 레이어 월드 구성(크리에이터 플랫폼에 중요), 먼 물체를 위한 임포스터 렌더링, 많은 광원을 위한 디퍼드 렌더링, 그리고 스트리밍은 콘텐츠 인식이어야 한다는 통찰(볼 수 없는 내부를 로드하지 말고, 가까이 있지 않은 NPC를 스폰하지 말 것)입니다.

Breath of the Wild의 화학 엔진

오픈 월드 디자인에 대한 닌텐도의 접근은 통상적인 공식을 뒤집었습니다. 세계를 스크립트 콘텐츠로 채우는 대신, 시스템적 규칙을 만들고 플레이어가 창발적 행동을 발견하게 했습니다. 불은 풀로 번집니다. 금속은 뇌우 속에서 전기를 전도합니다. 바람은 물체를 옮깁니다. 모든 것이 일관된 물리/화학 레이어를 통해 모든 것과 상호작용합니다.

이건 크리에이터 월드에 중요합니다. 세계 자체가 개별적으로 배치된 어떤 물체보다 더 흥미로울 수 있음을 시사하기 때문입니다. 크리에이터가 정적 메시를 배치하는 것만이 아니라 머티리얼 속성과 상호작용 규칙을 정의할 수 있다면, 세계는 창발적 행동을 얻고 아무도 명시적으로 설계하지 않은 영역조차 탐험할 가치가 생깁니다.

BotW에서 얻는 기술적 교훈:

• 비교적 낮은 폴리곤 수와 해상도(Switch 도크 모드에서 900p). 양식화된 셀 셰이딩 외관이 낮은 충실도를 가립니다. 오늘날 브라우저 월드는 비슷한 시각적 품질을 달성할 수 있습니다.
• 거리 렌더링은 수채화풍 스카이박스로 페이드되는 툰 셰이딩 안개를 씁니다. 렌더링이 저렴하고 실제로 아름답습니다. 이런 종류의 대기 원근은 프래그먼트 셰이더에서 사실상 공짜입니다.
• 세계는 대략 84 km2지만 듬성듬성합니다. 맵 대부분은 통행 가능한 지형이고 관심 지점이 그 위에 흩어져 있습니다. 밀집된 콘텐츠는 마을과 사당에 남겨둡니다. 이 "듬성듬성하지만 흥미로운" 접근은 The Witcher 3의 밀집한 Novigrad에 비해 에셋 요구량을 극적으로 줄입니다.
• 물리 물체는 상호작용을 결정하는 머티리얼 태그(나무, 금속, 음식, 폭발물)를 가집니다. 실제 규칙 수는 적지만(아마 20-30가지 상호작용 유형) 무한해 보이는 방식으로 결합합니다.

GTA V의 월드 레이어링

Los Santos에 대한 Rockstar의 접근은 다른 교훈을 줍니다. GTA V의 세계가 살아있는 느낌인 건 모든 NPC가 퀘스트를 가져서가 아니라 레이어드 앰비언트 시스템 덕분입니다.

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

크리에이터 월드에서 얻을 통찰은 앰비언트 생명이 박물관처럼 느껴지는 세계와 장소처럼 느껴지는 세계의 차이를 만든다는 점입니다. 단순한 행동(머리 위로 나는 새, 해안에 부딪히는 파도, 건물 사이를 걷는 NPC)만으로도 살아있는 세계의 환상을 만듭니다.

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

• 맵은 75 km2이며 공격적인 LOD와 속도 기반 스트리밍 시스템(빠르게 운전하면 걸을 때보다 더 멀리 로드)을 결합합니다.
• GTA Online은 이 세계에 30명의 플레이어를 동시에 넣습니다. 30명에서도 Rockstar는 공간 관심 관리가 필요하다는 걸 발견했습니다. 가까운 플레이어에 대해서는 자세한 업데이트를, 먼 플레이어에 대해서는 덜 빈번한 업데이트를 받습니다. 같은 원칙이 우리의 200명 플레이어 목표에 적용됩니다.
• GTA V의 에셋 파이프라인은 역사상 가장 효율적인 것 중 하나입니다. 극단적인 텍스처 압축, 메시 공유, 절차적 디테일 덕분에 전체 게임이 대략 80 GB에 들어갑니다. 건물 내부는 모듈식 부품을 광범위하게 재사용합니다.
• 게임은 정교한 임포스터 시스템을 사용하는데, 멀리 있는 건물은 실제로는 합성된 평평한 사진입니다. 전환 거리가 특정 시야각에 맞춰 튜닝되어 있어 플레이어는 전혀 눈치채지 못합니다.

Elden Ring의 심리스 오픈 월드

FromSoftware는 Elden Ring을 Dark Souls와 같은 엔진 위에 만들었지만 오픈 월드로 확장했습니다. 결과가 흥미로운 이유는 (Rockstar나 CD Projekt에 비해) 비교적 작은 팀이 어떻게 큰 오픈 월드를 만들 수 있는지 보여주기 때문입니다.

비결은 밀도 변화입니다. Elden Ring의 맵은 거대하지만(대략 79 km2) 넓은 구간이 흩어진 적과 관심 지점이 있는 개방 지형입니다. 밀집된 수작업 콘텐츠(Stormveil 성 같은 레거시 던전)는 오픈 월드에 박혀 있으며 Skyrim이 쓰는 것과 같은 내부/외부 분리를 사용합니다.

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

• 세계는 큰 타일로 스트리밍됩니다. 말 위에서는 아주 멀리 볼 수 있지만 먼 지형은 극도로 단순화됩니다. 가까이서는 디테일이 Dark Souls 3에 견줄 만합니다.
• 로딩 화면은 빠른 이동이나 특정 던전에 들어갈 때만 나타납니다. 오픈 월드 자체는 끊김 없이 스트리밍됩니다.
• 게임은 환경 에셋을 광범위하게 재사용합니다. 같은 나무 모델, 바위 형태, 폐허 조각이 맵 전체에 다른 배치로 나타납니다. 배치와 조명에 충분한 다양성이 있으면 반복은 눈에 띄지 않습니다. 이건 모듈식 조각 라이브러리가 무한한 다양성을 생성할 수 있는 크리에이터 월드에 그대로 적용됩니다.
• 멀티플레이어는 세션 기반(다른 플레이어를 여러분의 세계로 소환)이지 영속적이지 않습니다. 하지만 비동기 기능(메시지, 핏자국, 다른 플레이어의 유령)은 영속 서버의 네트워킹 부담 없이 공유 존재감을 만듭니다. 이런 앰비언트 멀티플레이어 기능은 브라우저 월드에 추가하기 저렴합니다.

No Man's Sky: 모든 것을 절차적으로

No Man's Sky는 절차적 생성의 극단적 사례입니다. 공유 시드에서 생성된 1800경 개의 행성이 있어, 그중 아무것도 서버에 저장하지 않고도 모든 플레이어가 같은 우주를 봅니다.

생성 파이프라인은 단계적으로 작동합니다. 은하 레벨 시드가 항성 위치를 결정하고, 항성 시드가 행성 수와 유형을 결정하며, 행성 시드가 지형 생성(다중 옥타브 노이즈), 바이옴 할당, 동식물 종, 색상 팔레트, 자원 분포를 구동합니다. 모든 것이 시드에서 결정론적으로 계산되므로, 같은 좌표를 방문하는 두 플레이어는 어떤 행성 데이터도 교환하지 않고 같은 행성을 봅니다.

No Man's Sky에서 얻는 기술적 교훈:

• 지형 생성은 노이즈 함수 스택을 가진 복셀 기반 마칭 큐브를 씁니다. 이는 하이트맵 지형이 표현할 수 없는 동굴, 오버행, 떠 있는 섬을 가능하게 합니다. 트레이드오프는 청크당 더 높은 연산 비용이지만, 결과는 시각적으로 더 흥미로운 지형입니다.
• 기지 건설 시스템은 우리가 구상하는 것에 가장 가깝습니다. 플레이어가 배치한 구조물은 서버에 영속하고 다른 플레이어에게 보입니다. 기지 데이터는 작고(위치와 회전을 가진 부품 목록), 누군가 행성을 방문할 때 온디맨드로 스트리밍됩니다.
• 게임은 무한한 다양성에도 불구하고 반복적인 콘텐츠로 초기에 비판받았습니다. 시드 기반 생성은 무한한 지형을 만들 수 있지만 놀라움은 제한적입니다. 교훈은 이렇습니다. 절차적 생성은 캔버스에는 통하지만, 어떤 장소가 설계되고 의도된 느낌을 주는 건 크리에이터가 배치한 콘텐츠입니다.
• Hello Games는 출시 몇 년 후 멀티플레이어를 추가했습니다. 최대 32명의 플레이어가 완전한 건설과 탐험을 하며 세션을 공유합니다. 네트워크 모델은 단순합니다. 한 플레이어가 호스트하고 다른 이들이 연결합니다. 영속 상태를 가진 브라우저 월드에는 서버 권위 모델이 더 낫지만, No Man's Sky는 공유 절차적 세계가 실현 가능함을 증명합니다.

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

Minecraft는 우리가 만들려는 것에 어떤 그래픽 AAA 타이틀보다 더 중요한 참고점입니다. 3억 장 판매. 세계는 무한히 생성되고, 완전히 파괴 가능하며, 멀티플레이어입니다. 크리에이터는 Minecraft에서 물체를 배치하는 데 그치지 않습니다. 지형 자체를 다시 빚습니다.

Minecraft에서 얻는 기술적 교훈:

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

AAA 오픈 월드 전반의 공통 패턴

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

공간 분할은 보편적입니다. cell(Bethesda), 섹터(CD Projekt), 청크(Mojang/Rockstar), 타일(FromSoftware) 무엇이든, 모든 오픈 월드는 공간을 로드 가능한 단위로 나눕니다. 어떤 엔진도 전체 세계를 메모리에 담으려 하지 않습니다.

모든 것이 다중 해상도. 지형, 메시, 텍스처, 심지어 오디오까지 모두 여러 품질 레벨을 가집니다. 받는 해상도는 얼마나 가까운지, 그리고 물체가 얼마나 중요한지에 달려 있습니다.

오클루전 컬링은 순수 삼각형 처리량보다 더 중요합니다. 볼 수 없는 것을 렌더링하지 않는 게 볼 수 있는 것을 최적화하는 것보다 더 많은 성능을 아낍니다. Skyrim은 단순한 거리 기반 시스템을 씁니다. The Witcher 3는 큰 오클루더(건물, 절벽)를 가진 소프트웨어 오클루전을 씁니다. UE5의 Nanite 같은 현대 엔진은 하드웨어 오클루전 쿼리로 이를 한 단계 더 밀고 나갑니다.

비동기 로딩은 전환을 숨깁니다. 이 게임들은 오픈 월드에 대해 로딩 화면을 보여주지 않습니다(빠른 이동이나 내부 전환에만). 백그라운드 스레드에서 콘텐츠를 로드하고, 병렬로 압축을 풀고, 새 콘텐츠를 점진적으로 교체합니다.

폴리곤 수보다 아트 디렉션. Skyrim은 2011년에 당시에도 수수했던 그래픽으로 출시했습니다. BotW는 태블릿급 칩에서 돌아가는데도 아름답습니다. Minecraft는 16x16 픽셀 텍스처를 쓰며 역사상 가장 시각적으로 알아보기 쉬운 게임 중 하나입니다. 브라우저 월드에는 이게 엄청나게 중요합니다. 낮은 충실도라도 잘 디렉팅된 아트 스타일은 기술적으로 앞섰지만 예술적으로 밋밋한 세계를 항상 이깁니다.

스크립트 콘텐츠보다 시스템적 디자인. BotW의 화학 엔진, Minecraft의 블록 상호작용, GTA V의 교통 시스템은 모두 단순한 규칙에서 창발적 행동을 만듭니다. 이건 만들기 더 저렴하고, 운영하기 더 저렴하며, 수작업 스크립트 시퀀스보다 더 많은 플레이어 이야기를 생성합니다. 크리에이터 월드에서 시스템적 디자인은 아무도 명시적으로 설계하지 않은 영역에서도 세계가 흥미롭게 유지된다는 뜻입니다.

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

렌더링: 브라우저가 실제로 할 수 있는 것은?

Three.js

Three.js는 기반입니다. 가장 큰 커뮤니티(GitHub 별 10만 개 이상), 가장 많은 예제, 가장 넓은 호환성을 가집니다. WebGL 2를 추상화하며 WebGPURenderer를 통해 실험적 WebGPU 지원을 제공합니다.

오픈 월드를 위해 Three.js가 주는 것:

• 식생, 바위, 반복 지오메트리를 위한 인스턴스드 렌더링(InstancedMesh)
• 내장 LOD 시스템(THREE.LOD가 거리에 따라 메시 교체)
• 물체별 자동 절두체 컬링
• 커스텀 BufferGeometry나 하이트맵 기반 PlaneGeometry를 통한 지형
• MeshStandardMaterial과 MeshPhysicalMaterial을 통한 PBR 머티리얼
• EffectComposer를 통한 포스트프로세싱(bloom, SSAO, 톤 매핑)
• 커스텀 코드로 캐스케이드 섀도우 매핑이 가능한 섀도우 맵
• 주요 에셋 포맷으로서의 glTF/GLB(작고, GPU 준비됨)

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

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

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

Babylon.js

Babylon.js는 또 다른 주요 경쟁자입니다. Microsoft가 후원하며, 오픈 월드라는 특정 문제에 대해 Three.js보다 깊은 내장 기능을 가집니다.

관련 내장 기능:

• 큰 씬의 효율적 컬링을 위한 옥트리 기반 씬 분할
• 대규모 인스턴스드 렌더링을 위한 Solid Particle System
• 내장 LOD와 멀티 텍스처 스플래팅을 가진 하이트맵 기반 지형
• 시각적 셰이더 생성을 위한 노드 머티리얼 에디터
• WebGPU 지원(Babylon이 더 일찍 투자했기에 Three.js보다 성숙)
• Havok 물리 통합(Wasm 컴파일, 프로덕션 품질)
• 점진적 로딩을 가진 glTF 스트리밍

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

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

트레이드오프: Babylon.js는 더 큰 라이브러리입니다(전체 빌드는 미니파이 후 약 1-2MB, Three.js는 약 600KB). 하지만 오픈 월드에서는 Three.js에 충분히 많은 커스텀 코드를 추가하게 되어 크기 차이가 무시할 만해질 가능성이 높습니다. Babylon에는 또한 자체 노드 머티리얼 시스템, 인스펙터, 개발 도구가 있어 반복을 빠르게 합니다.

Babylon.js 8.0(2025년 3월 출시)은 여기서 엔진 코어로서의 입지를 굳혔습니다. 이제 모든 코어 엔진 셰이더가 GLSL과 WGSL 양쪽으로 제공되어, WebGPU가 변환 레이어 없이 작동하고 WebGPU 번들은 예전의 대략 절반 크기입니다. 같은 릴리스는 Havok의 완전한 캐릭터 컨트롤러를 엔진에 들여왔고, 면적 광원, 재구축된 오디오 엔진, 가우시안 스플래팅 개선(SPZ와 압축 PLY 포맷, 구면 조화, 더 낮은 메모리/CPU 사용량)을 가져왔습니다.

PlayCanvas

PlayCanvas는 언급할 가치가 있습니다. 가장 프로덕션에서 검증된 웹 우선 3D 엔진이기 때문입니다. Snap, Facebook, 수많은 광고 클라이언트가 이걸로 복잡한 3D 경험을 출시했습니다. 엔진은 약 1MB로 빠르게 로드되며, 클라우드 에디터는 협업 월드 구축을 가능하게 합니다.

오픈 월드에 한정해서 PlayCanvas는 드로우 콜 최적화를 위한 배치 그룹, 내장 라이트매퍼, 가우시안 스플래팅 지원(포토그래메트리로 캡처한 현실 세계 환경에 관련)을 제공합니다. 런타임은 탄탄하고 모바일 브라우저에 잘 최적화되어 있습니다.

WebGPU: 성능 해방

WebGPU는 브라우저 오픈 월드의 방정식을 바꿉니다. 가장 중요한 두 가지 기능:

컴퓨트 셰이더는 GPU 측 지형 생성, 식생 배치, 파티클 시뮬레이션, 심지어 단순한 물리까지 가능하게 합니다. WebGL 세계에서는 이 모든 게 CPU의 JavaScript에서 실행됩니다. WebGPU로는 지형 패치를 전적으로 GPU에서 생성하고, LOD 전환을 GPU에서 계산하고, 컬링 패스를 GPU에서 실행할 수 있습니다. 이는 네트워킹, 게임 로직, 콘텐츠 스트리밍을 위해 CPU를 풀어줍니다.

간접 렌더링은 GPU가 컴퓨트 셰이더 출력에 기반해 무엇을 그릴지 결정하게 합니다. 드로우 콜 하나를 제출하면, GPU가 거리에 기반해 각 LOD 레벨에 대해 몇 개의 인스턴스를 렌더링할지 결정합니다. 이게 현대 엔진이 수백만 개의 풀잎이나 나무를 처리하는 방식입니다. 간접 렌더링(WebGL은 지원하지 않음) 없이는 CPU가 모든 것을 정렬하고 배치해야 하며, 이는 밀집 씬에서 병목이 됩니다.

WebGPU는 이제 모든 주요 브라우저에서 제공됩니다. Chrome과 Edge는 버전 113부터 지원했고, Firefox는 Windows(141)와 Apple Silicon macOS(145)에 추가했으며, Safari 26은 2025년 말 macOS, iOS, iPadOS, visionOS에 가져왔습니다. 이로써 모바일을 포함해(Chrome for Android와 Samsung Internet도 제공) 전 세계 지원율이 약 82%에 이릅니다. WebGPU가 활성화되지 않은 구형 브라우저와 기기를 위해 여전히 WebGL 2 폴백을 유지하겠지만, 격차는 빠르게 줄었습니다.

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

권장 렌더링 스택

데스크톱의 크리에이터를 겨냥한 브라우저 오픈 월드를 위해:

주력: Three.js 또는 Babylon.js, 가능한 곳에서는 WebGPU 렌더러, WebGL 2 폴백. Babylon은 내장 오픈 월드 프리미티브가 더 강합니다. Three.js는 더 큰 커뮤니티와 더 높은 유연성을 가집니다.

우리의 선택: 엔진 코어로는 Babylon.js. 내장 지형 LOD, 옥트리 컬링, Havok 물리(Wasm), 성숙한 WebGPU 지원 때문입니다. Babylon에 없는 곳에서는 Three.js 생태계 도구를 씁니다(예: 공간 쿼리용 mesh BVH). 모든 것을 커스텀 월드 스트리밍 레이어로 감쌉니다.

월드 스트리밍 아키텍처

이게 어려운 부분입니다. 브라우저 탭은 데스크톱에서 대략 2-4 GB 메모리(브라우저가 부과한 한계), 모바일에서 약 1 GB를 받으며 직접 디스크 접근이 없습니다. 모든 것이 네트워크를 통해 옵니다. 보이는 세계를 메모리에 유지하면서 플레이어가 움직이는 방향 바로 앞의 콘텐츠를 스트리밍하는 아키텍처가 필요합니다.

청크 기반 월드 그리드

Skyrim의 cell 시스템처럼, 세계를 규칙적인 청크 그리드로 나눕니다. 각 청크는 따로 로드, 렌더링, 언로드할 수 있는 독립 단위입니다.

청크 크기가 중요합니다. 너무 작으면 높은 오버헤드로 끊임없이 로드/언로드합니다. 너무 크면 각 청크 다운로드가 너무 오래 걸립니다. 일반적인 광대역 연결을 가진 브라우저 월드를 위해:

• 지면 레벨에서 64x64미터 청크
• 각 청크는 다음을 담습니다: 하이트맵 패치(2-4 KB), 텍스처 스플랫 맵(압축 16-32 KB), 인스턴스드 참조로서의 정적 메시(인스턴스 데이터 1-50 KB), 매니페스트로서의 크리에이터 배치 오브젝트(1-10 KB)
• 로드 반경: 전체 디테일로 5x5 청크(320m 시야), 중간 LOD로 9x9, 지형만으로 17x17
• 목표: 각 청크의 전체 디테일 데이터를 200 KB 미만으로, 그래서 5x5 동네는 5 MB 미만

점진적 로딩 파이프라인

청크에 관한 모든 것을 한 번에 로드하지 마세요. 우선순위 큐를 씁니다:

1. 지형 지오메트리 먼저(하이트맵만, 청크당 2-4 KB). 플레이어는 100ms 안에 지면을 봅니다.
2. 지형 텍스처(스플랫 맵, 저해상도 먼저 그다음 업그레이드). 지면은 200ms 안에 색을 가집니다.
3. 주요 구조물(건물, 큰 바위). 실루엣이 500ms 안에 나타납니다.
4. 디테일 오브젝트(식생, 작은 소품, 크리에이터 아이템). 세계는 1-2초에 걸쳐 채워집니다.
5. 고해상도 텍스처가 마지막에 업그레이드됩니다. 멀리 있는 건물의 텍스처가 1초 더 걸려도 아무도 눈치채지 못합니다.

이건 사람 눈이 작동하는 방식에 맞습니다. 우리는 빠진 지면과 빠진 큰 구조물을 알아챕니다. 빠진 풀은 알아채지 못합니다.

메모리 관리

브라우저 메모리는 유한하고 가비지 컬렉터는 여러분의 적입니다. 단 한 번의 GC 일시정지가 한 프레임 동안 60fps에서 10fps로 떨어뜨릴 수 있습니다.

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

텍스처 아틀라스는 드로우 콜과 메모리 단편화를 모두 줄입니다. 모든 지형 텍스처를 몇 개의 큰 아틀라스로 묶습니다. 크리에이터가 업로드한 텍스처를 서버에서 청크별 아틀라스로 묶어 단일 이미지로 스트리밍합니다.

지오메트리 압축을 Draco나 Meshopt로 하면 다운로드 크기를 5-10배 줄이고, 압축 해제는 Web Worker에서 실행되어 메인 스레드를 막지 않습니다. 지형에 한정하면, 양자화된 하이트맵(단순 델타 인코딩으로 압축한 16비트 값)이 어떤 범용 메시 포맷보다 작습니다.

ArrayBuffer 소유권 이전은 worker와 메인 스레드 사이의 복사를 피합니다. worker가 메시 압축을 풀면, 전송 가능 객체와 함께 postMessage를 사용해 버퍼를 메인 스레드로 복사 없이 이전합니다.

에셋 전달

정적 월드 데이터를 위한 엣지 캐싱이 있는 CDN. 자주 바뀌지 않는 지형 청크, 베이스 메시, 텍스처 아틀라스는 공격적으로 캐싱해야 합니다(Cache-Control: max-age=31536000, immutable).

콘텐츠 주소 지정 스토리지는 각 에셋 버전이 URL에 고유한 해시를 갖는다는 뜻입니다. 크리에이터가 청크를 수정하면 새 버전은 새 해시를 얻고, 여전히 보고 있는 사람을 위해 옛 버전은 캐시에 남습니다. 캐시 무효화가 필요 없습니다.

Basis Universal 압축이 있는 KTX2 텍스처. 이들은 기기가 지원하는 어떤 GPU 포맷으로든 압축이 풀립니다(BC7, ASTC, ETC2, 또는 RGBA 폴백). 1024x1024 지형 텍스처는 비압축 4 MB에서 KTX2로 대략 150 KB가 됩니다. 수천 개의 고유한 텍스처를 가진 세계에는 이 압축이 실현 가능과 불가능의 차이입니다.

모든 3D 에셋을 위한 glTF Binary(GLB). 3D의 JPEG입니다. 모든 브라우저 엔진이 로드하고, 작으며, 텍스처, 머티리얼, 애니메이션을 단일 파일에 임베드할 수 있습니다. 메시 압축에는 Draco나 Meshopt 확장을 씁니다. 크리에이터가 업로드한 에셋은 서버 측에서 최적화된 GLB로 처리된 후 세계에 들어옵니다.

멀티플레이어 네트워킹

수백 명의 크리에이터를 같은 세계에 넣으려면 실시간 이동, 영속 월드 상태, 크리에이터 편집을 녹아내리지 않고 처리하는 네트워킹 아키텍처가 필요합니다.

서버 아키텍처

월드 상태를 위한 권위 서버. 브라우저는 신뢰할 수 없습니다. 모든 의미 있는 동작(물체 배치, 지형 수정, 청크 간 이동)은 서버 측에서 검증됩니다. 클라이언트는 로컬에서 예측하고 서버 상태와 조정합니다.

공간 샤딩은 세계를 여러 서버 인스턴스에 나눕니다. 각 샤드는 월드 그리드의 직사각형 영역을 소유합니다. 플레이어 밀도가 변하면 샤드는 분할되거나 병합될 수 있습니다. 이게 EVE Online이 한 우주에서 수천 명의 플레이어를 다루는 방식이며, 더 작은 규모에서도 같은 원칙입니다.

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

서버를 위한 기술 옵션:

우리의 맥락(Cloudflare 인프라): Durable Objects가 자연스럽게 들어맞습니다. 각 월드 청크는 그 청크 콘텐츠의 권위 상태를 보유하는 Durable Object가 됩니다. 플레이어는 현재 청크를 담당하는 Durable Object에 WebSocket으로 연결합니다. 인접 청크로 이동하면 그 청크의 DO에 연결합니다. Durable Objects는 상태를 디스크에 자동으로 영속하므로 월드 데이터가 재시작을 넘어 살아남습니다.

클라이언트-서버 통신

신뢰성 있는 순서 보장 메시지(채팅, 월드 편집, 인벤토리, 게임 상태)를 위한 WebSocket. 플레이어가 볼 수 있는 활성 샤드당 연결 하나(보통 1-4개 연결).

신뢰성 없고 순서 없는 메시지(플레이어 위치, 애니메이션, 일시적 효과)를 위한 WebRTC DataChannel. WebRTC는 P2P가 가능하지만, 많은 플레이어가 있는 세계에서는 N² 연결을 피하기 위해 SFU(Selective Forwarding Unit)를 거쳐 실행합니다. Cloudflare Calls나 LiveKit이 SFU 역할을 할 수 있습니다.

상태 동기화는 델타 압축을 씁니다. 서버는 각 클라이언트가 본 것을 추적하고 변경 사항만 보냅니다. 크리에이터 월드에서 이건 특히 중요합니다. 월드 상태(어떤 물체가 존재하는지, 어디에 있는지, 어떤 속성을 가졌는지)는 플레이어 위치보다 훨씬 덜 자주 변하기 때문입니다. 월드 상태 업데이트는 2-5 Hz로 보내고 플레이어 위치는 20-30 Hz로 업데이트할 여유가 있습니다.

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

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