Skip to Content
Indie GamesMobile202609Luck be a Landlord

Luck be a Landlord — 수작업 레벨 없이 ‘경제 압박 + 드래프트 + 시너지’만으로 수십 시간을 만드는 법

한 줄 결론 — [의견] Luck be a Landlord는 슬롯머신이라는 시각적 은유를 쓰지만 실제 제작 구조는 **“매 턴 자동 시뮬레이션 → 3개 중 하나를 선택 → 제한된 턴 안에 다음 경제 목표를 넘김”**이라는 초저비용 데이터 게임이다. 대규모 맵·전투 애니메이션·스토리 없이도 152개 심볼과 227개 아이템의 상호작용을 통해 수백수천 개의 빌드를 만들고, rent라는 단 하나의 압박 곡선으로 매 선택에 의미를 부여한다. 현재 전체 콘텐츠를 그대로 따라가면 조합 QA가 커지지만, 핵심 재미는 프론트엔드 개발자가 14주 안에 충분히 검증 가능한 타입이다.

0. 왜 이번 분석 대상으로 골랐는가

[사실] TrampolineTales 공식 Press Kit은 회사를 solo game developer Dan DiIorio의 회사이자 alias라고 설명한다. 크레딧상 Dan DiIorio가 Designer, Programmer, Pixel Artist를 맡고 음악은 Vincent Colavita가 담당했다.

[사실] 현재 모바일 버전은 iOS와 Android에서 판매 중이고, 공식 Press Kit은 모바일 정가를 $4.99로 안내한다. Google Play는 현재 100K+ 다운로드와 유료 앱임을 표시하며, App Store/Google Play 설명은 실제 돈을 쓰는 도박이나 microtransaction이 없다고 명시한다.

[사실] 현재 제품은 공식 스토어 기준 152 Symbols / 227 Items / 186 Achievements / 20 Apartment Floors를 제공한다.

[의견] 이 게임이 특히 좋은 이유는 “작은 게임”의 정의를 잘 보여주기 때문이다. 규칙이 하나뿐인 게임은 아니다. 오히려 시스템은 꽤 많다.

  • 턴 단위 자동 시뮬레이션
  • 심볼 드래프트
  • 희귀도
  • 인접/파괴/생성/증폭 상호작용
  • 아이템 패시브
  • reroll/remove 자원
  • 임대료 난이도 곡선
  • 런별 빌드
  • 고난도 Apartment Floor
  • Endless/achievement/모딩

그런데 이 대부분이 데이터 테이블 + 규칙 엔진 + UI로 표현된다. 수작업 레벨이나 대규모 캐릭터 애니메이션이 거의 필요하지 않다. 사용자의 프론트엔드 경험이 가장 직접적으로 전이되는 유형 중 하나다.

1. 기본 정보

제품 정보

  • [사실] 장르: Roguelike Deckbuilder / Strategy / Resource Management
  • [의견] 더 정확한 세부 장르: Slot-builder / synergy drafting / short-run economy roguelite
  • [사실] 개발: TrampolineTales / Dan DiIorio
  • [사실] 퍼블리싱: TrampolineTales
  • [사실] 핵심 팀: 게임 디자인·프로그래밍·픽셀아트는 Dan DiIorio 1인, 음악은 외부 작곡가. 여러 언어는 번역가들이 참여했다.
  • [사실] Steam Early Access: 2021-01-08
  • [사실] Steam v1.0: 2023-01-06
  • [사실] 모바일 출시: 2023-07-21
  • [사실] 모바일 가격: $4.99 기준, 지역별 가격 차이 있음
  • [사실] PC 가격: Steam 정가 $9.99
  • [사실] 광고/IAP: 없음. 공식 개발자는 모바일을 무료+광고/IAP로 만들지 않기로 했다고 직접 설명했다.
  • [사실] Android package: com.trampolinetales.lbal
  • [사실] App Store ID: 6450724928
  • [사실] Steam App ID: 1404850
  • [사실] 엔진: 개발자 블로그에서 Godot 3.x로 제작했음을 명시한다.
  • [사실] 현재 모바일 지원: 2026-07-09부터 iCloud/Google Play 기반 cloud save 지원.

현재 공개 규모

  • [사실] Symbols: 152
  • [사실] Items: 227
  • [사실] Achievements: 186
  • [사실] Apartment Floors: 20
  • [사실] Google Play: 100K+ 다운로드, 약 1.8K+ 리뷰 수준
  • [사실] Steam: 2026-09-08 기준 공개 추적 서비스들은 약 1.1만 개의 전체 언어 리뷰를 관측한다. 공식 Steam 페이지의 영어 리뷰는 약 5.3K이며 94%가 긍정적이다.

2. 핵심 판타지와 플레이어에게 주는 약속

이 게임의 표면 판타지는 간단하다.

“돈이 없는데 집주인이 임대료를 요구한다. 슬롯머신 한 대를 내 마음대로 개조해서 임대료를 만들어낸다.”

하지만 제작자 관점의 진짜 약속은 다음이다.

“이번 런에서 나온 랜덤 재료를 잘 엮으면, 평범한 1코인 심볼들이 서로 먹고·증폭하고·복제되며 몇십~몇백 코인을 뽑는 엔진으로 변한다.”

[의견] 플레이어가 원하는 것은 잭팟 그 자체가 아니다. 중요한 감정은 **“내가 만든 엔진이 작동했다”**다.

이것이 일반 슬롯게임과 완전히 다른 지점이다.

  • 결과가 랜덤이지만
  • 플레이어가 심볼 풀을 직접 구성하고
  • 덱을 얇게 만들고
  • 시너지를 고르고
  • 특정 심볼이 다른 심볼의 가치를 바꾸고
  • 다음 rent까지 필요한 평균 수익을 계산한다.

즉, 운은 입력이고 빌드 설계가 출력 분포를 바꾼다.

3. 코어 루프

첫 10초

