Tiny Glade 성공 사례 분석

이번 사례는 최근 다룬 Balatro, Buckshot Roulette, BALL x PIT, Backpack Battles, Plausible Analytics, Dome Keeper 등과 겹치지 않도록 **Pounce Light의 《Tiny Glade》**를 선정했다.

《Tiny Glade》는 흔히 “코지한 성 짓기 게임”으로 소개되지만, 제품 관점에서 더 정확한 정의는 **“적은 입력으로 많은 결과가 나오고, 실패가 없으며, 사용자의 창작물을 자동으로 보기 좋게 다듬어 주는 3D 창작 장난감”**이다. 이 차이가 중요하다. Pounce Light는 기존 도시건설 게임의 자원관리·전투·효율 최적화·승패를 전부 제거하고, “그리듯 벽을 만들면 시스템이 알아서 문·아치·기둥·돌·식생·디테일을 조립해 주는 과정” 자체를 제품으로 만들었다.

상업 성과도 매우 강했다. 개발팀이 GameDiscoverCo에 제공한 Steam 백엔드 수치에 따르면 2024년 9월 23일 출시 후 한 달이 되기 전에 616,000장 이상 판매됐고, 출시 시점 Steam 위시리스트는 1,375,441개였다. 당시 일간 활성 사용자는 34,000명 이상, 중앙값 플레이시간은 1시간 4분이었다. 출시 직후 최고 동시접속은 약 10,692명이었다. (GameDiscoverCo, 2024-10-29 , WN Hub, 2024-10-30 , WN Hub, 2024-09-25 )

2026년 9월 현재 공개 Steam 데이터 기준 리뷰는 약 24.5K개, 97% 긍정 수준이고 가격은 $14.99다. 게임은 2025년 대형 계단 업데이트, 2026년 macOS Apple Silicon 지원, 2026년 9월에는 나무 벽·꽃·Steam Workshop·그룹 편집 등을 포함한 1.16 베타까지 이어가고 있다. (Steam, 확인 2026-09-21 , Steambase, 2026-09 집계 , Steam Community, 2026-09-08 )

핵심 성공 공식
프로시저럴 기술 실험 → “많은 결과를 적은 노력으로”라는 UX 원칙 → 실패 없는 창작 도구 → 짧은 영상만으로 가치가 보이는 비주얼 → Steam 페이지 공개 순간부터 집중된 위시리스트 모멘텀 → 장기 소셜 미디어 누적 → 무료 데모·Next Fest → 셀프 퍼블리싱 → UGC가 다시 마케팅이 되는 구조

1. 핵심 공개 지표와 타임라인

공개되지 않은 수치

정확한 누적 최신 판매량, 총매출, 순매출, 개발비, 두 창업자의 실제 수령액, 세금·Steam 수수료 반영 후 이익, 마케팅 지출, 환불률, 위시리스트→구매 전환율, D1/D7/D30 리텐션, 국가별 최신 판매량, 할인 시점별 매출 기여, TikTok·X의 개별 게시물별 구매 전환율은 신뢰할 만한 공식 자료에서 확인되지 않는다.

따라서 “616K × $14.99”를 매출로 계산하지 않는다. 지역가격, 할인, 환불, 부가세, 플랫폼 수수료를 반영하지 않은 단순 곱셈은 실제 사업 매출이 아니다. 또한 제3자 판매 추정 서비스의 2025~2026 누적 판매량은 서로 크게 어긋나므로 사용하지 않는다.

2. 창업자·개발자 배경: 2인 팀이지만 신입 2명이 아니다

[사실]

Pounce Light의 핵심은 Anastasia Opara와 Tomasz Stachowiak 두 명이다. 두 사람 합산 게임업계 경력은 15년 이상으로 소개되며, Embark Studios·Electronic Arts·Creative Assembly 등에서 AAA 제작 경험을 쌓았다. Ana는 프로시저럴 아트 쪽에서 장기간 경험을 축적했고, Tom은 렌더링·그래픽스 엔지니어링 분야 경력이 깊다. (GamingOnLinux, 2024-06-01 , 80 Level, 2024-05-30 )

Ana는 Tiny Glade 이전부터 거의 10년에 걸쳐 여러 프로시저럴 생성기를 만들었다고 설명한다. Tiny Glade도 애초에는 “게임”이 아니라 렌더링을 배우기 위한 취미 주말 프로젝트였다. (80 Level, 2024-05-30 )

[분석]

따라서 이 성공을 “2명이면 대작 스튜디오를 이길 수 있다”로 단순화하면 잘못이다.

실제 구조는:

고난도 전문기술 2개가 정확히 맞물린 2인 팀

이었다.

• Ana: 프로시저럴 생성·아트 디렉션·상호작용 감각
• Tom: 그래픽스·렌더링·시스템 엔지니어링

Tiny Glade의 차별점 자체가 프로시저럴 미학 + 실시간 렌더링 + 시스템적 UX이므로 창업자 기술과 제품 thesis가 거의 완전히 일치한다.

작은 팀이 성공한 것이 아니라 작은 팀이라도 제품의 가장 어려운 문제를 내부에서 직접 풀 수 있었던 것이 더 중요하다.

3. 제품 thesis: “건축 게임”이 아니라 “그리면 시스템이 예쁘게 완성해 주는 창작 장난감”

