지능형 문서 처리를 위한 스키마 생성 자동화

지능형 문서 처리(IDP, Intelligent Document Processing) 파이프라인의 가장 큰 병목은 새로운 문서 유형이 들어왔을 때 사람이 직접 문서를 분류하고 추출 스키마(필드 정의)를 작성해야 한다는 점이었다. 이번에 발표된 multi-document discovery 기능은 이 사전 처리 단계를 자동화한다. 핵심 기술은 두 가지로 나뉜다. 첫째, 비주얼 임베딩(visual embedding)을 활용해 문서의 레이아웃·시각적 특징을 벡터로 변환한 뒤 유사도 기반으로 클러스터링하여 같은 양식의 문서들을 자동으로 묶는다. 텍스트만 보는 NLP 방식과 달리 인보이스, 계약서, 신청서처럼 레이아웃이 정체성을 갖는 문서에 강하다. 둘째, LLM 에이전트가 각 클러스터를 분석해 추출해야 할 필드 목록과 데이터 타입을 추론하고 IDP Accelerator에서 바로 사용할 수 있는 스키마 JSON을 생성한다.

엔지니어 관점에서 이 기능의 실질적 임팩트는 "콜드 스타트 비용 제거"에 있다. 기존에는 새 고객사의 문서 1만 장을 받으면 데이터 엔지니어와 도메인 전문가가 며칠에서 몇 주에 걸쳐 샘플링·라벨링·스키마 설계를 반복해야 했는데, 이 과정을 자동화하면 PoC 단계의 리드 타임이 크게 줄어든다. 특히 SaaS 형태로 IDP를 제공하는 팀이라면 신규 테넌트 온보딩이 셀프 서비스에 가까워지고, 사내 문서 자동화 프로젝트에서도 부서별로 흩어진 양식들을 일괄 투입한 뒤 결과를 검수하는 방식으로 일하는 흐름이 가능해진다. 또한 비주얼 임베딩 기반 클러스터링은 OCR 품질이 떨어지는 스캔본·팩스 문서에서도 동작하기 때문에, 금융·보험·공공 분야처럼 레거시 종이 문서가 많은 도메인에 특히 유리하다.

다만 한국 개발자들이 실제 도입할 때 점검해야 할 포인트가 있다. 우선 생성된 스키마는 어디까지나 LLM의 추론 결과이므로, 한국어 문서·세금계산서·전자문서표준(XBRL, UBL 등) 같은 국내 양식에서는 필드명이 영문으로 잡히거나 도메인 의미가 어긋날 수 있다. 따라서 생성 스키마를 그대로 운영에 투입하지 말고 휴먼 인 더 루프(HITL) 단계를 반드시 끼워 검수·교정 워크플로우를 만들어야 한다. 또한 클러스터링 결과의 임계값(threshold)에 따라 한 클러스터에 이질적 문서가 섞이거나 거의 같은 양식이 분리되는 일이 흔하므로, 클러스터 수·실루엣 스코어 등을 관측 가능한 메트릭으로 잡아두는 게 좋다. 비용 측면에서도 비주얼 임베딩과 에이전트 추론은 페이지 단위로 과금이 누적되므로, 전체 문서를 다 돌리기보다는 대표 샘플링 후 점진적 확장 전략을 권장한다.

마지막으로 이 흐름은 단순한 AWS 기능 소개를 넘어 "스키마 자체를 코드처럼 생성·버저닝·테스트하는" 패러다임 전환을 시사한다. 앞으로 IDP를 다루는 개발자라면 추출 로직을 짜는 능력보다, 자동 생성된 스키마를 평가(eval)하고 회귀를 잡아내는 테스트 셋과 골든 데이터셋을 구축하는 역량이 더 중요해질 가능성이 높다. 자체 솔루션을 보유한 팀은 LayoutLMv3, Donut, ColPali 같은 오픈소스 멀티모달 임베딩 모델과 LangGraph·LlamaIndex 기반 에이전트 조합으로 유사 파이프라인을 재현해볼 수 있으며, 이를 통해 벤더 종속 없이 동일한 아키텍처적 이점을 누릴 수 있다.