1인개발자가 매출 $0에서 가장 먼저 바꿔야 할 것은 제품이 아니라 우선순위입니다. 여기까지가 한 1인개발자가 음성 메모 앱 하나로 매출 $0를 찍은 기록입니다. 한 번의 전면 재작성, 두 번의 앱스토어 반려, 제품 작업 200시간과 마케팅 작업 0시간. 부끄럽지만 흔한 이야기이고, 지금까지 그래왔듯 서비스명과 세부 사항은 바꿔서 적습니다.
이 시리즈는 총 8편입니다. 1편에서 처음 아이디어가 떠올랐고, 2편에서 완성된 앱을 제출조차 못 했으며, 3편에서 준비 중독을 자각했고, 4편에서 도망치듯 전면 재작성을 택했습니다. 5편에서 Claude Code로 앱을 다시 지었고, 6편에서 두 번의 심사 반려를 받았으며, 7편에서 온디바이스 STT 레이턴시 문제에 정면으로 부딪혔습니다. 그리고 이 8편에서 마지막으로 한 가지를 정면으로 직시합니다. 저는 제품은 만들 줄 알았지만, 사용자를 만나는 일은 한 번도 제대로 시도하지 않았습니다.
이 마지막 편은 자책으로 끝내지 않습니다. 같은 함정을 반복하지 않기 위해 제가 실제로 바꾼 우선순위를 적습니다. 앞으로 뭘 할 것인가를 기록하는 것이 아니라, 지금까지 무엇이 잘못됐는지를 구체적으로 해부하고, 그 위에서 어떤 순서로 움직일 것인지를 정하는 일입니다.
내가 마케팅에 한 일, 그리고 안 한 일
레이턴시 피벗이 어느 정도 윤곽을 잡아갈 즈음, 저는 처음으로 마케팅을 "준비"하기 시작했습니다. 코드 작업이 일단락되면 바로 사용자를 찾겠다는 계획이었습니다. 그 준비 작업의 목록을 솔직하게 적으면 다음과 같습니다.
- 관련 커뮤니티 거점 다섯 곳 선정 — 노트 앱·세컨드 브레인·생산성 도구·인디메이커·iOS 단축어 계열
- 각 커뮤니티별 키워드 모니터링 봇 세팅 — 특정 단어가 등장하면 알림을 받는 구조
- 12주 안에 첫 유료 사용자 100명이라는 목표 수립
- 커뮤니티별 톤 전략 문서 작성 — 어떤 플랫폼에서는 어떤 말투로, 노링크 규칙은 어떻게 지킬 것인가
- 받아쓰기 자동화를 활용해 사용자 반응(VOC) 수집 파이프라인 구성 초안
- 데모 시나리오 5가지 작성 — 어떤 상황에서 앱이 유용한지를 보여주는 짧은 흐름
이 목록을 다시 보면, 전부 "준비"입니다. 실제로 커뮤니티에 글을 쓴 적은 없습니다. 데모 영상을 찍은 적도 없습니다. 첫 유료 결제를 유도하는 페이지를 만든 적도 없습니다. 계획과 문서만 있었고, 실행은 0이었습니다.
정확히 말하면 실행이 0이었던 이유가 있습니다. 앱이 "아직 완성되지 않았기 때문"이었습니다. 레이턴시가 3초였고, 7편에서 적었던 것처럼 저 자신도 그 앱을 일상적으로 쓰지 않고 있었습니다. 느려서 직접 우회하고 있는 앱을 사람들 앞에 꺼내놓는 것이 불편했습니다. 그 감각은 이해할 수 있는 것이었지만, 결과적으로 그 감각이 마케팅 0의 핑계로 작동했습니다.
실제 사이드 프로젝트 마케팅에서 흔히 일어나는 패턴이 정확히 이것입니다. 제품에 남은 문제가 있으면, 그 문제가 해결될 때까지 사람을 안 만납니다. 그런데 제품의 문제는 절대 끝나지 않습니다. 레이턴시를 1초로 줄이면 다음에는 위젯 안정성이 신경 쓰이고, 위젯이 안정되면 다음에는 Notion 연동 오류가 눈에 들어옵니다. 제품이 완성된 다음 마케팅을 하겠다는 것은, 결국 마케팅을 영원히 하지 않겠다는 것과 같은 말입니다.
안 한 것을 다시 정리하면 이렇습니다. 실제 커뮤니티 탑레벨 포스트, 짧은 데모 영상 한 편, 베타 사용자 5명 모집, 첫 결제 시도 — 이 네 가지가 전부 미실행으로 남았습니다. 계획 문서는 있었지만, 한 번도 '발행' 버튼을 누른 적이 없었습니다. 이것이 이 시리즈 전체를 관통하는 핵심 실패입니다. 저는 3편에서 준비 중독을 자각했고, 4편에서 그걸 인정했으며, 5편과 6편과 7편을 거치면서도 결국 같은 패턴에서 벗어나지 못했습니다.
이 글에 그 사실을 적어두는 이유는 자책 때문이 아닙니다. 이 글 자체가 제가 다음에 취할 행동을 가두는 약속이기 때문입니다. 다음에 같은 상황이 오면, 이 문단으로 돌아와서 확인할 것입니다. "나는 이미 이 함정을 알고 있다"고 말할 수 있는 증거로 남겨두는 것입니다.
다시 세운 우선순위
이 시리즈를 쓰면서 가장 많이 생각한 것은 "순서"였습니다. 무엇을 먼저 해야 하는가. 개발이 먼저인가, 사용자 확보가 먼저인가. 그 질문에 저는 오랫동안 "개발이 먼저"라고 답해왔습니다. 그게 틀렸습니다. 정확히는, 그 답이 틀렸다는 것을 알면서도 계속 그렇게 행동해왔습니다.
핵심 전환은 하나입니다. "제품 작업"과 "사람 작업"을 매주 저울에 올립니다. 둘 다 중요하지만, 지금까지의 비율이 200대 0이었다면 앞으로는 그 비율을 바꾸는 것이 최우선입니다. 이 단순한 원칙에서 네 가지 구체적인 행동 규칙이 나옵니다.
- 재제출·출시 직후 24시간 안에 사람 앞에 선다. 온디바이스 STT 개선판을 재제출하는 날, 저는 같은 날 커뮤니티에 글 하나와 짧은 데모를 올립니다. "출시되면 한다"가 아니라 날짜와 시각을 미리 확정해 캘린더에 박습니다. 그 글이 아무 반응이 없어도 괜찮습니다. 발행하는 행위 자체가 목표입니다.
- 이번 작업이 다음 사용자를 데려오는지 매번 묻는다. 새 기능을 추가하거나 코드를 리팩토링할 때마다, "이게 사용자 1명을 더 오게 만드는가"라는 질문을 먼저 합니다. 아니라면 그 작업은 이번 스프린트에서 빠집니다. 4편에서 정리했던 구분법, "배포 후 사용자가 보는 것 vs. 아무도 알아채지 못하는 내부 작업"을 다시 꺼내는 것입니다.
- 매주 30분, 제품 시간 대 사람 시간 비율을 적는다. 노트에 숫자 두 개만 적습니다. 이번 주 제품 작업에 쓴 시간, 이번 주 사람을 만나거나 마케팅에 쓴 시간. 200대 0이 다시 나오면 그 주는 실패한 주입니다. 측정하지 않으면 바뀌지 않습니다. 이 측정이 없었기 때문에 7편이 끝날 때까지 비율이 그대로였습니다.
- 거절을 일정의 디폴트로 둔다. 커뮤니티에 글을 올렸을 때 무시당하는 것, 데모 링크를 공유했는데 아무도 클릭하지 않는 것, 베타 모집 글에 답변이 0개인 것 — 이 모든 것을 실패가 아니라 데이터로 받습니다. 무관심·반려·무댓글은 시장이 보내는 신호입니다. 그 신호를 피하지 않고 직접 마주하는 것이 이 우선순위 재설정의 전제 조건입니다.
이 네 가지가 새로운 것처럼 보이지 않는다는 것을 압니다. 사이드 프로젝트를 하는 사람이라면 누구나 한 번쯤 들어본 원칙들입니다. 그러나 알고 있는 것과 실제로 행동하는 것은 다릅니다. 저는 이 원칙들을 알고 있었고, 3편에서도 적었으며, 그러면서도 7편까지 오는 동안 한 번도 실행하지 않았습니다. 그러므로 이번엔 단순히 원칙을 나열하는 것이 아니라, 각각에 측정 기준을 붙입니다. 숫자가 없으면 실행됐는지 확인할 수 없습니다.
우선순위를 바꾸는 것은 결심의 문제가 아닙니다. 구조의 문제입니다. 매주 비율을 측정하는 루틴이 없으면 언제든 제품 작업으로 돌아갑니다. 마케팅 초안을 쓰는 시간을 캘린더에 블록하지 않으면 그 시간은 항상 코드로 채워집니다. 결심은 쉽게 깨지지만 구조는 쉽게 깨지지 않습니다. 이 우선순위 재설정의 본질은 새로운 결심이 아니라, 이전과 다른 구조를 만드는 일입니다.
누적 교훈
7편의 개발기를 지나오면서 얻은 교훈들이 있습니다. 그 중 일부는 이미 각 편에서 적었고, 일부는 전체를 다시 보았을 때 비로소 보이는 것들입니다. 여기서는 그 전체를 한 자리에 모아서 정리합니다. 각 항목은 단순한 명제가 아니라, 실제로 어떤 사건이 그 명제를 증명했는지와 함께 적겠습니다.
-
제품 완성도가 아니라 사용자 부재가 진짜 문제다.
앱은 v1 시점에도 기능적으로 동작했습니다. 녹음하면 텍스트가 되고, 그 텍스트가 Notion 페이지에 저장됐습니다. 그런데 그 앱을 본 사람이 없었습니다. 두 번의 앱스토어 반려는 제품 완성도의 문제가 아니었습니다. 반려 사유는 기능 부족이 아니라 심사 가이드라인 해석의 차이였습니다. 반려가 두 번 있었어도 만약 그 사이에 TestFlight 링크 하나를 커뮤니티에 공유했다면, 그 자체로 의미 있는 피드백을 받을 수 있었을 것입니다. 저는 반려를 이유로 사람을 만나는 일을 미뤘지만, 반려와 사용자 확보는 사실 독립적인 일이었습니다.
-
레이턴시는 기능이 아니라 생존 요소다.
7편에서 상세히 적었지만, 한 번 더 명시합니다. Whisper API를 호출하는 방식으로 STT를 구현했을 때 레이턴시가 평균 3초였습니다. 짧은 문장을 말했을 때 3초, 30초 분량의 문장을 말했을 때도 3초였습니다. 문제는 그 3초가 느껴지는 방식이었습니다. 말을 끝내고 화면을 봤을 때 아무 반응이 없는 그 시간이 앱을 쓰기 싫게 만들었습니다. 실제로 저는 자주 앱을 쓰는 대신 기본 메모 앱에 음성 받아쓰기를 쓰고 Notion에 붙여넣는 방식으로 우회하고 있었습니다. 제가 만든 앱을 제가 쓰지 않고 있었다는 것 — 그 사실을 인정하기까지 꽤 시간이 걸렸습니다. 온디바이스 STT로의 피벗은 기능 추가가 아니라 앱이 존재할 수 있는 최소 조건을 충족하는 작업이었습니다.
-
차별점은 책상이 아니라 사용 관찰에서 나온다.
v1 기획 때 저는 "사람들이 이런 앱을 원할 것이다"라는 가정에서 출발했습니다. Notion을 쓰는 사람이라면 음성으로 바로 넣고 싶을 것이다, 기존 메모 앱과 Notion의 연결이 불편할 것이다. 그 가정이 틀린 것은 아니었지만, 실제 사용자 관찰 없이 만들어진 가정이었습니다. 결과적으로 v1의 UX는 저의 편의에 맞춰져 있었고, 다른 사람들이 음성 메모를 쓰는 방식과 상당히 달랐습니다. 제 실제 사용 패턴을 관찰하면서 위젯이 필요하다는 것을 알았고, 레이턴시가 핵심 장벽이라는 것을 알았습니다. 이 두 가지 인사이트는 책상에서 나온 것이 아니라 직접 앱을 쓰면서 나온 것이었습니다.
-
온디바이스 처리는 속도와 프라이버시를 동시에 푼다.
Whisper API에서 Apple Speech Recognition Framework로 전환하면서 예상치 못한 이점이 생겼습니다. 속도 문제가 해결됐을 뿐 아니라, 음성 데이터가 기기 밖으로 나가지 않게 됐습니다. 처음에는 이것을 부수 효과 정도로 생각했지만, 막상 이걸 실제 사용자 관점에서 바라보면 전혀 다른 의미를 가집니다. 회의 중에 메모를 남기거나, 아이디어를 음성으로 기록할 때 "내 말이 서버로 올라가는지"를 신경 쓰는 사람이 많습니다. API 기반 STT의 고질적인 불신 포인트가 온디바이스 전환 하나로 사라졌습니다. 제약이 더 나은 설계를 강제한 케이스였습니다.
-
만들 수 있다는 건 이미 증명됐다.
이 시리즈에서 저는 앱을 처음부터 다시 만들었습니다. v1은 기본 기능만 있었고, v2는 Claude Code를 써서 위젯·StoreKit 결제·온디바이스 STT 피벗까지 포함했습니다. 앱스토어 심사를 두 번 제출했고, 두 번 반려 사유를 분석했으며, 수정 후 재제출 준비까지 마쳤습니다. 기술적으로 만드는 것에는 더 이상 의문이 없습니다. 하나의 기능을 구현하는 것, 예상치 못한 버그를 추적하는 것, 심사 피드백을 해석해서 수정하는 것 — 이것들은 이미 할 수 있습니다. 부족한 것은 딱 하나였습니다. 배포 후 사람을 모으는 일. 이 시리즈 내내, 그리고 지금도 여전히, 그 일만 시작되지 않았습니다.
이 다섯 가지를 적으면서 다시 한번 확인하는 것이 있습니다. 이 교훈들은 서로 연결됩니다. 사용자 부재가 문제라는 것(1번)을 알면서도, 레이턴시가 해결되지 않았다는 이유로(2번) 사람을 만나지 않았습니다. 실제 사용 관찰에서 인사이트가 나온다는 것(3번)을 알면서도, 내 기기에서만 관찰하고 다른 사람의 사용을 관찰하려는 시도는 하지 않았습니다. 기술적으로 충분히 만들 수 있다는 것(5번)이 증명된 상황에서, 그 역량이 모두 제품 방향으로만 쏠렸습니다. 각 교훈이 따로 있는 것이 아니라, 하나의 패턴이 다섯 가지 방향에서 드러난 것입니다.
그 패턴의 이름은 '제품 회피'입니다. 정확히는, 사람을 만나는 일을 제품 개선으로 대체하는 행동입니다. 만들 줄 아는 사람에게 만들기는 통제 가능하고 익숙한 일입니다. 커뮤니티에 글을 올리거나 낯선 사람에게 피드백을 요청하는 것은 통제 불가능하고 거절당할 수 있는 일입니다. 그 비대칭이 200대 0이라는 비율을 만들었습니다.
만들 줄 아는 우리에게
이 글을 읽는 당신이 1인개발자라면, 아마 코드는 충분히 짤 줄 알 것입니다. 원하는 기능을 구현하는 것, 버그를 추적하는 것, 심사 가이드라인을 읽고 수정하는 것 — 이런 작업들이 어느 정도 익숙한 상태일 것입니다. 그래서 더 위험합니다.
잘하는 일이 있으면, 못 견디게 무서운 일을 피해 그 잘하는 일로 끝없이 도망칠 수 있습니다. 코드는 통제 가능합니다. 내가 무언가를 입력하면 예측 가능한 결과가 나옵니다. 예상치 못한 버그가 생겨도, 충분한 시간을 들이면 반드시 원인을 찾을 수 있습니다. 반면 마케팅은 그렇지 않습니다. 잘 쓴 글을 올려도 반응이 없을 수 있고, 정성껏 만든 데모를 공유해도 아무도 클릭하지 않을 수 있습니다. 그 불확실성이 코드 작업보다 훨씬 견디기 어렵습니다.
그 비대칭이 사이드 프로젝트를 망가뜨리는 방식은 대개 비슷합니다. 처음에는 "제품이 좀 더 좋아지면 사람을 만나겠다"고 생각합니다. 다음에는 "이번 버그만 잡으면"이 됩니다. 그다음에는 "UI가 좀 더 깔끔해지면"이 됩니다. 그렇게 제품은 점점 좋아지는데, 사용자는 여전히 0입니다. 저는 이 시리즈에서 정확히 그 경로를 따라갔습니다. v1에서 v2로 전면 재작성을 하면서 기능이 훨씬 풍부해졌지만, 그사이에 실제 사용자와 나눈 대화는 단 한 번도 없었습니다.
이 글을 쓰면서 제가 스스로에게 남긴 문장이 하나 있습니다. "제품은 통제 가능해서 계속 하게 됩니다. 마케팅은 거절당할 수 있어서 안 하게 됩니다." 이 문장을 처음 만들었을 때, 너무 정확해서 오히려 불편했습니다. 제 행동 전체가 이 문장 하나로 요약됩니다. 200시간의 제품 작업과 0시간의 마케팅은 실력 부족이나 전략 미비 때문이 아니라, 통제 가능한 쪽으로만 움직인 결과였습니다.
그래서 다음 스텝은 기술적인 것이 아닙니다. 재제출 후 24시간 안에 커뮤니티에 글 하나를 올리는 것입니다. TestFlight 링크를 5명에게 공유하는 것입니다. 반응이 없어도 다음 주에 또 하는 것입니다. 그 반복이 축적되면 어느 시점에는 사용자 반응 데이터가 쌓이고, 그 데이터가 다음 우선순위를 결정하는 근거가 됩니다. 지금까지는 그 과정 전체가 없었습니다.
이 시리즈의 다음 이야기는, 이번엔 정말로 사람을 만난 뒤에 쓰겠습니다. 커뮤니티에 글을 올렸고, TestFlight를 공유했고, 누군가의 반응을 받았다는 것을 전제로 시작하는 이야기입니다. 그 이야기를 쓸 수 있는 상태가 된다면, 이 8편은 이 시리즈에서 진짜 전환점이 됩니다. 아직 그렇지 못하다면, 적어도 이 문단이 다음에 다시 읽힐 것입니다. "나는 이미 알고 있었다. 그러면 이번엔 다르게 해야 한다"는 것을. Voice To Notion 개발기는 이 8편으로 1차 마무리됩니다.
댓글
댓글 쓰기