데이터 입력은 이미 여러 번 해결되었어야 했다
여러 번

해결되지 않는 문제

송장, 영수증, 계약서, 명세서, 실험실 보고서, 선적 명세서 등 외부 문서를 다루는 모든 조직은 동일한 문제에 직면합니다. 데이터가 종이나 이미지 형태로 존재하며, 이를 시스템에 입력해야 한다는 점입니다. 문서는 수신자가 아닌 발신자가 통제하는 형식으로 도착합니다. 이 정보를 수신 시스템에 안정적이고 정확하게 대규모로 전송하는 것이 실제 데이터 입력의 의미입니다.

데이터 입력의 역사에서 주목할 점은, 각 시대마다 이전보다 확실히 개선된 기술이 등장했지만, 기존 병목 현상을 해소하기는커녕 새로운 병목을 만들어냈다는 사실입니다. 작업의 성격은 바뀌었지만, 작업량은 줄어들지 않았습니다.

시대별 발전

1950년대 – 1970년대: 천공 카드 시대

컴퓨터가 대화형이 되기 전, 데이터 입력은 물리적인 제조 과정이었습니다. 원본 문서(구매 주문서, 원장 기록, 급여 명세서)는 구멍 하나당 한 문자씩 IBM 천공 카드로 변환되었습니다. 천공 카드 작업자는 타자기와 비슷한 기계를 사용해 80열 카드에 구멍을 뚫었습니다. 카드가 곧 데이터였습니다.

속도보다 정확성이 더 중요했는데, 오류가 즉시 드러나지 않았기 때문이다. 별도의 기계에서 카드를 다시 입력해 불일치를 표시하는 검증 과정(verification pass)이 표준 관행이었다. 이후 카드 묶음은 컴퓨팅 센터로 제출되어 밤새 처리되었고, 출력 결과는 다음 날 아침에 인쇄되었다. 카드가 잘못 입력되면 수정 후 다시 제출하는 데 하루가 걸렸다.

병목 현상은 사람의 손과 배치 지연(batch latency)이었다. 이 작업은 숙련된 기술이 필요했다. 키펀치(keypunch) 운영자는 자격증을 취득하고 시험을 통과했으며, 대규모 전담 풀(pool)로 고용되었다. 주요 조직은 키펀치 운영자 층 전체를 인프라로 유지했다. 이는 임시방편이 아니라 인정된 생산 기능이었다.

1980년대 – 1990년대: 스프레드시트가 입력이 아닌 목적지를 바꾸다

1979년 비지칼크(VisiCalc)가 등장했다. 1983년에는 로터스 1-2-3(Lotus 1-2-3)이 뒤를 이었다. 1980년대 중반까지 엑셀(Excel)은 매킨토시(Macintosh)에서 실행되었다. 이 도구들은 데이터가 입력된 후 일어나는 일, 즉 이전에는 배치 실행이 필요했던 계산을 이제 데스크톱에서 즉시 수행할 수 있게 바꾸었다. 처음으로 한 사람이 프로그래밍 직원 없이 데이터 세트를 구축, 유지, 분석할 수 있게 된 것이다.

스프레드시트가 바꾸지 않은 것은 데이터가 시스템에 들어가는 방식이었다. 모든 셀은 여전히 사람이 원본 문서를 읽고 입력했다. 병목 현상은 배치 처리 처리 시간에서 사람의 타이핑 속도와 정확성으로 옮겨갔다. 데이터 입력은 민주화되었다. 키보드를 가진 사람이라면 누구나 데이터 입력 운영자가 될 수 있었지만, 사람이 문서를 읽고 셀에 값을 입력하는 기본 작업은 키펀치 운영자가 다른 하드웨어에서 했던 것과 동일했다.

스프레드시트 시대는 새로운 실패 유형을 도입했다. 바로 올바르게 보이는 셀 안에 숨겨진 수식 오류다. 데이터는 정확하게 입력되었을 수 있지만, 이후 단계에서 잘못 사용될 수 있었다. 정확성 문제는 입력 정확성과 수식 정확성, 두 가지로 나뉘었다. 둘 다 사람의 검토가 필요했지만, 이제 검토자는 종종 데이터를 입력한 동일한 사람이었다. 이는 천공 카드 시대의 독립적인 검증 과정보다 약한 확인이었다.

1990년대 후반 – 2000년대: OCR의 첫 번째 물결

