Manor Lords 성공 사례 분석: 7년짜리 취미 프로젝트가 320만 위시리스트와 400만 장 판매로 이어진 과정

이번 사례는 최근 다룬 Stacklands, Tally, Against the Storm, Lethal Company, A Little to the Left, Content Warning, Vampire Survivors, Dwarf Fortress, Stardew Valley 등과 겹치지 않도록 **Slavic Magic의 《Manor Lords》**를 선정했다.

이 사례는 흔히 “1인 개발자가 만든 초대박”으로 요약되지만, 그렇게 보면 중요한 부분을 놓친다. Manor Lords는 Greg Styczeń이 약 7년 동안 중심 개발자로 끌고 온 프로젝트인 것은 맞지만, Patreon과 Epic MegaGrant 이후 전문 프리랜서를 활용했고, 출시 전후에는 퍼블리셔 Hooded Horse의 마케팅·QA·커뮤니티 지원을 받았으며, 이후 프로그래밍·아트·디자인·AI 영역의 팀도 확대됐다. 즉 한 명의 강한 제품 비전과 다수의 외부 레버리지를 결합한 구조로 보는 편이 정확하다. Unreal Engine 인터뷰, 2024-04-25  PC Gamer, 2024-05-03 

최신 공식 판매 마일스톤은 2026년 8월 27일 기준 전 스토어 합산 400만 장 이상이다. 게임은 아직 Early Access이며, 2026년 8월 Major Update #8까지 계속 확장되고 있다. Hooded Horse 보도자료 재게시, 2026-08-27  Steam/SteamDB 업데이트 노트, 2026-08-27 

한눈에 보는 결론

Manor Lords의 성공은 “중세 도시 건설 게임을 잘 만들어서”만으로 설명하기 어렵다. 더 설득력 있는 구조는 다음과 같다.

오랜 장르 집착과 제작 경험
× 한눈에 이해되는 시각적 차별화
× 도시 건설과 전술 전투를 같은 세계 안에서 연결한 제품 포지셔닝
× 2020년부터 매우 이른 Steam 페이지·트레일러 공개
× 2022 Steam Next Fest 데모의 폭발적인 위시리스트 수집
× 출시까지 2년 더 기다리며 기대를 축적
× 퍼블리셔의 전략게임 전문 유통·인플루언서·QA 레버리지
× 3.2M 위시리스트라는 거대한 launch inventory
× $39.99 premium 가격에도 1일 100만 장 판매
× Early Access를 ‘완성 약속’보다 ‘listen, verify, implement’ 과정으로 정의

가장 재현할 가치가 큰 것은 400만 장 판매 자체가 아니다. “출시일에 처음 발견되는 게임”이 아니라, 몇 년 동안 사람들이 계속 보게 되는 게임을 만드는 방식과, 완성 전에 수요를 측정하면서도 너무 이른 상업 출시를 하지 않은 방식이 더 중요하다.

공개된 핵심 수치

공개 자료가 없는 수치

신뢰할 만한 1차·공식 자료에서 총매출, 순매출, 개발비 총액, Greg 개인 순수익, Patreon 누적액, Epic MegaGrant 정확한 금액, 퍼블리셔 revenue share, 마케팅비, CAC, Game Pass 계약금, 환불률, D1/D7/D30 retention, 플랫폼별 판매량, 현재 정확한 개발팀 인원수는 확인하지 못했다.

따라서 400만 장 × $39.99 같은 방식으로 매출을 추정하지 않는다. 출시 할인, 지역 가격, 스토어 수수료, Game Pass, 퍼블리셔 계약이 모두 빠지기 때문이다.

1. 창업자·개발자 배경: ‘첫 게임을 만든 천재’가 아니라 오랜 취미 개발자의 첫 대형 프로젝트

[사실]

Greg Styczeń은 어린 시절 RPG Maker 2000으로 게임 제작을 시작했고 Flash, Dark Basic을 거쳐 Unreal Engine으로 이동했다. Manor Lords는 그의 첫 “serious project”라고 본인이 표현했지만, 게임 제작 자체는 오래된 취미였다. 초기에는 영상 프리랜서 일을 하면서 파트타임으로 개발했다. Unreal Engine, 2024-04-25 

그는 Stronghold: Crusader, Knights & Merchants, The Settlers, Age of Empires 계열의 전략게임을 좋아했고, RTS를 직접 만들어보고 싶었다고 설명했다. 같은 인터뷰에서 Manor Lords는 출시까지 거의 7년에 걸친 프로젝트였다고 밝혔다.

[분석]

이 사례를 “게임개발 경력이 없는 1인이 7년 버텨서 성공”으로 해석하면 재현 가능성이 떨어진다.

더 정확한 구조는:

오랜 취미 제작 경험
→ 자신이 깊게 아는 장르 선택
→ part-time으로 리스크 제한
→ 시장 반응이 커진 뒤 full-time 전환
→ 외주·퍼블리셔 레버리지 추가

이다.

처음부터 회사를 만들고 burn rate를 키우지 않았다는 점이 중요하다. 확신보다 증거가 커질수록 비용 구조를 키웠다.

2. ‘솔로 개발’이라는 표현을 정확히 해석해야 한다

[사실]

Greg가 프로젝트의 주 개발자이자 최종 의사결정권자였던 것은 분명하다. 그러나 Patreon과 MegaGrant 이후 전문 프리랜서에게 mocap cleanup, illustration 등 작업을 외주했고, credits에는 추가 프로그래머·3D artist·animator·concept artist·historical consultant 등이 포함됐다. 퍼블리셔 CEO Tim Bender도 구조를 **“solo developer plus contractors”**라고 설명했다. PC Gamer, 2024-05-03 

2025년에는 Slavic Magic이 프로그래밍·아트·디자인·AI 분야의 팀으로 확대됐다고 Greg가 공개했다. 정확한 현재 headcount는 이번 조사에서 신뢰할 만한 고정 숫자를 확인하지 못했다. PC Gamer, 2025-04-28 

