왜 오픈소스로 만들었나 — 체크리스트를 닫으면 안 되는 이유

MMU를 유료 SaaS 대시보드가 아닌 MIT 오픈소스 CLI로 공개한 이유 분석. 1인 빌더의 워크플로우(터미널 중심)와 비용 구조(구독 피로도)를 고려한 결정 과정, 그리고 'What(무료)-How(유료)-Auto(SaaS)'로 이어지는 3단계 수익 모델 설계 및 검증 지표 정리.

처음 구상은 SaaS 웹 대시보드였습니다

534개 항목을 정리한 직후, 가장 먼저 떠오른 건 웹 대시보드였습니다. 자연스러운 판단이었습니다. 구조화된 콘텐츠가 있고, 사용자별 진행 상태를 추적해야 하고, 팀 협업이 가능하면 좋겠고, 구독료를 붙일 수 있습니다. B2B SaaS의 전형적인 시작점입니다.

초기 SaaS 구상

graph TB
    subgraph SaaS["웹 대시보드 SaaS (초기 구상)"]
        A["사용자 가입/로그인"] --> B["체크리스트 불러오기"]
        B --> C["항목 체크 + 진행률 시각화"]
        C --> D["팀 공유 + 협업"]
        D --> E["리포트 내보내기"]
    end

    subgraph PRICING["요금제 구상"]
        P1["Free: 3개 카테고리"]
        P2["Pro: 전체 카테고리, $9/mo"]
        P3["Team: 협업 + 리포트, $19/mo"]
    end

    SaaS --> PRICING

구체적으로 그려본 기능 목록은 이랬습니다.

기능	Free	Pro ($9/mo)	Team ($19/mo)
체크리스트 열람	3개 카테고리	전체 15개	전체 15개
진행률 대시보드	기본 바 차트	카테고리별 히트맵	카테고리별 히트맵
스택 기반 필터링	불가	가능	가능
팀 공유	불가	불가	최대 5명
리포트 내보내기	불가	PDF	PDF + CSV
우선순위 추천	불가	기본	AI 기반
커스텀 항목 추가	불가	10개	무제한

이 모델의 장점은 세 가지였습니다.

반복 매출 (MRR): 월 구독 기반이므로 예측 가능한 수익. Pro 100명이면 $900/mo, Team 20팀이면 $380/mo. 합산 $1,280/mo.
데이터 축적: 사용자들의 체크 패턴을 분석하면 “가장 많이 빠뜨리는 항목 Top 10”, “스택별 위험 패턴” 같은 인사이트를 생성할 수 있습니다. 이건 콘텐츠 마케팅 소재이자, 프리미엄 기능의 재료가 됩니다.
경쟁 해자: 체크리스트를 비공개로 유지하면 콘텐츠 자체가 경쟁 우위입니다. 534개 항목을 보려면 가입해야 하니까요.

사업 모델로는 깔끔했습니다. 스프레드시트에 MRR 시나리오까지 그렸습니다.

구현 비용 추정

SaaS를 만들려면 인프라가 필요합니다. 1인이 운영한다는 전제로 최소 스택을 잡아봤습니다.

구성요소	선택지	월 비용
프론트엔드	Next.js + Vercel	$0 (Hobby)–$20 (Pro)
백엔드 API	Railway / Fly.io	$5–15
DB	Supabase / PlanetScale	$0–25
인증	Clerk / NextAuth	$0–25
결제	Stripe	거래액의 2.9% + $0.30
이메일	Resend	$0–20
모니터링	Sentry	$0–29
합계 (운영비)		$5–134/mo

구독자가 0명이어도 서버 비용은 발생합니다. 구독자가 100명이 되어야 BEP(손익분기점)를 넘깁니다. 100명을 모으기 전까지는 순 적자입니다.

그리고 개발 시간. 인증, 결제, 대시보드 UI, 팀 협업, 리포트 내보내기를 1인이 만들면 최소 4–6주입니다. 이건 체크리스트 콘텐츠를 다듬는 데 쓸 수 있는 시간입니다.

문제는 사용자 관점이었습니다.

모순을 발견했습니다

타겟 사용자의 현실

이 체크리스트가 필요한 사람은 혼자서 SaaS를 만드는 사람입니다. indie hacker, solo founder, side-project builder. 이 사람의 현재 상황을 정리하면 이렇습니다.

항목	이미 내고 있는 비용 (월)
호스팅 (Vercel, Railway, Fly.io 등)	$0–25
DB (Supabase, PlanetScale, Neon 등)	$0–25
도메인	$1–2
결제 플랫폼 수수료	거래액의 2.9–5%
모니터링 (Sentry, Betterstack 등)	$0–29
이메일 (Resend, Postmark 등)	$0–20
분석 (PostHog, Mixpanel 등)	$0–free tier
AI API (OpenAI, Anthropic 등)	$10–50+
합계	$10–150+

