안녕하세요, 에디터 쏘입니다 :)

1년 사이 주가가 최대 500% 이상 상승한 팔란티어(Palantir). 요즘 가장 핫한 미국 기업 중 하나입니다. 

국방, 금융, 제조 등 다양한 산업 분야에서 흩어진 데이터를 한곳에 모아 분석하고 시각화하고, 이를 통해 조직의 빠르고 똑똑한 의사결정을 돕는 AI 소프트웨어 회사입니다.

팔란티어 로고
출처:  Palantir Technologies Inc.

일례로 9.11 테러의 배후로 알려진 오사마 빈 라덴을 추적하는 데에 팔란티어의 데이터 분석이 핵심적인 역할을 했다고 알려져 있습니다.

또 2022년에는 러시아의 우크라이나 침공 당시 우크라이나 측 군사 작전을 지원하며 다시 한번 주목받았죠.

중앙정보국(CIA), 연방수사국(FBI), 국방부 등 미국 핵심 정보기관들의 파트너이자, 최근에는 우리나라의 KT, HD현대와도 손잡고 있는 기업입니다.

팔란티어의 Gotham: 정부 기관과 방위 산업을 위한 실시간 대규모 데이터 분석 플랫폼
출처: 팔란티어 Gotham 소개 사이트

온톨로지란

그런데 팔란티어를 이야기할 때 빼놓을 수 없는 용어가 하나 있습니다. 팔란티어의 제품 설명 어디를 펼쳐도 빠지지 않는 단어, 온톨로지(Ontology). 팔란티어가 강조하는 온톨로지란 무엇일까요?

팔란티어에서는 온톨로지를 다음과 같이 정의합니다. 

통합된 데이터들 위의 의미론적 계층이다.

The Ontology is the digital twin of an organization, a rich semantic layer
that sits on top of the digital assets(datasets and models)

이것만 보면 무슨 말인가 싶을 텐데요, 이 글을 끝까지 읽고 나면 이 정의를 이해하시게 될 겁니다.

온톨로지는 사실 철학에서 온 형이상학적 개념입니다. 그리스어에서 존재를 의미하는 'onto'와 학문을 의미하는 'logia'의 합성어로, 존재의 본질과 구조를 탐구하는 존재론을 의미합니다. 철학자들이 세계를 구성하는 것을 범주화하고, 구분 짓고, 그 관계를 규명하려고 했던 것처럼, 컴퓨터 과학자들은 데이터를 구조화하여 컴퓨터가 이해할 수 있는 형태로 만들고자 했습니다.

예를 들어 이런 문장을 봅시다: "Ingress에서 라우팅 꼬였으면 Helm 차트 다시 배포해."

IT 업계 사람이라면 한 줄로 상황을 이해합니다. "쿠버네티스 환경에서 트래픽 경로가 꼬이면 배포 설정을 다시 적용하라"는 뜻이죠. 하지만 대부분의 사람은 이 문장을 단번에 이해하지 못합니다. 범용 LLM도 마찬가지입니다.

이 지점에서 온톨로지가 빛을 발합니다. 온톨로지는 도메인 데이터를 구성하는 개념과 관계를 구조적으로 매핑해줍니다. 예를 들어, 이렇게 구조적으로 바꿀 수 있죠: "{Ingress: [트래픽 진입점]}에서 {라우팅: [경로 설정]}이 꼬였으면 {Helm: [배포 설정]} 차트를 다시 {배포: [복구 조치]}해"

이렇게 표현하면, 사람도 LLM도 맥락을 훨씬 쉽게 이해할 수 있습니다. 온톨로지는 전문 용어를 맥락과 의미로 연결하여, 해당 도메인의 '언어'를 시스템이 이해할 수 있게 만듭니다.

웹에서 온톨로지를 적용하다: 시맨틱 웹의 도전과 실패

팔란티어 때문에 온톨로지를 처음 들어보신 분들도 많을 겁니다. 그러나 이미 수십 년 전부터 데이터를 의미 단위로 연결하려는 시도는 꾸준히 이어져 왔습니다.

그 대표적인 예가 바로 월드 와이드 웹(WWW)의 창시자, 팀 버너스 리(Tim Berners-Lee)가 제안한 ‘시맨틱 웹(Semantic Web)’입니다. 그는 웹상의 방대한 텍스트를 컴퓨터가 이해할 수 있는 형태로 바꾸기 위해 데이터 간 관계를 일종의 지식망으로 엮고자 했습니다. 즉, 웹의 정보를 ‘의미(Semantic)’ 단위로 표현하여 컴퓨터가 단어 간 관계와 맥락을 파악할 수 있게 하려는 시도였습니다.

