음성 메모를 Notion에 자동 저장하는 앱을 직접 만들게 된 건, 아주 사소하고 반복적인 불편에서 시작됐습니다. 좋은 아이디어나 중요한 생각은 대부분 키보드 앞에 앉아 있을 때 오지 않습니다. 출근길 지하철 안에서, 점심 먹으러 걷는 10분 사이에, 저녁 샤워를 마치고 침대에 누운 직후에 옵니다. 그 순간 떠오른 것들을 붙잡으려고 휴대폰을 꺼내 앱을 열고 타이핑을 시작할 때쯤이면, 처음 든 생각의 절반은 이미 어디론가 흩어진 뒤입니다.
그 경험이 쌓이면서 점점 명확해진 게 있었습니다. 저는 메모 앱이 더 필요한 게 아니었습니다. 이미 Apple 기본 메모 앱도, 카카오톡 나에게 보내기도, Notion 모바일도 써봤습니다. 도구가 없어서 생각을 잃은 게 아니었습니다. 생각을 포착하는 동작이 너무 무거웠기 때문이었습니다. 앱을 찾고, 열고, 빈 화면에 커서를 놓고, 타이핑하는 그 짧은 시간이 생각의 휘발 속도를 이기지 못했습니다. 그래서 저는 말 한마디로 생각을 박제할 수 있는 도구를 원했고, 없으니까 만들기로 했습니다. 이 시리즈는 그 결정에서 시작된 약 1년간의 기록입니다.
기존 음성 메모 앱으로는 왜 부족했나
이미 시장에는 음성 메모 도구가 넘쳐납니다. Apple 기본 음성 메모 앱, 클로바노트, Otter.ai, 네이버의 클로바 받아쓰기, Siri 단축어를 이용한 녹음-텍스트 변환 플로우까지. 저도 그것들을 하나씩 써봤습니다. 결론부터 말하면, 어느 것도 제가 원하는 방식으로 작동하지 않았습니다.
가장 먼저 부딪힌 문제는 저장은 되는데 정리가 안 된다는 점이었습니다. 클로바노트와 Apple 음성 메모는 녹음 파일을 시간순으로 쌓습니다. 내용이 무엇인지는 나중에 직접 재생해서 들어야 알 수 있습니다. 일주일이 지나면 "지난주 화요일 저녁에 녹음한 게 뭐였지?"라고 스스로에게 묻게 됩니다. 녹음 자체는 완벽하게 됐는데, 그게 시간순 더미로 쌓이는 순간 실질적으로 죽은 데이터가 됩니다.
두 번째 문제는 텍스트로 바꿔줘도 그 다음이 없다는 것이었습니다. Otter.ai나 클로바노트의 STT(Speech-to-Text) 품질은 이미 충분히 좋습니다. 한국어 인식률도 나쁘지 않습니다. 그런데 받아쓰기가 된 텍스트는 다시 복사해서 Notion을 열고, 알맞은 데이터베이스를 찾아서, 속성을 입력하면서 붙여 넣어야 합니다. 받아쓰기를 해줬을 뿐, 그것이 아이디어인지 할 일인지 회고 메모인지는 내가 판단해서 내가 옮겨야 합니다. STT는 전사(轉寫)를 해줄 뿐, 내 워크플로우에 연결해주지 않습니다.
세 번째이자 가장 본질적인 문제는 내 시스템(Notion)과 완전히 단절되어 있다는 점이었습니다. 저는 일과 사이드 프로젝트의 생각들을 Notion에서 관리하고 있었습니다. 할 일은 To-do DB에, 사업 아이디어는 Ideation DB에, 일상 회고는 Reflection DB에 넣는 구조입니다. 어떤 도구를 써도 결국에는 음성 메모를 다시 읽고, 어떤 DB에 해당하는지 판단하고, Notion을 열어서 손으로 옮기는 세 단계가 필요했습니다. 자동화된 게 하나도 없었습니다. 음성 포착 이후의 모든 과정이 수작업이었습니다.
Siri 단축어로 자동화를 시도해봤던 때도 있었습니다. "Hey Siri, 아이디어 메모해"라고 말하면 텍스트를 입력받아서 특정 URL Scheme으로 Notion에 넘기는 방식이었습니다. 처음 이틀은 신기하게 잘 됐습니다. 그런데 단축어 인식이 잘 안 될 때가 있었고, 받아쓰기가 틀리면 수정할 방법이 없었으며, 무엇보다 무조건 단일 inbox 페이지에만 쌓였습니다. 분류는 여전히 내 일이었습니다. 결국 단축어도 포기했습니다.
그때 제가 원하는 것이 정확히 무엇인지 한 문장으로 정리됐습니다. "말하면 알아서 제자리에 들어간다." 받아쓰기가 아니라 분류와 라우팅. 이 한 줄이 이 프로젝트의 전부였습니다.
핵심 컨셉 — 음성에서 Notion까지 자동 라우팅
원하는 것이 정해졌으니 다음은 그 구조를 설계하는 일이었습니다. 제가 머릿속에 그린 그림은 단순했습니다. 말한다. AI가 받아쓴다. 내용을 분석해서 어떤 종류의 생각인지 판단한다. 그 판단에 맞는 Notion DB에 구조화된 형태로 저장한다. 세 단계입니다.
핵심은 두 번째와 세 번째 사이에 있었습니다. 단순 STT라면 클로바노트로 충분합니다. 제가 필요한 건 내용을 이해해서 올바른 데이터베이스로 보내는 라우팅 레이어였습니다. "오늘 오후에 거래처 미팅 잡아야 해"가 입력되면 이게 To-do라는 걸 파악해서 Notion의 To-do DB에 할 일 항목으로 생성합니다. "요즘 너무 결과에 집착하는 것 같다, 과정을 즐기는 법을 다시 생각해봐야겠어"가 입력되면 Reflection DB에 회고 항목으로 들어갑니다. "구독 기반 음성 메모 앱 시장이 아직 한국에 제대로 없는 것 같던데"가 들어오면 Ideation DB로 라우팅됩니다.
당시에 이 판단을 해줄 수 있는 기술이 마침 충분히 성숙해 있었습니다. Whisper 기반의 STT와 GPT-4 계열 LLM을 조합하면, 음성을 텍스트로 바꾼 뒤 그 내용을 분류하는 것이 기술적으로 충분히 가능한 수준이었습니다. iOS 앱 안에서 이 두 단계를 이어붙이는 것, 그리고 Notion API로 결과를 쏘는 것. 설계 자체는 복잡하지 않았습니다.
Notion DB도 당시 이미 세 개가 운영 중이었습니다. To-do(할 일과 다음 행동), Reflection(일상 회고와 감정 정리), Ideation(사업 아이디어와 프로젝트 아이디어). 그전까지는 이 세 DB에 항목을 넣기 위해 게이트웨이 역할을 하는 inbox 페이지를 따로 두고 있었습니다. 떠오른 것들을 일단 거기 몰아넣고, 나중에 시간이 날 때 세 DB로 손으로 옮기는 방식이었습니다. 그 분류 노동이 사라지는 것이 이 앱이 가져다줄 실질적인 가치였습니다. 음성 메모의 진짜 비용은 녹음 자체가 아니라 녹음 이후의 분류 노동이라는 것, 그 부분을 AI에게 통째로 넘기는 것이 이 프로젝트의 핵심 가설이었습니다.
앱의 사용 흐름도 최대한 단순하게 잡았습니다. 앱을 열면 바로 녹음 버튼이 있습니다. 버튼을 누르면 녹음이 시작됩니다. 말을 마치고 손을 놓으면 서버로 음성이 올라가고, 처리가 끝나면 어느 DB에 어떤 내용으로 저장됐는지 결과 화면이 나옵니다. 생각이 Notion에 들어가기까지 걸리는 시간은 말하는 시간 더하기 서버 응답 시간. 손가락으로 타이핑하는 과정은 전혀 없습니다. 이 흐름이 실제로 작동한다면, 걷다가 떠오른 아이디어도 걷는 도중에 박제할 수 있습니다.
내가 첫 번째 사용자였다는 점
사이드 프로젝트를 시작할 때 가장 흔하게 빠지는 함정이 있습니다. "이런 게 있으면 사람들이 좋아하겠지"라는 가정에서 출발하는 것입니다. 상상 속의 사용자가 원할 것 같은 기능을 만들다가 정작 자신은 한 번도 그 기능을 쓰지 않게 되는 경우입니다. 저는 적어도 그 함정은 피했다고 생각했습니다. 이 앱의 문제는 제가 매일 겪는 제 문제였고, 저 자신이 첫 번째이자 가장 확실한 사용자였습니다.
이 확신이 처음에는 강한 동력이 됐습니다. 기능 하나를 만들면 바로 제가 써봤습니다. 음성 인식이 잘 됐는지, 분류가 맞게 됐는지, Notion에 제대로 들어갔는지를 직접 확인할 수 있었습니다. 외부 테스터를 구할 필요도, 설문을 돌릴 필요도 없었습니다. 제 불편이 해소되면 그게 기능 완성의 기준이었습니다. 개발 중에도 실제로 몇 번 쓴 적이 있었고, 그때마다 "이게 되네"라는 감각이 개발을 계속하게 하는 연료가 됐습니다.
그런데 지금 돌아보면, 이 믿음이 가장 위험한 착각의 씨앗이기도 했습니다. "내가 원한다"는 것과 "타인이 돈을 낸다"는 것 사이에는 깊은 간격이 있습니다. 저는 개발 내내 그 간격을 한 번도 진지하게 측정하지 않았습니다. 제가 원하는 기능을 만드는 것과, 낯선 타인이 앱을 열어서 음성을 녹음하고 돈을 내는 행동 사이에 어떤 설득의 과정이 필요한지를 생각하지 않은 채로 코드를 쌓았습니다.
개발 초기에는 이 문제가 잘 안 보입니다. 기능이 돌아가는 것을 보는 만족감, 조금씩 완성되어 가는 앱을 보는 뿌듯함이 "이게 팔릴까?"라는 질문을 계속 뒤로 미루게 했습니다. 저는 그 질문을 "심사를 통과하면 생각하자"로 미뤘고, 심사 문제가 생기자 "이 문제를 해결하면 생각하자"로 또 미뤘습니다. 결국 이 시리즈 8편 전체를 써야 할 만큼 많은 일이 지나도록, 그 질문에 제대로 답한 적이 없었습니다.
첫 번째 사용자가 자기 자신이라는 사실은 시작하기에는 좋은 조건입니다. 하지만 계속 나아가려면 두 번째, 세 번째 사용자가 자신과 얼마나 비슷한지, 혹은 다른지를 확인해야 합니다. 그 검증을 생략했을 때 어떤 일이 벌어지는지, 이 시리즈가 그 과정의 기록입니다.
1년을 매달렸지만, 아직 출시조차 못 했습니다
스포일러를 먼저 하겠습니다. 이 글을 쓰는 시점까지, 저는 이 앱에 거의 1년을 투자했지만 정식 출시도 못 했고 유료 사용자도 없으며 매출은 0입니다. 결제 모듈까지 붙인 첫 번째 버전은 완성까지 했는데도 끝내 App Store 심사 제출 버튼을 누르지 못했고, 다시 전면 재작성한 두 번째 버전은 심사에 두 번 제출했지만 두 번 모두 반려됐습니다. 지금도 그 반려 사유를 수정하는 중입니다.
첫 번째 버전을 제출하지 못한 건 기술 문제가 아니었습니다. 코어 기능이 작동하지 않아서가 아니라, 제출 버튼 앞에 서는 순간 "이게 팔릴 준비가 됐나?"라는 질문이 밀려왔고, 그 질문에 답하지 못한 채로 몇 주가 지나버렸습니다. 마케팅 페이지를 만들다가 멈추고, 가격 정책을 고민하다가 멈추고, 스크린샷을 다시 찍다가 멈추는 일이 반복됐습니다. 나중에 이걸 준비 중독이라고 이름 붙이게 되는데, 그 이야기는 3편에 있습니다.
두 번째 버전을 만든 건 첫 번째를 제출하지 못한 스스로에 대한 반성에서 시작했습니다. "만들기가 문제가 아니라 출시 행동이 문제다, 더 빨리 낼 수 있는 구조로 다시 짜자"는 생각이었습니다. 그래서 아키텍처를 처음부터 다시 설계했고, 이번에는 Claude Code를 중심에 놓고 에이전트 방식으로 개발 속도를 크게 높였습니다. 실제로 훨씬 빠르게 만들었고, 두 번 심사도 제출했습니다. 그리고 두 번 다 반려됐습니다. 반려 사유는 기능의 충분성 문제였습니다. 앱이 제공하는 가치가 Apple의 기준에서는 아직 독립 앱으로 팔기에 충분하지 않다는 판정이었습니다.
처음 반려 통보를 받았을 때, 솔직히 당황했습니다. 심사 가이드라인을 읽을 때는 그게 제 앱에 해당한다고 생각하지 않았습니다. 두 번째 반려 통보를 받고서야 Apple이 무엇을 보고 있는지를 다르게 해석하기 시작했습니다. 앱의 기술적 완성도가 아니라, 앱이 사용자에게 해결해주는 문제의 범위가 좁다는 것을 Apple의 심사 기준이 먼저 짚어냈습니다. 그 이야기는 6편에 자세히 적었습니다.
지금 되돌아보면, 막히는 지점들이 쌓이면서 제가 정말 배운 건 코드 실력이나 앱 개발 프로세스가 아니었습니다. "내가 쓸 만한 것을 만드는 것"과 "남이 돈을 내는 것" 사이에 어떤 거리가 있는지, 그 거리를 좁히려면 무엇이 필요한지를, 각 실패 지점에서 한 번씩 배운 것이 이 1년의 실질적인 수확입니다. 이 시리즈 전체가 그 강을 건너려다 빠지고, 바닥을 짚고, 다시 기어 나온 기록입니다.
다음 편에서는, 결제까지 다 붙인 첫 번째 버전을 완성하고도 왜 끝내 '제출'이라는 한 걸음을 넘지 못했는지를 씁니다. 기술 문제가 아닌 그 막힘의 정체가 무엇이었는지, 당시 제가 어떻게 그것을 합리화했는지까지 포함해서입니다. 여기 담은 이야기는 실제 개발 기록이며, 서비스명과 식별 정보는 익명 처리했습니다.
댓글
댓글 쓰기