Thronefall 성공 사례 분석

이번 사례는 독일의 2인 개발팀 Grizzly Games가 만든 미니멀 전략 게임 Thronefall이다. 최근 다룬 PEAK, Buckshot Roulette, Animal Well, A Game About Digging A Hole, Backpack Battles, Tally, Photopea, R.E.P.O., Mouthwashing, ScreenshotOne과 겹치지 않는다.

Thronefall이 특히 분석할 가치가 있는 이유는 단순하다. 이 게임은 ‘RTS를 더 크게’ 만든 것이 아니라 RTS에서 사람들이 피곤해하는 요소를 체계적으로 제거했다. 그 결과 2인 핵심 개발팀이 2023년 8월 Steam Early Access에 진입한 뒤, 2024년 9월 기준 정식 출시 전 이미 100만 장에 가까운 판매량과 565,000개 이상의 Steam 위시리스트를 확보했고, 2025년 2월에는 공식적으로 100만 장 판매를 돌파했다. 현재 PC 정가는 $12.99이며 Steam 영문 리뷰는 2026년 9월 19일 기준 약 11,035개, 95% 긍정이다. (GamesMarket, 2024-09-26 , GamesMarket, 2025-02-03 , Steam, 2026-09-19 확인 )

핵심 성공 공식을 먼저 요약하면 다음과 같다.

큰 장르의 핵심 만족은 남기고 관리 부담은 제거한다 → 아주 작은 프로토타입으로 검증한다 → 데모와 Early Access로 시장 신호를 빠르게 받는다 → Steam이 선호하는 장르 수요와 높은 만족도를 결합한다 → 정기 업데이트가 크리에이터와 알고리즘의 재노출을 만든다 → 검증 뒤 콘솔·모바일로 확장하고, 2인 팀의 운영 한계가 오면 IP까지 넘긴다.

이 사례에서 중요한 것은 “2명이 100만 장을 만들었다”가 아니라 작은 팀이 어떤 종류의 복잡성은 제품 가치이고, 어떤 복잡성은 단순한 비용인지 구분했다는 점이다.

1. 공개된 주요 지표

공개되지 않은 데이터: 최신 공식 누적 판매량(100만 장 이후), 공식 총매출·순매출·이익, 개발비, 마케팅비, CAC, 환불률, 위시리스트→구매 전환율, D1/D7/D30 리텐션, DAU/MAU, 국가별 판매 비중, Mythwright의 IP 인수 금액은 신뢰할 만한 공개 자료에서 확인되지 않았다. 따라서 정가×판매량 방식의 매출 추정은 하지 않는다.

2. 개발자 배경: ‘처음 만드는 두 명’이 아니라 작은 게임을 여러 번 끝내 본 두 명

[사실]

Grizzly Games의 핵심 개발자는 Jonas Tyroller와 Paul Schnepf 두 명이다. 두 사람은 베를린 HTW의 게임 디자인 과정에서 만났고, 대학 프로젝트로 만든 ISLANDERS를 함께 개발했다. 이후 Jonas는 Will You Snail?, Paul은 The Ramp와 The Block 같은 소형 프로젝트를 각자 만들다가 다시 팀을 이뤘다. 개발은 100% 원격으로 진행했고, 일상적인 조율은 Discord 통화와 Miro를 이용했다. 커뮤니티 운영에는 별도의 커뮤니티 매니저 Sacha가 참여했다. (INDIEGAMES/WTF 인터뷰, 게시일 미표기·2026-09-19 확인 )

또한 공개 초기부터 Future Friends Games가 마케팅을 지원했다. (GamesMarket, 2023-06-14 )

[분석]

따라서 “2명이 만들었다”는 표현은 핵심 제품 제작 인력에는 맞지만, 사업 전체를 단 두 명이 처리했다는 뜻은 아니다.

정확한 구조는 다음에 가깝다.

• 핵심 설계·개발·아트: Jonas + Paul
• 커뮤니티: 별도 담당자 활용
• 출시 마케팅: Future Friends의 지원
• Switch 포팅: 외부 전문 파트너 활용
• 모바일: Doghowl Games와 협업
• 2025년 말 이후 IP 운영: Mythwright

이 구조가 중요한 이유는 작은 팀 성공의 본질이 모든 것을 내부화하는 것이 아니라 차별화되는 부분만 직접 쥐고 나머지는 외부 레버리지로 해결하는 것임을 보여주기 때문이다.

3. 첫 번째 제품 원칙: “전략 게임의 재미가 아니라 두통을 삭제한다”

[사실]

개발진은 Thronefall의 핵심 방향을 반복해서 “headache-free strategy game”, 즉 머리 아프지 않은 전략 게임으로 설명했다. Jonas는 고전 RTS에서 다음과 같은 부담을 제거하려 했다고 설명한다.

• 긴 학습 시간
• 높은 APM 요구
• 숙련자와의 경쟁 부담
• 실시간으로 여러 유닛을 동시에 조작해야 하는 부담
• 패배 후 복구·수리·재건의 반복 노동

대신 Thronefall은 자원 관리, 빌드 선택, 유닛 구성, 업그레이드, 제한적인 마이크로 같은 전략의 핵심 만족을 남긴다. 플레이어는 낮 동안 충분한 시간을 갖고 건물·업그레이드를 선택하고, 밤에는 기본적으로 왕 한 명을 직접 조작한다. 사망해도 잠시 뒤 부활하며, 아침이 되면 건물은 무료로 복구되고, 패배하더라도 XP와 해금 요소를 얻을 수 있다. (INDIEGAMES/WTF 인터뷰, 게시일 미표기·2026-09-19 확인 )

[분석]

이것은 단순한 ‘캐주얼화’와 다르다. 캐주얼화는 흔히 선택 수 자체를 없애 버린다. Thronefall은 관리 업무는 줄이되 의사결정의 결과는 남겼다.

예를 들어 자유 배치형 RTS에서는 플레이어가 다음을 모두 고민한다.

어디에 지을까 → 방향은? → 길막은? → 일꾼은? → 수리할까? → 생산 큐는? → 여러 부대는?

