AI 에이전트 과금, Salesforce가 해결 건당 요금을 택한 이유

Salesforce는 왜 AI 상담을 ‘해결 건당’ 과금하나: SaaS 가격표가 바뀌는 이유

2026년 7월 24일
전략 분석

핵심 요약

Salesforce의 해결 건당 과금은 단순한 요금제 변경보다, AI 에이전트의 비용과 가치를 고객의 업무 성과에 연결하려는 계약 실험에 가깝다.
좌석 기반 SaaS는 사람의 접근권을 판매하지만, 고객 문의를 직접 처리하는 AI 에이전트는 요청마다 추론·데이터 조회·도구 실행·복구 비용이 발생한다. 같은 가격표로 설명하기 어려운 이유다.
토큰·호출·대화 수는 공급자의 원가를 추적하는 지표이고, 해결 건수는 고객이 구매하려는 결과에 가깝다. 둘을 혼동하면 AI의 경제성을 과대평가하기 쉽다.
결과 기반 과금은 고객의 초기 도입 리스크를 낮출 수 있지만, ‘해결’의 정의·재문의 기간·상담원 이관·오류 책임을 계약과 운영 지표로 엄밀히 정하지 않으면 분쟁의 출발점이 된다.
AI 시대의 경쟁은 모델 성능만이 아니라, 고객이 결과에 대해 기꺼이 비용을 지불할 수 있는 가격 구조를 설계하는 능력으로도 확장되고 있다.

Salesforce를 이해해야 가격 변화의 맥락이 보인다

Salesforce는 기업이 고객 정보, 영업 기회, 서비스 이력, 마케팅 활동을 한곳에서 관리하도록 돕는 CRM 중심의 기업용 소프트웨어 회사다. 회사는 자사 제품군을 고객 데이터와 AI를 이용해 더 빠르고 반응성 있게 일하도록 돕는 ‘에이전틱 CRM’으로 소개한다. 여기서 중요한 것은 제품 목록 자체가 아니다. Salesforce는 오랫동안 기업용 SaaS의 전형, 즉 직원이 소프트웨어에 접속해 업무를 수행하도록 하고 기업이 사용자 수와 제품 등급에 따라 반복 구독료를 내는 모델을 대표해 왔다는 점이다. Salesforce는 전 세계에서 가장 큰 기업용 SaaS 기업 중 하나로, 이 회사의 가격 정책 변화는 AI SaaS 시장 전체가 참고하는 신호로 받아들여진다. 출처: What is Salesforce?, Complete Salesforce Products & Software Suite

이 모델은 소프트웨어 경제학과 잘 맞았다. 영업사원이 한 명 더 늘면 계정을 하나 더 팔 수 있고, 고객은 필요한 인원만큼 라이선스를 사면 된다. 공급자는 제품 개발·운영 비용을 넓은 고객 기반에 분산하며, 고객은 예산을 비교적 예측 가능하게 관리한다. 사용자가 모든 기능을 적극적으로 쓰지 않아도 계약은 유지될 수 있다. 가격의 기준은 ‘업무를 얼마나 많이 끝냈는가’가 아니라 ‘몇 명에게 도구를 쥐여 주었는가’였다.

그런데 AI 에이전트는 이 전제를 흔든다. Agentforce는 대화형 AI를 비즈니스에 가져오고, 맞춤형 AI 보조자를 구축·시험·사용할 수 있도록 하는 플랫폼으로 설명된다. 서비스 에이전트가 고객의 질문에 답하고 필요한 업무를 수행하는 상황을 생각해 보자. 이제 기업이 구매하는 것은 상담원 화면에 로그인할 권한만이 아니다. 고객과 대화하고, 고객 데이터를 확인하고, 정책을 적용하고, 경우에 따라 다른 시스템을 호출한 뒤 결과를 남기는 실행 능력이다. Salesforce가 이를 ‘디지털 노동’이라는 언어로 설명하는 배경도 여기에 있다. 출처: Salesforce Developers, Get Started with Agentforce APIs and SDKs, Agentforce: The AI Agent Platform