[분석]

따라서 Manor Lords의 진짜 운영 모델은:

비전·제품 결정은 한 사람에게 집중

• 전문작업은 필요할 때 외부 인력 사용
• 퍼블리셔가 유통·QA·커뮤니티 레이어 제공

이다.

이 모델은 소규모 개발자가 “모든 것을 직접 해야 한다”는 생각보다 훨씬 현실적이다.

핵심역량만 내재화하고, production value를 올리는 전문작업을 외부에서 산다.

3. Product thesis: ‘격자 위에 효율적인 도시’를 만드는 게 아니라 ‘실제로 생겨난 것처럼 보이는 중세 정착지’를 만든다

[사실]

Manor Lords의 공식 포지셔닝은 in-depth city building + tactical battles + economic/social simulation이다. 도로를 자유롭게 그리고, 주거 plot이 도로·지형을 따라 유기적으로 형성되며, 계절과 경제가 변하고 군대를 직접 운용한다. Steam 공식 페이지 

Greg는 여러 고전 전략게임의 영향을 받았다고 밝혔고, 제품은 도시 건설과 실시간 전술전투를 같은 중세 세계 안에 배치했다. Unreal Engine, 2024-04-25 

[분석]

기존 city builder의 일반적 만족은:

격자 최적화
→ 생산량 증가
→ 도시 확대.

Manor Lords가 강하게 밀어붙인 감정은 조금 다르다.

빈 들판
→ 길이 생김
→ 집이 길을 따라 자연스럽게 생김
→ 사람들이 실제로 걷고 물건을 옮김
→ 멀리서 보면 ‘마을이 자란 것처럼’ 보임.

즉 optimization뿐 아니라 authorship와 관찰의 만족이 크다.

이 차이가 screenshot·trailer·YouTube에서도 바로 보인다.

4. 제품의 가장 강한 마케팅 자산은 설명문이 아니라 ‘한 장의 화면’이었다

[분석]

Manor Lords는 전투 시스템이나 생산 체계를 자세히 이해하지 않아도 다음 장면만으로 욕망을 만들기 쉽다.

• 언덕 아래 자연스럽게 굽은 중세 마을
• 밭을 가는 농민
• ox가 목재를 운반하는 모습
• 멀리 성당과 manor가 보이는 장면
• 수십~수백 명 병력이 들판에서 충돌하는 전투

이 제품은 feature 설명 이전에 결과물 fantasy를 보여줄 수 있다.

Steam wishlist 시대에 매우 강한 특성이다.

사용자는 게임을 아직 구매할 수 없어도:

“언젠가 저 마을을 만들어보고 싶다.”

라는 이유만으로 wishlist에 넣을 수 있다.

5. 핵심 UX ① — gridless 건설은 기능이 아니라 positioning

[분석]

도시건설 장르에서 grid는 production과 usability에 매우 유리하다. 하지만 grid를 쓰면 screen만 보고 다른 게임과 차이를 만들기 어렵다.

Manor Lords는 유기적 도로와 plot shape를 통해:

효율적으로 배치한 게임판

보다:

역사 속에서 자라난 마을

처럼 보이게 만든다.

이 선택은 UX complexity와 pathfinding 부담을 증가시키지만, 동시에 제품을 시각적으로 차별화한다.

즉 비용이 큰 기능이지만 marketing surface에도 직접 기여하는 기능이다.

6. 핵심 UX ② — ‘도시건설’과 ‘전투’를 별개 모드로 분리하지 않았다

[사실]

공식 설명은 city building, economic/social simulation, large-scale tactical battles를 한 제품의 핵심축으로 제시한다. Steam 

[분석]

전투는 단순 미니게임이 아니다.

도시에서:

식량 생산
장비 제작
인구 확보
세금·wealth 축적

이 군사력과 연결된다.

그리고 전쟁은 다시:

노동력 손실
영토
경제 안정성

에 영향을 준다.

제품 fantasy가:

“도시를 만든다.”

에서:

“영지를 통치한다.”

로 확장된다.

이 positioning은 city builder만 좋아하는 사람과 medieval RTS 팬을 동시에 끌어올 수 있지만, 동시에 scope를 크게 키우는 위험도 있다.

7. 핵심 UX ③ — production chain의 가치는 숫자보다 ‘보이는 물류’

[분석]

많은 management game에서 자원 이동은 숫자로 처리된다.

Manor Lords는 주민과 ox가 실제로 자원을 운반하는 장면을 강조한다.

이 방식은 시스템 효율만 놓고 보면 번거롭다. 하지만 플레이어가:

왜 건물이 느린지
어디에서 병목이 생기는지
누가 무엇을 운반하는지

를 세계 안에서 관찰할 수 있다.

simulation이 UI가 아니라 animation으로 설명되는 것이다.

작은 팀에게 비싼 선택이지만, 다시 한번 gameplay와 visual marketing을 같은 투자로 해결한다.

8. 제품 thesis가 wishlist 친화적이었다

Wishlist는 “지금 당장 재미있다”보다:

언젠가 꼭 해보고 싶다.

를 만드는 제품에 특히 유리하다.

Manor Lords는 완성된 중세 마을이라는 명확한 aspiration을 보여준다.

[분석]

따라서 이 게임의 prelaunch 전략은 단순 trailer marketing과 잘 맞았다.

다른 인디 게임이:

실제로 30분 해봐야 재미를 이해.

한다면 Manor Lords는:

10초 영상으로 fantasy가 이해됨.

이것이 수년간 wishlist를 누적할 수 있었던 제품적 전제다.

9. 최초 기대치는 14,000 wishlist였다

[사실]

Greg는 2020년 announcement trailer 공개 당시 여자친구가 약 7,000 wishlist를 예상했고, 자신은 14,000이면 굉장할 것이라고 생각했다고 회고했다. 실제로는 2024년 1월 200만을 넘어섰다. PC Gamer, 2024-01-18 

