---
title: "온톨로지, 지식그래프, RAG, GraphRAG 차이 정리"
slug: "ai-agent-ontology-kg-02-rag-graphrag"
canonicalUrl: "https://moonshotnotes.com/posts/ai-agent-ontology-kg-02-rag-graphrag/"
sourceUrl: "https://moonshotnotes.com/posts/ai-agent-ontology-kg-02-rag-graphrag/"
markdownUrl: "https://moonshotnotes.com/agent/posts/ai-agent-ontology-kg-02-rag-graphrag.md"
language: "ko"
category: "AI Agent"
updatedAt: "2026-05-01"
agentTokenEstimate: 3972
---

# 온톨로지, 지식그래프, RAG, GraphRAG 차이 정리

온톨로지, 지식그래프, RAG, GraphRAG, SHACL, SPARQL의 역할을 AI Agent 자동화 관점에서 정리합니다. 조직 지식 검색과 검증 아키텍처를 실무적으로 설명합니다.

## Agent metadata

- Source: https://moonshotnotes.com/posts/ai-agent-ontology-kg-02-rag-graphrag/
- Markdown: https://moonshotnotes.com/agent/posts/ai-agent-ontology-kg-02-rag-graphrag.md
- Language: ko
- Category: AI Agent
- Tags: AI Agent, 온톨로지, 지식그래프, RAG, GraphRAG
- Updated: 2026-05-01
- Estimated tokens: 3972

1편에서는 AI Agent에 온톨로지와 지식그래프가 언제 필요한지 정리했습니다.

핵심은 단순했습니다.

> **AI Agent라서 온톨로지/KG가 필요한 것이 아니라, 조직 단위 자동화에서 의미 불일치·권한·규칙·데이터 연결 문제가 커지기 때문에 필요해진다.**

이번 2편에서는 조금 더 기술적으로 들어가겠습니다.

온톨로지, 지식그래프, RAG, GraphRAG, SHACL, SPARQL은 자주 같이 등장하지만 역할은 다릅니다. 이 역할을 구분하지 못하면 두 가지 문제가 생깁니다.

첫째, RAG로 해결할 수 있는 문제에 지식그래프를 과하게 도입합니다.

둘째, 반대로 권한·규칙·관계 검증이 필요한 문제를 단순 RAG로만 해결하려고 합니다.

그래서 이번 글의 목표는 명확합니다.

**각 기술이 무엇을 해결하고, AI Agent 아키텍처 안에서 어디에 놓이는지**를 실무 관점으로 정리하겠습니다.

분석 기준일: **2026-05-01**
주요 참고자료: W3C OWL/SHACL/SPARQL, Microsoft GraphRAG, OpenAI/Anthropic 에이전트 설계 자료
분석 범위: 이론적 의미론 전체가 아니라, **조직 AI 자동화에 필요한 실무 아키텍처 관점**

---

## 핵심 요약

- **온톨로지**는 업무 세계의 개념 설계도입니다. 클래스, 관계, 제약, 의미를 정의합니다.
- **지식그래프**는 실제 업무 객체의 연결망입니다. 고객, 계약, 문서, 티켓, 담당자, 정책을 연결합니다.
- **RAG**는 관련 문서 조각을 찾아 LLM에 제공하는 방식입니다. 문서 기반 질의응답에 강합니다.
- **GraphRAG**는 그래프 구조를 활용해 검색과 요약 맥락을 구성하는 방식입니다. 관계와 전체 구조를 다루는 질문에 강합니다.
- **SHACL**은 그래프가 특정 조건을 만족하는지 검증하는 규칙 계층이고, **SPARQL**은 RDF 그래프를 질의하는 언어입니다.

---

## 1. 1편 요약: 왜 의미 계층이 필요한가

AI Agent가 개인이나 팀 업무를 도울 때는 대부분 다음 조합으로 충분합니다.

```text
# 예시 구조
프롬프트
+ 예시
+ RAG
+ 도구 호출
+ 체크리스트
```

예를 들어 회의록 요약, 코드 리뷰 초안, 문서 검색, 티켓 생성 같은 업무는 이 구조로도 꽤 잘 동작합니다.

하지만 조직 단위로 확장되면 문제가 달라집니다.

```text
# 예시 구조
같은 고객을 여러 시스템이 다르게 저장한다.
같은 '완료'라는 단어를 팀마다 다르게 해석한다.
같은 액션이라도 사용자 역할에 따라 실행 가능 여부가 다르다.
같은 리포트라도 근거 문서와 승인 상태를 확인해야 한다.
```

