자체 결제 시스템 구축의 14가지 고통

• 결제와 매출 시스템은 수익화를 위해 필수지만, 재무·제품·고객지원·법무·컴플라이언스·영업까지 얽히는 복잡한 핵심 시스템이라 작은 장애도 큰 운영 문제로 번질 수 있음
• 초기 회사나 신제품 팀은 결제를 단순한 엔지니어링 문제로 보고 직접 만들기 쉽지만, 실제 선택지는 자체 구축·서드파티·하이브리드로 나뉨
• 실제 결제 시스템은 멱등성, 날짜 처리, 사용량 계량, 세금, 환불, 고객 계층, 맞춤 계약, 가격 변경, 수익 인식을 동시에 다뤄야 함
• 일부 문제는 한 번 해결하면 안정적이지만, 세금 규칙·고객 실수·수동 정정·국가별 청구서 요구사항은 성장과 글로벌 확장에 따라 계속 커짐
• 제품 고유의 사용량 업데이트와 고객 생명주기 이벤트에 집중하고, 구독·청구·회계·수익 인식은 가능한 한 기성 결제 시스템과 ERP에 맡기는 편이 안전함

---

결제가 단순한 기능이 아닌 이유

• 결제와 매출 시스템은 비즈니스가 수익을 내기 위해 반드시 필요함
• 정상 동작할 때는 눈에 띄지 않지만, 실제로는 여러 조직과 기능을 동시에 건드리는 문어 같은 시스템임
  • 재무
  • 제품
  • 사용자 경험
  • 고객지원
  • 고객
  • 법무
  • 컴플라이언스
  • 영업
• 한 부분이 깨지면 연결된 영역까지 빠르게 문제가 커질 수 있으며, 실제로 자주 깨짐
• 합법적이고 정확하게 매출을 수금하지 못하면 비즈니스 운영자가 감당해야 할 문제가 크게 늘어남

세 가지 구축 패턴

• 결제 시스템에는 보통 세 가지 접근이 있음
  • 자체 구축
  • 완전한 서드파티 시스템
  • 자체 구축과 서드파티를 섞은 하이브리드
• 초기 회사나 새 제품을 시작하는 팀은 엔지니어가 있고 단순하게 유지하고 싶다는 이유로 직접 만들려는 경향이 있음
• 결제를 “S3에 청구 파일을 넣고 CRON 작업이 가져가 결제하면 되는 문제”처럼 보면, 결제를 엔지니어링 문제로만 오해하게 됨
• 보안이나 날짜 처리를 직접 구현하지 않는 것처럼, 결제도 처음부터 전부 직접 만들지 않는 편이 좋음
• 가장 좋은 결제 시스템은 전부 직접 만들 필요가 없었던 시스템임

자체 결제 시스템의 14가지 고통

• 멱등성

  • 모든 청구와 결제 수금 요청은 유일하고 멱등적이어야 함
  • API 제한으로 재시도하거나 결제 시스템 인스턴스를 늘릴 때 이 문제가 드러남
  • 제대로 처리하지 않으면 중복 청구 위험이 생김

• 날짜 처리

  • 30일마다 청구할지, 매월 가입일 기준으로 청구할지 정해야 함
  • 윤일, 시간대 같은 조건도 함께 처리해야 함

• 일할 계산과 잔여분

  • 업그레이드 때만 일할 계산할지, 다운그레이드에도 적용할지 정해야 함
  • 환불, 크레딧, 무시, 업그레이드·다운그레이드 차단 같은 선택지가 있음

• 사용량 계량

  • 사용량 계산 방식은 수십 가지가 될 수 있음
  • 고객 유형별로 달라지거나 자주 바뀔 수 있음

• 청구서 형식

  • 한 국가에서만 운영할 때는 쉬워 보일 수 있음
  • 확장하면 판매세뿐 아니라 VAT, GST, 국가별 추가 부담금까지 처리해야 함
  • 시장별 개별 템플릿이 필요해질 수 있음

B2B와 글로벌 확장에서 커지는 복잡성

• 복잡한 고객 계층

  • 특히 B2B 고객은 자회사와 파트너를 두고 청구 관계를 관리하려 할 수 있음
  • 사용량을 실제 지불 주체로 합산하는 방식이 필요함
  • 이런 요구는 성장과 확장 이후에야 나타나는 경우가 많음
  • 고객 법인이나 사용 위치가 다르면 세금이 달라질 수 있음
  • 법적으로 청구서와 인보이스를 나눠야 할 수 있음
  • 관련 규칙은 몇 달마다 바뀔 수 있음

