Cruise — 다음 제품을 골랐다, 1차의 실수를 교정하며 시작한 2차 킥오프
Sprint 1차를 끝내자마자 다음 베팅을 골랐다. 이름은 Cruise. 왜 다음 제품인가, Cruise가 뭘 푸는가, 킥오프 첫 주 체크리스트, 그리고 1차에서 한 실수를 의도적으로 교정한 5가지를 솔직하게 기록한 buildlog.
Sprint 1차를 끝내고 숨 고를 새도 없이, 나는 다음 베팅을 골랐다. 이름은 Cruise다.
원래는 한 주쯤 쉬려고 했다. 5주짜리 Sprint 결산을 쓰고 나니 양은 초과했는데 마음은 비어 있었다. 트래픽 312명, 수익 0원, 누적 비용 7만 원대. 그 숫자들을 정리하면서 깨달은 건 단순했다 — 나는 멈추면 더 불안한 사람이다. 그래서 쉬는 대신, 다음 제품의 이름을 먼저 정했다. 이름을 정하면 그건 시작된 것이다.
왜 곧바로 다음 제품인가
1차에서 가장 크게 배운 건 기능도 마케팅도 아니었다. 나라는 빌더가 어떤 속도로 무너지고, 어떤 구조에서 버티는가였다. 그 데이터가 손에 있을 때 다음 베팅을 거는 게 맞다고 판단했다. 한 달 쉬고 나면 그 감각은 흐려진다.
그리고 솔직히 — 1차 제품 하나로는 답이 안 났다. 검증은 절반만 됐고, 트래픽은 신규 도메인 한계 안쪽이었다. 한 제품에 더 오래 매달리는 것과 새 베팅을 추가로 거는 것 사이에서, 나는 후자를 골랐다. 이 선택 자체가 다음에 쓸 글의 주제이기도 하다. 한 제품에 집중할까, 여러 제품을 병렬로 굴릴까 — 그 고민은 따로 집중 vs 멀티 제품 글에서 정리하기로 했다.
Cruise가 뭘 푸는가 — 문제 정의
Cruise는 멈추지 않고 흘러가게 만드는 것에 관한 제품이다. 이름 그대로 항해(cruise)이자 순항 속도(cruise speed)다.
문제는 내 안에서 나왔다. 1인 빌더로 일하다 보면 시작은 폭발적인데 중반에 동력이 꺼지는 패턴이 반복된다. 의지력으로 켜는 게 아니라 구조로 흘러가게 만들어야 했다. Cruise는 그 "중반의 동력 상실"을 다루는 제품이다. 더 구체적인 스펙은 아직 비공개로 둔다 — 1차에서 완벽한 시스템을 미리 설계하다 검증을 놓친 실수를 또 하기 싫어서다.
대신 첫 주에 한 건 설계가 아니라 검증이었다.

