상점과 광고, 그리고 결제 서버를 고른 기준

「마계공단: 던전사업부」는 던전 편에 서서 쳐들어오는 모험가를 막는 모바일 던전 경영 게임이다. 지금 App Store에 나와 있는데, 출시 전에 제일 오래 고민한 게 돈 버는 구조였다. 1인 게임 개발에서 수익 얘기는 늘 뒤로 미루게 된다. 나도 9월 내내 게임만 만들다가 10월이 돼서야 상점과 광고를 손댔다.

이번 편은 10월 1일부터 16일까지, 그중 상점·광고·결제에 해당하는 커밋 60개 정도를 따라간 기록이다. 보상형 광고 9종을 붙이고, 상점을 만들었다가 갈아엎고, 유니티 인앱결제와 결제 서버를 연결해서 첫 테스트 구매랑 첫 환불까지 해 봤다. 그림은 이번에도 그때 저장소에 남긴 화면만 썼다.

보상형 광고부터 붙였다

상점보다 광고가 먼저였다. BM 문서 첫머리엔 "마케팅비를 많이 쓸 수 없으니 한 번 산 사람이 계속 하면서 다시 살 이유가 필요하다"고 적어 놨다. 돈을 안 쓰는 사람한테는 광고로 조금씩 더 받아 가는 길을 열어 두기로 했다. 기획 문서에 적은 규칙은 이랬다. 광고는 보는 사람이 직접 고른다. 강제 팝업이나 광고용 빨간 알림은 없다. 다 봐야 하는 일일 과제도 만들지 않는다.

10월 1일 오후에 6종을 먼저 붙이고, 그날 밤에 9종으로 늘렸다.

전부 열리면 하루 최대 13회, 토벌대까지 같은 날 쓰면 15회다. 숫자만 놓고 보면 많은데, 각 광고는 그 기능이 열릴 때 같이 열린다.

같은 날 밤엔 광고 버튼을 전부 다시 만들었다. 처음 버전은 버튼에 "화염 영혼석 +5개"만 적혀 있었다. 바꾼 버전은 지금 몇 개 있고 받으면 몇 개가 되는지(보유 0 → 5)를 같이 보여 준다. 재료가 부족해서 막힌 화면에서 들어오면 그 재료가 미리 골라져 있다. 발굴이나 길드장처럼 횟수가 있는 곳은 기본 횟수가 남아 있는 동안엔 광고 제안을 아예 숨겼다. 아직 공짜로 할 수 있는데 광고부터 보여 주면 이상하니까.

다음 날 아침엔 광고 없이 보상만 받는 권한을 만들었다. 이걸 산 사람은 9종 전부 같은 보상, 같은 횟수를 광고 없이 받는다. 버튼은 그래도 직접 누른다.

개발자 노트광고 보상은 언제 '받은 것'으로 치나

광고 SDK에서 오는 콜백은 여러 개인데, 보상 완료로 인정하는 건 '보상 획득' 콜백 하나뿐이다. 광고를 닫았거나 실패한 것만으로는 주지 않는다. 받을 양도 SDK가 넘겨 주는 숫자가 아니라 게임 쪽 지면 규칙이 정한다.

콜백은 늦게 오거나 두 번 오기도 해서, 요청마다 구분해 두고 이전 요청의 늦은 콜백은 버린다. 광고 요청은 버튼을 누를 때만 하고, 미리 계속 불러오지 않는다. 영업 결재처럼 기본 보상이 있는 곳은 광고 버튼을 누르기 전에 기본 보상을 이미 저장해 둔다. 광고 중에 앱이 꺼져도 원래 받을 건 남는다.

10월 13일엔 실제 AdMob SDK와 동의 화면(UMP)을 연결했다. 이때 광고 단위는 전부 Google의 테스트 ID였고, 실제 광고로 바꾼 건 출시 검수 빌드를 만들 때였다. 동의 화면이 광고 요청을 허용하지 않으면 앱이 마음대로 허용으로 바꾸지 않는다.

처음 만든 상점, 그리고 1인 게임 개발 수익 계산

