지능형 문서 처리(IDP)는 AI 및 관련 기술을 활용해 문서 내용을 워크플로가 사용할 수 있는 정보로 전환합니다. 일반적인 시스템은 들어오는 문서를 분류하고 관련 데이터를 추출한 뒤 결과를 검증하고, 검토된 정보를 다음 단계로 전달합니다. 진짜 관건은 시스템이 페이지를 읽을 수 있느냐가 아니라, 뒤따르는 작업에 대해 결과가 충분히 신뢰할 수 있느냐입니다.
AWS의 IDP 설명은 비즈니스 규칙이나 기존 데이터와의 대조를 포함해 이러한 단계를 설명합니다. 이 검증 단계가 중요한 이유는, 그럴듯한 청구서 금액이 여전히 틀릴 수 있고 올바르게 추출된 값이 이미 시스템에서 수신한 청구서에 속한 값일 수도 있기 때문입니다.
추출 이후의 ‘다음 액션’부터 시작하기
도구를 평가하기 전에 이 문장을 완성해 보세요: “문서가 처리되면 우리는 …를 해야 합니다.” 답은 레코드를 생성하는 것일 수도 있고, 검토자를 지정하는 것일 수도 있으며, 구매 주문서와 정보를 비교하거나 브리핑을 준비하는 것일 수도 있습니다. 각 결과는 서로 다른 점검 항목과 서로 다른 수준의 자동화를 필요로 합니다.
작업이 사람이 요약본을 읽는 것으로 끝난다면 문서 이해만으로도 충분할 수 있습니다. 그러나 다른 시스템의 레코드를 변경하는 결과라면 정의된 스키마, 검증 규칙, 예외를 처리할 경로까지도 필요합니다. 파일럿 이전에 이러한 요구사항을 먼저 정해야 합니다. 추출 데모만으로는 전체 워크플로가 준비되었는지 보여줄 수 없기 때문입니다.
IDP 워크플로의 단계
| 단계 | 목적 | 감지하지 못할 수 있는 실패 예시 |
|---|---|---|
| 인테이크 | 소스 파일을 수신하고 식별 | 동일한 파일이 두 번 도착 |
| 분류 | 문서 유형 또는 관련 카테고리 결정 | 신용장이 인보이스로 처리 |
| 추출 | 작업에 필요한 필드 캡처 | 합계(소계)가 총액으로 캡처 |
| 검증 | 값, 관계, 필수 정보 확인 | 총액이 합의된 계산 규칙에 실패 |
| 검토 | 애매하거나 거부된 결과 해결 | 불명확한 날짜에 근거 없는 추정이 들어감 |
| 라우팅 | 승인된 정보를 다음 단계로 전달 | 유효한 레코드가 잘못된 목적지로 전송 |
이는 모든 IDP 제품이 여섯 단계를 모두 제공한다는 보장이 아니라, 계획을 위한 모델입니다. 서비스가 제공하는 구성 요소와, 직접 구축하거나 설정해야 하는 부분이 무엇인지 확인하세요.
분류는 다음 해석을 결정합니다
문서가 서로 비슷해 보이더라도 목적이 다를 수 있습니다. 청구서, 구매 주문서, 신용장은 이름, 날짜, 금액이 포함되어 있을 수 있지만, 동일한 액션을 유발해서는 안 됩니다. 분류는 어떤 추출 규칙과 검토 요구사항이 적용될지를 결정합니다.
Microsoft의 Document Intelligence 개요는 추출 모델과 함께 커스텀 분류기를 설명합니다. 이 구분이 보여주는 핵심은 문서 유형을 인식하고 그 내용을 추출하는 일이 별도의 작업이라는 점입니다. 또한 문서 유형이 불확실하거나 예상된 범위를 벗어날 경우 어떤 일이 일어나야 하는지도 워크플로에서 정의해야 합니다.
추출은 각 필드에 대한 명확한 정의가 필요합니다
“날짜를 추출하세요”는 파일에 이슈 날짜, 서비스 날짜, 결제 마감일이 모두 있을 때 모호해집니다. 필요한 필드가 무엇인지, 출력에서 어떤 형태로 나타나야 하는지를 정의하세요. 누락된 값에 대한 규칙도 포함하고, 추출을 확인하는 데 필요한 정보는 그대로 보존해야 합니다.
예를 들어 청구서 스키마는 공급업체명, 인보이스 번호, 인보이스 날짜, 통화, 총액, 세금을 요청할 수 있습니다. 이러한 필드 정의는 문서가 여러 후보 값을 제시할 때 어떤 값을 선택해야 하는지 명시해야 합니다. 필드를 추가하는 일은 쉽지만, ‘정답’이 무엇인지 판단하려면 더 많은 주의가 필요합니다.
검증은 단순한 가독성을 넘어서는 확인입니다
일부 검증은 값이 예상된 형식을 갖추었는지 확인합니다. 다른 검증은 문서 내 관계를 확인하거나, 추출된 데이터를 신뢰할 수 있는 레코드와 비교합니다. 날짜는 올바르게 형식이 맞아 보이지만 잘못된 사건을 나타낼 수 있고, 총액은 읽기에는 문제가 없어 보이지만 항목(라인 아이템)과 일치하지 않을 수 있습니다.
비즈니스 규칙과 실패 시의 액션을 정의하세요. 예를 들어 인보이스 번호가 누락되면 검토를 요구해야 할 수 있고, 공급업체-인보이스 번호 조합이 반복되면 중복 확인이 트리거될 수 있습니다. 포맷 체크를 통과했다고 해서 후속 단계의 액션을 자동으로 승인하면 안 됩니다.
실제 청구서 예시
다음과 같은 세부 정보를 가진 공급업체 청구서를 떠올려 보세요. 발행일은 3월 5일, 지급일은 4월 4일, 소계는 1,000, 총액은 1,080입니다. 통화는 결정할 만큼 명확하게 인쇄되어 있지 않습니다. 이는 제품 테스트에서 측정된 결과가 아니라 예시입니다.
추출 시스템은 깔끔한 레코드를 반환하면서 인보이스 날짜를 4월 4일로, 총액을 1,000으로 설정하고 통화는 추정할 수 있습니다. 각 값은 단독으로는 충분히 그럴듯합니다. 함께 보면, IDP 워크플로가 필드의 의미를 명시적으로 정의하고 검토 규칙이 필요하다는 이유를 보여줍니다.
| 요청된 필드 | 검토된 값 | 수용(acceptance) 체크 |
|---|---|---|
| 인보이스 날짜 | 3월 5일 | 지급일이 아니라 발행일을 사용 |
| 지급일 | 4월 4일 | 인보이스 날짜와 분리해서 유지 |
| 총액 | 1,080 | 최종 총액을 식별하고 구성 요소를 점검 |
| 통화 | 미해결 | 미해결로 두고 검토를 요청 |
정답인 다음 단계는 통화가 어디에 중요한지에 따라, 레코드를 사용하기 전에 통화를 해결하는 것입니다. 추정으로 만들어 ‘완성된 것처럼 보이는’ 레코드는, 검토자가 무엇을 확인해야 하는지 명확히 식별하는 ‘불완전한’ 레코드보다 활용도가 떨어집니다.
OCR, Document AI, IDP, 그리고 RPA
Google의 Document AI는 OCR, 추출, 분류를 위한 프로세서를 제공합니다. 이러한 구성 요소는 워크플로가 각 단계에 따라 서로 다른 기능을 어떻게 사용할 수 있는지를 보여줍니다. 추출기가 존재한다고 해서 검증 규칙이나 예외 처리(handling)가 구현되어 있는지 알 수는 없습니다.
| 접근 방식 | 그것이 답하는 핵심 질문 | 별도로 평가할 것 |
|---|---|---|
| OCR | 어떤 텍스트가 보이나요? | 읽기 순서와 인식 오류 |
| 문서 이해 | 이 자료는 무엇이라고 말하거나 무엇을 의미하나요? | 소스 지원과 누락된 맥락 |
| IDP | 문서는 어떻게 ‘승인된’ 워크플로 레코드가 되나요? | 검증, 검토, 라우팅, 통합 |
| RPA | 다음에 어떤 반복 가능한 인터페이스 액션이 일어나야 하나요? | 입력이 유효한지, 그리고 액션이 적절한지 |
경계는 절대적이기보다는 현실적입니다. 제품은 여러 접근 방식을 결합할 수도 있습니다. 마케팅 라벨이 전체 시스템을 정의한다고 가정하기보다, 그 구분을 활용해 더 나은 평가 질문을 던지세요.
생성형 AI가 도움이 되는 지점—그리고 규칙이 여전히 중요한 지점
생성형 모델은 지침과 다양한 언어를 해석할 수 있어, 유연한 추출과 문서 이해에 특히 적합합니다. Google은 Document AI 제공에서 생성형 AI 기반 커스텀 추출기를 설명합니다. 이는 해당 제품에 대한 기능 주장에는 힘을 실어주지만, 모든 파일 또는 모든 워크플로에 대한 보편적인 정확도 수준을 보장하지는 않습니다.
지능형 문서 처리 AI 파일럿을 위해, 모델이 무엇까지 추론하도록 허용할지 정의하세요. 어떤 작업은 정규화된 값을 필요로 하고, 어떤 작업은 그대로 전사(직접 받아쓰기)해야 합니다. 검토자가 특정 필드가 명시적인 진술에서 나온 것인지 해석에서 나온 것인지 구분할 수 있도록 이러한 모드를 분리해 두세요.
프롬프트는 “없으면 null을 사용”이라고 요청할 수 있지만, 워크플로는 여전히 출력물을 확인해야 합니다. 유창한 설명을 ‘해당 필드가 맞다’는 증거로만 믿지 마세요. 관련 소스 구절, 필드 정의, 그리고 추출 이후 적용되는 어떤 규칙이든 검토하세요.
유용한 IDP 파일럿을 설계하는 방법
하나의 문서 패밀리와 하나의 결과를 선택하세요
검토를 위해 공급업체 청구서에서 지정된 필드를 추출하는 것처럼, 범위가 제한된 작업부터 시작하세요. 파일럿이 무엇을 산출할지, 그리고 예외를 누가 확인할지 정의합니다. 첫 번째 워크플로가 이해되기 전에 문서 패밀리를 여러 개로 확장하면 실패 원인을 진단하기가 더 어려워질 수 있습니다.
대표 평가 세트를 구축하세요
일반적인 예시와, 실제로 받을 것으로 예상되는 변형을 포함하세요. 예를 들어 누락된 필드, 익숙하지 않은 레이아웃, 다중 페이지 문서, 품질이 떨어지는 스캔, 그리고 중복 문서입니다. 검토자가 테스트 전에 기대 결과를 설정하도록 하세요. 별도의 홀드아웃(분리) 세트를 유지해, 최종 평가는 구성 선택을 안내하지 않았던 파일도 포함하도록 하세요.
결과를 ‘적절한 수준’에서 측정하세요
필드 정확성과 문서 수용(acceptance)은 서로 다른 질문에 답합니다. 시스템이 대부분의 필드는 정확히 캡처하지만, 작업을 완료하는 데 꼭 필요한 단 하나의 필드를 자주 놓칠 수도 있습니다. 어떤 필드가 실패하는지, 문서가 얼마나 자주 검토가 필요한지, 그리고 어떤 레코드가 다음 단계로 넘어갈 준비가 되었는지 기록하세요.
아래 정의를 일관되게 사용하세요.
- 필드 정확도(Field correctness): 문서에서 평가된 필드 중 정답으로 판정된 필드 수 / 평가된 전체 필드 수(문서화된 매칭 규칙 사용)
- 검토 비율(Review rate): 처리된 문서 중 사람의 검토가 필요한 문서 수 / 처리된 문서 수
- 수용률(Acceptance rate): 처리된 문서 중 모든 정의된 수용 체크를 충족한 문서 수 / 처리된 문서 수
- 검토 노력(Review effort): 예외를 해결하는 데 소요된 시간(일관된 시작 및 종료 지점으로 측정)
이들은 제안하는 평가 지표이지, 성능 주장(performance claims)이 아닙니다. 누락된 필드와 잘못된 값을 분리하고, 추출 오류뿐 아니라 후속 단계에서의 실패도 함께 기록하세요. 이러한 구분은 파싱을 개선할지, 필드 정의를 다시 작성할지, 검토 경로를 조정할지를 결정하는 데 도움이 됩니다.
자동화를 늘리기 전에 예외 처리부터 테스트하세요
파일을 읽을 수 없는 경우, 문서 유형을 알 수 없는 경우, 필수 필드가 서로 충돌하는 경우 어떤 일이 발생하는지 확인하세요. 워크플로는 미해결(unresolved) 상태가 눈에 보이게 하고, 검토자가 충분한 맥락을 확인할 수 있도록 보존해야 합니다. 거절된 레코드가 조용히 다음 시스템으로 넘어가지 않는지도 확인하세요.
“IDP AI” 도구를 평가한다면, 직접 준비한 대표 문서로 예외 경로(exception path)를 보여 달라고 요청하세요. 성공적인 데모는 일반 파일이 어떻게 처리되는지만이 아니라, 실패가 어떻게 처리되는지도 포함해야 합니다.
iWeaver는 어디에 들어맞나요
일부 문서 작업은 운영용 레코드보다는 ‘이해’로 끝납니다. 보고서를 읽거나 브리핑을 준비하는 중이라면 iWeaver는 요약, AI 대화, 지식 구성(오거나이제이션)을 제공합니다. AI 문서 요약기는 소스 자료를 검토하고 더 면밀한 주의가 필요한 대상을 결정하기 위한 출발점이 될 수 있습니다.
예를 들어 분석을 계획하기 전에 보고서의 주장, 근거, 한계에 대한 개요를 요청해 보세요. iWeaver의 공개 문서 워크플로는 맞춤형 요약과 후속 탐색을 지원합니다. 사실이 중요할 때는 언제든 원문을 확인하고, 필요한 엔터프라이즈 추출 또는 통합 기능은 각각 별도로 평가하세요.
IDP 시스템을 선택하기 전에 확인할 질문
지능형 문서 처리는 OCR과 같은가요?
OCR은 텍스트 인식에 집중합니다. IDP 워크플로는 분류, 추출, 검증, 검토, 라우팅 같은 작업을 추가합니다. 제품을 비교하기 전에, 여러분의 작업에 실제로 필요한 단계가 무엇인지 식별하세요.
IDP는 사람의 검토 없이도 실행할 수 있나요?
그것은 문서, 수용 기준(acceptance criteria), 그리고 오류가 가져오는 결과에 달려 있습니다. 어떤 결과는 자동으로 진행될 수 있고 어떤 결과는 검토가 필요할지 정의하세요. 모든 입력에 자동화가 적절하다고 가정하기보다, 파일럿 증거를 바탕으로 그 규칙을 설정하세요.
IDP 워크플로는 누락된 정보를 어떻게 처리해야 하나요?
누락된 값을 명시적으로 표현하고 정의된 규칙을 적용하세요. 필수 필드는 거절 또는 검토를 유발할 수 있고, 선택 필드는 비어 있게 둘 수도 있습니다. 누락된 값을 추측하면 결과를 감사(audit)하기 어려워지고 다음 단계에서 안전하게 쓰지 못할 수 있습니다.
무엇을 먼저 테스트해야 하나요?
다음 단계의 액션에 필요한 필드가 정확히 캡처되고 검증되는지 먼저 테스트하세요. 그런 다음 예외, 중복, 그리고 승인된 레코드의 목적지를 테스트하세요. 핵심 필드나 실패 경로가 여전히 신뢰할 수 없다면, 높은 수준의 추출 점수만으로는 부족합니다.
첫 워크플로는 검토 가능하게 만드세요
좁은 범위의 문서 작업을 선택하고, 승인된 출력(acceptance output)을 정의한 뒤 일반 파일과 예외 모두를 테스트하세요. 추출을, 최종 결과가 반드시 확인되어야 하는 프로세스의 한 단계로 취급하세요. 문서를 이해하는 것이 당장의 목표라면 소스 기반 요약부터 시작하고, 이를 바탕으로 검토를 진행하세요.