“토큰을 태우자”로 시작, 운영 구조의 인사이트를 얻었다!
사주 앱을 만들며 배운 창업/운영 회고
카카오톡에서 ChatGPT Pro를 30만 원에서 3만 원대로 살 수 있는 기회가 있었어요.
저는 그걸 5개 샀고요.
문제는 그 다음이었어요.
회사에서는 Claude Enterprise를 쓰고 있으니까, 개인 Pro를 거의 안 쓰게 되더라고요.
사이드 프로젝트에서 가끔 쓰는 정도였고, 리밋이 걸릴 만큼 쓰지도 않았어요.
그래서 고민이 생겼어요.
“이걸 어떻게 의미 있게 소모하지?”
처음에 제가 잡은 방향은 단순했어요.
입력보다 출력이 비싸고, 읽기보다 쓰기가 토큰을 더 많이 먹는다는 것.
모델별로 차이는 있지만, 보통 출력 토큰 단가가 입력보다 몇 배 높아요.
그러면 길고 풍부한 결과를 생성하는 구조를 만들수록, 토큰 소모도 자연스럽게 커져요.
그렇게 나온 아이템이 사주 앱이었어요.
“서버리스 + API 호출”로는 안 풀리더라
초기 생각은 일반적인 SaaS 흐름이었어요.
- 사용자 입력 받기
- DB 저장
- API로 모델 호출
- 결과 반환
근데 여기서 비용 구조가 어긋났어요.
내가 가지고 있던 건 “내가 쓰는 모델 사용량”이고, API 호출 과금은 또 다른 문제였거든요.
즉, 제가 원한 건
로컬에서 소비되는 토큰을 기반으로 운영하는 구조였어요.
그래서 아예 발상을 바꿨습니다.
실시간 대신 큐: “모아두고, 한 번에 처리”
그래서 만든 결론이 이거였어요.
요청은 DB 큐에 쌓고, 로컬 워커가 배치로 처리해서 다시 돌려준다.
이 방식이면 모델 호출은 로컬 실행 중심으로 통제할 수 있고,
동시에 처리량도 운영자 입장에서 조절할 수 있어요.
근데 곧바로 다음 문제가 나왔죠.
- 사용자는 결과를 어떻게 받지?
- 웹에서 푸시 알림은?
- 로그인 붙이면 초기 전환율 깨지지 않나?
로그인 대신 이메일: 작은 결정 하나가 체계를 바꿨다
결론은 이메일이었어요.
Resend + HTML 템플릿으로 결과를 보내는 구조로 정리했습니다.
이 선택이 좋았던 이유는 명확했어요.
- 로그인 없이도 결과 전달 가능
- 푸시 인프라 없이도 “비동기 완료 알림”이 됨
- 운영 부담이 낮고 구현 속도 빠름
결과적으로 사용자 경험은 단순해졌어요.
- 폼 입력
- 접수 완료
- 메일에서 리포트 확인
이 3단계만 남기니까, 제품이 훨씬 가벼워졌어요.
귀찮음은 시스템으로 없앴다: 맥북에 크론 돌리기
로컬 배치는 좋은데, 매번 손으로 돌리면 그건 운영이 아니잖아요.
그래서 맥의 launchd를 이용해 주기 실행으로 바꿨어요.
- Firestore는 무료 티어로 큐 운영
- launchd가 일정 간격으로 워커 실행
- 워커가
queued -> processing -> completed/failed상태 전환 - 실패는 에러와 함께 남기고 재시도 가능
한 줄로 요약하면:
돈 아끼려고 시작했는데, 생각보다 “운영 가능한 시스템”이 만들어졌다.
품질은 결국 “문장”에서 갈렸다
만들면서 느낀 건, 사주 앱의 경쟁력은 모델 자체보다
결과 톤과 문장 설계에 더 가까웠어요.
Perplexity 리서치 기반으로 표현을 계속 다듬었고,
사용자 반응을 보면서 다음을 많이 조정했어요.
- 과하게 차가운 문장 제거
- 행동 가능한 문장 추가
- 현실감은 유지하되, 희망적인 해석의 비중 조절
그리고 실제 니즈는 꽤 분명했어요.
사람들은 “정확함”만큼 “읽고 나서 움직일 수 있는 문장”을 원하더라고요.
숫자는 작아도, 구조는 남는다
지금까지 50+ 정도 사용자가 들어왔고,
다음은 다국어 붙여서 해외 테스트를 검토하고 있어요.
근데 이번에서 진짜 크게 얻은 건 사용자 수보다 구조였어요.
토큰 소모를 고민하다가,
결국 큐 기반 비동기 운영 구조를 얻었고,
이게 다른 사이드 프로젝트와 간단한 QA 업무 자동화에도 재사용 가능하다는 걸 확인했어요.
연애 결과를 보고 싶다면 https://saju-liart.vercel.app/ 여기서 받아보시길 바랍니다~!!!