10월 2일 아침 9시 46분에 상점 화면을 처음 커밋했다. 상품 12개를 카드로 늘어놓고, 누르면 상세 시트가 뜬다. 구매 버튼은 "결제 준비 중"으로 막아 뒀다. 이때는 결제 SDK가 없었다.

30분 뒤에 바로 고친 게 하나 있다. 각성 기능은 1-7을 깨면 열리는데, 1-8 직원 핫딜도 같은 1-7 클리어에 걸려 있었다. 그래서 1-7을 깨는 순간 상점에 유료 상품 세 개(1-8 직원, 각성 지원, 정착 지원)가 한꺼번에 떴다. 각성 지원은 각성 튜토리얼이 끝난 다음에 나오게 미뤘다.

10월 9일 밤엔 상품 그림을 PixelLab으로 그려서 넣었다. 영혼석·강화석 아이콘, 상품 그림, 태그 리본, '구매 완료' 도장 같은 것들이다.

그런데 12일에 상점을 다시 뜯어봤다. 판매 중인 일회성 상품을 전부 사도 한 계정에서 나올 수 있는 매출이 72,100원이었다. 반복해서 살 수 있는 상품은 7일에 한 번짜리 하나뿐이었고, 6장 이후 하드 모드나 길드장 구간엔 팔 게 아예 없었다. 엔드게임 편에서 만든 후반 콘텐츠에 오래 남는 사람한테 줄 상품이 없는 상태였다.

첫 결제 상품인 정착 지원(2,900원)도 문제였다. 원당 골드로 환산하면 상점에서 효율이 제일 낮았다. 처음 사는 상품이 제일 손해인 구조였다.

이 진단은 AI 도구로 정리했다. 비슷한 장르 게임 8종의 상점 구조를 웹 자료로 조사했고, 따로 받은 개선 제안은 항목마다 채택, 부분 채택, 미채택을 표로 정리했다. "모든 상품을 계정당 1회로" 같은 제안은 매출 상한 문제를 그대로 둬서 뺐다.

상점 개편: 바꾼 것과 안 바꾼 것

12일 오후 3시 45분에 개편안을 커밋했다. 원칙은 기존 BM 문서 그대로 뒀다. 무료로도 끝까지 성장할 수 있어야 하고, 돈 내야만 얻는 능력치는 없고, "클리어 보장" 같은 문구나 근거 없는 할인율은 쓰지 않는다. 그 위에 바꾼 것들이다.

• 정착 지원은 가격은 그대로 두고 수량을 늘렸다. 6,000골드, 영혼석 60, 강화석 20. 14일에 마정석 450개를 더 넣었다(채용 세 번 분량).
• 광고 없이 보상 받기는 이름을 '던전장 특권'으로 바꾸고 상점 맨 위로 올렸다. 전투 ×3 배속은 원래 하루 한 번 광고를 보면 1시간 쓸 수 있는 기능인데, 7일에 이 상품을 가진 사람은 무제한으로 쓰게 바꿨다. 스토리를 끝까지 깨려면 같은 스테이지를 수백 번 반복하는 게임이라 광고 9종보다 이쪽 체감이 훨씬 크다. 그런데 상품 이름엔 그게 하나도 안 드러나 있었다.
• 반복 상품을 새로 만들었다. 30일 보급(6,900원, 즉시 5일분 + 30일 동안 매일 우편), 주간 선택 보급(4,900원), 하드 패스.
• 마정석 팩을 팔기로 했다. 그 전까지는 판다고도 안 판다고도 정하지 않은 상태였다.

마정석 수량은 하루 사이에 한 번 바꿨다. 처음엔 4,900원에 300개였는데, 그 수량이면 천장까지 채용해서 전설을 하나 확정하는 데 11~18만 원이 들었다. 같은 상점에 9,900원짜리 전설 영입 상품이 있는데 말이다. 그래서 같은 가격에 1.5배로 올렸다. 4,900원 450개, 14,900원 1,500개(+150), 44,000원 5,000개(+750), 89,000원 10,500개(+2,250)이고 팩마다 첫 구매는 기본 수량이 2배다.

