문서를 ‘읽는 것’과 ‘이해하는 것’의 차이
문서 디지털화 기술을 논할 때 가장 흔히 언급되는 개념은 OCR(Optical Character Recognition)이다. OCR은 종이 문서나 이미지 속 글자를 기계가 인식해 텍스트로 변환하는 기술로, 이미 수십 년간 다양한 산업에서 활용되어 왔다.
그러나 최근에는 OCR만으로는 해결되지 않는 문제들이 점점 더 분명해지고 있다. 특히 의료 리포트, 금융 문서, 계약서, 행정 문서처럼 구조와 의미가 중요한 문서에서는 단순한 문자 인식만으로는 실질적인 데이터 활용이 어렵다. 이러한 한계를 보완하기 위해 등장한 개념이 ADE(Automated Data Extraction, 또는 Advanced Document Extraction)이다.
위 인포그래픽은 동일한 의료 검사 결과지(CBC 리포트)를 예시로, OCR과 ADE가 문서를 어떻게 다르게 처리하는지를 시각적으로 비교하고 있다.
왼쪽 패널은 OCR만 적용했을 때의 결과를 보여준다. 표면적으로 보면 OCR은 문서 속 대부분의 글자를 정확히 인식한다. 병원명, 환자 이름, 검사 항목, 수치, 단위, 날짜 등은 모두 텍스트로 추출된다. 그러나 문제는 문서의 구조와 의미가 완전히 붕괴된 상태라는 점이다.
병원명, 로고, 슬로건, 연락처, 주소가 하나의 헤더로 구성되어 있음에도 불구하고
OCR 결과에서는 단어 단위, 심지어 문자 단위로 분절되어 각각 별도의 인식 대상이 된다.
이로 인해 “병원 정보”라는 하나의 의미 단위는 사라지고, 텍스트 조각만 남는다.
환자 이름, 나이, 성별
검체 채취 장소
의뢰 의사
바코드 및 접수/보고 시간
이 정보들은 실제 문서에서는 명확히 구분된 영역에 배치되어 있으나, OCR 결과에서는 모두 동일한 텍스트 스트림으로 나열된다. 즉, 시스템 입장에서는 어떤 값이 환자 정보이고, 어떤 값이 검사 메타데이터인지 구분할 수 없다.
CBC 리포트의 핵심은 검사 항목과 결과값이 정리된 표이다.
Investigation (검사항목)
Result (결과)
Reference Value (정상 범위)
Unit (단위)
OCR은 각 셀의 텍스트는 읽어내지만, “이 수치는 어떤 항목의 결과인가”, “이 단위는 어떤 결과에 대응하는가”라는 관계를 보존하지 못한다. 결과적으로 표는 표가 아닌 텍스트 조각의 집합이 된다.
하단에 제시된 OCR 결과 예시는 이를 잘 보여준다.
문서에 등장한 텍스트가 위에서 아래로 나열되어 있을 뿐
필드, 속성, 관계, 계층 구조는 존재하지 않는다.
이 상태의 데이터는 사람이 다시 읽어 해석하거나, 추가적인 규칙 기반 후처리를 거쳐야만 활용 가능하다.
오른쪽 패널은 ADE 방식으로 동일한 문서를 처리한 결과를 보여준다. 여기서 핵심은 “글자를 읽었다”가 아니라, 문서를 구성하는 정보의 역할과 관계를 이해했다는 점이다.
ADE 결과에서는 문서가 다음과 같은 의미 단위로 분해된다.
병원 정보 블록
환자 정보 블록
검체 채취 정보
의뢰자 정보
바코드 및 시간 정보
검사 결과 테이블
각 블록은 시각적으로도 명확히 구분되어 있으며, 데이터 구조 상으로도 독립적인 엔티티로 취급된다.
환자 이름, 나이, 성별, ID 정보는 하나의 “환자 정보 객체”로 묶인다. 검체 채취 장소와 의뢰 의사는 각각 명확한 필드로 분리된다.
이러한 구조 덕분에:
환자 정보만 조회하거나
검사 이력과 연결하거나
다른 시스템(HIS, EMR, 보험 시스템 등)과 연동하는 것이 가능해진다.
CBC 검사 결과는 여전히 ‘표’로 유지된다.
항목명
결과값
정상 범위
단위
이상 여부 표시(High/Low)
이 관계가 그대로 보존되기 때문에, 데이터는 곧바로 분석, 시각화, 통계 처리, 임상 의사결정 지원에 활용될 수 있다.
하단 ADE 출력 예시는 OCR과 달리,
필드 중심
속성 중심
구조 중심의 결과를 보여준다.
이는 사람이 읽기 쉬울 뿐만 아니라, 기계가 바로 사용할 수 있는 데이터 형태라는 점에서 결정적인 차이를 만든다.
이 인포그래픽이 전달하는 핵심 메시지는 단순하다.
OCR은 “문서를 읽는 기술”이고, ADE는 “문서를 데이터 모델로 변환하는 기술”이다.
OCR은 여전히 유효한 기술이지만, 그 자체로는 완결된 솔루션이 아니다.
특히 다음과 같은 경우에는 ADE 수준의 접근이 필수적이다.
의료, 금융, 법률 문서처럼 구조가 중요한 경우
문서를 단순 보관이 아니라 데이터 자산으로 활용하려는 경우
자동화, 분석, AI 활용을 전제로 하는 경우
결국 문제는 “글자를 읽었는가”가 아니라 “문서를 이해했는가”이다.
이 인포그래픽은 그 차이를 한 장의 그림으로 명확하게 보여준다.
대규모 트래픽, 안정성, 엔터프라이즈 연계를 중시할 때 가장 먼저 검토되는 범주이다.
Google Cloud – Document AI
단순 OCR을 넘어 문서 타입별 파서(Parser)를 제공 Invoice Parser, Receipt Parser, Contract Parser, Identity Parser 등
레이아웃 이해 + 키-값 추출 + 테이블 구조 보존
의료·금융·공공 문서에 강점
한계: 커스터마이징은 가능하나 비용이 빠르게 증가
Amazon Web Services – Textract
Form(키-값), Table(표) 구조를 기본 지원
스캔 품질이 낮아도 비교적 안정적인 결과
의료·보험·백오피스 자동화에서 많이 사용
단점: 의미적 해석은 제한적, “구조 추출 중심”
Microsoft Azure – Form Recognizer
커스텀 모델 학습이 비교적 쉬움
문서 유형별 템플릿 학습에 강점
OCR + 레이아웃 + 필드 추출을 하나의 파이프라인으로 제공
기업 내부 시스템(ERP, Power Platform)과 연계 용이
OCR을 넘어서 업무 자동화·프로세스 통합까지 포함하는 상용 솔루션이다.
ABBYY – FlexiCapture
OCR 업계의 전통 강자
문서 분류(Classification) + 필드 추출 + 검증 워크플로우
금융·회계·공공기관에서 레퍼런스 풍부
룰 기반 + ML 혼합 구조
UiPath – Document Understanding
RPA(UiPath)와 깊게 통합된 ADE
문서 추출 → 검증 → 자동 처리까지 일관된 파이프라인
ADE를 “자동화의 입력 레이어”로 쓰는 경우에 적합
Automation Anywhere – IQ Bot
반정형·비정형 문서 처리에 초점
사람이 검증에 개입하는 Human-in-the-loop 구조가 잘 설계됨
대량 문서 처리에 적합
직접 시스템을 설계하거나, 비용/데이터 통제권이 중요한 경우에 사용된다.
LayoutLM 계열
문서 레이아웃 + 텍스트 + 위치 정보를 함께 학습하는 Transformer 모델
ADE 연구·프로덕션 양쪽에서 널리 사용
후속 버전(LayoutLMv2/v3)은 이미지 정보까지 통합
OCR을 거치지 않고, 이미지 → JSON 구조 직접 생성
복잡한 표, 영수증, 폼 처리에 강점
최신 연구/서비스에서 ADE 핵심 모델로 주목받는 흐름
Tesseract 자체는 OCR이지만,
Detectron2, Layout Parser 등과 결합해 ADE 파이프라인 구성 가능
개발 비용은 낮지만, 구현 난이도는 높음
최근에는 대형 언어 모델(LLM)을 ADE의 핵심 엔진으로 사용하는 접근이 급속히 확산되고 있다.
OpenAI GPT 계열
OCR 결과 + 문서 이미지 + 프롬프트를 결합
“이 문서에서 환자 정보/검사 결과를 JSON으로 추출하라” 같은 지시 가능
복잡한 비정형 문서에서 압도적인 유연성
단점: 비용, 재현성, 규제(의료/금융)
멀티모달 LLM 기반 ADE
이미지 + 텍스트 + 레이아웃을 동시에 해석
계약서 요약, 의료 리포트 구조화, 재무제표 파싱 등에서 강력
ADE의 개념을 “문서 이해 에이전트”로 확장시키는 흐름
현재 ADE 기술의 진화 방향은 명확하다.
OCR → Layout 이해 → 구조 추출
정형 규칙 → ML 기반 → LLM 기반
문서 처리 → 데이터 파이프라인 → 에이전트 입력 레이어
즉, ADE는 더 이상 “문서 처리 기술”이 아니라 AI 시스템이 현실 세계의 문서를 이해하기 위한 핵심 인터페이스 계층으로 이동하고 있다.
ADE 기술을 선택할 때는 기술 스펙보다 아래 질문이 더 중요하다.
문서를 사람이 읽기 위해 쓰는가, 시스템이 쓰기 위해 쓰는가?
결과가 저장이 목적인가, 의사결정/자동화가 목적인가?
문서 유형이 고정되어 있는가, 계속 바뀌는가?
이 질문에 대한 답에 따라,
클라우드 ADE,
상용 IDP,
오픈소스,
LLM 기반 접근
중 어느 쪽이 적합한지가 갈린다.
--
Written by AI Alchemist & Maestro 두드림
- Orchestrating AI, systems, and human judgment
이 글은 Creative Commons BY-NC 라이선스에 따라 비영리적 용도로 자유롭게 복사·배포·활용할 수 있습니다. 출처(저자명·브런치 링크)만 표시해 주세요.