대부분의 AI 파일럿은 시작하기도 전에 실패합니다. 모델 자체가 약해서가 아니라, '성공'이 무엇인지 아무도 문서로 작성하지 않았기 때문입니다. 석 달 후 한 사람은 "꽤 잘 작동한다"고 말하고, 다른 사람은 "실수를 한다"고 말하며, 이 논쟁을 종결시킬 숫자가 없습니다.
코드 작성을 시작하기 전에 회의에서 합의해야 할 다섯 가지 사항이 있습니다. 이 다섯 가지 질문에 모두 답할 수 없다면, 파일럿은 준비되지 않은 것입니다.
1. 하나의 프로세스, 하나의 담당자 (One process, one owner)
'고객 경험(customer experience)'과 같이 광범위한 것이 아니라 단일 프로세스를 선택해야 합니다. 예를 들어: 접수된 지원 요청, 공급업체 인보이스, 또는 내부 문서에 대한 질문 등이 될 수 있습니다. 그런 다음 이 프로세스의 주인이 되는 한 사람을 지정하고 그 사람이 "네, 이 결과는 허용 가능하다"라고 말할 수 있어야 합니다.
담당자가 없으면 아무도 파일럿을 받아들일 수 없습니다. 단일 프로세스가 없으면 아무도 측정할 수 없습니다.
2. 기준선 (The baseline)
오늘날 작업에 얼마나 시간이 걸리나요? 얼마나 자주 잘못되나요? 실제 샘플, 심지어 100개 항목이라도 가져와서 손으로 직접 측정해야 합니다.
이 단계는 팀들이 가장 흔하게 건너뛰는 부분입니다. 사람이 인보이스 한 장을 처리하는 데 6분이 걸리고 오류율은 3%라는 사실을 모른다면, 파일럿이 무언가를 개선했는지 말할 수 없습니다. 단지 '더 빨라진 것 같다'라고만 말할 수 있을 뿐입니다.
3. 성공으로 간주되는 숫자 (A number that counts as success)
어떤 결과도 보기 전에 목표를 숫자로 작성해야 합니다. 예시:
- "요청의 최소 70%가 사람의 개입 없이 처리되며, 이 중 정확도는 최소 97% 이상이어야 한다."
- "인보이스 총액 추출 오류율은 1% 미만이다."
두 가지 숫자가 하나보다 일반적으로 더 효과적입니다. 자동화되는 양과 그 자동화된 부분이 얼마나 정확한지입니다. 이 두 값은 서로 상충하며, 파일럿의 핵심은 바로 이 둘 사이의 지점을 선택하는 것입니다.
4. 파일럿이 접할 수 있는 데이터 (What data the pilot may touch)
어떤 시스템, 어떤 필드, 어느 기간의 데이터를 다루나요? 개인 정보가 포함되나요? 제3자 모델 API가 접근할 수 있나요, 아니면 반드시 내부 인프라 내에 머물러야 하나요?
이것을 초기에 결정해야 합니다. 이것은 '성공적'이었던 파일럿이 한 달 뒤 법률 검토 과정에서 좌초되는 가장 흔한 이유입니다.
5. 결정 날짜: 확장, 수정 또는 중단 (A date to decide: scale, fix or stop)
결정 날짜를 달력에 기록하고 세 가지 결과를 미리 명시해야 합니다: 확장(scale), 특정 문제 수정 및 재테스트, 또는 중단(stop). "중단"은 허용되는 답변이어야 합니다. 멈출 수 없는 파일럿은 단순히 예산이 적은 프로젝트일 뿐입니다.
실제 적용 사례
저는 합의된 목표의 형태를 보여주기 위해 작은 데모를 만들었습니다. 이 데모는 고객 지원 메시지(Banking77, 공개 데이터셋, 77개의 의도/intent)를 라우팅합니다. 수용 목표가 먼저 고정되었습니다: 자동으로 처리되는 티켓에 대해 최소 97%의 정확도입니다. 그런 다음 검증 분할(validation split)에서 이 목표를 충족하기 위한 신뢰 임계값(confidence threshold)이 선택되었고, 테스트 세트는 보고 목적으로 한 번 사용되었습니다.
분리된 테스트 세트(held-out test set)에서: 티켓의 75.9%가 97.7%의 정확도로 자동으로 처리되었고, 나머지는 사람에게 전달되었습니다. 만약 모든 것이 자동화되었다면, 정확도는 90.2%였을 것입니다.
명확히 하자면: 이것은 고객의 결과가 아니라 공개된 벤치마크이자 테스트 데이터 기반의 데모입니다. 핵심은 구조입니다. 자동화 수준은 추측한 것이 아니라, 먼저 합의된 정확도 목표에서 도출되었으며, 불확실한 사례에 대한 사람의 대체(human fallback) 방안이 있습니다. 목표를 높이면 오류는 줄어들지만 자동화 수준은 낮아집니다. 이것이 1번 항목의 소유자가 결정해야 할 트레이드오프입니다.
코드와 수치는 리포지토리에 있습니다: https://github.com/TerrKot/WorkSearchHepler (demos/ticket-triage 폴더).
단 한 번의 회의로 테스트하기
다섯 가지 질문을 한 슬라이드에 넣고 이해관계자들(stakeholders)에게 회의에서 답변하도록 요청하십시오. 만약 그 답변을 위해 일주일간의 이메일이 필요하다면, 당신은 파일럿의 실제 첫 번째 과제를 찾았으며, 이는 저렴한 비용으로 알아낸 것입니다.
저는 테스트 데이터 기반의 데모를 사용하고 꾸며낸 사례 연구가 없는, 비즈니스 내 실질적이고 측정 가능한 AI 도입에 관한 짧은 메모들을 작성합니다: