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

해결되지 않고 있는 문제

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

데이터 입력의 역사는 하나의 패턴을 따릅니다. 각 시대는 이전보다 실질적으로 개선된 기술을 만들어냈고, 각 기술은 기존 병목 현상을 제거하는 대신 새로운 병목 현상을 만들었습니다. 작업의 성격은 바뀌었습니다. 작업량은 바뀌지 않았습니다.

시대

1950년대 – 1970년대: 키펀치 시대

컴퓨터가 대화형이 되기 전, 데이터 입력은 물리적 제조 과정이었습니다. 원본 문서(구매 주문서, 원장 기록, 급여 명세서)는 한 번에 한 열씩 IBM 펀치 카드로 변환되었습니다. 카드의 80개 열 각각은 단일 문자를 보유하며, 해당 열에 1~3개의 구멍을 뚫어 인코딩했습니다. 키펀치 운영자는 타자기와 유사한 기계에서 작업하며 키를 누를 때마다 카드를 한 열씩 전진시켰습니다. 카드가 곧 데이터였습니다.

오류가 즉시 표시되지 않았기 때문에 속도보다 정확성이 더 중요했습니다. 불일치를 표시하는 별도의 기계에서 카드를 다시 뚫는 검증 단계는 표준 관행이었습니다. 그 후, 카드 배치는 컴퓨팅 센터에 제출되어 밤새 처리되었고, 출력물은 다음 날 아침에 인쇄되었습니다. 카드가 잘못 뚫린 경우, 수정하고 다시 제출하는 데 하루가 걸렸습니다.

병목 현상은 사람의 손과 배치 지연이었습니다. 이 작업은 숙련된 작업이었습니다. 키펀치 운영자는 자격을 갖추고, 테스트를 거쳤으며, 대규모 전담 풀에서 고용되었습니다. 주요 조직은 키펀치 운영자 층 전체를 인프라로 유지했습니다. 이는 임시 방편이 아니라 인정된 생산 기능이었습니다.

1980년대~1990년대: 스프레드시트가 바꾼 것은 입력이 아닌 결과물

비지칼크(VisiCalc)는 1979년에 등장했습니다. 로터스 1-2-3(Lotus 1-2-3)은 1983년에 뒤를 이었습니다. 1980년대 중반에는 엑셀(Excel)이 매킨토시에서 실행되고 있었습니다. 이 도구들은 데이터가 입력된 이후에 일어나는 일을 변화시켰습니다. 이전에는 일괄 처리로만 가능했던 계산이 이제는 데스크톱에서 즉시 실행되었습니다. 처음으로, 한 개인이 프로그래밍 인력 없이도 데이터 세트를 구축하고, 유지 관리하고, 분석할 수 있게 되었습니다.

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

스프레드시트 시대는 또한 새로운 실패 유형을 도입했습니다. 정확해 보이는 셀 안에 숨겨진 수식 오류였습니다. 데이터는 정확하게 옮겨졌지만, 이후 단계에서 잘못 사용될 수 있었습니다. 정확성 문제는 두 가지, 즉 필사 정확성과 수식 정확성으로 나뉘었습니다. 둘 다 인간의 검토가 필요했지만, 이제 검토하는 사람은 종종 데이터를 입력한 바로 그 사람이었습니다. 이는 키펀치 시대의 독립적인 검증 단계보다 약한 확인 절차였습니다.

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

이 시기에 광학 문자 인식(OCR) 기술이 성숙했습니다. 평판 스캐너는 사무용 장비가 되었습니다. ABBYY FineReader와 같은 제품은 깨끗하게 인쇄된 원본에서 합리적인 정확도로 스캔한 문서를 기계가 읽을 수 있는 텍스트로 변환할 수 있었습니다. 그 약속은 실재했습니다. 문서를 스캔할 수 있다면, 재입력 단계를 완전히 건너뛸 수 있었습니다.

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

병목 현상은 타이핑 속도에서 수정 작업량으로 옮겨갔습니다. 비표준 문서에 대한 OCR 출력은 빈 셀보다 작업하기 어려운 경우가 많았습니다. 단순히 정확하게 입력하는 대신 기존 텍스트에서 오류를 찾아 수정해야 했기 때문입니다. 충분한 양과 일관된 레이아웃을 가진 문서 유형의 경우, 검증 규칙이 있는 템플릿 기반 OCR이 효과적이었습니다. 혼합 소스의 경우, 수정하는 것보다 다시 입력하는 것이 여전히 더 빠른 경우가 많았습니다. 이 격차가 발생하는 지점에 대한 자세한 내용은 AI OCR과 기존 OCR 정확도 비교에서 확인할 수 있습니다.

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

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

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