• 결제 수금과 이탈 방지

  • 결제 재시도를 언제 포기할지 정해야 함
  • 차지백이 발생하면 계정을 종료할지, 정지할지, 환불할지 결정해야 함

• 일시정지와 재개

  • 고객이 구독을 일시정지했을 때 어느 수준의 접근 권한을 허용할지 정해야 함

• 크레딧과 환불

  • 전액 환불만 한다면 상대적으로 단순함
  • 부분 오류가 생기면 부분 환불이나 스토어 크레딧을 선택해야 할 수 있음
  • 크레딧 만료 여부도 별도로 결정해야 함

세금, 계약, 사람의 실수

• 세금 처리

  • 서로 다른 항목에 다른 세율이 적용되는 것만으로도 복잡함
  • 글로벌 수준에서는 세율과 세금 규칙이 자주 바뀜

• 맞춤 계약

  • PLG만 한다면 문제가 아닐 수 있음
  • 계약을 체결하기 시작하면 기존 가정으로 쉽게 설정할 수 없는 예외와 특별 조건이 빠르게 생김

• 사람의 실수

  • 고객은 실수를 하고, 그에 따른 정정이 필요함
  • 기업 내부에서도 고객 설정을 잘못 구성할 수 있어 이후 수정해야 함
  • 크레딧 발행과 청구서 재발행은 시간이 많이 드는 작업임
  • 고객의 법적 정보가 바뀌는 경우도 처리 대상임
    • 주소
    • VAT ID 등

• 선택적 가격 변경

  • 가격 변경은 모든 고객에게 적용되지 않는 경우가 많음
  • 신규 고객에게만 적용될 때는 기존 계약을 지키기 위해 서로 다른 가격 버전을 유지해야 함

• 수익 인식과 발생 수익

  • IFRS-15 기준 수익 인식 규칙에는 64쪽 PDF 명세가 있음
  • 맞춤 ERP 통합까지 직접 하면 복잡성이 더 커짐

한 번 끝나는 문제와 계속 커지는 문제

• 어떤 문제는 예상보다 훨씬 자주 바뀌고, 어떤 문제는 한 번 처리하면 다시 건드릴 일이 거의 없음
• 멱등성은 한 번 해결하면 드물게만 다시 손대는 엔지니어링 문제의 예임
• 세금 규칙은 전 세계적으로 자주 바뀜
  • 진출 국가가 많아질수록 추적해야 하는 세법도 늘어남
• 고객 실수는 비교적 꾸준히 발생함
  • 성장할수록 규모가 커짐
  • 더 많은 고객지원과 수동 정정이 필요해짐
• 결제는 처음에는 엔지니어링 문제처럼 보이지만, 실제로는 업계 경험자에게도 이해하기 어려운 복잡한 문제 공간에 뿌리를 둠

직접 만들지 않아도 되는 영역

• 가능한 한 많은 결제 문제를 외부 시스템에 맡기는 편이 좋음
• 기성 솔루션을 최대한 많이 구매하는 접근이 권장됨
• 구독과 청구 영역의 상당 부분은 결제 시스템이 처리할 수 있음
  • Solvimon
  • Orb
  • Lago
• 수익 인식과 회계는 이미 쓰고 있는 ERP나 다른 시스템에 내장된 기능에 맡기는 편이 좋음
• 제품 팀은 사용량 업데이트와 기본 고객 생명주기 이벤트처럼 제품에 고유한 부분에만 집중해야 함

[GN⁺]

Hacker News 의견들

