본문으로 건너뛰기

Salesforce가 4.3백만 문의 데이터를 기준으로 '해결된' AI 에이전트 건당 2달러의 결과 기반 과금을 발표했다.

Salesforce는 4.3백만 문의 데이터를 바탕으로 '해결' 기준을 정해 에이전트 건당 2달러의 결과 기반 과금을 제안했다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Salesforce는 헬프 포털의 4.3백만 건 문의 데이터를 이용해 '해결'을 에이전트가 인간 개입 없이 작업을 끝내고 고객이 불만을 표하지 않은 경우로 정의하고 해당 케이스에 대해 건당 2달러의 결과 기반 과금을 제안했다. 이 접근은 단순한 토큰 집계와 달리 로그 추적·에스컬레이션 탐지·이탈 신호 등으로 성공 여부를 판별해야 하므로 플랫폼 수준의 추적 인프라가 필요하다는 점을 분명히 했다. ServiceNow의 per-assist 과금과 SAP의 비공개 단가 같은 사례가 존재하며 Pega의 Infinity 26의 케이스당 고정 과금은 실질적 비교 포인트로 제시되었다. 최종적으로 결과 기반 과금은 비용 예측성을 개선할 가능성이 있지만 엣지 케이스와 최소 소비 정책이 도입되면 기존의 토큰 미터가 부분적으로 재등장할 위험이 존재한다.

실용적 조언

  • 결과 기반 과금을 도입하려면 트랜잭션 단위의 시작·중간·종료 이벤트를 일관되게 로깅하고 에스컬레이션 및 사용자 이탈 신호를 자동 판별하는 룰을 구축해야 한다. 이 과정에서 입력된 로그는 성공 판정 로직의 근거 데이터가 되므로 추적 경로 설계와 시계열 일관성이 중요하다. 또한 최소 소비량과 예외 규칙을 사전에 명문화해 고객과 제공자 간 분쟁을 줄이는 절차도 병행해야 한다.
  • 비교용으로 Pega처럼 AI 추론을 설계 시점으로 옮겨 런타임 비용 변동을 줄이는 아키텍처도 고려할 수 있다. 설계 시점에 규칙과 모델 동작을 고정하면 케이스 단가 예측이 쉬워지지만 유연성이 줄어들고 예외 처리 로직을 강화해야 한다. 따라서 조직은 예측성, 유연성, 운영 복잡성 간 트레이드오프를 명확히 평가한 뒤 과금 모델을 선택해야 한다.

섹션별 상세

01
Salesforce는 '해결'을 에이전트가 시작부터 끝까지 인간 개입 없이 고객 불만 없이 작업을 완료한 경우로 정의했고 이 정의에 따라 해결된 케이스당 2달러를 책정했다. 정의를 정밀하게 만들기 위해 실제 헬프 포털에서 4.3백만 건의 문의를 분석했고 이 데이터를 기준으로 경계 조건과 예외를 보정했다. 이 과정에서 단순한 토큰 집계 대신 로그 추적과 에스컬레이션 및 이탈 신호를 기반으로 성공 여부를 판별해야 한다는 결론을 도출했다. 결과 기반 과금은 단위당 소비가 아니라 완료 결과에 요금을 연결해 비용 예측성을 높일 수 있다는 근거를 제시했다.
02
기존의 토큰 미터링 방식은 계산 자원 소비를 단순 합산하는 접근으로, 작업의 성공 여부를 반영하지 못한다는 한계가 있다. 결과 과금을 적용하려면 각 거래의 시작과 종료, 중간 상태, 에스컬레이션 발생 여부, 고객 이탈 신호 등을 기록·연결하는 추적 인프라가 필요하며 이 정보로 각 트랜잭션의 성패를 판별할 수 있다. 원문은 토큰 수 측정이 '무엇이 일어났는가'를 무시한다고 지적했고 이는 서비스 제공의 품질과 비용을 분리하는 문제를 야기한다고 밝혔다. 실무적으로는 이같은 추적 체계가 없으면 결과 기반 과금이 적용되기 어렵다는 결론이 도출된다.
03
다른 플랫폼들의 과금 설계는 상이하며 예측성 측면에서 차이를 만들어냈다. ServiceNow는 행위당 보조(assist) 수로 과금하는 방식을 사용해 상호작용마다 청구 단위가 달라지고 청구 총액이 불확실해지는 문제가 발생했다고 지적되며 JPMorgan은 Action Fabric의 외부 에이전트 과금을 고객에 대한 세금 형태로 비판했다. SAP는 Joule을 통해 모든 트래픽을 라우팅하되 결과 단가를 공개하지 않아 비교가 어렵다고 나타났다. 이 사례들은 과금 단위를 어떻게 정의하느냐에 따라 사용자 비용과 예측 가능성이 크게 달라짐을 보여준다.
04
Pega는 6월부터 유사한 접근을 취했고 Infinity 26에서는 3분기에 케이스당 고정 과금을 도입해 AI 추론을 설계 시점으로 옮겼다는 점을 비교 지점으로 제시했다. Pega의 설계는 런타임에서의 추론 비용 변동을 줄이고 설계 단계에서 로직을 고정해 케이스 단가를 안정화하려는 전략으로 보인다. 원문은 Pega의 사례가 Salesforce의 결과 기반 과금이 실제로 비용 예측성을 제공하는지 검증할 첫 번째 실질적 비교 포인트가 될 것이라고 판단했다. 다만 원문은 엣지 케이스·최소 소비량 조건·예외 처리 등이 결국에는 토큰 기반 미터를 다시 부활시킬 위험이 있다고 경고했다.

용어 해설

결과 기반 과금(Outcome-based pricing)
서비스 결과의 완전한 수행 여부를 기준으로 요금을 부과하는 방식으로, 성공 판정에는 명확한 완료 조건과 상태 추적이 필요하며 클라우드 비용 예측 가능성을 개선하려는 목적으로 사용된다.
토큰 미터링(Token metering)
모델 사용량을 입력/출력 토큰 수로 단순 집계해 과금하는 방식으로, 계산 자원 소비는 측정하지만 작업의 성공 여부나 고객 만족도 같은 결과 지표는 반영하지 않는다.
에스컬레이션 탐지(Escalation detection)
자동화된 상호작용에서 인간 개입이 필요한 경우를 실시간으로 식별하는 기술로서, 로그·상태 변경·응답 지연 같은 신호를 분석해 작업이 자동화로 해결되지 못했음을 판별한다.
이탈 감지(Abandonment detection)
사용자가 대화나 과정 중에 떠난 상황을 식별하는 기법으로, 세션 종료 패턴·무응답 간격·명시적 종료 신호를 조합해 성공 여부 판단에서 실패 케이스를 구분하는 데 중요하다.
지원 행위 기반 과금(Per-assist pricing)
사용자 요청에 대해 시스템이 개입한 횟수나 보조 행위 수를 기준으로 청구하는 방식으로, 상호작용 단위가 변동해 청구 예측성이 낮아질 수 있다는 문제가 있다.
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 06. 30.수집 2026. 06. 30.출처 타입 REDDIT

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.