바이브 코딩을 통한 수익 창출의 길

바이브 코딩을 통한 수익 창출의 길은 쉽지 않다

코드는 빠르게 만들 수 있었습니다. 돈을 받고 계속 운영할 수 있는 서비스로 바꾸는 일은 그다음부터였습니다.

 

바이브 코딩으로 앱이나 서비스를 쉽게 만들 수 있다는 이야기를 자주 봅니다. 직접 해보니 절반은 맞았습니다. 예전 같으면 엄두를 내지 못했을 기능을 혼자서 실제 화면으로 만들 수 있었습니다.

그런데 화면이 돌아가기 시작한 뒤부터 해야 할 일이 더 늘었습니다. 도메인과 서버, 결제 심사, 데이터 이용 조건, 로그인, 백업, 검색 등록, 약관과 모니터링이 차례로 따라왔습니다. 코드를 만드는 속도와 서비스를 상용화하는 속도는 같지 않았습니다.

오늘 글은 수익화에 성공했다는 후기가 아닙니다. 첫 결제를 받기 전까지 무엇을 만들었고 어디에서 막혔는지 남겨두는 개발일지입니다.

처음에는 내 매매를 복기하려고 만들었습니다

시작은 개인용 주식 분석 도구였습니다. 내 포트폴리오와 매매일지를 올리고, 어느 시점에 수익이 났는지, 그때 어떤 투자 패턴이 반복됐는지 찾아보고 싶었습니다. 기억에 의존하던 매매 복기를 데이터로 해보자는 생각이었습니다.

만들다 보니 혼자만 쓰기보다 공개 서비스로 넓혀보고 싶어졌습니다.
여러 투자 전략과 기술적 지표가 같은 종목을 어떻게 해석하는지 한 화면에서 비교하고, 조건이 겹치는 구간을 찾는 서비스로 방향을 바꿨습니다.

처음에는 이를 매수나 매도 신호라고 불렀습니다.
출시를 준비하면서 표현과 기능을 다시 살폈고, 지금은 특정 행동을 권하기보다 조건 충족 여부와 여러 전략의 차이를 보여주는 분석 도구에 가깝게 정리했습니다. 처음 생각한 기능을 그대로 내놓는 것보다, 어디까지 제공할지를 정하는 데 시간이 더 걸렸습니다.

화면이 완성된 뒤에 일이 더 늘었습니다

도메인과 서버

서비스 주소로 사용할 도메인은 닷홈에서 구입했고, 외부 문의와 결제 심사에 사용할 도메인 이메일도 만들었습니다. 개인 메일로 개발하던 때에는 생각하지 않았던 작업입니다.

서버는 iwinv의 VPS를 골랐습니다. 운영체제는 Ubuntu 24.04 LTS, 웹 애플리케이션은 FastAPI와 Uvicorn, 앞단은 Caddy로 구성했습니다. Caddy가 HTTPS와 리버스 프록시를 맡고, systemd가 서버 재부팅 뒤에도 애플리케이션을 다시 실행하도록 했습니다.

당시 서버 비용은 월 5,600원이었습니다. 가격은 작아 보였지만 서버가 늘 켜져 있도록 만들고, 인증서와 로그를 확인하고, 문제가 생겼을 때 복구하는 일까지 포함하면 이야기가 달라졌습니다.

Git과 배포

개발 코드는 비공개 GitHub 저장소에서 관리했습니다. 서버에는 배포에 필요한 최소 권한만 두고, 로컬에서 검증한 코드를 올린 뒤 서버가 받아가게 구성했습니다. GitHub Actions에서는 변경사항이 올라올 때마다 자동 검증을 실행합니다.

혼자 만드는 프로젝트라 해도 배포 기록은 필요했습니다. 어제는 됐는데 오늘 갑자기 안 되는 상황이 생기면, 어떤 변경에서 문제가 시작됐는지 찾을 수 있어야 했습니다.

결제창보다 결제 심사가 어려웠습니다

포트원의 테스트 환경을 이용해 결제창을 띄우고 결제 결과를 받는 기능은 구현할 수 있었습니다. 여기까지는 개발 문제였습니다. 실제 돈을 받으려면 PG사 심사를 통과해야 했습니다.

카카오페이는 포트원을 통해 무료로 신청했지만, 주식과 투자정보를 다루는 서비스 업종 문제로 심사에서 탈락했습니다. 토스페이먼츠도 검토했습니다. 가입비는 부가세를 포함하면 22만 원, 연 관리비는 11만 원이었습니다. 비용을 내더라도 같은 업종 문제에 걸릴 가능성이 있어 신청하지 않았습니다.

국내 결제가 막힌 뒤에는 해외 결제 서비스를 찾아봤습니다. 여러 후보를 비교했고, Creem은 거래 도구와 관련된 서비스 정책 때문에 거절됐습니다.

모바일 앱은 Google Play와 App Store의 인앱결제를 사용하는 방향으로 바꿨습니다.
웹 결제와 앱 결제를 한 번에 해결할 수 있을 거라고 생각했지만,
실제로는 판매하는 곳과 결제 방식에 따라 준비해야 할 것이 달랐습니다.

무료 API와 상업 이용은 같은 말이 아니다.

주가 데이터를 가져오는 코드는 어렵지 않게 만들 수 있었습니다. 그 데이터를 유료 서비스 화면에 계속 보여줘도 되는지는 따로 확인해야 했습니다.

한국 주식 일봉과 종목 목록은 금융위원회 공공데이터를 사용. 일부 재무 데이터는 Yahoo Finance, 코인 데이터에는 Binance를 사용했습니다. 데이터 출처마다 이용 조건과 저장·표시 범위가 달랐습니다.