[사실]

Steam 공식 설명은 Tiny Glade를 작은 diorama builder로 정의한다. 관리, 전투, 목표가 없고 gridless building chemistry를 통해 벽·지붕·길·문 등이 서로 반응한다. (Steam )

개발팀이 직접 정리한 초기 디자인 기둥은 세 가지였다.

1. A lot from little effort — 적은 노력으로 많은 결과
2. No wrong answers — 틀린 답 없음
3. It’s alive — 사용자의 창작에 세계가 반응

(GameDiscoverCo, 2024-10-29 )

[분석]

이 세 문장이 제품 전체를 설명한다.

Tiny Glade가 해결하는 문제는 “건축을 정확하게 시뮬레이션”하는 것이 아니다.

더 정확한 고객 job은:

“내가 머릿속에 떠올린 예쁜 장소를, 기술 없이도 빠르게 눈앞에 만들고 싶다.”

이다.

Minecraft나 일반 city builder의 창작은 대개 다음 비용을 요구한다.

자원 수집 → 블록 선택 → 정렬 → 반복배치 → 미세수정 → 디테일링

Tiny Glade는 이 중 디테일링 비용을 시스템이 대신한다.

플레이어가 벽 하나를 그으면 게임이:

• 돌
• 기둥
• 창틀
• 아치
• 잡동사니
• 식생
• 구조적 연결부

를 자동으로 처리한다.

즉 사용자는 의도를 제공하고 시스템이 craft를 증폭한다.

4. 핵심 UX ①: “입력 대비 결과 비율”을 극단적으로 높임

[사실]

개발팀은 벽을 그리고 지붕을 바꾸거나 울타리를 늘릴 때 수많은 디테일이 즉시 자동생성되도록 설계했다. 벽에 길을 통과시키면 아치가 생기고, 구조를 들어 올리면 지지대가 생기는 식이다. (GameDiscoverCo, 2024-10-29 , Future Games Show 설명, 2023-08 )

[분석]

이것은 단순한 편의기능이 아니다.

창작 제품의 가장 큰 장벽 중 하나는:

내 머릿속 이미지와 내가 실제로 만들 수 있는 결과의 격차

다.

Tiny Glade는 프로시저럴 시스템을 이용해 이 격차를 좁힌다.

그 결과 초보자도 몇 초 만에 “공유하고 싶은 화면”을 만든다.

이를 제품 지표로 표현하면:

Shareable Output / Input Minute

가 매우 높다.

UGC 제품에서 이 비율이 높을수록 소셜 공유가 쉬워진다.

5. 핵심 UX ②: “No wrong answers”가 창작 불안을 제거

[사실]

Tiny Glade에는 자원 부족, 전투, 패배조건, 잘못된 구조라는 개념이 없다. Undo/redo도 제공하고 언제든 형태를 수정할 수 있다. (Steam , GamingOnLinux, 2024-06-01 )

[분석]

창작 소프트웨어의 숨은 리텐션 방해요인은 “실패”가 아니라 실패할 것 같은 느낌이다.

Photoshop·Blender·CAD처럼 결과가 좋지 않을 때 사용자는 자신의 실력을 탓하기 쉽다.

Tiny Glade는 반대로 시스템 자체가:

“무엇을 해도 어느 정도 예쁘게 나온다.”

는 안전망을 만든다.

이 때문에 사용자는 완벽한 계획 없이 드래그할 수 있다.

즉 제품이 skill floor를 낮추는 것이 아니라 embarrassment floor를 낮춘다.

6. 핵심 UX ③: 시스템이 사용자를 “보고 있다”는 느낌

[사실]

Ana는 게임이 사용자의 조합을 알아보고 반응하는 감각을 RPG가 과거 선택을 기억해 주는 경험에 비유했다. 벽·길·높이·창문 등이 상호작용할 때 “게임이 내가 하는 일을 신경 쓴다”는 느낌을 주고 싶었다고 설명한다. (80 Level, 2024-05-30 )

[분석]

프로시저럴 생성의 보통 목적은:

넓은 세계를 싸게 만든다.

Tiny Glade에서는 다르다.

사용자 입력에 대한 즉시 인정과 보상

에 쓰인다.

벽이 다른 벽을 만나면 시스템이 연결을 “이해”한다.

길이 벽을 가로지르면 아치를 “알아서” 만든다.

이 반응은 기능적으로는 알고리즘이지만 사용자는 친절한 도구로 느낀다.

7. 핵심 UX ④: 완성품보다 “만들어지는 과정” 자체가 콘텐츠

[사실]

Tom은 초기 프로시저럴 벽 영상 자체가 왜 사람들이 좋아하는지 뒤늦게 이해했다고 말했다. 벽이 즉석에서 재배열되고 조립되는 장면에는 눈에 보이는 만족감이 있었다. (80 Level, 2024-05-30 )

[분석]

이는 소셜 미디어 적합성의 핵심이다.

보통 3D 모델링은:

1시간 작업 → 완성품 screenshot

이다.

Tiny Glade는:

드래그 1초 → 벽 변형 → 디테일 생성 → 예쁜 결과

가 된다.

그래서 과정 자체가 GIF·TikTok·X 영상으로 즉시 소비 가능하다.