[분석]

이 수치는 성공이 예상 범위를 얼마나 벗어났는지 보여준다.

400만 장 같은 결과를 planning assumption으로 삼으면 안 된다.

재현 가능한 것은:

“200만 wishlist를 목표로 한다.”

가 아니라:

작은 개발비로 시장에 일찍 신호를 내고, 예상보다 큰 반응이 오면 프로젝트 투자를 단계적으로 키운다.

이다.

10. 가장 중요한 inflection point 중 하나: 2022 Steam Next Fest

[사실]

2022년 10월 Next Fest 조사에서 Manor Lords는 일주일 동안 약 309,463 wishlist를 추가했고, 해당 조사 표본 중 압도적 1위였다. median demo playtime도 약 1시간 20분으로 매우 높았다. How To Market A Game, 2022-11-04 

Hooded Horse가 나중에 공개한 수치에서는 당시 demo가 500,000+ wishlist를 만드는 데 기여했다. MMORPG.com, 2024-04-22 

[분석]

이 이벤트가 강했던 이유는 단순 노출이 아니다.

Trailer는:

“예뻐 보인다.”

를 증명한다.

Demo는:

“실제로 이것을 1시간 넘게 하고 싶다.”

를 증명한다.

Wishlist가 단순 hype에서 실제 product demand로 바뀐 순간에 가깝다.

11. Demo를 계속 열어두지 않은 결정도 중요하다

[사실]

2022 Next Fest 데모는 기간 한정으로 제공됐고 이후 잠겼다. 당시 개발자는 오래된 빌드가 계속 유통되며 현재 제품을 잘못 대표하는 것을 원하지 않았다고 설명했다. Game8, 2024-04-22 

[분석]

일반적으로 demo는 항상 켜두는 것이 discovery에 좋다.

그러나 빠르게 변하는 Early Access 이전 제품에는 다른 비용이 있다.

오래된 demo
→ 현재 품질과 다른 first impression
→ support·bug report 혼선
→ streamer가 낡은 버전을 계속 보여줌.

Manor Lords는 demo를 영구 funnel이 아니라 검증 이벤트로 사용했다.

이것은 상당히 재현 가능한 판단이다.

12. 2022년에 대박 signal이 왔지만 바로 출시하지 않았다

[분석]

이 사례에서 특히 중요한 점이다.

Next Fest에서 수십만 wishlist가 추가되면 즉시 Early Access를 열어 현금화하고 싶어진다.

하지만 실제 출시는 2024년 4월이었다.

즉 큰 demand signal과 commercial launch 사이에 약 18개월이 더 있었다.

그 기간은:

• production quality 개선
• 시스템 보강
• 퍼블리셔 캠페인 준비
• creator coverage 확대
• wishlist compounding

에 쓰였다.

수요가 있다는 증거와 지금 출시해도 된다는 판단은 다른 문제라는 좋은 사례다.

13. 2024년 launch inventory: 3.2M wishlist

[사실]

출시 시점 Manor Lords는 약 3.2M Steam wishlists를 보유했다. Game Developer, 2024-04-29 

출시 전 약 2주 동안 press와 creator coverage가 급증하면서 약 800K wishlists가 추가됐다. Game Developer, 2024-05-16 

[분석]

여기서 launch 성공의 핵심은 release day에 광고를 산 것이 아니다.

출시 전 이미 320만 명에게 Steam notification을 보낼 수 있는 재고가 있었다.

인디 개발자가 출시를 이벤트 하나로 생각하면 안 되는 이유다.

launch day는 acquisition의 시작점이 아니라, 4년간 쌓은 관심을 conversion하는 날이었다.

14. Wishlist conversion은 실제로도 강했다

[사실]

Hooded Horse CEO Tim Bender는 2024년 5월 11일 기준 Manor Lords의 **lifetime wishlist conversion rate가 약 26%**라고 밝혔다. 그는 출시 이후에도 wishlist가 계속 추가되기 때문에 launch-day cohort 전환율과는 다르다고 명확히 설명했다. Game Developer, 2024-05-16 

GameDiscoverCo가 퍼블리셔 제공 데이터를 분석한 자료에서는 당시 lifetime wishlist adds 약 4.7M, deletes 약 330K, wishlist에서 발생한 purchases 약 1.2M이라는 데이터도 공개됐다. GameDiscoverCo, 2024 

[분석]

26%는 단순 “wishlists는 중요하다” 수준을 넘어선다.

Wishlist의 질이 높았다는 뜻이다.

그 질을 만든 것은:

• 수년간 계속 노출
• demo 경험
• 정확한 genre fit
• 가격과 제품 기대의 일치
• creator의 실제 gameplay coverage

의 합이다.

15. 출시 전략: ‘FOMO를 최대화’한 것이 아니라 오히려 압박을 줄였다

[사실]

출시가는 정가 $39.99였고 첫 2주간 25% launch discount가 적용됐다. 그런데 Hooded Horse CEO Tim Bender는 공식 launch message에서 돈이 빠듯하거나 Early Access가 맞지 않는다면 기다리라고 명시적으로 말했다. 앞으로도 25% 할인을 자주 할 것이며 “놓칠까 봐 서두를 필요가 없다”고 강조했다. 공식 출시 공지 

[분석]

일반 launch copy는:

지금 사세요.
한정 할인.
놓치지 마세요.

에 가깝다.

Manor Lords는 반대로:

아직 Early Access니까 맞지 않으면 기다려도 된다.

고 말했다.

이는 conversion을 일부 희생할 수도 있지만 장기적으로:

• 기대관리
• review sentiment
• publisher trust
• Early Access에 대한 오해 감소

에 도움이 된다.

소규모 팀에게 특히 중요한 전략이다. 과도한 기대는 support와 review debt로 돌아오기 때문이다.

16. 첫날 100만 장: 결과는 폭발적이었다

[사실]

