이 글은 누구를 위한 것인가
- 무료로 시작하는 서비스에 유료 요금제를 붙이려는 팀
- 가격 페이지는 만들었는데 전환이 거의 없는 경우
- 무료 한도를 어디에 그을지 근거 없이 정하고 있는 상황
들어가며
무료 서비스에 유료 요금제를 얹는 일은 가격표를 만드는 게 아니라 "무엇을 무료로 줄 것인가"를 정하는 일이다. 그리고 이 결정이 잘못되면 가격 페이지를 아무리 다듬어도 전환이 나오지 않는다.
[잘못 그은 경계의 두 유형]
너무 관대 무료로 다 되니까 결제할 이유가 없음
→ 전환율 0.1% 미만
너무 인색 가치를 경험하기 전에 막힘
→ 가입 후 이탈. 애초에 유료 후보가 안 생김
둘 사이의 지점을 찾는 방법이 이 글의 주제다.
1. 무료와 유료를 나누는 축
경계를 긋는 방식은 몇 가지로 정리된다.
[A] 사용량 무료 3개까지, 유료 무제한
적합: 만들수록 가치가 커지는 도구
주의: 3개를 다 만들기 전에 이탈하면 전환 기회가 없음
[B] 기능 고급 기능은 유료
적합: 전문 사용자와 일반 사용자가 뚜렷이 갈릴 때
주의: 무료가 "체험판"처럼 느껴지면 인상이 나빠짐
[C] 협업 인원 혼자는 무료, 팀은 유료
적합: 조직이 쓰기 시작하면 결제 주체가 생기는 제품
주의: 개인 사용자는 영원히 무료 — 그래도 괜찮은가
[D] 브랜딩·용량 워터마크 제거, 저장 공간
적합: 결과물이 외부에 노출되는 제품
주의: 무료 사용자의 결과물이 곧 마케팅이라는 점과 상충
대부분의 서비스가 A와 D를 섞는다. "무료로 페이지 3개, 유료는 무제한 + 자체 도메인 + 브랜딩 제거" 같은 형태다.
핵심 원칙은 하나다.
가치를 충분히 경험한 뒤에 한도에 닿아야 한다
✗ 첫 페이지를 만들다가 막힘 → 제품을 이해하기 전에 이탈
✓ 세 번째 페이지를 만들려다 막힘 → 이미 유용하다는 걸 앎
무료 한도를 정하는 실용적인 방법은 기존 사용자 행동 분포를 보는 것이다.
-- 활성 사용자의 페이지 생성 개수 분포
SELECT pages, count(*) AS users
FROM (
SELECT user_id, count(*) AS pages
FROM pages WHERE deleted_at IS NULL
GROUP BY user_id
) t
GROUP BY pages ORDER BY pages;
[해석]
중앙값이 2개라면 무료 한도 3개는 대부분에게 도달하지 않는 벽
→ 전환 기회 자체가 안 생김
상위 20%가 5개 이상 만든다면 한도 3개가 그들에게만 작동
→ 이들이 유료 후보. 나머지는 무료로 두는 게 맞음
**"모두를 전환시키려 하지 않는 것"**이 중요하다. 무료 사용자는 비용이 아니라 유입 경로다.
2. 한도에 닿는 순간이 전환의 전부다
가격 페이지를 보고 결제하는 사용자는 드물다. 대부분의 전환은 막히는 순간에 일어난다.
❌ 한도 도달 처리 — 나쁜 예
"무료 플랜의 한도를 초과했습니다."
[요금제 보기]
→ 방금 만들던 것이 사라짐
→ 왜 이 한도인지 모름
→ 가격 페이지로 던져짐 (맥락 상실)
✅ 좋은 예
페이지 3개를 모두 사용 중이에요
지금 만들던 내용은 저장해 뒀습니다.
업그레이드하면 바로 이어서 만들 수 있어요.
┌─────────────────────────────┐
│ 프로 · 월 4,900원 │
│ · 페이지 무제한 │
│ · 자체 주소 연결 │
│ [업그레이드하고 계속하기] │
└─────────────────────────────┘
또는 기존 페이지 정리하기 · 나중에 하기
네 가지가 들어 있다.
1. 작업 내용 보존 "저장해 뒀습니다" — 손실 공포 제거
2. 즉시 재개 약속 "바로 이어서" — 결제 후 흐름이 끊기지 않음
3. 관련 혜택만 표시 전체 요금표가 아니라 지금 필요한 것
4. 대안 제공 정리하기 / 나중에 — 막다른 길이 아님
1번이 가장 중요하다. 만들던 게 날아갈까 봐 서둘러 결제하게 만드는 것은 단기 전환에는 유리하지만 환불과 불신으로 돌아온다. 보존을 약속하고 그 약속을 지키는 편이 낫다.
결제 직후 원래 작업으로 복귀하는 것도 반드시 구현해야 한다.
결제 화면 자체는 직접 만들기보다 Checkout 같은 호스팅 결제 페이지를 쓰는 편이 카드 정보 취급 범위를 줄여준다.
// 업그레이드 진입 시 복귀 지점을 기록
const checkoutUrl = buildCheckout({
plan: 'pro',
returnTo: `/editor/${draftId}`, // ★ 결제 후 여기로
trigger: 'limit_pages', // 어떤 한도에서 왔는지 (분석용)
});
trigger를 남기면 어느 한도가 실제로 전환을 만드는지 측정할 수 있다. 이게 없으면 다음 요금제 개편이 감으로 이뤄진다.
3. 요금제 구조 — 몇 개를 둘 것인가
[플랜 개수]
2개 (무료 + 유료)
· 결정이 단순. 초기에 적합
· 고액 지불 의사가 있는 사용자를 놓침
3개 (무료 + 개인 + 팀)
· 가장 흔한 구성
· 중간 플랜이 기준점 역할
4개 이상
· 선택 마비. 비교표가 길어짐
· 엔터프라이즈는 "문의하기"로 빼는 게 낫다
3개를 넘기지 않는 것이 대체로 안전하다. 플랜이 늘수록 사용자가 비교에 쓰는 시간이 늘고, 그 시간에 이탈이 일어난다.
연간 결제 할인은 거의 항상 넣을 가치가 있다.
월간 4,900원
연간 49,000원 (2개월 무료) ← 기본 선택
· 현금 흐름 개선
· 해지율 감소
· 표시는 "월 4,083원 (연간 결제 시)"로 월 단위 환산
월 환산 금액을 크게 보여주는 것이 심리적 저항을 낮춘다. 다만 실제 청구 금액을 작게라도 반드시 병기해야 한다 — 이걸 숨기면 결제 후 항의로 돌아온다.
구독 상태 전이(체험 → 활성 → 연체 → 해지)의 표준적인 모델은 구독 결제 문서를 참고해 설계하면 빠뜨리는 상태가 줄어든다.
4. 가격 페이지 구성
가격 페이지는 설득하는 곳이 아니라 확인하는 곳이다. 이미 관심 있는 사용자가 조건을 확인하러 온다.
[구성 순서]
1. 플랜 카드 (3개 이내, 추천 플랜 강조)
2. 기능 비교표 (접어두고 "자세히 비교" 로 펼치기)
3. 자주 묻는 질문 (결제·해지·환불)
4. 문의 경로
2번을 처음부터 펼쳐두면 화면이 표로 시작해 부담스럽다. 대부분의 사용자는 카드 3개만 보고 결정한다 — 점진적 공개 원칙의 전형적인 적용 대상이다.
[플랜 카드에 들어갈 것]
· 플랜 이름
· 가격 (월 환산 + 실제 청구액)
· 이 플랜을 고르는 이유 한 줄
"혼자 쓰기에 충분해요" / "팀으로 함께 만들 때"
· 핵심 혜택 3~5개 (전부 나열하지 않기)
· CTA 버튼
✗ 기능 15개를 체크 리스트로
✗ "가장 인기" 배지를 근거 없이
**"이 플랜을 고르는 이유 한 줄"**이 비교표보다 효과적이다. 사용자는 기능 목록을 대조하는 게 아니라 "나는 어느 쪽에 해당하나"를 알고 싶어 한다.
무료로 시작하는 제품의 가격 페이지가 어떤 톤이어야 하는지는 실제 사례를 보면 감이 온다. Linkme의 가격 안내는 "필요한 만큼만, 단순한 가격"을 앞세우는데, 무료로 시작하는 제품에서 가격 페이지의 첫 임무는 "돈 내라"가 아니라 "무료로도 충분히 쓸 수 있다"를 확인시키는 것이라는 판단이 읽힌다. 이 순서를 뒤집으면 가입 전 사용자가 가격 페이지에서 이탈한다.
5. 결제 전 마지막 화면
[반드시 명시할 것]
□ 오늘 청구되는 금액 (0원이면 0원이라고)
□ 다음 청구일과 금액
□ 자동 갱신 여부
□ 해지 방법과 해지 시점의 처리
"언제든 해지할 수 있고, 남은 기간은 계속 사용됩니다"
□ 환불 정책 링크
"해지 방법"을 결제 전에 보여주는 것이 역설적으로 전환을 올린다. 빠져나올 수 없을 것 같은 느낌이 가장 큰 결제 저항 요인이기 때문이다.
[체험 기간을 둔다면]
· 카드 등록을 요구할 것인가
요구 → 전환율 높지만 체험 시작률 낮음
미요구 → 체험 시작 많지만 전환율 낮음
· 종료 3일 전 알림은 필수
없으면 "몰랐다"는 환불 요청이 대부분
체험 기간의 상태 전이(trialing → active / canceled)와 종료 직전 웹훅은 체험 구독 문서에 정리된 모델을 참고하면 처리해야 할 분기를 빠뜨리지 않는다.
체험 종료 알림을 보내지 않는 것은 단기 매출에 유리하지만 환불·분쟁·평판 비용으로 되돌아온다. 알림을 보내고도 유지되는 구독이 진짜 전환이다.
6. 해지 흐름 — 막지 말고 이유를 받는다
해지를 어렵게 만드는 것은 규제 위험이 있을 뿐 아니라 실효도 없다.
[해지 화면 구성]
1. 해지 사유 선택 (선택 사항으로)
○ 생각보다 안 쓰게 됨
○ 가격이 부담됨
○ 필요한 기능이 없음 [무엇인가요?]
○ 다른 서비스로 이동
○ 일시적으로 중단
2. 사유에 맞는 대안 (강요 아님)
"안 쓰게 됨" → 일시정지 옵션
"가격 부담" → 하위 플랜 안내
"기능 부족" → 로드맵 안내 + 알림 신청
3. 해지 확정
"OO일까지는 계속 사용할 수 있어요"
2번을 한 번만 제시하고 넘어가는 것이 원칙이다. 여러 단계로 붙잡으면 해지는 결국 이뤄지고 인상만 나빠진다.
해지 사유 데이터가 요금제 개편의 근거가 된다. "가격 부담"이 다수라면 하위 플랜이 필요하고, "기능 부족"이 다수라면 가격이 아니라 제품 문제다.
7. 측정 — 전환율 하나로는 부족하다
[퍼널]
가입 → 첫 가치 경험 → 한도 도달 → 가격 확인 → 결제
(activation) (trigger) (view) (convert)
각 단계 전환율을 따로 본다
각 단계를 이벤트로 남길 때는 GA4 이커머스 규격의 begin_checkout·purchase 같은 표준 이벤트명을 쓰면 기본 리포트가 그대로 살아난다. 어느 단계가 병목인지 모르면 엉뚱한 곳을 고친다.
한도 도달률이 낮다 → 무료 한도가 너무 관대하거나,
사용자가 그 전에 이탈
한도 → 가격 확인이 낮다 → 한도 안내 화면의 문제
가격 확인 → 결제가 낮다 → 가격 또는 플랜 구조의 문제
[함께 볼 지표]
· 한도 유형별 전환율 어느 한도가 실제로 작동하는가
· 결제 후 7일 이탈률 전환을 서두르게 만들었는가
· 환불 요청률과 사유
· 체험 → 유료 전환율
· 해지 사유 분포
**"한도 유형별 전환율"**이 요금제 설계의 직접적 근거다. 페이지 수 한도에서는 전환이 나오는데 저장 용량 한도에서는 안 나온다면, 후자는 한도를 풀고 전자를 조정하는 것이 맞다.
8. 정리
1. 무료/유료 경계는 사용량·기능·인원·브랜딩 중 무엇으로 나눌지 먼저
2. 무료 한도는 행동 분포를 보고 정한다 (중앙값 위, 상위 20%가 닿는 지점)
3. 전환은 가격 페이지가 아니라 한도 도달 순간에 일어난다
4. 한도 안내에 작업 보존·즉시 재개·관련 혜택·대안을 함께
5. trigger를 기록해 어느 한도가 전환을 만드는지 측정
6. 플랜은 3개 이내, 연간 할인은 월 환산으로 표시하되 실청구액 병기
7. 해지 방법을 결제 전에 명시 (전환이 오히려 오른다)
8. 해지는 막지 말고 사유를 받는다 — 요금제 개편의 근거
가장 효과가 큰 건 3번과 4번이다. 가격 페이지를 다듬는 것보다, 사용자가 실제로 막히는 그 화면 하나를 제대로 만드는 것이 전환에 훨씬 크게 기여한다.