Ready Enough Data: 데이터 정비를 기다리지 말고 AI와 현대화를 두 트랙으로

데이터 정비가 끝나기를 기다렸다가 AI를 시작하는 순서는 끝나는 날이 오지 않아 더 위험하다는 것이 Snowflake 글로벌 필드 CTO의 주장입니다. 90일 안에 증명할 AI 성과와 데이터 현대화를 두 트랙으로 나눠 동시에 돌리고, 데이터는 옮기지 않은 채 하나의 정책 계층으로 통제하자고 제안합니다. 따라 하려면 성과 하나를 고르고, 그 성과에 필요한 데이터가 다섯 가지 '충분히 준비됨' 조건을 채우는지부터 확인해야 합니다.

요약

Snowflake의 Global Field CTO Fawad Qureshi는 경영진과 반복해서 나누는 대화에서 글을 시작합니다. 데이터 전환을 마친 뒤 AI를 하겠다는 이야기입니다. 저자는 이 ‘데이터부터 정리하라’는 처방이 온프레미스 시대에서 나왔다고 봅니다. 그때는 데이터가 시스템마다 흩어져 있어서 분석하려면 먼저 한곳에 모아야 했습니다. 그 합리적인 처방이 시간이 지나며 “레거시 이전이 끝나기 전에는 AI를 시작하지 않는다”는 규칙으로 굳었습니다. 저자는 그 대안으로 두 트랙(two tracks)을 제안합니다. Track 1은 90일 안에 증명할 수 있는 사업 성과를 골라 필요한 데이터를 있는 자리에서 찾아 쓰는 AI 트랙입니다. Track 2는 이전과 통합을 제 일정대로 계속하는 현대화 트랙입니다.

저자가 순서를 바꾸자는 이유는 ‘완료’라는 기준이 애초에 도달할 수 없기 때문입니다. 데이터 환경은 계속 바뀌므로 전환이 끝나는 날은 계속 밀리고, 그동안 가만히 있는 위험이 시작하는 위험보다 큰 경우가 많다고 봅니다. 근거로는 D&B의 2026년 자료를 인용합니다. 세계 기업의 97%가 AI 이니셔티브를 운영하지만 데이터가 준비됐다고 답한 곳은 5%뿐입니다. 저자는 대신 출처, 소유자, 접근 통제, 한계, 결정 의지라는 ‘충분히 준비됨(ready enough)’ 다섯 조건을 내놓고, 대기업 대부분이 이미 이 기준을 채운다고 말합니다. 두 트랙을 돌리면 운영 중인 AI가 어떤 통합이 급하고 어떤 레거시는 기다려도 되는지 알려 주므로, 현대화 순서도 실제로 드러난 가치에 따라 정해집니다. 이 글은 Snowflake 블로그의 의견 글이며 고객 사례나 성과 수치는 싣지 않았습니다. 아래에서는 주장을 여섯 가지 작동 원리로 풀고, 두 트랙을 실제로 돌릴 때 필요한 정책 계층 설계, 데이터 점검표, 90일 일정과 판정 기준을 덧붙입니다.

핵심 메커니즘

Sequential model: 합리적이던 처방이 굳어진 규칙

무엇인가. 데이터 이전과 통합을 먼저 끝내고 그다음 AI를 시작한다는 순차 모델입니다.

어떻게 작동하나. 온프레미스 환경에서는 분석하려면 흩어진 데이터를 한곳에 모아야 했습니다. 그래서 “먼저 모으고 나중에 분석하라”는 순서가 맞았습니다. 이 처방이 조직 안에서 관행이 되면, AI 과제가 올라올 때마다 “이전이 끝난 뒤에”라는 답이 돌아옵니다. 그런데 이전 범위는 계속 늘고 새 시스템도 계속 생기므로 완료 시점이 앞으로 밀립니다.

언제 맞고 언제 안 맞나. 데이터를 모으지 않으면 아예 연결할 방법이 없던 환경에서는 맞는 순서입니다. 지금처럼 데이터를 옮기지 않고도 여러 곳을 함께 조회하고 통제할 수 있다면, 이 순서를 지킬 이유가 약해집니다.

