Tiny Glade 성공 사례 분석

이번 사례는 스웨덴의 2인 인디 스튜디오 Pounce Light가 만든 Tiny Glade다. 최근 다룬 Buckshot Roulette, Schedule I, Content Warning, A Game About Digging A Hole, Animal Well 등과 겹치지 않으면서도, 작은 팀이 제품 설계와 배포를 어떻게 한 몸처럼 만들 수 있는지를 보여주는 사례다.

Tiny Glade는 전통적인 도시 건설 게임의 핵심 요소를 상당수 제거했다. 자원 관리도 없고, 전투도 없고, 승패도 없고, 목표도 없다. 대신 플레이어가 벽과 길을 낙서하듯 그리면 시스템이 문, 아치, 기둥, 지붕, 디테일을 상황에 맞게 자동 생성한다. 개발사 스스로 게임을 “diorama를 만드는 toy box”에 가깝다고 설명한다. (Steam, 현행 제품 페이지 , 80 Level, 2024-05-30 )

2024년 6월 16일에는 Steam 위시리스트 100만 건을 돌파했고, 그보다 앞선 6월 초에도 이미 80만 건을 넘어 Steam Next Fest 최대 기대작 중 하나로 언급됐다. 정식 출시 2주 뒤에는 개발사가 50만 명 이상이 플레이했다고 발표했다. 2026년 9월 확인 기준 SteamDB에는 역대 최고 동시접속자 10,692명, 긍정 리뷰 23,902개, 부정 리뷰 662개가 집계돼 있다. 기본 가격은 여전히 $14.99다. (Steam 공식 100만 위시리스트 공지, 2024-06-16 , PC Gamer, 2024-10-15 , SteamDB, 2026-09 확인 )

다만 중요한 제한이 있다. 공식 누적 판매량과 공식 매출은 공개되지 않았다. “50만 명 이상 플레이”는 개발사가 공개한 플레이어 수이지 판매량이라고 명시된 숫자가 아니다. 외부 판매량·매출 추정치는 여기서 확정 데이터로 사용하지 않는다.

핵심 지표와 타임라인

공개 자료가 없는 숫자

다음 수치는 신뢰할 만한 1차 공개 자료에서 확인되지 않는다.

• 공식 lifetime copies sold
• 공식 gross revenue 및 net revenue
• 개발 예산
• CAC 및 유료 광고비
• 위시리스트→구매 전환율
• 환불률
• D1/D7/D30 retention
• 평균 플레이타임의 공식 개발사 통계
• 지역별 판매 비중
• 사운드트랙 DLC 매출

따라서 이 글에서는 해당 수치를 추정하지 않는다.

1. 창업자·개발자 맥락: 첫 게임이지만 첫 기술 실험은 아니었다

[확인된 사실]

Pounce Light의 핵심 개발자는 Anastasia Opara와 Tomasz Stachowiak 두 명이다. 두 사람은 합쳐 15년 이상의 게임 업계 경험이 있었고 Embark Studios, Electronic Arts, Creative Assembly 등 AAA 환경에서 일한 경력이 있다. Opara는 procedural art에 약 10년 가까운 경험이 있었고, Stachowiak은 렌더링 기술에 강점을 갖고 있었다. (80 Level, 2024-05-30 , GamingOnLinux, 2024-06 )

Opara는 Tiny Glade 초기에는 Embark Studios에서 풀타임으로 일하면서 새벽 4시에 일어나 오전 9시 업무 시작 전까지 사이드 프로젝트를 진행했다고 회고했다. 처음 목적은 게임을 만드는 것이 아니라 렌더링과 GPU 기반 procedural generation을 실험하는 것이었다. (80 Level, 2024-05-30 )

[분석]

“2명이 만든 첫 인디 게임”이라는 서술은 맞지만, “2명의 초보가 처음 코드를 배워 만든 게임”과는 전혀 다르다.

이 성공의 기반에는 다음과 같은 누적 자산이 있었다.

1. 거의 10년짜리 procedural art 경험
2. AAA 렌더링·엔진 경험
3. Rust/Bevy에 대한 높은 기술 숙련도
4. 소셜 미디어에 기술 데모를 설명 가능하게 보여주는 능력
5. 두 사람이 서로 다른 전문성을 결합할 수 있는 팀 구조

따라서 재현해야 할 것은 “2명”이 아니라 작은 팀 안에서 제품의 핵심 난제를 거의 모두 덮을 수 있는 보완적 전문성이다.

2. 제품의 출발점: 게임 아이디어가 아니라 ‘보고 싶은 기술 데모’였다

[확인된 사실]

Tiny Glade는 처음부터 성을 만드는 게임으로 기획된 것이 아니다. Opara가 Bevy와 Rust로 만든 procedural wall generator가 출발점이었다. 벽이 곡선에 맞게 변형되고, 지형에 반응하고, 창문과 기둥이 자동으로 어울리는 기술 실험이 소셜 미디어에서 예상 밖의 반응을 얻었다. (80 Level, 2022-04-07 , 80 Level, 2023-09-14 )

개발팀은 초기 Twitter 반응이 단순히 “기술적으로 인상적이기 때문”일 가능성을 의심했다. 그래서 게임 개발자·그래픽 프로그래머가 아닌 일반 사용자에게도 먹히는지 검증하기 위해 TikTok 계정을 만들었다. Opara는 이때 관심이 크게 늘면서 “이게 실제 게임이 될 수 있겠다”고 판단했다고 말했다. (80 Level, 2024-05-30 )

[분석]

이 과정은 인디 제품 검증에서 매우 중요한 두 단계를 분리한다.

전문가가 좋아하는 기술인가?

과

일반 소비자가 돈을 내고 만져보고 싶은 경험인가?

는 다른 질문이다.

Pounce Light는 첫 번째 반응을 두 번째 수요로 착각하지 않았다. TikTok이라는 다른 audience에서 같은 소재를 보여주면서 technical admiration → consumer desire가 실제로 변환되는지 확인했다.

