01
제약이 실력이다
Constraints Reveal Skill
시간이 부족한 게 아니다. 범위가 넓은 것이다. 6개월 계획을 세우면 처음 3개월은 "준비"에 쓰고, 나머지 3개월은 "급하게 만들기"에 쓴다. 그리고 유저는 0명이다. 30일이라는 제약은 "진짜 중요한 것만 하게 만드는" 장치다.
구체적으로
- →Foundation (Day 0-7): 뭘 만들지 정한다. 코딩 0%.
- →Build (Day 8-17): MVP 핵심 기능 3개만 만든다.
- →Launch (Day 18-24): 사람을 데려온다. 마케팅 50%.
- →30일 후 Go면 가속, No-Go면 피벗. 둘 다 성공이다. 6개월 표류가 실패다.
이런 건 하지 않는다: "시간이 더 있었으면..." — 시간이 아니라 우선순위가 문제다. 무엇을 하지 않을지 결정하는 것이 30일의 핵심이다.
02
고객이 먼저다
Customers First
에이전트 코딩 도구가 있으면 뭐든 하루 만에 만들 수 있다. 문제는 "뭘 만들지"다. 대부분의 개발자는 아이디어가 떠오르면 바로 코딩을 시작한다. 재밌으니까. 편하니까. 그리고 2주 뒤에 아무도 안 쓰는 프로덕트가 완성된다.
구체적으로
- →Day 1에 AI 코파운더 인터뷰로 문제를 정의한다. git init은 아직이다.
- →Day 2에 The Mom Test로 잠재 고객과 대화한다. 아이디어가 아닌 과거 행동을 묻는다.
- →Day 7에 7일간의 데이터로 Go/No-Go를 결정한다. 감이 아닌 숫자로.
이런 건 하지 않는다: "일단 만들어보고 반응 보자" — 이건 도박이다. 빠르게 만들 수 있다는 게 아무거나 만들어도 된다는 뜻은 아니다.
03
불완전해도 공개하라
Ship Imperfect
Day 1에 랜딩페이지를 공개한다. 예쁘지 않다. 괜찮다. 100% 완성을 기다리면 0%가 전달된다. 에이전트 코딩 도구 덕분에 하루 만에 만들 수 있지만, 그래서 오히려 "좀 더 다듬고 나서" 함정에 빠지기 쉽다.
구체적으로
- →랜딩페이지는 디자인이 아니라 메시지가 핵심이다. Tailwind 기본 스타일로 충분하다.
- →MVP는 기능 3개면 된다. 10개를 넣으려고 Day 20까지 미루지 않는다.
- →첫 버전은 부끄러워야 정상이다. 부끄럽지 않다면 너무 늦게 출시한 것이다.
이런 건 하지 않는다: "아직 준비가 안 됐어요" — 대부분 완벽주의의 다른 이름이다. 전업 1인 개발자에게 시간은 저축 잔고다.
04
숫자로 결정하라
Decide with Numbers
"좋은 아이디어 같아요"는 데이터가 아니다. 커뮤니티에 올리면 "대박이다", "꼭 써볼게"라는 반응이 온다. 기분은 좋다. 하지만 가입은 0명이고 매출은 0원이다. 진짜 데이터는 행동이다.
구체적으로
- →방문자 100명, 가입 0명이면 아이디어가 아니라 메시지가 문제다.
- →"이거 쓸래요?" 대신 "지난번에 이 문제를 어떻게 해결했나요?"를 묻는다.
- →유저 100명 + 첫 매출(금액 무관)이 PMF 신호다. "관심 있어요"는 아니다.
이런 건 하지 않는다: "감으로 이게 될 것 같아요" — 감이 데이터를 이긴 경우는 생존자 편향이다.
05
혼자지만 고립되지 마라
Solo, Not Isolated
1인 개발자는 혼자 만든다. 하지만 혼자 판단하면 편향된다. 내 아이디어가 최고인 줄 알고, 내 메시지가 명확한 줄 알고, 내 가격이 적정한 줄 안다. 아무도 반박하지 않으니까. 이게 1인 개발의 가장 큰 위험이다.
구체적으로
- →AI 코파운더: 매일 체크인. 데이터 기반으로 다음 액션 제안.
- →멘토: 주간 1:1. 방향이 맞는지 확인. 감정적 지지도 역할.
- →커뮤니티: 동료의 진행을 보면 "나도 해야지"가 된다. 혼자면 "내일 하지"가 된다.
이런 건 하지 않는다: "나 혼자 다 할 수 있어요" — 할 수 있다. 하지만 혼자 하면 3배 오래 걸리고, 틀린 방향으로 2배 더 멀리 간다.