기업용 AX 전환 프로젝트의 95%가 성과로 이어지지 못하는 6가지 이유

기업에 ChatGPT나 업무용으로 생성형 AI를 도입하는 일은 이제 어렵지 않습니다. 전 직원에게 AI 계정을 지급하고 활용 교육을 진행하는 기업도 빠르게 늘고 있어요.

그런데 AI를 사용하는 직원이 늘었다고 해서 회사의 업무 방식까지 달라지는 것은 아닙니다.

이메일이나 보고서 초안을 조금 빠르게 작성할 수는 있지만, 계약서 검토나 인허가 자료 확인처럼 많은 시간과 전문성이 필요한 핵심 업무는 여전히 사람이 처음부터 끝까지 처리하는 경우가 많아요.

MIT Project NANDA가 2025년 발표한 연구에서는 이러한 간극을 ‘GenAI Divide’라고 설명했습니다. AI를 사용해 본 기업은 많지만, 이를 실제 업무에 통합해 지속적인 생산성 향상이나 손익 성과를 만든 기업은 매우 적다는 뜻이에요.

보고서가 제시한 숫자는 상당히 강렬합니다.

기업용 생성형 AI 프로젝트 가운데 지속적인 업무 또는 재무 성과를 보여준 비율은 약 5%에 그쳤습니다.

반대로 표현하면 약 95%는 측정 가능한 성과로 이어지지 못했다는 의미입니다.

그렇다면 기업의 AI 프로젝트는 왜 좋은 시연과 초기 검증을 넘어 실제 업무 성과로 이어지지 못할까요?

기업용 생성형 AI 프로젝트의 95%가 실패했다는 뜻일까요?

MIT Project NANDA의 「The GenAI Divide: State of AI in Business 2025」는 다음 자료를 바탕으로 작성됐습니다.

• 300개 이상의 공개된 AI 프로젝트 분석

• 52개 기업 및 조직 관계자 인터뷰

• 153명의 고위 리더 설문

• 2025년 1월부터 6월까지의 프로젝트 추적

연구에서는 특정 업무를 처리하는 생성형 AI 솔루션이 초기 검증 단계를 넘어 실제 업무에 배포되고, 6개월 뒤에도 측정 가능한 생산성 또는 손익 효과를 만든 경우를 성공으로 정의했습니다.

따라서 95%라는 숫자를 다음과 같이 해석해서는 안 됩니다.

• AI 프로젝트의 95%가 모두 폐기됐다는 뜻은 아니에요.

• AI를 사용한 직원의 95%가 효과를 느끼지 못했다는 의미도 아닙니다.

• 생성형 AI 기술 자체가 95%의 확률로 작동하지 않는다는 의미도 아니에요.

• 모든 산업과 모든 기업에 동일한 실패율이 적용된다는 뜻도 아닙니다.

대부분의 프로젝트는 AI 답변을 생성하는 데는 성공했지만, 실제 업무에 지속적으로 사용되거나 회사의 손익과 생산성 지표를 바꾸는 단계까지 도달하지 못했습니다.

보고서도 이 수치가 기업의 공식 재무공시만으로 계산된 절대적인 실패율은 아니라고 밝혔어요. 인터뷰 표본의 편향 가능성이 있고, 기업과 산업마다 성공 기준이 다르며, 6개월의 관찰 기간이 복잡한 프로젝트의 장기 효과를 판단하기에는 짧을 수 있습니다.

따라서 가장 정확한 해석은 다음과 같습니다.

MIT Project NANDA가 분석한 기업용 생성형 AI 프로젝트 가운데 약 95%는 지속적인 생산성 향상이나 손익 성과를 입증하지 못했습니다.

74%와 95%는 무엇이 다를까요?

기업 AI 성과와 관련해서는 74%, 95%, 56%처럼 서로 다른 숫자가 인용됩니다. 이 숫자들은 같은 실패율을 측정한 것이 아니에요.

숫자의 기준은 다르지만 공통적인 메시지는 분명합니다.

AI를 사용해 본 기업은 많지만, AI를 실제 업무에 통합해 측정 가능한 성과를 만든 기업은 아직 적습니다.

