한컴 OpenDataLoader PDF 해설: PDF 접근성은 OCR보다 태그 구조 자동화가 먼저 필요한 이유

발행일: 2026-04-30 | 카테고리: 개발정보

1) 한 줄 문제 정의

핵심 요약: 접근성 PDF의 핵심은 글자를 읽어내는 OCR이 아니라, 문서가 어떤 구조로 읽혀야 하는지 태그 트리를 복원하는 일입니다.

한컴이 2026년 4월 30일 공개한 OpenDataLoader PDF 접근성 자동 태깅 소식은 언뜻 보면 또 하나의 PDF AI 기능처럼 보입니다. 하지만 실무 관점에서 더 중요한 지점은 따로 있습니다. 기업과 공공기관이 이미 보유한 방대한 PDF 자산 대부분이 접근성 태그 없이 유통되고 있고, 이 상태에서는 스크린리더가 제목, 본문, 표, 목록, 이미지의 읽는 순서를 제대로 이해하지 못합니다.

이 글의 대상 독자는 문서 플랫폼 팀, 공공기관 디지털 전환 담당자, 전자문서 SaaS 개발팀, 그리고 RAG용 PDF 파이프라인을 운영하는 개발자입니다. 범위는 OpenDataLoader PDF의 자동 태깅이 왜 의미 있는지, 기존 PDF 추출·보정 도구와 무엇이 다른지, 실제 파일럿을 어떤 순서로 시작해야 하는지입니다. 반대로 일반적인 웹 접근성 소개나 법률 자문 자체는 다루지 않습니다.

2) 먼저 결론

핵심 요약: OpenDataLoader PDF는 “PDF를 읽는 도구”를 넘어 기존 PDF를 접근 가능한 구조 문서로 되돌리는 자동화 출발점에 가깝습니다.

• 지금 바로 맞는 팀: 대량의 민원서식, 계약서, 연구자료, 공시자료, 리포트를 PDF로 배포하는 조직
• 아직 과한 팀: PDF 몇 건만 수동 수정하면 되는 소규모 팀, 또는 최종 산출물이 PDF가 아닌 내부 텍스트 추출만 필요한 팀
• 제 판단: 이 도구의 핵심 가치는 “AI를 붙였다”가 아니라 접근성 보정 비용을 문서 1건 단위 수작업에서 배치 파이프라인으로 옮긴다는 데 있습니다.

다만 이것이 곧바로 모든 문서를 완전한 PDF/UA로 보장한다는 뜻은 아닙니다. 자동 태깅은 매우 좋은 출발점이지만, 최종 준수 여부는 이미지 대체 텍스트, 언어 설정, 표 구조 정확성, 검수 워크플로까지 포함해야 합니다. 그래서 저는 이 공개를 “완전 자동 끝판왕”보다 접근성 운영 자동화의 현실적 기반으로 보는 편이 맞다고 봅니다.

3) 핵심 구조 분해

핵심 요약: OpenDataLoader PDF의 강점은 추출 정확도와 접근성 태깅을 하나의 문서 구조 엔진 위에서 같이 다룬다는 점입니다.

3-1. 구조 추출 엔진

이 프로젝트는 원래 AI용 PDF 파서로 출발했습니다. README 기준 하이브리드 모드 벤치마크에서 전체 정확도 0.907, 표 추출 0.928을 제시하고 있으며, Markdown·JSON·HTML 같은 구조화 출력이 가능합니다. 즉 접근성 태깅은 완전히 별개 제품이 아니라, 이미 문서 구조를 잘 읽는 엔진 위에 올라갑니다.

3-2. 태그 트리 복원 계층

접근성 자동화의 핵심은 여기입니다. 제목, 문단, 목록, 표, 이미지 같은 요소를 식별한 뒤 Tagged PDF 구조로 다시 써 넣습니다. 쉽게 말해 “이 글자가 보인다”에서 끝나는 것이 아니라, “이 문단은 제목 아래 있는 본문이고, 이 표는 몇 번째 열과 행 관계를 가진다”를 기계가 이해할 수 있게 만드는 단계입니다.

3-3. 규제 대응 파이프라인

OpenDataLoader 문서에는 감사(Audit) → 자동 태깅(Tagged PDF) → PDF/UA 내보내기 → 시각적 검수 스튜디오의 4단계가 제시됩니다. 이 구조가 중요한 이유는 접근성을 단발성 변환이 아니라 운영 워크플로로 본다는 뜻이기 때문입니다.

3-4. 온프레미스 실행 모델

PDF Association 기사와 제품 문서는 모두 온프레미스 실행을 강조합니다. 법무·금융·공공 문서처럼 외부 업로드가 어려운 환경에서는 이 점이 실제 도입의 가장 큰 문턱을 낮춥니다.

4) 설계 의도 해설

핵심 요약: 한컴은 접근성 문제를 “편집 도구 부족”이 아니라 문서 구조를 기계가 이해하지 못하는 병목으로 보고 있습니다.

