.png)
Agentic AI를 위한 온톨로지 기반 RAG 시스템 구축하기
KB·KG·Zero-Copy를 조합하는 프로덕션 지식 도구 계층
기획연재 3편: 1편은 데이터를 어디에 둘 것인가를 다뤘고, 2편은 지식을 어떤 구조로 검색할 것인가를 다뤘습니다. 이번 편은 그 둘을 Agentic AI가 실제로 호출할 지식 도구 계층으로 조합하는 방법을 다룹니다. 핵심은 온톨로지를 데이터 저장소가 아니라 의미 지도(map)이자 도구 계약(tool contract)으로 두고, 값과 근거는 원본 RDB/API·문서 KB·그래프 KG 중 가장 적절한 곳에서 읽는 것입니다.
📚 연재 안내 | 이 글은 「Agent 시대의 RAG 재설계」 3부작의 3편입니다. ① 벡터 DB에 문서를 복사하지 않는 RAG — Zero-Copy RAG의 설계와 운영 · ② 벡터 유사도를 넘어 관계와 규칙을 검색하다 — GraphRAG·Ontology·KAG의 역할 · ③ Agentic AI를 위한 온톨로지 기반 RAG 시스템 구축하기 — KB·KG·Zero-Copy를 조합하는 프로덕션 지식 도구 계층(현재 글). 이후 Agent Harness 연재로 이어집니다.
1편에서는 문서·웹·PDF처럼 검색과 재사용이 중요한 데이터는 복제 인덱스를 쓰되, 현재 값과 권한 일관성이 중요한 운영 데이터는 소스네이티브 조회로 읽는 구조를 살펴봤습니다. 핵심은 원문·권한·스코프의 최종 책임을 어디에 둘 것인가였습니다.
2편에서는 벡터 유사도만으로는 부족한 관계·규칙·시간·수치 문제를 다뤘습니다. GraphRAG, Ontology, KAG를 하나의 유행어로 묶지 않고, 관계 구조, 업무 의미의 계약, 그래프와 원문 청크를 함께 쓰는 검색·추론 구조로 나눠 봤습니다.
이제 남는 질문은 더 구체적입니다.
문서는 KB에 있고, 운영 수치는 RDB/API에 있고, 관계는 KG에 있다. Agent가 사용자의 목표를 해석하고 여러 도구를 호출해 답변이나 후속 액션 후보를 만들려면, 무엇을 어디에 저장하고 무엇을 원본에서 읽어야 하는가?
이 글은 그 질문에 대한 답을 여섯 가지 구현 패턴으로 정리합니다. 결론을 먼저 말하면, 정답은 하나의 패턴이 아닙니다. 좋은 Agentic RAG는 Agent가 모든 데이터를 프롬프트에 밀어 넣는 시스템이 아니라, 데이터 성격에 맞는 지식 도구를 안전하게 호출하고 근거를 조립하는 시스템입니다.
💡 TL;DR · 3줄 요약
① 온톨로지는 데이터를 전부 빨아들이는 저장소가 아니라 '의미 지도'이자 '도구 계약'입니다.
② 실제 값과 근거는 문서(KB)·그래프(KG)·운영 원본(DB/API) 각자의 제자리에 둡니다.
③ Agent에게 모든 데이터를 프롬프트로 밀어 넣지 말고, 도구를 선택해 권한 게이트를 통과하도록 설계하세요.
온톨로지를 값 저장소가 아니라 '의미 지도이자 도구 계약'으로 두고, Agentic AI가 원본·KB·KG를 지식 도구로 호출합니다.
온톨로지는 지도이고, 값과 근거는 저장소에 남는다
먼저 은유를 정확히 고정하겠습니다. “온톨로지는 지도다”라는 표현은 유용하지만, 느슨하게 쓰면 두 가지 오해를 부릅니다.
첫 번째 오해는 온톨로지가 데이터를 대신 저장한다는 것입니다. 그렇지 않습니다. 온톨로지는 원본 RDB의 행, KB의 문서 청크, KG의 엔티티와 관계를 통째로 보관하는 저장소가 아닙니다.
두 번째 오해는 온톨로지가 권한까지 판정한다는 것입니다. 이것도 아닙니다. 온톨로지는 “무엇이 존재하고 어떻게 연결되는가”를 알려 줄 수 있지만, “이 사용자가 그것을 볼 수 있는가”는 원본 시스템의 권한 모델과 조회 시점의 스코프가 판단해야 합니다.
이 글에서 용어는 다음처럼 씁니다.
핵심 규칙은 1편의 Zero-Copy 원칙과 같습니다.
지도는 값을 복제하지 않는다. 무엇이 어디에 있고 어떤 의미로 연결되는지 ID와 포인터로 가리킬 뿐이다.
Agentic AI 관점에서 보면 온톨로지는 한 가지 역할을 더 갖습니다. Agent에게 “무슨 개념을 물을 수 있는지”, “어떤 도구로 읽어야 하는지”, “어떤 출력 스키마와 근거 포인터를 남겨야 하는지”를 알려 주는 도구 계약입니다. 온톨로지가 없다면 Agent는 KB 검색, KG 탐색, SQL 조회를 서로 다른 도구로만 봅니다. 온톨로지가 있으면 이 도구들이 같은 업무 의미 위에서 연결됩니다.
온톨로지에 실제 값을 통째로 베껴 넣으면, 1편에서 지적한 “또 하나의 오래된 복제본” 문제가 그대로 재발합니다. 반대로 온톨로지가 없으면 2편에서 지적한 “모든 지식을 평평한 청크로만 보는” 문제로 돌아갑니다.
그래서 이 글의 출발점은 단순합니다.
의미를 정의하는 곳과 값을 읽는 곳을 분리한다.
💡 핵심 요약 · 온톨로지는 저장소가 아니라 의미 지도이자 도구 계약이다
① 온톨로지는 개념·관계·제약을 정의하지만 값을 대신 저장하지 않는다.
② 값과 근거는 원본 RDB/API·KB·KG 중 적절한 저장소에 남는다.
③ Agent에게는 어떤 지식 도구를 어떤 입력·출력 계약으로 호출할지 알려 준다.
④ 권한은 지도가 아니라 원본 시스템과 조회 시점 스코프가 판정한다.
문서는 KB, 운영 수치는 RDB/API, 관계는 KG에 있습니다. 하나의 업무 의미 아래에서 각기 가장 적절한 곳을 읽습니다.
왜 조합이 필요한가: 하나의 질문이 여러 저장소를 동시에 요구한다
RAG를 문서 Q&A로만 보면 선택지는 단순해 보입니다. 문서를 청크로 나누고, 임베딩하고, 검색하면 됩니다. 하지만 업무 질문은 대개 한 저장소 안에서 끝나지 않습니다.
예를 들어 AI 인사이트 스튜디오에서 사용자가 이렇게 묻는다고 해보겠습니다.
지난달 캠페인 A의 전환율이 왜 떨어졌는지 설명하고, 다음 실험안을 제안해줘. 당시 적용된 쿠폰 정책, 대상 세그먼트 변화, 실제 발송 성과를 함께 보고 싶어.
이 질문은 단순 Q&A가 아닙니다. Agent는 원인을 설명하고, 정책과 수치를 확인하고, 다음 실험안이라는 후속 액션 후보까지 만들어야 합니다. 그러려면 최소 세 종류의 근거가 필요합니다.
여기서 어느 하나만으로는 부족합니다.
벡터 검색만 쓰면 정책 문서는 찾을 수 있지만 실제 전환율과 발송 성과를 현재 값으로 읽기 어렵습니다. SQL만 쓰면 수치는 정확하지만 “이 정책이 어떤 세그먼트에 적용됐는지” 같은 의미 관계를 설명하기 어렵습니다. 그래프만 쓰면 관계는 잘 보이지만 원문 정책 문장과 실제 운영 수치로 돌아가 검증해야 합니다.
그래서 제품에서는 다음 구조가 필요합니다.
이 구조에서 온톨로지는 모든 데이터를 빨아들이는 중앙 저장소가 아닙니다. 오히려 반대입니다. 각 데이터가 자기 저장소에 남아도, 제품이 그것을 같은 의미 체계 아래에서 읽을 수 있게 만드는 지도입니다.
좋은 RAG 조합은 “모든 것을 한 저장소에 모으는 것”이 아니라, 각 저장소가 잘하는 일을 유지한 채 같은 의미 계약으로 묶는 것이다.
Agentic AI에서 RAG는 컨텍스트가 아니라 지식 도구 계층이다
챗봇형 RAG에서는 검색 결과가 대개 “답변을 쓰기 위한 컨텍스트”입니다. 하지만 Agentic AI에서는 RAG가 더 넓은 역할을 맡습니다. Agent는 한 번 검색하고 답하는 대신, 목표를 해석하고, 필요한 근거를 나누고, 여러 도구를 호출하고, 결과가 부족하면 다시 조회하고, 마지막에는 답변이나 실행 후보를 만듭니다.
그래서 Agentic AI에서 RAG는 단순 검색 파이프라인이 아니라 지식 도구 계층에 가깝습니다.
이 차이가 중요합니다. KB 검색, KG 탐색, Zero-Copy SQL/API가 준비됐다고 해서 Agent가 자동으로 좋은 판단을 하지는 않습니다. Agent에게 필요한 것은 더 많은 도구가 아니라, 어떤 업무 개념에는 어떤 도구를 어떤 계약으로 호출해야 하는가입니다.
온톨로지가 이 계약을 정의합니다. 그리고 그 계약을 실행 루프 안에서 적용하는 것이 다음 연재의 Harness 문제입니다.
핵심 문장: Agentic RAG의 목적은 Agent에게 더 많은 데이터를 주는 것이 아니라, Agent가 필요한 근거를 올바른 도구로 읽고 검증 가능한 형태로 남기게 하는 것이다.
패턴을 나누는 설계 질문
여섯 가지 패턴은 임의의 목록이 아닙니다. 제품을 설계할 때 아래 질문에 답하다 보면 자연스럽게 나오는 기본 조합입니다.
질문 1 — 온톨로지를 언제 적용할 것인가
온톨로지는 두 시점에 개입할 수 있습니다.
질의 해석 단계에 적용하면 데이터는 기존 저장소에 남고, 온톨로지는 질문을 안전한 조회 계약으로 바꾸는 데 쓰입니다. 저장·적재 단계에 적용하면 온톨로지는 그래프를 만들 때의 스키마 가드레일이 됩니다.
질문 2 — 값과 근거를 어디에서 읽을 것인가
값과 근거가 사는 위치도 다릅니다.
질문 3 — 관계를 그때그때 조립할 것인가, 그래프로 유지할 것인가
관계 조립형 KB 검색과 근거 연결형 GraphRAG의 차이가 여기서 갈립니다.
- 관계를 자주 묻지 않는다면, KB 검색 결과를 질의 시점에 온톨로지로 엮는 것으로 충분할 수 있습니다.
- 같은 관계가 반복적으로 쓰이고, 경로 탐색이나 이웃 확장이 중요하다면, 관계 골격을 KG에 유지하는 편이 낫습니다.
아래 표는 이해를 돕기 위한 패턴 지도입니다. 제품이 모든 칸을 별도 기능으로 가져야 한다는 뜻은 아닙니다.
2편의 “질문 유형별 검색 경로”와 이 표는 비슷해 보일 수 있습니다. 하지만 보는 관점이 다릅니다. 2편은 어떤 질문에 벡터·그래프·SQL 중 무엇이 필요한가를 다뤘고, 이 글은 값과 근거를 어디에서 읽고, 온톨로지를 어느 시점에 적용할 것인가를 다룹니다. 같은 문제를 질문 유형이 아니라 제품 구현 방식에서 다시 보는 셈입니다.
💡 핵심 요약 · 패턴은 기술명이 아니라 설계 질문에서 나온다
① 온톨로지는 질의 해석 단계 또는 저장·적재 단계에 적용할 수 있다.
② 값과 근거는 원본 RDB/API·KB·KG 중 가장 적절한 곳에서 읽는다.
③ 반복 관계가 많으면 KG로 유지하고, 그렇지 않으면 질의 시점 조립으로 충분할 수 있다.
스코프 제한형 시맨틱 조회부터 Agentic Hybrid 지식 도구 체인까지 — 데이터 성격에 따라 온톨로지에 원본·KB·KG를 조합합니다.
여섯 가지 조합 패턴
각 패턴을 정의 → 데이터 흐름 → 적합한 경우 → 트레이드오프 순으로 보겠습니다. 목표는 여섯 가지를 전부 적용하는 것이 아닙니다. 데이터 성격에 맞는 가장 단순한 계약을 고르는 것입니다.
패턴 1. 스코프 제한형 시맨틱 조회
스코프 제한형 시맨틱 조회는 온톨로지가 원본 RDB/API의 업무 어휘를 정의하고, 사용자 권한 스코프 안에서만 현재 값을 읽는 방식입니다. “매출”, “전환율”, “캠페인”, “세그먼트”, “쿠폰 사용률” 같은 개념이 어떤 테이블·뷰·API와 연결되는지 지도에 기록합니다.
LLM은 이 지도를 참고해 자연어 질문을 구조화된 질의로 바꿉니다. 하지만 최종 실행은 자유 SQL이 아니라 백엔드가 허용한 querySpec과 Scoped Executor를 거쳐야 합니다.
적합한 경우
매출, 퍼널, 재고, 캠페인 상태처럼 계속 변하는 운영 정형 데이터에 적합합니다. 1편의 Zero-Copy SQL을 “업무 의미 질의”로 확장하되, 실행 범위는 항상 시스템이 해석한 스코프 안에 가둡니다.
트레이드오프
원본 지연과 가용성을 그대로 상속합니다. 또한 온톨로지가 질의 가능 범위를 정교하게 정의할수록 실행기는 권한·테넌트·조직 범위를 더 엄격하게 강제해야 합니다. 온톨로지는 질의를 구조화하는 계약일 뿐, 권한 시스템을 대체하지 않습니다.
스코프 제한형 시맨틱 조회의 핵심: 업무 데이터는 복제하지 않고, 온톨로지는 자연어를 안전한 조회 계약으로 바꾸며, 실행 범위는 백엔드가 해석한 스코프 안에서만 허용한다.
패턴 2. 관계 조립형 KB 검색
관계 조립형 KB 검색은 문서 중심 RAG에 온톨로지 지도를 얹는 방식입니다. KB 검색으로 문서 후보를 찾되, 결과를 단순 리스트로 보여 주지 않고 온톨로지가 정의한 관계로 엮습니다.
예를 들어 정책 문서, 실험 리포트, 장애 보고서가 있을 때 다음 관계를 정의할 수 있습니다.
이 방식은 영속 KG를 반드시 만들지 않습니다. 검색 결과를 질의 시점에 온톨로지 관계로 조립해, 문서 간 의미 관계를 보여 줍니다.
적합한 경우
문서 중심이지만 문서·청크 사이의 관계 탐색이 필요한 경우에 적합합니다. 예를 들어 “이 정책을 뒷받침하는 리포트와 반박하는 리포트를 함께 보여줘” 같은 질문입니다.
트레이드오프
관계를 사람이 정의하거나 관리해야 하므로 유지 비용이 듭니다. 대신 LLM이 자유 텍스트에서 자동으로 뽑은 관계보다 잡음이 적고, 제품이 지원하는 관계 유형을 명확히 통제할 수 있습니다.
관계 조립형 KB 검색의 핵심: 문서 본문은 KB에 남기고, 온톨로지는 검색 결과를 업무 관계로 묶는 데 쓴다.
패턴 3. 검증된 지식 그래프
검증된 지식 그래프는 온톨로지를 저장·적재 단계의 가드레일로 쓰는 방식입니다. 온톨로지가 허용한 클래스와 관계만 그래프에 적재하고, 검증을 통과한 인스턴스와 관계를 KG에 저장합니다.
여기서 중요한 점은 저장 기준의 분리입니다. 온톨로지 정의와 검증 규칙은 운영 메타데이터로 관리하고, 검증을 통과한 인스턴스와 관계만 KG에 적재합니다. 잘못된 매핑 결과가 그대로 그래프가 되지 않도록 게이트를 두는 것이 핵심입니다.
적합한 경우
관계 자체가 1급 자산이고 반복 질의되는 안정적인 도메인에 적합합니다. 예를 들어 제품-부품-공급사 관계, 캠페인-세그먼트-채널 관계, 조직-역할-승인 관계처럼 반복적으로 탐색되는 구조입니다.
트레이드오프
원문이나 원본 데이터가 바뀌면 그래프와 요약을 갱신해야 합니다. GraphRAG가 관계 탐색을 편하게 만들 수는 있지만, 자동으로 안전한 추론 계층이 되는 것은 아닙니다. 추출, 검증, 재색인, 근거 추적 비용을 함께 설계해야 합니다.
검증된 지식 그래프의 핵심: 온톨로지는 그래프를 예쁘게 그리는 도구가 아니라, 어떤 관계가 KG에 들어갈 수 있는지 제한하는 저장 가드레일이다.
패턴 4. 근거 연결형 GraphRAG
근거 연결형 GraphRAG는 대용량 문서 RAG에서 가장 실용적인 GraphRAG형 패턴입니다. 관계 골격은 KG에 저장하고, 본문 근거는 KB에 둡니다.
관계 조립형 KB 검색이 질의 시점에 KB 결과를 온톨로지 관계로 엮는 방식이라면, 근거 연결형 GraphRAG는 반복적으로 필요한 관계 골격을 영속 그래프로 만들어 둡니다. 다만 본문을 KG에 복제하지는 않습니다. KG에는 엔티티, 관계, 근거 포인터만 두고, 실제 문장과 문단은 KB에서 다시 읽습니다.
적합한 경우
대용량 문서에서 관계 탐색과 원문 근거를 둘 다 요구하는 Q&A에 적합합니다. KG는 탐색 인덱스, KB는 본문 원천으로 역할이 나뉩니다.
트레이드오프
추출 품질이 관건입니다. 이미 구조화된 필드와 메타데이터를 가진 KB는 선언적 매핑으로 안정적으로 처리할 수 있지만, 자유 텍스트에서 엔티티와 관계를 추출하는 경우에는 별도의 품질 관리가 필요합니다. 또한 포인터와 버전이 끊기면 그래프는 근거 없는 파생 구조가 됩니다.
근거 연결형 GraphRAG의 핵심: 관계는 KG로 빠르게 탐색하되, 답변 근거는 KB 원문으로 되돌아가 확인한다.
패턴 5. 값 미복제 ID 그래프
값 미복제 ID 그래프는 운영값을 복제하지 않는 그래프 패턴입니다. 저장·적재 단계에서는 KG에 식별자와 관계 골격만 저장하고, 질의 단계에서는 그 ID로 원본 RDB/API를 즉석 조회해 현재 값을 채웁니다.
적합한 경우
현재 값이 정확성 그 자체이고 원본이 최종 진실인 운영 데이터의 관계 질의에 적합합니다. 예를 들어 현재 세그먼트 규모, 현재 재고, 현재 캠페인 상태처럼 시간이 지나면 의미가 바뀌는 값입니다.
트레이드오프
값은 복제하지 않지만 그래프 인덱스의 갱신 책임은 남습니다. 관계 골격은 KG에, 값은 원본에 있으므로 조회마다 원본 조인이 필요합니다. 원본 지연과 가용성 설계는 스코프 제한형 시맨틱 조회와 동일하게 중요합니다.
값 미복제 ID 그래프의 핵심: 연결은 그래프로 빠르게 찾고, 값은 원본에서 현재 상태로 읽는다.
패턴 6. Agentic Hybrid 지식 도구 체인
Agentic Hybrid 지식 도구 체인은 Agentic AI에서 가장 자주 만나는 실무형입니다. 데이터 성격별로 앞선 다섯 가지 패턴을 섞고, Agent는 목표를 해결하기 위해 여러 지식 도구를 순차적으로 호출합니다. 하나의 질의 안에서 KB 인용, KG 관계 근거, Zero-Copy 지표가 함께 쓰이고, 공통 권한·근거 관리 계층 아래에서 조립됩니다.
AI 인사이트 스튜디오에서 “캠페인 성과를 설명하고 다음 실험안을 제안해줘”라는 요청은 보통 Agentic Hybrid 지식 도구 체인에 가깝습니다. 정책 문서는 KB에서 찾고, 캠페인과 세그먼트의 관계는 KG로 따라가고, 성과 지표는 원본 RDB/API에서 읽습니다. Agent는 이 근거를 바탕으로 원인 설명과 실험안 후보를 만들 수 있지만, 예산·권한·승인·실행은 별도 정책 게이트를 통과해야 합니다. 사용자는 소스 피커를 통해 어떤 근거를 쓸지 명시적으로 선택할 수 있고, 시스템은 각 경로에 같은 resolvedScope를 강제합니다.
적합한 경우
“지난달 캠페인 성과와 당시 정책, 그 정책이 적용된 대상 세그먼트를 함께 설명해줘”처럼 문서·관계·운영값이 한 질문에 섞이는 경우입니다.
트레이드오프
라우팅과 정책 복잡도가 올라갑니다. 그래서 자동 추정보다 소스별 조회 계약이 중요합니다. 어떤 데이터는 KB에서 읽고, 어떤 데이터는 KG에서 탐색하고, 어떤 데이터는 Zero-Copy로 읽는지 사용자와 시스템이 모두 알 수 있어야 합니다.
Agentic Hybrid 지식 도구 체인의 핵심: 이 패턴은 “Agent가 알아서 아무 도구나 쓰게 하기”가 아니라, 소스별 조회 계약을 공통 권한·근거 계층 아래에서 조합하고 실행 권한은 별도 게이트로 분리하는 것이다.
어떤 패턴을 고를 것인가
패턴은 기술 이름이 아니라 데이터 성격으로 고릅니다. 아래 표는 1편의 “데이터 성격별 복제 정책”에 관계 탐색 여부와 원문 근거 필요성을 더한 선택표입니다.
여기서 “현재 값 의존도”가 높다는 것은 값이 조금만 늦어도 답이 틀릴 수 있다는 뜻입니다. 이런 데이터는 원본에서 읽는 편이 안전합니다. 반대로 관계 탐색 빈도가 높고 구조가 안정적이라면 KG를 유지할 가치가 커집니다. 원문 근거 필요성이 높다면 그래프만 보여 주지 말고 KB나 원본 문서로 되돌아가야 합니다.
한 줄 원칙: 현재 값 의존도가 높을수록 원본에서 읽는다(스코프 제한형 시맨틱 조회·값 미복제 ID 그래프). 관계가 중요할수록 그래프를 만든다(검증된 지식 그래프·근거 연결형 GraphRAG). 둘 다 중요하면 Agentic Hybrid 지식 도구 체인으로 섞되, 무엇을 어디서 읽는지는 사용자와 시스템이 모두 알 수 있어야 한다.
온톨로지는 권한을 대체하지 않고, 파생 그래프와 원문 근거를 분리하며, 버전 불일치를 조용히 넘기지 않고, 도구 결과를 실행 권한과 분리합니다.
어떤 패턴이든 지켜야 하는 네 가지 원칙
패턴은 조합의 자유를 주지만, 아래 네 가지 원칙은 조합과 무관하게 공통입니다. 이것이 1편·2편 원칙의 제품 구현이자, Agentic AI로 확장할 때의 안전 기준입니다.
원칙 1 — 온톨로지는 권한 시스템을 대체하지 않는다
온톨로지가 “무엇이 존재하는가”를 알려주는 것과, 이 사용자가 “그것을 볼 권한이 있는가”는 다른 문제입니다. 어떤 패턴을 쓰든 조회 시점의 권한으로 범위를 강제해야 합니다.
1편의 triple-lock은 KB, KG, Zero-Copy 세 경로 모두에 동일하게 적용됩니다.
1. 세션으로 사용자의 스코프를 해석한다.
2. 요청 범위와 해석된 범위의 교집합만 실행한다.
3. 실행기가 스코프 조건을 강제한다.
LLM은 조회 범위를 요청할 수 있다. 하지만 범위를 부여할 수는 없다.
원칙 2 — 파생 그래프와 원문 근거를 분리한다
온톨로지로 조립한 그래프와 관계는 파생 근거입니다. 편리하지만 그 자체가 사실 보장은 아닙니다. 고위험 결정은 원본 청크, 원본 DB 값, 정책 엔진 판정 같은 원문 근거로 다시 확인해야 합니다.
그래서 모든 엔티티와 관계에는 원본으로 되돌아가는 근거 포인터가 붙어야 합니다.
entity / relation
├─ ontologyClass
├─ sourceType: KB | KG | SQL | API
├─ sourceId
├─ sourceVersion
├─ evidencePointer
└─ resolvedScopeFingerprint
원칙 3 — 포인터와 원본의 버전 불일치를 조용히 넘기지 않는다
그래프의 ID, 메타데이터, 근거 포인터가 원본과 어긋나면 그 후보를 오래된 후보로 판정해 제외해야 합니다. 1편의 “포인터는 계약이다 — 읽을 때 원본 버전을 대조한다”는 원칙이 그대로 적용됩니다.
오래된 지도보다 더 위험한 것은, 오래된 지도가 최신 원본인 척하는 것입니다.
원칙 4 — 지식 도구의 결과는 실행 권한이 아니다
Agent가 좋은 근거를 찾았다고 해서 곧바로 실행해도 된다는 뜻은 아닙니다. RAG 도구는 근거를 읽는 도구이고, 실행 도구는 시스템 상태를 바꾸는 도구입니다. 두 도구의 권한 모델은 분리해야 합니다.
예를 들어 Agent가 “이 세그먼트에 15% 쿠폰을 주면 좋겠다”는 실험안을 만들 수는 있습니다. 하지만 실제 쿠폰 발급, 메시지 발송, CRM 상태 변경은 2편에서 말한 정책·예산·승인·멱등 실행 게이트를 통과해야 합니다.
지식 도구는 판단 근거를 만든다. 실행 도구는 부수효과를 만든다. 둘을 같은 권한으로 다루면 Agentic AI는 곧바로 운영 리스크가 된다.
💡 핵심 요약 · 조합은 달라도 통제 원칙은 하나다
① 어떤 패턴이든 조회 시점 권한으로 범위를 강제한다.
② 온톨로지로 만든 그래프는 파생 근거이고, 고위험 결정은 원문 근거로 재검증한다. ③ 포인터와 원본 버전이 어긋나면 후보에서 제외한다.
④ 지식 도구의 결과는 실행 권한이 아니며, 후속 액션은 별도 정책·승인 게이트를 거쳐야 한다.
운영 체크리스트: 패턴보다 계약을 먼저 정한다
여섯 가지 패턴을 도입할 때 가장 위험한 접근은 “우리도 KG를 만들자”, “우리도 온톨로지를 붙이자”처럼 기술 이름에서 출발하는 것입니다. 먼저 정해야 하는 것은 계약입니다.
온톨로지 계약
- 어떤 개념과 관계를 제품에서 공식 지원하는가?
- 관계 이름은 자유 텍스트인가, 허용 목록인가?
- 도메인 용어가 바뀌면 온톨로지 버전은 어떻게 관리하는가?
- canonical entity ID는 어디서 발급하고 어디까지 공유하는가?
- 같은 이름의 다른 엔티티를 어떻게 구분하는가?
조회 계약
- 자연어 질문은 어떤 querySpec으로 변환되는가?
- LLM이 자유 SQL이나 임의 Cypher를 만들 수 없도록 막고 있는가?
- KB, KG, Zero-Copy 각각의 입력·출력 스키마가 있는가?
- 소스 피커나 라우팅 결과가 사용자에게 보이는가?
- 스코프가 비면 빈 결과 또는 fail-closed로 끝나는가?
Agent 도구 계약
- Agent가 호출할 수 있는 지식 도구 목록이 온톨로지 개념과 연결되어 있는가?
- 각 도구의 입력 스키마, 출력 스키마, 최대 결과 수, 타임아웃, 재시도 정책이 정의되어 있는가?
- 도구 결과가 “문자열 컨텍스트”가 아니라 출처·버전·스코프를 가진 evidence bundle로 반환되는가?
- Agent가 자유 SQL, 자유 Cypher, 임의 API 경로를 만들 수 없도록 querySpec·허용 목록으로 제한하는가?
- 지식 도구와 실행 도구의 권한이 분리되어 있는가?
근거 계약
- 모든 답변이 원문 문서, 원본 레코드, KG 관계로 되돌아갈 수 있는가?
- 파생 그래프와 원문 근거가 구분되어 표시되는가?
- sourceVersion, ingestionVersion, ETag, 해시 같은 버전 단서가 남는가?
- 원본이 삭제되거나 권한이 바뀌면 파생 후보를 제외하는가?
운영 계약
- KG 재색인 주기는 어떤 데이터 성격에 맞춰 정하는가?
- Zero-Copy 경로의 원본 장애 시 fail-open인지 fail-closed인지 정해져 있는가?
- 캐시 키에 사용자, 테넌트, resolvedScope, sourceVersion이 포함되는가?
- 감사 로그에 사용한 소스, 버전, 스코프, 도구 호출이 남는가?
- RAG 품질 평가가 “답변 점수”가 아니라 실패 경로 분리로 이어지는가?
이 체크리스트의 핵심은 하나입니다.
패턴을 고르기 전에, 값·근거·권한·버전의 책임 주체를 먼저 정해야 한다.
실무 도입 노트: 작게 시작하고 조합을 넓힌다
여섯 가지 패턴을 한꺼번에 적용할 필요는 없습니다. 실무에서는 대개 다음 순서가 안전합니다.
1단계 — 벡터 RAG의 기본기를 먼저 고친다
문서 청킹, 하이브리드 검색, 원문 인용, 권한·버전 처리가 약하면 그 위에 그래프를 얹어도 근거가 약합니다. KG는 잘못된 청크와 잘못된 메타데이터를 마법처럼 고쳐 주지 않습니다.
2단계 — 운영 정형 데이터는 Zero-Copy로 읽는다
현재 값이 곧 정확성인 영역은 원본에서 읽는 스코프 제한형 시맨틱 조회부터 적용합니다. 매출, 재고, 캠페인 성과, 퍼널 지표처럼 시간이 지나면 의미가 바뀌는 값은 복제 인덱스보다 원본 조회가 더 안전한 경우가 많습니다.
3단계 — 반복되는 관계만 KG로 유지한다
모든 문서에서 모든 관계를 뽑으려고 하면 인덱싱 비용과 검증 비용이 빠르게 커집니다. 먼저 반복적으로 묻는 관계부터 KG로 유지합니다. 관계가 안정적이고 재사용 가치가 커질 때 검증된 지식 그래프나 근거 연결형 GraphRAG로 확장합니다.
4단계 — 문서 근거가 필요한 관계는 근거 연결형 GraphRAG로 분리한다
관계 탐색과 원문 근거가 함께 필요하면 근거 연결형 GraphRAG가 적합합니다. KG는 탐색을 빠르게 하고, KB는 본문 근거를 제공합니다. 이때 KG가 원문을 대체하지 않도록 포인터와 버전 계약을 반드시 유지해야 합니다.
5단계 — 여러 성격이 섞일 때만 Agentic Hybrid 지식 도구 체인으로 간다
하이브리드는 강력하지만 복잡합니다. 처음부터 Agentic Hybrid 지식 도구 체인을 자동 라우팅 만능 구조로 만들면, 어떤 근거가 어디서 왔는지 설명하기 어려워집니다. 여러 성격이 한 질문에 섞일 때 Agentic Hybrid 지식 도구 체인을 쓰되, 어떤 소스를 어떤 방식으로 읽는지 명시적 계약으로 고정해야 합니다.
좋은 아키텍처는 여섯 가지 패턴을 전부 적용한 시스템이 아니라, 데이터마다 가장 단순한 조합을 고르고 고위험 결론을 원문으로 재검증하는 시스템이다.
여기서부터 문제는 Harness다
여섯 가지 패턴은 결국 여러 지식 도구를 만들어냅니다.
- KB 검색
- KG 그래프 질의
- Zero-Copy SQL/API
- 온톨로지 기반 querySpec 생성
- 근거 포인터 검증
- 컨텍스트 조립
- 정책·승인 게이트로 넘길 후속 액션 후보 생성
이 지점부터는 단순 RAG 문제가 아니라 Agentic AI 문제가 됩니다. 지식 도구가 많아질수록 “검색을 잘하자”보다 더 어려운 질문이 생깁니다.
- 이 목표에는 어떤 온톨로지와 어떤 데이터 소스가 필요한가?
- Agent가 먼저 KB를 읽어야 하는가, 현재값을 먼저 조회해야 하는가?
- 근거가 부족하면 다른 패턴으로 몇 번 다시 읽을 것인가?
- 파생 그래프로 충분한가, 원문 재검증까지 갈 것인가?
- 도구 결과를 그대로 컨텍스트에 넣을 것인가, 파일이나 중간 산출물로 관리할 것인가?
- 어떤 근거가 모이면 후속 액션 후보를 만들 수 있고, 어떤 경우에는 멈춰야 하는가?
- 언제 사람 승인으로 넘기고, 언제 자동화 런타임으로 넘길 것인가?
이 질문들은 온톨로지나 KG만으로 해결되지 않습니다. 온톨로지는 무엇이 무엇과 연결되는지를 알려 주고, 이 글의 여섯 가지 패턴은 어떤 지식 도구를 만들 수 있는지를 정합니다. 하지만 Agent가 그 도구를 어떤 순서로 호출하고, 결과를 어떻게 기억하고, 몇 번 반복한 뒤 멈출지는 별도의 실행 환경이 정해야 합니다.
그 실행 환경이 다음 연재에서 다룰 Agent Harness입니다.
정교한 RAG와 지식 도구를 완성해도, 그것을 언제·어떤 순서로 호출하고 언제 멈출지 정하는 실행 환경이 없으면 Agent는 완성되지 않습니다. 그것이 다음 연재의 주제, Agent Harness입니다.
온톨로지가 Agent에게 지도를 준다면, Harness는 그 지도를 보고 언제 어디까지 이동할지 정하는 운전 규칙이다.
이 글은 RAG 설계와 Agent Harness 사이의 제품 구현 계층을 채운 셈입니다. 다음 연재에서는 같은 LLM과 같은 도구를 써도 왜 Agent 성능이 달라지는지, 그리고 Harness가 검색·도구·컨텍스트·반복·예산·중단을 어떻게 지배하는지 살펴보겠습니다.
마치며: 복사하지 않고 연결한다
RAG 3부작을 한 문장으로 정리하면 이렇습니다.
- 1편(데이터 위치): 데이터 성격에 따라 복제와 소스네이티브 조회를 나누고, 원본·권한·스코프의 책임 위치를 고정하라.
- 2편(지식 구조): 벡터 유사도를 넘어 관계·개념·규칙을 각자의 구조로 검색하라.
- 3편(Agentic 지식 계층): 온톨로지를 지도로 두고, KB·KG·Zero-Copy를 Agent가 호출할 수 있는 지식 도구 계약으로 묶어라.
세 편이 공유하는 것은 하나입니다. 성패는 더 큰 벡터 DB나 더 똑똑한 모델이 아니라, 데이터·권한·도구 계약의 책임을 어디에 두는가라는 아키텍처 선택에서 갈립니다.
온톨로지는 Agent에게 업무 지도를 제공한다. 지도는 값을 복제하지 않고, 무엇이 어디에 있으며 어떤 도구로 읽어야 하는지 알려준다. 권한은 원본 시스템이 판정하고, 실행은 별도 게이트가 통제한다. 좋은 Agentic RAG는 의미 지도와 실제 데이터 저장소를 분리하고, 목표에 맞는 가장 단순한 지식 도구 조합을 고른다.
🚀 다음 연재 예고
다음 글부터는 “같은 LLM과 같은 도구를 써도 왜 Agent 성능이 달라지는가”를 출발점으로 Agent Harness를 다룹니다. 이 글에서 정의한 KB·KG·Zero-Copy 지식 도구를 언제 어떤 순서로 호출하고, 컨텍스트를 어떻게 전달하며, 반복·예산·중단·승인·복구를 어떻게 통제하는지 살펴보겠습니다.
참고자료
[1] 기획연재 1편, 벡터 DB에 문서를 복사하지 않는 RAG — Zero-Copy RAG의 설계와 운영
[2] 기획연재 2편, 벡터 유사도를 넘어 관계와 규칙을 검색하다 — GraphRAG·Ontology·KAG의 역할
[3] W3C, OWL 2 Web Ontology Language Document Overview, W3C Recommendation
https://www.w3.org/TR/owl2-overview/
4] W3C, Shapes Constraint Language (SHACL), W3C Recommendation
[5] Darren Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization, Microsoft Research, 2024
https://arxiv.org/abs/2404.16130
[6] Lei Liang et al., KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation, 2024
https://arxiv.org/abs/2409.13731
[3편 SEO 메타데이터]
- Meta Title: Agentic AI를 위한 온톨로지 기반 RAG 시스템 구축하기
- Meta Description: 온톨로지를 의미 지도이자 도구 계약으로 두고, KB·KG·Zero-Copy를 조합해 Agentic AI가 호출할 수 있는 프로덕션 지식 도구 계층을 설계하는 방법을 설명합니다. 지식 도구와 실행 도구의 분리, 권한·근거·버전 원칙, Agent Harness로의 연결까지 다룹니다.
- Keywords: Agentic AI, Agentic RAG, 온톨로지, Ontology, Knowledge Graph, KG, KB, Zero-Copy RAG, RAG 아키텍처, GraphRAG, Hybrid RAG, Tool Calling, 도구 계약, Context Engineering, Multi-Tenant RAG, Agent Harness
- URL Slug: agentic-rag-ontology-kb-kg-zerocopy
시리즈 대표 문장
온톨로지는 Agent에게 업무 지도를 제공한다. 지도는 값을 복제하지 않고 위치와 의미, 그리고 어떤 지식 도구로 읽어야 하는지를 알려준다. 권한은 원본 시스템이 판정하고, 실행은 별도 게이트가 통제한다 — 좋은 Agentic RAG는 지식 도구와 실행 도구를 분리하고 목표에 맞는 가장 단순한 조합을 고른다.