이 사람에게 “론칭 전에 뭘 빠뜨렸는지 확인하려면 또 다른 SaaS에 $9/월 구독하세요”라고 말하는 건 모순이었습니다.

구체적으로 따져보겠습니다. 체크리스트의 존재 이유는 빌더의 불필요한 삽질을 줄이는 것입니다. 빠뜨린 항목을 미리 잡아서 론칭 후 뒤늦게 고치는 시간을 절약합니다. 그런데 이 절약을 위해 매달 $9를 내야 합니다.

체크할 항목 534개 중에는 이런 것이 있습니다:

“불필요한 SaaS 구독을 정리하라” (카테고리: 운영)
“프리 티어만으로 운영 가능한 대체 도구를 확인하라” (카테고리: 비용)
“최소 도구로 론칭하라. 론칭 후 필요한 것만 추가하라” (카테고리: 프로세스)

체크리스트 도구 자체가 “불필요한 구독”에 해당할 가능성이 높습니다. 아직 수익이 없는 프로젝트에서, 론칭 전 확인용 도구에 월 $9를 쓰는 것이 합리적인가? 대부분의 solo builder는 아니라고 답할 것입니다.

사용자에게 “불필요한 구독을 줄이라”고 말하는 도구가, 스스로 불필요한 구독이 되는 것은 구조적 모순입니다.

사용 빈도 문제

SaaS 구독은 매일 또는 매주 사용하는 도구에서 정당화됩니다. Slack, Notion, Figma는 매일 씁니다. $10–20/mo를 내도 괜찮습니다.

론칭 체크리스트는 다릅니다. 사용 패턴이 이렇습니다:

시점	사용 빈도	사용 시간
론칭 2–4주 전	일 1–2회	10–30분
론칭 주간	일 3–5회	1–2시간
론칭 직후 1주	일 1회	10분
론칭 후 1개월–	거의 사용 안 함	0

집중 사용 기간은 최대 4–6주입니다. 그 이후에는 구독을 해지합니다. 월 구독 모델에서 churn rate가 극단적으로 높은 구조입니다. 사용자당 LTV(Life Time Value)가 $18–54 수준. CAC(Customer Acquisition Cost)을 감당하기 어렵습니다.

$49 연간 구독도 검토했지만, 1년에 한두 번 쓸 도구에 $49를 선불로 내는 사람은 더 적습니다.

경쟁 해자의 허약함

체크리스트를 비공개로 유지하면 콘텐츠 자체가 경쟁 우위라고 생각했지만, 냉정하게 분석하면 그렇지 않았습니다.

요인	현실
항목의 원출처	534개 중 70% 이상이 공개 자료(YC, Indie Hackers, OWASP, Web.dev 등)에서 수집
복제 난이도	경쟁자가 같은 자료를 모아서 비슷한 체크리스트를 만드는 건 2–3주면 가능
실제 경쟁 해자	콘텐츠 자체가 아니라 “체크리스트를 사용하는 경험의 품질”
오픈소스 위험	포크해서 유료 서비스로 만드는 경우가 있지만, 콘텐츠가 이미 공개 자료 기반이므로 추가 보호 효과 미미

결론은 명확했습니다. 콘텐츠를 닫아서 얻는 이점(구독 수익)보다, 열어서 얻는 이점(채택 속도, 커뮤니티 기여, 신뢰, 유기적 발견)이 더 컸습니다.

세 가지 대안 비교

SaaS 대시보드를 포기한 후, 세 가지 대안을 검토했습니다.

기준	웹 대시보드 (SaaS)	정적 사이트 (문서)	CLI (오픈소스)
진입 장벽	가입 + 결제 필요	없음	`pip install`
오프라인 사용	불가	가능 (다운로드)	가능
자동화 연동	API 필요 (추가 개발)	불가	CI/CD 네이티브
데이터 소유	서버 저장	사용자 로컬	`.mmu/` 로컬
맥락 전환	브라우저 탭 전환	브라우저 탭 전환	터미널 내 실행
커뮤니티 기여	어려움	PR 가능	PR 가능
수익화	직접 (구독)	어려움	간접 (유료 콘텐츠)
서버 유지	필요 (비용 발생)	불필요	불필요
제작 기간	4–6주	1–2주	2–3주
유지보수 부담	높음 (인프라+CS)	낮음	중간 (Issues)

의사결정 흐름

