PoC부터 운영까지 AI 도입 실패 7가지 점검

TL;DR AI 도입 실패는 모델보다 문제 정의·데이터·업무 프로세스·조직에서 시작됩니다. 일곱 가지 원인과 원인별 예방 방법을 점검표로 정리했습니다.

2026년 국내 기업과 공공기관이 AI 도입을 위해 예산을 잡을 때, 무엇이 AI 도입 실패를 부르고 어떤 방법으로 피할 수 있는지 공개 조사와 현장 경험으로 정리했습니다.

PoC는 박수를 받으며 끝났는데, 반년이 지나도 운영 시스템에 올라가지 않는 프로젝트가 있습니다. 시연에서는 똑똑하던 챗봇이 실제 업무 문서 앞에서는 엉뚱한 답을 내고, 현업은 결국 예전 방식으로 돌아갑니다. 예산 심의 자리에서 “그래서 무엇이 좋아졌느냐”는 질문에 답하지 못하면 다음 해 예산은 끊깁니다. 이것이 많은 조직이 겪는 AI 도입 실패의 전형적인 모습입니다. 이 글은 AI란 무엇인가에서 다룬 기본 개념 위에서, AI 도입 실패가 왜 생기는지 일곱 가지 원인으로 나누고 원인마다 피하는 방법을 정리합니다. GPU 수량과 추론 비용 관점은 LLM 도입이 실패하는 이유는 GPU가 부족해서가 아니다에서 따로 다뤘으니, 여기서는 조직·데이터·프로세스 관점에 집중합니다.

“AI 도입 실패”, “AI 도입 실패 사례”, “AI 프로젝트 실패 이유”를 검색하는 분들이 실제로 궁금해하는 내용을 순서대로 묶었습니다.

1. AI 도입 실패란 정확히 어떤 상태를 말하나요?
2. 공개 조사로 보면 AI 프로젝트는 얼마나 실패하나요?
3. 국내 기업은 AI 도입에서 어디에 막혀 있나요?
4. AI 도입 실패의 대표 원인 일곱 가지는 무엇인가요?
5. PoC가 끝나도 운영으로 넘어가지 못하는 이유는 무엇인가요?
6. 공공·금융·제조 현장에서는 어떤 실패 패턴이 반복되나요?
7. 실패 징후를 어떻게 일찍 알아차릴 수 있나요?
8. 실패를 피하려면 어떤 순서와 점검표로 시작해야 하나요?

AI 도입 실패는 투입한 시간과 예산에 비해 업무 성과가 확인되지 않은 채 프로젝트가 멈추거나 방치되는 상태를 말합니다. 모델이 틀린 답을 내는 기술 결함만을 뜻하지 않습니다. 오히려 기술은 그럭저럭 동작하는데, 아무도 쓰지 않거나 효과를 증명하지 못해 사라지는 경우가 더 많습니다.

현장에서 AI 도입 실패라고 부르는 상태는 대체로 네 가지로 나뉩니다.

이렇게 나눠 보면 AI 도입 실패의 대부분이 모델 바깥에서 결정된다는 점이 보입니다. 같은 모델을 쓰더라도 어떤 문제에, 어떤 데이터로, 어떤 업무 흐름 안에 넣느냐에 따라 결과가 갈립니다.

네 유형은 시간 순서로 이어지기도 합니다. PoC 중단을 겨우 넘긴 과제가 운영 미전환에서 멈추고, 운영에 올라간 과제가 사용자 이탈로 식고, 마지막까지 살아남은 과제가 비용 초과로 축소됩니다. 그래서 AI 도입 실패를 줄이려면 한 단계의 통과가 다음 단계의 통과를 보장하지 않는다는 사실을 처음부터 계획에 넣어야 합니다. 각 유형이 어느 단계에서 터지는지 알고 있으면, 그 단계 앞에 점검 지점을 미리 둘 수 있습니다.

한 가지 짚어 둘 점이 있습니다. PoC를 해 보고 접는 것 자체는 AI 도입 실패가 아닙니다. 작은 비용으로 “이 과제는 지금 AI로 풀 문제가 아니다”를 확인했다면 그것은 잘 설계된 검증입니다. 문제는 접어야 할 과제를 접지 못하고 끌고 가거나, 살려야 할 과제를 성과 측정이 없어서 놓치는 경우입니다. 이 글에서 말하는 AI 도입 실패는 바로 이 두 가지, 즉 판단 근거 없이 끝나는 프로젝트를 가리킵니다.

AI 도입 실패에 관한 여러 공개 조사가 공통으로 보여 주는 결론은 AI 프로젝트의 상당수가 PoC 이후 운영 성과로 이어지지 못한다는 것입니다. 수치는 조사 대상과 정의가 달라 단순 비교할 수 없지만, 방향은 일치합니다.

출처는 각각 Gartner 2024년 발표, Gartner 2025년 2월 발표, Gartner 2025년 6월 발표, RAND 보고서, BCG 보도자료, MIT NANDA 보고서 보도, S&P Global 조사 보도입니다. MIT NANDA 보고서 원문은 신청서를 낸 사람에게만 공개되고 S&P Global 조사 원문도 공개 페이지로 확인되지 않아, 이 두 수치는 보도 내용을 옮긴 것입니다.

AI 도입 실패 수치를 읽을 때 주의할 점이 세 가지 있습니다.

• 전망과 측정을 구분해야 합니다. Gartner 수치는 앞으로 일어날 일을 내다본 전망이고, S&P Global과 BCG는 설문 응답을 집계한 결과입니다.
• RAND의 80%는 RAND가 직접 잰 값이 아닙니다. 보고서는 여러 추정치를 인용하고, 자체적으로는 경험 많은 데이터 과학자·엔지니어 65명을 인터뷰해 근본 원인을 정리했습니다.
• MIT NANDA의 95%는 예비 연구의 결과로 보도됐습니다. 보도에 따르면 300여 개 공개 사례 검토, 52개 조직 인터뷰, 153명 리더 설문을 바탕으로 했으며(매체마다 인터뷰·설문 규모를 다르게 전했습니다), 모든 기업에 그대로 적용되는 실패율로 읽으면 안 됩니다.

그럼에도 결론은 분명합니다. AI 도입 실패는 예외가 아니라 기본값에 가깝습니다. 그래서 “실패하지 않는 방법”보다 “실패를 빨리 알아차리고 싸게 끝내는 방법”이 더 현실적인 목표가 됩니다.

