앱을 만들고 나서 가장 먼저 해야 할 일은 그 앱을 직접 쓰는 것입니다. 그런데 저는 그 일을 하지 않고 있었습니다.
JustBlurt는 말 그대로 "그냥 내뱉는" 앱입니다. 머릿속에 떠오르는 생각을 마찰 없이 음성으로 기록하고, 그 기록이 자동으로 Notion에 쌓이도록 설계했습니다. VTN(Voice To Notion) 시리즈를 통해 개발 과정을 연재했고, v2를 App Store에 제출했습니다. 반려를 거치고 수정을 반복했으며, 결국 앱이 심사를 통과했습니다.
그런데 며칠이 지나고 나서 깨달았습니다. 저는 JustBlurt를 거의 쓰고 있지 않았습니다.
완성하고 나서야 문제가 보였다
개발 중에는 보이지 않았던 것들이 있습니다. 기능이 동작하는지, 버튼이 의도대로 작동하는지, API 호출이 실패하지 않는지에 집중하다 보면 정작 "이 앱이 편한가"라는 질문을 잊게 됩니다. 저도 그랬습니다.
테스트 환경은 조용한 방이었습니다. 마이크에 가까이 대고 또렷하게 말했습니다. 인식률은 나쁘지 않았고, Notion에 기록도 잘 됐습니다. "이 정도면 충분하다"고 판단하고 심사 제출을 진행했습니다.
하지만 실제로 앱을 쓰는 상황은 테스트와 달랐습니다. 출퇴근길 지하철 안, 카페에서 커피를 기다리는 잠깐, 회의 직후 아이디어가 머릿속에 맴도는 순간 — 그런 순간에 앱을 꺼냈을 때, 인식 결과가 전혀 다른 방향으로 나왔습니다. "ElevenLabs API 연결 테스트"라고 말했는데 "엘레벤 랩스 에이피아이 연결 테스트"처럼 띄어쓰기와 표기가 뒤틀렸습니다. "오늘 미팅에서 나온 아이디어 정리해야 함"은 절반이 누락되거나 전혀 다른 단어로 대체됐습니다.
문제는 인식률만이 아니었습니다. 결과가 틀렸다는 것을 인식했을 때 다시 말하고 싶지 않다는 감정이 생겼습니다. 한 번 더 시도할 때마다 마찰이 누적됐습니다. 마찰이 누적되면 사람은 그 도구를 쓰지 않습니다. 저도 그랬습니다.
왜 안 쓰는가 — 나를 관찰했다
자기 자신을 사용자로 관찰하는 것은 불편한 작업입니다. 개발자로서의 자존심이 "내가 만든 앱이 불편하다"는 사실을 정면으로 받아들이기를 거부합니다. 그럼에도 일주일 동안 제 사용 패턴을 의식적으로 기록해봤습니다.
결과는 명확했습니다. JustBlurt를 열었다가 닫는 경우가 실제로 기록을 남기는 경우보다 많았습니다. 열었다가 닫는 이유는 하나였습니다. "말해봤자 제대로 안 적힌다"는 예상이 앞섰기 때문입니다.
구체적으로 어떤 상황에서 실패했는지 패턴을 정리해봤습니다.
- 배경 소음이 있을 때 — 지하철, 카페, 거리 — 인식률이 체감상 40% 이하로 떨어졌습니다.
- 영어 단어가 섞인 발화 — "React Native에서 expo-speech-recognition을 쓰는 방식" — 에서 영어 표기가 뒤섞이거나 통째로 누락됐습니다.
- 전문 용어나 고유명사 — API, Supabase, ElevenLabs, 클라우드 함수 — 가 포함된 문장에서 오인식 빈도가 높았습니다.
- 말하는 속도가 조금 빠르거나 문장이 길어지면 중간이 잘렸습니다.
이것은 단순히 "조금 불편한" 수준이 아니었습니다. 앱의 핵심 기능 — 빠르게 말하면 기록된다 — 이 실제 사용 환경에서 동작하지 않는다는 뜻이었습니다.
expo-speech-recognition의 구조적 한계
JustBlurt는 React Native + Expo 스택으로 만들어졌습니다. STT는 expo-speech-recognition 라이브러리를 사용했습니다. 이 라이브러리는 iOS에서 Apple의 온디바이스 Speech Recognition을 호출합니다. 서버를 거치지 않고 기기 내부에서 처리된다는 점은 프라이버시와 응답속도 면에서 명확한 장점입니다.
그런데 온디바이스 처리에는 구조적 한계가 있습니다.
먼저 학습 데이터의 범위가 좁습니다. Apple의 온디바이스 모델은 일반적인 일상어에 최적화돼 있습니다. 기술 용어, 외래어, 고유명사에 대한 대응이 약하고, 이를 사용자가 커스터마이징할 방법이 없습니다. API 이름이나 서비스 이름처럼 일상어가 아닌 단어는 비슷한 발음의 다른 단어로 대체되거나 공백으로 처리됩니다.
소음 환경에도 약합니다. 클라우드 기반 STT 서비스들은 대규모 소음 데이터를 학습해 노이즈 캔슬링에 강한 편입니다. 반면 온디바이스 모델은 조용한 환경을 전제로 설계된 경우가 많습니다. 지하철 배경 소음처럼 지속적이고 변화하는 소음에는 성능이 급격히 저하됩니다.
언어 전환 처리도 미흡합니다. 한국어와 영어가 혼용되는 발화는 모델이 하나의 언어로 처리하려는 경향이 있습니다. "Supabase Edge Function 만들었어"처럼 말하면 영어 부분이 한국어 음소에 맞춰 변환되거나, 반대로 한국어 부분이 의미 없는 영어 철자로 치환됩니다.
이 한계들은 expo-speech-recognition의 문제가 아닙니다. 라이브러리 자체는 Apple API를 정확히 wrapping하고 있습니다. 문제는 온디바이스 STT 모델 자체의 설계 범위입니다. 그리고 저는 그 범위 밖에서 앱을 쓰고 있었습니다.
인식률이 낮으면 앱의 핵심 가치가 무너진다
JustBlurt의 가치 제안은 단순합니다. "말하면 기록된다." 이 문장에서 "기록된다"는 결과가 정확해야 합니다. 말한 것과 기록된 것이 다르면, 사용자에게 남는 선택지는 손으로 고쳐 쓰거나 아예 그 기록을 버리는 것뿐입니다.
수정은 마찰입니다. 음성 입력의 존재 이유는 텍스트 입력보다 빠르기 때문입니다. 말한 뒤에 화면을 다시 보고 오타를 수정해야 한다면, 처음부터 타이핑한 것과 속도 차이가 없어집니다. 오히려 더 불편해질 수 있습니다. 타이핑은 눈으로 확인하면서 하지만, 말하기는 결과가 나오기 전까지 기다려야 하기 때문입니다.
포기는 더 나쁩니다. 사용자가 앱을 열었다가 닫는 패턴이 반복되면, 그 앱은 습관이 되지 못합니다. 음성 메모 앱은 쓰는 습관이 형성돼야 가치가 생깁니다. 한 번 쓰고 마는 도구가 아니라, 생각이 떠오를 때 자연스럽게 손이 가는 도구여야 합니다. 그 습관은 인식률이 충분히 높을 때만 형성됩니다.
저는 제 앱의 첫 번째 사용자였어야 합니다. 그런데 저는 그 역할을 제대로 하지 않았습니다. 제출 전 테스트는 기능 검증이었지, 사용성 검증이 아니었습니다. 실제 사용 환경을 모사하지 않은 테스트는 절반짜리 검증입니다. 그 대가로 제가 만든 앱을 제가 사용하지 않는 상황이 됐습니다.
결국 제가 만든 앱을 저조차 손이 안 가게 두고 있었습니다.
무엇을 바꿔야 하는가
진단은 명확합니다. STT 레이어를 바꿔야 합니다. 온디바이스 방식으로는 제가 원하는 사용 환경 — 소음 있는 곳에서, 영어와 한국어를 섞어서, 전문 용어를 포함해서 — 을 커버할 수 없습니다.
클라우드 기반 STT로 전환하면 달라지는 것들이 있습니다. 모델이 훨씬 크고, 소음 환경에 대한 학습 데이터가 풍부하며, 다국어 혼용에도 대응할 수 있습니다. 단점도 있습니다. 네트워크가 필요하고, API 비용이 발생하며, 응답 지연이 생깁니다. 그리고 무엇보다, 아키텍처가 달라집니다.
여러 옵션을 검토했습니다. OpenAI Whisper API, Google Speech-to-Text, 그리고 ElevenLabs Scribe v2 Realtime. 각각의 가격 구조, 인식률 특성, React Native 연동 방식이 다릅니다. 검토 기준은 세 가지였습니다. 한국어+영어 혼용 인식률, 실시간 스트리밍 지원 여부, 그리고 1인개발자 수준의 비용 감당 가능성.
이 검토를 거쳐 결정에 도달했습니다. 다음 편에서 그 결정과 이유를 다룹니다. ElevenLabs Scribe v2 Realtime을 선택한 과정, 그리고 기존 아키텍처에서 무엇이 바뀌어야 했는지를 구체적으로 설명합니다.
앱을 다시 짓는 일은 처음 만드는 것보다 어렵습니다. 동작하는 코드를 건드려야 하고, 이미 존재하는 사용자 경험을 고쳐야 합니다. 하지만 쓰지 않는 앱을 그대로 두는 것보다는 낫습니다. 1인개발자로서 실제 겪은 이 사이드 프로젝트의 기록을, 다음 편(ElevenLabs Scribe v2 Realtime으로 클라우드 STT를 옮긴 이야기)으로 이어갑니다.
댓글
댓글 쓰기