babipanote·
#Cruise#buildlog#신제품#Sprint#1인 빌더

Cruise — 다음 제품을 골랐다, 1차의 실수를 교정하며 시작한 2차 킥오프

Sprint 1차를 끝내자마자 다음 베팅을 골랐다. 이름은 Cruise. 왜 다음 제품인가, Cruise가 뭘 푸는가, 킥오프 첫 주 체크리스트, 그리고 1차에서 한 실수를 의도적으로 교정한 5가지를 솔직하게 기록한 buildlog.

읽는 시간 8

Sprint 1차를 끝내고 숨 고를 새도 없이, 나는 다음 베팅을 골랐다. 이름은 Cruise다.

원래는 한 주쯤 쉬려고 했다. 5주짜리 Sprint 결산을 쓰고 나니 양은 초과했는데 마음은 비어 있었다. 트래픽 312명, 수익 0원, 누적 비용 7만 원대. 그 숫자들을 정리하면서 깨달은 건 단순했다 — 나는 멈추면 더 불안한 사람이다. 그래서 쉬는 대신, 다음 제품의 이름을 먼저 정했다. 이름을 정하면 그건 시작된 것이다.

왜 곧바로 다음 제품인가

1차에서 가장 크게 배운 건 기능도 마케팅도 아니었다. 나라는 빌더가 어떤 속도로 무너지고, 어떤 구조에서 버티는가였다. 그 데이터가 손에 있을 때 다음 베팅을 거는 게 맞다고 판단했다. 한 달 쉬고 나면 그 감각은 흐려진다.

그리고 솔직히 — 1차 제품 하나로는 답이 안 났다. 검증은 절반만 됐고, 트래픽은 신규 도메인 한계 안쪽이었다. 한 제품에 더 오래 매달리는 것과 새 베팅을 추가로 거는 것 사이에서, 나는 후자를 골랐다. 이 선택 자체가 다음에 쓸 글의 주제이기도 하다. 한 제품에 집중할까, 여러 제품을 병렬로 굴릴까 — 그 고민은 따로 집중 vs 멀티 제품 글에서 정리하기로 했다.

Cruise가 뭘 푸는가 — 문제 정의

Cruise는 멈추지 않고 흘러가게 만드는 것에 관한 제품이다. 이름 그대로 항해(cruise)이자 순항 속도(cruise speed)다.

문제는 내 안에서 나왔다. 1인 빌더로 일하다 보면 시작은 폭발적인데 중반에 동력이 꺼지는 패턴이 반복된다. 의지력으로 켜는 게 아니라 구조로 흘러가게 만들어야 했다. Cruise는 그 "중반의 동력 상실"을 다루는 제품이다. 더 구체적인 스펙은 아직 비공개로 둔다 — 1차에서 완벽한 시스템을 미리 설계하다 검증을 놓친 실수를 또 하기 싫어서다.

대신 첫 주에 한 건 설계가 아니라 검증이었다.

Cruise 킥오프 첫 주 — 문제 정의 노트와 검증 스케치를 책상에 펼쳐 놓은 작업 풍경

킥오프 첫 주에 한 것

첫 주는 코드를 거의 안 짰다. 대신 틀린 데서 멈출 수 있게 만드는 데 썼다.

  • 문제 검증 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주가 아니라 닫는 단위로 잡는다. 발행 수가 아니라 검증 게이트를 기준으로 간다.

  1. W1 — 문제 검증 72시간 + 스택·레포 골격 (이번 주, 완료)
  2. W2 — 최소 가설 1개를 동작하는 프로토타입으로
  3. W3 — 실사용 5명 확보, 정성 피드백 수집 (첫 유료 사용자 실험과 연결)
  4. W4 — 검증 게이트: 지표 이동 없으면 여기서 멈춘다
  5. W5 — 게이트 통과 시 다음 단계, 실패 시 회고와 피벗

핵심은 4번 게이트다. 틀렸을 때 멈출 수 있는 지점을 미리 박아 두는 것 — 이게 1차에는 없었다. 마감(AdSense 신청)이 멈춤 버튼을 눌러버려서, 부채가 쌓여도 멈출 수 없었다. 이번엔 멈춤 버튼을 내가 쥐고 있다.

도구 쪽은 1차와 동일하게 Claude Code로 페어 코딩을 이어간다. 바뀐 건 도구가 아니라 언제 멈추기로 정했는가다.

5주 뒤, 같은 자리에서 Cruise 1차의 결과를 보고한다. 이번엔 양이 아니라 멈춤의 정확도를 자랑할 수 있기를 바란다.

관련 글