예를 들어 기존 웹에서는 “LG전자는 세탁기를 생산한다”라는 문장을 컴퓨터는 단순한 문자열로 인식하지만, 시맨틱 웹에서는 이를 <주어(Subject): LG전자> <술어(Predicate): 생산한다> <목적어(Object): 세탁기> 형태로 구조화하여, ‘기업-제품’ 간의 의미적 관계를 파악할 수 있도록 설계했습니다.

당시에 시맨틱 웹은 혁명적인 시도였습니다. 웹을, 지식을 이해하는 네트워크로 확장하려 했기 때문이죠. 그러나 결국 실패로 돌아갑니다. 웹 전체의 데이터를 사람이 일일이 온톨로지 기반으로 설계하는 것이 현실적으로 불가능했기 때문입니다. 하나의 수정에도 관련된 상위 개념이나 속성, 관계를 모두 수정해야 했죠. 완벽한 세계관을 설계하려던 도전은 현실 데이터의 변화 속도를 따라가지 못했고, 결국 ‘경직성’과 ‘비용’의 벽에 부딪혔습니다.

시맨틱 웹은 실패했지만, 중요한 인사이트를 남겼습니다. 데이터 간 관계를 이해하는 것은 여전히 중요하다는 것이었죠.

온톨로지의 재해석: RAG와 GraphRAG로 이어지다

ChatGPT 등장하고, LLM이 급속도로 발전하면서 기업들은 새로운 고민에 직면했습니다.

"우리 조직에 쌓인 방대한 내부 문서를 LLM과 어떻게 연결할 것인가?"

많은 기업들이 수만 페이지의 매뉴얼, 보고서, 이메일을 보유하고 있었지만, 정작 필요한 정보를 찾아 LLM에 통합하여 업무에 활용하는 데 어려움을 겪고 있었습니다.

이 문제를 해결하기 위해 등장한 것이 바로 RAG(Retrieval-Augmented Generation)입니다. 시맨틱 웹처럼 복잡한 온톨로지를 설계하는 대신, 훨씬 단순한 접근을 택했죠. RAG는 벡터 형태로 변환된 문장 중 사용자의 질문과 의미상으로 가장 가까운 문장을 찾아 LLM에 전달하는 구조입니다. RAG에 대한 자세한 내용은 이 글에서 확인하실 수 있습니다.

그러나 RAG에는 근본적인 한계가 있습니다.

수많은 문서를 응답 생성에 활용하기 위해 문장 단위로 분할하는 '청킹(Chunking)' 과정을 거친 뒤, 임베딩 모델을 통해 벡터 형태로 저장합니다. 이 과정에서 문장의 순서가 무시될 수 있고, 여러 문서에 흩어져 있는 개념 간 논리적 관계가 사라집니다. 따라서 여러 문서에 걸친 개념을 통합해야 하거나, 대용량 데이터의 전체적인 의미를 파악하고 요약하는 작업에서 한계를 보입니다.

왜 이런 한계가 생길까요? 임베딩만으로 유사한 문장을 찾는 건 너무 단순했던 것입니다. 시맨틱 웹이 너무 복잡해서 실패했다면, RAG는 너무 단순해서 중요한 것을 놓쳤습니다. 바로 시맨틱 웹이 중요하게 여겼던 "데이터 간 관계"였죠.

이러한 RAG의 한계를 극복하기 위해 등장한 것이 GraphRAG입니다.

GraphRAG는 지식 그래프 구조에 온톨로지 개념을 결합합니다. 문서 속 개체(Entity)와 관계(Relation)를 추출해 의미 네트워크(Semantic Graph)를 구성하는 것이죠. 시맨틱 웹이 꿈꾸던 '의미적 연결'을 보다 현실적인 규모에서 구현하며 온톨로지가 다시 주목받고 있는 것입니다.

출처: In-depth Analysis of Graph-based RAG in a Unified Framework (Zhou et al., 2025)