• 청구 의사결정을 해야 하지만 경험이 많지 않은 사람에게 좋은 글이고, 경험자에게도 참고용으로 유용함
  다만 “S3에 청구할 파일을 덤프해두고 CRON 작업이 결제를 수거하게 하면 안 되나?”라는 문장은 크게 웃었음. 엔지니어 머리로는 어떤 상황에서도 좋은 생각이 아님
  내가 좋아하는 청구 아키텍처 결정은 시스템에서 청구와 권한을 최대한 분리하는 것임. 선불 구독이라면 권한 자체에는 만료일과 활성 기간 동안 부여되는 권한 세부사항만 저장하고, 청구 시스템은 구독을 저장한 뒤 필요할 때 권한 쪽으로 동기화하는 방식이 좋았음. 이렇게 하면 사람이 수동 청구하거나 일시적 문제를 디버깅·패치하거나 Stripe 연동을 붙이기도 쉬워짐
  물론 미래 확장을 열어둬야 하지만, 이 결정 자체가 시스템을 크게 제한하지는 않는 편임. 내 독창적인 아이디어는 아니지만 다른 방식을 덜 성공적으로 시도해본 뒤 특히 좋아하게 됨

  • 경험상 엔지니어는 보통 청구 시스템을 다뤄본 사람과 그렇지 않은 사람으로 나뉨
    많은 문제는 결제와 청구의 차이에서 생김 https://www.wingback.com/blog/saas-payment-vs-saas-billing. 처음 고객을 받을 때는 반복 결제 몇 건만 받으면 되니 Stripe나 수동 인보이스로도 쉽게 시작 가능함
    하지만 시간이 지나면 더 복잡한 권한, 여러 요금제, 기존 고객 보호, 맞춤 청구 주기·조건·권한 부여가 필요한 엔터프라이즈 고객이 점점 들어옴. 청구는 기술적 초점이 되지 못하는 경우가 많아서 작은 해킹과 추가 기능이 쌓이고, 결국 제품 개발 자원을 빼앗으며 영업 속도를 늦추거나 팔 수 있는 상품을 제한하는 난장판이 됨
    청구의 복잡성에는 숨은 함정과 예외가 많고, 요즘은 대부분의 요금제가 여러 한도와 사용량 기반 요소를 포함하며 SaaS가 전 세계에 팔리기 때문에 더 복잡해졌음. 후기 단계 회사에는 청구만 담당하는 15명 이상 엔지니어 팀도 있음. 제품의 핵심이 아니라면 직접 청구 시스템을 만들지 말아야 한다는 데 동의함. 참고로 나는 SaaS 청구 플랫폼 Wingback의 CTO임
  • “직접 만들지 말라”는 구호에서 상정한 엔지니어 모델이 저 정도라면 이 글은 오히려 반대 효과를 냈음
    이제 그런 시스템을 만들고 싶어졌고, 생각보다 내가 훨씬 더 자격 있는 것처럼 느껴짐
  • Arnon이 바로 그 청구와 권한 분리를 다룬 좋은 글도 썼음
    https://arnon.dk/why-you-should-separate-your-billing-from-e...
  • 지난 몇 년간 Warrant로 고객 권한 솔루션을 쓰는 SaaS 회사들과 일하면서 우리도 같은 접근에 도달했음
    고객은 권한을 우리 시스템에 저장하고 필요할 때 확인하며, 결제 제공자 쪽에서 구독이 갱신·삭제되면 규칙과 권한을 추가하는 방식임. 이렇게 하면 하나 또는 여러 결제 제공자와 일하기 쉬워지고 관심사의 분리도 명확해짐. 관련 글도 이 맥락에 더 맞아서 공유함: https://warrant.dev/use-cases/pricing-tiers-and-entitlements..., https://arnon.dk/why-you-should-separate-your-billing-from-e...
    이상적인 권한 시스템은 동적이어야 하고, 즉 규칙이 데이터베이스에 저장되어야 하며, 엔터프라이즈 고객 같은 일회성 시나리오를 처리할 수 있어야 하고, 그 위에 정책 계층이 있어야 함. 예를 들어 Pro 요금제는 좌석 5개 이하, Growth 요금제는 어떤 기능을 하루 N회까지 같은 거의 모든 시나리오를 지원할 수 있어야 함
    비기술 담당자가 엔지니어링 개입 없이 고객별 변경을 할 수 있는 UI도 큰 장점임. 이전 엔지니어 역할에서는 이런 일이 항상 개발팀 발목을 잡았음
  • 우리가 도달한 방식도 비슷함. 청구는 단지 인보이스를 계산하는 메커니즘이고, 발송한 인보이스와 받은 결제, 조정 내역을 원장에 누적해 미수금을 관리함
    권한 집합도 있지만, 그 중간에 언제 권한을 적용하거나 적용하지 않을지 결정하는 정책 메커니즘이 있음. 핵심은 권한이 청구만의 문제가 아니라는 점임. 정책 메커니즘은 권한과 다른 모든 것을 이어주는 접착제라서, 가장 큰 고객사의 임원에게 청구와 연결하지 않고도 권한을 줄 수 있음

