흐린 사진 문서를 읽는 OCR 모델 고르기

28일 밤, 에이전트코리아 방에서 한 참가자가 대화 사이에 이렇게 말을 꺼냈다.

그 오늘 OCR 뭐 하나 발견했는데

OCR은 사진이나 스캔 속 글자를 텍스트로 읽어 내는 기술이다. 29일에 OCR 모델을 직접 학습시키고 있다고 밝히게 되는 참가자가 28일 밤 DeepseekOCR를 계승한 UnlimitedOCR 계열을 언급하며 약점을 하나 적었다. 이하 이 참가자를 모델 개발 참가자라 부른다.

이 계열 특징 : 1 ~ 2% 확률로 반복 터지는 경우가 있음

모델 개발 참가자는 이어서 gemini 2.5가 4 ~ 5%로 터지던 것에 비하면 낮은 편이라고 덧붙였고, 데이터랩 chandra는 표를 나름 잘한다는 말도 했다. 또 다른 참가자는 "써봄... 좋음"이라고 적은 뒤 "하지만 다시 패들로"라고 이었다. 무엇을 써 봤다는 말인지는 앞뒤에 대상 표시가 없어 확인되지 않는다.

29일, 흐리고 기울어진 사진 문서를 읽을 모델

29일 오전에는 질문한 개발자가 오픈소스 OCR 후보를 물었다. 글자뿐 아니라 BBOX, 곧 글자 위치를 네모로 표시한 좌표까지 나와야 하고, 업체마다 양식이 다르며, 사람이 사진이나 스캔으로 보내는 문서를 다뤄야 한다는 조건이었다.

오픈소스 OCR 모델 중에 좌표도 나오고 양식이 업체마다 조금씩 다르고, 그 사진을 사람이 직접 사진으로 찍거나 스캔해서 보내는 경우

낮에 모델 개발 참가자는 OCR 모델이 잘하는 순서를 올렸다. 순서표의 내용은 대화 글로는 남아 있지 않다. 같은 참가자는 의외로 Qwen이 잘한다며 GPU에 여유가 있으면 OCR에 써도 되겠다고 했다.

의외로 Qwen 3.8 27B FP8이 잘합니다

그러면서 모델을 작게 줄여 쓰는 양자화 수준을 두고 IQ3까지는 괜찮고 IQ2부터는 많이 틀린다는 경험을 팁으로 남겼다.

오후 1시를 넘기며 질문한 개발자가 구체적인 조건을 풀어 놓았다. 하루 10만 장 정도를 빠르게 처리해야 하고, 가벼운 모델 중에서는 Paddle을 도메인 문서에 맞게 파인튜닝하는 쪽이 맞는지 물었다. 문서는 잉크가 부족해 선이 흐린 출력물, 그것을 사진으로 찍은 것, 그 사진을 다시 출력해 스캔한 것까지 있었다고 했다.

출력한 문서를 사진으로 찍은걸 출력해서 또 스캔해서 올리는 경우(심하게 깨짐)

모델 개발 참가자는 Paddle은 파인튜닝이 힘든 편이어서 그대로 써도 된다고 했고, GPU 사정에 따른 기준을 한 줄로 내놓았다.

GPU가 작다 : Paddle 24B는 된다 : Qwen

질문한 개발자는 Paddle도 해 봤는데 성공률이 떨어져 다른 대안을 찾고 있었다고 답했다.

YOLO 권유와 폐쇄망이라는 조건

질문과 답이 오가는 중에 또 다른 참가자가 끼어들어 어떤 모델로 만드는지, 학습 자료는 무엇인지를 캐물었다. 이 참가자는 처음부터 만든다면 트랜스포머 모델이 좋고 가성비로는 YOLO라고 권했다. YOLO는 이미지 속 물체의 위치를 찾는 데 쓰는 모델 계열이다.

프롬스크래치 하실거면 트랜스포머 모델이 개쩔고 가성비는 YOLO ㄱㄱ

모델 개발 참가자는 같은 길을 이미 걸어 봤다는 투로 받았다. 한글 문자 인식을 YOLO로 하려면 문제가 생기고, 문자 사전이 커질수록 결과가 기괴해진다고 설명했으며 그렇게 몇 개월을 날렸다고 했다.

yolo는 한글 문자 인식에서 하려면 사리 생겨요

YOLO를 권한 참가자는 LLM API로 하면 안 되느냐고도 물었다. 질문한 개발자가 보안이 중요하냐는 물음에 그렇다고 하고 폐쇄망이라고 밝히자, YOLO를 권한 참가자는 그러면 해야 한다고 받았다. 질문한 개발자는 실제 고객 문서라 개인 정보가 있어 예시 한 장도 올릴 수 없다고 했다.

사진을 찍는 사람이 가장 큰 변수

질문한 개발자가 꼽은 가장 큰 문제는 모델이 아니라 올라오는 사진이었다.