안 한 것도 적어 뒀다. '×5 가치' 같은 배수 표기는 넣지 않았다. 골드나 재료는 실제 판매가로 환산할 기준이 없어서다. 대신 보유량, 받는 양, 구매 후 수량을 표로 보여 준다. 1,500원짜리 진입 상품도 보류했다. 14일 오후 4시 39분에 남은 결정을 다 끝내고 상점의 '테스트 가안' 문구를 내렸다. Google Play에는 상품 20종을 원화로 직접 입력해 등록했고, Apple 가격은 iOS 출시 준비 때 따로 맞추기로 했다.

결제 서버를 고른 기준: 유니티 인앱결제 + Firebase

12일 오후 5시 15분에 결제 구조를 정했다. 선택지는 둘이었다.

1. 서버 없이 스토어 영수증만 확인하고 기록은 기기에 저장
2. 가벼운 서버를 두고 영수증 검증, 구매 기록, 서버 시각을 서버가 맡기

72시간 핫딜이나 30일 보급은 기기 시계만 믿으면 시계를 돌려서 쉽게 뚫린다. 기기를 바꾸면 산 걸 되찾을 방법도 필요했다. 그래서 2번으로 갔다. 결제는 Unity IAP, 서버는 Firebase(로그인, 데이터베이스, 서버 함수)다.

같은 날 미리 정한 게 하나 더 있다. 구매 기록을 개발용 가짜로 먼저 만들지 않는다. 저장 위치가 정해지기 전에 만들면 어차피 다시 만들게 되니까, 결제 SDK를 붙일 때 한 번에 만들기로 했다.

개발자 노트Firebase를 고른 이유와 비용 방어

Unity 쪽 클라우드 저장·서버 코드 서비스는 구매 기록용으로 같이 쓰지 않기로 했다. 구매 기록은 Firebase 한 곳에만 둔다. Unity IAP는 결제 창을 띄워 주지만 영수증을 서버에서 검증해 주지는 않는다. 그래서 지급 판단은 반드시 서버 함수가 스토어에 직접 확인한 다음에만 한다. 클라이언트 혼자 지급하는 경로는 남기지 않는다.

구매 기록은 원장처럼 쌓는다. 지급할 때마다 순번이 붙은 기록이 하나씩 늘고, 같은 거래가 두 번 와도 한 번만 지급한다. 클라이언트는 원장을 읽기만 하고 쓰지 못한다.

비용은 이렇게 막았다.

• 서버 함수의 최소 인스턴스는 0. 1로 두면 아무도 안 들어와도 계속 과금된다.
• 전화번호 인증은 안 쓴다. 문자 한 통마다 돈이 나간다.
• 필요한 순간에만 호출하고, 전체 구매 내역을 반복해서 읽지 않는다.
• 세이브 백업은 최소 1시간 간격, 하루 10회까지만. 이 상한은 앱이 아니라 서버 보안 규칙에서 막는다.
• 월 1만 원 예산 알림을 걸었다. 이건 알림일 뿐 상한이 아니라서, 넘어도 결제 기능이 멈추지는 않는다.

같이 적어 둔 할 일 중엔 스토어 수수료 15% 신청도 있다. Google Play와 Apple 둘 다 신청해야 적용되고, 안 하면 30%다.

13일 오전에 구매 원장, 지급, Unity IAP 연결을 한 번에 커밋했다. 이 커밋 하나가 5,600줄이 넘는다. 바로 이어서 구매 버튼, 산 물건이 쌓이는 구매함, 패스 단계별 받기를 붙였다. 세이브가 꼬이지 않게 백업과 구매를 분리한 얘기는 세이브 편에 따로 썼다.

첫 테스트 구매, 첫 환불

14일 낮에 Google Play 내부 테스트 트랙에서 결제를 켰다. 저녁 6시 27분에 마정석 팩을 넣은 빌드를 올렸고, 실제 폰에서 450개짜리 팩을 두 번 사 봤다. 첫 번째는 첫 구매 2배, 두 번째는 기본 수량으로 들어갔다. 원장에도 두 건이 따로 남았다.