• 예전에 작은 약국 체인의 청구와 미수금 시스템을 만들었는데, 보험사에서 아무 예고 없이 꽤 큰 수표를 보내오곤 했음
  우리가 아무것도 청구하지 않았는데도 우편으로 15만 달러 수표가 오고, 몇 달 뒤에야 실수를 깨닫고 돌려달라고 했음. 이런 돈을 넣어두는 magic money라는 특별 계정이 있었음. 청구 세계는 정말 미친 동네임

  • 보류 계정, 특히 이 경우에는 송금자에 묶인 계정이라고 보면 됨. “이 주체에게서 돈을 받았지만 아직 이유를 모른다”는 상태임
  • 일정 시간이 지나면 이 “magic money”가 법적으로 회사 소유가 되는 시점이 있는지 궁금함
  • 혹시 다른 주체, 예를 들어 개인에게 청구한 금액이 보험사까지 흘러갔는데, 아무도 거슬러 추적하지 않아서 그 사람들 계정에는 부채가 남아 있었던 건 아닌지 궁금함
    그냥 magic money라고 부르면서 개인 계정의 부채는 그대로 둔 것 아닌가
  • 왜 그 수표를 현금화하거나 입금했는지 궁금함

• 직접 청구 시스템을 만드는 고통만으로 이 주제에 접근하는 건 적절하지 않다고 봄. 많은 회사가 그렇게 가고 싶다면 그렇게 두면 됨
  청구 시스템이 매우 복잡하다는 건 인정함. 하지만 Chargebee, Solvimon, Stripe, Recurly, Orb, Metronome, Lago, Togai 등이 그런 지식을 갖고 있다면, 그 지식을 한곳에 모을 수도 있음
  정답은 결국 자신에게 맞는 접근임. 구독 기반 SaaS라면 거기에 맞는 해법이 있고, 사용량 기반 API라면 그에 맞는 청구 해법이 있음
  관행을 말리기보다 지식, 접근법, 패러다임, 프로그래밍 패턴, 좋은 관행과 최선의 관행을 한곳에 모을 수 있음. 미국이나 유럽 밖 회사라서 Stripe 같은 청구 솔루션을 못 쓰는 예외도 있음. 예를 들어 베네수엘라 회사라서 Stripe 계정을 만들 수 없다면, 결국 직접 청구 솔루션을 만들고 현지 결제 게이트웨이의 난해한 SOAP-XML API에 연결해야 함
  별도로, “직접 청구 시스템 만들기”는 Elastic + Grafana 구성으로 “직접 SIEM 만들기”와 비슷하게 느껴짐. 추천하진 않지만, IT 보안 부서에서 왜 그렇게 많이 가는지는 이해함

  • 이 글은 청구 시스템을 흥미로운 방식으로 다룸. 문제로 제시된 주제들 중 일부는 이미 고용 중일 회계사나 다른 전문가에게 넘길 사안처럼 보임
    청구 시스템은 개발자들이 다루는 대상보다 덜 복잡함. 글은 어려운 법적 요구사항을 난점처럼 그리지만, 실제로는 명세를 찾기 쉽고 문서화가 잘 되어 있다는 뜻이기도 함. 자주 바뀌는 부분도 있지만, 그런 부분은 라벨링과 설명이 잘 되어 있음
    구독 기반 SaaS와 사용량 기반 API마다 맞는 청구 방식이 있다는 점은 동의함. 다만 고객이 책임 부담을 넘기는 걸 허용할지, 매출이 검증할 만큼 중요한지, 수수료나 손실을 감당할 수 있는지가 관건임

• 이 글이 다루지 않은 것 중 하나가 제휴 판매인데, 얼마나 깊게 구현하느냐에 따라 꽤 일이 많아질 수 있음
  플랫폼 내 판매에 대해 다른 사람이 수수료 기반 지급을 받을 수 있게 하는 시스템임
  제휴 코드를 판매와 사용자까지 추적하고, 제휴자가 설정한 결제 제공자로 지급을 보내며, 제대로 하려면 방문자 지표와 전환율·지급 이력을 볼 수 있는 UI도 제공해야 함
  다행히 대부분은 점진적으로 만들 수 있음. 고유 코드를 사용자에 연결하고, 그 코드를 특정 수수료율의 판매에 연결하기만 하면 나머지는 수동 처리하거나 생략 가능함. 예를 들어 나는 한 달에 한 번 Zelle이나 PayPal로 제휴자에게 지급하는데 10분도 안 걸림. 전환 추적 프런트엔드는 없고, 그 때문에 제휴를 안 하겠다는 사람도 없었음