이때 필요한 것은 단순히 더 긴 컨텍스트가 아닙니다. 조직의 개념과 관계, 규칙을 구조화한 의미 계층이 필요합니다.

2편에서 다룰 기술들은 바로 이 의미 계층을 구성하는 요소들입니다.

| 기술 | 한 줄 정의 | AI 자동화에서의 역할 |
|---|---|---|
| 온톨로지 | 업무 세계의 개념 설계도 | 용어, 관계, 제약 정의 |
| 지식그래프 | 실제 업무 데이터의 연결망 | 고객, 계약, 문서, 티켓, 담당자 연결 |
| RAG | 문서 검색 후 생성 | 관련 문서 조각을 LLM에 제공 |
| GraphRAG | 그래프 구조를 활용한 검색/생성 | 관계와 커뮤니티 기반 맥락 제공 |
| SHACL | 그래프 검증 규칙 | 데이터와 액션이 조건을 만족하는지 검증 |
| SPARQL | RDF 그래프 질의 언어 | 필요한 서브그래프 조회 |

이 표를 기억하면 이후 개념이 훨씬 명확해집니다.

---

## 2. 온톨로지란 무엇인가

온톨로지는 조직의 업무 세계를 설명하는 개념 모델입니다.

더 실무적으로 말하면 다음 질문에 답하는 구조입니다.

```text
# 예시 구조
우리 조직에는 어떤 업무 객체가 있는가?
그 객체들은 어떤 속성을 갖는가?
그 객체들은 서로 어떤 관계인가?
어떤 관계는 반드시 있어야 하는가?
어떤 관계는 동시에 존재하면 안 되는가?
어떤 액션은 어떤 조건에서만 가능한가?
```

예를 들어 고객 온보딩 업무의 온톨로지는 이런 식으로 시작할 수 있습니다.

```text
# 예시 구조
Class:
- Customer
- Contract
- SecurityReview
- OnboardingChecklist
- Person
- Team
- Policy
- Permission
- Evidence
- Action

Relation:
- Customer hasContract Contract
- Customer assignedTo Person
- Person belongsTo Team
- Contract hasStatus ContractStatus
- Action requires Permission
- Decision basedOn Evidence
- Policy constrains Action
```

W3C OWL은 이런 지식을 `class`, `property`, `individual`, `restriction` 같은 구조로 표현할 수 있게 해줍니다. OWL 2 Primer는 객체를 individuals, 범주를 classes, 관계를 properties로 설명하며, property도 객체 간 관계와 데이터 값 관계로 나눠 설명합니다.

실무에서는 온톨로지를 너무 거창하게 볼 필요가 없습니다.

> **온톨로지는 조직에서 AI가 헷갈리면 안 되는 개념과 관계를 명시하는 설계도입니다.**

온톨로지가 있으면 AI Agent는 “고객”, “계약”, “승인”, “완료”, “근거” 같은 단어를 조직 기준으로 해석할 수 있습니다.

물론 온톨로지가 모든 문제를 해결하지는 않습니다. 온톨로지는 실제 데이터가 아닙니다. 설계도입니다. 실제 고객 A, 계약 B, 문서 C가 어디에 있고 어떻게 연결되는지는 지식그래프가 담당합니다.

---

## 3. 지식그래프란 무엇인가

지식그래프는 실제 업무 객체와 관계를 연결한 데이터 구조입니다.

온톨로지가 이렇게 정의한다고 해보겠습니다.

```text
# 예시 구조
Customer hasContract Contract
Contract approvedBy Person
Decision basedOn Evidence
Action requires Permission
```

지식그래프는 실제 데이터를 이렇게 연결합니다.

```text
# 예시 구조
Customer:AcmeCorp
  → hasContract → Contract:ACME-2026-001
  → assignedTo → Person:KimCSM
  → belongsToIndustry → Industry:Finance

Contract:ACME-2026-001
  → hasStatus → Signed
  → approvedBy → Person:LegalLead
  → basedOn → Document:SecurityReviewReport

Action:StartOnboarding
  → requiresPermission → Permission:OnboardingStart
  → constrainedBy → Policy:FinanceCustomerPolicy
```

그래프의 강점은 관계를 따라갈 수 있다는 점입니다.

예를 들어 AI Agent가 “이 고객의 온보딩을 시작해도 되는가?”를 판단하려면 다음 관계를 따라가야 합니다.

```text
# 예시 구조
고객 → 계약 → 계약 상태
고객 → 보안심사 → 심사 상태
고객 → 산업군 → 적용 정책
요청자 → 팀/역할 → 권한
액션 → 필요 권한 → 정책 제약
결정 → 근거 문서 → 감사 로그
```

