사이드 프로젝트를 제품으로 만드는 과정

사이드 프로젝트의 함정

대부분의 사이드 프로젝트는 완성되지 않는다. 흥미로운 기술을 써보고, 어느 정도 동작하면 다음 흥미로운 것으로 넘어간다. 기술적으로는 성공이지만 제품으로서는 아무것도 아니다.

“제품으로 만든다”는 건 다른 사람이 쓸 수 있는 상태로 만드는 것이다. 여기에는 기술 외의 작업이 많다.

1단계: 문제부터 확인

기술이 아니라 문제에서 시작해야 한다.

KeyBox는 “API 키를 메모장에 저장하고 있다”는 불편함에서 시작했다. 1Password나 Bitwarden이 있지만, 개발용 시크릿 관리에는 과하다. 로컬에서 가볍게 관리하고 싶은 니즈가 있었다.

체크리스트:

• 이 문제를 겪는 사람이 나 말고도 있는가?
• 기존 솔루션이 없거나, 있어도 불만족스러운가?
• 해결책을 만들 수 있는 기술력이 있는가?

세 가지 모두 Yes여야 진행할 가치가 있다.

2단계: 범위 자르기

“있으면 좋겠다”와 “없으면 안 된다”를 구분한다.

KeyBox MVP의 범위:

• 필수: 시크릿 저장/조회, AES-256 암호화, 마스터 패스워드
• 나중에: 카테고리 분류, 검색, 내보내기/가져오기
• 안 한다: 클라우드 동기화, 팀 공유, 브라우저 확장

“안 한다” 목록이 가장 중요하다. 범위를 줄여야 출시할 수 있다.

3단계: 기술 선택은 빠르게

기술 비교에 시간을 쓰지 않는다. 익숙한 스택에서 시작하고, 문제가 생기면 그때 바꾼다.

KeyBox의 기술 선택은 30분 만에 끝났다:

• Desktop → Tauri (Electron은 무겁다)
• Frontend → React (익숙하다)
• Backend → Rust (Tauri 기본)
• DB → SQLite (로컬, 서버 불필요)

완벽한 선택이 아니어도 된다. 출시가 더 중요하다.

4단계: 2주 안에 동작하게

2주 안에 핵심 기능이 동작하지 않으면 문제가 있다.

• 기술적으로 너무 어렵거나
• 범위가 너무 넓거나
• 동기가 부족하거나

KeyBox는 3주 만에 v1을 출시했다. 디자인은 최소한으로, 기능은 필수만.

5단계: “제품”으로 만드는 작업들

코드가 동작하는 것과 제품이 되는 것 사이에 이런 작업들이 있다:

• 에러 핸들링: 잘못된 패스워드, 손상된 DB 파일, 디스크 용량 부족
• 설치/삭제: 인스톨러, 첫 실행 경험
• 문서: README, 사용법, FAQ
• 배포 채널: GitHub Releases, 홈페이지
• 피드백 채널: GitHub Issues, 이메일

이 작업들이 전체 시간의 40%를 차지한다. 코드 작성은 60%.

6단계: 출시 후

출시가 끝이 아니다. 하지만 출시 후에야 진짜 피드백을 받을 수 있다.

• 사용자가 실제로 어떤 기능을 쓰는지 (vs 내가 중요하다고 생각한 기능)
• 어떤 에러가 발생하는지 (vs 내가 예상한 에러)
• 무엇을 추가로 원하는지 (vs 내가 만들고 싶은 기능)

이 차이를 인식하고 반영하는 것이 “사이드 프로젝트”와 “제품”의 경계다.

판단 기준: 멈출 때와 계속할 때

멈춰야 할 때:

• 출시 후 3개월이 지났는데 사용자가 없다
• 문제를 해결하는 다른 도구가 나왔고 더 좋다
• 유지보수 비용이 가치보다 크다

계속해야 할 때:

• 소수라도 꾸준히 쓰는 사용자가 있다
• 피드백이 구체적이다 (막연한 칭찬이 아니라 기능 요청)
• 직접 쓰고 있고, 대안이 불만족스럽다

정리

사이드 프로젝트를 제품으로 만드는 건 기술이 아니라 습관이다. 범위를 자르고, 빠르게 출시하고, 피드백을 반영하는 루프를 돌리는 것. 완벽한 코드보다 출시된 코드가 낫다.