이 설계는 꽤 영리합니다. 전통적인 PDF 접근성 보정은 사람이 Acrobat 같은 도구에서 태그를 열어보고 제목 수준, 표 셀 관계, 이미지 alt를 손으로 손질하는 식이었습니다. 정확도는 높을 수 있지만, 수천~수만 문서로 가면 운영이 무너집니다. OpenDataLoader는 먼저 구조를 최대한 자동으로 복원해 Tagged PDF를 만들고, 그 위에 필요한 검수·PDF/UA 단계를 얹는 방향을 택했습니다.

이 방식의 장점은 세 가지입니다.

• 기존 문서 자산을 버리지 않고 사후 보정할 수 있습니다.
• 접근성과 AI 추출을 같은 구조 엔진으로 다뤄 중복 투자를 줄입니다.
• 온프레미스 파이프라인이라 민감 문서 반출 부담이 낮습니다.

대신 포기하는 것도 있습니다. 완전 자동 정확도에 대한 환상입니다. 실제 문서에는 깨진 표, 스캔 품질 저하, 잘못된 원본 서식, 장식 이미지 남발 같은 예외가 많습니다. 그래서 이 설계는 “100% 자동 완료”보다는 80~90%를 기계가 처리하고, 나머지를 검수 가능한 상태로 넘긴다는 현실적 자동화에 더 가깝습니다.

5) 근거 및 비교

핵심 요약: 이 도구의 경쟁 상대는 단순 OCR이 아니라, 비싼 수작업 보정과 구조 없는 PDF 추출기입니다.

공개 근거도 비교적 명확합니다.

• OpenDataLoader README는 하이브리드 모드가 200개 실사용 PDF 기준 전체 정확도 0.907, 표 추출 0.928을 기록했다고 설명합니다.
• README는 수동 접근성 보정 비용을 문서당 50~200달러 수준으로 제시하며, 무료 Apache 2.0 코어에서 자동 태깅을 제공한다고 밝힙니다.
• 접근성 전용 페이지는 연간 4000건 이상의 접근성 소송, 공공 PDF의 95% 이상 비준수, EAA 시행과 ADA Title II 시한을 함께 제시합니다.
• PDF Association 기사는 Apache 2.0 전환, 온프레미스 하이브리드 엔진, OCR·표·수식·차트 AI 애드온 4종을 한 번에 언급하며 제품 방향을 보강합니다.

제 해석은 이렇습니다. 이 도구의 진짜 차별점은 “PDF를 더 잘 읽는다”가 아니라 읽기 정확도와 접근성 준수를 하나의 아키텍처 문제로 합친다는 데 있습니다.

6) 실제 동작 흐름 / 단계별 실행 방법

핵심 요약: 파일럿은 전사 전환보다 문서 100건 내외의 고빈도 PDF 묶음으로 시작하는 편이 안전합니다.

Step 1. 태그 없는 PDF부터 골라내십시오

opendataloader-pdf file1.pdf file2.pdf folder/ \
  --output-dir audit-output/ \
  --use-struct-tree

구조 태그가 없으면 로그에 fallback 경고가 뜹니다. 이 목록이 자동 보정 우선순위 후보입니다.

Step 2. 자동 태깅 결과를 배치 생성하십시오

opendataloader-pdf --format tagged-pdf file1.pdf file2.pdf folder/

이 단계는 접근 가능한 Tagged PDF를 만드는 1차 자동화입니다. 아직 PDF/UA 최종 보장은 아니므로, 곧바로 전체 배포본으로 교체하기보다 샘플 검수가 필요합니다.

Step 3. 스캔 문서는 OCR 포함 하이브리드 모드로 분리하십시오

pip install "opendataloader-pdf[hybrid]"
opendataloader-pdf-hybrid --port 5002 --force-ocr --ocr-lang "ko,en"
opendataloader-pdf --hybrid docling-fast --format tagged-pdf scanned-folder/

한글·영문이 섞인 행정 문서나 스캔 계약서는 이 경로가 더 현실적입니다.

Step 4. 표와 이미지가 많은 문서는 샘플 검수 기준을 만드십시오

최소한 제목 계층, 표 헤더, 목록, 이미지 설명, 읽기 순서를 사람이 10건 이상 확인하십시오. 자동화 품질은 문서 유형마다 차이가 큽니다.

Step 5. 최종 배포 전 완료 기준을 명확히 두십시오

예를 들어 “상위 100개 민원서식 중 95건 이상이 제목·표·목록 구조를 유지하고, 검수 샘플에서 치명적 읽기 순서 오류가 0건일 것” 같은 기준이 있어야 합니다. 그래야 자동화가 성능 시연이 아니라 운영 품질로 연결됩니다.

7) 실수/함정(Pitfalls)

핵심 요약: 가장 흔한 실패는 OCR 성공을 접근성 성공으로 착각하는 것입니다.

• 실수 1: 글자 추출만 되면 끝났다고 보는 것
  예방: 제목·표·목록·대체 텍스트·읽기 순서를 별도 검수 항목으로 두십시오.
  복구: 텍스트 정확도 지표와 접근성 구조 지표를 분리해 다시 측정하십시오.
