RAG를 붙였는데도 답이 흔들릴 때: 생성형 AI에서 온톨로지를 써야 하는 이유

문서를 더 넣는다고 답이 더 안정되지는 않습니다

PDF, 정책 문서, 상담 기록을 인제스트해서 RAG를 붙였는데도 답변이 들쭉날쭉하다면, 먼저 검색 품질만 의심할 필요는 없습니다. 문서를 얼마나 잘 찾느냐보다, 그 문서들이 같은 의미 체계 안에 있느냐가 더 큰 문제일 수 있습니다.

이때 필요한 것이 온톨로지입니다. 온톨로지는 검색 엔진의 대체재가 아니라, 기업 안에서 어떤 개념을 무엇으로 볼지 미리 정해두는 의미의 지도입니다. 생성형 AI에서는 이 지도가 있어야 RAG도 믿을 수 있는 입력을 다루게 됩니다.

독자의 질문으로 바꾸면 답은 이렇습니다. 문서 텍스트는 일반적인 로드-청킹-임베딩-적재만으로 끝낼 대상이 아니라, 넣기 전에 의미를 통제해야 하는 데이터입니다. 특히 같은 대상을 여러 이름으로 부르거나, 정형 데이터와 문서 데이터를 함께 써야 한다면 더 그렇습니다.

생성형 AI에서 온톨로지는 텍스트용 데이터 모델에 가깝습니다.

온톨로지는 텍스트 세계의 데이터 모델입니다

정형 데이터에서는 데이터 모델이 기준점입니다. 고객, 주문, 계좌 같은 엔터티가 무엇인지 정하고, 어떤 속성을 가지며 서로 어떻게 연결되는지 정의합니다. 그리고 데이터베이스는 그 모델에 맞춰 저장되고 관리됩니다.

문서는 다르게 움직입니다. 같은 대상을 어떤 문서에서는 “고객”, 다른 곳에서는 “회원”, 또 다른 곳에서는 “사용자”라고 부를 수 있습니다. 표현은 제각각이고, 필요한 정보는 여러 문장과 문서에 흩어져 있습니다.

이 환경에서 온톨로지는 “우리 조직은 이 단어와 개념을 어떻게 이해할 것인가”를 정합니다. 예를 들어 “고객”, “회원”, “사용자”를 같은 것으로 볼지, 상황에 따라 구분할지, 더 큰 상위 개념 아래 묶을지를 결정하는 식입니다. 이 기준이 없으면 RAG가 문서를 잘 찾아도, 서로 다른 뜻을 한 답변 안에서 섞을 가능성이 있습니다.

실무에서는 이 차이가 꽤 큽니다. 검색은 관련 문서를 가져오지만, 온톨로지는 가져온 문서가 같은 대상을 말하고 있는지를 판단하는 기준이 됩니다. 즉, 검색의 정확도와 의미의 일관성은 다른 문제입니다.

왜 생성형 AI에서 이 문제가 더 커졌나

예전에도 데이터 품질 문제는 있었습니다. 여러 시스템에 같은 데이터가 반복 저장되면, 어느 값을 믿어야 하는지가 문제가 됩니다. 그래서 기업은 단순 저장보다 데이터의 정의와 신뢰 기준을 더 중요하게 다뤄왔습니다.

생성형 AI는 이 문제를 텍스트 영역으로 확장합니다. 이제 중요한 입력은 데이터베이스 레코드만이 아니라, LLM에 들어가는 방대한 문서 텍스트입니다. 신뢰하기 어려운 텍스트가 들어가면, 그 위에서 만들어지는 답변도 흔들릴 수밖에 없습니다.

여기서 정형 데이터와 다른 점이 있습니다. 데이터베이스는 스키마나 제약 조건을 직접 바꿔 통제할 수 있지만, LLM은 그렇게 다루기 어렵습니다. 그래서 통제 지점이 모델 내부가 아니라 입력 텍스트의 선택, 정제, 분류로 이동합니다.

이 관점에서 보면 온톨로지는 부가 기능이 아닙니다. 생성형 AI에서 데이터 관리는 “문서를 얼마나 많이 모았는가”보다 “어떤 의미 체계로 걸러서 넣는가”의 문제에 가까워집니다.

RAG와 온톨로지는 같은 문제를 풀지 않습니다

실무에서 가장 많이 나오는 질문은 이것입니다. “RAG도 결국 문서를 골라 넣는 건데, 온톨로지와 뭐가 다른가?” 겉으로는 비슷해 보여도, 둘은 통제하는 대상이 다릅니다.

RAG는 보통 질의 시점의 문제를 풉니다. 지금 사용자의 질문에 맞는 문서를 무엇으로 가져올지 결정하는 데 초점이 있습니다. 반면 온톨로지는 그보다 앞단에서, 어떤 문서를 남길지, 어떤 개념으로 묶을지, 무엇을 같은 의미로 볼지를 정합니다.

예를 들어 사내 정책 문서, 고객 문의, 외부 자료를 함께 쓰는 Agent를 생각해보겠습니다. 검색만 잘 되면 필요한 문서는 찾을 수 있습니다. 하지만 어떤 문서에서는 “상품”, 다른 문서에서는 “서비스”, 또 다른 문서에서는 “플랜”이 비슷하거나 다르게 쓰인다면, 검색 성공이 곧 답변 안정성을 보장하지는 않습니다.

이때 온톨로지는 용어의 경계와 관계를 정합니다. 그래서 RAG가 가져온 문서들이 같은 의미 체계 안에서 해석되도록 돕습니다. 정리하면, RAG는 문서를 가져오는 기술이고 온톨로지는 문서가 무엇을 뜻하는지 정하는 체계입니다.