그리고 기업들이 실제로 움직이기 시작했습니다. 2024년 마이크로소프트가 GraphRAG를 오픈소스로 공개한 이후, 금융, 의료, 법률 등 복잡한 문서를 다루는 산업에서 GraphRAG 도입이 빠르게 증가하고 있습니다. 특히 법률 회사들은 수만 건의 판례와 법령 간 관계를 파악하는 데, 제약사들은 임상시험 데이터 간 연관성을 찾는 데 GraphRAG를 활용하고 있죠.

출처: Gartner, The 2025 Hype Cycle for GenAI Highlights Critical Innovations(2025.07)

지난 7월, 글로벌 IT 리서치 기업 가트너(Gartner)가 제시한 생성형 AI의 하이프 사이클에서도 GraphRAG가 그 정점에 위치한 것을 볼 수 있습니다. 하이프 사이클은 신기술이 시장에서 받는 기대와 관심의 정도를 나타내는 지표인데요, GraphRAG가 현재 가장 뜨거운 주목을 받고 있다는 뜻입니다.

GraphRAG는 '관계'를 찾는다

GraphRAG의 핵심은 단순히 문장을 벡터로 변환하는 것이 아니라, 문장 속에 숨어있는 개체와 관계를 명시적으로 추출하는 것입니다.

다음과 같은 세 개의 문장이 서로 다른 문서에 흩어져 있다고 가정해봅시다.

1. "삼성전자는 반도체 사업부를 통해 DRAM을 생산한다."
2. "SK하이닉스도 DRAM 시장의 주요 플레이어다."
3. "DRAM 가격이 급등하면서 반도체 기업들의 실적이 개선되었다."

전통적인 RAG는 각 문장을 독립적인 벡터로 변환합니다. "DRAM 시장 점유율은?"이라는 질문이 들어오면 유사도가 높은 문장들을 개별적으로 반환하죠. 하지만 삼성전자와 SK하이닉스가 같은 시장의 경쟁사라는 관계는 파악하지 못합니다.

GraphRAG는 다르게 접근합니다. 문서에서 개체는 노드(Node)로, 관계는 엣지(Edge)로 표현하여 네트워크를 구성합니다.

 

개체(Entity)와 관계(Relation) 개체는 문서에 등장하는 중요한 명사들입니다. 사람, 조직, 제품, 개념 등이 포함됩니다. 관계는 이 개체들이 어떻게 연결되어 있는지를 나타냅니다. 예를 들어 "삼성전자는 반도체를 생산한다"에서 [삼성전자]는 개체, [생산]은 관계, [반도체]는 또 다른 개체입니다.

 

위 예시에서 GraphRAG는 이렇게 정보를 구조화합니다.

GraphRAG는 개체 간 관계를 연결된 네트워크로 구축합니다.
출처: ⓒ deep daiv.

"DRAM 시장 점유율은?"이라는 질문에 대해 [DRAM] 노드부터 시작해 그래프를 탐색하며 연결된 모든 기업(삼성전자, SK하이닉스)과 그들의 관계까지 파악하여 통합적인 답변을 만들어냅니다.

---

GraphRAG는 어떻게 만들어지나?

GraphRAG는 크게 두 단계로 작동합니다. 인덱싱(Indexing) 단계와 쿼리(Query) 단계인데요. 하나씩 살펴보겠습니다.

1단계 인덱싱 단계는 지식 그래프를 구축하는 단계입니다.

먼저 LLM을 활용하여 문서에서 개체와 관계를 추출합니다. 문서를 읽으면서 중요한 명사(개체)와 그들 간의 관계를 파악하는 것이죠.

그다음으로 이렇게 추출된 개체들 중 의미상 연관된 것들을 그룹으로 묶습니다. 이를 커뮤니티 탐지(Community Detection)라고 합니다. 예를 들어 [삼성전자], [SK하이닉스], [DRAM], [반도체 사업부]는 모두 "반도체 산업" 커뮤니티로 묶일 수 있습니다.

그리고 각 커뮤니티에 대해 LLM이 요약문을 생성합니다. 예를 들어 "반도체 산업 커뮤니티: 삼성전자와 SK하이닉스가 DRAM 시장에서 경쟁하고 있으며, DRAM 가격 변동이 이들 기업의 실적에 직접적인 영향을 미친다."처럼 말이죠. 이 과정이 GraphRAG의 핵심입니다. 개별 문장이 아니라 의미상 연결된 정보 덩어리를 미리 파악해 두는 것이죠.