Spin → 코인 획득 → 3개 심볼 중 하나 선택

[사실] 각 스핀 뒤 플레이어는 랜덤 심볼 3개 중 하나를 추가할 수 있다. 각 심볼은 기본 코인 수익뿐 아니라 인접, 파괴, 생성, 성장, 배수 효과 등을 가질 수 있다.

[의견] 첫 10초의 장점은 결과를 보기 전 설명이 거의 필요 없다는 것이다.

  • 큰 Spin 버튼
  • 슬롯이 돌아감
  • 코인 숫자가 올라감
  • 선택지 3개가 나옴

프론트엔드 개발자가 구현하기 좋은 명확한 상태 전이다.

READY → SPINNING → RESOLVING → PAYOUT → DRAFT → READY

첫 30초

2~4번 스핀하면 이미 첫 선택의 결과가 보인다.

예:

  • Cat을 늘렸더니 특정 아이템과 시너지가 난다.
  • Ore 계열을 뽑았더니 Miner가 가치를 가진다.
  • Banana Peel이 Thief를 제거하며 보상을 만든다.
  • Flower 계열을 모으면 Rain/Bees 같은 증폭 루트가 열릴 수 있다.

[의견] 중요한 점은 선택 → 결과 확인 간격이 10~20초로 매우 짧다는 것이다. 전략게임인데 피드백 속도가 액션게임 수준이다.

첫 5분

플레이어는 다음 패턴을 이해한다.

  1. 아무 심볼이나 추가하면 안 된다.
  2. 희귀도가 높다고 항상 좋은 것이 아니다.
  3. 현재 덱과 상호작용하는 심볼이 더 중요하다.
  4. 다음 rent까지 필요한 코인/스핀을 계산해야 한다.
  5. 필요하면 심볼을 제거하거나 선택을 skip해야 한다.

여기서 게임은 단순 랜덤 장난감에서 경제 최적화 게임으로 변한다.

한 세션

Spin → 자동 상호작용 해결 → 수익 → 새 심볼 선택/skip → 필요 시 reroll/remove → rent 임박 → 평균 수익 점검 → rent 지불 → item 선택 → 다음 rent 구간

보통 한 런은 짧은 턴 묶음의 연속이며, 실패하면 즉시 새 런을 시작한다.

장기 루프

런 반복 → 새로운 심볼/아이템 관계 학습 → 특정 Apartment Floor 클리어 → 더 까다로운 제약에서 재도전 → achievement/빌드 실험 → endless/모딩

[의견] Idle Slayer와 달리 계정 전체 숫자를 영구히 키우는 prestige가 핵심이 아니다. 장기 리텐션은 지식 성장과 빌드 숙련이 담당한다.

이 차이는 매우 중요하다.

  • Idle/Incremental: 계정 숫자가 성장한다.
  • Luck be a Landlord: 플레이어의 시너지 이해도가 성장한다.

4. 성장 루프 — 무엇을 모으고 무엇이 강해지는가

이 게임의 성장은 한 런 안에서 압축되어 있다.

4.1 코인: 생존 자원

코인은 점수가 아니라 시간을 사는 자원이다.

Rent를 못 내면 런이 즉시 종료된다.

따라서 코인의 의미는:

  • 현재 런의 생존 여부
  • 다음 빌드 단계까지 갈 수 있는지
  • 약한 심볼을 잠시 유지할 여유가 있는지
  • 장기 성장 심볼을 채택할 수 있는지

를 동시에 결정한다.

4.2 Symbol pool: 사실상의 덱

[사실] 시작 덱은 매우 작고, 각 스핀 뒤 3개 중 하나를 선택해 심볼 풀을 확장한다. 슬롯에는 최대 20개 심볼이 동시에 표시된다.

[의견] 여기서 좋은 설계는 추가만큼 추가하지 않음이 중요하다는 점이다.

보통 초보자는 “새 카드가 나오면 넣는다.” 숙련자는 “덱 평균 수익과 시너지 밀도를 떨어뜨리는가?”를 본다.

그래서 심볼 제거와 skip은 단순 편의 기능이 아니라 빌드 압축 도구다.

4.3 Items: 룰을 바꾸는 전역 modifier

[사실] 현재 227개의 item이 있고, rent 지불 뒤 item 선택 기회가 제공된다.

좋은 item은 단순 +5%가 아니라 규칙을 바꾼다.

예:

  • 특정 심볼 타입의 생산량 증가
  • 생성 확률 증가
  • 인접 판정 변경
  • 특정 행동의 가치 증가
  • 희귀도 확률 변경
  • 특정 심볼의 소비/파괴 메커니즘 강화

[의견] 제작 관점에서 매우 싸다.

아이템 하나를 추가할 때 필요한 자산은 대개:

  • 작은 아이콘 1개
  • 이름/설명
  • 조건식
  • 효과 함수
  • 태그/그룹 데이터

정도다.

하지만 기존 152개 심볼과 상호작용하므로 플레이 공간은 크게 증가한다.

4.4 Apartment Floors: 메타 성장 대신 난이도 변형

[사실] 현재 20개 Apartment Floor가 존재한다.

[의견] 여기서 중요한 설계 철학은 “플레이어에게 영구 공격력 +10%”를 주지 않고, 같은 시스템을 더 어려운 제약에서 다시 읽게 한다는 것이다.

이는 콘텐츠 생산이 싸다.

새 스테이지 20개를 만드는 대신:

  • 시작 방해 심볼 추가
  • 선택 수 감소
  • 희귀도 불리
  • rent 압박 증가
  • remove/reroll 비용 증가

같은 rule modifier만으로 난도를 만들 수 있다.

5. 경제 시스템 — rent가 모든 선택을 의미 있게 만드는 방식

5.1 Rent는 moving target이다

커뮤니티 위키가 정리한 최저 난도 기준으로 초기 rent는 25코인에서 시작하고, 이후 50 → 100 → 150 → 225… 식으로 증가해 12번째는 777코인까지 올라간다. 초기에는 rent 사이에 5번 정도의 스핀이 주어지고 이후 10번 수준까지 늘어난다.

