작은 팀 창업 얘기는 늘 두 종류로 나뉜다.
하나는 희망을 판다.
둘이면 된다, 3개월이면 된다, 요즘은 코딩도 AI가 해준다.
다른 하나는 현실을 말한다.
둘이면 되긴 하는데 둘이 아무 조합이어도 되는 건 아니고, 3개월이면 되긴 하는데 그 3개월 동안 뭘 버리고 뭘 미뤄야 하는지까지 같이 말한다.
2026년 3월 4일 공개된 Silicon Valley Girl 에피소드 설명에서 Higgsfield AI의 Alex Mashrabov는 이렇게 요약될 만한 주장을 했다.
day 30에 first dollar, day 90에 $1M ARR
그리고 이상적인 AI founding team은 2명
이 문장은 강하다.
강한 만큼 오해도 잘 부른다.
그래서 그냥 동기부여 글로 소비하면 남는 게 별로 없다.
이번엔 다르게 읽어봤다.
공식 에피소드 설명, Alex 본인 LinkedIn 글, 요약 포스트를 같이 보고 내 운영 루프에 대입해보니 이건 작은 팀 낭만론 보다는 작은 팀 운영 압축 규칙 에 더 가깝게 읽혔다.
특히 내가 요즘 돌리는 글감, 발행, 자동화 루프에 대입해보면 핵심은 사람 수가 아니라 역할 밀도, 출시 리듬, 검증 속도였다.
결론부터 적으면 이렇다.
2명으로 90일
이 문장은 인원수 자랑이 아니라
운영 압축 규칙으로 읽는 편이 맞다.
한 명은 만드는 속도를 책임지고,
다른 한 명은 시장과 배포,
피드백,
전환을 책임져야 한다.
둘 다 만들기만 하면 실패하고,
둘 다 마케팅만 해도 실패한다.
결국 승부는 기술력보다
짧은 출시 주기와 빠른 피드백 회수
에서 난다.
이런 팀이라면 특히 이 플레이북을 곱씹어볼 만하다
- AI SaaS를 만들고 싶은데 팀 규모가 작아서 겁나는 사람
- Claude Code나 비슷한 툴 덕분에 만드는 속도는 빨라졌는데 다음이 막힌 사람
기능은 금방 나오는데 첫 매출이 안 난다를 이미 겪은 사람- 배포와 리텐션이 개발보다 어렵다는 걸 몸으로 느끼는 사람
- 90일 안에 무엇을 버려야 하는지 기준이 필요한 사람
반대로 이 플레이북이 별로 도움이 안 되는 경우도 있다.
- 규제 산업처럼 검토와 인증이 긴 경우
- 엔터프라이즈 세일즈가 기본인 경우
- 멀티 제품을 동시에 욕심내는 경우
- 창업자 둘 다 고객 접점이 약한 경우
지금 결론
핵심만 먼저 적으면 이렇다.
2명은 적은 인원이 아니라 역할이 극단적으로 압축된 팀을 뜻한다.30일 첫 매출은 제품 완성보다 결제 가능성 검증을 먼저 보라는 신호다.90일 1M ARR은 그대로 따라 하라는 숫자라기보다 운영 속도 기준점에 가깝다.- 작은 팀은 기능 수가 아니라 출시 횟수와 피드백 회수 속도로 승부해야 한다.
- PMF 탐색 전에는 자동화보다 직접 대화가 더 중요하다.
- 둘이서 하려면 한 명은 builder,
한 명은 market-facing 역할에 가까워야 한다. - 배포 리듬이 느리면 AI 코딩 툴이 있어도 성과는 늦다.
공식 소스에서 고정되는 사실은 어디까지인가
먼저 추정과 사실을 분리하자.
2026년 3월 4일 공개된 Silicon Valley Girl 에피소드 설명은 이 정도를 꽤 분명하게 말한다.
- Alex Mashrabov가 Higgsfield AI를 9개월 만에 $200M ARR까지 키웠다고 소개한다
- day 30에 first dollar
- day 90에 $1M ARR
- 이상적인 AI founding team은 2명
- product-market fit을 어떻게 찾았는지
- 왜 product releases를 주 6일 내보내는지
- AI startup funding strategy
- 작은 팀이 큰 회사를 만드는 방식
그리고 Alex 본인의 LinkedIn 글도 비슷한 항목을 반복한다.
즉 적어도 메시지 축은 흔들리지 않는다.
이 글에서 내가 더하는 건 저 주장을 그대로 숭배하는 게 아니라 운영 체크리스트로 번역한 해석이다.
그래서 이 글은 인터뷰 요약 이라기보다 인터뷰를 실무 규칙으로 바꿔본 메모 에 더 가깝다.
내가 이 플레이북을 낭만보다 규칙으로 읽는 이유
2명이면 된다 는 문장은 언제나 위험하다.
사람을 흥분시키기 쉽기 때문이다.
근데 실제로는 인원보다 제약이 먼저 보인다.
두 명이면 회의가 적고, 의사결정이 빠르고, 맥락 공유가 쉽다.
대신 숨을 곳도 없다.
누가 무엇을 책임지는지 훨씬 선명해야 한다.
한 명이 만들기, 배포, 콘텐츠, 세일즈, CS, 운영까지 전부 조금씩만 하면 결국 아무것도 충분히 안 된다.
그래서 이 문장을 실무적으로 번역하면 이렇게 된다.
역할이 뭉개지지 않는 최소 팀을 만들라.
즉 두 명이어도 되지만 둘의 역할은 매우 다르게 서 있어야 한다.
builder 1명 + market-facing 1명 해석이 왜 설득력 있었나
공식 에피소드 설명은 ideal AI founding team 을 말하지만 구체적 직함까지 다 적진 않는다.
대신 내가 이걸 운영적으로 읽었을 때 가장 자연스러운 조합은 builder 1명 + market-facing 1명 이었다.
왜냐면 작은 팀이 망하는 가장 흔한 방식이 둘 다 만들기만 좋아하거나, 둘 다 홍보만 좋아하는 경우이기 때문이다.
AI 시대에는 만드는 속도가 빨라졌다.
그러면 상대적으로 더 귀해지는 건 배포, 세일즈, 문제 정의, 전환 설계, 리텐션 관찰이다.
이건 내가 이미 여러 번 본 패턴이기도 하다.
기능은 주말 안에 나오는데 누구에게 팔지, 왜 내일도 다시 써야 하는지, 어디서 이탈하는지를 보는 사람이 없어서 제품이 허공에 뜨는 경우.
그러니 two people 는 낭만적인 소형 팀이 아니라 개발 속도와 시장 피드백이 동시에 살아 있는 최소 단위 로 읽는 편이 맞다.
30일 first dollar는 왜 중요한가
이 숫자가 마음에 든 이유는 거창해서가 아니라 잔인하게 현실적이어서다.
30일 안에 첫 매출을 본다는 건 이런 뜻에 가깝다.
- 완벽한 제품을 만들지 말 것
- 결제 의사가 있는 문제부터 찾을 것
- 처음부터 누가 돈 낼지 생각할 것
- 제품보다 전환 경로를 먼저 실험할 것
이건 작은 팀에 정말 중요하다.
사람이 적을수록 가설 검증이 늦어지면 회복이 어렵다.
90일 동안 기능만 만들다가 고객이 안 산다는 걸 알게 되면 팀이 받는 데미지가 크다.
반대로 30일 안에 작은 금액이라도 첫 매출이 나오면 문제가 실제라는 신호를 받는다.
그다음부터는 제품 개선과 배포를 조금 더 자신 있게 설계할 수 있다.
즉 first dollar는 돈 자체보다 검증 신호의 역할이 더 크다.
90일 1M ARR는 그대로 외우지 말고 속도 기준으로 읽자
솔직히 말하면 이 숫자는 대부분 사람에게 너무 크다.
그래서 그대로 따라 하면 오히려 무력감만 남을 수 있다.
나는 이 숫자를 재무 목표보다 운영 속도 기준으로 읽는 편이 더 낫다고 본다.
무슨 뜻이냐면,
90일 안에 시장 반응이 있는 제품을 만들고, 배포 루프를 돌리고, 고객 대화를 반복하고, 출시 주기를 굴릴 정도의 속도감을 가져가라는 뜻이다.
작은 팀에 필요한 건 거대한 대시보드가 아니라 짧은 피드백 루프다.
그 루프가 살아 있으면 1M ARR가 아니더라도 그다음 단계로 넘어갈 힘이 생긴다.
반대로 루프가 죽어 있으면 숫자 목표는 그냥 벽지다.
왜 주 6일 릴리즈가 중요한가
공식 에피소드 설명에서 내가 제일 꽂힌 문장 중 하나가 why they ship product releases 6 days a week 였다.
이건 단순히 열심히 일한다는 자랑이 아니다.
작은 팀이 살아남으려면 릴리즈를 거대한 이벤트가 아니라 학습 장치로 써야 한다는 뜻에 가깝다.
릴리즈를 자주 하면 좋은 점이 있다.
- 가설이 빨리 깨진다
- 사용자가 어디서 반응하는지 빨리 보인다
- 팀 내부 합의 비용이 줄어든다
- 큰 실패를 작은 실패 여러 번으로 쪼갤 수 있다
물론 단점도 있다.
- 품질이 흔들릴 수 있다
- 검토 피로가 쌓인다
- 배포 체계가 없으면 혼란이 커진다
그래서 자주 배포한다고 다 좋은 건 아니다.
중요한 건 릴리즈 횟수보다 릴리즈 후 무엇을 보느냐 다.
만약 출시 후 가입률, 활성률, 결제 전환, 이탈 사유를 안 본다면 주 6일 배포는 그냥 분주함이 된다.
내가 이 플레이북을 지금 운영 루프에 대입해보니 남는 것
요즘 내가 돌리는 루프도 완전히 다른 얘기는 아니다.
글감 수집, 초안, QC, 발행, 내부링크, 허브 확장.
이 흐름을 보면 결국 중요한 건 많이 만드느냐 보다 짧게 만들고 빨리 검토하고 바로 배포하느냐 다.
AI 도구 덕분에 초안은 빨리 나온다.
근데 실제 성과는 리뷰, 링크, 채널 적합도, 후속 측정에서 갈린다.
이걸 제품에 대입하면 거의 똑같다.
AI가 만들어주는 건 출력 속도고, 성패를 가르는 건 배포와 반응 회수다.
그래서 이 인터뷰를 읽고 남는 진짜 메시지는 AI 덕분에 만들기 쉬워졌으니 더 많이 만들자 가 아니라, AI 덕분에 만들기 병목이 줄었으니 시장 확인 속도를 훨씬 더 올려라 에 가깝다.
이런 팀은 오히려 2명 전략이 위험하다
모든 팀이 작을수록 좋은 건 아니다.
오히려 이런 상황이면 2명 전략이 꽤 위험하다.
1. 창업자 둘 다 시장 접점이 약할 때
둘 다 만들기 좋아하면 제품은 계속 진화하는데 고객 대화는 부족해진다.
2. 엔터프라이즈 영업이 기본일 때
세일즈 사이클이 긴 시장은 90일 압축 플레이북이 바로 안 먹힌다.
3. 컴플라이언스가 무거운 시장일 때
출시를 자주 해도 검토가 느리면 배포 속도 우위가 줄어든다.
4. 문제 정의가 아직 흐릴 때
무엇을 고칠지 모르면 빠른 배포는 그냥 빠른 방황이 된다.
즉 작은 팀 전략은 시장과 제품의 제약이 맞을 때 강하다.
아무 데나 붙이면 만능 열쇠는 아니다.
작은 팀이 90일 동안 버려야 할 것
이 플레이북을 내 식으로 번역하면 초반 90일 동안은 아래를 과감히 버려야 한다.
- 넓은 기능 세트
- 모든 고객층을 만족시키겠다는 욕심
- 예쁜 브랜딩에 과도한 시간 쓰기
- 자동화부터 완벽히 만들겠다는 집착
- 나중에 쓰일지도 모를 추상화
작은 팀은 선택지가 많을수록 불리하다.
둘이서 굴리는 팀이라면 무엇을 더할지보다 무엇을 안 할지 먼저 정해야 한다.
실수 TOP 5
1. 2명이면 아무 조합이나 된다고 믿는 실수
역할이 겹치면 작은 팀의 장점이 바로 사라진다.
2. first dollar보다 기능 완성도를 먼저 보는 실수
완성도가 높은데 안 팔리는 제품은 작은 팀에 특히 치명적이다.
3. 배포 속도만 높이고 측정을 안 하는 실수
릴리즈가 많아도 학습이 없으면 그건 속도가 아니라 소음이다.
4. AI 덕분에 개발이 빨라졌으니 PMF도 빨라질 거라 착각하는 실수
개발 속도와 시장 적합성 속도는 같이 움직이지 않는다.
5. 작은 팀이면 자동으로 민첩하다고 생각하는 실수
역할이 흐리면 작은 팀도 충분히 느려질 수 있다.
언제는 이 플레이북을 그대로 따라 하지 말아야 하나
이런 상황이면 숫자를 그대로 흉내 내지 않는 편이 낫다.
- 계약 단가가 크고 세일즈 리드타임이 긴 경우
- 기술 검증보다 법무 검토가 오래 걸리는 경우
- 고객 피드백을 주 단위가 아니라 분기 단위로 받는 경우
- 제품보다는 신뢰와 도입 프로세스가 훨씬 중요한 경우
이럴 땐 30일, 90일 숫자보다 검증 단위 자체를 다시 정의해야 한다.
FAQ
Q1. 정말 2명만 있으면 AI SaaS를 만들 수 있나?
가능은 하다.
다만 사람 수보다 역할 분리가 더 중요하다.
한 명은 만들기, 한 명은 시장과 배포를 강하게 잡아야 한다.
Q2. 30일 first dollar는 왜 중요한가?
제품 완성보다 결제 의사 검증을 먼저 보라는 뜻이기 때문이다.
작은 팀일수록 이 신호가 빨리 필요하다.
Q3. 90일 1M ARR를 그대로 목표로 잡아야 하나?
그렇게 보기보다 운영 속도 기준점으로 읽는 편이 낫다.
숫자 자체보다 피드백 회수 속도가 중요하다.
Q4. 주 6일 릴리즈가 무조건 좋은가?
아니다.
릴리즈 후 측정과 검토가 없으면 그건 그냥 바쁜 팀이 된다.
Q5. AI 코딩 도구가 있으면 작은 팀이 무조건 유리한가?
아니다.
개발 속도는 빨라지지만 배포, 전환, 리텐션은 여전히 사람 손이 많이 간다.
관련 글
- 만들기는 쉬워졌는데 왜 안 쓰일까 2026 Claude Code 시대에 병목이 개발에서 배포·리텐션으로 옮겨간 이유
- 에이전트 실험 노트를 팀 플레이북으로 승격시키는 기준 2026 메모와 가이드북 사이 경계선
- 짧은 AI 뉴스 메모를 나중에 운영 허브로 키우는 가장 쉬운 방법 2026 메모와 가이드 분업 설계