황혜수 연구원

AI Engineer · AIWORKX R&D센터 지능화멀티모달연구팀

RAG·LLM 기반 시스템을 연구·기획하고 직접 개발합니다. 특수 도메인 RAG의 검색 설계와 온톨로지 구축을 실무에서 풀어내는 데 집중하고 있습니다.

RAGGraph RAG온톨로지

1편에서 우리는 데이터 전처리가 RAG 전체 성능에 미치는 치명적인 영향에 대해 알아보았습니다. 복잡한 표나 다단 레이아웃에 숨겨진 정보를 온전히 추출하고, 이를 최종적으로 AI가 완벽히 이해할 수 있는 텍스트 조각으로 엮어내는 과정을 거쳤죠.

이렇게 데이터 정제를 성공적으로 마무리했다면, 이제 이 데이터를 벡터 데이터베이스(Vector DB)에 넣고 검색만 띄우면 완벽한 RAG가 완성될까요?

안타깝게도 범용적인 RAG 아키텍처를 실무의 ‘특수 도메인’에 무작정 끼워 넣었다간, 우리는 또 다른 거대한 벽에 부딪히게 됩니다. 이번 2편에서는 단순한 벡터 검색이 실제 현장에서 어떻게 한계를 드러내는지, 그리고 이 문제를 해결하기 위해 어떤 방식으로 검색 파이프라인이 진화되어 왔는지, 그 여정을 함께 따라가 보고자 합니다.

1. RAG에서의 ‘검색’은 어떻게 이루어지는가? (BM25와 벡터 검색)

본격적인 현장의 문제에 들어가기에 앞서, 기본기를 잠시 짚고 넘어가겠습니다. RAG 파이프라인에서 말하는 ‘검색(Retrieval)’은 크게 두 가지 갈래로 나뉩니다.

1-A. 전통의 강자, 키워드 검색 (BM25)

우리가 매일 사용하는 포털 검색 엔진의 근간이 되는 방식입니다. 사용자가 입력한 검색어(키워드)가 문서에 포함되어 있는지를 따집니다. 어떤 단어가 문서에 자주 등장할수록(TF), 그리고 전체 문서들에서는 잘 안 나오는 희귀한 단어일수록(IDF) 가중치를 높게 주는 직관적인 알고리즘입니다.

BM25는 고유명사나 식별 코드를 찾아내는 데 매우 강력하지만, 치명적인 약점이 하나 있습니다. 바로 ‘의미론적 검색’이 불가능하다는 점입니다.

BM25의 한계 예시
“요즘 복숭아가 제철이라던데 괜찮은 거 파는 곳 좀 알고 싶네”라고 질의했을 때, 사용자의 진짜 의도는 “맛있는 복숭아”를 찾는 것입니다. 하지만 문서에 “환상적인 당도의 복숭아”라고 적혀 있다면, BM25는 ‘맛있는’이라는 정확한 텍스트 매칭이 없기 때문에 이 훌륭한 문서가 우선순위에서 밀려나게 됩니다.

1-B. 의미를 이해하는 벡터 검색 (Vector Search)

키워드의 한계를 극복하기 위해 등장한 것이 바로 벡터 검색입니다. 텍스트를 고차원의 숫자 배열(Vector)로 변환하여 임의의 공간에 흩뿌려두고, 사용자의 질문과 가장 가까운 거리에 있는 텍스트를 찾아오는 방식입니다.

여기서 RAG의 핵심 엔진인 ‘임베딩(Embedding)’ 기술이 쓰입니다. 문맥과 속뜻을 파악하여, 앞선 예시의 “당도 높은 복숭아”를 찰떡같이 찾아내는 것이 바로 이 벡터 검색입니다.

2. 실전에서 마주한 Vector RAG의 한계: 복합 질의의 늪

이 벡터 임베딩을 기반으로 구성된 것이 우리가 흔히 접하는 ‘기본 Vector RAG’입니다. 튜토리얼에서는 충분히 원활하게 작동하지만, 특수 도메인(의료, 법률, 공공 규정 등)과 같은 현실 세계에 이 아키텍처를 도입하는 순간 시스템은 여지없이 한계에 부딪힙니다.

이러한 한계가 실무에서 구체적으로 어떻게 나타나는지, 제가 과거 건강보험심사평가원 PoC인 RAG 시스템을 개발하며 직접 부딪혔던 사례를 통해 짚어보겠습니다.

당시 건강보험심사평가원은 매년 업데이트되는 고시, 심사 지침, 규정 문서들을 방대하게 다루고 있었습니다. 실무자들의 질문은 튜토리얼처럼 단순하지 않았습니다. “A질환 급여 기준은?”이라고 묻는 것이 아니라, “2023년 5월 진료 기준, 65세 이상 여성 환자의 A질환 급여 인정 여부는?”과 같이 특정 시점과 특정 조건이 얽힌 ‘복합 질의(Complex Query)’가 대부분이었습니다.

