여덟 번째를 만들지 않기로 했다

서비스를 만들 줄 알게 되면 이상한 병이 생긴다.

모든 문제가 "새 서비스를 만들면 되지 않을까?"로 보이기 시작하는 병이다. 예전에는 불편함을 참거나, 기존 도구를 찾거나, 그냥 손으로 했다. 하지만 이제는 뭔가 불편하면 자동으로 이런 생각이 든다. "이걸 자동화하는 서비스를 만들면 되겠는데."

5월의 어느 저녁, 나는 이 병의 발작을 경험했다.

StackTube를 쓰다 보니 문제가 하나 생겼다. 분석 노트가 계속 쌓이기만 했다. 유튜브 영상을 분석하면 노트가 생성되고, 그게 PDF로, 마크다운으로 폴더에 쌓인다. 그런데 그 노트를 다시 열어보는 일이 거의 없었다. 만드는 건 자동인데, 다시 보는 건 수동이었고, 수동인 일은 결국 안 하게 된다.

디지털 호딩. 디지털 저장 강박. 다운로드는 하는데 다시 안 보는 그것. 내가 만든 도구가 오히려 그 문제를 가속하고 있었다. 예전에는 영상을 안 보고 넘겼는데, 이제는 분석 노트를 안 보고 쌓아둔다. 형태만 바뀌었다.

병이 발작했다. "이 문제를 푸는 새 서비스를 만들면 되지 않을까?"

머릿속에서 이미 이름까지 지어졌다. StackBrain. 쌓인 노트를 다시 꺼내 보게 만드는, 지식 회고 서비스. 스페이스드 리피티션, AI 태깅, 주간 다이제스트, 벡터 검색. 기능이 줄줄이 떠올랐다. 관제탑에 신나게 설명했다. 경쟁 서비스 11개를 조사해달라고 했다. Readwise, NotebookLM, Recall, Heptabase, Mem... 지식관리 방법론 9개도 정리해달라고 했다. PARA, 제텔카스텐, BASB...

관제탑이 조사를 해줬다. 그리고 조사 끝에, 이렇게 말했다.

"이건 별도 서비스로 만들 문제가 아닙니다. StackTube 안에 넣어야 합니다."

이유는 명확했다. 나에게는 스스로 정한 규칙이 있었다. 동시에 활성 개발 중인 프로젝트는 3개를 넘기지 않는다. 그리고 12주 안에 사용자 100명 또는 월 $200 매출을 못 넘기면 접는다. 이 규칙은 감정 없이 미리 정해둔 것이었다.

StackBrain을 만들면 8번째 서비스가 된다. 이미 7개 서비스 로드맵이 있는데, 여기에 하나를 더 얹는 것이다. 그것도 아직 첫 번째 서비스(StackTube)도 제대로 안착하지 않은 상태에서.

관제탑의 논리는 이랬다. 디지털 호딩 문제는 진짜 문제다. 하지만 이건 StackTube 사용자가 겪는 문제다. StackTube가 만든 노트를 StackTube가 다시 보게 해주면 된다. 새 집을 지을 필요가 없다. 있는 집에 방을 하나 더 만들면 된다.

이 말을 듣고 나는 조금 부끄러웠다.

새 서비스를 만드는 게 문제를 푸는 것보다 재미있어서 그쪽으로 기울었던 건 아닐까. "StackBrain"이라는 이름을 지을 때의 그 흥분. 그건 문제를 풀고 싶은 마음이 아니라 새 걸 만들고 싶은 마음이었다. 문제는 핑계였고, 진짜 동기는 "새로운 것을 시작하는 쾌감"이었다.

이건 솔로 창업자가 가장 조심해야 할 함정이었다. 프로덕트 스프롤. 제품이 끝없이 번지는 것. 마스터 플랜에도 리스크 1순위로 적혀 있었다. "7개 제품 동시 관리"의 위험. 나는 아직 1개도 제대로 못 하면서 8개째를 만들려 하고 있었다.

결국 StackBrain을 접었다. 대신 그 기능들 — 회고, 태깅, 다이제스트 — 을 StackTube 안의 기능으로 통합하기로 했다.

그런데 이 병은 재발성이 있었다.

같은 날, 또 다른 발작이 왔다. 이번엔 모바일이었다. StackTube를 폰에서도 쓰고 싶었다. 그러면 네이티브 앱을 만들어야 하지 않나. 아이폰 앱, 안드로이드 앱, 맥 앱까지.

