Stop Inventing New AI Metrics: AI 성과는 기존 사업 지표로 측정하고 옮겨 간 병목을 고친다

AWS의 Colleen Aubrey는 AI 성과를 재려고 새 지표를 만들지 말고 재고, 해결률, 채용 소요 시간처럼 회사가 이미 보는 사업 지표로 재라고 말합니다. 실제로 쓰려면 가장 아픈 결정 하나를 골라 그 지표의 기준선부터 잡아야 합니다. AI는 병목을 다른 단계로 옮겨 놓으므로 하류 공정을 고칠 예산과 사람도 미리 마련해 둡니다.

요약

SiliconANGLE에 2026년 11월 6일 실린 Zeus Kerravala(ZK Research 수석 애널리스트)의 기고 칼럼입니다. 그는 re:Invent를 앞두고 AWS Applied AI Solutions 담당 수석부사장이자 Amazon S-team 일원인 Colleen Aubrey를 인터뷰했습니다. Aubrey는 AWS에 와서 애플리케이션 계층 프로그램 35개를 물려받았습니다. 그중 가장 잘된 사례로 컨택 센터 제품 Amazon Connect를 꼽습니다. Connect에서 얻은 교훈이 지금 Connect Customer, Connect Talent, Connect Health, Connect Decisions로 넓어진 제품군을 이끕니다. 칼럼은 이 경험을 다섯 가지 교훈으로 정리합니다. 기능 따라잡기를 버리고 좁은 결정점에서 시작할 것, AI 전용 ROI 대신 기존 사업 지표로 잴 것, AI가 옮겨 놓은 병목을 따라갈 것, 과업이 아니라 결과를 맡게 할 것, 사람의 일하는 방식에 맞춘 UX를 만들 것입니다.

칼럼이 정리한 Aubrey의 방식을 네 단계로 새로 그림

근거로 든 숫자는 셋입니다. Wells Vehicle Electronics는 3개월 만에 재고를 7% 줄이면서 모니터링하는 SKU를 20개에서 2,000개로 늘렸습니다(AWS 설명). Aubrey의 조직은 올해 소프트웨어 배포 속도를 2배로 높였는데 이득은 코딩 도우미가 아니라 테스트와 파이프라인 같은 하류 공정을 고친 데서 나왔습니다. TE Connectivity는 Connect Decisions를 플래너 2,000명에게 넓혔습니다. Kerravala는 이를 바탕으로 CFO가 이미 추적하는 지표에 묶이지 않는 과제는 투자가 아니라 실험이라고 정리합니다. IT 리더에게는 다섯 가지를 권합니다. 플랫폼 대신 쐐기 하나 고르기, AI ROI 슬라이드 버리기, 하류 수리 예산 잡기, 역할을 결과 중심으로 다시 쓰기, 사용성을 구매 기준에 넣기입니다. 아래에서 다섯 원리와 세 사례를 본 뒤 직접 돌릴 때 필요한 기술·현업 디테일을 붙입니다.

칼럼이 든 예시를 두 칸으로 나눔

핵심 메커니즘

Business Metrics over AI ROI: 이미 있는 지표로 잰다

AI 과제의 성과를 토큰당 수익, 사용자당 프롬프트 수, 도입률 같은 AI 전용 숫자로 재지 않고 회사가 원래 보던 사업 지표로 재는 원칙입니다. Aubrey는 기업들이 AI의 ROI가 얼마냐는 질문에 갇혀 토큰 수익을 들여다본다고 지적합니다. 그가 던지는 질문은 다릅니다. 일하는 방식을 바꿨을 때 핵심 사업 지표가 움직이느냐입니다. 작동은 단순합니다. 과제마다 움직일 사업 지표 하나와 기준선을 기록해 두고 정한 기한 안에 지표가 움직이지 않으면 확대를 멈춥니다. 칼럼이 든 지표는 재고, 해결률, 채용 소요 시간, 사이클 타임입니다. 토큰 비용과 사용량은 버리지 않고 비용 계산과 문제 진단에만 씁니다. 투자 판단에는 사업 지표 1단위를 개선하는 데 든 AI 운영비(예: 재고 1일 감소당 비용)로 환산해 씁니다. 가상 예시로, 고객 상담 AI라면 상담원 한 명당 AI 호출 수가 아니라 첫 통화 해결률과 건당 처리 시간을 성과로 봅니다.

