AI Agent 시장에 던져진 새로운 도전장
2025년 11월 6일, Google은 Gemini API에 File Search Tool이라는 완전 관리형 RAG(Retrieval-Augmented Generation) 시스템을 발표했습니다. 이 발표는 RAG 생태계에 적지 않은 파장을 일으켰습니다. Google이 제시한 가격 정책은 특히 주목할 만했습니다. 파일을 처음 인덱싱할 때만 $0.15/1M 토큰의 비용을 부과하고, 임베딩 저장과 검색은 완전 무료로 제공한다는 것이었습니다. 게다가 PDF, DOCX, XLSX, HWP, 심지어 ZIP 파일까지 다양한 형식을 지원하며 최대 1TB까지 처리할 수 있다고 밝혔습니다.
Google의 공식 블로그 포스트에 따르면, File Search Tool은 RAG 파이프라인의 복잡성을 추상화하여 개발자가 본질적인 비즈니스 로직 구축에 집중할 수 있도록 설계되었습니다. 파일 저장, 최적의 청킹 전략 선택, 임베딩 생성, 그리고 검색된 컨텍스트를 프롬프트에 동적으로 주입하는 전체 과정을 자동으로 처리합니다. 최신 Gemini Embedding 모델을 기반으로 한 벡터 검색을 통해 의미론적 유사성을 이해하며, 모델의 응답에는 자동으로 인용(citation)이 포함되어 출처 검증이 용이하다는 점도 강조했습니다.
이러한 발표는 자연스럽게 한 가지 질문을 불러일으켰습니다. 과연 이 서비스가 기존의 문서 파싱 및 RAG 솔루션 시장에 얼마나 큰 영향을 미칠 것인가? 특히 기업용 RAG 솔루션을 개발하는 저희에겐 매우 중요한 질문이었습니다. 이론적 스펙과 실제 성능 사이에는 종종 큰 차이가 있기 마련입니다. 그래서 우리는 체계적인 벤치마크 테스트를 통해 실제 성능을 검증하기로 결정했습니다.
STORM Parse 소개: RAG 최적화를 위한 Intelligent Document Parser
본격적인 벤치마크 결과를 논하기 전에, 먼저 STORM Parse가 무엇인지 소개하겠습니다.
STORM Parse는 사이오닉이 개발한 문서 파싱 서비스로, RAG 파이프라인에 최적화된 Intelligent Parser입니다. 단순히 문서에서 텍스트를 추출하는 것을 넘어서, 문서의 구조와 의미를 이해하고 이를 AI가 효과적으로 활용할 수 있는 형태로 변환하는 것이 핵심 목표입니다.
STORM Parse는 PDF, DOCX, DOC, PPTX, PPT, XLSX, XLS, PNG, JPG, JPEG, HWP 등 실무에서 사용되는 거의 모든 문서 형식을 지원합니다. 특히 한국 기업 환경에서 여전히 널리 사용되는 HWP 형식에 대한 지원은 중요한 차별점입니다. 많은 글로벌 솔루션들이 HWP를 제대로 지원하지 못하거나 품질이 떨어지는데, STORM Parse는 HWP의 복잡한 구조를 정확하게 파싱할 수 있습니다.
STORM Parse의 처리 과정은 크게 두 단계로 나뉩니다. 첫 번째는 정보 추출(Information Extraction) 단계로, 문서의 레이아웃과 계층 구조를 인식하고 텍스트, 표, 이미지, 차트 등 다양한 요소를 식별합니다. 두 번째는 의미 해석(Semantic Interpretation) 단계로, Vision-Language Model을 활용하여 추출된 요소들의 의미를 분석하고 요소 간 연관성을 파악하여 자연어 형태로 정리합니다.
이러한 접근 방식을 통해 STORM Parse는 계약서, 재무제표, 연구 보고서, 기술 문서 등 복잡한 구조를 가진 실무 문서들을 높은 정확도로 처리하여 검색, 요약, 질의응답 등 다양한 RAG 애플리케이션에 바로 활용할 수 있는 형태로 변환합니다.
AI 에이전트 유튜브 채널을 운영하시는 테디노트 님의 라이브에서 스톰 파스의 기술적 상세와 사용 방법을 소개한 바 있습니다.
Agentic RAG에서 문서 파싱이 중요한 이유: 기술적 관점
Agentic RAG 시스템의 성능을 논할 때 흔히 검색 알고리즘, 임베딩 모델, 리랭킹 전략, 프롬프트 엔지니어링 등에 초점을 맞춥니다. 물론 이러한 요소들도 중요하지만, 이 모든 것의 출발점은 문서 파싱입니다. 아무리 훌륭한 검색 알고리즘과 강력한 LLM을 사용하더라도, 문서가 제대로 파싱되지 않으면 전체 검색 시스템의 성능이 크게 저하됩니다.
문서 파싱의 품질이 RAG 성능에 미치는 영향은 여러 단계에서 나타납니다.
•
첫째, 정보 보존(Information Preservation)의 문제입니다. 파싱 과정에서 중요한 정보가 누락되거나 왜곡되면, 아무리 정교한 검색을 수행해도 올바른 답을 찾을 수 없습니다. 예를 들어 재무제표의 특정 셀 값이 잘못 추출되거나, 차트의 범례 정보가 누락되면 할루시네이션(hallucination)이 생길 확률이 높아집니다.
•
둘째, 구조 보존(Structure Preservation)의 문제입니다. 문서는 단순한 텍스트의 나열이 아니라 계층적 구조를 가지고 있습니다. 제목과 본문, 표의 헤더와 데이터 행, 리스트의 계층 구조 등이 명확히 구분되어야 합니다. 구조가 무너지면 맥락(context)이 손실되고, LLM이 정보를 올바르게 해석하기 어려워집니다. 특히 복잡한 다단 레이아웃이나 텍스트와 이미지가 혼재된 문서에서 읽는 순서가 뒤바뀌면 전혀 다른 의미로 해석될 수 있습니다.
•
셋째, 의미 보존(Semantic Preservation)의 문제입니다. 사람이 작성한 문서는 시각적 요소를 통해 의미를 전달합니다. 표의 색상 구분, 차트의 시각적 패턴, 이미지 속의 다이어그램 등은 단순한 장식이 아니라 정보를 담고 있습니다. 이러한 시각적 의미를 텍스트로 변환하지 못하면 중요한 정보가 손실됩니다. 예를 들어 "위험" 표시가 빨간색으로 강조되어 있다는 것, 특정 지표가 급격히 상승하는 추세를 보인다는 것 등은 사람의 눈으로는 바로 알 수 있지만 단순 텍스트 추출만으로는 포착되지 않습니다.
•
넷째, 청킹 친화성(Chunking Friendliness)의 문제입니다. RAG 시스템에서는 문서를 적절한 크기의 청크로 나누어 임베딩하고 검색합니다. 문서가 어떻게 파싱되느냐에 따라 청킹의 품질이 크게 달라집니다. 예를 들어 표가 단순히 텍스트로 평탄하게 변환되면 청크 경계에서 표가 잘렸을 때 맥락을 완전히 잃을 수 있습니다. 반면 표의 각 행이 완전한 문장으로 설명되어 있다면, 어디서 잘리든 각 청크가 독립적으로 의미를 갖게 됩니다.
•
다섯째, 검색 효율성(Retrieval Efficiency)의 문제입니다. 임베딩 모델은 자연어에 최적화되어 훈련됩니다. 마크다운 테이블 문법이나 HTML 태그 같은 구조화된 형식보다는 자연스러운 문장에서 더 좋은 임베딩을 생성합니다. 따라서 파싱 결과가 얼마나 자연어에 가까운지가 검색 정확도에 직접적인 영향을 미칩니다.
인간 중심 문서 vs AI 친화적 표현
문서 파싱이 어려운 근본적인 이유는 문서가 인간을 위해 설계되었기 때문입니다. 인간은 시각적 정보 처리에 탁월합니다. 텍스트를 읽는 것보다 그래프를 보는 것이 더 빠르고, "안전"이라는 텍스트보다 초록색 체크 아이콘이 더 직관적입니다. 그래서 문서 작성자들은 표, 차트, 그래프, 색상, 레이아웃 등 다양한 시각적 도구를 활용합니다.
문서의 목적에 따라 표현 방식도 달라집니다. 협업을 위한 문서는 빠른 스캔이 가능하도록 요약과 강조를 많이 사용하고, 설득을 위한 문서는 시각적 임팩트를 극대화하며, 기술 문서는 정확한 구조와 상세한 설명을 담습니다. 이러한 다양성은 인간에게는 장점이지만 AI에게는 도전 과제입니다.
예를 들어 재무제표를 생각해보면, 인간은 표의 구조를 한눈에 파악하고 각 열이 무엇을 의미하는지 이해하며, 병합된 셀들이 상위 카테고리를 나타낸다는 것을 자연스럽게 인식합니다. 또한 굵은 글씨로 표시된 합계 행을 다른 데이터 행과 구분하고, 음수는 보통 괄호나 빨간색으로 표시된다는 암묵적 규칙을 알고 있습니다.
하지만 단순한 텍스트 추출 방식은 이러한 시각적 정보와 구조적 맥락을 놓칩니다. 표의 모든 셀이 순차적으로 나열되면 어떤 값이 어떤 행과 열에 속하는지, 어떤 헤더와 연결되는지 알 수 없게 됩니다. 병합된 셀의 정보는 첫 번째 셀에만 나타나고 나머지는 빈 값으로 처리되어 맥락이 끊어집니다. 합계 행과 일반 데이터 행의 구분도 사라집니다.
이미지와 차트의 경우 문제는 더 심각합니다. OCR만으로는 차트 안의 텍스트(레이블, 범례, 수치)는 추출할 수 있지만, 선이나 막대가 나타내는 추세, 색상이 구분하는 카테고리, 데이터 포인트 간의 시각적 관계 등은 전혀 포착할 수 없습니다. 파이 차트에서 각 섹션의 비율, 라인 차트에서 값의 변화 추세, 산점도에서 데이터의 분포 패턴 같은 시각적 인사이트가 모두 손실됩니다.
복잡한 레이아웃의 경우 읽는 순서가 문제가 되기도 합니다. 2단 또는 3단 레이아웃, 텍스트 박스와 이미지가 혼재된 페이지, 사이드바가 있는 문서 등에서 올바른 읽는 순서를 파악하지 못하면 문맥이 완전히 뒤바뀝니다. "A 제품의 판매량은 증가했다. B 제품은 감소했다"가 "A 제품의 판매량은 감소했다. B 제품은 증가했다"로 해석될 수 있습니다.
STORM Parse의 기술적 접근: VLM 기반 2단계 변환
STORM Parse는 이러한 문제들을 해결하기 위해 Vision-Language Model을 핵심 기술로 채택했습니다. VLM은 이미지와 텍스트를 동시에 처리할 수 있는 멀티모달 AI 모델로, 최근 급격히 발전하고 있는 분야입니다.
최근에 나온 GPT 5.1, Claude 4.5 sonnet, Gemini 2.5 Pro 등과 같은 모델들이 대표적인 예입니다.
VLM의 가장 큰 장점은 시각적 의미를 이해할 수 있다는 점입니다. 단순히 이미지 안의 텍스트를 OCR로 추출하는 것이 아니라, 이미지 내 각 요소들이 어떤 관계를 가지고 시각적으로 어떤 정보를 가지고 있는지 이해할 수 있습니다. 표의 경우 셀들의 공간적 배치를 보고 어떤 셀이 헤더이고 어떤 셀이 데이터인지, 병합된 셀이 어떤 범위를 나타내는지 파악할 수 있습니다. 차트의 경우 선의 기울기에서 추세를, 막대의 높이에서 값의 비교를, 색상에서 카테고리 구분을 이해할 수 있습니다.
문서 레이아웃 측면에서도 VLM은 강력합니다. 페이지의 전체 구조를 보고 메인 컨텐츠와 사이드바를 구분하고, 다단 레이아웃에서 올바른 읽는 순서를 파악하며, 이미지 캡션과 본문의 관계를 이해합니다. 헤더와 푸터, 페이지 번호 같은 메타데이터를 실제 내용과 구분할 수도 있습니다.
또한 VLM은 기술적 확장성 측면에서도 유리합니다. 전통적인 룰 기반이나 머신러닝 모델은 새로운 형태의 표나 레이아웃이 나타나면 재훈련이나 규칙 수정이 필요합니다. 하지만 VLM은 범용적인 시각 이해 능력을 가지고 있어, 학습 단계에서 보지 못한 형식도 처리할 수 있습니다. 기업마다 다른 템플릿, 산업마다 다른 문서 스타일에도 유연하게 대응할 수 있습니다. 게다가 VLM 기술은 계속 발전하고 있어, 모델이 업데이트될수록 STORM Parse의 성능도 자연스럽게 향상됩니다.
하지만 VLM을 사용하는 것만으로 모든 문제가 해결되지는 않습니다. VLM은 강력하지만 때때로 예측 불가능한 출력을 생성할 수 있습니다. LLM의 할루시네이션 문제와 유사하게, VLM도 실제로 존재하지 않는 텍스트를 "보거나", 숫자를 잘못 읽거나, 구조를 오해할 수 있습니다. 특히 복잡한 레이아웃이나 품질이 낮은 스캔 문서에서 이런 문제가 두드러집니다.
또한, VLM은 일관성(consistency) 문제가 있습니다. 같은 문서를 여러 번 처리해도 매번 조금씩 다른 결과를 생성할 수 있습니다. 프로덕션 환경에서는 재현 가능하고 예측 가능한 결과가 중요한데, 순수 VLM만으로는 이를 보장하기 어렵습니다.
STORM Parse는 이러한 문제를 2단계 변환 구조를 통해 해결했습니다. 이 접근법은 전통적 방법의 안정성과 VLM의 이해력을 결합하여 최상의 결과를 도출합니다.
1단계: 마크다운 변환 (Markdown Conversion)
첫 번째 단계에서는 자체 개발한 마크다운 변환 모듈을 사용합니다. 이는 전통적인 문서 파싱 기법을 기반으로 하며, PyMuPDF, python-docx 같은 검증된 라이브러리들을 활용하되 대량의 문서 처리 경험을 통해 최적화되었습니다.
이 단계는 빠르고 안정적입니다. 문서의 기본 구조를 파악하여 제목, 단락, 리스트, 표, 이미지 위치 등을 식별하고, 텍스트를 추출하여 마크다운 형식으로 변환합니다. 표의 경우 마크다운 테이블 문법으로, 이미지의 경우 이미지 마크다운 링크로 변환됩니다.
물론 이 단계만으로는 완벽하지 않습니다. 복잡한 표의 병합된 셀은 제대로 표현되지 않을 수 있고, 이미지 안의 내용은 캡처하지 못하며, 다단 레이아웃에서 순서가 뒤바뀔 수 있습니다. 하지만 이 단계의 목적은 완벽한 변환이 아니라 VLM이 문서의 구조를 참고할 수 있는 정보를 제공하는 것입니다.
2단계: VLM 기반 의미 해석 (VLM-based Semantic Interpretation)
두 번째 단계에서 VLM이 등장합니다. 1단계에서 생성된 마크다운 텍스트와 원본 문서의 이미지를 함께 VLM에 입력합니다. VLM은 두 가지 정보를 종합하여 작업합니다.
VLM에게 주어지는 프롬프트는 매우 구체적이고 세밀하게 설계됩니다. 예를 들어 다음과 같은 지시사항이 포함됩니다:
"제공된 마크다운 텍스트는 이 문서의 초벌 변환 결과입니다. 원본 이미지를 보고 다음 사항을 검증하고 개선하세요. 첫째, 마크다운에 누락된 텍스트가 이미지에 있는지 확인하고 추가하세요. 둘째, 표의 구조가 올바른지 확인하고, 병합된 셀의 정보를 명확히 하세요. 셋째, 이미지나 차트가 있다면 그 내용을 상세히 설명하는 문장을 생성하세요. 넷째, 여러 단락이나 섹션의 읽는 순서가 논리적으로 올바른지 확인하세요..."
이러한 프롬프트를 통해 VLM은 단순히 이미지를 설명하는 것이 아니라, 마크다운 텍스트를 기준점으로 삼아 검증하고 보완하는 작업을 수행합니다. 이는 두 가지 중요한 효과를 냅니다.
첫째, 환각(hallucination)이 크게 감소합니다. VLM이 완전히 백지상태에서 문서를 해석하는 것이 아니라, 이미 추출된 텍스트를 참고하므로 실제로 없는 내용을 만들어낼 가능성이 낮아집니다. 예를 들어 표의 숫자를 읽을 때, 마크다운에 이미 "125"라고 되어 있다면 VLM이 "128"로 잘못 읽을 가능성이 줄어듭니다.
둘째, VLM 답변의 안정성을 높일 수 있습니다. 마크다운 텍스트가 기본 구조를 제공하므로, VLM의 출력이 매번 크게 달라지지 않습니다. 같은 문서를 여러 번 처리해도 핵심 내용은 일관되게 유지됩니다.
이 2단계 구조의 진정한 가치는 각 단계의 강점을 결합한다는 점입니다. 1단계의 안정성과 속도, 2단계의 이해력과 유연성이 만나 최상의 결과를 만들어냅니다.
Agentic RAG 최적화의 핵심: 자연어 변환
STORM Parse의 또 다른 중요한 차별점은 최종 출력 형태입니다. 많은 문서 파서들이 마크다운, HTML, JSON 같은 구조화된 형식으로 결과를 반환하지만, STORM Parse는 자연어 텍스트를 생성합니다. 이것이 왜 RAG 성능에 큰 차이를 만드는지 기술적으로 분석해보겠습니다.
임베딩 모델의 특성
현재 널리 사용되는 임베딩 모델들(OpenAI text-embedding-3, Cohere embed-v3, Voyage AI 등)은 대부분 자연어 코퍼스로 훈련되었습니다. 위키피디아, 뉴스 기사, 책, 웹 페이지 등 인간이 작성한 자연스러운 문장들이 주된 훈련 데이터입니다. 따라서 이들 모델은 자연어 문장에서 가장 좋은 성능을 발휘합니다.
반면 마크다운 테이블 문법("| 항목 | 값 |"), HTML 태그("<table><tr><td>"), JSON 구조({"key": "value"}) 같은 형식은 훈련 데이터에 상대적으로 적게 포함되어 있습니다. 이러한 구조화된 형식은 인간이 읽는 텍스트가 아니라 기계가 처리하는 데이터 형식이기 때문입니다.
결과적으로 동일한 정보라도 자연어로 표현되었을 때와 구조화된 형식으로 표현되었을 때 임베딩 품질이 달라집니다. "통계학특강은 4학년 1학기 과목이며 학점은 3점입니다"라는 문장은 임베딩 모델이 잘 처리하지만, "| 통계학특강 | 4학년 | 1학기 | 3 |"이라는 표 형식은 상대적으로 덜 의미있는 임베딩을 생성할 수 있습니다.
청킹 경계 문제의 해결
RAG 시스템에서는 긴 문서를 여러 청크로 나누어 처리합니다. 일반적으로 512~1024 토큰 정도의 청크를 사용하는데, 이 과정에서 청크 경계에 걸친 정보가 문제가 됩니다.
예를 들어 큰 표가 있다고 가정해봅시다. 마크다운 테이블 형식으로 변환된 경우, 청크 경계에서 표가 잘리면 헤더 정보와 데이터가 분리될 수 있습니다. 첫 번째 청크에는 "| 과목명 | 학년 | 학기 |"라는 헤더만 있고, 두 번째 청크에는 "| 통계학특강 | 4 | 1 |"이라는 데이터만 있을 수 있습니다. 이 경우 두 번째 청크만 검색되면 "4"와 "1"이 무엇을 의미하는지 알 수 없습니다.
반면 STORM Parse가 생성한 자연어 형식이라면 "통계학특강은 4학년 1학기 과목입니다. 통계학개론은 2학년 1학기 과목입니다"처럼 각 행이 독립적인 문장으로 표현됩니다. 이 경우 청크가 어디서 잘리든 각 문장은 완전한 의미를 갖습니다. 두 번째 문장만 검색되어도 충분한 맥락이 포함되어 있습니다.
LLM의 이해도 향상
최종 답변을 생성하는 LLM 역시 자연어 프롬프트에 가장 잘 반응합니다. 검색된 컨텍스트가 자연어 문장으로 구성되어 있으면 LLM이 정보를 추출하고 종합하기 쉽습니다. 반면 마크다운 테이블이나 구조화된 데이터가 컨텍스트에 포함되면, LLM이 이를 해석하는 과정에서 실수할 가능성이 있습니다.
특히 복잡한 표의 경우, LLM이 행과 열의 관계를 잘못 이해하거나, 병합된 셀의 범위를 오해하거나, 헤더와 데이터를 혼동할 수 있습니다. 이러한 해석 오류가 할루시네이션으로 이어집니다.
자연어 형식이라면 이미 파싱 단계에서 정보가 명확한 문장으로 변환되어 있으므로, LLM은 단순히 문장을 읽고 이해하면 됩니다. 추가적인 구조 해석이 필요 없으므로 오류 가능성이 줄어듭니다.
구체적 예시: 표의 자연어 변환
실제 예시로 살펴보겠습니다. 다음과 같은 대학 교과 과정 표가 있다고 가정합니다:
| 순번 | 과목명 | 교과목명 | 학수번호 | 학점 | 이론 | 실습 | 이수학년 | 개설학기 |
|------|--------|----------|----------|------|------|------|----------|----------|
| 37 | 전공선택 | 위상수학특강 | MATH4451 | 3 | 3 | | 4 | O | |
| 38 | 전공선택 | 통계학특강 | MATH4501 | 3 | 3 | | 4 | O | |
Plain Text
복사
일반적인 마크다운 파서의 출력:
위의 마크다운 테이블 그대로 반환됩니다. 구조는 보존되지만, 임베딩과 LLM 처리에는 최적화되지 않았습니다.
STORM Parse의 자연어 출력:
"37번째 항목인 위상수학특강은 전공선택 과목이며, 학수번호는 MATH4451, 학점은 3점입니다. 이론 시간은 3시간이며, 이수 학년은 4학년입니다. 개설학기는 1학기입니다. 38번째 항목인 통계학특강은 전공선택 과목이며, 학수번호는 MATH4501, 학점은 3점입니다. 이론 시간은 3시간이며, 이수 학년은 4학년입니다. 개설학기는 1학기입니다."
이렇게 변환된 텍스트는 몇 가지 장점이 있습니다:
1.
명시적 연결: "38번째 항목인"이라는 표현으로 순서 정보가 보존됩니다.
2.
완전한 문맥: 각 문장이 주어(과목명)와 속성들을 모두 포함하여 독립적으로 이해 가능합니다.
3.
자연스러운 표현: "~이며", "~입니다" 같은 자연어 연결사가 정보를 매끄럽게 연결합니다.
4.
임베딩 친화적: 자연어 문장이므로 임베딩 모델이 의미를 잘 포착합니다.
5.
청킹 안전성: 어디서 잘려도 각 부분이 의미를 갖습니다.
차트와 그래프의 자연어 변환
차트의 경우 이점이 더 명확합니다. 파이 차트를 예로 들어보겠습니다:
일반적인 파서의 출력:
Chart Type: pie
그림 3 일·생활균형은 삶의 만족도에
그렇다 1.3% 16.6% 81.9%
Plain Text
복사
이는 구조를 전혀 파악하지 못한 출력입니다. 숫자들이 무엇을 의미하는지, 어떤 순서로 배열되었는지 알 수 없습니다.
STORM Parse의 자연어 출력:
"이 내용은 일-생활균형은 삶의 만족도에 영향을 준다고 생각한다는 질문에 대한 응답을 나타낸 원형 그래프로 요약되어 있습니다. 전체 응답 중 그렇다는 답변이 81.9%로 가장 큰 비중을 차지하며, 보통이다는 16.6%, 그렇지 않다는 1.5%를 차지합니다. 이 그래프는 그림 3으로 명시되어 있습니다."
이 설명은:
1.
차트 유형을 명시합니다 (원형 그래프)
2.
주제를 설명합니다 (일-생활균형과 삶의 만족도)
3.
각 데이터 포인트를 명확히 연결합니다 (그렇다 = 81.9%)
4.
상대적 크기를 언급합니다 (가장 큰 비중)
5.
문서 내 참조를 보존합니다 (그림 3)
LLM이 "일-생활균형에 대한 설문 결과를 알려주세요"라는 질문을 받았을 때, 자연어로 설명된 컨텍스트를 받으면 즉시 정확한 답변을 생성할 수 있습니다.
벤치마크 테스트
이제 STORM Parse와 Google Gemini File Search, 그리고 다른 경쟁 솔루션들을 실제로 비교한 벤치마크 테스트를 상세히 살펴보겠습니다.
테스트 데이터셋 구성
공정한 비교를 위해 내부적으로 활용하고 있는 커머스 및 법률 기반의 실제 고객사 데이터셋을 사용했습니다. 이 데이터셋은 실무 환경을 반영하여 설계되었으며, 다음과 같은 특징을 가진 문서들로 구성되어 있습니다.
1.
복잡한 표가 포함된 제품 설명서: 가전제품이나 산업 장비의 사양을 담은 문서로, 다중 헤더, 병합된 셀, 계층적 구조를 가진 표들이 포함되어 있습니다.
2.
대학교 교과 과정: 학과별 교육과정을 정리한 문서로, 과목명, 학수번호, 학점, 이수 조건 등이 복잡한 표 형식으로 구성되어 있습니다.
3.
경제 전망 보고서: 차트, 그래프, 표가 텍스트와 혼재된 문서로, 시각적 데이터와 설명이 함께 제시됩니다. 라인 차트, 막대 그래프, 파이 차트 등 다양한 시각화가 포함됩니다.
4.
기술 문서: 다이어그램, 플로우차트, 스크린샷 등 이미지가 많이 포함된 문서입니다.
전체 문서는 총 6개이며 페이지 수는 20페이지 이상입니다. 각 문서에 대해 평균 45개의 질문이 준비되어 총 270개의 질의응답 쌍이 만들어졌습니다. 질문들은 다음과 같은 유형으로 분류됩니다:
•
단순 사실 확인: "통계학특강은 몇 학점인가요?"
•
조건부 검색: "4학년 1학기에 개설되는 전공선택 과목을 모두 나열하세요."
•
수치 비교: "2023년과 2024년의 매출 증가율을 비교하세요."
•
차트 해석: "그림 3의 파이 차트에서 가장 큰 비중을 차지하는 항목은 무엇인가요?"
•
복합 추론: "일-생활균형에 대해 긍정적으로 답변한 비율과 보통이라고 답변한 비율을 합하면 얼마인가요?"
각 질문에 대해 정답이 미리 정의되어 있으며, 시스템의 응답이 정답과 일치하는지 자동으로 평가합니다.
테스트 시나리오 설계
공정한 비교를 위해 여러 시나리오를 설계했습니다.
시나리오 1: 순수 File Search API
•
Google Gemini File Search: 원본 문서를 직접 업로드하고 Gemini 2.5 Pro로 답변 생성
•
OpenAI File Search: 원본 문서를 직접 업로드하고 Gemini 2.5 Pro로 답변 생성 (공정한 비교를 위해 LLM은 통일)
시나리오 2: 파서 + File Search API
•
STORM Parse → Gemini File Search → Gemini 2.5 Pro
•
경쟁사 B → Gemini File Search → Gemini 2.5 Pro
•
경쟁사 A → Gemini File Search → Gemini 2.5 Pro
•
STORM Parse → OpenAI File Search → Gemini 2.5 Pro
•
경쟁사 B→ OpenAI File Search → Gemini 2.5 Pro
•
경쟁사 A → OpenAI File Search → Gemini 2.5 Pro
시나리오 3: 완전 통합 STORM 솔루션
•
STORM Parse → 자체 벡터 DB → Gemini 2.5 Pro
각 시나리오에서 동일한 270개 질문을 던지고, 응답의 정확성을 평가했습니다. 평가는 정답과의 정확한 일치 여부로 판단했으며, 부분 점수는 부여하지 않았습니다. 이는 엄격한 평가 기준이지만, 실무 환경에서 "거의 맞는" 답변은 종종 "완전히 틀린" 답변만큼 문제가 될 수 있기 때문입니다.
테스트 결과
결과는 다음과 같습니다!
Google Gemini File Search 기준:
•
원본 문서 직접 사용: 68.15% (184/270)
•
경쟁사 B 전처리: 70.74% (191/270)
•
경쟁사 A 전처리: 70.00% (189/270)
•
STORM Parse 전처리: 81.11% (219/270)
OpenAI File Search 기준:
•
원본 문서 직접 사용: 77.41% (209/270)
•
경쟁사 B 전처리: 75.56% (204/270)
•
경쟁사 A 전처리: 78.52% (212/270)
•
STORM Parse 전처리: 86.67% (234/270)
STORM + STORM Parse를 사용했을 때 기준:
•
STORM Parse + 자체 RAG: 91.85% (248/270)
왜 이런 결과가 나왔을까 생각해봅시다.
1.
파서 품질의 결정적 영향: 같은 File Search API를 사용하더라도 파서에 따라 성능이 크게 달라집니다. Gemini File Search에서 원본 대비 STORM Parse 사용 시 12.96%p 향상, OpenAI File Search에서 9.26%p 향상되었습니다.
2.
STORM Parse의 일관된 우수성: 어떤 검색 시스템과 결합하든 STORM Parse가 가장 높은 정확도를 보였습니다.
3.
통합 솔루션의 최고 성능: STORM Parse를 자체 RAG 파이프라인과 함께 사용했을 때 91.85%로 최고 성능을 기록했습니다. 이는 파싱뿐 아니라 청킹, 검색, 프롬프팅까지 전체가 최적화되었을 때의 결과입니다.
4.
경쟁 파서들의 한계: LlamaParse와 Upstage DP도 원본보다는 나은 결과를 보였지만, STORM Parse만큼의 개선은 이루지 못했습니다. 특히 OpenAI File Search에서 LlamaParse가 원본보다 오히려 낮은 점수를 기록한 것은 흥미롭습니다. 이는 잘못된 파싱이 검색을 오히려 방해할 수 있음을 시사합니다.
5.
단순히 정확도 수치를 넘어서, 각 시스템이 어떤 유형의 질문에서 실패했는지 분석해보면 다음과 같습니다.
Gemini File Search 원본의 주요 오류:
•
복잡한 표의 특정 셀 값 추출 실패 (약 35%의 오류)
•
차트 내 수치 오독 또는 누락 (약 25%의 오류)
•
다단 레이아웃에서 텍스트 순서 혼동 (약 20%의 오류)
•
이미지 내 중요 정보 누락 (약 20%의 오류)
STORM Parse 적용 후 개선된 부분:
•
표 관련 질문: 68% → 89% 정확도
•
차트 관련 질문: 62% → 85% 정확도
•
레이아웃 복잡도가 높은 문서: 71% → 83% 정확도
특히 표와 차트가 많은 경제 보고서와 교과 과정 문서에서 STORM Parse의 개선 효과가 두드러졌습니다.
실전 적용 시나리오: STORM Parse가 빛나는 순간들
벤치마크 수치를 넘어서, 실제 기업 환경에서 STORM Parse가 어떻게 활용될 수 있는지 구체적인 시나리오를 통해 살펴보겠습니다.
시나리오 1: 금융 기관의 투자 보고서 분석
한 자산운용사는 매일 수십 개의 애널리스트 보고서, 기업 공시 자료, 시장 분석 리포트를 검토해야 합니다. 이러한 문서들은 재무제표, 실적 차트, 밸류에이션 테이블 등 복잡한 표와 그래프가 가득합니다.
일반적인 파서를 사용하면 "2024년 1분기 영업이익이 전년 동기 대비 몇 퍼센트 증가했는가?"같은 질문에 정확히 답하기 어렵습니다. 표의 특정 셀을 찾고, 헤더와 연결하여 의미를 파악하고, 수식을 계산해야 하는데, 파싱 단계에서 구조가 무너지면 이 모든 과정이 불가능해집니다.
STORM Parse는 재무제표의 각 행을 완전한 문장으로 변환합니다. "2024년 1분기 영업이익은 1,250억원으로 전년 동기 1,100억원 대비 13.6% 증가했습니다." 이런 식으로 변환되면 RAG 시스템이 정확히 검색하고 답변할 수 있습니다.
실제로 한 금융 고객사는 STORM Parse 도입 후 투자 의사결정에 필요한 정보 검색 시간을 평균 70% 단축했다고 보고했습니다. 더 중요한 것은 정확도 향상으로 잘못된 수치로 인한 의사결정 오류 리스크가 크게 감소했다는 점입니다.
시나리오 2: 제조업체의 기술 문서 관리
한 대형 제조업체는 수천 개의 부품 사양서, 조립 매뉴얼, 품질 관리 문서를 관리합니다. 생산 현장 직원들이 특정 부품의 규격, 조립 순서, 안전 주의사항 등을 빠르게 찾을 수 있어야 합니다.
이러한 문서들은 상세한 치수 표, 조립 순서 다이어그램, 경고 아이콘이 포함된 안전 지침 등으로 구성됩니다. 단순 텍스트 추출로는 "빨간색으로 강조된 경고"나 "화살표로 표시된 순서" 같은 시각적 정보를 포착할 수 없습니다.
STORM Parse의 VLM 기반 접근은 이러한 시각적 정보를 텍스트로 변환합니다. "주의: 부품 A를 먼저 장착한 후 (빨간색 화살표 참조) 부품 B를 시계 방향으로 90도 회전하여 고정합니다. 토크는 15Nm이며, 과도한 힘을 가하면 나사산이 손상될 수 있습니다 (경고 아이콘 표시됨)."
이렇게 변환된 정보는 현장 직원들이 자연어 질문으로 필요한 정보를 즉시 찾을 수 있게 해줍니다. "부품 B 조립 시 주의사항"이라고 검색하면 정확한 절차와 경고사항을 모두 제공받을 수 있습니다.
시나리오 3: 법률 사무소의 계약서 검토
법률 사무소는 다양한 계약서, 판례, 법령을 다룹니다. 계약서는 복잡한 조항 구조, 참조 관계, 예외 사항 등이 중첩된 문서입니다.
"계약 해지 조건이 무엇인가요?"라는 질문에 답하려면 제8조 2항, 부록 A의 예외 사항, 제12조의 통지 절차를 종합해야 할 수 있습니다. 문서의 구조와 참조 관계가 정확히 파싱되지 않으면 불완전하거나 잘못된 답변을 생성할 수 있습니다.
STORM Parse는 계약서의 계층적 구조를 보존하면서도 각 조항을 독립적으로 이해 가능한 형태로 변환합니다. "제8조 2항에 따르면 계약 해지는 다음 조건에서 가능합니다. 첫째, 30일 전 서면 통지 (제12조 통지 절차 참조). 둘째, 상대방의 중대한 계약 위반. 다만 부록 A에 명시된 불가항력 상황은 예외로 합니다."
이런 식으로 조항 간 참조 관계가 명시적으로 표현되면, RAG 시스템이 여러 관련 조항을 함께 검색하여 완전한 답변을 제공할 수 있습니다.
시나리오 4: 헬스케어 기관의 임상 연구 문헌 검토
병원이나 제약회사는 수많은 임상 연구 논문, 의료 가이드라인, 환자 데이터를 다룹니다. 이러한 문서들은 통계 표, 생존율 곡선, 약물 반응 그래프 등 데이터 시각화가 핵심입니다.
"A 약물과 B 약물의 5년 생존율을 비교하세요"같은 질문에 답하려면 Kaplan-Meier 생존 곡선을 정확히 해석해야 합니다. 단순 OCR로는 그래프의 축 레이블과 수치만 추출할 뿐, 곡선의 추세나 두 그룹 간 차이를 포착하지 못합니다.
STORM Parse는 생존 곡선을 다음과 같이 설명합니다. "그림 2의 Kaplan-Meier 곡선은 A 약물 그룹(파란색 선)과 B 약물 그룹(빨간색 선)의 5년 생존율을 비교합니다. A 약물 그룹의 5년 생존율은 약 72%이며, B 약물 그룹은 약 68%입니다. 통계적으로 유의한 차이를 보였습니다(p=0.031)."
이러한 상세한 설명을 통해 의료 전문가들이 신속하고 정확하게 문헌의 핵심 정보를 파악할 수 있습니다.
온프레미스 및 프라이빗 클라우드 구축
STORM Parse의 또 다른 중요한 장점은 클라우드 API 형태뿐만 아니라 온프레미스(On-Premise) 또는 프라이빗 클라우드 환경에서도 구축 가능하다는 점입니다. 이는 보안과 규제 준수가 중요한 산업에서 특히 중요합니다.
보안 및 규제 준수
금융, 의료, 공공, 국방 등의 산업에서는 데이터가 외부로 전송되는 것 자체가 규제 위반이 될 수 있습니다. 개인정보보호법, 의료법, 금융 관련 법규 등이 데이터의 외부 전송을 제한하거나 금지합니다.
클라우드 API를 사용하면 문서를 외부 서버로 보내야 하므로 이러한 요구사항을 충족할 수 없습니다. 반면 STORM Parse를 자체 인프라에 구축하면 모든 데이터 처리가 내부에서 이루어지므로 규제를 준수하면서도 AI의 이점을 활용할 수 있습니다.
성능 및 비용 최적화
대량의 문서를 지속적으로 처리하는 환경에서는 API 호출 비용이 빠르게 증가합니다. 또한 네트워크 지연으로 인해 처리 시간이 길어질 수 있습니다.
온프레미스 구축 시 초기 투자 비용은 있지만, 장기적으로는 API 호출 비용보다 경제적일 수 있습니다. 또한 내부 네트워크를 통해 처리하므로 지연 시간이 최소화됩니다. 특히 GPU 자원을 효율적으로 활용하면 대량 배치 처리 시 클라우드 API보다 훨씬 빠른 처리가 가능합니다.
커스터마이징 및 통합
온프레미스 구축 시 기업의 특수한 요구사항에 맞게 STORM Parse를 커스터마이징할 수 있습니다. 특정 문서 형식에 대한 최적화, 자체 VLM 모델 통합, 기존 시스템과의 긴밀한 통합 등이 가능합니다.
또한 SLA(Service Level Agreement)를 명확히 정의하고, 장애 발생 시 신속한 대응이 가능합니다. 클라우드 API의 경우 서비스 제공자의 장애나 정책 변경에 영향을 받지만, 자체 구축 시에는 완전한 통제권을 갖습니다.
지속적인 연구 개발
사이오닉은 현재의 STORM Parse 성능에 만족하지 않고, 더 고도화된 문서 이해 기술을 위해 적극적으로 연구 개발을 진행하고 있습니다.
TL-DPO: 시각적 환각 감소
최근 사이오닉 연구팀은 "Stop learning it all to mitigate visual hallucination, Focus on the hallucination target"이라는 제목의 논문에서 TL-DPO(Target-Limited Direct Preference Optimization)라는 새로운 접근법을 제안했습니다.
Multimodal Large Language Models(MLLM)은 강력하지만 시각적 환각 문제를 겪습니다. 이미지에 없는 객체를 "본다"고 하거나, 잘못된 설명을 생성하는 것입니다. TL-DPO는 환각이 발생하는 특정 대상에 집중하여 학습하는 선호 학습 방법입니다.
이 연구는 STORM Parse의 2단계 VLM 변환 단계의 정확도를 더욱 향상시킬 것입니다. 환각이 줄어들면 문서 파싱의 신뢰성이 높아지고, 프로덕션 환경에서 안정적으로 사용할 수 있습니다.
결론: 문서 파싱이 RAG의 성패를 좌우한다
지금까지 Google Gemini File Search API와 STORM Parse를 비교한 벤치마크 결과와 기술적 차별점을 상세히 살펴보았습니다. RAG 시스템의 성능은 문서 파싱 품질에 크게 좌우되며, STORM Parse는 업계 최고 수준의 파싱 품질을 제공한다는 것이 다시 한번 증명되었습니다.
270개 질문에 대한 체계적인 테스트를 통해 STORM Parse가 Google Gemini File Search 대비 약 23.7%p, OpenAI File Search 대비 약 9.26%p 높은 정확도를 보인다는 것을 검증했습니다. 같은 검색 시스템을 사용하더라도 STORM Parse로 전처리한 문서를 사용하면 12.96%p(Gemini 기준) 성능이 향상되었습니다.
이러한 성능 차이는 STORM Parse의 독특한 기술적 접근에서 비롯됩니다. VLM을 활용한 시각적 의미 이해, 2단계 변환 구조를 통한 안정성 확보, 자연어 형태의 출력으로 RAG 최적화, 이 모든 요소가 결합되어 탁월한 결과를 만들어냅니다.
예제 코드를 통한 더욱 자세한 활용 예시를 참고하고 싶으시다면 하기 GitHub에서 예제 코드를 확인해보시는 것도 추천드립니다.
STORM Parse는 그 출발점을 가장 높은 수준으로 보장합니다. 여러분의 RAG 시스템이 더 정확하고, 더 신뢰할 수 있고, 더 유용한 답변을 제공할 수 있도록, STORM Parse가 함께하겠습니다.
STORM Parse 및 STORM Platform을 테스트하고 싶으신 분들은, https://www.sionic.ai/ko 에 접속 하여 회원가입 후 자유롭게 테스트 가능합니다.