원문의 예. 저자는 경영진이 “전환을 끝내고 AI를 하겠다”고 말하는 대화가 반복된다고 전합니다. 특정 회사 이름은 들지 않습니다.

Two tracks: AI 성과와 데이터 현대화를 동시에

무엇인가. AI로 성과를 내는 트랙과 데이터를 현대화하는 트랙을 나눠 서로 기다리지 않게 하는 운영 방식입니다.

어떻게 작동하나. Track 1은 네 단계입니다. 90일 안에 증명할 수 있는 사업 성과를 하나 고르고, 그 성과에 필요한 데이터를 어디에 있든 찾아내고, 엔진과 관계없이 하나의 정책 계층으로 데이터를 그 자리에서 통제한 뒤, 그 위에서 AI 워크로드를 바로 돌립니다. Track 2는 이전, 레거시 통합, 파이프라인 개선을 원래 일정대로 이어 갑니다. 다만 더 이상 AI를 막지 않습니다. 이전이 끝난 데이터는 Track 1에 연결되므로 버리는 작업이 없습니다. 두 트랙 사이에는 피드백이 흐릅니다. 운영 중인 AI가 어떤 통합이 가장 급하고 어떤 레거시 플랫폼은 기다려도 되는지 보여 줍니다. 저자는 이를 leapfrog(순차 모델의 대기열을 건너뛰되 밑바탕 작업은 건너뛰지 않음)라고 부릅니다.

언제 맞나. 대규모 데이터 전환이 진행 중이거나 계획돼 있고, AI 과제가 그 일정에 묶여 대기하는 조직에 맞습니다. 성과를 90일 안에 측정할 수 없는 과제라면 Track 1의 첫 대상으로는 맞지 않습니다.

Govern in place: 데이터를 옮기지 않고 한 정책 계층으로 통제

무엇인가. 데이터를 한곳으로 옮겨 모은 뒤 통제하는 대신, 데이터가 있는 자리에 그대로 두고 그 위에 하나의 정책 계층을 씌우는 방식입니다.

어떻게 작동하나. 누가 어떤 데이터를 볼 수 있는지를 한 번 정의하면, 데이터를 읽는 엔진이 무엇이든 같은 규칙이 적용됩니다. 저자는 이것이 Track 1을 지금 시작할 수 있게 하는 조건이라고 봅니다. 이전이 끝나지 않아도 통제는 할 수 있기 때문입니다.

언제 맞나. 데이터가 여러 저장소와 엔진에 흩어져 있고, 이전 일정이 길게 남아 있을 때 맞습니다. 정책 계층이 닿지 않는 저장소에 핵심 데이터가 있다면 그 데이터는 Track 1에서 빼거나 사본 없이 접근하는 경로부터 만들어야 합니다.

Ready enough: ‘완료’ 대신 쓰는 다섯 조건

무엇인가. 데이터가 완벽하지 않아도 AI에 쓰기에 충분한지 판단하는 기준입니다.

어떻게 작동하나. 저자가 든 조건은 다섯 가지입니다. 데이터가 어디서 왔는지 압니다. 누가 소유하는지 압니다. 접근을 통제할 수 있습니다. 한계를 이해합니다. 그리고 그 데이터로 결정을 내릴 의지가 있습니다. 다섯 번째 조건만 사람에 관한 것입니다. 이 기준대로라면 데이터 품질이 같아도 그 데이터로 결정할 사람이 없으면 준비되지 않은 셈입니다.

원문의 예. 저자는 대기업 대부분이 이 기준을 이미 채운다고 봅니다.

세 가지 정체 유형: 어디서 멈춰 서는가

무엇인가. 저자가 조직이 AI 앞에서 멈추는 모습을 세 유형으로 나눈 틀입니다.

어떻게 작동하나. Battle-scarred(상처 입은 베테랑) 조직은 데이터 플랫폼에 수년과 큰돈을 썼고, AI를 또 하나의 포장만 바꾼 약속으로 봅니다. 전환 마무리와 AI 착수 가운데 하나만 골라야 한다고 생각합니다. Clean sheet(백지) 조직은 큰 전환을 아직 하지 않았고 뒤처졌다는 말을 듣지만, 레거시 부채 없이 지금 기술에 맞춰 설계할 수 있습니다. Mid-mandate(지시는 받았지만 진행 중) 조직은 AI 전략과 지시가 있는데 전환 적체가 실행을 막습니다.

