컴키
경영 위키 →문의데모 신청 →
실전 구축기5 min read

한국어 RAG가 어려운 이유 — 조사·별칭·부분일치 3대 함정

영어 기준으로 만든 검색 파이프라인은 한국어에서 조용히 틀립니다. 에러가 안 나서 더 위험합니다. 실제로 겪은 세 가지 함정과 해법.

01에러가 안 나서 위험합니다

한국어 RAG의 문제는 예외를 던지지 않는다는 점입니다. 검색은 정상적으로 결과를 반환하고, 모델은 그럴듯한 답을 만듭니다. 다만 근거가 틀렸을 뿐입니다. 테스트는 통과하고 사용자만 조용히 떠납니다.

영어 기준 파이프라인을 그대로 가져와 한국어에 쓸 때 반복적으로 걸리는 함정 세 가지를 정리합니다.

한국어 RAG 3대 함정 — 조사·부분일치 과탐·별칭

02함정 1. 조사가 매칭을 깨뜨린다

한국어는 교착어입니다. 명사 뒤에 조사가 붙어 표면형이 계속 바뀝니다.

문서에 적힌 형태사용자 질의단순 매칭 결과
토스에서 요청한토스❌ 불일치
토스와 협의토스❌ 불일치
토스의 담당자토스❌ 불일치

영어라면 Toss는 언제나 Toss입니다. 한국어에서는 토스에서, 토스와, 토스의, 토스는이 전부 다른 문자열입니다.

해법

  • 형태소 분석 기반 색인 — 한국어 분석기(예: nori)로 어간을 분리해 색인합니다. 키워드 검색을 쓴다면 사실상 필수입니다.
  • 조사 어간 매칭 — 분석기를 붙이기 어려운 경로에서는, 질의어에 대해 조사 목록을 접미로 허용하는 매칭을 씁니다.
  • 불용어 제거 — "알려줘", "어떻게 되나요" 같은 표현이 검색어에 섞이면 유사도가 흐려집니다. 질의 전처리에서 걷어냅니다.

임베딩 검색을 쓰면 이 문제가 자동으로 해결된다고 흔히 오해합니다. 상당 부분 완화되는 건 맞지만, 고유명사 정확 매칭에서는 여전히 키워드 경로가 필요합니다. 하이브리드 검색이 안전합니다.

03함정 2. 부분일치 과탐 — 토스 ⊄ 토스트

반대 방향의 문제입니다. 짧은 고유명사가 다른 단어에 포함되어 없는 관련성을 만들어냅니다.

  • 토스로 검색 → 토스트 관련 문서가 걸립니다
  • TMS로 검색 → TMS Cloud, TMS-web 문서가 전부 걸립니다
  • SK로 검색 → 온갖 계열사가 걸립니다

엔티티 자동 추출에서 이 문제는 더 심각합니다. 본문에 TMS Cloud라고 적혀 있는데 시스템이 TMS도 함께 추출하면, 하나의 사건이 두 제품의 실적으로 이중 집계됩니다.

해법

  • 긴 표기 우선(longest match first) — 후보 사전을 길이 내림차순으로 정렬해 TMS Cloud를 먼저 매칭합니다.
  • 구간 점유(span occupation) — 매칭된 문자 구간을 점유 처리해, 이미 소비된 구간에서 짧은 후보가 다시 잡히지 않게 합니다.
  • 한글 단어경계 판정 — 영어의 \b는 한글에서 의도대로 동작하지 않습니다. 매칭 구간의 앞뒤 문자가 한글 음절인지 확인해, 음절이 이어지면 경계 미성립으로 처리합니다. 이 한 줄이 토스/토스트 오탐을 없앱니다.

04함정 3. 같은 것을 다르게 부른다

현업 문서에서 하나의 대상은 절대 하나의 이름으로 불리지 않습니다.

㈜○○커머스 / ○○커머스 / ○○ / OO Commerce / 오커머스(오타)

