10건 데모에선 되던 자동화가 3,000건에서 무너집니다 — 파일럿과 실전 사이의 양의 벽

시연에서는 완벽했습니다.
서류 10건을 넣으면 10건이 깔끔하게 정리돼 나옵니다.

그런데 실데이터 전체를 물리는 순간 다른 이야기가 시작됩니다.
멈추고, 빠뜨리고, 어제는 됐는데 오늘은 안 됩니다.

저희 상담 기록에서 반복해서 만나는 장면입니다. 이 글은 그 벽의 정체를 해부하고, 벽을 견디는 구조 셋을 저희가 직접 맞은 실측 수치와 함께 정리합니다.

커머스를 운영하는 한 대표님은 AI 코딩 도구로 카톡 대화를 읽어 주는 자동화를 직접 만들었습니다.
기능은 만들어졌고, 작게 돌릴 때는 잘 됐습니다.

대화량 전체를 물리자 벌어진 일입니다.
두 달을 씨름하고도 풀리지 않아 저희를 찾아오셨습니다.

건설 관련 서류를 다루는 회사도 같은 벽을 말했습니다.
GPT로 PDF 추출을 시도했는데, 건수가 쌓이자 결과를 믿을 수 없게 됐다는 이야기였습니다.

상담 기록 전체를 조사해 보면 패턴이 하나 보입니다.
상당한 자가 시도 끝에 막힌 분들이 오시는데, 막힌 지점을 짚어 보면 기능은 이미 완성돼 있었고 무너진 자리는 양이었습니다.

마지막 20%가 안 끝나는 벽, 그러니까 기능 완성의 벽과는 다른 벽입니다.
이 글의 주인공들은 기능을 다 만들었습니다. 그런데도 실전이 안 됩니다.

기능은 완성됐는데, 실전이 안 됩니다.

왜 데모는 되고 실전은 안 될까요.
비밀은 단순합니다. 10건은 AI가 한 번에 읽습니다.

3,000건은 한 번에 못 읽습니다.
AI가 한 번에 읽고 기억할 수 있는 분량에는 한계가 있어서, 넘치면 나눠서 넣어야 합니다.

나누는 순간 새 일이 줄줄이 생깁니다.
묶음을 어떻게 자를지, 묶음마다 나온 결과를 어떻게 이어 붙일지, 세 시간짜리 작업이 중간에 죽으면 어디서부터 다시 시작할지.

10건 데모는 이 일들을 한 번도 만나지 않습니다.
그래서 데모가 통과해도 벽의 존재조차 보이지 않았던 겁니다.

10건과 3,000건 사이에는 다른 문제가 하나 통째로 숨어 있습니다.

양의 벽에는 두 번째 얼굴이 있습니다. 정확도입니다.

PDF 추출을 직접 시도했던 그 회사의 말입니다.
'약간씩'이라는 표현이 핵심입니다.

늘 틀리면 일찍 버립니다.
가끔 틀리니까 계속 쓰다가, 어느 날부터 결과 전체를 못 믿게 됩니다.

간단한 산수를 하나 하겠습니다.
아래 숫자는 특정 고객의 실측이 아닌 계산 예시입니다.

정확도 98%짜리 자동화가 있다고 치겠습니다.
하루 100건을 처리하면 틀리는 건 2건이고, 담당자가 눈으로 잡아냅니다.

같은 자동화에 하루 3,000건을 걸면 오류는 매일 60건이 됩니다.
60건을 찾아내고 고치는 일이 새 업무로 태어납니다.

더 아픈 대목은 따로 있습니다. 어느 60건이 틀렸는지 모른다는 점입니다.
찾으려면 3,000건을 다 봐야 하고, 안 보면 결과 전체를 못 믿게 됩니다.

정확도는 그대로인데, 양이 오류를 업무로 바꿉니다.

막힌 대표님들이 공통으로 하고 있던 일이 프롬프트 손질입니다.
지시문을 더 정교하게 다듬으면 나아질 거라는 기대였지요.

그런데 앞의 두 벽은 모두 프롬프트 바깥에 있습니다.
나눠 읽는 문제도, 오류 60건을 찾는 문제도 문장을 고쳐서는 풀리지 않습니다.

먼저 묶음의 단위를 정합니다.
한 번에 처리할 크기를 정해 두고, 전체 작업을 그 단위로 잘라 돌립니다. 중간에 죽어도 죽은 묶음부터 다시 시작하면 됩니다.

실패는 따로 모읍니다.
어느 묶음이 실패했는지 기록이 남고, 다시 돌릴 때는 실패한 것만 돕니다. 3,000건 전체를 처음부터 다시 돌리는 일이 사라집니다.