조사들이 지목한 원인도 눈여겨볼 만합니다. 표의 오른쪽 열을 다시 보면 모델 성능 부족을 첫 원인으로 꼽은 조사는 하나도 없습니다. 데이터 품질, 위험 통제, 비용, 사업 가치, 사람과 프로세스, 업무 흐름 통합이 반복해서 나옵니다. AI 도입 실패를 기술 문제로만 보면 처방도 틀린다는 뜻입니다. 더 좋은 모델로 바꾸면 해결될 것이라는 기대로 모델만 교체하다가 같은 자리에서 다시 멈추는 조직이 적지 않습니다.

국내 기업은 AI 도입 실패를 논하기 전에 아직 시작하지 못한 곳이 많고, 시작한 곳은 비용·인력·성과 확신에서 막혀 있습니다.

대한상공회의소가 2025년 11월 발표한 국내 제조기업 504곳 조사 결과를 보면 상황이 잘 드러납니다(대한상의 보도자료). 여기서 「AI 활용」은 개인이 생성형 AI를 쓰는 것을 빼고 생산·물류·운영에 AI 솔루션을 도입했는지를 물은 것입니다.

이 표에서 눈여겨볼 숫자는 마지막 줄입니다. 열 곳 중 여섯 곳이 시작하기 전부터 효과를 의심합니다. 이런 분위기에서 PoC가 한 번 AI 도입 실패로 끝나면 “역시 AI는 우리와 안 맞는다”는 결론이 굳어지고, 다음 시도는 몇 년 뒤로 밀립니다. 국내에서 AI 도입 실패의 비용이 유독 큰 이유입니다.

한국은행 분석도 같은 메시지를 줍니다. 2026년 6월 BOK 이슈노트(제2026-12호)는 AI 활용으로 근로자 업무시간이 평균 3.8%(주 40시간 기준 약 1.5시간) 줄었지만, 개인별 시간 절감과 업무처리량 증가의 상관계수가 0으로 그 시간이 실제 생산 증가로 이어지지는 않았다고 분석했습니다. 그리고 업무 프로세스와 조직 구조를 다시 설계하고 성과 기반 유인체계를 갖춰야 효과가 실현된다고 제안했습니다(한국은행 BOK 이슈노트 제2026-12호). 도구를 나눠 주는 것만으로는 성과가 생기지 않는다는 뜻입니다.

두 자료를 합치면 국내 기업의 AI 도입 실패는 크게 두 갈래입니다.

1. 시작 단계의 AI 도입 실패: 비용·인력 부담 때문에 과제를 너무 작게 잡거나, 반대로 외부 솔루션을 통째로 들여와 내부 역량이 쌓이지 않는 경우.
2. 확산 단계의 AI 도입 실패: 도구는 깔았지만 업무 방식과 평가 체계가 그대로라 절감된 시간이 성과로 바뀌지 않는 경우.

성과를 낸 국내 기업이 무엇을 달리했는지는 국내 기업 AI 도입 사례 — 성과를 낸 기업은 무엇이 달랐나에서 사례 중심으로 정리했습니다. 이 글은 그 반대편, 즉 멈춘 프로젝트에서 반복되는 원인을 다룹니다.

공개 조사와 현장 프로젝트에서 반복되는 AI 도입 실패 원인은 일곱 가지로 묶을 수 있습니다. RAND가 정리한 다섯 가지 근본 원인(문제 정의 오류, 데이터 부족, 인프라 투자 부족, 최신 기술 집착, 기술 한계를 넘는 과제 선정)과 BCG·한국은행이 강조한 사람·조직 요인을 실무 언어로 다시 나눴습니다.

AI 도입 실패 원인 일곱 가지는 따로 움직이지 않습니다. 문제 정의가 흐리면 필요한 데이터 범위도 정할 수 없고, 데이터 범위가 흐리면 보안 심사가 길어지고, 그 사이 비용이 쌓이며, 마지막에는 성과를 설명하지 못합니다. 그래서 첫 번째 원인을 바로잡는 일이 나머지 여섯 가지를 함께 줄이는 지렛대가 됩니다. 아래에서 원인마다 증상과 피하는 방법을 하나씩 살펴봅니다.

해결할 업무 문제를 정하지 않고 기술부터 고르면, 무엇이 성공인지 아무도 말할 수 없게 됩니다. RAND 보고서가 첫 번째 근본 원인으로 꼽은 것도 이해관계자가 AI로 풀 문제를 잘못 이해하거나 잘못 전달하는 문제였습니다.

AI 도입 실패의 전형적인 출발은 이렇습니다. 경영진이 “경쟁사는 생성형 AI를 쓴다는데 우리는 뭘 하고 있나”라고 묻고, IT 부서는 서둘러 사내 챗봇 PoC를 띄웁니다. 시연은 잘 됩니다. 그런데 이 챗봇이 줄여야 할 업무 시간이 무엇인지, 누가 어떤 질문을 하루에 몇 번 하는지, 지금은 그 답을 얻는 데 얼마나 걸리는지를 아무도 재지 않았습니다. 결국 좋아졌는지 나빠졌는지 판단할 기준 자체가 없는 PoC가 됩니다.

문제 정의가 흐릴 때 나타나는 AI 도입 실패 신호는 다음과 같습니다.

• 과제 이름이 업무가 아니라 기술 이름이다(예: “LLM 도입”, “에이전트 구축”).
• 과제 담당이 IT 부서뿐이고, 결과를 쓸 현업 부서장이 없다.
• 성공 기준이 “정확도 90%”처럼 모델 지표로만 적혀 있다.
• 과제 범위가 “전사 지식 검색”처럼 너무 넓다.

피하는 방법은 단순합니다. 과제 정의서를 한 장으로 쓰고, 다음 네 줄을 채우지 못하면 시작하지 않습니다.

1. 어떤 부서의 어떤 업무를 바꾸는가.
2. 지금 그 업무에 걸리는 시간·비용·오류율은 얼마인가.
3. AI가 들어간 뒤 그 숫자를 얼마로 만들 것인가.
4. 그 결과를 누가 확인하고 승인하는가.

RAND가 지적한 또 다른 원인, 즉 최신 기술 자체에 매달리는 태도도 여기서 걸러집니다. 업무 문제부터 적으면 의외로 규칙 기반 자동화나 검색 개선만으로 풀리는 과제가 섞여 있다는 것을 알게 됩니다. AI가 꼭 필요하지 않은 과제를 걸러 내는 것도 AI 도입 실패를 줄이는 방법입니다. AI가 무엇을 잘하고 무엇을 못하는지 기초부터 맞추고 싶다면 AI란 무엇인가의 유형별 설명을 먼저 공유하고 회의를 시작하는 편이 좋습니다.

