LLM의 환각을 잠재울 지식의 지도, ‘온톨로지(Ontology)’

최근 대형 언어 모델(LLM)을 실제 서비스에 도입하려는 기업들의 가장 큰 고민은 ‘환각(Hallucination)’ 현상입니다. 이를 해결하기 위해 외부 데이터를 참조하는 RAG(검색 증강 생성) 기술이 표준처럼 자리 잡았습니다. 하지만 단순한 문서 검색만으로는 복잡한 추론이나 정확한 관계 파악에 한계가 있습니다.

이러한 RAG의 한계를 돌파하고, AI에게 인간 수준의 논리적이고 구조화된 지식을 제공하기 위해 다시금 주목받고 있는 개념이 바로 **’온톨로지(Ontology)’**입니다.

1. 온톨로지(Ontology)란 무엇인가?

본래 철학에서 ‘존재론’을 뜻하는 온톨로지는, 컴퓨터 공학으로 넘어오면서 “특정 도메인의 지식을 개념화하여 명시적으로 명세한 것”을 의미하게 되었습니다. 쉽게 말해, 세상의 지식을 컴퓨터가 이해할 수 있는 형태의 ‘관계형 지도(Map)’로 만드는 작업입니다.

온톨로지는 단순히 단어의 뜻을 나열하는 사전을 넘어서, 관계형 지도를 통해 이해하게 됩니다. 다음과 같은 핵심 요소로 구성됩니다.

• 클래스(Class/Concept): 사물이나 개념의 범주 (예: ‘사람’, ‘회사’)
• 인스턴스(Instance): 클래스에 속하는 실제 객체 (예: ‘팀 쿡’, ‘애플’)
• 속성(Property): 객체가 가지는 특징 (예: ‘설립 연도’)
• 관계(Relationship): 객체 간의 연관성 (예: ‘팀 쿡’은 ‘애플’의 CEO이다)

즉, 온톨로지는 데이터 조각들을 모아 “A는 B의 하위 개념이고, C와는 D라는 관계를 가진다”는 명확한 논리적 규칙을 부여합니다. 이를 실제 데이터베이스 형태로 구현한 것이 바로 지식 그래프(Knowledge Graph)입니다.

2. 온톨로지와 RAG: 무엇이 다를까?

RAG는 일반적으로 데이터를 벡터(Vector) 형태로 변환하여 저장하는 ‘벡터 데이터베이스(Vector DB)’를 기반으로 동작합니다. 두 기술은 지식을 저장하고 검색하는 방식에서 명확한 차이를 보입니다.

구분	RAG (벡터 DB 기반)	온톨로지 (지식 그래프 기반)
데이터 구조	비구조화된 텍스트의 의미적 표현 (숫자 벡터)	고도로 구조화된 엔티티와 관계의 네트워크
검색 방식	‘의미적 유사도’에 기반한 확률적 검색	‘명시적 관계’에 기반한 논리적, 결정론적 검색
장점	구축이 빠르고 유연함, 방대한 비정형 문서 처리에 탁월	관계에 기반한 사실 추출, 복잡한 다단계 추론 가능
단점	문서 간의 명확한 ‘관계’나 ‘계층’을 파악하기 어려움	초기 설계(모델링)가 어렵고 구축 및 유지보수 비용이 높음

결정적인 차이는 ‘추론의 깊이’입니다. 예를 들어 “A회사를 인수한 B회사의 CEO가 졸업한 대학은?” 이라는 질문을 던졌을 때, 단순 RAG는 관련 키워드가 흩어진 문서를 찾아 헤맬 확률이 높습니다.
반면, 온톨로지 기반의 시스템은 [A회사] -> (인수됨) -> [B회사] -> (CEO) -> [인물] -> (졸업) -> [대학] 이라는 연결 고리(Path)를 따라가며 정확한 정답을 도출해냅니다.

3. RAG의 한계를 뛰어넘는 온톨로지의 3가지 강력한 무기