7시 5분엔 두 번째 주문을 Play Console에서 직접 환불했다. 환불되면 산 마정석 450개를 회수해야 한다. 이게 실제로 회수되는 걸 확인하기까지 이틀이 걸렸다. 다음 날 정기 점검에선 환불 건이 안 잡혔고, 16일 저녁에야 서버 쪽 권한 설정 하나가 빠져 있었다는 걸 찾았다. 권한을 주고 나서 450개가 한 번만, 앱 안에서 회수됐다.

환불 정책도 이날 정했다. 이미 받은 직원, 골드, 영혼석, 강화석은 환불해도 회수하지 않는다. 끊는 건 아직 안 받은 보상과 남은 권리, 그리고 마정석뿐이다. 직원을 회수하면 그 직원에 쓴 강화 재료까지 꼬이고, 골드를 빚으로 만들면 진행이 막힌다. 반복해서 환불하는 계정은 자동 제재 없이 직접 확인하기로 했다.

밤 8시 52분엔 핫딜 72시간을 서버 시각으로 재게 바꿨다. 처음 보여 준 시각도 서버에 기록하고, 창이 닫힌 뒤에는 결제 자체를 막는다. 앱도 마지막으로 서버와 맞춘 시각으로 자기 시계를 보정한다. 기기 시계를 앞뒤로 돌려도 남은 시간이 바뀌지 않는다.

한 시간쯤 뒤엔 새 직원 성장 지원을 붙였다. 영웅이나 전설 직원을 처음 도감에 올리면 그 직원을 키울 재료를 4,900원에 72시간 동안 제안한다. 산 직원이나 시작 직원, 보스는 해당이 안 되고, 제안 사이 간격은 최소 7일이다. 핫딜 자리는 두 개뿐이라 진행 구간 상품과 해금 지원이 먼저고, 빈자리가 있을 때만 들어간다. 이미 보여 준 핫딜을 밀어내지는 않는다. 같은 날 오후엔 로비 상점 입구에 새 상품 수를 알려 주는 배지도 도트로 그려 넣었다.

iOS 쪽 구매 검증은 15일 밤에 만들어 꺼 둔 채로 두고, 16일 오전 App Store Connect에 앱을 등록하면서 켰다.

확률형 아이템 확률 공개

14일 오후엔 채용 확률 표시를 법 기준에 맞췄다. 2024년 3월부터 확률형 아이템은 게임 안, 홈페이지, 광고물에 확률을 표시해야 한다. 채용은 마정석 말고 골드로도 하는데, 상점 상품에 골드가 들어 있으니 표시 대상이다.

먼저 숫자 표기를 고쳤다. 소수점 셋째 자리까지만 보여 줬더니 전설 직원 한 명의 확률이 0.011%로 뭉개져 있었다. 유효숫자를 네 자리 이상 남기게 바꿨다. 밤엔 시행령 별표 문서랑 게임 안 팝업을 항목별로 대조했다. 튜토리얼 첫 채용이 레어로 고정인 걸 안 적어 놨었고, 10회째 보장 채용(레어 92% / 에픽 7.5% / 전설 0.5%)과 천장 채용이 확률을 어떻게 바꾸는지도 빠져 있었다. 게임 안 팝업과 홈페이지 문서는 같은 코드에서 만들어서 둘이 어긋나지 않게 했다. 그 문서가 지금 홈페이지의 확률 정보 페이지다.

보름을 돌아보면

게임을 만드는 것과 파는 구조를 만드는 건 꽤 다른 일이었다. 상점은 처음 만들 때보다 숫자로 다시 뜯어볼 때 문제가 더 많이 나왔고, 결제는 코드보다 정책을 정하는 데 시간이 더 들었다. 환불되면 뭘 회수하는지, 시계를 누가 재는지, 한 달에 서버비가 얼마까지 나가도 되는지 같은 것들.

다음 편은 이 결제가 들어간 빌드를 Google Play 비공개 테스트와 TestFlight에 올리고 심사를 받기까지의 이야기다. 게임이 궁금하면 게임 소개 페이지에서 먼저 볼 수 있다.