지표에 연결되지 않는 과제는 실험이라는 칼럼의 기준

Wedge, Not Platform: 가장 아픈 결정점 하나에서 시작한다

Wedge(쐐기)는 업무 전체를 한꺼번에 옮기지 않고 사람이 가장 버거워하는 결정점 하나를 골라 거기서 크게 개선하는 진입 방식입니다. 초기 AWS Supply Chain은 모듈 다섯 개로 오래된 ERP 벤더의 기능을 따라잡으려 했습니다. Aubrey가 보기에 앞서기보다 쫓아가는 팀이었습니다. Connect는 반대로 기능 동등성을 포기하고 AWS 백본 위의 음성 품질 하나로 시작해 좁게 넓혀 갔습니다. Aubrey는 이 방식을 공급망에 다시 적용해 고통은 가장 크고 도구는 가장 약한 곳을 찾았고 답은 플래너였습니다. 플래너는 쏟아지는 신호 속에서 늘 불을 끄느라 결정을 내릴 때쯤이면 이미 늦습니다. 이 진단으로 제품을 Connect Decisions로 다시 짰습니다. 쐐기는 결정이 자주 반복되고 늦을수록 비용이 드러나는 곳에 맞습니다. 결정점이 흩어져 어느 하나도 아프지 않은 업무에는 잘 맞지 않습니다.

AWS 안의 두 사례를 나란히 놓음

Bottlenecks Move: AI는 병목을 없애지 않고 옮긴다

AI로 한 단계를 빠르게 하면 그다음 단계의 약점이 새 병목으로 드러난다는 관찰입니다. Amazon은 소프트웨어 개발부터 AI 도구를 넓게 풀었습니다. 처음에는 모두가 이것저것 시도하느라 어수선했습니다. Aubrey는 그 어수선함에서 진짜 배움이 나온다고 봅니다. 코드가 빨리 나오자 먼저 테스트 커버리지 부족이 드러났습니다. 그것을 고치자 파이프라인 건강 문제가 나왔고 이어서 수동 개입을 걷어 내고 배포 속도를 높였습니다. 그 결과 Aubrey 조직의 배포 속도는 올해 2배가 됐습니다. 도구만 사고 이 배관 공사를 건너뛰면 활동량은 늘어도 산출은 제자리라는 것이 칼럼의 결론입니다. 칼럼은 IT 리더에게 데이터 품질, 연동, 승인, 테스트를 고칠 예산과 인력을 배포 전에 잡아 두라고 권합니다.

Aubrey 조직의 올해 경험. 이득은 코딩 도우미가 아니라 하류 수리에서 나옴

Own the Outcome: 과업이 아니라 결과를 맡는다

AI가 과업의 경계를 흐리면 역할과 목표를 과업 목록이 아니라 결과로 정의해야 한다는 원칙입니다. Aubrey의 UX 조직에서는 디자이너가 alpha 환경에 직접 코드를 배포하고 있고 Amazon은 “UX tech”라는 역할을 새로 만들었습니다. 다만 목표 설정과 조직 설계는 아직 따라오는 중이라고 Aubrey는 인정합니다. 팀에 주는 메시지는 분명합니다. 과업을 맡는 것만은 선택지가 아니고 결과를 맡아야 합니다. Kerravala는 과업 중심 직무 기술서가 빨리 낡을 것이라고 봅니다. 그래서 HR과 함께 역할과 성과 기대치를 결과 기준으로 고치되 어떤 팀은 줄고 어떤 팀은 새 기술이 필요하다는 점을 솔직히 말하라고 권합니다.

Aubrey의 UX 조직에서 일어난 변화

Humorphism: AI가 사람의 일하는 방식에 맞춘다