인디 개발자가 기술 데모로 반응을 얻었을 때 바로 2년짜리 제작에 들어가기보다, 비전문가 채널에서 동일한 반응이 나오는지 확인하는 것이 재현성이 높다.

3. 제품 thesis: “건축 게임”에서 건축 스트레스를 제거한다

[확인된 사실]

Steam 공식 설명은 Tiny Glade를 “small diorama builder”라고 부르며 다음을 명확하게 강조한다.

• gridless building
• management 없음
• combat 없음
• goals 없음
• procedural detail
• 편안하게 만들고 감상하는 경험

(Steam )

개발팀 역시 플레이어를 끊임없이 자극하는 이벤트나 목표를 넣지 않으려 했고, 레고처럼 도구를 건네고 플레이어가 자기 이야기를 만들게 하는 것이 목표라고 설명했다. (80 Level, 2024-05-30 )

[분석]

Tiny Glade의 포지셔닝은 새로운 기능을 추가하는 방식이 아니라 기존 장르의 부담을 빼는 방식이었다.

전통적인 도시 건설 게임은 대개 다음을 요구한다.

자원 → 효율 → 인구 → 교통 → 목표 → 실패 가능성

Tiny Glade는 이것을 거의 전부 제거한다.

그리기 → 시스템이 예쁘게 정리 → 감상 → 더 그리기

즉 핵심 제품가치는 “더 깊은 시뮬레이션”이 아니라 예쁘게 만들기 위해 알아야 할 것을 줄이는 것이다.

이것은 포지셔닝 측면에서 매우 강하다. Manor Lords나 Cities: Skylines와 같은 복잡한 도시 건설 게임과 기능 대 기능으로 경쟁하지 않는다. 오히려 다음처럼 다른 job-to-be-done을 잡는다.

“도시를 운영하고 싶다”가 아니라

“내가 만든 예쁜 장소를 보고 싶다.”

4. 핵심 UX: 사용자가 명령하면 시스템이 ‘마무리’를 대신한다

[확인된 사실]

Tiny Glade의 procedural system은 플레이어 행동을 해석해 디테일을 자동으로 맞춘다. 예를 들어 길을 벽에 통과시키면 문이나 아치가 생기고, 건물을 들어 올리면 기둥이나 지지 구조가 나타나며, 건물들이 붙으면 접합부가 자연스럽게 정리된다. (Steam , 80 Level, 2024-01-26 )

개발팀은 이런 반응성을 “게임이 플레이어가 무엇을 하는지 알아차리고 그 순간만을 위해 결과를 맞춰주는 느낌”이라고 설명했다. (80 Level, 2024-05-30 )

[분석]

Tiny Glade의 procedural generation은 콘텐츠 절감 기술이기 전에 UX 자동완성 기술이다.

보통 건축 게임에서 사용자는 다음을 직접 처리한다.

벽 생성 → 문 구멍 생성 → 문 배치 → 지붕 정리 → 접합부 수정 → 장식

Tiny Glade에서는 사용자가 대략적인 의도를 그리면 시스템이 나머지를 처리한다.

이 구조는 생성형 AI와도 다르다. 사용자가 결과 전체를 요청하는 것이 아니라 사용자 행동을 보존하면서 마찰이 큰 마감 작업만 자동화한다.

소규모 앱에도 그대로 적용할 수 있다.

• 디자인 앱: 배치 의도는 사용자가 결정, 정렬·간격은 자동 보정
• 문서 앱: 구조는 사용자가 쓰고, 반복 포맷은 자동화
• 코딩 도구: 핵심 로직은 사용자가 만들고 boilerplate를 자동 생성
• 게임 제작 도구: 큰 형태는 사용자가 만들고 연결부를 자동 처리

핵심은 “자동 생성”이 아니라 사용자가 통제감을 잃지 않는 자동 보정이다.

5. 성공의 중요한 원칙: 초보자 output의 바닥을 높인다

[분석]

UGC 제품의 가장 큰 문제는 초보 사용자가 만든 결과가 보기 좋지 않다는 것이다.

결과가 못생기면 사용자는:

만들기 싫어지고 → 공유하지 않고 → 다른 사람도 제품을 발견하지 못한다.

Tiny Glade는 procedural detail을 통해 이 바닥을 높인다.

벽이 조금 어설퍼도:

• 기둥이 생기고
• 지붕이 맞춰지고
• 창문이 자연스럽게 섞이고
• 잡동사니가 배치되고
• 식생이 둘러싸고
• 조명이 분위기를 만든다.

즉 사용자의 실력 분산을 시스템이 흡수한다.

이것이 마케팅과 직접 연결된다. 초보자도 screenshot-worthy 결과를 만든다.

따라서 Tiny Glade의 viral loop를 이해할 때 procedural generation은 단순 그래픽 기능이 아니라 acquisition 기능이다.

6. undo/redo조차 제품 철학과 일치한다

[확인된 사실]

공식 기능 설명에는 모든 행동에 animated undo/redo가 있고 “wrong answers가 없다”는 점이 포함된다. (GamingOnLinux, 2024-06 )

[분석]

건축 도구에서 가장 큰 심리적 마찰 중 하나는:

“잘못 만들면 망치지 않을까?”

다.

Tiny Glade는 실수 비용을 거의 0으로 만든다.

이것은 cozy aesthetic보다 더 구조적인 선택이다.

relaxation = pastel color

가 아니라

relaxation = 의사결정 실패 비용이 낮음

이다.

다른 제품에서도 “편안함”을 만들고 싶다면 색상보다 먼저 다음을 봐야 한다.

• undo 가능한가
• preview 가능한가
• 실수 복구가 즉시 가능한가
• 삭제보다 수정이 쉬운가
• 사용자가 탐색 중 손실을 두려워하는가