Salesforce만의 이야기도 아니다. DoorDash가 에이전틱 커머스에서 보여준 변화도 같은 흐름이다. AI가 실제 업무를 수행하기 시작하면서, 사람 좌석에 요금을 매기던 기존 구조로는 설명하기 어려운 새로운 비즈니스 모델이 여러 산업에서 함께 등장하고 있다. 이런 에이전트가 여러 도구와 시스템을 안전하게 호출하도록 뒷받침하는 기반 기술도 함께 자리 잡는 중이다. 기업 내부에서는 AI Gateway가 모델·도구 호출을 한곳에서 통제하고, 에이전트끼리 작업을 넘길 때는 Agent2Agent 같은 연결 계층이, 외부 서비스와의 표준화된 도구 호출에는 MCP가 쓰인다. 가격 모델의 변화는 이런 실행 기반이 갖춰진 뒤에야 실제로 계약서에 반영될 수 있다.

따라서 질문은 자연스럽게 바뀐다. 사람에게 제공하는 업무 도구라면 좌석 수가 합리적 단위일 수 있다. 반면 AI가 고객 문의를 직접 처리한다면, 기업은 ‘에이전트를 몇 개 활성화했는가’보다 ‘실제로 어떤 업무가 얼마나 안정적으로 끝났는가’를 묻게 된다. Salesforce의 사례는 이 질문에 가격표로 답하려는 시도다. Salesforce는 대표적인 선도 사례이며, 일부 AI SaaS 기업들도 다양한 결과 기반 과금 모델을 실험하고 있다. 다만 그것이 SaaS 전체의 확정된 전환을 뜻하지는 않는다. 에이전트형 소프트웨어가 기존 구독 모델과 충돌하는 지점을 선명하게 보여 주는 사례로 읽는 편이 정확하다.

사람의 도구에서 실행 주체로 바뀌면 원가 곡선도 바뀐다

전통적 SaaS의 추가 사용자는 완전히 공짜가 아니지만, 한 명이 더 로그인한다고 해서 공급자 비용이 매번 크게 늘지는 않는다. 저장공간, 네트워크, 지원, 보안과 같은 비용은 있지만, 일반적인 업무 화면 조회와 기록 입력의 한계비용은 비교적 낮고 예측하기 쉽다. 그래서 연간 또는 월간 좌석 계약이 공급자와 고객 모두에게 편했다.

AI 에이전트는 요청을 받을 때마다 가변비를 만든다. 모델 추론은 물론이고, 대화 맥락을 구성하기 위한 데이터 검색, CRM·주문·결제 시스템 조회, 외부 도구 실행, 권한 확인, 로그 저장, 안전성 검토가 이어질 수 있다. 답변이 부족하면 재질문이나 재시도가 생기고, 불확실한 건은 사람 상담원에게 넘겨야 한다. 고객이 문제를 다시 제기하면 앞선 처리가 ‘해결’이었는지도 재검토해야 한다. 에이전트가 처리량을 늘릴수록 공급자의 비용도 일정 부분 함께 늘어나는 구조다.

이 차이는 모델 API 가격의 하락만으로 사라지지 않는다. 더 저렴한 모델을 쓰더라도, 실패율이 높아 두 번 세 번 실행하거나 시스템 연동이 자주 실패하면 전체 비용은 커질 수 있다. 반대로 상대적으로 비용이 높은 추론을 쓰더라도 첫 시도에 정확히 처리하고 사람이 개입할 일을 줄이면 업무 완료당 비용은 낮아질 수 있다. 실무에서 봐야 할 단위는 ‘입력 토큰 100만 개 가격’이 아니라, 실패와 복구까지 포함한 성공적인 업무 한 건의 비용이다. AI 에이전트의 재무 타당성이 모델 단가표만으로 결론나지 않는 이유다. 참고 사례로, 한 에이전트의 호출당 비용과 성공 결과당 비용이 크게 달라질 수 있음을 지적한 분석은 이 구분의 중요성을 잘 보여 준다. 출처: Your AI Agent Passed Every Eval. Finance Still Killed It

여기서 ‘비용 역전’이 생긴다. 생성형 AI의 단위 추론 비용은 하락할 수 있지만, 운영을 고도화할수록 비추론 비용이 전체의 더 큰 비중을 차지할 수 있다. 예컨대 단순 배송 조회는 고객 식별과 주문 상태 조회, 정형 응답으로 끝날 수 있다. 반면 환불 예외, 결제 오류, 배송지 변경, 약관 해석이 얽힌 문의는 여러 시스템 접근, 정책 검증, 승인, 상담원 이관을 요구한다. AI가 답변 초안을 빨리 만들었다는 사실과 AI가 그 업무를 경제적으로 끝냈다는 사실은 다르다.

