LLM(대형 언어 모델)을 기업 환경에 도입할 때, 내부 정보 기반의 RAG(검색 증강 생성, Retrieval-Augmented Generation) 파이프라인을 구축하게 됩니다. 보안이 필요한 기업 내부의 정보를 기반으로 업무에 도움을 받기 위해서는, 안전하게 내부 정보를 통해 작동하는 생성형 모델 RAG가 자연스럽게 뒤따라 나오게 되죠.

RAG 시스템을 처음 만들다 보면, 기본적인 RAG의 DB 구축·검색·답변 생성 등의 컴포넌트를 쉽게 갖다 붙여 사용해볼 수 있는 프레임워크인 LangChain이나 LlamaIndex만으로도 꽤 훌륭하게 작동하는 것처럼 보입니다. 실제로 검색 대상 문서를 넣고 질의응답 기능을 이어 붙이면, 우리가 상상했던 Naïve RAG 시스템을 꽤 쉽게 완성할 수 있습니다. 하지만 이 코드를 실제 기업 데이터에 적용하는 순간, 우리는 종종 예상치 못한 난관에 부딪히며 기대처럼 나오지 않는 결과물을 마주하게 됩니다.

이 시리즈에서는 튜토리얼 수준의 RAG가 실무에서 어떻게 한계를 드러내는지, 그리고 이를 엔지니어링으로 어떻게 풀어나가고 있는지 공유하고자 합니다.

1. 왜 RAG인가? — LLM의 한계와 검색 증강 생성(RAG)의 장점

2020년 Meta(당시 Facebook) AI 리서치 팀의 논문 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」(Lewis et al., 2020, arXiv:2005.11401)에서 처음 등장한 RAG(검색 증강 생성)는, LLM이 가진 고질적인 ‘지식의 한계’를 외부 데이터 검색으로 돌파하며 업계의 많은 이목을 이끌었습니다.

RAG의 작동 원리는 직관적입니다. 사용자의 질문과 관련된 문서를 외부 데이터베이스에서 검색(Retrieval)한 뒤, 그 문서를 컨텍스트로 삼아 LLM이 답변을 생성(Generation)하는 구조입니다.

우리가 굳이 복잡한 파이프라인을 구성하며 RAG를 도입하는 이유는, LLM이 가진 태생적인 한계를 명확한 장점으로 상쇄해 주기 때문입니다.

하지만 이 완벽해 보이는 파이프라인을 프로덕션 환경에 올렸을 때, 우리는 답변의 품질이 급격히 저하되는 현상을 겪습니다. 도대체 무엇이 문제일까요?

2. 채찍 효과(Bullwhip Effect): RAG 데이터 정제가 중요한 이유

물론 RAG 시스템에서 검색(Retrieval) 모델의 임베딩 성능이나 생성(Generation)을 담당하는 LLM의 추론 능력도 답변 품질에 큰 영향을 미칩니다. 하지만 실무 파이프라인에서 가장 치명적인 병목은 의외로 가장 앞단인 ‘데이터 정제(Data Ingestion)’ 단계에서 발생합니다.

공급망 관리(SCM)에서 소비자 수요의 작은 변동이 상류로 갈수록 눈덩이처럼 커지는 현상을 ‘채찍 효과’라고 합니다. RAG 파이프라인에서도 마찬가지입니다. 초기 문서 파싱 단계에서 발생한 작은 텍스트 유실이나 엉킨 구조는 임베딩 벡터 공간에서의 위치를 완전히 틀어지게 만들고(Retrieval 실패), 결국 LLM에게 오염된 컨텍스트를 전달하여 엉뚱한 답변(Generation 실패)을 유도합니다.

데이터 전처리가 제대로 되지 않은 상태에서 검색 알고리즘을 튜닝하거나 더 큰 파라미터의 LLM을 도입하는 것은, 밑빠진 독에 물을 붓는 것과 같습니다.

3. 실무 데이터의 민낯: 기본 파서(Parser)의 한계

일반적인 RAG 튜토리얼에서는 잘 정제된 TXT 파일이나 단일 단락으로 이루어진 깔끔한 PDF를 예시로 사용합니다. 그러나 실전에서 다뤄야 하는 기업의 데이터(제조 공정 지침서, 연구 보고서, 재무 제표 등)는 극도로 복잡합니다.

단순한 오픈소스 텍스트 파서(Parser)로 실무 PDF나 스캔본을 읽어 들이면, 다단 편집된 글의 읽기 순서(Reading Order)가 무시되거나 이미지 속 중요한 텍스트는 통째로 증발해 버립니다. 문서를 ‘읽는’ 것조차 실패하는 것입니다.

3-A. OCR과 VLM: 시각적 이해를 통한 1차 방어선

기존 단순 텍스트 추출의 한계를 극복하기 위해 업계가 도입한 훌륭한 무기가 바로 OCR(광학 문자 인식)과 VLM(시각 언어 모델)입니다.

• OCR: 이미지나 스캔된 문서에서 글자의 형태를 인식해 텍스트로 변환해 주는 기술입니다.
• VLM: LLM이 텍스트만 이해한다면, VLM은 ‘눈’을 달아 문서 전체의 시각적 형태를 이해하는 모델입니다.

