AI를 토큰으로 측정하는 것을 멈추세요: 모든 기업에 실제로 필요한 스코어카드

한 기업이 AI 파일럿 (AI pilot) 프로젝트를 시작합니다.

초기 결과는 흥미로워 보입니다.

직원들은 보고서를 더 빠르게 생성합니다. 개발자들은 어시스턴트 (assistant)와 함께 코드를 작성합니다. 고객 지원 팀은 답변 초안을 작성합니다. 재무 팀은 스프레드시트 (spreadsheet)를 요약합니다. 경영진은 수천 개의 프롬프트 (prompt)와 수백만 개의 토큰 (token)이 처리되었음을 보여주는 대시보드 (dashboard)를 봅니다.

그때 CFO (최고재무책임자)가 한 가지 질문을 던집니다:

우리가 돈을 들여 실제로 얻은 것은 무엇인가?

회의실은 조용해집니다.

AI 팀은 모델 가격 책정 (model pricing)을 설명할 수 있습니다.

토큰 소비량을 보여줄 수 있습니다.

활성 사용자 수, 라이선스 (license) 수, 총 프롬프트 수를 보고할 수 있습니다.

하지만 그 어떤 숫자도 회사가 더 유용한 업무를 완료했다는 것을 증명하지 못합니다.

더 저렴한 모델은 형편없는 답변을 다섯 번 만들어낼 수 있습니다.

더 유능한 모델은 단 한 번에 정확한 결과를 만들어낼 수 있습니다.

저렴한 토큰이 더 비용이 많이 드는 결과를 초래할 수 있습니다.

이것이 바로 기업에 더 나은 AI 스코어카드 (scorecard)가 필요한 이유입니다.

가장 유용한 질문은 다음과 같습니다:

토큰 하나당 비용이 얼마인가?

이 아니라:

AI에 투자된 1달러당 얼마나 가치 있고 신뢰할 수 있는 업무가 생성되는가?

이 글은 그 질문에 답하기 위한 실질적인 프레임워크 (framework)를 제시합니다.

이 프레임워크는 네 가지 측정 지표에 집중합니다:

1. 완료된 유용한 업무 (Useful work completed)
2. 성공적인 작업당 비용 (Cost per successful task)
3. 신뢰성 (Dependability)
4. 규모에 따른 가치 (Value at scale)

이 지표들을 결합하면 AI 시스템, 벤더 (vendor), 모델, 에이전트 (agent), 그리고 내부 자동화 프로젝트를 평가하는 더 명확한 방법을 만들 수 있습니다.

기존의 소프트웨어 지표로는 충분하지 않습니다

전통적인 소프트웨어는 종종 채택률 (adoption)을 통해 측정됩니다.

기업들은 다음을 추적합니다:

• 구매된 시트 (seats)
• 월간 활성 사용자 (MAU)
• 로그인 빈도
• 기능 사용량
• 라이선스 갱신
• 제품 내 체류 시간

이러한 지표들은 사람들이 도구를 사용하고 있는지는 보여줄 수 있습니다.

하지만 그 도구가 가치를 창출하고 있는지는 반드시 보여주지 않습니다.

어떤 직원은 매일 AI 어시스턴트를 열지만, 절약하는 시간보다 그 결과물을 수정하는 데 더 많은 시간을 보낼 수도 있습니다.

고객 지원 팀은 수천 개의 답변 제안을 생성하면서도, 동시에 동일한 수의 티켓 (ticket)을 처리하고 있을 수도 있습니다.

코딩 어시스턴트 (coding assistant)는 테스트에 실패하거나 광범위한 검토가 필요한 수백 개의 코드 변경 사항을 생성할 수도 있습니다.

사용량 (Usage)은 입력 (input)입니다.

완료된 작업 (Work completed)은 결과 (outcome)입니다.

이 차이는 매우 중요합니다.

도입률 (Adoption)이 실패를 숨길 수 있습니다

두 팀을 상상해 보십시오.

팀 A

