놀랐죠, $1000를 내세요
요약
과도한 과금 체계와 불투명한 비용 고지가 고객 신뢰 및 비즈니스 평판에 미치는 영향을 다룹니다. 서비스 제공자가 과금 시스템을 설계할 때 사용자 경험과 윤리적 책임을 고려해야 함을 강조합니다.
핵심 포인트
- 불투명한 과금 방식은 법적 분쟁과 고객 이탈의 원인이 됨
- 과금 및 계량 시스템 구축은 실제 서비스 개발만큼 복잡한 공학적 과제임
- 사용자 신뢰를 얻기 위해서는 명확한 사용량 제한과 알림이 필수적임
- 부당한 청구 관행은 단기 수익을 줄 수 있으나 장기적 평판을 해침
몇 년 전 처음 인터넷 되는 휴대폰을 샀을 때 통신사가 체험 기간에 300분 무료라고 광고해서 좋다고 생각했음
첫 달에 인터넷 서비스를 297분 썼는데, 알고 보니 그 “분”은 통화에만 해당했고 모바일 인터넷 요금으로 약 12,000달러짜리 연체 청구서를 맞음. MB당 360달러 같은 말도 안 되는 가격이었음
결국 대규모 집단소송에서 통신사가 패소했고, “분” 광고 때문이 아니라 데이터 비용을 아무에게도 제대로 고지하지 않았기 때문이었음. 최종적으로는 300달러쯤 냈던 것 같고, 600달러 합의안을 추심으로 넘긴 뒤 추심업체와 50%에 합의했음
그래서 기본값으로 강한 사용 한도를 두는 것에 꽤 공감함
아주 오래전 당시 여자친구가 어머니와 휴가를 가서 휴대폰에 Roaming Bundle을 추가해 둔 적이 있음
여행 중 통신사에서 전화가 와서 로밍 요금이 1,700파운드 쌓였다고 했고, 상담원은 “걱정하지 말라”며 혹시 모르니 이번 달 자동이체를 막아 두고 청구서가 생성되면 다시 전화하겠다고 했음
몇 주 뒤 최종 금액이 약 2,000파운드라고 확인해 줬고, 내가 “번들이 절반쯤 쓰였을 때와 거의 다 썼을 때 문자 알림이 온다던데 왜 안 왔냐”고 묻자, 이미 통화 녹음을 들어 봤고 실제로 그렇게 안내한 게 맞다고 인정했음
그러면서 원래는 150파운드짜리 다른 번들을 제안했어야 했고, 실제 사용량은 그 데이터의 75% 정도였으며 기존 번들 25파운드까지 감안해 75파운드로 처리하자고 했음. 그래서 아직도 그 통신사 고객으로 남아 있음
그때는 데이터도 분 단위로 계산됐나 봄? kB와 MB 요금만 기억남
와, 카드도 등록하지 않았는데 청구서가 올 거라고는 전혀 예상 못 했음
이것도 결국 “과금과 계량은 어렵고, 실제 서비스보다 더 큰 공학 작업일 수 있다”는 사례로 보임
우리 GitHub Actions가 너무 느려서 오늘 이 서비스를 살펴보고 있었는데, 좋아 보이긴 해도 이런 식이면 대부분의 체험판보다 내가 더 신경 써서 감시해야 해서 시간이 더 들 듯함
보통 이런 서비스는 체험 기간이 끝나면 서비스가 멈추고, 그때 “가치가 있으니 가입”하거나 “가치가 없으니 되돌리기” 중 고르면 됨
그럴듯해 보이고 업무상 명분이 있으면 그냥 청구서를 결제하는 회사가 꽤 있음
이걸 노리는 사기도 있고, 일부 공급업체도 그 점을 이용할 수 있음. 고객의 30%가 그냥 청구서를 내기 시작한다면, 나머지 문의를 처리할 만한 가치가 있음. 평판 손상이 시작되기 전까지는 말임
도메인을 가진 사람이라면 겪었을 법한 간단한 예로, 만료일이 다가오면 도메인 갱신 비용처럼 보이는 “청구서”가 여러 회사에서 옴. 작은 글씨를 읽으면 “영업 제안”이라고 되어 있지만 겉보기엔 청구서와 똑같고, 일부는 그냥 결제함
Depot 창업자임. 부담 없이 써봐도 됨
우리는 시간 기준의 진짜 무료 체험이 있고, 이런 이상한 일을 하지 않음. 예기치 않게 비용이 폭주하지 않도록 사용량 제한도 걸 수 있음
[0] https://depot.dev
여기서 “과금은 어렵다”는 설명과 사용자 신뢰 문제가 겹침
OpenAI도 예전에 과금을 이런 식으로 했음
스타트업은 살아남기 위해 혁신해야 하고, YC는 큰돈이 될 가능성이 있는 스타트업이라면 이런 종류의 “혁신”을 말리지 않는 듯함
Austrian NIC의 사업 관행이 떠오름
보통 도메인은 갱신하지 않으면 만료되지만, 오스트리아에서는 팩스로 명시적으로 취소하지 않으면 다음 해로 자동 갱신하고, 돈을 내지 않으면 추심으로 넘김[1]
적어도 국가 최상위 도메인(ccTLD)에는 “갱신하지 않으면 도메인이 만료되어야 한다”는 규칙이 없음. 그냥 관례일 뿐이고, 관례는 가정을 만들며, 그 가정은 사람을 속이는 데 쓰일 수 있음
일반적으로 사업에는 선불형, 예를 들면 McDonalds 같은 곳과 후불형, 예를 들면 앉아서 먹는 식당 같은 곳이 있음. 관례상 선불인 서비스에 후불 가격 책정을 적용하면 완벽한 사기가 됨
[1] https://www.reddit.com/r/sysadmin/comments/1bnjus/the_austri...
독일 서비스 제공업체라면 놀랍지 않음. 다만 지난 10년 사이 훨씬 나아지긴 했음
실제로 국가가 자기 ccTLD를 관리하는 방식에는 일반 최상위 도메인(gTLD)처럼 미국이 부과한 규칙이 전혀 없음
지금도 그러는 건가, 아니면 예전에 그랬던 건가? 링크한 글은 10년 전 글임
약관에는 Blacksmith Software Inc 서비스를 쓰려면 계정을 만들고, 계정 설정 과정에서 GitHub 계정을 연결하고 조직에 Blacksmith의 GitHub 통합을 설치하며, Stripe로 처리되는 신용카드 같은 유효한 결제수단을 추가해야 한다고 되어 있음
대형 계약의 경우에만 청구서 결제를 요청할 수 있고, 결제 정보를 제공하면 사용료를 신용카드에 청구하는 것을 승인하거나 청구서 기반 계약이면 청구 조건에 따라 제때 결제하는 데 동의한다고 되어 있음
이 사람이 대형 계약을 맺고 청구서 결제를 요청한 게 아니라면 약관 위반이니, 그냥 꺼지라고 해도 됨
한 달에 1,000달러라니, CI에서 대체 뭘 하고 있는 건가?
우리는 Warp build를 쓰고 있고 GitHub보다 50% 저렴한 편인데, 6명이 여러 저장소에서 꽤 빡세게 돌려도 월 150달러 정도임. Rust 빌드까지 하는데, 빌드 시간 면에서는 훨씬 나쁜 사례임
Blacksmith가 더 큰 실행기를 제공하는지는 모르겠지만, 큰 실행기를 쓰고 있다면 그만한 가치가 있는지 확인해야 함. 2배 실행기가 빌드를 2배 빠르게 해 주지는 않음. 나는 목표를 정하고 그에 맞춰 CI 크기를 잡았음
캐싱도 필요함. TypeScript는 코드가 패키지로 분해되어 있다면 Nx로 처리 가능함
예전 직장에서는 실행 후 시간 측정 작업을 두었고, GitHub Markdown이 Mermaid를 지원해서 Gantt 차트로 표현했음. GitHub API가 현재 워크플로의 시간을 가져올 수 있는지는 기억나지 않아 두 번째 워크플로였을 수도 있음
첫 번째는 약간의 수작업이고, 나머지는 에이전트가 5분 안에 해줄 수 있을 듯함
장기적으로 이렇게 사업하는 건 맞는 방식처럼 보이지 않음
누군가 운 좋게 실제로 “청구서”를 내더라도 많은 호의를 잃고, 기술 업계 전체에 수상한 행보를 알리게 됨
무료 체험에 신용카드를 요구하는 곳에는 항상 가상 카드를 쓰고 취소함. 실제로 청구하지 못해서 징징대는 걸 보는 게 꽤 재미있음
Blacksmith, Depot, Ubicloud를 각각 어느 시점엔가 만족스럽게 써본 고객으로서, 셋 다 GitHub 자체보다 저렴한 GitHub Actions 실행기를 제공하지만 이번 과금은 이상하다는 데 동의함
다만 1,000달러 청구서가 나오려면 CI 시간을 정말 많이 써야 한다는 점도 짚어야 함. 취미 수준은 한참 넘었고, 같은 사용량이면 기존 GitHub에서는 두 배 비용이 들었을 것임. 이건 실질적인 컴퓨트 수요가 있는 사업체가 실제 돈을 내라는 요구에 가까움
비용 면에서는 전용 서버 같은 걸 쓰는 편이 더 나았을지도 궁금함
Gusto에서 겪은 일이 떠오름
작년 5월에 R&D 세액공제 급여 상계 서비스에 가입했는데, 수수료는 우리가 얻는 혜택의 일정 비율로 계산됨. 연방 세금 신고를 9월에 했으니 자연히 10월 전까지는 급여 상계가 없었음
그런데도 제공하지 않은 서비스에 대해 요금을 청구했고, 도구의 목적과 반대로 첫날부터 현금 유출이 더 커졌음. 그들은 내가 체크박스를 눌렀을 때 작은 글씨에 “가입 시 청구”라고 되어 있었다고 주장했는데, 꽤 터무니없다고 느꼈고 지금도 그렇게 봄
얼마를, 얼마나 오래 청구했는지 물어봐도 될까?
Blacksmith가 이 스레드에 들어와 직접 해명해야 함
그리고 작성자는 이 사용량이 GitHub Actions에서는 얼마였을지도 알려줄 수 있나?
“불쾌한 놀라움과 까칠한 지원 응대가 있었는데도 Blacksmith를 계속 쓸 것인가?”라는 질문은 흥미롭고, 실용적으로 판단한 것도 이해됨
다만 Blacksmith가 이 일로 뒤통수를 맞을 수도 있음. 그러면 행동을 바꾸면 좋겠지만, 많은 스타트업처럼 그냥 실패할 수도 있음
그래서 성공 여부가 더 분명해질 때까지는 서비스에 종속되지 않게 계속 쓰는 것이 요령일 듯함. 그 뒤에야 플랫폼 기능을 활용할지 고려할 수 있음
그래도 Blacksmith를 얼마나 신뢰할 수 있을지, 나중에 떠나기 어렵게 만들고 싶을지는 잘 모르겠음
GitHub Actions에 대해서는, Microsoft가 플랫폼을 장악한 뒤 더 나은 대안으로 옮길 만큼은 아니지만 딱 쓸 만한 수준의 제품과 기능을 만드는 데 매우 능숙함. GitHub Actions가 명확한 예이고 Teams도 그렇고, 목록은 길다. 내게는 1990년대의 반경쟁적 행동을 현대적으로 변형한 것처럼 보임. 경쟁자가 들어오지 못할 만큼의 장벽을 만들고 혁신을 죽임. 별로 좋아하지 않음
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기