이 리얼월드의 질문 앞에서 단순 Vector RAG는 무시할 수 없는 핵심적인 문제들을 드러냈습니다.

• 도메인 특화 용어의 취약성 (OOD, Out-of-Distribution): 임베딩 모델은 전반적인 맥락은 잘 파악하지만, 학습 과정에서 보지 못한 사내 전문 용어나 미세한 질병 코드의 차이를 민감하게 구분하지 못했습니다. 코드가 하나만 달라도 완전히 다른 병인데, 모델은 뭉뚱그려 ‘비슷한 문맥’이라며 높은 점수를 줘버렸습니다.
• 조건 검색(시점/타겟)의 붕괴: 최신 문서만 남기고 다 지울 수 있으면 좋겠지만, 심사와 감사를 위해서는 ‘과거 특정 시점’의 규정이 반드시 필요합니다. 결국 체감상 90%의 내용에 변동이 없다고 느껴지는 과거와 현재의 문서들이 DB에 섞이게 되는데, 벡터 모델은 텍스트의 ‘의미’만 잴 뿐 ‘65세 이상’, ‘여성’, ‘2023년 5월’이라는 수학적이고 논리적인 조건(Condition)을 연산하지 못합니다.

그 결과, 우연히 의미 유사도가 높게 측정된 ‘남성 기준 문서’나 ‘엉뚱한 시점의 고시’를 당당하게 제시하는 할루시네이션(환각)이 발생했습니다.

3. 검색 파이프라인의 진화, 그리고 또 다른 장벽: 하이브리드에서 Graph RAG까지

이러한 한계를 극복하기 위해, 엔지니어들은 검색 파이프라인을 진화시키기 시작했습니다. 저 또한 마찬가지였죠.

진화 1: 하이브리드(Hybrid) RAG의 도입

가장 먼저 적용한 것은 키워드 검색(BM25)과 벡터 검색의 순위를 합산해 재정렬하는 RRF(Reciprocal Rank Fusion) 기반의 Hybrid RAG였습니다. 고유명사나 식별 코드를 정확히 잡아내며 첫 번째 문제(OOD) 등을 훌륭하게 방어해 내며, 검색의 정확도를 높일 수 있었습니다.

하지만 두 번째 문제인 복합 조건 검색의 한계는 여전히 제자리걸음이었습니다. BM25 알고리즘에게 ‘2023년’이나 ‘65세’는 그저 텍스트 쪼가리일 뿐, 문서를 논리적으로 필터링하는 장치가 되어주진 못했기 때문입니다.

진화 2: Graph RAG의 등장

단순한 텍스트 매칭만으로는 지식의 전후 관계와 조건을 파악할 수 없음을 깨달은 우리는, Graph RAG에 주목했습니다. 정보를 텍스트 덩어리가 아닌 주어-동사-목적어(Triplet)로 쪼개어 지식 그래프를 만들면, 정보 간의 ‘관계’를 통해 복합 조건 질의도 척척 풀어낼 수 있을 거라 기대했죠.

하지만 한국어 기반의 실무 생태계에 Graph RAG를 무작정 도입하는 것은 그야말로 ‘가시밭길’입니다. 한국어 특유의 복잡한 ‘조사’(은/는/이/가처럼 단어에 붙는 문법 요소) 때문에 LLM은 정보 추출 과정에서 엄청난 노이즈를 뱉어냅니다. 또한 동일한 의미에 대해 통일되지 않은 표현을 쓰거나, 중요하지 않은 정보를 엮어내는 등 기준 없이 무작정 뽑아낸 Triplet(Graph RAG가 지식을 저장하는 최소 단위)은 법령이 가진 엄격한 위계 질서를 구조화하기는커녕, 파편화시켜 엉망진창으로 꼬아버리기도 하죠.

4. 제대로 된 Graph RAG를 위한 필수 전제조건: 온톨로지(Ontology)

그렇다면 실무에서 Graph RAG는 쓸 수 없는 기술일까요? 아닙니다. Graph RAG를 오작동 없이 ‘제대로’ 구축하기 위해서는, 그 근간이 되는 지식의 ‘뼈대’를 먼저 세워야 합니다.

무작정 텍스트를 쪼개어 노드를 연결하기 전에 반드시 선행되어야 하는 이 근본적인 밑작업, 그것이 바로 ‘온톨로지(Ontology)’입니다.