• 정말 인상적이었던 건 이 전체 루브 골드버그 기계를 거꾸로 돌릴 수 있어야 한다는 필요였음
  “주문”은 최대한 정적으로 유지하고 싶고, “인보이스”는 법적 의무까지 있음
  예를 들어 5개를 사서 할인을 받았는데 3개만 원하고, 이름과 주소에 오타가 있었다고 해보자. 문제없다며 인보이스를 취소 처리하고 같은 금액으로 이름·주소를 고친 새 인보이스를 만들고, 반품이 도착해 검수될 때까지 기다렸다가 다시 크레딧 처리하고 또 새 인보이스를 만듦
  반품 배송은 한동안 애매한 상태에 있고, 고객은 5개를 더 주문하며, 하나는 깨져서 도착하고, 교체가 아니라 환불을 원함. 배송일이 2개로 나뉘어서 시스템은 5개 이상 할인을 적용하지 않음. 처음엔 단순한 주문 2건이라 생각했던 일이 순식간에 수많은 거래와 서류로 바뀜. 고객은 비밀번호도 잊어버려 다른 이메일로 새 계정을 만들었음. 1년 뒤 로그를 보면 왜 3개만 샀는데 할인을 받았는지 파악하기 어려움

• 이 조언은 잘 모르겠음. 글에서 말하는 기능의 절반은 필요 없을 수 있고, 사업이 커지면서 충분히 점진적으로 만들 수 있음
  인보이스, 크레딧, 과세 기간, 일할 계산 변경 같은 개념은 이해해야 함. 하지만 그 지식은 무조건 외주·구매해야 하는 이유가 아니라 구축과 구매 판단을 더 잘하기 위한 재료임
  SaaS에 필요한 외부 API는 신용카드 처리기 하나뿐이고, 멋을 내면 둘 정도임. 물론 첫해가 지나면 수작업이 많이 생기고 회계사가 바보 같은 실수를 알려줄 것이며, 회계도 많이 배우게 될 것임
  그래도 오늘 새 사업을 시작한다면 여러 솔루션을 비교해보겠지만, 직접 만드는 게 그렇게 무섭지 않다는 확신은 있음

  • 청구 시스템을 만들어도 보고 연동도 해본 입장에서, 이건 행복한 무지에서 나온 말로 들림
    시스템 구축은 항상 쉬워 보이고 첫날에는 실제로 쉬움. 하지만 곧 재무 책임자에게 왜 보고서가 완전히 엉망인지 설명하는 데 많은 시간을 쓰게 되고, 지원팀에는 왜 인보이스가 실패했는지, 왜 구독 가격을 잘못 청구했는지, 존재조차 몰랐던 여러 예외 상황을 설명하게 됨
    그다음에는 바뀐 규제를 맞춰야 하거나, 선택한 게이트웨이가 성장 중인 지역을 지원하지 않을 수 있음
    “그냥 더 잘 만들면 되지”라고 하기 전에, 그것도 시간이라는 점을 기억해야 함. 제품에 쓰지 못한 시간이고, 가격 모델 개선에도 쓰지 못한 시간이며, 사업 성장을 만드는 일 대신 제자리걸음에 쓰는 시간임
  • 어떤 길을 가든 먼저 회계사와 이야기해서 법적으로 결제에 반드시 붙어 있어야 하는 정보가 무엇인지 확인해야 함
    그 외에는 무시할 수 있지만, 나중에 세금을 계산할 수 없거나 고객확인제도 법을 어기게 되면 정말 힘들어짐
    또한 어떤 시스템이 예상보다 비싸고, 똑똑해 보이는 많은 회사가 쓴다고 해서 목적에 맞는다는 뜻은 아님. 특히 당신이 원하는 목적에 맞는다는 보장은 더더욱 없음. 구매한다고 조사를 안 해도 되는 건 아님
  • B2B SaaS의 핵심은 손이 많이 가는 고가 영업에서 돈이 나오고, 그 영업이 요구사항을 만들어낸다는 점임
    이런 청구를 다루는 사람의 목표는 단순함. 영업팀이 계약을 닫을 수 있도록 적절한 선택지를 제공해야 함. 영업팀과 협업해 “구현하기 쉽고 계약을 닫기에 충분한” 영역이 무엇인지 찾아야 함
    이 점은 아무리 강조해도 부족함. 영업팀은 실제로 매출을 만들고 있음. 완벽한 청구 시스템이 아니라고 징징대지 말아야 함. 충격적일 수 있지만, 비즈니스 관계가 걸린 문제에는 때로 팔 걷고 손으로 처리해야 함
    가능한 한 단순한 방식으로 하되, 회사 내 다른 팀이 읽고 이해할 수 있고, 자동화가 돌아가더라도 쉽게 수동 조정할 수 있는 시스템이어야 함. Stripe가 쓰기 좋게 느껴지는 이유의 80%가 여기에 있음. 수동 조정은 삶의 일부이고, 어떤 사업에서는 드물어도 결국 필요함
  • 여러 국가와 통화로 확장하면 구독 묶음의 가격 관리만 해도 얼마나 어려운지 과소평가하고 있음
    일할 계산, 서로 다른 청구 일정, 체험판, 새 가격 테스트, 지역별 가격, 지역별 세금, 여러 통화로 묶음 상품 나열, 새 가격 배포가 갑자기 6개 통화 × X개 지역 × Y개 제품 × Z개 청구 일정 × L개 언어의 조합이 됨
    여기에 새 구독을 추가하고, 구독 요금제를 병합하고, 오래된 요금제를 중단하면서 고객을 새 대안 요금제로 부드럽게 옮기고, 고객과 잘 소통해야 함. SaaS라면 거의 전부 자동화·셀프서비스·테스트가 잘 되어 있어야 하고, 그렇지 않으면 고객 지원과 이탈에 빠져 죽게 됨
  • 직접 만들 시간이 있다고 가정하고 있음. 우리는 직원 35명, 저가 B2C SaaS 고객 30만 명 규모인데, 제품을 만들고 버그를 고치느라 바빠서 청구 시스템 확장이나 맞춤 계약 구현에 쓸 시간이 사실상 0분임
    가격 변경 배포는 3일에서 2개월까지 걸릴 수 있고, 초기의 맞춤 계약 흔적을 처리하는 건 악몽임. 쉽게 자동화할 수 없다면 할 수 없음. 시간이 너무 많이 듦
    여기서 언급된 제품 같은 것에 청구를 기반으로 했다면, 고객 세그먼트별 맞춤 계약과 가격 변경 배포를 훨씬 더 잘할 가능성이 있었을 것임

