AI 도입 상담을 하다 보면 비슷한 장면을 반복해서 봅니다. 데모는 잘 돌아갑니다. 샘플 문서 몇 개를 넣으면 그럴듯한 결과가 나오고, 회의실 분위기도 좋습니다. 그런데 실제 업무에 붙이는 순간 정확도가 무너집니다.

원인을 기술에서 찾는 경우가 많습니다. 모델을 바꿔볼까, 프롬프트를 더 다듬어볼까. 대개 거기서 몇 주가 사라집니다. 그리고 대부분의 경우, 문제는 그쪽에 없습니다.

#데모가 잘 되는 이유

데모에 쓰는 데이터는 사람이 골라서 넣습니다. 깨끗하고, 형식이 일정하고, 대표적인 사례입니다. 고르는 사람도 의식하지 못한 채 잘 될 만한 것을 고릅니다. 악의가 아니라 자연스러운 일입니다 — 검증하려는 게 「이게 되나」이지 「어디까지 되나」가 아니기 때문입니다.

실제 업무 데이터는 그렇지 않습니다. 같은 항목이 부서마다 다른 이름으로 불리고, 예외 처리가 주석으로만 남아 있고, 몇 년 전에 규칙이 바뀌었는데 옛 데이터는 그대로입니다. 사람은 이 모든 맥락을 기억으로 보정하면서 읽습니다. 「아, 이건 그때 그 건이지」 하고 넘어갑니다. AI에게는 그 기억이 없습니다.

그래서 정확도가 떨어지는 지점을 하나씩 들여다보면, 모델이 틀린 게 아니라 입력이 애초에 여러 해석을 허용했던 경우가 압도적으로 많습니다. 사람이 보면 답이 하나로 보이지만, 그건 사람이 맥락을 갖고 있기 때문입니다.

#1. 같은 것을 여러 이름으로 부른다

가장 흔하고, 가장 조용히 정확도를 갉아먹습니다. 거래처명이 「(주)○○」와 「○○」와 「○○상사」로 흩어져 있고, 품목이 담당자마다 다른 약어로 적혀 있습니다. 엑셀에서는 옆자리 사람이 쓰던 표기를 그대로 이어 쓰다가, 담당이 바뀌면서 표기도 바뀝니다.

사람은 이걸 같은 것으로 읽습니다. 자동화는 다른 것으로 셉니다. 그래서 집계가 틀리는데 아무도 눈치채지 못합니다 — 총합이 조금 작아질 뿐 오류처럼 보이지 않기 때문입니다. 「생각보다 거래액이 적네」 정도로 넘어갑니다.

도입 전에 할 일은 명칭 통일이 아니라 어디가 얼마나 흩어져 있는지 세어보는 것입니다. 대상 항목의 고유값 개수를 뽑아보면 대개 예상보다 훨씬 많습니다. 거래처가 300곳이라고 알고 있었는데 고유값이 480개로 나오는 식입니다. 그 차이가 그대로 작업량이고, 그 숫자를 모르는 채 일정을 잡으면 반드시 밀립니다.

통일 작업 자체는 생각보다 빨리 끝나는 경우도 많습니다. 흩어진 표기의 대부분은 상위 몇십 건에 몰려 있어서, 자주 나오는 것부터 정리하면 나머지는 꼬리입니다. 어려운 건 작업량이 아니라 누가 정답을 정하느냐입니다. 「(주)를 붙이나 마나」를 결정할 사람이 없으면 이 단계에서 멈춥니다.

#2. 규칙이 문서가 아니라 사람 머릿속에 있다

「이 거래처는 마감이 25일이에요」, 「이 품목은 부가세 별도로 들어와요」, 「저 건은 작년부터 다르게 처리해요」. 이런 예외가 시스템 어디에도 없고 담당자만 압니다.

자동화를 붙이면 이 예외들이 한꺼번에 드러납니다. 그리고 대개 자동화 프로젝트가 아니라 업무 정의 프로젝트로 바뀝니다. 이건 나쁜 일이 아닙니다. 오히려 조직이 얻는 가장 큰 자산인 경우도 많습니다 — 담당자가 퇴사해도 업무가 남기 때문입니다. 다만 일정과 비용 산정에 들어가 있어야 합니다.

실무적으로는 착수 전에 담당자에게 「이 업무에서 예외는 몇 가지나 됩니까」를 묻습니다. 대답이 「글쎄요, 케이스마다 달라서」라면 그 업무는 아직 자동화 대상이 아니라 정리 대상입니다. 반대로 「네 가지예요」라고 바로 답한다면 그 업무는 지금 당장 시작해도 됩니다.