• 주당 500개의 AI 프롬프트 (prompts)
• 활성 사용자 100명
• 주간 도입률 (adoption) 80%
• 완료된 고객 사례 20건

팀 B

• 주당 200개의 AI 프롬프트 (prompts)
• 활성 사용자 40명
• 주간 도입률 (adoption) 40%
• 완료된 고객 사례 60건

팀 A는 도입률 대시보드(adoption dashboard) 상으로는 더 좋아 보입니다.

하지만 팀 B가 더 유용한 작업을 만들어냅니다.

AI의 목적은 AI와의 상호작용을 극대화하는 것이 아닙니다.

그 목적은 결과를 개선하는 것입니다.

더 나은 지표: 달러당 유용한 지능 (Useful Intelligence per Dollar)

실용적인 AI 스코어카드 (scorecard)는 다음과 같이 요약될 수 있습니다:

달러당 유용한 지능 (Useful Intelligence per Dollar)
=
성공적이고 가치 있는 완료된 작업
...

이것은 완벽한 회계 공식이 아닙니다.

이것은 의사결정 프레임워크 (decision-making framework)입니다.

이는 리더들이 방정식의 양면을 검토하도록 강제합니다:

창출된 가치 (Value created)
----------------
소비된 비용 (Cost consumed)

이 지표를 유용하게 만들기 위해서는 기업에 명확한 정의가 필요합니다.

무엇이 유용한 작업으로 간주되는가?

작업이 조직이 가치 있게 여기는 결과를 생성할 때 그 작업은 유용합니다.

예시는 다음과 같습니다:

• 해결된 고객 문제
• 병합된 코드 변경 사항 (code change merged)
• 정확하게 검토된 계약서
• 식별된 적격 영업 리드 (qualified sales lead)
• 준비된 예측 (forecast)
• 처리된 송장 (invoice)
• 완료된 보고서
• 조사된 사기 사례 (fraud case)
• 올바르게 분류된 문서
• 런칭된 마케팅 캠페인

총 비용 (total cost)에는 무엇이 포함되는가?

전체 비용은 API 청구서보다 더 큽니다.

다음 항목들이 포함될 수 있습니다:

• 모델 사용량 (model usage)
• 인프라 (infrastructure)
• 직원의 시간
• 인간의 검토 (human review)
• 재시도 (retries)
• 수정 (corrections)
• 재작업 (rework)
• 통합 유지보수 (integration maintenance)
• 보안 통제 (security controls)
• 모니터링 (monitoring)
• 벤더 수수료 (vendor fees)
• 실패 처리 (failure handling)

이것이 토큰 가격만으로는 오해의 소지가 있을 수 있는 이유입니다.

1. 완료된 유용한 작업을 측정하라

첫 번째 단계는 작업을 식별하는 것입니다.

모델에서 시작하지 마십시오.

워크플로 (workflow)에서 시작하십시오.

질문하십시오:

여기서 "완료(done)"란 무엇을 의미합니까?

그 정의는 작업이 실제로 일어나는 시스템 내에서 측정 가능해야 합니다.

고객 지원 (Customer support)

취약한 지표:

생성된 AI 응답 수

더 강력한 지표:

요구되는 품질 및 응답 시간 목표 내에서 해결된 고객 문제 수

소프트웨어 엔지니어링 (Software engineering)

취약한 지표:

생성된 코드 라인 수

더 강력한 지표:

테스트를 통과하고, 리뷰를 통과하며, 회귀(regression)를 일으키지 않고 병합(merge)된 코드 변경 사항

법무 운영 (Legal operations)

취약한 지표:

요약된 계약서 수

더 강력한 지표:

정확하게 검토되어 마감일 전에 전달된 계약서 수

재무 (Finance)

취약한 지표:

분석된 스프레드시트 수

더 강력한 지표:

예측 패키지가 완료, 조정(reconciled)되어 경영진 검토 준비가 된 상태

AI는 단순히 작업에 관여했다고 해서 가치를 창출하는 것이 아닙니다.

작업이 수용 가능한 결과에 도달했을 때 가치를 창출합니다.