Humorphism은 Aubrey가 Connect 제품군의 설계 철학으로 부르는 말로, 사람이 AI에 맞추지 않고 AI가 사람이 이미 일하는 방식에 맞춰야 한다는 뜻입니다. 그가 가장 걱정하는 것은 사내 프로토타입과 실제 운영 사이의 거리입니다. 팀은 명령을 입력해야 움직이는 인터페이스를 넘어 상황의 단서를 읽고 내린 결정을 기억해 일을 이어 가는 AI를 만들고 있습니다. 목표는 사람들이 쓸 만하다고 느껴 스스로 일하는 방식을 바꾸게 하는 것입니다. Aubrey는 이렇게 말합니다. “Shipping good AI with a bad user experience will fail.” 칼럼은 그래서 설정, 구성, 테스트, 분석, 일상 사용 경험을 모델 성능만큼 무겁게 따지고 기술팀이 아니라 현업 사용자가 어떻게 쓰는지를 벤더에게 물으라고 권합니다.

humorphism: AI가 사람의 일하는 방식에 맞춘다

통념과 다른 주장

흔히 이렇게 봅니다AI는 새로운 기술이니 토큰 사용량, 도입률, 프롬프트 수 같은 AI 전용 지표로 성과를 보고한다.

저자는 이렇게 봅니다새 지표를 만들 필요가 없습니다. 일하는 방식을 바꿨을 때 원래 보던 사업 지표가 움직이는지만 보면 됩니다. CFO가 보는 지표에 묶이지 않으면 실험입니다.

근거Wells Vehicle Electronics 사람들은 토큰을 말하지 않고 운전자본을 말합니다. 3개월에 재고 7% 감소와 모니터링 SKU 100배 확대라는 결과도 그 언어로 나왔습니다(AWS 설명).

측정 대상이 도구에서 사업으로 바뀜

흔히 이렇게 봅니다좋은 AI 코딩 도구를 넓게 배포하면 개발 속도가 오른다.

저자는 이렇게 봅니다AI는 병목을 없애지 않고 하류로 옮깁니다. 도구만 사면 활동은 늘고 산출은 그대로입니다.

근거Aubrey 조직의 배포 속도 2배는 테스트 커버리지, 파이프라인, 수동 개입, 배포 속도를 차례로 고친 결과였고 코딩 도우미 자체에서 나온 것이 아니었습니다.

도구만 사면 활동은 늘고 산출은 제자리

저자가 든 사례

Wells Vehicle Electronics: 재고 7% 감소와 SKU 100배 확대

상황: 제조사 Wells Vehicle Electronics가 재고를 관리했습니다. 칼럼은 이전의 구체적 문제를 밝히지 않았습니다.
한 일: AWS의 공급망 AI를 썼습니다. 해당 문단의 링크는 Connect Decisions 페이지로 이어지지만 본문은 제품명을 밝히지 않았습니다.
결과: 3개월 만에 재고를 7% 줄이면서 모니터링 SKU를 20개에서 2,000개로 늘렸습니다(AWS 설명). 이 회사가 보는 지표는 토큰이 아니라 운전자본입니다.
연결: Business Metrics over AI ROI.

AWS가 전한 수치. 같은 3개월 동안 재고는 7% 감소. 0 기준 비례

Amazon 소프트웨어 개발: 배포 속도 2배는 하류 수리에서 나왔다

상황: Amazon은 AI 도구를 소프트웨어 개발에 먼저, 넓게 풀었습니다. 초기에는 실험이 어수선했습니다.
한 일: 테스트 커버리지, 파이프라인 건강, 수동 개입, 배포 속도 순으로 드러난 병목을 차례로 고쳤습니다.
결과: Aubrey 조직의 올해 배포 속도가 2배가 됐습니다. 비교 기준 기간과 측정 방식은 칼럼에서 밝히지 않았습니다.
연결: Bottlenecks Move.

이득의 출처는 코딩 도우미가 아니라 하류 공정

AWS Supply Chain에서 Connect Decisions로: 플래너라는 쐐기

상황: 초기 AWS Supply Chain은 모듈 다섯 개로 기존 ERP 벤더의 기능을 따라잡으려 했습니다. 현장의 플래너는 신호에 묻혀 늦게 결정했습니다.
한 일: Connect의 방식대로 가장 아프고 도구가 약한 결정점인 플래너에 집중해 제품을 Connect Decisions로 다시 짰습니다.
결과: TE Connectivity가 Connect Decisions를 플래너 2,000명으로 넓혔습니다. 제품군의 Connect Talent는 2026년 9월 정식 출시됐고 초기 고객이 도입 중입니다. 팀은 공격적 확장보다 제품 품질을 먼저 챙기고 있습니다.
연결: Wedge, Not Platform, Humorphism.

