Salesforce AWU
Salesforce Agentic Work Unit이 토큰 사용량을 업무량 지표로 전환하려는 방식을 분석합니다.
핵심 요약
- Salesforce는 AWU를 Agentforce부터 Slack까지 플랫폼이 고객을 대신해 수행한 work volume으로 설명합니다.
- AWU는 고정된 토큰 환산 단위가 아니라 prompt 처리, reasoning chain 완료, tool invocation 같은 discrete task에 가깝습니다.
- Salesforce는 AWU와 Tokens Processed를 함께 추적해 infrastructure scale과 work volume을 분리하려 합니다.
- 한계는 AWU가 Salesforce 내부 정의와 측정에 의존한다는 점입니다.
Salesforce가 바꾸려는 질문
Salesforce의 문제 제기는 명확합니다. 토큰은 모델이 얼마나 말하고 처리했는지 보여줄 뿐, 실제 업무가 얼마나 완료됐는지는 보여주지 못한다는 것입니다.
그래서 AWU는 다음 질문에 답하려 합니다.
| 기존 질문 | AWU식 질문 |
|---|---|
| 토큰을 얼마나 처리했는가 | 고객을 대신해 얼마나 많은 일을 했는가 |
| AI 사용량이 얼마나 늘었는가 | agentic work volume이 얼마나 늘었는가 |
| 모델 비용이 얼마나 드는가 | inference가 work로 얼마나 전환되는가 |
Salesforce 공식 설명에서 AWU는 플랫폼 레벨 지표이며, tokens processed와 함께 추적됩니다. 이 구분은 중요합니다. tokens processed는 인프라 계층의 footprint이고, AWU는 고객 업무량 계층의 지표라는 주장입니다.
AWU가 포착하려는 일
Salesforce는 AWU를 하나의 고정된 기술 이벤트로만 설명하지 않습니다. 오히려 여러 형태의 agentic work를 묶습니다.
| 예시 | 해석 |
|---|---|
| prompt processed | 에이전트가 사용자 입력을 처리 |
| reasoning chain completed | 목표 달성을 위한 reasoning 흐름 완료 |
| tool invoked | Flow, API, CRM action 등 실제 시스템 동작 수행 |
| Slack AI activity | 협업 맥락에서 수행된 AI 업무 |
이 접근은 플랫폼 사업자에게 유리합니다. 고객이 Agentforce, Slack, CRM, Data Cloud를 함께 쓸수록 하나의 AI 업무량 지표로 묶어 설명할 수 있기 때문입니다.
이 흐름에서 AWU는 Tokens Processed보다 고객 업무에 가깝지만, case closed나 lead qualified와
같은 결과 자체는 아닙니다. 그래서 AWU를 내부 outcome event와 조인할 수 있는지가 분석의 핵심입니다.
장점
| 관점 | 장점 |
|---|---|
| 고객 | 토큰보다 업무량에 가까운 언어로 AI 사용을 설명할 수 있음 |
| Salesforce | 플랫폼 전체 AI 활동을 하나의 성장 지표로 제시 가능 |
| 운영팀 | 토큰 절감과 업무량 증가를 분리해 볼 수 있음 |
| 투자자 | Agentforce와 Slack AI 확산을 수치화할 수 있음 |
특히 “토큰은 줄고 AWU는 늘어나는” 상태는 Salesforce가 원하는 이상적인 그림입니다. 더 적은 inference 비용으로 더 많은 업무를 처리한다는 이야기이기 때문입니다.
한계
AWU는 결과 지표가 아니라 업무량 지표에 가깝습니다.
| 한계 | 설명 |
|---|---|
| 성공 판정과 분리 | AWU가 늘어도 고객 문제가 해결됐는지는 별도 측정 필요 |
| 내부 정의 의존 | Salesforce가 어떤 이벤트를 AWU로 세는지 외부에서 완전히 검증하기 어려움 |
| 업무 난이도 차이 | 간단한 Flow 실행과 복잡한 문제 해결이 같은 단위로 보일 수 있음 |
| 고객 KPI 연결 필요 | cost per case, time saved, CSAT 같은 내부 지표와 연결해야 함 |
따라서 AWU는 “AI가 일을 했다”는 플랫폼 지표로는 유용하지만, “AI가 가치를 만들었다”는 최종 지표로는 부족합니다.
해석상의 쟁점
- AWU가 어떤 이벤트를 하나의 일로 보는지는 Salesforce가 agentic labor를 어떻게 정의하는지 보여줍니다.
- AWU 증가가 resolution, time saved, revenue influenced와 연결되지 않으면 업무량 지표가 가치 지표처럼 보이는 착시가 생깁니다.
- 실패한 tool invocation이나 재시도가 AWU에 포함되는지는 “시도된 일”과 “완료된 일”의 경계를 드러냅니다.
- 같은 업무를 더 적은 토큰과 더 적은 AWU로 처리할 때 무엇을 개선으로 볼지는 AWU와 효율성의 관계를 결정합니다.
- AWU와 계약 과금 단위가 다르다는 점은 Salesforce가 가치 서사와 가격 회계를 분리하고 있음을 의미합니다.
분석적 해석
AWU를 내부 대시보드에 넣는다면 단독으로 쓰지 말고 아래 구조로 배치합니다.
| 내부 KPI | Salesforce 지표 연결 |
|---|---|
| Agent work volume | AWU |
| Infrastructure cost | Tokens Processed, model cost |
| Business result | case closed, lead qualified, workflow completed |
| Quality | escalation, rework, approval rejection |
AWU는 토큰을 넘어서는 좋은 논쟁의 출발점입니다. 하지만 조직이 원하는 답은 “몇 AWU를 만들었나”가 아니라 “그 AWU가 어떤 결과를 바꿨나”입니다.
Flex Credit 민감도
AWU는 공개 과금 단위와 다릅니다. 고객이 비용 예측에서 실제로 마주하는 것은 Flex Credits, action,
conversation, license 같은 계약 단위입니다. 아래 계산은 공개 예시인 100,000 credits = USD 500,
Agentforce action = 20 credits 구조를 바탕으로 성공 결과당 action 비용이 어떻게 달라지는지 보여줍니다.
이 계산은 Salesforce 계약 견적을 대체하지 않습니다. 핵심은 action 단가보다 action이 몇 번 쪼개지는가,
재시도와 실패가 얼마나 발생하는가, 성공률을 어떻게 판정하는가가 결과 단위 비용을 크게 바꾼다는
점입니다.