7. 타깃 사용자: 건축 시뮬레이션 유저보다 더 넓었다

공식 cohort 데이터는 공개되지 않았다. 아래는 제품과 커뮤니티 행동을 기반으로 한 분석이다.

[분석]

Tiny Glade가 “cozy city builder”라서 성공했다고만 보면 범위를 너무 좁힌다.

더 정확한 타깃은:

복잡한 도구를 배우지 않고 예쁜 3D 공간을 만들고 싶은 사람

이다.

그래서 전통 게임 유저뿐 아니라 일러스트레이터, 건축 취미 사용자, 소셜 미디어 creator까지 들어온다.

8. 개발 전략: 작은 기능을 만드는 대신 ‘조합되는 규칙’을 만든다

[확인된 사실]

개발자 인터뷰에 따르면 Tiny Glade는 하나의 거대한 알고리즘이 아니라 벽, 창문, 지붕, 구조물 등 요소별로 많은 procedural generator와 조립 규칙을 사용한다. 플레이테스트에서 사용자가 원래 의도하지 않은 방식으로 도구를 조합하는 것을 본 뒤 다리, elevation, machicolation 같은 기능이 새롭게 생기기도 했다. (80 Level, 2024-05-30 )

[분석]

작은 팀에게 이 구조가 중요한 이유는 콘텐츠 배수 때문이다.

새 오브젝트 하나는 그 오브젝트 하나만 추가한다.

하지만 새 rule 하나는:

기존 벽 × 기존 지붕 × 기존 높이 × 기존 색상 × 기존 terrain

전체와 결합한다.

따라서 Tiny Glade는 asset count보다 state space를 키우는 개발을 했다.

이것이 2명 팀이 수십만 사용자에게 오래 만질 수 있는 creative sandbox를 제공할 수 있었던 이유 중 하나다.

9. 엔진 선택은 목적이 아니라 제품 경험을 위한 수단이었다

[확인된 사실]

초기 prototype은 Bevy와 OpenGL로 시작했다. 프로젝트가 커지자 개발팀은 Vulkan 기반으로 렌더링 파이프라인을 크게 확장했고, Bevy도 수정해서 사용했다. 이유는 GPU compute와 procedural generation을 세밀하게 통제하고 Linux 등을 포함한 cross-platform을 고려하기 위해서였다. (80 Level, 2024-05-30 )

2026년 macOS 지원 과정에서는 개발팀이 “graphics engine의 절반을 다시 썼다”고 표현할 정도의 추가 작업이 필요했다. (Steam 공식 공지 모음, 2026-05-13 )

[분석]

Tiny Glade는 “커스텀 엔진을 만들면 성공한다”는 사례가 아니다.

오히려 반대다.

제품 차별화가 엔진 수준의 제어를 요구했기 때문에 커스텀 기술을 감수했다.

대부분의 인디 게임은 이 정도 제어가 필요하지 않는다.

따라서 벤치마킹할 질문은:

“우리도 Bevy/Rust를 쓸까?”

가 아니라

“제품의 가장 중요한 UX를 구현하려면 어떤 기술적 통제가 반드시 필요한가?”

다.

10. Distribution 1단계: 개발 과정을 광고로 바꿨다

[확인된 사실]

초기 procedural wall 영상이 Twitter에서 반응을 얻었고, 일반 사용자 수요를 확인하려 만든 TikTok에서도 관심이 커졌다. 80 Level 같은 기술·아트 매체는 2022년부터 창문, 벽, 지붕, terrain, procedural clutter 같은 개발 진행을 꾸준히 기사화했다. (80 Level, 2022-04-07 , 80 Level, 2023-09-14 )

[분석]

“build in public”이 잘 작동한 이유는 창업자 일기를 길게 썼기 때문이 아니다.

각 개발 작업 자체가 짧은 시각 데모였다.

예:

창문을 드래그 → 벽이 자연스럽게 깨짐

건물 두 개를 붙임 → 접합부가 자동으로 정리됨

탑 높이를 바꿈 → 지붕 타일이 실시간으로 재배치됨

이런 장면은 기술 업데이트이면서 동시에 제품 광고다.

따라서 개발시간과 마케팅시간이 완전히 분리되지 않는다.

feature work → GIF → social proof → wishlist

가 하나의 loop다.

11. 첫날 1만 위시리스트, 6개월 후 42만

[확인된 사실]

Pounce Light의 과거 공개 수치를 인용한 WN Hub에 따르면 Steam 노출 초기 24시간에 약 10,000 wishlist, 약 6개월 뒤 **420,000+**를 기록했다. (WN Hub, 2024-06-19 )

[분석]

중요한 것은 이 게임이 launch 직전에 마케팅을 시작한 것이 아니라는 점이다.

Steam 출시까지 거의 2년 동안:

새 interaction 공개 → social reaction → wishlist accumulation

이 반복됐다.

대형 광고 캠페인 대신 개발 속도와 distribution 속도를 동기화했다.

12. Distribution 2단계: Demo는 단순 체험판이 아니라 ‘적합성 필터’였다

[확인된 사실]

Opara는 demo를 만든 주된 이유가 사람들이 구매 전에 “이 게임이 자기 취향인지” 확인하게 하는 것이었다고 설명했다. Tiny Glade가 전통적인 게임보다 장난감에 가까워 어떤 사람은 매우 좋아하고 어떤 사람은 “좋지만 내 취향은 아니다”라고 느낄 수 있다고 했다. (80 Level, 2024-05-30 )

2024년 6월 데모는 약 360,000명이 체험했고 12,000개 이상의 의견·리뷰가 쌓였다. (80 Level, 2024-07-04 )

[분석]

보통 demo를 acquisition funnel로만 본다.

많이 플레이 → 많이 wishlist.

Tiny Glade에서는 두 번째 역할이 더 중요했다.

잘못된 고객이 구매하기 전에 스스로 빠져나가게 한다.