graph TB
    subgraph DECISION["의사결정 흐름"]
        Q1{"타겟 사용자의<br/>주 작업 환경은?"}
        Q1 -->|"터미널"| A1["CLI 방향"]
        Q1 -->|"브라우저"| A2["웹 기반 방향"]

        A2 --> Q2{"서버 유지 비용을<br/>감당할 수 있는가?"}
        Q2 -->|"Yes"| A3["웹 대시보드"]
        Q2 -->|"No"| A4["정적 사이트"]

        A1 --> Q3{"CI/CD 자동화가<br/>필요한가?"}
        Q3 -->|"Yes"| Q4{"오픈소스로<br/>공개하는가?"}
        Q3 -->|"No"| A4

        Q4 -->|"Yes"| FINAL["CLI + MIT 오픈소스"]
        Q4 -->|"No"| A5["CLI + Proprietary"]

        A3 -.->|"모순: 구독 강요"| X["기각"]
        A4 -.->|"한계: 자동화 불가"| X2["보조 채널로 유지"]
        A5 -.->|"한계: 채택 속도 느림"| X3["기각"]
    end

정적 사이트(문서)도 유력한 후보였습니다. 제작 기간이 가장 짧고, 유지보수 부담도 가장 낮습니다. 실제로 awesome-checklist 같은 GitHub 리포의 README.md 형태도 고려했습니다.

하지만 정적 문서는 두 가지 치명적 한계가 있었습니다.

자동화 불가: 문서는 읽는 것이지, 실행하는 것이 아닙니다. package.json을 보고 Node.js 프로젝트인지 판단해서 관련 항목만 필터링하는 것은 CLI만 가능합니다.
상태 추적 불가: “내가 534개 중 몇 개를 완료했는가”를 추적하려면 사용자가 별도 문서를 만들어야 합니다. CLI는 .mmu/ 디렉토리에 자동 저장합니다.

결론: CLI + 오픈소스가 타겟 사용자(터미널에서 코드 짜는 solo builder)의 워크플로우에 가장 자연스럽게 녹아들었습니다.

CLI를 택한 3가지 이유

1. 빌더의 작업 환경이 터미널입니다

코드를 짜는 사람이 브라우저 탭을 열어서 체크리스트를 확인하는 건 맥락 전환(context switch)입니다. 코드 -> 브라우저 -> 체크리스트 대시보드 -> 항목 확인 -> 다시 코드. 이 왕복이 하루에 10번 이상 발생하면 집중력이 깨집니다.

mmu status를 터미널에서 실행하면 맥락 전환이 0입니다.

# 터미널에서 바로 확인
$ mmu status

  MAKE ME UNICORN - STATUS DASHBOARD
  ──────────────────────────────────

  Evolution:  [████████░░] Hatchling → Pegasus

  Launch Gates
  ────────────
  M0 Skeleton     [██████████] 100%  PASS
  M1 Core         [████████░░]  83%
  M2 Hardening    [██████░░░░]  61%
  M3 Pre-launch   [████░░░░░░]  44%
  M4 Launch Day   [██░░░░░░░░]  22%
  M5 Post-launch  [░░░░░░░░░░]   0%

mmu next를 실행하면 현재 진행 상태에서 다음에 해야 할 가장 우선순위 높은 항목을 알려줍니다. 브라우저를 열 필요가 없습니다.

2. 의존성이 없어야 합니다

웹 서비스는 서버가 내려가면 끝입니다. SaaS 업체가 서비스를 종료하면 데이터와 함께 사라집니다. 2024–2025년에만 수십 개의 소규모 SaaS가 문을 닫았고, 사용자 데이터를 내보낼 시간도 주지 않은 경우가 적지 않았습니다.

CLI는 로컬에서 돌아갑니다. 체크리스트 데이터는 .mmu/ 디렉토리에 로컬 저장됩니다. PyPI에서 패키지를 설치한 순간, 인터넷 연결 없이도 작동합니다.

시나리오	웹 대시보드	CLI
인터넷 끊김	사용 불가	정상 작동
서비스 종료	데이터 유실 위험	로컬 데이터 영구 보존
서버 장애	사용 불가	정상 작동
프라이버시	서버에 데이터 전송	로컬 전용, 외부 전송 없음
비행기/지하철	사용 불가	정상 작동
보안 감사	외부 서비스 의존 보고 필요	해당 없음

이건 단순히 기술적 우위가 아니라 사용자의 데이터 주권 문제입니다. solo builder가 만드는 프로젝트의 체크리스트 진행 상태는, 아무리 사소해 보여도 해당 프로젝트의 성숙도와 약점을 그대로 보여줍니다. 이 데이터를 제3자 서버에 올릴 이유가 없습니다.

3. 자동화가 가능합니다