[의견] 핵심은 절대 rent 숫자가 아니다.

게임이 플레이어에게 매 구간 이런 질문을 던진다는 점이다.

남은 스핀 수 × 현재 평균 스핀 수익 >= 다음 rent 인가?

이 하나의 부등식이:

  • 공격적 성장 심볼을 살지
  • 즉시 수익 심볼을 살지
  • 덱을 정리할지
  • 희귀한 고점 빌드를 노릴지

결정하게 한다.

5.2 Source와 Sink

Source

  • 심볼 기본 payout
  • 인접 보너스
  • 파괴 보상
  • 배수 효과
  • 생성된 보조 심볼
  • 장기 성장형 심볼

Sink / 압박

  • rent
  • spin 비용 1코인
  • 일부 심볼/효과의 비용
  • 고난도에서의 불리한 modifier

이 게임이 좋은 이유는 sink가 복잡하지 않다는 것이다.

모바일 F2P처럼 재화 8종을 만들지 않고도 단일 통화 + 상승하는 목표로 충분한 긴장을 만든다.

5.3 숫자가 커지는 재미와 실제 의사결정

숫자가 커지는 재미

초기에는 심볼 하나가 1~3코인을 준다. 중반 이후에는 상호작용 때문에 같은 1칸이 배수·파괴·인접 효과를 연쇄시키며 훨씬 큰 숫자를 만든다.

실제 의사결정

  • 현재 덱에서 이 심볼의 기대값은 얼마인가?
  • 현재 빌드에 필요한 연결 고리인가?
  • 나중에 강해지는 심볼을 지금 감당할 수 있는가?
  • 희귀 심볼을 뽑기 위해 당장 약한 선택을 거절해야 하는가?
  • 덱이 너무 커져 핵심 심볼이 등장할 확률이 낮아졌는가?
  • 특정 아이템 때문에 원래 약한 심볼이 갑자기 핵심이 되었는가?

즉, 단순 exponential number game이 아니라 구성 확률과 시너지 밀도를 최적화하는 경제 게임이다.

6. ‘퍼즐이 아닌 반복 동력’은 무엇인가?

[의견] 답: 엔진 구축 + 경제 압박 + 변동 보상이다.

이 게임을 퍼즐로 보면 안 되는 이유는 정답이 없기 때문이다.

  • 매 런 선택지가 다르고
  • 심볼 등장 순서가 다르고
  • item이 다르고
  • 같은 전략도 rent 타이밍에 따라 실패할 수 있다.

반복 동력은:

  1. 이번에는 어떤 build seed가 나올까?
  2. 방금 얻은 item을 활용할 수 있을까?
  3. 이전 런보다 더 깔끔한 엔진을 만들 수 있을까?
  4. 고점 시너지가 한 번 터지면 얼마까지 갈까?

다.

퍼즐처럼 “문제를 풀고 다음 문제로 이동”하는 콘텐츠 구조가 아니어서, 레벨 100개를 손으로 만들지 않아도 된다.

7. 숫자/장비/자동화/빌드/경제 중 무엇이 세션을 이어주는가?

이 게임에서는 우선순위가 명확하다.

  1. 빌드 — 가장 강함
  2. 경제 압박 — 런의 텐션을 만드는 축
  3. 숫자 성장 — 성공 피드백
  4. 장비 — item이라는 형태로 존재하지만 전통 RPG 장비와 다름
  5. 자동화 — 핵심 아님

[의견] 사용자가 비슷한 게임을 만든다면 이 구조를 기억할 가치가 있다.

성장 시스템이 반드시 permanent upgrade나 idle automation일 필요는 없다.

한 세션 안에서 플레이어가 자신만의 생산 엔진을 조립하게 만드는 것도 강한 성장이다.

8. 첫 플레이 후킹과 온보딩

첫 훅

[의견] 훅은 3초 안에 설명 가능하다.

슬롯을 돌림 → 고양이/벌/꽃/광부 같은 심볼이 서로 반응 → 숫자가 여러 단계로 튀어 오름

게임 광고에서 이 장면 하나면 된다.

온보딩 구조

이 게임은 복잡한 튜토리얼보다 초기 심볼의 단순함으로 학습시킨다.

초기 심볼:

  • 1코인 지급
  • 특정 이웃과 만나면 보너스
  • 특정 심볼을 먹음

식의 한 문장 룰이 많다.

이후 플레이어가 이미 adjacent / destroy / add / give x more라는 문법을 익힌 뒤 복잡한 심볼을 보여준다.

[의견] 이것은 데이터 게임에서 매우 좋은 온보딩 방법이다.

새로운 UI를 계속 추가하는 대신 같은 문법으로 더 복잡한 문장을 만든다.

9. 재미의 원천

9.1 조합 발견

가장 큰 재미다.

심볼 A와 B가 각각 평범하지만 item C 때문에 갑자기 핵심 엔진이 된다.

9.2 변동 보상

매 스핀 결과가 완전히 같지 않다. 그러나 플레이어가 덱을 구성했으므로 결과는 순수 랜덤이 아니다.

좋은 변동 보상은 “예측 불가능하지만 내가 통제에 기여했다”는 느낌을 준다.

9.3 확률을 바꾸는 재미

덱빌더의 핵심은 좋은 결과를 기다리는 것이 아니라 좋은 결과가 나올 확률을 높이는 것이다.

9.4 압박 아래 선택

다음 rent가 없었다면 대부분의 선택은 그냥 취향 문제였을 것이다.

Rent가 있기 때문에:

  • 장기 성장
  • 현재 안정성
  • 고점
  • 평균값

사이에 trade-off가 생긴다.

9.5 빌드 완성 순간

특정 시너지가 완성된 뒤 매 스핀 결과가 이전보다 확연히 커지는 순간이 “power fantasy”다.