목표도 없고 management도 없는 게임을 $14.99에 샀다가 “할 게 없다”고 느끼는 고객을 줄이는 것이다.

즉 demo는 conversion maximizer이면서 동시에 expectation alignment tool이다.

이것은 높은 리뷰 점수와도 연결될 수 있다. 정확한 인과 수치는 공개되지 않았지만, 2026년에도 SteamDB상 긍정 비율이 약 97%라는 점은 적어도 기대치 불일치가 대규모로 발생하지 않았음을 보여준다. (SteamDB )

13. Demo가 UGC 생산기를 겸했다

[확인된 사실]

데모 공개 직후 플레이어들은 실제·가상 성, 마을, 로켓 등 다양한 결과물을 공유했다. 개발팀은 이런 행동을 관찰해 first-person view 같은 기능을 추가했고, 데모 피드백을 바탕으로 chimney, wall control, fence, optimization 등을 수정했다. (80 Level, 2024-06-11 , 80 Level, 2024-07-04 )

[분석]

이 구조에서 demo 사용자는 잠재고객이면서 콘텐츠 제작자다.

demo 다운로드 → 예쁜 건물 제작 → screenshot/video 공유 → 아직 demo를 모르는 사람이 발견 → 신규 demo 다운로드

즉 출시 전부터 product-led distribution이 생겼다.

무료 데모의 비용을 “공짜 사용량”으로만 보면 이 효과를 놓친다.

14. 100만 위시리스트의 의미

[확인된 사실]

2024년 6월 6일 PC Gamer는 이미 위시리스트가 **800,000+**라고 보도했다. 6월 16일 개발사는 Steam 공식 공지에서 1,000,000 위시리스트를 발표했다. (PC Gamer, 2024-06-06 , Steam, 2024-06-16 )

개발사는 자신들이 원래 이 게임을 “very niche”할 것으로 예상했다고 밝혔다. (Steam, 2024-06-16 )

[분석]

여기서 흥미로운 점은 Tiny Glade가 wishlist를 얻기 위해 기능 목록을 부풀린 것이 아니라는 점이다.

오히려:

“관리 없음, 전투 없음, 목표 없음”

을 적극적으로 말했다.

대부분의 게임은 무엇을 할 수 있는지 설명한다.

Tiny Glade는 무엇을 안 해도 되는지도 product promise로 썼다.

이는 대상 사용자를 좁히는 대신 message-market fit을 높인다.

15. Steam Next Fest는 수요를 만든 것보다 이미 있던 수요를 증폭했다

[확인된 사실]

Next Fest가 시작되기 전인 2024년 6월 초 Tiny Glade는 이미 80만 위시리스트를 갖고 있었다. 이후 데모가 큰 관심을 받았고, 6월 16일 100만을 넘었다. (PC Gamer, 2024-06-06 , Steam, 2024-06-16 )

[분석]

Next Fest를 “발견의 시작점”으로 보는 개발자가 많다.

Tiny Glade의 순서는 반대였다.

소셜에서 수년간 수요 축적 → 강한 wishlist base → Next Fest → 대규모 demo/social proof → launch.

따라서 Steam 이벤트는 엔진이 아니라 accelerator였다.

16. 출시 전략: self-publishing을 의도적으로 선택

[확인된 사실]

Pounce Light는 Tiny Glade를 self-publish하기로 일찍 결정했다. 이유는 두 가지였다.

1. 직접 출판을 배워 이후 publisher와 협상할 때도 무엇을 하는지 이해하고 싶었다.
2. 출시일과 제품 방향에 대한 완전한 통제권을 유지하고 싶었다.

두 사람은 AAA 환경에서 자신의 업무만 수행하고 큰 방향에 관여하기 어려웠던 경험도 self-publishing 선택에 영향을 줬다고 설명했다. (80 Level, 2024-05-30 )

[분석]

이것은 “퍼블리셔가 나쁘다”는 주장이 아니다.

Tiny Glade는 이미:

• 2인의 강한 기술력
• 자체 커뮤니티
• 대형 위시리스트
• 소셜 유통 능력

을 갖고 있었다.

즉 퍼블리셔가 제공하는 가장 큰 가치인 discovery와 validation을 상당 부분 내부에서 해결한 상태였다.

따라서 self-publishing은 이 팀에게는 합리적이었지만 모든 인디팀에 일반화할 수 없다.

17. 가격: $14.99의 1회 구매

[확인된 사실]

Tiny Glade의 현재 기본 가격은 $14.99다. Steam에는 사운드트랙 DLC도 있지만 게임 자체는 subscription이나 battle pass가 아닌 전통적 premium purchase 모델이다. (Steam )

[분석]

$14.99는 $3~5의 impulse-buy 게임보다 높은 편이지만, Tiny Glade에는 다음 장점이 있었다.

100만 wishlist

• demo를 통한 기대치 확인
• 높은 시각적 완성도
• creative tool로서 반복 사용 가능성

즉 제품이 짧은 linear campaign이 아니라 “내가 만들고 싶은 만큼 쓰는 도구”이기 때문에 가격을 단순 플레이시간으로만 보지 않아도 된다.

반대로 microtransaction을 넣지 않은 것도 제품 톤과 맞는다.

휴식과 창작을 파는 제품에서 계속 상업적 pressure를 노출하지 않는다.

18. 출시 결과: 2주 만에 50만 명 이상 플레이

[확인된 사실]

개발사는 2024년 10월 8일, 출시 약 2주 후 500,000+ people have played the game이라고 발표했다. PC Gamer와 WN Hub가 이를 보도했다. (WN Hub, 2024-10 , PC Gamer, 2024-10-15 )

SteamDB 기준 출시일 역대 최고 동시접속자는 10,692명이다. (SteamDB )

[분석]

위시리스트 100만 대비 플레이어 50만을 단순 conversion rate로 계산하면 안 된다.