Thronefall은 상당 부분을 다음처럼 압축한다.

이 슬롯에 경제 건물을 지을까, 방어 건물을 지을까?

선택의 수는 줄지만 경제 vs 방어라는 전략의 본질은 더 선명해진다.

작은 팀에게 이 방식은 이중 이점이 있다.

1. 플레이어의 인지 부담을 줄인다.
2. 개발해야 할 UI, AI, 경로, 건설 규칙, 튜토리얼, 예외 처리를 줄인다.

즉 UX 단순화가 동시에 개발 스코프 절감이 된다.

4. 제품 포지셔닝: RTS 팬만이 아니라 ‘RTS를 좋아했지만 이제 시간이 없는 사람’

[사실]

1.0 출시 전 Jonas는 Thronefall이 “처음 전략 게임을 하는 아이”부터 “새 게임을 배우는 데 수백 시간을 쓸 시간이 없는 베테랑”까지 즐길 수 있기를 바란다고 말했다. (GamesMarket, 2024-09-26 )

Steam의 공식 설명 역시 “quick sessions or fortification marathons”와 “streamlined”를 강조한다. 현재 게임은 10개 맵, 9개 무기, 50개 이상의 해금형 perk, 다양한 mutator와 미니 모드를 제공한다. (Steam, 2026-09-19 확인 )

[분석]

타깃 사용자를 단순히 “전략 게임 팬”으로 보면 포지셔닝의 절반만 이해한 것이다.

더 정확한 타깃은 다음 세 집단의 교집합이다.

즉 이 제품의 시장은 기존 RTS 코어층보다 **“전략적 선택은 좋아하지만 전략 게임의 운영 노동은 싫은 사람”**이라는 더 큰 욕구 집단이었다.

5. 프로토타이핑: 처음부터 Thronefall을 만들려고 하지 않았다

[사실]

2022년 말 Jonas와 Paul은 차기작을 정하기 위해 약 2주간 여러 프로토타입을 빠르게 만들었다. 초기에는 중세 왕국을 소재로 한 덱빌딩 게임도 시도했지만 방향을 찾지 못했고, 결국 “왕국을 만들고 방어한다”는 작은 타워디펜스형 프로토타입이 Thronefall로 발전했다. (Jonas Tyroller 개발 기록, 2022-12-30 , AUTOMATON, 2022-12-12 )

AUTOMATON이 당시 개발 영상을 정리한 내용에 따르면, 덱빌더 기획을 포함한 탐색 과정에서 Thronefall의 기본 프로토타입까지 약 41일이 걸렸고, 이후 실제 플레이 가능한 게임 형태까지는 Thronefall 본격 제작 시작 후 약 22일이 걸렸다. (AUTOMATON, 2022-12-12 )

[분석]

여기서 재현할 것은 “22일 게임 개발”이 아니다.

두 사람 모두 이미 여러 게임을 출시한 숙련자였고, 실제 Early Access까지는 훨씬 더 긴 시간이 걸렸다. 개발진도 Early Access 진입까지 180 실제 작업일, 달력 시간으로는 1년 이상이 걸렸다고 설명한다. EA 당시에도 맵은 4개, 플레이시간은 약 3~4시간 수준이었다. (INDIEGAMES/WTF 인터뷰 )

더 중요한 원리는 다음이다.

콘텐츠를 오래 만들기 전에 ‘핵심 행동의 조합’이 재미있는지 먼저 증명한다.

Thronefall의 프로토타입에서 검증해야 했던 것은 맵 10개가 아니었다.

• 낮에 건설한다.
• 경제와 방어 사이에서 선택한다.
• 밤에 직접 싸운다.
• 아침이 오면 다시 성장한다.

이 네 단계가 재미있으면 콘텐츠를 확장할 수 있고, 재미없으면 수개월을 아낄 수 있다.

6. UX 선택 ①: 자유도를 줄여서 전략을 선명하게 만들었다

[사실]

Thronefall에서는 모든 위치에 자유롭게 건물을 놓는 대신 미리 정해진 건설 위치를 사용한다. 개발진은 초기에는 이 제한이 너무 강한 것이 아닌지 걱정했지만, 결과적으로 경험을 단순화하는 핵심 선택이 됐다고 설명했다. (INDIEGAMES/WTF 인터뷰 )

[분석]

자유도를 늘리면 항상 깊이가 늘어나는 것은 아니다.

자유 배치에서 플레이어가 내리는 수많은 결정 중 상당수는 실제 전략보다 공간 정리와 UI 조작 비용이다. 슬롯 방식은 이 부분을 제거하면서 “경제를 먼저 키울지, 방어에 투자할지”라는 고가치 선택을 앞으로 끌어낸다.

이것은 인디 앱에도 그대로 적용할 수 있다.

• 대시보드 완전 커스터마이징 대신 좋은 기본 레이아웃 제공
• 자동화 규칙 무한 편집 대신 자주 쓰는 템플릿 제공
• 디자인 툴의 모든 자유도를 초기 화면에 노출하지 않기

핵심은 기능을 없애는 것이 아니라 사용자가 가치 있는 결정에 더 빨리 도달하게 하는 것이다.

7. UX 선택 ②: 실패 비용을 줄이되 실패 의미는 유지했다

[사실]

사망 시 잠시 뒤 부활하고, 아침에 건물이 무료 복구되며, 패배하더라도 XP와 해금이 남는다. (INDIEGAMES/WTF 인터뷰 )

[분석]

전략 게임의 전형적인 실패 비용은 매우 크다.

30분 운영 → 한 번의 판단 실수 → 기지 붕괴 → 처음부터 재건

이 구조는 숙련자에게는 긴장감을 주지만 입문자에게는 실험 비용을 너무 높인다.

Thronefall은 실패의 정보 가치는 남기고 반복 노동을 줄였다.

플레이어는 “방어선을 잘못 구성했다”는 교훈을 얻지만, 건물을 일일이 수리하거나 복구하는 노동은 하지 않는다.

이 때문에 실패 후 행동이 다음처럼 바뀐다.

좌절 → 종료