실제 업무로 예를 들면 이해가 빠르다. “주문번호 확인해줘” 같은 단순 FAQ는 AI가 데이터베이스를 한 번 조회해 정형 응답을 내놓으면 끝나므로, 사람보다 훨씬 저렴하게 처리된다. 반면 “해외에서 주문한 물건이 파손돼 왔는데, 환불과 재배송 중 뭐가 나은지 상황을 보고 판단해 달라”는 문의는 다르다. 에이전트는 주문 이력·배송 상태·환불 정책을 각각 조회하고(외부 시스템 조회), 파손 사진을 근거로 승인 여부를 여러 단계로 추론하고(다차례 추론), 정책과 어긋나는 답이 나오면 다시 계산하고(재시도), 그래도 판단이 애매하면 결국 사람 상담원에게 넘어간다(상담원 이관). 이 경우 AI가 쓴 추론·조회·재시도 비용에 이관된 뒤 사람이 처음부터 다시 처리하는 비용까지 더해지면, 실제 운영 비용이 애초에 사람 상담원 한 명이 바로 처리했을 때보다 더 높아질 수 있다.

해결 건당 과금은 무엇을 파는 방식인가

Salesforce는 Agentforce Help Agent를 발표하며 몇 분 안에 배포할 수 있고 해결 건수에 대해서만 비용을 청구한다고 설명했다. 회사가 Agentforce를 출시한 뒤 서비스 에이전트를 만든 고객들이 있었고, 이번 사전 구성 Help Agent를 결과 단위로 제시한 것이다. 이 사실은 ‘모든 Agentforce 기능이 언제나 해결 건당 과금된다’는 뜻도, 모든 SaaS가 이 모델로 넘어갔다는 뜻도 아니다. 특정 용도와 제품 구성을 중심으로 결과 단위 가격을 내놓은 선도 사례로 읽는 편이 정확하다. 출처: Salesforce Announces Prepackaged Agentforce Help Agent

여기서 ‘해결’은 “문제를 풀면 과금한다” 정도의 느슨한 개념이 아니다. Salesforce가 결과 단위 과금의 전제로 삼는 것은 AI가 처음부터 끝까지 스스로 처리하고, 사람 상담원에게 이관되지 않으며, 고객이 그 처리를 다시 미해결로 표시하지 않은 경우다. 이 세 조건 중 하나라도 어긋나면 같은 문의라도 ‘해결’로 청구되지 않을 수 있다. 다시 말해 무엇을 해결로 볼 것인가는 단순한 용어 정의가 아니라 계약과 서비스 정책에 따라 청구 금액과 책임 소재를 가르는 중요한 쟁점이 될 수 있다.

해결 건당 과금의 핵심은 공급자가 내부 실행량의 불확실성을 더 많이 떠안는다는 데 있다. 고객은 에이전트가 대화를 몇 번 했는지, 내부적으로 어떤 모델을 몇 차례 호출했는지보다 정의된 결과가 발생했는지를 기준으로 비용을 낸다. 공급자는 같은 해결을 더 적은 재시도와 더 정확한 라우팅으로 달성해야 마진을 지킬 수 있다. 가격 단위가 공급자의 기술 효율과 고객의 업무 성과를 같은 방향으로 묶는 셈이다.

물론 결과 기반은 순수한 단일 모델만을 뜻하지 않는다. Salesforce는 2025년 Agentforce의 유연한 가격 정책과 Flex Credits를 발표하면서, 여러 에이전틱 사용 사례를 하나의 확장 가능한 측정 단위로 다루겠다고 설명했다. 또 일부 Agentforce Coworker 환경에는 좌석 기반 가격이 있으며, 특정 검색은 Flex Credits나 Data Services Credits를 소진하지 않는다는 과금 고려 사항도 문서화했다. Agentforce Vibes 문서에는 요청을 일정 토큰 묶음으로 청구하는 Flex Credits 모델도 나온다. 즉 실제 시장에는 좌석·크레딧·토큰·결과가 섞인 혼합형 설계가 존재한다. ‘해결 건당’은 좌석제를 일괄 대체하는 선언이라기보다, 고객 접점 업무에서 가치 단위를 더 직접적으로 잡으려는 선택지다. 출처: Salesforce Introduces New Flexible Agentforce Pricing, Salesforce Developers, Billing Considerations for Agentforce Coworker, Learn About Agentforce Vibes