• 발표 시점이 출시 2주 후일 뿐이고
• wishlist 보유자 중 나중에 산 사람도 있고
• unique player는 판매량과 완전히 동일한 지표가 아니다.

확실한 것은 대규모 prelaunch attention이 실제 유료 제품 사용으로 이어졌다는 것이다.

19. 커뮤니티 loop: 플레이어의 결과물이 마케팅 콘텐츠다

[분석]

Tiny Glade의 가장 강한 바이럴 구조는 기능 설명보다 단순하다.

플레이어가 게임을 잘하면 → 멋진 성이 생긴다. 플레이어가 아주 잘하지 않아도 → 시스템이 멋진 성처럼 보이게 도와준다. 그 결과물을 올리면 → 게임 자체가 광고된다.

즉 UGC 품질이 acquisition quality와 직결된다.

전통 게임은 콘텐츠를 마케팅팀이 만든다.

Tiny Glade는 플레이어가:

• 재현 건축물
• 작은 마을
• 성
• 폐허
• 기상천외한 구조물

을 만들면서 마케팅 inventory를 지속적으로 생산한다.

20. “만드는 과정”도 콘텐츠다

[분석]

UGC 결과물뿐 아니라 과정 영상도 강하다.

Tiny Glade의 interaction은:

선을 그림 → 벽 생김 path를 통과시킴 → 아치가 생김 높임 → 기둥이 생김 건물을 붙임 → 접합부가 정리됨

처럼 before/after가 몇 초 안에 보인다.

이 때문에 TikTok, X, Shorts에서 product demo와 satisfying video의 경계가 거의 없다.

이것이 소셜 콘텐츠 효율을 극단적으로 높인다.

21. Retention은 퀘스트가 아니라 ‘내가 다음에 만들 것’에서 온다

[확인된 사실]

개발팀은 의도적으로 goals나 management pressure를 넣지 않았고, 플레이어가 자기 이야기를 만들 수 있게 공간을 주는 것이 목적이라고 설명했다. (80 Level, 2024-05-30 )

[분석]

전통 retention:

daily quest → XP → unlock → next quest.

Tiny Glade:

“이번엔 Studio Ghibli풍 집을 만들어볼까?” → “이번엔 거대한 성?” → “이번엔 폐허?”

즉 외부 목표가 아니라 창작 의도 자체가 콘텐츠다.

이 모델은 모든 유저에게 강하지 않다. 하지만 맞는 유저에게는 콘텐츠 생산량이 개발사 asset count와 비례하지 않는다는 장점이 있다.

22. 사용자 행동을 관찰해 기능 우선순위를 찾았다

[확인된 사실]

플레이테스트에서는 사람들이 lantern을 쌓아 나무 벽처럼 쓰거나, 계단을 맞춰 machicolation처럼 표현하고, 원래 계획에 없던 bridge를 만들려고 했다. 개발팀은 이런 우회 행동을 보고 정식 기능을 설계했다. (80 Level, 2024-05-30 )

[분석]

이것은 feature request 설문보다 강한 신호다.

“다리가 필요해요.”

라고 말하는 것보다

다리를 만들기 위해 이미 이상한 방법으로 도구를 조합하고 있음

이 훨씬 강한 수요 증거다.

인디 제품에서 roadmap을 정할 때 “원하는 기능”보다 반복적으로 발생하는 workaround를 우선 보라는 교훈이다.

23. 제품 업데이트도 ‘더 많은 콘텐츠’보다 expressive range 확대에 집중

[확인된 사실]

2025년 7월의 대형 Stairs 업데이트는 stairs뿐 아니라 bridge, walkway, platform, ladder 등으로 연결되는 시스템을 추가했다. 개발팀은 3월부터 작업해 7월 29일 출시했다고 밝혔다. (Steam, 2025-07-29 )

2026년 9월 beta 1.16.0에서는 style picker, mod editor, Workshop 연동, rope bridge 등 창작·변형 범위를 넓히는 기능을 계속 실험하고 있다. (Steam 공지 모음, 2026-09 )

[분석]

업데이트 철학도 core thesis와 일관된다.

새 스토리 10시간 추가

가 아니라

기존 플레이어가 만들 수 있는 형태의 공간을 넓힌다.

한 번의 시스템 업데이트가 수천 개의 새로운 사용자 제작 결과물로 번역될 수 있다.

24. 현재 지표가 보여주는 것: 성공은 live-service 동접 유지와 다르다

[확인된 사실]

SteamDB의 2026년 9월 스냅샷에서 Tiny Glade는 약 411명이 동시 플레이 중이었고, 역대 최고는 10,692명이었다. 리뷰는 긍정 23,902, 부정 662였다. (SteamDB )

[분석]

최고점 대비 현재 동접은 크게 줄었다.

하지만 이 제품을 live-service KPI로 평가하면 안 된다.

Tiny Glade는:

• premium 1회 구매
• single-player
• 창작 toy
• 시즌 과금 없음

이므로 사업모델상 매일 수만 명을 유지해야 할 의무가 없다.

더 적절한 성공 기준은:

launch sell-through

• 장기 review quality
• 계속되는 카탈로그 판매
• 작은 팀으로 유지 가능한 업데이트 비용

이다.

25. 운영 레버리지: 두 사람이 핵심을 만들고 외부 전문성을 최소한으로 결합

[확인된 사실]

Pounce Light의 핵심 개발팀은 Opara와 Stachowiak 두 명이다. 음악과 사운드는 Oda Tilset과 Martin Kvale 등 외부 전문 인력이 참여한 것으로 소개돼 있다. (GamingOnLinux, 2024-06 )

[분석]

작은 팀 운영의 핵심은 모든 일을 두 사람이 한 것이 아니다.

차별화 영역:

procedural system rendering interaction UX

은 내부에 둔다.

비핵심이면서 전문성이 필요한 영역:

music sound

은 협력한다.

즉 headcount를 줄이는 것보다 core competency 집중도가 높다.