액션게임의 궁극기와 비슷한 역할을 숫자와 규칙 엔진이 대신한다.

10. 게임 필 — 거의 정적인 화면인데 왜 손맛이 있는가

[의견] 이 게임의 juice는 캐릭터 애니메이션보다 정보의 순서에 있다.

좋은 처리 순서는 대략:

  1. 슬롯 결과 정지
  2. 상호작용 대상 강조
  3. 심볼 변화/파괴
  4. 코인 숫자 팝업
  5. 배수 반영
  6. 총합 카운트업
  7. 다음 draft 표시

만약 모든 계산 결과를 즉시 +134 한 줄로 보여주면 재미가 크게 줄어든다.

플레이어는 엔진이 작동한 과정을 보고 싶어 한다.

프론트엔드 개발 관점에서는 이것이 꽤 친숙하다.

  • 이벤트 큐
  • 애니메이션 sequence
  • optimistic하지 않은 상태 업데이트
  • 계산 결과 snapshot
  • 강조 상태
  • undo 불가능한 action resolution

을 잘 설계하면 된다.

사운드

[사실] 전문 작곡가 Vincent Colavita가 음악을 담당했다.

[의견] 중요한 효과음은:

  • spin 시작
  • reel stop
  • coin increment
  • rare symbol 선택
  • symbol destruction
  • 큰 payout
  • rent 성공

정도다.

아트가 단순할수록 사운드와 숫자 연출의 가치가 올라간다.

11. 리텐션 구조

세션 내 리텐션

다음 rent까지만

이 목표가 매우 강하다.

보통 5~10 spin 단위라 플레이어는 종료 시점을 계속 미룬다.

런 간 리텐션

  • 이번에 못 만든 build 다시 시도
  • 새로운 symbol/item interaction 발견
  • higher floor 도전
  • achievement
  • endless

장기 리텐션

[사실] 개발자는 Early Access 동안 큰 업데이트를 반복했고, 스트리머들이 업데이트 때마다 다시 돌아왔다는 점을 직접 언급했다.

[의견] 시스템형 roguelike는 update 효율이 좋다.

새 심볼 5개 + item 3개를 넣으면 8개 콘텐츠가 추가되는 것이 아니라, 기존 수백 개와 조합되는 새로운 관계가 추가된다.

다만 이 장점은 QA 비용과 정확히 반대 방향으로 움직인다.

12. 콘텐츠 레버리지 — 직접 많이 만들지 않고 10시간 이상 가능한가?

[의견] 답: 가능하다. 이 게임이 그 대표 사례다.

현재 데이터는 152 Symbols × 227 Items이다.

물론 모든 조합이 유효하지는 않지만, 단순 곱만 해도 34,504개의 symbol-item pair가 존재한다. 심볼끼리의 쌍/세 쌍 상호작용까지 고려하면 가능한 빌드 공간은 급격히 증가한다.

하지만 제작 자산 하나의 비용은 매우 낮다.

커뮤니티 위키 기준:

  • Symbol sprite: 12×12 px
  • Item sprite: 22×22 px

[의견] 이 게임의 진짜 콘텐츠는 이미지가 아니라 관계 그래프다.

symbol → tag → adjacency → consumer → generator → multiplier → item modifier

따라서 10시간을 만들기 위해 10시간짜리 맵을 만들 필요가 없다.

다만 현실적인 조건이 있다.

  • 최소 30~50개의 의미 있는 심볼
  • 최소 15~30개의 룰 변경 item
  • 충분한 rarity 구조
  • 덱 정리 도구
  • 난이도 곡선

정도는 필요하다.

MVP 20개 심볼만으로도 재미 검증은 가능하지만, 상용 장기 리텐션은 어렵다.

13. 모바일 적합성

한 손 조작

[사실] 개발자는 모바일 버전을 portrait로 만든 이유를 직접 설명했다. 뉴욕 지하철에서 한 손으로 휴대폰을 사용하는 사람들을 보고, 서서 한 손으로 잡고도 플레이하기 쉽게 만들고 싶었다고 밝혔다.

이것은 매우 좋은 모바일 설계 사례다.

  • 정밀 조작 없음
  • drag 거의 필요 없음
  • 반응속도 요구 없음
  • 큰 버튼
  • 짧은 선택

중단/재개

턴 기반이라 언제든 멈추기 쉽다.

[의견] 모바일의 대표적인 “전화가 와도 망하지 않는 게임”이다.

세션 길이

  • micro session: 1~3분, rent 한두 구간
  • standard session: 한 런 10~30분
  • 장기: build/achievement 반복

오프라인

[의견] 실시간 서버가 핵심이 아니므로 로컬 실행에 매우 적합하다. 2026년 추가된 cloud save는 보조 기능이지 gameplay server가 아니다.

배터리/성능

2D 픽셀 UI와 낮은 동시 객체 수이므로 구조적으로 가볍다. 다만 상호작용 chain이 길어질 때 계산량과 animation queue 최적화가 필요하다.

14. BM 해체

실제 BM

[사실] 모바일은 $4.99 premium, 광고 없음, microtransaction 없음.

개발자는 모바일 출시 전 블로그에서 무료+광고/IAP의 race to the bottom에 참여하고 싶지 않고, 공정한 가격에 완전한 제품을 제공하고 싶다고 직접 설명했다.

왜 이 게임에 premium이 잘 맞는가

슬롯머신 이미지가 이미 도박 연상을 만든다.

여기에:

  • paid reroll
  • coin pack
  • paid rare symbol
  • loot box

를 넣으면 게임의 전략성이 즉시 “돈으로 확률 구매”처럼 보인다.

실제 돈이 없는 현재 구조에서는 안전한 확률 실험이지만, IAP가 결합되면 윤리·규제·플랫폼 정책 리스크가 급증한다.

실제 규제/스토어 리스크

