완료율에는 잡히지 않는 조용한 오답
기업이 AI를 도입했다가 접었다는 소식에는 대개 모델이 부족했다는 설명이 따라붙는다. 그런데 접힌 프로젝트들을 보면 시스템이 멈추거나 오류를 낸 경우는 드물었다. 응답은 제때 돌아왔고 작업은 완료로 처리됐는데, 그 안에 담긴 답이 틀려 있었다.
이런 오답은 전통적인 소프트웨어 감시 도구로는 잡히지 않는다. 서버 오류나 응답 지연은 시스템이 스스로 신호를 보낸다. 반면 문법과 어투가 멀쩡한 문장 속에 담긴 잘못된 숫자나 잘못 고른 문서는 요청이 정상 종료되므로 아무 신호도 만들지 않는다.
대시보드에 뜨는 응답속도와 완료율 역시 형식이 지켜졌는지만 보여 주고, 내용이 맞았는지는 보여 주지 않는다. 그렇다면 현장에서는 어떤 모습으로 나타날까? 2026년 2~3월 500명 이상 규모 기업의 기술 임원 650명을 대상으로 한 조사에서는 완료율은 안정적인데 사람에게 넘어가는 문의 비율만 올라가는 구간이 있다고 했다. 품질이 무너지고 있는데도 완료율 지표에는 잡히지 않는 상태다.
그러나 틀린 결과는 거기에서 멈추지 않는다. 문제를 감지하는 장치가 없으면 틀린 결과는 사라지지 않고 뒤쪽 시스템으로 넘어간다. 같은 조사에 따르면 자동 품질 점검이 없는 조직에서는 오류가 몇 주 동안 누적된 뒤 사용자나 후속 업무 담당자가 발견하고 나서야 드러난다. 발견 시점에는 이미 잘못된 데이터가 여러 업무 시스템으로 퍼져 있다.
평가를 미루면 실패 원인도 사라진다
그럼에도 많은 팀이 일단 배포하고 평가체계는 나중에 붙이는 순서를 택한다. 데모는 하루면 보여줄 수 있고 경영진의 반응도 즉시 돌아오는 반면, 평가체계를 만들려면 실제 업무 사례를 모으고 도메인 전문가가 정답과 오답을 일일이 판정해 줘야 한다. 그 결과물은 화면에 보이지 않는다.
평가체계는 성능을 높이는 도구이기 이전에 무엇이 틀렸는지 알아내는 도구다. 평가 장치 없이 배포하면 문제가 터졌을 때 잘못된 데이터 연결 때문인지, 지시문이 모호해서인지, 모델 능력의 한계인지를 구분할 방법 자체가 없다.
원인을 구분하지 못하는 팀에게 남는 설명은 아직 AI가 우리 업무에는 안 맞는다는 쪽이다. 고칠 수 있었던 데이터 문제나 지시문 문제까지 모델의 한계로 묶이고, 프로젝트는 실패로 분류된 채 종료된다.
앞서 언급한 650명 조사에서 파일럿을 전사 규모로 확장하는 데 성공한 곳과 멈춘 곳을 가른 지출 항목은 어떤 모델을 골랐느냐가 아니었다. 성공한 조직은 평가와 모니터링 체계, 그리고 이를 운영할 인력에 예산을 상대적으로 더 많이 썼고 모델 선택과 지시문 다듬기에는 덜 썼다. 조사 대상 기업의 78%가 파일럿을 돌리고 있었지만 전사 운영까지 간 곳은 14%에 그쳤다. 모델 선택이 성패를 가른 게 아니라는 말이다.
평가를 통과했다는 또 하나의 착각
그렇다고 평가체계만 갖추면 끝이 아니다. 2026년 6월 기업 157곳을 대상으로 한 조사에서, 응답 기업의 절반은 내부 평가를 통과한 AI 에이전트를 배포했다가 고객 앞에서 실패를 겪었다고 답했다. 자사의 자동 평가 결과를 완전히 신뢰한다는 응답은 불과 5%에 그쳤다. 내부 통과가 현장 성공을 보장하지 않는다는 말이다.
원인은 평가 항목 부족이 아니라 평가와 현실의 어긋남이었다. 시험 환경에서 통과한 기준이 실제 업무에서 중요한 것과 달랐다는 뜻이다. 일정을 잡아 주는 도구가 문장은 자연스럽게 만들면서 시간대만 틀리는 식의 실패는 일반적인 품질 점수로 걸러지지 않는다. 무엇이 실패인지는 일반 점수가 아니라 그 업무 안에서만 정의된다.
그렇다면 이 간극은 어떻게 줄일까? 표면 지표와 실제 정확성 사이의 간극을 조기에 잡으려면 실제 출력물을 사람이 직접 읽는 과정이 도구 도입보다 앞선다. 자사 데이터로 실패한 응답 수십 건을 놓고 어떤 방식으로 틀렸는지 유형을 뽑아내면, 그때 비로소 자동으로 측정할 항목이 정해진다. 순서가 반대이면 측정하기 쉬운 항목만 남고, 업무에서 실제로 중요한 오류 유형은 빠진다.
평가체계에 대한 투자는 지금으로서는 인기 없는 말이다. 당장 눈에 보이는 성과가 없고 경영진 앞에서 보여줄 화면도 없다. 몇 년 뒤에도 AI를 실제 업무에 계속 운영하는 팀과 접은 팀을 가르는 것은 더 좋은 모델을 고르는 안목이 아니라, 자기 시스템이 언제 틀리는지 남보다 먼저 아는 능력이다. 그 능력은 배포 이후에 덧붙이는 부속이 아니라 배포의 전제 조건이다. 전제가 빠지면 프로젝트도 사라진다.