보다

원인 파악 → perk 조정 → 다시 시도

에 가까워진다.

공식 D1/D7 리텐션은 공개되지 않았으므로 이것을 수치적 리텐션 효과로 단정할 수는 없다. 다만 Early Access 기간 동안 높은 리뷰와 반복 업데이트에 따른 긴 판매 꼬리가 있었다는 공개 데이터와는 일관된다. (How To Market A Game, 2024-10-07 )

8. 핵심 게임 루프: 낮의 투자 결정과 밤의 검증을 분리했다

[사실]

공식 게임 구조는 낮 동안 건물·경제·방어를 준비하고, 밤에 적의 공격을 막는 방식이다. 플레이어는 왕을 직접 움직여 전투에 참여한다. (Steam )

[분석]

이 루프의 장점은 의사결정과 결과 사이의 거리가 짧다는 것이다.

낮: 금을 어디에 쓸까?

몇 분 뒤

밤: 그 선택이 맞았는가?

결과가 빠르게 돌아오기 때문에 학습 루프가 짧다.

전략 게임의 많은 시스템이 재미없게 느껴지는 이유는 결정과 결과가 너무 멀리 떨어져 있기 때문이다. Thronefall은 이를 짧은 낮/밤 주기로 압축한다.

이 구조는 앱에도 유용한 원리다.

사용자가 설정을 바꾼 뒤 가치가 보이기까지 얼마나 오래 걸리는가?

좋은 제품은 decision-to-feedback time을 줄인다.

9. 데모: ‘마케팅 자산’이 아니라 시장 적합성 확인 도구

[사실]

Thronefall 데모는 2023년 6월 13일 공개됐고, Early Access는 약 7주 뒤인 8월 2일 시작됐다. Jonas는 데모를 공개하며 직접 플레이 후 피드백을 달라고 요청했다. (Jonas Tyroller YouTube, 2023-06-13 , Steam )

[분석]

이 간격이 중요하다.

많은 팀은 데모를 출시 직전 행사 용도로 사용한다.

Thronefall은 데모를 실제 제품 방향의 확신을 높이는 단계로 사용했다.

프로토타입 → 데모 → 수요/피드백 → EA

이 순서에서는 정식 콘텐츠를 많이 만들기 전에 시장의 반응을 볼 수 있다.

특히 핵심 게임 루프가 짧게 압축되어 있기 때문에 데모만으로도 제품의 본질을 충분히 보여줄 수 있었다.

10. Early Access 전략: 처음부터 큰 게임을 약속하지 않았다

[사실]

개발진에 따르면 EA 시작 시점의 Thronefall은 맵 4개, 약 3~4시간 플레이 분량이었다. 180일은 실제 작업일 기준이며 달력 시간으로는 1년 이상이었다. 개발진은 이후 Early Access 동안 콘텐츠를 계속 확장했다. (INDIEGAMES/WTF 인터뷰 )

How To Market A Game에 Jonas가 제공한 비교 데이터에서는 Thronefall이 EA 출시 당시 약 20만 위시리스트, 약 7,000 최고 동접을 기록했고, 이후 업데이트를 반복하며 비교적 강한 장기 꼬리를 유지한 것으로 나타났다. (How To Market A Game, 2024-10-07 )

[분석]

이 전략의 핵심은 콘텐츠가 적은 것과 제품이 미완성인 것을 구분한 것이다.

EA 출시 시 제품은 짧았지만 핵심 경험은 명확했다.

• 경제 선택
• 방어 설계
• 직접 전투
• 실패 후 재시도

작은 팀이 “출시 가능한 최소 범위”를 잡을 때는 기능 개수보다 핵심 경험이 완결되어 있는가가 더 중요하다.

11. 출시 전후 위시리스트: 20만에서 56.5만으로 계속 늘었다

[사실]

Jonas가 How To Market A Game에 공유한 데이터에 따르면 EA 출시 시점 위시리스트는 약 200,000개였다. 2024년 9월 26일 1.0 직전에는 565,000개 이상으로 늘어났다. (How To Market A Game, 2024-10-07 , GamesMarket, 2024-09-26 )

[분석]

보통 위시리스트를 “출시 전에 모아야 하는 숫자”로만 생각한다.

Early Access 제품에서는 다르게 볼 수 있다.

출시 → 업데이트 → 신규 노출 → 신규 위시리스트 → 다음 세일/업데이트 → 구매

즉 위시리스트가 런칭 전 저수지가 아니라 운영 중 계속 채워지는 파이프라인이 된다.

공식 위시리스트→구매 전환율은 공개되지 않았으므로 20만·56.5만과 판매량을 나눠 전환율을 계산하지 않는다.

12. 가장 중요한 유통 채널 중 하나는 Steam 자체였다

[사실]

How To Market A Game의 Chris Zukowski는 Jonas에게 받은 실제 Steam 데이터를 분석했다. 그에 따르면 분석한 출시일 구간에서 Thronefall과 Will You Snail? 모두 Discovery Queue가 스토어 페이지 조회의 50% 이상을 차지하는 날이 많았고, Thronefall은 Discovery Queue에서 더 오래 성장 구간을 유지했다. (How To Market A Game, 2024-10-07 )

[분석]

이 지표는 매우 중요하다.

인디 마케팅을 외부 SNS 트래픽만으로 생각하면 다음을 놓친다.

Steam에서 가장 강한 광고 매체는 Steam일 수 있다.

Discovery Queue와 추천 알고리즘이 더 많은 사용자에게 제품을 보여주려면 초기 사용자 반응이 좋아야 한다. 정확한 알고리즘 공식은 공개되지 않았지만, Jonas와 Zukowski의 비교에서 Thronefall은 장르 적합성, 첫인상, 플레이어 만족이 결합되어 더 강한 노출을 얻었다.

따라서 마케팅의 핵심 질문이 바뀐다.

“X에서 몇 번 홍보할까?”보다

“Steam이 우리 게임을 전략 게임 구매자에게 보여줬을 때, 몇 초 안에 구매 이유가 보이는가?”

가 우선이다.