단순한 문서 검색 기반의 RAG가 가진 한계를 명확히 이해할 때, 온톨로지의 진정한 가치가 드러납니다. RAG가 해결하지 못하는 문제를 온톨로지는 다음과 같은 강력한 장점을 통해 돌파합니다.

① 확률이 아닌 ‘결정론적 정확성 (Deterministic Accuracy)’ 보장

• LLM과 벡터 기반 RAG는 본질적으로 ‘확률’에 기반하여 가장 적절해 보이는 단어와 문서를 짜맞춥니다.
  반면, 온톨로지는 명시적으로 정의된 관계 데이터만을 다룹니다.
  *”애플의 설립자는 스티브 잡스이다”*라는 명제가 지식 그래프에 등록되어 있다면, AI는 다른 문서의 맥락에 휘둘리지 않고 이 절대적인 사실을 그대로 가져옵니다.
  따라서 기업의 재무 데이터, 핵심 규정, 매뉴얼 등 환각(Hallucination)을 허용하지 않는 도메인에서 신뢰성을 제공합니다.

② 흩어진 정보를 연결하는 ‘다단계 추론 (Multi-hop Reasoning)’

• 실제 업무에서 발생하는 질문은 1차원적이지 않습니다.
  예를 들어, “우리 회사 A부서 소속 직원이 담당하는 B프로젝트에서 사용된 클라우드 인프라의 월별 비용은?” 이라는 질문을 가정해 보겠습니다.
  벡터 DB 환경에서는 ‘A부서’, ‘B프로젝트’, ‘클라우드 비용’이 모두 하나의 문서에 적혀 있지 않다면 제대로 된 답변을 찾기 어렵습니다.
  하지만 온톨로지로 구축된 지식 그래프에서는
  [A부서] -> (소속됨) -> [직원] -> (담당함) -> [B프로젝트] -> (사용함) -> [클라우드 인프라] -> (발생함) -> [월별 비용]
  이라는 노드 간의 연결 고리(Path)를 따라가며 흩어진 데이터를 조합해 정답을 추론해 냅니다.

③ 과정을 투명하게 보여주는 ‘설명 가능한 AI (Explainable AI, XAI)’

• LLM이 내놓은 답변이 맞는지 검증하는 것은 기업 입장에서 큰 골칫거리입니다. 벡터 기반 검색은 수많은 문서의 조각들을 섞어서 답변을 생성하기 때문에 “왜 이런 답변이 나왔는지” 역추적하기가 까다롭습니다.
  하지만 온톨로지는 AI가 어떤 엔티티(Entity)와 관계(Relationship)를 거쳐 결론에 도달했는지 그 경로를 시각적이고 논리적으로 추적할 수 있습니다. 이는 결과에 대한 명확한 근거와 책임이 필요한 의료, 금융, 법률, 공공 분야에서 AI를 도입하기 위한 필수적인 장치입니다.

4. 완벽해 보이는 온톨로지의 3가지 현실적 단점

온톨로지는 AI에게 정확한 논리를 제공하는 강력한 도구지만, 현실 비즈니스에 단독으로 적용하기에는 몇 가지 한계가 존재합니다.

① 초기 구축 비용과 시간 (High Cost)

• 온톨로지는 방대한 데이터베이스를 컴퓨터가 스스로 알아서 구축하는 것이 아닙니다. 도메인 전문가(SME)와 지식 엔지니어가 수작업으로 개념을 정의하고, 관계(Schema)를 설계해야 합니다. 기업 데이터 전체에 대한 관계 설계에는 막대한 시간과 인건비를 요구합니다.

② 새로운 지식에 대한 스키마 경직성 (Rigidity)

• 세상의 지식은 실시간으로 변합니다. 하지만 온톨로지는 사전에 정의된 ‘틀(규칙)’에 맞춰 데이터를 넣는 방식이므로, 아예 새로운 개념이나 관계가 등장하면 전체 구조(Schema)를 뜯어고쳐야 하는 번거로움이 있습니다. 따라서 유연성이 떨어지게 됩니다.

③ 비정형 데이터 처리의 어려움 (Handling Unstructured Data)