문제는 AI 모델을 사용할 수 있느냐가 아닙니다. AI를 어떤 업무에 적용하고, 현업이 사용하는 방식으로 설계하며, 결과를 어떻게 검증하고 개선하는지가 더 중요해요.

이유 1. 해결하려는 문제보다 “AI로 무엇을 할 수 있을까?”부터 묻습니다

기업의 AI 프로젝트는 흔히 다음 질문에서 시작합니다.

“생성형 AI로 우리 회사에서 무엇을 할 수 있을까요?”

자연스러운 질문처럼 보이지만, 이 질문부터 시작하면 AI 기능을 보여주기 쉬운 과제만 늘어나기 쉽습니다.

회의록 요약, 이메일 작성, 문서 번역, 아이디어 생성처럼 구현하기 쉬운 기능을 먼저 찾게 되는 것이죠. 이런 기능은 개인 생산성을 높이는 데 도움이 되지만, 회사가 오랫동안 비용을 지출해 온 중요한 문제를 해결하지는 못할 수 있습니다.

AI 프로젝트는 기능 목록이 아니라 문제 목록에서 출발해야 합니다.

다음과 같은 질문을 먼저 해보세요.

• 사람이 반복적으로 검토하느라 많은 시간을 사용하는 업무는 무엇인가요?

• 숙련된 담당자에게 판단이 집중돼 병목이 발생하는 업무는 무엇인가요?

• 문서가 많고 흩어져 있어 정보를 찾는 데 시간이 오래 걸리는 업무는 무엇인가요?

• 누락이나 오류가 발생했을 때 손실이 큰 업무는 무엇인가요?

• 인력을 더 투입하지 않으면 처리량을 늘리기 어려운 업무는 무엇인가요?

• 기존 시스템으로는 자동화하기 어려워 사람이 계속 처리해 온 업무는 무엇인가요?

예를 들어 “계약서를 요약하는 AI”보다 “계약서의 필수 조항 누락과 변경 내용을 찾아 검토 시간을 줄이는 방법”이 더 좋은 출발점이에요.

“인허가 신청서를 작성하는 AI”보다 “신청서와 여러 첨부 자료 사이의 불일치를 찾아내는 방법”이 더 명확한 문제입니다.

AI로 할 수 있는 일을 찾지 말고, 비용과 시간이 많이 들지만 기존 방식으로 해결하기 어려웠던 문제를 먼저 찾으세요.

이유 2. 중요한 한 가지 업무보다 전사적인 범용 AI부터 도입합니다

전 직원에게 범용 AI를 제공하면 사용자는 빠르게 늘어날 수 있습니다. 하지만 사용자가 많다는 것과 회사의 핵심 업무가 바뀌었다는 것은 다른 문제예요.

MIT Project NANDA 연구에서도 ChatGPT나 Copilot 같은 범용 AI를 검토하거나 사용해 본 기업은 많았습니다. 범용 AI는 이메일 작성이나 간단한 분석처럼 개인 단위의 업무에는 유용했어요.

하지만 기업의 중요한 업무에서는 한계가 나타났습니다.

사용자가 매번 필요한 맥락을 다시 설명해야 하고, 회사의 업무 기준과 예외 조건을 제대로 반영하지 못하며, 기존 업무 흐름과 연결되지 않았기 때문이에요.

기업 AI는 다음 두 가지로 구분해서 접근할 필요가 있습니다.

처음부터 모든 부서에 동일한 AI를 배포할 필요는 없습니다.

한 업무팀이 중요하게 수행하는 반복 업무 하나를 고르고, 해당 업무에 필요한 자료와 판단 기준, 결과 형식이 반영된 특화 AI 에이전트부터 시작하는 편이 현실적이에요.

다만 쉬운 업무만 찾아서는 안 됩니다. 범위는 좁게 잡되, 해결했을 때 현업이 분명한 가치를 느낄 수 있는 문제를 선택해야 합니다.

즉, 쉬운 문제를 고르는 것이 아니라 어려운 문제를 작게 나누는 방식이 필요해요.

이유 3. AI 시연은 만들지만 실제 업무에는 연결하지 못합니다

