오늘 SaaS 쪽에서 꽤 익숙한 비용표를 봤다. 결제 수수료 2.9%는 다들 어느 정도 받아들이는데, 한 팀이 매달 Stripe에서 ‘카드 처리비’가 아니라 청구 로직 쪽 비용만 거의 2,500달러까지 올라왔다고 했다. 처음엔 싸고 빨라서 붙였는데, MRR이 커지니까 구독·청구·인보이스를 대신 굴려주는 1% 안팎의 추가 비용이 갑자기 CFO가 쳐다보는 줄로 바뀐 셈이다. 재밌는 건 댓글 반응이었다. 누군가는 Chargebee나 Orb도 결국 매출이 커질수록 플랫폼 비용이 같이 뛴다고 했고, 다른 사람들은 “비즈니스 로직은 직접 만들고 Stripe는 웹훅과 결제 게이트웨이로만 쓰라”고 했다. 실제로 도메인에 맞지 않는 구독 모델 때문에 청구와 인보이스를 내부에서 만들었다는 팀도 있었다. 문제는 이게 한 번의 리팩터링이 아니라 플랜 변경, 프레이션, 쿠폰, 환불, 세금, 미납 재시도까지 계속 손이 가는 운영 업무라는 점이다. 여기서 작은 제품 기회가 보인다. 거대한 billing suite가 아니라, Stripe 비용이 특정 구간을 넘기 시작한 팀에게 “어떤 로직을 안으로 빼면 얼마가 줄고, 어떤 부분은 그냥 Stripe에 남겨야 안전한지”를 시뮬레이션해주는 얇은 레이어. 청구 이벤트와 플랜 데이터를 읽어서 비용 누수, 이전 난이도, 장애 리스크를 같이 보여주면, ‘그냥 감수할까, 갈아탈까, 직접 만들까’ 사이에서 훨씬 덜 감정적으로 결정할 수 있을 것 같다.