• 온톨로지는 “A는 B이다”라는 명확한 명제(Triple 구조)를 좋아합니다. 하지만 기업 데이터의 80% 이상은 맥락이 숨어있고 모호한 표현이 섞인 ‘비정형 텍스트(이메일, 보고서, 회의록)’입니다. 이러한 텍스트의 미묘한 뉘앙스를 온톨로지로 완벽하게 변환하는 것은 사실상 불가능에 가깝습니다.

5. 온톨로지와 RAG의 상호보완

이러한 온톨로지의 단점을 완벽하게 덮어주는 ‘구원투수’가 바로 기존의 벡터 기반 RAG입니다. 두 기술은 서로의 약점을 보완하며 다음과 같은 시너지를 냅니다.

① RAG의 유연성으로 온톨로지의 ‘경직성’ 극복

• 온톨로지에 새로운 개념을 업데이트하려면 시간이 걸립니다. 이때 RAG가 ‘임시 저장소’ 역할을 합니다. 매일 쏟아지는 최신 뉴스, 신규 매뉴얼, 업데이트된 정책 등의 동적 데이터는 벡터 DB(RAG)에 즉각적으로 밀어 넣어 빠르게 대응합니다.
  이후 정제되고 변하지 않는 핵심 지식만 선별하여 주기적으로 온톨로지(지식 그래프)에 편입시키는 투트랙(Two-Track) 전략을 사용할 수 있습니다.

② 벡터 검색으로 온톨로지의 ‘비정형 데이터 한계’ 보완

• 사용자의 질문이 항상 논리적이고 명확한 것은 아닙니다. “작년에 발표된 그 A프로젝트 관련해서 분위기가 어땠지?” 같은 모호한 질문이 들어올 경우, 정해진 관계만 찾는 온톨로지는 답변을 거부할 수 있습니다.
  이때 벡터 기반 RAG가 문서의 전반적인 맥락(Context)과 의미적 유사도를 바탕으로 관련된 회의록이나 보고서를 찾아냅니다. RAG가 비정형 데이터의 ‘맥락’을 잡아주면, 온톨로지는 그 안에서 ‘정확한 수치나 관계’를 짚어주는 역할을 분담합니다.

③ ‘Long-tail 지식’과 ‘Core 지식’의 분리 (비용 효율화)

• 모든 사내 데이터를 온톨로지로 구축하는 것은 비용 낭비입니다.
  • 온톨로지(그래프) 적용: 절대 틀리면 안 되는 기업의 핵심 비즈니스 로직, 조직도, 제품 스펙, 규정 등 **’Core 지식’**에만 집중하여 비용을 최적화합니다.
  • RAG(벡터) 적용: 그 외의 방대한 일반 문서, 과거의 프로젝트 이력, 참고 자료 등 빈도가 낮고 방대한 **’Long-tail 지식’**은 구축이 저렴한 벡터 DB로 처리합니다.
• 이 두 가지를 결합한 Graph RAG 아키텍처를 도입하면, 구축 비용은 최소화하면서도 환각이 통제된, 빠르고 정확한 엔터프라이즈 AI 시스템을 완성할 수 있습니다.

6. 최종적으로 온톨로지를 어떻게 사용해야 하는가? (Graph RAG의 부상)

온톨로지와 벡터 기반 RAG는 경쟁 관계가 아니라 상호 보완적인 관계입니다. 최근 AI 업계에서는 이 둘을 결합한 **Graph RAG(Graph Retrieval-Augmented Generation)**가 핵심 트렌드로 떠오르고 있습니다.

AI 서비스에서 온톨로지를 성공적으로 활용하기 위한 3단계 접근법은 다음과 같습니다.

Step 1. 핵심 도메인에 대한 온톨로지 모델링 (선택과 집중)

모든 데이터를 온톨로지로 만들 필요는 없습니다. 기업의 핵심 비즈니스 로직, 제품군, 전문 용어 등 **절대 틀려서는 안 되는 핵심 사실(Ground Truth)**에 대해서만 우선적으로 온톨로지를 설계해야 합니다.