정리된 샘플 자료를 AI에 입력해 그럴듯한 답변을 만드는 것은 어렵지 않습니다.

하지만 실제 업무에는 다음과 같은 변수가 존재해요.

• 형식이 서로 다른 수십 개의 문서

• 오래된 자료와 최신 자료가 섞인 폴더

• 동일한 문서의 여러 버전

• 조직과 고객별로 다른 판단 기준

• 담당자만 알고 있는 예외 조건

• 부서별 접근 권한

• 검토와 승인 절차

• 결과를 입력해야 하는 기존 업무 시스템

AI가 이러한 업무 흐름과 분리돼 있다면 사용자는 자료를 직접 찾아 업로드하고, 필요한 배경을 매번 다시 설명하고, AI 결과를 기존 시스템에 다시 옮겨야 합니다.

오히려 업무 단계가 하나 더 늘어날 수도 있어요.

MIT 연구는 기업용 AI 프로젝트가 중단되는 주요 원인으로 경직된 업무 흐름, 맥락 학습 부족, 일상적인 업무 방식과의 불일치를 지목했습니다.

AI를 도입할 때는 답변 품질만 볼 것이 아니라 전체 업무 흐름을 함께 설계해야 합니다.

1. 어떤 자료가 입력되는가

2. AI가 어떤 기준으로 자료를 처리하는가

3. 결과가 어떤 형식으로 작성되는가

4. 근거가 되는 원문을 어떻게 확인하는가

5. 담당자가 어떤 부분을 검증하는가

6. 누가 결과를 승인하는가

7. 수정 내용과 예외 사례를 어떻게 반영하는가

예를 들어 계약서 검토 AI라면 단순히 계약서를 요약하는 데서 끝나서는 안 됩니다.

계약서를 표준 조항과 비교하고, 변경되거나 누락된 조항을 정리하고, 각 판단의 근거가 되는 원문을 연결하고, 담당자가 확인한 결과를 일정한 형식으로 저장할 수 있어야 해요.

AI를 기존 업무 옆에 추가하는 것이 아니라, 실제 업무 안에서 역할을 맡도록 설계해야 합니다.

이유 4. 피드백을 받아도 같은 실수를 반복합니다

업무용 AI는 한 번 좋은 답변을 생성했다고 해서 완성되는 것이 아닙니다.

실제 업무 자료를 사용하면 예상하지 못한 문서 형식과 예외 조건이 계속 발견돼요. 특정 고객에게만 적용되는 조항이나, 부서별로 다른 작성 기준도 존재합니다.

그런데 많은 기업용 AI는 사용자가 결과를 수정해도 다음 작업에서 같은 실수를 반복합니다. 프로젝트를 진행하며 발견한 예외 조건과 업무 기준이 시스템에 반영되지 않는 것이죠.

MIT 연구는 이를 ‘학습 격차’라고 설명합니다.

보고서에 따르면 기업 담당자들은 업무용 AI에 다음과 같은 특성을 기대했어요.

• 현업의 피드백을 반영할 것

• 이전 업무의 맥락을 유지할 것

• 특정 팀의 업무 방식에 맞게 조정될 것

• 업무 기준이 바뀌었을 때 수정할 수 있을 것

• 반복적으로 사용하는 과정에서 결과가 개선될 것

여기서 학습은 반드시 AI 모델을 새로 훈련한다는 의미는 아닙니다.

업무 규칙을 추가하거나, 참고 자료를 최신 상태로 유지하거나, 결과 형식을 수정하거나, 자주 발생하는 예외 사례를 처리 흐름에 반영하는 것도 포함돼요.

중요한 것은 현업의 피드백이 다음 결과에 영향을 주는 구조입니다.

AI 프로젝트를 시작할 때는 다음 질문을 확인해야 합니다.

• 잘못된 결과를 누가 기록하나요?

• 오류의 원인을 어떻게 분류하나요?

• 새로운 업무 규칙은 어디에 반영하나요?

• 변경된 결과를 현업이 다시 검증하나요?

• 개선 전후의 결과를 같은 기준으로 비교하나요?

