CAE 기술 문서 질의응답 환경에서 청크 기반 RAG는 문서 구조와 검색 단위 간 

불일치로 인해 한계를 보인다. 기술 동향 1회에서는 기존 RAG 방식의 문제점을, 

2회에서는 제안 아키텍처와 검증 결과를 다룬다.

1. 서론 - 문제의 배경과 출발점

(1) CAE 엔지니어의 LLM 활용 장벽

Abaqus로 대표되는 상용 유한요소해석(FEM) 소프트웨어의 공식 문서는 Fundamental, Function Step 등 제품 전반에 걸친 광범위한 내용을 담고 있으며, 분량은 수만 페이지에 이른다. 해석 엔지니어의 실무적 질문에 답하기 위해서는 이 방대한 문서에서 관련 내용을 정확히 찾아 문맥과 함께 이해해야 한다. 전통적으로 이러한 탐색은 엔지니어 개인의 경험과 문서 구조에 대한 암묵지에 크게 의존해 왔으며, 숙련도에 따라 동일한 질문의 해결 시간이 수 분에서 수 일까지 차이가 나는 경우도 적지 않다. 그림 1은  방대한 기술 문서 사이에서 하나의 질문에 대한 답변을 찾기 위해 전문가가 검토해서 판단해야 하는 예를 보여주는 그림이다.

대규모 언어모델(LLM)의 등장은 이러한 문제를 해결할 수 있는 대안으로 기대되었다. 그러나 ChatGPT, Claude, Gemini와 같은 범용 LLM은 상용 CAE 소프트웨어의 구체적인 기능과 상세한 절차를 실무에서 요구되는 수준으로 내재하고 있지 않으며, 답변의 재현성이 부족하고 환각(hallucination)이 발생할 가능성도 높아 실제 업무에 적용하는 데는 한계가 있었다. 따라서 신뢰할 수 있는 문서를 기반으로 검증된 지식을 제공하는 검색 증강 생성(Retrieval-Augmented Generation, RAG) 계열 접근이 현실적인 대안으로 판단되었다.

(2) 초기 설계: 표준 청크 기반 RAG의 채택

초기의 시스템은 업계에서 널리 사용되는 청크(chunk) 기반 RAG 아키텍처를 채택하였다. 수만 페이지에 달하는 원본 문서에서 텍스트를 추출한 후 Markdown(MD) 형식으로 변환하고, 이를 일정한 토큰 단위의 청크로 분할하였다. 이후 bge-m3 임베딩 모델을 이용해 각 청크를 벡터화하여 ChromaDB에 저장하고, 질의 시 코사인 유사도를 기준으로 상위 k개의 청크를 검색하여 로컬 추론 모델(Ollama 기반 Gemma3 및 Qwen2.5 계열)의 컨텍스트로 제공하는 구조를 구성하였다. 또한 사용자 인터페이스(UI)는 Streamlit을 사용하여 구현하였다.

이 설계에는 두 가지 중요한 제약 조건이 있었다. 첫째는 보안 요구사항이다. 기업 내부 기술 자료의 외부 유출을 방지하기 위해 시스템은 완전한 온프레미스(on-premise) 환경에서 동작하도록 설계하였다. 둘째는 하드웨어 제약이다. 본 시스템은 고성능 GPU 서버나 전산 부서의 지원을 전제로 하지 않고, 해석 엔지니어 개인이 업무용 노트북에서 직접 구축하고 운용할 수 있는 것을 목표로 하였다. 고성능 워크스테이션을 전제로 한 시스템은 일부 사용자만 활용할 수 있지만, 일반적인 업무용 노트북에서 동작하는 시스템은 대부분의 엔지니어가 활용할 수 있기 때문이다.

실제 개발 환경은 RTX A1000 노트북 GPU(VRAM 4 GB)를 탑재한 일반적인 업무용 노트북이었다. 이러한 환경에서는 4-bit 양자화된 8~14B 규모의 로컬 LLM이 사실상 운용 가능한 상한이었으며, 실효 컨텍스트 윈도우 역시 4K~32K 토큰 수준으로 제한되었다. 따라서 수만 페이지에 달하는 전체 문서를 하나의 컨텍스트 윈도우에 포함시키는 것은 현실적으로 불가능했으며, 문서를 청크 단위로 분할하는 과정은 선택이 아니라 필수였다. 또한 제한된 4 GB VRAM 안에서 임베딩 모델(bge-m3)과 로컬 추론 모델이 메모리를 함께 사용해야 했기 때문에, 검색을 통해 가져올 수 있는 청크 수도 4~5개 수준으로 제한할 수밖에 없었다.