Connect Talent는 2026년 9월 정식 출시

기술 디테일: 사업 지표로 재는 AI 과제를 직접 만든다면

아래 필드명, 설정값, 구성은 칼럼에 없는 실행 제안이자 가상 예시입니다.

과제마다 지표 계약서를 데이터로 남깁니다(Business Metrics over AI ROI). 과제 착수 전에 한 레코드로 적고 이 레코드가 없으면 예산을 열지 않습니다. 핵심은 business_metric.owner가 AI 팀이 아니라 그 지표를 이미 관리하는 조직이라는 점입니다. 토큰 비용과 수락률은 activity_metrics_for_debug_only에 따로 둬서 보고서 첫 장에 올라가지 않게 합니다.

{
  "project_id": "AX-PLAN-01",
  "decision_point": "결품 위험 SKU의 발주·재배치 결정",
  "business_metric": {
    "name": "재고 일수",
    "owner": "CFO 조직(FP&A)",
    "source": "ERP 월말 재고 / 일평균 출고",
    "baseline": {"period": "직전 13주", "value": 41.0},
    "target": {"value": 38.0, "by_week": 12}
  },
  "guardrails": ["fill rate 95% 이상 유지", "긴급 운송비 증가 없음"],
  "activity_metrics_for_debug_only": ["추천 수", "수락률", "토큰 비용"],
  "comparison": {"method": "시범 SKU군 vs 대조 SKU군", "check": "주 1회"},
  "stop_rule": "12주 안에 목표 대비 절반도 못 가면 확대 중단"
}

효과는 대조군과 비교해 셉니다. 재고나 해결률은 계절, 프로모션, 공급 사정으로도 움직입니다. 시범 대상(예: SKU군, 상담 큐, 채용 직군)과 비슷한 대조 대상을 정해 같은 기간의 변화를 빼고 봅니다(이중 차분). 대조군을 둘 수 없으면 직전 13주 추세를 연장한 예측치와 비교합니다. 기준선은 재무 조직이 쓰는 원천 테이블에서 뽑아야 나중에 숫자 다툼이 없습니다.

쐐기 결정점에는 결정 지연 시간을 선행 지표로 둡니다(Wedge, Not Platform). 재고 같은 사업 지표는 몇 주 뒤에야 움직입니다. 그 전에 볼 수 있도록 신호 발생부터 조치까지 걸린 시간(signal_to_action_min)을 기록합니다. 가상 예시로, 플래너용 AI는 예외 신호를 영향 금액(재고 금액, 결품 시 매출)으로 정렬해 상위 20건만 먼저 보여 줍니다. 플래너가 조치하면 시각과 판단을 남깁니다. 조치가 빨라지는데 재고가 움직이지 않으면 신호 정렬 기준을 의심합니다.

병목은 이벤트 로그로 따라갑니다(Bottlenecks Move). 작업 단위(코드 변경, 주문, 채용 건)마다 단계별 시작·종료와 대기 시간을 남기면 AI가 앞 단계를 빠르게 한 뒤 어디에 대기가 쌓이는지 보입니다. 주 단위로 단계별 대기 시간 중앙값을 집계하고 가장 긴 단계를 다음 수리 대상으로 정합니다. 프로세스 마이닝 도구가 있으면 같은 로그를 그대로 넣을 수 있습니다.

{
  "work_item_id": "PR-58213",
  "stage_events": [
    {"stage": "ai_draft", "start": "09:02", "end": "09:20"},
    {"stage": "test", "start": "09:20", "end": "11:45", "queue_min": 120},
    {"stage": "review", "start": "13:10", "end": "13:40", "queue_min": 85},
    {"stage": "deploy", "start": "16:00", "end": "16:05", "manual_step": true}
  ]
}

실행 제안(가상 예시). 병목이 옮겨 갈 때마다 다시 돌림