[사실] Google은 2023년 이 게임을 도박 정책 문제로 여러 국가에서 차단했고, 개발자는 solo developer로서 대응이 매우 어려웠다고 공개했다. 한국에서는 GRAC 등급을 별도로 받아 다시 판매할 수 있었으며, 개발자는 차단 전 Google Play 매출의 약 20%가 한국에서 나왔다고 밝혔다.

[의견] 제작자에게 매우 중요한 교훈이다.

실제 gambling이 없어도 시각적 메타포 자체가 스토어 규제 비용을 만들 수 있다.

광고를 넣는다면 어디가 덜 해로운가?

원작 철학을 존중하면 광고는 안 넣는 것이 가장 좋다.

그래도 F2P 변형을 만든다면 덜 해치는 위치는:

  • 런 종료 후 선택형 광고
  • daily challenge 추가 ticket
  • 결과에 영향 없는 cosmetic unlock

정도다.

피해야 할 위치:

  • spin 직전 확률 boost 광고
  • rare symbol reroll 광고
  • rent 실패 직전 pay-to-rescue 반복

이런 구조는 플레이어가 결과 조작을 실력/빌드가 아니라 광고 소비로 해석하게 만든다.

IAP를 넣는다면

가장 자연스러운 것은:

  • cosmetic theme pack
  • soundtrack
  • 큰 expansion pack
  • 신규 symbol set을 포함한 명확한 DLC

이다.

경제/확률을 직접 판매하면 안 된다.

15. 돈을 얼마나 벌었을까?

정확한 lifetime 매출은 개발자가 공개하지 않았다. 따라서 아래는 범위 추정이다.

확인 가능한 사실

  • Google Play: 100K+ paid downloads
  • 모바일 정가: $4.99
  • Steam 정가: $9.99
  • Steam 공개 리뷰: 2026년 기준 전체 언어 약 1만~1.15만 수준으로 추적됨
  • 개발자는 v1.0 직후 Steam 평균 동접이 약 1,000명이라고 공개했다.
  • v1.0 launch week Steam impressions의 75% 이상이 New & Trending에서 왔다고 개발자가 설명했다.
  • 개발자는 YouTube coverage가 없었다면 재정적 성공이 아니었을 것이라고 직접 말했다.

Steam 판매량 추정

[추정 / 신뢰도: 낮음~중간]

공개 Steam review-to-sales 방식은 사이트마다 결과가 크게 다르다.

  • Raijin: 약 273K units 추정 (2026-09-08)
  • Video Game Insights: 약 344K units, premium revenue 약 $2.3M 추정
  • indielist: 약 337K~786K units, 중앙 약 561K 추정

따라서 허위 정밀도를 피하고 Steam lifetime paid units 약 300K~700K 정도를 넓은 범위로 보는 것이 합리적이다.

정가 $9.99지만 Early Access, 할인, 번들, 지역 가격이 있으므로 실현 평균 가격을 $5~$7 수준으로 가정하면:

300K~700K × $5~$7 ≈ $1.5M~$4.9M

정도의 Steam 소비자 지출/플랫폼 gross 범위가 나온다.

모바일

[사실] Android만 최소 100K+ 다운로드가 표시된다.

단순 정가 계산으로 Android의 100K는 $499K list-price value지만:

  • 실제 설치 수는 100K~500K bucket 안 어딘가
  • 지역 가격
  • Play Pass
  • 프로모션
  • 환불
  • 플랫폼 수수료

때문에 매출로 그대로 보면 안 된다.

Apple 판매량은 공개되지 않아 안전한 정량 추정이 어렵다.

전체 제품

[추정 / 신뢰도: 낮음] Steam + iOS + Android + 이후 콘솔까지 포함한 lifetime gross consumer spend는 수백만 달러 규모일 가능성이 높다.

그러나 개발자 실수령은:

  • 스토어 수수료
  • 세금
  • 지역 가격
  • 할인/번들
  • 외주 음악/현지화
  • 사업 운영비

를 제외해야 하므로 gross와 동일하지 않다.

제작자 관점의 핵심은 숫자 자체보다, solo 핵심 개발 + $0 paid influencer coverage 전략으로 이 정도의 상업성을 만든 구조다.

16. 성공은 게임 자체인가, UA/브랜드/퍼블리셔 파워인가?

퍼블리셔 파워

거의 없다.

[사실] self-published다.

[사실] 개발자는 Luck be a Landlord 마케팅에서 influencer coverage에 돈을 지불한 적이 없으며, 시작 당시 그런 비용도 감당할 수 없었다고 밝혔다.

Organic creator marketing

매우 중요하다.

개발자는 YouTube 영상 수백 개가 판매에 크게 기여했고 그 coverage가 없었다면 재정적 성공이 아니었을 것이라고 명시한다.

게임 자체의 creator fit

이것이 진짜 강점이다.

Roguelike deckbuilder는 방송에서:

  • 매 런 결과가 다름
  • 빌드 설명을 말로 하기 쉬움
  • 시청자가 선택에 의견을 냄
  • 대박 chain reaction이 clip이 됨
  • 업데이트 때 다시 플레이 가능

하다.

[의견] 즉, 마케팅 성공을 이메일을 잘 보냈다로만 해석하면 안 된다.

게임 구조 자체가 콘텐츠 크리에이터가 반복해서 다룰 수 있게 설계되어 있었다.

17. UA / 발견성 / 3초 광고 훅

ASO

좋은 점:

  • 제목이 기억에 남음
  • slot machine 이미지가 즉시 이해됨
  • roguelike deckbuilder라는 장르 태그가 명확함

나쁜 점:

  • gambling game으로 오인될 위험
  • 플랫폼 정책/연령 등급 문제

썸네일

슬롯 + 집주인/임대료 테마가 설명력이 높다.

3초 광고 소재

가장 좋은 장면:

평범한 슬롯 → 심볼들이 연쇄 파괴/증폭 → 7 → 23 → 85 → 350 코인으로 폭증

이 구조는 “성장 전후”가 한 화면 안에 들어간다.