광학 문자 인식(OCR)은 이 시기에 성숙해졌다. 평판 스캐너는 사무용 장비가 되었다. ABBYY FineReader와 같은 제품은 깨끗한 인쇄물에서 문서를 스캔하여 합리적인 정확도로 기계 판독 가능 텍스트로 변환할 수 있었다. 약속은 현실적이었다. 문서를 스캔할 수 있다면 재입력 단계를 완전히 건너뛸 수 있었다.

OCR은 표준화된 양식(일관된 정부 템플릿으로 인쇄된 세금 문서, 매달 같은 기관에서 발행된 은행 명세서, 수년간 변경되지 않은 보험 청구 양식)에서 잘 작동했다. 문자 인식은 충분히 좋았다. 문제는 레이아웃 인식이었다. 고정되고 예측 가능한 구조가 없는 모든 것에 대해 OCR은 여전히 사람이 읽고, 관련 값을 찾아내고, 대상 시스템에 입력해야 하는 텍스트 스트림을 생성했다. 문자 인식은 타이핑을 줄여주었지만, 이해를 줄여주지는 않았다.

병목 현상은 키 입력 속도에서 수정 작업량으로 이동했다. 비표준 문서에 대한 OCR 출력은 종종 빈 셀보다 다루기 더 어려웠다. 이제는 단순히 정확하게 입력하는 대신 기존 텍스트에서 오류를 찾아 수정해야 했기 때문이다. 충분한 볼륨과 레이아웃 일관성을 가진 문서 유형의 경우, 검증 규칙이 있는 템플릿 기반 OCR이 작동했다. 혼합 소스의 경우, 수정하는 것보다 재입력하는 것이 여전히 더 빠른 경우가 많았다.

2000년대~2010년대: 디지털 문서와 통합 문제

ERP 시스템이 기업의 표준 인프라로 자리 잡고 공급업체들이 종이에 출력하는 대신 소프트웨어로 PDF를 생성하기 시작하면서, 디지털 간 전환은 매끄러워야 한다는 합리적인 기대가 생겼습니다. 원본 문서는 이미 파일이었고, 대상 시스템도 이미 디지털이었습니다. 분명 전사(轉寫) 문제는 해결된 듯 보였습니다.

전사 문제를 대신한 것은 통합 문제였습니다. 모든 ERP는 고유한 가져오기 형식을 가졌고, 모든 공급업체는 고유한 PDF 템플릿을 사용했습니다. EDI(전자 데이터 교환)는 주요 거래 파트너 간의 거래를 표준화했지만, 전용 통합 계약과 이를 유지할 IT 자원을 갖춘 조직 쌍에만 해당되었습니다. 규모가 작은 공급업체, 일회성 벤더, EDI 표준 외부의 문서 유형은 계속해서 사람의 처리가 필요했습니다.

한편, PDF는 데이터 추출보다 인쇄에 최적화된 형식이었기 때문에 디지털 문서조차도 구문 분석 작업이 필요한 경우가 많았습니다. 노동력은 타이피스트에서 통합을 구축하고 유지하는 IT 팀으로 옮겨갔고, 구조화되지 않은 나머지(통합 비용 대비 가치가 낮은 공급업체의 송장, 소규모 은행의 명세서, 비표준 형식의 문서)는 여전히 수동으로 처리되었습니다.

2010년대: 규칙 기반 자동화

로봇 프로세스 자동화 도구는 사람이 하는 작업(화면 읽기, 필드 클릭, 값 입력)을 자동화하여 데이터 입력 문제에 접근했습니다. 봇은 송장 하나를 처리하는 데 몇 분이 아닌 몇 초면 충분했습니다. 안정적인 소스 형식을 가진 대량 반복 워크플로우에서 RPA는 진정한 생산성 향상을 가져왔습니다. 단순한 개선이 아닌, 문서당 처리 시간을 한 자릿수로 줄여준 것입니다.

취약성은 그 대가였습니다. RPA 봇은 규칙에 따라 작동했습니다. 문서의 X 영역에서 "송장 번호"라는 레이블이 있는 필드를 찾고, 값을 추출하여 시스템의 Y 필드에 붙여넣는 식이었죠. 새 공급업체, 재설계된 PDF 템플릿, 발신자 측의 다른 회계 시스템 등 원본 문서 레이아웃이 변경되면 규칙이 깨지고 봇이 작동을 멈췄습니다. 장애를 모니터링하고 레이아웃이 변경될 때 규칙을 업데이트하는 작업은 지속적인 운영 부담이 되었습니다.

