시작하며

사내 문서를 검색하여 답변하는 AI 메커니즘(RAG)을 만들었지만, "현장의 언어로 질문하면 대답하지 못한다", "여러 문서에 걸친 질문이 되면 갑자기 정밀도가 떨어진다"라고 느낀 적이 없으신가요? 원인의 대부분은 AI가 문서의 "의미적 연결(semantic connection)"을 가지고 있지 않기 때문입니다. 문장을 단편적으로 검색하기만 해서는 "이 제품의 도면은 무엇인가", "이 고객의 주문은 어느 담당자가 대응했는가"와 같이 업무에서는 당연한 관계를 추적할 수 없습니다.

이 과제에 대한 해답 중 하나가 바로 본 기사의 테마인 **온톨로지 (Ontology)**입니다. 온톨로지란 업무에 등장하는 개념(고객·주문·제품 등)과 개념 간의 관계(고객은 주문을 한다 등)를 AI가 다룰 수 있는 형태로 정의한 것입니다. Microsoft의 연구에 따르면, 온톨로지로 검색을 뒷받침한 RAG는 정확한 사실의 재현율이 55%, 답변의 정확도가 40% 향상되었다고 보고되었습니다 (자세한 내용은 본문에서 해설합니다).

본 기사에서는 온톨로지의 정의와 자주 혼동되는 용어와의 차이점부터, 작게 시작하는 제작 방법, RAG·AI 에이전트에 활용하는 방법까지 공개 논문과 1차 정보에 기반하여 해설합니다.

1. 온톨로지란: 기초 지식

1-1. 업무의 개념과 관계를 정의한 것

온톨로지란 대상이 되는 세계(여기서는 업무)에 무엇이 존재하며, 그것들이 어떻게 관계하고 있는지를 기계가 다룰 수 있는 형태로 명시적으로 정의한 것입니다. 정보과학 분야에서는 1990년대부터 지식 표현 (Knowledge Representation) 연구에서 사용되어 온 용어로, "개념화의 명시적인 사양 (an explicit specification of a conceptualization)"이라고 정의됩니다 (Gruber, 1993).

정의만으로는 이해하기 어려우므로, 제조업의 수주 업무를 예로 들어보겠습니다. 이 업무에는 "고객", "주문", "제품", "도면"과 같은 개념이 등장합니다. 그리고 개념 사이에는 관계가 있습니다.

• 고객은 주문을 발주한다
• 주문은 제품을 포함한다
• 제품은 도면을 참조한다

이 "개념 목록"과 "관계 목록"을 써 내려가며 정의한 것이 온톨로지입니다. 포인트는 온톨로지가 데이터 그 자체가 아니라, 데이터의 의미를 정하는 규칙 (정의) 이라는 점입니다. 개별 고객명이나 주문 번호는 데이터이며, "고객은 주문을 발주한다"는 그 데이터를 어떻게 해석할 것인가에 대한 정의에 해당합니다.

1-2. 스키마·나리지 그래프·RAG와의 차이

온톨로지는 데이터베이스의 스키마 (Schema)나 나리지 그래프 (Knowledge Graph)와 자주 혼동됩니다. 차이점을 표로 정리합니다.

보충: RAG (Retrieval-Augmented Generation: 검색 증강 생성)는 질문과 관련된 문서를 검색하고, 그 내용을 근거로 LLM (대규모 언어 모델)이 답변하게 하는 메커니즘입니다. 온톨로지는 RAG와 대립하는 기술이 아니라, RAG의 검색을 똑똑하게 만들기 위해 조합하여 사용합니다.