26. self-publishing의 운영 레버리지와 대가

[분석]

self-publishing으로 얻은 것:

• 제품 방향 통제
• 출시 시점 통제
• publisher share 없음
• 고객과 직접 관계
• 출판 경험 축적

대신 직접 떠안은 것:

• Steam 운영
• QA
• support
• localization 판단
• marketing
• community
• 플랫폼 대응

100만 wishlist가 없던 팀이라면 이 구조는 과부하가 될 수 있다.

Tiny Glade는 self-publishing에 적합한 demand position을 먼저 만들고 self-publishing한 사례로 보는 편이 정확하다.

27. 기술부채와 플랫폼 확장: 작은 팀의 성공이 새 부담을 만든다

[확인된 사실]

2026년 Apple silicon macOS 버전을 공식화하면서 개발팀은 mac 지원을 위해 그래픽 엔진의 절반을 다시 작성했다고 설명했다. 또한 테스트 기기가 많지 않으니 포럼에 문제를 알려달라고 요청했다. (Steam 공식 공지 모음, 2026-05-13 )

[분석]

초기에는 커스텀 그래픽 파이프라인이 차별화의 핵심이었다.

성공 후에는 같은 기술이:

Mac 지원 driver issue Steam Deck GPU 호환성 mod support

같은 maintenance 비용으로 돌아온다.

즉 기술적 moat와 기술적 부채는 같은 자산의 양면이다.

28. 가장 설득력 있는 성공 인과관계

공개 자료를 연결하면 다음 흐름이 가장 타당하다.

procedural art·rendering 전문성을 가진 두 개발자 → 취미성 wall generator 실험 → Twitter에서 시각적 반응 확인 → TikTok으로 비개발자 수요를 재검증 → “건축 시뮬레이션”보다 “doodle toy”로 제품 thesis 정립 → 전투·관리·목표 제거 → procedural system이 플레이어 의도를 자동으로 예쁘게 마무리 → 초보 사용자도 공유 가능한 결과물을 만들 수 있음 → 개발 feature 자체가 짧은 social clip이 됨 → Steam 노출 24시간 약 1만 wishlist → 6개월 42만+ wishlist → 2024년 6월 80만 → 100만 wishlist → demo 36만 명+ / 1.2만 피드백 → UGC가 다시 social discovery를 생산 → $14.99 self-published launch → 2주 50만+ unique players → 높은 Steam 리뷰 품질 유지 → 큰 업데이트도 콘텐츠 양보다 표현 범위 확대 → 2026년 Mac·modding·Workshop로 long-tail 확장.

핵심을 한 문장으로 줄이면:

Tiny Glade는 사용자가 잘 만들도록 가르친 것이 아니라, 서툴게 만들어도 시스템이 보기 좋게 완성해 주도록 설계했고, 그 결과물이 다시 마케팅 콘텐츠가 되게 했다.

29. 대안 가설 A — “cozy 게임 붐이라서 성공했다”

[분석]

cozy 수요가 강한 시기였다는 것은 분명 tailwind다.

하지만 cozy라는 라벨만으로 100만 wishlist가 생기지는 않는다.

Tiny Glade의 차이는:

• 설명 없는 짧은 영상에서도 재미가 보임
• 초보 output이 아름다움
• management pressure를 명시적으로 제거
• creative UGC가 스스로 퍼짐

이었다.

더 정확한 설명은:

cozy demand × unusually shareable creation UX

다.

30. 대안 가설 B — “그래픽이 예뻐서 성공했다”

[분석]

시각적 완성도는 매우 큰 acquisition driver다.

그러나 예쁜 그래픽만 있었다면 플레이어는 screenshot 몇 장 보고 끝날 수 있다.

Tiny Glade는 “예쁜 결과”뿐 아니라 예쁜 결과가 생기는 과정 자체가 재미있다.

drag → adapt → rearrange → flourish.

그래서 product demo가 영상 콘텐츠로 반복 가능하다.

31. 대안 가설 C — “procedural tech가 대단해서 성공했다”

[분석]

개발자와 technical artist에게는 중요한 매력이다.

하지만 팀이 TikTok으로 비개발자 audience를 확인한 이유가 바로 이 대안 가설을 검증하기 위해서였다.

결과적으로 사람들은 알고리즘 자체보다:

내 행동에 세계가 자연스럽게 반응하는 느낌

을 좋아했다.

따라서 복제해야 할 것은 복잡한 procedural system이 아니라 사용자에게 보이는 반응성이다.

32. 대안 가설 D — “100만 wishlist가 성공을 자동으로 만들었다”

[분석]

위시리스트는 launch visibility에 매우 중요하다.

하지만 100만 wishlist는 원인이면서 동시에 결과다.

그 숫자를 만든 것은:

2년 가까운 social clips

• 시각적으로 명확한 product hook
• demo
• Next Fest
• UGC.

따라서 “wishlist를 모아라”는 조언만으로는 실행 가능성이 없다.

더 좋은 질문은:

wishlist를 누를 이유를 매주 새롭게 보여줄 수 있는 product surface가 있는가?

이다.

33. 대안 가설 E — “Steam Next Fest가 띄웠다”

[분석]

Next Fest 전에 이미 80만 wishlist가 있었다. (PC Gamer, 2024-06-06 )

따라서 Next Fest는 discovery engine보다 multiplier에 가깝다.

이미 강한 제품 → Steam 이벤트가 가속.

순서가 중요하다.

34. 대안 가설 F — “두 사람이라 의사결정이 빨라서”

[분석]

맞지만 충분하지 않다.

2명이라는 규모는:

• 빠른 결정
• 낮은 burn
• 높은 creative coherence

를 만든다.

동시에:

• key-person risk
• support bottleneck
• platform QA 한계
• 대형 업데이트 장기화

도 만든다.