온톨로지란 도메인 내의 개념, 속성, 그리고 그 관계를 명시적으로 정의한 데이터 스키마(Schema)입니다. 쉽게 말해 RAG 시스템에게 “이 도메인의 데이터는 이런 규칙과 위계를 가지고 있어”라고 미리 지도를 그려주는 것입니다.

단순히 문서를 청킹(Chunking)하는 것이 아니라, 온톨로지 스키마를 통해 다차원적인 메타데이터를 강제로 주입하면 기계는 비로소 단순한 텍스트를 넘어선 ‘맥락과 조건’을 이해하게 됩니다.

실전 예시로 보는 온톨로지와 지식 그래프(Knowledge Graph)의 차이

비유하자면 온톨로지는 ‘건축 설계도(Schema)’이고, 지식 그래프는 설계도에 따라 지어진 ‘실제 건물(Data)’입니다. 다음 문장을 RAG 시스템이 어떻게 처리하는지 따라가 보겠습니다.

원문 텍스트
“2023년 5월 1일부터 개정된 규정에 따라, A질환은 65세 이상 여성 환자에 한하여 요양급여를 인정한다.”

① 온톨로지 (설계도 정의)

문서를 무작정 쪼개기 전에, “이 도메인에는 어떤 개념(Class)이 있고 서로 어떤 관계(Relation)를 맺는가?”를 미리 정의합니다.

• 클래스: 규정, 질환, 연령조건, 성별조건, 시행일
• 관계: appliesTo(적용대상), hasCondition(세부조건), hasDate(시행일)

② 지식 그래프 (실제 데이터 구축)