스키마와의 차이가 특히 중요합니다. 스키마는 "t_order 테이블에 cust_cd 컬럼이 있다"와 같이 시스템 편의를 위한 구조를 정합니다. 반면 온톨로지는 "고객이 주문을 발주한다"와 같이 현장의 인간이 사용하는 언어와 관계로 의미를 정합니다. 같은 데이터라도 스키마만으로는 AI가 cust_cd가 "거래처"라고도 불리고 "클라이언트"라고도 불리는 동일한 개념이라는 것을 알 수 없습니다. 이 대응 관계를 담당하는 것이 온톨로지입니다.

나리지 그래프와의 역할 분담은 다음과 같습니다. 온톨로지가 "고객은 주문을 발주한다"라고 정의하면, 나리지 그래프는 그 정의에 따라 "A사 → 발주한다 → 주문#1234"와 같이 실데이터를 연결합니다. 온톨로지 없이도 나리지 그래프는 만들 수 있지만, 정의가 없으면 관계의 이름이나 입도가 제각각이 되어 추적하기 어려운 그래프가 되기 쉽기 때문에 두 가지는 세트로 취급됩니다.

1-3. 기존 RAG의 약점과 온톨로지가 정밀도를 높이는 이유

기존의 RAG는 문서를 청크(Chunk, 수백 자 정도의 파편)로 분할하고, 질문과 의미가 가까운 청크를 벡터 검색(Vector Search)으로 찾아내어 답변합니다. 이 방식에는 세 가지 구조적인 약점이 있습니다.

표기 불일치 및 동의어에 취약: '거래처'라고 적힌 문서는 '클라이언트'라는 질문과 의미가 어긋나 검색에서 누락될 수 있습니다. -
문서를 가로지르는 관계를 추적할 수 없음: '제품 X의 도면을 작성한 담당자는 누구인가'와 같이 여러 문서에 나뉘어 있는 사실을 연결하는 질문에 답할 수 없습니다. 청크는 서로의 관계를 알지 못하기 때문입니다. -
전체를 관통하는 질문에 답할 수 없음: '지난 1년간의 장애 보고서에 공통적으로 나타나는 원인은 무엇인가'와 같이 데이터셋 전체를 조망하는 질문은 애초에 '검색해서 읽는' 방식으로는 다룰 수 없습니다.

온톨로지(Ontology)는 이 세 가지 문제에 각각 효과적입니다. 별칭 정의가 표기 불일치를 흡수하고, 관계 정의가 문서를 가로지르는 사실을 연결하며, 개념 단위의 집약이 전체를 관통하는 요약을 가능하게 합니다. 이러한 효과는 Microsoft의 연구를 통해서도 수치로 확인되었습니다. 연구는 두 가지가 있으며, 답하고자 하는 질문의 종류에 따라 접근 방식이 나뉩니다.

첫 번째는, 질문할 때마다 읽는 범위를 좁히는 방법입니다 (OG-RAG, Microsoft, 2024년). 온톨로지에 따라 문서를 의미 단위별로 정리해 두고, 질문이 들어오면 관련된 덩어리(Chunk/Group)만 AI에게 전달합니다. 무관한 문서를 처음부터 제외할 수 있기 때문에, '제품 X의 도면을 작성한 담당자는 누구인가'와 같이 특정 사실을 묻는 질문에서 정밀도가 높아집니다. 4종류의 LLM 평가 결과, 정확한 사실의 재현율(Recall)이 55% 향상, 답변의 정확도가 40% 개선, 사실에 기반한 추론 정밀도가 27% 향상되었다고 보고되었습니다.

두 번째는, 미리 요약을 만들어 두는 방법입니다 (GraphRAG, Microsoft Research, 2024년). LLM을 통해 문서에서 엔티티(Entity, 실체)와 관계를 추출하여 지식 그래프(Knowledge Graph)를 만들고, 관계가 깊은 덩어리별로 요약을 준비해 둡니다. 이러한 사전 준비가 되어 있으면, '지난 1년간의 장애 보고서에 공통적으로 나타나는 원인은 무엇인가'와 같이 문서를 하나씩 읽어서는 답할 수 없는 질문에도 대응할 수 있습니다. 100만 토큰 규모의 데이터셋에서 기존 방식의 RAG로는 다룰 수 없었던 이러한 질문들에 대해, 답변의 포괄성과 다양성 양면에서 앞섰다고 보고되었습니다.