TikTok / Shorts / GIF

매우 좋음.

특히:

  • absurd synergy
  • 고점 payout
  • 특정 심볼 20개 build
  • 극단적인 rabbit/cat/miner build

처럼 설명 없이도 시각적 payoff를 만들 수 있다.

Streamer fit

최상급. 실제 성공 사례가 이를 증명한다.

18. 경쟁작과 포지셔닝

Balatro

[사실] Balatro 개발자 LocalThunk는 Luck be a Landlord가 Balatro의 가장 큰 단일 영향이었다고 공개적으로 말했다.

비교:

  • Balatro: poker hand + joker + scoring multiplier
  • Luck be a Landlord: symbol pool + item + adjacency/destruction economy

둘 다 공통적으로 기존 확률 놀이를 전략적 engine-builder로 변환한다.

Backpack Battles / Backpack Hero류

공간 배치가 더 중요하고 제작 자산이 더 크다.

Dicey Dungeons / Slay the Spire

전투·적·카드·연출 등 수작업 콘텐츠가 더 많이 필요하다.

일반 idle/clicker

영구 숫자 성장과 offline progress가 강하지만, 순간 의사결정 밀도는 낮다.

[의견] Luck be a Landlord의 포지션은:

“Idle처럼 숫자가 커지는 쾌감은 있는데, 매 10초마다 덱빌더 수준의 선택을 한다.”

이다.

19. 제작 난이도

코어 시스템 — 6/10

초기 prototype은 쉽다.

필요:

  • RNG
  • grid/reel 결과
  • symbol collection
  • payout 계산
  • draft
  • rent timer

그러나 제품화 단계에서는 상호작용 resolution이 어려워진다.

UI — 7/10

이 게임은 UI가 대부분이다.

  • 150+ symbol tooltip
  • 200+ item tooltip
  • mobile responsive layout
  • inventory
  • filter/scroll
  • localization
  • accessibility

개발자 블로그에도 다국어 문자열 길이 때문에 UI 줄바꿈 처리를 직접 구현한 사례가 나온다.

아트 — 2/10

12×12 / 22×22 수준 픽셀 아이콘 중심.

하지만 낮은 해상도에서도 식별 가능한 실루엣을 만드는 디자인 감각은 필요하다.

애니메이션 — 3/10

캐릭터 애니메이션은 거의 없지만, interaction readability를 위한 highlight/sequence가 중요하다.

사운드 — 4/10

곡 수는 많지 않아도 되지만 반복 spin game이라 효과음 피로도가 중요하다.

레벨 디자인 — 1/10

전통적 레벨 없음.

밸런싱 — 9/10

가장 어렵다.

152 symbols + 227 items의 조합을 모두 수작업으로 생각하기 어렵다.

QA — 9/10

진짜 제작 비용이다.

  • 무한 loop
  • effect order
  • destroy/add timing
  • multiplicative overflow
  • rounding
  • disabled item
  • interaction recursion
  • save migration

등을 테스트해야 한다.

Backend — 1/10

핵심 gameplay server 불필요.

Cloud save 정도면 충분하다.

결제/광고 SDK — 1/10

Premium이라 복잡도가 낮다.

20. 데이터 테이블 / 밸런싱 툴 / 에디터가 얼마나 필요한가?

매우 중요하다.

이 게임을 코드에 if symbol == CAT 식으로 100개 박으면 유지보수가 빠르게 망가진다.

추천 데이터 모델

SymbolDefinition
- id
- name
- rarity
- basePayout
- tags[]
- trigger
- condition
- targets
- effect
- destroyPolicy
- spawnPolicy
- descriptionKey

ItemDefinition
- id
- rarity
- tags[]
- condition
- modifier
- descriptionKey

필요한 내부 툴

  1. Symbol editor
  2. Item editor
  3. Rarity/drop simulator
  4. 100K-run Monte Carlo simulator
  5. rent curve dashboard
  6. interaction graph viewer
  7. save migration validator
  8. localization overflow screenshot test

프론트엔드 개발자에게 특히 유리한 부분

이런 게임은 사실상 게임 화면을 가진 데이터 애플리케이션에 가깝다.

사용자에게 익숙한 능력이 그대로 전이된다.

  • schema 설계
  • state normalization
  • derived state
  • selector
  • event reducer
  • immutable snapshot
  • debug panel
  • admin editor
  • responsive UI
  • localization
  • analytics

[의견] 화려한 물리나 3D보다 이런 프로젝트가 프론트엔드 출신 첫 게임으로 더 성공 확률이 높다.

21. 출시 전/후 콘텐츠 생산 부담

출시 전

중간.

자산 제작량은 적지만 상호작용 수와 밸런싱 때문에 시간이 든다.

출시 후

중간.

새 콘텐츠 제작 단가는 낮다.

  • 아이콘 1개
  • 룰 1개
  • 텍스트 1개

면 되지만, 기존 시스템과 충돌 테스트가 필요하다.

좋은 구조

20개 심볼 추가가 20개 레벨 추가보다 훨씬 높은 replay value를 만든다.

나쁜 구조

콘텐츠가 쌓일수록:

새 심볼 1개 × 기존 150개 × 기존 227 items

의 QA surface가 커진다.

그래서 자동화 테스트 없이는 장기 운영이 힘들다.

22. 예상 팀 규모 / 개발 기간

아래는 원작 실제 기간이 아니라 비슷한 핵심 구조를 새로 만드는 경우의 제작 추정이다.

1인

가능하다.

원작 자체가 핵심적으로 solo 개발 사례다.

Prototype

1~3일

  • 4×5 grid
  • spin
  • 10 symbols
  • payout
  • 3-choice draft
  • rent

여기서 재미가 없으면 바로 중단 가능하다.

Playable vertical slice

1~2주

  • 25~35 symbols
  • 8~12 items
  • reroll/remove
  • 5 rent tiers
  • basic juice
  • save

30일 MVP