단순 문서 검색은 관련 텍스트를 찾아줄 수 있지만, 이런 관계 기반 상태 검증은 별도의 구조가 필요합니다.

| 질문 | 문서 검색만으로 충분한가 | 그래프가 유리한 이유 |
|---|---|---|
| 이 정책 내용을 요약해줘 | 대체로 충분 | 문서 하나 또는 몇 개의 chunk로 가능 |
| 이 고객에게 어떤 정책이 적용되는가 | 일부 부족 | 고객-산업군-계약-정책 관계 필요 |
| 이 액션을 실행할 권한이 있는가 | 부족 | 사용자-역할-권한-액션 관계 필요 |
| 이 결정의 근거 문서는 무엇인가 | 부족 | 결정-Evidence-Document 관계 필요 |
| 이 이슈와 관련된 고객, 계약, 티켓은 무엇인가 | 부족 | 여러 객체의 연결 필요 |

결국 지식그래프는 검색 결과를 꾸미기 위한 기술이 아니라, 조직 업무 객체를 연결하고 검증하기 위한 운영 데이터 구조입니다.

---

## 4. 온톨로지와 지식그래프의 차이

온톨로지와 지식그래프는 자주 같이 쓰이지만 같은 것이 아닙니다.

가장 쉬운 비유는 이렇습니다.

```text
# 예시 구조
온톨로지 = 설계도
지식그래프 = 설계도에 따라 실제로 지어진 연결망
```

조금 더 기술적으로는 T-Box와 A-Box로 나눠 설명할 수 있습니다.

| 구분 | 의미 | 예시 |
|---|---|---|
| T-Box | 개념, 클래스, 관계, 제약 정의 | Customer, Contract, hasContract, requiresPermission |
| A-Box | 실제 인스턴스 데이터 | AcmeCorp, Contract-001, KimCSM, SecurityReview-123 |

실무에서는 이렇게 이해하면 충분합니다.

| 항목 | 온톨로지 | 지식그래프 |
|---|---|---|
| 질문 | 어떤 개념이 있고 어떻게 연결되는가 | 실제 데이터가 어떻게 연결되어 있는가 |
| 대상 | 클래스, 관계, 제약 | 고객, 계약, 문서, 티켓, 담당자 |
| 변경 빈도 | 상대적으로 낮음 | 상대적으로 높음 |
| 담당자 | 도메인 전문가 + 데이터/AI 아키텍트 | 데이터 엔지니어 + 플랫폼/업무 시스템 |
| 실패 리스크 | 개념 모델 오류 | 데이터 품질, 엔티티 매핑 오류 |

예를 들어 “계약은 반드시 승인자를 가져야 한다”는 온톨로지 또는 검증 규칙의 영역입니다. “계약 B의 승인자는 김OO이다”는 지식그래프의 영역입니다.

이 둘이 함께 있어야 AI Agent는 조직 지식을 안정적으로 사용할 수 있습니다.

---

## 5. RAG는 무엇을 잘하고, 무엇을 못하는가

RAG는 Retrieval-Augmented Generation의 줄임말입니다. 간단히 말하면 사용자의 질문과 관련된 문서 조각을 검색한 뒤, 그 내용을 LLM에게 제공해 답변을 생성하는 방식입니다.

RAG는 조직 AI 자동화에서 매우 유용합니다.

```text
# 예시 구조
사용자 질문
  ↓
벡터 검색 / 키워드 검색
  ↓
관련 문서 chunk 검색
  ↓
LLM에 문맥 제공
  ↓
답변 생성
```

RAG가 잘하는 일은 다음과 같습니다.

| 잘하는 일 | 예시 |
|---|---|
| 특정 문서 내용 요약 | 보안 정책 요약, 제품 문서 요약 |
| 질문과 관련된 문단 검색 | “환불 정책이 뭐야?” |
| 내부 위키 기반 Q&A | “배포 절차 알려줘” |
| 회의록/문서 기반 초안 작성 | “지난 회의 액션 아이템 정리해줘” |
| 근거 문서 일부 제공 | 답변에 관련 문서 링크 붙이기 |

하지만 RAG에는 한계도 있습니다.

문서 chunk는 기본적으로 텍스트 조각입니다. 고객, 계약, 담당자, 승인, 권한, 정책의 관계가 명시적으로 정리되어 있지 않으면 LLM이 텍스트에서 추론해야 합니다.