첫 과제의 개수도 문제 정의의 일부입니다. 첫 회차에 업무 다섯 건 이상을 한꺼번에 맡기면 결과가 나쁠 때 원인을 가려낼 수 없습니다. 절차가 문서로 정리되지 않았는지, 입력 자료가 예상과 달랐는지, 도구 연결이 끊겼는지가 겹쳐서 나타나기 때문입니다. 그래서 첫 회차는 세 건 이하로 좁히는 편이 안전합니다. 후보를 고를 때는 담당자가 자료를 찾지 않고 바로 답할 수 있는 세 값, 즉 반복 주기, 한 번 처리에 걸리는 시간, 사람이 틀렸을 때의 비용을 적고 순위를 매기면 대개 30분 안에 끝납니다. 틀렸을 때 되돌릴 수 없는 업무는 이 자리에서 바로 제외합니다.

AI에 맞게 준비되지 않은 데이터는 답의 품질, 보안, 운영 비용을 한꺼번에 무너뜨립니다. Gartner는 2025년 2월 발표에서 데이터 관리 리더 1,203명 조사를 근거로, 조직의 63%가 AI에 맞는 데이터 관리 관행을 갖추지 못했거나 갖췄는지 모른다고 밝혔습니다. 그리고 그런 데이터로 뒷받침되지 않는 AI 프로젝트의 60%가 2026년까지 포기될 것으로 내다봤습니다.

여기서 말하는 준비된 데이터는 “데이터가 많다”는 뜻이 아닙니다. 생성형 AI 시대의 데이터 준비는 다음 네 가지를 묻습니다.

• 위치: 답의 근거가 되는 문서가 어디에 있는지 알고 있는가. 그룹웨어, 파일 서버, 개인 PC에 흩어져 있지 않은가.
• 최신성: 개정된 규정과 폐기된 규정이 섞여 있지 않은가. 무엇이 최신본인지 시스템이 알 수 있는가.
• 권한: 이 사람이 볼 수 없는 문서를 AI가 대신 보여 주지 않는가. 문서마다 열람 권한이 붙어 있는가.
• 맥락: 표, 이미지, 약어, 부서 고유 용어가 기계가 읽을 수 있는 형태로 정리되어 있는가.

이 네 가지가 비어 있으면 AI 도입 실패는 시간문제입니다. 검색 증강 생성(RAG)을 붙여도 결과가 나아지지 않습니다. 오래된 규정을 근거로 자신 있게 틀린 답을 내고, 현업은 한두 번 속은 뒤 다시 쓰지 않습니다. 답이 틀린 이유를 모델이 아니라 데이터에서 찾아야 하는 경우가 훨씬 많습니다. RAG 파이프라인의 구조와 점검 항목은 RAG란 무엇인가에 따로 정리해 두었습니다.

단순한 RAG 구조가 PoC에서 인기를 끈 이유도 여기에 있습니다. 구현이 쉽고 내부 문서로 질의응답 화면을 금방 보여 줄 수 있어 시연용으로는 매력적입니다. 하지만 운영 환경에서 서로 얽힌 문서, 표, 부서 간 관계를 만나면 한계가 바로 드러납니다. PoC에서 통한 검색 구조가 운영에서도 통한다는 보장은 없다는 점을 데이터 준비 계획에 넣어 두어야 합니다. 고객 상담 챗봇이 존재하지 않는 보증 정책을 안내하는 순간, 문제는 품질이 아니라 기업 평판과 책임의 문제로 커집니다.

AI 도입 실패를 데이터 관점에서 미리 막으려면 과제 범위를 데이터가 준비된 곳으로 좁혀야 합니다. 전사 문서를 한꺼번에 넣는 대신, 소유자가 분명하고 개정 이력이 관리되는 문서 묶음 하나로 시작합니다. 예를 들어 인사 규정 전체가 아니라 “출장비 정산 규정과 최근 2년 질의응답”처럼 범위를 잘라 냅니다. 그리고 데이터 소유 부서에 품질 책임자를 지정합니다. 데이터 정비는 화려하지 않지만, 이 단계를 건너뛴 프로젝트가 가장 먼저 멈추고 AI 도입 실패 목록에 오릅니다.

AI를 기존 업무 흐름 옆에 붙이기만 하면, 사람이 AI 결과를 다시 옮겨 적는 일이 하나 더 늘어날 뿐입니다. MIT NANDA 보고서가 생성형 AI 투자에서 수익을 얻지 못한 원인으로 모델 품질보다 깨지기 쉬운 업무 흐름, 맥락 학습 부족, 일상 업무와의 부조화를 꼽았다고 보도된 것도 같은 맥락입니다.

프로세스에서 비롯된 AI 도입 실패의 흔한 장면을 하나 보겠습니다. 콜센터 상담원에게 상담 요약 AI를 제공했습니다. 요약은 잘 나옵니다. 그런데 요약 결과가 상담 이력 시스템에 자동으로 들어가지 않아, 상담원은 요약문을 복사해 다시 붙여 넣고 항목을 고칩니다. 오히려 일이 늘었다는 불만이 나오고, 몇 달 뒤 사용률은 바닥으로 떨어집니다. 모델은 잘못한 것이 없습니다. 업무 흐름을 다시 설계하지 않은 것이 원인입니다.

프로세스를 바꾸지 않은 AI 도입 실패는 다음 특징을 보입니다.

• AI 결과를 업무 시스템에 넣는 단계가 사람 손에 남아 있다.
• AI를 쓰든 안 쓰든 결재 단계와 검토 횟수가 같다.
• AI가 처리한 건과 사람이 처리한 건을 구분해 집계하지 않는다.
• 예외 상황(AI가 모르는 질문)이 생겼을 때 넘길 곳이 정해져 있지 않다.

피하는 방법은 도입 전과 후의 업무 흐름도를 나란히 그리는 것입니다. 어떤 단계가 사라지고, 어떤 단계가 새로 생기며, 사람의 확인은 어디에 남는지를 그림으로 합의합니다. 그다음 AI 결과가 업무 시스템에 바로 들어가도록 연동을 설계합니다. 이때 업무 시스템과 모델, 도구를 하나의 흐름으로 묶는 계층이 필요한데, 그 구조는 AI 오케스트레이션이란? 모델·에이전트·도구를 연결하는 구조와 도입 기준에서 자세히 다룹니다.

