월 다운로드수 300, 비개발자가 이틀만에 출시한 앱
바이브코딩, 노코드 툴로 앱 출시한 후기와 계획 - 비라이트!
바이브 코딩, 노코드 툴로 지난 추석 연휴동안 개발한 앱을 출시한지 약 3개월이 지났습니다.
2025년 여름까지만해도 아직 세상이 바뀌지 않았다고 확신해왔습니다. 여러 아이디어들을 들고, 짧은 개발 지식으로 생성형 AI, 각종 바이브 코딩 툴과 씨름했으나, 아직 비개발자에게 개발의 장벽은 높아보였습니다.
불과 1,2개월 후인 2025년 가을 쯤, '세상이 바뀌어버렸구나'를 읖조리는 저를 발견했습니다. 러버블, 볼트 같은 툴들을 발견하고, 정말 미친 사용성에 홀딱 반해 2일만에 앱의 형태를 갖춘 것을 만들어냈습니다.
바이브 코딩 툴 - Lovable을 어떻게 효과적으로 사용했는지를 보기 위해 들어오셨다면, 다음의 글을 추천드립니다. https://brunch.co.kr/@minjumin/31 조회수 2천회를 넘은 저의 효자 상품입니다.
앱의 형태를 갖춘 것을 다듬어, 2025년 10월 말 앱스토어에 앱(비라이트)을 하나 출시했습니다. 엉성했지만, 앱스토어의 심사를 무사히 넘기고 출시된 앱은, 현재 월 다운로드수 300 정도를 기록하고 있습니다. 사용자들의 데이터가 쌓이고, 기능 개선 업데이트 8회, 사용자 확대를 위한 소소한 마케팅 활동, 사용자 문의 메일도 받아보며 서비스를 운영한지 3개월이 지났습니다.
세상의 변화를 체감하게 만들었고, 앞으로의 지형 변화에 대해 진지하게 고민하게 만들어준 경험이었으며
프로덕트 기획부터, 출시와 데이터 기반의 개선, 그리고 그로스까지 작지만 전 과정을 경험해본 프로젝트였기에, 어떻게 기획했고, 어떻게 성장하고 있는지, 그리고 어떻게 앞으로 키우려고 하는지 저의 육아 일기를 남겨보려고 합니다.
기획 배경: 비라이트 라는 스위치온 다이어트 관리 앱을 만들게된 이유
여러 아이디어들 중, '스위치온 다이어트 전용 앱'을 첫 프로덕트로 선택한 이유에는 세 가지가 있었습니다. 내가 곧 사용자였기에 문제를 쉽게 정의할 수 있었다는 것, 기능을 간단히 정의할 수 있었다는 것, 그리고 개발 난이도에 비해 명확하고, (생각보다) 큰 사용자 시장이 있다는 것.
1. 내가 곧 사용자
고백하자면, 저는 스위치온 다이어터였습니다. 조금 TMI같지만, 설명에 필요한 내용이니 덧붙이자면 스위치온 다이어트는 박용우 교수님이 만든 다이어트 방법 중 하나입니다. 당류를 제한하고, 운동, 수면 습관을 통해 몸의 대사를 바꿔주는 지방 대사를 on 해준다는 의미에서 '스위치 on!'이라는 이름을 가진 다이어트인데요. 스위치온 1회차였던 전, 쑥쑥 빠지는 살에 신나있었지만, 한 편으로는 지쳐있었습니다. '아 맞다 쉐이크 안먹었네', '단식은 또 언제하냐' 혼란스러울 때가 많았습니다. 사용자로서 '괜찮은 앱 없나?'하며 찾아봤지만, 광고가 너무 많아 사용성을 해치는 수준의 앱이나, 보기 불편하게 되어있는 앱 정도만 존재했습니다. 이렇게 사용자로서 문제를 정의할 수 있는 프로덕트라는 점이 중요한 매력 요인 중 하나였습니다.
2. 간단한 기능 정의
저는 당시 주말마다 Cursor, Bolt, Lovable 많은 툴들과 시간 날 때마다 씨름했습니다. 변화를 체감한다는 쏟아지는 후기들을 보며, 나 역시 이 변화를 기반으로 새로운 기회를 만들어보고 싶다는 생각 하나로 바이브 코딩 툴들에 월에 30만원 정도는 투자했습니다. 그렇게 다양한 툴들을 써보던 중 Lovable이라는 툴이 뱉어낸 결과물에서 변화를 느꼈습니다. '추석 연휴 동안 하나의 프로덕트를 만들어서 출시까지 해보자'는 생각으로 제가 문제의식을 느꼈던 다른 여러 문제들을 가져왔습니다. 기능 단위로 정의해보자 생각보다 타 기업과의 파트너십, API 연동 같이 당시 제가 느끼기에는 조금 복잡한 기능들을 필요로 하는 프로덕트가 많았습니다. 하지만, 비라이트는 프로그램을 쉽게 관리해줄 수 있는 요소들만 필요로 했기에, 위와 같은 복잡한 기능 구현이 필요없었습니다.
3. 난이도에 비해 꽤 큰 사용자 시장
우선 비라이트는, '스위치온 다이어트를 하는 사람'으로 타겟이 명확한 프로덕트입니다. 그래서 흔히 말하는 제품의 시장을 측정하기가 매우 간편한데요. 스위치온 다이어트는 네이버 기준 월 검색량 8만, 3천명의 활성 오픈 톡방 참여자를 보유한 다이어트 프로그램입니다.
즉, 1명이 8번 정도를 검색한다고 가정해도 월 1만명의 고객 층을 확보할 수 있는 프로덕트를 만들 수 있다는 것입니다. 거기에 앞서 말한 것처럼 스위치온 다이어트라는 키워드로 카카오톡 오픈 커뮤니티가 매우 활성화되어있는데, 여기에 각각 1500명 정도가 속해 있어, 고객을 찾아나서는 등 마케팅 비용을 들이지 않고도, 고객에게 도달할 수 있는 프로덕트를 만들 수 있다는 것이 가장 큰 매력 요인이었습니다.
스위치온 다이어트 프로그램이라는 특성상, 4주간의 프로그램 종료 후 앱을 삭제할 가능성이 높고, 연에 2,3회 정도만 다운로드 받겠지만, 프로그램을 진행하는 4주동안은 완전 활성 유저라는 점, 그리고 한 번 스위치온 프로그램을 진행한 사람은, 다시 스위치온 프로그램을 진행할 가능성이 높은 열혈 유저라는 점, 또 다이어트 프로그램의 인지도가 높아짐에 따라 새로운 사용자가 유입된다는 점을 감안했을 때 시장이 지속적으로 커지며, 사용자의 피드백을 확보하기 좋은 시장이라는 판단이 있었습니다.
이런 특성을 고려했을 때 보상형 등 광고를 붙였을 때 월 20-50 정도의 수익으로, 노코드 툴 사용 비용 정도는 환수할 수 있을 것 같다는 판단도 더해졌습니다.
앱을 기획하며: 데이터를 통한 문제, 제품의 기능 정의
저는 스위치온 다이어트를 하는 사용자였습니다. 매일 '아 맞다 쉐이크 안 먹었네', '단식은 또 언제 하지?'라며 혼란스러워했지만, 이런 불편함만으로는 해결책(앱)을 만들 수 없었습니다. 이를 위해선 외부 진짜 사용자들의 생각이나 의견, 문제 의식들을 정량화 하는 것이 필요했습니다.
가장 먼저 힌트를 얻은건 블랙키위, 연관 검색어와 유튜브에 있는 댓글들이었습니다. 블랙키위의 연관 검색어, 여기에서 검색량, 반복적으로 댓글에서 언급되는 내용들 모두 좋은 인사이트를 줬지만, 이런 문제들을 정량화하여 기능의 우선순위를 정하는데에는 어려움이 있었습니다. 그렇게 선택한 것이 앞서 언급한 3000명 규모의 오픈 채팅방이었습니다.
카카오톡 오픈 채팅방에는 정말 좋은 기능이 하나 있는데요. 대화 내용을 전체 텍스트 파일로 추출할 수 있습니다. 해당 오픈 채팅에는 사용자들이 자주하는 질문, 헷갈려하는 지점들에 대한 모든 정보가 있기에 이를 추출하여, 생성형 AI 와 함께 문제의식을 정량화하는 작업을 진행했습니다. 그렇게 이런 수치화된 근거를 기반으로 기능들을 정의하고, 이를 기반으로 PRD를 완성했습니다.
0에서 1을 만드는 실행력: 추석 48시간의 MVP와 배포
1. 개발
앞서 언급한 PRD를 기반으로, 개발자(Lovable)에게 전달하기 좋은 형태로 가공해달라는 요청, 이들에게 전달하기 좋은 프롬프터로 가공해달라는 요청을 통해 정리한 내용을 Lovable에 밀어넣고, 의도와 다르게 나온 것들을 하나씩 수정해나갔습니다.
그리고 여기에서 기능 수정이 발생하는 것들은, 다시 기존 PRD를 기반으로 PRD를 수정해달라는 프롬프터를 통해 Readme로 받아보는 형태로 지속적으로 업데이트 해나갔습니다.
2. Xcode와의 싸움 Capacitor과의 맞짱을 통한 배포
노코드 툴로 앱을 배포했다고 하면, 가장 많이 궁금해하시는 지점인 것 같습니다. Xcode와 Simulator 환경 구축, 빌드.. 전체의 과정이 모두 처음해보는 것이다보니 예상하신 것처럼 순탄하진 않았습니다. 하지만 가장 저를 어렵게 만들었던 것은 명백히 'capacitor'였습니다.
Lovabe은 앱을 기본적으로 웹(React/Vite)로 구축하고, Capacitor(연결 다리 역할)을 통해 Swift 와 같이 ios 배포에 적합한 형태로 바꿔주는데요. 이 다리 역할을 하는 놈의 버전 문제가 정말 지속적으로 계속 빈번하게 발생했습니다. 여기에 저는 Firebase등 사용자 데이터 수집을 위한 것들을 추가했고, 이 때문에 Capacitor가 더 많은 문제에 직면하게 됐습니다. 에러메세지를 개발 맥락을 알고 있는 Chat GPT에 밀어넣고는 '문제의 원인을 알려주고, 바보도 이해할 수 있게 해결책을 단계별로 정리해달라'는 말을 반복하며 주말 중 하루를 통으로 투자하기도 했습니다. 그렇게 결국 배포에 성공했습니다. 여전히 Capacitor 버전 이슈, 애플 헬스를 연동하고 나서는 더 많은 문제들에 직면하고 있지만, 항상 위와 같은 프롬프터들로 오류를 해결해나가며 배포에 항상 성공하고 있습니다.
3. 핵심 기능에 집중하기
앱을 배포한 초기엔 사용자가 거의 없었습니다. 이 때 문제의 원인이 기능 개선에 있는건 아닌가? 기능에 자신이 없던 상태라, 매일 제품을 괴롭혔는데요. 초반 두번의 업데이트 정도는 앱을 무겁게 만드는데 (의도치 않았지만) 많은 시간을 보냈던 것 같습니다. 지금 앱에선 찾아보기 어려운 커뮤니티 기능이나, OCR기반의 성분표 분석 기능이 대표적입니다. OCR 기반의 기능은, Lovable에서 오픈 소스를 자동으로 찾아와서 연결하여 개발해주는 것에 큰 놀라움을 느껴 개발한 기능 중 하나였는데요. 단백질 쉐이크의 단백질 함량, 탄수화물 함량을 매일 물어보는 오픈 채팅 사용자들을 보며 만든 기능 중 하나였습니다. 해당 기능은 AI도 활용해야하다보니, 사용자가 늘어날 수록 비용이 높아지는 문제도 존재했습니다.
이렇게 앱이 무거워지고, 몇 없는 사용자들의 데이터를 보니 사용자들이 헤매고 있다는 것이 느껴졌습니다. 홈에서 이탈하는 사용자가 많아졌고, 무겁게 만들어놓은 기능들에서 (QA를 잘 했어야 하는데 크흠 죄송합니다) 오류가 생겨서 반복된 오류 메세지 끝에 이탈하는 사용자들이 늘어났습니다.
그래서 세번 째 업데이트에는 고민 끝에 '스위치온 다이어트'에 필요한 핵심 기능 3가지를 정의하고, 해당 기능을 중심으로 서비스 전체를 개편했습니다. 그리고 이 3가지 기능들에 사람들이 쉽게 접근할 수 있게 만드는, 기능들이 한 눈에 들어올 수 있게 만들어주는 방향으로 UIUX를 개선하고, 최초 로그인시 앱에 가이드라인 이 붙게 설계했습니다.
그로스: MAU300을 만들기 위한 노력
1. 간단하지만 확실한 방법: 스위치온으로 검색했을 때 노출되게 만들기
앱을 출시한 초반엔 유입이 없었습니다. 그래서 앞에서 이야기한 것처럼 기능을 개선하려고 했는데, 문득 앱스토어에 스위치온이라고 검색했을 때 앱이 나오지 않는 다는 것을 깨달았습니다. 처음엔 '검색 엔진에 걸리는데까지 시간이 걸릴 수 있으니까~ '하고 넘겼는데, 일주일 정도 지난 시점에 다시 검색해도 안나오는걸 보자 쎄한 위기 의식이 몰려왔습니다.
당시 앱 이름에도 '스위치온'이라는 키워드가 들어가 있었습니다. '스위치온에 필요한 다이어트앱' 같은 식으로 풀어썼는데, 소개글이나 이미지 등은 크게 신경쓰지 않았습니다. 앱을 소개하는 문구를 통일하고, 직관적으로 앱이 전달하는 가치를 보여주면서도, '스위치온 다이어트'로 검색했을 때 노출되는 것의 중요성을 체감하고 앱 이름, 앱 소개, 이미지를 모두 수정했습니다.
검색 > 클릭 > 전환 이 이루어져야 앱이 상단에 노출된다는 것을 발견했지만, 지금 비라이트는 노출되지도 않는 상황이었기에, 노출되는 것이 최우선 목표였습니다. 그렇게 <비라이트 - 가벼워지는 스위치온 다이어트 식단 관리 앱>으로 바꾸고, 부제목, 소개글, 업데이트 설명, 이미지를 모두 스위치온 다이어트라는 키워드가 상위에 들어가게 수정하였습니다. 그리고 지금은 이렇게 2,3번째에 노출되고 있습니다.
2. 침투 마케팅 - 커뮤니티와 나의 자산 적극 활용하기
앱에서 검색에 걸리기 시작하자 사용자가 생기기 시작했습니다! (실제로 앱스토어 데이터를 봐도 AppStore 검색을 통한 유입이 제일 - 압도적으로 많다.) 그럼에도 이를 2~3번째까지 올리기 위해선, 다른 유입, 즉 '스위치온 다이어트'로 검색해서 비라이트를 누르고, 다운로드 받는 사람의 수 자체를 늘려야했는데, 그러기 위해선 홍보가 필요했습니다. 다른 스위치온 다이어트 앱이라는 경쟁자도 존재하는 상황이었기에 지인에게 추천해볼까도 고민했지만, 지인들이 스위치온 다이어트를 몰랐기에 또 진입장벽이 존재했습니다.
그렇게 최초 제품 기획의 배경이 됐던 스위치온 다이어트 오픈 채팅방을 활용하기로 결심하고, 톡방에 올라오는 '앱 추천'관련 질문에 키워드 알림을 걸어, 귀신 같이 답장하기 시작했습니다. (조금 짜치는 행위라 부끄럽습니다)
이렇게 하고 나면 지표가 확실히 뛰는 것을 발견하고는, 새로운 방법을 찾았다.
질문이 올라오기만 기다릴 순 없기 때문에, 사람들에게 궁금한 것들을 물어보며 앱을 노출시켰다.
결과는 매우 성공적이었습니다. 앱의 깔끔한 모양새, 강점을 보고는 무슨 앱인지 물어봐주는 사람들이 있었습니다 감사합니다! 덕분에 자연스럽게 PPL처럼 홍보할 수 있었습니다.
그리고 저의 블로그를 활용했습니다. 지금 글을 쓰고 있는 브런치 외에도 네이버블로그가 약간의 수익이 들어올 정도로 활성화 되어있는데요. 그런 저의 블로그를 활용하여 네이버에서 '스위치온 다이어트 1주차', '스위치온 다이어트 앱'이라고 검색했을 때 상위에 노출되는 것을 목표로 글을 몇 개 작성했습니다. 위의 목표는 달성하지 못했지만, 운좋게 한 글이 네이버 메인에 걸리면서 꽤 많은 유입이 발생했습니다.
3. DAU를 위한, 기능 개선과 고도화
사용자수가 증가했으나, 이탈도 매우 높았습니다. 리텐션이 매우 낮게 나왔습니다. 그러고 보니, 사용자로서 앱을 사용하려고 보니 이해가 안되는 지점들이 명확히 있었습니다. 가끔 가족, 친구들에게 앱을 써보라고 하면 이 문제를 확실히 느낄 수 있었는데, '오늘 뭐먹어야하는지 찾아봐'라고 해도 한참을 헤매는 것을 볼 수 있었고, 서비스의 직관성이 떨어지고 있다는 것을 발견하고는 이를 개선하기 위한 서비스 개선을 진행했습니다.
그러던 중 아주 귀한 메일을 하나 받게 됐는데요, '나의 앱을 지속적으로 애정을 가지고 있는 사람은 아직 없겠지' 하던 찰나에, 서비스 개선이 얼마나 예민하고 민감한 사안인지를 크게 깨닫고, 서비스를 개발하는 것의 보람을 느끼게 해주신 너무 감사한 분이셨습니다.
앞서 말했던 OCR 기능을 없애고, 단백질, 탄수화물 입력 기능도 없앴을 때 (서비스 간소화를하며 다 없애버렸을 때) 받았던 메세지였습니다. 사용자가 이렇게 직접적으로 피드백을 준 것이 처음이라 놀라면서 주말에 바로 기능을 복구해뒀는데요.
이 메세지와 더불어 몇 가지 제안까지 주셨던 터라 서비스 개선, 기능 업데이트 시 "기능 삭제"에 얼마나 신중해야하는지, 그렇기 때문에 "기능 추가"역시 얼마나 신중해야하는 영역인지를 체감할 수 있었습니다. 더 좋은 방향으로 서비스는 지속적으로 개선해나가야하지만, 활성 사용자들의 데이터 접근 권한을 모두 삭제하는게 될 수도 있다는 것을 깨달았습니다.
그래서 PRD에 DB와 연결되는 것들을 표시해두고, 데이터 삭제와 연결되는 기능을 조정할 때에는 사전 안내 & 백업 방법등을 고지하는 식으로 진행하는 가이드를 만들었습니다.
그리고 지금은 Firebase - 상에서 세부적인 지표를 볼 수 있게 다시 업데이트하여, 사용자들이 병목을 느끼는 기능이나 위치가 어디인지를 파악하고 있습니다. 추가로 외부 커뮤니티 등에 오프라인으로 참석하여 앱에 대해 소개하며, 사용자들로부터 직접 피드백을 듣기도 하는데요. 이런 피드백, 데이터를 통해 곧 애플헬스와 연동한 기능이 추가될 예정입니다.
앞으로는?
앞으로도 이 앱을 통해 실험해볼 수 있는게 아주 많다고 생각합니다. Admob을 붙이는 경험도 처음이라 의미가 있으며, 앱의 다운로드 수가 1만 단위, MAU가 1천 이상이 된다면 앱을 운영하고 개발하는 과정에서 더 많은 것들을 배울 수 있을 것이라고 생각합니다. 단순히 배움을 넘어, 실제 다이어터들에게 편의를 제공하는 앱을 만들고 있다는 사실이 의미가 깊습니다.
지금은 또 다른 아이디어를 서비스화하고 있습니다. '커리어 관리 앱'은 MVP 수준으로 개발을 완료했으며, '문서 AI 툴'은 웹으로 개발하고자 하는 서비스로, 현재 PRD를 완성한 단계입니다. 그리고 기술의 개발 속도가 전과는 다른 만큼, 다른 노코드 툴들을 여전히 계속 테스트해보고 있습니다. Chat GPT, Claude, Gemini의 싸움에서 봤듯 언제 누가 압도적인 결과를 낼지는 알 수 없기 때문입니다. 최근에는 TRAE 해커톤에 다녀오며, TRAE도 사용해봤고, 이전에는 멀어졌던 Cursor도 다시 사용해보고 있습니다. 저의 세 번째 프로덕트는 Cursor를 기반으로 할 가능성이 높아보입니다.
비개발자가 간단한 수준이지만, 사용자가 쓸 수 있는 서비스를 배포까지 할 수 있다는 것이 놀랍도록 고무적입니다. 여전히 많은 장벽이 있어보이지만, 노코드 툴의 등장은, AI가 프로덕션에 미친 영향은 획기적입니다. 비개발자가 느끼는 장벽에 비해, 개발자가 느끼는 장벽이 더 크다는 느낌도 듭니다. 하지만 저는 서비스의 안정성, 코드의 지속 가능성 등의 관점에서 개발자의 식견이 아직 매우 필요하다고 생각합니다. 또 서비스가 제휴하고 있는, 파트너십을 맺고 있는 업체가 적을수록 개발자가 개입해줘야 편해지는 기능개발 영역이 아직 많습니다. 대표적으로 Lovable을 통한 애플로그인 구현이 그렇습니다. Google 로그인은 구현이 쉬운데, 애플로그인은 제휴가 되어있지 않아 연동에 어려움이 존재합니다.
이렇게 서비스를 개발해보니, 앱, 서비스가 유튜브의 콘텐츠들처럼 과잉 상태가 되는 시기가 올 것 같다는 생각이 듭니다. 그리고 이렇게 간단하고 일방적인 편의를 제공하는 서비스들이 시장에서 얼마나 살아남을 수 있을지 의문이 생깁니다. AI는 모든 영역의 생산성을 (0~10까지 단계별로 가야했던 것들을 0만 하면 10이 나올 수 있게 바꿔주고 있기 때문입니다) 혁신하고 있기 때문입니다.
Cowork를 써보면 이렇게 앱의 형태로 존재하는 것 자체가 비효율적이라는 생각도 듭니다. 분절된 기능을 제공하는데, 내 휴대폰의 용량을 차지한다는 것 자체가 비효율적이라는 인상도 받습니다.
하지만, 웹의 세상이 오고서도 DX라는 움직임이 불과 1-2년 전까지도 이어지고 있고, 아직도 전환되지 않은 전환을 기다리는 영역이 있는 것을 보면, 세상이 변화하는 속도는 더딜수도 있을 것 같습니다. 하지만, 우리의 투자는 먼저 이 세상에서 시장을 바꿔놓을 곳들에 이루어져야하기에, 이렇게 개발 생산성이 극대화된 시대 안에서 새로운 프레임워크를 제시할 곳들을 찾게 됩니다. 이런 투자에 대한 저의 생각은 다음 글에서 자세히 정리해보겠습니다.
긴 글 읽어주셔서 감사합니다!
궁금한 내용은 편하게 문의주세요!
