[Tech Series] kt cloud AI 검색 증강 생성(RAG) #2 : 데이터 파싱과 전처리 최적화

Tech Story/Tech Inside

[Tech Series] kt cloud AI 검색 증강 생성(RAG) #2 : 데이터 파싱과 전처리 최적화

kt cloud 기술 블로그 2025. 9. 29. 11:01

[ kt cloud 마케팅커뮤니케이션팀 김지웅 님 ]

📋 요약

RAG 시스템에서 데이터 파싱과 전처리가 검색 품질에 미치는 핵심 영향을 분석합니다.

정형·반정형·비정형 데이터별 최적화 전략과 효율적인 자동화 파이프라인 설계 방안을 제시합니다.

#RAG #데이터파싱 #전처리 #검색증강생성 #AI

들어가며 💭

안녕하세요, kt cloud 테크 마케터 김지웅입니다. 🙋‍♂️

RAG 시리즈 1편에서 아키텍처와 핵심 구성 요소를 다뤘는데, 많은 분들이 이런 질문을 해주셨어요.

"RAG 구조는 이해했는데... 실제로 데이터를 어떻게 준비해야 하나요?" 🤔

정말 핵심을 짚은 질문이에요. 아무리 훌륭한 LLM과 벡터 검색 엔진을 갖춰도, 데이터 준비 단계에서 실수하면 모든 게 무너져요. 특히 기업 환경에서는 PDF 보고서, 웹페이지, 데이터베이스, 심지어 손글씨 스캔본까지... 정말 다양한 형태의 데이터를 다뤄야 하거든요.

그런데 막상 이런 데이터들을 RAG에 넣어보면 예상과 다른 결과가 나오는 경우가 많아요. 표가 깨져서 엉뚱한 숫자가 나오거나, 광고 텍스트가 답변에 섞여 들어가거나, 코드가 알아볼 수 없게 변형되는 식으로요.

"왜 이런 일이 생기는 걸까? 어떻게 해야 깔끔하게 처리할 수 있을까?"

이번 2편에서는 바로 이런 궁금증에 답해보려 해요. 데이터 유형별 파싱 전략부터 품질 관리, 자동화 운영까지 실무에서 바로 써먹을 수 있는 노하우를 차근차근 정리해보겠습니다. 🛠️

1. 왜 파싱이 RAG 품질을 좌우하는가 🔍

📑 1.1 데이터 소스 다양성과 난제들

RAG가 처음 맞닥뜨리는 큰 장벽은 데이터 소스의 다양성이에요. 기업은 PDF 보고서, DB·CSV, 로그, 웹페이지 HTML, API 응답, 이미지·코드·동영상까지 폭넓은 데이터를 다루죠. 이제 단순 텍스트 처리에서 벗어나 멀티모달 데이터를 전제로 생각해야 해요.

그런데 데이터가 많아질수록 파싱 난이도와 리스크가 함께 커져요. 각 소스마다 구조와 노이즈 패턴이 달라서 “일단 텍스트만 뽑자” 접근으로는 금방 한계가 드러납니다. 유형별로 자주 마주치는 이슈를 살펴볼게요.

PDF: 스캔·표·수식·그래프가 뒤섞여 OCR 오류나 레이아웃 손실이 잦아요.
DB/CSV: 스키마 변경·컬럼 불일치가 생기면 사실 자체가 왜곡되기 쉬워요.
로그: 대량·시계열 특성이라 잡음 제거에 실패하면 무의미한 결과가 쏟아져요.
웹/HTML: 광고·내비·댓글이 본문을 압도해 검색 정확도를 깎아요.
API 응답: 버전·필드 정의가 바뀌면 최신성과 일관성이 금방 깨져요.
이미지·코드: 파서 성능이 부족하면 텍스트 추출은 되어도 의미 보존이 안 돼요.

이런 오류는 단순한 데이터 손실로 끝나지 않아요. 임베딩→검색→생성 전 단계에 연쇄적으로 번지며 품질을 흔들죠. 실제로 한 글로벌 기업은 고객지원 문서 파싱 오류로 챗봇 답변이 흔들려 고객 만족도가 27% 하락하는 손실을 겪은 적이 있어요. 📉

잘못 파싱된 데이터는 임베딩 품질을 저하시켜 검색 단계에서 의미적 유사성을 왜곡합니다. 그러면 LLM은 틀린 전제를 기반으로 추론을 이어가게 되고, 그 결과 환각(hallucination) 가능성도 높아지죠. 여기에 최신성·일관성 관리까지 소홀하다면 동일한 사실이 서로 다른 값으로 저장되면서 시스템 신뢰도는 급격히 떨어집니다. 이런 현상을 더 잘 이해하려면, RAG가 따르는 가장 기본적인 원칙을 떠올려야 해요.

♻️ 1.2 Garbage In, Garbage Out 원칙

Garbage In, Garbage Out(GIGO)은 “잘못된 입력은 잘못된 출력으로 이어진다”는 원칙입니다. RAG에서도 예외가 아니에요. Garbage는 잘못 파싱되거나 불완전한 데이터, Out은 그 데이터를 근거로 생성된 LLM의 답변을 뜻하죠. 결국 이 단순한 격언이 RAG 성패를 좌우하는 기준이 됩니다.

많이 걱정하는 환각 문제도 이와 맞닿아 있어요. 지식 베이스가 부정확하거나 비어 있다면 모델은 빈칸을 두지 않고 내용을 지어내요. 해외 연구진 등(2024)의 연구에서도 RAG 실패 원인 1순위로 “지식 베이스의 필요한 콘텐츠 부재”가 지목되었고, 실제로 정제되지 않은 로그를 그대로 투입한 챗봇이 전혀 다른 답변을 한 사례도 보고되었어요.

작은 오류도 파급이 커요. 깨진 문자나 오타는 임베딩 의미를 왜곡해 중요한 정보가 검색에서 빠지게 만들고, 광고·각주 같은 비본질 텍스트는 LLM 응답에 불필요한 문장을 끼워 넣을 수 있어요.

이런 위험을 줄이려면 데이터 품질 기준을 바탕으로 점검해야 해요.

정확성(Accuracy): 사실·표기 오류가 없는가
완전성(Completeness): 질문에 충분히 답할 수 있는가
일관성(Consistency): 형식과 표현이 통일되어 있는가
고유성(Uniqueness): 불필요한 중복은 없는가
최신성(Timeliness): 최신 정보를 반영하는가

최근에는 이를 지원하는 도구와 전략도 많이 활용되고 있어요. OpenAI의 Evals는 오류 원인이 데이터인지 모델 한계인지 구분해주고, 클라우드 기업들은 PDF·CSV 같은 복잡한 구조를 보존하는 파서와 품질 검사 모듈을 전처리에 추가하고 있죠.

결국 RAG 파이프라인의 성패는 이 단순한 원칙에 달려 있어요. 좋은 데이터를 넣어야 좋은 답변이 나온다.

즉 Garbage In을 막기 위한 철저한 파싱과 정제가 무엇보다 중요한 이유입니다. 💡

2. 데이터 유형별 파싱 전략 🗂️

📊 2.1 정형 데이터(DB, CSV 등)

정형 데이터는 이름 그대로 구조가 명확히 정의된 데이터예요. 관계형 데이터베이스, CSV, 엑셀 파일이 대표적이고, 행과 열이 뚜렷하며 스키마(schema)가 있어서 겉보기에는 가장 다루기 쉬운 데이터처럼 보여요.

하지만 RAG 관점에서는 조금 달라져요. 핵심 문제는 “구조를 어떻게 보존할 것인가”예요. 🏗️
예를 들어 DB 데이터를 단순히

Cloud VM Instance, 10, 2025-01-01

처럼 값만 나열하면, 임베딩 모델은 이 값들이 어떤 맥락에서 나온 건지 알 길이 없어요. 반대로

Resource: Cloud VM Instance, Usage Fee: 10,000원, Created: 2025-01-01

처럼 컬럼명과 함께 표현하면 맥락이 살아나고, LLM이 질문과 데이터를 훨씬 정확하게 연결할 수 있습니다.

연구 결과에서도 스키마 정보를 포함한 데이터가 검색 정확도를 눈에 띄게 높여준다고 보고되었어요. 결국 정형 데이터 파싱의 핵심은 아주 단순합니다. 👉 “값만 뽑지 말고 구조까지 보존하라.”

