안녕하세요. 엔터프라이즈 AI를 위한 AI-Ready 데이터 플랫폼 Syntitan을 만드는 CUBIG입니다.
기업의 AI 도입 속도가 빠르게 올라가고 있습니다. 이제는 생성형 AI를 검토하는 수준을 넘어, 실제 업무에 적용하기 위한 PoC를 진행하는 기업도 많아졌어요.
그런데 PoC가 끝난 뒤에는 비슷한 질문이 반복됩니다.
“데모에서는 잘됐는데, 실제 운영에서는 왜 결과가 달라졌을까?”
이럴 때 가장 먼저 모델이나 프롬프트를 확인하는 경우가 많습니다. 물론 둘 다 중요해요.
하지만 모델도 같고 프롬프트도 같은데 결과가 달라졌다면, AI가 사용한 데이터의 상태가 달라지지 않았는지도 확인해야 합니다.
AI가 어떤 데이터 상태에서 실행됐는지 기록하지 않았다면 결과가 달라진 이유를 찾기 어렵습니다. 잘됐던 결과를 같은 조건에서 다시 만드는 것도 쉽지 않아요.
결국 기업 AI 도입의 다음 과제는 단순히 ‘AI를 도입했는가’가 아닙니다.
AI가 만든 결과를 다시 설명하고, 같은 조건에서 다시 증명할 수 있는가.
이 글에서는 국내 기업의 AI 도입 현황부터 PoC가 실제 운영 단계에서 흔들리는 이유, 그리고 AI의 결과를 반복 가능한 성과로 만들기 위해 필요한 AI-ready data의 조건까지 살펴봅니다.
기업 AI 도입의 다음 질문은
“AI를 사용하고 있는가?”가 아니라
“AI가 만든 결과를 다시 설명하고 증명할 수 있는가?”다.
기업 AI 도입은 늘었는데, 성과는 왜 따라오지 않을까?
국내 기업에서 AI는 더 이상 일부 기술 조직만의 과제가 아닙니다. 실제 사업과 운영에 AI를 적용하려는 움직임이 빠르게 늘고 있어요.
정보통신정책연구원은 2010년부터 2024년까지 국내 기업의 사업보고서 3만 8,522건을 분석했습니다.
그 결과, 2024년 분석 대상 사업보고서의 ‘사업의 내용’에 AI 관련 키워드가 등장한 기업의 비중은 약 53.7%였습니다.
물론 이 숫자를 국내 전체 기업의 공식적인 AI 도입률로 보기는 어렵습니다. 사업보고서에 등장한 AI 관련 키워드를 기준으로 기업의 도입·활용 움직임을 분석한 결과이기 때문이에요.
다만 한 가지 흐름은 분명합니다.
기업이 AI를 일시적인 기술 유행이 아니라 실제 사업 의제로 다루기 시작했다는 점입니다.
국가데이터처의 2024년 기업활동조사에서도 비슷한 흐름을 확인할 수 있습니다.
4차 산업혁명 관련 기술을 개발하거나 활용하는 기업은 3,398개로 전년보다 28.1% 증가했습니다. 이들 기업이 개발·활용하는 기술 중 AI의 비중은 18.7%로, 클라우드에 이어 두 번째로 높았습니다.
도입 속도만 놓고 보면 기업의 AI 전환은 이미 본격적으로 시작됐다고 볼 수 있습니다.
하지만 AI를 많이 도입했다는 것과 실제 생산성이 높아졌다는 것은 다른 이야기입니다.
대한상공회의소 SGI가 2017년부터 2023년까지 기업활동조사 데이터를 분석한 결과, AI 도입은 매출·부가가치·사업 다각화 등에는 긍정적인 영향을 보였습니다.
반면 생산성 개선 효과는 아직 뚜렷하게 확인되지 않았습니다.
즉, 국내 기업은 AI를 빠르게 도입하고 있지만 어떤 조건에서 성과가 나왔는지 설명하고, 그 성과를 다시 반복하는 단계까지는 충분히 넘어가지 못한 상황입니다.
지금 기업 AI 도입에서 봐야 할 부분은 바로 이 차이입니다.
‘AI를 도입하는 것’과 ‘실제 운영에서 일관된 성과를 내는 것’ 사이에는 여전히 큰 간극이 존재합니다.
‘AI 프로젝트의 95%가 실패한다’는 말보다 먼저 봐야 할 것
기업 AI의 성과를 이야기할 때 자주 등장하는 숫자가 있습니다.
바로 “AI 프로젝트의 95%가 실패한다”는 이야기예요.
MIT NANDA의 2025년 생성형 AI 보고서는 조사 대상 생성형 AI 파일럿 가운데 빠른 손익 효과로 연결된 비율을 약 5%로 제시했습니다.
이후 이 숫자가 ‘나머지 95%의 AI 프로젝트는 모두 실패했다’는 식으로 빠르게 확산됐습니다.
하지만 이를 모든 AI 프로젝트의 일반적인 실패율로 해석하는 것은 정확하지 않습니다.
해당 보고서가 살펴본 대상은 조사 대상 생성형 AI 파일럿이고, 주요 판단 기준도 ‘빠르게 측정할 수 있는 재무 성과로 연결됐는가’에 가깝습니다.
즉, 95%의 프로젝트에서 AI 모델이 전혀 작동하지 않았다거나 모든 프로젝트가 중단됐다는 의미는 아닙니다.
보고서가 지적한 주요 원인 중 하나는 ‘학습 격차’였습니다.
AI 도구가 실제 업무에서 발생하는 피드백과 맥락을 충분히 학습하지 못하고, 기존 업무 프로세스에도 깊게 연결되지 못하면서 데모 이후 확장되지 못했다는 설명입니다.
여기에서 한 가지 질문을 더 해볼 수 있습니다.
AI가 업무 지표를 개선했다면, 그 성과가 어떤 데이터와 어떤 조건에서 나왔는지 확인할 수 있을까요?
성과를 제대로 측정하려면 결과가 달라진 이유부터 구분할 수 있어야 합니다.
모델이 달라졌는지, 프롬프트가 바뀌었는지, 입력 데이터가 변했는지, 접근 권한이 달라졌는지를 확인해야 해요.
같은 조건을 다시 만들 수 없다면 좋은 결과가 한 번 나왔더라도 그 성과가 AI 덕분인지 설명하기 어렵습니다. 다음 AI 투자를 결정할 때도 근거가 약해질 수밖에 없어요.
따라서 ‘측정 가능한 성과가 없다’는 문제를 KPI 설정의 문제로만 볼 수 없습니다.
그 결과가 나온 조건을 다시 확인하고, 필요할 때 같은 상태를 재구성할 수 있는가.
이 질문까지 함께 봐야 합니다.
AI PoC는 왜 실제 운영에서 흔들릴까?
AI PoC는 대부분 통제된 환경에서 시작합니다.
필요한 데이터만 골라 사용하고, 결측치는 미리 보완합니다. 접근 권한이 정리된 샘플 데이터셋을 사용하기도 해요.
이런 환경에서는 모델이 안정적으로 작동하고 데모 결과도 기대에 맞게 나오는 경우가 많습니다.
문제는 이 결과를 실제 운영 환경으로 옮기는 순간부터 시작됩니다.
PoC에서는 고정할 수 있었던 조건이 운영 환경에서는 계속 바뀌기 때문입니다.
| PoC 환경 | 실제 운영 환경 |
|---|---|
| 선별된 샘플 데이터 | 계속 갱신되는 실시간·운영 데이터 |
| 고정된 스키마와 컬럼 | 상위 시스템에 따라 바뀌는 스키마 |
| 단순화된 접근 권한 | 사용자·부서·목적에 따라 달라지는 권한 |
| 담당자가 정리한 업무 맥락 | 여러 시스템과 문서에 흩어진 업무 규칙 |
| 일회성 검증 | 반복 실행과 지속적인 결과 설명 |
PoC에서 확인하는 것은 통제된 조건에서 모델이 작동한다는 사실입니다.
실제 운영에서는 요구사항이 달라집니다.
조건이 계속 변하더라도 어떤 환경에서 결과가 나왔는지 추적하고, 결과가 달라졌을 때 그 이유를 설명할 수 있어야 합니다.
이 차이를 관리하지 못하면 성공한 PoC가 그대로 운영 성과로 이어지기 어렵습니다.
같은 모델인데 결과가 달라지는 이유
예를 들어 3월 고객 데이터를 기반으로 실행한 AI가 고객 이탈률을 낮췄다고 가정해 볼게요.
6월에도 같은 모델과 같은 프롬프트를 사용했는데 효과가 사라졌다면 무엇이 달라진 걸까요?
가능성은 여러 가지입니다.
모델 버전이나 프롬프트가 바뀌었을 수 있어요.
고객군과 데이터 분포가 달라졌을 수도 있습니다. ERP나 CRM이 업데이트되면서 컬럼 정의나 결측치 비율이 달라졌을 가능성도 있어요.
실행자의 권한이 변경돼 AI가 읽은 데이터 범위가 좁아졌을 수도 있습니다.
원인을 찾으려면 3월과 6월의 실행 조건을 비교해야 합니다.
그런데 3월에 사용한 데이터의 범위, 스키마, 접근 권한, 전처리 조건이 남아 있지 않다면 비교할 기준 자체가 없습니다.
코드와 모델이 같아도 데이터 상태가 달라지면 결과는 달라질 수 있다.
일반적인 테스트와 모델 평가는 코드나 모델의 변화를 확인하는 데 유용합니다.
하지만 AI가 실행될 때마다 사용한 데이터의 구성, 접근 권한, 업무 맥락까지 자동으로 다시 만들어주지는 않습니다.
그래서 PoC를 통과한 모델도 실제 운영에서는 다른 결과를 만들 수 있습니다.
모델이 달라져서가 아니라, 모델이 바라본 데이터의 상태가 달라졌기 때문입니다.
기업 AI 도입의 숨은 변수, ‘데이터 상태’
데이터 상태란 AI가 실행됐던 시점의 데이터 조건을 의미합니다.
어떤 파일이나 테이블을 사용했는지만 기록한다고 충분한 것은 아니에요.
AI 결과에 실제로 영향을 미치는 데이터 상태에는 다음과 같은 정보가 함께 포함됩니다.
- 실행에 사용한 데이터의 범위와 기준 시점
- 스키마와 각 필드의 정의
- 결측치 처리 방식과 전처리 규칙
- 사용자·부서별 접근 권한
- 원천 데이터의 출처와 변경 이력
- 실행 당시 적용된 업무 규칙과 맥락
모델 버전만 기록하면 “어떤 모델을 실행했는가?”에는 답할 수 있습니다.
하지만 “그 모델이 정확히 어떤 데이터 조건에서 결과를 만들었는가?”에는 답하기 어렵습니다.
국내 기업에서는 왜 더 복잡할까?
국내 기업의 데이터는 대부분 하나의 시스템에 모여 있지 않습니다.
ERP, CRM, 데이터 웨어하우스, 그룹웨어, 문서 저장소는 물론이고 현업이 관리하는 엑셀 파일까지 여러 곳에 흩어져 있습니다.
같은 ‘고객’, ‘매출’, ‘활성 사용자’라는 용어도 부서마다 정의나 집계 기준이 다를 수 있어요.
금융·의료·공공·통신·제조처럼 권한과 규제 조건이 중요한 산업에서는 더 복잡해집니다.
누가, 어떤 목적으로, 어떤 정책 아래 AI를 실행하는지에 따라 접근할 수 있는 데이터 범위 자체가 달라지기 때문입니다.
그래서 현장에서는 AI PoC를 진행할 때마다 데이터를 다시 추출하고 정리하는 일이 반복됩니다.
결과가 달라지면 어떤 데이터가 원인이었는지 사람이 하나씩 다시 추적해야 하죠.
담당자가 바뀌면 당시 어떤 방식으로 전처리했고 어떤 기준으로 데이터를 판단했는지조차 알기 어려운 경우가 있습니다.
결과 화면은 경영진에게 보여줄 수 있지만, 그 결과가 어떤 조건에서 만들어졌는지까지 설명하기 어려운 이유입니다.
이 문제는 더 좋은 모델 하나를 추가한다고 해결되지 않습니다.
AI가 실행됐던 데이터 상태를 기록하고, 비교하고, 다시 구성할 수 있는 운영 기반이 함께 필요합니다.
AI-Ready는 한 번 받는 진단서가 아니다
많은 기업이 생성형 AI나 AI PoC를 시작하기 전에 데이터 품질, 조직 역량, 인프라 수준을 점검합니다.
이런 준비도 진단은 현재 위치를 확인하고 우선순위를 정하는 데 필요해요.
하지만 한 번 받은 점수가 다음 달의 데이터 상태까지 보장해주지는 않습니다.
운영 데이터는 계속 변합니다.
스키마가 달라지고, 접근 권한이 바뀌고, 데이터 분포도 변합니다. 업무 규칙 역시 계속 수정됩니다.
그래서 AI-Ready는 프로젝트 시작 전에 한 번 확인하는 점수에 머물러서는 안 됩니다.
AI가 실행될 때마다 확인할 수 있는 운영 조건이 되어야 한다.
예를 들어 다음 질문에 계속 답할 수 있어야 합니다.
- 이번 AI 실행에는 어떤 데이터가 사용됐는가?
- 이전 실행과 비교하면 무엇이 달라졌는가?
- 당시와 같은 데이터 조건을 다시 만들 수 있는가?
- 결과가 달라진 이유를 데이터 수준에서 설명할 수 있는가?
이 질문에 계속 답할 수 있어야 AI-Ready가 보고서를 넘어 실제 운영으로 이어집니다.
AI-ready data를 만드는 네 가지 조건
AI-ready data라고 하면 흔히 결측치가 없고 형식이 잘 정리된 데이터를 떠올립니다.
물론 데이터 품질은 중요합니다.
하지만 실제 운영에서 필요한 조건은 이것보다 넓습니다.
AI-ready data는 단순히 AI가 읽을 수 있는 데이터여서는 부족합니다.
어떤 데이터 상태에서 사용됐는지가 남아 있어야 하고, 결과가 달라졌을 때 무엇이 변했는지도 비교할 수 있어야 합니다.
필요할 때 과거의 조건까지 다시 구성할 수 있어야 같은 실행을 반복할 수 있습니다.
이를 네 가지 기능으로 나누면 데이터 재현성이 만들어지는 구조를 더 쉽게 이해할 수 있습니다.
1. Release State: 실행 당시의 데이터 상태를 남긴다
AI 실행에 사용한 데이터 상태를 하나의 식별 가능한 버전으로 남깁니다.
이렇게 하면 결과가 담당자의 기억이나 임시 파일에만 남지 않고, 특정 시점의 데이터 조건과 함께 기록됩니다.
2. Run Binding: AI 실행과 데이터 상태를 연결한다
각 AI 실행을 당시 사용한 모델과 Release State에 연결합니다.
그래야 어떤 결과가 어떤 모델과 어떤 데이터 조건에서 나왔는지 추적할 수 있습니다.
3. Diff: 두 실행 사이에서 무엇이 달라졌는지 비교한다
정상적인 결과가 나온 실행과 문제가 발생한 실행을 비교합니다.
스키마가 달라졌는지, 권한이 달라졌는지, 데이터 구성이 변했는지, 업무 맥락이 바뀌었는지를 확인합니다.
이 과정을 통해 결과 변화의 원인을 모델과 데이터로 나눠 좁혀갈 수 있습니다.
4. Reproduce: 과거 실행 조건을 다시 만든다
과거 실행 당시의 데이터 상태를 다시 구성합니다.
잘됐던 결과는 같은 조건에서 다시 확인하고, 문제가 있었던 결과 역시 당시 환경에서 다시 검증할 수 있습니다.
네 가지 기능은 따로 움직이지 않습니다.
Release State가 기준점을 만들고,
Run Binding이 실행과 기준점을 연결합니다.
Diff는 두 실행 사이에서 무엇이 달라졌는지 보여주고,
Reproduce는 과거 조건을 다시 검증할 수 있게 합니다.
이 흐름이 연결되면 AI 결과는 한 번 성공하고 끝나는 데모가 아닙니다.
왜 이런 결과가 나왔는지 설명하고, 필요할 때 다시 반복할 수 있는 운영 근거가 됩니다.
다음 AI PoC 전에 확인해야 할 다섯 가지
데이터 재현성이라는 표현이 다소 기술적으로 들릴 수 있습니다.
하지만 다음 AI 파일럿을 시작하기 전에 아래 다섯 가지 질문만 확인해도 현재 어디에서 문제가 생기고 있는지 파악할 수 있어요.
- 특정 AI 결과가 어떤 데이터 상태에서 만들어졌는지 확인할 수 있는가?
- 같은 입력과 조건을 다시 구성해 같은 결과를 검증할 수 있는가?
- 권한이나 스키마가 바뀌어도 PoC 당시 조건과의 차이를 추적할 수 있는가?
- 경영진이나 감사 조직에 결과 화면뿐 아니라 실행 근거까지 제시할 수 있는가?
- 파일럿마다 데이터 준비와 검증을 처음부터 반복하지 않고 재사용 가능한 구조로 운영하고 있는가?
‘아니오’가 많다면 다음 AI 투자에서 모델을 바꾸는 것만 고민할 필요는 없습니다.
데이터가 어떤 상태에서 실행됐는지 기록하고 다시 구성할 수 있는 운영 구조가 있는지도 함께 확인해야 합니다.
기업 AI 도입의 다음 기준은 ‘도입’이 아니라 ‘증명’이다
국내 기업의 AI 도입 경쟁은 이미 시작됐습니다.
앞으로의 차이는 누가 더 많은 AI 모델을 테스트했는지에서만 만들어지지 않을 가능성이 큽니다.
누가 AI 결과를 실제 업무와 성과에 연결하고, 그 과정을 반복할 수 있는지가 더 중요해집니다.
AI가 한 번 좋은 결과를 냈다고 끝나는 것이 아닙니다.
어떤 데이터에서 결과가 나왔는지 설명할 수 있어야 합니다.
조건이 달라졌다면 무엇이 달라졌는지 비교할 수 있어야 합니다.
필요할 때는 당시의 데이터 상태를 다시 만들어 같은 결과를 검증할 수 있어야 해요.
이것이 AI PoC를 실제 운영으로 전환하고, 기업의 AI 도입을 반복 가능한 성과로 만드는 AI-ready data의 조건입니다.
CUBIG의 Syntitan은 Release State, Run Binding, Diff, Reproduce를 통해 AI 실행에 사용된 데이터 상태를 기록하고 비교하며 다시 구성합니다.
다음 AI 파일럿을 시작하기 전에 모델부터 바꾸기보다 한 가지를 먼저 확인해보세요.
지금 우리 AI는 어떤 상태의 데이터를 보고 실행되고 있나요?