피드백이 쌓이기만 하고 실제 시스템은 변하지 않는다면, 사용자는 곧 AI를 신뢰하지 않게 됩니다.

이유 5. 경영진과 전담 조직이 정하고 현업에는 사용만 요구합니다

AX 전환에는 경영진의 지원이 필요합니다.

예산을 배정하고, 우선순위를 정하고, 데이터 사용과 결과 책임에 관한 기준을 만드는 일은 현업팀만으로 결정하기 어렵기 때문이에요.

하지만 중앙 전담 조직이 AI 도구와 사용 방법을 모두 정한 뒤 현업에 사용을 지시하는 방식도 성공하기 어렵습니다.

실제 업무를 수행하는 사람만 알고 있는 다음 내용이 빠질 수 있기 때문이에요.

• 문서가 실제로 들어오는 경로

• 검토할 때 중요하게 보는 항목

• 규정에는 없지만 실무에서 적용하는 기준

• 자주 발생하는 예외 사례

• 결과물을 전달받는 다음 담당자의 요구

• 기존 방식에서 가장 많은 시간이 걸리는 단계

MIT 연구는 성과를 만든 조직이 중앙의 AI 연구 조직보다 현업 관리자를 중심으로 프로젝트를 추진하는 경향이 있다고 설명합니다.

그렇다고 모든 결정을 현업에 맡겨야 한다는 뜻은 아니에요. 역할을 나누어야 합니다.

가장 좋은 방식은 위에서 방향과 안전 기준을 정하고, 아래에서 실제 업무를 설계하는 것입니다.

현업 실무자가 AI를 직접 사용하며 “이전보다 확실히 편해졌다”는 경험을 해야 새로운 활용 아이디어도 나옵니다. 이런 경험 없이 전사 교육과 활용 캠페인만 진행하면 AI는 일회성 도구로 끝날 가능성이 커요.

한 팀에서 먼저 눈에 보이는 결과를 만들고, 다른 팀이 이를 직접 확인하게 하세요. 첫 번째 성공 사례가 조직 안에서 만들어져야 수평적인 확장이 시작됩니다.

이유 6. 보안과 성과 기준을 정하지 않은 채 오래 개발합니다

기업의 AI 프로젝트에서는 정확도만큼 정보보안이 중요합니다.

계약서, 인사 자료, 고객 정보, 연구 자료, 재무 자료를 사용하는 경우에는 어떤 정보를 어디까지 연결할 수 있는지 먼저 정해야 해요.

하지만 보안 검토를 프로젝트 마지막에 진행하면 이미 설계한 구조를 변경해야 하거나, 실제 업무 자료를 사용할 수 없어 프로젝트가 중단될 수 있습니다.

AI 프로젝트를 시작하기 전에 다음 내용을 확인하세요.

• 어떤 등급의 업무 자료를 사용할 수 있나요?

• 원본 파일은 어디에 저장되나요?

• 외부 서버나 AI 모델로 전달되는 정보는 무엇인가요?

• 입력한 자료가 AI 모델 학습에 사용되나요?

• 질문과 답변 기록은 어디에 저장되나요?

• 삭제한 자료는 언제 완전히 사라지나요?

• 사용자와 부서별 접근 권한을 설정할 수 있나요?

• 누가 어떤 자료를 사용했는지 확인할 수 있나요?

• AI 결과를 사람이 검증하고 승인하는 절차가 있나요?

성과 기준도 프로젝트가 끝난 뒤 정해서는 안 됩니다.

AI 답변이 좋아 보인다는 인상만으로는 프로젝트를 확대할 근거를 만들기 어려워요. 시작하기 전에 기존 업무의 상태를 측정하고, AI 도입 이후 같은 기준으로 비교해야 합니다.

예를 들면 다음과 같은 지표를 사용할 수 있어요.

• 문서 한 건을 처리하는 데 걸리는 시간

• 담당자 한 명이 하루에 처리할 수 있는 문서 수

• 검토 과정에서 발견하지 못한 누락 항목 수

• 결과를 다시 작성해야 하는 비율

• 담당자와 승인자가 검증에 사용하는 시간

• 수정 없이 사용할 수 있는 결과의 비율