네 가지 가격표는 같은 것을 측정하지 않는다

가격 모델을 비교할 때 가장 흔한 오류는 ‘어느 쪽이 더 싸냐’만 묻는 것이다. 각 모델은 다른 대상을 계량하고, 다른 쪽에 변동성 위험을 배분한다. 같은 에이전트라도 어떤 업무를 맡기는지와 데이터·연동 구조에 따라 적합한 단위가 달라진다.

과금 방식	청구 기준	고객이 주로 부담하는 리스크	공급자가 주로 부담하는 리스크	어울리는 업무
좌석 기반	사용자·상담원·관리자 수	사용률이 낮아도 고정 구독료를 낼 수 있음	낮음 — 실제 사용량 급증의 수익 기회를 놓칠 수 있음	사람이 주도하고 AI가 보조하는 내부 업무
사용량 기반	API 호출, 처리량, 저장·전송량 등	사용량 급증에 따른 예산 변동, 사용량과 가치의 불일치	낮음 — 단위 원가 산정과 계측 정확도	호출량이 비교적 예측 가능하고 기계적으로 측정되는 서비스
토큰 기반	입력·출력 토큰 또는 추론 묶음	복잡한 질문과 재시도가 곧 비용 증가로 이어짐	낮음~보통 — 모델 가격 변동, 고객이 비용을 통제하기 어렵다고 느낄 위험	개발자 도구, 생성 작업, 모델 사용량을 직접 관리하는 팀
결과·해결 기반	정의된 업무 완료, 해결된 문의	해결 정의가 모호하면 청구 분쟁과 품질 저하	높음 — 재시도·실패·연동·지원 비용, 처리 효율 저하	해결 여부를 비교적 검증할 수 있는 고객 서비스·정형 업무

좌석 기반은 비용 예측성이 강점이다. 하지만 AI가 야간에도 고객을 응대하며 사람 수와 무관하게 거래량을 처리한다면 좌석 수가 가치의 대리 변수로 약해진다. 사용량 기반과 토큰 기반은 공급자의 실제 원가에 가까운 신호를 고객에게 전달한다. 대신 고객 입장에서는 ‘시스템이 비효율적으로 여러 번 생각한 비용’까지 떠안을 수 있다는 불만이 생길 수 있다.

결과 기반은 이 불만을 뒤집는다. 고객은 결과를 사며, 공급자는 실행 효율을 판다. 그러나 공급자가 비용을 떠안는 만큼 가격은 평균 원가뿐 아니라 실패 가능성, 업무 난이도, 고객별 데이터 품질, 계절성까지 반영해 설계된다. 단순히 결과당 가격을 낮게 제시하는 공급자가 항상 유리한 것이 아니다. 해결 기준을 좁게 잡아 사람 이관을 늘리거나, 어려운 문의를 제외해 해결률을 보기 좋게 만드는 식의 왜곡도 가능하다. 좋은 가격표는 단가표가 아니라, 어떤 업무를 포함하고 누가 실패 비용을 부담하는지 적은 운영 헌장에 가깝다.

‘해결’은 감상이 아니라 계약 가능한 사건이어야 한다

결과 기반 과금의 가장 어려운 부분은 가격이 아니라 계측이다. 고객이 ‘감사합니다’라고 답했다고 해결인가. 주문이 실제로 변경돼야 해결인가. AI가 안내를 마친 뒤 고객이 며칠 뒤 같은 사유로 다시 연락하면 앞선 건은 무효가 되는가. 상담원이 마지막 한 번만 승인했다면 AI 해결, 사람 해결, 공동 해결 중 무엇인가. 이 질문에 답하지 못하면 결과당 단가는 계약서에 넣기 어렵다.