2025년 stairs 업데이트가 3월부터 7월까지 걸린 것처럼, 작은 팀은 feature scope가 커질수록 속도가 급격히 느려질 수 있다. (Steam, 2025-07-29 )

35. 실패 위험 ①: “목표 없음”이 장점이면서 이탈 원인이 될 수 있다

[분석]

Tiny Glade는 명시적으로 goals가 없다.

맞는 유저에게는 자유다.

맞지 않는 유저에게는:

“그래서 무엇을 해야 하지?”

가 된다.

이 위험을 demo가 완화한다. 구매 전에 제품 성격을 체험하게 해 기대치 불일치를 줄인다.

즉 극단적 포지셔닝일수록 무료 체험의 가치가 커진다.

36. 실패 위험 ②: UGC 제품은 기능 요청이 끝없이 늘어난다

[확인된 사실]

데모와 이후 커뮤니티에서는 bridge, stair, clutter 이동, lighting, terrain, Workshop 등 수많은 요청이 이어졌다. 개발팀은 일부를 큰 시스템으로 확장했고 2026년에도 mod·Workshop 관련 기능을 실험하고 있다. (80 Level, 2024-05-30 , Steam 공지 )

[분석]

창작도구의 구조적 문제다.

사용자가 만들 수 있는 것이 많아질수록:

“이것도 만들어야 한다.”

가 더 많아진다.

따라서 feature coverage 목표를 잡으면 끝이 없다.

우선순위 기준은:

요청 수

보다

새 기능이 기존 도구와 얼마나 많은 조합을 만드는가

가 되어야 한다.

37. 실패 위험 ③: 소셜 알고리즘 의존

[분석]

초기 성장에 Twitter와 TikTok이 큰 역할을 했다.

같은 영상을 오늘 올린다고 같은 reach가 나온다는 보장은 없다.

플랫폼 알고리즘, cozy 트렌드, 경쟁작 상황은 재현하기 어렵다.

재현 가능한 것은 조회수 자체가 아니라:

개발 중인 기능이 설명 없이도 5~10초 콘텐츠가 되는 제품 구조

다.

38. 실패 위험 ④: custom tech의 유지비

[분석]

Vulkan, modified Bevy, bespoke procedural pipeline은 차별화의 기반이다.

하지만 성공 이후:

• Mac
• 새로운 GPU
• driver bugs
• modding
• Workshop
• Steam Deck

같은 호환성 부담이 생긴다.

2026년 macOS 지원을 위해 그래픽 엔진을 크게 다시 썼다는 공식 설명은 이 비용을 보여준다. (Steam 공지, 2026-05 )

39. 실패 위험 ⑤: 2인 팀의 key-person risk

[분석]

핵심 procedural logic과 rendering 지식이 사실상 두 사람에게 집중돼 있다.

이 구조는 PMF 전에는 강하지만 장기 운영에서:

• 휴가
• 건강
• burnout
• platform support

문제가 크게 느껴질 수 있다.

작은 팀을 유지하려면 기능 추가 속도에 대한 커뮤니티 기대치를 관리해야 한다.

40. 실패 위험 ⑥: 100만 wishlist가 오히려 scope 압력을 키울 수 있다

[분석]

대규모 관심을 받으면 개발자는:

“이 정도 기대를 받으니 더 큰 게임으로 만들어야 하지 않을까?”

라는 압력을 받기 쉽다.

Pounce Light는 오히려 전투·관리·목표를 끝까지 넣지 않고 제품 thesis를 유지했다.

이것이 중요한 scope discipline이다.

수요가 커져도 제품을 더 넓게 만들 필요는 없다.

41. 운과 맥락 특수성

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

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

실행 아이디어 ①: 개발자와 일반 사용자에게 같은 영상을 보여준다

Tiny Glade 팀은 초기 Twitter 반응이 기술 커뮤니티의 감탄일 뿐일 수 있다고 의심해 TikTok에서 다시 검증했다. (80 Level, 2024-05-30 )

실험 방법:

1. 같은 10초짜리 product clip을 만든다.
2. A: 업계·개발자 커뮤니티에 배포한다.
3. B: 일반 소비자 채널에 배포한다.
4. 조회수 대신 행동을 비교한다.

측정:

• save rate
• profile/store click
• wishlist
• “직접 써보고 싶다” 응답
• 공유율

전문가 반응만 크고 일반 사용자 행동이 약하면 product가 아니라 기술 데모일 가능성이 있다.

실행 아이디어 ②: 초보자가 만든 ‘가장 못생긴 결과’를 개선한다

숙련자 5명의 결과보다 초보자 20명의 결과를 본다.

각 결과물을 외부 평가자에게 보여주고:

“이걸 만든 사람이 공유하고 싶을 정도로 만족스러운가?”

를 1~5점으로 평가한다.

그 다음 자동 기능을 하나 넣는다.

예:

• spacing 자동정렬
• color harmony
• path smoothing
• wall join 자동처리
• default typography
• component auto-layout

목표는 최고 output을 100점→110점으로 만드는 것이 아니다.

최저 output을 30점→70점으로 올리는 것.

UGC 제품에서 이 변화가 바이럴에 더 중요할 수 있다.

실행 아이디어 ③: 5초 무음 영상에서 제품을 이해시키기

Tiny Glade의 강점은 벽을 그리는 동작과 결과가 즉시 연결된다는 것이다.

A/B 영상:

A. 기능 설명 자막 포함 20초

B. 무음 5초: 드래그 → 벽 → 아치 자동생성

20명에게 보여주고 묻는다.

“이 제품에서 무엇을 할 수 있나요?”

KPI:

정확한 핵심 기능 설명 비율.

80% 미만이면 UI 상태변화가 충분히 읽히지 않는지 점검한다.

실행 아이디어 ④: ‘추가’가 아니라 ‘제거’로 포지셔닝한다

현재 제품에서 사용자가 부담스러워할 요소를 적는다.

예:

