개떡같이 말해도 찰떡같이 답변하는 RAG - 한글 문서는 왜 파싱부터 다른가

TL;DR: RAG 파이프라인에서 파싱은 문서를 깨끗한 텍스트로 바꾸는 첫 단계다. 영어는 공백으로 단어가 나뉘지만, 한글은 조사와 어미가 어근에 달라붙어 형태소 분석 없이는 제대로 된 토큰화가 불가능하다. 파싱을 대충 넘기면 한 문단 중간에서 청크가 잘려 맥락이 끊기고, 조사가 붙은 채로 임베딩되어 벡터 거리가 벌어지며, "배포"를 검색해도 "배포를"이 포함된 문서가 누락된다.

파싱, 대충 해도 되지 않을까

RAG를 처음 만들 때, 대부분의 튜토리얼은 영어 PDF 몇 장을 LangChain에 넣는 것으로 시작한다. 코드 몇 줄이면 문서가 벡터로 변환되고, 질문을 던지면 답이 나온다. "생각보다 쉬운데?" 싶다.

그런데 사내 위키를 넣으려고 하면 이야기가 달라진다. Confluence에서 가져온 문서에는 HTML 태그가 잔뜩 섞여 있고, 표는 파싱 과정에서 행·열 구조가 사라지고 셀 안의 숫자만 나열된다. 거기에 한글이라는 변수가 더해진다. "배포 절차"를 검색하면 "배포를", "배포에서", "배포했던" 같은 조사 붙은 표현은 매칭이 안 되는 상황이 벌어진다.

결국 파싱은 RAG 파이프라인에서 가장 먼저 마주하는 단계이면서, 가장 과소평가되는 단계이기도 하다. 이 글에서는 파싱이 왜 중요한지, 한글에서는 왜 유독 까다로운지, 그리고 어떤 도구를 쓸 수 있는지 정리한다.

RAG 파이프라인에서 파싱의 위치

RAG의 오프라인 인덱싱 파이프라인은 다섯 단계로 나뉜다.

문서 수집 → 파싱 → 청킹 → 임베딩 → 벡터 저장

그림 1 : RAG 오프라인 인덱싱 파이프라인에서 파싱의 위치. 파싱은 문서 수집 직후, 청킹 직전에 위치한다. 비정형 문서(HTML, PDF 등)를 깨끗한 텍스트로 변환하는 역할이며, 이 단계의 품질이 후속 단계 전체에 영향을 준다.

파싱(Parsing)이 하는 일은 비정형 문서에서 깨끗한 텍스트를 뽑아내는 것이다. 다만 문서를 가져오는 방식에 따라 파싱의 무게가 달라진다.

사내 위키를 예로 들면, HTML을 통째로 가져오는 방법만 있는 것은 아니다. Confluence REST API는 storage format(XHTML 기반)이나 렌더링된 본문을 직접 반환하고, Notion API는 블록 단위의 JSON 구조를 준다. API로 가져오면 네비게이션이나 푸터 같은 노이즈가 애초에 포함되지 않기 때문에 HTML 태그를 일일이 걷어내는 작업이 크게 줄어든다.

그렇다고 파싱이 필요 없어지는 것은 아니다. API 응답이든 HTML이든, 텍스트를 정제하는 과정은 공통으로 필요하다.

문서 구조 처리: HTML이면 태그를 정리하고, API 응답이면 JSON/XHTML에서 본문을 추출한다. 어느 쪽이든 제목 계층(<h1>~<h6> 또는 heading 블록)은 보존해야 한다
노이즈 필터링: HTML 경로에서는 네비게이션, 광고, 푸터를 제거한다. API 경로에서는 이 작업이 대부분 불필요하다
인코딩 처리: 깨진 문자, 특수 문자를 정규화한다. 특히 레거시 한국어 문서에서 흔한 EUC-KR 인코딩은 UTF-8로 변환하지 않으면 파싱 전체가 깨진다
텍스트 정제: 연속 공백 제거, 줄바꿈 정리 등 텍스트를 깔끔하게 만든다