소수의 안정적이고 대용량 워크플로우를 가진 조직은 이 유지보수 비용을 흡수할 수 있었습니다. 문서당 절감액이 전담 봇 유지보수 기능을 정당화했기 때문입니다. 다양한 가변 문서 소스를 가진 조직은 그럴 수 없었습니다. 병목 현상은 사람의 데이터 입력에서 규칙 엔지니어링과 봇 유지보수로 이동했습니다. 데이터 입력 작업자는 사실상 봇 개발자가 되었습니다.

2020년대에 실제로 바뀐 것

이전의 모든 기술은 알려진 템플릿이나 사전 정의된 규칙에 대한 패턴 매칭으로 작동했습니다. OCR은 문자를 찾았습니다. RPA는 필드 위치를 매칭했습니다. EDI는 알려진 거래 코드를 매핑했습니다. 이 모든 기술은 소스 레이아웃을 사전에 예측해야 했습니다. 이것이 바로 레이아웃이 변경될 때 모두 작동을 멈춘 이유입니다.

AI 추출은 다르게 작동합니다. 사람이 하는 것처럼 문서를 의미론적으로 읽고, 레이블이나 위치에 관계없이 필드 의미를 이해합니다. 네 공급업체의 네 문서에 있는 "INVOICE NO.", "INV#", "Bill Reference", "Ref:"는 모두 같은 것을 의미하며, 언어 모델은 이를 알려주지 않아도 압니다. 정의하는 열 이름(Invoice Number)은 특정 문자열이나 영역과 일치시킬 키워드가 아니라, 개념을 찾으라는 명령어입니다.

이는 이전의 모든 접근 방식을 취약하게 만들었던 레이아웃 의존성을 제거합니다. 새 공급업체의 인보이스는 새로운 규칙을 작성해야 하는 것이 아니라, 동일한 열 집합으로 처리할 또 다른 문서일 뿐입니다. 첫 번째 공급업체를 위해 작성한 열 정의는 문서 형식이 아무리 달라도 50번째 공급업체에서도 그대로 작동합니다.

시대별 병목 현상

현재 업무의 모습

AI 추출이 데이터 입력 작업을 없애는 것은 아닙니다. 작업의 성격을 바꿀 뿐입니다. 핵심 질문이 "이 문서에서 이 값을 어떻게 추출할까"에서 "모든 문서에서 일관되게 필요한 값은 무엇인가"로 바뀝니다. 이는 빠르고 정확한 타이핑과는 다른 기술이며, 스키마 설계에 더 가깝습니다.

• 컬럼 정의가 문서 읽기를 대체합니다. 송장 번호, 공급업체명, 청구 금액(숫자만), 발행일(YYYY-MM-DD) 등 원하는 내용을 한 번만 지정하면, 해당 정의가 이후 모든 배치의 모든 문서에 적용됩니다. 읽기와 필드 찾기는 모델이 처리합니다.
• 형식 요구사항은 컬럼명에 포함됩니다. "금액(숫자만, 통화 기호 제외)"는 컬럼명이자 동시에 형식 지시사항입니다. 이전에는 후처리 정리 단계가 필요했던 작업이 추출 시점에 처리됩니다.
• 검증이 문자 단위에서 행 단위로 전환됩니다. 각 키 입력이 원본과 일치하는지 확인하는 대신, 추출된 각 행이 타당한지 확인합니다. 금액이 합리적인지, 날짜가 적절한 범위에 있는지, 공급업체명이 알려진 업체와 일치하는지 등을 검증합니다. 교정이 아닌 이상 탐지입니다.
• 문서량이 제약이 되지 않습니다. 송장 50장도 1장과 동일한 컬럼 설정을 사용합니다. 이전에는 문서 수에 비례하여 증가하던 작업이, 이제는 고유한 문서 스키마의 수에 비례하여 증가합니다. 이는 일반적으로 문서 수보다 훨씬 적습니다.

실패 방식도 다릅니다. AI 추출은 컬럼명이 모호하거나, 문서가 인식 불가능할 정도로 손상되었거나, 필드가 원본 문서에 실제로 존재하지 않을 때 실패합니다. 이는 사양의 실패로, 컬럼 정의를 개선하여 해결할 수 있습니다. 타이핑 속도의 실패처럼 더 빠른 작업자나 더 많은 인력이 필요한 문제가 아닙니다.

자주 묻는 질문