AI PoC 실패 이유: 성공 보고 뒤에 아무도 쓰지 않는 까닭

석 달짜리 AI 시범 사업이 끝났습니다. 시험한 질문의 정답률은 90%를 넘었고, 결과 보고서는 '성공'으로 올라갔습니다. 그런데 석 달 뒤 접속 기록을 열어 보니 첫 2주가 지난 뒤로는 쓰는 사람이 거의 없습니다. 담당자는 확산 예산을 요청해야 하는데, 정작 현업은 "그거 아직 하나요?"라고 묻습니다.

드문 일이 아닙니다. 가트너는 2024년 7월, 생성형 AI 프로젝트의 최소 30%가 2025년 말까지 개념 검증(PoC) 이후 중단될 것이라고 내다봤습니다. 이 글은 PoC가 보고서에서는 성공하고 현장에서는 사라지는 다섯 가지 이유와, 다음 시범 사업을 설계할 때 처음부터 바꿔야 할 것을 정리합니다.

PoC는 무엇을 증명해야 했을까

PoC는 '이 기술로 이 일을 할 수 있는가'를 확인하는 단계입니다. 문제는 많은 PoC가 앞부분인 '이 기술로'만 증명하고 끝난다는 점입니다. 모델이 질문에 답하는지, 문서를 요약하는지는 확인했지만, 실무자가 그 답을 받아 실제로 일을 더 빨리 끝내는지는 재지 않았습니다.

기술 검증과 업무 검증은 다른 질문입니다. 앞의 것은 개발팀이 실험실에서 답할 수 있고, 뒤의 것은 현업의 하루 안에서만 답이 나옵니다. 보고서는 성공인데 아무도 쓰지 않는 PoC는 대부분 뒤의 질문을 건너뛴 경우입니다.

실패 이유 1. 정답률은 쟀지만 시간은 재지 않았다

정답률 92%는 좋은 숫자처럼 보입니다. 하지만 실무자에게 중요한 건 '이걸 쓰면 내 일이 몇 분 줄어드는가'입니다. 답이 맞아도 확인하는 데 원래 일보다 오래 걸리면 아무도 쓰지 않습니다.

틀린 8%가 어떤 질문인지도 봐야 합니다. 자주 묻는 쉬운 질문은 다 맞히고, 정작 사람이 찾기 어려워 AI에 기대한 질문에서 틀린다면 쓸 이유가 사라집니다.

정답률은 필요하지만 충분하지 않습니다. 시범 기간에는 적어도 업무 한 건을 끝내는 전체 시간과 4주째 사용률을 함께 기록해야 확산을 판단할 수 있습니다. 답변 품질을 어떻게 잴지는 생성형 AI 답변 품질 평가에서 자세히 다뤘습니다.

실패 이유 2. 고른 데이터로 시험했다

PoC 기간은 짧고 데이터 정리는 오래 걸립니다. 그래서 시험용으로 깨끗한 문서 수백 건을 골라 시작하는 경우가 많고, 거기서 정답률 90%가 나옵니다.

실제 업무 문서는 다릅니다. 스캔 상태가 나쁜 PDF, 개정 전과 개정 후 규정이 함께 들어 있는 폴더, 중요한 내용이 표 안에 숨어 있는 엑셀이 섞여 있습니다. 실제 문서를 넣는 순간 정답률은 크게 떨어지고, 실무자는 첫 주에 틀린 답을 몇 번 보고는 다시 오지 않습니다.

시범 단계부터 실제 문서를 모두 쓰기 어렵다면, 적어도 시험 질문의 일부는 '지저분한 실제 자료'에서 뽑아야 합니다. 보고서에도 깨끗한 자료와 실제 자료의 결과를 나눠 적어 두는 편이 정직하고, 확산 일정도 현실적으로 잡힙니다.

실패 이유 3. 현업은 만든 사람이 아니라 구경한 사람이었다

PoC를 IT 부서나 외부 업체가 만들고, 현업은 마지막 시연회에서 처음 보는 경우가 있습니다. 시연에서는 미리 준비한 질문으로 잘 돌아가니 박수가 나옵니다. 그러나 현업에게 그 도구는 '내가 요청한 것'이 아니라 '위에서 내려온 것'입니다.

현업이 매주 한 번이라도 직접 써 보고 불편한 점을 말할 수 있어야 합니다. 어떤 질문에서 틀렸는지, 어떤 화면이 번거로운지 들어야 고칠 수 있고, 고친 결과를 본 사람이 동료에게 권합니다. 시범 사업 담당자 명단에 현업 실무자의 이름을 올리고 그 사람의 업무 시간 일부를 공식적으로 배정하는 것만으로도 결과가 크게 달라집니다.

실패 이유 4. 기존 업무 흐름 밖에 따로 놓였다

새 도구가 별도 사이트에 있고, 따로 로그인해야 하고, 결과를 복사해 원래 쓰던 시스템에 붙여 넣어야 한다면 사람들은 금방 원래 방식으로 돌아갑니다. 바쁜 날일수록 더 그렇습니다.

오래 쓰이는 AI는 대개 이미 쓰는 화면 안에 들어가 있습니다. 메일 프로그램 옆, 결재 화면 안, 상담 화면의 한 칸처럼요. PoC에서 처음부터 연동을 다 만들 필요는 없지만, 확산하면 어느 화면에 붙일지는 시범 단계에서 정해 두어야 합니다. 그래야 보안 검토와 연동 범위를 다음 예산에 넣을 수 있습니다.

실패 이유 5. 성공한 다음에 무엇을 할지 정하지 않았다

시범 사업이 끝나면 보고서가 올라가고, 다음 해 예산을 기다리는 동안 몇 달이 흐릅니다. 그사이 담당자가 바뀌고, 모델과 서비스 가격이 바뀌고, 현업은 다른 일로 바빠집니다. 시범 사업이 끝없이 시범으로만 남는 이른바 '파일럿 연옥'입니다.

PoC를 시작하는 날 세 가지가 문서로 정해져 있어야 합니다. 어떤 결과가 나오면 확산하고 어떤 결과면 멈출지, 확산하면 누가 운영을 맡을지, 보안 심사와 예산 요청을 언제 시작할지입니다.

다음 PoC는 이렇게 설계합니다

위 기준 숫자는 예시입니다. 업무마다 다르지만, 중요한 건 숫자를 시작 전에 합의한다는 점입니다. 끝나고 나서 기준을 정하면 어떤 결과도 '성공'으로 쓸 수 있고, 그런 보고서는 확산 예산을 설득하지 못합니다.

이미 끝난 PoC는 살릴 수 있을까

살릴 수 있는 경우가 많습니다. 먼저 접속 기록에서 2주 이후에도 꾸준히 쓴 사람을 찾습니다. 한두 명이라도 있다면 그 사람이 어떤 업무에 썼는지가 다음 시범의 출발점입니다.

아무도 남지 않았다면 위의 다섯 가지 가운데 어디에 해당하는지 짚어 보고, 업무를 더 좁혀 4주짜리 짧은 재시험을 하는 편이 처음부터 다시 하는 것보다 빠릅니다. 어디서부터 다시 설계할지 막막하다면 기업 AI 도입 방법을 함께 읽어 보시거나, AX 컨설팅에서 업무 진단부터 같이 시작할 수 있습니다.