[Trend & Event] 요즘 왜 다들 Graph를 말할까? 지식 그래프·온톨로지·GraphRAG를 한 번에 이해하기

[Trend & Event]

Graph는 하나의 유행어가 아니다. 관계를 표현하는 모델, 의미를 정하는 온톨로지, 실제 지식을 엮는 Knowledge Graph, 저장·탐색 엔진, 그리고 AI 활용 방식이 한 단어 아래 겹쳐 있다. 층을 나눠 보면 용어가 정리되고, 어디에 써야 할지도 훨씬 분명해진다.

요즘 기술 발표를 보다 보면 Graph라는 단어가 자주 눈에 들어온다. 2026년 9월 Google Cloud는 BigQuery Graph를 정식 출시했고, Amazon Web Services(AWS)는 Amazon Bedrock에서 그래프 기반 검색 증강 생성(Graph-based Retrieval-Augmented Generation, GraphRAG)을 관리형 기능으로 제공하고 있다. Palantir는 6월 Ontology MCP를 정식 공개했고, 보안과 커머스 영역에서는 Security Graph, Commerce Graph 같은 표현도 다시 앞에 나온다.

문제는 용어가 너무 많다는 점이다. 어떤 문서는 Ontology를 말하고, 어떤 문서는 Knowledge Graph를 말하며, 또 다른 문서는 Graph Database나 GraphRAG를 말한다. 심지어 Context Graph, Identity Graph, Commerce Graph처럼 앞에 산업 이름이 붙는 경우도 많다. 겉으로는 모두 Graph처럼 보이지만, 실제로는 역할이 다르다.

이 글은 Graph를 하나의 기술 이름으로 설명하지 않는다. 대신 관계 표현 방식인지, 의미 규칙인지, 실제 지식 구조인지, 저장·질의 엔진인지, AI 활용 방식인지를 나눠 본다. 그리고 각각이 최근 어떤 영역에서 쓰이고 있는지, 실무자가 어떤 문제를 만났을 때 검토할 만한지까지 연결해 본다.

EDITORIAL NOTE

이 보고서는 최근 공식 발표를 바탕으로 작성했다. 다만 제품명에 Graph가 붙었다고 해서 모두 같은 표준 기술을 뜻하는 것은 아니다. 이름보다 중요한 것은 무엇을 노드와 엣지로 삼는지, 관계의 의미를 어디서 정의하는지, AI가 어떤 방식으로 그 관계를 읽고 행동하는지다.

WHAT CHANGED

Graph가 전용 그래프 데이터베이스 제품군을 넘어 데이터웨어하우스, 보안, 커머스, AI 에이전트 영역으로 퍼지고 있다.
Graph는 저장 방식만이 아니라 AI가 맥락을 이해하고 행동을 추적하는 구조로도 쓰이기 시작했다.
같은 Graph라도 Ontology, Knowledge Graph, Graph Database, GraphRAG는 서로 다른 층의 문제를 푼다.

왜 지금 다시 Graph인가

관계형 데이터베이스(Relational Database)가 약해졌기 때문은 아니다. 거래 처리와 정형 보고에서는 여전히 핵심이다. 다만 기업이 던지는 질문이 바뀌고 있다. “무엇이 팔렸나”보다 “어떤 고객이 어떤 경로로 어떤 상품과 어떤 채널에 연결됐나”가 중요해졌다. 보안에서는 “어떤 경고가 떴나”보다 “어떤 사용자, 기기, 권한, 이벤트가 어떤 공격 경로로 연결되나”가 더 중요해졌다. AI에서도 “비슷한 문서 조각을 찾았나”보다 “답의 근거가 어떤 개체와 관계를 따라 연결되나”가 점점 중요해진다.

최근 발표를 시간순으로 놓아 보면 흐름이 더 분명하다. Graph는 더 이상 특정 데이터 모델러의 도구에 머물지 않는다. 데이터 분석, 보안 조사, 커머스 행동 분석, 에이전트 연결과 추적까지 들어오고 있다.

2026년 1월 27일

Microsoft Security의 security graph 해설 · Microsoft가 사용자, 기기, 애플리케이션, 자산과 활동의 관계를 연결해 공격 경로와 위협을 파악하는 security graph 개념과 활용 사례를 설명했다. 제품 출시 발표와는 구분할 필요가 있다.