마케팅용 연출을 별도로 만들지 않아도 실제 제품 interaction이 광고 소재가 된다.

8. 개발 전략: 게임을 만들기 전에 “반응하는 프로시저럴 벽”부터 만들었다

[사실]

Tiny Glade는 주말 hobby rendering experiment에서 출발했다. Ana는 렌더링 학습용 장면이 필요해 프로시저럴 생성물을 넣었고, 초기 영상을 X에 공유했더니 반응이 예상보다 컸다. 이후 “기술적으로 흥미로워 보일 뿐 실제 일반 사용자가 하고 싶은 건 아닐 수 있다”고 생각해 TikTok 계정을 만들어 비개발자에게 보여줬다. 여기서 다시 강한 반응이 나오며 게임화 가능성을 확인했다. (80 Level, 2024-05-30 )

[분석]

이 검증 순서가 매우 좋다.

1. 기술실험 — 내가 만들 수 있는가?
2. 개발자 커뮤니티 반응 — 보는 재미가 있는가?
3. 비개발자 TikTok 반응 — 일반 소비자도 원하는가?
4. Steam 페이지 — 구매의향이 있는가?
5. 데모 — 실제로 사용하고 싶은가?
6. 정식 출시 — 돈을 낼 것인가?

하나의 가설을 한 번에 큰 게임으로 검증하지 않고 점점 비싼 검증으로 이동했다.

9. 첫 대형 distribution inflection: Steam 페이지를 “아무 날” 열지 않았다

[사실]

2022년 12월 Tiny Glade는 이름, 새 트레일러, Steam 페이지 공개를 Wholesome Games 계열 이벤트와 맞췄다. 공개 첫 24시간에 10,000 wishlist, 약 4개월에 **420,000+**를 확보했다. 마케팅 분석가 Chris Zukowski는 소셜 모멘텀·이벤트·Steam 페이지 공개를 한 번에 묶은 “surge”가 Steam 추천과 장기 wishlist 유입을 만드는 데 도움이 됐다고 분석했다. (How To Market A Game, 2023-06-12 )

[분석]

많은 개발자는 Steam 페이지를:

준비됐으니 오픈

한다.

Tiny Glade는:

관심이 가장 많이 모이는 순간에 페이지를 열어 모든 관심을 wishlist로 저장

했다.

이 차이는 크다.

소셜 조회수는 사라지지만 wishlist는 launch day demand inventory가 된다.

10. 마케팅 전략: “개발일지”가 아니라 완성된 마이크로 판타지를 보여줌

[사실]

GameDiscoverCo는 Tiny Glade의 초기 viral tweets, Future Games Show trailer 등 거의 모든 영상이 “이걸 직접 만져보고 싶다”는 감정을 즉시 전달했다고 평가했다. 개발팀은 WIP 기능을 꾸준히 영상으로 공개했고 launch 시점까지 137만 개 이상의 wishlist를 누적했다. (GameDiscoverCo, 2024-10-29 )

[분석]

여기서 흔한 “build in public”과 차이가 있다.

개발팀이 주로 보여준 것은:

• Jira
• 코드
• 개발고충
• 로드맵

이 아니었다.

사용자가 원하는 최종감정인:

“내가 저 벽을 드래그하면 이렇게 예쁘게 바뀌겠구나.”

를 반복해서 보여줬다.

좋은 prelaunch content는 제작과정 설명보다 제품 가치의 5초짜리 데모일 수 있다.

11. 데모 전략: 피드백 도구이면서 동시에 qualification 도구

[사실]

Ana는 데모의 가장 중요한 목적 중 하나가 “이 게임이 자기 취향인지 구매 전에 확인하게 하는 것”이라고 설명했다. Tiny Glade는 전통적 game이라기보다 toy box에 가까우므로 어떤 사람은 예상보다 좋아할 것이고, 어떤 사람에게는 애초에 맞지 않을 수 있다고 봤다. (80 Level, 2024-05-30 )

2024년 6월 Next Fest 무렵에는 100만 wishlist를 넘었고, 데모 반응이 좋아 종료 시점을 연장했다. (WN Hub, 2024-06-19 )

GameDiscoverCo가 받은 수치상 launch 시점 wishlist는 137만 개였으며, 여름 demo festival 자체가 추가한 wishlist는 약 20,000개였다. (GameDiscoverCo, 2024-10-29 )

[분석]

여기서 의외의 포인트는 Next Fest가 wishlist 전체를 만든 것이 아니라는 점이다.

1.37M wishlist 중 Next Fest 기여 약 20K.

즉 주요 growth engine은 훨씬 이전부터 존재했다.

데모의 핵심 가치는:

• 제품 이해
• 기대치 조정
• 구매전환 qualification
• UX 문제 발견
• creator가 실제 interaction을 보여줄 수 있는 소재

였다.

12. UX 개발: 기능 하나를 6~7번 다시 만들 정도로 상호작용에 집중

[사실]

개발팀은 일부 도구가 6~7개의 완전한 prototype을 거쳤다고 밝혔다. 내부 테스트 → 외부 playtest → 다시 설계하는 과정을 반복했고, 2년 개발 동안 다섯 번의 외부 playtest를 실시했다. (GameDiscoverCo, 2024-10-29 )