출시 다음 날 Hooded Horse는 100만 장 이상 판매와 170K+ Steam concurrent players를 발표했다. 이후 SteamDB 역대 peak는 173,178명으로 기록됐다. PC Gamer, 2024-04-27  SteamDB 

3주가 되기 전에 200만 장을 넘었다. Game Developer, 2024-05-16 

2025년 2월 300만 장, 2026년 8월 400만 장으로 이어졌다. 4Gamers, 2025-02-10  Hooded Horse 보도자료 재게시, 2026-08-27 

[분석]

판매곡선에서 중요한 것은 첫 100만 장만이 아니다.

1일 1M
→ 3주 미만 2M
→ 약 10개월 3M
→ 약 28개월 4M.

즉 launch 이후 속도는 크게 느려졌지만 catalogue sales가 계속 이어졌다.

이는 wishlist backlog, 할인, 업데이트, Steam 노출이 장기적으로 계속 작동했다는 뜻이다.

17. Day-one Game Pass가 premium 판매를 죽이지 않았다

[사실]

Manor Lords는 Steam·GOG·Epic Games Store·Microsoft Store에서 판매됐고 PC Game Pass Game Preview에도 day one으로 포함됐다. Hooded Horse/Steam 출시 정보 

그럼에도 첫날 100만 장 이상 판매했다.

[분석]

이 사례만으로 “Game Pass가 판매를 늘린다”고 일반화할 수는 없다. 계약금도 공개되지 않았다.

다만 적어도 Manor Lords에서는:

subscription availability가 premium demand를 완전히 잠식하지는 않았다.

특히 Steam wishlist가 압도적으로 컸기 때문에 사용자는 이미 특정 storefront에서 소유하기를 원했다고 볼 수 있다.

18. 가격: $39.99는 저가 인디 전략이 아니다

[사실]

2026년 현재 정가는 $39.99다. Steam  2026년 8월 400만 장 milestone과 Major Update #8 공개 때는 35% 할인 프로모션이 진행됐다. 보도자료, 2026-08-27 

[분석]

Manor Lords는 Vampire Survivors나 Lethal Company처럼 낮은 가격으로 impulse purchase를 만든 사례가 아니다.

대신:

긴 개발기간
높은 production value
genre depth
수년간의 wishlist intent

를 $39.99 가격으로 monetization했다.

즉 가격보다 desire를 먼저 크게 만들었다.

19. 퍼블리셔 역할: PMF를 만든 것이 아니라 reach와 operations를 확장

[사실]

Hooded Horse는 Manor Lords의 publisher로 마케팅, QA, community sentiment monitoring 등을 지원했다. Tim Bender는 출시 직후에도 Greg가 최종 개발 결정을 내리고, 퍼블리셔 쪽은 feedback 정보와 지원 infrastructure를 제공한다고 설명했다. PC Gamer, 2024-05-03 

[분석]

좋은 publisher fit의 사례다.

이미:

visual hook
demo traction
huge wishlists

가 있었고, publisher는 이를:

press
creator
store
QA
community

로 확장했다.

작은 팀이 퍼블리셔를 고를 때 단순 advance 규모보다 이미 잘 작동하는 제품을 더 크게 만들 수 있는가를 봐야 한다.

20. Community strategy: ‘listen, verify, implement’

[사실]

Early Access 직전 Greg는 roadmap을 고정적으로 공개하지 않고 “listen, verify, implement” 방식으로 사용자 의견을 듣고 검증한 뒤 반영하겠다고 설명했다. 첫 달은 bug fix와 polish에 집중하고, Hooded Horse와 feedback을 모아 우선순위를 정하겠다는 접근이었다. PC Gamer, 2024-04 

출시 직후에도 trade mechanic 같은 구체적인 시스템을 두고 커뮤니티와 의견을 교환했다. PC Gamer, 2024-04-29 

[분석]

핵심은 “community-driven development”가 아니다.

사용자가 말한 대로 만들면 제품 방향이 흔들릴 수 있다.

더 좋은 문장은:

의견을 듣는다 → 실제 문제인지 확인한다 → 구현한다.

이다.

verify 단계가 가장 중요하다.

21. Early Access의 가장 큰 리스크: 압도적인 hype가 미완성 제품과 충돌

[사실]

출시 당시 Manor Lords는 Early Access였고, 일부 시스템과 콘텐츠는 미완성 상태였다. 출시 직후 몇몇 사용자는 업데이트가 며칠 없었다는 이유만으로 “abandoned” 우려를 제기하기도 했다. 퍼블리셔는 출시 4일 만에 이런 반응이 나오는 상황을 언급했다. PC Gamer, 2024-05-03 

[분석]

3.2M wishlist는 blessing이면서 liability다.

작은 프로젝트가 갑자기 수백만 명의 기대를 받으면:

• update 속도
• content 양
• bug tolerance
• roadmap 확실성

에 대한 기대가 AAA 수준으로 올라갈 수 있다.

즉 distribution이 production capacity보다 빨리 커진 것이 장기 리스크였다.

22. ‘그럼 50명을 채용하면 되지 않나?’가 틀린 이유

[사실]

출시 직후 Hooded Horse CEO Tim Bender는 성공했다고 사람을 50명씩 바로 채용하는 것이 답이 아니라고 설명했다. 빠른 대규모 확장은 core vision과 개발 효율을 오히려 해칠 수 있으며, 좋은 성장은 천천히 해야 한다는 취지였다. PC Gamer, 2024-05-03 

[분석]

이 판단은 이후 실제 문제를 보면 더 설득력 있다.

기존 codebase와 workflow가 한 사람 중심으로 만들어졌다면 신규 개발자를 넣는 순간:

onboarding
architecture 설명
coding convention 정리
refactor
vision alignment

가 필요하다.

매출이 100배 된다고 개발 throughput이 즉시 100배 될 수 없다.

23. 실제로 팀 확대는 coordination tax를 만들었다

[사실]

