생성형 AI 파일럿의 95%는 회사 손익에 아무 영향을 주지 못합니다. MIT 연구진이 2025년 보고서에서 낸 숫자입니다(MIT 보고서). 그리고 Gartner는 2024년, 생성형 AI 프로젝트의 최소 30%가 개념검증(PoC) 뒤 폐기될 것이라고 내다봤습니다(Gartner 전망). McKinsey의 2025년 조사에서는 기업의 80% 이상이 전사 이익에 의미 있는 영향이 없다고 답했습니다(McKinsey 조사). 세 기관이 따로 쟀는데 결론은 같습니다. 대부분의 AI 도입은 손익까지 가지 못하는 셈입니다.
원인은 기술이 아닙니다. MIT 보고서가 지목한 것도 모델 성능이 아니라, 도구가 실제 업무에 맞물리지 못한 도입 방식이었습니다. 지금까지 검증해 게재한 사례 다섯 건 — Klarna, Morgan Stanley, GitHub Copilot, Lumen, 국내 실무자 기록 — 을 겹쳐 놓으면, 결재 전에 정해야 할 결정이 네 가지로 모입니다.
첫째, 무엇을 잴 것인가요
Klarna는 2024년 AI 상담사를 출시해 첫 달에 230만 건, 전체 상담의 66%를 처리했습니다(회사 발표). 그런데 1년 뒤, 상담직 채용을 다시 열었습니다. CEO는 블룸버그 인터뷰에서 이렇게 말했습니다.
"Cost unfortunately seems to have been a too predominant evaluation factor, and what you end up having is lower quality." (비용이 지나치게 지배적인 평가 기준이 됐고, 결국 남은 것은 더 낮은 품질이었습니다.)
기술은 그대로였습니다. 잘못된 것은 성과표였습니다.
그러니 첫 결정은 이것입니다. 결재 문서의 성과 지표에 비용 절감과 나란히 품질 지표를 넣습니다. 해결률, 재문의율, 고객 만족. 이 자리를 비워 두면 도입 뒤에는 고치기 어렵습니다. 왜냐하면 조직은 재는 것을 향해 움직이기 때문입니다. 비용만 재면 비용만 좋아지고, 품질은 아무도 모르는 사이에 나빠집니다. Klarna가 1년 만에 사람을 다시 뽑으며 치른 수업료가 그것입니다.
둘째, 어떤 업무부터일까요
첫 대상은 판단 업무가 아니라 반복·규칙 업무여야 합니다. Klarna가 AI에게 넘긴 것도 환불, 반품, 결제 오류처럼 규칙이 분명한 일이었고, 재조정 뒤에도 그 영역은 AI가 맡았습니다. 사람에게 돌아간 것은 판단과 감정이 필요한 상담이었습니다.
다만 업무를 고르는 것으로 끝나지 않습니다. McKinsey의 2025년 조사가 전사 이익 영향의 가장 큰 동인으로 지목한 것은 도구가 아니라 워크플로우 재설계였습니다. 기존 흐름을 그대로 두고 도구만 얹는 방식으로는 손익까지 가지 못한다는 뜻입니다. 말하자면 AX는 도구를 사는 일이 아니라 업무의 구조를 다시 정하는 일입니다. 어떤 업무를 분해해 어느 단계를 AI에게 넘기고 어느 단계를 사람이 맡을지, 그 그림이 결재 문서에 들어 있어야 합니다.
셋째, 어디서 끝나나요
결과물이 어디에 떨어지는지 정하지 않으면, 만들어도 쓰지 않습니다. Morgan Stanley의 회의 정리 도구 Debrief는 회의를 요약하고 이메일 초안을 만든 뒤, 자문역이 원래 쓰던 Salesforce에 노트를 저장하며 끝납니다. 결과물이 기존 시스템의 종점에 그대로 떨어지니 사람이 옮겨 적을 일이 없습니다. 회사는 자문역 팀의 98%가 어시스턴트를 도입했다고 발표했습니다(Morgan Stanley 발표 — "도입"이지 "매일 사용"은 아닙니다).
순서도 봐야 합니다. Morgan Stanley는 도구를 배포하기 전에 데이터 경계부터 합의했습니다. 회사 정보가 외부 모델 학습에 쓰이는가라는 질문에 먼저 답을 정해 둔 것입니다. 규제 산업이 아니어도 순서는 같습니다. 결과물의 종점과 데이터의 경계, 이 두 가지가 계약서와 결재 문서에 먼저 적혀 있어야 합니다.
넷째, 멈추면 어떻게 되나요
자동화 사고는 만들 때가 아니라 멈췄다 다시 돌 때 납니다. 국내 커뮤니티 지피터스에 올라온 기록이 이를 보여줍니다. 단톡방에 실적 요약을 보내던 봇이 잠시 멈춘 사이 보낼 메시지가 큐에 쌓였고, 복구되는 순간 한꺼번에 터졌습니다. 작성자는 이를 "폭탄 문자 사태"라고 불렀습니다(지피터스 기록, 회원 자기보고).
작은 사례지만 던지는 질문은 전사급입니다. 멈추면 누가 아나요. 밀린 작업은 버리나요, 보내나요. 재시도는 몇 번, 어떤 간격으로 하나요. 이 답은 시스템을 만들기 전에 정해야 합니다. 만든 뒤에는 장애가 먼저 와서 답을 대신 정해 버립니다.
혼자 해야 할까요
네 가지를 정했다면 실행 방식이 남습니다. MIT 보고서에서 성패의 갈림이 가장 컸던 변수가 바로 이것입니다(MIT 보고서). 전문 파트너와 함께 도입한 기업은 약 67%가 성과를 냈고, 자체 구축은 그 3분의 1 수준에 그쳤습니다.
이 숫자를 무조건 외부에 맡기라는 말로 읽을 필요는 없습니다. 판단 기준으로 읽으면 됩니다. 파트너를 고른다면, 기술 목록을 먼저 내미는 곳보다 앞의 네 가지 — 지표, 업무, 종점, 장애 — 를 먼저 묻는 곳이 낫습니다. 그 질문을 건너뛴 프로젝트가 95% 쪽에 쌓입니다.
우리 조직이라면
결재 서명 전에 네 칸을 확인해 보세요.
- 성과표에 비용 절감과 나란히 품질 지표(해결률·재문의율·만족도)가 들어 있나요.
- 첫 대상은 반복·규칙 업무인가요. 도구를 얹는 그림인가요, 업무 흐름을 다시 그린 그림인가요.
- 결과물은 지금 쓰는 시스템의 어느 종점에 떨어지나요. 데이터 경계는 합의됐나요.
- 멈췄다 다시 돌 때 무슨 일이 생기는지, 재시도 정책이 문서에 있나요.
네 칸이 다 채워져 있다면 그 도입은 이미 95%의 바깥에서 출발합니다. 비어 있는 칸이 있다면, 그 칸이 파일럿이 끝난 뒤 지불하게 될 비용입니다.