첫 지시: "방탈출 게임을 만들어볼까 하는데, 나 혼자서 가능한가?"
방탈출 소재의 긴장감을 손안의 게임으로 만들어 보고 싶었습니다. 저는 게임 엔진을 다뤄 본 적이 없는 기획자입니다. 그래서 "직접 코딩" 대신 "기획과 기준을 정하고 AI에게 단계별로 지시해 상용 수준 게임을 스토어까지 올린다"를 목표로 삼았습니다.
← 전체 작업
Case 01 / 09
THE HOUSE
게임 엔진 경험 0에서 시작해, AI를 지휘해 혼자 만든 1인칭 방탈출 게임 — 스토어 제출까지
테스트 중아이디어→출시약 4주*
2026.09 – 2026.10 (약 4주, 파일 날짜 기준 추정 — git 없음) / 1인 (AI를 팀으로) / Android · iOS
- 문제
- 방탈출 소재의 긴장감을 손안의 게임으로 — 게임 엔진 경험 없이.
- 내 역할
- 기획 · 레벨 설계 · 기준 설정 · AI 지휘로 구현 · 빌드/출시
- 스택
- Unity 6 (6000.6.2f1) · C# · Input System · Addressables · Play Asset Delivery
결과
- 아이디어 → 스토어 빌드 (실작업 약 16일, 추정)
- 약 4주
- 아이디어 → 스토어 빌드 (실작업 약 16일, 추정)
- 게임 런타임 C# 코드 (전체 약 35,900줄 중)
- 17,700+
- 게임 런타임 C# 코드 (전체 약 35,900줄 중)
- 반복한 스토어 빌드 (최신 1.0.10_27)
- 10+
- 반복한 스토어 빌드 (최신 1.0.10_27)
최신 시네마틱 트레일러 (CASE 03)
- 스토어 등록 언어 (영·일·태·번체 중문)
- 4개 언어
- 스토어 등록 언어 (영·일·태·번체 중문)
⚡ 아이디어→출시
약 4주*
2026-09-20
첫 지시
1일 뒤
2026-09-21
첫 동작
26일 뒤
2026-10-17
첫 출시
1일 뒤
2026-10-18
최신 · 1.0.10_27
* 아이디어→구글플레이 스토어 빌드 약 4주(실작업 약 16일). 파일 날짜 기준 추정, 해커톤과 병행
01
아이디어 / 문제
02
내가 정한 기획·기준
- 게임 시나리오와 방 구성, 퍼즐·기믹을 직접 설계 (레퍼런스 영상 스크린샷을 찍어 기준으로 제시)
- 조작 방식 기준: 이동 조이스틱 + 화면 드래그로 시야 회전, 고정 파노라마가 아닌 실시간 3D로 자유롭게 둘러보기
- 출시 기준: 영어 1차, 안드로이드 우선 + iOS, 시나리오당 $1
- 엔진은 Mac(Apple Silicon)에서 바로 쓸 수 있는 Unity 6로, 범용 3D 템플릿에서 시작 — AI와 함께 이 조합을 골랐습니다.
03
AI 지휘 과정
Fig. the-house-03
AI 지휘 과정
01 처음 시킨 것
3D 씬과 1인칭 컨트롤(이동·시야 회전), 오브젝트 상호작용의 기본 골격을 만들도록 지시했습니다.
02 확인한 것
직접 플레이해 보며 시야 회전이 어색한 지점, 상호작용이 밋밋한 지점을 찾아냈습니다.
03 수정 지시
"오브젝트를 클릭하면 시네마틱 줌인으로 확실히 보여 줘", "힌트 표시는 빼고 더미 오브젝트도 클릭되게 해 줘"처럼 플레이 감각을 말로 바꿔 지시했습니다. 빌드·에셋 분리도 같은 방식으로 단계별로 지시했습니다.
실제 지시 (발췌)
- 레퍼런스와 기믹은 내가 아이템표까지 짜서 줄게 — 넌 구현과 이미지 가이드를 해줘.
- 힌트 표시는 빼고, 오브젝트를 클릭하면 시네마틱 줌인으로 확실히 보여 줘.
04
막힌 순간과 해결
- 설치 용량 폭증: 처음엔 에셋을 전부 앱에 담아 용량이 과했습니다. 공식 문서를 먼저 찾아 Addressables + Play Asset Delivery(필요한 시점에 나눠 받기) 방식을 확인한 뒤, AI에 그 구조로 바꾸도록 지시해 초기 설치 부담을 줄였습니다.
- 빌드 반복 실수: 버전마다 손으로 빌드하다 설정을 빠뜨렸습니다. 빌드·아카이브 과정을 스크립트로 묶도록 지시해 매 버전 동일한 절차로 뽑도록 고정했습니다.
Fig. the-house-05
설치 용량 문제 → Addressables + Play Asset Delivery
Before
앱 하나 = 코드 + 모든 방의 에셋
첫 설치부터 전부 다운로드 → 용량 과다
After
기본 앱 (설치 시)코드 + 첫 화면가볍게 시작
에셋 팩 (Addressables)
Room ARoom BRoom CCinematicsAudio…
Play Asset Delivery: 필요한 시점에 내려받기
Case 01
초기 빌드의 설치 용량이 과도하게 큼.
증상
초기 빌드의 설치 용량이 과도하게 큼.
내 설명
에셋이 많아 앱이 너무 무겁다, 용량을 줄이고 싶다"고 사실로 전달.
AI 첫 시도
단순 정리로는 근본 해결이 안 됨.
내가 잡은 포인트
공식 문서에서 Addressables + Play Asset Delivery(필요 시점 분할 다운로드)가 정답임을 확인.
해결
그 구조로 재구성하도록 지시해 초기 설치 용량을 낮춤.
재발 방지
이후 '에셋 분리'를 처음부터 기준에 포함.
05
결과 · 수치
- C# 237개 파일, 약 35,900줄 — 이 중 절반가량은 에디터용 씬 빌더이고 게임 런타임 코드는 약 17,700줄(Core/Interaction/Player/Cinematic/UI 역할별 구조)
- 구글플레이 업로드용 앱 번들을 여러 세대에 걸쳐 반복(최신 빌드 1.0.10_27), 오류 0으로 성공
- 영어·일본어·태국어·번체 중국어 4개 언어 스토어 등록 이미지·메타 준비
- 구글플레이 내부 테스트 배포 단계까지 진행
06
회고
엔진을 모르는 상태에서도, "무엇을 어떤 순서로 시키고, 결과를 어떻게 확인해 바로잡을지"를 잘 설계하면 출시까지 갈 수 있다는 걸 배웠습니다. 다시 한다면 처음부터 에셋 분리와 빌드 자동화를 기준에 넣어, 중간에 구조를 뜯어고치는 비용을 줄이겠습니다.
(01) Review
Honest Review
개발자가 만들었다면?
강점3
속도·비용 — 아이디어→스토어 빌드 약 4주, 1인
C# 약 3.6만 줄(런타임 약 1.77만), 3개 케이스, 인앱결제, 4개 언어. 같은 범위면 2~3인 팀이 보통 2~4개월(추정). git이 없어 파일 날짜 기준(최소치).
배포·운영 — 4주간 스토어 빌드 10회 이상, 스크립트화
Android·iOS 출시 빌드를 10회 이상 반복, 디버그 심볼·에셋팩 보관을 스크립트로 자동화하고 빌드마다 결과 기록.
현지화 — 4개 언어, 누락 0
영어·일본어·태국어·번체 중국어 테이블이 모두 정확히 1,452줄, 시스템 언어 자동 감지.
동등4
기능 범위 — 소규모 팀 출시작 수준
3개 케이스, 세이브, 설정, 힌트북, 시네마틱, 구매·복원.
성능 — 분할 다운로드는 정석대로
Addressables + Play Asset Delivery로 설치 용량을 줄임. 매 프레임 오브젝트 탐색 일부는 정리 대상.
가독성 — 일관적, 일부 촘촘한 코드
이름 규칙 일관, UI 패널 10개가 공통 부모 클래스 사용. 한 줄에 몰린 로직이 일부 있음.
문서화 — 결정 기록은 있음
기획·수익화·출시 결정을 문서로 남김. 개발자용 구조 문서는 아직 없음.
다음 단계 (보완 중)5
테스트·자동화 — 자동 테스트·CI 아직 없음
매 단계 직접 플레이하고 에디터 플레이테스트 도구로 확인.
개선 계획 → 구매·세이브 로직부터 테스트 작성 → 커밋마다 빌드+테스트 자동 실행(CI).
구조 — 런타임 코드 모듈 미분리
코드 절반이 일회성 에디터 씬 빌더이고, 씬 연결을 실행 중 탐색으로 처리.
개선 계획 → 런타임 코드를 Core / Cases / UI 모듈로 나누고, 참조는 시작 시 한 번 주입.
버전 관리 — git 대신 수동 백업
출시 속도를 우선해 코드·빌드를 사본으로 백업.
개선 계획 → 비공개 Git 저장소로 이전, 비밀값은 처음부터 제외.
보안 — 공개 출시 전 강화
결제는 공식 스토어 SDK 사용. 공개 출시 전에 서버 측 보호 단계를 추가합니다(세부는 비공개).
개선 계획 → 구매 검증을 서버 중심으로 강화한 뒤 외부 점검.
접근성 — 기본 옵션만
소리·감도·진동 설정만 있고 자막·글자 크기·색각 옵션은 아직 없음.
개선 계획 → 자막·글자 크기·색각 옵션을 출시 체크리스트 필수 항목으로.
다음 프로젝트 →
MECHOOSE
기획자가 AI를 지휘해 혼자 만든 태국 패션 이커머스 + AI 가상 피팅 — 실제 운영 중 (mechoose.store)