결국 당시의 하드웨어 환경은 문서를 ‘조각으로 분할하는 것’과 ‘그 조각 가운데 극히 일부만 검색하는 것’을 시스템 설계의 전제로 강제하였다. 뒤에서 자세히 설명하겠지만, 초기에는 이러한 청킹 전략이 최적의 설계라고 판단하였다. 그러나 시행착오를 거치면서, 청킹은 본질적으로 가장 우수한 방법이 아니라 당시의 하드웨어 제약이 강제한 차선의 선택이었다는 사실을 확인하게 되었다.

2. 전개 - 청크 기반 RAG의 단계별 시행착오

(1) 첫 번째 시행착오 : 수식/표 손실

먼저 파이프라인의 최상류인 데이터 변환 단계에서 첫 번째 품질 저하가 발생하였다. 초기 변환 스크립트는 매뉴얼의 본문 텍스트를 비교적 안정적으로 추출했지만, 수식은 깨진 기호열로 변환되거나 통째로 누락되었고, 표는 행·열 구조가 붕괴되면서 내용이 일부 유실되었다. 당시에는 “본문만 유지되면 검색과 답변에는 충분하다”는 판단 아래 이를 큰 문제로 인식하지 않았다. 그러나 시간이 지나면서 손상된 Markdown(MD) 자체가 파이프라인 전체 성능의 상한선을 결정하는 병목이라는 사실을 확인하게 되었다. 이후 임베딩 모델을 교체하고, 청크 크기를 조정하며, 프롬프트를 반복적으로 개선하는 등 하류 단계를 지속적으로 최적화했지만, 원본 변환 과정에서 소실된 수식과 표는 어떠한 방법으로도 복원할 수 없었다.

이러한 손실이 치명적이었던 이유는 FEM 문서의 도메인 특성에 있다. Theory Guide 수준의 문서에서 수식은 단순한 보조 자료가 아니라 본문의 핵심 내용이다. 약형(weak form)의 유도, 요소 강성행렬의 적분, 접촉 제약의 정식화(penalty, Lagrange multiplier, augmented Lagrange) 등은 수 페이지에 걸쳐 연속적인 수식 전개로 설명되며, 중간의 수식 하나만 누락되어도 전후 문맥 전체의 의미가 크게 훼손된다. 표 역시 마찬가지이다. 요소 라이브러리, 수렴 판정 기준, 키워드 파라미터 등은 표 전체가 하나의 의미 단위를 구성하므로, 행이나 열 구조가 무너지거나 일부 행이 분리되는 순간 정보로서의 가치가 사실상 상실된다. 다시 말해, 줄글 중심의 일반 문서를 암묵적으로 전제로 설계된 범용 문서 변환 도구는 FEM 기술 문서의 특성을 충실히 보존하기 어려웠다.

이를 해결하기 위해 Markdown 변환 파이프라인에 Gemini Flash의 비전(Vision) 기능을 도입하였다. 문서 페이지를 이미지로 렌더링한 뒤 Gemini가 시각적으로 내용을 인식하도록 함으로써, 수식은 LaTeX 형식으로 변환하고 표는 원래의 행·열 구조를 유지한 채 추출하도록 방식을 변경하였다. 그 결과 수식과 표의 보존율이 크게 향상되었으며, 이후 단계의 검색 및 응답 품질도 함께 개선되었다.

(2) 두 번째 시행착오: 청크 경계에 의한 의미 단위의 절단

데이터 변환 품질을 개선한 이후에도 답변 품질은 기대에 미치지 못하였다. 원인을 추적한 결과, 청킹(chunking) 단계에서는 두 번째 구조적 손상이 발생하고 있음을 확인하였다. 당시 인덱싱 스크립트는 Markdown(MD) 문서를 H2/H3 헤더를 기준으로 1차 분할한 뒤, 청크당 최대 4,000자를 기준으로 다시 분할하는 방식을 사용하였다. 그러나 이러한 기계적 분할은 수식 유도의 중간, 표의 중간, 키워드 설명의 중간을 무차별적으로 절단하였다.

청크 크기, 오버랩(overlap), 최소 병합 길이 등 조정 가능한 모든 파라미터를 대상으로 반복적인 실험을 수행했지만, 어떠한 조합으로도 의미 단위를 보존하면서 청킹하는 데에는 한계가 있었다. 원인은 FEM 문서가 갖는 두 번째 도메인 특성인 강한 상호참조성(cross-referentiality)에 있었다. FEM의 개념들은 독립적으로는 존재하지 않는다. 예를 들어 CONTACT PAIR의 파라미터는 별도 섹션에서 정의된 서피스(SURFACE)를 전제로 하고, COUPLED TEMPERATURE-DISPLACEMENT 해석의 수렴 제어는 다른 장에서 설명되는 CONTROLS와 함께 이해되어야 비로소 의미가 완성된다. 즉, 하나의 청크만으로 완결된 설명을 구성하기는 어렵다.

