「보안 정리까지 끝났다. 이제 프로젝트가 굴러가겠지.」 지난달 어느 제조 대기업 DX 팀장이 커피잔을 두고 한 말이다. 실제로 그 회사는 반년 동안 감사 로그·PII 마스킹·권한 분리를 다 짜뒀다. 그런데 상반기 리뷰에서 프로젝트는 「일단 보류」로 결론 났다.
이유는 하나가 아니었다. 데이터는 여전히 흩어져 있었고, PoC에서 잘 되던 케이스가 실제 사용자 트래픽에서는 무너졌으며, 배포 두 달째 아무도 대시보드를 열어보지 않았다. 정확히 말하면 보안은 통과 조건일 뿐, 성공 조건이 아니었다. 시리즈 6회에서 보안·거버넌스를 정리했다면, 이번 회는 그다음에 만나는 벽에 대한 이야기다.
MIT Project NANDA가 2025년 7월 발표한 조사에서, 생성 AI 파일럿을 돌린 조직의 95%가 측정 가능한 P&L 영향을 얻지 못했다고 답했다. RAND의 엔터프라이즈 AI 분석에서는 80.3%가 약속된 비즈니스 가치를 못 냈고, 그중 33.8%는 프로덕션 진입 전에 이미 폐기됐다. 숫자만 보면 절망적이지만, 실패 방식은 놀랄 만큼 반복적이다. 여러 프로젝트를 옆에서 지켜보면 결국 5가지 패턴으로 수렴한다.
1. 데이터 미정비 — 흩어진 문서 위에 RAG를 얹는 순간
어느 첫 미팅에서 팀장은 「사내 문서는 SharePoint에 있습니다」라고 답했다. 열어보니 폴더 34개, 중복 문서 1,200건, 최신 매뉴얼과 3년 전 버전이 같은 이름으로 공존했다. 이 상태에서 RAG 인덱싱을 돌리면 어떤 일이 벌어지는가. 사용자가 「반품 규정」을 물었을 때 2022년 버전과 2025년 버전이 뒤섞여 답이 나온다. 그것도 아주 그럴싸하게.
실패 프로젝트의 85%가 데이터 품질을 근본 원인으로 지목했다는 업계 조사가 있다. 데이터가 AI 애플리케이션을 지탱할 수준인 조직은 12%에 불과했다. 즉 나머지 88%는 「지금 데이터로 일단 시작하자」의 함정에 들어가 있다.
- 원본 문서의 최신성·중복·버전 상태를 최소 3주 점검
- PII·기밀 등급을 문서 단위로 태깅
- RAG 인덱싱 전 「골드셋 100개 질의」로 정답률 사전 측정
- 정답률 70% 미만이면 데이터 정비를 먼저 마친다
2. PoC 함정 — 데모에서 잘 되던 것이 실제 트래픽에서 무너진다
S&P Global 조사에서 AI PoC의 46%가 프로덕션 도달 전에 폐기됐다. 이 숫자를 처음 봤을 땐 「그 정도인가」 싶었는데, 몇 사례를 겪어보면 이해된다.
PoC 데모는 대체로 이렇게 흘러간다. 준비된 20개 질의로 시연, 참석자 박수, 「본격 개발 갑시다」. 그러나 실사용자는 예상 못한 걸 물어본다. 오타·반말·비속어·중복 질문·질문 세 개를 하나에 몰아 던지는 케이스. PoC 정확도 92%가 프로덕션 정확도 61%로 떨어진다. 원인은 명확하다. 데모 세팅이 「이상적 사용자」를 가정했기 때문이다. 실제 사용자는 이상적이지 않다.
- PoC 단계부터 실제 사용자 로그(익명 처리)로 평가
- 「의도적으로 어색한 질의 50개」를 스트레스 셋으로 유지
- PoC 성공 기준을 「데모 통과」가 아니라 「실사용 정확도 X% 이상」으로 명문화
3. 운영 부재 — 배포 두 달째 아무도 대시보드를 열지 않는다
솔직히 이 패턴이 가장 자주 보인다. 배포는 이벤트다. 운영은 습관이다. 대부분 조직은 이벤트까지만 예산을 잡는다.
배포 뒤에 필요한 일은 뻔하다. 주간 정확도 지표 확인, 실패 사례 리뷰, 프롬프트 개선 PR, 모델 업데이트 대응, 사용량 리포트. 이걸 담당할 사람이 없으면 석 달 뒤 도구는 그대로인데 사용자는 사라진다. 자연스러운 결말이다.
Gartner가 2026년 4월 발표한 자료에서 AI 인프라 프로젝트 중 약속된 ROI를 달성한 비율이 28%였다. 미달성 그룹의 상당수가 운영 리소스 부재를 지목했다. 잘 만든 것과 오래 쓰이는 것은 다른 게임이다. ROI 지표 설계 자체는 시리즈 3회에서 다뤘다. 그때 정의한 KPI를 실제로 「매주 누가 볼 것인가」가 운영 성패를 가른다.
- 배포 전에 운영 담당자·주간 지표 리뷰 미팅을 캘린더에 등록
- 프롬프트·데이터 업데이트 PR을 월 최소 2건 리듬으로 유지
- 사용량 하락 시 알림·대응 프로세스를 문서화
4. 과도한 기대 — 「AI가 다 해줄 것」이라는 가정의 대가
이 패턴은 결재자보다 도입 스폰서 쪽에서 자주 나타난다. 「직원 대신 AI가 처리하게 하자」는 그림. 처음엔 매력적이지만, 인간 체크포인트를 뺀 자동 실행은 사고로 이어진다.
2026년 에이전틱 시스템 실패의 가장 흔한 원인이 「human-in-the-loop 체크포인트 부재」였다는 보고가 있다. 자율성을 과신하면, 잘못된 판단이 인간 개입 없이 그대로 실행된다. 고객 응대에서 잘못된 환불 승인, 문서 자동 생성에서 사실 오류의 그대로 배포. 한번 사고가 터지면 조직 내 신뢰가 무너지고, 프로젝트 자체가 중단된다.
- 자동 실행 액션은 「금액·범위·중요도」 기준으로 인간 승인 단계를 정의
- 초기 3개월은 모든 액션을 「제안 모드」로 운영하고 검토 로그를 축적
- 신뢰 지표(승인율·수정율)를 확인한 뒤 단계적 자동화
5. 보안 뒷전 — 감사·법무 리뷰 단계에서 롤백되는 패턴
앞선 회차에서 다룬 주제이지만, 「보안은 나중에」라는 판단이 프로젝트 후반에 어떻게 돌아오는지 짧게 짚는다.
한 사례. 서비스 개발 90% 완료, 사내 시연 성공. 그런데 법무팀 리뷰에서 「감사 로그가 개인정보 원문을 그대로 저장하고 있다」는 지적. 리팩토링 규모가 커서 결국 4개월 롤백. 원 예산의 40%가 추가 투입됐다. 62%의 조직이 데이터 거버넌스에서 어려움을 겪는다는 조사가 있는데, 이런 후반 롤백이 그 통계의 실체다.
비용 관점의 폭발은 시리즈 5회에서 정리했다. 보안 후행이 만들어내는 예산 초과가 그 회의 케이스와 정확히 맞물린다.
- 아키텍처 설계 단계부터 감사·법무 담당자를 리뷰어로 지정
- PII·감사 로그·권한 분리는 MVP 범위에 포함
- 서비스 출시 전 「법무 사인오프」를 스프린트 완료 조건으로 등록
마무리 — 실패의 공통점은 「만들기」가 아니라 「지속시키기」
다섯 가지를 나열해놓고 보면 공통점이 하나 있다. 전부 「만들기」가 아니라 「지속시키기」의 문제라는 점이다. 실패의 상당수는 기술 선택이 아니라 조직·프로세스 설계에서 결정된다. 5years+에서 진행하는 자사 LLM 프로젝트 초기 미팅의 절반 이상은, 이 5가지 중 어떤 리스크가 가장 큰지를 함께 짚어보는 시간으로 쓴다. 검토 중이시라면 부담 없이 프로젝트 리스크 무료 점검으로 현황을 공유해주셔도 좋다.
다음 회는 시리즈의 마지막 실행편이다. 진단→PoC→운영·추가개발까지의 단계별 실행 플랜을 정리한다. 이번 회의 5가지 패턴을 피하면서 실제로 프로젝트를 굴리기 위한 캘린더·역할·마일스톤 관점의 이야기다.