여기서 중요한 점이 하나 있다. HTML 태그를 무분별하게 제거하면 오히려 문맥이 깨진다는 것이다. <h2> 태그를 제거하면 제목과 본문이 뒤섞여 "배포 절차"라는 제목 아래의 내용이 다른 섹션의 내용과 합쳐져버린다. 제목 태그를 마크다운 헤딩(##)으로 변환하는 것이 단순 제거보다 낫다.

파싱이 엉망이면 이후 과정도 엉망이 된다. 제목과 본문이 하나로 합쳐진 텍스트를 청킹하면 한 청크 안에 서로 다른 주제가 섞이고, 그 상태로 임베딩하면 "배포 절차"와 "모니터링 설정"이 같은 벡터 공간에 놓인다. 검색할 때 "배포"를 입력해도 모니터링 문서가 함께 올라오는 식이다. 파이프라인에서 가장 앞에 있기 때문에, 여기서 생긴 오류는 뒤에서 복구할 수 없다.

여기서 중요한 점이 하나 있다. HTML 태그를 무분별하게 제거하면 오히려 문맥이 무너진다는 것이다. <h2> 태그를 제거하면 제목과 본문이 뒤섞여 "배포 절차"라는 제목 아래의 내용이 다른 섹션의 내용과 합쳐져버린다. 제목 태그를 마크다운 헤딩(##)으로 변환하는 것이 단순 제거보다 낫다.

암튼 그래서 파싱이 엉망이면 이후에 기대하는 결과가 나오지 않을 것이다. 청킹 경계가 의미 단위와 맞지 않게 되고, 임베딩 벡터가 왜곡되며, 검색 결과는 쓸모없어진다. ~~(AI가 그림에서 쓰레기라고 표현했다..)~~ 파이프라인에서 가장 앞에 있기 때문에, 여기서 생긴 오류는 뒤에서 복구할 수 없다.

영어와 한글, 토큰화부터 다르다

파싱의 핵심 단계 중 하나가 토큰화(Tokenization)다. 텍스트를 의미 있는 단위로 쪼개는 것이다. 여기서 영어와 한글의 근본적인 차이가 드러난다.

영어는 단순하다. 공백으로 자르면 된다.

"I read a book" → ["I", "read", "a", "book"]

단어 사이에 공백이 있고, 공백이 곧 토큰 경계다. 물론 영어에도 복수형(-s), 과거형(-ed) 같은 변화가 있지만, 공백 분리만으로도 대부분의 NLP 태스크에서 충분히 작동한다.

한글은 다르다. 공백으로 자르면 이런 결과가 나온다.

"나는 책을 읽었다" → ["나는", "책을", "읽었다"]

얼핏 보면 괜찮아 보인다. 하지만 "나는"은 "나"(대명사) + "는"(조사)이 합쳐진 것이고, "책을"은 "책"(명사) + "을"(조사), "읽었다"는 "읽"(어간) + "었"(과거 시제 선어말어미) + "다"(종결어미)다.

한글은 교착어(Agglutinative Language)다. 어근에 조사와 어미가 결합해서 하나의 어절을 이룬다. "책"이라는 단어 하나가 "책이", "책을", "책에", "책으로", "책에서", "책이었던", "책이라면", "책에서부터" 등 수많은 표면형으로 변한다.

그림 2: 영어와 한글의 토큰화 차이. 영어는 공백 분리만으로 의미 단위가 나뉘지만, 한글은 공백으로 나눠도 조사와 어미가 어근에 붙어 있다. 형태소 분석을 거쳐야 "나/는", "책/을", "읽/었/다"처럼 의미 단위로 분리된다.

이 차이가 RAG에서 실제로 문제를 일으킨다.

먼저 BM25 검색을 보자. BM25(Best Matching 25)는 단어의 출현 빈도와 문서 길이를 기반으로 관련도를 계산하는 키워드 검색 알고리즘이다. 벡터 검색과 함께 RAG에서 가장 많이 쓰이는 검색 방식이기도 하다. 문제는 BM25가 토큰 단위로 매칭한다는 것이다. 사용자가 "배포"를 검색하면, 문서에 있는 "배포를", "배포에서", "배포했던"은 다른 토큰으로 취급되어 매칭이 안 된다. 형태소 분석 없이 공백 기반으로 BM25를 돌렸을 때와 형태소 분석기를 적용했을 때 검색 F1 점수가 0.667에서 0.798로 올라간다(공개 한국어 QA 벤치마크 기준이며, 도메인에 따라 편차가 있다). 여기서 놓치기 쉬운 점이 하나 있다. 검색 쿼리에도 동일한 형태소 분석기를 적용해야 인덱스와 매칭이 일관된다는 것이다. 문서만 분석하고 쿼리는 공백으로 자르면 효과가 반감된다.

임베딩에서도 문제가 있다. 현대 임베딩 모델은 서브워드 토큰화(Subword Tokenization)를 쓰기 때문에 공백 분리에 직접 의존하지는 않는다. 하지만 한글에서는 BPE(Byte Pair Encoding) 과분절 문제가 발생한다. "우두머리"가 "우두"+"머리"로 쪼개져 의미가 파괴되는 식이다. 형태소 경계를 미리 알려주면 이 문제를 완화할 수 있다.

물론 text-embedding-3 같은 최신 임베딩 모델은 한국어를 이전보다 훨씬 잘 처리한다. 벡터 검색만 사용하는 소규모 RAG라면 형태소 분석 없이도 어느 정도 작동하는 경우가 있다. 하지만 BM25를 함께 쓰는 하이브리드 검색에서는 형태소 분석이 여전히 필수이고, 임베딩에서도 정제된 텍스트를 넣는 것이 노이즈가 섞인 원문을 그대로 넣는 것보다 결과가 안정적이다. 벡터 검색 단독으로 시작하고, BM25를 추가하는 시점에 형태소 분석을 도입하는 것도 합리적인 접근이다.

다른 언어는 어떨까

한글만 유독 까다로운 것은 아니다. 다른 언어들도 각자의 파싱 난이도를 가지고 있다.

일본어는 세 가지 문자 체계(히라가나, 가타카나, 한자)가 섞여 있고, 단어 사이에 공백이 거의 없다. "東京タワーに行きました"처럼 한자와 가나가 연속으로 이어진다. 별도의 분절기(MeCab-IPAdic 등)가 필수다.

중국어도 단어 사이에 공백이 없다. "我去北京了"에서 "我/去/北京/了"로 분절해야 한다. jieba 같은 분절 라이브러리를 쓴다. 다만 한 글자가 독립적 의미를 가지는 경우가 많아 분절 실패의 영향이 한글보다는 적다.

독일어는 복합어가 유명하다. "Donaudampfschifffahrtsgesellschaft"(도나우 증기 선박 항해 회사)처럼 단어를 끝없이 붙여 쓴다. 복합어 분해(decompounding)가 필요하다.

한글의 특수한 점은 공백은 존재하지만, 공백 단위가 의미 단위가 아니라는 것이다. 일본어와 중국어는 공백 자체가 없어서 분절이 필요하다는 게 명확하다. 독일어는 복합어를 제외하면 공백 분리가 잘 작동한다. 반면 한글은 공백이 있어서 "그냥 공백으로 자르면 되겠지"라는 착각을 유발한다. 결국 형태소 분석이라는 추가 단계를 거쳐야 한다는 점을 인식하는 것 자체가 첫 번째 과제다.

한글 파싱을 위한 도구들

한글 RAG 파이프라인에서 파싱은 크게 두 레이어로 나뉜다. 문서에서 텍스트를 추출하는 문서 파싱 레이어와, 한국어 텍스트를 정제하는 형태소 분석 레이어다.

문서 파싱

문서를 가져오는 경로에 따라 도구가 달라진다.

API 기반 (Confluence, Notion 등)

위키 플랫폼이 API를 제공한다면 가장 깔끔한 경로다. LangChain의 ConfluenceLoader는 Confluence REST API를 통해 페이지 본문을 직접 가져온다. NotionDBLoader도 마찬가지다. API 응답은 이미 구조화되어 있어서 HTML 태그를 직접 다룰 일이 줄어든다. 다만 Confluence Cloud와 Server/DC는 API 엔드포인트가 다르므로 환경에 맞게 설정해야 한다.

HTML 직접 파싱

API가 없거나 HTML을 직접 처리해야 하는 경우에는 BeautifulSoup4가 기본이다. lxml 파서를 쓰면 빠르고, html5lib을 쓰면 브라우저와 동일하게 해석한다. 주의할 점은 동일한 잘못된 HTML에 대해 파서마다 다른 결과를 만든다는 것이다.

# pip install beautifulsoup4 lxml
from bs4 import BeautifulSoup

html = "<h2>배포 절차</h2><p>서버에 접속하여...</p>"
soup = BeautifulSoup(html, "lxml")
# 태그를 전부 제거하지 말고, 구조를 보존하면서 텍스트를 추출한다
for tag in soup.find_all(["h1", "h2", "h3"]):
    tag.string = f"\n## {tag.get_text()}\n"
text = soup.get_text(separator="\n")

비정형 문서 (PDF, DOCX 등). Unstructured.io는 PDF, 이미지, DOCX 등 다양한 포맷을 파싱하는 라이브러리다. partition_html(url="...") 하나로 웹 페이지를 구조화된 요소(제목, 본문, 목록 등)로 분해한다. 다만 오픈소스 버전의 한국어 지원 완성도는 영어보다 낮다. 특히 스캔 PDF에서는 OCR 품질을 별도로 검증해야 한다.

다이어그램과 구조화된 비텍스트 데이터. 텍스트와 HTML만 파싱하면 끝이 아니다. 사내 위키에는 Mermaid, PlantUML, draw.io 같은 다이어그램이 포함되어 있는 경우가 많고, 이 안에 담긴 정보가 오히려 핵심인 경우도 있다. 아키텍처 구조도, 배포 흐름도, 시스템 간 연결 관계 같은 내용이 텍스트가 아닌 다이어그램에만 존재하는 경우다.

이런 데이터는 100% 원본 그대로 저장하기 어렵지만, 검색 대상으로 포함시키려면 텍스트로 변환하는 과정이 필요하다. 접근 방식은 포맷에 따라 다르다.

Mermaid, PlantUML: 코드 기반 다이어그램이라 원본 코드 자체를 텍스트로 보존하면 된다. graph TD; A-->B 같은 코드에 노드명과 관계가 그대로 담겨 있어서 별도 변환 없이도 검색에 걸린다
draw.io: XML 기반이라 다른 접근이 필요하다. Confluence에서는 API로 .drawio 첨부파일을 다운로드한 뒤, XML을 파싱하여 노드 목록과 연결 관계를 텍스트로 추출한다. 이때 draw.io 특유의 플레이스홀더(%name% 등)를 실제 텍스트로 치환하는 과정을 거쳐야 의미 있는 결과가 나온다

다이어그램 파싱은 일반 텍스트 파싱과 달리 표준 도구가 거의 없다. 포맷별로 파서를 직접 구현해야 하는 경우가 대부분이다.

형태소 분석이란

HTML에서 텍스트를 추출한 다음, 한국어에서는 형태소 분석(Morphological Analysis)이라는 추가 단계가 필요하다.

형태소는 의미를 가지는 가장 작은 언어 단위다. "읽었다"를 예로 들면, "읽"(동사 어간) + "었"(과거 시제) + "다"(종결어미)로 나뉜다. 이 세 조각 중 하나라도 빠지면 원래 의미가 달라지거나 성립하지 않는다. 형태소 분석기는 이 작업을 자동으로 해주는 도구다. 어절을 입력하면 형태소 단위로 쪼개고, 각 조각이 명사인지 조사인지 어미인지 품사 태그를 붙여준다.

from kiwipiepy import Kiwi

kiwi = Kiwi()
tokens = kiwi.tokenize("나는 책을 읽었다")
for token in tokens:
    print(f"{token.form}/{token.tag}")
# 나/NP  는/JX  책/NNG  을/JKO  읽/VV  었/EP  다/EF

위 결과에서 NNG는 일반 명사, JKO는 목적격 조사, VV는 동사 어간이다. 이렇게 품사가 분리되면 조사를 떼어내고 "나", "책", "읽" 같은 핵심 의미만 뽑아낼 수 있다. RAG에서 형태소 분석이 필요한 이유가 여기에 있다. "배포를", "배포에서", "배포했던"이 전부 "배포"라는 같은 어근을 공유한다는 걸 알아야 검색에서 매칭이 된다.

형태소 분석기 선택

형태소가 뭔지, 왜 필요한지 알았으면 이제 도구를 고를 차례다. Python에서 쓸 수 있는 한국어 형태소 분석기는 여러 개가 있고, 속도·설치 난이도·정확도에 차이가 있다.

Kiwi(kiwipiepy)는 C++ 기반으로 빠르고, 대부분의 환경(Python 3.8~3.11)에서 pip install kiwipiepy로 설치된다. 오타 교정, 사용자 사전 추가도 지원한다.

Mecab-ko는 속도가 가장 빠르다. 10만 건 처리 시 약 6초로, Kkma의 432초와 비교하면 72배 차이가 난다. 단, Windows에서 설치가 까다롭고 Java가 아닌 C++ 기반이라 별도 바이너리가 필요하다.

Okt(Open Korean Text)는 KoNLPy 패키지에 포함되어 있어 접근성이 좋다. stem=True 옵션으로 어간 추출도 가능하다. 다만 JVM이 필요하다는 점이 걸린다.

형태소 분석 결과를 검색에 쓰려면

이제, 분석 결과를 검색에 쓸 수 있는 형태로 가공해야 한다.

먼저 핵심 키워드 추출을 해야한다. 형태소 분석 결과에서 의미를 담고 있는 품사만 골라낸다. 명사(NNG, NNP), 동사 어간(VV), 형용사 어간(VA) 정도를 추출하고, 조사(JKS, JKO 등)와 어미(EP, EF 등)는 버린다.

from kiwipiepy import Kiwi

kiwi = Kiwi()

def extract_keywords(text):
    """의미 있는 품사만 추출하여 키워드 리스트를 반환한다."""
    keep_tags = {"NNG", "NNP", "NNB", "VV", "VA", "SL"}  # 일반적인 시작점. 도메인에 따라 조정 필요
    tokens = kiwi.tokenize(text)
    return [t.form for t in tokens if t.tag in keep_tags]

extract_keywords("배포 절차를 확인하고 서버에 접속했다")
# → ["배포", "절차", "확인", "서버", "접속"]

"배포 절차를 확인하고 서버에 접속했다"에서 조사("를", "하고", "에")와 어미("했다")가 빠지고, "배포", "절차", "확인", "서버", "접속"만 남는다. 이 키워드로 BM25 인덱스를 만들면 "배포"를 검색했을 때 "배포를"이 포함된 문서도 매칭된다.

다음은 텍스트 정규화다. 검색 결과의 일관성을 위해 불필요한 공백, 문장부호 주변 공백, 연속된 특수문자를 정리한다.

import re

def normalize_text(text):
    """검색 품질을 위한 텍스트 정규화."""
    text = re.sub(r"\s+", " ", text)           # 연속 공백 → 단일 공백
    text = re.sub(r"\s*([.,!?;:])\s*", r"\1 ", text)  # 문장부호 주변 정리
    text = text.strip()
    return text

형태소 분석기도 만능은 아니다

형태소 분석기를 붙이면 모든 문제가 해결될 것 같지만, 실무에서는 형태소 분석기 자체가 문제를 일으키는 경우도 있다.

요기요는 가게명 검색에 형태소 분석기를 적용했다가 "형태소 분석기가 답이 아니다"라는 결론에 도달했다. 원인은 세 가지였다. 첫째, 형태소 분석기는 문법에 맞는 텍스트에 특화되어 있어서 "맛닭꼬" 같은 가게명을 제대로 분석하지 못했다. 둘째, 형태소 분석은 서로소 분할(disjoint segmentation)이라서 음절을 공유하는 패턴을 잡지 못했다. 셋째, 사전에 없는 외래어, 줄임말, 신조어에 대응이 불가능했다. 요기요는 결국 N-gram 방식으로 전환했다.

사내 위키에서도 비슷한 문제가 생길 수 있다. 팀명("플랫폼TF"), 프로젝트명("마이그레이션v2"), 내부 약어("PGW", "CS팀")는 형태소 분석기의 사전에 없다. 사용자 사전을 추가하면 어느 정도 대응 가능하지만, 조직이 바뀔 때마다 사전을 갱신해야 하는 운영 부담이 생긴다.

그렇다고 형태소 분석을 안 하면 되느냐 하면, 그것도 아니다. 앞서 본 것처럼 BM25 검색 품질이 20% 가까이 차이 난다. 결국 형태소 분석은 기본으로 적용하되, 고유명사와 내부 용어에 대해서는 사용자 사전이나 N-gram을 병행하는 것이 현실적인 접근이다.

속도도 고려해야 한다. 문서가 수만 건이라면 Kkma는 현실적으로 쓸 수 없다. Mecab이나 Kiwi처럼 빠른 분석기를 쓰되, 정확도가 아쉬운 부분은 하이브리드 검색(BM25 + 벡터 검색)으로 보완하는 전략이 실무에서 많이 쓰인다.

마무리

이 글은 RAG 파이프라인에서 "파싱"이라는 단계를 짚어보기 위해 쓴 글이다. 처음에는 대충 이해하고 넘어갔던 부분인데, 정리하면서 한글 문서가 왜 영어와 다른 접근이 필요한지 명확해졌다.

실제로 직접 구현하면서 느낀 점은, 텍스트 파싱보다 다이어그램 파싱이 더 까다롭다는 것이다. Confluence 위키에는 draw.io 도면이나 Mermaid 흐름도가 곳곳에 있었는데, 버리기엔 핵심 정보가 너무 많았다. 앞서 정리한 방식대로 포맷별 파서를 직접 만들었고, 추출한 텍스트에 형태소 분석까지 적용해서 BM25 검색 대상에 포함시켰다. 100% 완벽한 변환은 아니지만, "이런 다이어그램이 있었다"는 것을 검색으로 찾을 수 있게 된 것만으로도 충분한 가치가 있었다.

참고자료

kt cloud, "AI RAG 파싱 전처리 최적화", kt cloud 기술 블로그, 2025. https://tech.ktcloud.com/entry/2025-09-ktcloud-ai-rag-parsing
Park et al., "An Empirical Study of Tokenization Strategies for Various Korean NLP Tasks", AACL, 2020.
Marker Inc. Korea, "Korean BM25 Tokenizer Benchmark with AutoRAG", GitHub, 2024. https://github.com/Marker-Inc-Korea/AutoRAG-example-korean-embedding-benchmark
Lee et al., "MoB: Morphological Boundary-aware Subword Tokenization", EACL, 2026.
LangChain, "BSHTMLLoader". https://python.langchain.com/docs/integrations/document_loaders/bshtml
BeautifulSoup4, "Differences between parsers". https://www.crummy.com/software/BeautifulSoup/bs4/doc/
Unstructured.io, "Partitioning". https://docs.unstructured.io/open-source/core-functionality/partitioning
Kiwi, "kiwipiepy 공식 문서". https://bab2min.github.io/kiwipiepy/
Ahn et al., "Benchmarking Korean Morphological Analyzers", Applied Sciences, 2023.
KoNLPy, "API Reference, konlpy.tag". https://konlpy.org/ko/stable/api/konlpy.tag/
정승한, "요기요 검색에서 형태소 분석기의 한계와 극복", 요기요 기술블로그, 2024. https://techblog.yogiyo.co.kr/요기요-검색에서-형태소-분석기의-한계와-극복-3da53beb6ea5

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