• 여기서 다루지 않았지만 직접 처리해본 문제가 2가지 있음
  첫째는 월말·분기 마감임. 글은 계정 원장을 말하지만, 숫자를 보고해야 하는 상장사를 다루기 시작하면 엄격한 마감 시점이 있고 모든 것이 매끄럽게 진행되도록 해야 함
  둘째는 이동 중 현금 회계임. 이 글은 결제 처리기가 100% 정확하고 아무 문제도 없다고 가정함. 충분히 커지면 은행 계좌에 들어온 모든 돈을 특정 인보이스나 청구 항목과 대조할 수 있어야 함. 대응되는 은행 명세 라인이 없는 인보이스도 찾아야 하고, 반대로 인보이스 항목과 연결되지 않은 돈이 들어오는 경우도 처리해야 함. 청구 인보이스와 연결되지 않은 은행 계좌 크레딧을 다루는 능력도 중요함
  이걸 전부 회계 부서 문제라고 할 수도 있지만, 시스템과 매우 밀접하게 결합되어 있어서 두 팀이 장부 간 불일치가 없도록 함께 일해야 함

  • 큰 상장사 주변에서 회계와 조금이라도 관련해본 사람이라면 월말·분기 마감이라는 말만 들어도 정신이 움찔했을 것임
    실제 회계사는 마감 때문에 반복해서 자정까지 남아 있어야 하고, 기술·비즈니스 쪽 사람은 회계팀에서 뭔가 받아야 하는데 마감 기간 동안 회계팀이 지구상에서 사라진 것처럼 보이는 상황을 겪음. 가족 구성원으로 겪어도 마찬가지임
  • 처음부터 은행 입금과 청구 항목 대조를 하지 않으면 세금을 제대로 맞출 희망이 없음
    내부 회계와 은행 계좌가 서서히 어긋나고, 회계사는 어디서부터 문제를 찾아야 할지 모르게 됨