• 현업 사용자의 반복 사용률

오랜 기간 완성된 시스템을 만든 뒤 공개하기보다, 실제 업무 자료로 빠르게 검증하고 현업의 피드백을 받아 반복적으로 개선해야 합니다.

빠른 검증의 목적은 빨리 성공했다고 선언하는 것이 아니에요. 잘못된 가정을 작은 비용으로 발견하고, 현업이 체감할 수 있는 결과가 나올 때까지 개선하는 것입니다.

성과를 만드는 기업은 어떻게 다를까요?

MIT Project NANDA 연구에서 성과를 만든 프로젝트는 공통적으로 다음과 같은 특징을 보였습니다.

• 광범위한 기능보다 범위가 좁고 가치가 큰 업무에 집중했습니다.

• 기존 업무 방식과 깊게 연결됐습니다.

• 현업의 피드백을 반영하며 결과를 개선했습니다.

• 중앙 전담 조직보다 현업 관리자와 실무자가 적극적으로 참여했습니다.

• 소프트웨어를 구매하는 데 그치지 않고 업무를 함께 설계했습니다.

• 사용자가 빠르게 가치를 확인할 수 있는 결과부터 만들었습니다.

• 사용량이 아니라 비용·시간·오류와 같은 업무 지표로 평가했습니다.

결국 성공한 기업은 더 많은 AI 기능을 도입한 것이 아니에요.

특정 업무를 더 잘 처리하도록 설계된 AI를 실제 업무에 적용하고, 결과를 측정하며 개선했습니다.

AX 전환 팁: ‘한 팀·한 문제·한 에이전트·한 지표’로 시작하세요

처음부터 전사적인 AX 전환을 추진하면 해결해야 할 문제가 지나치게 많아집니다.

첫 번째 프로젝트는 다음 네 가지를 명확히 정하는 것부터 시작하는 것이 좋아요.

한 팀

문제가 명확하고, 담당자가 개선 의지가 있으며, 결과의 정확성을 직접 판단할 수 있는 업무팀을 선택합니다.

한 문제

단순히 구현하기 쉬운 기능이 아니라 시간, 비용, 인력 또는 오류 부담이 큰 문제를 선택합니다.

한 에이전트

여러 업무를 두루 처리하는 범용 도구보다 입력 자료, 작업 기준, 결과물과 검증 절차가 명확한 특화 AI 에이전트를 설계합니다.

한 지표

처리 시간, 누락 건수, 재작업률, 처리량처럼 도입 전후를 비교할 수 있는 지표를 정합니다.

예를 들어 “법률팀에 AI를 도입한다”는 계획은 범위가 너무 넓어요.

다음과 같이 바꾸면 프로젝트의 범위와 목표가 명확해집니다.

법률팀이 검토하는 계약서를 표준 조항과 비교해 누락·변경 항목과 원문 근거를 정리하고, 계약서 한 건의 1차 검토 시간을 측정한다.

어떤 업무부터 시작하면 좋을까요?

첫 번째 AI 업무는 다음 다섯 가지 조건으로 평가할 수 있습니다.

다섯 가지 조건을 모두 만족하지 않아도 괜찮습니다. 하지만 결과를 정의하거나 검증할 수 없는 업무는 첫 번째 프로젝트로 적합하지 않아요.

특히 법률, 인허가, 관세, 재무처럼 전문적인 판단이 필요한 업무에서는 AI가 최종 결론을 내리게 해서는 안 됩니다.

AI가 검토할 항목과 근거를 정리하고, 담당자가 이를 확인한 뒤 승인하는 구조로 시작하는 것이 안전해요.

부서별로 시작할 수 있는 특화 AI 에이전트 예시

공통점은 AI에게 모든 판단을 맡기는 것이 아니라는 점이에요.

자료를 찾고, 비교하고, 누락 가능성을 표시하고, 근거를 정리하는 반복 업무는 AI가 맡습니다. 최종 판단과 승인은 담당자가 수행합니다.

기업 AI 프로젝트의 실전 진행 순서

1. 비용이 큰 문제를 수집합니다

