한국딥러닝이 글로벌 문서 AI 벤치마크에서 또 한 번 1위를 기록했다.
지난 3월, 한국딥러닝의 KDL Frontier는 OCRBench v2 영어 부문에서 제미나이, GPT, 엔비디아 등 글로벌 빅테크 모델을 앞서며 전체 1위를 차지했다. 그리고 몇 달 뒤, LlamaIndex가 주관하는 문서 파싱 벤치마크 ParseBench에서도 VLM 부문 종합 1위에 올랐다.
첫 번째 성과가 한국딥러닝의 OCR 기술력을 보여줬다면, 이번 성과는 문서 파싱 기술력을 보여준다.
이번에 평가된 모델은 KDL-Frontier-Parser-nano다. 12억 개, 즉 1.2B 파라미터 규모의 초경량 모델이다. 기존 오픈소스 1위 모델보다 약 30분의 1 크기이면서도 Google Gemini 3 Flash, OpenAI GPT-5.5 등 글로벌 상용 VLM을 앞섰다.
모델이 커질수록 성능도 좋아진다는 흐름 속에서, 한국딥러닝은 작은 모델로 더 높은 문서 파싱 성능을 입증했다.
KDL-Frontier-Parser-nano 개발에 참여한 AI 개발자 지니에게 물었다. 작은 모델이 어떻게 복잡한 기업 문서를 구조화할 수 있었는지, 문서 파싱에서 레이아웃 이해가 왜 중요한지, 그리고 Parser가 RAG와 AI 에이전트의 성능에 어떤 영향을 주는지 들어봤다.
“큰 모델이 아니어도, 문서를 제대로 보면 성능은 나옵니다.”
Q. 먼저 ParseBench VLM 부문 1위 달성 소감이 궁금합니다.
기뻤습니다. 글로벌 벤치마크에서 1위를 했다는 건 개발자로서 분명 의미 있는 일이니까요. 특히 Google Gemini나 OpenAI GPT-5.5 같은 상용 VLM 모델보다 높은 점수를 받았다는 점도 인상적이었습니다.
다만 이번 결과에서 가장 먼저 본 건 순위보다 모델 크기였습니다. KDL-Frontier-Parser-nano는 1.2B 규모의 작은 모델입니다. 기존 오픈소스 1위 모델이었던 Infinity-Parser2-Pro는 35.1B였고요. 훨씬 작은 모델로 더 좋은 성능을 낸 셈입니다.
저희가 처음부터 만들고 싶었던 것도 무조건 큰 모델은 아니었습니다. 기업과 기관에서 실제로 돌릴 수 있는 모델을 만들고 싶었습니다. 보안 환경에서도 직접 배포할 수 있고, 비용과 인프라 부담을 줄이면서도 문서 구조를 안정적으로 처리하는 모델이 필요하다고 봤습니다.
이번 결과는 문서 파싱에서는 모델 크기만큼이나 설계 방식이 중요하다는 걸 보여준 것 같습니다.
OCRBench와 ParseBench, 두 번의 1위
Q. 한국딥러닝은 OCRBench v2에 이어 ParseBench에서도 1위를 했습니다. 두 성과는 어떻게 연결된다고 보시나요?
OCRBench v2 1위가 문서 인식 기술력을 보여준 결과라면, ParseBench 1위는 문서 구조화 기술력을 보여준 결과라고 봅니다.
실제 업무에서 문서는 단순한 텍스트 모음이 아닙니다. 제목, 본문, 표, 차트, 주석, 이미지, 수식, 도장, 체크박스가 함께 존재하고 각각의 역할이 있습니다. 기업이 원하는 건 이 요소들을 업무 시스템이 쓸 수 있는 데이터로 바꾸는 것입니다.
예를 들어 보고서 안의 표를 보면, 숫자만 추출해서는 부족합니다. 그 숫자가 어떤 행과 열에 속하는지, 어떤 기간과 항목을 설명하는지, 표의 제목이나 캡션과 어떻게 연결되는지까지 남아 있어야 합니다. 그래야 검색이나 분석, RAG, AI 에이전트 업무에 활용할 수 있습니다.
OCR과 Parser는 서로 다른 기술 축입니다. 하지만 고객 업무에서는 자연스럽게 이어집니다. 문서를 정확히 인식하고, 그 안의 요소를 구조화하고, 의미 단위로 나눠 시스템이 사용할 수 있는 형태로 만드는 과정이 함께 필요하기 때문입니다.
이번 두 번의 1위는 한국딥러닝이 문서 AI에서 쌓아온 기술이 서로 다른 영역에서 검증된 결과라고 생각합니다.
ParseBench는 어떤 평가인가요?
Q. ParseBench는 어떤 벤치마크인가요?
ParseBench는 LlamaIndex가 주관하는 글로벌 문서 파싱 벤치마크입니다. 보험, 금융, 정부 분야의 실제 기업 문서 약 2,000페이지를 기반으로 모델이 문서를 얼마나 잘 구조화하는지를 평가합니다.
평가 항목은 Visual Grounding, Content Faithfulness, Tables, Semantic Formatting, Charts로 구성됩니다. 문서의 레이아웃을 얼마나 잘 이해하는지, 원문 내용을 얼마나 충실하게 보존하는지, 표와 차트 정보를 제대로 처리하는지, 문서의 의미적 서식을 얼마나 유지하는지를 함께 봅니다.
이런 평가가 필요한 이유는 최근 RAG나 AI 에이전트에서 Parser의 역할이 커지고 있기 때문입니다. AI가 문서를 기반으로 답변하거나 업무를 수행하려면, 문서가 먼저 신뢰할 수 있는 구조화 데이터로 바뀌어야 합니다.
문서가 잘못 구조화되면 그다음 단계도 같이 흔들립니다. Embedding은 잘못 정리된 입력을 기준으로 벡터화되고, VectorDB에는 불완전한 의미 단위가 저장됩니다. 검색 단계에서는 엉뚱한 근거가 반환될 수 있고, 생성 단계에서는 틀린 근거를 바탕으로 답변이 만들어질 수 있습니다.
그래서 문서 파싱은 RAG나 에이전트 앞단에서 굉장히 중요한 역할을 합니다. 뒤쪽 모델을 아무리 바꿔도, 입력 문서가 잘못 정리되어 있으면 성능 개선에는 한계가 있습니다.
“Parser는 텍스트를 뽑는 도구가 아니라, 문서를 다시 쓰는 방식에 가깝습니다.”
Q. KDL-Frontier-Parser-nano 개발에서 가장 중요하게 본 관점은 무엇인가요?
Parser를 단순 추출기로 보지 않는 것이었습니다.
문서 파싱 결과는 이후 파이프라인의 입력이 됩니다. 문서가 Parser를 거쳐 구조화 데이터가 되고, 그 데이터가 의미 단위로 나뉘고, Embedding을 거쳐 VectorDB에 저장됩니다. 그다음 검색, 재랭킹, 생성 단계가 이어집니다.
이때 Parser가 문서를 어떻게 정리하느냐에 따라 뒤쪽 성능이 달라집니다. Embedding 모델은 원본 문서를 직접 보는 것이 아니라, Parser가 만들어낸 결과를 기준으로 작동하기 때문입니다.
그래서 Parser 단계에서 이미 많은 결정이 이뤄집니다.
제목과 본문의 위계가 살아 있는지, 표의 행과 열 관계가 유지되는지, 캡션과 이미지가 연결되는지, 작성일이나 문서 유형 같은 메타데이터가 남아 있는지, 의미 단위가 자연스럽게 나뉘는지 같은 부분입니다.
이게 제대로 되지 않으면 뒤에서 좋은 LLM을 붙여도 한계가 있습니다. 검색할 때 문맥이 빠지거나, 표의 의미가 깨지거나, 오래된 문서와 최신 문서가 섞여 나올 수 있습니다.
저희는 KDL-Frontier-Parser-nano를 개발할 때 문서를 단순 문자열로 바꾸는 것이 아니라, AI가 다시 사용할 수 있는 형태로 정리하는 데 집중했습니다. Parser는 텍스트를 뽑는 도구라기보다, 문서를 기계가 이해할 수 있게 다시 구성하는 기술에 가깝습니다.
“좋은 파싱은 문서를 Element 단위로 보는 데서 시작합니다.”
Q. 문서를 구조화한다는 것을 조금 더 구체적으로 설명해주실 수 있을까요?
문서를 구조화한다는 건 문서를 구성하는 요소를 구분하고, 각 요소의 역할과 관계를 남기는 일입니다.
문서에는 대제목, 섹션 제목, 본문, 리스트, 표, 캡션, 각주, 이미지, 차트, 수식, 흐름도 같은 요소가 있습니다. 사람은 문서를 볼 때 이 요소들을 자연스럽게 구분합니다. 제목은 제목으로 보고, 표는 표로 보고, 표 아래 설명은 해당 표의 캡션으로 이해합니다.
모델도 이 구조를 이해해야 합니다. KDL-Frontier-Parser-nano는 문서를 Element 단위로 바라보도록 설계되었습니다. Title, Section-header, Text, List-item, Caption, Footnote, Table, Picture, Chart, Formula, Flowchart 같은 요소를 구분하고, 문서 안에서 어떤 역할을 하는지 파악하는 방식입니다.
이 구조는 결과물을 보기 좋게 만들기 위한 장식이 아닙니다. 이후 Chunking과 검색 품질에 바로 영향을 줍니다.
예를 들어 제목과 본문이 연결된 상태로 나뉘어야 검색할 때 해당 문맥이 살아납니다. 표는 셀 안의 텍스트만 남는 것이 아니라, 행과 열의 관계가 유지되어야 합니다. 차트는 이미지로만 남는 것이 아니라, 그 안의 데이터와 설명이 함께 표현되어야 합니다.
좋은 파싱은 문서 안의 정보를 최대한 잃지 않는 일입니다. 문서가 갖고 있던 구조를 보존해야 그다음 단계에서도 쓸 수 있습니다.
“Visual Grounding 1위는 문서 파싱에서 꽤 큰 성과입니다.”
Q. 이번 평가에서 Visual Grounding 항목 전체 1위를 기록했습니다. 이 결과가 왜 중요한가요?
Visual Grounding은 문서의 시각적 구조를 이해하는 능력입니다. 어떤 텍스트가 어디에 놓여 있는지, 어떤 영역에 속하는지, 어떤 표나 그림, 캡션과 연결되는지 파악하는 능력이라고 보면 됩니다.
문서는 단순히 위에서 아래로 읽는 글이 아닙니다. 표, 박스, 다단 구성, 머리글, 바닥글, 주석, 이미지, 차트가 모두 위치와 구조를 통해 의미를 갖습니다.
이번 평가에서 KDL-Frontier-Parser-nano는 Visual Grounding 항목에서 81.83점을 기록하며 전체 참가 모델 중 1위를 했습니다. 종합 1위도 좋았지만, 저는 이 항목에서 1위를 했다는 점이 특히 의미 있다고 봅니다.
Parser가 레이아웃을 제대로 이해하지 못하면 결과가 겉으로는 맞아 보여도 실제로는 틀릴 수 있습니다. 다단 문서에서 왼쪽과 오른쪽 컬럼이 섞이면 문장 순서가 깨집니다. 표에서 헤더와 값이 분리되면 숫자의 의미가 사라집니다. 캡션이 어떤 표를 설명하는지 놓치면 검색 단계에서 잘못된 근거가 반환될 수 있습니다.
문서의 위치와 관계를 먼저 이해해야, 그 안의 내용을 안정적으로 구조화할 수 있습니다. Visual Grounding은 그 기반이 되는 능력입니다.
“표와 차트는 문서의 핵심 데이터입니다.”
Q. 세부 항목 중 Tables와 Charts도 중요한 평가 항목입니다. 실제 개발에서는 어떤 점이 어려웠나요?
기업 문서에서 표와 차트는 부속 요소가 아니라 핵심 데이터인 경우가 많습니다. 재무 보고서, 보험 서류, 공공 행정문서, 성과 보고서, 정책 자료를 보면 중요한 정보가 대부분 표나 차트에 들어 있습니다.
표에서 어려운 점은 텍스트를 읽는 것이 아니라 관계를 유지하는 것입니다. 행과 열, 병합 셀, 다중 헤더, 단위, 주석, 캡션이 함께 해석되어야 합니다. 예를 들어 “30억”이라는 값이 있어도 그것이 어느 분기의 영업이익인지, 매출인지, 예산인지 연결되지 않으면 쓸 수 있는 데이터가 아닙니다.
차트도 마찬가지입니다. 차트는 이미지처럼 보이지만 실제로는 데이터 구조를 갖고 있습니다. 축, 범례, 수치, 색상, 라벨, 추세가 함께 의미를 만듭니다. 이걸 단순 이미지로만 처리하면 정보가 사라집니다.
KDL-Frontier-Parser-nano는 표와 차트를 구조화된 형태로 이해하는 데 집중했습니다. 이번 평가에서도 Tables 항목에서 84.56점, Content Faithfulness 항목에서 86.63점을 기록했습니다.
문서 파싱에서 표와 차트를 잘 처리한다는 것은 보기 좋은 Markdown이나 HTML로 변환하는 수준에 그치지 않습니다. 사람이 업무에서 해석하던 관계를 기계가 사용할 수 있는 데이터로 남기는 일입니다.
“Chunking은 문서를 그냥 잘라내는 일이 아닙니다.”
Q. Parser가 RAG 성능에는 어떻게 영향을 주나요?
RAG를 도입할 때 많은 분들이 먼저 LLM, Embedding 모델, VectorDB, 재랭킹 모델을 고민합니다. 물론 모두 중요합니다. 그런데 그보다 앞에 있는 Parser를 놓치면 성능이 기대만큼 나오지 않을 수 있습니다.
RAG 파이프라인은 보통 문서, Parser, 구조화 데이터, Chunking, Embedding, VectorDB, 검색, Re-ranking, Generation 순서로 이어집니다. Parser가 문서 구조를 제대로 보존하지 못하면 Chunking 단계부터 문제가 생깁니다.
Chunking은 문서를 일정 길이로 자르는 일이 아닙니다. 의미 단위가 유지되도록 나누는 일입니다.
하나의 조항이 두 Chunk로 갈라지면 필요한 근거가 반쪽만 검색될 수 있습니다. 반대로 서로 다른 의미의 내용이 하나의 Chunk에 섞이면 검색 정확도가 떨어집니다. 문단 경계, 표 블록, 조항 단위, 제목과 본문 연결이 유지되어야 검색 결과가 안정됩니다.
Parser가 구조를 잘 보존하면 VectorDB에는 단순 텍스트 조각이 아니라 의미 단위의 데이터가 저장됩니다. 그러면 검색 단계에서 필요한 근거를 더 정확히 가져올 수 있고, LLM이 답변을 만들 때도 근거가 덜 흔들립니다.
저희가 Parser를 RAG 앞단의 부가 기능처럼 보지 않는 이유가 여기에 있습니다. Parser는 RAG 정확도를 좌우하는 앞단 인프라에 가깝습니다.
“메타데이터는 검색 품질을 좌우합니다.”
Q. 문서 파싱에서 메타데이터도 중요하게 보시나요?
네. 기업 문서에서는 정답이 본문 텍스트 안에만 있지 않은 경우가 많습니다.
같은 규정 문서라도 버전이 다르면 답이 달라질 수 있습니다. 같은 제목의 보고서라도 작성일이 최신인지, 어느 부서 문서인지, 어떤 문서 유형인지에 따라 검색 우선순위가 달라져야 합니다. 계약서나 정책 문서에서는 날짜, 버전, 문서 유형, 작성 주체 같은 정보가 매우 중요합니다.
이런 정보가 Parser 단계에서 남지 않으면 재랭킹은 단순 유사도에 의존하게 됩니다. 비슷한 문서를 찾는 것과 지금 질문에 맞는 문서를 찾는 것은 다릅니다.
KDL-Frontier-Parser-nano를 개발할 때도 본문뿐 아니라 문서가 가진 주변 신호를 어떻게 유지할지 중요하게 봤습니다. 제목, 섹션, 페이지, 캡션, 표, 작성일, 문서 유형 같은 정보가 검색과 재랭킹에서 활용될 수 있어야 합니다.
기업용 문서 AI에서는 “무엇이 적혀 있는가”뿐 아니라 “그 정보가 어디에 있고, 어떤 문서의 어떤 맥락에 속하는가”가 같이 남아야 합니다. 메타데이터는 그 맥락을 유지하는 장치입니다.
“1.2B라는 크기는 운영 가능성과 연결됩니다.”
Q. 다시 모델 크기 이야기로 돌아가보면, 1.2B 모델이라는 점이 고객 환경에서는 어떤 의미가 있나요?
기업용 AI에서 모델 크기는 단순한 스펙이 아닙니다. 운영 가능성과 바로 연결됩니다.
모델이 너무 크면 비용이 커지고, 응답 속도가 느려지고, 배포 환경도 제한됩니다. 특히 금융, 보험, 공공기관처럼 보안 요구사항이 높은 고객은 외부 API로 민감한 문서를 보내기 어려운 경우가 많습니다. 내부망이나 폐쇄망, 온프레미스 환경에서 직접 운영해야 하는 상황도 있습니다.
KDL-Frontier-Parser-nano는 1.2B 규모의 초경량 모델입니다. GPU 1장으로도 구동 가능한 수준을 목표로 했고, 오픈 가중치로 공개되어 고객 환경에 맞춰 직접 검토하고 배포할 수 있습니다.
좋은 모델은 벤치마크에서만 좋아서는 안 됩니다. 실제 고객 환경에서 돌아가야 합니다. 문서가 많아도 처리 속도를 확보해야 하고, 보안 정책에 맞게 운영되어야 하며, 시스템 연계까지 가능해야 합니다.
작은 모델로 높은 문서 파싱 성능을 낼 수 있다면, 기업과 기관이 문서 AI를 도입할 때의 부담도 줄어듭니다.
“오픈 가중치 공개는 자신감이기도 하고, 필요한 선택이기도 했습니다.”
Q. KDL-Frontier-Parser-nano는 오픈 가중치로 공개됐습니다. 어떤 의미가 있나요?
기업용 문서 AI에서는 신뢰가 중요합니다. 특히 금융, 보험, 공공 분야에서는 어떤 모델이 어떻게 동작하는지, 내부 환경에 직접 배포할 수 있는지, 외부 서버로 문서를 보내지 않아도 되는지가 중요합니다.
상용 API는 편리하지만 모든 고객에게 맞지는 않습니다. 민감한 문서를 다루는 조직은 데이터를 외부로 보내는 것 자체가 부담일 수 있습니다. 이 경우 고객이 직접 모델을 검토하고, 내부 인프라에 맞춰 배포하고, 보안 정책에 맞게 운영할 수 있어야 합니다.
오픈 가중치 모델은 이런 환경에서 더 유연합니다. 연구자나 고객이 직접 성능을 확인할 수 있고, 필요한 환경에 맞춰 실험하거나 적용 가능성을 검토할 수 있습니다.
저희 입장에서는 자신감이기도 했습니다. 작은 모델이지만 문서 파싱에 특화된 성능을 보여줄 수 있고, 글로벌 벤치마크에서도 검증됐기 때문에 공개할 수 있었습니다.
동시에 필요한 선택이기도 했습니다. 문서 AI가 더 많은 기업 환경에서 쓰이려면 무겁고 닫힌 모델만으로는 한계가 있습니다. 더 가볍고, 검토 가능하고, 배포하기 쉬운 모델이 필요합니다.
“문서 파싱에서 가장 어려운 건, 사람이 당연하게 보는 구조를 모델도 이해하게 만드는 일입니다.”
Q. 개발 과정에서 가장 어려웠던 부분은 무엇이었나요?
사람은 문서를 보면 구조를 자연스럽게 이해합니다. 제목과 본문을 구분하고, 표의 헤더와 값을 연결하고, 캡션이 어떤 그림을 설명하는지 파악합니다. 다단 문서에서도 읽는 순서를 자연스럽게 잡습니다.
하지만 모델에게는 이 모든 것이 학습해야 하는 정보입니다. 문서 안의 위치, 간격, 선, 박스, 글자 크기, 굵기, 여백, 페이지 흐름이 모두 힌트가 됩니다. 이 중 하나만 놓쳐도 구조가 틀어질 수 있습니다.
실제 기업 문서는 더 어렵습니다. PDF도 많고, 스캔 품질이 낮은 문서도 있고, 표 안에 표가 들어가거나 셀이 병합된 경우도 있습니다. 공공 문서처럼 페이지가 길고 머리글, 바닥글, 각주가 많은 문서도 있습니다. 보고서에는 표와 차트, 이미지가 함께 섞여 있습니다.
그래서 가장 어려웠던 건 다양한 문서에서도 구조를 안정적으로 유지하는 일이었습니다. 특정 샘플에만 잘 맞는 모델이 아니라, 처음 보는 문서에서도 Element를 구분하고 관계를 보존하는 모델을 만드는 것이 중요했습니다.
문서 파싱 모델은 보이는 정보를 순서대로 나열하는 데서 끝나면 안 됩니다. 사람이 문서를 보며 자연스럽게 이해하는 구조를 최대한 남겨야 합니다.
“좋은 파서 모델은 RAG와 Agent까지 생각하고 설계되어야 합니다.”
Q. 고객사 입장에서 이번 성과를 어떻게 이해하면 좋을까요?
고객사 입장에서 중요한 질문은 “이 모델이 우리 문서 업무에 어떤 변화를 만들 수 있는가”라고 봅니다.
문서 파싱 결과는 단독으로 끝나지 않습니다. ERP, EDMS, RPA, RAG, LLM, AI Agent와 연결됩니다. 그래서 파싱 결과는 사람이 보기 좋은 출력물이 아니라, 시스템이 바로 활용할 수 있는 구조화 데이터여야 합니다.
KDL-Frontier-Parser-nano의 강점은 문서의 구조를 보존하고, 의미 단위로 활용할 수 있는 데이터를 만든다는 점입니다. 표는 표로, 차트는 차트로, 제목과 본문은 위계를 유지한 상태로, 캡션과 본문은 연결된 상태로 표현되어야 합니다. 그래야 검색과 질의응답, 업무 자동화까지 이어질 수 있습니다.
특히 RAG나 AI 에이전트를 도입하려는 고객에게 Parser는 더 중요합니다. RAG에서 답변이 흔들리는 원인은 LLM이 아니라 입력 데이터의 구조일 때가 많습니다. 문서가 잘못 분해되어 VectorDB에 들어가면 검색 결과도 흔들리고 답변도 흔들립니다.
좋은 Parser는 이 병목을 앞단에서 줄입니다. 의미 단위로 문서를 나누고, 필요한 메타데이터를 붙이고, 표와 차트의 관계를 보존해 AI가 신뢰할 수 있는 근거를 찾도록 돕습니다.
이번 ParseBench 1위는 한국딥러닝의 문서 파싱 기술이 실제 기업용 AI 파이프라인에서도 충분히 경쟁력 있게 쓰일 수 있다는 점을 보여줍니다.
Ginnie가 생각하는 좋은 AI 개발자
Q. AI 개발자로서 가장 중요하게 생각하는 태도는 무엇인가요?
문제를 끝까지 구조적으로 보는 태도라고 생각합니다.
문서 AI에서는 작은 오류처럼 보여도 실제 업무에서는 큰 문제가 될 수 있습니다. 표의 셀 하나가 잘못 연결되거나, 항목과 값이 바뀌거나, 차트의 수치를 잘못 추출하면 후속 업무 전체가 영향을 받을 수 있습니다.
그래서 개발자는 모델 점수만 보면 안 됩니다. 어떤 오류가 왜 발생했는지, 그 오류가 이후 검색, 재랭킹, 생성, 시스템 입력 단계에서 어떤 문제를 만들 수 있는지까지 봐야 합니다.
또 하나는 효율성을 계속 고민하는 태도입니다. AI 모델은 점점 커지고 있지만, 실제 고객 환경에서는 무조건 큰 모델을 쓰기 어렵습니다. 비용, 속도, 보안, 배포 환경을 함께 고려해야 합니다.
저는 좋은 AI 개발자는 성능과 현실 사이의 균형을 볼 수 있는 사람이라고 생각합니다. 연구적으로 좋은 모델을 만드는 것도 중요하지만, 고객이 실제로 쓸 수 있는 모델을 만드는 것도 그만큼 중요합니다.
KDL-Frontier-Parser-nano도 그런 관점에서 개발했습니다. 글로벌 벤치마크에서 성능을 입증하는 동시에, 실제 기업 환경에서 구동 가능한 모델이어야 한다고 봤습니다.
“문서 AI의 다음 과제는 더 작게, 더 정확하게, 더 쉽게 연결되는 것입니다.”
Q. 앞으로 Ginnie와 한국딥러닝 개발팀이 집중하고 싶은 방향은 무엇인가요?
정확도는 계속 높여야 합니다. 문서 파싱은 아직 어려운 문제가 많습니다. 표, 차트, 복잡한 레이아웃, 다양한 문서 양식, 저품질 스캔본처럼 해결해야 할 과제가 계속 있습니다.
하지만 정확도만큼 효율성과 연결성도 중요합니다. 더 작은 모델로 더 좋은 성능을 내고, 더 적은 자원으로 더 빠르게 처리하고, 다양한 고객 환경에 쉽게 배포할 수 있어야 합니다.
또 하나는 파싱 결과가 실제 업무 시스템과 더 잘 연결되도록 만드는 것입니다. Parser의 결과가 JSON, Markdown, HTML 같은 구조화 형식으로 제공되고, 이후 ERP, EDMS, Agent, RAG, LLM 파이프라인과 자연스럽게 이어져야 합니다.
기업과 기관은 환경이 모두 다릅니다. 어떤 곳은 클라우드를 사용할 수 있고, 어떤 곳은 온프레미스가 필요하며, 어떤 곳은 폐쇄망 환경에서만 운영해야 합니다. 문서 AI가 실제로 확산되려면 이런 환경에 맞춰 유연하게 적용될 수 있어야 합니다.
KDL-Frontier-Parser-nano는 그 방향의 시작점이라고 생각합니다. 작은 모델이지만 문서 파싱에 특화된 성능을 보여줬고, 오픈 가중치로 공개되어 다양한 환경에서 활용 가능성을 확인할 수 있습니다.
앞으로는 더 정확하고, 더 가볍고, 더 쉽게 업무 시스템에 연결되는 문서 AI를 만드는 데 집중하고 싶습니다.
문서를 파싱하는 AI에서, 에이전트가 신뢰할 수 있는 데이터로
ParseBench VLM 부문 1위는 한국딥러닝에게 중요한 성과다. 특히 1.2B 초경량 모델로 Google Gemini, OpenAI GPT-5.5 등 글로벌 상용 모델을 앞섰다는 점에서 의미가 크다.
하지만 지니는 인터뷰 내내 “큰 모델을 이겼다”는 말보다 “실제 업무에서 쓸 수 있는 모델”과 “신뢰할 수 있는 구조화 데이터”를 더 많이 이야기했다.
문서 AI의 경쟁은 더 정교해지고 있다. 기업과 기관은 문서를 단순히 처리하는 기술을 넘어, 문서 안의 구조와 맥락을 정확하게 이해하고 업무 시스템에 연결할 수 있는 기술을 필요로 한다.
AI 에이전트가 실제 업무를 수행하려면 문서를 믿을 수 있어야 한다. 계약서의 조건, 청구서의 금액, 공문서의 항목, 보고서의 표와 차트가 정확한 구조로 변환되어야 한다. 그래야 AI가 그 정보를 기반으로 다음 행동을 할 수 있다.
RAG 역시 마찬가지다. 검색 품질은 LLM만으로 결정되지 않는다. Parser가 문서를 어떻게 표현하고, 어떤 의미 단위로 나누고, 어떤 메타데이터를 남기는지가 VectorDB와 검색, 재랭킹, 생성 품질에 영향을 준다.
한국딥러닝이 집중하는 방향도 여기에 있다.
문서를 단순 텍스트로 바꾸는 것이 아니라, 업무에 쓸 수 있는 데이터로 구조화하는 것. 큰 모델에만 의존하는 것이 아니라, 실제 배포 가능한 작은 모델로 높은 성능을 내는 것. 고객의 보안 환경과 운영 조건 안에서도 안정적으로 돌아가는 문서 AI를 만드는 것.
Ginnie는 마지막으로 이렇게 말했다.
문서 파싱 모델은 결국 사람이 다시 손보지 않아도 될 만큼 정확한 구조를 만들어야 합니다. 모델이 크고 복잡해 보이는 것보다, 고객 환경에서 안정적으로 돌아가고 실제 업무에 바로 쓸 수 있는 결과를 내는 게 더 중요합니다. 저희가 만들고 싶은 건 그런 모델입니다.
ParseBench 글로벌 1위는 그 방향을 보여주는 하나의 결과다.
그리고 이 결과는 한국딥러닝이 문서 AI를 어디까지 확장해갈 수 있는지 보여주는 또 다른 출발점이기도 하다.