• 다들 권한 관리는 무엇을 쓰는지 궁금함. 기능 플래그 시스템을 쓰는지, Stigg 같은 별도 SaaS를 쓰는지, 아니면 내부 시스템을 따로 두는지 궁금함
  오늘 아침 HN에 온 것도 기능 플래그를 권한 관리에 쓰는 글을 썼기 때문임: https://prefab.cloud/blog/modeling-product-entitlements-with.... Arnon의 SKU 형식 관련 글에서도 영감을 받았음
  기능 플래그가 권한 관리에 완벽한 장소처럼 보이진 않지만, 경험상 이런 과제를 처리할 때 손에 있는 도구 중 가장 나은 경우가 많았음. 다른 의견을 듣고 싶음

  • 우리는 숫자 한도, 예를 들어 일일 API 호출 수와 제품 플래그를 태그 배열 형태로 조합해서 씀
    이 한도와 플래그는 “요금제”에 붙고, 요금제는 계정에 붙일 수 있음. 요금제를 조합할 경우 숫자 값은 더 큰 값을 취하고 태그는 합집합으로 합침. 또한 계정별로 값을 덮어쓰거나 추가할 수 있어서, 고객이 PlanX는 필요하지만 맞춤 API 할당량이 필요하면 그 값 하나만 계정에 직접 덮어쓰면 됨
    구식이라고 불러도 좋지만, 왜 이런 걸 제3자에게 외주해야 하는지 모르겠음
  • 지금 요금제 권한과 비슷한 기능을 위한 솔루션을 만들고 있음
    기본적인 해법은 기능 플래그로 가능하지만, 청구·가격과 관련된 권한, 예를 들어 요금제와 에디션의 조직화와 변화는 시간이 갈수록 주변 요구사항이 많아져 복잡해짐. 기능, 좌석, 사용량 기반·계량 전략의 다양한 조합, 팀 구독, 요금제 이전, 일회성 엔터프라이즈 요금제, 여러 구독을 가진 고객, 프로모션 기간과 계층형 구독, 사용량 집계, 자동 상향 판매 등을 생각해보면 됨
    글에서 보이듯 숫자 값을 가진 플래그로 한도를 표현할 수는 있지만, 사용량 추적 인프라는 여전히 비즈니스가 직접 구현해야 함. 대신 그 사용량을 권한 서비스로 내보내고, 사용량 기반 권한이 팀 간에도 실시간으로 갱신된다고 생각해보면 좋음. 또한 그 권한에 의존하는 다른 권한도 함께 갱신될 수 있음. 한도에 접근하거나 넘으면 계속 쓰게 두되 영업팀에 알리는 소프트 제한이나, 업그레이드 안내를 띄우는 하드 제한을 선택할 수 있음
    원글의 취지처럼 우리는 청구를 다시 만들기보다 기존 청구 솔루션과 함께 동작함. 이전 성공적 엑싯으로 부트스트랩 중이고 초기 고객과 일하고 있으니, 이 주제로 이야기만 해보고 싶은 사람도 trent at planship.io로 연락해도 됨
  • 기능 플래그는 딱 충분히 표현력이 좋아서 모든 것에 억지로 끼워 넣고 싶어지는 아름다운 시스템 중 하나임
    베타 배포, 역할 기반 인증, 청구 권한, 일회성 고객 요청까지 전부 기능 플래그로 만들 수 있음. 가장 좋은 기능 플래그는 선택적으로 값도 붙일 수 있으니 API 요금제 한도도 기능 플래그가 될 수 있음
    이게 최선이냐고 하면, 각 사용 사례별로는 아마 아닐 것임. 하지만 한 번 만들어두면 모든 곳에 쓰고 싶은 유혹이 큼
  • “기능 플래그 권한”이 엔지니어가 보통 쓰는 기능 플래그, 즉 작은 증분 변경, 테스트, 배포, A/B 테스트와 명확히 다르게 취급된다면 잘 작동할 수 있다고 봄
    권한은 고객이 보는 기능과 명확히 연결되어야 하며, 개념적으로는 훨씬 큰 기능 블록임. 이 접근의 어려움은 여전히 많은 청구 관련 측면을 고려해야 한다는 점임. 연체 고객 처리, 특정 한도를 넘었을 때 초과 요금, 같은 기능에 대한 여러 가격 모델, 요금제 변경·업그레이드 시 사용량 카운터 초기화나 이월 등이 시간이 지나며 큰 복잡성을 더함
    그래서 우리는 Wingback에서 청구 체인과 계량에 긴밀히 결합된 별도 기능 권한을 제공하기로 했음. 참고로 나는 CTO임. 결국 요금제 복잡도와 이미 기능 플래그에 얼마나 투자했는지에 따라 두 접근 모두 잘 작동할 수 있다고 봄. 고객용 기능 게이팅이 있으면 고객 계정 프로비저닝과 맞춤 패키지 제공이 훨씬 쉬워짐