CLI의 진정한 가치는 CI/CD 통합입니다. 사람이 기억해서 체크리스트를 확인하는 것보다, 코드를 푸시할 때마다 자동으로 검증하는 것이 확실합니다.

# .github/workflows/mmu-guardrails.yml
name: MMU Launch Gate Check
on: [push]

jobs:
  mmu-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install make-me-unicorn
      - run: mmu scan             # 프로젝트 스택 자동 감지
      - run: mmu doctor           # 론칭 게이트 자동 검증
      - run: mmu gate --stage M2  # M2 통과 여부 확인

mmu scan은 프로젝트의 기술 스택을 자동 감지합니다. package.json이 있으면 Node.js 프로젝트로 판단하고, requirements.txt가 있으면 Python으로 판단합니다. robots.txt 파일 존재, LICENSE 파일 존재 같은 이미 충족된 항목을 자동으로 pre-check합니다.

mmu doctor는 현재 프로젝트 상태를 534개 항목 기준으로 진단하고, 빠진 항목을 경고로 출력합니다. mmu gate --stage M2는 특정 마일스톤의 통과 여부를 exit code로 반환합니다. CI/CD에서 이 exit code를 기반으로 배포를 차단하거나 경고를 발생시킬 수 있습니다.

웹 대시보드로 이런 자동화를 하려면 API를 별도로 만들어야 하고, 인증 토큰을 관리해야 하고, 네트워크 의존성이 생깁니다. 불필요한 복잡도입니다.

라이선스 결정: MIT를 택한 이유

CLI로 만들기로 한 후, 다음 결정은 라이선스였습니다. 오픈소스로 공개할 것인가, 공개한다면 어떤 라이선스를 쓸 것인가.

검토한 라이선스 옵션

graph LR
    subgraph OPEN["완전 개방"]
        MIT["MIT"]
        APACHE["Apache 2.0"]
    end

    subgraph RESTRICTED["조건부 개방"]
        FAIR["Fair-code<br/>(n8n 모델)"]
        BSL["BSL<br/>(HashiCorp 모델)"]
        CUSTOM["추가 조건<br/>(Dify, SSPL)"]
    end

    subgraph CLOSED["비공개"]
        PROP["Proprietary"]
    end

    MIT -->|"확산 최대"| ADOPTION["채택 속도"]
    FAIR -->|"재판매 방어"| PROTECTION["가치 보호"]
    PROP -->|"완전 통제"| CONTROL["통제"]

    ADOPTION -->|"현재 규모 < 100"| PRIORITY["현재 우선순위"]
    PROTECTION -->|"규모 > 10000"| FUTURE["미래 고려"]

각 라이선스를 7개 기준으로 비교했습니다.

기준	MIT	Apache 2.0	Fair-code (n8n)	BSL (HashiCorp)	SSPL (MongoDB)	Proprietary
확산 용이성	최고	높음	중간	낮음	낮음	최저
재판매 방어	없음	없음	있음 (상업적 재판매 제한)	강력 (경쟁 서비스 제한)	매우 강력	완전
기업 법무 통과	즉시	즉시	검토 필요	검토 필수	기피 대상	해당 없음
커뮤니티 기여 의지	높음	높음	중간	낮음	낮음	없음
포크 위험	있음	있음	낮음	매우 낮음	매우 낮음	없음
라이선스 변경 용이성	쉬움 (관대에서 제한적으로)	쉬움	어려움	어려움	어려움	해당 없음
대표 프로젝트	LangChain, CrewAI	HuggingFace, Qdrant	n8n	Terraform, Vault	MongoDB	-

라이선스 변경 사례 분석

최근 몇 년간 오픈소스 프로젝트의 라이선스 변경이 빈번했습니다. 이 패턴을 분석하면 결정에 참고할 수 있습니다.

프로젝트	변경 전	변경 후	변경 시점 규모	변경 사유
Elastic	Apache 2.0	SSPL	수만 명 사용자, AWS 갈등	AWS가 Elastic 대체 서비스(OpenSearch) 런칭
MongoDB	AGPL	SSPL	대규모 상용	클라우드 업체가 MongoDB를 서비스로 제공
HashiCorp	MPL 2.0	BSL 1.1	Terraform 수만 사용자	경쟁 서비스의 무임승차
Redis	BSD-3	SSPL	대규모 상용	클라우드 업체 갈등

공통점: 모두 대규모 채택 이후에 라이선스를 변경했습니다. 사용자가 100명도 안 되는 시점에서 방어적 라이선스를 고르는 것은 최적화의 순서가 틀린 것입니다.

판단 근거