실무에서는 해결을 하나의 대화 종료 이벤트가 아니라 검증 가능한 상태 전이로 설계하는 편이 안전하다. 예를 들어 배송 조회는 ‘본인 확인 완료, 주문 식별, 최신 배송 상태 제공, 추가 요청 없음’처럼 정의할 수 있다. 비밀번호 재설정은 ‘본인 확인, 재설정 절차 실행, 성공 응답 수신’까지를 완료 조건으로 둔다. 환불은 ‘정책 안내’와 ‘환불 요청 접수’와 ‘실제 환불 승인’을 분리해야 한다. 어느 단계를 과금 사건으로 삼는지에 따라 같은 문의의 경제성이 달라진다.

계약과 운영 대시보드에는 적어도 다음 항목이 필요하다.

해결 이벤트의 시작과 종료 조건, 제외되는 문의 유형
AI 단독 해결, 사람 이관 후 해결, 사람 공동 처리의 분류 규칙
동일 고객·동일 사유의 재문의 판단 기간과 기존 청구의 조정 방식
고객 만족도, 재접촉률, 오류율처럼 해결 품질을 보정할 지표
장애·외부 시스템 실패·고객 데이터 오류처럼 귀책을 나눠야 하는 예외 규칙
샘플 감사와 이의 제기, 청구 데이터 보관과 검증 권한

특히 상담원 이관은 숨기면 안 되는 지표다. 에이전트가 쉬운 질문만 해결하고 어려운 사례는 곧바로 사람에게 넘긴다면, 표면적인 자동 해결률만으로 인력 절감 효과를 말할 수 없다. 이관된 티켓의 평균 처리 시간, 이관 전 AI가 남긴 정보의 품질, 사람이 처음부터 다시 물어봐야 하는 비율까지 보아야 한다. 결과 기반 계약은 AI 성능 평가를 재무 지표와 연결하는 장점이 있지만, 그만큼 관측 설계의 수준이 가격의 신뢰도를 결정한다.

‘AI가 사람보다 싸다’는 비교식을 다시 써야 한다

AI 도입 검토에서 가장 위험한 비교는 월 구독료와 상담원 인건비를 곧바로 나누는 방식이다. 사람 비용에는 채용, 교육, 근무 관리, 품질 관리가 포함되고, AI 비용에는 모델·플랫폼 요금 외에도 통합·보안·감사·운영 인력이 든다. 두 쪽의 비용 경계가 다르므로 단순 비교는 결론을 왜곡한다.

더 유용한 식은 다음과 같다.

성공 처리 1건당 총비용
= (AI 사용료 + 추론·도구·데이터 비용 + 통합·운영 인력비
   + 재시도 비용 + 검수 비용 + 이관 후 사람 처리비 + 오류 복구·보상 비용)
  ÷ 품질 기준을 통과한 해결 건수

이 식에서 분모는 단순 종결 티켓 수가 아니다. 재문의, 취소, 잘못된 처리, 불만족으로 인해 다시 열린 건을 어떻게 반영할지 정해야 한다. 분자도 공급자 청구서만이 아니다. 고객사 내부의 프롬프트·지식 관리, 정책 변경 검토, 연결 시스템 유지, 감사 대응 인력까지 포함해야 한다. AI가 상담 시간을 줄이더라도, 오류가 결제·환불·규제 민원으로 번질 위험이 큰 업무라면 복구 비용이 절감분을 상쇄할 수 있다.

두 가지 운영 장면을 비교해 보자. 첫째, 정형화된 배송 조회·계정 정보 변경·예약 확인은 데이터가 정리돼 있고 정답 경로가 짧다. 이 경우 에이전트가 사람보다 빠르고 낮은 비용으로 처리할 가능성이 높다. 둘째, 고객별 예외가 많은 계약 변경, 보상 협상, 민감한 민원은 정보가 여러 시스템에 흩어져 있고 정책 해석·권한·공감이 함께 요구된다. 이 경우 AI가 상담을 보조할 수는 있어도, 스스로 종결하는 비율을 높이려다 재시도와 이관, 오류 복구가 늘 수 있다.