2026년 4월 21일

FERMÀT Commerce Graph · FERMÀT는 세션 리플레이, 히트맵, 분석, 고객 데이터 플랫폼(Customer Data Platform, CDP)에 정보가 흩어진 문제를 지적하고, Commerce Graph를 세션 신호를 하나의 질의 가능한 그림으로 연결하는 행동 인텔리전스 계층으로 공개 베타했다.

2026년 6월 25일

Palantir Ontology MCP · 객체 유형, 액션 유형, 함수를 모델 컨텍스트 프로토콜(Model Context Protocol, MCP) 도구로 노출해 AI 에이전트가 기존 엔터프라이즈 지식 구조와 워크플로를 쓸 수 있게 했다.

2026년 9월 1일

Google Cloud BigQuery Graph · ISO 표준 그래프 질의 언어(Graph Query Language, GQL)를 구조화 질의 언어(Structured Query Language, SQL)와 나란히 두고, 별도 추출·변환·적재(Extract, Transform, Load, ETL) 없이 데이터웨어하우스에서 그래프 탐색을 수행하는 방향을 제시했다.

핵심은 Graph가 독립 기술 스택에만 머무르지 않고 기존 기업 데이터 스택 안으로 들어오고 있다는 점이다. Google Cloud는 BigQuery Graph의 사용 사례로 위협·사기 탐지와 공급망 디지털 트윈을 들었고, Yahoo가 광고 캠페인·오디언스·노출·성과의 관계를 분석하는 사례도 소개했다. 이를 하나의 시장 법칙으로 단정하기는 어렵지만, 최근 제품들이 관계 중심 질문을 전면에 내세우는 흐름은 분명하다.

Graph를 이해하는 가장 쉬운 프레임은 5개 층이다

Graph를 어렵게 만드는 이유는 서로 다른 층의 개념이 한꺼번에 섞이기 때문이다. AgencyTimes에서는 아래 다섯 층으로 나누면 이해가 빨라진다고 본다.

AGENCYTIMES · GRAPH 5-LAYER MAP

1. 관계 표현 · Graph / RDF / Property Graph : 사람, 상품, 주문, 문서 같은 개체와 그 사이의 연결을 그래프 구조로 나타낸다. RDF와 Property Graph는 서로 다른 그래프 데이터 모델이다.

2. 의미 규칙 · Ontology / OWL : 어떤 개체와 관계를 어떤 의미로 해석할지 정의한다. RDF 자체는 온톨로지 언어가 아니라 그래프 기반 데이터 모델이다.

3. 실제 지식 · Knowledge Graph : 실제 회사, 상품, 사람, 사건, 문서를 연결해 조직이 쓸 수 있는 지식층을 만든다.

4. 저장·질의 · Graph Database / Warehouse-native Graph : 관계를 저장하고 경로를 빠르게 탐색하는 엔진이다.

5. AI 활용 · GraphRAG / Context Graph : AI가 관계를 따라 문맥을 확장하거나, 에이전트의 상태와 행동 이력을 설명 가능한 구조로 남긴다.

Graph는 가장 바닥의 관계 표현 방식이다. 예를 들어 Property Graph에서는 고객 A, 주문 101, 상품 X, 공급업체 S를 노드로 놓고, “주문했다”, “포함한다”, “공급한다”를 엣지로 표현할 수 있다. 날짜, 금액, 상태 같은 정보는 노드나 엣지의 속성(Property)으로 붙일 수 있다. RDF는 이와 다른 트리플 기반 그래프 모델을 사용한다.

온톨로지(Ontology)는 의미와 규칙을 정한다. 예를 들어 ‘고객’과 ‘판매자’는 같은 사람일 수 있어도 업무상 다른 역할이다. ‘주문 취소’와 ‘반품’도 다르다. Ontology는 이런 구분을 정의한다. 자원 기술 프레임워크(Resource Description Framework, RDF)는 주어-술어-목적어 형태의 트리플로 관계를 표현하는 그래프 데이터 모델이고, 웹 온톨로지 언어(Web Ontology Language, OWL)는 더 복잡한 지식과 관계를 논리적으로 표현해 일관성 검사와 추론에 활용할 수 있는 온톨로지 언어다.