구체적인 방법은 다음과 같아요.

텍스트 변환: 테이블을 행 단위로 풀어 문장 형태로 변환
- 장점: 간단하고 바로 벡터화 가능
- 단점: 대규모 테이블에는 비효율적
SQL 질의 기반 접근: 질문을 SQL로 변환해 DB에서 직접 결과 가져오기
- 장점: 정확성 높음
- 단점: 스키마가 복잡하면 LLM이 쿼리 생성에 실패할 수 있음

최근에는 두 방식을 결합한 하이브리드 접근도 주목받고 있어요. 예를 들어 TableRAG(Chen et al., 2025)는 SQL로 데이터를 뽑은 뒤, 그 결과를 다시 텍스트 검색과 결합했는데요. 이 방식으로 정확도가 10~20% 향상되었다고 합니다.

산업 현장 사례도 있어요. 금융 데이터나 재고 관리 시스템에서 스키마와 시간 순서를 보존했더니, 복합 질의 응답 정확도가 30% 개선된 경험이 보고되었죠.

정형 데이터는 단순해 보이지만, 사실은 구조 보존이라는 함정을 품고 있는 데이터예요. 이 구조를 제대로 살려낼 때 RAG의 성능이 크게 끌어올려집니다.

🧩 2.2 반정형 데이터 (JSON, HTML, 로그)

반정형 데이터는 말 그대로 구조와 비구조가 섞여 있는 데이터예요. JSON, HTML, 로그 파일이 대표적이죠. 얼핏 보면 일정한 포맷을 따르는 것 같지만, 실제로는 중첩 구조나 가변 스키마, 불필요한 노이즈 때문에 그대로는 RAG에서 활용하기가 어렵습니다.

전략은 한 문장으로 정리할 수 있어요. 🎯“구조는 살리고, 잡음은 없애라.”

🔷 JSON: 계층 구조를 어떻게 풀어낼까?

JSON은 API 응답, 클라우드 서비스 설정, 사용자 프로필 데이터 등에서 사실상 표준 포맷처럼 쓰여요. 하지만 막상 다뤄보면 중첩 구조 때문에 난제가 생겨요. 단순히 평면화(flatten)해서 값만 나열하면 관계 정보가 끊겨버리기 때문이죠.

예를 들어

{ 
  "user": { 
    "name": "김케클", 
    "contacts": [
      {"type": "email", "value": "kim@ktcloud.com"}
    ] 
  }
}

이걸

김케클, email, kim@ktcloud.com

처럼 값만 뽑아내면, 모델은 이 값들의 연결 고리를 파악하기 어려워요.

대신 이렇게 경로(path)를 포함해 풀어내면 훨씬 명확해져요.

user.name: 김케클  
user.contacts[0].type: email  
user.contacts[0].value: kim@ktcloud.com

이 방식이라면 “김케클의 이메일 주소는 뭐야?” 같은 질문도 정확히 매칭되죠. 실제로 JSON Path 기반 추출 방식을 적용했을 때 검색 품질이 개선됐다는 연구 결과도 보고된 바 있어요.

전자상거래 기업 사례도 흥미로워요. 고객 주문 JSON에서 상품 ID, 수량, 배송 주소를 구조적으로 보존해 파싱했더니, 주문 추적 챗봇의 응답 정확도가 크게 향상됐다고 합니다.

🔷 HTML: DOM 구조를 버리지 말라

웹 문서를 파싱할 때 흔히 하는 실수가 있어요. <h1>, <p> 같은 태그를 다 지우고 본문만 뽑는 방식인데, 이렇게 하면 문맥이 붕괴돼 버립니다. 제목, 본문, 댓글, 답변이 뒤섞여 혼란스러워지는 거죠.

최근에는 HTML을 마크다운(Markdown) 같은 구조적 표현으로 변환하는 방법이 권장돼요. 예를 들어 <h2>는 ##, <li>는 리스트 항목으로 바꿔서 문서의 계층을 드러내는 거예요. 동시에 광고, 네비게이션, 푸터 같은 불필요한 영역은 사전에 제거하는 게 필수고요.

Databricks 실험에서도 DOM 구조를 보존했을 때 Q&A 매칭 정확도가 확연히 올라갔다고 해요. 반대로 구조를 무시하면 질문과 무관한 답변이 자주 튀어나오는 문제가 있었다고 합니다. 실제로 한 글로벌 SaaS 기업은 고객지원 포털의 HTML 페이지를 마크다운 변환 + 광고 제거로 전처리했는데, FAQ 검색 성공률이 18% 개선됐다고 보고했어요.

🔷 로그: 시간과 패턴을 챙겨라

로그 데이터는 반정형 데이터 중에서도 특히 다루기 까다로운 유형이에요. 서버나 애플리케이션 로그는 형식은 있어도 메시지는 자유롭고, 양도 방대하죠.

그래서 로그 파싱에는 보통 이런 전략을 씁니다:

필드 분리 → 타임스탬프, 로그 레벨(ERROR/WARN/INFO), 모듈명은 메타데이터로 따로 저장
메시지 추출 → 실제 오류·이벤트 텍스트만 임베딩
중복·압축 → 동일 패턴이 수천 개라면 대표 케이스로 묶어 저장
시간 윈도우 → 5분·10분 단위로 묶어 시계열 청크 생성

이 과정을 거치면 단순히 나열된 문자열 로그가 아니라, “지난주 결제 시스템 오류 패턴” 같은 질문에도 대응할 수 있는 구조화된 지식으로 변해요. Pathway(2024) 보고서에서도 단순 문자열 로그보다, 패턴화·클러스터링된 로그를 활용했을 때 RAG 기반 장애 분석 정확도가 크게 올라갔다고 해요.

🖼️ 2.3 비정형 데이터 (PDF, PPT, 이미지, 코드 등)

비정형 데이터는 말 그대로 정해진 틀이 거의 없는 데이터예요. PDF 리포트, PPT 슬라이드, 스캔 문서, 이미지, 소스코드 등이 여기에 해당하죠. 사람이 보기엔 자연스러운 문서라도, 기계 입장에서는 그대로 이해하기 어렵습니다. 그래서 RAG 파이프라인에서는 “사람이 읽던 의미와 맥락”을 어떻게 파싱 단계에서 지켜낼 것인가가 핵심 과제가 됩니다.

🔷 PDF와 PPT: 레이아웃이 곧 맥락이다

PDF는 단순 텍스트처럼 보여도 실제로는 표, 이미지, 머리말/바닥글, 다단 레이아웃이 얽혀 있어요. 텍스트만 추출하면 관계가 쉽게 깨져버립니다.

예를 들어 “분기별 클라우드 리소스 사용량” 표를 줄 단위로 추출하면

Q1 100TB Q2 120TB

처럼 붙어버려서 의미가 왜곡돼요. 반대로 열=분기, 행=사용량 구조를 보존하면 “2분기 사용량은 얼마인가요?” 같은 질문에도 정확히 대응할 수 있습니다.

실무에서는 pdfplumber(표 추출), PyMuPDF(본문 추출), Camelot·Tabula(표 구조화) 같은 도구를 조합해 활용하곤 해요. PPT의 경우는 슬라이드 단위로 묶어 제목 + 불릿 구조를 보존하는 게 중요합니다. 이렇게 하면 LLM이 슬라이드 전체 맥락을 파악하기 쉬워져요.

🔷 이미지·스캔 문서: OCR과 순서 복원

계약서 스캔본이나 데이터센터 설비 사진 속 텍스트는 OCR 없이는 활용이 불가능하죠. 여기서 중요한 건 정확도와 읽기 순서예요.

Tesseract → 가볍지만 복잡한 레이아웃에는 취약
DocTR, TrOCR → 무겁지만 표·필기체·다단 레이아웃까지 잘 인식

OCR 결과는 종종 순서가 뒤섞이기도 해요. 예를 들어 병렬 단락이 있으면 “A1 → B1 → A2 → B2”처럼 엉켜 나오는데, 이를 좌→우, 상→하 흐름으로 복원해야 원래 맥락이 살아납니다.

🔷 코드 문서: 구조와 주석까지 데이터다

코드는 들여쓰기, 괄호, 키워드, 주석까지 모두 의미를 담고 있어요. 단순 텍스트화하면 맥락이 무너져요.