| RAG의 한계 | 설명 |
|---|---|
| 관계 추적 약함 | 여러 문서와 객체를 가로지르는 관계를 안정적으로 추적하기 어려움 |
| 엔티티 정합성 약함 | 같은 고객이 여러 이름/ID로 등장하면 혼동 가능 |
| 상태 검증 약함 | 계약 상태, 승인 상태, 권한 상태를 기계적으로 검증하기 어려움 |
| 정책 적용 약함 | 조건부 규칙을 명시적으로 검사하기 어려움 |
| 감사 가능성 제한 | 어떤 객체 관계를 따라 결론이 나왔는지 추적하기 어려움 |

따라서 RAG는 문서 기반 질의응답에는 훌륭하지만, 조직 단위 자동화의 모든 문제를 해결하지는 못합니다.

> **실무 판단**
> 질문이 “관련 문서를 찾아 요약해줘”라면 RAG가 먼저입니다.
> 질문이 “여러 객체의 관계와 상태를 확인하고 실행 가능 여부를 판단해줘”라면 그래프와 검증 규칙이 필요해집니다.

---

## 6. GraphRAG는 어떤 문제를 해결하려는가

GraphRAG는 RAG에 그래프 구조를 결합한 접근입니다.

Microsoft GraphRAG 문서는 GraphRAG를 단순 텍스트 chunk 기반 semantic search와 대비되는 구조적·계층적 RAG 접근으로 설명합니다. 원시 텍스트에서 지식그래프를 추출하고, 커뮤니티 계층과 요약을 만든 뒤, RAG 작업에 활용하는 방식입니다.

단순화하면 이런 흐름입니다.

```text
# 예시 구조
문서 corpus
  ↓
엔티티/관계/주장 추출
  ↓
지식그래프 생성
  ↓
커뮤니티 탐지 및 요약
  ↓
질문에 맞는 그래프 맥락 검색
  ↓
LLM 답변 생성
```

GraphRAG가 유리한 질문은 일반적인 “정답 문단 찾기”가 아니라, 전체 데이터셋의 구조를 봐야 하는 질문입니다.

예를 들면 다음과 같습니다.

```text
# 예시 구조
이 고객 이슈와 관련된 계약, 담당자, 정책, 장애 티켓을 연결해줘.
지난 분기 고객 불만의 주요 테마와 관련 제품군을 정리해줘.
이 프로젝트의 리스크가 어떤 팀과 문서에서 반복적으로 등장하는지 알려줘.
여러 문서에 흩어진 보안 예외 승인 흐름을 요약해줘.
```

RAG와 GraphRAG를 비교하면 다음과 같습니다.

| 항목 | 일반 RAG | GraphRAG |
|---|---|---|
| 기본 단위 | 문서 chunk | 엔티티, 관계, 커뮤니티, 서브그래프 |
| 강점 | 구현 단순, 빠른 문서 검색 | 관계 기반 맥락, 전체 구조 요약 |
| 약점 | 관계 추론과 전역 요약이 약함 | 구축 비용과 운영 복잡도 증가 |
| 적합한 질문 | “이 정책 요약해줘” | “이 이슈와 연결된 고객·계약·정책을 찾아줘” |
| 도입 시점 | 개인/팀 지식 검색 | 조직 지식 통합, 감사, 정책 검증 |

다만 GraphRAG가 항상 일반 RAG보다 좋은 것은 아닙니다.

그래프를 만들려면 엔티티 추출, 관계 추출, 중복 제거, 커뮤니티 요약, 품질 검증이 필요합니다. 데이터가 작고 질문이 단순하면 일반 RAG가 더 빠르고 경제적일 수 있습니다.

> **주의**
> GraphRAG는 “RAG의 상위 호환”이 아닙니다.
> 데이터가 관계형이고, 질문이 여러 문서와 객체를 가로지르며, 근거 추적이 중요할 때 효과가 커집니다.

---

## 7. SHACL은 왜 조직 규칙 검증에 중요한가

조직 AI 자동화에서 가장 위험한 것은 AI가 틀린 답변을 하는 것만이 아닙니다.

더 큰 위험은 **그럴듯한 판단으로 실제 시스템 액션을 실행하는 것**입니다.

예를 들어 다음과 같은 일이 생길 수 있습니다.

```text
# 예시 구조
승인되지 않은 계약 변경
권한 없는 고객 공지 발송
보안 심사 전 온보딩 시작
근거 문서 없는 리포트 발행
상태가 불완전한 티켓의 완료 처리
```

이런 문제는 프롬프트만으로 막기 어렵습니다. 실행 전에 데이터와 액션이 조직 규칙을 만족하는지 기계적으로 검증해야 합니다.

여기서 SHACL이 등장합니다.