그러므로 구매팀은 ‘AI가 몇 퍼센트 자동화하는가’보다 업무군별로 다음을 따로 측정해야 한다. 첫 답변까지 시간, AI 단독 종결률, 사람 이관률, 재문의율, 이관 티켓의 평균 처리시간, 해결 후 만족도, 예외 처리의 오류율, 성공 해결당 총비용이다. 최근 CRM 가격 책정이 구독·라이선스에서 소비·성과 지표로 옮겨갈 수 있으나 예산 책정의 복잡성도 커진다는 지적은, 이 계측 체계가 왜 필요한지를 보여 준다. 출처: 2026년 CRM 7대 트렌드

고객에게는 리스크 이전, 공급자에게는 운영 혁신의 압력

해결 건당 과금이 고객에게 매력적인 이유는 파일럿의 불확실성을 줄일 수 있기 때문이다. 고객은 에이전트가 실제 문의를 풀지 못하면 큰 사용량 청구를 맞을 우려가 줄어든다. 예산 논의도 ‘월간 토큰 한도’보다 ‘예상 해결 건수와 목표 단가’로 전환할 수 있다. 고객센터 책임자는 자동화의 약속을 인력 계획과 서비스 수준에 연결하기 쉬워지고, 재무·구매 조직은 비용이 사업 성과에 연동되는지 검토할 수 있다.

그러나 고객 리스크가 사라지는 것은 아니다. 결과당 단가가 낮아도 해결 정의가 공급자에게 유리하거나, 복잡한 케이스가 계약 범위 밖으로 빠지면 전체 비용은 여전히 커질 수 있다. 또한 매출 급증, 제품 장애, 계절성 문의가 발생하면 해결 건수도 급증한다. 결과 기반 계약에도 월별 예산 상한, 단계별 단가, 초과 승인, 업무 유형별 분리, 데이터 접근 범위 같은 안전장치가 필요하다. 사용량 가시성과 지출 통제 기능이 에이전틱 AI 운영에서 중요해지는 배경이다. 출처: Claude Enterprise Spend Controls

공급자에게는 더 큰 과제가 생긴다. 좌석제에서는 고객이 기능을 충분히 쓰지 않아도 매출이 비교적 안정적일 수 있다. 결과제에서는 해결률과 운영 효율이 곧 수익성이다. 공급자는 더 좋은 모델을 고르는 데서 멈출 수 없다. 지식의 최신성, 데이터 연결의 신뢰성, 도구 호출의 실패 처리, 고객별 정책 구성, 이관 설계, 문제 유형 분류를 함께 개선해야 한다. 자동화 비율을 높이되 품질을 떨어뜨리지 않는 운영 능력이 마진을 좌우한다.

이 때문에 결과 기반 과금은 제품 전략이기도 하다. 공급자는 해결하기 쉬운 업무부터 제품화하려 할 가능성이 높고, 표준화된 워크플로우·명확한 완료 상태·신뢰할 수 있는 데이터가 있는 영역에서 먼저 성과를 내기 쉽다. 반대로 업무 정의가 모호하고 책임 소재가 민감한 영역은 좌석 기반 보조 도구나 혼합형 과금이 더 현실적일 수 있다. 모든 고객 서비스 업무를 하나의 해결 단가로 묶으려는 접근은 대개 위험하다.

도입 기업이 계약 전에 확인할 일

첫째, AI 도입의 목표 단위를 상담 건수가 아니라 업무 유형으로 쪼개야 한다. ‘고객센터 자동화’는 너무 넓다. 배송 조회, 주소 변경, 구독 해지, 환불 요청, 기술 장애 진단처럼 각 업무의 입력 품질·권한·완료 조건·오류 비용이 다르기 때문이다. 업무별로 사람 처리 시간과 재문의율을 기준선으로 확보한 뒤, AI의 결과를 비교해야 한다.

둘째, 파일럿은 낮은 위험과 명확한 완료 조건을 가진 흐름에서 시작하는 편이 낫다. 단순 FAQ만 시험하면 실제 경제성을 과대평가할 수 있으므로, 운영에서 충분한 비중을 차지하면서도 결과를 검증할 수 있는 업무를 고르는 것이 좋다. 반대로 금전 이동, 법적 판단, 안전 문제처럼 오답의 후속 비용이 큰 업무는 사람 승인과 명확한 이관 규칙을 유지해야 한다. AI의 역할을 ‘완전 대체’와 ‘단순 답변’ 사이의 여러 단계로 설계하는 것이 현실적이다.

