문서 자동화의 핵심은 추출보다 판정 근거다
논문 『LLM-Based Examination of Eligibility Criteria from Securities Prospectuses at the German Central Bank』를 읽고
독일 중앙은행 담보 적격성 검토 사례를 통해, 긴 문서 업무에서 LLM 자동화가 추출-정규화-해석-검증의 운영 구조로 설계되어야 함을 읽는다.
제일 먼저 든 생각
긴 문서 자동화는 “필드 몇 개를 뽑아냈다”에서 끝나지 않는다. 진짜 어려운 곳은 그 다음이다. 뽑힌 값이 업무 규칙에 맞게 해석됐는지, OCR 잡음과 언어 차이를 견딜 수 있는지, 사람이 나중에 왜 그런 판정이 나왔는지 확인할 수 있는지까지 이어져야 한다.
이 논문은 독일 중앙은행(Deutsche Bundesbank)의 담보 적격성 검토 사례를 다룬다. 증권을 중앙은행 신용거래의 담보로 받을 수 있는지 판단하려면 수백 페이지짜리 투자설명서(prospectus)를 읽고 법적·재무적 기준을 확인해야 한다. 문서는 반정형이고, 독일어와 영어가 섞여 있으며, 정보가 여러 페이지에 흩어져 있다. 이 연구는 그 과정을 LLM 기반 생성형 정보추출(generative information extraction) 파이프라인으로 바꾸어 본 사례다.
긴 문서 자동화는 추출, 정규화, 해석, 평가가 분리되어야 운영 가능한 흐름이 된다.
NER에서 생성형 추출로 넘어갈 때 생기는 차이
기존 접근은 필요한 정보를 Named Entity Recognition(NER) 문제로 보고, 문서 안의 정확한 텍스트 범위를 찾아내는 방식에 가까웠다. 하지만 투자설명서 같은 문서는 표현이 일정하지 않다. OCR 잡음이 있고, 같은 의미가 다른 언어·형식·문장 구조로 나타난다. 정확한 위치를 맞추는 평가만으로는 실제 업무 판단에 필요한 “의미상 같은 값인가”를 충분히 다루기 어렵다.
연구진은 LLM 파이프라인을 추출(extraction), 정규화(normalization), 해석(interpretation) 단계로 나눈다. 그리고 평가는 위치 기반 지표보다 값 기반(value-based) 평가를 쓴다. 예를 들어 독일어 금융 용어가 형식상 다르게 추출되어도, 업무상 같은 금융상품 유형으로 볼 수 있다면 맞는 것으로 판정하는 식이다.
“이 접근은 과업을 추출, 정규화, 해석으로 분해해, 잡음 있는 텍스트와 독일어-영어가 섞인 내용을 더 유연하게 다룰 수 있게 한다.”
“Our approach decomposes the task into extraction, normalization, and interpretation, allowing for greater flexibility in handling noisy text and interleaved German-English content.”
이 구조가 실무적으로 중요하다. 많은 문서 자동화 프로젝트가 “PDF에서 값을 뽑는다”에 머문다. 그러나 판정 업무에서는 뽑힌 값이 규칙과 만나야 하고, 규칙과 만난 결과가 설명 가능해야 한다.
보수적인 자동화가 더 쓸모 있을 때
논문은 285개 주석 문서를 대상으로 실험했고, 문서 단위 적격성 판단에서 LLM 기반 시스템이 높은 정밀도(최대 91%)를 보였다고 보고한다. 특히 Command-R 08-2024는 문서 단위에서 정확도 0.84, F1 0.86, 정밀도 0.91, 재현율 0.82로 제시된다. 논문은 이 프로파일을 “false acceptance를 최소화하는 보수적 운영”으로 해석한다.
“LLM 기반 시스템은 문서 단위 적격성에서 최대 91%의 높은 정밀도를 달성했고, 잘못된 수락을 최소화하는 보수적 운영 특성을 보였다.”
“LLM-based systems achieve high precision (up to 91%) in document-level eligibility, exhibiting a conservative operating profile that minimizes false acceptance.”
담보 적격성처럼 리스크가 큰 업무에서는 이 점이 중요하다. 놓치는 것(false negative)도 문제지만, 부적격한 것을 적격하다고 받아들이는 것(false acceptance)은 더 치명적일 수 있다. 모든 자동화가 균형 잡힌 F1만 추구해야 하는 것은 아니다. 업무 리스크에 따라 보수성이 성능 목표가 될 수 있다.
원문 첫 페이지. 연구는 중앙은행 담보 적격성 검토를 LLM 기반 문서 자동화 사례로 다룬다.
LLM-as-a-judge는 평가 자동화이자 설계 도구다
논문에서 또 하나 흥미로운 부분은 LLM-as-a-judge를 평가에 쓴 방식이다. 단순 문자열 유사도와 함께, 필드별로 “무엇을 동등한 값으로 볼 것인가”를 지시한 평가자를 둔다. 이 평가자는 점수뿐 아니라 이유를 반환한다. 연구진은 이 이유가 평가 지침을 개선하는 데 도움이 되었다고 쓴다.
이 지점은 Deciflow의 문서 자동화에도 바로 연결된다. RAG나 에이전트 워크플로를 만들 때, 결과를 평가하는 작은 판정기를 따로 두면 산출물 품질을 볼 수 있을 뿐 아니라 운영 규칙도 드러난다. “왜 틀렸는가”가 쌓이면 프롬프트 수정이 아니라 업무 규칙 정비로 이어질 수 있다.
다만 논문 스스로도 다음 단계로 RAG 통합을 언급한다. 환각 위험을 줄이고, 검토자가 관련 문서 구간으로 바로 이동할 수 있게 하려면 검색 기반 근거 연결이 필요하다는 것이다. 이건 문서 자동화의 거의 기본 원칙처럼 보인다. 생성형 추출만으로 끝내지 말고, 근거 위치와 판정 이유를 함께 남기는 구조가 필요하다.
업무에 붙이면: 자동화 산출물보다 검토 화면 먼저
이 논문을 실무 와일드카드로 고른 이유는 Power BI·평가 자동화·문서 검토 업무와 연결하기 좋기 때문이다. 보고서, 규정, 계약서, 제안서 같은 긴 문서에서 AI를 쓸 때 다음 순서로 설계할 수 있다.
- 문서에서 필요한 값을 추출한다.
- 값의 형식과 단위를 정규화한다.
- 업무 규칙에 따라 판정한다.
- 판정마다 원문 근거와 이유를 붙인다.
- 위험이 큰 판정은 자동 확정하지 않고 검토 큐로 보낸다.
이렇게 보면 문서 자동화의 첫 화면은 챗봇이 아니라 검토 테이블일 수 있다. 행마다 추출값, 정규화값, 판정, 근거 위치, 검토 필요 여부가 붙어 있고, 사람은 전체 문서를 다시 읽는 대신 위험한 행부터 본다.
오늘 남길 질문
다음 문서 자동화 실험에서는 “AI가 무엇을 추출했는가”보다 먼저 “사람이 어떤 근거로 승인하거나 되돌릴 수 있는가”를 화면에 그려보자. 자동화는 문서를 대신 읽는 기술이 아니라, 검토 가능한 판단 단위를 만드는 기술에 가까워야 한다.
원문 정보
- 제목: LLM-Based Examination of Eligibility Criteria from Securities Prospectuses at the German Central Bank
- 저자: Serhii Hamotskyi, Akash Kumar Gautam, Christian Hänig
- 출처: arXiv
- arXiv: 2606.27316v1