Knowledge Graph: 팔란티어 Ontology의 심장
Ontology가 왜 '그래프'여야 했는지, 그 아래의 데이터 구조를 해부합니다
카카오 내비에는 없는 것
카카오 내비를 열면 출발지에서 도착지까지 최적 경로를 알려줍니다. 도로와 도로가 연결되어 있고, 실시간 교통량도 반영합니다.
그런데 이런 질문에는 답하지 못합니다: "이 도로가 공사 중인데, 공사를 발주한 건설사가 동시에 공사하는 다른 도로는 어디야? 그 도로를 우회하면 물류 트럭이 몰릴 텐데, 그 트럭들이 배달하는 창고 근처에 내 공장이 있나?"
점(장소)과 점을 잇는 선(도로)은 있지만, "그 선 위를 지나가는 트럭이 어떤 회사 소속이고, 그 회사가 어떤 원자재를 운반하고, 그 원자재가 어디서 생산되는지"까지는 모릅니다.
이것이 일반 데이터베이스와 Knowledge Graph의 차이입니다. 네비게이션은 "A에서 B까지 어떻게 가?"에 답합니다. Knowledge Graph는 "A와 B 사이에 보이지 않는 관계가 몇 겹으로 존재하는가?"에 답합니다.
점(장소)과 선(도로)을 안다
질문: "A에서 B까지 어떻게 가?"
관계: 1단계 (직접 연결만)
행동: 길 안내만 제공
점, 선, 그리고 관계의 관계를 안다
질문: "A와 B 사이에 숨겨진 연결은?"
관계: N단계 (3~5홉 깊이)
행동: 분석, 추론, 실행까지
팔란티어의 Ontology는 이런 Knowledge Graph입니다. 그것도, 보기만 하는 것이 아니라 "저 트럭 경로를 바꿔"라고 실행까지 할 수 있는 Knowledge Graph.
Ontology 완전 해설에서 우리는 Object, Link, Action, Workflow라는 5가지 빌딩블록을 살펴봤습니다. 이번 글에서는 한 층 더 내려가, 이 빌딩블록들이 왜 "그래프"라는 형태여야 했는지를 봅니다.
1. Knowledge Graph란 무엇인가
Knowledge Graph를 이해하려면, 먼저 "그래프"라는 데이터 구조가 왜 특별한지부터 봐야 합니다. 엑셀의 행과 열로 정리된 세상에 익숙한 우리에게, 그래프는 전혀 다른 사고방식을 요구합니다.
1.1 그래프의 기본: 노드, 엣지, 속성
그래프는 두 가지 요소로 구성됩니다. 노드(Node)는 "무엇"이고, 엣지(Edge)는 "어떤 관계"입니다. "엔비디아는 SK하이닉스에 HBM을 주문한다"를 그래프로 표현하면:
Subject
Object
Subject(주어) + Predicate(술어) + Object(목적어) = 1개의 트리플
이것이 그래프의 최소 단위인 "트리플(Triple)"입니다. 모든 Knowledge Graph는 이 트리플의 집합입니다. 수십억 개의 트리플이 모이면, 세상의 관계를 담은 거대한 그물이 됩니다.
그래프를 구현하는 방식은 크게 두 가지입니다.
출처: W3C RDF 1.2 Specification, Neo4j Graph DB Concepts
팔란티어의 Ontology는 Property Graph에 가깝습니다. Object에 속성(Property)을 직접 붙이고, Link로 관계를 정의하는 구조가 그렇습니다. 하지만 여기에 Action과 Workflow라는 "실행 레이어"를 얹은 것이 결정적 차이입니다.
1.2 Knowledge Graph vs 일반 그래프 DB
Neo4j 같은 그래프 데이터베이스는 "관계를 저장"합니다. Knowledge Graph는 여기에 "의미(semantics)"와 "추론(inference)"을 더합니다.
✅ 구조 저장 (노드 + 엣지)
✅ 빠른 순회 (traversal)
❌ 의미 해석 없음
❌ 자동 추론 없음
✅ 구조 저장
✅ 빠른 순회
✅ 시맨틱 스키마 (의미 정의)
✅ 규칙 기반 추론
구글 검색창에 "아이폰"을 치면 오른쪽에 뜨는 정보 패널. 이것이 Google Knowledge Graph(2012년 론칭, 초기 5.7억 엔티티, 현재 550억+ 엔티티 추정)입니다. 단순 검색이 아니라 "아이폰은 Apple이 만들고, Apple의 CEO는 팀 쿡이고, 팀 쿡은 듀크 대학을 졸업했다"는 관계 체인을 이해합니다. (Google Blog)
Wikidata(1.2억+ 항목), DBpedia(2.3억+ 엔티티, 13억+ 트리플) 같은 공개 KG도 같은 원리입니다. 이들은 "세상의 지식을 관계로 정리"하는 인프라입니다. (Wikidata Statistics)
1.3 왜 지금 다시 주목받는가: LLM과의 만남
Knowledge Graph는 1990년대 시맨틱 웹에서 시작된 기술입니다. 한동안 학술계에 머물렀지만, LLM의 등장으로 다시 주목받고 있습니다. 이유는 단순합니다: LLM은 환각(hallucination)합니다.
LLM이 "SK하이닉스의 HBM4 양산 시점은?"이라는 질문에 그럴듯하지만 틀린 답을 하는 이유는, 구조화된 팩트 기반이 아니라 학습 텍스트의 패턴으로 답하기 때문입니다. KG는 이 문제의 해답이 됩니다. 구조화된 팩트를 LLM에 제공하면, 환각이 줄어듭니다.
학술계에서는 LLM과 KG의 결합을 3가지 패턴으로 분류합니다.
KG가 LLM에
맥락 제공
LLM이 KG
자동 구축
양방향 순환
강화
출처: Pan et al., "Unifying Large Language Models and Knowledge Graphs: A Roadmap" (2023)
팔란티어의 AIP는 세 번째 패턴(Synergized)의 대표적 상용 구현체입니다. Ontology(=KG)가 LLM에 구조화된 맥락을 제공하고, LLM이 자연어를 Ontology 쿼리로 변환합니다. 이것이 "AIP가 Ontology 위에서 작동한다"는 말의 기술적 의미입니다.
2. Ontology는 Knowledge Graph다
Ontology 완전 해설에서 5가지 빌딩블록을 소개했을 때, 의도적으로 생략한 것이 하나 있습니다. 이 빌딩블록들이 왜 "그래프"라는 데이터 구조 위에 존재하는지, 그 이유였습니다.
2.1 "실행할 수 있는 Knowledge Graph"
Ontology의 빌딩블록을 Knowledge Graph 용어로 매핑하면, 관계가 즉시 드러납니다.
보라색 3개(Object, Link, Property)는 일반 Knowledge Graph에도 있습니다. Neo4j도 노드, 엣지, 속성을 지원합니다.
노란색 3개(Action, Workflow, Function)가 결정적 차이입니다. 일반 KG는 읽기 전용입니다. "이 관계가 존재한다"를 조회할 수 있지만, "이 관계를 바탕으로 무언가를 실행하라"는 불가능합니다. Ontology는 읽기와 쓰기, 그리고 실행까지 하나의 그래프 위에서 수행합니다.
💡 핵심: 읽기 전용 그래프 vs 실행 가능한 그래프
Neo4j에서 "패혈증 위험 환자"를 조회하면 목록을 얻습니다. Ontology에서 같은 조회를 하면 목록을 얻고, 동시에 "담당 의사에게 알림 전송 + 프로토콜 자동 실행"까지 이어집니다. 그래프를 "읽는" 것에서 그래프 위에서 "행동하는" 것으로의 전환. 이것이 Ontology의 본질입니다.
2.2 3층 아키텍처의 그래프적 해석
Ontology의 3층 아키텍처(Semantic, Kinetic, Dynamic)는 온톨로지 학술 용어와 정확히 대응합니다.
출처: Understanding Palantir's Ontology Layers (Medium), Palantir Architecture Center
최하단의 Semantic Layer는 "어떤 종류의 노드와 엣지가 존재하는가"를 정의합니다. 온톨로지 학술 용어로는 TBox(Terminological Box)입니다. 예를 들어 "환자"라는 Object Type을 정의하고, "환자는 검사결과와 연결된다"는 Link Type을 선언합니다.
중간의 Kinetic Layer는 실제 데이터를 그 스키마에 채워넣습니다. ABox(Assertion Box)에 해당합니다. "환자 #12345 = 김철수, 58세"라는 구체적 인스턴스가 여기에 놓입니다.
최상단의 Dynamic Layer는 비즈니스 규칙과 권한을 관장합니다. RBox(Rule Box)에 해당합니다. "검사 결과가 임계값을 초과하면 담당의에게 자동 알림"같은 규칙이 여기에 정의됩니다.
일반 Knowledge Graph에는 TBox와 ABox만 있습니다. RBox, 즉 "규칙을 정의하고 실행하는 레이어"가 팔란티어만의 차별점입니다.
2.3 하나의 Object, 수백 개의 Edge
BP 디지털 트윈 사례에서 본 것처럼, 하나의 "유정(Oil Well)" Object는 센서(200만+), 작업자, 장비, 지질 데이터, 유지보수 이력 등 수백 개의 엣지로 연결됩니다. 관계형 데이터베이스에서 이런 데이터를 표현하려면 수십 개의 테이블과 복잡한 JOIN이 필요합니다. 그래프에서는 하나의 노드에서 엣지를 따라가면 됩니다.
그래프 밀도와 비선형 가치 증가
그래프의 가치는 노드 수가 아니라 엣지 밀도로 결정됩니다. 노드 N개가 있을 때, 이론적으로 가능한 엣지 수는 N(N-1)/2입니다. 하지만 모든 노드가 모든 노드와 연결되는 것은 무의미합니다. 의미 있는 엣지만이 가치를 만들고, 이 의미 있는 엣지를 정의하는 것이 도메인 전문가(FDE)의 역할입니다.
그래프 밀도가 높아질수록 전환 비용은 지수적으로 증가합니다. 노드 100개에 엣지 50개인 그래프는 복제 가능합니다. 노드 100만 개에 의미 있는 엣지 500만 개, 그 위에 5,000개의 Action과 200개의 Workflow가 올라간 그래프는 복제 불가능합니다. 이것이 Ontology가 시간이 지날수록 강해지는 구조적 이유입니다.
💡 핵심: 그래프 밀도 = 해자의 깊이
Ontology의 해자는 소프트웨어 코드가 아닙니다. 고객 조직 내부에 5~10년간 축적된 노드, 엣지, Action, Workflow의 총합입니다. 그래프가 밀도를 더할수록 전환 비용은 기하급수적으로 증가하고, NDR 150%라는 수치가 그 증거입니다.
3. 그래프가 만드는 차이: 3가지 능력
"왜 굳이 그래프여야 하는가?" 관계형 데이터베이스(RDBMS)도 테이블 간 JOIN으로 관계를 표현할 수 있습니다. 그래프가 만드는 결정적 차이 3가지를 봅니다.
3.1 Multi-hop Reasoning: 3단계 떨어진 원인 찾기
Tampa General Hospital의 패혈증 조기 경보 시스템을 예로 들어봅니다. "이 환자가 패혈증 위험군인가?"를 판단하려면, 환자 → 최근 검사결과 → 해당 검사와 상호작용하는 약물 → 환자의 알레르기 이력까지 3단계의 관계를 추적해야 합니다.
SELECT p.name
FROM patients p
JOIN test_results t
ON p.id = t.patient_id
JOIN drug_interactions d
ON t.test_type = d.test_type
JOIN allergies a
ON p.id = a.patient_id
AND d.drug = a.allergen
WHERE t.value > threshold;
MATCH
(p:Patient)
-[:HAS_RESULT]->(t:Test)
-[:INTERACTS]->(d:Drug)
<-[:ALLERGIC_TO]-(p)
WHERE t.value > threshold
RETURN p.name;
코드의 길이 차이가 본질은 아닙니다. 본질은 성능입니다.
쿼리 성능: JOIN vs Traversal
관계형 데이터베이스에서 JOIN의 비용은 관계의 깊이가 늘어날수록 지수적으로 증가합니다. Neo4j의 벤치마크에 따르면, 100만 노드(인당 50개 관계) 소셜 네트워크에서 4-hop 탐색 시 그래프 DB가 RDBMS 대비 1,000배 빠릅니다. 5-hop에서는 격차가 더 벌어집니다. (Neo4j)
출처: 주: 개념적 비교. 100만 노드, 인당 50관계 기준. 4-hop에서 약 1,000배 차이. 출처: Neo4j RDBMS vs Graph Performance
주: 개념적 비교. 100만 노드, 인당 50관계 기준. 4-hop에서 약 1,000배 차이. 출처: Neo4j RDBMS vs Graph Performance
3.2 Schema Evolution: 깨지지 않는 변화
엔터프라이즈 소프트웨어에서 가장 두려운 단어 중 하나는 "스키마 마이그레이션"입니다. 관계형 데이터베이스에서 테이블 구조를 바꾸면, 그 테이블을 참조하는 모든 쿼리, 모든 애플리케이션, 모든 리포트가 깨질 수 있습니다.
마이그레이션 계획 수립에 2~4주 소요
의존 쿼리 전수 검사에 1~2주 추가
서비스 중단 후 마이그레이션 실행 (다운타임)
실패 시 롤백 절차 필요 (리스크)
새 노드/엣지 타입을 즉시 추가
기존 그래프 불변, 다운타임 없음
새 타입을 기존 노드에 점진적 연결
추가만 했으므로 롤백 불필요
팔란티어의 가장 오래된 특허(US7962495B2, 2006년 출원)가 정확히 이 문제를 다룹니다. 특허 명칭은 "Creating data in a data store using a dynamic ontology"이며, 핵심 주장은 이렇습니다: "전통적 관계형 데이터베이스에서 온톨로지 변경은 매우 파괴적(very disruptive)이다." 이 특허가 해결한 것이 바로 "깨지지 않는 스키마 변화"입니다. (Google Patents)
3.3 Contextual AI: 맥락을 아는 에이전트
같은 질문 "우리 회사 매출이 왜 떨어졌어?"에 대해, LLM만 사용하는 경우와 KG 위에서 LLM이 작동하는 경우의 차이를 봅니다.
"일반적으로 매출 하락의 원인은 계절적 요인, 경쟁 심화, 거시 경제 둔화 등이 있습니다..."
→ 일반론. 우리 회사에 대해 아무것도 모른다
"3분기 매출 하락의 주 원인은 APAC 지역 공급업체 B의 납기 지연(평균 +12일)으로, 완제품 출하가 23% 감소한 것입니다."
→ 구체적 원인 체인. 그래프 순회 결과
AIP의 힘은 LLM의 언어 능력이 아닙니다. LLM이 Ontology(Knowledge Graph)라는 구조화된 세계 위에서 작동한다는 것. "무엇을 물어봐야 하는지"를 LLM이 결정하고, "어디서 답을 찾아야 하는지"를 그래프가 안내하고, "답을 찾으면 무엇을 해야 하는지"를 Action이 실행합니다.
4. 경쟁자의 그래프
Knowledge Graph 기술은 팔란티어만의 전유물이 아닙니다. 하지만 같은 "그래프"라는 단어를 쓰면서도, 기능의 깊이는 크게 다릅니다.
4.1 Neo4j: 순수 그래프의 강점과 한계
Neo4j는 그래프 데이터베이스 시장의 선두주자입니다. 2007년 설립, 총 $631M 자금을 조달했고(밸류에이션 $2B), Fortune 100 기업 중 84%가 고객입니다. ARR $200M+을 돌파하며 Nasdaq IPO를 준비하고 있습니다. Cypher라는 선언적 쿼리 언어를 만들었고, 이것이 ISO 표준 GQL의 기반이 되었습니다. (Neo4j)
2024년에는 LLM Knowledge Graph Builder를 출시하여, LLM이 비정형 텍스트에서 자동으로 노드와 엣지를 추출하는 GraphRAG 파이프라인을 제공합니다. OpenAI, Anthropic Claude, Google Gemini, Meta Llama 등 주요 LLM을 지원합니다.
NASA(지식 그래프로 $2M+ 절감), UBS(Basel 규제 준수), Walmart(공급망 최적화) 등이 고객 사례입니다. 하지만 Neo4j는 본질적으로 "데이터를 저장하고 조회하는 도구"입니다. Action(실행), Workflow(자동화), 세밀한 권한 관리 같은 운영 레이어가 없습니다.
4.2 LinkedIn DataHub + Apache Atlas
LinkedIn DataHub(GitHub Stars 11.9k+, 80+ 데이터 커넥터)와 Apache Atlas는 메타데이터 관리 도구입니다. 데이터가 어디서 왔고, 어떻게 변환되었고, 누가 접근할 수 있는지를 추적합니다. 이것도 그래프 구조이지만, "관찰(observe)"하는 레이어에 머뭅니다. DataHub에 Actions Framework가 있기는 하지만, 소스 시스템에 write-back하는 기능은 지원하지 않습니다. Atlas는 네이티브 액션 자체가 없습니다.
4.3 Microsoft Fabric IQ: 같은 이름, 다른 성숙도
가장 주목해야 할 경쟁자는 Microsoft입니다. 2025년 Ignite에서 Fabric IQ Ontology를 Preview로 발표했습니다. 엔티티 타입, 속성, 관계를 정의하고 OneLake의 데이터 자산에 바인딩하는 구조입니다. "Ontology"라는 같은 이름을 사용합니다.
흥미로운 점은, Fabric IQ가 단순한 시맨틱 레이어를 넘어서 Action(Fabric Activator 연동)과 Workflow(Rules)까지 지원한다는 것입니다. 조건 충족 시 알림, 알람, 자동화 트리거가 가능합니다. 또한 NL2Ontology(자연어 쿼리), Plan(승인 워크플로우 포함 writeback), MCP 엔드포인트(에이전트 생태계 노출) 로드맵도 발표되었습니다. (Fabric Blog)
다만 여전히 Preview 상태이며, 팔란티어가 20년간 국방, 의료, 에너지 등 미션크리티컬 환경에서 검증한 깊이와는 격차가 있습니다. 팔란티어의 Ontology에는 오브젝트 타입당 최대 2,000개 속성, ACID 트랜잭션, 에어갭 배포, 3,438개 특허 포트폴리오(그 중 370개가 온톨로지 관련)라는 20년 축적이 있습니다.
| 기능 | Palantir Ontology | Neo4j | DataHub /Atlas | Fabric IQ (Preview) |
|---|---|---|---|---|
| 그래프 네이티브 저장 | ✅ | ✅ | 부분 | ❌ |
| 시맨틱 스키마 (TBox) | ✅ | 부분 | ✅ | ✅ |
| 규칙 기반 추론 (RBox) | ✅ | ❌ | ❌ | 부분 |
| Action / Write-back | ✅ | ❌ | ❌ | 부분 (Activator) |
| Workflow 자동화 | ✅ | ❌ | ❌ | 부분 (Rules) |
| LLM 통합 (GenAI) | ✅ (AIP) | ✅ (GraphRAG) | 부분 | ✅ (Copilot) |
| 에어갭 배포 (국방) | ✅ | ✅ | ❌ | ❌ |
| 성숙도 | 20년 GA | 18년 GA | 6년+ GA | Preview |
출처: 각 공식 문서 및 제품 페이지 기준. 2026년 5월 기준.
⚠️ Fabric IQ가 GA되고 깊이를 더하면?
Fabric IQ는 이미 Action(Activator)과 Workflow(Rules) 기능을 Preview로 제공하고 있습니다. Azure OpenAI + Teams + Power Automate 생태계와 결합되면, 일반 엔터프라이즈 시장에서 팔란티어의 가장 직접적인 위협이 될 수 있습니다. 현재는 Preview 상태이며 실전 검증이 부족하지만, Microsoft의 실행력과 기존 고객 기반을 고려하면 격차가 메워지는 속도를 지속적으로 모니터링해야 합니다. 다만, 국방/미션크리티컬 영역에서는 인증 격차와 에어갭 배포 부재로 단기 위협은 낮습니다.
5. LLM이 Knowledge Graph를 대체할 수 있는가
Ontology 완전 해설 6.2절에서 "LLM 자동 스키마 추론"을 위협으로 분류했습니다. 여기서는 이 위협을 KG 관점에서 더 깊이 분석합니다.
5.1 LLM이 KG를 자동 구축하는 현재 수준
LLM이 비정형 텍스트에서 Knowledge Graph를 자동으로 구축하는 기술은 빠르게 발전하고 있습니다. 2025년 기준 벤치마크를 보겠습니다.
출처: 출처: arXiv: LLM-Powered Knowledge Graphs for Enterprise (2025.03), REBEL 벤치마크 기준. 환각율 6~25%를 역산한 환각 없는 정확도.
출처: arXiv: LLM-Powered Knowledge Graphs for Enterprise (2025.03), REBEL 벤치마크 기준. 환각율 6~25%를 역산한 "환각 없는 정확도".
엔티티(노드) 추출은 Precision 89.7%, Recall 92.3% 수준입니다. "엔비디아", "SK하이닉스" 같은 고유명사를 텍스트에서 뽑아내는 것은 LLM이 잘합니다.
하지만 관계(엣지) 추출은 Macro-F1 65% 수준입니다. "엔비디아가 SK하이닉스에 HBM을 주문한다"는 관계를 정확히 추출하는 것은 훨씬 어렵습니다. 학습하지 않은 도메인(크로스도메인)에서는 성능이 45%까지 떨어집니다. 환각율은 도메인과 모델에 따라 6~25% 범위입니다.
일반 비즈니스 문서 분석에서는 충분할 수 있습니다. 하지만 의료, 군사, 항공처럼 오류가 인명 피해로 직결되는 도메인에서는, 25%의 환각율은 허용되지 않습니다.
한편, Diffbot(100억+ 엔티티, 1조+ 팩트 규모)이나 Neo4j의 LLM Knowledge Graph Builder 같은 상용 도구도 등장하고 있어, KG 자동 구축의 비용과 난이도는 빠르게 낮아지고 있습니다.
5.2 구조적 한계: "만드는 것"과 "실행하는 것"
LLM이 대체할 수 있는 것과 대체할 수 없는 것을 구분해야 합니다.
최하단의 Semantic Layer(스키마 정의)는 LLM이 상당 부분 자동화할 수 있습니다. 비정형 문서에서 Object Type과 Link Type을 추론하는 것은 LLM의 강점입니다.
하지만 최상단의 Action/Workflow Layer는 LLM이 대체할 수 없습니다. "패혈증 위험 환자를 찾으면, 담당의에게 알림을 보내고, 프로토콜을 자동 실행하고, 실행 이력을 감사 로그에 남겨라"는 비즈니스 규칙은 자연어로 추론되는 것이 아니라, 도메인 전문가가 정의하고 검증하는 것입니다.
팔란티어의 진짜 해자는 "그래프 구조" 자체가 아닙니다. 그래프 위에 올라간 실행 레이어, 그리고 20년간 미션크리티컬 환경에서 검증된 그 실행 레이어의 신뢰성입니다.
5.3 LLM + KG = 공생
결론적으로, LLM과 KG의 관계는 "대체"가 아니라 "공생"입니다. 팔란티어의 AIP가 정확히 이 공생 모델의 상용 구현체입니다.
흥미로운 점은, LLM이 KG 구축을 가속하면 팔란티어에게도 기회가 된다는 것입니다. 현재 Ontology 구축에 가장 큰 병목은 FDE(Forward Deployed Engineer)의 인건비입니다. LLM이 스키마 초안을 자동 생성하면, FDE는 "처음부터 만드는 사람"에서 "LLM의 초안을 검증하고 다듬는 사람"으로 역할이 바뀝니다. 구축 기간이 단축되면 더 많은 고객을 더 빠르게 온보딩할 수 있습니다.
6. 투자자가 봐야 할 것: 그래프의 깊이
6.1 Object Type 수 x Link Density = Ontology의 가치
Ontology의 가치를 정량화할 수 있는 프레임워크는 이렇습니다: 고객이 정의한 Object Type이 많을수록, 각 Object 간 Link가 촘촘할수록, 그 위에 올라간 Action과 Workflow가 많을수록, 전환 비용은 기하급수적으로 증가합니다.
이 세 지표의 곱이 커질수록, 전환 비용은 비선형적으로 증가합니다. 그리고 이것이 NDR 150%를 방어하는 구조적 메커니즘입니다.
6.2 모니터링 지표: 그래프가 성장하고 있는가
팔란티어는 Ontology의 내부 지표(Object Type 수, Link 밀도 등)를 공개하지 않습니다. 하지만 IR 자료에서 확인 가능한 프록시 지표가 있습니다.
이 지표들이 분기마다 증가하고 있다면, Ontology라는 Knowledge Graph는 계속 밀도를 더하고 있고, 해자는 깊어지고 있는 것입니다.
- Knowledge Graph는 관계의 구조화. Ontology는 그 위에 실행 레이어(Action/Workflow)를 올린 것
- LLM은 KG를 대체하지 않는다. KG 위에서 더 강해진다. AIP가 정확히 이 공생 모델
- Neo4j는 "읽는 도구". Ontology는 "실행하는 도구". 경쟁의 축이 다르다
- Fabric IQ가 빠르게 추격 중이지만, 20년 축적의 성숙도 격차는 단기간에 메울 수 없다
- 그래프 밀도(Object x Link x Action)가 곧 해자의 깊이. NDR 150%가 그 증거