직원들에게 원하는 AI 기능을 묻기보다 현재 많은 시간과 인력이 투입되는 업무를 조사하세요. 반복되는 오류, 고객 불만, 숙련자 의존도도 함께 확인합니다.

2. 한 팀의 중요한 업무를 선택합니다

조직 전체에서 사용할 수 있는 기능보다 해당 팀의 문제를 실제로 해결할 수 있는지가 우선입니다. 범위는 좁되 해결했을 때 가치가 큰 업무를 선택하세요.

3. AI 에이전트가 맡을 범위를 정합니다

사용할 자료, AI가 처리할 작업, 필요한 결과물, 출처 표시 방식과 사람의 승인 단계를 정합니다. AI가 판단하지 않아야 할 영역도 함께 정의해야 해요.

4. 보안 요구사항을 확인합니다

자료의 저장과 전송 방식, 접근 권한, 삭제 정책, 모델 학습 여부, 사용 기록과 사람의 검증 절차를 확인합니다.

5. 실제 자료로 빠르게 검증합니다

정리된 예제만 사용하지 말고 실제 업무에서 발생하는 다양한 문서와 예외 사례를 포함하세요. 기존 업무 시간과 AI 사용 후 시간을 같은 기준으로 비교합니다.

6. 현업 피드백으로 개선합니다

잘못된 결과와 사용하기 불편한 지점을 기록하고, 업무 규칙과 결과 형식을 수정합니다. 현업이 개선된 결과를 다시 확인할 수 있어야 해요.

7. 검증된 업무부터 수평적으로 확장합니다

첫 번째 팀에서 사용 방법과 성과가 확인된 뒤 구조가 비슷한 다른 업무로 확장하세요. 같은 AI 도구를 일괄 배포하는 것이 아니라, 검증된 업무 설계 방식을 재사용하는 것이 중요합니다.

AX 전환의 출발점은 AI가 아니라 어려운 업무입니다

기업용 생성형 AI 프로젝트의 95%가 성과로 이어지지 못했다는 연구 결과는 AI 기술이 쓸모없다는 의미가 아닙니다.

기업이 AI를 도입하는 데는 성공했지만, 실제 업무에 연결하고 현업의 피드백을 반영해 지속적인 성과를 만드는 데는 어려움을 겪고 있다는 의미에 가까워요.

AX 전환은 최신 AI 모델을 도입하는 것에서 시작하지 않습니다.

회사가 오랫동안 해결하지 못했던 문제를 선택하고, 한 팀의 실제 업무에 맞는 AI 에이전트를 만들고, 정보보안 조건 안에서 빠르게 검증하고, 현업의 피드백으로 결과를 개선하는 과정에서 시작됩니다.

처음부터 조직 전체를 바꾸려고 하지 마세요.

한 팀의 어려운 문제 하나를 선택하고, 한 개의 특화 AI 에이전트로 해결하고, 한 개의 지표로 효과를 증명하세요.

문서 검토와 비교처럼 자료의 근거를 확인해야 하는 업무라면 스쿠피(Scoopie)로 시작할 수 있습니다. 스쿠피는 사내용 AI 업무보조 에이전트로, 업무 자료를 파일 연동한 뒤 요약·분류·검토·초안을 요청하고 결과의 출처를 원문에서 확인할 수 있어요.

기업용 도입 프로젝트는 문의, 요구사항 파악, 구축 범위와 견적 협의, 프로젝트 착수 순으로 진행됩니다. 인허가 신청서 검토나 관세 자료 검증처럼 특정 팀의 중요하고 반복적인 업무부터 시작할 수 있습니다.

Reference

• MIT Project NANDA, The GenAI Divide: State of AI in Business 2025

• BCG, AI Adoption in 2024: 74% of Companies Struggle to Achieve and Scale Value

• BCG, Where’s the Value in AI?

• McKinsey, The State of AI: Global Survey 2025

• McKinsey, The State of AI: How Organizations Are Rewiring to Capture Value

• PwC, 2026 Global CEO Survey

• Deloitte, State of AI in the Enterprise 2026

• Gartner, Why Generative AI Projects Fail

• NIST, AI Risk Management Framework

• 스쿠피 공식 홈페이지