13. ‘유튜버 개발자라서 성공했다’는 설명은 충분하지 않다

[사실]

Jonas는 이미 대형 게임개발 YouTube 채널을 운영하고 있었다. 그러나 본인은 Thronefall에서 자신의 채널이 결정적 요인은 아니라고 반복해서 설명했다.

그가 공개한 비교에 따르면 *Will You Snail?*은 유튜브의 영향을 크게 받았지만, Thronefall은 약 20만 위시리스트로 EA를 시작했고 이후 50만 이상으로 성장해 자신의 영상 하나가 그래프에서 눈에 띄지 않을 정도였다. Jonas는 “유튜브는 baseline을 만들 수 있지만 매우 시간 소모가 크며, 게임 자체가 더 중요하다”고 평가했다. (How To Market A Game, 2024-10-07 , INDIEGAMES/WTF 인터뷰 )

[분석]

따라서 대안 가설은 이렇게 나눠야 한다.

가설 A: 20만+ 구독자 채널 덕분에 성공했다.

→ 초기 관심과 피드백에는 분명 도움이 됐다.

하지만: 같은 개발자의 *Will You Snail?*은 더 긴 기간 유튜브 노출을 받았지만 Thronefall보다 훨씬 작은 상업 성과를 냈다. Jonas가 제공한 데이터에서도 Thronefall은 동일 개발자의 다른 게임보다 훨씬 강한 Steam 내 알고리즘·크리에이터 노출을 받았다.

더 설득력 있는 설명은:

기존 채널이 초기 불씨를 제공했고, 제품·장르 적합성이 Steam과 외부 크리에이터를 통해 규모를 키웠다.

14. 장르 선택 자체가 마케팅이었다

[사실]

How To Market A Game는 Jonas의 세 작품—ISLANDERS, Will You Snail?, Thronefall—을 비교하며 Steam에서는 건설·전략·시뮬레이션 계열이 플랫폼의 구매자 수요와 잘 맞는다고 분석했다. Jonas 자신도 Thronefall이 *Will You Snail?*보다 훨씬 더 많은 위시리스트와 크리에이터 관심을 얻었다고 인정했다. (How To Market A Game, 2024-10-07 )

[분석]

이 사례의 가장 불편하지만 중요한 교훈 중 하나다.

좋은 게임의 품질과 시장 크기는 별개다.

같은 개발자, 비슷한 홍보 역량, 같은 Steam에서도 장르가 달라지면 성과가 크게 달라질 수 있다.

따라서 제품 선택 단계에서 이미 마케팅 결정의 상당 부분이 끝난다.

• 플레이어가 많은 장르인가?
• Steam 사용자가 돈을 내는 장르인가?
• 스트리머가 반복해서 플레이할 수 있는가?
• 업데이트가 다시 콘텐츠를 만들 수 있는가?

Thronefall은 이 네 가지에서 비교적 유리했다.

15. 가격 전략: 초기에 낮게 들어가고 제품 가치가 커지면서 올렸다

[사실]

EA 초기 가격은 최종 가격보다 낮았고, 이후 콘텐츠 증가와 함께 가격이 상승했다. How To Market A Game에 Jonas가 제공한 자료에서도 Thronefall은 당시 약 $12에 판매되지만 Early Access 시작 시점에는 훨씬 저렴했다고 설명한다. 현재 Steam 정가는 $12.99다. (How To Market A Game, 2024-10-07 , Steam, 2026-09-19 확인 )

[분석]

Early Access 가격을 단순 할인으로 보면 부족하다.

초기 구매자는 다음 리스크를 감수한다.

• 콘텐츠가 적음
• 밸런스가 바뀔 수 있음
• 기능이 미완성일 수 있음

낮은 초기 가격은 그 리스크에 대한 보상이다.

그리고 콘텐츠가 늘면서 가격을 올리면 다음 효과가 있다.

1. 초기 팬에게 좋은 거래였다는 만족을 준다.
2. 나중 구매자는 더 큰 완성 제품을 산다.
3. Early Access 참여에 시간적 인센티브가 생긴다.

다만 정확한 가격별 판매량·탄력성 데이터는 공개되지 않았다.

16. 수익화 모델: 프리미엄 단일 구매, 라이브서비스 과금 없음

[사실]

PC 핵심 모델은 일회성 프리미엄 구매다. 현재 Steam 정가는 $12.99이며 본편 내 배틀패스나 소비형 소액결제가 핵심 수익모델이라는 공개 자료는 없다. (Steam )

모바일판은 Doghowl Games가 포팅·퍼블리싱을 맡았다. 미국 App Store에서는 무료 다운로드와 인앱 구매가 표기되고 제품 설명에 “TRY BEFORE YOU BUY”가 명시되어 있다. (App Store, 2026-09-19 확인 )

[분석]

모바일에서 체험 후 구매 구조를 사용한 것은 PC 데모 전략과 철학적으로 유사하다.

먼저 핵심 재미를 체험시킨 뒤, 광고·에너지·가챠가 아니라 완제품 구매로 전환한다.

이는 게임의 브랜드인 “복잡성 없는 전략”과도 일치한다. 수익화 UX가 제품 UX보다 복잡해지지 않는다.

17. 업데이트 전략: 새 콘텐츠가 retention뿐 아니라 재유통 이벤트가 됐다

[사실]

How To Market A Game의 비교에서 Thronefall은 Early Access 중 반복 업데이트 덕분에 동시접속과 크리에이터 관심의 긴 꼬리를 유지했다. 일부 크리에이터는 새 업데이트마다 다시 게임을 다뤘다. (How To Market A Game, 2024-10-07 )

1.0에서는 3개 신규 맵과 새 장비·perk·mutator가 추가됐다. 2025년 2월 마지막 대형 콘텐츠 업데이트에서는 12개 미니 모드, True Endless, Reverse Siege, 추가 언어와 QoL 기능이 추가됐다. (GamesMarket, 2024-09-26 , SteamDB가 보존한 공식 패치노트, 2025-02-03 )

[분석]

업데이트의 경제적 역할은 단순히 기존 플레이어를 붙잡는 것이 아니다.

