무료로 나가 있던 앱 네 개에 하루 만에 수익화를 붙였습니다. 앱마다 "이건 유료로 팔자"는 항목을 먼저 정하고 페이월을 설계했습니다.
네 앱 전부, 유료로 팔기로 정한 항목이 이미 무료로 출시돼 있었습니다.
당신이 팔려는 기능은, 지금 라이브 빌드에서 무료로 쓸 수 있습니까?
넷 다 같은 모양이었습니다
- 한 앱은 더 큰 격자 난이도 — 라이브러리 화면 선택기에 이미 들어 있었습니다.
- 한 앱은 그룹별 정답률 통계 — 통계 화면에 그 블록이 이미 있었습니다.
- 한 앱은 간격 반복 복습 — 세션 엔진이 하는 일 자체가 그것이었습니다.
- 한 앱은 저장 경로 여러 개 — 최근 경로 저장이 이미 다섯 개까지 됐습니다.
앱 설명도, 제 기억도, 스펙 문서도 "무엇을 팔 수 있는가"를 알려주지 않습니다. 라이브 코드만 압니다.
그대로 밀었으면 어떻게 됐나
넷 다 쓰던 기능을 빼앗는 변경이 됐습니다.
이건 새 기능을 파는 게 아닙니다. 기존 사용자에게는 다운그레이드로 보입니다. 그리고 평점 표본이 얇은 플릿에서는 별 1개 몇 건이 순위를 흔듭니다.
즉 비용이 "수익 0"이 아니라 **"마이너스"**가 될 수 있는 변경이었습니다. 페이월 설계에서 겉보기와 실체가 갈린 다른 사례는 스크린샷에 페이월이 찍혀 있던 이야기에 있습니다.
당신이라면?
무료 앱에 페이월을 붙여야 합니다. 어느 순서로 하겠습니까?
- 가치가 높은 기능을 정하고 게이트를 설계한다 — 자연스러운 순서. 제가 네 번 한 것.
- 라이브 코드에서 이미 무료인 것을 먼저 세고, 남은 것에서 고른다 — 팔 수 있는 것만 후보가 된다.
- 둘 다 하고 교차한다 — 설계 의도와 실제 상태를 대조한다.
두 번째로 시작해야 합니다. 확인 절차는 이것뿐입니다 — 유료 경계를 확정하기 전에 후보 기능마다 호출부를 grep합니다. 있으면 무료로 남기고, 새로 만들 것을 찾습니다.
그리고 게이트 구조체에는 항상 true인 항목을 일부러 남기고 왜 그런지 주석을 붙였습니다. 나중에 누가(저를 포함해) "이건 왜 무료지"를 물을 때, 그 답이 코드 옆에 있어야 합니다.
자가진단 세 줄
- 유료 후보 기능의 호출부를 grep했습니까? 스펙 문서와 라이브 빌드는 다릅니다. 판정은 코드입니다.
- 그 변경이 기존 사용자에게 다운그레이드로 보입니까? 그렇다면 그건 수익화가 아니라 회수이고, 평점으로 대가를 치릅니다.
- 게이트에서 "항상 무료"인 항목의 이유가 코드에 적혀 있습니까? 안 적으면 다음 사람이 그걸 유료 후보로 다시 올립니다.
솔직한 부분
네 번 연속 같은 실수를 했습니다. 첫 앱에서 겪었는데도 두 번째 앱에서 다시 설계를 먼저 하고 코드를 나중에 봤습니다. 세 번째에야 순서를 바꿨습니다.
"이미 있다"를 확인하는 데 든 시간은 앱당 몇 분입니다. 설계를 다시 하는 비용이 훨씬 큽니다. 그런데도 순서를 자꾸 틀렸습니다. 설계가 재미있고 grep은 재미없기 때문이라고 생각합니다.
그리고 유료 경계를 다시 정하면서 각 앱에 새로 만들 것을 찾아야 했습니다. 그건 이 작업의 범위를 늘렸습니다. "붙이기만 하면 되는 일"이 아니었습니다.