셋째, 공급자에게 청구 데이터를 요구해야 한다. 결과당 청구서만 받아서는 개선할 수 없다. 문의 유형별 시도 수, 이관 사유, 재문의, 실패 코드, 사람이 수정한 비율, 처리 시간 분포를 익명화·보안 원칙 아래 검토할 수 있어야 한다. 이것은 공급자의 내부 원가를 캐내려는 요구가 아니라, 고객이 결과의 진짜 품질과 계약 준수 여부를 확인하기 위한 최소한의 관측 장치다.

넷째, 성공 지표와 안전 지표를 함께 둬야 한다. 성공 지표는 해결 건수, 단독 해결률, 처리 시간 단축, 성공 해결당 총비용이 될 수 있다. 안전 지표는 재문의율, 이관율, 오류 수정률, 고객 불만, 정책 위반 가능성이다. 성공 지표만 최적화하면 에이전트가 너무 쉽게 ‘해결’을 선언할 수 있고, 안전 지표만 강조하면 사람에게 모두 넘기는 보수적 시스템이 될 수 있다. 둘 사이의 균형이 가격 협상보다 먼저 정해져야 한다.

다섯째, 혼합형 구조를 기본값으로 검토할 만하다. 플랫폼 접근·관리 기능은 좌석 또는 연간 구독으로, 가변적인 에이전트 실행은 크레딧이나 사용량으로, 명확히 검증 가능한 고객 서비스 업무는 결과 단위로 계약하는 방식이다. Salesforce의 문서와 발표에서도 좌석, Flex Credits, 토큰 묶음, 해결 기반 접근이 공존한다는 점은 하나의 만능 과금 단위보다 업무별 설계가 현실적일 수 있음을 시사한다. 출처: Introducing Flex Credits for Agentforce, Agentforce pricing calculator

가격표가 곧 제품의 약속이 되는 시기

AI 에이전트 시장에서 가격은 뒤늦게 붙는 영업 조건이 아니다. 무엇을 자동화할 수 있는지, 실패하면 누가 비용을 부담하는지, 고객이 무엇을 측정할 수 있는지를 한 번에 드러내는 제품 설계다. 토큰 기반 가격은 투명한 원가 신호를 줄 수 있고 개발자 중심 서비스에 잘 맞을 수 있다. 좌석 기반은 내부 협업 도구의 예측 가능한 예산에 맞을 수 있다. 해결 기반은 고객 서비스처럼 결과가 비교적 명확한 분야에서 강력한 제안이 될 수 있다. 어느 모델도 모든 업무에 우월하다고 단정할 수 없다.

Salesforce의 해결 건당 접근이 주는 더 큰 메시지는 AI가 ‘사용하게 하는 소프트웨어’에서 ‘일을 끝내는 소프트웨어’로 이동할 때, SaaS의 단위 경제도 함께 재정의돼야 한다는 것이다. 고객은 모델이 얼마나 많은 토큰을 읽었는가보다, 문의가 재발하지 않게 처리됐는가와 그 총비용이 얼마인가를 묻게 된다. 공급자는 기능 데모보다 반복 실행의 품질, 연동의 견고함, 예외 처리와 회복 능력으로 수익성을 증명해야 한다.

그 전환은 아직 진행형이다. 일부 기업과 제품이 결과·성과 기반 모델을 도입하거나 실험하는 단계이며, 좌석 기반 구독과 사용량 기반 모델은 많은 환경에서 계속 유효할 것이다. 다만 AI가 실제 업무 흐름 안으로 들어갈수록, 기업의 구매 기준은 ‘얼마나 사용했는가’에서 ‘얼마나 성공적으로 처리했는가’로 이동할 가능성이 높다. AI 도입 담당자가 다음 예산 회의에서 던져야 할 질문도 그래서 단순하다. 모델의 단가가 얼마인가가 아니라, 품질 기준을 만족한 업무 한 건을 끝내는 데 우리의 총비용은 얼마인가다. AI 시대에는 소프트웨어를 얼마나 사용했는가보다, 얼마나 많은 업무를 성공적으로 완료했는가가 새로운 가격 기준으로 부상하고 있다.

참고 출처

함께 읽기: AI 에이전트 실무 도입