2025년 큰 업데이트가 오랫동안 지연된 뒤 Greg는 팀을 확대하면서 너무 많은 문제를 동시에 해결하려 했고, 새 디자이너와 vision을 맞추는 작업, 새 프로그래머가 기존 “solo dev spaghetti” codebase를 배우는 과정, 대규모 refactor가 지연을 만들었다고 설명했다. PC Gamer, 2025 

[분석]

이것은 매우 재현 가능한 교훈이다.

히트 이후 가장 위험한 결정 중 하나는:

“돈이 생겼으니 개발자를 많이 뽑자.”

다.

팀 확장 자체가 하나의 대형 프로젝트다.

특히 solo-developed codebase에서는 더욱 그렇다.

24. Technical debt가 성공 후에야 비싸게 보였다

[분석]

초기 solo development에서는 빠르게 기능을 만드는 것이 합리적이다.

그 코드가:

7년 뒤 400만 장 게임

• 여러 프로그래머
• 수년의 Early Access support

를 감당할 것이라고 처음부터 설계하는 것은 오버엔지니어링일 수 있다.

문제는 성공 후 전환 시점이다.

Manor Lords는 hit 이후:

feature throughput보다 architecture migration 비용

을 지불했다.

따라서 indie 개발자는 “기술부채를 만들지 말라”보다:

성공이 확인되면 어떤 코드를 먼저 팀용 구조로 바꿀지 목록을 미리 갖고 있어야 한다.

라고 해석하는 편이 현실적이다.

25. 2026년 Major Update #8: 기술기반 정비 후 다시 visible content로

[사실]

2026년 8월 27일 Major Update #8에서는:

• Wide Valley 신규 맵
• 완전 개편된 main HUD
• cows & calves
• oats
• animal feed
• cider·mead
• cheese production
• Construction Yard
• Advanced Construction
• seasonal assignment/breeding/produce
• AI 개선
• balance·bug fix

등이 메인 브랜치에 들어갔다. 공식 업데이트 노트, 2026-08-27 

Greg는 해당 노트에서 “새 콘텐츠가 부족하다”는 리뷰를 읽고 있다고 직접 언급하면서, 이번 업데이트가 긍정적인 방향 신호가 되길 바란다고 썼다.

[분석]

장기 Early Access에서 플레이어가 체감하는 것은:

내부 refactor 완료.

가 아니라:

내가 다시 해볼 이유가 생겼는가?

다.

기술부채를 갚는 기간과 visible content cadence 사이의 균형이 중요한 이유다.

26. 콘텐츠 루프: built-in virality보다 ‘creator-friendly spectacle’

Manor Lords에는 Tally의 badge나 Content Warning의 자동 영상 같은 명확한 제품 내 viral loop가 없다.

[분석]

대신 세 가지 외부 콘텐츠 surface가 강하다.

1. Transformation — 빈 들판이 거대한 마을로 바뀐다.
2. Detail — 주민·동물·건물 animation이 zoom 영상에 잘 잡힌다.
3. Battle spectacle — 전투 장면이 city-builder 영상보다 강한 thumbnail을 만든다.

따라서 creator는:

“내가 만든 마을”
“100일 생존”
“대도시 건설”
“대규모 전투”

처럼 자연스럽게 콘텐츠를 만들 수 있다.

출시 직전 press·creator wave가 2주 만에 약 800K wishlists를 추가했다는 수치는 이 surface의 효과를 잘 보여준다. Game Developer, 2024-05-16 

27. Retention은 ‘daily loop’가 아니라 ownership·mastery·새 settlement

정확한 retention cohort는 공개되지 않았다.

[분석]

구조적으로는 다음 요소가 재방문을 만든다.

• 더 효율적인 settlement를 다시 만들어보기
• 다른 resource distribution에 적응하기
• 경제와 군사 전략의 trade-off 실험
• 새 map·mechanic 업데이트 때 재시작
• 더 자연스럽고 아름다운 도시를 만들려는 aesthetic mastery

즉 retention은:

streak
daily reward

보다:

“이번에는 더 잘 만들 수 있다.”

는 mastery loop에 가깝다.

28. 업데이트와 할인은 catalogue relaunch 역할을 한다

[사실]

2026년 Major Update #8과 400만 장 milestone은 Steam 35% 할인과 함께 공개됐다. Hooded Horse 보도자료, 2026-08-27 

[분석]

큰 업데이트 단독보다:

업데이트

• milestone PR
• discount
• creator 복귀

를 겹치면 오래된 wishlist와 lapsed users를 동시에 다시 활성화할 수 있다.

출시를 한 번만 하는 것이 아니라 major patch마다 작은 재출시를 만든다.

29. Unreal Engine과 outsourcing이 operational leverage였다

[사실]

Greg는 custom engine을 만드는 대신 Unreal Engine을 사용했고, 장기간 UE를 사용한 결과 driver compatibility, rendering, SDK 등 많은 기반 문제를 직접 해결하지 않아도 됐다고 설명했다. MegaGrant 이후에는 mocap cleanup, illustration 등 전문 작업을 외주화했다. Unreal Engine, 2024-04-25 

그가 직접 강조한 교훈 중 하나는:

기술적으로 멋진 custom component보다 이미 존재하는 시스템을 쓰고, 재미와 scalability에 집중하라.

는 취지였다.

[분석]

작은 팀에서 differentiation하지 않는 기술을 직접 만드는 것은 사치일 수 있다.

Manor Lords가 돈을 써야 했던 곳은:

• organic settlement simulation
• visual fidelity
• historical art
• battle

이지:

• rendering engine
• driver compatibility

가 아니었다.

30. ‘scalability’라는 말이 콘텐츠 제작에도 적용됐다

[사실]

Greg는 AAA 수준 environment 하나를 만들 수 있더라도 “100개를 더 만들 수 있는가”를 생각해야 한다고 말했다. Unreal Engine, 2024-04-25 

[분석]

인디 제품에서 prototype quality보다 중요한 것은:

그 품질의 단위를 반복생산할 수 있는가?