온톨로지라는 뼈대를 바탕으로 원문을 분석하면, 텍스트가 쪼개지며 실제 노드(Node)와 엣지(Edge)가 생성됩니다. (실제 데이터베이스에는 (규정#230501, appliesTo, A질환) 같은 트리플(Triple) 형태로 저장됩니다.)

③ 굳이 이렇게 복잡하게 만드는 이유가 뭔가요?

사용자가 “70세 남성도 A질환이면 급여가 되나요?”라고 질문했다고 가정해 봅시다. 단순 텍스트 검색(Vector RAG)이었다면 ‘70세’, ‘남성’, ‘A질환’, ‘급여’라는 단어들의 의미 유사도에 휘둘려 오답을 낼 확률이 높습니다. 하지만 그래프 환경에서는 논리적인 조건 탐색이 진행됩니다. A질환 규정을 탐색 → Gender = 여성 조건 확인 → 질의한 남성과 불일치(남성 ≠ 여성) → “급여 대상이 아닙니다”라는 정확한 결론 도출.

만약 문서에 “2024년부터는 남성도 인정한다”는 새로운 규정이 추가된다면 어떨까요? Vector RAG는 23년 문서와 24년 문서 사이에서 길을 잃겠지만, 지식 그래프는 규정#240101이라는 새로운 노드를 하나 더 붙이기만 하면 됩니다. 사용자가 “23년 8월 기준”을 묻느냐, “25년 기준”을 묻느냐에 따라 정확히 해당 시점의 노드만 따라가면 되기 때문입니다.

이렇게 온톨로지의 옷을 입고 뼈대가 잡힌 데이터는 뚜렷한 시공간적 좌표와 대상 조건을 가진 ‘지식 자산’으로 변모합니다. 이 단단한 뼈대가 있어야만 비로소 조사의 간섭이나 노이즈 없는 깨끗한 Graph RAG를 만들 수 있고, 복합 질의에도 대처할 수 있는 시스템이 완성됩니다.

5. 이상과 현실의 타협점, 그리고 시스템화

이론적으로는 완벽하지만, 실무에서 온톨로지를 구축하는 과정은 끝없는 수작업의 연속입니다. 특히 현장에서 맞닥뜨리는 가장 큰 고민은 두 가지로 요약됩니다.

• HITL (Human-In-The-Loop) 개입 시점: 언제 사람이 개입해서 검수할 것인가? LLM에게 무작정 맡기는 것은 능사가 아닙니다. 도메인 전문가가 중간에 개입해 올바른 방향을 제시하는 구조가 필수적입니다. 도메인에 대한 전문 지식을 제공함으로써 LLM이 가고 있는 방향이 맞는지 확인하고, 아니라면 수정해주는 과정이 결합될 때 보다 안정적인 구축이 가능합니다.
• 구조화의 타협선 (Granularity & Scope): 가장 현실적이고 뼈아픈 타협점입니다. 무작정 모든 사내 데이터를 그래프로 만들겠다고 덤비면 프로젝트는 100% 좌초합니다. 단순한 줄글 형태의 인사말이나 일반 보고서는 벡터 검색으로 넘기고 위계가 명확한 ‘규정/매뉴얼’에만 Graph를 도입하는 선택과 집중, 그리고 문장 단위가 아닌 문단(Paragraph), 문서(Document), 상위 폴더(Folder) 단위까지 치밀하게 쪼개기 단위의 타협점을 찾는 일이 필요합니다.

“이 복잡하고 고된 타협과 검증의 과정을 매번 새 프로젝트마다 수작업으로 반복할 수는 없다.”

현장에서 뼈저리게 느낀 이 한계점이, 저희 AIWORKX(에이아이웍스)가 온톨로지 구축 및 검증 과정을 아예 ‘하나의 AI 파이프라인으로 시스템화’하게 된 결정적 계기가 되었습니다.

AI에게 무작정 구축을 맡기는 것이 아니라, LLM이 초석을 제안하면 도메인 전문가(인간)가 개입하여 방향을 수정하고, 이를 지속적으로 비교·평가하는 ‘AI-인간 협업 시스템’을 구축한 것입니다. 이 파이프라인을 거쳐 앞서 고민했던 타협점(어떤 문서, 어느 단위)이 세밀하게 조율되고 정제된 Triplet을 추출해 내면 비로소 신뢰성 높은 Graph RAG가 완성됩니다.

이러한 과정을 통해 관계와 조건에 강한 Graph, 단어 매칭에 강한 BM25, 유사도에 강한 Vector 검색기가 어우러져 삼위일체로 작동할 때, 어떤 악조건의 도메인에서도 굴하지 않는 강건한 하이브리드 RAG 시스템이 탄생하게 됩니다.

데이터 정제의 늪(1편)을 지나, 도메인 지식을 구조화하여 검색 아키텍처(2편)까지 완성하며 RAG 파이프라인은 이제 원활하게 돌아가기 시작했습니다. 그렇다면 마지막으로, 기업에 RAG를 도입하는 엔지니어와 PM이 가장 두려워하는 질문 하나가 남습니다.

“그래서, 우리가 힘들게 만든 이 시스템이 얼마나 똑똑하게 동작하는지, 경영진에게 어떤 ‘숫자’로 증명할 수 있나요?”

다음 3편 「RAG, 도대체 어떻게 평가할 것인가?」에서는 막막하기만 한 RAG 성능 평가의 어려움과 지표 설계, 그리고 도메인 특화 데이터셋을 직접 구축해 모니터링 체계를 만들어내는 과정을 공유하겠습니다.

자주 묻는 질문 (FAQ)

Q1. 벡터 검색(Vector RAG)의 한계는 무엇인가요?

의미 유사도만 계산하기 때문에 ‘65세 이상’, ‘2023년 5월’처럼 시점과 대상이 얽힌 논리 조건을 연산하지 못합니다. 의미가 비슷한 엉뚱한 문서를 제시하는 할루시네이션이 발생할 수 있습니다.

Q2. 하이브리드 RAG(Hybrid RAG)란 무엇인가요?

키워드 검색(BM25)과 벡터 검색의 순위를 RRF(Reciprocal Rank Fusion)로 합산해 재정렬하는 방식입니다. 고유명사와 식별 코드에 강해 도메인 용어 취약성을 보완하지만, 복합 조건 검색은 해결하지 못합니다.

Q3. Graph RAG란 무엇인가요?

정보를 텍스트 덩어리가 아닌 주어-동사-목적어 트리플(Triplet)로 쪼개 지식 그래프를 만들고, 정보 간의 ‘관계’를 따라 탐색하는 RAG 방식입니다. 조건이 얽힌 복합 질의에 강합니다.

Q4. 온톨로지와 지식 그래프의 차이는 무엇인가요?

온톨로지는 도메인의 개념과 관계를 정의한 ‘건축 설계도(스키마)’이고, 지식 그래프는 그 설계도에 따라 실제 데이터를 연결한 ‘건물(인스턴스)’입니다.

Q5. Graph RAG는 언제 도입해야 하나요?

모든 문서에 적용하면 프로젝트가 좌초하기 쉽습니다. 위계가 명확한 규정·매뉴얼처럼 조건이 얽힌 문서에 선택적으로 도입하고, 단순 줄글 문서는 벡터 검색으로 처리하는 선택과 집중이 필요합니다.

관련 글 · 시리즈

• 1편: RAG의 환상과 현실: 비정형 데이터 전처리의 늪 탈출하기
• 3편: RAG, 도대체 어떻게 평가할 것인가 (지표와 도메인 특화 데이터셋, 발행 예정)
• AI 에이전트 평가, 왜 기존 LLM 벤치마크로는 부족한가
• AI를 만드는 시대에서, 검증하는 시대로