AI가 논문을 ‘제대로’ 읽게 만드는 법 : DBpia OCR 이야기 누리미디어 테크블로그
AI가 논문을 ‘제대로’ 읽게 만드는 법 : DBpia OCR 이야기
누리미디어 테크블로그
about 1
AI가 논문을 ‘제대로’ 읽게 만드는 법
: DBpia OCR 이야기
about 1
안녕하세요. 올해 누리미디어에 합류하게 된 AI 엔지니어입니다.
누리미디어는 대한민국 논문 1등 플랫폼 DBpia로 잘 알려져 있는데요. AI 시대가 도래한 만큼 누리미디어 역시 AI로 새로운 도약을 준비하고 있습니다. DBpia에 있는 약 500만 건의 학술 콘텐츠를 바탕으로 AI 뷰어, AI 아이디어, AI 검색, 그리고 최근에는 AI Agent(beta)까지, 지난 1년간 다양한 논문 기반 AI 서비스를 출시했으며, 많은 초·중·고 학생부터 대학생, 대학원생, 교수님들까지 폭넓게 사용하고 계십니다.
이 글에서는 논문 기반 AI 서비스의 초석인 OCR 이야기를 해보려 합니다.
제목없음
제목없음
논문은 왜 PDF일까
논문은 어디에서 열어도 레이아웃/폰트가 깨지지 않고, 인쇄에도 적합한 PDF 파일 형태로 제출/유통/열람되는 것이 표준이 되었습니다.
PDF 파일은 크게 두 종류로 구분됩니다.
텍스트 정보가 살아있는 PDF
페이지 내 텍스트 정보가 살아있어 드래그 시 복사/붙여넣기 가능
각 글자, 문단에 대한 좌표, 폰트, 문단 구조 같은 메타 정보가 포함되어 있음
텍스트 정보가 없거나 손상된 PDF (이미지 PDF)
스캔된 이미지 위에 아무런 텍스트 정보가 없거나, 인코딩 정보가 손상되어 복사/붙여넣기 시 이상한 문자열이 복사됨
이 세상의 모든 논문이 텍스트 PDF였다면 얼마나 좋았을까요? (그럼 PyMuPDF와 같은 라이브러리로 손쉽게 데이터를 추출할 수 있었을 텐데..) DBpia는 아주 오래전부터 다양한 발행 기관의 논문을 서비스해 왔기에 손 글씨로 된 논문, 스캔된 논문 등 이미지 PDF의 비중이 30% 정도로 꽤 높은 편입니다. 이미지 PDF라고 서비스에서 제외할 순 없겠죠? 지금이 바로 AI의 힘이 필요한 순간입니다.
제목없음
제목없음
OCR이란?
OCR은 Optical Character Recognition의 약자로, 이미지 안에 들어 있는 글자를 찾아서 텍스트 데이터로 변환하는 기술입니다.
문서의 경우 단순한 글자 인식을 넘어, 페이지의 구조를 파악하고, 어떠한 순서로 배치해야 하는지, 각 항목의 위치 정보까지 추출하는 것을 목표로 하는 Document AI 분야도 함께 활발히 연구되었습니다.
특히 최근에는 이미지 입력이 가능한 Vision Language Model(VLM)이 등장하면서, VLM 기반의 OCR 모델들이 공개되고 있습니다.
기존에는 OCR 모델이 특정 언어만 지원하는 경우가 많아 한국어 성능이 처참하거나, 한국어 전용 모델이 필요했는데요. 다양한 언어를 통해 학습된 VLM 기반 OCR 모델들은 한국어는 물론 수십 개의 언어를 지원합니다. 이를 통해 한국어+영어, 한국어+한자와 같이 두 개 이상의 언어가 혼재된 문서에서도 높은 품질의 OCR 결과를 얻을 수 있게 되었습니다.
제목없음
제목없음
누리미디어에 OCR이 필요한 이유
사실 논문의 제목, 저자, 초록(Abstract)과 같은 메타데이터만으로도 RAG와 같은 AI 서비스를 구현하는 것은 가능합니다. 하지만 DBpia가 지향하는 방향은 조금 다릅니다.
논문이란 저자가 오랜 시간 심혈을 기울여 고민하고, 실험하고, 증명해 낸 결과물입니다. 논문의 진정한 가치는 메타데이터가 아니라, 본문 전체(Full-text)에 있습니다. AI가 논문의 실제 내용 깊숙한 곳까지 검색하고 참조하여 사용자에게 답변할 수 있어야 진정한 논문 기반의 AI 서비스라고 할 수 있다고 생각합니다. 더 나아가 AI가 답변에 활용한 부분을 PDF 위에 보여준다면 AI의 환각(Hallucination)을 검증함과 동시에 답변의 신뢰도를 높일 수 있을 겁니다.
Gemini에 PDF를 업로드하고 대화를 해보면 답변에 활용한 부분의 위치를 우측 PDF 뷰어 위에 하이라이팅 해주는 것을 볼 수 있는데요.
이러한 기능을 위해선 단순히 PDF를 Markdown 형식으로 추출하는 것이 아니라, PDF에 담긴 각 내용들이 PDF 몇 페이지, 어느 좌표에 위치하는지까지 정확히 파악하고 있어야 합니다.
제목없음
제목없음
오픈소스 OCR 모델들
2025년 10월, 여러 기업이 자신들의 기술력을 자랑하듯 경쟁적으로 OCR 모델들을 오픈소스로 공개했습니다.
실제로 이때 Hugging Face에서 Trending 모델 TOP10 중 무려 5개 모델이 OCR 모델이었습니다…!
그만큼 많은 사람들이 OCR에 관심이 많다는 뜻이겠죠.
저희는 아래와 같은 기준으로 모델들을 추려 테스트를 진행했습니다.
상업적으로 이용할 수 있고
한국어를 지원하며
각 item들의 경계 상자(bounding box, bbox) 정보와 함께 json 출력을 지원하는 OCR 모델
후보 1️⃣ DeepSeek-OCR
GRPO로 학습된 딥시크로 화제가 됐던 DeepSeek AI에서 공개한 모델로, 시각적 압축(Optical Compression)이라는 개념을 도입한 VLM 기반의 모델입니다. 이미지를 적은 수의 비전 토큰으로 압축하여 처리하기 때문에 속도가 매우 빠른 편입니다. 레이아웃 분석 모듈이 별도로 존재하지 않고 VLM이 바로 json 형태로 출력을 생성하는 구조입니다.
모델 링크: DeepSeek-OCR
후보 2️⃣ PaddleOCR-VL
Baidu의 PaddlePaddle 팀이 새롭게 공개한 VLM 기반의 OCR 모델로, 다른 OCR 모델들에 비해 압도적으로 가벼운 크기임에도 OCR 벤치마크에서 최고 성능을 달성했습니다. 별도의 레이아웃 분석 모듈 PP-DocLayoutV2가 페이지 내 객체들의 이미지를 batch로 전송하면 VLM이 각 이미지에 대해 OCR을 수행하는 구조입니다.
모델 링크: PaddleOCR-VL
후보 3️⃣ Dolphin1.5 + olmOCR-2-7B-1025-FP8 파이프라인
olmOCR-2-7B-1025-FP8은 AI2라는 기업에서 개발한 OCR 모델로, 개인적으로 체감하기에 가장 성능이 좋다고 느꼈던 모델입니다. 하지만 아쉽게도 Markdown 출력만을 지원했습니다. 이에 bytedance에서 개발한 Dolphin 1.5 모델로 레이아웃 분석만을 수행하고, olmOCR-2이 페이지 내 객체들을 디코딩하여 OCR을 수행하도록 하는 파이프라인을 구현했습니다.
모델 링크: Dolphin1.5
모델 링크: olmOCR-2-7B-1025-FP8
테스트 결과
DeepSeek-OCR은 타 모델 대비 글자 인식 정확도가 떨어졌으며, 한글을 한자로 출력하거나 띄어쓰기가 자연스럽지 못한 문제를 발견했습니다. PaddleOCR-VL은 모델 크기에 비해 성능이 매우 준수했고, Dolphin1.5 + olmOCR-2-7B-1025-FP8 역시 매우 정확한 OCR 성능을 보였습니다.
테스트 결과를 정리해 보면 다음과 같습니다.
테스트 결과 (*속도는 H100 1장 기준)
제목없음
제목없음
PaddleOCR-VL을 선택한 이유
아무래도 더 큰 모델이 좋은 성능을 보이겠지만, 약 500만 건에 달하는 논문에 대해 OCR을 수행해야 했기에 처리 속도를 고려해야 했습니다. 그래서 약 1B 사이즈로, 속도 대비 성능이 가장 우수한 PaddleOCR-VL로 최종 모델을 선정했습니다.
DBpia에서 보유한 PDF 파일의 페이지 수 기준, 3개월 정도면 전체 논문 OCR을 완료할 수 있는 일정이 나왔습니다.
(11월 7일 이후로 PaddleOCR-VL은 flash-attn과 vLLM 서빙을 모두 지원합니다.)
PaddleOCR-VL의 개행 문자 생성 문제
그런데 한 가지 문제를 발견했습니다.
위와 같이 일부 문단에서 한 문단을 자연스럽게 연결하지 못하고 각 line을 생성한 뒤, 매 line마다 줄 바꿈을 해버리는 현상을 발견했습니다. 각 줄의 간격이 멀다고 판단했는지 개행 문자 토큰을 생성한 다음, 그다음 line의 첫 토큰을 생성하는 이슈가 있었습니다.
PaddleOCR-VL은 한 문단에 대한 전체 이미지 조각을 입력받기 때문에 한 문단 내에서 개행 문자를 생성할 일은 없습니다.
따라서 객체의 label이 한 문단(text)인 경우, 그 문단 내에서 의도적으로 개행 문자 토큰 생성을 억제한다면, 자연스럽게 그다음으로 확률이 높은 토큰을 출력하도록 유도할 수 있습니다.
tokenizer.json · PaddlePaddle/PaddleOCR-VL at main 를 열어서 개행 문자 토큰의 id를 확인해 봅시다.
아스키(ASCII) 코드상에서 줄 바꿈 제어 문자인 의 토큰 id가 23번이네요.
그럼, 이제 VLM이 매 토큰을 생성할 때 23번 토큰을 생성하지 못하도록 억제해 봅시다.
이를 위해 vllm의 Logits Processors라는 기능을 활용할 겁니다. PaddleOCR-VL의 파이프라인에서는 vllm으로 VLM을 서빙하여 OCR을 수행하는데, Logits Processors 기능을 활용하면 VLM의 logit 값을 조정할 수 있습니다.
OpenAI API 형태를 통해 요청을 보낼 때 logit_bias 파라미터로 {토큰ID: 바이어스값} 와 같이 딕셔너리 형태로 값을 전달해 주면 됩니다.
kwargs["logit_bias"] = {23: -100}와 같이 전달하게 되면 23번 토큰의 logit 값에 -100이라는 값이 더해지게 되어 개행 문자 토큰의 확률은 거의 0으로 수렴합니다.
그럼, 아래 그림과 같이 그다음으로 확률이 높은 토큰이 채택되면서 한 문단이 자연스럽게 연결되게 됩니다.
출처: Gemini의 ‘동적뷰’ 기능으로 구현한 페이지 (토큰 확률 실제값 아님)
실제로 개행 토큰 억제를 적용하고 나니 한 문단을 매끄럽게 생성해 내는 것을 확인했습니다.
원본 PaddleOCR-VL 결과
개행 문자 토큰 생성 억제 수정 후 결과
제목없음
제목없음
GPU는 열일 중...
이제 남은 건 약 500만 건의 논문을 처리하는 일뿐입니다.
지금 누리미디어의 서버실에서는 GPU가 열심히 열과 소음을 내며 OCR을 수행 중입니다.
OCR을 시작으로, 본문 전체를 읽고 이해하는 진정한 원문 기반 AI 서비스로 도약하려 합니다.
앞으로 한층 더 업그레이드될 AI 서비스들을 기대해 주세요!!