실제 VLM과 고성능 OCR은 비정형 데이터를 처리하는 데 있어 강력한 성능을 자랑합니다. 스캔본에 갇혀 있던 글자를 뽑아내고, 문서의 대략적인 구조를 텍스트로 변환하여 많은 파싱 문제를 성공적으로 커버하고 있습니다. RAG 파이프라인에서 시각적 이해 모델의 도입은 이제 선택이 아닌 필수가 되었습니다.

3-B. 복잡한 레이아웃과 병합 셀 — VLM으로도 남는 숨은 문제

VLM을 통해 문서에서 텍스트를 무사히 ‘추출’해 냈다고 해서 RAG에 바로 쓸 수 있는 것은 아닙니다. 추출된 텍스트가 임베딩 모델과 LLM이 이해하기 좋은 ‘논리적 컨텍스트’로 구성되어 있는가는 완전히 다른 문제이기 때문입니다.

• 복잡한 레이아웃의 문맥 단절: 머리말, 꼬리말, 각주, 페이지 번호 등이 본문 텍스트와 섞여 들어가면 검색 품질이 크게 떨어집니다. 또한 1단 페이지가 아닌 2단, 심지어 3~4단의 레이아웃을 넘나들며 데이터가 이어지는 흐름을 파악하기 어려운 구조가 등장하기도 합니다.
• 표(Table)와 병합 셀의 저주: 기업 실무자들은 중요한 정보를 복잡한 다중 헤더(Multi-level header)와 병합된 셀을 가진 ‘표’로 정리합니다. 이를 VLM이나 OCR로 단순히 읽어 내리기만 하면, 특정 데이터가 어떤 행과 열의 기준(Header)에 속하는지 연결 고리가 끊어져 버립니다.

3-C. AIWORKX의 데이터 전처리: 검색 맞춤형 데이터로의 변환

AIWORKX(에이아이웍스)는 VLM이 훌륭하게 추출해 낸 원시 데이터를 바탕으로, LLM이 문맥을 완벽히 이해할 수 있도록 파이프라인에 세밀한 엔지니어링을 가미하고 있습니다.

• Elements별 Tagging (문서의 구조적 분해): 문서를 단순 텍스트가 아닌, 시각적·논리적 구조를 바탕으로 Header(제목), Text(본문), Meta(머리말/꼬리말), Image, Table 등 요소별로 태깅하여 분리합니다. 이를 통해 쓸데없는 정보가 컨텍스트를 오염시키는 것을 막고, 쪼개진 청크(Chunk)들이 어느 상위 헤더에 속해 있는지 문맥을 보존합니다.
• Table Serialization (표 직렬화): 가장 난해한 표 데이터를 처리하는 핵심 기술입니다. Table로 분류된 데이터를 LLM이 직관적으로 이해할 수 있는 1차원적인 텍스트 형태로 ‘직렬화(Serialization)’합니다. 셀을 단순 나열하는 것이 아니라, 각 데이터 값이 어떤 기준(행/열 헤더)에 속하는지 명시적인 메타데이터로 엮어내는 것이죠. 이를 통하면 병합 셀에 대한 정보의 깨짐이나 표 정보의 누락 등의 문제를 현저히 완화할 수 있습니다.

4. 파서 품질이 RAG 성능에 미치는 영향 — L0·L1·L2 비교 실험

그렇다면 이렇게 세밀하게 정제된 데이터는 최종 답변 퀄리티에 어느 정도의 영향을 미칠까요? 이를 확인하기 위해 동일한 문서, 동일한 임베딩, 동일한 LLM을 사용하는 환경에서 오직 ‘파서(Parser)의 수준’만 3단계로 변경하여 질의응답 성능을 비교해 보았습니다. 테스트 실험은 3개의 문서와 5개의 질의로 진행했으며, 단답식 질의 유형으로 구성해 EM(Exact Match)을 평가 지표로 사용했습니다.

[파서의 3단계 설정]

4-A. 파서별 RAG 정답률 비교 (40% → 80% → 100%)

신용평가사 등급표, 농촌 매거진, 복잡한 다단 레이아웃의 지자체 소식지 등 실무 난이도를 반영한 문서들을 대상으로 질의를 수행한 결과는 다음과 같습니다.

단순 흐름 텍스트(초지 CO₂ 흡수량)는 세 파서 모두 쉽게 정답을 맞혔습니다. 즉, RAG의 실제 검색 성능은 데이터를 어떻게 “잘 정제”해서 저장했는지에 큰 영향을 받습니다.

※ 위 표는 5개 질의 중 대표 4개를 보인 것입니다. 표본이 작으므로 정답률은 절대 성능이 아니라 경향을 보여주는 데모입니다. EM(Exact Match) 너머 무엇을 ‘정답’으로 볼지 — 평가 지표 설계와 도메인 특화 평가셋 구축 — 는 3편에서 본격적으로 다룹니다.

4-B. 잘못된 전처리가 부르는 나비효과 — 확신에 찬 오답과 검색 누락