새 모드
→ 기존 플레이어 복귀
→ 동접 상승
→ 크리에이터 재방문
→ 영상·방송 증가
→ Steam 활동 신호 증가
→ 신규 사용자 발견

이렇게 리텐션 이벤트가 acquisition 이벤트로 바뀐다.

공식 업데이트별 판매 lift는 공개되지 않았지만, Jonas가 제공한 동접·크리에이터 패턴은 이 메커니즘과 일치한다.

18. 콘텐츠 레버리지: 새 맵보다 ‘규칙을 바꾸는 모드’가 효율적이었다

[사실]

마지막 대형 업데이트의 12개 mini-mode는 기존 맵과 시스템에 새로운 규칙을 부여하는 방식이 많았다. 예를 들어 True Endless는 한 맵에서 무한에 가까운 웨이브를 버티게 하고, Reverse Siege는 플레이어가 공격자 역할을 맡게 한다. (SteamDB/공식 패치노트, 2025-02-03 )

[분석]

2인 팀에게 가장 비싼 콘텐츠는 매번 새 자산·맵·적·애니메이션을 만드는 것이다.

반면 규칙 변형은 기존 자산을 재사용하면서 새로운 플레이를 만든다.

기존 자산 × 새 규칙 = 새 경험

이것은 작은 앱에서도 같은 원리로 적용할 수 있다.

• 기존 데이터에 새로운 뷰 제공
• 기존 기능을 다른 workflow preset으로 재조합
• 기존 템플릿에 제약 조건을 바꾸는 challenge 제공

작은 팀은 asset production보다 rules recombination으로 콘텐츠 배수를 높일 수 있다.

19. 커뮤니티 전략: 개발 로그는 신뢰와 피드백을 만들었지만 핵심 성장 엔진은 아니었다

[사실]

Jonas는 개발 초기부터 YouTube에 프로토타입, 아트 방향, 데모, 업데이트 제작 과정을 공개했다. 2023년 6월 데모 공개 영상만 해도 플레이 후 피드백을 요청하고 Discord 참여를 유도했다. (Jonas Tyroller YouTube, 2023-06-13 )

팀은 별도 커뮤니티 매니저를 두고 Discord와 Steam 포럼을 관리했다. (INDIEGAMES/WTF 인터뷰 )

[분석]

개발 로그의 가장 큰 가치는 “영상 조회수”보다 다음 세 가지였다고 볼 수 있다.

1. 초기 플레이어 풀 확보
2. 개발 과정의 신뢰 형성
3. 반복 피드백 채널 확보

하지만 Jonas 자신이 말했듯 YouTube 운영은 시간 대비 효율이 낮을 수 있다.

따라서 벤치마킹할 것은 모든 개발자가 유튜버가 되어야 한다가 아니다.

제품을 일찍 보여주고 피드백을 반복해서 받을 공개 채널 하나를 운영한다.

이것은 Discord, Steam 공지, 짧은 devlog, 뉴스레터 등으로도 충분히 구현 가능하다.

20. 크리에이터 루프: 플레이 가능한 ‘전략 이야기’가 계속 생겼다

[사실]

Jonas가 공유한 비교에 따르면 Thronefall은 *Will You Snail?*보다 YouTube·Twitch 크리에이터 커버리지가 훨씬 강했고, 일부 크리에이터는 여러 업데이트를 반복해서 다뤘다. (How To Market A Game, 2024-10-07 )

[분석]

전략 게임은 영상 콘텐츠에 유리한 특징이 있다.

• “이 빌드로 깨기”
• “경제만 올리면 가능한가”
• “최고 난이도”
• “이 무기 조합이 강하다”
• “무한 모드 몇 웨이브까지 가나”

즉 플레이어의 결정 과정 자체가 콘텐츠가 된다.

새로운 스토리 컷신이 없어도 크리에이터가 자신의 전략을 이야기할 수 있다.

이것이 업데이트 하나가 반복적으로 방송 소재가 될 수 있었던 이유 중 하나다.

21. 1.0과 Switch 동시 출시: 검증된 후 플랫폼을 넓혔다

[사실]

Thronefall은 PC Early Access로 1년 이상 검증한 뒤 2024년 10월 11일 PC 1.0과 Nintendo Switch 버전을 동시에 출시했다. (GamesMarket, 2024-09-26 , Nintendo )

[분석]

처음부터 PC·Switch·모바일을 동시에 만들었다면 2인 팀의 QA와 UI 복잡성이 크게 늘었을 것이다.

실제 순서는 다음이었다.

PC 프로토타입 → 데모 → PC Early Access → 1.0 + Switch → 모바일

플랫폼 리스크를 제품 리스크 뒤로 미뤘다.

작은 팀에게 매우 재현성이 높은 전략이다.

22. 모바일 포팅: 핵심 팀이 직접 모든 플랫폼을 떠안지 않았다

[사실]

2025년 모바일 버전은 Doghowl Games와 협업해 출시됐다. Grizzly Games는 공식 Steam 공지에서 Doghowl이 모바일 인터페이스, 성능 최적화, 모바일 특화 문제를 맡는다고 설명했다. (Steam 공식 공지, 2025-05-12 )

2026년 9월 현재 Google Play는 공개 설치 수 100K+, App Store 미국 페이지는 3.5K 평가, 4.6점을 표시한다. 다만 공식 모바일 총 다운로드·매출 수치는 공개되지 않았다. (Google Play , App Store )

[분석]

이것이 운영 레버리지다.

핵심 개발팀이 포팅까지 모두 직접 하면 성공한 게임이 오히려 다음 프로젝트를 막을 수 있다.

Thronefall은 검증 후 전문 파트너에게 플랫폼별 복잡성을 넘겼다.

창작자의 가장 희소한 자원은 코드 시간이 아니라 다음 좋은 게임을 만들 집중력일 수 있다.

23. 가장 흥미로운 후속 전략: 성공한 IP를 직접 끝까지 보유하지 않았다

[사실]

2025년 12월 18일 Mythwright는 Thronefall IP 전체를 Grizzly Games로부터 인수했다고 공식 발표했다. 인수 금액은 공개되지 않았다.

