AI 프로젝트, 왜 85%가 실패하는가
숫자부터 직시하자. Gartner는 AI 프로젝트의 85%가 기대 가치를 내지 못하거나 배포 전에 폐기된다고 보고한다. MIT는 더 냉정하다. 파일럿 프로젝트의 95%가 프로덕션에 도달하지 못한다. McKinsey 조사에서도 AI를 사용 중인 기업의 39%만이 수익에 의미 있는 영향을 받았다고 응답했다.
이 숫자들을 처음 보면 모델 품질이나 기술 성숙도 문제로 귀결하고 싶어진다. 하지만 dev.to에 소개된 중국 사례는 다른 진단을 내린다. 275만 위안짜리 전문 AI 오피스 시스템은 6개월 강제 도입 끝에 폐기됐고, HR 담당자가 3분 만에 만든 채용 에이전트는 310개 이력서 중 6명을 30분 안에 스크리닝했다. 기술 격차가 아니다. 구조 설계의 격차다.
테크 리드가 놓치는 진짜 병목
나는 팀에 AI 도구를 붙일 때마다 비슷한 패턴을 목격한다. 리더십이 결정한다 → 외부 팀이 개발한다 → 현장 담당자는 쓰지 않는다. 275만 위안 시스템이 실패한 이유가 정확히 이것이다. 기술팀은 PyTorch와 Transformer를 빠르게 배울 수 있지만, HR 담당자가 30년간 쌓은 묵시지(tacit knowledge)—어느 요일에 지원자가 몰리는지, 연봉 협상이 쉬운 시기가 언제인지, 대량 발송 이력서를 직관적으로 거르는 감각—는 요구사항 문서에 담기지 않는다.
반면 성공한 SoloEngine은 다른 방향으로 설계됐다. 전문가가 AI를 도구로 쓰는 구조다. 비즈니스를 아는 사람이 자연어로 규칙을 정의하고, AI가 그것을 실행 조건으로 변환한다. 지식 이전이라는 죽음의 길목을 우회한 것이다.
이것이 첫 번째 거버넌스 구조가 필요한 이유다. AI 도입 목표를 단수화하고, 도메인 전문가가 설계에 직접 참여하는 구조를 만들지 않으면, 어떤 훌륭한 모델을 붙여도 현장에서 버려진다.
고아 결정이 팀 전체를 잠식할 때
두 번째 문제는 더 조용하게 번진다. dev.to의 또 다른 글은 이것을 '고아 결정(Orphan Decision)'이라 정의한다. AI가 생성한 출력물을 검증 없이 프로덕션에 배포할 때, 그 결정을 실제로 이해하고 책임지는 사람이 아무도 없는 상태다.
엔지니어 한 명이 AI 출력물을 그대로 커밋하면 버그 하나다. 팀 전체가 이 방식으로 작업하면 시스템 부채가 지수적으로 쌓인다. 각자 다른 AI 세션에서 생성된 '진실의 버전'이 서로 충돌하고, 검증되지 않은 출력물이 다음 작업의 입력이 되고, 장애가 터졌을 때 "AI가 그렇게 출력했어요"라는 답변만 남는다.
책임이 증발한 것이다.
이것이 두 번째 거버넌스 구조다. 인간 판단과 기계 실행을 명시적으로 분리하는 운영 규칙이 없으면, AI는 생산성 도구가 아니라 무주공산 의사결정 기계가 된다. 팀 차원에서 "이 결정은 AI가 제안하고 인간이 승인한다"는 경계를 설계 단계에서 못 박아야 한다. 나중에 문화로 해결하려 하면 이미 늦다.
에이전트 경계를 설계하지 않으면 보안이 뚫린다
세 번째 구조는 팀이 가장 뒤늦게 마주치는 문제다. 에이전트가 실제로 도구를 호출하고 외부와 통신하기 시작하면, 프롬프트 인젝션은 이론이 아니라 현실이 된다.
2026년 6월 Tenet Security가 공개한 Agentjacking 사례는 충격적일 만큼 단순하다. 공격자가 Sentry 프로젝트에 가짜 에러 이벤트를 주입한다. Sentry MCP 서버가 이를 실제 버그로 AI 코딩 에이전트에 전달한다. 에이전트는 메시지 본문에 숨겨진 악성 지시를 그대로 실행한다. AWS 시크릿 키, GitHub OAuth 토큰, SSH 소켓, Kubernetes 토큰이 탈취된다. 100개 이상의 에이전트를 대상으로 한 통제 실험에서 성공률은 85%였다. Claude Code, Cursor, Codex 모두 해당된다.
더 불편한 사실은 Sentry의 공식 대응이다. 그들은 이것을 "기술적으로 방어 불가능"하다고 인정하며 모델 벤더의 미들웨어에 기댔다. 플랫폼도, 모델도 이 구멍을 소유하지 않는다. 구멍의 형태는 에이전트 설계 자체에 있다.
Simon Willison이 명명한 '치명적 트리페타(lethal trifecta)'—신뢰할 수 없는 입력 읽기, 비공개 데이터 읽기, 외부 전송—이 세 가지가 하나의 공유 컨텍스트에서 연결될 때 공격 경로가 완성된다. 모델 수준에서 패치할 수 없다. LLM은 지시와 데이터를 신뢰도 기준으로 구분하지 못하기 때문이다. 95% 탐지율을 자랑하는 가드레일은 보안 관점에서 실패율 5%다. 공격자는 성공할 때까지 재시도한다.
세 번째 거버넌스 구조는 명확하다. 에이전트를 실행하기 전에 도구 매니페스트의 데이터 흐름 그래프를 정적으로 검증하고, 공유 컨텍스트에서 egress를 격리하는 경계를 설계해야 한다. 런타임 탐지가 아니라 실행 전 구성 차단이다.
세 구조를 한 문장으로
정리하면 이렇다.
- 목표 단수화 + 도메인 소유권: AI 도입 목적을 하나로 좁히고, 해당 도메인 전문가가 설계 주체가 되는 구조
- 의사결정 소유권 명시: AI 제안과 인간 승인의 경계를 워크플로우에 명문화하는 운영 규칙
- 에이전트 경계 사전 설계: 실행 전 도구 매니페스트 기반 데이터 흐름 검증과 egress 격리
도구는 이미 충분히 발전했다. 실패율 85~95%는 모델의 한계가 아니라 이 세 구조가 없는 팀이 치르는 비용이다.
내일 당장 할 수 있는 것
세 구조 중 가장 먼저 손댈 수 있는 것은 두 번째다. 팀 내에서 지금 AI 출력물이 검토 없이 배포되고 있는 지점—고아 결정이 이미 쌓이고 있는 곳—을 먼저 찾아라. 그 지점에 "누가 이 결정을 이해하고 서명하는가"라는 질문을 붙이는 것만으로 팀의 책임 구조가 보이기 시작한다.
AI-First 팀 리빌딩은 도구를 더 많이 붙이는 일이 아니다. 도구가 만들어내는 결정의 소유권을 누가 가져가는지를 설계하는 일이다. 그 설계가 없으면, 빠른 팀이 아니라 빠르게 실패하는 팀이 완성된다.