4주

  • 40~60 symbols
  • 20~30 items
  • rarity
  • 8~10 rent tiers
  • 3 difficulty modifiers
  • analytics/debug tools
  • mobile responsive UI

판매 가능한 소형 제품

3~6개월 / 1인

  • 70~100 symbols
  • 40~60 items
  • full sound
  • localization 2~4 languages
  • accessibility basics
  • automated simulation
  • achievements
  • store polish

원작급 장기 콘텐츠

**9~18개월+**를 각오하는 편이 안전하다.

이유는 아트가 아니라 balance + QA + content interaction이다.

23. 엔진/기술 후보

Godot — 매우 적합

원작도 Godot 기반이다.

장점:

  • 2D/UI 강함
  • 작은 binary/프로젝트
  • 빠른 iteration
  • data resource 작성 쉬움
  • 모바일 export

Unity — 적합

장점:

  • 모바일 SDK ecosystem
  • analytics/결제 확장 쉬움
  • 에디터 툴 제작 강함

단, 이 게임 규모에서는 다소 무거울 수 있다.

Defold — 적합

가벼운 2D 모바일 게임에 좋다.

다만 복잡한 editor tooling은 직접 만들 부분이 늘 수 있다.

Phaser / Web

Prototype에는 매우 추천.

프론트엔드 개발자라면:

  • TypeScript
  • React 기반 debug/editor
  • Phaser Canvas
  • localStorage/IndexedDB

로 1일 prototype을 가장 빨리 만들 수 있다.

상용 모바일은 Capacitor/WebView 또는 네이티브 엔진 전환을 검토한다.

개인 추천

  • 1일 검증: TypeScript + Phaser
  • 30일 모바일 MVP: Godot
  • 광고/IAP 중심 F2P로 확장: Unity

24. 1일 / 7일 / 30일 MVP 분해

1일 Prototype

절대 넣지 말 것:

  • achievement
  • animation polish
  • shop
  • meta progression
  • localization
  • fancy art

구현:

  1. 5×4 board
  2. 시작 심볼 5개
  3. spin 시 덱에서 최대 20개 표시
  4. 각 심볼 payout
  5. spin 후 랜덤 3개 중 하나 추가
  6. 5 spin 뒤 rent 25
  7. 10 symbols
  8. 3개의 simple synergy

검증 질문:

“플레이어가 spin 자체보다 다음 심볼 선택을 고민하는가?”

그렇다면 성공이다.

7일 Prototype

  • 30 symbols
  • rarity 3단계
  • 10 items
  • adjacency
  • destruction
  • spawning
  • multiplier
  • reroll token
  • remove token
  • 6 rent payments
  • run summary

검증 지표:

  • 3회 이상 연속 런 시작 비율
  • 평균 런 길이
  • symbol 선택 시간
  • 특정 build 편중
  • rent 실패 구간

30일 MVP

  • 50~70 symbols
  • 25~40 items
  • 10~12 rent tier
  • 5 difficulty floor
  • endless optional
  • 20 achievements
  • save/load
  • sound
  • juice
  • portrait mobile UI
  • tutorial-lite
  • Monte Carlo balance simulator
  • event log/debug replay

이 정도면 실제 소프트런치/itch 테스트에 충분하다.

25. 스코프 폭발 위험

위험 1 — 콘텐츠 개수 경쟁

“원작 152 symbols니까 우리도 150개”라고 시작하면 실패 확률이 높다.

먼저 25개로 재미를 증명해야 한다.

위험 2 — 모든 심볼이 서로 특수 처리

태그 기반 규칙이 없으면 조건문 지옥이 된다.

위험 3 — animation resolution과 실제 계산이 결합됨

계산 engine과 presentation queue를 분리해야 한다.

먼저 deterministic 결과를 만든 뒤 화면이 그 결과를 재생해야 한다.

위험 4 — balance를 손으로만 함

런 100번 플레이해서는 rarity와 rent 곡선을 검증할 수 없다.

simulation tool이 필수다.

위험 5 — 도박 테마를 그대로 복제

스토어 심사/등급 문제가 실제로 발생했다.

시스템은 복제해도 슬롯 외형은 바꾸는 편이 더 안전하다.

26. 장기 운영 부담

서버

낮음.

콘텐츠

중간.

밸런스

높음.

커뮤니티

중간.

빌드 게임은 wiki, mod, strategy discussion이 활성화되기 쉽다.

플랫폼 유지보수

생각보다 존재한다.

2026년에도 개발자는 모바일 cloud save를 추가했고, 과거에는 Android 국가별 정책 차단을 직접 해결해야 했다.

[의견] backend 없음 = 운영 없음은 아니다.

  • OS update
  • store policy
  • rating
  • cloud save
  • localization
  • accessibility

비용은 계속 남는다.

27. 복제 가능한 원리 vs 원작 의존 요소

복제 가능한 원리

  1. 자동 실행 + 수동 선택 조합
  2. 3개 중 하나 드래프트
  3. 상승하는 경제 목표
  4. 작은 데이터 객체 간 시너지
  5. build engine 완성의 쾌감
  6. 낮은 자산 비용 + 높은 관계 복잡도
  7. 한 화면에서 성장 전후가 보이는 마케팅 훅
  8. 짧은 turn / 긴 build arc
  9. meta power 대신 player knowledge progression

원작에 의존하는 요소

  • 슬롯머신 테마
  • 집주인/반자본주의 농담
  • 특정 심볼 구성
  • 고양이/광부/맥주 등 개별 관계
  • 장기간 Early Access로 쌓인 방대한 interaction set

[의견] 복제할 것은 슬롯이 아니라 **“작은 생산 객체를 draft해 하나의 경제 엔진을 만드는 구조”**다.

28. 비슷한 게임을 만든다면

유지할 것

  • 한 턴 5~10초
  • 선택지 3개
  • 상승하는 목표 압박
  • interaction-driven build
  • short readable rule text
  • skip/remove의 중요성
  • premium 또는 매우 절제된 BM