Paul Schnepf는 두 명뿐인 Grizzly Games가 Thronefall의 잠재력을 모두 확장하기에는 자원이 부족했고, 동시에 자신과 Jonas는 새 프로젝트로 옮기고 싶었다고 설명했다. Mythwright는 이후 콘텐츠 개발을 이어가고 Doghowl과의 모바일 협력도 유지한다고 밝혔다. (Mythwright, 2025-12-18 )

[분석]

이 사례의 가장 성숙한 선택 중 하나다.

인디 팀은 흔히 히트작이 나오면 그 제품을 영원히 운영해야 한다는 압력을 받는다.

하지만 2인 팀에서는 다음 문제가 생긴다.

성공 → 업데이트 요구 증가 → 포팅·지원 증가 → 기존 IP 운영이 전업화 → 새 게임을 만들 수 없음

Grizzly Games는 이 문제를 “팀을 20명으로 키운다”가 아니라 IP를 더 큰 운영 주체에게 넘긴다로 해결했다.

성공한 제품의 최적 운영자와 원래 창작자가 항상 같은 조직일 필요는 없다.

24. 개발 기간을 어떻게 봐야 하나

[사실]

• 2022년 말: 프로토타입 탐색 시작
• 2023년 6월: 데모
• 2023년 8월: EA
• 2024년 10월: 1.0
• 2025년 2월: Grizzly Games의 마지막 대형 콘텐츠 업데이트

개발진은 EA까지 약 180 실제 작업일, 달력 시간으로는 1년 이상이라고 설명했다. (INDIEGAMES/WTF 인터뷰 )

How To Market A Game의 2024년 분석에서 Jonas는 Thronefall의 누적 개발 투입을 당시 약 2인 × 3년 = 6 man-years 정도로 비교했다. 이 숫자는 단순 EA 진입 기간이 아니라 이후 지속 개발을 포함한 총투입을 비교하기 위한 근사치다. (How To Market A Game, 2024-10-07 )

[분석]

따라서 “22일 만에 만들었다”, “180일 만에 만들었다”, “3년 만들었다”는 표현은 서로 다른 범위를 말한다.

• 22일: 핵심 플레이 가능한 형태
• 180 작업일: EA 출시 가능한 제품
• 약 3년: 업데이트와 1.0까지 포함한 장기 투입 근사

인디 사례에서 개발 기간을 비교할 때 프로토타입, 최초 판매 버전, 1.0, 라이브 운영을 구분해야 한다.

25. 매출은 공개되지 않았다

[사실]

공식 판매량은 2025년 2월 100만 장 이상까지 공개되어 있다. 이후에도 여러 플랫폼으로 확장됐지만 2026년 9월 현재 더 높은 최신 공식 누적 판매량이나 매출액은 확인되지 않는다. (GamesMarket, 2025-02-03 )

[분석]

1,000,000 × $12.99로 매출을 계산하는 것은 부정확하다.

실제 매출에는 다음이 영향을 준다.

• Early Access 초기 저가
• 지역별 가격
• 할인
• Steam·Nintendo·Apple·Google 플랫폼 수수료
• 세금
• 환불
• 번들

따라서 공식 매출 자료가 없는 이상 숫자를 만들지 않는 것이 맞다.

26. 핵심 인플렉션 포인트

인플렉션 1 — 실패한 덱빌더를 빨리 버림

초기 중세 덱빌더 기획에 집착하지 않고 작은 왕국 방어 프로토타입으로 전환했다. (AUTOMATON, 2022-12-12 )

[분석] 성공의 첫 원인은 좋은 아이디어를 처음부터 맞힌 것이 아니라 나쁜 방향을 오래 유지하지 않은 것이다.

인플렉션 2 — 공개 데모에서 제품의 핵심을 증명

2023년 6월 데모를 공개한 뒤 8월 EA로 빠르게 넘어갔다. (YouTube, 2023-06-13 )

[분석] 내부 확신보다 실제 사용자 반응을 다음 투자 결정에 사용했다.

인플렉션 3 — EA 출시 때 이미 약 20만 위시리스트

(How To Market A Game, 2024-10-07 )

[분석] 출시 첫날부터 Steam이 테스트할 충분한 초기 수요 신호가 있었다.

인플렉션 4 — Discovery Queue와 크리에이터가 외부 audience를 넘어 확장

Steam 내부 추천이 출시일 트래픽의 절반 이상을 차지하는 날이 많았고, 크리에이터들이 업데이트 때 반복해서 돌아왔다. (How To Market A Game, 2024-10-07 )

[분석] 이 시점부터 성장의 주체가 개발자의 채널에서 플랫폼·크리에이터 생태계로 이동했다.

인플렉션 5 — 1.0 전에 이미 100만 장 직전

2024년 9월 1.0 직전 이미 100만 장에 가까운 판매량이었다. (GamesMarket, 2024-09-26 )

[분석] 1.0은 PMF를 찾는 순간이 아니라 검증된 제품을 새 플랫폼과 더 넓은 audience에 재출시하는 이벤트가 됐다.

인플렉션 6 — 성공 후 IP를 넘김

2025년 말 IP를 Mythwright에 매각했다. (Mythwright, 2025-12-18 )

[분석] 제품 성공과 조직 확장을 동일시하지 않았다.

27. 바이럴 메커니즘: 강한 referral보다 ‘관찰 가능한 전략’

Thronefall은 R.E.P.O.나 PEAK처럼 친구 초대가 구매를 직접 증가시키는 멀티플레이형 바이럴 제품이 아니다.

공식 referral coefficient나 친구 초대 전환율 자료도 없다.

[분석]

대신 바이럴은 관찰 가능한 전략 콘텐츠에서 나온다.

새 맵/모드
→ 플레이어가 다른 빌드 시도
→ 크리에이터가 공략·도전 영상 제작
→ 시청자가 핵심 루프를 이해
→ Steam에서 발견·구매

즉 사람 자체가 콘텐츠인 사회적 게임과 달리 Thronefall에서는 선택의 비교 가능성이 콘텐츠가 된다.

