🧠 레슨

온톨로지 기초 — 데이터에 의미의 지도 붙이기

개체 타입·속성·관계·식별자·카디널리티로 AI가 업무 데이터를 이해하는 구조를 잡는다.

① 오늘의 질문

온톨로지는 AI에게 주는 업무 세계의 지도입니다

이번 참고 자료는 Ontology Playground의 온톨로지 기초 학습 경로입니다. 온톨로지를 “멋진 그래프 그림”이 아니라, 사물의 종류·속성·관계를 기계가 읽을 수 있게 정리한 설계도로 설명합니다.

AI 심화 트랙에서는 이걸 에이전트·RAG·업무 자동화의 관점으로 가져옵니다. LLM이 자연어를 잘 다루더라도, 회사 업무에서는 “고객”, “주문”, “환불”, “상품”이 무엇이고 서로 어떻게 연결되는지를 별도로 잡아줘야 합니다.

한 문장으로

온톨로지는 데이터 자체가 아니라, 데이터가 어떤 모양이어야 하는지 알려주는 의미의 스키마입니다.

📚 「온톨로지 기초 — 데이터에 의미의 지도 붙이기」 레슨 내용 전체 텍스트로 훑어보기

온톨로지는 AI에게 주는 업무 세계의 지도입니다

한 문장으로

온톨로지는 데이터 자체가 아니라, 데이터가 어떤 모양이어야 하는지 알려주는 의미의 스키마입니다.

온톨로지의 역할로 가장 알맞은 설명은 무엇일까요?

맞아요. 온톨로지는 데이터 그 자체가 아니라 데이터의 형태와 의미를 정의합니다. Customer, Order, Product가 있고, Customer가 Order를 만들고, Order가 Product를 포함한다는 식의 지도를 제공합니다.

온톨로지를 어렵게 시작하지 말고 커피숍 예시로 보면 됩니다.

Fourth Coffee로 보기

개체 타입(Entity type): Customer, Product, Store, Order처럼 사물의 범주
속성(Property): Customer.name, Product.price, Order.totalAmount처럼 개체에 붙은 사실
관계(Relationship): Customer → places → Order, Order → contains → Product처럼 개체 사이의 연결

여기서 중요한 것은 “컬럼명이 있다”가 아니라, 이 컬럼이 어떤 비즈니스 개념의 어떤 속성인지를 이름 붙이는 것입니다.

둘 다 구조를 다루지만 초점이 다릅니다.

관계형 DB 스키마: 테이블, 컬럼, 타입, 외래키 중심이다. 저장과 조회의 물리적 구조에 가깝다. 예: orders.customer_id → customers.id.

온톨로지 / 시맨틱 모델: 사람이 말하는 업무 개념과 관계 중심이다. 자연어 질의·에이전트 검증·GraphRAG 판단에 쓰기 좋다. 예: Order → placedBy → Customer.

온톨로지에서 초보자가 놓치기 쉬운 두 가지가 식별자(identifier)와 카디널리티(cardinality)입니다.

식별자: 각 인스턴스를 고유하게 구분하는 열쇠입니다. 고객은 customerId, 책은 isbn, 주문은 orderId처럼 잡습니다.
카디널리티: A 하나가 B 몇 개와 연결될 수 있는지입니다. Customer → Order는 보통 일대다, Order → Store는 다대일입니다.

AI에게 왜 필요할까?

“고객당 주문 수”를 묻는 순간 AI는 Customer와 Order의 관계 방향, 그리고 한 고객이 여러 주문을 가질 수 있다는 사실을 알아야 합니다. 이게 없으면 조인과 집계가 흔들립니다.

어떤 쇼핑몰에서 관계를 이렇게 정의했다고 해봅시다.

Customer → places → Order 를 일대일(One-to-one)로 설정했다.

가장 큰 문제는 무엇일까요?

정답입니다. 카디널리티는 단순 표기가 아니라 AI가 집계를 만드는 기준입니다. 고객 하나가 여러 주문을 할 수 있다면 일대다로 잡아야 “고객별 주문 수”, “고객별 총 매출” 같은 질문이 자연스럽게 됩니다.

참고 자료는 RDF/OWL도 소개합니다. 이름이 어렵지만 역할은 단순하게 잡으면 됩니다.

RDF/OWL 감각

RDF: 주어 → 술어 → 목적어, 즉 트리플로 지식을 표현합니다.
OWL: RDF 위에 클래스 계층, domain/range, 카디널리티, 제약 같은 더 강한 모델링을 얹습니다.

Product rdf:type owl:Class, price rdfs:domain Product, price rdfs:range xsd:decimal 같은 식으로 “Product라는 클래스가 있고 price는 Product의 숫자 속성이다”를 기계가 읽게 합니다.

다만 우리 수강생이 XML을 손으로 외울 필요는 없습니다. 핵심은 그래프적 의미 구조가 표준 포맷으로 내보내질 수 있다는 감각입니다.

도서관 온톨로지를 만든다면 어떤 순서가 자연스러울까요?

좋습니다. 온톨로지는 큰 철학 프로젝트가 아니라, 좁은 업무 범위를 잡고 개체·속성·관계를 반복해서 명확하게 만드는 작업입니다.

자연어 질의와 에이전트 검증에서는 이름이 중요합니다.

나쁜 이름: tbl_cust_v2, amt, dt, relatedTo, thing처럼 내부 사정이나 축약어가 먼저 보인다. 사람이 질문하는 말과 멀어진다.

좋은 이름: Customer, totalAmount, createdDate, placedBy, contains처럼 업무 사람이 실제로 쓰는 단어에 가깝다. AI가 자연어를 구조로 바꾸기 쉬워진다.

아래 중 온톨로지/시맨틱 모델을 비교적 먼저 검토할 만한 경우는 무엇일까요?

맞아요. 온톨로지는 모든 문제의 출발점이 아니라, 의미가 반복되고 합의되어야 하는 좁은 영역에서 강합니다. 그래서 앞선 ‘온톨로지가 필요 없는 순간’ 레슨과 함께 봐야 균형이 잡힙니다.

이번 레슨의 핵심을 한 줄로 정리해봅시다.

정답입니다. 온톨로지는 데이터가 어떤 개체·속성·관계로 이해되어야 하는지 정의합니다. 이 구조가 있어야 AI가 자연어 질문을 더 안정적으로 쿼리나 검증 규칙으로 바꿀 수 있습니다.

이 참고 자료는 기본에도 넣을 수 있지만, 지금은 AI 심화 트랙의 온톨로지 묶음에 두는 게 좋습니다.

앞으로 볼 에이전트와 온톨로지 레슨의 기초 어휘를 제공합니다.
온톨로지가 필요 없는 순간 레슨과 짝을 이뤄 “쓸 때/안 쓸 때”를 판단하게 합니다.
RAG, GraphRAG, 지식그래프, 업무 규칙 검증을 한 덩어리로 사지 않도록 분해하는 기준이 됩니다.

참고 출처

Ontology Playground — 온톨로지 기초 학습 경로
https://ontologystudy.vercel.app/#/learn/ontology-fundamentals