W3C SHACL은 RDF 그래프가 특정 조건을 만족하는지 검증하는 언어입니다. SHACL에서는 검증 조건을 shapes graph로 표현하고, 실제 데이터 그래프가 그 조건을 만족하는지 검사합니다.

예를 들어 다음 규칙을 생각해볼 수 있습니다.

```text
# 예시 구조
계약 변경 액션은 승인자를 가져야 한다.
승인자는 계약 변경 권한을 가져야 한다.
고객 온보딩 액션은 보안 심사 통과 상태를 필요로 한다.
리포트 발행 결정은 최소 하나 이상의 근거 문서를 가져야 한다.
```

이를 SHACL 스타일로 표현하면 다음과 같은 형태가 됩니다. 실제 운영 코드라기보다 개념 예시입니다.

```turtle
# 예시 구조
:OnboardingActionShape
  a sh:NodeShape ;
  sh:targetClass :OnboardingAction ;
  sh:property [
    sh:path :requiresSecurityReview ;
    sh:minCount 1 ;
  ] ;
  sh:property [
    sh:path :basedOnEvidence ;
    sh:minCount 1 ;
  ] .
```

실무적으로 SHACL의 가치는 다음과 같습니다.

| 역할 | 설명 | 예시 |
|---|---|---|
| 데이터 품질 검증 | 필수 관계와 속성이 있는지 확인 | 계약에는 상태가 있어야 함 |
| 액션 조건 검증 | 실행 전 필요한 조건 확인 | 온보딩 전 보안 심사 필요 |
| 감사 가능성 확보 | 근거와 실행 조건 기록 | Decision basedOn Evidence |
| 운영 안정성 향상 | LLM 판단을 규칙으로 보완 | 권한 없는 실행 차단 |

LLM은 판단을 도울 수 있지만, 조직 규칙의 최종 검증을 LLM에게만 맡기면 안 됩니다.

> **실무 판단**
> AI Agent가 실제 시스템을 변경한다면, 프롬프트 가드레일과 별개로 기계적 검증 계층이 필요합니다.
> SHACL은 RDF 그래프 기반 환경에서 그 역할을 맡을 수 있는 대표적인 표준입니다.

---

## 8. SPARQL은 AI Agent의 그래프 조회 도구가 될 수 있다

SPARQL은 RDF 그래프를 질의하기 위한 언어입니다.

W3C SPARQL 1.1 문서는 SPARQL이 RDF 그래프의 쿼리 언어이며, RDF로 저장된 데이터뿐 아니라 미들웨어를 통해 RDF처럼 보이는 다양한 데이터 소스에도 질의할 수 있다고 설명합니다.

AI Agent 관점에서 SPARQL은 “그래프 데이터베이스용 SQL”처럼 생각할 수 있습니다. 물론 문법과 데이터 모델은 다르지만, 역할은 비슷합니다.

예를 들어 Agent가 이런 질문에 답해야 한다고 해보겠습니다.

```text
# 예시 구조
고객 A의 계약 상태, 담당자, 보안 심사 상태, 적용 정책을 조회해줘.
```

SPARQL 질의는 개념적으로 이런 형태가 됩니다.

```sparql
# 예시 구조
SELECT ?contract ?contractStatus ?csm ?reviewStatus ?policy
WHERE {
  :CustomerA :hasContract ?contract .
  ?contract :hasStatus ?contractStatus .
  :CustomerA :assignedTo ?csm .
  :CustomerA :hasSecurityReview ?review .
  ?review :hasStatus ?reviewStatus .
  :CustomerA :constrainedBy ?policy .
}
```

이 질의 결과를 LLM에게 그대로 넘기면, LLM은 훨씬 안정적으로 답변을 생성할 수 있습니다.

```text
# 예시 구조
고객 A의 계약은 Signed 상태입니다.
담당 CSM은 KimCSM입니다.
보안 심사는 Passed 상태입니다.
적용 정책은 FinanceCustomerPolicy입니다.
따라서 온보딩 시작 조건은 충족된 것으로 보입니다.
단, 실제 실행 전 사용자의 OnboardingStart 권한 검증이 필요합니다.
```

AI Agent 아키텍처에서는 SPARQL을 하나의 도구로 등록할 수 있습니다.

```text
# 예시 구조
Tool: queryKnowledgeGraph
Input: customerId, actionType
Output: 관련 서브그래프, 상태, 근거 문서, 정책
```

중요한 것은 그래프 전체를 프롬프트에 넣지 않는 것입니다.