고민은 있었습니다. 누군가 534개 체크리스트를 그대로 가져다가 웹 대시보드를 만들어 유료로 파는 시나리오입니다. MIT 라이선스로는 이를 막을 수 없습니다.

하지만 현 시점에서 방어보다 중요한 건 확산이었습니다.

534개 항목의 체크리스트를 아무도 모르면 아무 가치도 없습니다. MIT 라이선스는 확산에 대한 마찰을 최소화합니다. “이거 써도 되나?” 고민 없이 바로 pip install하게 만듭니다.
기업 법무 검토에 걸리지 않습니다. 스타트업이든 대기업이든 MIT는 즉시 통과입니다. Fair-code나 BSL은 법무팀이 “이 조건이 우리 사용 케이스에 해당하는가?”를 검토해야 합니다. 이 과정에서 채택이 지연되거나 포기됩니다.
커뮤니티 기여 동기가 높아집니다. “내가 기여한 코드가 나중에 라이선스 변경으로 닫힐 수 있다”는 우려가 없으므로 PR을 보내기 쉽습니다.
사용자가 100명도 안 되는 시점에서 라이선스 방어 전략을 고민하는 건 순서가 아닙니다. 위 표에서 본 것처럼, 라이선스 변경은 수만 명 규모에서 발생합니다.

규모가 커지면 라이선스를 바꿀 수도 있습니다. 하지만 사용자가 100명도 안 되는 시점에서 라이선스 방어 전략을 고민하는 건 우선순위가 틀린 것입니다. 채택이 먼저이고, 방어는 그 다음입니다.

Freemium SaaS를 다시 고려하지 않은 이유

CLI + 오픈소스를 결정한 후에도, “CLI는 무료로 두고, 프리미엄 기능이 있는 웹 대시보드를 별도로 만들면 어떨까?”라는 생각이 잠깐 들었습니다. GitLab이나 Sentry처럼 CLI/SDK는 오픈소스, 웹 대시보드는 Freemium SaaS로 가는 모델입니다.

검토 결과 현 시점에서는 적합하지 않았습니다.

요소	현실
시장 규모	”SaaS 론칭 체크리스트 대시보드”의 TAM은 좁습니다. 전 세계 indie hacker 중 체크리스트 도구에 돈을 낼 사람은 극소수
지불 의사	체크리스트는 “참고 자료”에 가깝습니다. 참고 자료에 월 구독을 거는 건 서적보다 비쌉니다
지원 부담	SaaS는 사용자가 늘면 지원 요청도 늘어납니다. 1인 운영에서 감당 가능한 CS 규모에 한계가 있습니다
개발 리소스	웹 대시보드 + CLI 두 개를 동시에 유지하면 한쪽이 방치됩니다. 1인이 양쪽을 동시에 관리하면 둘 다 품질이 낮아집니다
수익 시작까지 시간	대시보드 개발 4–6주 + 사용자 확보 3–6개월. 첫 수익까지 최소 4–8개월

이보다는 CLI를 잘 만들어서 채택을 먼저 확보하고, How 계층(Playbook)에서 수익을 만드는 것이 1인 빌더에게 현실적입니다.

그러면 돈은 어디서 버나 — What / How / Auto 모델

오픈소스로 공개한 것은 무엇을(What) 확인해야 하는가입니다. 수익은 어떻게(How) 실행하는가와 자동으로(Auto) 해결하는가에서 만들 계획입니다.

3계층 수익 모델

graph TB
    subgraph WHAT["What (오픈소스, 무료)"]
        W1["534개 체크리스트"]
        W2["CLI 도구 (mmu)"]
        W3["점수 계산 + 시각화"]
        W4["스택 자동 감지 (scan)"]
        W5["우선순위 추천 (next)"]
    end

    subgraph HOW["How (Playbook Pack, 유료)"]
        H1["provider별 스텝바이스텝 가이드"]
        H2["코드 스니펫 + 스크린샷"]
        H3["Stripe/LemonSqueezy 결제 설정"]
        H4["NextAuth/Clerk 인증 구현"]
        H5["SEO 완성 체크리스트"]
    end

    subgraph AUTO["Auto (AI Coach, 미래)"]
        A1["mmu doctor --deep"]
        A2["코드 자동 분석"]
        A3["수정 제안 생성"]
        A4["PR 자동 생성"]
    end

    WHAT -->|"확인은 했는데,<br/>어떻게 하지?"| HOW
    HOW -->|"매번 직접 하기<br/>귀찮은데?"| AUTO

    WHAT -.->|"무료"| USERS["사용자 확보"]
    HOW -.->|"$29~49 원샷"| REVENUE1["수익 1"]
    AUTO -.->|"$9~19/mo"| REVENUE2["수익 2"]

