파일럿에서 멈추는 AI 프로젝트, 원인은 데이터입니다

결론부터

파일럿과 본 구축의 결정적 차이는 데이터의 상태입니다. 파일럿은 담당자가 고른 깔끔한 사례로 진행됩니다. 본 구축은 실제 데이터, 즉 형식이 어긋나고 누락이 있고 예외가 섞인 데이터를 만납니다.

그래서 파일럿의 성공률이 90%였다가 확산 후 60%로 떨어지고, 그 지점에서 프로젝트가 멈춥니다. 해결책은 파일럿 단계에서 일부러 더러운 데이터를 넣어보는 것입니다.

1. 파일럿 데이터를 담당자가 고르지 않게 한다

가장 흔한 실수입니다. 담당자에게 “예시 자료 좀 주세요”라고 하면 가장 잘 정리된 것을 줍니다. 그 데이터로 검증한 정확도는 실제 운영 정확도와 상당히 다릅니다.

해결책은 표본을 무작위로 뽑는 것입니다. 지난 3개월치에서 무작위로 30건을 뽑아 그대로 넣습니다. 형식이 깨진 것, 누락된 것, 예외 사례가 자연히 섞이고, 그것이 실제 성능입니다.

2. 예외 처리 비율을 미리 측정한다

자동화의 실질적 가치는 “몇 %를 사람 손 없이 통과시키는가”입니다. 90%가 통과하고 10%만 사람이 보면 큰 절감이지만, 60%만 통과하면 검토 부담이 남아 체감 효과가 사라집니다.

파일럿에서 반드시 기록할 숫자가 이 통과율입니다. 정확도가 아니라 통과율입니다. 그리고 통과하지 못한 사례를 유형별로 분류해두면, 본 구축에서 어디를 보완해야 하는지가 그 목록에서 바로 나옵니다.

3. 확산 대상을 파일럿 전에 정한다

“성공하면 다음은 어디”를 미리 정해두지 않으면 파일럿 산출물이 그 팀 전용으로 만들어집니다. 프롬프트에 팀 이름이 박히고, 예외 규칙이 그 팀 관행에 맞춰지고, 결과적으로 재사용이 어려워집니다.

확산 대상 세 팀을 미리 정해두면 설계가 달라집니다. 팀별로 달라지는 부분을 설정값으로 빼내고 공통 로직을 분리하게 됩니다. 이것이 파일럿과 본 구축을 잇는 가장 실질적인 장치입니다.

4. 담당자 부재 시나리오를 시험한다

파일럿은 대개 열정적인 담당자 한 명이 붙어 있습니다. 그 사람이 없을 때도 돌아가는지 확인하지 않으면, 확산 후 그 사람이 이동하는 순간 멈춥니다.

시험 방법은 단순합니다. 파일럿 마지막 주에 담당자를 빼고 다른 사람이 운영해 봅니다. 문서만 보고 운영할 수 있는지, 오류가 났을 때 무엇을 봐야 하는지 알 수 있는지 확인합니다.

5. 확산 비용을 미리 계산한다

파일럿 성공 기준을 다시 정의한다

“동작한다”는 파일럿 성공 기준으로 너무 약합니다. 동작하는 것은 데모 단계에서 이미 확인됩니다. 파일럿의 목적은 확산 가능성 판정입니다.

따라서 성공 기준은 네 가지여야 합니다. 무작위 표본에서 통과율이 목표치 이상인가, 통과 실패 사례가 유형화되어 있는가, 담당자 없이 운영 가능한가, 확산 비용이 계산되어 있는가. 이 네 가지가 충족되면 본 구축은 기술적 문제가 아니라 예산 문제로만 남습니다.

자주 묻는 질문