플레이테스터들이 lantern을 쌓아 나무벽을 흉내 내거나, stairs를 machicolation처럼 사용하는 행동을 보고 아예 정식 도구로 승격했다. 처음 계획에 없던 bridge도 사용자들이 반복적으로 원해 새로운 elevation system으로 발전했다. (80 Level, 2024-05-30 )

[분석]

좋은 feedback loop다.

사용자에게 “어떤 기능 원하세요?”라고 묻는 대신:

기존 도구를 억지로 써서 무엇을 만들고 있는가?

를 관찰했다.

이런 workaround는 실제 unmet need의 강한 증거다.

사용자가 lantern 20개를 쌓아 벽을 만들면 “lantern 기능 개선”보다 “나무벽 도구가 없다”는 뜻일 수 있다.

13. Launch strategy: self-publishing은 비용절감이 아니라 통제권 선택

[사실]

Pounce Light는 첫 게임인데도 퍼블리셔 없이 자체 출시했다. Ana는 이유를 두 가지로 설명했다.

1. 직접 퍼블리싱을 배워 미래에 publisher의 역할을 더 잘 이해하기 위해
2. 출시시점과 제품방향을 스스로 통제하기 위해

Tom도 AAA에서 개별 구성원이 전체 결정에 영향력이 제한적이었던 경험과 반대로, 이번에는 전권을 갖고 싶었다고 말했다. (80 Level, 2024-05-30 )

[분석]

이 사례를 “퍼블리셔는 필요 없다”로 읽으면 위험하다.

Tiny Glade는 self-publishing 전에 이미:

• 2명의 강한 senior 경험
• 수십만 wishlist
• 지속적인 viral social proof
• 명확한 visual hook

을 갖고 있었다.

즉 distribution risk가 이미 상당히 낮아진 상태였다.

재현 가능한 교훈은 “무조건 self-publish”가 아니라:

외부 자본·유통이 제공하는 가치보다 자율성의 가치가 큰지 숫자로 판단하라.

이다.

14. 가격·수익화: $14.99 premium, 목표도 패배도 없지만 충분히 돈을 받음

[사실]

출시 정가는 $14.99였고 2026년 9월 현재도 기본가격은 $14.99다. (Steam , Steambase, 2026-09 )

초기 한 달은 할인 없이도 강한 판매를 기록했다. GameDiscoverCo는 목표가 없는 자유형 toy에 $15를 받을 수 있었다는 점 자체를 특기할 만하다고 평가했다. (GameDiscoverCo, 2024-10-29 )

[분석]

전통적 게임 가격 논리는 종종:

플레이시간 / 가격

으로 흐른다.

하지만 Tiny Glade의 중앙값 플레이시간은 한 달 시점 1시간 4분에 불과했다. 그럼에도 리뷰는 97% 수준이었다. (GameDiscoverCo, 2024-10-29 )

이는 고객이 반드시 콘텐츠 시간만 사는 것이 아님을 보여준다.

고객은:

표현능력 + 감정상태 + 아름다운 output을 만드는 경험

에도 돈을 낸다.

창작앱 관점에서도 매우 중요한 사례다.

15. 타깃 사용자: city-builder보다 훨씬 넓다

GameDiscoverCo의 구매자 affinity에서는 Townscaper, Dorfromantik, Unpacking 같은 코지·추상적 창작 게임뿐 아니라 Banished, Manor Lords 같은 medieval builder와도 overlap이 나타났다. (GameDiscoverCo, 2024-10-29 )

제품 job 기준으로 보면 핵심 세그먼트는 다음과 같다.

[분석]

핵심은 “city builder”라는 장르명보다 창작행동을 좋아하는 사람을 타깃으로 했다는 것이다.

그래서 The Sims creator와 도시건설 creator가 모두 반응할 수 있었다.

16. Viral loop ①: 제품 사용 결과가 그대로 마케팅 소재

[사실]

GameDiscoverCo는 사용자들이 Helm’s Deep 같은 유명 장소를 재현한 영상이 활발히 공유됐다고 지적했다. launch traffic에도 cozy·Sims·city-builder 계열 creator가 모두 기여했다. (GameDiscoverCo, 2024-10-29 )

[분석]

구조는 다음과 같다.

도구 사용 → 예쁜 건축물 → screenshot/video → 소셜 공유 → “어떻게 만들었지?” → 신규 유입 → 새 창작물

즉 product usage와 acquisition asset이 같다.

Canva, Figma, Minecraft, dress-up app과 같은 output-led growth 구조다.

17. Viral loop ②: 유명 IP를 직접 계약하지 않아도 fandom이 마케팅을 만든다

[분석]

플레이어가:

• Lord of the Rings 성
• 역사적 건축물
• 유명 판타지 마을
• 실제 집

을 재현하면 Tiny Glade는 별도 IP crossover 없이 기존 fandom의 관심을 빌릴 수 있다.

이는 UGC 도구에서 특히 강력하다.

사용자의 관심사가 곧 제품의 마케팅 캠페인 테마가 된다.

개발팀이 매주 소재를 기획할 필요가 없다.

18. Retention: “목표”가 아니라 계속 떠오르는 다음 장면

Tiny Glade에는 quest·daily reward·battle pass가 없다.