• 실수 2: 모든 PDF를 같은 파이프라인으로 처리하는 것
  예방: 디지털 원본, 스캔본, 표 중심 문서, 이미지 브로셔를 유형별로 나누십시오.
  복구: 스캔/OCR 문서는 하이브리드 모드, 표 중심 문서는 샘플 검수 비율을 높이십시오.
• 실수 3: 법규 대응을 개발팀 단독 과제로 두는 것
  예방: 접근성 담당자, 문서 소유 부서, 법무 또는 정책 담당자와 완료 기준을 함께 정의하십시오.
  복구: 기술 검증과 규정 검증 체크리스트를 분리하고 승인 절차를 추가하십시오.
• 실수 4: 기존 문서만 고치고 새 문서 생성 프로세스는 방치하는 것
  예방: 배치 보정과 함께 새 문서 템플릿 접근성 기준을 같이 만드십시오.
  복구: 신규 PDF 생성 시 태그 포함 여부를 CI 또는 배포 전 검증 항목으로 넣으십시오.

8) 강점과 한계

핵심 요약: 방향은 아주 좋지만, 실제 성패는 자동 태깅 이후 검수 체계를 같이 설계하느냐에 달려 있습니다.

강점

• Apache 2.0 오픈소스라 대량 파일럿 비용 장벽이 낮습니다.
• Python·Node.js·Java와 CLI를 모두 제공해 기존 업무 흐름에 넣기 쉽습니다.
• 접근성과 AI 데이터 추출을 하나의 구조 엔진으로 다뤄 중복 파이프라인을 줄일 수 있습니다.
• 온프레미스 실행이 가능해 공공·금융·법무 문서에 유리합니다.

한계

• 자동 태깅만으로 모든 PDF/UA 요구사항을 100% 충족한다고 단정하면 위험합니다.
• 원본 문서 품질이 나쁘면 구조 추론도 흔들릴 수 있습니다.
• 문서 유형별 성능 차이를 조직이 직접 검증해야 합니다.

반례: 이미 문서가 원본 작성 단계에서 접근성 태그를 잘 포함하고 있고, 새 문서만 관리하면 되는 팀이라면 사후 대량 보정보다 문서 생성 도구 개선이 더 우선일 수 있습니다.

9) 더 깊게 공부할 포인트

핵심 요약: 다음 학습 포인트는 모델 이름보다 Tagged PDF와 PDF/UA 운영 차이를 이해하는 것입니다.

• Tagged PDF와 PDF/UA는 무엇이 같고 무엇이 다른가
• 우리 조직 PDF 중 태그 없는 문서 비율은 얼마나 되는가
• RAG용 PDF 추출과 접근성용 PDF 보정이 어느 지점에서 같은 엔진을 공유할 수 있는가
• veraPDF 같은 검증 도구를 배포 전 품질 게이트로 넣을 수 있는가
• 새 문서 생성 단계에서 접근성 결함을 줄이려면 어떤 템플릿 규칙이 필요한가

10) 실행 체크리스트 + 작성자 관점

핵심 요약: 이 도구를 도입할지 판단하는 기준은 “AI냐 아니냐”가 아니라 PDF 접근성 부채를 배치 처리할 필요가 있느냐입니다.

• 태그 없는 기존 PDF 자산 규모를 파악했는가?
• 문서 유형별로 디지털 원본과 스캔본을 구분했는가?
• 자동 태깅 후 사람이 확인할 샘플 검수 기준을 정했는가?
• 법규 준수 판단을 위한 내부 승인 주체를 정했는가?
• 신규 PDF 생성 프로세스에도 접근성 검증을 넣었는가?
• 민감 문서라면 온프레미스 운영 방식과 자원 계획을 검토했는가?

Definition of Done: 우선순위 문서 묶음에서 자동 태깅 결과가 샘플 검수와 검증 도구를 통과하고, 신규 문서 생성 단계까지 같은 접근성 기준이 연결되면 1차 도입이 완료된 것입니다.

제 추천: 공공기관, 금융, 교육, 엔터프라이즈 문서 플랫폼처럼 PDF가 핵심 산출물인 팀이라면 지금 바로 작은 파일럿을 시작해 볼 가치가 큽니다. 반대로 PDF를 단순 텍스트 추출 원천으로만 쓰는 팀은 접근성 자동 태깅보다 기존 추출 파이프라인 최적화가 우선일 수 있습니다. 저는 이번 공개를 “PDF 접근성도 이제 수작업 교정 시장에서 구조 자동화 시장으로 넘어가기 시작했다”는 신호로 봅니다.

참고자료

• AI타임스 - 한컴, PDF 접근성 태그 자동 생성 AI 도구 오픈소스 공개 (발행일: 2026-04-30)
• OpenDataLoader PDF - Accessibility (확인일: 2026-04-30)
• OpenDataLoader PDF README (확인일: 2026-04-30)
• OpenDataLoader Docs - Tagged PDF (확인일: 2026-04-30)
• OpenDataLoader Docs - PDF Accessibility Compliance Guide (확인일: 2026-04-30)
• PDF Association - OpenDataLoader PDF v2.0 Tops Open-Source PDF Benchmarks in PDF Data Loading (발행일: 2026-03-17)
• European Commission - European Accessibility Act (확인일: 2026-04-30)