줄일 것

  • 150+ symbol
  • 200+ item
  • achievement 수
  • floor 수
  • 초기 localization 범위
  • mod support

첫 게임이면 1/3 수준이면 충분하다.

바꿀 것

슬롯머신 테마를 다른 생산 시스템으로 바꾸는 것을 강하게 추천한다.

예:

  • 광산 컨베이어
  • 낚싯배 창고
  • 자동 요리 라인
  • 우주 채굴 드론
  • 몬스터 농장
  • 작은 상점 진열대

이렇게 하면 도박 정책 리스크를 줄이고, 사용자가 관심 있어 하는 mining/automation 방향과도 더 잘 맞는다.

29. 제작 효율 점수

항목점수이유
재미 잠재력9.0매 턴 선택 + build 고점 + 변동 보상
구현 난이도8.0prototype은 쉬움. 상용 interaction engine은 중간 난도
아트 부담9.5작은 아이콘 중심
콘텐츠 부담7.0레벨 제작은 거의 없지만 symbol/item 개수는 필요
운영 부담8.0서버는 낮지만 store/localization/QA는 존재
성장 시스템 레버리지9.5객체 하나가 기존 수백 관계와 결합
BM 적합성9.0premium에 매우 잘 맞음
마케팅 훅9.2chain reaction과 숫자 폭증이 영상에 강함

종합 제작 효율: 8.7 / 10

[의견] Keep on Mining! 같은 시스템형 소형 게임을 목표로 한다면, 퍼즐류보다 훨씬 참고 가치가 높다. 특히 경제·상태·데이터 모델을 잘하는 개발자가 아트 인력 없이도 깊이를 만들 수 있다는 점이 핵심이다.

30. 최종 판정

지금 프로토타입 추천

단, Luck be a Landlord clone을 만들라는 의미는 아니다.

추천하는 검증 문제는:

“플레이어가 작은 생산 객체를 하나씩 고르면서 스스로 돈 버는 엔진을 만들게 하면, 수작업 레벨 없이도 반복 플레이가 생기는가?”

이 질문은 하루면 검증할 수 있다.

사용자가 처음 게임을 만든다면:

  • 2D
  • portrait
  • singleplayer
  • offline
  • no backend
  • data driven
  • 30~50 objects

라는 스코프가 매우 현실적이다.

31. 실제로 실험할 작은 게임 아이디어 / 가설 3개

아이디어 A — Mine Conveyor

훅: 광산에서 나온 광물이 5×4 컨베이어를 지나가며 서로 반응한다.

  • Iron: 기본 가치
  • Coal: 인접 Iron 제련
  • Magnet: 같은 열의 ore 수익 ×2
  • Crusher: Rock 파괴 후 랜덤 mineral 생성
  • Miner Bot: 특정 ore를 소비해 영구 효율 증가

spin 대신 다음 광산 사이클.

Rent 대신 굴착기 유지비.

검증 가설: 슬롯 이미지를 버리고도 draft → engine → payout 재미가 유지되는가?

아이디어 B — Night Market

매 라운드 진열대 20칸에 상품/손님/직원이 랜덤 배치된다.

  • Coffee + Student
  • Fish + Cat
  • Flower + Couple
  • Coupon + Shopper
  • Security + Thief

목표는 매일 임대료와 재료비를 지불하는 것.

장점: 프론트엔드식 상태/경제 설계에 매우 적합하고 아트도 작은 아이콘으로 가능하다.

아이디어 C — Fishing Fleet Draft

한 턴마다 바다에서 20개 대상이 등장한다.

플레이어는:

  • 어종
  • 미끼
  • 선원
  • 장비

를 draft한다.

예:

  • Sardine 떼는 Schooling item으로 배수
  • Shark는 작은 물고기를 먹고 가치 상승
  • Ice Box는 잡은 생선의 부패 방지
  • Chef는 특정 어종을 소비해 가치 ×4

검증 가설: “생산 객체가 서로 먹고/증폭하는 관계”는 테마만 바꿔도 강한 build fantasy를 만든다.

32. 제작자가 가져갈 핵심 원칙

  1. 수작업 콘텐츠 대신 관계를 만든다.
  2. 객체 수보다 객체 간 상호작용 수를 늘린다.
  3. 매 선택에 의미를 주려면 상승하는 deadline/resource target이 필요하다.
  4. 플레이어가 결과를 기다리는 것이 아니라 결과 확률을 설계하게 한다.
  5. 자동 처리 과정은 빠르게 끝내지 말고 읽을 수 있게 연출한다.
  6. 규칙 엔진과 animation을 분리한다.
  7. 30개 객체 이후부터는 밸런스 simulator를 만든다.
  8. 마케팅 소재를 게임 안에서 자연스럽게 발생시키는 구조를 선택한다.
  9. “solo-friendly”는 시스템이 적다는 뜻이 아니라 자산 생산 파이프라인이 작다는 뜻이다.
  10. 도박을 연상시키는 테마는 실제 결제가 없어도 플랫폼 비용을 만들 수 있다.

참고 출처

공식 / 1차 자료

게임 규칙 보조 자료

판매량/매출 추정용 2차 자료

공식 판매량이 공개되지 않았으므로 아래는 방향성 확인용이며 실제 수치로 간주하지 않는다.

분석 신뢰도 메모

  • 출시일/가격/팀/콘텐츠 개수/BM/스토어 정책 사건: 높음 — 공식 자료 중심
  • 세부 런 규칙/스프라이트 크기: 중간~높음 — 커뮤니티 위키와 공식 게임 설명 교차 참고
  • 제작 기간 추정: 중간 이하 — 원작 실제 공수 공개가 아니라 축소 재현 기준 모델
  • 판매량/매출 범위: 낮음 — 공식 lifetime sales 미공개, review 기반 추정 오차가 큼
Last updated on
Kittens GameMagic Survival