AI 프로젝트 90%가 실패하는 배경: 프롬프트 부채, 검색 부채, 평가 부채가 기업 배포의 발목을 잡고 있다

2025년 42%의 기업이 다수의 AI 프로젝트를 중단했으며, 이는 전년도의 17%를 훨씬 웃도는 수치입니다. 문제는 모델이 충분히 강력하지 않다는 데 있는 것이 아니라, 새로운 형태의 기술 부채가 기업의 AI 인프라 내에서 조용히 누적되고 있다는 점입니다. 프롬프트 부채, 검색 부채, 평가 부채가 그것입니다. (이전 줄거리: Harness Engineering이란 무엇인가? AI Agent가 실제로 정착하기 위한 7대 엔지니어링 모듈(AI 제어 엔지니어링) 분석) (배경 보충: GPT-5.5 Instant가 전체 사용자에게 개방, OpenAI가 더 똑똑하고 효율적인 Prompt 작성법을 알려준다) 데이터는 AI 실패가 우발적 현상이 아니라 시스템적 문제임을 보여줍니다. 같은 해 MIT 연구는 95%의 AI 파일럿이 실제 생산 환경에 진입하거나 정량화 가능한 비즈니스 가치를 창출한 적이 없다고 지적했습니다. 2%, 이는 2025년에 다수의 AI 프로젝트를 중단한 기업의 비율로, 전년도보다 정확히 1.5배 증가한 수치입니다. S&P Global Market Intelligence의 이러한 실패는 보통 모델 능력 부족, 데이터 품질 저하, 또는 ROI 설명의 어려움 탓으로 돌려집니다. 그러나 Cota Capital 책임자 Vikram은 진정한 원인이 더 은밀하다고 봅니다. AI 시스템의 프롬프트 계층, 모델 의존 계층, 평가 계층에서 조용히 누적되고 있는 새로운 형태의 기술 부채로, 전통적인 코드 부채와는 전혀 다르지만 똑같이 치명적입니다. 전통적인 기술 부채는 코드베이스에 존재하며, Bug는 재현 가능하고, 테스트 가능하며, 수정 가능합니다. AI 부채의 특성은 완전히 다릅니다. 분산되어 있어 프롬프트, 모델 API, 데이터 파이프라인, 인프라의 각 계층에 분포해 있습니다. 간헐적입니다. AI 시스템은 본질적으로 확률적 특성을 가지므로, 같은 입력이 같은 출력을 보장하지 않기 때문입니다. 또한 거의 보이지 않습니다. 시스템이 "정상적으로 작동하는 것처럼 보이다가" 어느 결정적인 순간에 전체가 붕괴되기 때문입니다. 프롬프트 부채(Prompt Debt)는 셋 중 가장 명백한 것입니다. 문서화되지 않은 임시 조정, 버전 관리되지 않는 프롬프트 변경, 그리고 "프롬프트 채우기"는 대량의 무관한 배경 정보를 프롬프트에 강제로 집어넣어 모델이 더 많이 이해하도록 시도하는 방식입니다. 그 결과 프롬프트는 타입도 없고, 테스트도 없고, 버전 관리도 없는 비공식 코드가 되어버립니다. 매번의 미세 조정은 불투명한 시스템 위에서 이루어지며, 누적될수록 시스템의 취약성도 기하급수적으로 증가합니다. 모델 의존 부채(Model Dependency Debt)는 기업이 외부 기반 모델 API에 고도로 의존하는 데서 비롯됩니다. 애플리케이션 로직은 외부 모델 호출 위에 구축되지만, 이러한 모델의 업데이트는 기업이 통제할 수 없습니다. 모델 공급업체가 조용히 버전을 업그레이드하면, 구버전에 정교하게 맞춰진 프롬프트는 직접 실패하거나, 출력 동작이 예측하기 어려운 드리프트를 보일 수 있습니다. 재현 가능성은 이로써 사라집니다. 검색 부채(Retrieval Debt)는 대다수 기업 AI 배포가 채택하는 RAG 아키텍처에서 나타납니다. 문제는 그러한 데이터 창고에 종종 혼란스러운 데이터, 중복 파일, 그리고 이미 기한이 지난 정보가 가득 쌓여 있다는 점입니다. 따라서 AI가 반환하는 답변은 기술적으로 한때 정확했지만, 지금은 더 이상 적용되지 않을 뿐입니다. 이는 환각보다 발견하기 더 어렵습니다. 완전히 합리적으로 보이며, 심지어 일반 테스터의 검토를 통과할 수도 있기 때문입니다. 평가 부채(Evaluation Debt)는 네 가지 새로운 형태의 AI 부채 중 가장 과소평가되기 쉬운 것입니다. 기존의 AI 벤치마크 테스트는 대부분 좁은 범위, 시점 기반의 평가 결과에 초점을 맞추고 있어, 배포 후 실제 성능을 반영할 수 없습니다. 절대다수의 기업은 일관된 테스트 표준, 벤치마크 데이터셋, 그리고 배포된 모델에 대한 실시간 모니터링 메커니즘이 부족합니다. 전통적인 소프트웨어 개발에서 이미 성숙한 CI/CD(지속적 통합/지속적 배포) 프로세스와 대조적으로, AI 배포 영역에는 지금까지 동등한 "프롬프트 지속적 통합" 메커니즘이 없습니다. 쉽게 말하면 이렇습니다. 엔지니어가 코드를 병합하면 자동화된 테스트가 어디가 망가졌는지 알려주지만, 프롬프트가 수정된 후에는 어떤 시스템도 실시간으로 경보를 울리지 않습니다. 결과적으로 CIO와 CTO는 모델의 실제 성능에 대한 가시성이 부족하며, 성능이 악화되고 있는지도 추적할 수 없습니다. 이 네 가지 새로운 형태의 부채는 기존의 코드 기술 부채 위에 겹쳐지며 복합적인 누적을 가속화합니다. 설상가상으로 AI 시스템의 소유권 자체가 분산되어 있습니다. 엔지니어링, 제품, 데이터, 비즈니스 팀이 각각 시스템의 서로 다른 부분을 소유하고 있어, 일단 문제가 발생하면 책임 소재가 불분명한 경우가 많습니다. 모델이 더 강력해진다고 이 문제가 해결되지는 않습니다. Vikram의 논점은 직접적입니다. 높은 실패율은 모델 정확도와 무관하며, 근원은 시스템 설계, 통합 통제, 그리고 조직 문화의 결여에 있습니다. 구체적으로, 프롬프트는 코드로 취급되어야 하며, 버전 관리에 포함되고, 문서 설명이 보충되며, 배포 전후로 모든 가능한 구성에 대해 엄격하게 테스트되어야 합니다. 평가 메커니즘은 전체 AI 인프라 스택에 내장되어 지속적인 평가 파이프라인을 구축하고, 기술 지표와 비즈니스 지표를 동시에 포괄하며, AI 관찰 가능성 시스템을 통합하여 출력 품질, 실패율, 모델 드리프트와 데이터 드리프트를 모니터링해야 합니다. 또한 모든 AI 결과는 기본적으로 설명 가능성에 대한 설명을 포함해야 하며, 데이터 출처, 사용된 모델, 실행된 단계가 명확하게 추적 가능해야 하고, 감사 가능성을 보장하며, 시스템적 오류가 발생했을 때 신속하게 수정할 수 있어야 합니다. 이는 과거에 기업이 보안 강화나 클라우드 현대화에 투자한 것처럼, 명확한 AI 부채 해소 계획과 전용 예산을 설립하고, CXO급 리더가 직접 주도해야 합니다. 이렇게 많이 말씀드렸으니 이제 이해하실 것입니다. 95%의 실패는 AI가 충분히 똑똑하지 않아서가 아닐 수 있습니다. 오히려 AI 시스템을 구축하는 방식이 여전히 그것을 블랙박스 API 호출로 취급하는 단계에 머물러 있고, 진지하게 엔지니어링적으로 다루어져야 할 복잡한 시스템으로 보지 않기 때문입니다. 기술 부채는 결코 저절로 사라지지 않으며, 미래의 어느 시점에 더 높은 이자로 한 번에 갚게 될 뿐입니다.