[분석]

리텐션 동기는:

“다음에는 저런 성을 만들어 볼까?”

이다.

이런 제품은 session frequency가 전통 게임보다 낮을 수 있다. 실제 첫 달 당시 DAU 대 CCU 비율이 약 30배로, 일반적으로 더 sticky한 게임의 8~10배보다 높았다. GameDiscoverCo는 이를 “많은 사람이 짧게 들어오는 구조”로 해석했다. (GameDiscoverCo, 2024-10-29 )

즉 Tiny Glade의 건강성을 MMORPG식 session time으로 평가하면 안 된다.

더 적절한 지표는:

• 창작물 완료율
• 재방문 시 새 glade 시작률
• screenshot 생성률
• 공유율
• 업데이트 후 reactivation

일 가능성이 높다.

공식 수치는 공개되지 않았다.

19. Operational leverage ①: 프로시저럴 시스템이 ‘콘텐츠 생산자’ 역할

[사실]

팀은 모든 벽돌을 사람이 직접 배치하는 대신 여러 generator가 형태를 조립·변형하게 만들었다. 기술적으로는 modified Bevy + Rust, 자체 Vulkan 기반 rendering pipeline을 크게 활용했다. (80 Level, 2024-05-30 )

[분석]

2인 팀이 넓은 건축 표현을 제공할 수 있었던 핵심이다.

새 “벽” 하나를 만들 때 prefab 수백 개를 수동제작하는 대신:

규칙 + 변형 + 연결조건

을 만든다.

그 규칙은 사용자가 수천 가지 형태를 만들 때 재사용된다.

즉 개발자 1시간이 플레이어 1시간에 반복 소비되지 않고 플레이어의 무한 조합으로 증폭된다.

20. Operational leverage ②: 저사양 PC까지 동일한 미학을 목표로 함

[사실]

개발팀은 높은 사양에서만 아름다운 옵션을 제공하기보다, 가능한 한 모든 기기에서 비슷한 미학을 보게 만드는 것을 목표로 했다고 밝혔다. low-end PC에서도 조명경험을 유지하기 위해 렌더링 기술을 반복개선했다. (GameDiscoverCo, 2024-10-29 )

[분석]

이 선택은 단순 기술완성도가 아니다.

Tiny Glade의 가장 중요한 acquisition asset이 예쁜 화면이므로 저사양에서 비주얼이 크게 나빠지면:

기술문제 = 마케팅문제

가 된다.

제품가치와 rendering target이 직접 연결됐다.

21. Operational leverage ③: 최신 2026 업데이트에서도 “사용자 확장성”으로 이동

[사실]

2026년 9월 1.16 베타에는 wooden walls, plants, 그룹 이동·회전뿐 아니라 Steam Workshop 지원과 mod clutter를 쉽게 제작하는 in-game mod editor가 포함돼 있다. 개발팀은 완전한 arbitrary modding은 아니지만, 기존 asset replacement mods와 새 clutter를 Workshop으로 공유할 수 있게 하고 있다. (Steam Community, 2026-09-07~08 )

[분석]

제품의 운영레버리지가 한 단계 바뀌고 있다.

초기:

개발자가 규칙을 만들고 사용자가 건축

2026:

사용자가 건축뿐 아니라 일부 콘텐츠 asset까지 추가

할 수 있게 된다.

2인 팀에게 매우 자연스러운 장기 전략이다.

22. key inflection points

성공을 시간순으로 압축하면 다음과 같다.

주말 rendering experiment
→ 프로시저럴 벽 영상이 X에서 반응
→ TikTok으로 비개발자 반응 검증
→ “실제 게임으로 만들 수 있다” 판단
→ 2인 full-time indie 전환
→ 2022-12 Wholesome 이벤트 + Steam 페이지 동시 공개
→ 24시간 10K wishlist
→ 4개월 420K+
→ 지속적인 WIP 영상·Future Games Show
→ 세밀한 playtest와 도구 6~7회 반복설계
→ bridge·elevation 등 사용자 workaround를 제품기능으로 승격
→ 2024-06 1M wishlist + Next Fest
→ demo 연장
→ 2024-09 launch / 1.375M wishlist
→ 10.7K peak CCU
→ 출시 한 달 이내 616K copies
→ UGC·creator long tail
→ 2025 stairs 대형 업데이트
→ 2026 macOS 지원
→ 2026-09 Workshop·wooden walls 베타

23. 왜 성공했나: 가장 설명력 높은 인과모형

Tiny Glade의 성공을 단순히 “cozy trend”로 설명하기에는 부족하다.

더 설명력 높은 구조는 다음과 같다.

전문성이 높은 프로시저럴/렌더링 창업자 조합
× 적은 입력으로 많은 결과를 내는 interaction
× 실패할 수 없는 창작환경
× 과정 자체가 영상으로 아름다운 product
× 일찍 시작된 social proof
× Steam 페이지 공개 이벤트를 한 지점에 집중
× 2년간 누적된 wishlist inventory
× 데모로 구매 적합성을 미리 확인
× UGC가 마케팅으로 환류
× 셀프 퍼블리싱으로 제품과 브랜드 일관성 유지

24. 대안 가설 A — “cozy 게임 붐을 탔다”

