1개에 5년, 다음은 10개월에 30개. 월매출 $22,000에 도달한 앱 양산으로의 방침 전환

※ 본문 중 달러 금액에는 1달러=150엔으로 계산한 대략적인 엔화 환산을 함께 표기한다.

‘1개에 5년’과 ‘10개월에 30개’. 같은 개발자가 같은 기술로 낸 두 가지 결과다. iOS 엔지니어로서 8년의 경력을 가진 Max Artemov는 첫 번째 앱인 칼로리 계산 앱을 5년 넘게 키우려 했지만 성과를 내지 못했다. 2025년 2월 방침을 바꿔 단일 프로젝트에서 포트폴리오형으로 전환한다. 2025년 12월 10일 공개된 Indie Hackers 인터뷰 시점에, 30개 이상의 앱 그룹이 합계 MRR $22,000(월매출 약 330만 엔)을 만들어내고 있다.

이 사례에서 검증하고 싶은 것은 “많이 만들면 맞는다”는 거친 교훈이 아니라, 만드는 순서 자체를 뒤집은 것이 왜 숫자를 움직였는가다.

공개된 숫자

참고로 “앱당 평균 $730”은 합계를 개수로 나눈 숫자일 뿐, 실제 분포는 언급되지 않았다. 본인이 “초기 반짝임 후 사라지는 앱이 대부분”이라고 말한 이상 수익은 상위 몇 개에 편중되어 있다고 보는 것이 자연스럽지만, 그 내역은 공개되지 않았다.

무엇을 만들고 있나

만들고 있는 것은 Flutter로 제작한 작은 앱 그룹이다. 앱 1개에 담는 기능은 특정 사용자 과제를 푸는 ‘핵심 기능 하나’. 백엔드는 Firebase로 해결하고 수익은 구독이 아닌 광고로 회수한다. 유료화 설계, 결제 도선 최적화, 가격 테스트 같은 무거운 작업을 애초에 배제한 구성이다.

지원 체제도 혼자 전부 떠안지 않는다. 사용자 피드백과 리뷰 대응은 퍼블리셔 측에 맡기고, 본인에게는 실제 결함만 올라오도록 하고 있다. 30개를 혼자 돌리려면 운영의 고정비를 낮추는 설계가 전제가 된다.

조류가 바뀐 순간

전환점은 명확하다. 2025년 2월, Adam Lyttle의 유튜브 동영상을 본 것이다. 단일 프로젝트에 집중하는 것이 아니라 여러 앱의 포트폴리오를 구성해야 한다는 주장으로, 본인은 “모바일 앱에 대한 나의 이해가 완전히 바뀌었다”고 표현한다.

전후의 낙차는 극단적이다. 전환 전에는 앱 1개에 5년 이상을 투자하고도 성과는 제로. 전환 후에는 10개월 만에 30개 이상을 내놓고 합계 MRR $22,000에 도달했다. 투입한 기술도 인원도 변하지 않았다. 변한 것은 무엇에 시간을 배분하는가 그 배분뿐이었다.

또 하나, 숫자가 움직인 지점으로 ASO 습득이 있다. 습득 후 “노출, 다운로드, 수익이 50% 늘었다”고 명언하며, 양산이라는 틀 안에서 개별 탄환의 명중률을 끌어올린 것이 이 부분이다. 전환점이 ‘양산으로의 전환’, 증폭 장치가 ‘ASO’라는 이중 구조다.

왜 효과가 있었나, 구조로 분해한다

표면적으로는 “많이 냈으니까 맞았다”로 보인다. 하지만 작동하고 있는 메커니즘은 조금 더 구체적이다.

첫째, 만드는 순서의 반전이다. 종래에는 “만들고 싶은 앱을 만든다→나중에 집객을 생각한다”였다. 전환 후에는 “App Store 내에서 인기도 20 초과·난이도 60 미만의 키워드를 찾는다→그 키워드를 중심으로 앱을 설계한다→제목·부제목·설명문에 사용한다”는 순서가 된다. 수요의 존재를 확인한 뒤 착수하므로 수요 제로 영역에 5년을 낭비하는 사고가 구조적으로 일어나기 어렵다. 검색 키워드는 이미 사람들이 찾으러 오는 장소의 지도이기 때문이다.

둘째, App Store의 초기 부스트를 무료 검증 장치로 사용하고 있는 점이다. 출시 직후 며칠간 App Store는 신작에 일정한 노출을 준다. 대부분의 앱은 그 후 주 10~50 다운로드까지 떨어져 사라진다. 본인은 여기를 합격선으로 삼는다. 피크를 유지하지 않아도 되고, 급락하지 않고 일정 수준에서 안정되면 가능성 있음이라는 판정이다. 특정 다운로드 수로 기계적으로 자르는 것이 아니라 부스트 후의 움직임을 하나씩 보고 판단한다고 말한다. 즉 광고비를 지불하기 전에 플랫폼이 배분해 주는 노출로 수요의 유무를 측정하고 있다.