킥오프 첫 주에 한 것
첫 주는 코드를 거의 안 짰다. 대신 틀린 데서 멈출 수 있게 만드는 데 썼다.
- 문제 검증 72시간 — 가설을 글이 아니라 실제 사람의 말로 확인했다. 72시간 아이디어 검증에서 만든 틀을 그대로 재사용했고, 이번엔 더 빨리 돌았다.
- 스택 동결 — 1차와 같은 Flutter + 로컬 우선 구조로 못 박았다. 새 기술 학습 비용 0을 의도했다.
- 저장소·CI 골격 — 빈 레포에 CLAUDE.md·컨벤션 문서·CI부터 넣었다. 글 쓰기 전에 인프라를 닫는 방식이다.
- 완료 정의 명문화 — "기능 동작"이 아니라 "검증 지표가 움직였는가"를 완료로 정의했다.
의도적으로 다르게 한 것 — 1차의 실수 교정
여기가 이 글의 핵심이다. 1차에서 아팠던 지점마다, 2차에서는 반대로 했다.
| 영역 | 1차에서 한 것 (실수) | 2차에서 다르게 한 것 |
|---|---|---|
| 완료 정의 | "발행/기능 동작"을 완료로 봄 | "검증 지표 이동"을 완료로 정의 |
| 인프라 | 검증 전에 시스템부터 설계 | 검증 통과 전엔 인프라 동결 |
| 속도 | 양 위주(280% 초과)로 질주 | 닫는 단위(색인·링크까지)로 측정 |
| 점검 | 후반에 부채 폭증 후 일괄 보강 | 매 단위마다 점검 내장 |
| 건강 | 임계점 직전까지 밀어붙임 | 회복일을 캘린더에 먼저 박음 |
1차의 가장 큰 실수는 완벽한 시스템을 먼저 짓고 검증을 나중으로 미룬 것이었다. 그래서 2차에서는 검증이 통과하기 전엔 어떤 인프라도 추가하지 않기로 했다. 제품 선택 기준 자체도 다시 점검했는데, 그 틀은 SaaS 아이디어 선정 프레임워크에 정리해 둔 그대로다 — 이번엔 그 체크리스트를 빠뜨리지 않고 처음부터 돌렸다.
건강 항목은 특히 신경 썼다. 1차 마지막 주에 본업 루틴을 두 번 깼고, 그게 곧 보강 1주를 통째로 잡아먹었다. 그래서 2차는 회복일을 먼저 캘린더에 박고 그 사이에 작업을 끼웠다. 순서를 바꾼 것뿐인데 체감이 다르다.
2차 스프린트 계획
Cruise 1차는 5주가 아니라 닫는 단위로 잡는다. 발행 수가 아니라 검증 게이트를 기준으로 간다.
- W1 — 문제 검증 72시간 + 스택·레포 골격 (이번 주, 완료)
- W2 — 최소 가설 1개를 동작하는 프로토타입으로
- W3 — 실사용 5명 확보, 정성 피드백 수집 (첫 유료 사용자 실험과 연결)
- W4 — 검증 게이트: 지표 이동 없으면 여기서 멈춘다
- W5 — 게이트 통과 시 다음 단계, 실패 시 회고와 피벗
핵심은 4번 게이트다. 틀렸을 때 멈출 수 있는 지점을 미리 박아 두는 것 — 이게 1차에는 없었다. 마감(AdSense 신청)이 멈춤 버튼을 눌러버려서, 부채가 쌓여도 멈출 수 없었다. 이번엔 멈춤 버튼을 내가 쥐고 있다.
도구 쪽은 1차와 동일하게 Claude Code로 페어 코딩을 이어간다. 바뀐 건 도구가 아니라 언제 멈추기로 정했는가다.
5주 뒤, 같은 자리에서 Cruise 1차의 결과를 보고한다. 이번엔 양이 아니라 멈춤의 정확도를 자랑할 수 있기를 바란다.
관련 글
1인 빌더의 하루 — GentleLab·AIGrit·babipanote 3개를 운영하는 법
GentleLab 시리즈(앱 3개)·AIGrit 블로그·babipanote 허브 3-브랜드를 동시에 운영하는 1인 빌더의 실제 하루 루틴. 05:30~23:00 시간 블록, 제품별 주간 시간 배분, 도구 스택 22개, 번아웃 관리 규칙까지 공개.
1인 빌더 분기 회고 — 3개월간 무엇이 바뀌었나
1인 빌더의 분기 회고. 분기 초 목표 대비 실제, 잘된 것 3가지·안 된 것 3가지, 이번 분기에 버리기로 한 것, 다음 분기 1순위까지 솔직하게 기록한 저널.
번아웃 없이 매주 발행하는 법 — 영감이 아니라 시스템이었다
매주 글을 낸다는 건 영감의 문제가 아니라 시스템의 문제였다. 빈 주가 생긴 이유와 내가 만든 주제 백로그·템플릿·AI 보조·예약 발행 루틴, 그리고 품질을 안 떨어뜨리는 선을 적은 에세이.