Knowledge Graph는 연결된 개체와 관계에 도메인의 의미를 함께 담는 지식 구조다. 이해를 위해 단순화하면, Ontology가 “상품은 브랜드와 관계를 가질 수 있다”는 의미 규칙을 정의하고 Knowledge Graph에 “상품 X–브랜드 B” 같은 실제 연결이 들어가는 식으로 볼 수 있다. 다만 모든 Knowledge Graph가 정교한 형식 온톨로지를 필수로 사용하는 것은 아니며, 제품과 구현에 따라 경계가 다르다.

Graph Database는 저장과 탐색 엔진이다. Amazon Neptune처럼 전용 그래프 데이터베이스를 쓸 수 있고, BigQuery Graph처럼 기존 데이터웨어하우스 안에서 그래프 질의를 할 수도 있다. 여기서 중요한 점은 Graph라는 개념과 Graph Database라는 제품 범주는 같은 말이 아니라는 것이다.

GraphRAG와 Context Graph는 AI 활용 층에서 만나는 표현이다. GraphRAG는 그래프 관계를 활용해 검색 맥락을 확장하고 여러 문서와 개체 사이의 연결을 답변에 반영하는 것을 목표로 한다. 여기서 Context Graph는 특히 Google Cloud가 2026년 BigQuery Agent Analytics에서 사용한 의미로, 에이전트의 선택·정책 적용·대안·실행 결과를 질의 가능한 추적으로 남기는 구조를 가리킨다. 업계 전체에서 하나의 표준 정의로 굳어진 용어로 보기는 아직 이르다.

NOTE

Ontology → Knowledge Graph → Graph Database → GraphRAG가 시간순 발전 단계라는 뜻은 아니다. 서로 다른 역할을 맡는 층이다. 어떤 조직은 Ontology 없이 Graph Database만 쓸 수 있고, 어떤 조직은 전용 Graph Database 없이도 Knowledge Graph와 GraphRAG를 운영할 수 있다.

비슷해 보이지만 다른 용어들: 어디서 갈라지나

실무에서는 용어를 아주 엄격하게 쓰지 않는 경우가 많다. 그럼에도 어느 정도 기준이 있어야 회의가 덜 엇갈린다. 아래 표는 Graph 주변 용어를 같은 기준으로 다시 정리한 것이다.

용어	무엇인가	주로 푸는 문제	짧은 예제
Graph	노드와 엣지로 관계를 표현하는 기본 모델	누가 누구와 어떻게 연결됐는지 본다.	고객 A → 주문 101 → 상품 X → 공급업체 S
Ontology	개체 유형, 속성, 관계의 의미를 정의하는 체계	용어 충돌을 줄이고 규칙을 맞춘다.	“고객”, “리드”, “계정”, “법인 고객”을 구분해 정의
RDF	주어–술어–목적어 트리플을 핵심으로 하는 W3C 그래프 데이터 모델	웹과 시스템 사이에서 식별 가능한 관계 데이터를 교환·연결할 때 쓴다.	기관 A–발행함–문서 B
OWL	복잡한 개체·집합·관계의 의미를 논리적으로 표현하는 W3C 온톨로지 언어	일관성 검사나 명시되지 않은 관계의 추론이 필요할 때 검토한다.	클래스·관계·제약을 형식적으로 정의
Knowledge Graph	실제 개체와 사실을 연결한 지식층	여러 시스템의 지식을 한 맥락에서 읽는다.	회사–제품–계약–문의–담당자 연결
Graph Database	연결 데이터를 저장하고 탐색하는 데이터베이스	복잡한 경로, 다단계 연결, 빠른 순회가 필요할 때 유리하다.	사기 네트워크 4단계 연결 찾기
Vector Database	벡터를 저장하고 유사도 검색을 수행하도록 설계된 데이터베이스. 생성형 AI에서는 임베딩 벡터 저장에 자주 쓰인다.	유사한 문맥을 빠르게 찾는다.	비슷한 정책 문단 찾기
GraphRAG	그래프 관계를 활용해 RAG 검색 맥락을 확장하는 방식	멀리 떨어진 사실과 경로를 함께 가져와 답을 돕는다.	공급사 지연 → 부품 부족 → 출하 지연 → 주요 고객 영향
Context Graph	에이전트의 상태, 선택, 도구 호출, 정책 적용, 결과를 연결하는 최근 표현	AI 행동의 설명 가능성과 추적성을 높인다.	어떤 데이터로 어떤 액션을 실행했는지 감사 기록 남기기