하나의 워크플로(Workflow)로 시작하십시오

대규모 AI 프로그램은 기업이 모든 것을 한꺼번에 측정하려고 시도하기 때문에 실패하는 경우가 많습니다.

더 나은 접근 방식은 다음과 같은 특징을 가진 하나의 워크플로를 선택하는 것입니다:

• 명확한 시작
• 명확한 종료
• 반복되는 볼륨
• 측정 가능한 품질
• 알려진 비즈니스 가치

예를 들어:

워크플로:
비밀번호 재설정 지원 티켓 해결

...

이제 조직은 다음을 비교할 수 있습니다:

• AI 도입 전 완료된 작업
• AI 도입 후 완료된 작업
• AI 도입 전 비용
• AI 도입 후 비용
• 오류율 (error rates)
• 에스컬레이션 비율 (escalation rates)
• 고객 만족도

이는 프롬프트(prompt) 볼륨을 추적하는 것보다 훨씬 더 유용합니다.

결과는 작업이 일어나는 곳에서 측정되어야 합니다

AI 플랫폼은 종종 훌륭한 사용량 분석(usage analytics)을 제공합니다.

하지만 실제 결과는 다른 곳에 존재할 수 있습니다.

예시:

AI 플랫폼은 응답이 생성되었다는 사실은 알 수 있습니다.

하지만 지원 플랫폼은 해당 티켓이 해결되었는지 여부를 압니다.

코드 어시스턴트(code assistant)는 자신이 패치(patch)를 생성했다는 사실은 알 수 있습니다.

CI 시스템은 패치(patch)가 통과되었는지 여부를 압니다.

AI 측정을 시스템 기록(system of record)과 연결하세요.

2. 성공적인 작업당 비용(Cost per Successful Task) 계산

"성공적인 작업(successful task)"이 정의되면, 그 비용이 얼마인지 계산하십시오.

간단한 공식은 다음과 같습니다:

성공적인 작업당 비용
=
전체 워크플로우 비용
...

한 기업이 AI를 사용하여 1,000건의 송장(invoice)을 처리한다고 가정해 봅시다.

월간 비용은 다음과 같습니다:

모델 사용료:              $1,200
인프라(Infrastructure):     $400
사람의 검토(Human review): $3,000
...

만약 900건의 송장이 품질 기준을 충족한다면:

$6,000 ÷ 900
=
성공적인 송장당 $6.67

이것이 의미 있는 비용입니다.

토큰 청구서가 아닙니다.

가장 저렴한 모델이 더 많은 비용을 초래할 수 있는 이유

동일한 작업을 수행하는 두 모델을 비교해 보십시오.

모델 A

시도당 비용:             $0.02
성공률:                   50%
평균 시도 횟수:           2.0
...

모델 B

시도당 비용:             $0.08
성공률:                   95%
평균 시도 횟수:           1.05
...

모델 A는 호출 비용이 더 저렴합니다.

하지만 모델 B의 총비용이 더 낮을 수 있습니다.

사람의 검토 비용이 시간당 $60라고 가정해 봅시다.

이는 분당 $1과 같습니다.

모델 A 예상 비용

모델 비용:
2회 시도 × $0.02 = $0.04

...

모델 B 예상 비용

모델 비용:
1.05회 시도 × $0.08 = $0.084

...

모델 B의 API 호출은 더 비쌉니다.

하지만 그 성공적인 결과물은 훨씬 더 저렴합니다.

이것이 토큰 가격 비교에서 발생하는 핵심적인 실수입니다.

사람의 검토(Human Review)를 포함하십시오

사람의 검토는 종종 AI의 가장 큰 숨겨진 비용입니다.

조직들은 다음과 같이 말할 수 있습니다:

AI가 30초 만에 초안을 작성했습니다.

하지만 직원이 이를 확인하는 데 20분을 소비한다면, 그 작업은 30초 만에 끝난 것이 아닙니다.

20분 30초가 걸린 것입니다.

사람의 검토에는 다음 사항이 포함될 수 있습니다:

• 사실 확인 (checking facts)
• 계산 검증 (validating calculations)
• 출처 비교 (comparing sources)
• 어조 수정 (fixing tone)
• 생성된 코드 테스트 (testing generated code)
• 정책 준수 확인 (checking policy compliance)
• 서식 교정 (correcting formatting)
• 권한 확인 (confirming permissions)
• 보안 리스크 검토 (reviewing security risks)

검토 시간을 측정해야 합니다.

그렇지 않으면, AI 경제성이 실제보다 더 좋아 보일 것입니다.

재시도(Retries) 및 재작업(Rework) 포함

실패한 시도는 다음과 같은 여러 비용을 발생시킵니다:

• 또 다른 모델 호출 (model call)
• 직원의 시간
• 지연 (delay)
• 컨텍스트 스위칭 (context switching)
• 잠재적인 고객 영향

다음 항목을 추적하세요:

작업당 시도 횟수 (Attempts per task)

그리고:

작업당 재작업 시간 (Rework time per task)

한 번의 통과로 성공하는 모델이, 반복적인 프롬프팅 (prompting)이 필요한 더 저렴한 모델보다 더 가치 있을 수 있습니다.

비용으로서의 지연 시간 (Latency) 측정

지연 시간 (Latency)은 단순한 사용자 경험 (user-experience) 지표가 아닙니다.

그것은 경제적 가치를 가집니다.

느린 AI 워크플로 (workflow)는 다음과 같은 문제를 일으킬 수 있습니다:

• 직원의 대기
• 고객의 이탈
• 다운스트림 시스템 (downstream systems)의 차단
• 병렬 작업의 중단
• 더 많은 지원 요청
• 낮은 채택률 (adoption)

어떤 작업에서는 1분의 추가 시간이 중요하지 않을 수 있습니다.

하지만 실시간 지원, 결제 (checkout), 사기 탐지 (fraud detection), 또는 개발자 피드백의 경우, 그 차이는 매우 클 수 있습니다.

따라서 성공적인 작업당 비용은 다음 항목과 함께 평가되어야 합니다:

성공적인 작업당 시간 (Time per successful task)

3. 신뢰성 (Dependability) 측정

가끔씩만 작동하는 시스템은 데모 (demo)에 불과합니다.

일관되게 작동하는 시스템이 비즈니스의 일부가 됩니다.

신뢰성 (Dependability)은 직접적인 경제적 가치를 가집니다.

신뢰할 수 있는 AI는 다음을 줄여줍니다:

• 검토 (review)
• 재시도 (retries)
• 수정 (corrections)
• 에스컬레이션 (escalations)
• 직원의 좌절감
• 고객 리스크

실용적인 프레임워크는 결과물을 세 가지 범주로 나누는 것입니다.

즉시 사용 가능 (Ready to use)

결과물이 수정 없이 요구되는 품질 기준을 충족함.

예시:

• 편집 없이 전송된 응답
• 테스트와 검토를 통과한 코드
• 승인된 계약 분석
• 정확하게 처리된 송장

수정 필요 (Needs correction)

결과물이 유용하지만 인간의 편집이나 다른 AI의 시도가 필요함.

예시:

• 누락된 컨텍스트 (context)
• 잘못된 형식 (formatting)
• 불완전한 답변
• 사소한 코드 수정
• 사실 관계 수정

에스컬레이션 필요 (Needs escalation)

사람이 업무를 인계받아 완료해야 함.

예시:

• 복잡한 고객 불만 사항
• 불확실한 법률 조항
• 고위험 금융 결정
• 보안에 민감한 코드 변경
• 이례적인 예외 상황

이러한 범주들은 운영 현황을 보여주는 그림을 만들어냅니다.

신뢰성 점수 (A Dependability Score)

간단한 점수는 다음과 같을 수 있습니다:

즉시 사용 가능 비율 (Ready-to-use rate)
=
즉시 사용 가능한 작업 (Ready-to-use tasks)
...

가정해 봅시다:

즉시 사용 가능 (Ready to use):      720
수정 필요 (Needs correction):      210
에스컬레이션 필요 (Needs escalation):   70
...

그러면:

즉시 사용 가능 비율 (Ready-to-use rate) = 72%
수정 비율 (Correction rate)   = 21%
에스컬레이션 비율 (Escalation rate)   = 7%

이제 팀은 의도적으로 시스템을 개선할 수 있습니다.

예를 들어:

• 더 나은 컨텍스트 (Context)는 수정 사항을 줄일 수 있습니다.
• 더 나은 라우팅 (Routing)은 에스컬레이션을 줄일 수 있습니다.
• 더 강력한 모델은 즉시 사용 가능 비율을 높일 수 있습니다.
• 더 명확한 작업 경계는 신뢰성 (Reliability)을 높일 수 있습니다.

정확도만으로는 충분하지 않습니다

전통적인 평가 방식은 다음과 같이 보고할 수 있습니다:

모델 정확도 (Model accuracy): 91%

그 수치는 유용하지만 불완전합니다.

그 수치는 다음 사항들을 보여주지 못할 수 있습니다:

• 오류가 심각한지 여부
• 결과가 일관적인지 여부
• 얼마나 많은 수정이 필요한지 여부
• 모델이 언제 에스컬레이션(Escalate)해야 하는지 알고 있는지 여부
• 고객 그룹별로 성능이 변하는지 여부
• 작업이 되돌릴 수 있는지 (Reversible) 여부

95%의 정확도를 보이지만 위험한 행동을 확신을 가지고 수행하는 모델보다, 90%의 정확도를 보이면서 불확실성을 안전하게 에스컬레이션하는 모델이 더 유용할 수 있습니다.

신뢰성 (Dependability)에는 경계에 대한 판단이 포함됩니다.

AI의 경계를 정의하십시오

AI가 초안 작성 단계에서 실행 단계로 넘어가기 전에, 조직은 다음을 정의해야 합니다:

데이터 경계 (Data boundaries)

• 어떤 정보에 접근할 수 있는가?
• 고객 기록을 읽을 수 있는가?
• 금융 데이터에 접근할 수 있는가?
• 비공개 소스 코드를 사용할 수 있는가?
• 외부 제공업체로 데이터를 전송할 수 있는가?

실행 경계 (Action boundaries)

• 이메일을 보낼 수 있는가?
• 데이터베이스 레코드를 변경할 수 있는가?
• 환불을 승인할 수 있는가?
• 소프트웨어를 배포할 수 있는가?
• 사용자를 생성할 수 있는가?
• 결제를 시작할 수 있는가?

인간 검토 경계 (Human-review boundaries)

• 어떤 작업에 승인이 필요한가?
• 시스템은 언제 에스컬레이션해야 하는가?
• 최종 결정권자는 누구인가?
• 실행된 작업을 되돌릴 수 있는가?

경계가 없는 능력은 리스크를 초래합니다.

신뢰성은 작업 유형별로 측정되어야 합니다

모든 AI 워크플로우에 단 하나의 신뢰성 수치를 사용하지 마십시오.

시스템은 일상적인 사례에서는 성능이 좋을 수 있지만, 예외적인 사례에서는 성능이 저조할 수 있습니다.

다음 항목별로 결과를 세분화하십시오:

• 작업 복잡도 (task complexity)
• 고객 유형 (customer type)
• 언어 (language)
• 제품 (product)
• 지역 (region)
• 리스크 수준 (risk level)
• 입력 품질 (input quality)
• 사용된 모델 (model used)

예시:

단순 지원 티켓:             94% 사용 가능
결제 관련 질문:            82% 사용 가능
기술적 장애:               48% 사용 가능
...

이는 기업에 자동화가 안전한 영역이 어디인지 알려줍니다.

또한 인간의 전문 지식이 여전히 필수적인 영역이 어디인지도 보여줍니다.

4. 규모가 커질 때 가치가 개선되는지 측정하십시오

AI 파일럿(pilot)은 100개의 작업에서는 성공적인 것처럼 보일 수 있습니다.