결정을 기억하는 화면을 만듭니다(Humorphism). 사용자가 추천을 받아들이거나 고친 이유를 decision_log에 남기고 다음 추천을 만들 때 같은 대상의 최근 결정을 함께 넣습니다. 명령형 대화창만 두지 말고 사용자가 이미 쓰는 화면(ERP 예외 목록, 상담 화면)에 추천을 붙입니다. 사용성은 추천 뒤 조치까지 걸린 클릭 수와 시간, 추천 무시 비율로 잽니다.

막히는 경우	증상	대응
사업 지표가 너무 늦게 움직임	12주 판정 때 신호가 약함	결정 지연 시간 같은 선행 지표를 함께 보고, 판정 기한을 지표 주기에 맞춤
대조군 오염	시범팀 방식이 대조팀으로 번짐	대조군을 다른 사이트나 직군으로 두고, 안 되면 추세 예측과 비교
활동 지표가 다시 보고서에 오름	도입률이 성과처럼 보고됨	보고 양식 첫 줄을 사업 지표로 고정, 활동 지표는 부록
병목 수리 예산 없음	AI 단계만 빨라지고 대기 증가	착수 때 하류 수리 몫을 예산 항목으로 분리
로그 부재	어디가 막혔는지 모름	착수 2주 안에 단계별 이벤트 로그부터 연결

현업 실행 디테일: 누가, 언제, 무엇을

칼럼은 IT 리더에게 다섯 가지를 권합니다. 아래 역할, 일정, 판정 기준은 그 권고를 바탕으로 새로 짠 가상 예시입니다.

역할	맡는 일
사업 오너(지표 주인)	움직일 지표와 목표 확정, 쐐기 결정점 선택, 판정
FP&A·재무	기준선 산출 방식 검증, 중간 점검, 효과 확인 서명
현업 사용자 3~5명	결정점 인터뷰, 시범 사용, 추천 무시 사유 기록
IT·데이터	이벤트 로그 설계, 시스템 연동, 하류 병목 수리
HR	결과 기준 역할 정의와 성과 목표 개정
AX 추진 조직	지표 계약서 관리, 과제 포트폴리오 재심사

준비물. 진행 중인 AI 과제 목록과 각 과제가 보고하는 지표, 후보 결정점의 최근 13주 사업 지표 원천 데이터, 그 업무의 단계별 처리 기록, 현재 직무 기술서와 성과 목표, 검토 중인 벤더의 데모 계정이 필요합니다. 벤더 데모는 기술팀이 아니라 실제 현업 사용자가 직접 써 보게 합니다.

기간	할 일	산출물
1~2주	결정점 인터뷰, 지표 계약서 작성, 기준선 산출, 이벤트 로그 설계	지표 계약서, 기준선, 대조군 정의
3~6주	쐐기 결정점에서 시범 운영	선행 지표 추이, 추천 수락·무시 기록
7~10주	드러난 하류 병목 수리, 역할 초안	단계별 대기 시간 변화, 결과 기준 역할 초안
11~12주	사업 지표 효과 확인, 판정	확대·보완·중단 결정서

가상 예시 일정. 1~2주 기준선, 3~6주 시범, 7~10주 하류 수리, 11~12주 판정

현업에 물을 것.

하루에 가장 늦게 내려서 손해를 보는 결정은 무엇이고 늦는 이유는 신호가 많아서인가요, 정보가 없어서인가요?
그 결정의 결과는 어느 사업 지표에 찍히고 그 지표는 누가 매달 보나요?
AI가 이 단계를 절반 시간에 끝내면 다음에 일이 쌓일 곳은 어디인가요?
지금 직무 기술서에 적힌 과업 중 AI가 대신하면 남는 책임은 무엇인가요?
새 도구를 쓰려고 지금 쓰는 화면을 떠나야 하나요?

진행 판정 기준(예시). 12주 안에 사업 지표가 대조군 대비 목표의 절반 이상 움직이고 가드레일 지표가 나빠지지 않으면 다음 결정점과 다른 사이트로 넓힙니다. 선행 지표는 좋아졌는데 사업 지표가 그대로면 하류 병목을 찾아 6주 더 봅니다. 선행 지표도 그대로면 결정점 선택을 다시 합니다. 도입률이나 토큰 사용량만 올랐다면 성과로 인정하지 않습니다.