아래 그림은 AI로 업무를 바꾸려 할 때 기술 바깥에서 만나는 세 장벽을 현상과 대응으로 나눠 보여 줍니다.

그림. AI 도입을 막는 것은 기술보다 업무 절차·조직 문화·사업 모델의 장벽입니다

특히 첫 번째 장벽에서 지표가 “AI를 반복해 쓸 때 업무 절차 전체의 생산성이 오르는가”로 적혀 있다는 점을 눈여겨볼 만합니다. 단일 작업의 속도가 아니라 절차 전체를 기준으로 재야 프로세스 변화가 성과로 잡힙니다.

한국은행이 “절감된 업무시간이 생산 증가로 이어지지 않았다”고 분석한 것도 이 지점입니다. 상담원 한 명이 하루 30분을 아꼈더라도, 그 30분에 무엇을 할지 정하지 않으면 성과는 숫자로 나타나지 않습니다. 아낀 시간을 어디에 다시 쓸지까지 설계해야 프로세스 혁신이 완성됩니다.

AI 도입은 기술 프로젝트처럼 시작하지만 실제로는 조직 변화 프로젝트이고, 이를 놓치면 현업이 쓰지 않는 시스템이 남습니다. BCG는 2024년 조사에서 AI로 가치를 내는 선도 기업이 자원의 70%를 사람과 프로세스에, 20%를 기술과 데이터에, 10%만 알고리즘에 쓴다고 정리했습니다. 대부분의 실패 조직은 이 비율이 거꾸로입니다.

조직 요인에서 비롯된 AI 도입 실패는 세 가지 얼굴로 나타납니다.

1. 책임자 부재: 과제를 IT 부서에 맡기고 현업 부서장은 결과만 기다립니다. 현업의 우선순위가 바뀌면 프로젝트는 아무도 챙기지 않는 상태가 됩니다.
2. 불안과 저항: 현장 직원은 “AI가 내 일을 대신하면 나는 어떻게 되나”를 먼저 걱정합니다. 이 질문에 답하지 않으면 사용을 미루거나 결과의 흠만 찾게 됩니다.
3. 역량 공백: 대한상의 조사에서 80.7%가 AI 전문인력이 없다고 답했습니다. 외부 업체가 만들어 주고 떠난 뒤에는 프롬프트 하나 고칠 사람이 없어 시스템이 굳어 버립니다.

아래 그림은 같은 메시지를 조직 관점에서 다시 정리한 것입니다. AI 중심의 업무 설계와 사람 중심의 시스템 설계가 함께 가야 하고, 효율화 효과와 잘못된 결과를 허용하는 비용을 같이 따져야 합니다.

그림. AI 도입의 벽은 업무 프로세스·조직 문화·비즈니스 모델 세 곳에 있습니다

조직 요인의 AI 도입 실패를 피하는 방법은 역할을 먼저 정하는 것입니다. 최소한 다음 네 역할은 이름을 붙여 배정해야 합니다.

변화관리는 교육 한 번으로 끝나지 않습니다. 처음 석 달 동안은 현장 의견을 주 단위로 모으고 바로 고치는 체계가 필요합니다. 사용자가 “고쳐 달라고 했더니 다음 주에 고쳐졌다”를 한 번 경험하면 신뢰가 생깁니다. 인력 공백을 AI 에이전트로 어디까지 메울 수 있는지, 그리고 어떤 역량은 사람에게 남겨야 하는지는 AI 인재 부족 시대, AI Agent로 무엇을 대체할 수 있나에서 다섯 가지 역량으로 정리했습니다.

보안·개인정보·법무 검토를 운영 직전으로 미루면, 다 만든 시스템이 심사 단계에서 멈춥니다. Gartner가 2024년과 2025년 전망 모두에서 부족한 위험 통제를 주요 중단 사유로 꼽은 것도 이 때문입니다. S&P Global 조사를 전한 보도에서도 데이터 프라이버시와 보안 위험이 비용과 함께 대표 장애물로 나왔습니다.

국내 공공기관과 금융사는 이 유형의 AI 도입 실패가 더 큽니다. 망분리, 개인정보 처리, 외부 클라우드 사용 제한 같은 요건이 있어, PoC 때 외부 API로 만든 구조를 운영 단계에서 그대로 쓸 수 없는 경우가 많습니다. 결국 PoC 결과물을 버리고 구조를 처음부터 다시 짜야 하는 상황이 생깁니다. 이는 AI 도입 실패 가운데 가장 비싼 형태입니다.

거버넌스를 미뤄 AI 도입 실패로 이어진 프로젝트에서 자주 보이는 장면은 다음과 같습니다.

• 어떤 데이터가 외부 모델로 나가는지 목록이 없다.
• 프롬프트 인젝션, 권한 밖 데이터 노출 같은 위험을 시험한 기록이 없다.
• AI가 만든 답에 대해 누가 책임지는지, 사람이 언제 확인하는지 정해져 있지 않다.
• 모델 호출 기록과 비용 기록이 남지 않아 사고가 나도 원인을 추적할 수 없다.

피하는 방법은 설계 첫 주에 보안·법무 담당을 회의에 부르는 것입니다. 그리고 다음 세 가지를 문서로 남깁니다. 첫째, 처리하는 데이터 등급과 외부 전송 여부. 둘째, 사람 승인이 반드시 들어가는 단계. 셋째, 로그 보관과 감사 방법. 공공기관이라면 2025 공공 AI 도입 가이드라인과 공공기관 AI, 왜 온프레미스여야 하는가를 함께 보면 어떤 구조로 시작해야 심사를 통과하기 쉬운지 감을 잡을 수 있습니다. 전사 차원의 거버넌스 틀은 엔터프라이즈 AI 거버넌스 가이드에 정리되어 있습니다.

외부 플랫폼이나 클라우드 서비스를 쓴다면 계약 단계의 문장도 거버넌스입니다. 기관이 입력한 원본 데이터, 추론 중에 생기는 임베딩과 캐시, 사용자에게 돌려준 출력 데이터의 보관 위치, 접근 권한, 삭제 명령권이 누구에게 있는지 계약서에 적혀 있어야 합니다. “로그 분석을 위해 공급사 클라우드로 자동 전송된다”는 한 줄 조항이 부속서에 숨어 있으면, PoC가 성공해 운영 범위가 넓어지는 순간 그 공백이 드러납니다. 그래서 이런 통제권 조항은 운영 계약이 아니라 PoC 제안요청서 단계에서 이미 넣어 두는 것이 안전합니다.

