긴 설명 대신 목업 한 장과 고친 바위 하나를 보여 준다

이번 주에는 바이브게임 커뮤니티를 손봤어요. 글쓰기 칸을 맨 위로 올리고, 게임을 올린 직후에 친구에게 바로 알릴 수 있는 버튼도 달았어요. 열심히 만들어 올렸는데 아무도 모르고 지나가면 아쉬우니까요.

이번 호는 AI에게 방향을 알려 주는 방법 이야기예요. 긴 설명 대신 목업 한 장, 네모 상자 레벨 하나, 직접 고친 바위 하나를 보여 주는 두 제작자를 모았어요. Claude Opus 5.5로 브라우저 3D 게임을 만들어 출시한 Chong-U와, 폴란드의 산을 게임 속에 옮기고 있는 Can It Code?예요.

만들기 전에 그림부터 맞춘다

Chong-U는 고압 세척기로 집 앞을 청소하는 캐주얼 게임을 만들었어요. 시간 안에 구역을 다 치우면 이기고, 화분에 물을 뿌리거나 집주인의 반려동물을 맞히면 지는 게임이에요. X에 올린 뒤 천 명 가까운 사람이 평균 2분쯤 플레이했대요. 게임 엔진 없이 WebAssembly와 WebGPU로 만들어서 설치 없이 브라우저에서, 휴대폰에서도 바로 돌아가요.

그는 첫 프롬프트 끝에 꼭 한마디를 붙여요. "이해했어?" 바로 만들게 하지 않고, AI가 방향을 제대로 잡았는지 먼저 확인하는 거예요. 그다음 이미지 생성 모델로 게임 화면 목업을 여러 장 뽑아요. PC와 휴대폰에서 어떻게 보일지까지요. 목업을 보며 스타일을 정하고 나서야 만들기 시작해요.

그의 말을 옮기면 이래요. "원샷으로 만든 게임은 모델 성능을 보여 주는 데는 좋아요. 하지만 내 게임을 만들고 싶다면 원샷으로 만들면 안 돼요." 게임은 디테일이 전부이고, 디테일은 처음에 맞춰 둘수록 나중에 덜 고친다는 뜻이에요.

캐릭터, 배경, 핵심 재미를 따로 만들고 동시에 돌린다

방향이 정해지면 일을 셋으로 나눠요. 캐릭터 모델, 배경 소품, 그리고 핵심 재미를 확인할 회색 상자 레벨이에요. 캐릭터는 앞, 옆, 뒤 모습을 그린 턴어라운드 시트를 만들어 3D 모델 생성 도구에 넣고, Blender에서 뼈대를 심어 움직이게 해요. 배경은 참고 그림을 주고 나무와 자동차를 따로 만들어요.

그동안 다른 에이전트는 네모 상자만 있는 레벨에서 물줄기가 시원하게 뿜어지는지만 만져요. 그림이 없어도 손맛은 먼저 확인할 수 있거든요. 그는 이걸 게임 회사에서 아티스트, 게임플레이 담당, 배경 아티스트가 동시에 일하던 방식이라고 설명해요. 이제는 그 팀을 에이전트로 꾸릴 수 있는 거예요.

비용이 궁금한 분도 많을 거예요. 처음부터 출시까지 약 6시간 반이 걸렸고, API 요금으로 치면 233달러쯤이었대요. 그는 Claude Max 요금제 안에서 썼고, 프롬프트를 던져 두고 다른 일을 하다가 끝나면 확인하는 식으로 일했어요.

바이브코딩으로 첫 게임을 만든다면 이렇게 줄여 볼 수 있어요. 그림은 나중에 넣기로 하고, 네모와 동그라미로 누르는 순간이 재밌는지부터 만들어 보세요. 재미가 없으면 그림이 아무리 예뻐도 한 판으로 끝나요.

처음 하는 사람을 위한 첫 판을 따로 설계한다

출시 직전에 그가 가장 공을 들인 건 첫 판이에요. 설명서를 읽게 하는 대신, 첫 레벨에서는 넓게 퍼지는 물줄기만 쓰게 하고, 두 번째 레벨에서 기름 얼룩이 나오면 강한 물줄기로 바꾸는 법을 배우게 하고, 세 번째 레벨에서 시간 제한을 붙였어요. 레벨을 하나씩 넘기면 규칙을 저절로 알게 되는 구조예요.