여기서 가장 자주 생기는 오해는 두 가지다. 하나는 Ontology를 Graph의 다른 이름으로 보는 것이고, 다른 하나는 Vector Database와 Graph Database를 경쟁 기술로만 보는 것이다. 전자는 의미 규칙과 저장 구조를 섞는 오해다. 후자는 유사도 검색과 관계 탐색이라는 서로 다른 강점을 놓치는 오해다.

요즘 Graph가 쓰이는 영역: 풍부한 예제로 보면 더 쉽다

Graph는 특정 산업만의 기술이 아니다. 실제 현장에서는 문제 유형에 따라 다른 모습으로 등장한다. 이름보다 어떤 관계를 모델링하는지가 중요하다.

1. 검색과 지식 탐색

Google Search에서 오래전부터 알려진 Knowledge Graph는 검색 결과의 개체 이해를 돕는 대표 사례다. 기업 내부에서는 제품 문서, 정책 문서, 고객 기록, 티켓 이력을 하나의 지식층으로 연결하는 방식으로 응용할 수 있다.

2. 보안 조사와 공격 경로

Microsoft는 security graph를 사용자, 기기, 애플리케이션, 자산과 활동의 관계를 연결해 위협과 공격 경로를 조사하는 구조로 설명한다. 이는 특정 단일 제품명이라기보다 Microsoft Security가 설명하는 그래프 기반 보안 접근의 범주로 보는 편이 정확하다.

3. 커머스 행동 분석

FERMÀT는 기존 커머스 분석 정보가 세션 리플레이, 히트맵, 웹 분석, CDP 등에 흩어진 문제를 지적한다. Commerce Graph는 세션 신호를 질의 가능한 행동 인텔리전스 계층으로 묶는다고 설명한다. 예를 들어 장바구니 이탈이나 페이지 마찰이 어떤 고객 행동과 연결되는지 묻는 식의 분석을 생각할 수 있다.

4. 사기 탐지와 금융 네트워크

같은 전화번호, 기기, 배송지, 카드 토큰을 공유하는 계정이 여러 차례 환불을 반복한다면, 표 기반 리포트보다 Graph가 강하다. Google Cloud도 BigQuery Graph의 활용 장면으로 사기 네트워크 탐지를 제시했다.

5. 공급망과 운영 리스크

부품 A는 공급사 B가, 공급사 B는 항구 C를, 항구 C는 특정 해상 운송 노선을 거친다고 하자. 이때 한 단계의 차질이 어떤 공장과 주문에 연결되는지 보려면 공급망 디지털 트윈 형태의 Graph가 적합하다.

6. 고객 360과 식별 통합

Identity Graph는 이메일, 쿠키, 로그인 ID, 앱 디바이스 ID처럼 흩어진 식별자를 하나의 고객 맥락으로 묶는 데 쓰인다. 마케팅에서는 광고 노출, 방문, 구매, 고객지원 이력을 하나의 고객 여정으로 보는 데 도움이 된다.

7. 엔터프라이즈 AI와 에이전트

Palantir의 Ontology MCP는 Foundry Ontology의 객체 유형, 액션 유형, 함수를 MCP 도구로 노출해 에이전트가 데이터를 조회하고 워크플로를 실행할 수 있게 한다. 여기서 Palantir의 Ontology는 W3C OWL 온톨로지와 동일한 규격명이 아니라, 조직의 데이터와 실제 업무 개체·액션을 연결하는 Palantir 고유의 운영 계층이다. Google Cloud의 Context Graph는 에이전트 행동의 설명 가능성과 감사 추적에 초점을 둔다.

