메인 콘텐츠로 건너뛰기
조회수 10

GLM-OCR로 OCR 끝내기: 정확도·속도·구조화까지 한 번에

요약

GLM-OCR로 OCR 끝내기: 정확도·속도·구조화까지 한 번에

최근 Z.ai가 GLM-OCR을 GitHub에 공개하면서, “텍스트만 뽑는 OCR”에서 “문서를 이해해 구조로 내보내는 OCR”로 한 단계 점프가 일어났습니다1. 특히 표·수식·다단 편집 같은 골치 아픈 PDF를 빠르게 구조화해, 개발 파이프라인에 바로 꽂을 수 있다는 점이 큽니다.

GLM-OCR이 ‘문서 이해 OCR’로 불리는 이유

기존 OCR은 문서의 모양을 납작하게 펴서 글자만 나열하는 경우가 많았습니다. 그래서 표는 표가 아닌 “흩어진 단어 더미”가 되고, 수식은 기호가 엉키며, 두 개 컬럼은 문장 순서가 뒤섞이기 쉽죠.

GLM-OCR은 여기서 목표가 다릅니다. 결과를 그냥 텍스트로 내놓지 않고, 사람이 읽기 좋은 시맨틱 마크다운이나 시스템이 쓰기 좋은 JSON, 수식은 LaTeX처럼 “형태가 살아있는 포맷”으로 생성하는 쪽에 초점이 있습니다. 즉, OCR 이후에 우리가 매번 만들던 후처리(정규식, 좌표 기반 표 복원, 문단 재정렬)를 모델이 상당 부분 대신해주는 구조입니다.

정확도·속도·가벼움: 숫자로 보는 성능 포인트

이 모델이 재미있는 지점은 “작은데 세다”에 있습니다. 파라미터가 약 0.9B 수준인데, 문서 이해 벤치마크인 OmniDocBench V1.5에서 94.62 점을 기록하며 상위권 성능을 내세웁니다2. 게다가 PDF 처리 속도도 약 1.86페이지/초로 알려져 있어, 대량 문서 파이프라인에서도 현실적인 처리량을 기대할 수 있습니다2.

물론 숫자만 보고 바로 프로덕션 투입은 금물입니다. 생성형 구조화 모델은 맥락으로 “그럴듯한 답”을 만들 수 있어서, 중요한 수치(계약서 금액, 재무제표 소수점)에서는 검증 레이어가 필요합니다. 실제로 생성형 OCR 특성상 환각 가능성을 경고하는 관점도 있습니다3. 그래서 실무에서는 “정확도 모드(Precision)” 같은 옵션을 쓰거나, 핵심 필드만 이중 검수하는 방식이 안전합니다3.

표·수식·서식까지 한 번에: 출력 포맷 전략이 핵심

GLM-OCR을 제대로 쓰려면, “무엇을 얻고 싶은지”부터 정해야 합니다. 사람이 읽고 편집할 문서화 목적이면 마크다운+LaTeX가 강점입니다. 반대로 자동화가 목적이면 JSON이 훨씬 유리합니다. 예를 들어 인보이스나 신분증처럼 필드가 정해진 문서는, JSON 스키마를 주고 그 틀에 맞춰 뽑게 하면 ETL 파이프라인이 깔끔해집니다(다만 스키마가 빡빡할수록 누락·형식 오류에 대비해야 합니다).

배포 선택지도 폭이 넓습니다. 빠르게 맛보기는 Ollama 같은 간편 실행이 좋고, 서비스로 운영한다면 vLLM/SGLang 같은 고성능 서빙이 어울립니다2. “로컬에서 돌릴 수 있다”는 건 비용뿐 아니라 보안에서도 의미가 큽니다. 법무·금융처럼 문서 반출이 어려운 팀은 특히요.

시사점

GLM-OCR의 핵심은 “OCR 결과를 후처리로 다듬는 시대”에서 “처음부터 구조화된 결과를 받는 시대”로의 이동입니다. 다만 생성형인 만큼, 전 문서 무검수 자동화보다는 ‘위험 구간(금액·날짜·조항 번호)’을 좁혀 검증하는 설계가 현실적입니다.

지금 GLM-OCR을 도입한다면, 첫 단계는 간단합니다. 우리 문서 20~50장만 샘플로 돌려서 표/수식/다단 레이아웃에서 후처리 비용이 얼마나 줄어드는지부터 재보세요. “정확도”보다 “후처리 시간 절감”에서 ROI가 먼저 보이는 경우가 많습니다.

참고

1GLM-OCR: Accurate × Fast × Comprehensive

2GLM-OCR: 0.9B Parameters Top OmniDocBench, Zhipu AI's Open-Source OCR Champion

GLM-OCR로 OCR 끝내기: 정확도·속도·구조화까지 한 번에

이 노트는 요약·비평·학습 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.