즉, RAG의 정밀도가 더 이상 향상되지 않을 때, 청크를 나누는 방식이나 검색 모델을 조정하는 것뿐만 아니라, 데이터의 의미 구조 자체를 정비하는 방식이 연구로 뒷받침된 또 다른 선택지가 됩니다. 고정밀 RAG를 Dify로 구축하는 방법에 대해서는 이쪽을 참고해 주세요.

2. 온톨로지 만드는 법: 작게 시작하는 구현 단계

온톨로지라고 하면 전사의 데이터를 망라하는 대규모 정비를 상상하기 쉽지만, 처음부터 그것을 목표로 할 필요는 없습니다. 여기서는 대상 업무 1개 · 개념 5~10개의 최소 구성으로 시작하는 절차를 해설합니다.

2-1. 업무의 명사와 관계를 도출하기

첫 번째 재료는 이미 사내에 있습니다. 업무 매뉴얼, 양식, 기간계 시스템(Legacy System)의 마스터 데이터, 용어집입니다. 거기서 다음 세 가지를 뽑아냅니다.

개념(명사): 업무에 등장하는 '사물·사건'. 예: 고객, 주문, 제품, 도면, 담당자 -
별칭(표기 불일치): 동일한 개념을 가리키는 다른 명칭. 예: 고객 = 거래처 = 클라이언트. 동일한 것을 가리키는 다른 표기를 하나로 합치는 작업을 '데이터 정제(Data Cleansing/Master Data Management)'라고 부릅니다 -
관계: '주어 — 관계 — 목적어' 형태로 쓸 수 있는 사실의 유형. 예: 고객 — 발주한다 — 주문

이 단계의 결과물은 Excel이나 표로 충분합니다. 중요한 것은 현장 실무자가 실제로 사용하는 언어를 채택하는 것입니다. 시스템의 컬럼명이 아니라 현장의 언어로 정의해야만, 현장의 언어로 질문할 수 있는 AI가 됩니다.

참고로, 도출 대상이 되는 도면이나 양식류가 애초에 AI가 다룰 수 있는 형태가 아니라면 먼저 데이터의 구조화가 필요합니다. 도면이나 양식을 AI가 사용할 수 있는 형태로 바꾸는 방법에 대해서는 이쪽을 참고해 주세요.

2-2. 정의 파일로 옮기기

도출한 내용을 기계가 읽을 수 있는 정의 파일로 만듭니다. 학술 분야에는 OWL(Web Ontology Language: 온톨로지를 엄격하게 기술하기 위한 국제 표준)도 있지만, 사내 이용을 위한 최소 구성이라면 우선 YAML(들여쓰기로 계층을 나타내는 읽고 쓰기 쉬운 기술 형식)로도 충분합니다.

# 온톨로지 정의의 최소 예시 (수주 업무)
concepts: # 업무에 등장하는 개념 목록
- name: 고객 # 개념의 정식 명칭
...

이 정의 파일이 그대로 팀의 공통 언어가 됩니다. "관계의 이름은 동사형으로 통일한다", "별칭은 현장 인터뷰를 통해 추가한다"와 같은 운영 규칙을 파일 서두의 주석에 적어두면, 지식의 개인화(属人化, Siloization)를 방지할 수 있습니다.

2-3. 데이터베이스에 저장하는 최소 스키마 (Schema)

정의가 완료되면 실제 데이터와 결합하여 저장합니다. 다음은 PostgreSQL과 pgvector(벡터 검색용 확장 기능)를 활성화한 환경을 전제로 한 최소한의 테이블 구성 예시입니다. 실제 도입 시에는 다루는 데이터 양이나 기존 시스템에 맞춰 조정하십시오.

