Scale-Ready AI Mandate: 'AI 우선' 지시를 확장 가능한 실행으로 바꾸는 데이터 준비 순서
Capital One Software 제품 총괄 Prashant Prahlad는 AI 확장을 막는 것이 기술보다 권한 없는 'AI 우선' 지시와 데이터 준비 부족이라고 봅니다. 부서 횡단 타이거 팀과 사용 사례 하나로 데이터를 진단하는 순서를 정리하고 0·3·5점 준비도 채점표와 6주 진단 일정을 붙였습니다.
"AI 우선"이라는 지시만으로는 AI가 확장되지 않습니다. 실행 권한과 데이터 기반이 함께 있어야 합니다. Capital One Software는 부서 횡단 타이거 팀을 꾸리고 사용 사례 하나를 골라 거꾸로 데이터를 점검하라고 권합니다. 따라 하려면 권한을 가진 스폰서부터 정하고 첫 사용 사례를 성과 과제가 아닌 데이터 진단 도구로 써야 합니다.
요약
CIO Dive의 Paige Gross 기자가 2026년 10월 27일 Capital One Software의 제품 총괄 SVP Prashant Prahlad를 인터뷰한 기사입니다. Capital One Software는 Capital One의 기업용 B2B 소프트웨어 사업으로, 고객사가 AI 확장에 맞게 데이터를 준비하고 데이터 전환이나 클라우드 이전을 하도록 돕습니다. Prahlad는 복잡한 데이터 자산, 컴퓨트 확보, 시스템 통합 같은 기술 과제가 많은 기업에서 오히려 작은 문제라고 말합니다. 더 큰 걸림돌은 조직입니다. 많은 기업이 AI를 먼저 쓰라는 지시는 받았지만 그 지시를 실행할 권한은 없습니다. 부서들이 같은 목표를 향해 일하지만 공동의 인센티브는 없습니다.
Prahlad는 AI가 얼마나 넓게 퍼질 수 있는지를 데이터 기반이 정한다고 봅니다. 기사는 최근 AI 프로젝트 실패율이 오른 원인을 기술 한계가 아닌 데이터 준비 부족으로 본 TechTarget 보고를 함께 인용합니다. 그가 권하는 출발점은 두 가지입니다. 데이터를 찾고 시험할 부서 횡단 전문가 모임인 타이거 팀(tiger team, 특정 과제를 위해 꾸린 소수 정예 팀)을 만들고 사용 사례 하나를 골라 거기서 거꾸로 데이터 준비도·거버넌스·보안 요구를 점검합니다. 한 고객사는 이렇게 사용 사례 하나로 데이터를 평가하다가 중앙 데이터 전략이 없다는 사실을 발견했습니다. 그래서 7개 사업부의 데이터 관리를 한곳으로 모으는 팀을 새로 만들었습니다. 아래에서는 이 순서를 개념별로 풀고 사용 사례 하나로 데이터를 진단할 때 필요한 채점표, 역할, 6주 일정을 덧붙였습니다.
핵심 메커니즘
Mandate without authority: 지시는 있고 권한은 없는 상태
무엇인가. 경영진이 “AI 우선”을 선언했지만 현업 팀에 데이터 접근, 예산, 우선순위를 바꿀 권한을 주지 않은 상태입니다. Prahlad는 고객사들이 이 지점에서 조직을 한데 모으는 데(organizational rallying) 애를 먹는다고 말합니다.
어떻게 작동하나. 현장에서는 흔히 이런 흐름이 생깁니다. 지시가 내려오면 부서마다 각자 AI 과제를 시작합니다. 하지만 데이터는 다른 부서 시스템에 있고 그 부서는 데이터를 내줄 이유도 의무도 없습니다. 인센티브가 맞지 않으니 공동 과제는 협의에서 멈추고 부서별 시범만 늘어납니다. 그 결과 시범은 많은데 확장된 것은 없는 상태가 됩니다.
언제 점검하나. 시범 과제 수는 늘어나는데 전사로 넓힌 사례가 없을 때, 혹은 데이터 요청이 다른 부서 승인에서 몇 주씩 걸릴 때 이 상태를 의심합니다.
Data foundation: 데이터 기반이 확장의 상한을 정한다
무엇인가. AI가 얼마나 넓게 퍼질 수 있는지는 모델보다 데이터의 위치와 소유자, 신뢰도, 꺼내는 경로에 달려 있다는 관점입니다.
어떻게 작동하나. 한 부서 안에서 돌아가는 시범은 그 부서 데이터만으로 됩니다. 다른 사업부, 다른 시스템으로 넓히는 순간 데이터 정의가 다르고 소유자가 불분명하며 접근 경로가 없다는 문제가 한꺼번에 드러납니다. 기사는 이런 데이터 준비 부족이 최근 실패율 상승의 원인이라는 TechTarget 보고를 근거로 듭니다.
ROI와의 관계. 기사는 ROI 측정이 어려운 이유도 같은 데서 찾습니다. 정확하게 재려면 기반이 먼저 갖춰져야 합니다. 시스템을 실제 운영에 올리고 민감한 데이터를 넣어 시험해야 합니다. 그 사이에도 CIO는 이사회에 가치를 보고해야 하고 많은 기업이 아직 AI 지출의 타당성을 입증하지 못했습니다. 직원이 고위 리더보다 AI를 덜 믿는다는 CIO Dive의 다른 기사도 함께 소개합니다.
Tiger team: 데이터를 찾고 시험하는 부서 횡단 팀
무엇인가. 여러 부서의 전문가를 모아 데이터가 어디 있는지 찾고 실제로 쓸 수 있는지 시험하는 작은 팀입니다. Prahlad는 이것을 좋은 출발점으로 봅니다.
어떻게 작동하나. 지시만 있고 권한이 없는 문제를 팀 구성으로 푸는 방식입니다. 데이터를 가진 부서, 데이터를 쓰려는 부서, 보안을 책임지는 부서가 한 팀에 들어오면 데이터 요청이 부서 간 결재가 아니라 팀 안의 작업이 됩니다. 원문은 어떤 직무를 넣을지까지는 밝히지 않았습니다. 아래 그림은 실제로 꾸릴 때의 구성 예입니다.
Work backward from one use case: 사용 사례 하나에서 거꾸로 점검
무엇인가. 전사 데이터를 한꺼번에 정비하지 않고 사용 사례 하나를 정한 뒤, 그 사례에 필요한 데이터만 따라가며 준비도를 점검하는 방식입니다.
어떻게 작동하나. Prahlad가 드는 예는 한 사업 부문에 챗봇을 배치하는 경우입니다. 챗봇이 답하려면 어떤 데이터가 필요한지 정하고 그 데이터의 준비도, 거버넌스, 보안 요구를 하나씩 확인합니다. 범위가 좁으니 빈틈이 구체적으로 보입니다. “데이터 품질이 낮다” 같은 막연한 진단 대신 “이 시스템의 이 필드는 소유자가 없다”처럼 고칠 수 있는 목록이 나옵니다.
언제 쓰나. 어디서부터 데이터를 정비할지 합의가 안 될 때 씁니다. 첫 사용 사례의 목적은 성과보다 진단에 둡니다.
Signal vs noise: 벤더 포화 속에서 기존 제품을 먼저 본다
무엇인가. 효과를 크게 약속하는 AI 벤더가 쏟아지는 상황에서, 새 도구를 들이기보다 이미 쓰는 제품을 AI에 맞게 준비하는 편이 나은 경우가 많다는 판단입니다.
어떻게 작동하나. AI는 조직 곳곳에서 동시에 생겨납니다. 부서마다 다른 벤더를 들이면 중앙 팀이 무엇이 진짜 효과인지 가려내기 어렵습니다. 기존 제품을 기준으로 삼으면 데이터와 통합 경로를 다시 쓸 수 있고 비교할 대상도 줄어듭니다.
통념과 다른 주장
흔히 이렇게 봅니다기술 인력이 많은 큰 조직일수록 AI 확장에서 앞서 있다.
Prahlad는 이렇게 봅니다출발점은 조직마다 크게 다르고 기술팀 규모가 아니라 AI를 얼마나 의도적으로 도입했는지와 어떤 지시를 받아 왔는지가 갈라 놓습니다.
근거AI에서 앞서 있을 것으로 보이는 기관 중에도 예상만큼 나아가지 못한 곳이 있다고 말합니다. 그의 표현으로는 "It depends on their intentionality in adopting AI"입니다.
흔히 이렇게 봅니다AI 확장의 걸림돌은 컴퓨트, 통합 같은 기술 과제다.
Prahlad는 이렇게 봅니다기술 과제는 오히려 작은 문제이고 권한 없는 지시와 데이터 준비 부족이 더 크게 막습니다.
근거고객사들이 조직을 하나로 모으는 데서 막힌다는 현장 관찰과, 실패율 상승을 데이터 준비 부족으로 설명한 TechTarget 보고를 듭니다.
저자가 든 사례
익명 고객사: 사용 사례 하나로 시작해 7개 사업부 데이터를 모으다
| 구분 | 내용 |
|---|---|
| 상황 | 최근 고객사 한 곳. 회사명과 업종은 원문에서 밝히지 않음 |
| 한 일 | 사용 사례 하나를 정해 그 사례 기준으로 데이터를 평가 |
| 결과 | 중앙 데이터 전략이 없다는 사실을 발견하고 7개 사업부의 데이터 관리를 한곳으로 모으는 팀을 신설. Prahlad는 정렬 과정이 쉽지 않았지만 사용 사례 하나가 빈틈을 보여 줬다고 설명 |
| 연결 | Work backward from one use case, Data foundation |
기술 디테일: 사용 사례 하나로 데이터 준비도를 재려면
아래는 원문에 없는 실행 제안입니다. 원문이 예로 든 “한 부문 고객 응대 챗봇”을 기준으로 씁니다.
Work backward를 돌리려면 먼저 챗봇이 받아야 할 질문 100~200개를 현업에서 모읍니다. 질문마다 정답과 그 정답이 나오는 원천(시스템명, 문서 ID, 테이블·필드)을 적은 평가 세트(golden set)를 만듭니다. 이 원천 목록이 곧 점검할 데이터 목록입니다. 질문에서 데이터로 거슬러 올라가기 때문에 쓰지 않을 데이터를 정비하는 일이 생기지 않습니다.
타이거 팀이 데이터를 기록할 때는 원천마다 같은 필드로 적습니다. 사업부마다 형식이 다르면 7개 사업부를 비교할 수 없습니다.
{
"use_case": "card-servicing-chatbot",
"source_id": "crm.case_notes",
"line_of_business": "LOB-3",
"owner": "고객지원 데이터 담당",
"access_path": "read-only API",
"sensitivity": "PII",
"masking": "partial",
"freshness_hours": 24,
"quality_check": "sampled-200",
"readiness_score": 3,
"blocker": "소유자 승인 절차 없음"
}데이터를 시험할 때는 평가 세트 질문을 검색 기반 생성(RAG) 시제품에 넣고 답변이 올바른 원천 문서를 인용했는지 봅니다. 같은 질문을 3회씩 돌려 답이 흔들리는 질문을 따로 표시합니다. 흔들림의 원인은 대개 모델이 아니라 같은 내용이 사업부마다 다르게 적힌 원천 문서입니다. 시제품은 temperature 0, 모델 버전 고정, 검색 상위 5개 문서(top-k 5)로 설정해 데이터 차이만 드러나게 합니다. 근거 문서 인용 비율과 정답률을 원천별로 집계하면 어느 데이터부터 고칠지 순서가 나옵니다.
거버넌스와 보안은 시제품 단계에서 함께 확인합니다. 챗봇 계정이 읽을 수 있는 범위를 원천별로 제한하고 민감 정보 필드는 마스킹 여부를 기록합니다. 프롬프트로 권한 밖 데이터를 끌어내려는 시험 질문 20~30개를 평가 세트에 섞어 둡니다.
| 막히는 경우 | 증상 | 대응 |
|---|---|---|
| 데이터 소유자가 없음 | 접근 요청이 몇 주째 멈춤 | 스폰서가 원천별 소유자를 지정하고 결정 기한을 둠 |
| 같은 용어를 사업부마다 다르게 씀 | 같은 질문에 답이 흔들림 | 용어 정의표를 만들고 원천 문서에 정의 ID를 붙임 |
| 민감 정보가 섞인 원천 | 시험 자체가 보류됨 | 마스킹한 표본으로 먼저 시험하고 운영 전 재심사 |
| 부서마다 따로 벤더 도입 | 비교 기준이 서로 다름 | 평가 세트를 공용으로 두고 같은 기준으로 비교 |
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 맡는 일 |
|---|---|
| 경영 스폰서(CIO 또는 CDO) | 타이거 팀에 데이터 접근 권한을 문서로 위임, 부서 간 이견 결정 |
| 사용 사례 오너(현업 부문장) | 챗봇이 받을 질문과 성공 기준 정의 |
| 사업부 데이터 담당 | 원천 데이터의 뜻과 소유자 확인, 접근 승인 |
| 데이터 엔지니어 | 원천 연결, 표본 추출, 준비도 기록 |
| AI 엔지니어 | 시제품과 평가 세트 운영 |
| 보안·컴플라이언스 | 민감 정보 분류, 접근 통제와 보안 시험 기준 |
준비물과 회의. 스폰서는 매주 30분 타이거 팀 점검에 들어와 막힌 데이터 요청을 그 자리에서 결정합니다. 시작 전에는 스폰서가 서명한 권한 위임 문서, 사용 사례 한 개의 범위 정의서, 현업이 모은 실제 질문 100~200개, 관련 시스템 목록과 담당자 연락처가 필요합니다.
현업에 물을 것.
- 이 사용 사례에 필요한 데이터 중 우리 부서 밖에 있는 것은 무엇이고 누가 승인하나요?
- 같은 고객이나 상품을 사업부마다 다른 이름이나 코드로 부르고 있나요?
- 지금 데이터 요청 한 건을 처리하는 데 며칠이 걸리나요?
- 이 사용 사례에 이미 쓰고 있는 제품 중 AI 기능을 붙일 수 있는 것은 무엇인가요?
진행 판정 기준(예시). 6주 뒤 세 가지를 봅니다. 필요한 원천의 80% 이상이 준비도 3점 이상이고 평가 세트 정답률이 현업이 정한 기준을 넘고 보안 시험 질문에서 권한 밖 데이터가 한 건도 나오지 않아야 넓힙니다. 원천 여러 곳이 소유자 없음으로 막혔다면 확대보다 고객사 사례처럼 전사 데이터 관리 조직부터 논의합니다.
AX 적용 제언. 계열사나 사업부가 여럿인 국내 그룹사는 지주사나 그룹 IT가 “AI 우선”을 선언하고 계열사별 과제를 모으는 방식이 흔합니다. 이 구조에서 먼저 정할 것은 과제 목록이 아니라 권한입니다. 누가 사업부 데이터 접근을 결정하는지를 문서로 정하고 그 권한을 가진 스폰서 아래 타이거 팀을 둡니다. 첫 사용 사례는 효과가 가장 클 과제보다 여러 사업부 데이터를 건드리는 과제를 고르는 편이 낫습니다. 그래야 데이터 빈틈이 한 번에 드러납니다. 진단 결과는 중앙 데이터 조직을 만들지, 사업부별 소유 체계를 정비할지 결정하는 근거로 씁니다. 새 벤더 검토는 이 진단이 끝난 뒤 같은 평가 세트로 기존 제품과 나란히 비교합니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 기사 | CIO Dive, Paige Gross, 2026.10.27 |
| 인터뷰 대상 | Prashant Prahlad, Capital One Software 제품 총괄 SVP |
| 핵심 주장 | 기술보다 조직 정렬과 데이터 준비가 AI 확장을 막음 |
| 조직 문제 | AI 우선 지시는 있으나 실행 권한이 없고 부서별 인센티브가 다름 |
| 데이터 | 데이터 기반이 확장 범위를 정함. 실패율 상승을 데이터 준비 부족으로 본 TechTarget 보고 인용 |
| 신뢰·ROI | 직원이 고위 리더보다 AI를 덜 신뢰한다는 기사, 대부분 조직이 비용·생산성보다 통찰·의사결정에서 AI 효과를 본다는 기사 인용 |
| 벤더 | 벤더 포화, AI에 맞게 준비할 수 있는 기존 제품이 나은 경우가 많음 |
| 권고 | 부서 횡단 타이거 팀, 사용 사례 하나에서 거꾸로 데이터·거버넌스·보안 점검 |
| 고객사 예 | 사용 사례 하나로 평가, 중앙 데이터 전략 부재 발견, 7개 사업부 데이터 관리 통합 팀 신설 |
| 준비도 | 큰 기술팀이 곧 앞서 있다는 뜻은 아님. 도입의 의도성과 지시 이력에 달림 |
핵심 개념
- AI-first mandate
- 경영진이 AI를 우선 적용하라고 내린 지시. 권한과 인센티브가 함께 오지 않으면 부서별 시범만 늘어납니다.
- data readiness
- 특정 용도에 데이터를 바로 쓸 수 있는 정도. 위치, 소유자, 품질, 접근 경로, 민감 정보 처리로 나눠 봅니다.
- line of business
- 기업 안의 사업 부문 단위. 원문 고객사는 7개 사업부의 데이터 관리를 한곳으로 모았습니다.
- golden set
- 질문과 정답, 정답의 근거 원천을 묶은 평가용 질문 세트. 사용 사례에서 데이터로 거슬러 올라가는 출발점입니다.
- Capital One Software
- Capital One의 기업용 B2B 소프트웨어 사업. 고객사의 데이터 준비, 데이터 전환, 클라우드 이전을 돕습니다.
내 메모
TODO: 내 생각 추가
원문은 CIO Dive에 실린 Paige Gross의 「How to create a scale-ready AI mandate」(2026.10.27)입니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 고객사 사례, 원문 사례 표는 Prashant Prahlad의 발언과 기사가 인용한 자료를 AX Review가 다시 정리했습니다. 타이거 팀 직무 구성, 기술·현업 실행 디테일, JSON 예시, 준비도 채점표, 6주 일정과 판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 그 안의 필드명과 숫자는 가상 예시입니다. 기사 전문은 원문 페이지에서 볼 수 있습니다.