언제 쓰나. 우리 조직이 어디서 막혔는지 진단할 때 씁니다. 유형마다 두 트랙의 출발점이 다릅니다.

농부의 일은 수확: 플랫폼과 도메인 전문가의 분담

무엇인가. 인프라 일은 플랫폼에 맡기고, 도메인 전문가가 AI로 결정을 낫게 할 지점을 찾는 역할 분담입니다.

어떻게 작동하나. 저자는 예전에는 큰 수평 조직이 하던 인프라 작업을 이제 플랫폼이 맡는다고 봅니다. 그러면 사람의 시간은 수확, 곧 결정을 개선하는 일에 갑니다. 리테일 바이어는 마크다운(가격 인하) 최적화를, 제조 운영 관리자는 다운타임 비용을, 금융의 신용 분석가와 컴플라이언스 담당자는 각자의 판단 업무를 봅니다.

통념과 다른 주장

저자가 든 사례

원문은 벤더 의견 글로, 특정 고객사의 도입 사례나 성과 수치를 싣지 않았습니다. 저자가 실제로 언급한 것은 조직 유형 세 가지와 업종별 적용 지점입니다. 아래는 그것을 사례 틀로 다시 짠 것입니다.

세 유형이 두 트랙으로 출발하는 법

구분	내용
상황	Battle-scarred는 투자 피로, Clean sheet는 뒤처졌다는 압박, Mid-mandate는 지시와 적체 사이에 끼임
한 일	저자는 세 유형 모두에 두 트랙 병행을 제안. Clean sheet는 레거시 부채 없이 지금 기술로 설계할 수 있다고 봄
결과	원문에서 밝히지 않음
연결	Sequential model, Two tracks, 세 가지 정체 유형

업종별로 AI가 낫게 할 결정

구분	내용
상황	인프라 일에 사람이 묶이면 결정 개선에 쓸 시간이 없음
한 일	리테일 바이어는 마크다운 최적화, 제조 운영 관리자는 다운타임 비용, 금융 신용 분석가·컴플라이언스 담당자는 판단 업무에 AI 적용 지점을 찾음
결과	원문에서 밝히지 않음
연결	농부의 일은 수확, Ready enough의 ‘결정 의지’ 조건

기술 디테일: 두 트랙을 실제로 돌리려면

Track 1의 데이터를 고르려면 성과 하나에서 거꾸로 내려갑니다. 예를 들어 리테일의 마크다운 최적화라면 판매 실적, 재고, 가격 이력, 프로모션 일정이 필요합니다. 이 테이블만 목록으로 뽑고, 각 테이블이 어느 시스템에 있는지 적습니다. 전사 데이터 카탈로그를 다 채울 필요는 없습니다. Track 1에 들어가는 10~20개 테이블만 다섯 조건으로 점검합니다. 아래 점검표는 가상 예시입니다.

dataset: sales_daily            # 가상 예시
system: legacy_dw_oracle        # 지금 있는 자리 (이전 대상이어도 그대로 씀)
source: POS 일 마감 배치         # 출처
owner: 영업기획팀 데이터 담당     # 소유자
access_policy: [store_mgr_row_filter, mask_customer_id]  # 접근 통제
known_limitations:              # 한계
  - 반품은 D+2에 반영
  - 2024년 이전 일부 점포 누락
decision_owner: 시즌 MD 바이어   # 결정 의지: 이 데이터로 결정할 사람
ready_enough: true

다섯 칸 가운데 하나라도 비면 그 테이블은 Track 1에서 빼거나, 빈칸을 채우는 일을 Track 1 첫 2주 할 일로 넣습니다. 특히 decision_owner가 비면 기술 준비가 끝나도 진행하지 않습니다.