> **실무 팁**
> LLM에게 전체 그래프를 보여주지 말고, 질문에 필요한 서브그래프만 조회해서 제공해야 합니다.
> 그래프는 컨텍스트 자체가 아니라, 컨텍스트를 잘라내는 인덱스이자 조회 도구입니다.

---

## 9. AI Agent 실행 흐름에 연결하는 방식

이제 각 요소를 하나의 실행 흐름에 넣어보겠습니다.

```text
# 예시 구조
사용자 요청
  ↓
의도 파악
  ↓
온톨로지로 업무 개념 해석
  ↓
지식그래프로 관련 객체 조회
  ↓
RAG/GraphRAG로 근거 문맥 검색
  ↓
SHACL/정책 엔진으로 조건 검증
  ↓
도구 실행
  ↓
실행 결과와 근거를 그래프에 기록
```

각 단계의 역할은 다음과 같습니다.

| 단계 | 사용 기술 | 역할 |
|---|---|---|
| 의도 파악 | LLM | 사용자의 요청을 업무 액션 후보로 해석 |
| 개념 해석 | 온톨로지 | 요청 단어를 조직 개념에 매핑 |
| 객체 조회 | 지식그래프, SPARQL | 관련 고객, 계약, 문서, 담당자, 정책 조회 |
| 문맥 검색 | RAG, GraphRAG | 근거 문서와 관련 맥락 검색 |
| 조건 검증 | SHACL, 정책 엔진 | 실행 전 필수 조건과 권한 검증 |
| 실행 | API, 워크플로우 도구 | 티켓 생성, 문서 작성, 알림 발송 |
| 기록 | KG, 로그 저장소 | 결과, 근거, 실행자, 상태 기록 |

여기서 LLM은 모든 것을 직접 판단하지 않습니다. LLM의 역할은 다음에 가깝습니다.

```text
# 예시 구조
요청 해석
필요 정보 결정
도구 호출 계획 수립
검증 결과 해석
사용자에게 설명
```

반면 기계적으로 처리해야 하는 것은 별도 계층에 맡깁니다.

```text
# 예시 구조
권한 확인
정책 검증
필수 필드 검증
상태 전이 검증
감사 로그 기록
```

이 분리가 중요합니다.

> **AI Agent 운영의 핵심은 LLM에게 모든 판단을 맡기는 것이 아니라, LLM을 조직 지식과 검증 규칙 위에서 실행되게 만드는 것입니다.**

---

## 10. 실무 아키텍처 패턴

조직에서 실제로 도입할 때는 여러 패턴이 가능합니다.

### 패턴 A. RAG 중심 + 최소 용어집

가장 단순한 구조입니다.

```text
# 예시 구조
문서 저장소
  ↓
벡터 DB
  ↓
RAG
  ↓
LLM 답변
```

적합한 상황은 다음과 같습니다.

- 팀 내부 문서 검색
- 정책 문서 요약
- 회의록 정리
- 코드/문서 기반 Q&A
- 실행 액션이 제한적인 업무

이 단계에서는 온톨로지 대신 공통 용어집 정도만 있어도 충분할 수 있습니다.

### 패턴 B. RAG + 업무 객체 매핑

문서 검색에 업무 객체 매핑을 추가합니다.

```text
# 예시 구조
문서 chunk
  + 고객 ID
  + 계약 ID
  + 프로젝트 ID
  + 티켓 ID
  ↓
하이브리드 검색
```

적합한 상황은 다음과 같습니다.

- 특정 고객 관련 문서 검색
- 프로젝트별 지식 정리
- 티켓과 문서 연결
- 고객지원 이슈 분석

이 단계에서는 완전한 지식그래프가 아니더라도, 엔티티 ID를 일관되게 붙이는 것만으로 효과가 있습니다.

### 패턴 C. 온톨로지 + KG + RAG

조직 자동화에 가까운 구조입니다.

```text
# 예시 구조
온톨로지
  ↓
지식그래프
  ↔ 기존 DB/API/문서 저장소
  ↓
RAG/GraphRAG
  ↓
Agent 도구 실행
```

적합한 상황은 다음과 같습니다.

- 여러 팀이 같은 고객/계약/정책을 사용
- 권한과 상태 검증 필요
- 여러 시스템 데이터를 연결
- 근거 추적과 감사 로그 필요

### 패턴 D. KG + 정책 엔진 + Agent 운영체계

가장 고도화된 구조입니다.

```text
# 예시 구조
사용자/Agent 요청
  ↓
정책 엔진
  ↓
지식그래프 조회
  ↓
검증 규칙 실행
  ↓
승인 또는 Human-in-the-loop
  ↓
도구 실행
  ↓
감사 로그 기록
```