이걸 방치하면 고객사 하나가 다섯 개로 쪼개져 집계됩니다. 대시보드 숫자가 전부 틀리고, "○○ 진행 상황"을 물으면 5분의 1만 근거로 잡힙니다.

해법: 별칭 사전을 마스터데이터로 관리합니다.

  • 정식 명칭 1개 + 별칭 N개를 등록하고, 추출·검색 모두 이 사전을 참조합니다.
  • 추출은 사전에 실재하는 엔티티만 반환하도록 제한합니다. LLM에게 자유롭게 회사명을 뽑으라고 하면 없는 회사를 만들어냅니다. 화이트리스트 방식이 환각을 구조적으로 차단합니다.
  • 이미 쪼개진 엔티티는 병합 기능이 필요합니다. 운영 6개월이면 반드시 중복이 생깁니다.
  • 사람에게 표기 통일을 요구하지 마십시오. 지켜지지 않습니다. 시스템이 흡수하는 것이 유일하게 작동하는 방식입니다.

05보너스 함정. 유니코드 정규화

한글에는 함정이 하나 더 있습니다. 같은 글자가 두 가지로 저장될 수 있습니다.

  • NFC (완성형 1글자)
  • NFDㅎ + ㅏ + ㄴ (자모 분해형)

macOS 파일 시스템은 NFD를 씁니다. 그래서 파일명을 그대로 저장하면 DB에 NFD로 들어가고, 사용자가 웹에서 입력한 NFC 문자열과 육안으로 동일한데 문자열 비교가 실패합니다. 검색이 안 되는데 원인을 못 찾는 전형적인 상황입니다.

해법 입력 경계에서 무조건 NFC로 정규화한 뒤 저장·비교하십시오. 특히 파일 업로드 경로가 위험합니다.

06검증 방법

세 함정 모두 평가셋 없이는 발견되지 않습니다. 최소한 아래를 고정 테스트로 두십시오.

  • 조사가 붙은 형태 5종으로 같은 고유명사를 검색해 동일 결과가 나오는가
  • 짧은 이름이 긴 이름을 오탐하지 않는가 (TMS vs TMS Cloud)
  • 별칭 5종이 하나의 엔티티로 모이는가
  • NFD로 저장된 문자열이 NFC 질의로 검색되는가

우리는 이 4개를 회귀 테스트로 박아두고 나서야 "검색이 왜 이러지"를 반복하지 않게 됐습니다.

07자주 묻는 질문

Q임베딩만 쓰면 형태소 분석이 필요 없지 않나요?
의미 검색에는 강하지만 고유명사·숫자·코드처럼 정확히 일치해야 하는 것에는 약합니다. "○○기업 계약 금액"처럼 특정 대상을 지목하는 질의에서 키워드 경로가 없으면 엉뚱한 문서가 올라옵니다. 하이브리드를 권합니다.
Q청크는 어떻게 나누는 게 좋나요?
한국어는 문장이 길어 고정 길이로 자르면 중간이 끊깁니다. 의미 단위(제목·섹션·필드)로 자르는 편이 훨씬 낫습니다. 구조화된 기록이 RAG에 유리한 이유이기도 합니다. 그리고 조용한 절단은 답변 품질을 눈에 띄지 않게 갉아먹으니, 길이 초과로 잘린 경우 반드시 로그로 남기십시오.
Q오픈소스 한국어 임베딩 모델로 충분한가요?
문서 규모가 크지 않고 도메인 용어가 사전으로 잡혀 있으면 실용상 충분한 경우가 많습니다. 모델을 바꾸기 전에 위 세 함정을 먼저 점검하십시오. 체감 개선폭이 훨씬 큽니다.
Get Started

회사를 벗어나지 않는
우리 회사 전용 AI 위키

같은 고민을 하고 계시다면, 실제로 운영 중인 화면을 보여드리겠습니다.

Read Next