한편, 데이터 추출보다 인쇄에 최적화된 PDF 형식은 디지털 문서조차도 파싱 작업이 필요한 경우가 많다는 것을 의미했습니다. 노동은 타이피스트에서 통합을 구축하고 유지하는 IT 팀으로 이동했으며, 구조화되지 않은 나머지 — 통합 비용을 감당할 가치가 없는 공급업체의 인보이스, 소규모 은행의 명세서, 비표준 형식의 문서 — 는 여전히 수동으로 처리되었습니다.

2010년대: 규칙 기반 자동화

로보틱 프로세스 자동화 도구는 사람이 하던 작업, 즉 화면 읽기, 필드 클릭, 값 입력을 자동화하여 데이터 입력 문제에 접근했습니다. 봇은 인보이스를 몇 분이 아닌 몇 초 만에 처리할 수 있었습니다. 안정적인 소스 형식을 가진 대량의 반복 워크플로우에서 RPA는 실질적인 생산성 향상을 제공했습니다 — 점진적이 아니라 문서당 처리 시간을 한 자릿수 이상 줄였습니다.

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

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

2020년대에 실제로 달라진 것

이전의 모든 기술은 알려진 템플릿이나 사전 정의된 규칙에 대한 패턴 매칭 방식으로 작동했습니다. OCR은 문자를 찾았고, RPA는 필드 위치를 매칭했으며, EDI는 알려진 거래 코드를 매핑했습니다. 이 모든 기술은 원본 레이아웃이 사전에 예측되어야 했습니다. 그래서 레이아웃이 바뀌면 모두 작동이 중단되었습니다.

AI 추출은 다르게 작동합니다. 사람이 읽는 방식대로 문서를 의미적으로 읽고, 레이블이나 위치와 관계없이 필드 의미를 이해합니다. 네 곳의 공급업체가 보낸 네 개의 문서에 있는 "INVOICE NO.", "INV#", "Bill Reference", "Ref:"는 모두 같은 의미입니다. 그리고 언어 모델은 이를 별도로 설명하지 않아도 알고 있습니다. 사용자가 정의한 열 이름(Invoice Number)은 개념을 찾으라는 지시이지, 특정 문자열이나 영역을 매칭할 키워드가 아닙니다.

이는 이전의 모든 접근 방식을 취약하게 만들었던 레이아웃 의존성을 제거합니다. 새 공급업체의 인보이스는 새 규칙을 작성할 대상이 아니라, 동일한 열로 처리할 또 하나의 문서일 뿐입니다. 첫 번째 공급업체를 위해 작성한 열 정의는 문서 형식이 아무리 달라도 50번째 공급업체에도 그대로 적용됩니다. 이 메커니즘에 대해 자세히 알아보려면 AI가 템플릿 없이 데이터를 추출하는 방법에 대한 설명을 참조하세요.

시대별 병목 지점

데이터 입력의 역사를 처음부터 끝까지 읽어보면, 이는 제약 조건이 이동해 온 연속 과정입니다. 각 시대의 해결책이 다음 시대의 유지 보수 부담이 되었습니다.

현재 업무의 모습

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

• 열 정의가 문서 읽기를 대체합니다. 원하는 값을 한 번만 지정하면 — Invoice Number, Vendor Name, Amount Due (number only), Issue Date (YYYY-MM-DD) — 이 정의는 이후 모든 배치의 모든 문서에 적용됩니다. 읽기와 필드 찾기는 모델에 위임됩니다.
• 형식 요구 사항이 열 이름에 포함됩니다. "Amount (number only, no currency symbol)"는 열 이름이자 형식 지정 지침입니다. 이전에 사후 정리 단계가 필요했던 작업이 추출 시점에 처리됩니다.
• 검증이 문자 수준에서 행 수준으로 전환됩니다. 각 키 입력이 원본과 일치하는지 확인하는 대신, 추출된 각 행이 타당한지 — 금액이 합리적인지, 날짜가 올바른 범위에 있는지, 공급업체 이름이 알려진 업체와 일치하는지 — 확인합니다. 교정이 아닌 이상 감지입니다.
• 문서 수는 더 이상 제약 조건이 아닙니다. 인보이스 50장도 열 설정은 1장과 동일합니다. 이전에 문서 수에 비례하여 증가하던 작업은 이제 고유한 문서 스키마 수에 비례합니다. 이는 일반적으로 문서 수보다 훨씬 적습니다.

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

자주 묻는 질문