how to plan an office subscription price target

 

개요

Office Add-in(Word/Excel/PowerPoint/Outlook 등)에서 유료 결제/과금제를 구축하려면
크게 보면 **“어디서 결제하고, 어떻게 권한을 확인할 것인가”**를 설계하는 문제입니다.

Office 애드인은 기본적으로 **웹 기술(HTML/JS + 서버 백엔드)**로 동작하므로,
웹/모바일 서비스에서 쓰는 대부분의 과금 모델을 동일하게 적용할 수 있습니다.

아래에서 대표적인 시나리오와 구현 방법을 정리하겠습니다.

1. 결제·과금 방식의 큰 분류

1) 사용량 기반 vs 기간(구독) 기반

  1. 기간 기반(Subscription)

    • 월/년 단위 구독(예: Pro 플랜 9.9$/월)
    • 기업용: 좌석 수(사용자 수)에 따른 요금제
    • 장점: 구현이 단순, SaaS 표준 패턴, 예측 가능한 매출
    • 단점: 실제 사용량과 무관하게 비용이 나간다는 인식

  2. 사용량 기반(Pay-as-you-go)

    • 예: “문서 분석 1,000건까지 무료, 이후 건당 n원”
    • API 호출 수, 페이지 수, 변환 횟수 등을 기준으로 측정
    • 장점: 사용량과 요금이 직관적으로 연결
    • 단점: 사용량 집계/과금 로직/대시보드 구현이 복잡

  3. 혼합형

    • “월 기본 요금 + 초과 사용량에 대한 사용량 과금”
    • 예: 월 10,000건까지 포함 + 초과분 1,000건당 n원

2) 라이선스 단위

  • 사용자 단위(User-based): 특정 Microsoft 계정/회사 계정 단위
  • 조직/테넌트 단위(Tenant-based): 테넌트 전체 라이선스 후, 내부에서 사용자 수 제한
  • 디바이스 단위 (요즘은 드묾): PC 1대 기준

Office Add-in 특성상 “사용자(계정)” 단위가 가장 자연스럽고,
기업 고객 타깃이면 테넌트 + 좌석 수 방식도 고려할 수 있습니다.

2. 결제 채널 선택: MS 마켓플레이스 vs 자체 결제

1) Microsoft AppSource / Microsoft 365 관리 센터를 통한 과금

Office Add-in을 AppSource에 올리고,
“라이선스/구독 상품”을 Microsoft 상점에서 판매하는 방식입니다.

  • 장점
    • Microsoft 계정/조직 계정으로 결제·청구
    • 기업 고객의 구매/배포 플로우와 잘 맞음
    • 신뢰도, 구매 장벽↓
  • 단점
    • 수수료, 정책(환불, 국가 제한 등)에 따라 제약
    • 결제 플로우/라인업이 MS 플랫폼에 종속
    • 셀프 빌링(송장 커스터마이즈 등)이 어렵거나 제한적

구현 개념:

  • AppSource 상에 Offer(플랜)를 정의 (무료, Trial, 유료)
  • 고객이 AppSource/관리 센터에서 구독 → 구독/좌석 정보가 라이선스 API 또는 백엔드에서 조회 가능
  • Add-in은 로그인한 사용자와 조직 정보를 기반으로 “구독 상태 조회 → 기능 잠금/해제”

이 경로는 대기업/엔터프라이즈 고객을 주요 타깃으로 할 때 특히 유리합니다.

2) 자체 결제 시스템(Stripe, PayPal, 국내 PG 등) 연동

Add-in UI 안에서 웹 기반 결제 페이지로 유도해
Stripe/PayPal/국내 PG(토스페이먼츠, KG이니시스 등)를 직접 연동하는 방법입니다.

  • 장점
    • 결제 UI/플랜/프로모션을 완전 자율적으로 설계 가능
    • 수수료·정책을 어느 정도 스스로 최적화
    • 기존 웹/모바일 서비스 Billing을 재사용 가능
  • 단점
    • 결제/정산/환불/세금/보안/규제(특히 국내 전자결제 관련) 모두 직접 책임
    • Office 승인 심사 시, 결제 관련 UX/정책을 잘 설명해야 함

