첫 프로토타입까지 3D 에셋 100%를 AI로 생성한 게임, 블룸 가든
미리 준비해둔 리소스 없이 시작해, 플레이 가능한 첫 프로토타입에 도달할 때까지 3D 에셋을 100% PicoBerry로 생성했습니다. 걸린 시간은 약 2주. 이후 게임 시스템과 UI 구현, 그리고 최적화가 이어졌습니다 — 그 과정에 실제로 무엇이 필요했는지, AI가 풀어주지 못한 부분까지 함께 정리했습니다.
AI로 생성한 3D 에셋만으로 실제 모바일 게임을 만들 수 있나요?
블룸 가든은 구글 플레이에 출시됐고, 게임에 등장하는 꽃과 소품, 배경 오브젝트는 전부 PicoBerry로 생성했습니다. 그림을 그리는 역량이 따로 없는 개발자가 진행했습니다. 플레이 가능한 첫 프로토타입까지는 미리 준비한 것 없이 3D 에셋을 100% AI로 생성했고, 여기까지 약 2주가 걸렸습니다. 그 이후로는 답이 더 구체적이어야 합니다 — 에셋을 만드는 일과 게임을 완성하는 일은 다릅니다. UI는 사람의 피드백을 여러 번 거쳐야 했고, 반복 배치되는 오브젝트의 폴리곤은 결국 아트 디렉션과 최적화로 풀어야 하는 성능 문제가 되었습니다. 에셋 단계는 생성이 상당 부분 감당하지만, 씬 예산과 UI, 마지막 완성도는 여전히 사람의 몫입니다.
블룸 가든은 어떤 게임인가요?
한적한 들판을 번창하는 꽃 사업으로 키워가는 정원 경영 게임입니다.
심고, 키우고, 수확하기
다양한 꽃을 심어 키우고, 정원이 생기를 되찾는 모습을 지켜보며 수확합니다.
상품 제작과 주문 처리
수확한 꽃을 상품으로 만들어 마을 주민의 주문을 완료하고, 보상으로 다음 확장을 준비합니다.
치우고, 고치고, 넓히기
자라난 풀을 치우고, 고장난 기계와 건물을 수리하며 정원을 되살리고 넓혀갑니다.
개발은 어떻게 진행되었나요?
기획에서 출시까지, 실제로 거쳐온 단계를 순서대로 정리합니다.
- 개발 인원
- 1명유모델러 소속 게임 개발자
- 기간
- 약 4주실제 작업일 20일 · 하루 8시간
- 프로토타입 도달
- 약 2주생산·판매·업그레이드·퀘스트·시네마틱
- 사전 준비 리소스
- 없음3D 에셋을 최대한 PicoBerry로 생성
목표는 분명했습니다 — 미리 준비한 리소스 없이, 경영 시뮬레이션 한 편을 끝까지 만들어보는 것. 프로토타입 이후의 기간은 게임 시스템과 UI 구현, 그리고 출시 준비와 실제 기기에서의 최적화에 들어갔습니다.
기획과 프로토타입
검증된 장르 위에서 PicoBerry 에셋의 활용 범위를 시험했습니다.
만들기로 한 것은 생산 → 판매 → 수익 재투자로 더 많이 생산 → 자동화로 이어지는 경영 시뮬레이션이었습니다. 최근 모바일 시장에서 꾸준히 자리를 지키는 장르라, 이미 검증된 재미 구조 위에서 시험하기에 적합하다고 봤습니다. 비슷한 게임들을 조사해 핵심 루프와 시스템을 참고했습니다.
프로토타입에 필요한 에셋은 미리 준비한 것 없이 전부 PicoBerry로 조달했습니다. 그 덕분에 약 2주 만에 생산·판매·업그레이드·퀘스트·시네마틱 시스템까지 갖춘, 실제로 플레이되는 프로토타입에 도달했습니다.
에셋 파이프라인 구축
3D로 바로 가지 않고 '이미지 먼저'로 흐름을 잡았습니다.
모든 모델을 PicoBerry로 생성했기 때문에, 초반에는 흐름을 잡는 것 자체가 과제였습니다. 기능 구현에 필요한 오브젝트를 컨셉에 맞춰 이미지로 먼저 생성하고, 게임에 쓸 만한 인상이 나올 때까지 이미지 단계에서 방향을 다듬은 뒤에 3D로 넘어갔습니다.
- 시행착오 — 이미지 한 장만으로는 형태가 제대로 살지 않는 캐릭터들이 있었습니다. 그 뒤로는 그런 오브젝트에 한해 뒤·옆 모습 이미지를 함께 만들어 여러 각도를 준 채로 생성했습니다.
- 폴리곤 기준 — 기본적으로 최소화하는 쪽으로 생성하되, 형태가 복잡한 경우에만 수를 조금 늘려 잡았습니다.
게임 구현과 UI
시스템 로직은 맡길 수 있었지만, UI는 사정이 달랐습니다.
게임 시스템과 UI 구현에는 코딩 AI(Claude Code)를 활용했습니다. 특히 HUD는 Unity UI Toolkit으로 구현했는데, AI가 레퍼런스 이미지를 분석하거나 요청 사항을 UI에 정확히 반영하는 데에는 의외로 약했습니다.
레퍼런스 이미지를 넣어도 각 구성 요소의 비율을 적절히 맞추지 못해, 원하는 결과가 나올 때까지 UI 이미지와 피드백을 반복해서 줘야 했습니다. 이 부분은 아직 사람이 방향과 요청을 구체적으로 잡아줘야 하는 영역으로 보였습니다.
출시와 외부 테스트
최적화를 뒤로 미룬 대가를 막판에 치렀습니다.
막판에는 SDK 연동과 최적화가 발목을 잡았습니다. 개발 중에는 비교적 사양이 좋은 환경에서 테스트했던 탓에, PicoBerry로 만든 수천 폴리곤 규모의 메쉬가 큰 문제로 드러나지 않았습니다.
하지만 실제 기기 환경에서는 그 부담이 곧바로 드러났고, 여기에 SDK 연동 문제까지 겹치면서 출시와 외부 테스트를 앞둔 마지막 구간에 작업이 몰릴 수밖에 없었습니다.
3D 에셋은 어떻게 만들었나요?
게임에 들어간 꽃과 소품, 배경 오브젝트를 만들어낸 반복 흐름입니다.
꽃 형태 이미지 생성
메시를 만들기 전에 이미지 생성으로 꽃의 형태 후보를 여러 개 만들어 비교하고 고릅니다. 게임에서 꽃을 모아 꽃다발이 되므로, 꽃과 꽃다발의 형태가 자연스럽게 이어져야 합니다.
꽃다발 이미지 생성
선택한 꽃 이미지를 참고로 꽃다발 이미지를 생성합니다. 3D로 넘어가기 전에 색과 형태를 이 단계에서 확정합니다.
메쉬 + 텍스처링
확정한 꽃다발 이미지를 PicoBerry에서 3D로 만들며, 메쉬 생성과 텍스처링을 함께 진행합니다. 한 번에 완벽을 노리기보다 생성·비교·선택을 반복했습니다.
Unity에서 조립
에셋을 가져와 배치하고 게임 시스템에 연결합니다. 씬 예산이 실제로 결정되는 지점이 바로 여기입니다.
생성된 에셋은 다듬어 쓰는 출발점이지 완성된 게임 콘텐츠가 아닙니다. 위 소품들도 모두 선별과 보정을 거친 뒤에야 씬에 자리를 얻었습니다.
① 꽃 형태 후보 A
잔가지에 작은 꽃이 촘촘한 형태의 후보.
② 꽃 형태 후보 B — 선택
또렷한 꽃 형태. 이 이미지를 참고 이미지로 골랐습니다.
③ 꽃다발 이미지 생성
선택한 꽃을 참고해 생성한 꽃다발 이미지.
④ 메쉬 + 텍스처링
이 이미지로 메쉬와 텍스처링을 함께 작업한 결과.
신규 모델로 저폴리 에셋을 직접 생성하기
프로젝트 후반에 적용한 신규 생성 모델은 초기 모델보다 결과 품질과 저폴리 생성 품질에서 개선을 보였습니다. 고폴리로 만든 뒤 줄이는 대신 처음부터 목표 폴리곤에 맞춰 생성하는 경로가 열린 셈이라, 이 사례는 이 페이지에서 가장 실용적인 대목입니다.
이 페이지에 반복해서 등장하는 꽃다발이 그 사례입니다. 게임에서 가장 자주 배치되는 소품이라 폴리곤 부담이 특히 컸습니다.
처음에는 약 5,000폴리곤 기준으로 생성한 모델을 그대로 1,000폴리곤까지 리메시했습니다. 그런데 이렇게 한 번에 크게 줄이자 형태가 뭉개지고 면이 깨졌습니다 — 포장지와 리본이 무너지고 꽃 모양이 뭉툭하게 뭉쳐버렸습니다.
방향을 바꿔, 고폴리로 만든 뒤 줄이는 대신 image-to-3D 단계에서 처음부터 폴리곤 수를 낮게 설정해 생성했습니다. 그 결과는 저폴리인데도 형태를 유지했고, 이후 UModeler X로 세부를 조금 손봐 게임에 쓸 형태로 정리했습니다.
생성을 여러 번 반복했지만 대기가 부담되지는 않았습니다. 한 번 생성에 2분 정도라, 폴리곤 설정을 바꿔가며 결과를 비교하고 고르는 반복이 현실적으로 가능했습니다.
AI로 게임을 개발할 때의 노하우는?
같은 방식을 시도하려는 사람이 실제로 가져갈 수 있는 실무 감각.
직접 해보고 가장 크게 남은 감각은 하나였습니다 — AI 생성물은 '참고 자료만 주면 알아서 맞춰주겠지'로는 원하는 결과가 나오지 않습니다. 스타일과 역할, 구조를 먼저 명시하고, 여러 장 생성해 비교하고, 실제로 돌려서 검증하는 반복을 전제로 삼아야 쓸 만한 결과가 나왔습니다.
3D 에셋 생성 노하우
3D를 바로 생성하지 않습니다. 이미지가 먼저입니다.
이미지를 먼저 생성하고, 그 이미지로 3D 오브젝트를 만드는 순서입니다. 이미지의 스타일을 일정하게 유지하면 3D 결과도 비슷한 분위기로 뽑을 수 있었습니다. 그래서 게임 전체에 공통으로 쓸 참조 이미지 한 장, 또는 프롬프트 한 줄을 정해두는 것이 중요했습니다.
하이퍼 캐주얼 스타일을 고려하지 않고 단순히 '기계를 그려달라'고 했더니, 너무 복잡하고 실제로 작동할 것 같은 기계가 나왔습니다.
기계적인 디테일을 덜어내고 하이퍼 캐주얼 톤에 맞도록 프롬프트를 수정. 이후 다른 기계도 그 프롬프트를 재사용해 '동작 없이 역할 차이만 드러나게' 요청하니 수정 횟수가 훨씬 줄었습니다.
텍스처와 스타일 통일
생성 모델을 하나로 고정하는 것이 첫 번째 조건이었습니다.
- 모델 고정 여러 모델을 비교해보고, 만들려는 스타일에 가장 가까운 모델을 하나 골라 끝까지 유지했습니다.
- 참조 이미지로 편차 잡기 같은 모델을 써도 결과에 편차가 생길 때는 참조 이미지로 잡았습니다. 단순히 '건물' '물건'이라고 하는 대신 '이 캐릭터가 살 법한 건물' '이 캐릭터가 쓸 만한 물건'처럼, 미리 정해둔 참조 이미지와 프롬프트를 조합해 맥락을 주는 방식입니다.
AI 코딩 도구 활용
수치를 주면 코드는 고쳐집니다. UI는 그렇지 않았습니다.
시스템 개발은 대부분 AI 코딩 도구로 진행했습니다. 다만 메쉬를 전부 AI로 생성했기 때문에 최적화가 필수였습니다.
- 최적화 — 되는 방식 프로파일링으로 나온 결과를 AI 도구에 그대로 전달하고, AI가 그 수치를 근거로 원인을 짚어 코드를 개선하게 한 뒤, 다시 측정해 확인하는 반복입니다.
- UI — 안 되는 방식 게임 내 HUD를 UI Toolkit으로 만들었는데, 배치 비율이나 정렬을 한 번에 맞추지 못했습니다. 참고 이미지와 대략적인 설명을 더해도 원하는 구성이 나오지 않아, 여러 번 반복하거나 USS·UXML을 직접 수정하거나 잘못된 부분을 직접 짚어줘야 하는 경우가 많았습니다.
사람이 반드시 봐야 하는 지점
'이 정도 자료면 알아서 잘하겠지'가 실수였습니다.
- 역할과 구조를 먼저 돌아보면 UI에서의 실수는 그렇게 맡겨버린 것이었습니다. 각 요소의 역할과 구조를 먼저 정확히 인지시킨 다음 진행했어야 했습니다.
- 실행 환경 알고리즘상으로는 문제가 없어 보여도, 실제 실행 환경과 Unity 앱의 특성에 따라 문제가 되는 코드가 나올 수 있었습니다. 이런 부분은 결국 테스트로 직접 돌려 확인하고 보완하는 과정이 항상 필요했습니다.
같은 걸 다시 만든다면
- 시작 단계부터 실행 성능을 정확히 판단하고 폴리곤·에셋 기준을 세우겠습니다. 이번에는 정확한 측정 없이 진행해, 뒤늦게 에셋을 고치거나 예상치 못하게 실행이 매끄럽지 않은 상황을 겪었습니다.
- 최종 단계에서는 프로파일링과 빌드 테스트로 최적화를 충분히 돌리겠습니다. 자잘한 배경 오브젝트는 개발 후반에야 배치할 수 있었는데, 그전에는 없던 오브젝트들이 한꺼번에 생기면서 부하가 뒤늦게 드러났습니다.
- 이미지는 한 장이 아니라 2~4장을 함께 뽑아 비교하겠습니다. AI 생성 결과는 한 번에 원하는 것이 나오지 않는 경우가 많으므로, 이것만으로도 작업이 한결 수월했습니다.
AI는 어디까지 해냈고, 어디서 멈췄나요?
이 사례에서 쓸모 있는 부분은 성공담이 아니라 이 경계선입니다.
AI 생성이 감당한 구간
- 전담 아트 인력 없이 게임에 쓸 만한 분량의 소품을 확보했습니다. 그림을 그리는 역량이 없는 개발자도 진행할 수 있었습니다.
- 프로토타입과 외부 테스트 빌드를 실제로 플레이 가능한 상태까지 끌어올렸습니다.
- 인상을 빠르게 반복했습니다. 값비싼 에셋 하나에 매이지 않고 여러 후보를 생성해 비교하고 고르는 방식이 가능했습니다.
- 후반에 적용한 신규 모델은 초기 모델보다 결과 품질과 저폴리 생성 품질에서 눈에 띄는 개선을 보였습니다.
사람의 손이 필요했던 구간
- UI 디자인과 배치는 사람의 피드백을 여러 번 거쳐야 했습니다. 의도와 참고 이미지, 게임 문맥이 한 번에 정확히 반영되지는 않았습니다.
- 씬 단위의 예산 — 폴리곤, 그림자, 텍스처, 누적되는 오브젝트는 AI 생성이 대신 결정해주지 않습니다.
- 사용자가 체감하는 완성도 구간의 아트 디렉션.
- 성능 검토. 코딩 AI는 화면에 기능이 나오는 것을 우선하므로, 성능 구조는 사람이나 별도 검토 루프가 초기에 명시해야 했습니다.
- 게임 내 연출에 맞추기 위한 최소한의 메쉬·텍스처 수정은 사람이 UModeler X로 직접 손봤습니다.
폴리곤 예산에서 무엇을 배웠나요?
이 프로젝트에서 가장 널리 적용할 만한 교훈과, 그것을 PicoBerry 안에서 어떻게 풀었는지입니다.
반복 배치는 조용히 곱해진다
꽃다발 하나는 폴리곤이 많아도 그 자체로는 문제없어 보입니다. 그러나 게임이 진행되며 수량이 쌓이면 같은 에셋이 수십만 폴리곤을 동시에 그리게 됩니다. 나빠진 것은 에셋이 아니라 씬이었습니다.
리메시보다 '저폴리로 직접 생성'
고폴리로 만든 뒤 리메시로 줄이면 형태가 훼손될 위험이 크고 작업 시간도 들쭉날쭉했습니다. 결정적이었던 것은 PicoBerry에 새로 추가된, 저폴리 메쉬 생성에 특화된 생성 모델입니다. 이 모델로 처음부터 낮은 폴리곤으로 생성하니 기존 대비 폴리곤을 10분의 1 이하로 줄이면서도 형태가 유지됐고, 메쉬를 만든 뒤 리메시로 줄이는 경로보다 결과가 더 좋았습니다.
작게 보이면 싸게 그려도 된다
화면에서 작게 반복되는 오브젝트까지 3D 복잡도를 유지할 필요는 없습니다. 텍스처 기반 표현이나 단순한 메시, 빌보드 전환을 먼저 비교해본 뒤에 정밀한 버전을 고집해야 합니다.
예산은 만들기 전에 정한다
최적화가 마감 단계로 밀리면서 그림자와 텍스처, 누적 오브젝트를 조정할 여유가 부족했습니다. 착수 시점에 폴리곤과 성능 예산을 세우고, 마감이 아니라 중간에 프로파일링을 배치하는 것이 해법입니다.
측정 환경은 보급형 안드로이드 기기 Galaxy A16(해상도 2340×1080)였습니다. 최적화 전에는 장면에 따라 10~30 FPS까지 떨어졌지만, 아래 조치를 거친 뒤에는 60 FPS로 안정됐습니다.
| 대상 | 조치 전 | 조치 후 |
|---|---|---|
| 저장소 꽃다발 36개 | 약 400,000 폴리곤 | 약 18,000 폴리곤 |
| 장미밭 성장·수확 (장미 25×6 = 150개) | 약 750,000 폴리곤 | 약 75,000 폴리곤 |
| 텍스처 (컬러 팔레트로 통합) | 2048 크기 수십 장 | 512 크기 1장 |
같은 오브젝트라도 씬에 수십·수백 개가 쌓이면 폴리곤이 곱으로 불어납니다. 개별 에셋의 폴리곤을 줄이고 여러 텍스처를 하나의 컬러 팔레트로 합치자, 보급형 기기에서도 프레임이 안정됐습니다.
① 리메시로 줄인 초기 방식
약 5,000폴리곤 모델을 1,000폴리곤까지 한 번에 리메시하자 포장지와 꽃 형태가 무너졌습니다.
② 처음부터 저폴리로 생성
image-to-3D 단계에서 폴리곤 수를 낮게 잡아 생성하니, 저폴리인데도 형태가 유지됐습니다.
③ UModeler X로 정리
생성 결과를 UModeler X로 조금 손봐 게임에 쓸 형태로 마무리했습니다.
에디터에서는 어떤 작업을 했나요?
생성한 에셋을 Unity 씬에 앉히고 시스템에 연결하는, 사람 손이 들어간 구간입니다.
에디터에서의 작업
Unity 에디터에서 타운홀 관련 오브젝트의 인스펙터 값을 배선하는 작업 화면입니다.
실제로 움직이는 모습은 어떤가요?
출시된 빌드의 플레이 화면입니다. 생성한 에셋이 Unity에서 그대로 돌아가고 있습니다.
자주 묻는 질문
블룸 가든은 어떤 게임인가요?
구글 플레이에 출시된 정원 경영 게임으로, 개발사는 유모델러입니다. 꽃을 심고 수확해 마을 주민의 주문에 맞는 상품으로 만들고, 자라난 풀을 치우고 시설을 수리하며 정원을 넓혀갑니다. 3D 에셋은 PicoBerry로 생성했고 게임 자체는 Unity로 만들었습니다.
에셋 제작에 PicoBerry의 어떤 기능을 썼나요?
레퍼런스 인상을 잡는 이미지 생성, 그 이미지를 바탕으로 한 3D 모델 생성, 그리고 결과물의 텍스처 작업입니다. 프로젝트 후반에는 저폴리 결과가 더 좋은 신규 모델을 별도로 활용했습니다.
게임 에셋을 전부 만드는 데 크레딧이 얼마나 들었나요?
전부 합쳐 82,280 크레딧입니다. 다만 이 숫자를 그대로 견적으로 쓰지는 마세요 — 실제 게임에 들어간 분량이 아니라 쓰지 않은 후보까지 전부 포함한 수치입니다. 이미지 514장과 3D 모델 153개를 만들었고, 모델 하나당 이미지를 평균 세 장 넘게 뽑았습니다. 이 페이지가 계속 권하는 '한 번에 완벽을 노리지 말고 여러 장 뽑아 비교하라'는 방식의 비용이 바로 이 숫자입니다. 규모 감각으로는 이렇습니다 — 개발자 한 명이 한 달 동안 게임 한 편에 필요한 3D 에셋 전부를 구독 한 달 범위 안에서 해결했습니다. 처음 만들어보는 파이프라인이라 시행착오분이 컸으니, 흐름이 잡힌 뒤라면 더 줄어듭니다.
AI가 게임 전체를 만든 건가요?
아닙니다. PicoBerry가 만든 것은 3D 에셋입니다. 게임의 시스템과 UI, 씬 조립과 성능 작업은 팀이 Unity에서 직접 했습니다. 생성된 결과물을 완성된 게임 콘텐츠로 이해하면 이 사례를 잘못 읽는 것입니다.
이 방식을 쓰려면 아티스트여야 하나요?
프로토타입이나 테스트 빌드까지라면 아닙니다. 그림을 그리는 역량이 따로 없는 개발자들이 이 방식으로 게임에 쓸 만한 분량의 소품을 만들었습니다. 다만 사용자가 체감하는 완성도 구간에서는 아트 디렉션이 필요했습니다. 진입 장벽을 낮춰주는 것이지 안목과 검토를 없애주지는 않는다는 것이 정직한 답입니다.
AI로 생성한 에셋이 성능을 망치지 않게 하려면요?
생성한 다음이 아니라 생성하기 전에 폴리곤 예산을 정하세요. 고폴리 결과를 무리하게 리메시하면 형태가 훼손될 수 있으니, 목표 폴리곤에 맞춰 생성하거나 저폴리 품질이 좋은 모델을 쓰는 편이 낫습니다. 그리고 반복 배치되는 오브젝트는 씬 문제로 다뤄야 합니다. 화면 점유율과 수량, 그림자, 텍스처, LOD·빌보드 전환을 함께 설계해야 합니다.
고폴리 에셋을 리메시로 줄이면 되지 않나요?
될 때도 있지만 이 프로젝트에서는 신뢰하기 어려웠습니다. 큰 폭으로 줄이면 실루엣이 훼손될 위험이 있었고 작업 시간이 들쭉날쭉해 일정에 넣기 어려웠습니다. 처음부터 목표 밀도로 생성하는 편이 더 효율적이었습니다.
다음 프로젝트에서는 무엇을 다르게 하시겠어요?
착수 시점에 성능과 에셋 기준을 정하고, 프로파일링과 빌드 테스트를 마감이 아니라 중간 단계에 배치하겠습니다. 출시 전 최적화와 QA를 위한 독립적인 시간을 따로 확보하고, UI와 게임 플레이 코드는 화면에 보이는 결과만이 아니라 갱신 비용과 성능까지 함께 리뷰하겠습니다.