예를 들어 Python 코드를 들여쓰기 없이 파싱하면 함수·블록 구조가 사라집니다. 그래서 개행·들여쓰기·코드 블록(python ...)을 반드시 유지해야 해요. 주석과 독스트링도 중요한 설명 데이터로 함께 남겨야 합니다.

임베딩 단계에서는 일반 모델보다 CodeBERT, CodeT5 같은 코드 특화 모델이 효과적이에요. 함수 호출 구조와 의미를 반영하기 때문이죠. 실제로 GitHub 사례에서도 CodeBERT 적용 후 유사 코드 검색 정확도가 개선된 것으로 보고됐습니다.

비정형 데이터는 결국 사람이 읽던 맥락을 기계에도 전달하는 게 관건이에요. 🔑

PDF/PPT → 레이아웃과 표 구조 보존
이미지/스캔 → OCR + 순서 복원
코드 문서 → 포맷 유지 + 코드 전용 임베딩

이 과정을 충실히 거쳐야 RAG에서 비정형 데이터도 신뢰할 수 있는 지식 소스로 자리잡을 수 있어요.

⭐ 한 단계 더 들어가 보기: OCR·코드 파싱 시 고려사항

비정형 데이터 중에서도 특히 까다로운 게 OCR과 코드 파싱이에요. 단순히 텍스트를 추출하는 게 아니라, 원래 구조와 맥락을 얼마나 충실히 복원하느냐가 RAG 품질을 좌우합니다. 🎯

🔷 OCR: 정확도만큼 중요한 레이아웃

2025년 현재 OCR 기술은 빠르게 발전 중이에요.

MiniCPM-o → 8B 파라미터, 1.8MP급 이미지를 모바일·엣지 환경에서도 빠르게 처리
H2OVL-Mississippi → 경량 모델이지만 대형 모델에 필적하는 성능, 온디바이스 배포 적합
Tesseract → 여전히 가볍고 빠르지만 복잡한 레이아웃엔 약점
TrOCR, DocTR, EasyOCR → 무겁지만 표·다단 레이아웃 처리에 강점

하지만 엔진만 좋다고 끝나지 않아요. OCR 결과물에는 종종 띄어쓰기 오류, 깨진 문자, 불필요한 아티팩트가 섞여 나오거든요. 이를 정제하지 않으면 검색 품질이 떨어집니다. 그래서 보통은

소문자 변환
유니코드 정규화
숫자 그룹핑

같은 전처리를 거친 뒤 임베딩해요. 또 다단 편집·각주 섞임 같은 경우에는 bounding box 기반 순서 복원을 해야 원문 맥락이 지켜집니다.

🔷 코드 파싱: 포맷과 의미를 지켜라

코드 파싱에서는 포맷 보존 + 구조적 메타데이터가 핵심이에요.

추상 구문 트리(AST)를 메타데이터로 저장
함수 시그니처, 클래스 계층, import 관계를 별도로 인덱싱
주석과 독스트링을 함수와 연결

이렇게 하면 자연어 질문 기반 코드 검색 품질이 크게 올라갑니다. 임베딩은 CodeBERT, CodeT5 같은 코드 전용 모델을 쓰는 게 효과적이고요.

보안도 중요해요. 코드 안의 API 키·비밀번호 같은 민감정보는 반드시 마스킹 후 저장해야 합니다. 또 파이썬의 들여쓰기, HTML 특수문자 < > 같은 포맷 요소는 Markdown 코드 블록으로 감싸 보존하는 게 안전합니다.

최근에는 OCR·코드 파싱을 LLM과 직접 결합하는 연구도 많아요. GPT-4o는 이미지를 직접 읽을 수 있고, CodeBERT·CodeT5는 코드와 주석을 함께 이해하죠. 언젠가는 지금처럼 “OCR → 텍스트 변환 → 임베딩” 단계를 거치지 않는 RAG도 가능해질 거예요.

하지만 현재 시점에서는 여전히 정확한 전처리 + 전용 임베딩 모델 조합이 가장 안정적인 방법이에요. 이 단계를 소홀히 하면 청킹·검색·생성 전부가 흔들리게 됩니다.

3. 텍스트 추출·정규화 ✨

🪙 3.1 토큰화, 언어 감지, 불용어 처리

텍스트 추출·정규화 단계에서 가장 먼저 맞닥뜨리는 과제가 토큰화, 언어 감지, 불용어 처리예요. 얼핏 단순한 전처리처럼 보이지만, 사실 이 단계가 임베딩 품질과 검색 정확도를 결정하는 핵심 과정이에요. 🔑

🔷 토큰화(Tokenization): 언어별 최적 방식을 고려하라

토큰화는 텍스트를 모델이 이해할 수 있는 단위로 쪼개는 과정이에요. LLM 생태계에서는 BPE(Byte Pair Encoding), WordPiece, SentencePiece, GPT 계열의 Byte-Level BPE 같은 방식이 주로 쓰이고 있죠.

언어별 최적 방식이 다른 것도 흥미로워요. 영어권에서는 SentencePiece BPE(32k vocab)가 효율적이라 LLaMA2도 이 방식을 채택했어요. 반면 한국어나 터키어처럼 형태소가 풍부한 언어는 형태소 분석 기반 하이브리드 토큰화가 더 유리하다는 연구 결과가 있습니다. 실제 TR-MMLU 벤치마크에서도 형태소+음운 기반 토큰화가 기존 GPT·LLaMA 토크나이저보다 더 높은 성능을 냈다고 해요.

실무에서는 보통 임베딩 모델이 제공하는 토크나이저를 그대로 쓰는 게 기본이에요. 예를 들어 OpenAI의 text-embedding-ada-002는 GPT Byte-Level BPE를 강제로 사용합니다. 개발자가 임의로 바꾸긴 어렵지만, 모델을 고를 때 토크나이저 특성까지 고려하는 게 중요해요.

🔷 언어 감지(Language Detection): 다국어 문서엔 계층적 접근

다국어 문서가 섞여 있다면 언어 감지 → 토큰화 순서를 지키는 게 필수예요. 잘못된 토크나이저를 쓰면 의미 단위가 무너지고 검색 품질도 급격히 떨어져요.

추천되는 방법은 계층적 언어 감지예요.

문서 전체에서 주요 언어를 먼저 식별
문단·문장 단위에서 세부 변화를 추적

이렇게 하면 영어와 한국어가 뒤섞인 기술 문서도 안정적으로 처리할 수 있어요. 보통 fastText, langdetect 같은 라이브러리를 활용하고, 멀티랭 토크나이저(SentencePiece multilingual 등)와 결합하면 효과가 커집니다.

언어 구분은 불용어 처리와도 이어져요. 영어의 “the, is, and”와 한국어의 조사·어미는 성격이 다르기 때문에 언어별 맞춤 규칙이 필요합니다.

🔷 불용어 처리(Stopword Handling): 맥락은 살리고 잡음만 줄여라

전통 IR에서는 불용어 제거가 기본이었지만, 벡터 기반 RAG에서는 다르게 접근해요. 맥락이 중요하기 때문에 불용어도 의미 강화에 기여할 수 있거든요.

그래서 최근에는 도메인 맞춤형 선택적 처리가 주류예요.

법률 문서 → “shall”, “whereas” 같은 단어는 의미를 담고 있어 유지
기업 문서 → 회사명처럼 모든 문서에 반복 등장하는 단어는 제거

즉, 목표는 잡음은 줄이고 맥락은 보존하는 것이에요.

🔷 정규화(Normalization): 코드·수식은 깨뜨리지 말고 보호하라

토큰화와 불용어 처리만 거쳤다고 끝나지 않아요. 파싱된 텍스트에는 여전히 노이즈가 숨어 있죠.

연속 공백은 하나로 축약
불필요한 줄바꿈 제거, 문단 구분은 \n\n 유지
PDF 추출 시 끊긴 단어(infor- mation → information) 복원
대소문자 통일, 구두점 정리

여기서 중요한 건 특수 패턴 보호예요. 코드나 수식을 잘못 손대면 망가져요. 예를 들어 <if (a < b)> 같은 코드를 정규화 과정에서 깨뜨리면 문법이 무너집니다. 그래서 보통은 코드 블록은 Markdown의 ``````, 수식은 $…$로 감싸 안전하게 보존합니다.

토큰화, 언어 감지, 불용어 처리, 정규화는 단순한 전처리가 아니에요. 이 과정을 얼마나 정교하게 설계하느냐가 곧 검색 정확도와 모델 응답 신뢰도로 이어진다고 할 수 있죠.