정책 계층을 하나로 두려면 접근 규칙을 엔진마다 따로 쓰지 않고 한 곳에서 정의합니다. 실제로는 클라우드 데이터 플랫폼의 거버넌스 기능, 공용 카탈로그, Apache Iceberg 같은 개방형 테이블 형식과 그 카탈로그를 조합하는 방법이 흔합니다. 규칙은 태그 기반으로 씁니다. 예를 들어 열에 pii 태그를 달고 “pii 태그 열은 분석가 역할에게 마스킹” 정책을 한 번 걸면, SQL, 노트북, AI 에이전트가 모두 같은 마스킹된 값을 봅니다. LLM에 데이터를 넘길 때는 검색이나 쿼리 단계에서 이미 정책이 적용된 결과만 넘기고, 프롬프트 안에서 “개인정보는 무시하라”고 지시하는 방식에 기대지 않습니다.

흔한 실패와 대응. 첫째, 빨리 하려고 Track 1 팀이 데이터를 따로 복사해 가는 경우입니다. 사본이 생기면 정책 계층 밖으로 나가므로, 사본 생성은 승인 대상으로 두고 원칙적으로 제자리 조회를 씁니다. 둘째, 엔진마다 정책이 미묘하게 달라지는 경우입니다. 분기마다 같은 역할로 각 엔진에서 같은 쿼리를 돌려 결과 행 수와 마스킹 여부가 같은지 대조합니다. 셋째, 레거시 원천의 조회 성능이 AI 워크로드를 못 버티는 경우입니다. 이 테이블은 Track 2 이전 순서표의 맨 위로 올립니다.

Track 1이 Track 2의 순서를 정하게 하려면 피드백을 감이 아닌 기록으로 돌립니다. Track 1 워크로드의 쿼리 로그에서 테이블별 조회 횟수, 지연, 실패, 사람이 손으로 보정한 횟수를 매주 모읍니다. 여기에 사업 가치를 곱하고 이전 비용으로 나눈 점수로 Track 2 순서표를 매달 다시 정렬합니다. 한 번도 조회되지 않은 레거시는 이전을 미뤄도 되는 후보가 됩니다.

AI 워크로드 자체는 첫 90일에는 작게 둡니다. 마크다운 예라면 모델이 할인율을 직접 정하지 않고, 바이어에게 품목별 권장 할인율과 근거 데이터(재고 일수, 판매 속도)를 함께 보여 주는 추천 형태로 시작합니다. 출력은 품목 코드, 권장 할인율, 근거 지표, 확신도 같은 고정 필드로 받고, 바이어가 받아들였는지 여부를 기록합니다. 이 채택률이 90일 판정의 핵심 지표가 됩니다.

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

역할(예시).

역할	맡는 일
경영 스폰서(CEO·사업부장)	Track 1 성과 하나를 고르고 90일 판정에 참석
CDO·데이터 플랫폼 리드	정책 계층 설계, Track 2 순서표 관리
도메인 결정권자(바이어·운영 관리자)	decision_owner. 추천을 실제 결정에 쓰고 채택 여부 기록
보안·컴플라이언스	접근 정책과 마스킹 규칙 승인
Track 2 프로그램 리드	이전 일정 유지, 월 1회 순서표 반영

시작 전 준비물. 진행 중인 데이터 전환 계획표, 후보 AI 과제 목록(과제마다 측정 지표와 결정권자), 현재 접근 권한 정책 문서, 저장소별 데이터 위치 목록.

기간	할 일	산출물
0~2주	90일 성과 하나 선정, 필요한 테이블 목록, 다섯 조건 점검	성과 정의서, ready-enough 점검표
3~6주	정책 계층에 규칙 등록, 제자리 조회 연결, 첫 버전 구축	정책 목록, 추천 v1
7~10주	결정권자가 실제 업무에 사용, 채택 여부와 보정 기록	사용 로그, 주간 채택률
11~13주	성과 측정, 확대·수정·중단 판정, Track 2 순서표 갱신	판정 보고서, 갱신된 이전 순서

유형별 첫 질문.

1. Battle-scarred: 지금까지 이전을 끝낸 데이터 가운데 바로 AI에 쓸 수 있는 것은 무엇인가요?
2. Clean sheet: 레거시를 옮기지 않고 처음부터 정책 계층을 깔 수 있는 영역은 어디인가요?
3. Mid-mandate: AI 지시 가운데 전환 적체 때문에 멈춘 과제는 무엇이고, 그 과제에 필요한 테이블은 몇 개인가요?
4. 공통: 이 데이터로 결정을 바꿀 사람은 누구이고, 그 사람이 90일 동안 쓸 시간이 있나요?