마지막 칸에는 사람이 앉습니다.
결과에서 표본을 뽑아 사람이 확인하고, 어긋난 비율이 기준을 넘으면 공정을 멈추게 합니다. 오류를 없애는 대신 오류가 새 나가지 않게 막는 겁니다.

프롬프트는 문장을 고치고, 구조는 양을 견딥니다.

이 구조는 남에게 권하기 전에 저희 공정이 먼저 통과한 시험지입니다.
저희는 이 블로그의 초안 제작을 자동화해서 돌리고 있습니다.

처음에는 AI 작업 세션 하나가 하룻밤에 4편을 이어 쓰게 했습니다.
그러자 세션이 기억해야 할 맥락이 6만 9천 토큰에서 30만 9천 토큰까지 부풀었습니다. 토큰은 AI가 읽고 쓰는 글자량의 단위입니다.

4번째 글을 쓸 때는 앞 세 편의 작업 이력 전부를 매번 다시 읽었습니다.
하룻밤에 3,290만 토큰이 나갔는데, 실제 산출물은 그중 0.6%였습니다.

세션 하나가 중간에 죽으면 그날 4편이 통째로 0편이 됐습니다.
실제로 두 번 그랬습니다.

고친 방법이 위의 세 칸 그대로입니다.
한 편당 세션 하나로 잘랐고, 실패한 편만 다시 돌게 했고, 발행 전에 사람이 프리뷰를 승인하는 칸을 뒀습니다.

이 숫자들이 양의 벽의 실물입니다.

정리

경고 신호

• 시연은 완벽한데 실데이터 전체를 걸면 멈추거나 끝까지 못 간다

• 작업이 중간에 죽으면 처음부터 다시 돌린다

• 오류가 나올 때마다 프롬프트를 고치는 것으로 대응하고 있다

• 어제 몇 건이 틀렸는지, 어느 건이 틀렸는지 아무도 답하지 못한다

좋은 신호

• 한 번에 처리할 묶음의 크기가 정해져 있다

• 실패한 건만 따로 모여 그것만 다시 돈다

• 표본을 사람이 확인하는 자리가 공정 안에 있다

• 어젯밤 몇 건이 실패했고 왜였는지 아침에 바로 볼 수 있다

실데이터 전체를 걸기 전에, 세 가지만 자문하세요

1. 중간에 멈추면 어디서부터 다시 시작합니까?
   '처음부터 다시'가 답이면 묶음 단위가 없는 겁니다. 자르는 크기부터 정하세요.

2. 틀린 결과는 누가 언제 발견합니까?
   '고객이 발견한다'가 현실이면 표본 검증 칸이 없는 겁니다.

3. 처리량이 10배가 되면 오류 처리에 하루 몇 분을 쓰게 됩니까?
   오류율에 건수를 곱해 보세요. 그 시간이 새로 생길 업무의 크기입니다.

자주 묻는 질문

Q. 데모에서 잘 되면 실전에서도 되는 것 아닌가요?

데모가 검증하는 건 기능까지입니다. 나눠 읽기, 이어 붙이기, 중간 실패 후 재시작 같은 일은 데이터가 적을 때는 아예 등장하지 않아서 데모로는 시험조차 되지 않습니다. 실데이터 일부를 떼어 양을 늘려 가며 돌려 봐야 벽이 보입니다.

Q. 정확도를 100%로 올리면 해결되지 않나요?

생성형 AI의 출력은 확률적이라 100%를 전제할 수 없습니다. 그래서 실무 설계는 오류를 없애는 쪽 대신, 오류가 있어도 새 나가지 않게 잡는 쪽으로 갑니다. 표본 검증과 기준 초과 시 멈춤이 그 장치입니다.

Q. 어떤 도구를 쓰면 이 구조가 따라오나요?

구조는 특정 도구에 들어 있지 않습니다. 어떤 도구를 쓰든 묶음 단위와 재시도 칸과 표본 검증 칸은 자기 데이터와 업무에 맞게 설계해 넣어야 합니다. 반대로 이 설계만 있으면 도구는 바꿔도 됩니다.

Q. 만들다 멈춘 자동화는 버려야 하나요?

대개 버릴 필요가 없습니다. 기능이 완성돼 있다면 그 바깥에 묶음 단위와 재시도 칸을 두르는 쪽이 새로 만드는 것보다 빠릅니다. 저희 블로그 공정도 기능은 그대로 두고 구조만 다시 설계해 벽을 넘었습니다.