React Native로 앱테크 서비스 만들기: 리워드 시스템 편

2023년 1월부터 2024년 3월까지 서비스했던 영단어 앱테크 서비스 '캐시보카'를 2024년 3월에 매각했다.

매각할 때의 감정을 누가 물어보면, '시원섭섭' 이라는 표현이 제일 잘맞는 것 같다.

 

혼자서 고군분투한 1년 2개월이라는 시간을 다시 톺아보고, 기록으로 남기고자 한다.

14개월이라는 시간을 시계열적으로 나열하기보다는, 그동안 개발했던 굵직한 기능들을 중심으로 작성할 계획이다. (기능 소개 느낌으로..)

그래서 어쩌면 소스코드가 난무하는 개발 블로그가 될 수도 있고, 그때를 기억하는 회고록이 될 수도 있다.

 

'영단어 앱테크 서비스'에서 '영단어' 기능 구현 부분은 2년 전 첫 게시글에서 다루었으니, 이번 게시글에서는 캐시보카의 시작 부분 조금과 함께 '리워드' 개발 내용을 곁들이려고 한다. 

(영단어 부분도 거의 새로운 서비스처럼 구조가 바뀌어서 언젠가 한 번 다루긴 해야겠다)

 

1. 캐시보카의 시작

사실 캐시보카 컨셉을 구상하고 시작한건 2022년 1월이다. 당시에도 블로그에 글을 남겼었는데, 애드몹 계정이 차단당하는 바람에.. 그리고 취업을 하는 바람에 기초적인 '영단어 앱'까지만 만들고 방치해뒀다. 

https://juzero-space.tistory.com/265

기획부터 배포까지 일주일만에 영단어 퀴즈 앱 만들기 (앱스토어 첫 출시 심사 4시간만에 승인!)

 

 

 

그 후로, 2022년 11월쯤에 우연히 파이어베이스를 들어갔다가 방치해둔 앱에서 DAU가 슬금슬금 오르더니 100언저리를 꾸준히 유지하고 있는 걸 알게됐다.

어라...? 이걸 쓰네? 라는 생각과 함께 예전에 마무리하지 못한 기획을 다시 만들기로 다짐했다. 리워드 서비스의 핵심 수익인 애드몹 광고를 대체할 수 있는 방법을 찾기도 했다. 

 

2022년 12월에 한 달 동안 회사를 다니며 사전 준비와 리서치를 꽤나 준비했다. 리서치는 크게 개발 측면과 사업 측면으로 나누어서 진행했다.

나는 백엔드 개발에 대한 경험과 지식인 전무하기 때문에, 나 혼자서도 운영할 수 있는 백엔드 기술이 필요했다. 여러 수소문 끝에, 코드와 서버 개발이 필요없는 Firestore를 채택했다. 

 

사업적인 측면은 앱테크 시장에 대한 이해와 애드몹을 대체할 광고주(?) 찾기였다. 유저에게 하루 얼마정도의 리워드(캐시)를 주어야 되는지? 광고 단가가 어느정도 되는지? 어떤 광고를 노출하는게 좋은지? 광고 효율은 어떻게 올리는지? 광고주와 광고매체 등 온라인 광고 시장의 구조는 어떻게 생겨먹었는지? 폭포수와 입찰식은 뭔지 등등.

 

결정적으로 Applovin (앱러빈)이라는 광고네트워크를 찾았는데 온라인 광고시장에서 꽤나 주목받고 있는 회사였다. 애드몹이 깡패 of 깡패이긴 하지만 애드몹을 제외한 광고시장을 앱러빈이 야금야금 먹고있었다. 이때 당시에 주가가 15달러 내외였는데... 이렇게나 성장했다. 

 

 

 

각설하고, 개발과 사업측면에 대한 리서치 및 준비가 끝나고 12월 중순부터 개발을 시작했다.

기존의 영단어 서비스 구조에 리워드 시스템을 붙이는 작업이었다. 

기능은 아주 간단한데 돈 이라는 개념이 들어가다보니 DB작업을 꽤나 공들여서 했다. 추후에 CS가 들어올 경우, 해당 회원이 어떤 문제를 통해 얼마나 캐시를 받았는지 또는 못받았는지 모두 추적할 수 있어야 했다.

그래서, 회원, 월렛, 거래 내역, 퀴즈 내역, 데일리 내역 등 캐시와 관련된 유저 행위는 모두 DB에 남기도록 설계를 했다.

당시 팀원이었던 백엔드 개발자의 도움이 상당히 컸다. (colin 고마워)

 

 

 

2. 리워드 시스템 개발 과정

내가 모범 사례도 아니고, 정답도 아니지만 이런 구조로 문제없이 잘 운영했으니 혹시 앱테크나 리워드 서비스 구조를 기획 또는 개발하려는 분들께 도움이 되었으면 좋겠다. 

