Show HN 1면 간 인디 앱이 MRR $0인 이유 — 바이브코딩의 진짜 병목은 코드가 아니었다

핵심 요약 (TL;DR)

Ruby on Rails와 agentic AI + TDD로 만든 일일 퍼즐 허브 PuzzleLair가 Show HN 1면(243pts·151댓글)에 올랐지만, MRR은 $0이었습니다. 빌더 본인 자백에 따르면 "아무도 무료 25문제 한도에 아직 도달하지 못해서"입니다. 바이브코딩 시대, 진짜 병목은 코드가 아니라 freemium 분기점과 UX 설계입니다.

Show HN 1면 가면 매출이 따라올까

인디 해커 커뮤니티엔 오랜 신화가 있습니다. Hacker News 1면에 가면 비즈니스가 풀린다는 믿음이죠. 이번 주 그 신화의 가장 깨끗한 반례가 나왔습니다. HaxleRose라는 솔로 빌더가 만든 PuzzleLair는 Show HN 게시 60시간 만에 243포인트, 151개의 댓글을 받으며 1면에 직행했습니다. 그런데 같은 시점, 빌더 본인이 댓글에서 자백한 MRR은 정확히 0달러였습니다.

사연은 이렇습니다. 본업이 소프트웨어 엔지니어인 그는 "광고 없고 모바일 UI가 깔끔한 퍼즐 앱이 안 보여서 직접 만들었다, 몇 달러면 살 사람 많을 거라고 봤다"고 동기를 밝혔습니다. Sudoku, Killer Sudoku, Calcudoku, Kakuro, Nonogram 등 10여 종의 로직 퍼즐을 하나의 사이트에 모았고, 일일 퍼즐과 통계 추적, 리더보드까지 붙였습니다. 운영비는 다른 앱들과 공유하는 VPS에 도메인까지 합쳐 월 9달러 수준입니다.

빌딩이 아니라 분기점이 병목이었다

흥미로운 건 그가 쓴 도구입니다. "회사에서 쓰는 방식 그대로, agentic AI로 Rails 따라가며 TDD로 짰다"고 했습니다. Ruby on Rails 백엔드에 Tailwind CSS v4 프론트, 일부 퍼즐 생성에는 Claude와 Fable 5를 함께 썼습니다. 우리가 지난 1년간 "바이브코딩의 정석"이라고 부르던 워크플로 그대로입니다. 코드 품질도 멀쩡하고, UX도 호평이 많았습니다.

그런데 왜 0달러였을까요. 빌더가 직접 짚은 원인은 freemium 분기점이었습니다. "25문제 무료 → 그 이후엔 몇 달러 1회 결제"라는 구조를 설계했는데, 그 25문제 한도에 도달한 사용자가 단 한 명도 없었던 거죠. 1면에 올린 트래픽이 무료 구간만 야금야금 즐기고 빠져나간 셈입니다. 코드가 빈약해서가 아니라, 사용자가 결제 결심을 하기 직전 단계에 닿기도 전에 멈춰버린 게 진짜 문제였습니다.

바이브코딩 시대의 새 병목 — 가격 분기점

이 사례가 무서운 이유는 따로 있습니다. agentic AI와 TDD가 빌더의 손에 들어오면서, "제품을 만드는" 부분은 더 이상 솔로 빌더의 병목이 아니게 됐다는 점이죠. 며칠이면 Show HN에 올릴 만한 결과물이 나옵니다. 그 다음 병목은 어디로 이동했을까요. 가격 설정, freemium 분기점, 첫 결제까지 닿는 사용자 여정 — 즉 "비즈니스 디자인"입니다.

무료 한도를 25문제로 잡은 건 빌더의 직관이었습니다. 본인 입장에선 "하루 1문제씩 하면 한 달이면 결제 결심하겠지" 같은 가설이었겠죠. 그런데 일일 퍼즐 사이트는 보통 "매일 한 문제씩" 가볍게 들렀다 가는 곳입니다. 25문제면 사용자에겐 두 달 분량입니다. 그 안에 사용자가 사이트 자체를 잊거나, 더 가벼운 대체재로 옮겨갈 시간이 충분합니다. 즉 무료 한도가 너무 후했던 게 아니라, 결제 결심이 만들어지는 사용 빈도와 한도 설정이 어긋난 거죠.

코드보다 어려운 건 "분기점 설계"

PuzzleLair 사례는 1인 빌더 누구에게나 적용됩니다. 코드를 짤 수 있느냐가 아니라, 어디서 무료를 끊고 어디서 결제를 받느냐를 어떻게 설계할 것이냐. 그게 매출의 거의 전부를 좌우합니다. 비슷한 함정에 빠지지 않으려면 출시 전 세 가지를 점검해보세요.

첫째, 사용 빈도와 한도가 같은 시간대에서 만나는지 봅니다. 일일 퍼즐처럼 가볍게 쓰는 도구라면 무료 한도는 "하루 1~2회 사용 × 1~2주" 안에서 결제 결심이 만들어지는 지점에 둬야 합니다. 둘째, 결제 시점에 사용자가 무엇을 얻는지 한 줄로 적어보세요. "광고 제거"보다 "내일치 퍼즐 미리 풀기" 같은 구체적 보상이 강합니다. 셋째, freemium 구간에서 사용자가 만든 자산(점수, 통계, 친구 리더보드)을 잃을지를 명확히 보여주세요. 결제 결심은 욕망보다 손실 회피에서 더 자주 만들어집니다.

PuzzleLair는 빌더가 글을 더 다듬고, 무료 한도를 조정하고, 결제 트리거 메시지를 손볼 시간이 충분히 있습니다. 다만 우리가 이 사례에서 배워야 할 건, "바이브코딩으로 빠르게 만들었다"는 자랑이 매출로 자동 변환되지 않는다는 사실입니다. 코드가 빠른 시대일수록, 코드 바깥의 결정들이 매출을 가릅니다.

FAQ

Q. freemium 한도는 도대체 몇으로 잡아야 하나요

절대값이 아니라 "사용 빈도와의 함수"로 잡으세요. 일일 사용이 기대되는 제품이라면 "하루치 사용 × 결제 결심에 필요한 일수(보통 5~10일)"가 출발점입니다. 25문제처럼 큰 숫자는 일주일에 한 번 사용 가능한 도구에 어울립니다.

Q. 코드를 잘 짜는 것 말고 인디 빌더가 더 갖춰야 할 건 뭔가요

가격 가설을 글로 적어보고, 출시 첫 주에 결제 시점·이탈 시점을 분리해서 로그로 보는 습관입니다. 코드 작성보다 "무료 한도 다른 값으로 두 그룹 분리" 같은 작은 실험을 돌리는 근육이 매출을 가릅니다.

Q. Show HN 1면에 가는 게 의미가 없나요

트래픽과 피드백 측면에서 분명 가치 있습니다. 다만 "1면 트래픽 = paying customer"는 거의 항상 거짓이라는 걸 PuzzleLair가 보여줬습니다. 1면을 결제 가설을 검증하는 실험장으로 쓰는 게 훨씬 남는 장사입니다.

바이브코딩이 빌딩을 쉽게 만들수록, 빌더가 진짜로 신경 써야 할 자리는 코드 바깥으로 이동합니다. PuzzleLair가 그 자리가 어디인지 정확히 짚어줬습니다.