솔로 제품을 만들면서 배운 것
Source: Dev.to
Background
나는 WhatShipped를 약 일주일 만에 출시했다—내가 특별히 빠른 것이 아니라, 빌드에 최적화하던 방식을 버리고 바로 출시하는 데 집중했기 때문이다.
The Cycle I Used to Run
- 아이디어를 갖는다
- 머릿속에 전체 버전을 만든다
- 실제로 만들기 시작한다
- “준비됐다”고 느낄 때까지 만든다
- 출시한다
- 침묵
- 동기 부여가 사라지고, 다음으로 넘어간다
문제는 실행이 아니라 프레이밍이었다. 나는 “완료”를 내부 품질 기준으로 여겼다. 출시할 때쯤이면 모든 질문에 답을 했지만 가장 중요한 질문은 놓쳤다: 사람들이 실제로 이것을 원할까?
The Origin Story
나는 몇 달 동안 Geentoo—공동 창업자를 위한 이탈리아 플랫폼—를 만들고 있었다. 커밋 히스토리는 수정, 진행 중 메모, “이거 작동한다” 라는 코멘트들로 엉망이었다. 사용자에게 변경 사항을 전달하려고 할 때 보여줄 일관된 것이 전혀 없었다. 나는 지저분한 git 히스토리를 스캔해 자동으로 읽기 쉽고 구조화된 changelog를 생성해 주는 도구가 필요했다. 내가 원하는 형태의 도구는 없었기에 직접 만들었다.
이것이 직접 경험한 문제를 해결했을 때 비로소 출시할 가치가 있는 유일한 기원 스토리다. 그 외는 모두 추측에 불과하다.
Scope Decisions for v1
첫 번째 버전에서는 다음 항목들을 구현하지 않기로 명시적으로 결정했다:
- 모든 플랫폼에 대한 OAuth (GitHub만 지원)
- 사용자당 맞춤 도메인 지원
- 팀 및 협업 기능
- 사용량 분석 대시보드
- 다듬어진 UI
- 공개 changelog 호스팅 페이지
- Webhook 연동
이 중 어느 것도 핵심 질문에 답하기 위해서는 필요하지 않았다: 레포를 연결하고 AI로 changelog를 생성하는 것이 실제로 문제를 해결하는가? 나머지는 모두 반복(iteration) 단계이며, 아직 출시하지 않은 것에 대해서는 반복할 수 없다.
Working Solo
가장 어려운 부분은 코드가 아니라 외부 구조의 부재다: 제품 관리자가 우선순위를 정해 주지 않고, 스탠드업이 책임감을 만들지 않으며, 팀원이 범위 확장을 억제해 주지 않는다. 혼자 작업하면 기능을 무한히 만들 수 있다. 제약은 스스로 만들어야 한다.
Cutting Scope
“핵심 기능이 작동하는지 테스트하는 데 이게 필요할까?”
답이 아니오라면, 나중을 위한 별도 리스트에 넣는다—백로그에 올리지 않으니 내 주의를 끌지 않는다.
Metrics That Matter
- 스타 수가 아니다
- 회원 가입 수가 아니다
- 매출도 아니다 (아직은)
Weekly Validation
“이번 주에 실제 사용자와 대화를 나눴는가?”
답이 아니오라면, 다른 모든 것은 의미가 없다. 누군가가 내 제품을 사용해 자신의 문제를 해결한다는 확인이 있기 전까지는 모든 것이 추측일 뿐이다.
Next Phase: Distribution
제품은 동작한다. 이제 가장 필요로 하는 사람들에게 다가가는 것이 목표다: 활동 중인 프로젝트를 가지고 있지만 changelog가 없는 오픈소스 유지보수자. 이를 위해서는:
- 직접적인 outreach
- 콘텐츠 제작
- 실제로 효과가 있는 부분과 그렇지 않은 부분을 공개적으로 공유
Call to Action
만약 당신이 changelog가 없는 오픈소스 프로젝트를 유지보수하고 있다면, 당신이 겪는 불편함을 듣고 싶다. 댓글을 남기거나 직접 연락해도 좋다.
이미 존재하는 git 히스토리(지저분한 커밋 포함)에서 changelog를 생성하고 싶다면, whatshipped.dev 에서 무료 한 번 생성을 이용해 보라.