다.

게임뿐 아니라 앱에도 적용된다.

예:

수작업 onboarding 하나는 아름답게 만들 수 있지만, 고객 segment 20개마다 새 flow가 필요하면 유지할 수 있는가?

기능의 화려함보다 생산 시스템의 반복성을 봐야 한다.

31. 가장 중요한 성공 인과관계

전체 흐름을 연결하면 다음이 가장 설명력이 높다.

어린 시절부터 전략게임·게임제작 취미
→ 약 2017년 Manor Lords part-time 개발
→ Unreal을 활용해 기술 scope 제한
→ organic medieval settlement라는 강한 visual thesis
→ 2020 announcement trailer 공개
→ 예상보다 큰 wishlist signal
→ Patreon으로 외주 활용 시작
→ 2021 Epic MegaGrant로 full-time 전환
→ 전문 freelance art·animation으로 production value 상승
→ Hooded Horse와 publisher partnership
→ 2022 Next Fest demo가 수십만 wishlist 생성
→ demo를 닫고 제품개선 지속
→ 바로 출시하지 않고 약 18개월 더 polish
→ 2024년 초 2M wishlist
→ creator·press pre-release campaign
→ 출시 직전 3.2M wishlist
→ $39.99 premium Early Access + 25% 할인
→ 1일 1M copies / 170K+ CCU
→ 3주 미만 2M copies
→ community feedback 기반 반복개선
→ hit 이후 무리한 대규모 hiring 대신 점진적 팀 확대
→ 그러나 codebase·alignment 문제로 update delay 발생
→ technical overhaul와 process 재설계
→ 2025 3M copies
→ 2026 Major Update #8 + 4M copies.

32. 가장 설명력 높은 성공 공식

장르에 대한 오랜 취향과 이해
× 10초 안에 보이는 visual differentiation
× wishlist에 잘 맞는 aspirational product fantasy
× 매우 이른 공개
× demo로 실제 playability 검증
× 반응이 클수록 개발비를 단계적으로 확대
× 출시를 서두르지 않음
× 전략게임 전문 publisher의 distribution
× 거대한 wishlist inventory
× premium pricing
× Early Access 기대관리
× 장기 업데이트로 catalogue value 유지.

대안 가설 1 — “중세 city builder라서 그냥 잘 팔린 것 아닌가?”

[사실]

City builder는 Steam에서 강한 장르였고 Manor Lords 출시 전에도 관련 장르 여러 게임이 wishlist 상위권에 있었다. PC Gamer, 2024-01-18 

[분석]

장르 tailwind는 분명 존재했다.

하지만 동일 장르 제품이 모두 3.2M wishlist를 얻는 것은 아니다.

Manor Lords의 차별점은:

city builder

• organic visual growth
• grounded medieval realism
• tactical battle.

즉 강한 카테고리 안에서 즉시 보이는 차이가 있었다.

대안 가설 2 — “Steam Next Fest가 다 했다”

Next Fest는 매우 큰 inflection point였다.

하지만 demo가 성공한 이유는 그 전부터 visual hook과 wishlist baseline이 있었고, demo median playtime이 약 80분으로 실제 engagement도 강했기 때문이다. How To Market A Game, 2022-11-04 

[분석]

Next Fest는:

좋은 제품 신호를 확대했다.

이벤트 자체가 수요를 만들어낸 것은 아니다.

대안 가설 3 — “퍼블리셔가 마케팅을 잘해서”

Hooded Horse의 역할은 크다.

특히 전략게임 audience, creator outreach, QA, community support에서 강한 leverage를 제공했다. PC Gamer, 2024-05-03 

[분석]

하지만 publisher가 붙기 전에도 프로젝트는 이미 강한 organic interest를 갖고 있었다.

따라서:

publisher가 PMF를 생성.

보다:

PMF와 visual hook이 있는 제품의 distribution ceiling을 높였다.

가 더 정확하다.

대안 가설 4 — “solo-dev 스토리가 바이럴돼서”

[분석]

“한 사람이 만든 야심작” narrative가 press hook으로 작용한 것은 사실일 가능성이 높다.

그러나 3.2M wishlist와 400만 장의 장기 판매를 story alone으로 설명할 수 없다.

더구나 실제 production에는 contractors·publisher support가 존재했다.

Solo-dev narrative는 attention amplifier이지 core product value는 아니다.

대안 가설 5 — “운이 좋았다”

[분석]

400만 장 scale은 power-law 결과이며 상당한 운이 있다.

Greg 본인도 처음에는 14K wishlists면 훌륭하다고 생각했다.

하지만 다음은 운이 아니다.

• 7년 동안 제품을 계속 개선
• visual identity 구축
• 데모 공개
• wishlist 축적
• full-time 전환 시점 조절
• specialist outsourcing
• publisher 선택
• 출시를 급하게 당기지 않은 판단

즉 성공 규모는 운이지만, 운을 받을 surface는 설계할 수 있다.

실패 위험과 한계

1. Hype-to-content gap

3.2M wishlist는 기대를 AAA 수준으로 끌어올렸다.

Early Access의 실제 콘텐츠 범위가 그 기대에 못 미치면 review와 community sentiment가 빠르게 악화될 수 있다.

리스크: 마케팅 성공이 개발 부담으로 전환된다.

2. 한 사람 중심 vision의 bus factor

제품 방향과 codebase가 Greg에게 강하게 집중돼 있었다.

리스크: 의사결정 속도는 빠르지만 팀 확장·지식 이전이 어렵다.

2025년 team expansion 과정의 지연이 실제 사례다. PC Gamer, 2025 

3. ‘city builder + RTS + simulation’의 scope 폭발

이 조합은 차별점이지만:

• AI
• pathfinding
• economy
• animation
• combat balance
• UI

를 모두 요구한다.

리스크: 한 영역을 고치면 다른 영역에 regression이 생기기 쉽다.

4. Early Access update expectation

