Input Metric vs Output Metric: S&P Global이 AI 성과를 고객 기준으로 재는 법
S&P Global의 기술·전환 책임자 Firdaus Bhathena는 Newsweek 웨비나에서 AI 채택률은 투입 지표일 뿐이고 성과는 고객에게 2년 전엔 못 하던 무엇을 해 주는지로 재야 한다고 말했습니다. 수백 개 실험을 소수 과제로 좁히고 상류 에너지 제품 16개를 에이전트 플랫폼 하나로 묶었으며 비용 절감만 재면 사람들이 그 보상에 맞춰 움직인다고 경고했습니다.
S&P Global의 기술·전환 책임자 Firdaus Bhathena는 AI 성과를 도입률이나 절감액이 아니라 고객에게 2년 전엔 못 하던 무엇을 해 주는지로 재라고 말합니다. 따라 하려면 실험 수백 개를 큰 가치를 낼 소수 과제로 줄이고 과제마다 고객 기준 결과 지표와 중단 조건을 먼저 정해야 합니다.
요약
Newsweek AI 에디터 Adam Mills가 2026년 11월 5일, 전날 열린 AI Impact Forum 웨비나 「What Enterprise AI Looks Like When It Works」를 정리한 기사입니다. 진행은 Ranjit Tinaikar가 맡았고 연사는 S&P Global의 EVP 겸 Chief Technology and Transformation Officer인 Firdaus Bhathena입니다. 그는 FIS Global과 CVS Health에서 기술 조직을 이끌었습니다. S&P Global은 기업과 투자자가 큰 결정을 내릴 때 쓰는 금융 정보와 분석을 파는 회사입니다. Bhathena는 회사가 초기 dabbling phase(이것저것 시험해 보는 실험기)에 AI 과제를 수백 개 벌였다가, 큰 가치를 낼 소수 과제로 좁혔다고 말했습니다. 대표 사례는 석유·가스 탐사 정보를 다루는 상류 에너지 부문입니다. 제품이 16개라 고객은 화면이 제각각인 앱 사이를 오가야 했습니다. 회사는 앱을 하나 더 만들지 않고 AI 에이전트로 여러 업무 흐름을 받아 주는 플랫폼 하나를 만들었습니다.
결과를 보는 그의 기준은 엄격합니다. 상류 에너지 플랫폼은 소수 고객에게 먼저 도입해 반응이 좋았지만 그는 이것이 곧바로 큰 매출을 냈다는 뜻은 아니라고 선을 그었습니다. 효율 향상은 다른 투자의 재원이 될 뿐, 경쟁사도 곧 비슷한 능력을 갖추므로 오래가는 우위가 되지 못한다고 봅니다. 그래서 그는 “AI adoption is an input metric, it’s not an output metric”라고 말하고 경영진에게 지금 AI로 고객에게 2년 전엔 못 하던 무엇을 해 주는지 물었습니다. 비용 절감 위주로 재면 사람들은 그 보상에 맞춰 움직이므로 제품 품질, 고객 필요, 시장 성공을 함께 봐야 한다는 경고도 덧붙였습니다. 실행 원칙으로는 고객 현장 배치 엔지니어, 영업·마케팅 실습 교육, 에이전틱 제품 개발 주기, 성과 없는 실험 중단을 꼽았습니다. 마무리는 보안을 처음부터 넣는 설계, 고객이 묻기 전에 알리는 투명성, 리더의 겸손이었습니다. 아래에서 여섯 원칙의 작동 방식과 두 사례를 보고 실제로 돌릴 때 필요한 기술·현업 디테일을 붙입니다.
핵심 메커니즘
소수 과제 집중: 수백 개 실험을 큰 가치를 낼 몇 개로 좁힌다
과제 수를 늘리는 대신, 큰 가치를 낼 몇 개에 사람과 예산을 몰아주는 운영 방식입니다. 실험기에는 부서마다 작은 과제가 생기고 어느 것도 끝까지 가지 않습니다. Bhathena는 300개보다 의미 있는 3개가 낫다는 취지로 말했습니다. 좁힌 뒤에는 과제마다 분명한 목표를 정하고 목표에 못 미치면 이미 들인 자원이 아까워도 멈춥니다. 실험기가 쓸모없다는 뜻은 아닙니다. 무엇이 되는지 감을 잡는 데 실험기가 필요하고 그다음 고르는 단계가 따로 있어야 합니다. 기사는 S&P Global이 최종적으로 고른 과제의 수와 이름은 밝히지 않았습니다. 작은 예로(가상 예시), 영업 메일 요약, 회의록 정리, 보고서 초안 같은 과제 40개를 고객 제품에 닿는 과제 3개와 사내 공통 도구 1개로 줄이는 식입니다.
Input Metric vs Output Metric: 사용량이 아니라 고객이 새로 할 수 있게 된 일로 잰다
Input metric(투입 지표)은 얼마나 썼는지, output metric(결과 지표)은 그래서 무엇이 달라졌는지를 셉니다. 채택률, 사용자 수, 호출 수는 앞쪽에 속합니다. Bhathena가 내놓은 결과 질문은 하나입니다. 고객에게 2년 전엔 못 하던 무엇을 지금 해 주는가. 비용 절감도 결과처럼 보이지만 그는 절감만 재면 사람들이 절감에 맞춰 움직인다고 경고했습니다. 잘못된 것을 재면 잘못된 결과가 나온다는 말입니다. 그래서 절감과 함께 제품 품질, 고객 필요 충족, 시장에서의 성공을 봅니다. 투입 지표는 버리지 않고 결과가 안 나올 때 원인을 찾는 진단용으로 남깁니다.
플랫폼 통합: 제품 16개를 에이전트 플랫폼 하나로 묶는다
여러 제품을 쓰는 고객의 불편을 앱 하나 더로 풀지 않고 공용 플랫폼 위에서 에이전트가 업무 흐름을 받아 주게 하는 방식입니다. 상류 에너지 부문은 탐사 정보 제품이 16개였고 제품마다 화면이 달라 고객이 앱을 오가야 했습니다. 회사는 여러 워크플로를 유연하게 지원하는 에이전트 기반 플랫폼을 만들어 소수 고객에게 먼저 내놓았습니다. 플랫폼 안에서 에이전트가 정확히 무엇을 하는지는 기사에 없습니다. Bhathena는 고객사들이 오래된 업무 방식을 다시 생각하는 지금이 기존 작업을 빠르게 하는 데서 멈추지 않고 워크플로 자체를 다시 짤 기회라고 봤습니다. 제품이 3~4개 이상이고 고객이 그 사이를 오가며 한 가지 일을 끝내는 회사에 맞는 방식입니다.
Agentic PDLC: 코딩이 빨라지면 PM이 엔지니어 옆으로 온다
Bhathena는 에이전틱 PDLC(product development life cycle, 제품 개발 주기)를 좁은 SDLC(software development life cycle, 소프트웨어 개발 주기)와 구분했습니다. AI가 코드를 빨리 쓰게 해 주면 개발 구간은 짧아지지만 기획과 고객 피드백 반영은 그대로라 병목이 PM 쪽으로 옮겨 갑니다. 고객 피드백이 더 빨리 오고 주기가 짧아지니, 소프트웨어가 나오기를 기다리던 PM이 엔지니어 옆에서 함께 일해야 합니다. 그는 너무 빨리 만들고 있다고 느껴 본 적이 있느냐고 되물으며 이 변화의 속도를 강조했습니다. 개발 조직에 코딩 에이전트를 넣었는데 출시 속도가 그만큼 오르지 않는 회사라면 이 구분부터 볼 만합니다.
Forward-Deployed Engineering: 고객 옆에서 문제를 이해하고 같이 만든다
FDE(forward-deployed engineering, 현장 배치 엔지니어링)는 기술 전문가를 고객사에 붙여 문제를 직접 보고 해결책을 함께 만드는 방식입니다. Bhathena는 여기에 영업·마케팅도 끼어야 한다고 봤습니다. 이들이 기술을 충분히 알아야 고객과 워크플로 재설계를 이야기할 수 있기 때문입니다. 그래서 AI로 무엇이 되는지, 고객이 S&P Global 제품을 쓰는 방식이 어떻게 바뀔지를 직접 손으로 해 보는 실습 교육을 강조했습니다. 설명회형 교육으로는 고객 앞에서 쓸 감이 생기지 않는다는 판단입니다.
Radical Transparency: 보안은 처음부터 넣고 고객이 묻기 전에 알린다
Bhathena는 보안, 컴플라이언스, 복원력을 나중에 덧붙이는 것이 아니라 제품의 기본 기능으로 처음부터 넣어야 한다고 말했습니다. 고객은 공급사가 사이버 위협에 어떻게 대응하는지, 외부 벤더를 어떻게 관리하는지, 취약점이 나오면 어떻게 움직이는지를 점점 더 알고 싶어 합니다. 그가 말한 radical transparency(급진적 투명성)는 이 정보를 고객이 거듭 요청하기 전에 먼저 내놓는 태도입니다. 다만 공개하면 보안 위험이 커지는 세부는 지킵니다. 그는 고객이 가격이나 속도, 제품 때문이 아니라 더 믿을 수 있어서 이 회사를 골랐다고 말하는 장면을 목표로 들었습니다.
통념과 다른 주장
흔히 이렇게 봅니다AI로 얻은 효율 향상이 곧 경쟁 우위이고 생산성 수치가 투자 성과를 보여 준다.
저자는 이렇게 봅니다효율은 경쟁사도 곧 따라오므로 오래가는 우위가 아닙니다. 효율 이득은 다른 투자의 재원으로 쓰고 차별점은 고객이 보내는 신뢰에서 찾아야 합니다.
근거Bhathena는 상류 에너지 플랫폼의 성공을 즉시 매출로 정의하지 않았고 마무리에서 고객이 가격·속도·제품이 아니라 신뢰 때문에 공급사를 고르는 장면을 목표로 들었습니다.
흔히 이렇게 봅니다AI 전환은 경험 많은 리더가 지금까지 통한 방식으로 이끌면 된다.
저자는 이렇게 봅니다지식 노동이 바뀌는 지금 경영진에게 필요한 것은 겸손입니다. 과거 경험이 오히려 약점이 될 수 있고 겸손의 반대는 오만입니다.
근거그는 리더가 가정을 의심하고 새 기술을 배우고 예전 관행을 다시 봐야 한다고 말했고 젊은 직원이 계속 배우는 힘을 기르도록 돕는 일도 리더의 몫으로 꼽았습니다.
저자가 든 사례
상류 에너지 플랫폼: 제품 16개를 에이전트 플랫폼 하나로
- 상황: 석유·가스 탐사 정보를 다루는 제품이 16개이고 화면이 제각각이라 고객이 앱 사이를 오가야 했습니다.
- 한 일: 앱을 하나 더 만들지 않고 AI 에이전트로 여러 업무 흐름을 지원하는 유연한 플랫폼을 만들어 소수 고객에게 먼저 도입했습니다.
- 결과: 초기 고객 반응은 고무적이었습니다. 다만 Bhathena는 곧바로 큰 매출을 냈다는 뜻은 아니라고 밝혔습니다. 도입 고객 수와 사용 지표는 원문에서 밝히지 않았습니다.
- 연결: 플랫폼 통합, Input Metric vs Output Metric.
실험기에서 집중기로: 수백 개 과제를 소수로
- 상황: 초기 실험기에 S&P Global 안에서 AI 과제가 수백 개 돌았습니다.
- 한 일: 큰 가치를 낼 소수 과제에 집중하기로 하고 목표를 분명히 정한 뒤 성과가 없는 실험은 들인 자원과 관계없이 멈추는 원칙을 세웠습니다.
- 결과: 최종 과제 수와 이름, 줄인 비용은 원문에서 밝히지 않았습니다.
- 연결: 소수 과제 집중, Input Metric vs Output Metric.
기술 디테일: 고객 기준 지표를 시스템에 심으려면
아래 필드명, 설정값, 기준은 실행 제안이자 가상 예시이며 S&P Global이 밝힌 구현이 아닙니다.
소수 과제 집중과 결과 지표를 돌리려면 과제마다 한 장짜리 레지스트리 항목을 만들고 투입 지표와 결과 지표를 다른 필드에 나눠 적습니다. customer_capability에는 고객이 새로 할 수 있게 되는 일을 한 문장으로 씁니다. 이 문장을 못 쓰면 그 과제는 사내 생산성 과제로 분류해 따로 관리합니다. kill_criteria에는 날짜와 숫자를 함께 넣어, 분기 리뷰에서 자동으로 판정 대상에 오르게 합니다.
{
"initiative_id": "AX-2027-03",
"owner": "상류 에너지 제품 책임자",
"customer_capability": "탐사 담당자가 화면 전환 없이 한 번에 후보 지역을 비교한다",
"output_metrics": [
{"name": "task_completion_minutes", "baseline": 95, "target": 40},
{"name": "paying_customers_using_workflow", "baseline": 0, "target": 10}
],
"input_metrics": ["weekly_active_users", "agent_calls"],
"cost_metrics": ["infra_cost_per_task"],
"kill_criteria": {"review_date": "2027-03-31", "rule": "output_metrics 중 하나도 목표의 30% 미만이면 중단"},
"security_by_design": ["접근 권한 범위", "감사 로그", "벤더 목록"],
"status": "pilot"
}
플랫폼 통합을 따라 하려면 제품마다 화면을 붙이지 않고 각 제품의 데이터 조회 기능을 API로 감싸 에이전트가 부르는 도구로 등록합니다. 고객 요청을 받는 에이전트는 어느 제품 도구를 부를지 고르고 결과를 한 화면으로 모읍니다. 인증, 권한, 호출 로그는 공용 층에 한 번만 구현해야 Radical Transparency에서 말한 고객의 감사 요구에 답할 수 있습니다. 출시 전에는 고객이 실제로 하던 일 30~50건으로 평가 세트를 만들어 고정하고 모델이나 도구를 바꿀 때마다 같은 세트로 다시 돌려 완료율과 오답을 비교합니다. 에이전트의 제품 호출은 자유 서술 대신 도구 호출(function calling)로 받고 도구 응답은 제품마다 정해 둔 JSON 필드로 고정합니다. 같은 입력을 3회 돌려(temperature 0~0.2) 답이 갈리는 과제는 따로 표시해 사람 검토로 넘깁니다.
FDE 관찰을 데이터로 남기려면 고객사에서 본 업무를 한 건씩 같은 형식으로 적습니다. 필드는 task(고객이 끝내려는 일), steps(거친 단계 수), minutes(걸린 시간), apps_switched(오간 화면 수), pain(막힌 지점), observed_at(관찰 날짜) 정도면 충분합니다. 이 기록이 결과 지표의 기준선이 되고 파일럿 뒤 같은 형식으로 다시 재면 변화가 숫자로 남습니다.
결과 지표는 로그와 따로 모읍니다. 사용 로그는 자동으로 쌓이지만 고객이 새로 할 수 있게 된 일은 과업 시간 측정, 고객 인터뷰, 계약·갱신 데이터에서 나옵니다. 분기 리뷰 대시보드에는 결과 지표를 위에, 투입 지표를 아래 진단 칸에 둡니다.
| 막히는 경우 | 증상 | 대응 |
|---|---|---|
| 결과 지표를 못 정함 | customer_capability가 “업무 효율화”처럼 흐림 | 고객 과업 하나를 동사로 다시 쓰고 못 쓰면 사내 과제로 분류 |
| 사용량만 오름 | 주간 사용자는 늘고 과업 시간은 그대로 | 평가 세트로 실패 유형을 뽑아 도구·데이터 보강 |
| 절감 목표가 행동을 비틂 | 품질 문의가 늘거나 고객 응답이 짧아짐 | 절감 지표에 품질 지표를 짝으로 붙여 함께 판정 |
| 멈추지 못함 | 기한이 지나도 “조금만 더” | kill_criteria를 리뷰 안건에 자동 상정, 연장은 1회만 |
| 보안을 나중에 붙임 | 출시 직전 감사 요구로 일정 지연 | 레지스트리 단계에서 security_by_design 비면 파일럿 불가 |
현업 실행 디테일: 누가, 언제, 무엇을
원문은 과제 선정, 측정, FDE, 실습 교육, 중단 원칙을 경영 원칙으로 제시했습니다. 아래 역할 표, 일정, 기준은 이를 실제로 돌리기 위해 새로 짠 가상 예시입니다.
| 역할 | 맡는 일 |
|---|---|
| CEO 또는 사업부장 | 집중할 과제 3~5개 최종 선정, 중단 결정권 |
| AX 추진 책임자 | 과제 레지스트리 운영, 분기 리뷰 진행, 지표 정의 표준화 |
| 제품 책임자·PM | customer_capability 작성, 엔지니어와 주간 피드백 회의 |
| FDE 2~3명 | 파일럿 고객사에 배치, 고객 과업 관찰과 기준선 측정 |
| 영업·마케팅 대표 | 실습 교육 이수, 고객 대화에서 워크플로 재설계 제안 |
| 보안·컴플라이언스 | 과제별 보안 요구 확인, 고객용 투명성 자료 준비 |
준비물. 지금 진행 중인 AI 과제 전체 목록(담당자, 예산, 시작일), 과제별로 지금 재고 있는 지표, 주요 고객 3~5곳의 대표 업무 흐름, 제품 간 고객 중복 사용 현황, 기존 보안 질의서와 답변 이력이 필요합니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 진행 중 과제 전수 조사, 고객 과업 기준 분류 | 과제 목록, 고객 과제와 사내 과제 구분표 |
| 3~4주 | 집중 과제 선정, 결과 지표와 중단 조건 확정 | 레지스트리 항목, 중단·통합할 과제 목록 |
| 5~10주 | FDE 배치 파일럿, 영업·마케팅 실습 교육 | 고객 과업 기준선과 변화, 교육 이수 기록 |
| 11~12주 | 분기 리뷰에서 계속·확대·중단 판정 | 판정 결정서, 다음 분기 과제 목록 |
현업에 물을 것.
- 이 과제가 성공하면 고객이 새로 할 수 있게 되는 일은 무엇입니까? 한 문장으로 말할 수 있습니까?
- 그 일을 지금 고객은 어떻게 하고 있고 시간과 단계는 얼마나 듭니까?
- 이 과제를 멈추면 누가, 무엇을 잃습니까?
- 절감 목표를 맞추려다 품질이나 고객 응대가 나빠질 지점은 어디입니까?
- 고객이 이 기능의 보안과 벤더 관리를 두고 물을 질문은 무엇이고 답은 준비돼 있습니까?
진행 판정 기준(예시). 결과 지표 가운데 하나라도 목표의 70% 이상이면 확대, 30~70%면 범위를 좁혀 한 분기 더, 30% 미만이면 중단합니다. 사용량이 높아도 결과 지표가 30% 미만이면 중단 대상입니다. 연장은 과제당 한 번만 허용합니다.
AX 적용 제언. 이 원칙이 가장 빨리 먹히는 곳은 AI 과제가 부서마다 수십 개씩 흩어진 대기업입니다. 첫 조치는 새 과제를 더하는 것이 아니라 기존 과제를 고객 과업 기준으로 다시 분류하는 일입니다. 결과 문장을 못 쓰는 과제는 사내 생산성 과제로 묶어 비용 관점에서 따로 관리하고 고객 과제 3~5개에 FDE와 예산을 몰아줍니다. 제품이나 시스템이 여러 개로 나뉜 회사라면 상류 에너지 사례처럼 화면을 하나 더 만들기 전에 공용 에이전트 층을 먼저 검토합니다. 경영진 보고서의 첫 줄도 채택률에서 고객이 새로 할 수 있게 된 일로 바꿉니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 원문 | Newsweek, 2026.11.5 게재, AI 에디터 Adam Mills |
| 행사 | Newsweek AI Impact Forum 웨비나 「What Enterprise AI Looks Like When It Works」, 2026.11.4, 진행 Ranjit Tinaikar |
| 연사 | Firdaus Bhathena, S&P Global EVP 겸 Chief Technology and Transformation Officer(전 FIS Global, CVS Health) |
| 과제 운영 | 실험기에 AI 과제 수백 개, 큰 가치를 낼 소수 과제로 집중, 성과 없는 실험은 중단 |
| 사례 | 상류 에너지 제품 16개를 에이전트 기반 플랫폼으로 통합, 소수 고객 도입, 반응 고무적, 즉시 큰 매출은 아님 |
| 측정 | 채택률은 투입 지표, 결과는 고객에게 2년 전 못 하던 일, 절감만 재지 말고 품질·고객 필요·시장 성공 |
| 조직 | FDE, 영업·마케팅 실습 교육, 에이전틱 PDLC, PM과 엔지니어의 밀착 |
| 신뢰 | 보안·컴플라이언스·복원력을 처음부터, radical transparency, 위험한 세부는 비공개 |
| 리더십 | 겸손, 과거 경험이 약점이 될 수 있음, 젊은 직원의 계속 학습 지원 |
핵심 개념
- Dabbling phase
- 여러 부서가 작은 AI 실험을 동시에 벌이며 무엇이 되는지 감을 잡는 초기 단계입니다.
- Upstream energy
- 석유·가스 산업에서 탐사와 생산을 다루는 앞단 부문입니다.
- Sunk cost
- 이미 써서 되돌릴 수 없는 비용입니다. 이것 때문에 성과 없는 과제를 계속하면 손실이 커집니다.
- Chief Technology and Transformation Officer
- 기술 조직과 전사 전환을 함께 맡는 임원 자리입니다.
- AI Impact Forum
- Newsweek이 기업 AI 리더를 초청해 여는 웨비나 시리즈입니다.
내 메모
TODO: 내 생각 추가
원문은 Newsweek의 「S&P Global Tech Chief Says AI Efficiency Won’t Be Enough, Try Humility」(Adam Mills, 2026.11.5)이며 연사 이력과 행사 정보는 같은 매체의 웨비나 예고 기사 「S&P Global Tech Chief to Break Down What Makes Enterprise AI Work」를 참고했습니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 Bhathena가 웨비나에서 말한 내용을 AX Review가 다시 정리했습니다. 기술·현업 디테일, 작은 예시, 인포그래픽, 표는 새로 작성한 실행 제안이며 S&P Global의 구현이 아닙니다. 전체 내용은 원문에서 볼 수 있습니다.