RAG만으로 부족한 순간: Context·Knowledge Graph·Ontology를 어디까지 써야 하나
기업 AI에서 'RAG 정확도가 낮다'는 말 속에는 문서 검색, 관계 탐색, 의미·규칙 정의라는 서로 다른 층의 문제가 섞여 있다. Context·Knowledge Graph·Ontology가 각각 무엇을 해결하는지 구분하고, GraphRAG와 온톨로지를 올려야 하는 업무 조건과 운영 비용의 경계를 제품·기술 구조 관점에서 정리한다.
참고로 이 글은 Context·Knowledge Graph·Ontology·GraphRAG의 개념 경계와 도입 순서를 다루는 구조 비교 글이다. 이 분야는 도구와 용어의 기능이 빠르게 겹쳐지고 바뀌는 중이라, 여기 제시하는 구분과 사례는 특정 제품·구현의 정답이나 우열을 말하는 것이 아니다. 자기 조직의 질문 유형과 오류 신호에 맞춰 해석 기준으로만 쓰기 바란다.
“사내 지식검색 RAG 정확도가 낮습니다.” 이 한마디 속에는 실제로는 서로 다른 문제가 섞여 있다. 최신 문서를 못 찾는 문제, 여러 시스템의 관계를 따라가지 못하는 문제, 같은 단어의 뜻이 조직마다 다른 문제. 셋은 해법이 다르다. 이 글은 그 경계를 Context·Knowledge Graph·Ontology의 세 층으로 나누고, 어느 신호가 보일 때 구조를 한 단계 올려야 하는지를 정리한다.
“정확도가 낮다”는 말 속에 섞여 있는 세 가지 문제
반도체 회사의 특성상 사내에는 절차서, 장비 매뉴얼, 품질 기준, 변경 관리 기록처럼 효력과 버전이 중요한 문서가 많다. 이런 환경에서 지식검색을 만들면 “이번 분기 해외 반출 승인 절차가 뭐지?” 같은 질문이 들어오는데, 답변은 작년 정책과 국내 정책, 이미 폐기된 양식을 섞어서 가져오는 일이 반복된다.
AX 담당자 입장에서 이 현장을 들여다보면, 실패의 원인은 한 가지가 아니다.
- 관련 문서를 못 찾아오는 검색의 문제가 있다.
- “이 설비 변경에 영향을 받는 품질 기준과 담당 조직은?”처럼 문서를 넘어 관계 경로를 따라야 답할 수 있는 문제가 있다.
- “승인”이 결재 완료인지, 기술 검토 통과인지, 규제기관 허가인지가 시스템마다 달라서 같은 단어의 의미를 합의해야 하는 문제가 있다.
이 세 가지를 모두 “검색 성능”으로 묶어버리면, 문제 정의가 틀어진다. 벡터 검색을 그래프로 교체하고, 그래프를 곧바로 온톨로지로 승격하는 식의 결정이 나오는 순간 설계 비용은 급격히 커지고, 나중에 실패해도 어느 층이 틀렸는지 설명할 수 없게 된다.
한 줄로 구분하면 이렇다. Context는 모델에 넣는 정보의 품질 문제, Knowledge Graph는 관계를 저장하고 탐색하는 구조의 문제, Ontology는 그 관계가 무엇을 뜻하며 무엇이 허용되는지를 정의하는 의미와 규칙의 문제다. 세 층은 서로를 대체하지 못하고, 잘못된 층에서 문제를 풀면 비용만 늘어난다.
시작 전 6문항 자기 진단
구조를 올리기 전에, 지금 겪는 문제가 어느 층의 문제인지부터 확인해야 한다. 다음 질문에 답해보면 출발층이 보인다.
- 답변이 폐기·구버전 문서를 최신 문서와 섞어서 가져오는가? → 예: Context 층부터.
- 답변이 문서를 찾기는 하는데 조건문·예외 조항이 잘려 내용이 반쪽인가? → 예: Context 층(청크 설계)부터.
- 질문에 답하려면 문서 한 편이 아니라 여러 대상의 연결 경로를 따라야 하는가? → 예: Knowledge Graph 층 검토 대상.
- 같은 단어(예: ‘승인’)가 시스템마다 다른 사실에 연결되어 수작업 중재가 반복되는가? → 예: Ontology 층 검토 대상.
- 규칙 위반 여부를 판정하는 질문이 반복되는데, 그 규칙이 프롬프트 조각으로 흩어져 있는가? → 예: Ontology 층 검토 대상.
- 데이터셋 전체의 주제·패턴을 요약하는 질문이 실제로 들어오고 있는가? → 예: 전역 질의(Global Search) 설계 대상. 아니오라면 전역 질의는 아직 필요 없다.
1번과 2번에서 막힌다면 그래프나 온톨로지 논의는 미뤄도 된다. 3번이 반복되면 그래프 도입의 최소 조건(아래 체크리스트)을 확인하고, 4번과 5번이 반복되면 온톨로지 승격 신호로 본다.
첫 번째 층: Context — 대부분의 실패는 여기서 고칠 수 있다
RAG는 질문과 관련된 외부 정보를 찾아 모델의 입력 컨텍스트에 넣음으로써, 모델이 학습하지 않은 사내 자료에 대해서도 답하게 만드는 방식이다. 대부분의 기업 지식검색이 벡터 유사도 검색을 기본으로 삼는데, 이런 방식을 Microsoft GraphRAG 문서에서는 Baseline RAG라고 부른다.[1]
이 층의 실패는 구조를 높이기 전에 고칠 수 있는 경우가 많다. 내가 현장에서 확인한 전형적인 원인은 다음 네 가지다.
- 청크 분리가 문단 경계를 무시한다. 조건문과 예외 조항이 잘려 나가서, 답변이 규정은 찾되 예외를 놓친다.
- 메타데이터가 없다. 문서 버전, 작성 부서, 적용 기간, 보안 등급이 검색 필터로 쓰이지 않으니, 폐기된 문서가 최신 문서와 동등하게 경쟁한다.
- 질의를 그대로 검색한다. “반출 절차”와 “외부 반출 승인 프로세스”처럼 표현이 다르면 못 찾고, 질의 재작성·하이브리드 검색·재순위화 같은 단계가 없다.
- 근거 묶음이 아니라 문장 몇 개만 전달한다. 답변 작성에 필요한 문서 단위(규정 전체의 구조, 조항 간 참조)가 아니라 유사도가 높은 조각만 모델에 들어가면, 답은 그럴듯하되 책임질 수 없는 형태가 된다.
“이번 분기 해외 반출 승인 절차” 질문에 작년 정책이 섞여 나오는 사례로 돌아가면, 여기서의 첫 조치는 온톨로지가 아니라 문서의 효력 기간·법인·보안 등급을 메타데이터로 만들고, 답변이 인용할 문서 단위를 재설계하는 일이다. 이 층의 산출물은 “더 긴 컨텍스트”가 아니라 질문에 맞고 권한을 지키는 근거 묶음이다.
두 번째 층: Knowledge Graph — ‘관계 경로’가 답의 근거일 때
문서 검색은 “관련 문서를 고르는” 데 강하지만, 여러 개체와 그 연결을 따라야 하는 질문에는 약하다. “이 설비의 변경 승인에 영향을 받는 품질 기준과 담당 조직은 무엇인가”, “이 계약의 예외 조항이 연결된 공급사·제품군·통제 항목은 무엇인가” 같은 질문이 그렇다. 답이 문서 한 곳에 없고, 노드 사이의 경로로 존재하기 때문이다.
이 지점에서 지식 그래프는 설비–공정–품질 기준, 계약–공급사–제품군 같은 노드와 관계를 명시해서 경로 탐색을 가능하게 한다. 그리고 이 그래프 구조를 검색·생성 흐름에 결합한 대표적 접근이 GraphRAG다.
GraphRAG 문서의 설명을 빌리면, GraphRAG는 평문 조각에 대한 단순 의미 검색과 달리 원시 텍스트에서 지식 그래프를 추출하고, 밀접하게 연관된 엔터티 그룹(커뮤니티)의 계층을 만든 뒤, 각 커뮤니티의 요약을 생성해서 검색에 활용하는 구조적·계층적 RAG다.[1] 원 논문은 이 접근이 필요한 이유를 더 분명하게 말한다. “데이터셋의 주요 주제는 무엇인가?”처럼 전체 말뭉치를 향하는 전역 질문은 본질적으로 질의 중심 요약(query-focused summarization)의 문제이지, 관련 문서를 찾는 검색의 문제가 아니라는 것이다.[3]
질의 방식도 이 구분에 맞춰 설계되어 있다. Microsoft의 Query 문서는 질의를 Local Search와 Global Search 등으로 구분하는데, Global Search는 데이터셋 전체를 이해해야 하는 질문에 대해 모든 커뮤니티 리포트를 map-reduce 방식으로 검색하며 자원 소모가 큰 방법이라고 명시한다.[2] 원 논문 역시 그래프 인덱스를 두 단계로 구축한다고 설명한다. 먼저 원문에서 엔터티 지식 그래프를 유도하고, 이어서 밀접한 엔터티 그룹의 커뮤니티 요약을 사전 생성한 뒤, 질문이 들어오면 각 커뮤니티 요약으로 부분 답변을 만들고 이를 다시 최종 답변으로 종합하는 방식이다.[3]
다만 그래프를 만든다고 자동으로 정확해지지는 않는다. 여기서도 실패 패턴이 분명하다.
- 엔터티 추출 오류와 중복 식별자. 같은 장비를 다른 표기로 두 번 등록하면, 경로가 갈라지거나 가짜 연결이 생긴다.
- 관계에 출처와 갱신 시점이 없다. 언제, 어떤 문서에서 뽑은 관계인지가 없으면 그래프 전체가 “출처 없는 주장”이 된다.
- 데이터 오너가 없다. 관계가 틀렸을 때 누구에게 고치라고 요청해야 하는지 정의되지 않으면, 그래프는 만들어진 순간부터 썩기 시작한다.
따라서 그래프 도입의 최소 조건은 두 가지다. “관계가 답의 근거인가” 그리고 “관계 데이터의 소유자와 갱신 주기가 있는가”. 둘 중 하나라도 없으면, 메타데이터가 잘 정비된 RAG가 더 낮은 비용으로 운영될 가능성이 크다.
그래프 도입 최소 조건 체크리스트
두 가지 최소 조건을 도입 검토 회의에서 바로 쓸 수 있는 체크 항목으로 풀면 다음 표와 같다. 한 칸이라도 “아니오”라면 그래프 구축이 아니라 그 칸을 채우는 작업이 먼저다.
| 조건 | 확인할 질문 | 아니오일 때 나타나는 실패 패턴 |
|---|---|---|
| 관계가 답의 근거인가 | “경로를 따라야 답이 나오는 질문”이 실제로 반복 접수되고 있는가, 아직 예상일 뿐인가 | 질문이 없는데 그래프부터 만들면 활용 없는 스키마만 남는다 |
| 엔터티 ID 체계가 있는가 | 같은 대상을 가리키는 표준 식별자가 시스템 사이에 합의되어 있는가 | 표기 차이로 중복 노드·가짜 연결이 생기고 경로가 갈라진다 |
| 관계에 출처·갱신 주기가 있는가 | 각 관계가 언제, 어떤 문서·시스템에서 뽑혔는지 기록되고 갱신 주기가 정해져 있는가 | 그래프 전체가 “출처 없는 주장”이 되어 검증·감사가 불가능해진다 |
| 데이터 오너가 있는가 | 관계가 틀렸을 때 수정을 요청할 책임 주체가 지정되어 있는가 | 오류 수정 경로가 없어 그래프가 만들어진 시점부터 낡기 시작한다 |
세 번째 층: Ontology — ‘의미 충돌’과 ‘규칙 검증’이 반복될 때
온톨로지는 그래프의 스키마나 용어집보다 강한 약속이다. W3C의 OWL 2 명세는 이 언어를 “형식적으로 정의된 의미를 갖는 온톨로지 언어”로 규정하며, 클래스·속성·개체·데이터 값을 제공한다고 정의한다.[4] 즉 단순한 분류표가 아니라, 무엇이 무엇이고 어떤 관계가 성립할 수 있는지를 기계가 검증할 수 있는 형태로 쓰는 것이다.
기업 업무에서 이 층이 가치가 생기는 신호는 반복되는 두 가지 현상이다.
첫째, 용어 충돌이다. “승인”이 어떤 시스템에서는 결재 완료, 다른 시스템에서는 기술 검토 통과, 또 다른 곳에서는 규제기관 허가를 뜻한다면, 그래프의 APPROVED_BY 관계 하나로는 부족하다. 승인 유형, 적용 범위, 선행 조건, 유효 기간, 예외 권한을 정의하지 않는 한, 같은 관계명이 시스템마다 다른 사실에 연결된다.
둘째, 규칙 검증의 반복이다. “제품이 특정 물질을 포함하면 특정 규제 통제가 필수” 같은 제약이 있다면, 이 규칙은 프롬프트에 매번 붙이는 설명문으로 둘 것이 아니라 검증 가능한 관리 대상이 된다. 조건이 바뀌었을 때 규칙 정의를 고치면 모든 질의가 함께 바뀌는 구조와, 프롬프트 조각을 찾아다니며 고치는 구조는 운영 비용이 다르다.
여기서 한 가지 구분이 필요하다. 메타데이터 필터와 온톨로지 제약은 비슷해 보여도 역할이 다르다. “효력 기간이 지난 문서는 검색에서 제외한다”처럼 문서 속성으로 거르는 일은 메타데이터 필터, 즉 Context 층의 일이다. 반면 “‘승인’은 결재 완료·기술 검토 통과·규제 허가를 구분해야 하고, 규제 허가가 선행되지 않은 상태에서는 특정 관계가 성립할 수 없다”처럼 용어의 의미와 관계 성립 조건 자체를 정의하는 일이 온톨로지 층의 일이다. 전자는 검색의 범위를 좁히고, 후자는 관계의 의미를 판정한다. 이 구분이 흐려지면 필터링으로 충분한 문제에 온톨로지를 올리게 된다.
반대의 경우도 분명하다. 탐색하는 관계가 자주 바뀌고, 정답 규칙 자체가 아직 합의되지 않은 초기 업무에 온톨로지를 먼저 고정하면 변화 비용이 커진다. 용어 합의가 안 된 상태에서 온톨로지부터 만들면, 매번 스키마 변경 승인이 필요해지고 현장은 우회 경로를 만들기 시작한다. 이 경우에는 느슨한 그래프 스키마와 출처가 분명한 관계부터 시작해서, 충돌 사례가 임계점까지 쌓일 때 온톨로지로 승격하는 편이 안전하다.
잘못된 층에서 문제를 풀면 생기는 일
현장에서 반복해서 본 장면이 둘 있다. 특정 기업의 이야기가 아니라, 어디서나 마주치는 실패 패턴을 그대로 옮긴 것이다.
첫째, 온톨로지를 먼저 올린 경우. 사내 지식검색 정확도가 낮다는 보고를 받으면 “근본부터 잡자”며 온톨로지 프로젝트부터 시작하는 경우가 있다. 수개월에 걸쳐 용어 체계를 만들고 제약 규칙을 정의하는데, 정작 답변 오류의 상당수는 폐기된 문서가 최신 문서와 동등하게 검색되는 메타데이터 문제인 경우가 많다. 메타데이터를 정비하면 온톨로지 없이도 줄어드는 오류인데, 공들여 만든 용어 정의는 실제 답변 경로에 연결되지 못한 채 유지 비용만 남는다.
둘째, 모든 질문에 전역 질의를 태운 경우. “전체 데이터셋의 흐름을 요약해주는” 질문 몇 건에 감탄해서 모든 질문을 같은 그래프 파이프라인으로 흘려보내는 경우도 본다. 그런데 실제 질문의 대부분은 특정 문서의 근거를 찾는 유형이고, 전역 질의는 소수의 요약 질문에만 필요하다. 모든 질문에 커뮤니티 리포트를 광범위하게 탐색하는 구조를 적용하면, 자원 소모가 큰 방식이 일상 질의마다 반복되며 운영 비용이 구조적으로 높아진다.[2]
두 장면 모두 “나쁜 기술을 골라서” 실패한 것이 아니다. 문제가 있는 층이 아닌 곳에서 해법을 시작해서 실패했다. 첫 번째는 Context 층의 문제를 Ontology 층에서 풀려 했고, 두 번째는 전역 질의가 필요한 소수의 질문과 일반 문서 검색으로 충분한 다수의 질문을 라우팅 없이 섞은 것이다.
질문 유형 라우팅: 어떤 질문에 어떤 구조를 태울 것인가
위 두 번째 장면은 라우팅 문제로 귀결된다. 전역 질의(Global Search)는 데이터셋 전체를 이해해야 하는 질문에 대해 모든 커뮤니티 리포트를 map-reduce 방식으로 탐색하므로 자원 소모가 크다.[2] 따라서 “전체 주제 요약”이 필요한 소수의 질문과, 문서 검색으로 충분한 다수의 질문을 같은 파이프라인에 넣지 않는 설계가 필요하다. 실무적으로는 다음 순서로 라우팅 기준을 잡을 수 있다.
- 질문 로그를 먼저 본다. 최근 실제로 접수된 질문을 모아 “단일 문서 근거형 / 관계 경로형 / 전체 요약형”으로 분류한다. 분류 기준은 기술이 아니라 질문이 요구하는 근거의 형태다.
- 기본 경로는 가장 싼 구조로 둔다. 단일 문서 근거형 질문은 메타데이터가 정비된 RAG로 처리한다. 이 경로가 기본값이고, 그래프·전역 질의는 예외 경로다.
- 관계 경로형만 그래프 질의로 올린다. “영향을 받는 대상은?”처럼 경로가 답의 근거인 질문만 그래프 질의로 보낸다. 이때도 앞의 최소 조건 체크리스트가 채워진 범위로 한정한다.
- 전체 요약형만 전역 질의로 올린다. 데이터셋 전체의 주제·패턴을 묻는 질문만 Global Search로 보내고, 이 유형이 실제로 접수되는지 주기적으로 재확인한다. 이 유형이 사라졌다면 전역 질의 파이프라인의 유지 여부도 함께 재검토한다.
- 분류가 안 되는 질문은 샘플로 남긴다. 어느 유형에도 넣기 어려운 질문은 다음 구조 결정의 근거가 되는 샘플로 보관한다. 오류 신호가 쌓여야 다음 층으로 올릴지 판단할 수 있다.
제품·아키텍처 선택의 경계
세 층의 선택을 업무 신호로 정리하면 다음 표와 같다.
| 업무 신호 | 우선 구조 | 운영에서 확인할 것 |
|---|---|---|
| 최신 문서·규정의 근거를 찾아 설명하는 질문 | Context 정비 + RAG | 버전·권한·메타데이터, 인용 가능 여부, 청크 설계 |
| 다단계 영향도·의존성을 따라 답해야 하는 질문 | Knowledge Graph + GraphRAG | 엔터티 ID 체계, 관계 출처·갱신 주기, 데이터 오너, 경로 설명 가능 여부 |
| 용어가 부서마다 충돌하거나 규칙 위반을 판정해야 하는 질문 | Ontology + 규칙 계층 | 표준 용어 오너, 변경 승인 절차, 제약 검증, 감사 가능성 |
| 데이터셋 전체의 주제·패턴을 요약하는 질문 | GraphRAG의 전역 질의(Global Search) | 커뮤니티 요약 생성·갱신 비용, 질의당 자원 소모 |
여기서 중요한 판단 기준은 두 가지다.
첫째, 세 구조는 교체 관계가 아니라 누적 관계다. 온톨로지가 좋은 Context를 대신하지 못하고, 그래프가 원문 문서와 출처를 없애지 않는다. 온톨로지를 올린 뒤에도 답변은 여전히 문서 원문을 인용해야 감사할 수 있다.
둘째, 순서가 비용을 결정한다. 실무적으로는 원문 문서와 메타데이터를 먼저 정비하고, 관계 질의가 실제로 반복되는 구간만 그래프로 모델링한 뒤, 그 관계의 의미 충돌과 규칙 검증 비용이 임계점을 넘을 때 온톨로지를 도입하는 순서가 합리적이다. 반대로 “최신 아키텍처”라는 이유로 온톨로지에서 시작하면, 아직 검증되지 않은 의미를 고정하는 데 비용 대부분을 쓰게 된다.
또 하나 짚어야 할 점은 전역 질의의 비용이다. 데이터셋 전체를 대상으로 하는 Global Search 계열의 답변은 커뮤니티 리포트를 광범위하게 탐색하므로 자원 소모가 크다.[2] “전체 주제 요약”이 필요한 질문은 소수인데, 모든 질문을 같은 파이프라인으로 흘려보내면 운영 비용이 구조적으로 높아진다. 질문 유형을 라우팅해서, 문서 검색으로 충분한 질문에는 그래프·커뮤니티 비용을 태우지 않는 설계가 필요하다.
결론: “무엇을 도입할까”가 아니라 “어떤 오류를 내고 있는가”
기업 AI의 다음 병목은 “더 많은 문서를 넣는 방법”이 아니다. 어떤 업무 질문에 어떤 수준의 구조적 약속이 필요한지를 구분하는 일이다.
- Context 품질은 답변의 근거를 만든다.
- Knowledge Graph는 관계 경로를 만든다.
- Ontology는 그 경로가 업무상 유효한지 판정할 언어를 만든다.
세 층의 경계를 먼저 정하면, 제품과 아키텍처 선택도 “GraphRAG를 도입할까, 온톨로지를 만들까”라는 유행의 질문에서 벗어날 수 있다. 대신 “우리 업무가 지금 어떤 종류의 오류를 내고 있는가”라는 질문에서 시작하게 된다. 근거가 틀리는지, 경로를 못 찾는지, 의미를 합의하지 못했는지. 그 진단이 정해지면 구조는 따라온다.
다음 단계로 확인해볼 질문은 이것이다. 우리 시스템에 최근 실제로 접수된 질문 스무 개를 펼쳐놓고, 이 글의 6문항 진단과 라우팅 기준에 따라 분류해보면 어떤가. 대부분이 한 유형에 몰려 있다면 구조 선택은 생각보다 빨리 끝난다. 반대로 유형이 고르게 섞여 있다면, 그것이 곧 “모든 질문을 하나의 파이프라인에 넣지 말라”는 신호다.
이 글은 공개 자료와 필자의 AX/업무자동화 현장 관점을 바탕으로 재구성·각색한 내용입니다. 특정 기업·제품에 대한 구매 추천이나 특정 종목에 대한 투자 판단이 아닙니다.
[1] https://microsoft.github.io/graphrag — Welcome - GraphRAG (Microsoft) [2] https://microsoft.github.io/graphrag/query/overview — Query Overview - GraphRAG (Microsoft) [3] https://arxiv.org/abs/2404.16130 — Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization (arXiv:2404.16130) [4] https://www.w3.org/TR/owl2-overview — OWL 2 Web Ontology Language Document Overview (W3C Recommendation)