사용자는 구매 후 개발 cadence를 사실상 서비스 약속처럼 해석한다.

실제로 출시 며칠 만에도 “abandoned” 반응이 나왔다. PC Gamer, 2024-05-03 

리스크: premium one-time purchase인데도 live-service 수준의 cadence expectation이 생길 수 있다.

5. 대규모 팀 채용이 곧 throughput 증가가 아님

신규 인력이 기존 solo codebase에 들어오면서 refactor와 vision alignment 비용이 발생했다.

리스크: 성공 후 hiring이 오히려 몇 달간 속도를 낮출 수 있다.

6. historical authenticity는 differentiation이면서 expectation debt

중세 분위기와 realism이 강점이지만, 사용자는 더 깊은 역사적 정확성을 기대하게 된다.

리스크: 모든 장비·건물·농업 시스템이 검증대상이 된다.

7. visual fidelity의 생산비

Manor Lords식 디테일은 trailer와 screenshots에 강하지만 asset·animation·optimization 비용이 크다.

리스크: 작은 팀이 표면만 따라 하면 content throughput이 무너질 수 있다.

맥락 특수적인 요소 vs 재현 가능한 요소

다른 인디 개발자가 우선순위별로 벤치마킹할 항목

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

실험 1 — 10초 Wishlist Test

게임이나 앱의 핵심 화면을 10초 무음 영상으로 만든다.

50명에게 보여주고 두 질문만 묻는다.

1. “무엇을 하는 제품 같나요?”
2. “나중에 써보고 싶나요?”

측정:

• category 이해율
• 차별점 회상률
• wishlist/메일등록 의향

설명이 없으면 차이가 보이지 않는다면 마케팅 카피보다 제품의 visible outcome을 먼저 개선한다.

실험 2 — Early Page, Late Launch

상업 출시 9~18개월 전에 store/landing page를 연다.

매월 기록한다.

• organic visitors
• wishlist/signups
• trailer conversion
• creator mentions

목표는 일찍 팔기 위한 것이 아니라 수요곡선을 관찰하기 위한 것이다.

wishlist가 약해도 제품 pivot 비용이 아직 낮다.

실험 3 — Demo Event ROI

항상 켜둔 demo와 이벤트 demo를 구분한다.

Next Fest나 특정 행사 7일 동안:

• demo downloads
• median playtime
• 20분 이상 플레이 비율
• wishlist adds
• wishlist / unique demo player

를 측정한다.

wishlist 수만 보지 말고 playtime을 같이 본다.

Manor Lords처럼 두 지표가 동시에 강하면 실제 제품 수요일 가능성이 높다.

실험 4 — Demo Kill Switch

데모 공개 전 종료조건을 정한다.

예:

이벤트 종료 후 48시간 뒤 비공개.

그 뒤 질문한다.

• 현재 build가 3개월 뒤에도 제품을 제대로 대표하는가?
• 오래된 버전 bug report를 받을 준비가 있는가?
• creator가 계속 오래된 version을 보여줘도 괜찮은가?

No가 많으면 permanent demo보다 기간 한정 validation을 선택한다.

실험 5 — Wishlist Quality Cohort

wishlist 유입원을 나눈다.

• trailer
• demo
• creator
• press
• festival
• organic Steam

출시 뒤 가능하면 source별 구매율을 비교한다.

직접 source conversion이 어려우면 launch 직후 survey로 보완한다.

목표는:

100K wishlist.

보다:

어떤 wishlist가 실제 구매로 이어지는지.

를 아는 것이다.

실험 6 — Hype/Readiness Ratio

매달 다음 두 점수를 1~10으로 평가한다.

Hype

• wishlist growth
• creator interest
• press
• Discord activity

Readiness

• crash rate
• tutorial completion
• content hours
• major bug count
• support capacity

Hype / Readiness가 지나치게 높아지면 launch date를 당기지 말고 기대관리와 품질에 투자한다.

실험 7 — “No FOMO” Launch Copy A/B

A:

지금 사세요. 출시 할인은 곧 끝납니다.

B:

Early Access가 맞지 않으면 기다려도 됩니다. 앞으로도 할인 기회가 있습니다.

측정:

• conversion
• refund
• review sentiment
• support complaint

단기 구매율뿐 아니라 30일 품질지표를 같이 본다.

실험 8 — Contractor Boundary Map

모든 업무를 세 칸으로 분류한다.

1. Core vision — 반드시 창업자/핵심팀
2. Specialist production — 외주 가능
3. Commodity infrastructure — engine/tool/SaaS 사용

예:

목표는 “1인이 다 한다”가 아니라 1인이 무엇을 직접 해야 하는지 명확히 하는 것이다.

실험 9 — Publisher Fit Matrix

publisher 후보를 advance만으로 비교하지 않는다.

1~5점으로 평가한다.

• 장르 audience
• Steam launch 경험
• creator network
• QA
• localization
• community management
• creative control
• 장기 Early Access support

현재 약한 영역을 가장 잘 채우는 partner를 선택한다.

실험 10 — Listen / Verify / Implement Board

feature request를 바로 backlog에 넣지 않는다.

각 요청에 세 칼럼을 만든다.

예:

“무역을 더 강하게 해주세요.”

를 그대로 구현하지 않고:

“현재 특정 resource가 dead end인가?”

를 먼저 데이터와 playtest로 확인한다.

실험 11 — Hit 후 90일 Hiring Freeze

예상보다 큰 매출이 발생하면 90일 동안 large-scale full-time hiring을 보류한다.

먼저 측정한다.

• recurring support workload
• update bottleneck
• code ownership
• QA debt
• community workload
• art backlog

그 뒤 반복적으로 존재하는 병목만 채용한다.

일시적 launch load를 영구 조직으로 바꾸지 않는다.

실험 12 — Codebase Teamability Audit

두 번째 프로그래머가 들어온다고 가정한다.

질문:

• 빌드까지 몇 시간이 걸리는가?
• architecture 문서가 있는가?
• save migration을 이해할 수 있는가?
• automated test가 어디 있는가?
• critical system owner가 한 명뿐인가?

모든 답을 시간으로 환산한다.

신규 개발자 첫 의미 있는 commit까지 걸리는 일수를 운영 KPI로 둔다.

실험 13 — Major Update Relaunch Bundle

큰 업데이트를 각각 따로 하지 않는다.

같은 주에:

• major content update
• Steam discount
• creator keys
• returning-user email
• patch trailer
• milestone PR

를 묶는다.

측정:

• lapsed-user return
• wishlist conversion
• units/day
• review volume
• creator coverage

업데이트를 작은 launch로 만든다.

실험 14 — “100개 만들 수 있는가?” 테스트

새 asset·level·workflow를 만들 때 묻는다.

이 품질을 하나 만드는 게 아니라 100개 만들 수 있는가?

No라면:

• proceduralize
• simplify
• outsource
• template화

중 하나를 선택한다.

Manor Lords 개발자가 직접 강조한 scalability 질문을 production gate로 쓰는 방식이다. Unreal Engine, 2024-04-25 

실험 15 — Marketing Asset = Product Output 비율

최근 20개 marketing asset을 분류한다.

• 실제 gameplay 그대로 사용
• gameplay를 많이 편집
• 별도 cinematic/graphic 필요

실제 gameplay만으로 강한 asset이 30% 미만이면:

제품 자체가 보여주기 좋은 결과물을 만드는가?

를 재검토한다.

Manor Lords의 가장 강한 마케팅은 중세 마을과 대규모 전투라는 제품 결과 자체였다.

가장 표면적으로 복제하면 안 되는 것

Manor Lords를 보고 따라 하기 쉬운 것은:

Unreal Engine
중세
city builder
높은 그래픽
혼자 개발
Patreon
Early Access.

이 조합을 복제한다고 성공하지 않는다.

오히려 비용만 커질 가능성이 높다.

복제해야 할 것은 다음 구조다.

자신이 매우 오래 이해한 장르에서 시작한다.

→ 한 화면만으로 결과 fantasy가 보이게 만든다.

→ 초기에 공개해 wishlist로 interest를 측정한다.

→ 데모로 실제 playability를 확인한다.

→ 반응이 커질 때만 비용·외주·full-time 비중을 늘린다.

→ 큰 signal이 와도 출시 readiness와 혼동하지 않는다.

→ publisher는 이미 작동하는 제품의 reach와 operational gaps를 보완하는 데 쓴다.

→ 성공 직후 사람을 급격히 늘리지 않는다.

→ 커뮤니티 요구를 그대로 구현하지 않고 검증한다.

→ major update마다 catalogue를 다시 launch한다.

최종 결론

Manor Lords에서 가장 눈에 띄는 공개 숫자는 다음이다.

약 7년 개발
2022 Next Fest 주간 약 309K wishlist 증가
demo 효과 500K+ wishlist
2024년 1월 2M wishlists
launch 3.2M wishlists
출시 전 2주 약 800K wishlist 증가
$39.99 정가
출시 약 1일 1M copies
173,178 Steam peak CCU
3주 미만 2M copies
2024-05 lifetime wishlist conversion 26%
2025-02 3M copies
2026-08 4M copies.

그러나 다른 인디 개발자가 가장 먼저 벤치마킹할 숫자는 400만 장이 아니라 14,000일 수 있다.

처음 Greg가 “성공하면 이 정도”라고 생각한 wishlist 목표다. 실제 결과는 그 예상의 수백 배가 됐다. PC Gamer, 2024-01-18 

이 차이가 보여주는 것은:

power-law 성공을 예측할 수 없다는 것.

이다.

그래서 더 중요한 전략은 성공 규모를 예측하는 것이 아니라 작은 비용으로 시장에 계속 option을 열어두는 것이다.

Manor Lords는:

part-time hobby
→ trailer
→ Patreon
→ MegaGrant
→ contractors
→ demo
→ publisher
→ 3.2M wishlists
→ premium Early Access

순으로 리스크를 단계적으로 키웠다.

두 번째로 중요한 숫자는 1시간 20분이다.

Next Fest demo에서 관측된 높은 median playtime은 trailer hype가 실제 제품 engagement로 이어지고 있다는 강한 증거였다. How To Market A Game, 2022-11-04 

세 번째는 **26%**다.

수백만 wishlist가 단지 vanity metric이 아니라 실제 구매로 전환되는 high-intent audience였음을 보여준다. Game Developer, 2024-05-16 

마지막 교훈은 성공 이후에 있다.

돈이 생겼다고 50명을 즉시 뽑으면 개발이 50배 빨라지지 않는다.

실제로 Manor Lords는 팀 확장과 solo-dev codebase의 충돌을 겪었고, 대규모 refactor와 vision alignment 때문에 업데이트가 늦어졌다. 이는 실패라기보다 초소형 프로젝트가 대형 상업제품으로 변할 때 발생하는 전환비용이다.

따라서 Manor Lords의 재현가치 높은 성공공식은 다음처럼 정리할 수 있다.

깊은 장르 이해 × 즉시 보이는 visual differentiation × early wishlist collection × high-engagement demo × staged investment × premium desire × specialist outsourcing × genre-fit publisher × expectation management × slow team scaling × community verification loop × catalogue relaunches

다른 인디 개발자가 이 사례에서 바로 던져야 할 질문은 네 가지다.

“우리 제품은 10초만 봐도 wishlist에 넣고 싶은 결과를 보여주는가?”

“사람들이 관심을 보이는 것과 지금 출시할 준비가 된 것을 구분하고 있는가?”

“성공했을 때 채용부터 할 것인가, 아니면 먼저 codebase와 workflow를 팀이 들어올 수 있게 만들 것인가?”

그리고 가장 중요하게:

“출시일까지 기다릴 audience를 지금부터 쌓고 있는가?”

주요 출처와 게시일