지난 몇 년간 여러 기업의 AI 도입 과정을 함께하면서, 실패하는 프로젝트에는 놀랄 만큼 비슷한 패턴이 있다는 것을 알게 되었습니다. 흥미로운 점은 기술력이 부족해서 실패하는 경우는 오히려 드물다는 것입니다. 대부분은 시작하는 방식에서 이미 결과가 정해집니다.
패턴 1. "AI를 도입한다"가 목표인 경우
가장 흔한 출발점입니다. 경영진이 AI 도입을 지시하고, 실무진이 적용할 곳을 찾습니다. 순서가 거꾸로입니다.
이 경우 프로젝트는 보통 이렇게 흘러갑니다. 적용 가능한 후보를 나열하고, 그중 기술적으로 가장 만만한 것을 고르고, 데모를 만들고, 성공적으로 시연하고, 그리고 아무도 쓰지 않습니다. 시연 성공과 업무 정착은 전혀 다른 문제이기 때문입니다.
대안: 문제를 숫자로 먼저 정의하기
저희가 프로젝트를 시작할 때 가장 먼저 하는 일은 기술 검토가 아니라 기준값 측정입니다.
- 이 업무에 지금 몇 명이 몇 시간을 쓰고 있는가
- 오류율은 얼마이고, 오류 하나당 비용은 얼마인가
- 처리 지연이 다음 공정에 얼마나 영향을 주는가
이 숫자가 없으면 프로젝트가 끝났을 때 성공했는지 판단할 방법이 없습니다. 판단할 수 없는 프로젝트는 예산을 다시 받지 못하고, 예산을 받지 못한 시스템은 방치되다 사라집니다.
패턴 2. 데이터가 있다고 믿는 경우
"우리 데이터는 충분합니다"라는 말을 들으면 저희는 반드시 실물을 확인합니다. 경험상 이 말이 사실인 경우는 절반이 되지 않습니다.
흔한 상황은 이렇습니다. 데이터는 분명히 쌓여 있지만 라벨이 없거나, 라벨 기준이 담당자마다 다르거나, 정상 데이터만 남아 있고 정작 학습에 필요한 이상 데이터는 폐기되어 있습니다. 불량 검출 프로젝트에서 불량 이미지가 30장뿐인 경우도 드물지 않습니다.
대안: 첫 2주를 데이터 진단에 쓰기
데이터 진단은 비용이 아니라 보험입니다. 확인해야 할 것은 네 가지입니다.
- 양 — 클래스별로 충분한가. 전체 개수가 아니라 가장 적은 클래스의 개수가 성능을 결정합니다.
- 품질 — 라벨링 기준이 일관적인가. 두 사람이 같은 데이터를 라벨링했을 때 얼마나 일치하는지 측정해 보면 상한선이 보입니다.
- 대표성 — 실제 운영 환경의 조명, 각도, 계절, 설비 노후도가 반영되어 있는가.
- 접근성 — 기술적으로 꺼낼 수 있는가. 보안 정책상 반출이 불가능한 데이터는 없는 데이터와 같습니다.
데이터가 부족하다는 결론이 나와도 프로젝트가 끝나는 것은 아닙니다. 사전학습 모델 활용, 데이터 증강, 합성 데이터 생성 같은 방법이 있습니다. 다만 그 사실을 개발 6개월 차가 아니라 2주 차에 아는 것이 중요합니다.
패턴 3. PoC에서 멈추는 경우
가장 아까운 실패입니다. PoC는 성공했는데 운영으로 넘어가지 못합니다.
이유는 대개 PoC 조건과 운영 조건이 다르기 때문입니다. 깨끗하게 정리된 데이터셋에서 97%가 나온 모델이, 현장의 실시간 스트림에서는 결과가 크게 달라집니다. 조명이 바뀌고, 카메라가 흔들리고, 예상하지 못한 물체가 들어옵니다. 게다가 PoC에서는 아무도 신경 쓰지 않던 응답 속도, 장애 복구, 담당자 교육 같은 문제가 한꺼번에 등장합니다.
대안: PoC 단계에서 운영 조건을 미리 넣기
저희는 PoC 설계 시 다음을 의도적으로 포함합니다.
- 정제되지 않은 현장 원본 데이터로 최소 1회 평가
- 목표 응답 시간을 처음부터 성능 지표에 포함
- 모델이 틀렸을 때 시스템이 어떻게 동작할지 함께 설계 (사람에게 넘기는 임계값 등)
- 실제 사용자 1명 이상이 PoC 단계에서 직접 써 보기
이렇게 하면 PoC 성공률 자체는 낮아집니다. 하지만 성공한 PoC가 운영까지 도달하는 비율은 크게 올라갑니다. 저희는 후자가 더 중요하다고 봅니다.
정리
세 패턴은 결국 하나의 문장으로 요약됩니다. 기술보다 문제 정의가 먼저이고, 데모보다 운영이 먼저입니다.
AI 도입을 검토 중이시라면, 기술 스택을 고르기 전에 "성공했는지 어떻게 알 수 있는가"부터 답해 보시길 권합니다. 그 질문에 숫자로 답할 수 있다면 이미 절반은 성공한 것입니다.
