
파일럿의 무덤: 기업용 AI가 프로덕션 단계 이전에 중단되는 이유
요약
기업용 AI 프로젝트의 높은 실패율과 프로덕션 단계 진입의 어려움을 분석합니다. RAND, S&P Global 등의 연구를 인용하여 AI 도입이 단순 기술 문제를 넘어 구조적, 조직적 장벽에 직면해 있음을 설명합니다.
핵심 포인트
- AI 프로젝트의 80% 이상이 실패하며 기존 IT 프로젝트보다 실패율이 높음
- 실패 원인은 잘못된 비즈니스 문제 설정, 취약한 데이터, 인프라 부족 등 구조적 요인
- 성공적인 도입을 위해서는 컴플라이언스, 리스크, 데이터 가용성을 고려한 우선순위 설정 필요
- 모델 성능보다 거버넌스가 갖춰진 조직적 시스템 구축이 핵심
이 기사는 원래 EthereaLogic.ai에 게시되었습니다.
수치들을 직접적으로 비교할 수는 없지만, 이들은 모두 같은 방향을 가리키고 있습니다. RAND Corporation의 연구 보고서는 AI 프로젝트의 80% 이상이 실패한다고 추정하며, 이는 기존 IT 프로젝트의 실패율보다 대략 두 배 높은 수치입니다. S&P Global Market Intelligence는 조사 대상 기업의 42%가 2025년에 프로덕션(production) 단계 이전에 대부분의 AI 이니셔티브를 포기했다고 밝혔으며, 이는 전년도의 17%에서 증가한 수치입니다. 응답자들에 따르면 프로젝트의 평균 46%가 개념 증명(proof of concept)과 광범위한 도입 사이에 폐기되었습니다. MIT NANDA의 예비 연구 노트는 더 좁은 정의 — 즉, 현저하고 지속적인 생산성 또는 손익(P&L) 영향을 미치는 작업 특정 시스템(task-specific systems) — 를 사용하여, 검토된 구현 사례 중 해당 임계값을 충족한 것은 5%에 불과하다고 보고했습니다.
이러한 연구들은 서로 다른 모집단과 결과를 측정합니다. 이 연구들이 하나의 보편적인 AI 실패율을 확립하는 것은 아닙니다. 이들이 확립하는 것은 이 시리즈의 논지, 즉 반복되는 장벽은 구조적이라는 점입니다. RAND의 인터뷰에서는 잘못 설정된 비즈니스 문제, 취약한 데이터, 기술 우선적 의사결정, 불충분한 인프라, 그리고 AI에 적합하지 않은 문제들이 드러났습니다. S&P는 실패율이 낮은 조직일수록 더 총체적인 우선순위 설정을 사용하며, 프로젝트를 선택할 때 컴플라이언스(compliance), 리스크, 데이터 가용성을 고려할 가능성이 더 높다는 것을 발견했습니다. MIT 연구 노트는 맞춤형 도구들이 워크플로우(workflows)와 통합되지 않거나 사용자의 요구에 적응하지 못해 정체되고 있다고 설명했습니다. 모델이 중요합니다. 하지만 그 모델을 둘러싼 조직이 모델이 하나의 역량이 될지 여부를 결정합니다.
이 내용은 이 블로그의 독자들에게 익숙하게 들릴 것입니다. 에이전트 거버넌스 스택 시리즈에서는 단일 코딩 에이전트 수준에서 다음과 같은 논거를 제시했습니다. 모델의 역량은 거버넌스가 구축된 시스템의 일부일 뿐이라는 점입니다. 본 시리즈는 조직 수준에서 동일한 논거를 펼칩니다. 기업용 AI 배포를 실패하게 만드는 리스크는 종종 벤더의 데모가 증명하고자 했던 범위를 벗어난 곳에 존재합니다. 이러한 리스크는 작동하는 데모와 거버넌스가 갖춰진 프로덕션 시스템(Production system) 사이의 조직적 흉터 조직(Organizational scar tissue)을 이루는 6개의 계층에 자리 잡고 있습니다. 그리고 많은 조직은 이러한 계층에 대한 지도도, 이를 책임질 담당자도, 이를 명시한 예산 항목도 가지고 있지 않습니다.
작동하는 데모는 시작점이며, 주로 모델에 관한 단계입니다. 그 뒤를 잇는 6개의 관문 — 지속 가능성(Enduring problem), 워크플로우 적합성(Workflow fit), 프로덕션 데이터(Production data), 리스크 소유권(Risk ownership), 신뢰할 수 있는 운영(Reliable operations), 그리고 측정된 가치(Measured value) — 는 모델 자체가 아니라 모델을 둘러싼 조직에 관한 것입니다.
이 글은 미드마켓(Mid-market) 및 엔터프라이즈 수준에서 AI를 배포하는 것에 관한 새로운 EthereaLogic 시리즈의 첫 번째 기사입니다. 이 기사는 배포 격차(Deployment gap)와 그 격차를 채우는 실패 모드(Failure modes)를 매핑합니다. 두 번째 기사에서는 거버넌스 프레임워크 환경 — NIST AI RMF, ISO/IEC 42001, 그리고 범용 AI 의무 사항이 2025년 8월에 발효되고 집행 권한이 2026년 8월 2일에 시작되는 EU AI Act — 와 세 가지 컴플라이언스(Compliance) 프로그램을 각각 운영하지 않고도 이 세 가지를 모두 충족하는 방법을 다룹니다. 세 번째 기사에서는 에이전트 전환(Agentic transition)을 구체적으로 다룹니다. 즉, 하나의 실험적 에이전트에서 거버넌스가 갖춰진 프로덕션 플릿(Production fleet)으로 이동하기 위해 무엇이 필요한지를 다룹니다.
같은 이름을 가진 두 가지 서로 다른 문제
"기업용 AI 배포 (Enterprise AI deployment)"는 보통 하나의 문제로 다루어집니다. 하지만 이는 두 가지 문제이며, 두 문제는 서로 충분히 다르기 때문에 한쪽을 위한 조언이 다른 쪽에는 적극적으로 해를 끼칠 수 있습니다.
Fortune 500 기업의 문제는 포트폴리오 (portfolio) 문제입니다. 대기업은 20개의 파일럿 (pilot)을 운영할 여력이 있습니다. 이들의 특징적인 실패 모드 (failure mode)는 20개 모두를 실행하면서, 각 프로젝트가 실패 여부를 가릴 수 있을 만큼 날카로운 성공 정의 (success definition)를 부여하지 않는 것입니다. 그 결과, 포트폴리오는 통합 (integration) 및 플랫폼 (platform) 역량을 소모하면서도 정작 프로덕션 (production) 결정 단계에는 결코 도달하지 못하는 좀비 이니셔티브 (zombie initiatives)들을 축적하게 됩니다. S&P의 포기 데이터 (abandonment data)는 조직들이 더 많은 개념 증명 (proof of concept)을 수행하고 있다는 사실과 일치합니다. 다만 이 설문 조사가 이것이 더 나은 포트폴리오 규율 (portfolio discipline)을 반영하는지, 아니면 더 나쁜 실행력 (execution)을 반영하는지, 혹은 둘 다인지는 밝혀내지 못했습니다.
미드마켓 (mid-market)의 문제는 역량 (capacity) 문제입니다. 매출 5,000만 달러에서 5억 달러 사이의 기업은 20개가 아닌 23개의 파일럿을 지원할 수 있을 뿐입니다. 이들은 실패한 이니셔티브를 대규모 포트폴리오 전체에 걸쳐 분산시켜 상쇄 (amortize)할 수 없으며, 통합 작업을 흡수할 전담 AI 플랫폼 팀이 없을 수도 있습니다. 그렇기에 짧은 의사결정 루프 (decision loops)와 좁은 프로젝트 범위 (project scope)가 가치가 있습니다. 직원 수 2005,000명 규모의 미국 기업을 대상으로 한 Netrio의 2026년 6월 설문 조사에 따르면, 응답자의 82%가 조직 어딘가에서 AI가 이미 프로덕션 (production) 단계에 있거나 널리 사용되고 있다고 보고했습니다.
결과가 긍정적일 때조차 어려움은 실재합니다. RSM의 2025년 미드마켓 AI 설문 조사 (Middle Market AI Survey)에 따르면, 경영진의 62%가 생성형 AI (generative AI)를 구현하는 것이 예상보다 더 어렵다고 답했습니다. 이들이 언급한 장애물은 모델 품질 (model quality)이 아닌 구조적인 문제입니다. 구현 문제에 직면한 응답자들 사이에서는 데이터 품질 (data quality)이 가장 큰 우려 사항(41%)이었으며, 준비가 되지 않았다고 답한 응답자들 사이에서는 내부 전문 지식 (in-house expertise)의 부족이 가장 큰 문제(39%)였습니다.
하지만 Netrio의 설문 조사에는 모든 중견 기업(mid-market) CTO가 우려해야 할 수치가 포함되어 있습니다. 단 26%만이 AI가 기업 전반에 걸쳐 확장(scaled)되고 거버넌스(governed)가 구축되었다고 답했습니다. 그리고 거버넌스 격차(governance gap)는 추상적인 문제가 아닙니다. 동일한 조사 대상자 중 42%가 지난 12개월 동안 확인된 AI 관련 보안 사고(security incident) 또는 노출(exposure)을 보고했으며, 또 다른 31%는 사고가 발생할 뻔했던 아차 사고(near-miss)를 보고했습니다. 이 표본에서는 기업 전반의 거버넌스가 구축되기 전에 도입(adoption)이 광범위하게 이루어졌습니다. 이는 노출 격차(exposure gap)이며, 사용량이 확장됨에 따라 더욱 심화됩니다.
따라서 두 가지 운영 패턴을 정확히 정의하자면 다음과 같습니다. 대기업은 포트폴리오 저하(portfolio drag)를 통제해야 하며, 중견 기업은 거버넌스가 도입 속도에 뒤처지지 않도록 유지해야 합니다. 두 경우 모두 모델 품질(model quality)이 중요합니다. 하지만 어느 쪽에서도 품질만으로는 충분하지 않습니다.
운영 제약 조건은 다르지만, 프로덕션 표준은 동일합니다. S&P의 기업 포기(enterprise abandonment) 데이터와 Netrio의 중견 기업 거버넌스 데이터는 동일한 격차로 향하는 서로 다른 경로를 가리키고 있습니다.
격차의 해부 (The Anatomy of the Gap)
연구 전반에 걸쳐 다섯 가지 구조적 실패 모드(structural failure modes)가 반복적으로 나타납니다. 이는 내부에서 바라본 동일한 여섯 가지 관문(gates)이며, 지속적인 문제(enduring-problem) 관문과 측정된 가치(measured-value) 관문을 아우르는 검증 가능한 성공 정의(falsifiable definition of success)를 포함합니다. 연구들은 이를 하나의 보편적인 순서로 나열하지는 않지만, 각각은 조직이 모델을 중심으로 구축하지 못한 요소를 설명합니다.
1. 검증 가능한 성공 정의의 부재 (No Falsifiable Definition of Success)
RAND의 조사에 따르면, 비즈니스 문제를 오해하거나 잘못 전달하는 것이 가장 흔한 근본 원인(root cause)이었으며, 여기에는 리더들이 잘못된 지표(metric)를 추구하는 것도 포함되었습니다. 이러한 실패의 운영적 버전은 특정 수치를 달성하기보다는 역량을 "탐색"하는 것을 목표로 설정된 파일럿(pilot)입니다. 중단 기준(kill criterion)이 없는 파일럿은 실패할 수 없으며, 이는 곧 성공할 수도 없음을 의미합니다. 즉, 그저 지속될 뿐입니다. 해결책은 회의 한 번이면 충분합니다. 파일럿을 시작하기 전에 지표(metric), 임계값(threshold), 측정 책임자(measurement owner), 그리고 의사결정이 내려질 날짜를 기록하십시오. 이러한 규율은 사양 기반 개발(spec-driven development)이 코딩 에이전트(coding agent)에 부과하는 수락 기준(acceptance-criteria) 규율과 동일하며, 이를 한 단계 더 높은 수준에 적용한 것입니다. 만약 성공 정의를 문서로 작성할 수 없다면, 그 파일럿은 시작할 준비가 되지 않은 것입니다. 그것은 프로젝트 코드를 달고 있는 연구 관심사일 뿐입니다.
2. 파일럿 이후로 미뤄진 통합 (Integration Deferred Until After the Pilot)
MIT NANDA 연구 노트에 따르면, 작업 특화 도구(task-specific tools)들은 워크플로(workflow)에 맞지 않거나 사용자의 피드백으로부터 학습하지 못할 때 자주 정체되는 것으로 나타났습니다. 표준적인 파일럿 설계는 이러한 결과를 더 초래하기 쉽습니다. 파일럿은 내보내기(exported)된 데이터, 샌드박스(sandbox) 환경, 그리고 수동으로 구성된 컨텍스트(context)에서 실행되는데, 이는 프로덕션(production) 환경에서는 절대 재현될 수 없는 조건들입니다. 깨끗하게 내보내진 데이터에서 모델이 작동함을 증명하는 파일럿은 배포(deployment)에 대해 아무것도 증명하지 못한 것입니다. 이는 모든 어려운 질문들을 예산 유연성이 가장 낮고 이해관계자의 피로도가 가장 높은 단계로 미뤄버린 것에 불과합니다. 대안은 프로덕션 형태의 제약 조건 하나를 파일럿 자체의 일부로 만드는 것입니다. 실제 권한 모델(permission model)을 통한 실시간 데이터 접근, 실제 워크플로 트리거(workflow trigger), 또는 실제 지연 시간 예산(latency budget) 등이 이에 해당합니다. 프로덕션 제약 조건 하나를 견뎌낸 파일럿은 샌드박스에서 실행된 열 개의 파일럿보다 가치 있습니다. McKinsey의 State of AI 연구는 이러한 실패의 더 깊은 버전에 대해 수치로 보여줍니다. 테스트된 25가지 속성 중, 워크플로를 근본적으로 재설계하는 것이 생성형 AI(generative AI)로부터 보고된 EBIT(이자 및 세전 이익) 영향과 가장 강력한 상관관계를 보였으나, 이를 실행한 조직은 사용 중인 조직의 21%에 불과했습니다.
대부분의 배포는 기존의 운영 모델(operating model)에 새로운 엔진을 설치한 뒤, 엔진을 탓하는 방식을 취합니다.
3. 지루한 중간 단계(Boring Middle)를 책임질 주체의 부재
모델을 구축하는 데이터 과학 (Data Science)과 결과를 원하는 사업 부서 (Business Unit) 사이에는 액세스 권한 부여 (access provisioning), 모니터링 (monitoring), 장애 라우팅 (incident routing), 모델 및 프롬프트 버전 관리 (model and prompt version discipline), 비용 추적 (cost tracking)과 같은 매력적이지 않은 작업들이 자리 잡고 있습니다. 전통적인 소프트웨어 프로젝트에서 이러한 작업은 플랫폼 엔지니어링 (platform engineering) 또는 SRE (Site Reliability Engineering)라는 이름과 예산 항목을 가지고 있습니다. 하지만 대부분의 AI 이니셔티브에서는 이 두 가지가 모두 없습니다. 왜냐하면 해당 이니셔티브가 소프트웨어 인도 (software delivery)가 아닌 혁신 프로젝트 (innovation project)로 수립되었기 때문입니다. 이름이 붙여지지 않았다고 해서 이 작업이 사라지는 것은 아닙니다. 문제가 발생했을 때 가장 가까이 있는 사람에게 업무가 전가되며, 이것이 바로 배포 모델이 '버스 지수 (bus factor)' 1을 갖게 되는 방식입니다.
4. 후순위 단계로 취급되는 거버넌스 (Governance)
McKinsey의 2025년 조사에 따르면, 응답자의 28%는 CEO가 AI 거버넌스 (AI governance)를 감독한다고 답했으며, 17%는 이사회가 감독한다고 답했습니다. 설문 조사가 인과관계를 입증한 것은 아니지만, CEO의 감독은 보고된 수익 (bottom-line) 영향력이 더 강력한 관행 중 하나였습니다. 실질적인 논거는 더 간단합니다. 거버넌스는 파일럿의 성공을 일반화할 수 있게 해주는 장치입니다. 실제 액세스 제어 (access controls), 실제 감사 추적 (audit trails), 실제 장애 대응 경로 (incident path) 하에서 실행된 파일럿은 리스크 관리자 (risk officer)가 수용할 수 있는 증거를 생성합니다. 거버넌스 없이 실행된 파일럿은 데모 (demo)를 만들어낼 뿐이며, 이 경우 파일럿에서 프로덕션으로 넘어가는 모든 협상은 이번에는 컴플라이언스 (compliance) 부서가 참여한 상태에서 다시 처음부터 시작해야 합니다.
5. 검증되지 않은 채 가정된 데이터 기반 (Data Foundations)
취약한 데이터 기반 (Data Foundations)은 모든 실패 조사에서 반복적으로 나타나며, 이 블로그의 데이터 신뢰성 관련 기사를 읽은 독자들은 이미 문제의 양상을 알고 있습니다. 즉, 조직은 AI가 생성하는 결과물은 검증하지만, AI가 소비하는 데이터는 전혀 검증하지 않는다는 점입니다. 배포 단계에서는 하부 데이터에 존재하는 측정되지 않은 모든 결함을 그대로 물려받게 되며, 이러한 결함은 프로덕션 규모 (production scale)의 다운스트림 (downstream) 단계에서 "모델이 신뢰할 수 없다"라는 가면을 쓴 채 표면화됩니다. 모델은 대개 문제가 없습니다. 데이터 경로 (data path)가 전혀 거버넌스 (governance)를 받지 못했을 뿐입니다.
에이전틱 웨이브 (Agentic Wave)가 판돈을 높이는 이유
위의 모든 내용은 기존의 AI 및 생성형 AI (Generative AI)에서 존재했던 배포 격차 (deployment gap)를 설명합니다. 에이전틱 웨이브 (Agentic wave)는 이 격차 전체를 그대로 물려받으면서, 여기에 실행 (execution) 차원을 추가합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기