[사실]

개발자 자신도 Townscaper, Unpacking, A Little to the Left 같은 작품을 즐겼고, 초기부터 cozy 방향을 의식했다. (80 Level, 2024-05-30 )

[분석]

시장 tailwind는 분명 존재했다.

하지만 cozy라는 라벨만으로 137만 wishlist를 설명할 수는 없다.

Tiny Glade의 독특한 점은 cozy aesthetic이 아니라 cozy interaction이다.

실패·비용·정렬·자원관리 같은 긴장을 시스템 수준에서 제거했다.

25. 대안 가설 B — “예뻐서 바이럴됐다”

맞는 말이지만 불완전하다.

[분석]

예쁜 게임은 많다.

Tiny Glade는 **예쁜 결과가 ‘사용자의 작은 동작 때문에 즉시 탄생하는 장면’**이 바이럴했다.

즉 정적인 visual quality가 아니라:

visual transformation per second

가 강했다.

이것이 trailer와 TikTok에서 훨씬 강한 차이를 만든다.

26. 대안 가설 C — “Steam Next Fest가 대박을 만들었다”

[사실]

Next Fest 당시 이미 80만~100만 수준 wishlist가 있었고, 최종 137만 wishlist 중 여름 festival에서 추가된 것은 개발팀 수치상 약 20,000개였다. (GameDiscoverCo, 2024-10-29 , WN Hub, 2024-06-19 )

[분석]

따라서 Next Fest는 원인보다 검증·증폭기였다.

주 성장곡선은 이미 2022~2024에 형성돼 있었다.

27. 대안 가설 D — “2인 팀이라 효율적이었다”

2명이라 coordination cost가 낮은 것은 사실이다.

하지만 핵심은 인원수가 아니라 두 사람이 가진 기술의 희소성이다.

프로시저럴 아트·GPU generation·Vulkan renderer·interaction design을 일반적인 2인 junior team이 동일 속도로 재현하기 어렵다.

판단

팀 크기는 반복 가능하지만 skill density는 context-specific이다.

28. 대안 가설 E — “UGC가 성공시켰다”

UGC는 강력한 launch·long-tail engine이었다.

하지만 사용자가 공유하는 건 “에디터가 존재하기 때문”이 아니다.

[분석]

UGC 루프가 작동한 더 깊은 이유는:

1. 초보자도 결과가 예쁨
2. 결과가 개인적임
3. 외부 팬덤 소재를 재현 가능
4. screenshot 한 장만으로 가치가 보임
5. 만드는 과정도 영상으로 재미있음

이다.

UGC 기능만 넣으면 되는 문제가 아니다.

29. 위험과 한계

위험 1 — 낮은 전통적 리텐션

첫 달 중앙값 플레이시간은 1시간 4분이었다. (GameDiscoverCo, 2024-10-29 )

게임에 목표·진행·전투가 없기 때문에 플레이어가 “한두 작품 만들고 끝”낼 가능성이 높다.

한계

장기 매출을 live-service 방식으로 기대하기 어렵고, 신규콘텐츠·플랫폼·Workshop 같은 reactivation surface가 중요하다.

위험 2 — 사용자가 더 많은 ‘게임’을 요구할 수 있음

일부 사용자에게는 NPC, 경제, larger maps, interiors 등이 자연스러운 다음 요구가 된다.

하지만 이를 모두 넣으면 Tiny Glade가 최초에 제거했던 complexity가 다시 들어온다.

분석

장기 roadmap의 가장 큰 위험은 고객요청을 따라가다 제품 thesis를 잃는 것이다.

위험 3 — 프로시저럴 시스템의 edge-case debt

[사실]

브리지·계단·높이 조절 같은 기능 하나가 추가될 때 기존 generator와 수많은 상호작용을 처리해야 했다. 2025 stair update는 여러 시스템 rewrite가 필요했고 팀은 이를 역대 가장 큰 업데이트라고 표현했다. (Steam Community, 2025-07-29 )

[분석]

프로시저럴 leverage의 반대편은 combinatorial maintenance debt다.

새로운 도구 하나가 전체 시스템과 통합돼야 한다.

위험 4 — 기술이 너무 custom이라 플랫폼 확장이 비쌀 수 있음

2026 macOS 지원을 위해 개발팀은 그래픽 엔진의 절반가량을 다시 썼다고 밝혔다. (SteamDB/Steam notes, 2026-05-13 )

분석

자체 기술은 제품 차별화를 가능하게 했지만, 표준엔진의 platform ecosystem을 포기한 비용도 있다.

위험 5 — 두 명의 key-person concentration

제품 핵심이 두 사람의:

• procedural art taste
• rendering expertise
• UX 판단
• community communication

에 강하게 집중돼 있다.

성공 후 장기운영에서 bus factor·burnout risk가 크다.

위험 6 — viral social distribution은 예측 불가능

초기 X·TikTok 영상이 반복적으로 터진 것은 큰 행운도 포함한다.

같은 품질의 clip을 만든다고 모든 제품이 알고리즘 노출을 얻는 것은 아니다.

재현 가능한 것은 viral을 보장하는 것이 아니라 viral됐을 때 Steam wishlist로 포착할 구조를 만들어 두는 것이다.

