SpotOn: 너무 빨리 만드는 공동창업자
하네스가 빌드를 너무 싸게 만들었다. 그래서 검증도 전에 제품을 거의 다 만들어버렸다. 좋은 공동창업자의 위험한 이면, 1인 파운더의 함정.
보드부터 살까, 코드부터 짤까. 새 하드웨어 제품은 보통 둘 중 하나로 출발한다. 나는 어느 쪽도 안 했다. 처음 한 건 하네스 세팅이었다. 부품도 코드도 없이.
하네스를 먼저 세운 선택은 다시 해도 그렇게 한다. 문제는 그걸로 그다음에 뭘 했느냐다.
손에 이미 있던 하네스
오해부터 풀자. SpotOn 때문에 하네스를 새로 짠 게 아니다. 예전 프로젝트들에 쓰려고 만들어서 이미 오픈소스로 풀어둔 harness-maker를 그냥 꺼내 썼다. 프로젝트마다 모양을 맞춰주는 범용 생성기라, SpotOn용 하네스는 명령 한 방에 나왔다. “하네스 먼저”가 안 비쌌던 이유다.
1인한테 이게 뭘 해주는지는 명확하다. Claude랑 Codex가 프로젝트에 맞춰 한 번에 세팅된다. plan에서 execute, review, wrapup으로 도는 루프가 생긴다. worktree 덕에 펌웨어랑 앱이랑 도구 작업이 서로 안 부딪치고 병렬로 굴러간다. 그리고 적대적 리뷰 게이트가, 혼자라 없는 두 번째 눈 역할을 한다.
마지막 게 제일 크다. 한번은 네 파일에 손으로 복붙된 데이터 계약을 자동 체크가 순서를 무시하고 통과시켰다. 같은 필드를 순서만 바꿔 모델에 넣으면 기기에서 조용히 쓰레기가 나오는 버그였다. 혼자 눈으로 네 파일을 대조했으면 놓쳤다. 계약을 파싱해서 순서까지 잠그는 적대적 테스트가 잡아냈다. 이런 게이트가 1인한테는 두 번째 리뷰어다.
하네스가 진짜 한 일
여기까지 보면 하네스는 그냥 코딩 도구 같다. 그런데 하네스가 처음 한 일은 코드랑 상관없었다.
dynamic workflow로 시장조사를 fan-out 했다. 에이전트들이 갈래갈래 훑어서 죽은 테니스 센서들의 무덤을 가져왔다. 하나씩 왜 죽었나 봤더니 패턴이 똑같았다. 하드웨어가 모자라서 죽은 게 아니었다. 죄다 수요랑 retention에서 죽었다. 사람들이 한두 번 써보고 서랍에 넣어버렸다. 좌절한 플레이어의 돈이 실제로 어디로 흘러가는지, 그게 진짜 질문이었다.
그걸 깔고 기술 방향을 잠그고 스펙을 썼다. 그다음 앱 목업을 쏟아냈다. 내가 원하는 방향을 씨앗으로 던지면 dynamic workflow가 웹이랑 논문이랑 arXiv, 레딧을 훑어서 화면을 HTML로 빠르게 찍어낸다. 100장이 넘게 나왔다. 내 일은 그중에서 “이건 나 혼자선 절대 안 나왔겠다” 싶은 몇 장을 알아보는 거였다.
하네스가 쏟아낸 100여 장 중에 골라서 다듬은 앱 목업. “임팩트 한 줄 평” 같은 표현도 내가 처음부터 떠올린 게 아니라 저 더미에서 건진 wow 포인트다. 화면 속 숫자는 전부 목업용 가짜값이다.
분담은 단순하다. 생성은 하네스가, 고르고 정하는 건 내가 한다. 리서치랑 마케팅은 에이전트로 쫙 펼치고, 코어 코드는 단일 스레드로, 모든 변경은 적대적 게이트를 통과하고, 최종 승인은 내가 한다. 그 분담이 하네스의 전부다. 여기까진 좋은 공동창업자였다.
그런데 너무 잘 만들어버렸다
문제는 그 공동창업자가 일을 너무 잘했다는 점이다.
빌드가 싸지니까 멈추질 않았다. dev kit에 펌웨어 올리고, BLE 동기화를 실 보드랑 실폰 사이에서 돌리고, on-device ML로 스트로크를 분류하게 하고, 앱 붙이고, 테스트를 수백 개 쌓았다. 몇 주 만에 제품이 거의 다 섰다. 좌절한 플레이어 한 명이 돈 내고 계속 쓸지, 단 한 번도 확인 안 한 채로.
어느 날 STATUS 문서 보다가 멈췄다. 빌드 항목은 거의 다 체크돼 있는데, “이걸 살 사람이 있나” 칸은 텅 비어 있었다. 순서가 거꾸로였다.
건강한 순서는 기획, 검증, 빌드다. 내 건 기획, 빌드, 그다음 검증이었다. 팀이 있으면 빌드가 비싸니까 누군가 “이거 확실해?” 하고 멈춰서 묻는다. 혼자, 하네스랑 있으면 아무도 안 묻는다. 비용이라는 브레이크를, 그 마찰을 하네스가 없애버린 것이다.
먼저 닫았어야 할 게이트
진짜 리스크는 “만들 수 있나”가 아니었다. 그 무덤에 묻힌 센서들도 다 만들 줄 알았다. 걔네가 죽은 데는 하드웨어가 아니었다. 수요랑 retention이었다. 그러니 제일 먼저 답했어야 할 건 펌웨어 질문이 아니었다. 좌절한 플레이어가 “오늘 왜 안 됐고, 고칠 한 가지는 이거”에 돈을 내는지, 그리고 계속 내는지다.
친구랑 동호회 동료 20명한테 목업을 보여줬더니 다들 좋아했다. 하지만 좋아하는 것과 사는 건 다르다. “괜찮네”랑 “지갑을 연다” 사이가 제품의 생사를 가른다. 그 게이트는 금형도 코드도 필요 없어서 싸고 빠른데, 나는 그걸 지나쳐서 빌드로 직행했다. 지금은 그 게이트를 닫는 게 진짜 일이다. 펌웨어를 더 찍는 게 아니라.
정리
보드나 코드보다 하네스를 먼저 세운다. 그건 맞다.
다만 그게 너를 어떻게 바꾸는지 알고 써야 한다. 하네스는 빌드를 너무 싸게 만들어서, 그 빌드가 만들 가치가 있었는지 묻는 게이트를 그냥 건너뛰게 한다. 코드는 대신 써준다. 하지만 멈춰서 먼저 검증하라고는 안 말해준다. 그 판단은 여전히 사람 몫이고, 내가 틀린 게 정확히 거기다.
댓글
댓글 불러오는 중...