관제탑에 물었다. "네이티브 앱을 만드는 게 좋을까?"

또 만류당했다.

관제탑의 분석은 냉정했다. StackTube는 "한 번 설정하면 알아서 도는" 서비스다. 채널을 등록해두면 새 영상이 올라올 때마다 백그라운드에서 분석하고, 결과를 이메일이나 Obsidian으로 보낸다. 매일 앱을 열어서 뭔가를 조작하는 서비스가 아니다. 뉴스레터에 가깝다.

이런 서비스에 네이티브 앱은 과하다고 했다. 네이티브 앱의 이점 — 푸시 알림, 홈 화면 설치, 오프라인 접근 — 의 80%는 PWA로 달성할 수 있다고. PWA는 웹사이트인데 앱처럼 설치되는 것이다. 그리고 애플 앱스토어를 통하면 인앱 결제 수수료 문제까지 생긴다. 개발에 4주에서 10주가 걸리는데, 그 시간이면 로드맵의 다른 일들 — 일본 론칭, 다음 서비스 — 을 밀어낸다.

두 번의 발작, 두 번의 만류. 하루에 두 번, AI가 나에게 "만들지 마"라고 말했다.

이상한 일이다. AI는 코드를 만들어주는 도구다. "만들어줘"라고 하면 만든다. 그런데 그 AI가 "만들지 마"라고 말하고 있었다. 그리고 그 조언이 옳았다.

여기서 배운 게 있다. 만들 줄 아는 능력이 생기면, 안 만들 줄 아는 능력이 그만큼 중요해진다. 망치를 쥐면 모든 게 못으로 보인다는 말이 있다. 서비스를 만들 줄 알게 되면 모든 문제가 새 서비스로 보인다. 하지만 대부분의 문제는 새 서비스가 아니라 기존 서비스의 개선으로, 혹은 아예 만들지 않는 것으로 풀린다.

절제가 곧 전략이다.

이건 코드를 짜는 것보다 어렵다. 코드는 AI가 대신 짜준다. 하지만 "이건 만들지 말자"라는 판단은 내가 해야 한다. 그리고 그 판단을 내리려면, 새 걸 만들고 싶은 충동을 이겨야 한다. 충동을 이기는 건 기술이 아니라 규율이다.

여덟 번째를 만들지 않기로 한 그 밤, 나는 아무것도 만들지 않았다. 그리고 그게 그날의 가장 좋은 결정이었다.

---

🔧 이 에피소드의 기술 용어 해설

디지털 호딩 (Digital Hoarding) 디지털 파일을 계속 저장하지만 다시 보거나 정리하지 않고 쌓아두기만 하는 습관. 다운로드한 PDF, 저장한 북마크, 캡처한 스크린샷이 쌓이기만 하는 것. StackTube의 분석 노트도 이 문제를 겪을 수 있었다.

프로덕트 스프롤 (Product Sprawl) 제품이나 기능이 통제 없이 계속 늘어나는 현상. 솔로 창업자에게는 치명적인데, 관리할 수 있는 것보다 많은 것을 만들면 전부 부실해지기 때문이다.

킬 크라이테리아 (Kill Criteria) 프로젝트를 중단할 기준을 미리 숫자로 정해두는 것. "12주 내 100명 또는 월 $200 미달 시 중단"처럼. 감정이 아니라 기준으로 판단하기 위한 장치.

PWA (Progressive Web App) 웹사이트인데 앱처럼 동작하는 기술. 홈 화면에 설치할 수 있고, 푸시 알림도 받을 수 있고, 오프라인에서도 일부 동작한다. 네이티브 앱을 따로 만들지 않고도 앱 경험의 상당 부분을 제공한다.

네이티브 앱 (Native App) 아이폰용, 안드로이드용으로 각각 따로 만드는 앱. 앱스토어를 통해 배포된다. 기능은 강력하지만 개발 비용이 크고, 앱스토어 결제 수수료(보통 15~30%) 문제가 있다.

스페이스드 리피티션 (Spaced Repetition) 간격 반복 학습법. 배운 내용을 점점 긴 간격으로 반복 복습하면 기억에 오래 남는다는 원리. 안키(Anki) 같은 앱이 대표적. 쌓인 노트를 다시 보게 만드는 방법 중 하나로 검토했다.