앤스로픽이 청구 시스템의 자체 개발을 검토하는 이유
외부 결제 서비스를 쓰면서 청구 기능도 직접 검토하는 앤스로픽. 가격 정책과 사용량 계산을 어디까지 통제할지 살펴봅니다.
비즈니스스트라이프를 쓰면서 청구 시스템도 직접 검토하는 앤스로픽
스트라이프의 고객 사례에는 앤스로픽이 결제와 청구, 재무 보고에 자사 제품을 활용한 과정이 소개돼 있어요. 초기에는 제품 개발에 집중하기 위해 외부 인프라를 이용했고, 거래가 늘면서 매출 데이터를 BigQuery로 보내는 방식도 개선했다고 해요. 스트라이프 고객 사례
한편 앤스로픽의 빌링 플랫폼 채용 공고에는 외부 서비스에 맡길 부분과 직접 만들 부분을 판단한다는 업무가 적혀 있어요. 결제 사업자를 쓰면서도 자사 청구 시스템에 개발자를 투입하는 거예요.
저는 앞선 호에서 스트라이프의 오픈라우터 인수 합의를 다뤘어요. 스트라이프는 AI 모델 사용량과 비용을 관리하는 쪽으로 사업을 넓히고 있는데, 큰 고객인 앤스로픽도 그 일부를 직접 관리하려고 해요. 두 움직임이 어디서 겹치는지 살펴볼 만해요.
청구 시스템은 카드 결제보다 범위가 넓어요
앤스로픽의 스태프 엔지니어 채용 공고는 요금 설정, 결제 흐름, 계약과 사용 권한, 매출 데이터 등을 업무로 제시해요. 외부 빌링·결제·세금 플랫폼을 많이 활용하고 있으며, 이를 확장할지 자사 기능을 만들지 판단한다고 적혀 있어요. 빌링 플랫폼 채용 공고
공고에는 결제 승인율, 재시도, 처리 비용, 분쟁 대응과 사기 방지도 들어 있어요. 청구 계산만 개발한다거나 카드 결제 처리는 검토 범위 밖이라고 단정할 수는 없어요. 그렇다고 외부 사업자를 전부 대체하겠다는 발표도 아니에요. 어디까지 맡기고 어디를 직접 통제할지 판단할 인력을 구하는 내용이에요.
카드에서 돈을 받아오는 일과 고객이 낼 금액을 계산하는 일은 연결돼 있지만 달라요. 예를 들어 AI API의 청구서를 만들려면 다음을 정해야 해요. 어떤 사용을 과금 대상에 포함할지, 입력과 출력의 단가를 어떻게 적용할지, 할인과 선불 크레딧은 어떤 순서로 차감할지요.
사용량을 세는 기능을 미터링이라고 해요. 이를 요금제와 계약 조건에 맞춰 금액으로 계산하고 청구하는 기능이 빌링이에요. 같은 호출이라도 캐시 사용, 배치 처리, 고객별 할인 조건에 따라 청구 금액이 달라질 수 있어요.
무엇에 얼마를 받을지는 서비스 회사가 정해야 해요. 그 계산을 반드시 전부 직접 구현해야 한다는 뜻은 아니에요. 외부 제품이 필요한 조건을 지원한다면 활용할 수 있어요. 다만 요금제를 바꾸고 싶을 때 어느 부분을 스스로 바꿀 수 있는지 알아야 해요.
사기 방지도 결제와 사용량을 함께 봐야 해요
앤스로픽의 금융 사기 엔지니어 공고는 결제 승인 시점의 위험 평가와 함께 환불·분쟁 대응, 체험·프로모션 악용 탐지를 다뤄요. 결제 사업자와 협력하면서 기기 정보, 짧은 시간에 반복되는 거래, 계정 간 연결 등 여러 신호를 쓰는 업무예요. 금융 사기 엔지니어 채용 공고
AI 서비스에서는 결제를 받지 않았어도 연산 비용이 생길 수 있어요. 가령 무료 크레딧을 받기 위해 계정을 반복 생성하고 API를 대량 호출한다면 서비스 회사는 사용 비용을 부담하게 돼요. 이는 가능한 악용 사례이지, 이 공고가 공개한 실제 피해 규모는 아니에요.
이런 문제를 보려면 카드 결제 정보와 서비스 이용 정보를 함께 연결할 필요가 있어요. 도난 카드 탐지가 중요하지 않아지는 것도, 무료 혜택 악용이 AI에만 있는 것도 아니에요. 어디서 비용과 손실이 생기는지에 맞춰 필요한 신호를 더하는 일이에요.
외부 결제 회사도 사기 탐지 기능을 제공해요. 스트라이프 고객 사례는 앤스로픽이 Radar의 위험 점수와 자체 규칙을 활용해 정상 거래의 잘못된 차단을 줄였다고 설명해요. 직접 운영하는 기능과 외부 기능을 함께 쓰는 사례로 볼 수 있어요.
결제 실패도 구분해서 처리해야 해요. 일시적인 오류와 카드 정보 문제, 실제 사기 의심은 대응이 달라요. 여러 결제 경로가 도움이 되는 경우가 있지만, 사업자가 하나면 재시도가 불가능한 것은 아니에요. 다른 경로로 무조건 반복 요청한다고 승인율이 좋아지는 것도 아니고요. 재시도 조건과 중복 결제를 막는 처리가 함께 필요해요.
결제사를 바꿀 수 있는지도 확인해야 해요
아디옌은 2026년 8월 상반기 실적 발표에서 오픈AI를 새로 확보한 주요 기업 고객 중 하나로 소개했어요. 다만 이 발표만으로 오픈AI가 기존 결제사의 어떤 기능을 대체했는지까지 알 수는 없어요. 아디옌 상반기 발표
회사가 결제 사업자를 추가하거나 바꾸려면 카드 정보와 기존 구독 계약을 어떻게 이전할지 살펴봐야 해요. 보관 위치가 중요한 이유예요. 별도 보관 서비스를 활용하면 여러 결제사 연결에 도움이 될 수 있지만, 그것만으로 언제든 쉽게 교체할 수 있는 것은 아니에요.
반대로 카드 정보가 결제사에 있다고 반드시 고객에게 다시 등록을 요구해야 하는 것도 아니에요. 스트라이프는 일정 보안 요건을 갖춘 새 결제 사업자에게 카드 정보를 이전하는 절차를 제공해요. 다만 Link에 저장된 결제 자격증명은 내보내기에서 제외해요. 카드 정보와 결제 이력·구독 데이터의 이전 방식도 달라요. 스트라이프 데이터 이전 안내
저라면 수수료를 협상하기 전에 이전 가능한 데이터, 지원되는 결제 수단, 이전에 필요한 시간과 개발 작업을 확인하겠어요. 실제 대안으로 옮길 수 있어야 협상에서도 선택지가 생기니까요.
스트라이프가 넓히는 사업과 고객의 자체 개발이 겹쳐요
스트라이프는 2026년 1월 14일 사용량 기반 청구 업체 메트로놈 인수를 완료했어요. 8월 19일에는 여러 AI 모델 중 요청을 보낼 곳을 고르고 사용 비용을 관리하는 오픈라우터 인수 합의를 발표했고요. 인수 완료와 합의는 다른 단계예요. 메트로놈 인수 완료, 오픈라우터 인수 합의
스트라이프의 관심은 고객에게 결제받는 순간뿐 아니라 그 전에 발생하는 AI 사용량과 비용으로 넓어지고 있어요. 앤스로픽이 채용하는 청구·가격·매출 시스템 업무와 일부 겹치는 영역이에요.
여기서 어느 기능은 무조건 사고 어느 기능은 무조건 만들어야 한다고 나누기는 어려워요. 같은 미터링이라도 고객 수, 계약의 복잡성, 개발 인력, 외부 제품의 지원 범위에 따라 선택이 달라질 수 있어요.
| 기능 | 외부 서비스를 검토할 때 볼 점 | 직접 개발을 검토할 때 볼 점 |
|---|---|---|
| 결제 처리 | 지원 국가·결제 수단·수수료·승인 성과 | 여러 경로를 연결하고 운영할 역량 |
| 사용량 집계 | 처리량·정확성·지연·원본 데이터 접근 | 자사에서만 필요한 집계 규칙 |
| 요금·계약 관리 | 할인·선불·종량제 조건의 지원 범위 | 가격 실험과 고객별 예외의 빈도 |
| 사용 권한 | 계약 변경과 실제 서비스 권한의 연동 | 실시간 한도와 중단 조건 |
| 사기 방지 | 외부 결제망에서 얻는 정보 | 제품 사용 기록과 계정 간 관계 |
고객이 일부 기능을 직접 개발해도 외부 결제와 청구 서비스를 계속 이용할 수 있어요. 채용 공고와 기존 고객 사례가 함께 있다는 사실 자체가 모순은 아니에요. 외부 서비스에 맡기는 범위가 달라질 가능성을 보여주는 거죠.
수수료만 줄이면 되는 일은 아니에요
매출과 거래가 커지면 작은 요율 차이도 큰 비용이 될 수 있어요. 그래서 외부 서비스 비용을 검토하는 건 자연스러운 일이에요. 다만 연환산 매출에 임의의 요율을 곱한 금액은 실제 지불한 비용이 아니에요. 결제 수단, 계약별 할인, 사용 제품이 다르면 비용도 달라져요.
직접 개발에는 다른 비용이 들어요. 엔지니어 채용과 운영, 세금·회계 시스템 연동, 오류 수정과 고객 응대가 필요해요. 잘못 청구했을 때 돌려줄 돈과 신뢰 손실도 고려해야 하고요.
청구 시스템은 정확하게 한 번 만드는 것으로 끝나지 않아요. 요금 변경 전후를 구분하고, 과거 계약을 유지하고, 중복 집계를 막으며, 고객 문의에 근거를 제시할 수 있어야 해요. 앤스로픽 공고가 정합성 확인과 감사 기록, 운영 책임을 강조하는 이유도 이런 업무와 연결돼요.
상장 준비나 수수료 절감 하나만으로 자체 개발 검토의 이유를 설명하기는 어려워요. 공고에서 드러나는 요구는 제품 출시 속도, 계약 처리, 결제 성과, 매출 데이터의 정확성에 걸쳐 있어요.
오스왈드의 시선
저는 이 뉴스를 보면서 소프트웨어 회사가 무엇을 외부에서 사고 무엇을 직접 만들지 판단하는 기준을 다시 생각했어요. 특히 고객에게 얼마를 청구하는지 결정하는 규칙은 제품의 일부라고 봐요.
매달 같은 금액을 받는 요금제와 사용량·할인·한도가 고객마다 다른 요금제는 필요한 계산이 달라요. 외부 제품에 요금 설정을 맡기더라도, 그 설정이 우리 고객에게 어떤 결과를 만드는지는 회사가 설명할 수 있어야 해요.
사용량이 늘고 계약이 복잡해지면 지원되지 않는 조건 하나가 가격 실험을 막을 수 있어요. 저는 바로 그 지점에서 직접 개발의 이유가 생긴다고 봐요. 외부 제품을 쓰는 비용뿐 아니라, 원하는 요금제를 제때 내지 못하는 비용도 비교해야 하는 거예요.
국내 SaaS와 AI 서비스에서도 PG에 결제를 맡기고 자체 데이터베이스에서 사용량을 집계하는 구조를 볼 수 있어요. 그 자체로 부족한 설계는 아니에요. 중요한 건 집계가 정확한지, 요금이 바뀌어도 근거를 재현할 수 있는지예요.
에이전트가 자동으로 작업을 반복하면 한 사용자의 소비량이 짧은 시간에 커질 수 있어요. 그래서 무엇을 세는지뿐 아니라 언제 한도를 적용하고 어떤 조건에서 중단할지도 가격 정책과 함께 정해야 해요.
고객이 청구 금액에 이의를 제기하면 호출 기록만 늘어놓아서는 설명이 충분하지 않을 수 있어요. 어떤 작업에 어떤 요금 규칙을 적용했고, 할인과 크레딧을 어떻게 계산했는지 보여줄 수 있어야 해요. 이 근거를 자사 코드에서 만들든 외부 시스템에서 받든, 회사가 확인하고 설명할 수 있어야 한다고 봐요.
구독자님이 종량제나 크레딧 요금제를 운영하고 계시다면, 고객 한 명의 청구서를 원래 사용 기록부터 다시 계산할 수 있는지 확인해 보세요. 그 과정에서 외부에 맡겨도 되는 일과 직접 통제해야 할 일이 더 구체적으로 보일 거예요.
💬 지금 서비스의 사용량과 청구 금액은 어디에서 계산하시나요? 요금제를 바꾸려다 시스템의 제약을 만난 경험이 있다면 들려주세요.
오늘 얻은 관점, 다음 이슈에서도 이어가세요.
쏟아지는 소식 사이에서 오래 남는 한 편을 골라 격일로 보내드립니다.
이메일 확인 후 구독이 완료돼요.
이미 구독 중이신가요? 로그인하고 댓글 남기기
SEND A COFFEE
이 관점이 좋았다면, 다음 글에 커피 한 잔
오스왈드에게 커피와 함께 짧은 쪽지를 보내주세요. 응원은 다음 취재와 집필에 보탭니다.
참고자료 & 더 읽기
- 앤스로픽 빌링 플랫폼 스태프 엔지니어 채용 공고.
- 앤스로픽 금융 사기 담당 엔지니어 채용 공고.
- 스트라이프의 앤스로픽 고객 사례.
- 스트라이프의 메트로놈 인수 완료 발표, 2026년 1월 14일.
- 스트라이프의 오픈라우터 인수 합의 발표, 2026년 8월 19일.
- 스트라이프 결제 데이터 이전 안내.
관련 지난 호

여러분의 생각이 다음 호를 만듭니다
이번 호에서 가장 공감했거나, 다른 경험을 한 지점은 무엇인가요?