• 계정 생성
• 점수
• 레벨
• 리소스 관리
• 실패
• 설정
• 복잡한 export
• 협업 권한

그중 하나를 제거한 prototype을 만든다.

측정:

• 첫 성공까지 시간
• 오류율
• session 만족도
• 재방문 의향

Tiny Glade의 핵심 differentiation 상당 부분은 새로운 기능보다 없앤 기능에서 나왔다.

실행 아이디어 ⑤: 데모를 conversion tool이 아니라 qualification tool로 본다

무료 demo 사용자에게 두 질문을 한다.

1. “구매하고 싶은가?”
2. “이 제품은 당신 취향인가?”

두 번째 질문에서 “아니다”라고 답한 사용자가 구매하지 않는 것은 실패가 아니다.

오히려:

refund negative review support burden

을 줄일 수 있다.

측정할 KPI:

demo→qualified buyer conversion

이다.

실행 아이디어 ⑥: 사용자의 workaround를 roadmap으로 바꾼다

20명 playtest를 녹화한다.

다음 행동을 표시한다.

• 같은 행동을 세 번 이상 반복
• 엉뚱한 기능을 다른 용도로 사용
• 외부 도구로 해결
• copy/paste로 반복 구조 생성
• UI를 피해 우회

같은 workaround가 3명 이상에게 나오면 feature 후보로 올린다.

Tiny Glade의 bridge·elevation 같은 기능은 이런 사용자의 ‘억지 조합’에서 발전했다. (80 Level, 2024-05-30 )

실행 아이디어 ⑦: 새 asset보다 ‘조합 배수’를 계산한다

두 기능 후보가 있다고 하자.

A. 장식품 10개 추가

B. 기존 벽·창문·지붕·계단을 새로운 방식으로 연결하는 rule 1개

각 후보에 대해:

새로운 의미 있는 조합 수 / 개발일

을 계산한다.

B가 더 크면 작은 팀에서는 B를 우선한다.

Tiny Glade의 강점은 콘텐츠를 만드는 도구보다 콘텐츠를 증식시키는 규칙에 있다.

실행 아이디어 ⑧: 개발 sprint의 결과물을 marketing artifact로 만든다

기능 후보마다 질문한다.

“이 기능을 완성하면 10초짜리 만족스러운 GIF가 자동으로 나오는가?”

점수:

• 0: 설명이 길어야 이해
• 1: before/after 가능
• 2: 무음으로도 이해
• 3: 반복해서 보고 싶음

동일 개발가치라면 점수가 높은 기능을 먼저 만든다.

이렇게 하면:

product roadmap

과

content calendar

를 분리해서 관리할 필요가 줄어든다.

44. 가장 복제하면 안 되는 표면

Tiny Glade를 보고 쉽게 따라 할 수 있는 표면은 다음이다.

pastel color cozy music medieval cottage procedural building sheep no combat.

하지만 이 조합을 그대로 만들면 이미 Tiny Glade와 직접 비교된다.

복제할 가치가 있는 구조는 더 아래에 있다.

기술 실험을 먼저 만든다.

→ 전문가 반응과 일반 사용자 수요를 분리해 검증한다.

→ 사용자가 하는 고차원 결정은 남기고 귀찮은 마무리는 자동화한다.

→ 초보 결과물의 품질 바닥을 높인다.

→ 제품 사용 결과가 자연스럽게 공유 콘텐츠가 되게 한다.

→ 개발 기능 자체가 짧은 소셜 영상이 되게 한다.

→ demo로 잘못된 고객도 미리 걸러낸다.

→ 사용자가 억지로 만들어내는 workaround를 다음 기능 신호로 본다.

→ asset 수보다 조합 규칙을 늘린다.

→ 수요가 커져도 처음의 좁은 제품 thesis를 지킨다.

이것이 더 재현 가능하다.

45. 최종 결론

Tiny Glade의 가장 눈에 띄는 숫자는 100만 Steam 위시리스트, 데모 약 36만 체험자, 출시 2주 50만+ unique players, 그리고 2026년에도 유지되는 약 97% 긍정 Steam 평가다. (Steam, 2024-06-16 , 80 Level, 2024-07-04 , PC Gamer, 2024-10-15 , SteamDB )

하지만 가장 중요한 성공요인은 “cozy”라는 장르도, Bevy/Rust라는 기술도 아니다.

Tiny Glade는 사용자가 예쁜 것을 만들기 위해 필요한 실력을 줄였다.

사용자는 큰 형태와 의도를 결정한다.

시스템은:

• 연결부를 정리하고
• 기둥을 만들고
• 지붕을 맞추고
• 디테일을 추가하고
• 실수를 되돌릴 수 있게 해준다.

그 결과 초보 사용자도 자기 결과물을 공유하고 싶어진다.

그리고 그 공유물이 다시 새로운 위시리스트와 데모 사용자를 만든다.

즉 제품과 마케팅 사이의 가장 강한 인과관계는 다음과 같다.

좋은 UX → 좋은 사용자 결과물 → 좋은 UGC → organic discovery → 더 많은 사용자 → 더 많은 결과물.

다른 인디 개발자가 이번 사례에서 가장 먼저 물어볼 질문은 세 가지다.

“우리 제품에서 전문가만 잘하는 마감 작업 중 시스템이 대신할 수 있는 것은 무엇인가?”

“처음 쓰는 사람의 결과물도 다른 사람에게 보여주고 싶을 만큼 좋은가?”

그리고:

“이번 주에 만든 기능이 제품 개선인 동시에 10초짜리 마케팅 영상이 될 수 있는가?”

Tiny Glade의 재현가치는 “cozy castle builder를 만들어라”가 아니다.

사용자의 창작 의도는 그대로 두면서 결과물의 품질과 공유 가능성만 시스템적으로 끌어올리면, 작은 팀도 제품 사용 자체를 distribution engine으로 바꿀 수 있다는 것이다.

주요 출처와 게시일