• “시스템 X는 매우 복잡하니 직접 만들지 말고 기성 솔루션을 써라”라는 논리 구조 전반은 납득하기 어려움
  X의 일반해가 엄청 까다롭고 복잡할 수는 있지만, 내 사용 사례에는 복잡성의 특정 부분만 필요함. 그래서 필요한 복잡성만 다루는 자체 해법을 만들 수 있고, 그것은 기성 도구보다 훨씬 단순할 수 있음
  나는 이 입장을 날짜·시간에 대해서는 완전히 채택함. 내 날짜·시간 접근은 라이브러리가 두 함수 호출만 제공하면 됨. 에포크 시간을 특정 시간대의 ISO 형식 시간 문자열로 바꾸는 함수와 그 역함수임. 다른 라이브러리 코드는 전혀 건드리지 않고, 나머지 시간 조작은 그 두 함수를 기준으로 내 코드에서 처리함

  • 청구에서 돈이 오가는 일은 오류 허용 범위가 아주 좁고 규제도 받음
    처음부터 개인정보 처리의 해야 할 것과 하지 말아야 할 것, 여러 청구 옵션의 주기와 수명, 환불 한도, 멱등성 지원, 과업에 맞는 모델을 갖춘 합리적인 데이터베이스 트랜잭션 관리, 인보이스 발행과 고객 노출 등을 이해해야 함
    전부 한꺼번에 필요한 건 아니지만, 첫 번째로 작동 가능한 구현에도 적어도 절반은 필요함

• “길 건너기의 14가지 고통과 왜 내 책을 사서 읽어야 하는가” 같은 느낌이 있음
  많은 사람은 눈을 감고 걷기 시작하는 게 좋다고 생각해서 때 이른 부상이나 죽음을 맞음
  나라마다, 심지어 도시마다 길 건너는 규칙이 다름. 아직 모를 수도 있지만 양쪽을 봐야 함. 자신이 색맹인지 몰라 빨강과 초록을 구분하지 못해 죽거나 다치는 사람도 많음. 양쪽은 봤지만 위도 봤는가? 도시에선 창문에서 물건이 떨어지고, 시골에선 새가 머리 위를 날 수 있으며, 우주 쓰레기도 점점 더 많이 지구로 떨어지고 있음. 물체는 여러 방향에서 올 수 있음
  이 글이 그 정도로 나쁘다는 건 아니지만, 방법론 글로 구성됐으면 더 좋았을 것임. 부정적으로 짜인 글보다 그런 글을 훨씬 더 읽고 싶음

  • 지금 청구팀에서 일하고 있음. 커리어 대부분을 청구에서 보낸 건 아니지만, 이 글은 정확함
    “얼마나 어렵겠어?” 농담 프로젝트의 이상형인데, 문제는 전부 사실이라는 점임
    예시는 셀 수 없이 많지만, 문제에 잘못 접근하면 곧 “고객은 얼마를 내야 하는가”라는 질문에 부딪히고, 이어서 “왜 우리가 이 금액이 아니라 다른 금액을 청구했는가”가 따라옴. 이런 일이 너무 자주 생기면 재무팀이 와서 회사 운영 보고서, 심지어 해고 여부를 결정하는 보고서까지 신뢰할 수 없게 만들었다며 무엇을 했느냐고 묻게 됨