이 사례들이 보여주는 공통점은 간단하다. Graph는 “데이터가 많아서” 쓰는 기술이 아니라, 경로·관계·전파·의존성이 질문의 핵심일 때 가치가 커진다. 반대로 한 단계 집계로 끝나는 질문이라면 굳이 Graph를 앞세울 필요가 없다.

AI와 함께 쓸 때는 Vector 검색과 Graph를 대립시키지 않는 편이 낫다

Graph 열풍을 AI와 연결할 때 가장 많이 나오는 질문은 이것이다. “Vector Database면 충분하지 않나?” 답은 문제에 따라 다르다. 제품 설명서 몇 개를 찾아 요약하는 수준이라면 벡터 검색만으로도 충분할 수 있다. 하지만 기업의 질문은 점점 더 다단계 관계를 요구한다.

AWS가 소개한 GraphRAG도 사실상 둘을 함께 쓴다. 먼저 벡터 검색으로 관련 문서나 개체를 찾고, 이어 그래프를 따라 인접한 노드와 관계를 확장한다. 이 구조는 “비슷한 문장”과 “실제로 연결된 사실”을 동시에 다뤄야 하는 장면에 잘 맞는다.

질문 유형	우선 검토할 방식	이유
정책 문서나 매뉴얼에서 비슷한 문단을 찾고 싶다	Vector 검색 중심	의미 유사도가 핵심이다.
여러 문서와 시스템에 걸친 개체 관계를 함께 설명해야 한다	GraphRAG 또는 Vector + Graph	문서 의미와 실제 연결 구조가 둘 다 필요하다.
조직 용어가 제각각이라 데이터 의미가 자주 엇갈린다	Ontology 우선	저장 방식보다 정의와 규칙 정리가 먼저다.
사기·공급망·권한처럼 다단계 경로를 자주 계산한다	Graph Database 또는 Warehouse-native Graph	관계 순회와 경로 탐색 성능이 중요하다.
AI 에이전트가 어떤 데이터로 어떤 행동을 했는지 추적해야 한다	Context Graph 성격의 구조	설명 가능성, 권한, 감사 이력이 중요하다.

실전에서는 “어느 데이터베이스를 살까”보다 “우리가 풀고 싶은 질문이 관계 중심인가”를 먼저 따지는 편이 낫다. 그리고 그다음에 의미 정리, 저장 엔진, AI 연결 방식을 나누어 본다. 순서를 거꾸로 잡으면 기술은 도입되는데 답은 더 복잡해지는 일이 생긴다.

실무자는 무엇부터 확인하면 되나

Graph를 검토한다고 해서 처음부터 큰 플랫폼을 도입할 필요는 없다. 오히려 아래 질문을 먼저 던지는 편이 안전하다.

CHECKLIST

우리 질문은 단순 집계인가, 아니면 여러 단계의 경로를 따라가야 하는가.
사람·상품·문서·계정 같은 핵심 개체를 조직 안에서 같은 의미로 쓰고 있는가.
관계를 연결할 식별자와 기준 키가 실제로 정리되어 있는가.
관계가 얼마나 자주 바뀌며, 누가 갱신 책임을 지는가.
AI가 이 구조를 읽을 때 조회만 할 것인가, 액션까지 실행할 것인가.
도입의 목표가 더 좋은 검색인지, 더 빠른 탐지인지, 더 설명 가능한 AI인지 명확한가.

실패도 비슷한 패턴으로 나온다. 데이터는 연결했지만 의미 정의가 없고, Ontology는 만들었지만 운영 주체가 없고, AI 에이전트는 붙였지만 권한과 감사 이력이 없다. Graph 프로젝트는 기술보다 운영 기준에서 자주 흔들린다.

PRACTICAL TAKE

Graph를 “도입할 기술”로만 보지 말고 “관계를 기준으로 질문하는 방식”으로 먼저 이해하는 편이 낫다. 그다음에 Ontology가 필요한지, Knowledge Graph가 필요한지, 전용 Graph Database가 필요한지, 아니면 기존 데이터웨어하우스와 Vector 검색만으로 충분한지 나눠 보면 된다.

Summary