30. 무엇이 맥락 특수적이고 무엇이 반복 가능한가

31. 다른 인디 개발자가 우선 벤치마킹할 항목

32. 이번 사례에서 바로 적용할 수 있는 실행 아이디어

실험 1 — 5초 Transformation Test

현재 제품의 핵심 interaction을 5초짜리 silent GIF 세 개로 만든다.

A. 기능 시작 전 → 결과
B. 사용자가 drag/click → 시스템 반응
C. 완성 결과만 보여줌

100명에게 무작위 노출하고 다음을 측정한다.

• “무엇을 하는 제품인지 이해” 비율
• 직접 해보고 싶은 비율
• 저장·공유 의향
• B vs C 차이

목표: 결과보다 interaction 과정이 더 강한 acquisition asset인지 확인한다.

실험 2 — Output / Input Minute KPI

창작 제품에서 15분 세션 후 사용자에게 공유할 만한 결과물을 몇 개 만들었는지 센다.

공유 의향 있는 output 수 / active minutes

를 cohort별로 비교한다.

기능을 추가하기 전에 이 비율을 올릴 수 있는 자동화·smart default·procedural detail을 우선한다.

실험 3 — No Wrong Answer A/B

A 버전:

잘못 놓으면 에러·빨간 표시·placement 실패

B 버전:

시스템이 자동보정·snap·morph해서 가능한 형태로 만듦

측정:

• 첫 10분 undo 횟수
• abandon rate
• 자발적 실험 수
• 완성 screenshot 생성률

Tiny Glade의 핵심은 기능 추가가 아니라 실패를 예쁜 변형으로 바꾸는 것이다.

실험 4 — Workaround Mining Session

playtest 20명의 화면을 녹화한다.

사용자가:

• 같은 오브젝트를 반복 쌓음
• 특정 기능을 이상한 용도로 씀
• 3단계 이상 우회함
• 외부 툴까지 사용함

을 전부 태깅한다.

가장 많이 반복되는 workaround 3개를 전용 기능 prototype으로 만든다.

Tiny Glade의 bridge·machicolation 사례처럼 요청문보다 행동을 roadmap에 반영한다.

실험 5 — Six-Prototype Rule

가장 핵심인 interaction 하나는 첫 구현을 shipping하지 않는다.

같은 기능을 최소 4~6개 방식으로 만들고 다음 지표로 평가한다.

• 설명 없는 성공률
• 첫 성공까지 시간
• misclick
• undo
• 만족도
• “다시 써보고 싶다”

기능 자체보다 feel이 판매 포인트인 제품에 적합하다.

실험 6 — Steam Page Surge Calendar

Steam 페이지를 조용히 공개하지 않는다.

페이지 공개 주간에:

• 이름 발표
• gameplay trailer
• festival/online showcase
• creator outreach
• social clips 3~5개
• mailing list

를 한꺼번에 집중한다.

측정:

• Day-1 wishlist
• Day-7 wishlist
• Steam organic recommendation 비율
• social → Steam click

Tiny Glade의 benchmark는 공개 24시간 10K wishlist였지만, 절대 수치를 목표로 삼기보다 baseline 대비 surge multiplier를 측정한다.

실험 7 — TikTok vs Dev-Audience Validation

기술적으로 신기한 prototype이 개발자 사이에서 반응했을 때 바로 제품화하지 않는다.

동일 영상을:

A. gamedev 커뮤니티
B. 일반 소비자 중심 TikTok/Reels/Shorts

에 올린다.

측정:

• completion rate
• comments 중 “어떻게 구현?” vs “직접 써보고 싶다” 비율
• wishlist/click

기술 admiration과 consumer demand를 분리한다.

실험 8 — Demo as Qualification

데모 KPI를 다운로드 수만 보지 않는다.

설문에 한 문항을 추가한다.

“정식 버전을 살 가능성이 낮다면 가장 큰 이유는?”

그리고 다음을 분리한다.

• 제품 자체가 취향 아님
• 기능 부족
• 가격
• UX 난이도
• 성능

“취향 아님”이 높아져도 반드시 나쁜 것은 아니다. 정식 구매 전에 wrong-fit을 걸러내면 리뷰·환불 측면에서 이득일 수 있다.

실험 9 — UGC External-Fandom Test

도구형 제품이라면 사용자가 제품 밖의 대상을 재현할 수 있는지 본다.

예:

• 유명 영화 장소
• 현실 건물
• 밈
• 게임 캐릭터 테마

공식 contest 없이도 이런 창작물이 자발적으로 발생하는지 30일 측정한다.

KPI:

• 외부 IP/현실 대상 재현 UGC 비율
• UGC당 외부 share
• 신규 방문 유입

실험 10 — Procedural Leverage Score

신규 기능 후보마다 다음을 계산한다.

플레이어가 만들 수 있는 새로운 결과의 수 ÷ 개발일

예:

• 고정 성 prefab 10개 추가: 결과 10 / 10일
• wall morph rule 1개: 수백 조합 / 5일

후자를 우선한다.

실험 11 — Short Session Satisfaction Test

목표 없는 제품이라면 플레이시간을 무조건 늘리지 않는다.

20분 cohort와 60분 cohort에서:

• 만족도
• 리뷰 의향
• 재방문 의향
• screenshot 생성