DB 구조나 시나리오를 작성하기 전에 기능 정책을 먼저 정의했다. 리워드 시스템은 "캐시를 얻는" 부분과 "캐시를 쓰는" 부분으로 나눌 수 있다. 

 

우선, DB의 주요 테이블(firestore에서는 컬렉션&문서에 해당)은 아래와 같이 구성했다. (컬렉션명은 예시이다.)

- user: 유저 정보

- wallet: 유저의 캐시 잔고

- daily: 유저의 데일리 문제 개수 및 캐시 적립 내역

- quiz: 유저가 푼 문제 내역

- earn: 유저가 캐시를 적립한 내역

- use: 유저가 캐시를 사용한 내역

 

 

1) 리워드 획득 정책

 

 

1. 회원만 캐시를 얻을 수 있다. 비회원일 경우 캐시가 쌓이지 않는다. 

2. 회원이 영단어 퀴즈를 맞출 경우 > 1캐시를 지급하고 3초뒤 다음 문제로 넘어간다.

3. 문제를 틀릴 경우 > 캐시를 지급하지 않고 오답노트 화면으로 넘어간다.

4. 하루 최대 100캐시까지만 받을 수 있다. 문제를 맞췄더라도 오늘 100캐시를 받았다면 캐시가 지급되지 않는다.

 

 

 

 

 

 

2) 리워드 사용 정책

 

 

1. 회원정보에 '전화번호'가 등록된 회원만 캐시샵에 있는 상품을 구매할 수 있다.

2. 전화번호가 등록되어 있고 보유캐시가 캐시샵 가격보다 많은 회원이 상품을 구매하면, 회원의 wallet의 balance에서 상품 가격만큼 캐시가 차감되며, wallet의 pendingBalance에 캐시 금액이 추가된다.

3. 구매한 기프티콘은 매주 주말에 문자로 발송되며, 발송된 이후에는 wallet의 pendingBalance의 금액이 차감되고, usedBalance 항목에 캐시금액이 추가된다.

 

*wallet: 유저의 지갑 테이블

*balance/pendingBalance/usedBalance: wallet 테이블의 칼럼이며 balance는 사용 가능한 캐시, pendingBalance는 사용했지만 기프티콘 발송 처리가 완료되지 않은 캐시(취소 및 환불 등을 위해 존재), usedBalance는 완전히 사용처리된 캐시

 

 

이처럼 매 기능을 개발하기 전에 간단히 핵심 정책을 정의해놓고 시작했다. 

출시 이후에는 캐시를 받는 방법도 바뀌고, 정책도 많이 추가되었다. 

 

 

3. 다섯 달 동안의 적자

눈치 빠르신 분은 알았겠지만, 위의 초기 정책에는 캐시를 얻는 과정에서 광고가 노출되는 정책이 없다.

보통의 앱테크들은 캐시를 얻는 과정에서 팝업광고나 전면광고를 노출해서 수익을 창출한다. 그런데, 영단어를 공부하는 과정에서 팝업이나 전면광고가 노출되는건 UX가 파괴를 넘어 멸망하는 수준이라고 생각했다. 그래서 처음에는 상하단에 띠배너 정도만 넣고 서비스를 운영했다.

 

캐시샵에서 제일 저렴한 상품의 가격이 5000캐시(네이버페이 5000원권)였고, 하루에 최대 100캐시까지 쌓을 수 있기 때문에 신규유저가 처음 상품을 구매하는 시점까지는 최소 50일이 소요된다. 

그동안 나는 지출없이 광고수익만 발생했고, 띠배너로 아주 소소한 수익이었지만 기분이 좋았다. 그리고 이때는 바보같이 50일 뒤의 상황을 예측하지 못하고 있었다.

 

"광고도 없고 공부도 하는 개꿀 앱테크"로 블로그 게시글이 한 두개 써지더니 DAU가 3~400을 금새 넘어갔다.

1월 8일에 출시가 되었고 2월즘부터 유저가 많아져서 4월쯤 되니까 적자가 내 월세보다 커졌다. (친구가 나보고 디지털 월세도 낸다고 놀렸다) 

 

그래도 캐시보카의 핵심 가치는 '영어 학습'이라며, 앱테크는 부차적인 수단일 뿐이라고 자부심을 챙기며 자선단체와 비슷한 행위를 하게 됐다. (혹여나 자사 서비스에 리워드 기능을 추가하려는 분은 장기적은 재무구조를 꼭 검토해야 한다. 한 번 추가하면 나중에 뺄 수도 없다.)

 

매주 주말에 기프티콘을 발송했는데, 매주 눈덩이처럼 불어나는 금액을 보면서 더 이상 안되겠다고 판단하고 전면광고를 넣기로 결정했다. 그때가 23년 5월 말이었다. 

 

글이 다소 길어진 것 같아, 전면광고를 추가하고 흑자로 전환한 과정은 다음 게시글에 작성해야겠다.