인제스트 파이프라인 앞에 하나의 질문을 더 둬야 합니다

많은 팀이 문서를 다룰 때 로드 → 청킹 → 임베딩 → 적재 흐름부터 설계합니다. 이 파이프라인 자체가 틀렸다는 뜻은 아닙니다. 다만 그 전에 하나를 더 물어야 합니다.

이 텍스트는 우리 조직이 AI에게 이해시키고 싶은 세계에 속하는가?

이 질문이 빠지면 두 가지 문제가 생길 수 있습니다. 첫째, 업무와 직접 관련 없는 텍스트까지 계속 유입되어 처리 범위가 불필요하게 넓어집니다. 둘째, 업무 관련 텍스트만 남겼더라도 같은 대상을 다른 이름으로 부르는 문서들이 섞여 의미 충돌이 발생할 수 있습니다.

그래서 생성형 AI에서 온톨로지가 하는 가장 실무적인 일은 화려한 추론이 아니라, 텍스트를 덜 넣고 맞게 넣는 것입니다. 많이 넣는 것보다, 어떤 기준으로 제외하고 어떤 기준으로 묶는지가 더 중요해집니다.

실무에서는 아래 질문으로 점검해볼 수 있습니다.

• 이 텍스트는 우리 업무와 직접 관련이 있는가
• 같은 대상을 다른 이름으로 부르는 문서가 섞여 있는가
• 서로 다른 개념인데 같은 단어를 쓰는 경우가 있는가
• 새 문서가 들어왔을 때 기존 분류체계에 무리 없이 들어가는가

이 질문에 자주 막힌다면, 청킹 전략이나 검색 파라미터를 더 만지기 전에 의미 체계부터 점검하는 편이 낫습니다.

정형 데이터와 문서를 함께 쓰려면 ELDM과 연결해야 합니다

온톨로지가 텍스트의 의미 체계라면, ELDM은 기업 전체의 논리 데이터 모델입니다. 생성형 AI 환경에서 중요한 점은 온톨로지가 문서 안에서만 닫혀 있으면 한계가 있다는 것입니다.

현실의 질문은 정형 데이터와 비정형 텍스트를 나눠 오지 않습니다. 사용자는 “이 고객은 어떤 상품을 쓰고 있고, 최근 어떤 이슈가 있었나?”처럼 한 번에 묻습니다. 여기에는 데이터베이스의 고객 정보와 문서 속 상담 기록, 정책 설명, 계약 관련 텍스트가 함께 필요합니다.

이때 ELDM은 연결축 역할을 합니다. 예를 들어 데이터베이스의 customer_id와 문서 속 “고객”, “회원”, “법인 사용자”가 어떤 관계인지 맞춰야 합니다. 그래야 정형 데이터와 텍스트가 같은 대상을 가리키는지 일관되게 해석할 수 있습니다.

여기서 핵심은 물리적으로 한곳에 모으는 것이 아닙니다. 중요한 것은 의미론적 중앙집중, 즉 저장 위치가 아니라 의미와 정의를 중앙에서 맞추는 일입니다. 데이터는 흩어져 있어도, 개념 기준은 흩어지면 안 됩니다.

온톨로지는 한 번 설계하고 끝내는 문서가 아닙니다

온톨로지를 도입할 때 흔히 “정답 구조를 한 번에 설계해야 하나”라는 부담이 생깁니다. 하지만 제공된 정보만 놓고 보면 더 현실적인 기준은 완성도가 아니라 지속적으로 갱신 가능한가입니다.

텍스트와 외부 환경은 계속 바뀝니다. 새 문서가 들어오고, 업무 용어가 달라지고, 외부 자료가 유입됩니다. 특히 외부 텍스트를 다룬다면 먼저 넓게 수집하고, 그다음 기업 업무와 관련된 텍스트만 다시 추리는 2단계 선별이 필요할 수 있습니다.

따라서 온톨로지는 산출물이라기보다 운영 체계에 가깝습니다. 아래 기준이 더 실무적입니다.

• 새 문서와 새 업무가 들어와도 분류체계를 계속 갱신할 수 있는가
• 정형 데이터의 개념과 텍스트 개념이 충돌할 때 조정 기준이 있는가
• LLM에 들어가는 텍스트 범위를 조직 차원에서 관리할 수 있는가

이 기준을 만족하지 못하면, 온톨로지를 만들었다고 해도 실제 운영에서는 금방 낡을 가능성이 있습니다.

언제는 가벼운 분류체계로도 충분한가

모든 팀이 처음부터 큰 온톨로지를 설계할 필요는 없습니다. 문서 범위가 좁고, 용어가 거의 고정돼 있으며, 정형 데이터와의 연결도 약하다면 가벼운 분류체계부터 시작하는 편이 현실적일 수 있습니다.

반대로 아래 상황이라면 온톨로지의 필요성이 커집니다.

• 검색은 되는데 답변의 개념 경계가 자주 흔들릴 때
• 같은 엔터티가 시스템과 문서마다 다른 이름으로 등장할 때
• 정형 데이터와 문서 데이터를 함께 써야 할 때
• 외부 텍스트가 계속 유입되어 입력 범위 통제가 중요할 때

실무 판단 기준은 단순합니다. 지금 겪는 문제가 “못 찾는 문제”인지, 아니면 “같은 것으로 봐야 할 것을 다르게 이해하는 문제”인지 구분해보면 됩니다. 전자라면 검색 개선이 우선일 수 있고, 후자라면 온톨로지나 분류체계가 먼저일 가능성이 큽니다.

참고 자료

• https://williaminmon.substack.com/p/data-management-in-the-age-of-ai
• https://news.hada.io/topic?id=31681