형사 증거기록 OCR, 어떤 모델로 할까
형사 사건을 맡으면 증거기록을 받는다. 수십, 수백 페이지짜리 스캔본 PDF다. 이걸 읽고 사실관계를 파악하고 변론 방향을 잡는 것이 일의 출발점인데, 종이를 통째로 다시 타이핑할 수는 없으니 OCR이 필요하다.
OCR 자체는 새로운 기술이 아니다. 시중에 좋은 상용 서비스도 많다. 그런데 나는 그것들을 쓸 수 없다. 증거기록에는 의뢰인과 피해자의 주민등록번호, 주소, 진술이 그대로 들어 있다. 이걸 외부 OCR 서버에 올린다는 것은 의뢰인 정보를 제3자에게 넘긴다는 뜻이다. 이 세팅기를 시작한 이유 자체가 데이터 통제권이었으니, OCR도 ATOM 안에서, 데이터가 한 바이트도 밖으로 나가지 않는 방식으로 해야 한다.
그래서 이번 화의 질문은 하나다. 로컬에서, 한글 스캔 증거기록을 읽을 수 있는 모델은 무엇인가.
전통 OCR과 VLM의 갈림길
로컬 OCR의 선택지는 크게 두 갈래다.
하나는 전통 OCR 엔진이다. Tesseract, PaddleOCR 같은 것들이다. 글자가 있는 영역을 찾고, 그 글자를 읽는 작업을 전용으로 하는 도구다. 빠르고 가볍다. 중요한 특징이 하나 있는데, 글자를 못 읽으면 못 읽은 티가 난다. 깨진 글자나 빈칸을 내놓는다.
다른 하나는 **VLM(비전-언어 모델)**이다. 이미지를 통째로 이해하는 모델이라, “이 문서를 읽어서 마크다운으로 정리해줘”, “도장은 빼고 본문만” 같은 자연어 지시가 먹힌다. 단순히 글자를 읽는 것을 넘어 문서의 구조를 파악한다.
내 증거기록은 스캔본이고, 도장·표·손글씨가 섞여 있고, 텍스트뿐 아니라 표 구조도 살리고 싶었다. 이 조건이면 전통 엔진은 약하다. 도장이 글자 위에 겹치거나 레이아웃이 복잡하면 전통 엔진은 무너진다. 그래서 VLM 쪽으로 기울었다.
그런데 VLM에는 치명적인 약점이 있다. 환각이다. 전통 엔진은 못 읽으면 깨진 글자를 내놓지만, VLM은 글자를 생성하는 모델이라 안 보이는 부분을 만나면 문맥상 그럴듯한 글자로 메워버린다. 그것도 깨진 글자가 아니라 멀쩡하고 자연스러운 문장으로. 형사기록에서 날짜 하루, 금액 한 자리가 틀리면 사건이 달라진다. 이 환각 위험은 작업 내내 머리에 두기로 했다.
한국 OCR 강자들을 뒤졌더니
한글이 핵심이니 한국 기업이 만든 모델부터 찾았다. 업스테이지, 네이버, 카카오를 차례로 봤다.
업스테이지의 Document AI는 OCR로 평이 매우 좋다. 기울어진 각도나 음영이 있는 스캔도 잘 읽는다고 한다. 그런데 이건 API 서비스다. 문서를 업스테이지 서버로 보내야 한다. 데이터 통제권과 정면으로 충돌하니 탈락이다.
네이버의 CLOVA OCR도 강력하지만 역시 클라우드 API다. 같은 이유로 탈락.
카카오 쪽도 봤다. 카카오브레인이 만든 Pororo라는 도구에 OCR 기능이 있긴 한데, 자료가 대부분 2021년 무렵이다. AI 모델 기준으로 2021년이면 사실상 화석이고, 유지보수도 멈춰 ARM64 환경에 설치하는 것 자체가 고생길일 가능성이 높다. 카카오의 현재 주력인 Kanana는 멀티모달이 나왔다지만 OCR로 검증된 트랙이 아니다.
여기서 의미 있는 사실 하나가 드러났다. 한국 OCR 강자들이 죄다 클라우드 API거나 옛 모델이다. 데이터 통제권을 전제로 깔면 선택지가 확 좁아진다. 성능 좋은 건 다 데이터를 밖으로 보내야 하고, 로컬로 받을 수 있는 본격 한국어 OCR 모델은 손에 꼽는다. 로컬 후보로 남은 한국어 특화 모델은 NC AI(엔씨소프트)의 VARCO-VISION 2.0 정도였다.
결국 비교 후보는 글로벌 범용 VLM인 Qwen3-VL과 한국어 특화인 VARCO-VISION으로 좁혀졌다. 그런데 그 전에, 전통 엔진을 기준선으로 하나 넣을지 고민하다가 벽을 만났다.
PaddleOCR을 고르려다 만난 벽
전통 엔진은 “환각 없는 기준선” 역할로 가치가 있다. VLM이 지어낸 글자를 잡아내려면, 글자를 지어내지 않는 정직한 엔진의 출력과 대조해보는 것이 유용하기 때문이다. 그래서 PaddleOCR을 후보로 넣으려 했다.
습관대로 먼저 선례를 찾아봤다. 나와 같은 기계 — DGX Spark, GB10 칩, ARM64 — 에서 PaddleOCR을 돌린 사람이 있는지.
있었다. 그것도 막혀 있었다. PaddleOCR 토론에서 한 사용자가 “DGX Spark에 GB10 GPU를 가진 ARM64 머신인데, 작동하는 빌드를 찾고 있다”고 적어둔 것을 발견했다. 나와 똑같은 처지였고, 그 사람도 GPU로 못 올려 헤매고 있었다. 원인은 ARM64용 GPU 지원 패키지가 공식 배포되지 않아서, pip로 설치하면 CPU로만 돈다는 것이었다. PaddleOCR을 쓰는 이유가 “빠른 기준선”인데, CPU로만 돌면 그 속도 장점이 사라진다.
더 결정적인 선례가 NVIDIA 개발자 포럼에 있었다. “PaddleOCR anyone?”이라는 글이었는데, 작성자가 자기소개를 이렇게 했다. 중부유럽의 작은 법률 사무소에서 일하는, 개발자도 IT 배경도 없는 평범한 사람. DGX Spark를 한 달쯤 썼고, 일상 업무에서 나온 질문이 OCR이라고 했다.
같은 기계, 같은 법률 사무소, 같은 OCR 고민. 읽는데 묘하게 공감이 갔다. 나도 개발자가 아니고, 사무실 일을 편하게 하려고 이 기계를 들였고, 결국 증거기록 OCR이라는 같은 지점에 도달했다. 다른 나라에서 같은 장비로 같은 고민을 하는 사람이 있다는 것이 — 동지를 만난 것 같아 좋았다.
그 사람의 결론은 명확했다. PaddleOCR이 데모로는 훌륭하지만 DGX에서 도저히 실행시킬 수 없었다는 것. 그래서 결국 우회한 방법이 Ollama에 올린 VLM으로 OCR을 돌리는 것이었다. PDF를 페이지로 쪼개 각 페이지를 Ollama 모델로 보내 텍스트를 뽑는 방식. 내가 지금 검토하던 바로 그 방향이었다.
같은 하드웨어를 쓰는 사람이 먼저 부딪혀, PaddleOCR은 막힌 길이고 VLM이 현실적인 우회로라는 것을 보여준 셈이다. 성능만 보고 PaddleOCR을 골랐다면 설치에서 시간을 통째로 날렸을 것이다.
MinerU라는 대안
그 포럼 글의 답글에서 또 하나를 건졌다. 여러 사용자가 PaddleOCR 대신 MinerU라는 도구를 거론하고 있었다. PDF를 마크다운으로 변환하는 도구인데, 같은 DGX Spark에서 실제로 잘 돌았다는 후기가 복수로 있었다. “안 된다”가 아니라 “됐다”는 후기라 무게가 달랐다.
MinerU를 살펴보니 한 가지 알아둘 구조가 있었다. MinerU 자체가 OCR 모델이 아니라, OCR 엔진을 안에 끼워 돌리는 파이프라인이라는 점이다. 옛 버전은 내부에서 PaddleOCR을 썼는데, 그러면 우리가 피하려던 그 설치 문제를 그대로 물려받는다. 다행히 최신 MinerU는 자체 VLM 백엔드를 갖췄다. 한국어도 지원한다.
그래서 비교군에 MinerU도 후보로 남겨뒀다. 다만 “전통 엔진 기준선”으로 넣을지 “또 하나의 VLM”으로 넣을지는 백엔드 설정에 달려 있어, 역할은 다음에 정하기로 했다.
파라미터가 크면 OCR도 잘하나
비교군을 짜면서 자연스럽게 든 의문이 있다. 모델 파라미터가 크면 OCR도 더 잘하는가. 보통 큰 모델이 좋다고들 하니까.
여기에는 미리 의심을 걸어둘 이유가 있었다. 앞서 본 DGX Spark 사용자들의 후기 중에, 큰 모델이 작은 모델보다 구조 판단이나 일관성에서 오히려 나빴다는 실측이 있었다. OCR의 본질은 복잡한 추론이 아니라 “이 픽셀이 무슨 글자냐”를 알아보는 지각에 가깝다. 지각 능력은 파라미터 수보다 입력 이미지 해상도나 모델이 OCR에 특화됐는지에 더 좌우될 수 있다.
그래서 비교군에 같은 모델의 두 체급(8B, 32B)을 넣어, “체급을 키우면 실제로 나아지는가”를 직접 확인해보기로 했다. 일단은 8B로도 잘되는지 확인해보기로.
오늘의 정리
- 로컬·한국어·스캔본 OCR이라는 세 조건을 걸면 선택지가 확 좁아진다. 한국 OCR 강자(업스테이지·네이버·카카오)는 클라우드 API거나 옛 모델이라, 데이터 통제권을 지키려면 로컬 오픈모델로 가야 한다.
- ARM64라는 환경이 모델 선택을 제약한다. PaddleOCR은 같은 DGX Spark 사용자 여러 명이 GPU 설치에 막힌 선례가 있어, 비교군에서 뺐다. 엔비디아에서 x86환경 모델을 가을에 출시한다는데 스물스물 사고 싶은 마음이 든다.
- 비교군: 글로벌 범용 VLM(Qwen3-VL, 8B·32B 두 체급), 한국어 특화(VARCO-VISION 2.0), 문서 파싱 특화(MinerU). 파라미터 크기가 OCR에 실제로 의미가 있는지도 함께 보기로 했다.
모델을 받기 전에 후보를 좁히는 것으로 한 화가 갔다. 다음 화에서는 실제로 스캔본을 페이지 이미지로 쪼개고, 첫 모델에 한 페이지를 읽혀본다. 그 첫 시도에서 환각을 정면으로 마주하게 된다.