구현 개념:

  1. Add-in에서 사용자 로그인 (자체 계정 or OAuth)
  2. 백엔드는 사용자 계정/테넌트 기준으로 Billing 상태·플랜 정보 관리
  3. “업그레이드/결제” 버튼 클릭 시 → 내부 웹 결제 페이지(Stripe Checkout, PG 결제창 등)로 이동
  4. 결제 성공 후 → 백엔드 DB에 구독/플랜 업데이트
  5. Add-in 실행 시마다 백엔드에 플랜·사용량 조회 → 기능 잠금/해제

3. Office Add-in 내부에서의 과금 로직 구성

1) 인증/식별

과금제의 핵심은 “누굴 기준으로 청구할 것인가?”입니다.

  • 일반적으로:
    • 사용자의 Microsoft 계정(AAD 계정) 또는
    • 자체 서비스 계정 (이메일/회사명)
      을 기준으로 식별합니다.

구현 흐름 예:

  1. Office.js로 사용자 계정 정보 획득 (예: Office.context.mailbox.userProfile등, 호스트에 따라 다름)
  2. 또는, OAuth2/OpenID Connect로 사용자를 로그인시켜 자체 계정/테넌트 ID 확보
  3. 이 ID를 백엔드에 전달 → Billing DB와 매핑

2) 플랜·권한 체크

Add-in 시작마다(또는 일정 주기):

  1. 백엔드 API: /billing/status?userId=xxx&tenantId=yyy
  2. 서버에서 아래 정보 반환:
    • planType (free, pro, enterprise 등)
    • expiresAt (구독 만료일)
    • usage (이번 달/이번 기간 사용량)
    • limits (이번 플랜에서 허용되는 최대량)
  3. 프론트(애드인)에서:
    • 무료 사용량 초과 시 업그레이드 모달/배너
    • 기간 만료 시 일부/전체 기능 잠금, 재결제 유도

3) 사용량(Usage) 집계

사용량 기반 과금을 한다면:

  • 클라이언트가 수행하는 핵심 액션마다 백엔드에 로그:
    • 예: /usage/record (문서 분석 1회, 페이지 변환 10페이지 등)
  • 서버에서:
    • 테이블: Usage(userId, tenantId, actionType, amount, timestamp)
    • Billing 주기(월/년)별 Aggregation → 요금 계산
  • 최적화:
    • 모든 호출을 실시간 전송하면 느려질 수 있으니
    • “버퍼링 후 배치 전송” or “주요 액션만 기록” 전략 사용

4. 대표적인 과금 모델 설계 예시

모델 A: Freemium + 구독(가장 무난)

  • Free 플랜
    • 하루 5회 분석/변환
    • 기능 제한(예: 기본 템플릿만)
  • Pro 플랜 (월/년 구독)
    • 무제한 or 넉넉한 사용량
    • 고급 기능(예: AI 분석, 팀 공유)
  • Enterprise 플랜
    • 테넌트 단위 사용자 수 제한 + 전용 기능
    • 별도 영업/견적

구현 포인트:

  • 무료 플랜에서도 “가치를 어느 정도 주되, 확실히 차별화된 Pro 기능 제공”
  • 업그레이드 버튼은 Add-in UI 곳곳에 자연스럽게 배치(배너, 제한 도달 팝업 등)

모델 B: 사용량 기반 + 최소 기본요금

  • 기본 요금: 월 N원 (소량 사용 포함)
  • 초과 사용: 1,000건당 n원
  • 기업 고객: 일정량 이상이면 별도 할인/약정

구현 포인트:

  • 사용량 대시보드 제공 (Add-in 내부 또는 웹 포털)
  • “예상 요금 시뮬레이션” 제공 → 불안감 감소
  • 요금 상한선(캡) 옵션 제공 시 안심감↑