-- 온톨로지와 RAG를 연결하는 최소 테이블 구성 예시
CREATE EXTENSION IF NOT EXISTS vector; -- pgvector 확장을 활성화한다
CREATE TABLE entities ( -- 개념의 실체(Entity)를 저장한다
...

테이블이 생성되면 2-2에서 정의한 개념과 관계에 따라 실제 데이터를 입력합니다. "A사"를 고객으로 등록하고, 별칭을 연결하며, 주문과의 관계를 잇는 과정이 다음 예시입니다.

-- 정의에 따라 실제 데이터를 등록하는 예시 (id는 자동으로 채번됨)
INSERT INTO entities (type, name) VALUES
('고객', 'A사'), -- 「고객」의 실체로서 A사를 등록 (id=1이 됨)
...

여기까지 입력해 두면, "A사의 주문은?"이라는 질문을 받아도 aliases 테이블을 통해 정식 명칭인 A사를 특정하고, relations를 따라 주문 #1234에 도달할 수 있습니다. 정의(2-2)와 실제 데이터(여기)가 대응된 상태가 바로 온톨로지를 업무 데이터에 적용한 모습입니다.

구성의 포인트는 두 가지가 있습니다. 하나는 aliases 테이블을 처음부터 준비하는 것입니다. 표기 불일치(表記ゆれ, Variation)를 흡수하는 것은 온톨로지의 효과가 가장 명확하게 나타나는 부분으로, 나중에 추가하려고 하면 데이터 통합(名寄せ, Entity Resolution) 작업을 다시 해야 하는 상황이 발생합니다. 다른 하나는 evidence_links입니다. 엔티티와 청크(Chunk)를 대응시켜 둠으로써, 해당 엔티티와 관련된 문서로만 검색 범위를 좁힐 수 있습니다. 이와 동시에 답변의 근거가 된 문서도 제시할 수 있습니다.

2-4. RAG와 결합하기

저장된 온톨로지를 RAG의 검색 플로우(Flow)에 포함시킵니다. 설계의 기본 형태는 다음과 같은 흐름입니다.

• 엔티티 해결 (Entity Resolution): 질문 문장에 포함된 단어를 aliases를 통해 정식 명칭으로 변환합니다 (예: "거래처 A의 수주" → 엔티티 "A사", "주문")
• 관계의 전개 (Relation Expansion): relations를 따라 질문과 관련된 엔티티를 확장합니다 (예: "A사" → 발주하다 → A사의 주문 그룹)
• 검색 범위 축소: evidence_links를 통해 관련 엔티티에 연결된 청크로 검색 대상을 좁힙니다.
• 답변 생성: 좁혀진 청크를 컨텍스트(Context, LLM에 전달하는 참고 정보)로서 LLM에 전달하여 답변을 생성합니다.

기존 RAG와의 차이점은 벡터 검색의 전단계에 의미 처리(1~3단계)가 들어간다는 점입니다. 검색 대상이 문서 전체가 아니라, 질문과 관계가 있다고 정의상 말할 수 있는 범위로 좁혀지기 때문에 무관한 청크가 섞여 들어오는 일이 줄어듭니다. OG-RAG가 보여준 정밀도 향상은 바로 이 "검색 대상을 개념적으로 뒷받침하는" 효과에 의한 것입니다.

LLM에 전달할 컨텍스트를 어떻게 설계하느냐는 온톨로지의 유무와 관계없이 RAG의 품질을 좌우합니다. 컨텍스트 엔지니어링(Context Engineering)의 실천에 대해서는 이쪽도 참고해 주시기 바랍니다.

3. 응용·발전: LLM을 통한 구축 지원과 AI 에이전트로의 전개

3-1. 온톨로지 구축은 LLM에게 도움을 받는다

여기까지 읽으셨다면, "정의를 일일이 수작업으로 찾아내는 것은 너무 힘들 것 같다"라고 느끼신 분들이 많을 것입니다. 실제로 온톨로지 정비의 부담은 오랫동안 이 분야의 과제였습니다. 하지만 상황은 변하고 있습니다. 지식 그래프(Knowledge Graph) 구축에는 온톨로지 설계, 지식 추출(문서로부터의 추출), 지식 융합(중복 및 표기 불일치의 통합)의 3단계 과정이 있습니다. 2025년 서베이 논문(Survey Paper, 특정 분야의 연구를 폭넓게 조사하여 동향을 정리한 논문)에 따르면, 이 모든 과정이 규칙 기반(Rule-based) 방식에서 LLM을 사용하는 생성적(Generative) 방식으로 이행하고 있다고 정리되어 있습니다.

해당 서베이는 구축 접근 방식을 두 가지로 분류하고 있습니다.

실무에서는 이 두 가지를 단계적으로 사용하는 방법이 현실적입니다. 먼저 스키마 프리 방식으로 LLM에게 업무 문서로부터 개념과 관계의 초안을 만들게 하고, 사람이 리뷰하여 정식 정의로 정돈한 뒤, 이후에는 스키마 기반 방식으로 추출을 수행합니다. 초안 작성을 AI에게 맡기고 확정을 사람이 담당하도록 분담하면, 처음부터 수작업으로 정의하는 것보다 착수 부담을 크게 낮출 수 있습니다.

3-2. AI 에이전트의 세계 모델(World Model)로서의 온톨로지

온톨로지의 용도는 RAG의 정밀도 향상에 그치지 않습니다. 또 다른 중요한 맥락은 AI 에이전트(자율적으로 도구를 조작하여 태스크를 수행하는 AI)입니다.

에이전트에게 업무를 맡기려면, 업무에 무엇이 존재하며 어떤 조작이 허용되는지를 에이전트 스스로 참조할 수 있어야 합니다. 온톨로지는 여기서 세 가지 역할을 수행합니다. 첫째는 업무에 어떤 개념이 존재하는지를 에이전트에게 보여주는 세계 모델 (World Model) (에이전트가 전제로 하는 업무의 전체상)로서의 역할입니다. 다음으로, 어떤 개념에 어떤 조작을 해도 되는지에 대한 행동 범위와 권한을 정하는 역할이 있습니다. 그리고 마지막 하나는 인간과 AI가 동일한 언어로 업무를 다루기 위한 공통 언어로서의 역할입니다.

구체적인 예로 생각해 보겠습니다. "주문을 취소해 줘"라는 지시를 받은 에이전트는, 온톨로지가 있다면 "주문"이 무엇을 가리키는지, 취소에 의해 "제품", "청구"와의 관계가 어떻게 변하는지, 그리고 자신에게 그 조작 권한이 있는지를 정의에 기반하여 판단할 수 있습니다. 정의가 없다면 에이전트는 문서의 기술 내용으로부터 매번 추측해야 하므로 동작이 불안정해집니다. 에이전트의 활용이 확산될수록 온톨로지는 정밀도 향상의 수단을 넘어, 안전하게 업무를 맡기기 위한 전제 조건에 가까워질 것입니다.

3-3. 도입 시 주의사항

효과와 함께 제약 사항도 파악해 둡니다.

• 적용 영역을 선택할 것: OG-RAG 논문 자체에서도 효과를 발휘하는 영역은 사실에 기반한 추론이 중심이며, 업무 규칙이나 절차를 정의할 수 있는 영역이라고 명시하고 있습니다. 정의가 어려운 비정형 업무까지 처음부터 확장하지 않는 것이 중요합니다.
• 유지 관리 체계를 결정한 후 시작할 것: 업무가 변하면 개념과 관계도 변합니다. 정의 파일의 오너(업데이트 책임자)와 검토 타이밍을 정하지 않고 만들면, 실태와 동떨어진 정의가 계속 남게 됩니다.
• 명칭 통합(Entity Resolution)은 지속적인 운영이 필요함: 별칭은 도입 후에도 현장에서 계속 발견됩니다. "발견한 사람이 aliases에 추가를 요청한다"와 같은 가벼운 운영 루트를 마련해 두면, 정의가 현장의 언어를 따라갈 수 있습니다.

4. 요약 및 결론

본 기사의 요점을 정리합니다.

• 온톨로지란 업무의 개념과 관계를 기계가 다룰 수 있는 형태로 정의한 것입니다. 데이터 그 자체가 아니라, 데이터의 의미를 정하는 규칙에 해당합니다.
• 기존 RAG의 약점(표기 불일치, 관계 추적 불가, 전체 횡단 질문)을 구조적으로 해결합니다. Microsoft의 연구에 따르면, 온톨로지로 검색을 뒷받침함으로써 사실 재현율이 55% 향상되고 답변의 정확도가 40% 개선되었으며, 지식 그래프 (Knowledge Graph)를 사용하는 수법으로는 전체를 횡단하는 질문에도 답할 수 있게 되었다고 보고되었습니다.
• 최소 구성은 "개념 5~10개 + 별칭 + 관계"부터 시작할 수 있습니다. YAML 정의 파일과 실체(Entity), 별칭(Alias), 관계(Relation), 문서(Document), 매핑(Mapping)의 5개 테이블을 통해 기존 RAG에 의미론적 전처리를 추가할 수 있습니다.
• 구축은 LLM에게 초안을 만들게 하고 사람이 확정하는 분담 방식이 현실적입니다. 나아가 AI 에이전트 시대에는 온톨로지가 업무의 전체상, 허용된 조작 범위, 인간과 AI의 공통 언어라는 세 가지 역할도 담당하게 됩니다.

참조 정보 시점: 본 기사에서 인용한 논문 및 기사는 2026년 7월 13일 시점에서 참조한 내용을 바탕으로 합니다. 연구 동향은 업데이트되므로 최신 정보는 기사 말미의 참고문헌을 확인해 주시기 바랍니다.

마치며

저희는 단순히 시스템을 구축하기만 하는 개발 회사가 아닙니다. 저비용 고품질의 AI 도구 구축부터 ROI (투자 대비 효과)를 극대화하는 도입 로드맵 책정, 사내 스태프가 직접 AI를 운영하고 개선할 수 있는 체계 구축까지, AI 도입 성공에 필요한 모든 과정을 처음부터 끝까지 통합적으로 지원합니다.

사실, 상담을 요청하시는 분들의 대부분은 "무엇을 모르는지도 모르는" 상태에서 시작합니다. 구상 단계에서도 단순한 아이디어 베이스여도 상관없습니다.

먼저, 귀하의 고민을 있는 그대로 들려주시지 않겠습니까? 귀사의 비즈니스를 가속화하는 파트너로서 함께하겠습니다.

무료 온라인 상담으로 최적의 도입 플랜을 상담하기

참고 문헌

• Kartik Sharma, Peeyush Kumar, Yunqing Li (Microsoft) 「OG-RAG: Ontology-Grounded Retrieval-Augmented Generation For Large Language Models」 (2026년 7월 13일 참조)
• Darren Edge 외 (Microsoft Research) 「From Local to Global: A Graph RAG Approach to Query-Focused Summarization」 (2026년 7월 13일 참조)
• Haonan Bian 「LLM-empowered Knowledge Graph Construction: A Survey」 (2026년 7월 13일 참조)
• Thomas R. Gruber 「A Translation Approach to Portable Ontology Specifications」 (2026년 7월 13일 참조)
• Yamaguchi Natsuo · Komlock lab (Zenn) 「온톨로지(Ontology)란 무엇인가」 (2026년 7월 13일 참조)

Discussion