을 비교한다.

Tiny Glade처럼 짧은 중앙 플레이시간에도 높은 만족도가 가능하다면 “더 오래 붙잡기”가 최적화 목표가 아닐 수 있다.

실험 12 — Self-Publish Decision Matrix

퍼블리셔 계약 전 다음을 1~5점으로 평가한다.

이미 distribution signal이 매우 강하고 control 가치가 크다면 self-publish가 합리적일 수 있다. 반대로 Tiny Glade의 결과만 보고 퍼블리셔를 자동으로 배제하면 안 된다.

실험 13 — Low-End Visual Parity Budget

제품의 판매 포인트가 시각품질이라면 최고사양 FPS만 최적화하지 않는다.

세 등급 PC에서 동일 장면 screenshot을 비교하고 사용자에게 블라인드 평가한다.

• high-end
• mainstream laptop
• minimum-spec

“제품의 대표 이미지를 80% 이상 유지” 같은 threshold를 둔다.

실험 14 — Workshop Before Content Team

업데이트 요청이 늘어날 때 내부 콘텐츠 인력을 먼저 늘리기보다 제한된 mod surface를 열어본다.

예:

• props
• skins
• templates
• maps
• presets

측정:

• 신규 UGC 수
• update 후 reactivation
• support cost
• crash rate
• 사용자 생성 asset 다운로드

Tiny Glade의 2026 Workshop 방향처럼 작은 팀의 콘텐츠 공급을 community와 분담한다.

33. 표면적으로 복제하면 안 되는 것

Tiny Glade를 보고 쉽게 따라 할 수 있는 것은:

코지 색감
작은 양
중세 성
프로시저럴 건물
목표 없음

이다.

하지만 이 조합을 복제하는 것은 성공공식의 껍데기에 가깝다.

실제로 가져갈 것은 더 깊다.

사용자가 가장 원하는 창작결과와 실제 제작능력 사이의 거리를 시스템이 줄여준다.

→ 사용자의 한 번의 gesture를 여러 층의 자동화로 증폭한다.

→ 잘못된 입력을 막기보다 보기 좋은 결과로 흡수한다.

→ 제품을 사용하는 과정 자체가 short-form content가 되게 만든다.

→ 소셜 관심이 생긴 순간을 storefront wishlist로 저장한다.

→ 사용자가 기존 도구를 억지로 변형하는 행동을 관찰해 다음 기능을 만든다.

→ 사용결과가 다른 팬덤·문화와 연결될 수 있게 한다.

→ 작은 팀은 수동 콘텐츠 생산보다 시스템·UGC leverage를 선택한다.

34. 최종 결론

Tiny Glade의 눈에 띄는 숫자는 다음과 같다.

핵심 개발자 2명
약 2년 본격 개발
Steam 페이지 첫 24시간 10K wishlist
약 4개월 420K+ wishlist
2024-06 1M wishlist
launch 시점 1,375,441 wishlist
peak CCU 약 10,692
출시 1개월 미만 616K+ copies
34K+ DAU
중앙값 플레이 1h 4m
미국 매출 비중 32%
2026-09 Steam 약 24.5K reviews / 97% positive

그러나 다른 인디 개발자가 가장 주목해야 할 숫자는 61만 장보다 6~7개 prototype일 수 있다.

Pounce Light는 핵심 tool 하나를 여러 번 완전히 다시 만들 정도로 interaction을 다듬었다. (GameDiscoverCo, 2024-10-29 )

두 번째로 중요한 숫자는 10,000이다.

Steam 페이지가 열린 첫 24시간에 1만 wishlist가 모였다. 이건 단순히 게임이 예뻤기 때문만이 아니라, 이미 WIP social audience가 있었고 이벤트·트레일러·Steam 페이지를 같은 순간에 결합했기 때문이다. (How To Market A Game, 2023-06-12 )

세 번째는 1시간 4분이다.

일반적인 게임 KPI라면 짧아 보이지만 실제 사용자 만족도는 압도적으로 높았다. 이것은 Tiny Glade가 콘텐츠 소모형 게임이 아니라 창작 경험을 파는 software toy였기 때문에 가능했다. (GameDiscoverCo, 2024-10-29 )

가장 반복 가능한 성공공식을 한 문장으로 줄이면 다음과 같다.

“적은 입력으로 놀랄 만큼 좋은 결과를 만들고, 그 결과가 자연스럽게 공유되며, 공유에서 생긴 관심을 출시 전에 wishlist로 축적하는 제품.”

다른 인디 개발자가 먼저 던져볼 질문은 네 가지다.

“우리 제품은 사용자의 1분을 몇 배짜리 결과로 증폭하는가?”

“사용자가 실수했을 때 에러를 보여주는가, 아니면 시스템이 좋은 결과로 바꿔주는가?”

“제품을 사용하는 실제 화면 5초가 광고영상보다 강한가?”

그리고 가장 중요하게:

“사용자가 만든 결과가 그 자체로 다음 사용자를 데려오는가?”

Tiny Glade의 강점은 단순히 코지하거나 예쁜 것이 아니라, 프로시저럴 기술을 제작비 절감용이 아니라 사용자의 창작능력 증폭과 distribution loop에 연결했다는 것이다.

주요 출처와 게시일