Step 2. 지식 그래프(Knowledge Graph) 구축 및 통합

설계된 온톨로지를 바탕으로 그래프 데이터베이스(Neo4j 등)를 구축합니다. 이때 기존의 관계형 DB(RDB)나 사내 문서 등에서 엔티티(Entity)와 관계(Relation)를 추출하여 지식 그래프를 지속적으로 업데이트하는 파이프라인을 구축해야 합니다.

Step 3. 하이브리드 검색(Hybrid Search) 기반의 Graph RAG 구현

사용자의 질문이 들어오면, AI는 두 가지 검색을 동시에 수행하도록 설계합니다.

1. 벡터 검색: 문서의 전반적인 맥락과 의미를 파악하여 유연한 답변의 뼈대를 만듭니다.
2. 그래프(온톨로지) 검색: 질문 속 엔티티를 식별하고, 관계를 추론하여 정확한 고유 명사나 수치, 관계 데이터를 추출합니다.

결국 이 두 가지 정보가 프롬프트에 합쳐져 LLM에 전달됨으로써, “풍부한 맥락(RAG)을 가지면서도 사실관계가 완벽히 검증된(Ontology)” 최적의 답변을 생성하게 됩니다.

7. AWS를 활용한 온톨로지 및 Graph RAG 구현 가이드

AWS는 그래프 데이터의 저장부터 LLM 연동까지 아우르는 강력한 완전 관리형 서비스 라인업을 보유하고 있습니다.

• 주요 AWS 서비스 라인업
  • Amazon Neptune: 온톨로지의 핵심인 그래프 데이터베이스입니다. RDF(Resource Description Framework)와 Property Graph 모델을 모두 지원하며, 지식 간의 복잡한 관계를 수 밀리초 안에 쿼리할 수 있는 고성능 엔진을 제공합니다. (Neptune Analytics를 통해 실시간 분석 및 벡터 검색도 가능합니다.)
  • Amazon OpenSearch Service: RAG의 필수 요소인 벡터 데이터베이스 역할을 수행합니다. 비정형 문서의 시맨틱 검색(Semantic Search)을 담당하며, Neptune의 구조화된 데이터와 결합하여 하이브리드 검색을 완성합니다.
  • Amazon Bedrock: 파운데이션 모델(FM) API 서비스입니다. 문서에서 엔티티(Entity)와 관계(Relation)를 추출하여 온톨로지를 자동 생성하거나, 검색된 지식을 바탕으로 최종 답변을 생성하는 ‘두뇌’ 역할을 합니다.
  • AWS Glue & Amazon Comprehend: 비정형 데이터에서 지식을 추출하고 정제하는 ETL 및 NLP 파이프라인을 구축할 때 사용합니다.

아키텍처 설계 시 고려사항 (Tip)

1. 서버리스 우선 전략: Amazon Neptune Serverless와 AWS Lambda를 사용하면 초기 비용 부담 없이 트래픽에 따라 유연하게 확장할 수 있는 시스템을 구축할 수 있습니다.
2. 자동화된 온톨로지 업데이트: 새로운 문서가 S3에 업로드될 때마다 Bedrock을 호출하여 지식 그래프 노드를 자동으로 추가하는 Event-Driven 파이프라인 구축이 중요합니다.
3. 보안: IAM 정책을 통해 지식 기반 데이터에 대한 접근 권한을 세밀하게 제어하여, 기업의 민감한 정보가 안전하게 관리되도록 설계해야 합니다.

마무리하며

AI가 단순한 ‘문장 생성기’를 넘어 신뢰할 수 있는 ‘전문가 시스템’으로 진화하기 위해서는, 인간의 지식 구조를 닮은 온톨로지의 도입이 필수적입니다. 데이터의 양(Volume)에만 집중하던 시대에서 벗어나, 이제는 데이터 간의 맥락과 관계(Relationship)를 어떻게 구조화할 것인지 고민해야 할 시점입니다.