28. 리텐션 메커니즘: 긴 캠페인이 아니라 반복 가능한 결정 공간

공식 D1/D7/D30 지표는 공개되지 않았다.

[사실]

현재 게임에는 10개 맵, 9개 무기, 50개 이상의 perk, mutator, Eternal Trials, 미니 모드가 존재한다. (Steam )

[분석]

리텐션 구조는 콘텐츠 길이보다 조합에서 나온다.

맵 × 무기 × perk × mutator × 난이도 × 미니모드

개발자가 하나의 perk를 추가하면 기존 요소와의 조합이 여러 개 생긴다.

작은 팀에게 이상적인 구조다.

새 자산 1개가 플레이 세션 1개만 만드는 것이 아니라 여러 전략 실험을 만든다.

29. 대안 가설 검토

가설 A — “Jonas의 YouTube 채널 덕분이다”

부분적으로 맞다. 초기 audience와 피드백 baseline은 있었다.

하지만 Jonas 본인의 비교에서 Thronefall의 위시리스트 증가에는 자신의 영상 효과가 그래프에서 거의 보이지 않을 정도였고, 같은 개발자의 *Will You Snail?*은 큰 채널을 가지고도 훨씬 작은 성과를 냈다. (How To Market A Game, 2024-10-07 )

더 타당한 설명: 기존 채널은 초기 seed, 제품·장르·Steam 알고리즘이 scale을 만들었다.

가설 B — “전략 게임이라 원래 잘 팔렸다”

장르 tailwind는 분명 중요했다.

하지만 Steam에는 실패한 전략 게임도 매우 많다. Thronefall은 전략 장르의 수요를 이용하면서도 학습 부담을 크게 줄여 장르의 기존 시장 + 장르를 어려워하던 인접 시장을 함께 노렸다.

더 타당한 설명: 장르 선택이 유리했고, simplification thesis가 시장 폭을 더 넓혔다.

가설 C — “가격이 싸서 팔렸다”

EA 초기 저가는 분명 구매 마찰을 낮췄다.

하지만 1.0 시점에는 가격이 $12 수준까지 올라간 상태에서도 판매와 리뷰가 강했다. 가격은 단독 원인보다는 짧고 명확한 경험의 리스크를 낮추는 보조 변수로 보는 편이 타당하다.

가설 D — “Steam 알고리즘 운이었다”

알고리즘 노출의 세부 조건은 통제할 수 없고 운도 존재한다.

하지만 Discovery Queue가 노출을 늘리려면 최초 사용자 반응이 유지되어야 한다. 높은 리뷰, 장르 적합성, 반복 업데이트가 있었기 때문에 알고리즘의 운이 왔을 때 오래 증폭될 수 있었다.

가설 E — “미니멀 그래픽이라 개발이 쉬웠다”

비주얼 단순화는 비용을 줄였지만 핵심 기술 위험이 사라진 것은 아니다. Jonas는 이후 인터뷰에서 pathfinding이 개발에서 가장 어려운 기술 문제 중 하나였다고 설명했다. (The Pragmatic Engineer, 2025-01-29 )

더 타당한 설명: 모든 기술을 쉽게 만든 것이 아니라, 플레이어 가치가 낮은 복잡성을 제거해 어려운 부분에 집중했다.

30. 운의 요소

[분석]

Thronefall 성공에서 재현하기 어려운 운과 맥락은 분명 존재한다.

• Steam에서 건설·전략 장르 수요가 강한 시기
• 기존 ISLANDERS 브랜드와 개발자 경력
• Jonas의 20만+ YouTube audience
• Future Friends의 마케팅 네트워크
• 특정 크리에이터들이 반복적으로 다뤄 준 것
• Discovery Queue가 장기간 강하게 노출한 것
• 2023~2024년 ‘작지만 깊은 전략 게임’ 수요와의 타이밍

The Pragmatic Engineer 인터뷰에서도 성공 조언과 함께 luck의 역할을 별도 주제로 다뤘다. (The Pragmatic Engineer, 2025-01-29 )

따라서 100만 장이라는 결과는 복제 대상이 아니다.

복제할 것은 운이 왔을 때 이를 증폭할 제품 구조다.

31. 실패 위험과 한계

1) 너무 단순하게 만들면 깊이까지 사라질 위험

미니멀리즘은 기능 삭제가 아니다. 전략의 핵심 trade-off가 남아야 한다. 건설 슬롯·단순 경제만 복제하고 실제 선택의 긴장감이 없다면 밋밋한 게임이 된다.

2) Steam 알고리즘 의존

내부 추천이 큰 유통 채널이었다는 것은 장점이지만, 동시에 플랫폼 의존이다. 초기 반응이 약하면 같은 성장 곡선이 나오지 않을 수 있다.

3) 업데이트 cadence 부담

Early Access의 긴 꼬리는 업데이트와 연결되어 있었다. 작은 팀에게는 지속 콘텐츠 제작이 번아웃·다음 프로젝트 지연으로 이어질 수 있다.

4) 성공 후 운영 기대치가 팀 규모를 초과

결국 Grizzly Games는 “두 명으로 Thronefall의 잠재력을 모두 확장하기 어렵다”고 판단해 IP를 Mythwright에 넘겼다. (Mythwright, 2025-12-18 )

5) 기존 audience를 과대평가할 위험

Jonas처럼 큰 개인 채널이 없는 팀은 같은 초기 baseline을 기대하면 안 된다.

6) 장르 수요는 변한다

2023년의 전략·타워디펜스 시장 조건이 미래에도 동일하다고 볼 수 없다.

32. 재현 가능한 요소와 재현하기 어려운 요소

33. 다른 인디 개발자가 실제로 벤치마킹할 우선순위

P0 — 기능 추가보다 ‘두통 제거 목록’을 먼저 만든다

핵심 장르의 사용자가 싫어하는 반복 업무·UI·설정·관리 요소를 모두 적는다.

질문은 다음이다.

이것이 실제 재미인가, 아니면 장르 관습 때문에 남아 있는 관리 비용인가?