AX 적용 제언. 먼저 진행 중인 AI 과제를 모두 CFO 지표 하나씩에 연결해 보고 연결되지 않는 과제는 실험 예산으로 따로 분리하는 포트폴리오 재심사부터 시작하길 권합니다. 첫 쐐기로는 수요·공급 플래너의 예외 처리, 상담 폭주 시 상담원 응대, 채용 담당자의 후보 선별처럼 신호에 묻혀 결정이 늦는 자리가 좋습니다. 과제 예산을 짤 때 AI 도구 비용과 별도로 하류 수리 몫을 처음부터 잡고 HR을 착수 회의에 넣어 역할 개정을 시범과 같은 속도로 진행합니다. 벤더 수치(재고 7%, SKU 100배)는 자사 대조군 비교로 다시 재야 합니다.

원문 사례

항목	내용
원문	SiliconANGLE 기고 칼럼, 2026.11.6, Zeus Kerravala(ZK Research). re:Invent(11.30~12.4) 전 인터뷰
화자	Colleen Aubrey, AWS Applied AI Solutions 수석부사장, Amazon S-team, Amazon 근무 20년 이상
출발점	애플리케이션 계층 프로그램 35개 인수, 최고 성공 사례 Amazon Connect
제품군	Connect Customer, Connect Talent, Connect Health, Connect Decisions
기능 따라잡기	초기 AWS Supply Chain 모듈 5개로 ERP 기능 동등성 추구 → 플래너 중심 Connect Decisions로 재편
측정	AI ROI·토큰 수익 대신 기존 사업 지표, CFO 지표에 묶이지 않으면 실험
Wells Vehicle Electronics	3개월에 재고 7% 감소, 모니터링 SKU 20 → 2,000(AWS 설명)
병목 이동	테스트 커버리지 → 파이프라인 → 수동 개입 → 배포 속도, 올해 배포 속도 2배
역할	디자이너의 alpha 코드 배포, UX tech 역할 신설, 과업이 아니라 결과를 맡음
UX	humorphism, 단서를 읽고 결정을 기억하고 일을 이어 가는 AI
확산	TE Connectivity 플래너 2,000명, Connect Talent 2026년 9월 정식 출시
IT 리더 권고	쐐기 선택, AI ROI 슬라이드 폐기, 하류 수리 예산, 결과 중심 역할, 사용성을 구매 기준에

핵심 개념

S-team: Amazon 최고 경영진 협의체입니다. Aubrey가 회사 전략 결정에 참여하는 위치라는 뜻입니다.
Feature parity: 경쟁 제품과 기능 목록을 똑같이 맞추는 것을 목표로 삼는 개발 방식입니다.
AI pilot purgatory: 시범 과제가 성과를 증명하지 못해 확대도 중단도 못 하고 머무는 상태를 가리키는 업계 표현입니다.
운전자본: 재고와 매출채권에서 매입채무를 뺀, 영업에 묶여 있는 돈입니다. 재고가 줄면 줄어듭니다.
SKU: Stock Keeping Unit. 재고를 관리하는 최소 품목 단위입니다.
re:Invent: AWS가 매년 여는 연례 개발자·고객 행사입니다.

내 메모

TODO: 내 생각 추가

원문은 SiliconANGLE의 「AWS’ Colleen Aubrey: Stop inventing new AI metrics, it’s your business metrics that matter」(Zeus Kerravala 기고, 2026.11.6)입니다. 필자가 AWS 임원을 인터뷰해 쓴 칼럼입니다. 재고 7%, SKU 20 → 2,000, TE Connectivity 플래너 2,000명 같은 고객 수치는 AWS가 전한 내용입니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 칼럼 내용을 AX Review가 다시 정리했고 IT 리더 권고 다섯 가지는 필자의 정리입니다. 핵심 개념의 뜻풀이는 일반적인 정의로 보탰습니다. 지표 계약서와 이벤트 로그 JSON, 대조군 비교 방식, 선행 지표, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽은 칼럼에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 내용은 원문 페이지에서 볼 수 있습니다.