이 글의 목차
Shopify 판매자가 주문 하나를 창고에서 처리해 보고, 주문이 바뀌면 어떤 일이 생기는지 살펴본 뒤, 스토어에 유용한 무언가를 얻어 가면 좋겠다고 생각했습니다. 그렇게 탄생한 것이 무료로 영어로만 제공하는 브라우저 게임 Warehouse Rush입니다.
상품을 피킹하고, 키트를 조립하고, 소포를 포장하고, 밴에 적재하며, 모은 돈을 투자합니다. Maple Depot는 Riverside Warehouse와 Aurora Fulfillment로 확장됩니다. 게임에는 제안을 선택하고 테스트하는 실용 가이드 The Nine-Figure Upsell Playbook이 담겨 있습니다.
AI 코딩 에이전트로 3D 브라우저 게임을 만들고 싶다면 이 글이 저희의 개발 기록입니다. 개발 중 바뀐 부분을 포함해 Three.js, Codex, Claude, Higgsfield, ElevenLabs를 다룹니다.
위 이미지는 홍보용 메인 일러스트입니다. 아래 창고 스크린샷은 실제로 플레이할 수 있는 세계를 보여줍니다.
Shopify 앱이 창고 게임을 만든 이유
플레이 자체가 주문 흐름을 설명하고, 보상이 판매자의 실행을 돕는 리드 확보용 콘텐츠를 만들고 싶었습니다.
Revize는 구매자가 주문 처리 전에 조건에 맞는 Shopify 주문을 수정할 수 있게 합니다. 운영 측면에서 흥미로운 질문은 고객이 주문을 바꾼 시점부터 창고가 배송하는 시점 사이에 무슨 일이 생기는가입니다. 3PL이 이미 피킹 중인 주문에 관한 가이드에서 실제 조율 과정을 다룹니다.
게임은 이를 작은 규모로 눈에 보이게 만듭니다. 상품은 특정 주문에 속합니다. 변경된 주문은 출고 전에 수정하고 최신 라벨을 붙여야 합니다. 포장, 재고, 배송은 서로 연결된 작업입니다.
플레이북은 이 예시를 본 뒤 판매자가 할 일을 제시합니다. 표지에는 “선택 / 제작 / 검증 / 결정”과 “9자리 매출 규모 브랜드와 일하며 배운 실용적인 교훈”이 적혀 있습니다. 16페이지에 걸친 여섯 개 미션은 유용한 조합 선택, 제안 제작 및 배치, 의도한 제안의 우선 적용, 결제 입증, 결과 진단, 자체 성과표에 따른 결정을 다룹니다.
이메일과 스토어 URL로 게임에 들어가세요. 첫 소포를 배송하면 업셀 플레이북을 받습니다. 이 게임은 주제를 직접 체험하며 접하는 입문 과정이며, 보고할 만한 측정된 직장 교육 성과는 없습니다.
기술 구성과 중요한 경계
Three.js는 창고를 그리고, TypeScript는 규칙을 담으며, Vite는 독립적인 브라우저 프로젝트를 패키징합니다.
게임은 웹사이트의 Astro 프로젝트와 별도로 자체 소스, 잠금 파일, 테스트, 에셋을 갖고 있습니다. Vite는 정적 프로덕션 빌드 방식에 맞춰 상대 에셋 경로를 사용하는 브라우저 번들을 만듭니다.
핵심 구분은 시뮬레이션과 화면 표현 사이에 있습니다.
tycoon-model.ts는 주문, 수량, 소포 소유 관계, 변경 버전, 작업자, 현금, 저장 데이터 검증을 담당합니다.tycoon-world.ts는 해당 상태를 그리고 장면의 시각 리소스를 관리합니다.tycoon-entry.ts는 입력, 메뉴, 저장, 오디오, 프레임 루프를 연결합니다.
애니메이션 콜백은 재고나 돈을 지급하지 않습니다. 날아가는 노트는 모델 변경을 알려 주는 피드백입니다. 이 구분을 유지하면 시각 효과가 빠진 것과 상품이 사라진 것을 다르게 다룰 수 있습니다.
플레이 카메라는 Three.js 원근 카메라인 THREE.PerspectiveCamera이며, 렌더러의 직교 카메라는 태양 그림자에만 사용됩니다.
Rapier는 업스트림 라이선스 이력에 등장합니다. 현재 타이쿤은 이를 가져오지 않으며 충돌, 경로 탐색, 정해진 범위 안의 소품 움직임을 직접 구현합니다.
코드로 만든 부분과 생성 도구로 만든 부분
창고와 움직이는 캐릭터는 코드로 제작했고, 일부 이미지, 컨베이어 모델, 포털 영상, 효과음은 생성 도구로 만들었습니다.
게임을 어떻게 만들었는지 설명할 때 이 구분이 중요합니다. 초상화, 캐릭터 리그, 영상은 서로 다른 결과물이며 각각 다른 통합 작업이 필요합니다.
| 부분 | 기록된 출처 | 게임 안에 남는 작업 |
|---|---|---|
| 창고, 상품, 현재 캐릭터 | 원본 Three.js 지오메트리와 로컬에서 그린 Canvas 텍스처 | 배치, 이동, 운반, 기계 장치, 상태 기반 애니메이션 |
| 초기 포스터 및 portrait-v2 세트 | 내장 image_gen / OpenAI 이미지 생성, ASSETS.md에 기록됨 |
에셋 준비와 인터페이스 배치 |
| 출고 컨베이어 | 소유자의 Higgsfield 3D Jutsu 장면을 GLB로 내보냄 | 정적 소품 통합. 소포와 상호작용은 게임이 계속 담당 |
| 이전 콘크리트 바닥 | 소유자의 Higgsfield PBR 텍스처 세트 | 과거 에셋. 이후 바닥 표현은 코드로 제작 |
| 포털 | 소유자 계정의 Higgsfield 에셋과 Kling 3.0 클립 | 표지 교체, 루프 편집, 인코딩, 진입 타이밍 |
| 게임플레이 샘플 모음 | ElevenLabs eleven_text_to_sound_v2 |
로딩, 믹싱, 이벤트 연결, 합성음 대체 처리 |
에셋 이력에는 중간 단계의 일러스트 캐릭터도 포함되어 있습니다. Claude Opus가 Canvas2D 아틀라스와 컷아웃 애니메이션을 만들고 Codex가 통합했습니다. 현재 인계 문서에 따르면 그 평면 레이어는 이후 제거되었고 현재 캐릭터는 Three.js 지오메트리를 사용합니다. 아틀라스는 개발 이력의 일부이며 현재 캐릭터 렌더러는 아닙니다.
현재 가로형 및 세로형 메인 일러스트는 2026년 10월 24일 Codex gpt-6-astra가 내장 OpenAI 이미지 생성 도구로 만들었습니다. 소유권이 있고 승인된 게임 내 “Cozy Soft” 렌더를 스타일 참조로, 소유권이 있는 v2 캐릭터 초상화를 정체성 참조로 사용했습니다. 배포 파일은 WebP 인코딩본이며 프롬프트는 art-src/menu-v3/jobs.tsv에 보관되어 있습니다. 아래 초상화는 문서에 기록된 생성형 v2 세트에 속합니다.
개발 이력을 잃지 않고 Codex와 Claude를 활용한 방법
유용했던 에이전트 작업 방식은 구체적인 일을 배정하고 방향 설정, 구현, 검증의 기여 주체를 남기는 것이었습니다.
기록으로 확인되는 기여는 구체적입니다. ASSETS.md는 실행 가능한 플레이북의 편집 방향 설정을 Astra와 Claude Opus의 작업으로 기록합니다. Sol은 콘텐츠, 공용 렌더러, 게임 메뉴 표시를 구현했습니다. 일러스트 캐릭터 이력에는 제작자로 Claude Opus, 통합자로 Codex가 명시되어 있습니다. 기록에는 Claude Opus가 제 창고 메인 일러스트를 기준으로 해당 캐릭터를 다듬은 내용도 있습니다.
확장 검증 기록에는 승인된 수정 후 Opus가 나중에 마무리 검증을 한 내용이 있습니다. 이 항목들은 실제 기여를 설명하며, 한 에이전트가 게임의 모든 부분을 만들거나 검토했다는 뜻은 아닙니다.
이 기록을 바탕으로 재사용할 수 있는 제 작업 방식은 다음과 같습니다.
- 시각 작업을 요청하기 전에 동작과 그 상태의 관리 주체를 정의합니다.
- 구현 작업에 구체적인 모듈 또는 에셋과 눈으로 확인 가능한 승인 조건을 부여합니다.
- 이전 저장 데이터, 리소스 정리, 실패 경로를 포함해 통합을 검토합니다.
- 결과 버전의 근거를 보관합니다. 이전 실험이 대체되면 과거 기록임을 표시합니다.
마지막 단계에서 실제 문서 불일치를 발견했습니다. 렌더러가 바뀐 뒤에도 옛 캐릭터 기법이 문서에 남을 수 있습니다. 개발 과정 소개도 인계 문서만큼 주의가 필요합니다.
생성한 미디어에도 편집과 런타임 설계가 필요했습니다
생성 도구는 원본 소재를 제공했고, 후처리와 이벤트 연결이 이를 브라우저에서 쓸 수 있게 만들었습니다.
Higgsfield 컨베이어 내보내기 과정에서는 실제 장면에서 샘플 소포, 카메라, 조명을 제거합니다. 그렇지 않으면 전시용 모델이 게임의 소포를 중복시키거나 자체 조명을 가져올 수 있습니다. 컨베이어는 정적 에셋으로 남고 이동하는 상품은 시뮬레이션이 관리합니다.
포털에는 다른 정리 작업이 필요했습니다. 기록된 제작 과정에서는 Higgsfield/Kling 영상을 사용하고, 실제 플레이북 표지를 영상에 투사하고, 앞으로 이동하는 루프를 만듭니다. 움직이는 입구 밖의 그려진 구조물은 고정해 텍스처가 일렁이는 현상도 제거합니다. 포스터 프레임과 최종 인코딩본은 별도로 확인합니다.
진입에도 기능상 계약이 있습니다. 리드 접수와 게임 준비가 모두 성공해야 합니다. 포털은 실제 게임에서 프레임 렌더링을 확인한 뒤에만 사라집니다. 영상이 끝났다고 창고가 입력을 받을 준비가 되었다는 뜻은 아닙니다.
사운드의 경우 현재 인계 문서에는 eleven_text_to_sound_v2로 생성해 배포한 ElevenLabs 효과음 23개가 기록되어 있습니다. ElevenLabs는 게임과 인터랙티브 미디어용 텍스트 기반 효과음 생성을 문서로 안내합니다. 저희 샘플은 피킹, 봉하기, 밴 출발, 업그레이드 완료 같은 동작을 다룹니다.
이전 기록에는 생성한 효과음이 24개라고 되어 있습니다. 인계 문서는 배포 수량의 이유를 설명합니다. ui-tap은 생성했지만 중앙 버튼 클릭 훅이 없어 제외했습니다.
브라우저는 오디오 재생을 허용하는 사용자 동작 후 샘플 모음을 불러와 디코딩합니다. 이벤트가 샘플을 호출하고, 사용할 수 없는 샘플은 합성음으로 대체합니다. 런타임에는 ElevenLabs API 호출이나 키가 필요하지 않습니다. 음악과 작은 재질 효과음은 코드로 합성하며, 음악과 효과음 설정은 따로 저장됩니다.
성능 작업은 레이아웃과 로딩에서 시작했습니다
3D 장면의 처리 예산과 함께 브라우저의 반복 레이아웃 작업을 없애고 필수 에셋 용량을 줄이는 것이 중요했습니다.
기록된 docs/perf-report.md는 작업대 버튼 위치 계산 안에서 캔버스를 반복 측정하는 문제를 지적합니다. 프레임 중 스타일을 쓴 뒤 getBoundingClientRect()를 읽고 있었습니다. 캔버스 사각 영역을 캐시하고 크기 변경 시 무효화해 해당 반복 레이아웃 작업을 없앴습니다.
해당 보고서에는 적응형 품질, 병렬 에셋 가져오기, 정적 소품 병합도 기록되어 있습니다. 프레임 시간이 계속 예산을 넘으면 품질 단계가 먼저 픽셀 비율을 낮추고, 이어서 그림자와 파티클을 줄입니다.
규모를 설명하자면, 보고서의 테스트 빌드에는 JavaScript 번들 1,072 KB, gzip 압축 시 308 KB가 나옵니다. Maple 초반 구간의 휴대전화 뷰포트 항목에는 그림자 패스를 포함해 드로 콜 59회가 기록되어 있습니다. 이는 Apple Silicon의 헤드리스 Chrome에서 20초 표본으로 얻은 과거 측정값입니다. 출시 빌드를 새로 감사한 결과도, 실제 휴대전화에서 측정한 값도 아닙니다.
보고서 이후 컨베이어는 변경되었습니다. ASSETS.md에는 지오메트리 단순화나 텍스처 없이 meshopt 압축으로 641,960바이트에서 51,044바이트로 줄였다는 기록이 있습니다. 로더는 압축된 GLB를 위해 Three.js의 MeshoptDecoder를 등록합니다. 이전 보고서의 압축 전 컨베이어 크기를 현재 크기로 제시해서는 안 됩니다.
앞으로 빌드할 때도 장면이 매 프레임 제출하는 작업과 첫 플레이 가능 프레임 전에 브라우저가 가져와야 하는 데이터를 모두 확인하겠습니다.
테스트는 소포의 전체 여정을 따라갔습니다
모델 테스트는 소유 관계와 수량·금액 정합성을 확인하고, 브라우저 점검은 화면에 표시되는 여정과 조작을 다뤘습니다.
Node 테스트 모음은 시뮬레이션, 안내형 학습, 보상, 저장 상태, 컨트롤러 동작을 다룹니다. 더 긴 여정 검증기는 실제 모델 경로를 따라가며 업그레이드를 획득하고, 접수한 작업을 끝낸 뒤 다음 창고로 이동합니다. 확인 지점에서 재고, 돈, 저장과 다시 불러오기를 점검합니다.
확장 검증에는 직접 성과를 쌓아 완료한 48건 배송 캠페인과 Riverside 및 Aurora 경로에서 총 배송 300건에 도달한 연속 실행이 기록되어 있습니다. 이는 정확성 검증 실행이지 플레이어 수나 초보자가 해당 챕터를 무리 없이 완료한다는 근거가 아닙니다.
브라우저 검증은 모델 여정으로 볼 수 없는 것을 더합니다. 주문서가 화면에 들어가는지, 대화상자가 스크롤되는지, 조작부에 계속 접근할 수 있는지, 포털 뒤에 실제 프레임이 나타나는지 확인합니다. 기록된 Chrome 점검은 데스크톱 및 휴대전화 크기 뷰포트를 사용하며 동작 줄이기 설정과 실패 상황도 포함합니다.
설명을 위한 테스트 사례로 머그잔 두 개와 노트 한 권을 배송하는 선물용품 스토어를 생각해 보세요. 피킹 후 노트 요구 사항을 바꿉니다. 유용한 검증은 최종 소포가 현재 주문 및 라벨과 일치하고, 영향을 받지 않은 상품도 빠짐없이 계산되는지 확인하는 것입니다. 애니메이션이 성공했다는 사실만으로는 이를 입증할 수 없습니다.
조립에서도 이 구분이 드러납니다. 스크린샷은 곰 인형 선물 세트 미니게임을 보여주지만, 화면 표현은 여전히 소포의 실제 내부 내용물과 일치해야 합니다.
사람이 내린 결정과 다음에는 바꿀 점
문서를 더 일찍 대조해 맞추고, 장식을 추가하기 전에 실제 기기 테스트를 우선하겠습니다.
개발 기록에는 생성 결과만으로 결정할 수 없는 사람의 선택이 담겨 있습니다. 저는 소유권이 있는 참조 이미지를 제공했습니다. 포털 검토에서는 글자와 가장자리 결함이 있는 업스케일 결과를 반려했습니다. 미디어 제작 과정은 파일 수치뿐 아니라 표지 내용의 가독성과 움직임도 확인합니다. 이는 내보내기 성공의 결과가 아니라 승인에 관한 결정입니다.
현재 인계 문서에도 구체적인 한계가 남아 있습니다. 경로를 따라가는 배송은 계속 작동하지만, 수동으로 걸을 때 확장된 출고 구역 가장자리의 주차된 트럭과 겹칠 수 있습니다. 보고된 휴대전화 지연 및 시각적 오류 문제에는 재현에 필요한 기기 정보가 없습니다. 데스크톱 뷰포트 점검으로 기기 성능이나 해당 제보를 해결할 수는 없습니다.
진행 상황은 해당 브라우저에만 저장됩니다. 클라우드 저장 동기화나 멀티플레이는 없습니다. 파트너 제안은 아직 미정입니다. 이런 한계도 완성된 화면과 함께 개발 과정에 포함되어야 합니다.
판매자에게 이 게임은 하나의 예시입니다. 실제 판매 절차에는 구매 후 업셀 배치 가이드를 활용하세요. Revize의 업셀 기능에는 Pro가 필요합니다. 자체 제안 여정을 테스트 주문으로 확인하세요.
이번 주에 할 일
창고를 확장하거나 에셋을 더 의뢰하기 전에 주문 처리의 완전한 흐름 하나를 만들고 검증하세요.
- 주문, 재고, 소포, 보상 상태의 관리 주체를 적으세요.
- 눈으로 볼 수 있는 하나의 여정에서 피킹, 포장, 출고가 작동하게 하세요.
- 생성한 각 에셋의 출처, 처리 과정, 현재 용도를 기록하세요.
- 다시 불러오기, 로딩 실패, 동작 줄이기를 확인한 뒤 실제 휴대전화에서 테스트하세요.
Warehouse Rush를 플레이하며 결과를 살펴보세요. 이메일과 스토어 URL로 들어가 첫 소포를 배송하고 The Nine-Figure Upsell Playbook을 받으세요. 여섯 개 미션은 판매자의 과제를 이름이 붙은 제안, 테스트한 결제 여정, 환불 없이 남은 자체 추가 상품과 비용에 근거한 결정으로 이어 줍니다.
자주 묻는 질문
아래 답변은 배포된 게임과 이전 실험, 기록된 테스트 조건을 구분합니다.
AI 코딩 에이전트로 3D 브라우저 게임을 만들 수 있나요?
네, 하지만 구현에는 여전히 명확한 규칙, 통합 작업, 검증이 필요합니다. Warehouse Rush는 시뮬레이션과 렌더러를 분리하고, 기록된 작업에 에이전트를 활용하고, 전체 여정을 점검합니다. 생성한 이미지로 재고, 소포 소유 관계, 저장된 진행 상황이 올바르게 작동한다고 입증할 수는 없습니다.
Warehouse Rush의 모든 아트워크가 AI로 생성되었나요?
아니요, 현재 창고와 움직이는 캐릭터는 코드로 제작한 Three.js 작업입니다. 기록에는 생성한 포스터 및 초상화 에셋, Higgsfield 컨베이어, 포털 미디어가 별도로 나옵니다. 이전 Canvas 캐릭터 아틀라스도 코드로 만들었습니다. 이 이력과 현재 렌더러를 구분하세요.
Warehouse Rush는 Rapier 물리를 사용하나요?
현재 타이쿤은 Rapier를 가져오지 않습니다. 업스트림 프로젝트 이력과 라이선스 기록에 등장합니다. 현재 충돌, 경로 탐색, 정해진 범위 안의 시각적 움직임은 직접 구현하므로 라이선스 고지를 남겼다고 실제 물리 엔진 의존성이 있다는 뜻은 아닙니다.
게임에 ElevenLabs 효과음을 어떻게 사용했나요?
브라우저 빌드 밖에서 효과음을 생성하고 배포 샘플을 게임플레이 이벤트에 연결했습니다. 인계 문서에는 eleven_text_to_sound_v2를 사용한 효과음 23개가 기록되어 있습니다. 재생은 효과음 설정을 따르며 샘플을 사용할 수 없으면 합성음으로 대체합니다. 브라우저는 생성 API를 호출하지 않습니다.
성능 테스트로 제 휴대전화에서도 잘 실행된다고 입증되나요?
아니요, 휴대전화 크기 뷰포트로 실행한 데스크톱 Chrome은 실제 휴대전화 성능의 근거가 아닙니다. 성능 보고서에는 장비, 표본 조건, 남은 한계가 명시되어 있습니다. 실제 기기에서 게임을 실행해 보세요. 미해결 휴대전화 제보에는 여전히 재현 가능한 기기·브라우저 사례가 필요합니다.
The Nine-Figure Upsell Playbook은 어떻게 받나요?
이메일과 스토어 URL로 Warehouse Rush에 들어간 뒤 첫 소포를 배송하면 플레이북을 받습니다. 가이드는 16페이지와 여섯 개 미션으로 구성됩니다. 제안 하나를 상품 적합성, 배치, 우선순위, 결제 확인, 진단, 성과표에 따른 결정까지 이끌어 줍니다.