- Patreon에는 의미 있는 경쟁자가 없으며, 동시에 불편한 점도 많아 시장을 빼앗을 큰 기회가 존재하지만, 그러려면 창작자가 수익의 5%(추가로 결제 처리 수수료 5%)를 내면서까지 사용하는 이유를 이해해야 함
- 창작자가 실명이 아닌 가명(stage name·pen name) 으로 활동하고, 플랫폼은 법적으로 보유해야 하는 실명·세금 ID를 비밀로 유지하는 기능이 가장 기본적인 전제 조건
- 월 구독 외에 작업 단위(by-works) 펀딩 모델을 지원하는 점이 핵심 차별점이며, 후원자는 작업물 1건당 금액을 약정하고 창작자는 정해진 일정 없이 결과물을 만들 때마다 청구
- 창작자가 후원자에게 직접 무언가를 파는 것이 아니라 세상에 공개하는 작업(오픈소스, 행동주의, 글쓰기 등)을 후원받는 비대가성(non quid pro quo) 후원 모델도 지원
- 청구 묶음(charge bundling), API 기반 청중 관리, 저사양 하드웨어 접근성 등에서 Patreon의 약점이 커지고 있어, 단순함을 지킨 경쟁자에게 시장을 가져갈 여지가 큼
개요: Patreon이 실제로 하는 일
- Patreon은 음악가이자 뮤직비디오 제작자였던 실제 창작자가 설립·설계해, 창작자가 플랫폼에 진짜 필요로 하는 기능을 이해하고 있었음
- Patreon은 결함이 있지만 후술할 핵심 기능들에서 다른 어떤 결제 수용 플랫폼보다 앞서 있어, 이를 구현하고 개선하지 못하면 경쟁이 불가능함
1) 가명(Pseudonym) 지원
- 무대명·필명은 2,000년 넘게 이어진 예술가 업계의 현실이며, 창작자는 일반 판매원과 다름
- 창작자가 후원자와의 모든 상호작용에서 가명을 사용할 수 있어야 하고, 플랫폼은 법적으로 알아야 하는 창작자의 실명·세금 ID(미국의 경우 SSN)를 기밀로 보관해야 함
- 가명을 단지 지원하는 데 그치지 않고, 창작자에게 사전에 명확히 약속해야 하며 이상적으로는 신규 창작자 유치 설명에 포함되어야 함
- 실명 노출만 감수한다면 그동안 PayPal 구독을 써도 됐을 것이므로, 실명을 기밀로 다루지 않는 플랫폼은 Patreon의 사업을 빼앗을 수 없음
2) 작업 단위(By-works) 펀딩 모델 지원
- Patreon의 두 가지 기반 모델 중 하나는 월 구독으로 단순하지만, 다른 하나인 작업 단위 모델이 진짜 차별점
- 후원자는 월 단위가 아니라 창작자가 만드는 결과물 1건당 금액을 약정하며(스토리당, 뮤직비디오당 등), 창작자는 한 달에 0건·1건·10건·100건 등 어떤 수량이든 가능함
- 작성자의 최고 기록은 한 달 10건
- 후원자가 예상보다 많은 청구를 받지 않도록, 월 상한선(monthly upper limit) 설정이 가능하며 초과분은 청구되지 않음
- 시스템은 창작자가 무언가를 실제로 배송했는지 검증하지 않음
- 창작자가 Patreon에 로그인해 "결과물을 만들었다"는 짧은 글을 올리고 "결제 요청" 체크박스를 켜 제출하면 끝
- 실제 배송 여부는 창작자와 후원자 사이의 문제이며, 작성자 본인은 결제 대상물 전달을 Patreon이 아닌 별도 채널로 처리
- 본질적으로 후원자의 신용카드에 연결된 "결제 요청" 버튼에 가깝고, 창작자가 버튼을 남발하는 것을 막는 장치는 없음
- 다만 남발하면 후원자가 분노해 후원을 취소하므로 이것만으로 충분함
- PayPal로 조경 작업 인보이스를 보내도 PayPal이 실제 작업 수행 여부를 확인하지 않는 것과 동일한 원리
- 작성자가 아는 한 이 모델을 지원하는 플랫폼은 Patreon 외 단 한 곳, Tipeee.com뿐이며 수수료가 5%가 아닌 8%이고 개인 서류 요구가 매우 침습적임
- 작업 단위 모델의 핵심 구조
- 후원자가 작업 1건당 $n을 작업 완료 전에 지속적으로 약정
- 창작자가 정해진 일정 없이 임시로(ad hoc) 작업물을 생성하고 그때마다 UI에서 후원자에게 청구
- 플랫폼이 청구를 모아 월 단위로 후원자 신용카드에 제출
3) 비대가성(Non quid pro quo) 후원
- Patreon은 물건을 파는 플랫폼으로 쓸 수도 있지만, 돈을 낸 사람에게 직접 무언가를 주지 않는 후원 수집에도 사용 가능
- 오픈소스 기여자, 활동가, 저널리스트, 블로거 등이 후원자에게 물건을 주는 것이 아니라 세상에 무언가를 내놓기 위해(누구나 쓸 코드 공개, 세상을 바꾸는 활동, 누구나 읽을 글 작성) 후원받음
- 작성자가 9년 전 Patreon에 가입한 가장 큰 이유는, 글을 판매(돈 낸 사람에게만 제공) 하지 않고 인터넷에 공개해 누구나 읽고 인용할 수 있게 하면서 자금을 마련하는 유일한 방법이었기 때문
- 저작권 도용 우려가 아니라, 글을 PDF·책·잡지로 만들어 팔면 결제한 사람만 볼 수 있게 되는 판매의 본질 자체가 작성자가 원하는 바와 정반대임
- 다수의 잠재 경쟁자는 Patreon을 일종의 DRM 시스템으로 오해하지만, 회원제를 문서 판매와 결합하면 마찰이 생겨 수익이 줄어들 가능성이 큼
4) 청중 관계 관리(Audience Relationship Management) 시스템과 API
- 작성자가 "고객 관계 관리(CRM)"에 빗대 만든 용어로, 창작자는 후원자와 그들의 결제를 추적하고 소통할 수 있어야 하며 약정액·수령액·차감 수수료·카드 거절 등 자금 흐름과 분석도 파악해야 함
- Patreon의 관련 인프라가 무너지고 있으며, 일부 기능은 버그를 고치는 대신 그냥 내려버림
-
Patreon API 문제
- Patreon은 창작자가 특정 약정 금액을 티어(tier) 패키지에 연결할 수 있게 하고, 외부 소프트웨어가 사용자의 후원 여부와 티어를 실시간 조회하는 API를 제공했음
- 예: 창작자가 후원자 전용 토론 포럼을 운영할 때, 로그인 시 이메일을 Patreon에 대조해 입장 허용 여부와 티어별 기능 접근을 결정하도록 구현 가능했음
- 일부 창작자는 전체 비즈니스 모델을 이 API에 의존했고, API에 맞춰 제품을 만들어 창작자에게 판매하던 서드파티 통합 업체도 존재했음
- Patreon은 한때 API를 끌 것처럼 보였다가 입장을 번복해, 끄지는 않되 더 이상 지원·개발하지 않겠다고 발표함
- 결과적으로 이들은 Patreon을 후원자의 신원뿐 아니라 후원자 지위까지 제공하는 신원 서버(identity server) 로 사용 중이며, 이를 지원하지 않는 경쟁자는 창작자를 끌어올 수 없음
-
창작자용 UI 약화
- Patreon은 창작자가 자금 상황을 파악하던 핵심 기능, 특히 작업 단위 캠페인 관련 기능을 웹 인터페이스에서 제거함
- 과거 UI에는 작업별로 약정액·실제 수령액·Patreon 수수료·결제 처리사 전달액·창작자 순수익을 한눈에 보여주는 페이지가 있었으나 삭제됨
- 이런 기능을 작업 단위 모델과 함께 제공하면 불만에 찬 Patreon 이탈자들에게 매우 매력적
P.S. 5) 청구 묶음(Charge Bundling)
- Patreon이 빼앗으려다 모든 것을 망가뜨린 뒤에야 사용자들이 가치를 깨달은 숨은 기능
- 2017년 12월, Patreon은 창작자에게 유리한 척했지만 실제로는 다른 변경을 발표함
- 기존: 한 후원자가 여러 창작자를 후원하면 그 달 총액을 한 번의 청구로 결제 처리사에 제출
- 변경안: 후원하는 창작자마다 별도 청구(3명 후원 시 월 3회 청구)
- 결제 처리 수수료에는 비율 외에 건당 고정 수수료 $0.30이 있고, Patreon의 평균 약정액은 $2 미만이라는 점이 문제
- 기존: $1씩 3명 후원 시 총 39센트 차감 → 창작자들이 $2.61을 3등분
- 변경 후: 총 99센트 차감 → 창작자들이 $2.01을 3등분
- 즉 결제 수수료율이 13%에서 33%로 상승
- 게다가 Patreon은 수수료를 약정액에서 차감하던 방식을 약정액에 추가하는 방식으로 바꾸려 함
- $1 약정 시 카드 청구액이 $1.33(약정 $1 + 2.9%(3센트) + 고정 30센트)
- Patreon 자체 수수료 5%(5센트)까지 포함하면 $1.38
- 인터넷의 거센 반발로 Patreon은 일시적으로 물러섰고, 기존 창작자는 묶음 결제를 유지하도록 유예(grandfather) 했으나, 일정 기준일 이후 신규 계정은 묶음 없는 방식으로 작동
마이크로페이먼트와 롱테일(Long Tail)
- 묶음 없이는 숫자가 맞지 않으며, Patreon의 폭발적 성공 비결은 인터넷의 가장 어려운 난제 중 하나인 마이크로페이먼트(micropayments) 해결에 있었음
- 소액 거래는 결제 처리 수수료가 거래액 대비 큰 비중을 차지해 비경제적이었으나, Patreon은 자체 5% + 결제 처리 약 5% 가격대로 소액 후원을 가능하게 함
- 작성자 계산상 5% 수수료가 결제 처리 비용을 실제로 충당하는 시점은 약정액 $14.29 이상("Fourteen Twenty-Nine Hypothesis")
- 특별 할인 없이 5%를 유지했다면 $14.29 미만 약정에서는 손실
- 가설 1: PayPal이 제공한 고정 5센트 + 5% 비율 대체 수수료 구조 사용
- 가설 2: 고액 약정 수수료로 소액 약정 처리 비용을 보전
- 묶음 결제가 이를 가능하게 했음
- 한 후원자가 창작자 15명을 각 $1씩 후원하면 $0.30 고정 수수료가 한 번만 부과되어, 창작자당 수수료가 $0.05 수준으로 낮아짐
- Patreon은 본질적으로 롱테일(long tail) 사업으로, 수백만 개의 서로 다른 것을 $1씩 판매하는 구조이며, 롱테일의 문제는 여전히 마이크로페이먼트의 거래 비용 마찰
- 롱테일 용어는 Chris Anderson이 2004년 Wired에서 대중화했으나, 그가 처음 만든 것은 아니라는 정정 표기가 있음
- Amazon이 무료 배송으로 일정 금액 이상 주문을 유도하는 것도 롱테일 거래를 배치(batch)하기 위함
- 한 후원자가 여러 창작자를 한 곳에서 찾아 후원할 수 있는 후원 마켓플레이스라는 점이 묶음 결제를 가능하게 한 Patreon의 큰 강점이었으나, 현재는 신규 캠페인에서 묶음을 더 이상 적용하지 않는 것으로 보임
복잡성과 신기능 집착(Neophilia)
- 두 가지 펀딩 모델, 연간 멤버십, 월초·월말 결제, 약정 변경 시점 추적, 굿즈 결제, 캠페인 연령에 따른 두 가지 결제 처리 방식 등으로 Patreon의 내부 회계 로직은 극도로 복잡함
- 작성자는 Patreon이 기술적으로 감당하기 어려운 수준을 떠안았다고 보며, 신용카드 청구 관리와 자금 현황 UI 제공 모두에서 어려움을 겪는 점이 핵심 회계 시스템이 브레이크 없는 기차 같은 상태임을 시사한다고 봄
- 한편으로 복잡성을 줄이려 하면서 다른 한편으로 사명에 필수적이지 않은 새 기능을 계속 출시하는 모습은 조직이 신기능 집착(neophilia) 을 앓고 있음을 보여줌
- 경쟁자가 Patreon을 이길 핵심 방법은 단순함을 지키는 KISS(Keep It Simple, Stupid) 원칙
-
기술 스택과 접근성 문제
- Patreon은 대부분 정적 페이지에 가까운 UI를 고도로 추상적인 DHTML/Ajax(자바스크립트 프레임워크 추정)로 구현해 세 가지 나쁜 결과를 낳음
- 디버깅 불가(Undebuggable): 클라이언트 측 구조가 지나치게 추상적이어서 버그 발생 시 수정이 어려웠고, 이는 불필요했음
- 접근성 결여(Inaccessible): 과도한 자바스크립트로 스크린 리더 사용자가 이용하기 어려워 ADA 소송 위기에 몰렸고, 2020년에야 미국시각장애인협의회(American Council of the Blind)와 합의해 개선하기로 함
- 계층 차별적(Classist): 자바스크립트는 브라우저에서 프로세서 부하가 커 구형 컴퓨터에서 느리고 열기 어려운데, 정작 Patreon이 끌어들이려는 가난한 창작자 다수가 구형 컴퓨터를 사용
- 작성자는 2015년경 화상 통화 기반 마케팅 연구 참여 제안을 받았을 때, 가난한 창작자 다수는 화상 통화가 가능한 플랫폼조차 없다는 점을 지적함
경쟁자를 위한 조언
- 사용자 기반에 대해 어리석게 굴지 말고, 가난한 예술가를 위한 플랫폼이라면 저사양 하드웨어와 장애인 접근성을 확보해야 함
- 불필요한 코드 계층을 줄여 디버깅 시 기술 부채에 짓눌리지 않도록 해야 함
- 펀딩 모델과 사이트에 새 기능·장식을 추가하기 전에 신중해야 하며, 기본 모델 지원만으로도 충분히 어려우므로 새로움을 좇아 스스로를 힘들게 하지 말 것
- 화려하지만 불안정한 것과 신뢰할 수 있지만 지루한 것 중에서는 신뢰할 수 있지만 지루한 쪽을 택해야 하며, 금융 UI에서 견고함(stolid)은 충분히 수용 가능한 미적 가치
- UI에 전문적 주의를 기울이면 Patreon보다 앞설 수 있으며, 기능 명칭을 실제 그대로 짓고 내비게이션을 잘 정리해야 함