Graph는 하나의 기술 제품명이 아니라 관계를 중심으로 데이터를 표현하고 활용하는 넓은 접근이다. RDF와 Property Graph는 관계를 표현하는 서로 다른 그래프 데이터 모델이고, Ontology와 OWL은 의미와 규칙을 정의하는 층에서 만난다. Knowledge Graph는 연결된 개체·관계와 도메인 의미를 지식으로 조직하는 구조이며, Graph Database는 연결 데이터를 저장하고 탐색하는 엔진이다. GraphRAG는 이 관계 구조를 생성형 AI 검색에 활용하는 방식이고, Context Graph는 제품마다 의미가 다르지만 Google Cloud에서는 에이전트 행동의 질의 가능한 추적 구조로 쓰인다. 최근 BigQuery Graph, GraphRAG, Ontology MCP, security graph, Commerce Graph가 함께 등장하는 흐름은 관계·경로·의존성을 데이터와 AI의 핵심 맥락으로 다루는 사례가 늘고 있음을 보여준다.

FAQ

자주 묻는 질문

Q. Graph와 Knowledge Graph의 차이는 무엇인가요?

Graph는 개체와 관계를 표현하는 일반 모델이다. Knowledge Graph는 그 모델 위에 실제 사람, 상품, 회사, 문서, 사건 같은 개체와 사실을 채워 넣은 지식층이다. 모든 Graph가 Knowledge Graph인 것은 아니다.

Q. Ontology와 Knowledge Graph는 같은 것인가요?

같지 않다. Ontology는 무엇이 어떤 의미를 가지는지 정의하는 규칙 층이고, Knowledge Graph는 그 규칙 위에 실제 데이터를 채운 구조다. 실무에서는 둘을 넓게 묶어 부르기도 있지만, 회의에서는 구분해 두는 편이 유용하다.

Q. Graph Database가 관계형 데이터베이스를 대체하나요?

대부분의 조직에서는 대체보다 역할 분담에 가깝다. 거래 처리와 정형 집계는 관계형 데이터베이스가 여전히 강하다. 다단계 관계 탐색과 경로 분석이 핵심일 때 Graph Database나 Warehouse-native Graph가 유리할 수 있다.

Q. GraphRAG는 Vector RAG를 대체하나요?

보통은 대체보다 보완 관계다. 유사 문서를 찾는 일은 Vector 검색이 강하다. 다만 여러 문서와 개체 사이의 연결, 경로, 의존성을 함께 설명해야 할 때는 GraphRAG가 강점을 가진다. AWS의 관리형 GraphRAG도 두 방식을 함께 쓴다.

Q. 우리 회사가 처음 시작한다면 무엇부터 해야 하나요?

도구 선정부터 시작하지 않는 편이 낫다. 먼저 관계 중심으로 풀어야 할 질문이 실제로 있는지 확인하고, 핵심 개체와 식별자를 정리해야 한다. 그다음에 의미 규칙, 저장 방식, AI 연결 여부를 단계적으로 나누어 보는 것이 안정적이다.

TERMINOLOGY

함께 보면 좋은 용어

용어	뜻	실무 포인트
Node	사람, 상품, 문서처럼 연결의 대상이 되는 개체	무엇을 노드로 삼는지에 따라 그래프의 가치가 달라진다.
Edge	노드 사이의 관계	관계의 방향과 의미가 분명해야 한다.
Property	노드나 엣지에 붙는 속성값	날짜, 금액, 상태, 위험도 같은 값이 여기에 들어간다.
Triple	주어–술어–목적어 형태의 관계 표현	RDF를 이해할 때 핵심 단위다.
Traversal	그래프에서 노드와 엣지를 따라 이동하며 탐색하는 일	사기 네트워크, 공급망, 공격 경로 같은 문제와 잘 맞는다.
GQL	ISO/IEC 39075:2024로 표준화된 Property Graph용 데이터베이스 언어	BigQuery Graph는 ISO GQL과 SQL/PGQ 호환 기능을 기존 SQL 환경과 함께 제공한다.
MCP	AI 애플리케이션이 외부 데이터와 도구에 연결할 때 쓰이는 공개 프로토콜	Palantir는 Ontology MCP를 통해 Foundry Ontology 자원을 MCP 도구로 노출한다.

이 블로그 검색