LLM 시대, 검색 성능을 결정한 것은 모델이 아니라 ‘문서 구조’였습니다
생성형 AI와 RAG(Retrieval-Augmented Generation)가 빠르게 확산되면서 많은 기업이 LLM 기반 검색 시스템을 구축했습니다. 그러나 현장에서는 또 다른 벽에 부딪힙니다.
“모델은 최신인데 검색 정확도가 오르지 않는다.”
“VectorDB를 쌓았는데 답변이 엉뚱하다.”
“같은 문서인데도 결과가 불안정하다.”
한국딥러닝은 이 문제를 LLM의 한계로 보지 않았습니다. 문제의 본질은 모델이 아니라, 문서를 어떻게 분해(청킹)하고 저장했는가에 있었습니다.
DEEP Parser가 시장에서 선택된 이유는 단순한 성능 우위가 아닙니다. RAG 구조의 병목을 정확히 짚었기 때문입니다.
기존 Parser는 어디에서 멈췄는가
OCR 기반 Parser의 구조적 한계
초기의 Parser는 OCR 기반이었습니다. 이미지 안의 텍스트 전문을 인식하고, 표는 HTML로 표현했습니다.
표면적으로는 “구조화”처럼 보였습니다. 하지만 다음이 불가능했습니다.
제목과 문단의 위계 인식
문서 구조의 의미 해석
이미지·그래프의 설명 및 요약 표현
텍스트는 추출했지만, 문서를 이해하지는 못했습니다. 문서의 시각적인 모습을 ‘구현’하는 것에 그쳤죠.
이 상태에서 Chunking을 수행하면, 제목과 본문이 분리되고, 표와 캡션이 끊어지고 문맥이 붕괴된 채 VectorDB에 저장됩니다.
RAG 정확도가 멈추는 이유는 여기에서 시작됩니다.
LLM 시대에 Parser가 중요해진 이유
LLM 사업에서 검색 성능을 높이려면 VectorDB 구성이 매우 중요합니다. LLM을 직접 튜닝하기보다, 부족한 도메인 지식을 별도의 DB(VectorDB)로 보완해 학습되지 않은 정보도 답변하도록 만드는 구조가 일반화됐기 때문입니다.
하지만 VectorDB의 품질은 얼마나 의미 단위로 정확히 Chunking했는가에 달려 있습니다. 즉, 문서를 잘게 나누는 것이 아니라, 의미를 보존한 채 분해하는 것이 핵심입니다.
이 지점에서 기존 Parser는 한계를 보였습니다. 그리고 DEEP Parser는 다른 질문에서 출발했습니다.
DEEP Parser의 출발점
“이 문서는 어떤 구조로 구성되어 있는가?”
“각 요소는 어떤 의미 단위인가?”
DEEP Parser는 Vision-Language Model(VLM) 기반입니다. 문서를 텍스트 블록이 아니라, 화면 전체의 의미 구조로 이해합니다.
MS Office, HWP, PDF, 이미지 등 다양한 문서에서 데이터를 발췌하고, VectorDB 구성을 위한 Chunk 단위로 재구성하는 문서 AI 기술입니다.
단순 OCR의 확장이 아니라, LLM 시대를 전제로 설계한 Parser입니다.
DEEP Parser의 핵심 기능
Element 기반 문서 표현
DEEP Parser는 문서를 다음과 같은 Element로 분해합니다.
Title – 문서 대제목
Section-header – 문단 제목
Text – 일반 텍스트
Page-header – 머릿글
Page-footer – 바닥글
List-item – 글머리 기호
Caption – 표/이미지 캡션
Footnote – 각주
Table – 표
Picture – 그림
Chart – 차트·그래프를 HTML 테이블로 해석
Flowchart – 흐름도를 자연어로 해석
Formula – 수식을 논문 표현식으로 변환
이 구조는 단순 시각화 목적이 아닙니다. Chunking 기준이 됩니다.
의미 단위가 보존된 상태로 VectorDB에 저장되기 때문에 검색 정확도가 구조적으로 달라집니다. 문서 상에서 어떤 정보가 어떠한 역할을 하는지 명시하기에 검색 정확도가 올라갈 수 밖에 없죠.
구조화 데이터 제공
문서 분석 및 정보 추출 결과는 JSON, Markdown, HTML 형식으로 제공합니다.
이는 사람이 보기 위한 화면이 아니라, 시스템 연계를 전제로 한 데이터입니다.
ERP, EDMS, Agent, RAG, LLM 파이프라인과 즉시 연결 가능한 구조입니다.
운영 환경에서 검증된 성능
최근 테스트 기준은 다음과 같습니다.
테스트 환경: DGX B200 × 2
테스트 문서: 온나라문서 제5차 국가안전관리 기본계획(100페이지 기준)
총 소요 시간: 52초
페이지당 처리 속도: 0.52초 (B200 1장 기준 0.71초)
이 수치는 단순 텍스트 추출 속도가 아니라, 구조 해석이 포함된 처리 속도입니다. 이는 업계에서 괄목할만한 수치라고 할 수 있습니다. 사람이 직접 읽고 분석하는 시간과 비교하면 엄청난 시간 단축이죠.
지원 환경과 파일 형식
지원 파일 형식은 다음과 같습니다.
.pdf, .hwp, .hwpx
.doc, .docx
.xlsx, .ppt, .pptx
.jpg, .png, .tif, .tiff
.txt, .csv
.odt, .hwtx, .owpml
이는 공공·기업 문서 환경을 포괄합니다.
온프레미스 환경을 전제로 설계되어 HW 플랜, 설치 디렉토리 구조, 대용량 처리까지 고려합니다. 보안이 중요한 조직에서도 데이터 반출 없이 운영 가능합니다.
경기도청 적용 사례
적용 구조는 명확합니다.
Agent를 통해 문서를 업로드
DEEP Parser로 구조 분석
추출 데이터를 VectorDB에 임베딩
RAG 기반 질의 응답 수행
ㅗ
흐름도는 다음과 같습니다.
Parser → VectorDB → RAG → LLM
모델을 바꾸지 않아도 검색 정확도가 올라가는 구조입니다.
왜 DEEP Parser는 시장에서 승리했는가
DEEP Parser는 OCR 성능 경쟁을 하지 않았습니다. 모델 크기 경쟁도 하지 않았습니다. 이는 물론 중요하겠지만, 실질적으로 작동하고 유의미한 데이터를 추출하는 것이 보다 중요하다고 본 것입니다. 대신, RAG의 병목이 Parser에 있다는 점을 짚었습니다.ㅇ
문서를 이해하지 못하면 VectorDB는 쌓이지만 검색은 정확해지지 않습니다.
DEEP Parser는 문서를 Element 단위로 재구성하고 의미 단위로 Chunking하며 구조를 보존한 채 저장합니다.
그 결과, 모델을 바꾸지 않아도 성능이 올라갑니다.
LLM 시대의 경쟁은 누가 더 큰 모델을 쓰느냐가 아니라, 누가 더 정확하게 문서를 구조화하느냐입니다.
그 지점에서 DEEP Parser는 기능이 아니라 인프라가 되었습니다.
그리고 시장은 결국 인프라를 선택합니다.