AI 비용은 PoC 때는 작아 보이다가 사용자가 늘면 비선형으로 커지기 때문에, 처음부터 트래픽과 한도를 기준으로 계산하지 않으면 운영 단계에서 멈춥니다. Gartner는 2024년 발표에서 생성형 AI의 개발·배포 비용 부담이 커지고 있고, 생산성 향상을 직접적인 재무 효과로 바꾸기 어렵다는 점을 지적했습니다. 대한상의 조사에서도 73.6%가 투자비용을 부담으로 꼽았습니다.

비용 오판에서 비롯된 AI 도입 실패는 보통 두 방향으로 나타납니다.

• 과소 산정: 시범 사용자 20명 기준으로 비용을 잡았다가 전사 2,000명으로 늘면서 외부 API 비용이 예산을 넘습니다. 에이전트형 서비스는 질문 한 건에 모델 호출이 여러 번 일어나 계산이 더 어긋납니다.
• 과대 투자: 반대로 “보안 때문에 사내 설치가 필요하다”며 GPU 서버부터 대량으로 사 놓고, 정작 쓸 과제와 트래픽이 정해지지 않아 장비가 놀고 있습니다.

두 경우의 AI 도입 실패 모두 순서가 거꾸로라는 공통점이 있습니다. 올바른 순서는 업무 트래픽 추정, 모델 결정, 인프라 산정입니다. GPU를 몇 장 사야 하는지, 언제 사내 설치형으로 가야 하는지, 추론 단가가 떨어지는 흐름을 어떻게 읽을지는 LLM 도입이 실패하는 이유는 GPU가 부족해서가 아니다에서 비용 곡선과 함께 자세히 다뤘습니다. 이 글에서는 조직 관점에서 꼭 정해야 할 세 가지만 짚습니다.

1. 비용 책임 부서: 모델 호출 비용을 IT 예산으로 볼지, 사용 부서에 배분할지 정합니다. 정하지 않으면 사용량이 늘어도 아무도 줄이려 하지 않습니다.
2. 사용 한도: 사용자·부서·서비스별 호출 한도와 경보 기준을 둡니다. LLM 게이트웨이를 쓰면 이 한도를 한 곳에서 관리할 수 있습니다.
3. 모델 등급: 모든 요청을 가장 비싼 모델로 보내지 않습니다. 간단한 분류·요약은 경량 모델, 복잡한 추론만 고성능 모델로 나눕니다.

인프라 관점의 AI 도입 실패는 결국 비용을 기술 문제로만 보고 운영 정책으로 다루지 않은 결과입니다.

도입 전 기준선을 재지 않은 프로젝트는 효과가 있어도 증명할 수 없고, 증명하지 못한 프로젝트는 다음 예산을 받지 못합니다. BCG 조사에서 74%가 가시적 가치를 입증하지 못했다고 답한 것도, 실제로 가치가 없어서라기보다 측정 체계가 없어서인 경우가 적지 않습니다.

성과 측정이 빠진 AI 도입 실패는 예산 심의 자리에서 드러납니다. “사용자 만족도가 높았다”, “직원들이 편해졌다”는 말은 정성 평가일 뿐, 비용 대비 효과를 설명하지 못합니다. 특히 공공기관은 다음 해 예산 편성에서 정량 근거를 요구하므로, 측정 설계가 없으면 성공한 시범 사업도 연속 사업이 되지 못합니다.

측정 지표는 세 층으로 나눠 잡으면 설명이 쉬워집니다.

측정에서 비롯된 AI 도입 실패의 가장 흔한 실수는 업무 지표의 기준선을 도입 전에 재지 않는 것입니다. 도입 후에 “예전에는 30분쯤 걸렸던 것 같다”고 추정하면 그 숫자는 아무도 믿지 않습니다. PoC를 시작하기 전 2주 동안이라도 실제 처리 시간을 기록해 두면 이후 모든 설명이 쉬워집니다. AI 에이전트 도입의 단계별 비용 변화와 ROI 계산 예시는 AI Agent 도입 로드맵 — 사전 준비부터 단계별 적용·비용 변화까지에 정리되어 있습니다.

측정 대상 업무를 고르고 보안 점검과 ROI 측정을 한 흐름으로 묶는 절차는 Flowise 엔터프라이즈 도입 4단계 — 자동화 대상 선정부터 보안·ROI 측정까지에 예시와 함께 정리되어 있습니다.

PoC가 운영으로 넘어가지 못하는 것은 PoC와 운영의 성공 조건이 서로 다르기 때문입니다. S&P Global 조사를 인용한 보도에서 기업들이 평균적으로 PoC의 46%를 운영 전에 폐기했다는 결과는, 많은 조직이 이 간격을 넘지 못하고 있음을 보여 줍니다.

PoC 단계의 AI 도입 실패를 이해하려면 질문의 차이부터 봐야 합니다. PoC는 “될 수 있는가”를 묻고, 운영은 “매일 안정적으로, 안전하게, 감당할 수 있는 비용으로 되는가”를 묻습니다. 두 질문에 필요한 준비물이 다릅니다.

이 표의 오른쪽 열을 PoC 단계에서 전혀 생각하지 않으면, PoC가 성공할수록 오히려 운영 전환의 벽이 높아집니다. 기대치는 올라갔는데 준비물은 하나도 없기 때문입니다. 이것이 흔히 말하는 파일럿 함정(PoC 지옥)입니다. 시범 사업만 여러 개 돌고 아무것도 운영에 올라가지 않는 상태입니다.

아래 그림은 기업의 AI 활용이 한 업무에서 전사, 다시 에이전트로 넓어질수록 남는 기업이 줄어드는 이유를 세 가지 원인으로 보여 줍니다.

그림. PoC가 운영으로 넘어가지 못하는 세 가지 원인은 데이터 분산·보안 후행 설계·운영 설계 부재입니다

세 원인 모두 모델을 교체해서는 풀리지 않는다는 점이 이 그림의 핵심입니다.

피하는 방법은 PoC를 설계할 때부터 운영 전환 조건을 함께 적는 것입니다. “정확도가 기준을 넘고, 보안 심사 항목 열 가지 중 여덟 가지를 PoC 구조에서 이미 충족하면 운영으로 간다”처럼 숫자로 합의합니다. 그리고 PoC 기간을 짧게 잡습니다. 석 달을 넘긴 PoC는 대체로 목표가 흐려진 상태입니다. 또 PoC 결과 보고서에는 잘 된 점만이 아니라 운영 전환을 막을 수 있는 남은 과제를 함께 적습니다. 남은 과제 목록이 길어도 괜찮습니다. 문제는 목록이 없는 PoC이며, 그런 PoC가 AI 도입 실패의 출발점이 됩니다. 업무 흐름 도입을 PoC부터 ROI 분석까지 다섯 단계로 나눈 예시는 노코드 AI Agent 워크플로우 도입 5단계에서 볼 수 있습니다.