이 패턴은 금융, 의료, 보안, 대기업 내부 자동화처럼 리스크가 큰 환경에서 필요해집니다.

| 패턴 | 장점 | 단점 | 추천 시점 |
|---|---|---|---|
| RAG 중심 | 빠르고 단순 | 관계/권한 검증 약함 | 개인/팀 문서 검색 |
| RAG + 객체 매핑 | 검색 정확도 개선 | 개념 모델 제한적 | 팀 간 데이터 연결 시작 |
| 온톨로지 + KG + RAG | 관계와 규칙 반영 | 구축/운영 복잡도 증가 | 조직 업무 자동화 |
| KG + 정책 엔진 | 안전한 실행 | 높은 설계 비용 | 고위험 자동화 |

---

## 11. 리스크와 도입 판단

온톨로지와 지식그래프는 강력하지만 운영 리스크가 있습니다.

### 구축 리스크

- 개념 모델이 지나치게 커질 수 있습니다.
- 도메인 전문가 없이 개발자만 모델링하면 실제 업무 의미가 빠질 수 있습니다.
- 너무 많은 시스템을 한 번에 연결하려다 PoC가 끝나지 않을 수 있습니다.

### 데이터 품질 리스크

- 같은 고객이 여러 ID로 저장될 수 있습니다.
- LLM이 추출한 엔티티와 관계에 오류가 있을 수 있습니다.
- 오래된 문서가 최신 정책처럼 연결될 수 있습니다.

### 운영 리스크

- 잘못된 그래프가 Agent의 판단 근거가 될 수 있습니다.
- 권한 검증 없이 도구 실행이 연결되면 사고가 커질 수 있습니다.
- 그래프 업데이트와 실제 시스템 상태가 어긋날 수 있습니다.

> **보안 주의**
> AI Agent가 실제 업무 시스템을 변경한다면, 그래프 조회와 문서 검색만으로는 충분하지 않습니다.
> 권한, 승인, 정책, 감사 로그, human-in-the-loop 설계를 반드시 함께 봐야 합니다.

도입 판단은 다음 기준으로 하면 됩니다.

| 질문 | 예이면 |
|---|---|
| 여러 팀이 같은 용어를 다르게 쓰는가 | 온톨로지 검토 |
| 여러 시스템의 같은 객체를 연결해야 하는가 | KG 검토 |
| 문서 검색보다 관계 추적이 중요한가 | GraphRAG/KG 검토 |
| 실행 전 규칙 검증이 필요한가 | SHACL/정책 엔진 검토 |
| 근거와 감사 로그가 필요한가 | provenance 설계 검토 |
| 단순 문서 요약이 대부분인가 | RAG부터 시작 |

---

## 12. 체크리스트, Q&A, 참고자료

### 실전 체크리스트

```text
# 예시 구조
아키텍처 설계 체크리스트

[ ] 이 문제는 문서 검색 문제인가, 관계 검증 문제인가?
[ ] RAG로 충분한 질문과 KG가 필요한 질문을 분리했다.
[ ] 핵심 업무 객체가 정의되어 있다.
[ ] 동일 객체를 여러 시스템에서 매핑할 방법이 있다.
[ ] 온톨로지의 클래스와 관계가 최소 범위로 정의되어 있다.
[ ] 그래프 조회 결과를 LLM에 넘기는 방식이 정해져 있다.
[ ] SHACL 또는 정책 엔진으로 검증할 규칙이 정리되어 있다.
[ ] 도구 실행 전 권한 확인 절차가 있다.
[ ] 실행 결과와 근거를 기록할 로그 구조가 있다.
[ ] 그래프 품질을 사람이 검토하는 절차가 있다.
```

### Q1. 온톨로지와 데이터베이스 스키마는 같은 건가요?

같지 않습니다. 데이터베이스 스키마는 저장 구조에 가깝고, 온톨로지는 업무 개념과 의미 관계에 가깝습니다. 물론 둘은 연결될 수 있습니다.

### Q2. 지식그래프를 만들면 RAG가 필요 없나요?

아닙니다. 지식그래프는 객체와 관계에 강하고, RAG는 문서 맥락에 강합니다. 조직 자동화에서는 둘을 함께 쓰는 경우가 많습니다.

### Q3. GraphRAG를 쓰면 무조건 성능이 좋아지나요?

아닙니다. 질문이 단순 문서 검색에 가깝고 데이터가 작다면 일반 RAG가 더 효율적일 수 있습니다. GraphRAG는 관계와 전체 구조를 다루는 질문에서 가치가 커집니다.