모델 C: 기업용 좌석 라이선스

  • 테넌트 단위로 “10 seats, 50 seats” 등 판매
  • 각 좌석은 특정 사용자 계정에 할당
  • Add-in은 로그인한 사용자가 좌석이 할당된 사용자 ID인지를 체크

구현 포인트:

  • 관리자 포털(웹)에서 라이선스 할당/회수 UI
  • AAD/테넌트 ID 활용 시 온보딩 편리

5. 기술 스택/아키텍처 관점

1) 프론트엔드(Office Add-in)

  • TypeScript/JavaScript + Office.js
  • React/Vue/Angular 등 SPA 형태로 구현 가능
  • 주요 기능:
    • 사용자 인증 (MS 계정 or 자체 계정)
    • 백엔드 Billing API 연동
    • 사용량 전송 / 플랜 상태 표시
    • 결제 페이지로 리다이렉트(또는 내부 iFrame/팝업)

2) 백엔드

  • 아무 언어/프레임워크 (Node, .NET, Python, Go 등)
  • 필요 모듈:
    • User/Tenant 관리
    • Billing(플랜/구독/결제 이력/사용량) DB
    • 결제 게이트웨이 연동 모듈(Stripe/PG SDK)
    • Webhook 처리 (결제 성공/실패/구독 갱신 등)
    • 라이선스 검증 API

데이터 모델 예시(간략):

  • Users(id, email, tenantId, msUserId, createdAt, ...)
  • Tenants(id, domain, msTenantId, planId, seats, ...)
  • Plans(id, name, type, price, billingCycle, limitsJson, ...)
  • Subscriptions(id, userId/tenantId, planId, status, startAt, endAt, ...)
  • Usage(id, userId, tenantId, actionType, amount, timestamp)

6. 나라별/플랫폼별 이슈

  1. 국가별 결제 규제
    • 한국에서 국내 결제수단을 쓰려면 전자금융/PG 계약, 세금계산서, 현금영수증 등 고려 필요
  2. 환율·과세(VAT 등)
    • 글로벌 판매 시 각국 VAT 규정 고려(특히 EU, 영국 등)
    • Stripe Tax 또는 외부 세금 계산 솔루션 활용 가능
  3. 엔터프라이즈 고객 보안/데이터 위치
    • 데이터가 어느 리전에 저장되는지
    • SOC2/ISO 등 보안 인증 요구 가능
    • 과금보다는 계약/보안 쪽 이슈지만, B2B 세일즈에서 자주 나옴

7. 단계별 로드맵 제안

  1. MVP 단계

    • 자체 결제(Stripe 등) + 가장 단순한 구독형(Freemium + Pro 1종)
    • 사용자 단위 라이선스만 지원
    • 사용량 집계는 대략적인 수준으로 시작

  2. 성장 단계

    • 기업용 테넌트/좌석 모델 추가
    • AppSource를 통한 판매/배포 채널 확대
    • 사용량 기반/하이브리드 플랜 실험

  3. 고도화 단계

    • 관리자 포털 + 상세 사용량 대시보드
    • 국가별 가격/통화, 세금 자동 처리
    • 프로모션 코드, 쿠폰, 리셀러 플로우 등 추가

8. 실무적으로 “어떻게 시작할지” 정리

  1. 먼저 결정할 것

    • 타깃: 개인 중심 vs 기업 중심?
    • 과금 기준: 기간(구독) vs 사용량 vs 혼합?
    • 결제 채널: AppSource vs 자체 결제(Stripe/PG) vs 둘 다?

  2. 그 다음 구현 순서

    1. 사용자/테넌트 식별 로직 설계 (Microsoft 계정 매핑 여부 포함)
    2. 무료/유료 플랜 정의 (기능 차이, 사용량 제한 등)
    3. 백엔드 Billing DB 스키마 설계 및 API 작성
    4. Add-in에서 Billing API 연동 + 플랜에 따라 기능 잠금/해제
    5. 결제 연동(Stripe/PG or AppSource Offer) 및 테스트
    6. 로깅/모니터링(에러, 사용량, 결제 실패) 구축

댓글

댓글 쓰기