📐 3.2 표/수식/코드 블록 보존 기법

문서에는 본문 텍스트 외에도 표(table), 수식(formula), 코드 블록(code block) 같은 구조적 요소가 들어 있어요. 이들은 단순한 장식이 아니라 핵심 정보를 담고 있기 때문에, 어떻게 파싱하고 보존하느냐가 RAG의 검색 정확도와 최종 답변 품질을 크게 좌우합니다.

🔷 표 (Table): 행·열 구조를 유지해 맥락을 살려라

표는 행과 열의 관계 속에서 의미를 전달해요.📊 그런데 단순히 텍스트로 풀어버리면 구조가 사라지고 맥락을 잃어버리죠. 최근 연구를 보면, HTML이나 Markdown 형태로 표를 보존했을 때 검색 성능이 가장 높았다고 해요. 복잡한 병합 셀 구조에서도 HTML 방식은 높은 정확도를 달성했다고 합니다.

물론 CSV나 TSV로 변환하면 가볍게 처리할 수 있지만, 복잡한 보고서나 논문의 테이블에서는 맥락 손실이 커요. 따라서 가능하다면 행·열 구조를 유지한 채 파싱하는 것이 바람직합니다.

🔷 수식 (Math): LaTeX·MathML로 원형 그대로 보존하라

과학·기술 문서에서 수식은 텍스트 못지않게 중요한 정보예요. 예를 들어 $E=mc^2$를 평문화해서 “E equals m c squared”라고 바꿔버리면 관련성 평가가 크게 떨어진다는 실험 결과도 있었어요.

그래서 최신 파이프라인에서는 LaTeX($...$)이나 MathML 형태로 수식을 보존하는 방식을 채택해요. 이렇게 하면 사용자가 기호 그대로 질의했을 때 매칭이 가능하고, 특히 연구 논문 같은 도메인에서는 수식 기반 검색 성능이 확실히 향상됩니다.

🔷 코드 블록 (Code block): 들여쓰기와 펜스를 지켜라