그림자지고

40도 기울여서찍고

다른 참가자는 이 상황에 공감하며 사진으로 올라오는 원본이 문제라고 적었다.

핸드폰으로 찍어 올리는데 아주 환장하죠 소스가 ㅎㅎ

이어 이 참가자는 OCR 뒤처리를 일반화하는 대신 서식의 문법을 익히게 하려는 곳도 있다고 했다. 같은 참가자는 넘겨짚어야 정확도가 오르는데 넘겨짚지 말라는 요구가 붙는 경우를 짚었다.

넘겨짚어야 확률적으로 좋아지는데, 넘겨짚으면 안된다고 클라이언트가 요구하면

모델 개발 참가자는 이미지를 이해하는 언어모델, 곧 VLM의 장단을 한 문장으로 정리했다.

VLM 장점 : 알아서 맞는것 같은걸로 채운다 VLM 단점 : 그래서 틀린다

오후에는 다른 참가자가 OCR을 안 해도 되게 데이터를 주면 좋겠다고 했고, 모델 개발 참가자는 모든 서류가 MD나 xlsx면 좋겠다는 생각을 매번 한다고 했다. 다만 XML은 가장 무섭다며 토큰이 많이 든다고 덧붙였다.

29일 밤, 오래된 서류를 직접 돌려 본 이야기

29일 밤에는 또 다른 참가자가 오래된 서류 사진을 올렸다. 이 참가자는 서류 가운데 일부만 올린 것이라며 전체는 훨씬 심하다고 했다. 모델 개발 참가자는 내부 모델로 돌려 보겠다고 했고, 쓰던 H200 장비를 멈추고 직접 돌려 보는 중이라고 밝혔다.

아 궁금한건 못참지...

모델 개발 참가자가 말한 어려움은 몇 가지였다. 번체자는 데이터가 거의 없고, 예전 스캔 문서는 늘 상상을 넘는다는 것이다. 정답을 얻으려면 내부에서 특화시킨 모델 두세 개를 한꺼번에 쓰고 큰 모델로도 점검해야 한다고 했다.

내부 특화 다르게 분화시켜놓은거 2 ~ 3개를 한번에 쓰고

결과는 일부만 맞았다. 모델 개발 참가자는 지금까지 본 가장 어려운 파일 열 개 안에 든다고 했고, 올라온 파일 세 개 중 하나는 없다를 있다로 읽었다고 밝혔다.

파일 3개 중에 1개는 없다를 있다라고해서

모델 개발 참가자는 취소선까지 읽어 내는 일 자체가 매우 어렵다고 했다. 볼드 표기를 결과에 넣을지 말지는 오래된 논쟁거리라고 따로 덧붙였다.

내가 아는 모델중에 OCR에서 취소선까지 가져오는 것만 해도 타노스 두번스냅인데…

긴 문서를 한 번에 읽는 계열의 장단

같은 밤 한 참가자가 UnlimitedOCR 2 계열이 별로인지 물었다. 모델 개발 참가자는 전작이 더 낫다고 했고, 페이지를 이어 읽는 긴 문서 처리가 강점이며 속도는 빠르지만 폭주가 심한 것이 단점이라고 했다. 여러 영수증을 PDF 하나로 묶어 보내면 성능이 안 나오느냐는 물음에는 그렇다고 답했다. 질문한 참가자는 수백 쪽 PDF의 한계를 자기 경험으로 이렇게 말했다.

수백페이지 pdf 특히 좌우 다단의 경우에는 어떤 pdf to md 로더를 써도 완벽한건 없더라고요

밤이 깊어 한 참가자가 오답노트 사진을 올리자 모델 개발 참가자는 "음 이건 OCR보다 VLM이네요"라고 했다. 글자를 읽는 것과 뜻을 맞춰 읽는 것은 다른 일이라는 이 대화의 흐름이 거기서 한 번 더 드러났다.

이 대화가 가리키는 곳

이틀치 대화를 겹쳐 보면 모델 이름은 계속 바뀌었지만 걸림돌은 한곳에 모였다. 양식이 일정하지 않고, 사진은 기울고 흐리며, 오래된 서류는 글자 자체가 낯설었다. 모델 개발 참가자의 조언도 어느 모델이 최고라는 말보다 GPU 크기와 문서 상태에 따라 고르라는 쪽에 가까웠다.

이 흐름은 현장에서 OCR의 성패가 모델 성능표만으로 정해지지 않는다는 점을 시사한다. 질문한 개발자의 폐쇄망 조건처럼 쓸 수 있는 도구 자체가 좁아지는 경우도 있었다. 다만 모델끼리 같은 문서로 정확도를 나란히 잰 수치는 대화에 없었고, 모델 순위 자료도 글로 옮겨지지 않아 어느 쪽이 낫다고 단정하기는 어렵다.