### Q4. SHACL은 꼭 써야 하나요?

RDF 기반 그래프를 사용한다면 SHACL은 강력한 선택지입니다. 다만 모든 조직이 SHACL을 써야 하는 것은 아닙니다. 정책 엔진, 타입 시스템, 업무 규칙 엔진으로도 일부 역할을 수행할 수 있습니다.

### Q5. SPARQL을 LLM이 직접 작성하게 해도 되나요?

가능은 하지만 위험합니다. 운영 환경에서는 허용된 질의 템플릿, 파라미터 검증, 접근 권한 제한을 두는 것이 좋습니다. LLM이 임의의 쿼리를 실행하게 두면 데이터 유출과 성능 문제가 생길 수 있습니다.

---

## 참고자료와 불확실성

### 참고자료

- W3C, [OWL 2 Web Ontology Language Primer](https://www.w3.org/TR/owl2-primer/)
- W3C, [OWL Web Ontology Language Overview](https://www.w3.org/TR/owl-features/)
- W3C, [Shapes Constraint Language SHACL](https://www.w3.org/TR/shacl/)
- W3C, [SPARQL 1.1 Query Language](https://www.w3.org/TR/sparql11-query/)
- Microsoft, [GraphRAG Documentation](https://microsoft.github.io/graphrag/)
- Microsoft Research, [Project GraphRAG](https://www.microsoft.com/en-us/research/project/graphrag/)
- OpenAI, [A practical guide to building agents](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/)
- Anthropic, [Building Effective AI Agents](https://www.anthropic.com/research/building-effective-agents)

### 확인된 사실

- OWL은 클래스, 속성, 개인, 관계 등을 표현하는 온톨로지 언어입니다.
- SHACL은 RDF 그래프를 조건에 따라 검증하기 위한 W3C 표준입니다.
- SPARQL은 RDF 그래프를 질의하기 위한 W3C 표준입니다.
- Microsoft GraphRAG는 원시 텍스트에서 지식그래프와 커뮤니티 요약을 만들고 이를 RAG에 활용하는 구조적 접근을 설명합니다.

### 작성자의 해석

- 조직 AI Agent 아키텍처에서 RAG와 KG는 경쟁 관계가 아니라 상호 보완 관계입니다.
- LLM이 업무 판단을 돕더라도, 권한과 규칙 검증은 별도 계층으로 분리하는 것이 안전합니다.

### 불확실성

- GraphRAG의 효과는 데이터 구조, 질문 유형, 추출 품질, 요약 품질에 크게 좌우됩니다.
- 실제 운영에서는 OWL/SHACL/SPARQL을 모두 쓸 수도 있고, 일부만 쓰거나 다른 정책 엔진으로 대체할 수도 있습니다.

---

## 마무리

정리하면, 조직 AI 자동화에서 중요한 것은 LLM이 더 긴 문서를 읽는 것이 아닙니다.

중요한 것은 **어떤 개념을 어떤 관계와 규칙 안에서 해석해야 하는지**입니다.

온톨로지는 이 개념과 관계의 설계도입니다. 지식그래프는 실제 업무 객체의 연결망입니다. RAG는 문서 맥락을 가져오고, GraphRAG는 관계와 구조를 활용해 맥락을 구성합니다. SHACL은 조건을 검증하고, SPARQL은 필요한 서브그래프를 조회합니다.

한 줄로 정리하면 이렇습니다.

> **조직 AI Agent는 LLM 하나로 완성되지 않습니다. LLM이 조직 지식을 읽고, 검증하고, 실행할 수 있도록 의미 계층과 검증 계층을 함께 설계해야 합니다.**

다음 3편에서는 이 구조를 실제 조직에 어떻게 도입할지 다룹니다. 전사 KG부터 만들지 않고, 핵심 업무 하나에서 최소 온톨로지로 시작하는 단계별 전략을 정리하겠습니다.

---

## 요약 카드

- 한 줄 요약: **RAG는 문서를 찾고, KG는 관계를 연결하고, SHACL은 실행 조건을 검증한다.**
- 추천 대상: AI Agent 아키텍처를 설계하는 개발자, 데이터 엔지니어, 플랫폼팀
- 비추천 대상: 단순 문서 요약만 필요한 팀
- 가장 중요한 설정: 그래프 전체가 아니라 필요한 서브그래프만 LLM에 제공하기
- 가장 큰 리스크: GraphRAG를 일반 RAG의 상위 호환으로 오해하는 것
- 지금 바로 할 일: 현재 업무 질문을 “문서 검색형”과 “관계 검증형”으로 분류하기