PDF·이미지 OCR 번역 파이프라인 짜는 법 — 로컬 모델 추천

오후 4시, 한 참가자가 방에 조심스러운 질문을 던졌다. OCR로 텍스트를 뽑아 번역까지 자동화하고 싶은데 비용을 줄일 방법이 없겠냐는 물음이었다.

"OCR 후 번역하는거… 그런건 안깎으시겠져..."

곧바로 다른 참가자가 실전 파이프라인을 풀어놓기 시작했다.

"ppLayout으로 스트럭쳐 잡아서 → crop → crop 대상만 ppOCRv5 (6인가) 이걸로 ocr 처리하시고 그걸로 bbox에 whitebox 씌우고 그 위치에 재작성"

문서 레이아웃을 먼저 분석해 영역을 자른 뒤 OCR로 텍스트만 뽑아내고, 원문 자리에 흰 박스를 덮어 번역문을 다시 앉히는 순서였다. 질문자가 700페이지 남짓 되는 분량이라며 문제를 꺼내자, 답변자는 상용 LLM에 통째로 넣는 대신 로컬 번역 모델을 쓰라고 권했다.

"요놈 경량화들 찾아보시면 됨여"

텐센트의 경량 번역 모델(huggingface.co/tencent/HY-MT1.5-1.8B) 링크가 공유됐고, 이 모델은 450MB까지 압축한 GGUF 버전까지 나와 있어 노트북급 환경에서도 굴릴 수 있다.

이 파이프라인이 눈에 띄는 이유는 700페이지 분량 문서를 다루는 실무 문제를, 상용 API에 통째로 밀어넣는 방식이 아니라 단계별로 쪼갠 로컬 조합으로 풀었다는 점이다. 레이아웃 분석(ppLayout)이 문서 구조를 먼저 파악하고, OCR(ppOCRv5)이 텍스트만 정밀하게 뽑아내며, 경량 번역 모델이 마지막 단계에서 언어를 옮기는 3단 구조는 하나의 범용 LLM에 모든 작업을 떠넘기는 접근과는 다르다. 각 단계를 목적에 맞는 별도 도구로 나눠 처리하면 문서 분량이 커져도 비용과 처리 시간을 예측 가능한 범위 안에 묶어둘 수 있다는 점에서, 이런 조합형 설계가 대량 문서 처리의 실전 해법으로 이 방에서 통용되고 있음을 시사한다.

이 대화에는 단 3명이 참여했지만 메시지는 70건에 달했다. 참여 인원 대비 대화량이 두드러진다는 점은, 질문 하나에서 시작된 문답이 표면적인 답변에 그치지 않고 구체적인 도구명·URL·모델 크기까지 오간 심층 논의로 이어졌다는 뜻으로 읽힌다. 이 문답을 지켜보던 참가자는 답변자를 찌르면 늘 팁이 나온다는 취지로 감탄했는데, 이런 반응 역시 실전 노하우가 방 안에서 반복적으로 오간다는 정황을 뒷받침한다.

문서 분량이 크고 비용 부담이 큰 작업일수록 로컬 모델과 파이프라인 설계로 문제를 우회하려는 시도가 이 커뮤니티의 기본값에 가까워지고 있다는 인상을 준다. 질문 하나에서 시작된 대화가 곧바로 재현 가능한 절차로 이어졌다는 흐름은, 비슷한 문제를 마주한 다른 참가자들에게도 참고가 될 만하다.