성과 기반 SaaS 과금

이 문서는 자라는 중인 질문입니다. 아직 증거를 모으고 있으며, 내용이 바뀔 수 있습니다.

한 줄로 말하면

성과 기반 SaaS 과금은 소프트웨어에 들어갈 권리가 아니라 소프트웨어가 끝낸 일의 결과에 가격을 매기는 방식이야. 고객이 좌석을 사서 쓰든 말든 비용을 부담하는 구조에서, 공급자가 해결된 티켓, 성사된 거래, 완료된 작업 같은 결과 단위의 책임을 더 많이 지는 구조로 옮겨간다.¹

비유로 이해하기

좌석 과금은 헬스장 회원권에 가까워. 회원권을 산 사람이 운동을 하든 안 하든, 헬스장은 접근권을 판 거야. 성과 기반 과금은 트레이너가 “체지방을 몇 퍼센트 낮추면 얼마”처럼 결과에 돈을 받는 쪽에 가까워.

이 비유는 여기까지야. 실제 SaaS에서는 결과가 훨씬 더 복잡해. 티켓 하나가 해결됐는지, 거래가 성사됐는지, 자동화된 대사가 맞았는지, 에이전트가 잘못 처리했을 때 누가 비용을 부담하는지를 계약과 데이터로 정해야 하거든.

정확한 정의

성과 기반 SaaS 과금은 과금 단위를 사용자 수에서 완료된 결과로 옮기는 가격 구조야. 기존 좌석 모델에서는 고객이 500개 라이선스를 사고, 실제로 얼마나 쓰였는지와 별개로 접근권에 돈을 냈다는 설명이 나온다.¹ 반대로 결과 단위 과금에서는 해결된 티켓, 성사된 거래, 완료된 작업이 가격의 기준이 된다.

그래서 이 구조는 단순한 청구 방식 변경이 아니야. 에이전트가 실패하면 공급자가 그 비용을 떠안을 수 있고, 마진은 결과 가격에서 추론 비용과 실패 비용을 뺀 차이로 결정된다.¹ 원문은 이 점 때문에 성과 기반 SaaS가 전통적인 소프트웨어보다 보험사와 비슷한 구조를 가진다고 설명해.

flowchart TD
    A["좌석 기반 과금"] --> B["접근권 판매"]
    B --> C["사용 여부의 위험은 고객이 부담"]
    D["성과 기반 과금"] --> E["완료된 결과 판매"]
    E --> F["실패 비용과 추론 비용을 공급자가 관리"]
    F --> G["가격 책정 데이터와 위험 인수 역량"]

여기서 중요한 단어가 인수(underwriting)야. 보험사가 사고 확률과 손해액을 계산해 보험료를 정하듯, 성과 기반 SaaS 공급자는 어떤 작업이 얼마나 자주 실패하고, 실패했을 때 얼마가 새는지 알아야 해. 결과 가격을 정확히 매길 데이터가 있으면 우위가 누적되지만, 추측으로 가격을 잡으면 실패한 결과가 나올 때마다 마진이 깎인다.¹

왜 중요한가

agentic workflow가 길어지면 소프트웨어의 사용자는 사람만이 아니게 돼. 에이전트가 분석, 모니터링, 대사, 후속 작업을 대규모로 처리하면, 매출 기준도 “몇 명이 로그인했나”보다 “얼마나 많은 작업이 자동으로 끝났나”로 이동할 수 있어.¹

이 변화는 SaaS 시장을 작게 만들 수도, 다르게 크게 만들 수도 있어. 좌석 수가 줄면 기존 좌석 매출은 약해질 수 있다. 하지만 원문은 자동화되는 작업량의 증가율이 단위 작업 가격 하락률보다 크면 전체 소프트웨어 시장은 커질 수 있다고 설명한다.¹ 핵심 변수는 좌석 감소 자체가 아니라 새로 처리되는 일의 양과 단가의 경쟁이야.

또 하나는 방어력의 위치야. 소프트웨어 기능과 UI를 빨리 복제할 수 있다면, 가격을 결과에 맞춰 옮기는 회사는 더 깊은 데이터가 필요해. 어떤 고객의 어떤 작업이 성공할지, 실패하면 얼마나 비싼지, 어떤 모델과 절차를 쓰면 비용이 낮아지는지를 알아야 하니까. 그래서 성과 기반 과금은 독점 데이터 루프와 다시 연결된다.¹

실제 예시

원문은 Salesforce Agentforce를 사례로 든다. Salesforce는 Agentforce가 ARR 12억 달러에 접근했고, 2027 회계연도 1분기 상위 10개 거래 가운데 7개가 좌석을 추가했다고 설명된다.¹ 이 사례만으로 성과 기반 과금 전환이 끝났다고 볼 수는 없어. 다만 에이전트형 제품이 기존 좌석 모델을 바로 없애기보다, 좌석·사용량·결과 단위가 섞이는 중간 국면을 만들 수 있다는 신호로는 읽을 수 있다.

로봇 쪽에서도 비슷한 질문이 나온다. Robust.AI 페이지에는 성과 기반 RaaS 모델이 고객의 초기 비용과 공급자의 서비스 책임을 어떻게 나누는지가 남은 질문으로 잡혀 있어. 물리 로봇과 SaaS는 다르지만, 결과에 맞춰 돈을 받는 순간 공급자는 장비 고장, 현장 예외, 유지보수 책임까지 가격에 넣어야 한다는 점은 닮아 있다.

헷갈리지 말아야 할 점

성과 기반 과금은 무조건 더 좋은 가격 모델이 아니야. 결과를 잘 재고 실패 비용을 낮출 데이터가 있을 때 강해진다.
사용량 과금과 성과 과금은 같지 않아. API 호출 횟수처럼 쓴 만큼 내는 것은 사용량 과금이고, 해결된 문제나 성사된 거래처럼 고객이 원하는 결과에 맞춰 받는 것은 성과 과금에 더 가깝다.
좌석이 바로 사라진다는 뜻도 아니야. 기업 조달과 보안, 관리자 통제, 사람 승인 흐름이 남아 있으면 좌석·사용량·성과 단위가 한동안 섞일 수 있다.
결과를 판다고 해서 투자 판단이 바로 나오지는 않아. 어떤 회사가 이 구조에서 유리한지는 데이터 루프, 실패율, 추론 비용, 계약 책임을 따로 봐야 한다. 그 판단은 Insight의 몫이야.

남은 질문들

성과 기반 SaaS 계약은 실패한 결과를 어떻게 정의하고, 누가 환불·보상·재작업 비용을 부담할까?
에이전트형 제품의 추론 비용은 결과 단가 안에서 어느 정도까지 낮아질까?
좌석·사용량·성과 과금이 섞인 하이브리드 모델에서 고객은 어떤 단위를 더 신뢰할까?
결과 가격을 잘 매길 독점 데이터 루프는 어떤 제품 범주에서 먼저 생길까?

GeekNews, 「AI 에이전트 시대의 새로운 SaaS 플레이북」 링크. ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶ ↩︎⁷ ↩︎⁸

🥚

Explorer

Recent Notes

에이전트 유통

연결 풀러 프로세스 플릿