코드는 형식 자체가 의미라서 들여쓰기, 괄호, 문법 구조가 깨지면 LLM이 제대로 인식하지 못해요. 그래서 반드시 Markdown 코드 펜스(```)를 유지하고, 원문에 있는 공백과 줄바꿈도 그대로 반영하는 게 좋아요.

연구에 따르면 코드 블록을 보존했을 때 개발자 대상 RAG 시스템의 사용자 만족도가 40% 이상 개선되었다고 해요. 구문 하이라이팅은 필수는 아니지만, 코드와 본문을 시각적으로 구분하는 데 도움이 되기 때문에 실무에서는 자주 활용되고 있어요.

🔷 메타데이터와 문맥 연결: 본문 맥락과 연결해 의미를 강화하라

표·수식·코드 같은 요소는 본문과 연결될 때 의미가 더 강해져요. 그래서 최근에는 단순 보존을 넘어, “이 표가 어떤 절에 속하는지”, “이 수식이 어떤 알고리즘 설명과 이어지는지” 같은 정보를 메타데이터로 함께 저장하는 방식이 주목받고 있어요.
이렇게 하면 검색 정확도가 높아질 뿐만 아니라, 사용자가 결과를 검증할 때도 문맥을 쉽게 이해할 수 있어요.

핵심은 복잡한 문서의 구조적 요소를 단순화하지 않고 원래 형태를 최대한 보존하는 것입니다. 표는 표답게, 수식은 수식답게, 코드는 코드답게 다뤄야만 검색과 답변의 신뢰성을 확보할 수 있습니다.

🧹 3.3 특수문자·줄바꿈·메타데이터 정리

텍스트 추출과 토큰화가 끝났다고 해서 전처리가 모두 끝난 건 아니에요. 실제로 파싱된 문서를 보면 여전히 깨진 특수문자, 엉뚱한 줄바꿈, 반복되는 메타데이터 같은 잔여 노이즈가 가득하죠. 이런 요소들이 남아 있으면 임베딩 품질이 떨어지고, 검색 정확도도 쉽게 왜곡돼요. 그래서 마지막 정규화 단계에서는 “노이즈는 걷어내되, 중요한 정보는 살리는 균형”이 꼭 필요합니다.

🔷 특수문자 처리: 의미 없는 건 제거, 중요한 건 변환·보존

PDF나 OCR을 거친 문서에는 종종 특수문자가 섞여 들어가요. 예를 들어

대체문자 �(U+FFFD)
제어문자 \x0c
의미 없는 장식 기호나 이모지
HTML 파싱 후 남은 &,   같은 엔티티

대부분은 의미 없는 토큰만 늘리므로 제거하는 게 좋아요. 다만 수학 기호(α, β)처럼 도메인에서 중요한 특수문자는 유지하거나, 필요하다면 LaTeX 기호로 변환하는 게 더 안전해요. 실제로 어느 데이터 카탈로그 기업은 “허용 문자 목록(whitelist)”을 두고, 이외의 특수문자는 자동 필터링하는 정책을 쓰고 있다고 하죠.

🔷 줄바꿈과 공백 정리: 일관성 유지하며 단어 쪼개짐 복원

의도치 않은 개행이나 공백도 큰 문제예요.

문장 중간에 끼어든 개행은 공백으로 바꿔 이어 붙이고,
문단 구분은 \n\n처럼 이중 개행만 남기는 게 일반적이에요.
연속된 공백은 하나로 축약하고, 탭은 공백으로 치환해 일관성을 유지해요.

특히 OCR이나 PDF 추출물에서 흔한 "infor- \n mation" 같은 단어 쪼개짐은 반드시 복원해야 해요. 이런 처리가 안 되면 토큰이 불필요하게 나뉘고, 결국 검색 성능까지 떨어집니다.

🔷 메타데이터 관리: 본문에 섞지 말고 별도 필드에 구조화

페이지 번호, 헤더·푸터, 문서명 같은 반복 메타데이터는 본문에 섞어두면 벡터 유사도를 왜곡해요. 따라서 본문에서는 제거하고, 별도의 메타데이터 필드에 구조화해 저장하는 것이 권장됩니다.

예를 들어

작성일 → 시간 관련 질의에 활용
저자 정보 → 인물 검색에 활용

반대로 챕터 제목이나 섹션 헤딩은 본문에도 남겨두는 게 좋아요. 맥락을 풍부하게 하고, 동시에 메타데이터로도 저장하면 검색 결과 요약이나 출처 표시에서 두 번 활용할 수 있거든요.

🔷 균형 잡힌 정리 전략: 노이즈는 걷고, 정보는 살려라

최근 연구에서도 강조하는 게 바로 “노이즈 제거와 정보 보존 사이의 균형”이에요. 예를 들어 페이지 푸터처럼 반복되는 건 과감히 삭제해야 하지만, 작성일이나 문서 제목은 유지해야 검색 품질이 더 좋아져요. 실제로 금융기관 사례에서도 PDF 파싱 시 페이지 번호와 머리글을 제거했더니 임베딩 품질이 개선됐다는 보고가 있었습니다.

결국 이 단계의 목표는 간단합니다.✅ 본문은 최대한 깨끗하게, 메타데이터는 따로 정리해 활용 가능하게. 이 과정을 거쳐야 비로소 RAG에 맞는 “검색 친화적 파싱 데이터”가 완성됩니다.

4. 데이터 클렌징과 품질 관리 🧼

🧽 4.1 중복·노이즈 제거

RAG 파이프라인에서 데이터 클렌징의 첫 단계는 중복 제거(deduplication)와 노이즈 필터링이에요. 웹 크롤링이나 대규모 말뭉치 데이터에서는 같은 문서가 반복되거나, 거의 동일한 내용이 다른 형태로 존재하는 경우가 흔하죠. 실제 연구를 보면 대규모 웹 데이터셋의 30~60%가 중복 콘텐츠일 정도로 비율이 높다고 해요. 이런 중복을 제거하지 않으면 검색 품질이 왜곡되고, 임베딩 학습에서도 과적합·메모리화 문제가 생길 수 있습니다.

🔷 중복 제거의 효과

중복 데이터가 남아 있으면 검색 결과에 동일한 내용이 반복 노출돼서 다른 유용한 정보가 가려져요. 예를 들어 QA 페어가 중복되어 있으면 같은 답변이 상위 랭킹을 차지해 결과 다양성이 떨어지죠. 한 기업 사례에서는 MinHash 기반 중복 제거를 적용한 뒤, 사용자 질문에 대한 고유 답변 비율이 40% 증가했다고 해요. 또, 벡터DB 크기가 20% 줄면서 검색 속도까지 개선된 사례도 있었어요. LLM 학습 데이터에서도 중복 제거는 모델이 특정 문장을 그대로 암기하는 현상을 줄이는 데 효과적입니다.

🔷 중복 제거 기법

대표적인 방법으로는 SimHash와 MinHash LSH(Locality Sensitive Hashing)가 있어요.

SimHash는 문서의 특징 벡터를 압축해 fingerprint를 만들고, Hamming distance로 유사도를 빠르게 판별해요. Google이 수십억 웹페이지 중복 검출에 활용한 기법으로 알려져 있습니다.
MinHash LSH는 문서를 n-gram 집합으로 보고 여러 해시 함수를 적용해 시그니처를 만든 뒤, Jaccard 유사도를 근사 계산해요. 유사도가 높은 문서는 같은 bucket에 모아 “거의 중복” 문서를 효율적으로 걸러냅니다. 최근에는 GPU 가속화된 FED(Fast and Efficient Dataset Deduplication) 같은 프레임워크도 등장했는데, CPU 대비 2~5배 빠른 속도로 동작하면서도 95% 이상의 정확도를 유지한다고 해요.

실무에서는 보통 정확 해시(SHA-1 등)로 완전히 동일한 문서를 먼저 제거하고, 그 다음 SimHash나 MinHash로 의미적으로 유사한 문서를 그룹화해요. 이때 threshold를 조정해서 번역문처럼 의도된 유사 문서는 남기고 단순 복제는 제거하는 식으로 균형을 맞추는 게 중요합니다.

🔷 노이즈 제거: 저품질·짧은 문서·HTML 파편 필터링

중복 외에도 품질을 해치는 노이즈 데이터는 반드시 걸러야 해요. 예를 들면

의미 없는 placeholder 텍스트(예: “Lorem ipsum”)
자동 생성된 저품질 문서
지나치게 짧아 의미 없는 문서
크롤링 오류로 인한 HTML 파편

이런 경우에는 규칙 기반 필터링(문서 길이 기준, 특정 단어 반복 횟수 제한 등)이나 perplexity 기반 필터를 활용해요. 실제로 여러 기관에서 일정 기준 이상 비정상적인 문장을 제외해 말뭉치 품질을 높이고 있습니다.

🔷 운영 전략: 파이프라인에 dedup 모듈을 넣어 자동화

중복·노이즈 제거는 한 번 하고 끝내는 작업이 아니에요. 새로운 데이터가 주기적으로 유입되는 RAG 시스템에서는 파이프라인 안에 dedup 모듈을 넣어 자동화하는 게 일반적이에요. 이렇게 해야 데이터 코퍼스의 “청정도”를 유지하면서 검색 품질과 리소스 효율을 동시에 확보할 수 있죠.

중복 제거는 검색 품질, 저장 효율, LLM 학습 안정성까지 개선하는 다층적 효과를 가집니다.📈 그래서 벡터DB와 RAG 구축 사례 대부분에서 “중복 제거는 기본”으로 여겨지고 있어요.

🗂️ 4.2 버전 관리와 출처 추적

RAG 시스템은 최신성과 신뢰성이 생명이에요. 이를 뒷받침하는 두 가지 기둥이 바로 데이터 버전 관리와 출처 추적입니다.

🔷 데이터 버전 관리: 최신판만 기본 제공, 과거판은 아카이브로 보존

지식 베이스는 시간이 흐르면서 계속 갱신돼요. 문제는 구버전과 신버전이 섞여 있을 때 발생합니다. 예를 들어 제품 설명서의 1월판과 6월판이 동시에 DB에 남아 있다면, 사용자가 최신 정보를 기대하고 질문했을 때 시스템이 구버전을 인용할 위험이 커요. 이를 막으려면 데이터에 버전 태그를 부여하고, 기본 검색에서는 최신 버전만 포함하되 필요에 따라 과거 버전도 열람할 수 있어야 합니다. 법률이나 규정처럼 개정 이력이 중요한 도메인에서는 이런 방식이 특히 유용해요.

이 과정에서 활용할 수 있는 대표 도구가 DVC(Data Version Control)와 Git-LFS예요.

DVC는 Git과 연동해 대용량 데이터셋과 모델 버전을 관리하며, 어떤 데이터와 파이프라인 버전으로 임베딩이 생성되었는지를 추적할 수 있습니다.
Git-LFS는 대용량 문서 파일의 변경 이력을 효율적으로 관리하는 데 쓰여요.

실무에서는 문서 ID에 버전 정보를 포함하는 단순한 방식도 많이 활용돼요. 예를 들어 Spec_v2.1 같은 ID를 붙이고, 업데이트 시 새 ID로 교체하며 이전 버전은 deprecated 처리하는 식이죠. 필요할 경우 아카이브에서 과거 버전을 다시 불러올 수도 있어요. 더 나아가 스트리밍 데이터가 실시간으로 들어오는 환경에서는 Apache Kafka와 DVC를 결합해 주기적으로 스냅샷을 버전화하고, 문제가 생기면 안정된 버전으로 롤백하는 하이브리드 접근도 연구되고 있습니다.

🔷 출처 추적 (Provenance): 메타데이터로 근거를 기록하고 투명성 확보

출처 추적은 RAG 응답의 투명성과 책임성을 보장해요. 각 텍스트 조각이 언제, 어디서, 어떤 과정을 거쳐 수집·처리됐는지를 기록하면 결과의 신뢰성을 검증하고 오류 원인도 추적할 수 있습니다.

구현 방식은 비교적 단순해요. 임베딩을 생성할 때 문서 ID, 페이지 번호, 섹션 제목, 단락 번호 같은 메타데이터를 함께 저장하는 거예요. 검색 결과를 사용자에게 보여줄 때 이 정보를 링크나 출처로 노출하면, “이 답변이 어디서 나왔는지” 즉시 확인할 수 있죠. 예를 들어 위키백과 기반 RAG에서는 문서 revision ID를 저장해 최신판 기준 검색을 기본으로 하되, 필요 시 과거 판도 검색할 수 있도록 합니다.

산업계도 출처 추적을 강화하는 방향으로 움직이고 있어요.

Microsoft는 GraphRAG 연구에서 LLM이 knowledge graph 상의 노드 출처까지 추론하도록 실험했어요.
IBM은 RAG 응답에 원본 문서 경로를 UI에 표시해 사용자가 직접 검증할 수 있도록 개발 중입니다.
일부 최신 구현에서는 블록체인 기반 불변 기록이나 암호학적 해시를 적용해 데이터 무결성과 감사 가능성을 높이고 있어요.

이러한 출처 관리와 버전 기록은 단순한 품질 문제 해결을 넘어 규제 준수와도 직결됩니다. GDPR이나 EU AI Act 같은 규제는 생성형 AI가 근거를 투명하게 제시할 것을 요구하고 있죠. 금융·의료 같은 도메인에서는 특히 “어떤 데이터로 이 답변이 나왔는가”를 사후에 입증할 수 있는 감사 체계가 필수적입니다.

결국 데이터 버전 관리와 출처 추적은 RAG 시스템이 “신뢰할 수 있는 AI 비서”로 기능하기 위한 기반입니다.🛡️ 최신 정보를 안정적으로 반영하면서도 과거 이력을 투명하게 보존하고, 사용자에게는 답변의 근거를 명확히 제시할 수 있어야 해요. 이런 관리 체계가 뒷받침될 때 비로소 RAG는 책임 있는 지식 서비스로 자리 잡을 수 있죠.

🛡️ 한 단계 더 들어가 보기: 민감정보 마스킹 파이프라인

오늘날 RAG 시스템을 실제 서비스에 적용할 때 가장 민감한 이슈 중 하나가 바로 개인정보(PII) 보호입니다. 고객 지원, 의료 기록, 금융 데이터 등 실제 비즈니스 환경에서 활용되는 데이터에는 이름, 이메일, 주소, 카드 번호와 같은 민감정보가 다수 포함됩니다. 이런 데이터가 그대로 외부 LLM API로 전달된다면 규제 위반은 물론, 치명적인 보안 사고로 이어질 수 있습니다. 그래서 최근에는 민감정보 탐지와 마스킹을 자동화한 파이프라인을 필수 구성 요소로 두는 흐름이 강하게 자리 잡고 있습니다.

🔷 왜 민감정보 마스킹이 중요한가?

첫째, 법규 준수가 필요합니다. GDPR(유럽), HIPAA(미국), 개인정보보호법(한국) 등은 개인식별이 가능한 데이터를 처리할 때 강력한 안전조치를 요구합니다. 원본 데이터가 그대로 노출되면 과징금뿐 아니라 서비스 신뢰성 자체를 잃게 됩니다.
둘째, 서비스 신뢰 확보 차원에서도 중요합니다. 사용자는 "내 데이터가 안전하게 관리된다"는 확신이 있어야 서비스를 안심하고 활용할 수 있습니다.
셋째, 실질적 보안 리스크 차단입니다. 예를 들어 “010-1234-5678로 연락 바람” 같은 문장이 LLM 학습 로그에 그대로 남는다면 이는 즉각적인 보안 위협이 됩니다.

따라서 RAG 파이프라인에는 반드시 민감정보 탐지 → 마스킹/익명화 → 벡터화 순서가 들어가야 합니다.🔒

🔷 PII 탐지: 룰, ML, 그리고 LLM

민감정보 탐지 기법은 크게 세 가지로 나눌 수 있습니다.

룰 기반 탐지 (정규표현식)
전화번호, 이메일처럼 패턴이 일정한 데이터는 정규표현식으로 빠르게 잡아낼 수 있습니다. 하지만 이름이나 주소처럼 규칙이 불명확한 항목에는 취약합니다.
ML 기반 탐지 (NER 모델)
문맥 속에서 인명, 위치, 조직명, 날짜 등을 식별하는 NER(Named Entity Recognition) 모델을 활용합니다. 대표적으로 spaCy NER, HuggingFace의 BERT NER 모델, Microsoft의 Presidio가 있습니다. Presidio는 룰 기반과 NER을 혼합한 방식으로 수십 종의 PII를 식별하며, 신용카드 번호, 이메일, 심지어 비트코인 지갑 주소까지 감지할 수 있습니다. 다만 도메인 특수성에 따라 커스텀 인식기를 추가하거나 여러 모델을 앙상블해야 정확도가 올라갑니다.
LLM 기반 탐지 (컨텍스트 이해)
GLiNER은 GPT-3.5를 활용해 PII 라벨링 성능을 높였으며, Precision/Recall이 90%대에 근접한 사례도 보고되었습니다. LlamaIndex의 PIINodePostprocessor 같은 기능도 정확한 탐지에 효과적입니다. 장점은 맥락 이해력이 뛰어나 복잡한 상황에서도 잘 작동한다는 것이고, 단점은 높은 비용과 긴 처리 시간입니다. 이를 보완하기 위해 최근에는 로컬 LLM(Mistral, Llama 등)을 이용해 온프레미스 환경에서 민감정보를 탐지하는 방식이 주목받고 있습니다. 이렇게 하면 데이터 외부 유출 위험도 없애고, 컨텍스트 기반의 정교한 마스킹도 가능합니다.

🔷 마스킹과 익명화: 문맥을 살리며 개인정보를 안전하게 치환

탐지된 민감정보를 어떻게 다루느냐에 따라 데이터 활용성과 검색 성능이 크게 달라집니다.

단순 치환/삭제: “김케클”을 “[NAME]”이나 “██”로 대체하는 가장 단순한 방식입니다. 하지만 이렇게 하면 문맥이 깨지고, 임베딩 품질이 떨어질 수 있습니다.
컨텍스트 보존형 마스킹: “John Smith”를 “[NAME1] [NAME2]”로 바꾸거나, 가짜 이름으로 일관성 있게 치환하는 방식입니다. 문서의 구조와 맥락을 살려 검색 성능을 유지할 수 있습니다. 날짜는 연도만 남기거나, 주소는 도시명만 남기는 등 유형별 보존 정책도 많이 활용됩니다.
가명화(Pseudonymization): 실제 이름을 “PersonA” 같은 가명으로 바꿔 원본을 알 수 없게 하는 방법입니다.
복원 가능한 익명화(Reversible Anonymization): 내부적으로는 “김케클 → <ID123>” 같은 토큰으로 치환해두고, 필요 시 매핑 테이블을 통해 다시 복원하는 방식입니다. 이렇게 하면 개인정보는 안전하게 보호하면서도, 사용자의 질의 응답에는 정확한 결과를 제공할 수 있습니다.

실제 기업들은 Microsoft Presidio나 Google DLP API 같은 오픈소스/상용 도구를 활용해 이 과정을 자동화하고 있으며, 경우에 따라 k-익명화(k-Anonymity), 차등 프라이버시(Differential Privacy) 같은 통계적 접근법도 병행합니다. 하지만 RAG 문서 처리에서는 여전히 텍스트 치환 방식이 주류입니다.

🔷 성능과 프라이버시의 균형

마스킹은 필연적으로 데이터 품질과 프라이버시 보호 간의 트레이드오프를 발생시킵니다. 예를 들어 “John은 London에 산다”에서 John을 [NAME]으로 치환하면 “누군가 London에 산다” 정도의 의미만 남아 맥락이 약화됩니다. 이를 최소화하기 위해 [NAME] 같은 토큰을 토크나이저에 등록하거나, LLM 프롬프트에서 해당 토큰의 의미를 모델에 이해시키는 방법이 활용됩니다.

따라서 시스템 설계자는 서비스 목적에 맞게 균형을 잡아야 합니다. 내부 직원용 시스템이라면 약간의 정보 노출이 허용될 수 있지만, 외부 고객 서비스라면 절대 노출이 불가합니다.

정리하자면, 민감정보 마스킹 파이프라인은 단순한 보안 옵션이 아니라, RAG 시스템이 신뢰받는 AI 서비스로 자리잡기 위해 반드시 필요한 핵심 구성 요소입니다. 룰·ML·LLM 기반 탐지를 적절히 조합하고, 상황에 맞는 마스킹 전략을 세운다면 개인정보 보호와 검색 성능을 동시에 확보할 수 있습니다.

5. 파싱 자동화와 운영 ⚙️

⏱️ 5.1 배치 vs 스트리밍 파싱

데이터 파싱과 전처리 방식은 RAG(Retrieval-Augmented Generation) 시스템의 품질, 최신성, 운영 효율성을 결정하는 핵심 요소예요. 전통적으로 데이터 처리 전략은 배치(batch)와 스트리밍(stream)으로 구분되며, 두 방식은 서로 다른 장단점을 가집니다. 최근에는 하이브리드 접근과 통합 프레임워크의 발전으로 선택지가 한층 넓어지고 있어요.

🔷 배치 처리

배치 처리는 일정 주기로 데이터를 모아 일괄 처리하는 방식이에요.

[장점]

높은 처리량: 대규모 데이터 집합을 한 번에 처리해 throughput이 높아요.
자원 예측 가능성: 특정 시간대에 작업을 집중시켜 리소스 사용을 안정적으로 관리할 수 있어요.
계산 집약 작업 적합성: PDF 파싱, OCR 같은 무거운 연산을 야간에 집중 처리해 운영 환경에 부담을 줄일 수 있어요.

[단점]

지연 발생: 새로운 데이터가 들어와도 다음 배치 실행 전까지 검색 인덱스에 반영되지 않아요.
리소스 피크: 대규모 배치 실행 시 순간적인 부하가 발생할 수 있어요.

따라서 배치 처리는 데이터 발생 빈도가 낮거나 수 시간의 지연이 허용되는 환경(예: 주간 보고서, 정적 자료 업데이트)에 적합합니다.

🔷 스트리밍 처리

스트리밍 처리는 데이터가 생성되는 즉시 처리하는 방식이에요.

[장점]

최신성 보장: 데이터 입력 후 몇 초 내에 검색 가능 상태로 반영돼요.
증분 처리: 새로 들어온 데이터만 처리해 불필요한 중복 계산을 줄일 수 있어요.
확장성: 이벤트 단위 병렬 처리와 자동 스케일링에 유리해요.

[단점]

운영 복잡성: 이벤트 순서 보장, 중복 처리, 오류 추적 같은 이슈를 고려해야 해요.
상시 자원 점유: 데이터 발생이 드문 환경에서는 오히려 비효율적일 수 있어요.
트랜잭션 오버헤드: 소규모 이벤트가 잦으면 누적 비용이 커질 수 있어요.

대표적인 사례로 전자상거래 플랫폼은 Kafka 토픽으로 신규 상품 등록 이벤트를 발행하고, Flink 잡(Job)이 이를 소비해 즉시 파싱 → 임베딩 → 벡터DB 업서트 과정을 수행해요. Confluent 보고서에 따르면, 이런 실시간 파이프라인은 고객 문의 응답 시간을 50% 단축했다고 합니다.

🔷 하이브리드 접근

현업에서는 배치와 스트리밍을 혼합하는 방식이 점점 일반화되고 있어요.

중요 데이터(예: 장애 로그, 뉴스 기사)는 스트리밍 처리.
비핵심 데이터(예: FAQ, 내부 가이드 문서)는 배치 처리.
마이크로 배치: 수 분 단위로 배치해 근실시간 처리와 유사한 경험을 제공.

최근 Pathway, Apache Flink 같은 프레임워크는 동일한 코드로 배치와 스트리밍을 모두 지원해 단일 플랫폼 내에서 두 방식을 유연하게 결합할 수 있게 되었어요.

🔷 선정 기준과 비용 관점

배치와 스트리밍을 선택하거나 혼합할 때 고려할 기준은 명확해요.

데이터 업데이트 빈도: 하루 수십 건 이하 → 배치 / 시간당 수백 건 이상 → 스트리밍.
최신성 요구 수준: 수 시간 지연 허용 → 배치 / 즉시 반영 필요 → 스트리밍.
운영 역량 및 인프라: Kafka, Flink 같은 실시간 파이프라인 경험이 부족하다면 Apache Pulsar, Redpanda 같은 비교적 단순한 대안을 검토하거나, 짧은 주기 배치를 활용하는 편이 좋아요.

비용 측면에서는 배치는 전체 데이터 재처리를 기본으로 하기 때문에 장기적으로 중복 계산 부담이 커질 수 있어요. 반면 스트리밍은 증분 처리 특성 덕분에 중복 계산을 줄이지만, 상시 실행 인프라와 운영 복잡성에서 비용이 발생하죠. 따라서 총소유비용(TCO)은 데이터 특성과 운영 역량에 따라 달라지며, 이를 기준으로 최적 접근법을 결정해야 합니다.

배치와 스트리밍 파싱은 상호 배타적이지 않습니다. 데이터 특성과 비즈니스 요구에 따라 조합적으로 활용할 수 있으며, 최신 프레임워크의 발전으로 두 패러다임의 경계도 점점 희미해지고 있어요. RAG 시스템에서는 데이터 최신성과 처리 효율성 간의 균형을 잡는 것이 설계의 핵심이죠.⚖️

🪵 5.2 오류 탐지·로그 관리·재처리 전략

대규모 RAG 파이프라인에서 데이터 파싱과 전처리 과정은 여러 외부 의존성과 다양한 입력 형식 때문에 오류가 자주 발생해요. 그래서 체계적인 오류 탐지, 로그 기반 모니터링, 재처리 전략은 안정적인 운영을 보장하는 핵심 요소예요. 최근 연구와 산업 사례를 보면 단순 예외 처리만으로는 부족하고, 관찰성(observability) 확보, 멱등성(idempotency) 보장, 자동 복구 메커니즘이 주요 설계 원칙으로 자리 잡고 있습니다.🛠️

🔷 오류 탐지와 분류

파이프라인 오류는 크게 세 가지로 나눌 수 있어요.

입력 단계 오류: 네트워크 실패, 접근 권한 문제, 손상된 파일, 지원 불가 포맷. 특히 OCR·HTML 파싱에서 입력 오류가 자주 발생해요.
처리 단계 오류: 메모리 부족, 시간 초과, 파싱 라이브러리 예외. 대규모 문서 파싱이나 비정형 데이터 처리 시 흔해요.
출력 단계 오류: 결과 저장 실패, 인덱싱 불일치, 품질 기준 미달.

이런 오류는 단발로 끝나지 않고 연쇄적으로 퍼질 수 있어요. 따라서 입력 유효성 검사 → 처리 중 예외 포착 및 로깅 → 출력 품질 검증 같은 삼중 검증 체계를 두는 것이 바람직합니다.

🔷 로그 관리와 모니터링

효율적인 로그 관리 체계는 단순 디버깅 도구가 아니라, 시스템 건강성을 실시간으로 측정하는 핵심 인프라예요.

구조화된 로깅: 문서 ID, 에러 코드, 스택트레이스를 JSON 같은 형식으로 기록.
중앙 집중화: Elasticsearch, Loki 등 로그 수집기로 검색·필터링이 가능하도록 관리.
실시간 모니터링: Prometheus+Grafana, Datadog 등을 활용해 성공/실패 건수, 처리 지연, 메모리 사용량을 관찰.
알림 체계: PagerDuty, Slack과 연동해 에러율 급증 시 즉시 알림.

이런 관찰성 체계를 갖추면 데이터 품질 저하나 성능 저하를 조기에 발견해 대응 시간을 크게 줄일 수 있어요.

🔷 재처리와 복구 전략

재처리는 오류 유형에 따라 다르게 접근해야 해요.

일시적 오류(Transient): 네트워크 불안정, API 타임아웃은 backoff를 적용한 자동 재시도(2~3회)로 복구 가능해요.
영구적 오류(Permanent): 손상된 PDF, 암호화 파일처럼 반복 재시도가 무의미한 경우에는 실패 목록에 기록하고 관리자가 직접 개입해야 해요.
성능 문제(Performance Issue): 과도한 시간 초과나 메모리 부족은 chunk 단위 분할, 리소스 확장 같은 구조적 개선이 필요해요.

또한 주 파싱 경로가 실패했을 때 대비한 폴백(fallback) 경로도 유용해요. 예를 들어 HTML 파싱이 실패하면 단순 텍스트 추출로 대체하거나, OCR 엔진을 교체해 재시도하는 방식이죠. 품질은 다소 낮아질 수 있지만 데이터 손실은 줄일 수 있어요.

🔷 멱등성과 부분 재처리

재처리 전략에서 핵심은 멱등성을 보장하는 거예요. 동일한 입력을 여러 번 처리하더라도 결과가 일관되게 유지돼야 합니다. 이를 위해서는

데이터 단위에 고유 식별자(doc_id, checksum 등) 부여,
중간 산출물은 안전한 저장소에 보관하고 체크포인트로 상태 추적,
실패 구간만 다시 실행하는 부분 재처리(partial reprocessing) 구조 마련,

이런 설계가 필요해요. Airflow, Prefect 같은 워크플로 오케스트레이션 도구는 태스크 단위 재시도, 사용자 정의 재처리 함수, 체크포인트 기반 복구를 지원해 이런 전략을 쉽게 구현할 수 있습니다.

🤖 5.3 자동화 오픈소스 도구 활용

RAG 시스템의 데이터 파이프라인은 파싱 → 임베딩 → 벡터DB 적재까지 이어지는 다단계 프로세스로 구성돼요. 이 과정이 원활하지 않으면 검색 인덱스 최신성이 깨지고 답변 품질도 떨어질 수 있어요. 그래서 워크플로 오케스트레이션 도구를 활용하면 운영 효율이 좋아지고, 검색 품질 유지에도 도움이 될 수 있어요.

🔷 Apache Airflow: 안정적인 선택지

Apache Airflow는 DAG(Directed Acyclic Graph) 기반으로 파이프라인을 코드로 정의할 수 있는 도구예요. 다양한 조직에서 폭넓게 활용되고 있어서, 실무에서 신뢰할 수 있는 선택지로 꼽히곤 해요.
Airflow는 의존성 관리, 자동 재시도, 태스크별 로깅·모니터링 UI 같은 기능을 제공할 수 있어요. 예를 들어 “문서 크롤링 → 텍스트 파싱 → 임베딩 생성 → 벡터DB 반영” 과정을 DAG으로 구성하면, 오류 발생 시 후속 단계가 자동으로 멈추거나 재시도돼요. 덕분에 데이터가 빠짐없이 반영되고 검색 최신성을 안정적으로 유지할 수 있죠.

🔷 Prefect·Dagster: 동적 워크로드 대응

Airflow가 안정성에 강점을 가진다면, Prefect와 Dagster는 더 유연하고 동적인 워크로드에 잘 맞을 수 있어요.

Prefect는 Pythonic 인터페이스와 동적 플로우 생성을 지원해서, 이벤트 기반 파이프라인을 간단하게 구성할 수 있어요. GitHub 웹훅 이벤트가 발생하면 곧바로 파싱과 임베딩 과정을 실행해 새로운 문서가 신속히 검색에 반영될 수 있죠.
Dagster는 데이터 자산(data asset) 중심 접근법을 제공해, 데이터 계보(lineage) 추적과 품질 관리에 강점을 보여요. 정형화된 데이터 품질이 중요한 환경에서는 도움이 될 수 있어요.

🔷 Kafka·ksqlDB·Kubeflow: 실시간성과 품질 보완

Kafka + Flink/ksqlDB는 실시간 이벤트 처리에 적합해요. 신규 문서 등록 이벤트가 발생하면 Flink가 이를 파싱·임베딩해 벡터DB에 반영할 수 있어요. 이렇게 하면 최신 문서 검색 품질을 높일 수 있습니다.
Kubeflow Pipelines는 쿠버네티스 기반 ML 파이프라인 도구예요. 임베딩 생성이나 모델 업데이트를 ML 스텝처럼 관리해, 데이터 반영과 모델 학습 타이밍을 맞출 수 있어요.

🔷 사례와 하이브리드 활용

금융기관에서는 Airflow로 매일 FAQ DB를 파싱·임베딩해 Milvus에 반영하고, 실패 시 알림을 보내 검색 정확도를 높였다고 해요.
한 스타트업은 Prefect를 통해 Google Drive 업로드 이벤트를 트리거 삼아 문서를 파싱·임베딩·Qdrant 업데이트까지 자동화해서, 사용자가 업로드한 자료가 수분 내 검색 가능한 상태가 되도록 했어요.

최근에는 Airflow 같은 오픈소스 엔진을 코어로 두고 클라우드 서비스와 결합하는 방식도 늘어나고 있어요. 이렇게 하면 안정성과 유연성을 동시에 확보할 수 있죠.

정리하면, 자동화 오픈소스 도구는 RAG 파이프라인 운영에 꼭 필요한 것은 아니지만, 활용하면 운영을 더 효율적으로 만들고 검색 품질을 안정적으로 유지하는 데 도움이 될 수 있어요.🚀 Airflow, Prefect, Dagster, Kafka, Kubeflow 같은 도구들은 상황에 따라 선택적으로 쓰일 수 있고, 팀 역량과 환경에 맞춰 조합하면 효율성과 유연성을 동시에 얻을 수 있죠.

📝 마치며: 데이터가 곧 RAG의 운명을 결정한다

이번 2편을 통해 RAG에서 데이터 파싱과 전처리가 얼마나 중요한지 살펴봤어요. 아무리 뛰어난 LLM과 벡터 검색 엔진을 갖춰도, 들어가는 데이터가 엉망이면 결과도 엉망이 나온다는 GIGO 원칙이 여전히 유효하다는 걸 확인했죠.

PDF 표 구조 보존부터 HTML 노이즈 제거, OCR 정확도 향상, 코드 포맷 유지까지... 각 데이터 유형마다 고유한 함정과 해결책이 있다는 것도 알 수 있었어요. 특히 "단순히 텍스트만 뽑지 말고 구조와 맥락까지 보존하라"는 원칙이 모든 파싱 전략의 핵심이었습니다.

하지만 이 모든 과정을 수동으로 관리하기엔 현실적 한계가 있어요. 데이터 소스는 계속 늘어나고, 형식도 다양해지고, 품질 관리도 복잡해지죠. 그래서 자동화된 파이프라인과 지속적인 품질 모니터링이 필수가 되고 있어요.

앞으로는 더 정교한 파싱 기술들이 등장할 거예요. LLM 자체가 문서 구조를 이해하고 최적의 파싱 전략을 제안하는 AI-assisted parsing이나, 도메인별 특화된 전처리 모델들이 나올 가능성이 높죠. 멀티모달 RAG가 확산되면서 이미지·음성·비디오 파싱도 텍스트만큼 중요해질 테고요. ✨

결국 핵심은 "우리 도메인의 데이터 특성을 정확히 파악하고, 그에 맞는 파싱 전략을 체계적으로 적용하는 것"이에요. 완벽한 만능 솔루션은 없지만, 원칙을 지키고 꾸준히 개선해나간다면 RAG 시스템의 신뢰성과 정확성을 크게 높일 수 있어요.

🚀 kt cloud 의 AI Foundry RAG Suite로 파싱 복잡성 해결!

특히 kt cloud AI Foundry에서는 이런 복잡한 파싱 과정을 획기적으로 간소화하는 RAG Suite 서비스를 제공하고 있어요. 이미지부터 PDF, PPT, 워드까지 다양한 문서 유형을 뛰어난 파싱 능력으로 처리할 수 있고, 사용자는 간단히 API 엔드포인트만 생성하면 바로 활용할 수 있죠.

복잡한 OCR 엔진 설정이나 표 구조 파싱 로직을 직접 구현할 필요 없이, API 호출 한 번으로 고품질 파싱 결과를 얻을 수 있어요. 덕분에 개발팀은 파싱 기술 구현보다는 비즈니스 로직과 품질 최적화에 더 집중할 수 있습니다.

좋은 데이터가 좋은 RAG를 만든다는 건 변하지 않을 진리예요.

다음 3편에서는 이렇게 정제된 데이터를 어떻게 효과적으로 청킹하고 임베딩할지 다뤄보겠습니다.

감사합니다! 🙏

❓ 자주 묻는 질문 (FAQ)

Q. RAG 시스템에서 데이터 파싱과 전처리가 왜 중요한가요?

A: RAG 시스템의 성능은 “Garbage In, Garbage Out(GIGO)” 원칙에 따라 입력 데이터의 품질에 의해 좌우됩니다.
여기서 핵심은 단순히 데이터를 읽어들이는 것(파싱)에 그치지 않고, 이를 학습과 검색에 적합한 형태로 정제하는 과정(전처리)까지 포함한다는 점입니다.

먼저 데이터 파싱은 원본 문서의 구조적·의미적 정보를 최대한 보존하는 단계입니다. 예를 들어 PDF의 표가 단순 텍스트로 풀려버리거나, HTML의 DOM 계층이 손실되면 맥락이 붕괴되어 검색 정확도가 떨어집니다. 이는 곧 LLM이 잘못된 전제를 기반으로 추론하게 만들어 환각(hallucination)을 유발할 수 있습니다.

이어서 데이터 전처리는 파싱된 결과물 속 노이즈를 제거하고 일관성을 맞추는 작업입니다. 깨진 특수문자, 불필요한 줄바꿈, 중복 메타데이터가 남아 있으면 임베딩 품질이 저하되어 의미 검색이 왜곡됩니다. 반대로 정규화·필터링을 통해 불필요한 신호를 줄이고 중요한 정보만 남기면, 임베딩이 더욱 선명해지고 검색·생성 단계의 품질도 향상됩니다.

결국, 파싱과 전처리는 단순한 준비 단계가 아니라 RAG 시스템의 정확성, 신뢰성, 운영 안정성을 보장하는 기반입니다. 이 두 과정이 제대로 설계되지 않으면, 아무리 정교한 검색 알고리즘과 고성능 LLM을 사용해도 원하는 답변을 얻기 어렵습니다.

📚 관련/출처

저작자표시 비영리 변경금지 (새창열림)

'Tech Story > Tech Inside' 카테고리의 다른 글

[기술리포트] 양자컴퓨팅의 현재와 미래: 클라우드 시대의 새로운 도약 (2)	2025.09.08
[Tech Series] kt cloud AI 검색 증강 생성(RAG) #1 : 핵심 개념과 시스템 구조 이해 (0)	2025.08.22
[Tech Series] A2A는 AI 에이전트 간 통합과 확장성을 어떻게 향상시킬까? (0)	2025.07.15
[기술리포트] 2025 구글 AI 에이전트 아키텍처 구조 완벽 이해 (1)	2025.07.15
[Tech Series] AI 에이전트 시대의 USB-C, MCP(Model Context Protocol) 표준화는 어디까지 왔을까? (5)	2025.06.13

현재글[Tech Series] kt cloud AI 검색 증강 생성(RAG) #2 : 데이터 파싱과 전처리 최적화