실제 LLM이 받아본 컨텍스트(청크)를 뜯어보면 그 영향을 명확히 확인할 수 있습니다.

① 표가 뒤섞여 만들어낸 “확신에 찬 오답” (좌우 병렬 표)

신용평가 문서에는 ‘기업어음 신용등급표’와 ‘기업신용평가표’가 한 페이지에 좌우로 나란히 배치되어 있었습니다. L0 기본 파서는 열(Column)을 감지하지 못하고 이 두 표를 가로로 한 줄씩 뒤섞어 읽어버렸습니다. 그 결과, L0 파서를 거친 RAG는 “기업어음 A2 등급의 정의”를 묻는 질문에 엉뚱하게도 옆에 있던 ‘기업신용평가 A등급’의 정의를 가져와 오답을 내놓았습니다. 금융권 문서에서 등급과 정의가 뒤바뀌는 것은 매우 위험한 오류입니다. 반면 다단 구조와 요소를 분리한 L1, L2 파서는 정답을 올바르게 도출해 냈습니다.

② 검색 누락을 구출하는 직렬화(Serialization)의 힘

L1 파서가 표를 마크다운으로 잘 보존하더라도, 한계점은 존재합니다. 표의 크기가 커서 여러 개의 청크(Chunk)로 쪼개질 경우, 헤더 행(기준)과 데이터 행(값)이 물리적으로 분리되어 검색 엔진이 매칭에 실패하는 현상입니다. “회사채 A등급의 평균누적부도율 중 광의 기준 수치”를 묻는 질문에서 L1 파서는 관련 문서를 찾지 못해 답변에 실패했습니다. 하지만 직렬화(Serialization)를 거친 L2 파서는 이를 찾아낼 수 있었습니다.

L2(AIWORKX)를 거쳐 LLM에 입력된 컨텍스트
“A 등급은 원금 상환 가능성은 높지만 …, 규정 연간부도율 0.00, 광의 연간부도율 0.00, 규정 평균누적부도율 0.26, 광의 평균누적부도율 1.30을 기록한다.”

셀을 단순히 나열한 것이 아니라, 위처럼 각 숫자가 어떤 헤더에 속하는지 ‘자기완결성 있는 문장’으로 엮어냈기 때문입니다. 질의 키워드와 숫자 값이 하나의 청크 안에 온전히 존재하므로 안정적인 검색과 답변이 가능해집니다.

“좋은 RAG 파이프라인을 만들기 위해서는, 좋은 데이터 전처리가 수반되어야 한다.”

지금까지 실무 RAG 적용을 위한 첫 걸음, 비정형 데이터의 전처리에 대해 논해보았습니다. 다음 2편에서는 범용 임베딩 모델이 특수 도메인에서 갖는 한계를 짚어보고, 이를 라우팅 에이전트와 온톨로지로 풀어내는 ‘검색 파이프라인의 설계’를 다루겠습니다. 이어 3편에서는 이렇게 만든 RAG의 성능을 ‘어떻게 정량적으로 증명할 것인가’ — 평가 지표와 도메인 특화 데이터셋 구축 — 를 다룹니다.

자주 묻는 질문 (FAQ)

Q1. RAG 성능이 낮은 가장 흔한 원인은?

검색 모델이나 LLM보다 앞단의 데이터 전처리(파싱)가 낮은 성능의 원인인 경우가 많습니다. 표와 레이아웃이 깨진 채 임베딩되면 검색 단계부터 실패합니다.

Q2. RAG에서 표(Table) 데이터 검색이 잘되려면 어떻게 처리해야 하나요?

셀을 단순 나열하지 말고, 각 값이 어떤 행·열 헤더에 속하는지 명시하는 표 직렬화(Table Serialization)로 자기완결적 문장을 만들어야 합니다.

Q3. OCR과 VLM의 차이는 무엇인가요?

OCR은 이미지·스캔본에서 글자를 텍스트로 인식하는 기술이고, VLM(시각 언어 모델)은 문서 전체의 시각적 구조까지 이해하는 모델입니다.

Q4. 파서 품질에 따라 RAG 정확도가 얼마나 달라지나요?

동일 문서·임베딩·LLM 조건에서 파서만 바꿨을 때 정답률이 40%(기본) → 80%(구조 인식) → 100%(표 직렬화)로 나타났습니다.

Q5. 기업이 RAG를 도입할 때 가장 먼저 점검할 것은?

검색 튜닝이나 더 큰 LLM보다, 비정형 문서의 전처리(파싱) 품질을 먼저 점검해야 합니다.

관련 글 · 다음 편

• 다음 편: 범용 임베딩 모델의 한계와 라우팅 에이전트·온톨로지로 푸는 검색 파이프라인 설계 (실전 RAG 파이프라인 구축기 ②, 발행 예정)
• 3편: RAG, 도대체 어떻게 평가할 것인가 — 지표와 도메인 특화 데이터셋 (실전 RAG 파이프라인 구축기 ③, 발행 예정)
• AI 에이전트 평가, 왜 기존 LLM 벤치마크로는 부족한가
• AI 에이전트 검증 체계, 어떻게 설계하는가
• AI를 만드는 시대에서, 검증하는 시대로