기대가 실제 기술 수준보다 크면, 정상적으로 동작하는 시스템도 실패로 평가받습니다. Gartner는 2025년 6월 발표에서 많은 공급사가 기존 AI 비서, RPA, 챗봇에 에이전트라는 이름만 새로 붙이는 이른바 에이전트 워싱을 하고 있으며, 수천 곳의 에이전틱 AI 공급사 가운데 실제 역량을 갖춘 곳은 약 130곳으로 추정한다고 밝혔습니다. 같은 발표에서 에이전틱 AI 프로젝트의 40% 이상이 2027년 말까지 취소될 것으로 전망했습니다.

과대 기대는 두 가지 방식으로 AI 도입 실패를 부릅니다.

• 과제 선정 오류: “에이전트가 알아서 다 한다”는 기대로, 판단 기준이 모호하고 예외가 많은 업무를 첫 과제로 고릅니다. RAND가 근본 원인으로 꼽은 기술 한계를 넘는 과제 선정이 바로 이것입니다.
• 평가 기준 왜곡: 사람도 90%를 못 맞히는 업무에 AI에게는 99%를 요구합니다. 그 기준을 못 넘으면 실패로 판정하고, 실제로 사람보다 나은 부분은 묻혀 버립니다.

피하는 방법은 공급사와 내부 모두에게 같은 질문을 던지는 것입니다. 이 제품은 사람 확인 없이 몇 단계까지 스스로 실행하는가, 실패했을 때 어떻게 멈추는가, 실제 고객의 운영 사례에서 어떤 지표가 바뀌었는가. 이 세 질문에 구체적으로 답하지 못하면 에이전트라는 이름을 걷어 내고 다시 평가합니다. 에이전트와 챗봇의 차이, 여러 에이전트를 함께 쓸 때 생기는 실패 모드는 AI Agent vs 챗봇과 멀티 에이전트 시스템 설계 — 협업 패턴과 도입 전 알아야 할 실패 모드를 참고하시기 바랍니다.

질문 하나를 더 보태면 좋습니다. 이 에이전트가 사람 확인 없이 수행하는 동작 가운데 되돌리기 어려운 것은 무엇인가. 자료를 찾아 요약만 하는 읽기 전용 에이전트와 파일을 고치고 외부로 메시지를 보내는 에이전트는 같은 이름을 달고 있어도 실패했을 때 치르는 비용이 전혀 다릅니다. 제품 이름에 에이전트가 붙었는지는 이 질문에 아무 답도 주지 않습니다.

공공·금융·제조는 실패하는 지점이 서로 다르므로, 업종의 제약부터 알고 시작해야 같은 실수를 피할 수 있습니다. 아래는 특정 기업의 사례가 아니라, 국내 프로젝트에서 반복적으로 관찰되는 대표 패턴을 업종별로 묶은 것입니다.

표를 보면 업종은 달라도 AI 도입 실패 원인의 뿌리는 앞의 일곱 가지 안에 있다는 점이 드러납니다. 공공은 데이터 최신성과 거버넌스, 금융은 권한과 프로세스 연동, 제조는 현장 운영 조직과 데이터 대표성이 약한 고리입니다.

국내 공공기관에서 AI 도입 실패를 피한 경우는 대체로 범위를 좁게 시작했습니다. 전 부서 민원이 아니라 한 개 부서의 자주 묻는 질문 수백 건으로 시작해, 답변 근거 문서를 함께 보여 주고, 담당 공무원이 답을 확인한 뒤 내보내는 구조를 택했습니다. 공공기관 AI 에이전트가 대국민 서비스를 바꾼 흐름은 공공기관 Ask Gov 도입 사례에서 볼 수 있습니다. 성공한 기업 쪽 이야기는 앞서 언급한 국내 기업 AI 도입 사례를 함께 읽으면 균형이 맞습니다.

반대로 공공에서 자주 보이는 AI 도입 실패 패턴은 범용 챗봇 하나를 단발성으로 발주하는 경우입니다. 질문에 답하는 1~2단계 수준에서 멈추면 채널 통합, 부처별 라우팅, 결재 연계, 운영 모니터링으로 넓힐 길이 없고, 몇 달 뒤 효용이 정체되면서 “AI는 써 봐도 소용없다”는 평가가 나옵니다. 그래서 최근 공공 사업은 챗봇 한 개가 아니라 업무 시스템을 하나씩 붙여 갈 수 있는 플랫폼 구조로 발주하는 흐름이 늘고 있습니다.

AI 도입 실패는 어느 날 갑자기 오지 않고, 몇 주 전부터 측정 가능한 신호를 보냅니다. 신호를 일찍 읽으면 과제를 고치거나 싸게 접을 수 있습니다.

이 AI 도입 실패 경보 표의 숫자는 절대 기준이 아니라 조직이 스스로 정해야 할 경보선의 예시입니다. 중요한 것은 경보선을 미리 정해 두고, 넘었을 때 누가 무엇을 결정하는지 합의해 두는 것입니다. 그래야 “조금만 더 해 보자”며 끌려가는 일을 막을 수 있습니다.

특히 사용자 감소 신호는 AI 도입 실패를 알리는 가장 정직한 지표입니다. 설문 만족도는 높게 나와도 실제 사용량이 줄면, 현업은 이미 마음속으로 그 시스템을 포기했다는 뜻입니다. 오답 사례를 모아 원인을 데이터·프롬프트·업무 흐름으로 나눠 보면, 대부분 한두 가지 원인에 몰려 있다는 것을 알게 됩니다.

과제를 접기로 했다면 그 과정도 자산으로 남겨야 합니다. 프로젝트를 닫을 때 무엇을 기대했고, 무엇이 달랐고, 다음에는 무엇을 먼저 확인할지를 한 장으로 정리하는 회고 문서를 씁니다. 책임을 묻는 자리가 아니라 다음 과제의 점검표를 고치는 자리로 운영하면, 한 번의 AI 도입 실패가 조직 전체의 학습으로 바뀝니다. 반대로 실패한 과제를 조용히 묻으면 다른 부서가 같은 AI 도입 실패를 되풀이합니다. 국내 기업에서 같은 유형의 챗봇 PoC가 부서마다 따로 돌다가 모두 멈추는 일이 반복되는 것도 이 회고가 공유되지 않기 때문입니다.