결국 청킹 최적화가 실패한 이유는 파라미터 튜닝의 부족이 아니라, ‘문서는 독립적인 의미 조각의 집합으로 분할할 수 있다’는 청킹의 기본 전제 자체가 이 도메인에서는 성립하지 않았기 때문이다.

(3) 세 번째 시행착오: 임베딩 유사도 검색의 구조적 한계

세 번째 문제는 검색(retrieval) 단계에서 드러났다. bge-m3는 한·영 혼합 문서에 우수한 성능을 보이는 임베딩 모델이었지만, 코사인 유사도 기반의 Top-k 검색은 CAE 질의에서 일관된 한계를 보였다. 

관찰된 실패 양상은 크게 세 가지였다. 

첫째, 유사도 점수는 정보의 완전성을 반영하지 못하였다. 표면적인 어휘가 유사하면 수식이나 표가 누락된 청크와 의미가 온전한 청크를 동일하게 평가하였고, 그 결과 정보가 손상된 청크가 오히려 상위에 검색되는 경우가 빈번하였다.

둘째, C3D8R·STEP·DYNAMIC과 같은 기호 중심의 식별자는 의미 임베딩 공간에서 충분한 변별력을 갖지 못하였다. 이러한 토큰들은 자연어적 의미가 거의 없기 때문에 임베딩 공간에서 서로 유사한 위치에 분포하는 경향을 보였다.

셋째, 실무 질의의 상당수는 본질적으로 종합형 질문이었다. 예를 들어 “XFEM과 Cohesive Zone Model의 차이”를 설명하려면 서로 다른 강의(예: Lecture 12와 Lecture 14)에 위치한 내용을 동시에 검색해 하나의 문맥으로 결합해야 한다. 그러나 Top-k 검색에서는 필요한 두 문서가 동시에 검색 결과에 포함되지 않는 경우가 빈번하였으며, 실험을 통해 이러한 현상이 반복적으로 확인되었다.

(4) 네 번째 시행착오: 파일 구조 최적화 실험과 예상 밖의 발견

청킹 기반 접근의 한계가 분명해지자, 소스 파일의 구성 단위 자체를 변경하는 실험을 수행하였다. 슬라이드 단위로 분리된 666개 파일, 강의 단위로 병합한 약 20개 파일, 주제 단위 약 10개 파일 그리고 전체를 하나로 통합한 단일 파일의 네 가지 구성을 비교하였다. 실험 결과, 파일당 약 5,000~ 30,000단어 수준이 검색 정확도와 관리 편의성 사이에서 가장 균형이 좋은 구성임을 확인하였다. 이를 위해 강의 병합 스크립트와 대용량 가이드 분할 도구도 별도로 개발하였다.

당시 이 실험의 목적은 청킹의 성능을 높이기 위해 소스 구조를 최적화하는 것이었다. 그러나 결과적으로 가장 중요한 수확은 다른 곳에 있었다. 강의 단위로 병합된 Markdown 파일 하나하나가 그 자체로 완결된 의미 단위를 이루고 있었던 것이다. FEM 교육 자료와 매뉴얼은 애초에 Guide–Chapter–Lesson의 계층 구조를 기반으로 조직되어 있으며, 계층 구조 자체가 인간 저자가 설계한 최적의 의미 분할이라 할 수 있다. 이러한 관찰은 이후 검색 단위를 청크가 아닌 PDF 전체 파일로 설정할 수 있다는 발상의 출발점이 되었다.

참고 문헌 (초안 단계 주요 항목)

•Chan, B. J., Chen, C.-T., Cheng, J.-H., & Huang, H.-H. (2024). Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks. arXiv:2412.15605. 

•Li, X., Cao, Y., Ma, Y., & Sun, A. (2025). Long Context vs. RAG for LLMs: An Evaluation and Revisits. arXiv:2501.01880. 

•Li et al. (2024). Retrieval Augmented Generation or Long-Context LLMs? 

A Comprehensive Study and Hybrid Approach. 

•Li et al. (2025). LaRA: Benchmarking Retrieval-Augmented Generation and Long-Context LLMs. 

•기타 관련 연구: Agent-based RAG, embedding-free retrieval(ELITE), LongRAG, OP-RAG, CAG 등.

cipark@alten-korea.com