기업, 정부 등 거의 모든 조직들이 LLM, Gen AI 도입에 여전히 열을 올리고 있습니다. 이제는 AI agent 로 향해가고 있죠. 그 중 가장 먼저 널리 채택된 방식은 단연 RAG(Retrieval-Augmented Generation)였습니다. RAG는 LLM의 치명적인 약점인 환각(Hallucination)을 줄여주고, LLM 트레이닝+ 추론 비용도 줄여주는, 조직 내부의 최신 데이터를 참조하게 하는 가장 현실적이고 비용 효율적인 전략으로 각광을 받았습니다.
그런데, 대부분의 조직들을 RAG를 도입한 지 1년도 채 되지 않아, 한계에 직면했습니다. RAG는 본질적으로 ‘단순한 오픈북 테스트’에 불과하다는 지적이 나왔죠. 아무리 많은 문서를 참조하게 해도, “두 문서 사이의 숨겨진 관계는?” “이 현상의 근본적인 원인은?”과 같은 복잡한 ‘추론’ 질문에는 답하지 못했습니다. 표준 RAG 는 어떻게 보면 “다소 멍청한 부지런한 검색기”에 불과했던 것입니다.
이 지점에서 AI의 초창기부터 존재했던 ‘이상적 기술’이자 한때 ‘실패한 유산’ 으료 여겨졌던 온톨로지(Ontology)가 화려하게 귀환했습니다. 과거에 온톨로지는 ‘완벽한 지식’ 을 구축하려다 ‘경직성’과 ‘비용’의 덫에 빠져 완전히 외면받았는데, 팔란티어 덕분에 ‘왕의 귀환(?)’을 하게 된것입니다.
여기에 RAG가 결합합니다. 팔란티어의 온톨로지와 RAG의 유연성이 결합하게 되기도 했습니다. RAG의 유연성, LLM의 추론능력, 온톨로지의 구조적 힘이 결합하면서, AI 전략은 다분화 하게 됩니다. 단순한 기술 스택의 차이라기 보다는 조직이 AI를 ‘정보 검색기’로 쓸 것인지, ‘전략적 추론 엔진’ 으로 쓸 것인지, 아니면 ‘운영체제(OS)’로 삼을 것인지를.
그래서, 온톨로지와 RAG에 대해 좀더 상세히 정리해봤습니다. (잘 아시는 분들은 패스~)
1) 온톨로지에 대한 오해
흔히, 온톨로지를 ‘지식 그래프(Knowledge)’와 동일시 하거나, 팔란티어의 독창적 기술로 오해하지만, 온톨로지는 ‘개념, 속성, 관계를 정의하는 규칙(스키마)’이고, 지식 그래프는 그 규칙에 따라 데이터를 채워 넣은 ‘결과물’입니다.
전통적 온톨로지(Heavy OAG)는 학술적, 철학적 이상에 가까웠습니다. 고대 그리스 시절부터 나온 개념입니다. 온톨로지의 어원은 그리스어 on(존재)와 logos(학문)에서 유래합니다. 전문가들은 세상의 모든 ‘개념(Entity)’과 ‘관계(Relation)’를 미리 정의하는 ‘완벽한 세계관’을 설계하려 했죠.
예를 들어, 도시를 짓기 전에, 모든 도로, 건물, 상하수도관이 포함된 ‘완벽한 도시설계도’를 그리는 것입니다. 모든 관계를 정의하고, 이 ‘스키마’라는 틀에 데이터를 주입하는 것입니다. 이 방식의 가장 큰 문제는 ‘변경’ 이었습니다 .만약 갑자기 생각지 않았던, 송전로가, 가스관이 생기거나, ‘연결한다’ 라는 개념이외에 ‘공급한다’
또는 ‘흐른다’ 와 같은 새로운 ‘관계’가 필요해진다면 어떻게 될까요?
이미 완성된 ‘완벽한 도시설계도(온톨로지 스키마)’ 자체를 뜯어고쳐야 했습니다. 이는 기존의 모든 도로와 건물의 설계를 다시 검토하는 것과 같은 막대한 비용과 시간을 요구했습니다. 이 ‘경직성’ 때문에 현실 세계의 역동성을 따라잡지 못해 결국 ‘실패한 기술’로 사장되었습니다.
2) 팔란티어 온톨로지(AIP)의 등장
팔란티어는 바로 이 ‘경직성’ 문제를 완전히 다른 방식으로 해결했습니다. 팔란티어는 온톨로지를 ‘고정된 지식 지도’가 아니라, AI 운영체제(OS)로 재정의한 것입니다.
팔란티어는 Heavy OAG(온톨로지)를 두 파트로 분리했습니다.
1단계 (Heavy Part) : 전통적인 Heavy OAG 를 AI 운영체제(OS)의 커널로 사용하는데요, 이 ‘코어 온톨로지’는 조직의 모든 데이터를 연결하는 안정적이고 견고한 기반이 됩니다. (당연히 여전히 무겁고 매우 비싼…)
2단계 (Flexible Part) : 그 커널 위에 유연한 앱(API Logic) 레이어를 올립니다. 바로 Operation 계층입니다. Window OS 에 이거저거 앱을 많이 까는 개념과 유사하죠.
예를 들어 ‘AI 데이터 주권법’ 이 신설되면, 전통 OAG 에서는 ‘데이터’객체에 ‘국외 반출 금지’ 속성을 추가하기 위해, 온토롤지 설계도 자체를 다 뜯어고치는 재설계 프로젝트를 시작해야 했는데,
팔란티어 AIP 에서는 데이터는 건드리지 않습니다. 그냥 ‘개인정보’가 포함된 ‘데이터’ 객체가 ‘국외서버’로 전송되려 하면, 즉시 차단하고 경고하는 새로운 규칙 앱(AIP Logic)을 하나 설치하면 끝나는겁니다.
결론적으로, 팔란티어는 ‘Heavy OAG’를 버린 것이 아니라, ‘Heavy OAG’를 핵심 기반(OS)으로 삼되, 그 치명적인 약점이었던 ‘경직성’을 ‘유연한 앱’ 레이어로 해결한 것입니다. 그러다보니, 경직성을 해결됐는데, 더더 비싸졌죠. 가장 강력하지만, 가장 비싸고, 팔란티어꺼 한번 쓰면 평생 써야하는(?) life-time Lock-in을 요구하는 전략이 되버린 것입니다.
3) RAG 에 얇은’ 온톨로지 추가
그런데, 다들 아시는것처럼 모두가 팔란티어처럼 막대한 비용을 들여 ‘AI OS’를 구축할수 없습니다. 팔란티어에 호구잡히기도 너무 좋은 구조고(빠져나올수 없는..), 비용도 너무 막대하기 때문입니다. 그래서, 가성지 좋은 RAG에서 출발해, RAG의 약점인 ‘추론’ 능력을 최소한의 비용으로 보완하는거죠. 이게 바로 ‘얇은’ 온톨로지 레이저(Thin OAG), 즉, Graph RAG 입니다.
다 아시는것처럼, 팔란티어도 당연히 RAG를 씁니다. 하지만 팔란티어가 RAG를 쓰는 방식은 우리가 말하는 ‘가성비’ 접근과는 근본이 다릅니다. 팔란티어에게 RAG는 거대하고 무거운 ‘코어 온톨로지(AI OS)’에 비정형 데이터를 ‘주입(Ingest)’하는 여러 파이프라인 중 하나일 뿐입니다. RAG가 읽어들인 PDF나 이메일조차 결국엔 자신들이 미리 설계한 ‘Heavy OAG’의 틀 안에 매핑되어야 합니다.
바로 이지점에서 GraphRAG 와의 차이점이 드러납니다.
– 팔란티어 : ‘선(先) 온톨로지 구축, 후(後) RAG 연결’의 무겁고 경직된 Top-down 방식
– GraphRAG : ‘선(先) RAG 구축, 후(後) Graph 연결’의 가볍고 유연한 Bottom-up 방식
GraphRAG는 처음부터 완벽한 ‘도시설계도(Heavy OAG)’를 만들지 않는 대신, 일단 표준 RAG(벡터 DB)로 시작해, 당장 필요한 ‘정보 검색(Q&A)’ 문제를 가장 저렴하고 빠르게 해결합니다.
그리고 LLM을 활용해, RAG가 이미 읽어들인 그 문서들 안에서 ‘개체(Entity)’와 ‘관계(Relation)’를 동적으로, 그리고 ‘얇게’ 추출해서 별도의 그래프 DB에 쌓아나가는 겁니다. 제가 그동안 쭉 지켜본 결과, 국내에서 온톨로지를 한다는 대부분의 기업들이 이 방식을 씁니다.
이 방식의 장점은 명확합니다.
– 낮은 초기비용 : RAG처럼 즉각적인 성과를 냅니다.
– 높은 유연성 : 팔란티어처럼 ‘코어 OS’를 걱정할 필요 없이, 새문서(법률, 판례 등)가 나오면 RAG에 추가하고, 새 ‘관계’만 그래프에 더하면 끝입니다.
– ‘추론’ 능력확보 : RAG의 약점이었던 “A와 B의 관계는?”이라는 질문에, GraphRAG가 답을 줄 수 있게 됩니다.
4) RAG의 진화 : 하이브리드 전략
하지만, GraphRAG만으로는 한계가 있습니다. 데이터 저장소(What)을 업그레이드 해도, RAG의 ‘프로세스(HOW)’ 자체가 멍청하다는 근본적인 문제가 남습니다.
표준 RAG는 질문 → 검색 → 답변이라는 ‘싱글 패스 파이프라인’입니다. 만약 ‘검색’ 단계에서 쓰레기를 가져오면(Garbage-in), ‘답변’도 무조건 쓰레기(Garbage-out)가 됩니다. 이 ‘멍청한 프로세스’와 ‘멍청한 데이터(관계 모름)’라는 RAG의 2가지 근본적인 약점을 해결하기 위해 RAG는 2가지 축으로 진화했습니다.
a) 프로세스의 진화
LangGraph와 같은 프레임워크가 RAG 파이프라인에 상태(State)와 순환(Loop)라는 개념을 도입했습니다.
– 자가 교정(Self-Correction) : AI(추론엔진으로서의 LLM 이겠죠..)가 스스로 1차 검색결과를 판단합니다. 이 검색 결과가 질문에 답하기 충분한가? 만약 ‘아니오’라면 싱글패스로 앞으로 가는 대신, 순환(Loop)하면서 키워드를 바꿔 다시 검색합니다. Garbage-in, Garbage-out 문제를 해결하는 핵심입니다.
– 쿼리 변환(Query Transformation) : 사용자의 모호한 질문, 예를 들어 “RAG OAG 차이” 이런걸, LLM이 “RAG와 OAG의 기술적 장단점 비교”처럼 검색하기 좋은 질문으로 변환하는겁니다.
– 동적 라우팅(Dynamic Routing) : 단순 대화인지(LLM), 내부 문서 검색(RAG)인지, 최신 뉴스(Web Search)인지 판단하여 적절한 ‘도구’로 작업을 분배합니다.
이것이 바로 ‘Dynamic RAG’ 또는 ‘Agentic RAG’라 불리는, RAG 프로세스의 진화입니다.
b) 데이터의 진화
앞서 말한, GraphRAG입니다. 텍스트 목록(Vector DB)가 아닌 관계망 지도(Graph DB)에서 검색을 합니다. A와 B의 관계는? 이라는 질문에 답할 수 있게 데이터 저장소를 업그레이드하는 겁니다.
C) 하이브리드 RAG : Dynamic GraphRAG
똑똑한 에이전트(Dynamic RAG)가 네비게이션 지도(GraphRAG)를 사용해 일하는 방식입니다.
LangGraph 에이전트가 State 를 가지며, 작업계획을 수립하고, 도구를 호출하고, 자가 교정(loop)를 수행합니다. 지시자 또는 컨트롤러의 역할을 하는거죠.
Standard RAG를 ‘유사성’ 기반 문서 검색용으로 사용하고, (Vector DB 조회)
GraphRAG를 ‘관계’ 기반 지식 추론용 (Graph DB 조회)
Web Search 를 통해 ‘최신성’ 을 확보합니다.
Vector DB는 문서를 전략적으로 Chuck 해서 시멘틱 서치를 위해 저장하고,
Graph DB는 동적 추출된 개체(Node)와 관계(Edge)를 저장합니다 (Relational Search)
예를 들어 보면,
“A 법안 개정에 반대한 B 의원이, 기존에 A법안의 최대 수혜 기업인 임원과 ‘친족 관계’에 있나?”
1단계 : 에이전트(지시자)가 “단순 검색이 아니라, 복잡한 관계추론, 작업 분해” 를 지시
2단계 : 에이전트(지시자)가 GraphRAG 호출, A법안, B의원, C회사의 관계를 Graph DB에서 확인
3단계 : 에이전트(지시자)가 ‘친족 관계”를 Graph DB에서 확인
4단계 : 만약, ‘친족관계’ 가 그래프에 업사면? Standard RAG 나 Web Search 를 통해 B의원의 인물 정보나 C회사의 임원진 뉴스 기사를 검색해 보충 (Loop 및 보완)
5단계 : 최종답변 생성 “B의원과 C회사의 D이사는 ‘형제’ 관계인 것으로 확인(출처)”
이처럼 ‘하이브리드 RAG’는 RAG의 유연성을 유지하면서도(새 문서를 RAG/Graph DB에 동적 추가), 스스로 생각하고(Dynamic) 관계를 추론(Graph)하는 강력한 AI 전략이라고 볼 수 있습니다.
5) 4가지 전략 비교 분석
– 전통적 RAG (Standard RAG): “빠른 성공(Quick-Win)”이 가능하고, 80%의 단순 Q&A 문제를 가장 저렴하고 유연하게 해결하지만 ‘멍청한 검색’이라는 한계가 명확합니다.
– 전통적 온톨로지 (Classic OAG): “학술적 이상”입니다. 완벽한 지식을 추구하지만, 규칙이 바뀌는 순간(예: 법 개정) 시스템 전체가 멈추는 ‘경직성’ 때문에 현실 도메인에 부적합합니다.
– 하이브리드 RAG (Dynamic GraphRAG): “현실적 최강자”입니다. RAG의 유연성과 저비용을 가져가면서, RAG의 약점 2가지(멍청한 프로세스 + 멍청한 데이터)를 ‘Dynamic’과 ‘Graph’로 동시에 해결합니다. ‘추론’이 가능한 가성비 전략입니다.
– 팔란티어 온톨로지 (AIP): “최종 보스, 궁극의 솔루션”입니다. ‘Heavy OAG’의 강력한 데이터 통제력과 ‘유연한 App(운영)’을 결합해 ‘경직성’을 해결했습니다. ‘검색’이나 ‘추론’을 넘어 AI가 ‘실행(Action)’하고 ‘운영’하는 단계입니다. 하지만 그 대가로 ‘엄청난 비용’과 ‘벤더 종속’을 요구합니다.
6) 공공, 의료, 법률 분야 에서 어떤걸 택할 것인가?
a) 법률 : 새로운 판례와 개정 법률이 계속 쏟아지는데, 결국 ‘최신성’ 이 생명입니다. 결국 1순위는 전통적 RAG, 표준 RAG라고 봐야합니다. 법률 분야의 80% 업무는 ‘리서치’입니다. RAG는 개정 법령 PDF를 그냥 덮어쓰거나 추가하면 즉시 최신성이 반영됩니다. ‘가성비’와 ‘유연성’ 측면에서 압도적 1위입니다. 또한, ‘장, 조, 항’ 구조가 명확해 청킹(Chunking) 정확도도 높죠. 이렇게 되면, 변호사 및 법무팀의 시간이 줄어드는 즉각적인 ROI가 나옵니다.
여기에, ‘소송 전략 수립’ 을 위한 추론이 필요하다면, 하이브리드 RAG면 됩니다. “A 판사, B 로펌, C 쟁점” 간의 관계를 추론하거나, “B 의원이 발의한 법안과 C 기업의 연관성”을 추적하는 등 고부가가치 업무에 사용할 수 있을 겁니다. 검색을 넘어서 추론으로 갈 수 있습니다.
b) 의료 : 의료는 사실 ‘정보 검색’보다 ‘환자 안전’이 중요합니다. ‘관계’를 추론하지 못하면 의료사고로 이어지는 고위험(High-Stakes) 도메인입니다. 제가 디플정에서 추진했었던 여러 프로젝트 중, 공공의료PDS 사업이 있습니다. 응급환자가 실려갈때, 건보나 심평원에 있는 그 환자의 DB를 빠르게 연결해서, 기저질환, 진료이력 등을 제공해서 ‘관계’를 추론하게 하는 거였죠.
때문에, 일단은 1순위 전략은 하이브리드 RAG가 적합합니다. RAG 가 A약물 정보와 B알레르기 정보를 따로따로 검색할 순 있지만, 두 정보의 ‘치명적 상호작용’ 이라는 ‘관계’를 모르죠.
하이브리드 RAG 방식은 RAG로 논문/차트를 검색(효율)하되, ‘얇은 그래프(Graph)’를 통해 ‘약물-질병-유전자’ 간의 상호작용을 검증하는 ‘안전망’을 확보(안전)할 수 있습니다. ‘Dynamic’ 에이전트가 “이 환자의 A 유전자와 B 처방약을 고려할 때, C 약물 처방은 위험하다”고 추론할 수 있어야 하겠죠.
그런데, 돈을 생각하지 않는다면, 사실 이상적인 건 팔란티어 온톨로지 일수 있겠죠. 의사결정 까지 지원하면서 병원 전체의 ‘운영 최적화’를 추구하는게 목표입니다. ‘병상-의료진-수술실-환자 데이터-제고’를 실시간으로 연결하는 ‘병원 디지털 트윈’ 구축이 이상향입니다. 예를 들어, 또 제가 추진하던^^ ‘실시간 의료자원 통한관리 플랫폼’ 은 기본적으로 의료인력-의료자원-병상 을 실시간으로 연결하여 관리하는게 목표입니다. 특히, 중요한 ‘State’, 병상이 현재 찰예정인지, 차있는지, 빠질예정인지, 에크모가 사용중인지, 사용예정인지, 비어있는지, 응급실에 어떤 전문의가 근무중인지 등등 다양한 state 와 ‘관계’ 가 중요합니다.
물론, 이 프로젝트에서는 팔란티어식 온톨로지는 사용하지 않았지만, 이상적으로는 팔란티어의 AIP 도입이 궁극의 솔루션이라고 생각합니다.
c) 공공 : 공공에는 제가 항상 강조하는 것처럼, 대국민서비스, 공무원 일하는 방식 혁신, 사회문제 해결 이라는 3가지 목표가 존재합니다. 2가지로 정리해보면, 대국민서비스(정보제공) 와 국가 운영(추론/통제/생산성)입니다.
대국민서비스 만 생각하면 사실, 표준 RAG로도 일단 충분하다고 봅니다. RAG 기반 ‘AI 민원 챗봇’과 ‘공무원 내부 업무 봇’은 가장 적은 비용으로 가장 많은 국민과 공무원이 체감하는 ‘빠른 성공(Quick-Win)’입니다. 법률 분야처럼 정책/매뉴얼 파일만 교체하면 되므로 현업에서 직접 유지보수가 가능합니다.
여기에 국가운영까지 고민하기 시작하면, 하이브리브 RAG 전략으로 가야겠죠.
지난 정부의 디지털플랫폼정부, 이번 정부의 AI 정부 모두 핵심 목표중 하나가 ‘부처간 사일로 해소’입니다. 각 부처가 각자의 RAG DB(Vector DB)를 가지고, 전체 Graph DB, 부처간의 관계를 정의하고, 업무간 연관성을 정의하는 Graph DB가 있다면, 협업과 데이터 공유는 물론, ‘A 부처 사업(문서)’과 ‘B 부처 예산(문서)’ 간의 ‘관계’를 ‘하이브리드 RAG’로 추론하여 예산 중복을 검토하는 등 다양한 ‘AI 기반 정책’ 이 가능합니다. ‘Heavy OAG’ 없이도 부처 간 칸막이를 허물수 있죠.
– 개별 (Vector DB): 각 부처는 자체 정책/문서에 대한 ‘표준 RAG’ (Vector DB)를 자율적으로 운영하며 빠른 속도와 효율을 확보합니다.
– 중앙 (Graph DB): 이와 별도로, 부처 간의 ‘관계’, ‘업무 연관성’, ‘데이터 정의’만을 담은 ‘얇은’ 중앙 Graph DB를 구축합니다.
AI는 중앙 Graph DB를 통해 두 사업의 ‘관계’를 먼저 인지하고, 각 부처의 Vector DB에서 ‘세부 내용’을 RAG로 가져와 비교 추론하고, 또 각 부처는 각 부처의 Vector DB를 활용해 다양한 AI 활용이 가능할겁니다.
물론, 국방, 안보, 재난 같이 ‘가성비’가 아닌 ‘국가 생존’이 목표인 특수 도메인에서는 팔란티어 온톨로지(AIP)가 답이겠지요. 하지만, 비용보다도 영원한(?) 기술종속의 위험과 안보 이슈가 있는 상황에서 국산화 또는 철저한 통제 하에 제한적인 고려만 가능할 겁니다.
#
온톨로지가 ‘왕의 귀환’을 했지만, 온톨로지도 RAG도 하나의 연결되는 방법론으로 봐야합니다. 완전한 정답은 없습니다. 하지만, 현실적으로 볼때, LLM을 다양한 도메인에서 도입할때, 도메인 성격에 따라, 검색이 중요하면 전통적 RAG로 80%의 정보 검색 문제를 해결해서 퀵윈을 거두거나, 아니면, 추론과 관계가 중요하다면, 하이브리드 RAG로 RAG의 유연성과 가성비를 유지하되, ‘자가교정’ 과 ‘관계 추론’이 가능하도록 하는게 맞지 않나 싶습니다. 사실 앞서도 얘기했지만, 대부분의 국내 온톨로지 기술들이 저는 이 부분이라고 봅니다. 팔란티어와 같은 온톨로지는 비싼 만큼, 투입되는 자원과 전문가들이 어마어마하니까요.
앞으로 계속 기술은 진화하고, 새로운 대안이 나올거라 봅니다. 그래서, 저는 일단 ‘경직성’ 에는 조금 부정적인 생각을 가지고 있긴 합니다. 계속 ‘고도화’의 길을 열어 두어야 겠지요.
* p.s. : KT가 공공에 팔란티어를 도입한다고 설명할 때, 그리고 외교부가 외교AI를 만들면서 온톨로지를 구현한다고 할때부터, 나름 이거저거 자료도 찾아보고 고민해오던 문제를 좀더 보완해서 정리해봤습니다. 온톨로지라는 개념이 비전문가들 입장에서는 혼란스러운 부분, 오도되는 부분 등이 많아서… Anyway, 역시나 제 개인적인 생각이니, 진짜 전문가들께서는 이해해주시길…^^ 설명을 위해 좀 세게 얘기하기도 하고, 일반화도 좀 했습니다..
* p.s 2 :몇가지 오독이 있는것 같아서 추가합니다. 제가 말항‘Heavy’는 RDF·OWL 등 시맨틱웹 기술 스택을 의미한 것이 아니라, 고정된 스키마와 복잡한 거버넌스를 지닌 운영형 코어 모델을 표현한것이고, Heavy OAG의 개념적 유산 위에서 팔란티어가 경직성을 완화했다는 관점입니다.
그리고, 팔란티어가 RDF/OWL을 그대로 쓰지 않는다고 해서, 그게 “팔란티어가 Heavy하지 않다”는 뜻이 아닙니다. Foundry Ontology는 여전히 복잡한 타입 정의, 객체 간 계층적 관계,데이터 거버넌스 룰, 액션 레이어 통제를 전제로 하는 강한 스키마드(schema’d) 시스템 입니다.