AI 도입 실패를 피하는 가장 확실한 방법은 작게 시작해 증명하고, 증명한 것만 넓히는 순서를 지키는 것입니다. 단계마다 다음 단계로 넘어가는 조건을 정해 두면 실패 비용이 작아집니다.

1. 진단(2~4주): 업무 후보를 10~20개 모으고, 효과 크기와 실행 난이도로 점수를 매겨 2~3개를 고릅니다. 데이터 준비 상태와 보안 등급을 함께 평가합니다.
2. 기준선 측정(2주): 고른 과제의 현재 처리 시간, 오류율, 처리 건수를 실제로 기록합니다.
3. PoC(6~10주): 좁은 범위의 실제 데이터로 시험합니다. 운영 전환 조건을 숫자로 미리 합의합니다.
4. 파일럿(2~3개월): 한 부서의 실제 업무에 넣고 업무 흐름을 바꿉니다. 사용 지표와 업무 지표를 매주 봅니다.
5. 운영 전환: 보안 심사, 장애 대응, 비용 한도, 상시 운영 조직을 갖추고 정식 서비스로 전환합니다.
6. 확산: 같은 플랫폼 위에 비슷한 과제를 하나씩 추가합니다. 공통 구성 요소(게이트웨이, 검색, 권한, 로그)는 재사용합니다.

이 순서에서 핵심은 단계마다 접을 수 있는 출구를 두는 것입니다. 진단에서 데이터가 없으면 접고, PoC에서 기준을 못 넘으면 접고, 파일럿에서 사용이 늘지 않으면 원인을 고치거나 접습니다. 작은 실패를 여러 번 허용하는 구조가 큰 AI 도입 실패를 막습니다.

단계를 나누는 기준은 기간보다 다음 단계로 넘어가는 조건이어야 합니다. 에이전트형 AI 프로젝트의 중단 사유로 꼽힌 불분명한 사업 가치와 부족한 위험 통제는, 언제 넓히고 언제 멈출지 미리 정하지 않은 프로젝트에서 커지기 때문입니다. 단계마다 하는 일, 남기는 산출물, 넘어가는 조건 세 가지를 한 줄씩 적어 두면 일정이 밀려도 판단 기준은 흔들리지 않습니다.

단계별로 필요한 결정권자도 다릅니다. 진단과 PoC는 현업 부서장과 IT 책임자가 결정할 수 있지만, 운영 전환과 확산은 예산과 조직을 움직여야 하므로 경영진의 결정이 필요합니다. 많은 AI 도입 실패가 이 경계에서 일어납니다. 파일럿 결과는 좋았는데 경영진 보고 자리에서 숫자가 준비되지 않아 결정이 미뤄지고, 그 사이 담당자가 바뀌며 동력이 사라집니다. 파일럿을 시작할 때 운영 전환 보고 날짜를 미리 잡아 두는 것만으로도 이런 공백을 크게 줄일 수 있습니다.

전사 차원의 AI 전환(AX) 관점에서 이 단계를 어떻게 조직 로드맵으로 만드는지는 AX(AI 전환)란 무엇인가와 AX 추진 전략과 로드맵에서 진단부터 전사 확산까지 단계별로 정리했습니다. 이 글의 여섯 단계는 그 로드맵 안에서 과제 하나를 끝까지 끌고 가는 실행 단위라고 보면 됩니다.

AI 도입 실패를 미리 걸러 내는 아래 20문항 가운데 “아니오”가 다섯 개를 넘으면 지금은 착수보다 준비를 먼저 해야 합니다. 회의 자리에서 그대로 체크해 쓸 수 있도록 원인별로 묶었습니다.

이 AI 도입 실패 점검표는 착수 전에 한 번, PoC 종료 시점에 한 번, 운영 전환 직전에 한 번 다시 봅니다. 같은 질문에 대한 답이 단계마다 구체해지는지가 프로젝트 건강도를 보여 줍니다. 경영진 보고 자료에 이 표를 그대로 붙이고 “아니오” 항목의 해소 계획을 함께 적으면, 예산 심의에서도 설득력이 높아집니다.

MSAP.ai는 과제 진단부터 운영 플랫폼까지 이어지는 흐름으로 AI 도입 실패를 줄입니다. 앞에서 본 일곱 가지 원인을 단계별로 다루도록 돕습니다.

• 진단 단계(문제 정의 실패 예방): 무료 AI Discovery Workshop에서 현업과 함께 업무 후보를 모으고, 효과와 난이도, 데이터 준비 상태로 우선순위를 정합니다. 문제 정의 없이 기술부터 고르는 실패를 첫 단계에서 막는 자리입니다. 더 깊은 검토가 필요하면 기업 맞춤형 AI 컨설팅으로 이어집니다.
• 실행 단계: 업무 전문가가 직접 에이전트를 만들고 운영하는 AI Agent Studio(AAS)로 현업 참여를 높입니다. IT 부서만 바쁘고 현업은 기다리는 구조를 바꾸는 데 초점을 둡니다.
• 운영 단계: AINP(AI Native Platform)로 모델·게이트웨이·검색·권한·로그를 사내 인프라에 한 번에 갖춥니다. 망분리와 데이터 주권 요건이 있는 공공·금융 환경에서도 PoC 구조를 버리지 않고 운영으로 넘어갈 수 있게 설계합니다.

GPU 인프라 비용이 첫 걸음을 막고 있다면, 장비 구매 전에 실제 사용량으로 검증해 보는 방법도 있습니다. 어떤 경우든 작게 시작해 숫자로 증명하는 순서는 바뀌지 않습니다.

