생성형 AI는 안정적인데, 왜 RAG는 불안정해질까
요즘 기업에서 생성형 AI를 도입하는 흐름은 정말 빠르죠.
내부 문서를 붙여서 우리 회사 기준으로 답해주는 챗봇, 사내 지식 검색, 고객센터 자동 응답까지… 활용 범위도 점점 넓어지고 있고요.
특히 RAG를 붙이면 기대가 더 커집니다.
“모델이 기억에 의존하지 않고, 문서를 찾아서 근거를 들고 오니까 더 안정적이겠지?”
이런 생각이 자연스럽거든요.
그런데 실제 운영 환경에서는 이런 말이 자주 나옵니다.
“근거 문서는 가져오는데, 결론이 어딘가 엇나가요.”
“표 기반 질문은 유독 수치가 흔들려요.”
“같은 질문인데 표현을 조금만 바꾸면 답이 달라져요.”
“그럴듯하긴 한데, 결국 사람이 마지막에 확인하게 돼요.”
이 지점이 참 난감합니다.
모델이 나쁜가? 싶어서 모델을 바꿔보기도 하고, 프롬프트를 손대보기도 하죠.
그런데 이상하게도 같은 RAG 모델을 쓰는데도 조직마다 결과 안정성이 달라요.
어떤 팀은 이 정도면 쓸 만하다까지 가는데, 어떤 팀은 결국 사람이 검수해야 한다에서 계속 멈춥니다.
그 차이는 어디서 생길까요?
많은 경우, 그 출발점은 Parser 설계에서 시작됩니다.
RAG 약자보다 더 중요한 것, 검색의 품질
RAG는 Retrieval-Augmented Generation의 약자입니다.
말 그대로 검색(Retrieval) 해서, 생성(Generation) 한다는 구조죠.
그런데 RAG를 처음 도입할 때는 시선이 자연스럽게 Generation 쪽으로 갑니다.
어떤 LLM을 쓰면 좋을까?
컨텍스트 윈도우를 더 크게 쓰면 해결될까?
재랭킹 모델을 붙이면 안정될까?
다 중요한 고민이에요.
다만 기업 환경에서는 한 단계 앞에서 멈춰 생각해 볼 필요가 있습니다.
검색 품질이 낮으면, 생성 품질은 구조적으로 흔들립니다.
그리고 검색 품질이 낮을 때 벌어지는 일은 꽤 명확해요.
LLM은 잘못된 근거를 보고도 그럴듯하게 추론합니다.
재랭킹(Re-ranking)은 엉뚱한 문서를 더 위로 올리기도 합니다.
컨텍스트 윈도우는 불필요한 정보로 채워지고, 정작 필요한 근거는 빠집니다.
결국 생성 단계는 입력을 넘어서서 답할 수 없습니다.
그리고 그 입력을 만드는 첫 단추가 바로 문서가 어떻게 구조화되었는지, 즉 Parser 설계입니다.
Parser는 단순 추출이 아닌 데이터 표현 설계 계층입니다
RAG 파이프라인을 한 줄로 적어보면 보통 이렇게 정리됩니다.
문서 → Parser → 구조화 데이터 → 의미 단위 분할 → Embedding → Vector DB → 검색 → Re-ranking → Generation
많은 조직이 Embedding 모델이나 Vector DB 튜닝에 힘을 줍니다. 그 선택이 중요하다는 것도 맞습니다.
그런데 여기서 놓치기 쉬운 사실이 하나 있어요.
Embedding은 입력 텍스트가 어떤 방식으로 표현되었는지에 전적으로 의존합니다.
즉, 벡터화는 원본 문서가 아니라 Parser가 만들어낸 표현물을 기준으로 일어납니다.
그래서 Parser 단계에서 이미 이런 질문들이 결정돼요.
문서의 계층이 보존되는가 (제목–섹션–본문의 위계가 살아 있는가)
표 구조가 유지되는가 (행·열 관계가 남아 있는가)
메타데이터가 포함되는가 (작성일/버전/문서 유형 같은 정보가 붙는가)
의미 단위 경계가 정확한가 (자르는 기준이 자연스러운가)
이 요소들이 결국 벡터 공간의 품질을 좌우하고, 벡터 공간의 품질이 검색 품질을 좌우합니다. 그래서 Parser는 텍스트를 뽑는 도구가 아니라, 데이터 표현을 설계하는 계층으로 보는 게 더 정확합니다.
Layout Analysis가 정확도를 좌우하는 이유
여기서 구조화를 말할 때 빠지면 안 되는 키워드가 하나 있습니다.
바로 Layout Analysis(레이아웃 분석)입니다.
Layout Analysis는 문서의 시각적·논리적 구조를 인식합니다.
사람이 문서를 볼 때 자연스럽게 파악하는 구조를, 기계가 따라잡게 해주는 단계라고 보면 이해가 쉬워요.
구체적으로는 이런 것들을 다룹니다.
제목의 계층 깊이 (어디까지가 제목이고 어디부터가 본문인가)
단락 간 포함 관계 (이 문단은 어떤 섹션에 속하는가)
표의 행·열 매핑 (헤더와 값이 어떻게 연결되는가)
캡션과 본문 연결 (이 표 설명이 어떤 표에 붙는가)
다단 구성 레이아웃 정렬 (좌/우 컬럼이 섞이지 않는가)
이 구조 정보는 단순 텍스트로는 표현되지 않습니다.
그래서 Layout Analysis가 없으면 흔히 이런 일이 생깁니다.
제목과 본문이 동일 가중치로 벡터화됩니다.
(중요도 구분이 흐려져요.)
표의 열-행 관계가 손실됩니다.
(숫자는 남지만 의미가 사라집니다.)
항목-값 매핑이 붕괴됩니다.
(“이 숫자가 뭘 의미하지?”가 해결되지 않습니다.)
결과적으로 Embedding은 의미 단위가 아니라 텍스트 조각을 학습합니다.
검색이 흔들리는 건 자연스러운 결과죠.
Parser는 텍스트 추출이 아니라 구조 보존이 핵심입니다
RAG를 운영하면서 Parser를 붙였습니다.라고 말하는 팀은 많습니다.
그런데 성능 차이를 가르는 건, Parser가 있느냐/없느냐보다 어떤 방식으로 파싱 하느냐인 경우가 많아요.
구분 | 단순 텍스트 추출 | 구조 보존 Parser 설계 |
|---|---|---|
데이터 표현 | 평면 텍스트 | 계층적 객체 |
Embedding 품질 | 부분 의미 반영 | 맥락 단위 반영 |
검색 Precision | 낮음 | 높음 |
재랭킹 신호 | 제한적 | 메타데이터 기반 강화 |
수치 해석 | 문자열 매칭 | 관계 기반 해석 |
이 차이는 기능이 더 많다/적다의 문제가 아닙니다.
정보가 보존되었는지, 손실되었는지의 문제입니다.
RAG는 정보 손실에 특히 민감합니다.
근거가 조금만 엇나가도 답변은 그럴듯하게 틀릴 수 있으니까요.
PDF parser 설계가 특히 중요한 이유
기업 문서의 상당수는 PDF입니다.
그래서 현실의 RAG는 종종 PDF parser 성능과 거의 동의어가 되기도 합니다.
PDF parser가 단순 문자열 추출에 머무르면 문서는 논리 구조를 잃습니다.
표현이 조금 세게 들릴 수 있지만, 실제 운영에선 이게 그대로 드러나거든요.
예를 들어 이런 표를 생각해 볼게요.
분기 | 매출 | 영업이익 |
|---|---|---|
2Q | 200억 | 30억 |
표가 텍스트로만 변환되면 행-열 관계가 사라집니다.
Embedding은 <영업이익 30억> 같은 토큰은 학습하지만,
<2분기–영업이익–30억> 이 묶인 관계는 온전히 유지되지 못합니다.
그래서 이런 현상이 나타납니다.
Vector 검색은 비슷한 숫자를 잘 가져올 수는 있지만
정확한 의미 단위로 근거를 가져오기는 어렵습니다.
이 상태에서 고성능 RAG 모델을 붙이는 건,
입력 데이터의 손실을 모델이 알아서 보정해 주길 기대하는 것과 비슷합니다.
물론 모델을 바꾸는 것도 방법일 수 있습니다.
하지만 비용이 큽니다. 반면 Parser 구조 개선은 훨씬 근본적이고, ROI 관점에서도 우선순위가 달라질 수 있습니다.
Chunk를 어떻게 자르느냐가 검색 결과를 좌우합니다
여기서 많은 팀이 Chunk를 어떻게 자르지?에서 막힙니다.
고정 길이 Chunk는 구현이 쉬워서 많이 쓰이죠.
그런데 이 방식은 정보 이론 관점에서 손실을 유발합니다.
문제가 되는 지점은 크게 두 가지입니다.
1) 의미 단위 분리
하나의 조항이 두 Chunk로 나뉘면 검색 Recall이 떨어집니다.
필요한 근거가 반쪽만 검색되기 시작하거든요.
2) 맥락 혼합
서로 다른 의미 단위가 한 Chunk에 섞이면 Precision이 떨어집니다.
“이 문단이 이 질문에 맞는 근거인가?”가 흐려집니다.
그래서 의미 단위 기반 분할은 이런 것을 지키려는 전략입니다.
문단 경계 유지
표 블록 유지
조항 단위 유지
제목-본문 연결 유지
이 전략이 결국 검색의 안정성을 만듭니다.
메타데이터는 재랭킹의 핵심 신호입니다
기업 환경에서 정답은 종종 텍스트에만 있지 않습니다.
최신성, 버전, 문서 유형 같은 조건이 정답을 가르는 경우가 많죠.
그래서 메타데이터는 선택이 아닙니다.
작성일 → 최신성 가중치
버전 → 정책 변경 반영
문서 유형 → 질의 적합도 강화
중요도 → 신뢰도 가중치
Parser 단계에서 이 정보가 구조화되지 않으면, Re-ranking은 단순 유사도 기반으로만 작동합니다. 기업 환경에서 이것이 치명적인 이유는, 비슷한 문서가 항상 맞는 문서는 아니기 때문입니다.
RAG 단점으로 보이는 현상의 실제 원인
RAG 단점으로 흔히 지적되는 현상들이 있습니다.
긴 문서일수록 정확도 저하
수치 질문 오류
응답 편차 발생
그런데 이 문제들 중 상당수는, 사실 Embedding 이전 단계에서 이미 시작됩니다.
데이터 표현이 불완전하면 벡터 공간도 불완전합니다.
그리고 모델은 입력을 초과해서 추론할 수 없습니다.
모델이 똑똑하면 되지 않나?라는 질문이 나오곤 하는데,
현실은 반대로 흘러갑니다.
입력이 흔들리면, 똑똑한 모델일수록 더 그럴듯하게 틀릴 수 있습니다.
그래서, 당신의 Parser는 몇 단계입니까
마지막으로 아주 현실적인 질문 하나만 던져볼게요.
우리 시스템의 Parser는 지금 몇 단계까지 와 있을까요?
Layout Analysis 기반 구조 인식이 가능한가
표의 행·열 관계를 유지하는가
문서 계층 구조를 보존하는가
메타데이터를 재랭킹 신호로 활용하는가
의미 단위 기반 Chunk 전략을 적용하는가
이 중 절반 이상이 아직이라면,
RAG 모델을 바꾸기 전에 Parser 설계를 먼저 점검하는 것이 더 합리적일 수 있습니다.
결론 :
RAG는 단순한 생성 기술이 아닙니다. 구조 위에서 작동하는 아키텍처입니다.
그리고 Retrieval의 품질은 Parser 설계에서 결정됩니다.
Parser는 단순 추출 도구가 아니라, 기업 문서를 AI가 이해 가능한 형태로 재구성하는 데이터 표현 설계 계층입니다.
RAG의 안정성을 높이고 싶다면, 모델 튜닝보다 Parser 구조 설계가 먼저입니다.
결국 그 차이가, 같은 모델에서도 결과의 안정성을 갈라놓습니다.