주의할 점이 하나 있습니다. 예외를 다 없애려 하면 안 됩니다. 예외에는 이유가 있고, 대개 고객과의 약속입니다. 목표는 예외를 없애는 게 아니라 예외를 적어 두는 것입니다. 적혀 있으면 자동화할 수 있고, 적혀 있지 않으면 사람만 할 수 있습니다.

#3. 원본이 기계가 읽을 수 없는 형태다

스캔한 PDF, 셀 병합이 겹겹인 엑셀, 표처럼 보이지만 실은 줄바꿈과 공백으로 맞춘 텍스트. 사람 눈에는 표지만 구조가 없습니다.

이런 자료도 읽어낼 수는 있습니다. 다만 정확도가 원본 품질에 그대로 묶입니다. 스캔이 비뚤어져 있으면 그만큼 틀리고, 셀 병합이 불규칙하면 그만큼 헷갈립니다. 그리고 이 부분은 모델을 바꿔도 크게 나아지지 않습니다.

개선 여지가 있는 쪽은 대개 원본을 만드는 단계입니다. 그래서 자동화 범위를 정할 때 「이 원본이 어디서 어떤 형태로 만들어지는가」를 먼저 봅니다. 우리가 만드는 문서라면 형식을 바꾸면 되고, 거래처가 보내주는 문서라면 양식을 요청할 수 있는지 봅니다.

상류에서 형식을 바꿀 수 있으면 하류 자동화는 훨씬 단순해지고, 그 편이 거의 항상 쌉니다. 인식 정확도를 90%에서 97%로 올리는 데 드는 비용보다, 애초에 인식할 필요가 없게 만드는 비용이 대개 더 작습니다.

#정확도를 요구하기 전에 정해야 하는 것

「정확도 몇 %면 쓸 만한가」라는 질문을 자주 받습니다. 답은 업무마다 다르고, 정확히는 틀렸을 때 무슨 일이 벌어지는가에 달려 있습니다.

틀린 결과가 다음 단계에서 사람 눈에 걸리는 업무라면 90%도 충분합니다. 나머지 10%는 어차피 검토에서 잡힙니다. 반대로 틀린 결과가 그대로 외부로 나가거나 회계에 반영되는 업무라면 99%도 부족합니다 — 100건 중 1건이 고객에게 잘못 나가는 것이니까요.

그래서 도입 설계에서 정확도만큼 중요한 것이 확신이 낮을 때 어떻게 할 것인가입니다. 애매한 건은 사람에게 넘기고, 확실한 건만 자동 처리한다 — 이 구조를 만들면 전체 정확도가 낮아도 실제로 쓸 수 있습니다. 「전부 자동」이 아니라 「대부분 자동, 일부는 사람」이 현실적인 목표입니다.

#그래서 무엇부터 해야 하나

순서를 뒤집는 것이 핵심입니다. 「어떤 AI를 쓸까」가 아니라 「어떤 업무의 입력이 이미 정리돼 있는가」부터 봅니다.

입력이 정형화돼 있고, 규칙이 문서로 있고, 예외가 손에 꼽히는 업무 — 대개 규모는 작습니다. 하지만 여기서 시작하면 몇 주 안에 실제로 도는 것이 나옵니다. 그리고 그 하나가 조직 안에서 다음 대상을 찾아줍니다. 「이게 되면 저것도 되겠는데」라는 말이 회의실에서 나오기 시작하면 그때부터는 속도가 붙습니다.

반대로 가장 손이 많이 가는 업무부터 손대면, 그 업무가 손이 많이 가는 이유가 바로 정리가 안 돼 있어서인 경우가 많습니다. 첫 프로젝트가 거기서 멈추면 조직은 「AI는 우리한테 안 맞더라」로 결론 내립니다. 기술 문제가 아니었는데도요. 그리고 그 결론은 다음 시도까지 몇 년을 미룹니다.

정리하면 이렇습니다. 데이터가 흩어진 정도를 세어보고, 예외가 문서로 있는지 확인하고, 원본을 상류에서 고칠 수 있는지 보고, 틀렸을 때의 처리 방식을 정한다. 어느 것도 AI 지식이 필요하지 않습니다. 그리고 이걸 하지 않고 시작하면, 필요한 건 AI 지식이 아니라 인내심이 됩니다.