What 단계 — 오픈소스 (현재)

체크리스트 항목 자체, CLI 도구, 진행률 시각화, 점수 계산, 스택 자동 감지. 이것들은 무료입니다.

체크리스트에 “결제 webhook에 서명 검증을 추가하라”는 항목이 있습니다. 이 항목의 존재를 아는 것은 무료로 제공합니다.

이 단계의 역할은 수익 창출이 아니라 사용자 확보와 신뢰 축적입니다. 무료 체크리스트의 품질이 높아야, 유료 Playbook을 구매할 동기가 생깁니다.

How 단계 — Playbook Pack (계획)

“결제 webhook에 서명 검증을 추가하라”는 항목을 알았습니다. 그런데 Stripe에서 실제로 어떻게 구현하는지, Lemon Squeezy는 어떻게 다른지, 테스트는 어떻게 하는지 — 이건 별도의 가이드가 필요합니다.

이 가이드가 Playbook Pack입니다. provider별 스텝바이스텝 실행 가이드. $29–49 원샷 가격.

What과 How의 차이를 구체적으로 보면:

What (무료)	How (유료 Playbook)
“결제 webhook에 서명 검증을 추가하라”	Stripe webhook 서명 검증 코드(Node.js/Python), 테스트 방법, Stripe CLI 로컬 테스트 설정, 실패 시 재시도 설정, 모니터링 대시보드 설정까지
”인증에 RBAC을 적용하라”	NextAuth + Clerk 각각의 RBAC 구현, 미들웨어 설정, 역할별 접근 제어 테스트, 관리자 페이지 보호 패턴
”Core Web Vitals를 측정하라”	Lighthouse CI 설정, Next.js/Astro/Nuxt별 최적화 가이드, 이미지 최적화, 폰트 로딩, 번들 분석

우선 제작 예정 Playbook 3개:

Playbook	대상 체크리스트	예상 가격	예상 분량
Billing Setup (Stripe + LemonSqueezy)	04-billing 36개 항목	$29	80–100 페이지
Auth Complete (NextAuth + Clerk)	03-auth 42개 항목	$29	60–80 페이지
SEO Launch Kit	08-seo-marketing 58개 항목	$49	100–120 페이지

Auto 단계 — AI Coach (미래)

Playbook을 읽고 직접 구현하는 것도 시간이 듭니다. mmu doctor --deep이 코드를 분석하고, 빠진 항목을 감지하고, 수정 제안이나 PR을 자동 생성하는 단계입니다.

이건 현재 기술적으로는 가능합니다. LLM이 코드를 읽고 체크리스트 항목과 대조하는 것은 2026년 시점에서 충분히 구현 가능한 기술입니다.

하지만 수요가 확인되지 않았으므로 착수하지 않습니다. 투자 순서는 이렇습니다:

Issues/Discord에서 “how do I do this?” 류의 질문이 충분히 쌓인다
Playbook을 만들어서 판매한다
Playbook 구매자에게서 “자동으로 해줬으면” 피드백이 나온다
그때 Auto를 만든다

수요가 없으면 만들지 않습니다. “기술적으로 가능하다”와 “시장이 원한다”는 다른 질문입니다.

오픈소스를 배포 채널로 활용하는 전략

오픈소스는 라이선스가 아니라 배포 전략입니다. MIT로 공개하는 행위 자체가 마케팅입니다.

오픈소스 채택 퍼널

graph TB
    subgraph FUNNEL["오픈소스 채택 퍼널"]
        D1["발견<br/>(GitHub Trending, 블로그, HN)"]
        D1 --> D2["설치<br/>(pip install make-me-unicorn)"]
        D2 --> D3["사용<br/>(mmu scan, mmu status)"]
        D3 --> D4["공유<br/>(mmu share → 점수 공유)"]
        D4 --> D5["기여<br/>(Issues, PR, 항목 추가)"]
        D5 --> D6["전환<br/>(Playbook 구매)"]
    end

    D1 -.->|"SEO + 커뮤니티"| ORGANIC["유기적 유입"]
    D4 -.->|"바이럴"| D1
    D5 -.->|"품질 향상"| D3

각 단계에서 오픈소스가 주는 이점을 정리합니다.

단계	비공개 SaaS	오픈소스 CLI
발견	유료 광고, SEO 경쟁	GitHub Trending, 커뮤니티 공유, “Show HN”, 블로그 인용
설치	가입 -> 이메일 확인 -> 로그인	`pip install make-me-unicorn` (30초)
사용	온보딩 흐름 설계 필요	`mmu scan` 한 줄로 시작
공유	”이 SaaS 좋아요” (신뢰도 낮음)	“내 프로젝트 점수 78점” + 스크린샷 (구체적)
기여	피드백 폼	GitHub PR로 직접 항목 추가/수정
전환	Free->Paid 전환율 통상 2–5%	CLI 사용자->Playbook 구매 (전환율 미검증)

핵심은 발견 비용(CAC)이 극단적으로 낮다는 것입니다. SaaS는 Google Ads나 콘텐츠 마케팅에 투자해야 발견됩니다. 오픈소스는 GitHub 자체가 배포 플랫폼입니다. README가 랜딩 페이지이고, Stars가 사회적 증거이고, Issues가 사용자 피드백 채널입니다.

mmu share 명령어는 의도적으로 설계한 바이럴 요소입니다. 프로젝트 점수를 이미지로 생성해서 SNS에 공유할 수 있게 합니다. “내 프로젝트 론칭 준비도 점수”를 공유하고 싶은 욕구는 자연스럽습니다. 이 공유가 다시 발견으로 연결됩니다.

Open-Core 모델의 핵심 원칙

MMU의 open-core 구조를 한 문장으로 요약하면:

확인해야 할 목록(What)은 무료, 실행 방법(How)은 유료, 자동 실행(Auto)은 SaaS

이 구조가 작동하려면 세 가지 조건이 충족되어야 합니다.

조건	설명	현재 상태
What의 품질이 충분해야 함	무료 체크리스트만으로도 가치 있어야 채택됨	534개 항목, 15 카테고리
What->How의 전환 동기가 자연스러워야 함	”항목은 알겠는데 구현을 모르겠다”가 자연스럽게 발생해야 함	Issues 모니터링 중
How의 품질이 What보다 명확히 높아야 함	무료 콘텐츠와 차별화되지 않으면 구매 이유 없음	미검증

세 번째 조건이 가장 어렵습니다. What(체크리스트 항목)은 이미 인터넷에서 찾을 수 있는 정보를 정리한 것입니다. How(Playbook)도 인터넷에서 찾을 수 있는 튜토리얼과 뭐가 다른지 명확해야 합니다.

차별점은 **맥락(context)**입니다. 개별 튜토리얼은 하나의 주제를 다룹니다. Playbook은 체크리스트 항목과 1:1로 연결되어 있으므로, “이 항목을 왜 해야 하는지(체크리스트) -> 어떻게 하는지(Playbook) -> 했는지 자동 확인(CLI)“이 하나의 흐름으로 연결됩니다. 이 연결이 개별 튜토리얼 검색으로는 얻기 어려운 가치입니다.

리스크 분석

오픈소스 공개에 리스크가 없는 것은 아닙니다. 예상되는 리스크와 대응 방안을 정리했습니다.

리스크	확률	영향도	대응 방안
포크 후 유료 서비스화	중간	낮음	콘텐츠 70%가 공개 자료 기반이므로 방어 효과 미미. 오히려 원본 프로젝트의 인지도가 올라감
대기업이 비슷한 도구 출시	낮음	높음	시장 자체가 작아서 대기업이 진입할 유인 낮음. 진입하더라도 커뮤니티 기반 차별화
채택 부진 (Stars < 100)	중간	높음	3개월 시점에서 채택 지표 미달 시 배포 채널 재검토. 콘텐츠 자체는 유지
What->How 전환 미발생	중간	높음	Issues/Discord에서 “how-to” 수요가 없으면 Playbook 제작 보류. 컨설팅/워크숍으로 전환 검토
기여자 부재	높음	중간	1인 프로젝트로 지속 가능한 범위 유지. 커뮤니티 기여는 보너스, 필수가 아님
라이선스 변경 필요 시 반발	낮음	중간	현 규모에서는 해당 없음. 향후 변경 시에도 기존 버전의 MIT 라이선스는 유지

가장 경계하는 리스크는 채택 부진 + What->How 전환 미발생의 조합입니다. 이 경우 무료로 공개만 하고 수익은 0인 상태가 지속됩니다. 이에 대한 대응은 아래 검증 기준에서 다룹니다.

비슷한 패턴의 성공 사례

What을 무료로 풀어서 How/Auto에서 돈을 버는 구조가 실제로 작동한 사례를 분석했습니다.

프로젝트	What (무료)	How/Auto (유료)	규모	1인 운영 여부
LangChain	프레임워크 (MIT)	LangSmith (관측+디버깅 SaaS)	80K+ Stars	아니오 (VC 투자)
Hugging Face	Transformers (Apache-2.0)	Hub Pro, Inference Endpoints	130K+ Stars	아니오 (VC 투자)
n8n	워크플로우 코어 (Fair-code)	Cloud, Enterprise 라이선스	50K+ Stars	아니오 (VC 투자)
Excalidraw	화이트보드 (MIT)	Excalidraw+ (협업, 저장소)	80K+ Stars	소규모 팀
Cal.com	스케줄링 코어 (AGPL)	Enterprise, 관리형 서비스	30K+ Stars	아니오 (VC 투자)
Plausible	분석 코어 (AGPL)	관리형 클라우드	20K+ Stars	소규모 팀 (부트스트랩)