Thronefall은 수리, 복구, 과도한 유닛 마이크로, 자유 배치의 일부 부담을 제거했다.

P0 — 2주 안에 핵심 trade-off를 검증한다

콘텐츠가 아니라 “선택이 재미있는가?”를 먼저 본다.

Thronefall이라면 경제 vs 방어, 직접 전투 vs 배치 전략이다.

P0 — 첫 세션에서 가치 있는 결정까지 시간을 측정한다

튜토리얼 시간보다 첫 전략적 선택까지 걸리는 시간이 중요하다.

P0 — 실패 후 재작업을 없앤다

사용자가 실패한 뒤 이미 했던 일을 그대로 반복하는 시간이 얼마나 되는지 측정한다.

P1 — 데모를 행사 장식이 아니라 PMF 테스트로 사용한다

Steam 페이지·데모를 일찍 열고, completion·wishlist·재실행·피드백을 다음 개발 결정에 사용한다.

P1 — 플랫폼 내부 추천에 최적화된 첫인상을 만든다

capsule, 태그, 첫 5초 영상, 한 문장 pitch가 정확히 같은 제품 가치를 말하게 한다.

P1 — 업데이트를 ‘새 콘텐츠’가 아니라 ‘새 마케팅 순간’으로 계획한다

업데이트마다 크리에이터에게 설명 가능한 한 문장 훅을 만든다.

예: “이제 공격자가 된다”, “한 맵에서 무한 웨이브를 버틴다.”

P1 — 규칙 변형으로 콘텐츠 레버리지를 만든다

새 자산보다 기존 시스템의 조합과 제한을 바꾸는 모드를 먼저 실험한다.

P2 — 성공 뒤 포팅과 운영을 외부화할 기준을 정한다

핵심 개발자의 시간이 새 제품 개발보다 포팅·지원에 더 많이 쓰이기 시작하면 파트너를 검토한다.

P2 — ‘계속 운영’이 유일한 성공 전략이라고 가정하지 않는다

팀의 창작 목표와 운영 요구가 갈라지면 라이선스·퍼블리싱·IP 매각도 선택지가 될 수 있다.

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

35. 가장 중요한 인과관계: 단순화가 마케팅까지 연결됐다

[분석]

Thronefall의 성공을 단순히 “게임이 재미있어서”라고 설명하면 실행 가능한 교훈이 적다.

더 구체적인 인과관계는 다음과 같다.

RTS의 불필요한 복잡성 제거
→ 입문자도 몇 분 안에 핵심 루프 이해
→ 데모에서 제품 가치를 빠르게 경험
→ 높은 wishlist·긍정 반응
→ Steam Discovery Queue가 더 넓은 장르 audience에 노출
→ 새 구매자와 크리에이터 증가
→ 업데이트로 기존 유저·크리에이터 재방문
→ 긴 판매 꼬리와 추가 wishlist
→ 1.0·Switch·모바일로 새 플랫폼 확장

즉 제품 단순화 → 전환 → 알고리즘 유통 → 반복 노출이 하나의 연결된 시스템이었다.

36. 이 사례에서 가장 재현하기 어려운 것

100만 장이라는 숫자 자체다.

Jonas와 Paul은 이미 여러 상용 게임을 끝내 본 숙련자였고, Jonas에게는 큰 YouTube audience가 있었으며, ISLANDERS라는 성공 경험과 Future Friends의 마케팅 지원도 있었다.

Steam의 2023~2024년 장르 수요, Discovery Queue 노출, 크리에이터 채택도 통제할 수 없다.

따라서 다음 공식을 복제하려 해서는 안 된다.

“2명이 미니멀 전략 게임을 만들고 유튜브 devlog를 올리면 100만 장.”

그보다 재현 가능한 공식은 다음이다.

작은 팀은 큰 장르의 핵심 만족을 찾아내고, 그 만족과 직접 관계없는 복잡성을 과감히 삭제하고, 아주 작은 버전으로 시장에 일찍 노출한 뒤, 실제 반응이 강할 때만 콘텐츠와 플랫폼을 확대한다.

37. 최종 벤치마킹 결론

Thronefall에서 다른 인디 개발자가 가장 먼저 가져가야 할 것은 미니멀 그래픽도, 타워디펜스도, 낮/밤 구조도 아니다.

가장 중요한 것은 “무엇을 더 넣을까?”보다 “사용자가 원하지 않는 일을 무엇까지 없앨 수 있을까?”를 제품 전략의 중심에 둔 것이다.

Grizzly Games는 전략 장르에서 사람들이 좋아하는 것은 남겼다.

• 경제와 방어의 trade-off
• 병력 구성
• 업그레이드
• 전투 결과를 직접 보는 만족
• 빌드 실험

반면 다음과 같은 부담은 줄였다.

• 긴 튜토리얼
• 과도한 APM
• 수리 노동
• 복잡한 자유 배치
• 실패 후 장시간 원상복구
• 수십 개 유닛의 동시 마이크로

그 결과 제품은 더 작아졌지만 시장은 오히려 넓어졌다.

그리고 성공 이후에도 같은 원칙이 이어졌다. 모든 플랫폼을 직접 만들지 않았고, 모든 커뮤니티 업무를 핵심 개발자가 떠안지 않았으며, 결국 자신들이 더 이상 최적 운영자가 아니라고 판단하자 IP 자체를 더 큰 파트너에게 넘겼다.

이 사례를 한 문장으로 압축하면 다음과 같다.

Thronefall은 ‘작게 만드는 법’보다 ‘작게 남겨야 할 것과 절대 삭제하면 안 되는 것을 구분하는 법’으로 성공했다.

다른 인디 개발자가 바로 적용할 첫 질문은 이것이다.

“우리 장르에서 사용자가 정말 돈을 내는 핵심 만족 3개를 남기고, 나머지 복잡성의 절반을 없애면 제품이 더 좋아질 수 있는가?”

그 질문에 ‘그렇다’고 답할 수 있다면 Thronefall의 가장 중요한 전략을 이미 벤치마킹하기 시작한 것이다.

주요 출처