하나 더 있어요. 모든 게임에 하늘 배경 그림(스카이박스) 한 장을 넣으라는 거예요. 회색 배경 대신 그림 한 장만 둘러도 게임이 훨씬 완성돼 보인대요. 오늘 바로 따라 할 수 있는 팁이에요.

잘 된 하나를 직접 고치고 "나머지도 이렇게"라고 말한다

두 번째 영상은 스팀 출시를 목표로 폴란드 베스키디 산맥을 게임에 옮기는 개발 일지예요. 실제 지형 데이터를 받아 산 모양을 만들고, OpenStreetMap에서 길과 개울, 숲의 위치를 가져와요.

나무를 만드는 방식이 인상적이에요. 먼저 GPT와 원하는 스타일을 이야기하며 참고 그림을 뽑고, 마음에 드는 나무 하나만 빈 배경에 다시 그려 달라고 해요. 그 그림을 가장 강한 모델에 주면 모델이 Blender용 파이썬 스크립트를 써서 나무를 만들어요. 줄기를 가늘게, 가지를 넓게, 숫자 몇 개만 바꿔 다시 돌리면 돼요. 전부 코드라서 버전 관리도 돼요.

여기에 검사 담당 에이전트를 하나 붙여요. 렌더링 결과를 참고 그림과 비교해 통과인지 실패인지만 말하게 하고, 실패하면 최소 두 군데를 고쳐 다시 돌려요. 통과했을 때만 사람이 봐요. 사람은 마지막 판단만 하는 거예요.

바위를 놓을 때는 더 간단한 방법을 써요. 에이전트가 만든 바위 하나가 둑 위에 떠 있자, 에디터를 열어 그 바위 하나만 직접 넓고 납작하게 고쳤어요. 그리고 "나머지 바위도 이렇게 해 줘"라고 했죠. 무엇을 바꾸고 무엇을 그대로 둘지 예시 하나로 보여 주는 게 긴 설명보다 잘 통한대요.

무거운 계산은 미리 해 두고, 게임은 읽기만 한다

이 영상에서 가장 멋진 장면은 강이에요. 물살이 계단에서는 빠르고, 웅덩이에서는 느리고, 섬을 돌아 흘러요. 그런데 게임은 플레이 중에 물을 계산하지 않아요. 강바닥을 체스판처럼 잘게 나누고, 칸마다 물의 깊이와 방향만 미리 계산해 작은 파일 하나에 저장해요. 게임은 그 파일을 읽기만 하니 거의 부담이 없어요. 미리 계산하는 데도 1분이면 끝나요.

웹 게임을 만드는 빌더에게도 그대로 통하는 이야기예요. 휴대폰에서 버벅이는 효과가 있다면, 매 순간 계산하지 말고 미리 만들어 둘 수 있는지 AI에게 물어보세요.

다음 작업에 붙여 볼 네 가지

두 사람의 방법을 첫 게임에 옮기면 이렇게 돼요.

첫째, 첫 프롬프트 끝에 "이해했어? 만들기 전에 화면 목업부터 보여 줘"를 붙여 보세요. 둘째, 그림 없이 네모와 동그라미로 핵심 조작 하나가 재밌는지부터 확인하세요. 셋째, 마음에 안 드는 부분이 여러 개라면 하나만 직접 고치고 "나머지도 이렇게"라고 말해 보세요. 넷째, 첫 판은 튜토리얼 대신 단계별로 숙지할 수 있도록 가르치세요. 규칙 하나에 레벨 하나면 충분해요.

만든 게임과 웹 서비스는 바이브게임에 올려 주세요. 이번 달 만든 것의 게임 부문 1~3위는 다음 달 플레이 홈에 이달의 게임으로 걸려요. 여러분이 써 본 방법도 커뮤니티 팁 게시판에 나눠 주시면 다음 뉴스레터에서 소개할게요.

이번 호에서 다룬 영상은 Chong-U(AI Oriented Dev)의 "I Built (And Shipped) a 3D Game With Claude Opus 5.5"와 Can It Code?의 "I Stole a Mountain for My Game"이에요.