• AI 도입 실패는 예외가 아니라 기본값에 가깝습니다. Gartner, RAND, BCG의 발표와 MIT NANDA, S&P Global 조사 보도가 모두 상당수 AI 과제가 PoC 이후 성과로 이어지지 못한다고 전합니다.
• 국내 제조기업의 82.3%가 아직 AI를 경영에 활용하지 않고, 60.6%가 성과를 의심합니다. 한 번의 실패가 다음 시도를 몇 년 늦출 수 있습니다.
• AI 도입 실패 원인은 일곱 가지입니다. 문제 정의, 데이터, 업무 프로세스, 인재와 조직, 거버넌스와 보안, 비용과 인프라, 성과 측정.
• 첫 번째 원인인 문제 정의를 바로잡으면 나머지 원인도 함께 줄어듭니다.
• PoC와 운영은 성공 조건이 다릅니다. PoC 설계 때부터 운영 전환 조건과 중단 조건을 숫자로 합의해야 합니다.
• GPU와 추론 비용 관점은 LLM 도입 실패 이유, AI 기본 개념은 AI란 무엇인가에서 이어서 확인할 수 있습니다.
• 착수 전 20문항 점검표에서 “아니오”가 다섯 개를 넘으면 준비부터 해야 합니다. 이번 분기 예산 계획에 이 점검표를 붙여 착수 여부를 결정해야 합니다.

AI 도입 실패율은 실제로 얼마나 되나요?

조사마다 정의와 대상이 달라 하나의 숫자로 말할 수는 없습니다. Gartner는 2025년 말까지 생성형 AI 프로젝트의 최소 30%가 PoC 이후 중단될 것으로 전망했고, S&P Global 조사를 인용한 보도에서는 대부분의 AI 과제를 포기한 기업 비율이 42%로 늘었습니다. RAND는 80% 이상 실패한다는 추정을 인용했습니다. 공통 결론은 상당수 AI 과제가 운영 성과로 이어지지 못한다는 것입니다.

AI 도입 실패의 가장 큰 원인은 무엇인가요?

가장 자주 지목되는 원인은 해결할 업무 문제를 정하지 않고 기술부터 고르는 것입니다. RAND 보고서도 이해관계자가 AI로 풀 문제를 잘못 이해하거나 잘못 전달하는 것을 첫 번째 근본 원인으로 꼽았습니다. 문제 정의가 흐리면 필요한 데이터, 성과 지표, 운영 책임자도 정할 수 없어 다른 원인이 연쇄적으로 생깁니다.

PoC는 성공했는데 왜 운영으로 넘어가지 못하나요?

PoC는 될 수 있는지를 확인하고, 운영은 매일 안정적이고 안전하게 감당할 수 있는 비용으로 되는지를 묻기 때문입니다. 전체 데이터와 권한, 정식 보안 심사, 장애 대응, 비용 한도, 상시 운영 조직이 PoC 단계에서 준비되지 않으면 성공한 PoC도 멈춥니다. PoC 설계 때부터 운영 전환 조건을 숫자로 합의해야 합니다.

데이터가 부족해도 AI 도입을 시작할 수 있나요?

시작할 수 있지만 범위를 데이터가 준비된 곳으로 좁혀야 합니다. 소유자가 분명하고 최신본 관리가 되는 문서 묶음 하나로 시작하고, 데이터 소유 부서에 품질 책임자를 지정합니다. Gartner는 AI에 맞게 준비된 데이터가 뒷받침하지 않는 AI 프로젝트의 60%가 2026년까지 포기될 것으로 전망했습니다.

AI 도입 실패 사례에서 업종별 차이가 있나요?

있습니다. 공공은 데이터 최신성과 망분리 같은 거버넌스 요건, 금융은 문서 권한과 업무 시스템 연동, 제조는 현장 운영 책임자와 학습 데이터의 대표성이 약한 고리로 자주 드러납니다. 다만 뿌리를 따라가면 문제 정의, 데이터, 프로세스, 조직, 거버넌스, 비용, 성과 측정이라는 일곱 가지 원인 안에 들어갑니다.

GPU가 부족해서 AI 도입이 실패하는 경우도 있나요?

GPU 부족이 직접 원인인 경우는 생각보다 적습니다. 더 흔한 것은 업무 트래픽을 추정하지 않은 채 GPU부터 사거나, 반대로 외부 API 비용을 과소 산정하는 순서 오류입니다. 트래픽 추정, 모델 결정, 인프라 산정 순서로 계산해야 하며, 자세한 내용은 MSAP.ai의 LLM 도입 실패 이유 글에서 비용 곡선과 함께 다룹니다.

AI 도입 실패를 피하려면 무엇부터 해야 하나요?

과제 정의서 한 장과 기준선 측정부터 시작합니다. 어떤 부서의 어떤 업무를 바꾸는지, 지금 처리 시간과 오류율이 얼마인지, 도입 후 목표치가 얼마인지, 누가 결과를 승인하는지를 적습니다. 그다음 20문항 점검표로 데이터, 프로세스, 조직, 거버넌스, 비용 준비 상태를 확인하고 “아니오”가 많은 영역부터 보완합니다.

MSAP.ai

• AI란 무엇인가 — 뜻·원리·종류부터 기업 도입까지
• LLM 도입이 실패하는 이유는 GPU가 부족해서가 아니다
• 국내 기업 AI 도입 사례 — 성과를 낸 기업은 무엇이 달랐나
• AX(AI 전환)란 무엇인가 — 정의부터 추진 4단계까지
• AX 추진 전략과 로드맵 — 진단부터 전사 확산까지
• AI Agent 도입 로드맵 — 사전 준비부터 단계별 적용·비용 변화까지
• AI 인재 부족 시대, AI Agent로 무엇을 대체할 수 있나
• 무료 AI Discovery Workshop

OPENMARU · Cloud Native Forum

• 찾아가는 AI 네이티브 세미나 — AI 도입, 아직도 막막하신가요?
• AI 시대, 왜 모두가 프라이빗 클라우드를 주목할까?
• AI MCP 전략이란? 모델 크기보다 투자 효율을 높이는 비결
• GraphRAG란? 데이터 연결이 만드는 차세대 엔터프라이즈 AI

외부 조사

• Gartner — 생성형 AI 프로젝트 30% PoC 이후 중단 전망(2024)
• Gartner — AI에 맞는 데이터 부족이 AI 프로젝트를 위협(2025)
• Gartner — 에이전틱 AI 프로젝트 40% 이상 취소 전망(2025)
• RAND — The Root Causes of Failure for Artificial Intelligence Projects(2024)
• BCG — AI Adoption in 2024: 74% of Companies Struggle to Achieve and Scale Value
• MIT NANDA 보고서 보도 — The GenAI Divide(2025)
• CIO Dive — S&P Global 조사, AI 과제 포기 기업 42%(2025)
• 대한상공회의소 — K-성장 시리즈(7) 기업의 AI 전환 실태와 개선방안 보고서(2025-11-19)
• 한국은행 BOK 이슈노트 제2026-12호 — AI 도입은 생산성을 높이는가? 초기 3년의 효과 분석(2026-06-08)