진행 판정 기준(예시). 세 조건을 채우면 Track 1의 다음 과제로 넘어갑니다. 첫째, 결정권자가 추천의 절반 이상을 실제 결정에 썼습니다. 둘째, 정한 사업 지표(예: 마크다운 후 재고 소진율)가 기준 기간보다 나아졌습니다. 셋째, 정책 위반이나 승인 없는 사본이 0건입니다. 채택률이 낮으면 데이터보다 결정 흐름을 먼저 다시 봅니다.

AX 적용 제언. 국내 기업에서는 ERP·차세대 시스템 구축이 몇 년씩 이어지면서 “차세대 끝나고 AI”라는 말이 자주 나옵니다. 이 글은 그 일정을 건드리지 말고 옆에 90일 트랙을 하나 붙이라는 제안으로 읽을 수 있습니다. 첫 대상은 차세대 이전 대상이 아닌 데이터, 또는 이미 이전이 끝난 데이터로 성과가 나는 결정 하나가 적당합니다. 경영진 보고에서는 Track 1의 채택률과 Track 2 순서표가 바뀐 이유를 함께 보여 주면, AI가 현대화 투자 순서를 바로잡는 근거가 된다는 점이 드러납니다. 벤더 블로그인 만큼 정책 계층을 어느 제품으로 구현할지는 현재 쓰는 플랫폼과 카탈로그를 기준으로 따로 따져 봅니다.

원문 사례

항목	내용
저자·매체	Fawad Qureshi(Snowflake Global Field CTO), Snowflake 블로그, 2026.10.29
글의 성격	벤더 의견 글. 고객 사례 없음, 끝에 eBook 안내
핵심 주장	데이터 준비 완료를 기다리는 쪽이 지금 시작하는 쪽보다 위험
인용 수치	AI 이니셔티브 운영 기업 97%, 데이터가 준비됐다는 기업 5% (D&B 2026 자료)
제안	Track 1 AI 성과(90일), Track 2 현대화 병행, 단일 정책 계층으로 제자리 통제
준비 기준	출처, 소유자, 접근 통제, 한계 이해, 결정 의지
조직 유형	Battle-scarred, Clean sheet, Mid-mandate
업종 예	리테일 바이어(마크다운), 제조 운영 관리자(다운타임 비용), 금융 신용 분석가·컴플라이언스 담당자

핵심 개념

Leapfrog

순차 모델의 대기열은 건너뛰되 밑바탕 데이터 작업은 건너뛰지 않는 진행 방식입니다.

Policy layer

데이터가 어느 저장소·엔진에 있든 같은 접근 규칙을 적용하는 공통 통제층입니다.

Markdown optimization

재고와 판매 속도를 보고 가격 인하 시점과 폭을 정하는 리테일 의사결정입니다.

Tag-based policy

열이나 테이블에 붙인 태그를 기준으로 마스킹·접근 규칙을 거는 방식. 정책을 한 번 쓰고 여러 엔진에 적용하기 쉽습니다.

Apache Iceberg

여러 엔진이 같은 테이블을 읽고 쓸 수 있게 하는 개방형 테이블 형식입니다.

내 메모

TODO: 내 생각 추가

원문은 Snowflake 블로그의 「Why Waiting for “Ready” Data Is Riskier Than Starting Now」(Fawad Qureshi, 2026.10.29)입니다. 자사 플랫폼을 알리는 벤더 블로그의 의견 글이며, 고객 사례나 도입 성과는 담고 있지 않습니다. 97%·5% 수치는 원문이 D&B 2026 자료를 인용한 것입니다. 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 사례, 원문 사례 표는 저자가 언급한 내용을 AX Review가 다시 정리했습니다. 기술·현업 실행 디테일, 점검표, 피드백 점수, 역할 표, 90일 일정과 판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 그 안의 테이블명·필드명·기간·기준은 가상 예시입니다. 원문 전체는 Snowflake 블로그에서 볼 수 있습니다.