당신의 AI 프로젝트가 실패하는 이유

당신의 프로젝트가 실패하는 이유는 AI 모델이나 하네스 엔지니어링의 문제가 아니다.

이전 시절을 돌아보면, 도구를 먼저 결정한 케이스가 한두 번이 아니었다. Notion을 깔면 지식이 흐를 거라고 생각했고, Slack을 깔면 소통이 빨라질 줄 알았다. 결과는 부서별 위키, 부서별 채널. 도구만 바뀌고 구조는 그대로였다.

지금 AI도 똑같은 길을 가고 있다. 회사들이 Claude Code나 Codex를 도입한다. “이제 우리도 AX가 되겠지” 기대한다. 그런데 실제로 일어나는 건, 그 도구로 옛날 워크플로우를 더 빨리 돌리는 것뿐이다. 멋진 도구로 잘못된 일을 더 빨리 하는 시스템이 된다.

“실행 속도는 한 번도 어려운 부분이었던 적이 없다. 어려웠던 건 ‘무엇을 만들지’고, 그건 지금도 변하지 않았다. 싸게 만들 수 있어졌기 때문에 발견(discovery)은 덜 중요해진 게 아니라 더 중요해졌다.” - Continuous Discovery Habits 저자

빠르게 만들 수 있을수록 무엇을 만들지 결정하는 일이 더 어려워진다. 도구는 그 결정을 대신해 주지 않는다. 제약은 실행이 아니라 방향이다.

데이터도 이미 같은 얘기를 한다. 스탠퍼드 HAI 공동소장은 최근 인터뷰에서 “AI가 전반적 생산성 향상을 제공한 영역은 프로그래밍과 콜센터뿐”이라고 정리했다. 나머지 직무에서는 의미 있는 향상이 측정되지 않는다. 모델 성능의 한계가 아니라, 적용 영역이 잘못된 결과다.

또 다른 솔직한 고백이 있다. SNS에 “AI 50개로 회사를 돌린다”고 자랑하던 어느 스타트업 창업자는 인터뷰에서 직접 말했다.

“50개는 거짓이다. 실제로 작동하는 건 5개고, 나머지는 데모용이다.”

이건 그 회사 한 곳의 문제가 아니다. SNS에서 매일 보는 “AI 자동화 워크플로우 N개” 캡처들 대부분이 같은 구조다. 데모는 화려하지만 실제 production에서 매일 도는 건 그 중 일부뿐이다.

실패하는 AI 프로젝트들의 공통 패턴은 결국 단순하다.

• 문제를 정의하기 전에 도구를 선택한다
• 멋있어 보이는 데모를 먼저 만들고 사용 시나리오는 나중에 끼워맞춘다
• 데이터 품질을 무시한다
• 사람의 일을 통째로 대체할 수 있다고 기대한다
• 기존 워크플로우 안에 통합되지 않는, 별개의 AI 섬을 만든다

다섯 가지 중 하나만 걸려도 프로젝트는 실패한다. 그리고 보통은 다섯 가지가 한꺼번에 걸린다.

잘못된 문제 정의 위에 AI를 얹으면, AI는 그 잘못을 더 빨리 양산한다.

실패한 건 모델이 아니다. 그 위에 얹힌 결정과 설계가 실패한 거다.