셋째, 감정적인 집착을 설계로 배제한 점이다. “사용자가 그 앱을 어떻게 생각하는지는 자신이 다음 앱을 만드는 동안 말하게 하면 된다” “만들어 내놓고, 실제 사용자의 반응에 따라 가라앉든 뜨든 맡긴다”고 말한다. 1개만 가진 개발자는 그 앱을 포기하는 것이 사업의 종료를 의미하기 때문에 철수 판단이 왜곡된다. 30개가 있으면 1개의 실패는 통계상 1건에 불과하다. 5년의 집착을 낳은 것은 기술력 부족이 아니라 선택지가 하나뿐이었던 구조였다고 읽을 수 있다.

넷째, 과잉 설계를 그만둔 것이다. 예전에는 SOLID 원칙이나 이상적인 아키텍처에 시간을 썼지만, 지금은 “핵심 기능에 필요한 것만”으로 좁힌다. 본인의 조언도 명료하다. “내놓는 것을 두려워하지 마라. 다듬거나 하나 더 킬러 기능을 넣으려고 시간을 낭비하지 마라. 버그 없는 상태로 기능 하나 담아서 내놓아라.”

잘 풀리지 않은 부분과 안고 있는 리스크

우선 전제로, 이 사례는 실패 기간 쪽이 더 길다. 8년 경력 중 5년 이상이 결과가 나오지 않은 1개에 투입됐다. 칼로리 계산이라는 포화된 카테고리를 고르고, 기능을 부풀리고, 설계에 공을 들였다. 양산 전략은 그 반성의 이면이며, 처음부터 정답으로 선택된 것이 아니다.

현재의 모델에도 약점이 있다. 수익원이 광고에 집중되어 있고, 집객은 App Store 알고리즘에 거의 전면적으로 의존하고 있다. ASO가 작동하는 전제가 바뀌면 30개 전부가 동시에 영향을 받는 구조다. 본인도 이 리스크를 인식하고 있으며, 2026년은 수입을 분산하기 위해 SaaS를 몇 개 만들 계획이라고 말한다. 포트폴리오의 분산은 ‘앱의 개수’가 아니라 ‘의존처의 종류’로 측정해야 한다는 자기 평가로 읽을 수 있다.

또한 대부분의 앱은 초기 부스트를 넘지 못한다는 전제로 운영되고 있다. 30개라는 숫자는 성공의 증거라기보다 생존율이 낮음을 반영한 필요량에 가깝다.

어디까지 흉내 낼 수 있나

재현하기 쉬운 것은 판단 규칙 부분이다. 키워드의 인기도·난이도에 임계값을 두어 착수를 결정하는 것, 출시 후의 움직임으로 지속 여부를 결정하는 것, 기능을 하나로 좁혀서 내놓는 것. 이것들은 특별한 자산을 필요로 하지 않는다. ASO 도구도 일반적으로 입수할 수 있다.

한편 그대로 흉내 낼 수 없는 조건도 있다. 8년분의 iOS 개발 경험이 있기 때문에 앱 1개당 개발 비용이 다른 사람보다 압도적으로 낮다. Flutter를 통한 크로스플랫폼 개발과 Firebase의 조합에 숙달되어 있다는 점도 전제다. 지원과 리뷰 대응을 퍼블리셔에게 맡길 수 있는 체제도 누구나 바로 마련할 수 있는 것이 아니다. 개발 속도가 절반이라면 같은 10개월에 낼 수 있는 것은 15개가 되고, 상위 몇 개에 편중되는 수익 분포를 감안하면 결과는 비례하지 않을 가능성이 높다.

게다가 이 방법은 ‘깊이 파고드는 1개’를 만드는 전략과는 궁합이 좋지 않다. 개수를 내기 위해 기능을 깎고 광고로 회수하는 설계는 단가가 높은 제품이나 장기적인 고객 관계를 전제로 하는 사업에는 전용하기 어렵다. 양산은 목적이 아니라 수요의 소재를 저렴하게 찾기 위한 수단으로 기능하고 있다——그렇게 읽는 것이 이 사례의 타당한 해석일 것이다.

함께 읽으면 좋은 글

• 혼자서 월 $100K에 도달한 Photo AI, Pieter Levels의 만드는 법
• Kindle 책 24권을 쌓아 올린 개인 출판의 수익 구조