2단계 쿼리 단계는 사용자 질문에 답변하는 단계입니다. 사용자 질문이 들어오면 크게 두 가지 방식으로 답변합니다.

"반도체 산업의 전체적인 동향은?" 같은 포괄적인 질문이 들어오면 Global Search를 합니다. 관련 커뮤니티들을 모두 찾아서 각 커뮤니티의 요약문들을 종합하여 전체적인 맥락을 보고 답변합니다.

"삼성전자의 DRAM 생산 현황은?" 같은 구체적인 질문에는 Local Search를 합니다. 특정 개체(삼성전자)를 찾고, 그래프에서 이 개체와 연결된 관계를 탐색합니다. 1-hop은 하나의 엣지로 바로 연결된 개체, 2-hop은 한 다리 두 개의 엣지를 건너 연결된 개체를 의미합니다. 이런 식으로 점점 범위를 넓혀가며 관련 정보를 수집하여 답변합니다.

"이 문서들에서 가장 많이 언급된 주제 5가지는?", "서로 다른 부서 간의 협업 관계를 설명해 줘", "이 프로젝트에 관련된 모든 이해관계자를 찾아 줘" 이런 질문들은 개별 문장의 유사도로는 답할 수 없고, 전체 데이터의 구조와 관계를 파악해야 합니다. 마이크로소프트의 벤치마크에 따르면, GraphRAG는 특히 이처럼 전체 데이터셋을 이해해야 하는 질문에서 전통적 RAG 대비 월등한 성능을 보였습니다.

Neo4j로 구축한 지식 그래프
출처: Neo4j Blog, <What Is GraphRAG?> (Michael Hunger, 2024)

이렇게 보면 GraphRAG 구축하는 일도 만만치 않아 보입니다. 그러나 다행히도 문서를 분석하고, 개체와 관계를 추출하고, 그래프를 구축하는 일련의 과정을 쉽게 구축할 수 있도록 도와주는 도구들이 있습니다. 마이크로소프트에서 공개한 GraphRAG 라이브러리에서는 문서만 입력하면 개체 추출부터 커뮤니티 탐지, 요약까지 자동으로 처리합니다. 이 외에도 LlamaIndex나 LangChain 같은 RAG 구축 프레임워크에도 GraphRAG 기능이 내장되어 있습니다. Neo4j 같은 그래프 데이터베이스와 연동하면 구축된 그래프를 시각화해서 볼 수도 있죠. 물론, 팔란티어처럼 복잡한 도메인 데이터를 다루는 수준의 시스템을 만들려면 훨씬 더 많은 엔지니어링이 필요합니다.

팔란티어의 핵심: 도메인 특화 온톨로지

팔란티어가 온톨로지 개념을 내세우며 성장할 수 있었던 이유는 이들은 누구보다 도메인 특화 전략에 치밀했기 때문입니다.

도메인이 달라지면, 같은 단어도 그 뜻이 다르게 사용됩니다. ‘포지션(Position)’은 금융에서는 투자 비중(보유 자산의 방향성)을, 국방에서는 병력 배치를 의미합니다. 그래서 팔란티어는 국방, 보안, 정부 기관처럼 외부 반출이 불가능하고 복잡한 도메인 데이터 환경에서 압도적인 성능을 발휘할 수 있었습니다.

시맨틱 웹의 실패로 한때 온톨로지는 잊혔지만, 팔란티어는 이 오래된 개념을 가장 팔란티어다운 방식으로 되살렸습니다. 팔란티어는 CIA, 국방부, 금융사처럼 외부 반출이 불가능하고 전문 용어로 가득한 도메인에 집중했습니다. 그리고 그 안에 온톨로지를 깊이 결합해, 범용 AI로는 이해할 수 없는 조직의 언어와 논리를 시스템 속에 내재화했습니다.

GraphRAG가 기술 업계의 화두가 되면서 온톨로지와 지식 그래프가 다시 주목받고 있습니다. 그러나 도메인 지식을 시스템화하기 위해서는 굉장히 많은 시간과 전문성이 필요합니다.

팔란티어는 지난 20년간 국방, 보안, 금융 각 분야의 전문 용어, 업무 프로세스, 의사결정 구조를 하나하나 시스템에 새겨 넣었습니다. 결국 팔란티어는 '특정 조직의 복잡한 내부 데이터'라는 스위트 스팟을 선점하며 경쟁력 있는 위치를 차지할 수 있었던 것입니다.