오픈소스 라이브러리를 무료로 사용할 수 있다는 사실이 데이터의 상업 이용까지 보장해 주지는 않았습니다. 받아오는 코드를 만드는 일보다 그 데이터를 돈을 받고 제공할 수 있는지 확인하는 일이 더 까다롭다.

로그인은 버튼 세 개로 끝나지 않았습니다

Google, Naver, Kakao 로그인을 붙였습니다. 화면에는 버튼 세 개만 보이지만, 뒤에서는 각 회사의 개발자센터와 콘솔을 따로 설정해야 했습니다. 앱 등록, 동의 화면, 콜백 주소, 공개 상태와 검수 절차가 모두 달랐습니다.

회원과 관심종목, 사용자 설정은 SQLite에 저장하도록 옮겼습니다. 데이터가 생기고 나니 백업도 필요했습니다. 서버에는 일정 기간의 일일 백업을 남기고, Google Drive에도 한 번 더 보관하도록 구성했습니다.

로그인을 구현했다는 말에는 계정을 연결하고 삭제하는 기능, 세션 관리, 데이터 보관과 복구까지 포함돼 있었습니다. 버튼을 누르면 로그인되는 장면만 보고 예상한 작업량과는 차이가 컸습니다.

검색 등록과 SEO도 개발의 일부였습니다

사이트를 공개해도 검색엔진이 알아서 모든 페이지를 보여주지는 않았습니다. Google Search Console과 Naver Search Advisor에서 소유권을 확인하고, sitemap.xml과 robots.txt를 준비했습니다. Daum과 Kakao 쪽 검색 등록 방법도 따로 확인해야 했습니다.

canonical과 다국어 페이지 주소, 구조화 데이터, 모바일 화면도 차례로 손봤습니다. 페이지를 만들었다고 색인이 바로 되는 것은 아니었습니다. 검색엔진이 페이지를 발견했는지, 읽을 수 있는지, 색인에서 빠진 주소는 없는지 계속 확인해야 했습니다.

SEO 점검에는 오픈소스 도구인 https://github.com/AgricIDaniel/claude-seo를 활용했습니다. 내부 감사 점수는 약 50점에서 75점, 다시 82점까지 올라갔습니다. 검색 순위가 아니라 사이트의 기술적 준비 상태를 점검한 결과입니다.

GitHub - AgriciDaniel/claude-seo: Universal SEO skill for Claude Code. 25 sub-skills + 18 sub-agents covering technical SEO, E-E

 

SEO 최적화라는 말은 짧지만 실제 작업은 길었습니다. 검색엔진 접근, 색인, 페이지 구조, 속도, 콘텐츠의 근거와 신뢰성을 각각 살펴야 했습니다.

서버가 멈추면 누가 알려줄까

개인 컴퓨터에서 가끔 실행하던 프로그램이라면 문제가 생겼을 때 다시 켜면 됩니다. 공개 서비스는 내가 자는 동안에도 열려 있어야 했습니다.

UptimeRobot에 30분 간격 모니터를 등록하고 이메일 알림을 연결했습니다. 서버가 응답하는지만 확인하지 않았습니다. 매일 돌아야 하는 데이터 작업이 36시간 넘게 멈추면 상태 확인 주소도 오류를 내도록 만들었습니다.

화면은 열리는데 데이터는 며칠 전 상태인 서비스도 장애입니다. 운영을 시작하니 정상이라는 말의 기준부터 달라졌습니다.

결제 뒤의 일까지 만들어야 했습니다

개인정보처리방침과 이용약관, 환불 안내, 투자정보에 관한 고지문도 준비했습니다. 형식적으로 페이지를 하나 만드는 데 그치지 않고, 실제 로그인과 결제 흐름에 맞게 내용을 고쳐야 했습니다.

결제키와 로그인 비밀값은 Git에 들어가지 않도록 서버 환경 설정으로 분리했습니다. 결제가 완료되거나 취소됐다는 웹훅을 받으면 회원 상태를 바꾸고, 같은 알림이 여러 번 들어와도 중복 처리되지 않게 만들었습니다.

결제 버튼을 띄우는 데 걸린 시간보다 결제 전후의 상태를 안전하게 관리하는 데 더 많은 시간이 들었습니다. 사용자에게는 한 번의 결제로 보이지만, 운영하는 쪽에서는 실패와 취소, 중복 알림과 복구까지 생각해야 했습니다.

만드는 것만큼 알리는 일도 남았습니다

서비스를 올렸다고 사용자가 생기는 것은 아니었습니다. 개발일지와 시장 이야기, 투자자와 전략에 관한 글을 관리하려고 SNS 콘텐츠 전용 Git 저장소를 따로 만들었습니다. 완성된 뒤 홍보를 시작하기보다 만드는 과정부터 기록해 보기로 했습니다.

이 글도 그 기록 중 하나입니다. 아직 첫 실결제 전이고, 데이터 이용 문제와 앱 결제처럼 남은 일도 있습니다. 그래서 수익화 방법을 찾았다고 말하기에는 이릅니다.

바이브 코딩 이후에 남는 일

바이브 코딩은 분명히 시작의 문턱을 낮춰줬습니다. 혼자서 서버와 로그인, 분석 화면을 실제로 만들 수 있었던 것도 그 덕분입니다. 다만 수익화의 병목은 코드를 얼마나 빨리 쓰느냐에만 있지 않았습니다.

결제 심사를 통과할 수 있는지, 데이터를 어디까지 사용할 수 있는지, 회원정보를 잃지 않을 수 있는지, 서버가 멈췄을 때 알아차릴 수 있는지가 더 오래 걸렸습니다.

앱 하나를 만들고 돈을 번다는 문장은 짧습니다. 실제로 해보니 그 사이에는 작은 회사가 맡아야 할 일들이 전부 들어 있었습니다.