AI 자동화는 왜 시연 뒤에 실패할까: 실제 운영에서 달라지는 조건

시연자는 잘 읽히는 문서를 고르고, 필요한 계정에 미리 로그인한 뒤, 애매한 결과를 화면 밖에서 고칠 수 있습니다. 같은 자동화를 업무 담당자에게 넘기면 그 준비 작업까지 운영 절차에 포함됩니다. 구글 SRE의 제품 출시 점검이 요청 흐름, 의존 서비스, 부하 가정과 운영 책임을 함께 다루는 이유도 실행 코드 밖에 출시 조건이 있기 때문입니다.

자동화의 운영 범위는 “문서를 처리합니다”보다 좁고 구체적입니다. 어떤 문서를 어느 계정으로 받아서, 무슨 결과를 남기며, 판단이 어려울 때 누가 인계받는지까지 적으면 시연에서 확인하지 않은 부분이 드러납니다.

시연에 쓴 입력이 운영 대상을 대표하는지 확인하기

잘 고른 샘플에는 선택 과정이 숨어 있습니다. 텍스트가 또렷한 PDF만 골랐다면 스캔본과 사진은 검증하지 않은 입력입니다. 제출자가 양식의 필수 칸을 모두 채웠다면 누락값을 받았을 때의 동작은 아직 모릅니다. 시연에서 통과한 입력과 업무에 실제로 들어오는 입력을 각각 적으면 검증하지 않은 종류가 드러납니다.

가상의 구매 요청 분류 업무에서는 한글 신청서, 영문 견적서, 사진으로 찍은 영수증이 같은 수신함에 들어옵니다. 시험용 문서가 정형 신청서뿐이었다면 “구매 문서를 분류한다”는 설명은 검증 범위를 넓게 잡은 것입니다. 정형 신청서 자동 분류부터 운영하고 나머지 입력을 검토 대기함으로 보내는 쪽이 관측 가능한 시작점입니다.

입력을 늘릴 때는 파일 개수와 함께 달라지는 속성을 기록합니다. 문서 종류, 언어, 텍스트 추출 가능 여부, 필수 필드 누락, 한 파일 안의 여러 요청을 구분합니다. 형식이 같은 문서가 많아져도 새로운 실패 조건을 확인했다는 근거가 되지는 않습니다.

기존 업무에서 “접수된 것”의 범위도 고정합니다. 읽을 수 없어 제외한 파일, 중복으로 판정한 요청, 검토 대기함에 남은 문서를 분모에서 빼면 자동 처리 성공률이 높아 보입니다. 접수 건수에서 자동 처리, 수동 처리, 처리 불가, 대기 상태로 어떻게 나뉘었는지 남겨야 누락이 보입니다.

입력과 외부 서비스는 코드가 같아도 달라집니다

상류 시스템이 날짜 표기나 항목 이름을 바꾸면 문서 추출 단계의 가정이 깨집니다. 텍스트가 추출됐어도 통화나 세금 포함 여부를 잘못 읽으면, 형식이 정상인 분류 결과 안에 오류가 남습니다. 파일을 열었다는 기록과 필요한 정보를 올바르게 얻었다는 기록을 분리하면 이 차이를 찾기 쉽습니다.

2015년 논문 Hidden Technical Debt in Machine Learning Systems는 다른 시스템이 만드는 입력에 의존할 때 그 입력이 바뀌면서 유지 비용이 생기는 문제를 설명합니다. 전통적인 머신러닝 시스템을 다룬 논문입니다. LLM을 쓰는 문서 자동화에서는 이를 입력 생산자, 형식 변경, 결과 소비자의 가정을 묻는 운영 점검으로 옮겨 쓸 수 있습니다.

구매 요청의 “금액”을 예로 들면 숫자만 저장하는 계약과 통화·세금 조건을 함께 저장하는 계약은 다릅니다. 값이 없을 때 빈칸으로 둘지, 0으로 볼지, 검토 대상으로 보낼지도 정합니다. 예시 업무에서는 금액이나 통화가 빠진 요청을 검토 대상으로 보냅니다. 누락을 0으로 채우면 낮은 금액의 정상 요청으로 잘못 분류할 여지가 생깁니다.

외부 서비스의 응답도 입력의 일부입니다. API 오류, 응답 지연, 필드 누락이 뒤 단계에 어떤 값으로 전달되는지 확인합니다. 서비스나 모델의 설정이 바뀐 날짜를 결과 기록과 연결하면, 같은 파일에서 결과가 달라진 원인을 비교할 단서가 남습니다.

시연자가 대신하던 예외 처리를 업무량에 포함하기

시연 전에 파일 이름을 정리하고, 중복 요청을 지우고, 거래처 이름을 통일했다면 그 작업은 운영 비용에 포함됩니다. 사람이 결과를 고치는 단계가 있다면 어떤 항목을 왜 고쳤는지 기록합니다. “사람이 확인합니다”라는 한 문장만으로는 필요한 판단과 소요 작업을 알 수 없습니다.