솔직하게 말하면, 이들 대부분에게는 VC 투자와 수십–수백 명의 팀이 있었습니다. 1인 빌더가 순수하게 OSS-first로 수익을 만든 사례는 드뭅니다.

그래도 참고할 패턴은 있습니다:

Plausible: VC 투자 없이 부트스트랩으로 성장. 무료 셀프 호스트 + 유료 클라우드의 이원 구조. “설치하기 귀찮으면 우리가 관리해줄게”라는 전환 동기.
Excalidraw: MIT 오픈소스로 사용자를 모은 후, 협업 기능과 저장소를 유료화. 핵심 기능은 무료, 편의 기능은 유료.

MMU에 적용하면: 체크리스트(핵심)는 무료, 실행 가이드(편의)는 유료. Plausible의 “셀프호스트 vs 관리형” 패턴과 유사하게, “스스로 찾아서 구현 vs Playbook 따라하기”의 편의 차이로 전환 동기를 만듭니다.

검증 기준과 피봇 조건

이 판단이 맞는지는 아직 모릅니다. 그래서 “되고 있다”를 판단할 기준을 미리 정해뒀습니다.

3개월 시점 체크포인트

지표	목표	미달 시 액션
GitHub Stars	200+	배포 채널 재검토. README/랜딩 개선, 커뮤니티 포스팅 강화
`mmu share` 주간 실행 수	50+	바이럴 기능 효과 미미. 공유 UX 개선 또는 대체 성장 채널 탐색
Issues/Discussions “how-to” 태그	5+/주	What->How 전환 수요 부족. Playbook 제작 보류
PyPI 주간 다운로드	100+	실제 사용자 부족. 발견 경로 분석 필요

6개월 시점 체크포인트

지표	목표	미달 시 액션
GitHub Stars	500+	성장률 분석. 정체 시 프로젝트 방향 재검토
Playbook 대기자	100+	100명 미만이면 Playbook 대신 컨설팅/워크숍 모델로 전환 검토
커뮤니티 기여 PR	10+ 누적	기여 부재 시 1인 유지보수 가능한 범위로 축소
`mmu doctor` 주간 실행 수	30+	CI/CD 통합 수요 미미. CLI의 핵심 가치 재검증

피봇 시나리오

위 기준에 도달하지 못하는 경우의 대안도 미리 정리했습니다.

상황	대안
채택은 되지만 전환이 없음	Playbook 대신 1:1 코칭/컨설팅으로 수익 모델 변경
채택 자체가 부진	CLI가 아닌 VS Code 확장, GitHub Action 등 다른 인터페이스로 재포장
경쟁자가 더 나은 도구 출시	차별화 불가 시 체크리스트 콘텐츠를 기여하고, 자체 도구는 종료

이 과정에서 배운 원칙

이 결정 과정을 돌아보면, 1인 빌더가 오픈소스 프로젝트의 비즈니스 모델을 설계할 때 참고할 원칙이 몇 가지 있습니다.

사용자가 100명 미만이면, 방어보다 확산이 우선입니다. 라이선스 방어, 경쟁 해자, 지적재산 보호는 사용자가 생긴 후에 고민해도 됩니다.
“기술적으로 가능한가”와 “시장이 원하는가”를 구분해야 합니다. AI Coach(Auto 단계)는 기술적으로 가능하지만, 수요가 확인되지 않았으므로 만들지 않습니다.
도구의 존재 이유와 사업 모델이 모순되면 안 됩니다. 비용을 줄이라고 말하는 도구가 비용을 추가하면 안 됩니다.
검증 기준을 먼저 정하고 실행해야 합니다. “잘 되면 좋겠다”가 아니라, “3개월에 Stars 200, 6개월에 대기자 100”처럼 숫자로 정해야 피봇 타이밍을 놓치지 않습니다.
피봇 시나리오를 미리 정해두면 집착을 줄일 수 있습니다. “이 모델이 안 되면 이걸 한다”가 미리 있으면, 안 될 때 감정적으로 끌려가지 않습니다.

이 과정도 계속 기록할 예정입니다. 다음 글에서는 같은 open-core 구조를 사용하는 AI/LLM 오픈소스 프로젝트들의 실제 사업화 사례를 더 깊이 분석합니다.