사내 유휴 맥 30대가 밤마다 돌아간다 — 4만3천 권 PDF·HWP를 마크다운으로

낮 2시 13분, 에르메스단에 한 참여자가 자신이 만든 자동화 파이프라인을 소개하며 대화가 시작됐다.

"PDF OCR 자동화 만들었는데 야간에 30대 정도 안쓰는 맥에 연결해서 밤새 작업하도록 시켰습니다."

사내에서 밤마다 놀고 있는 맥 30여 대를 그대로 컴퓨팅 자원으로 돌린다는 발상이었다. 직원들 컴퓨터에 코드 한 줄을 심어두고, 메뉴바의 "퇴근" 버튼을 누르면 퇴근 기록과 동시에 PDF 변환 작업이 자동으로 시작되도록 만들었다는 설명이 이어졌다. 처리 대상은 4만3천 권 규모다.

"4만3천권 해야하는데 만약 계산대로라면 대략 한달 걸리네요"

대시보드로 각 맥(워커)의 작업 현황을 확인하며 중복 파일을 걸러내는 구조까지 갖췄다는 설명도 뒤따랐다. 지원 범위도 구체적으로 공개됐다. PDF·HWP·DOC·PPT를 마크다운으로 바꾸는데, 표·그림·도표·지도까지 캡처해 마크다운 파일과 연결하고 45개 국어를 지원한다는 것이다. 정확도는 95% 이상이라고 밝혔고, 처리 속도는 M1 기준 권당 20분이라고 전했다. 다만 hwp 2.0 버전 문서는 아직 지원하지 못해 건너뛴다는 한계도 함께 언급했다.

이 자리에서 OCR 품질을 둘러싼 짧은 논쟁도 벌어졌다. 다른 참여자가 자체 보유한 데이터 규모를 언급하며 범용 OCR의 오류가 많다고 지적하자, 원 개발자는 문제의 근본 원인을 분명히 했다.

"PDF 오류의 근본은 그냥 쓰레기 OCR 때문입니다. AI 는 잘못없음"

그는 OCR은 전용 OCR 모델이 맡아야 하며, LLM에게 그 역할까지 맡기면 결국 토큰만 낭비한다고 짚었다. 반면 이미지 업스케일링과 보정까지 자체 파이프라인에 포함시켜, 결과물이 출판사가 만든 전자책 수준으로 나온다고 자신했다. 이어진 대화에서 한 참여자는 도형·수식이 섞인 문서 처리의 어려움을 직접 겪은 경험을 전했다.

"수학 문제집이라.. 도형이나 그래프 부분 정확히 크롭하려 해도 잘 안되길래 그냥 luna max한테 latex 문법까지 작성하라 시켰는데 크롭까지 잘 되신다니 부럽네요 어떻게 하신건지.."

이 대화는 두 가지를 동시에 보여준다. 하나는 사내 유휴 하드웨어를 재조직하기만 해도 별도 서버 투자 없이 대규모 문서 변환 인프라를 구축할 수 있다는 점이고, 다른 하나는 OCR 정확도가 결국 "만능 LLM"이 아니라 문제에 맞는 전용 모델 선택에서 갈린다는 점이다. 도형·수식이 섞인 문서에서 크롭 정확도가 여전히 난제로 남아 있다는 사실은, 대량 문서 자동화가 일반 텍스트를 넘어 구조화된 시각 정보까지 다루려면 아직 세밀한 튜닝이 필요하다는 것을 시사한다.