온톨로지, 쉽게 이해하기

개념, 관계, 어휘, 규칙. 그리고 직접 돌려 본 데모

LLM은 왜 우리 데이터 앞에서 틀릴까

사람이 쓰는 말과 시스템에 저장된 값 사이의 세 가지 간극

고객 (또는 직원)의 질문"미국국채 ETF 중에 보수가 제일 싼 거 뭐예요?"

상품 원장에 실제로 저장된 값ast_cls = 'BD_OVS_GOV'
rgn_cd = 'US'
fee_bp = 5

말의 간극

"미국국채", "미국채", "US Treasury"는 같은 것. DB에는 BD_OVS_GOV 하나뿐입니다.

관계의 간극

미국국채는 해외국채이고, 해외국채는 채권입니다. 이 계층은 테이블 어디에도 적혀 있지 않습니다.

상식의 간극

"보수"는 fee_bp이고 단위는 bp(0.01%p). 담당자는 알지만 DB는 말해 주지 않습니다.

온톨로지 = 개념, 관계, 규칙의 약속

탭을 눌러 은행 예시로 확인

무엇이 있는가

업무에 등장하는 "종류"를 정합니다. 종류(클래스)와 그 종류에 속하는 실제 하나하나(인스턴스)를 구분합니다.

비유: 사전의 표제어

고객계좌상품자산분류운용사

클래스 고객의 인스턴스: 홍길동, 김민지 ...
클래스 상품의 인스턴스: SKY 미국채10년, RIVER 코스피200 ...

어떻게 이어지는가

개념과 개념 사이에 이름 붙은 연결을 정합니다. 방향이 있고, 어떤 종류끼리 이어지는지도 정합니다.

비유: 지도의 길

고객 보유 계좌
계좌 편입 상품
상품 자산분류 자산분류
상품 브랜드 브랜드, 브랜드 운용사 운용사

무엇은 반드시 지켜지는가

항상 참이어야 하는 제약과 업무 규칙입니다. 모델이 추측하지 않도록 시스템이 강제할 수 있습니다.

비유: 규정집

상위, 하위: 미국국채는 해외국채이고, 해외국채는 채권이다
단일값: 상품의 자산분류는 하나뿐이다
상호배타: 주식이면서 채권일 수는 없다
업무 규칙: "배당"은 분배율로 비교한다

모든 지식을 세 단어 문장으로

주어, 관계, 목적어(트리플)를 하나씩 쌓으면 지식 그래프

버튼을 눌러 트리플을 하나씩 쌓아 보세요.

실선 테두리: 인스턴스(실제 하나)
점선 테두리: 클래스(개념, 종류)
모든 이름과 계좌는 가상 예시

계층이 있으면 "채권"이 저절로 풀린다

개념을 누르면 하위 개념과 해당 상품까지 함께 포함

개념 노드를 눌러 보세요예: "채권 ETF 보여줘". DB에 "채권"이라는 값은 없지만 계층을 따라가면 상품까지 이어집니다.

점선 테두리: 개념(클래스), 실선: 상품(인스턴스). 데모용 가상 ETF 22개 중 이 계층에 연결된 20개만 표시

사람의 말을 DB 값으로 확정하는 사전

대표 이름(prefLabel), 별칭(altLabel), 실제 값을 한 개념에 묶는 어휘(SKOS)

# etf_ontology.ttl (데모에 실제로 쓴 파일 일부)
ex:BdUSGov  a skos:Concept ;
    skos:broader   ex:BdOvsGov ;        # 상위: 해외국채
    skos:prefLabel "미국국채" ;
    skos:altLabel  "미국채", "미 국채", "US Treasury" ;
    ex:sqlFilter   "ast_cls = 'BD_OVS_GOV' AND rgn_cd = 'US'" .

# 업무 상식 (Semantic Layer)
ex:RuleFee  ex:trigger "보수" ;
    rdfs:comment "fee_bp 단위는 bp(1bp = 0.01%p)다. 0.1% = 10bp." .

질문 속 말: "미 국채 ETF 중 보수가 낮은 것"

사전 조회 (LLM 호출 없음)

개념 확정: 미국국채 (상위: 해외국채, 채권)

개념에 붙은 값

조건 확정: ast_cls = 'BD_OVS_GOV' AND rgn_cd = 'US', 규칙: 보수는 fee_bp(bp)

사전에 없는 말이면 추측하지 않고 되묻습니다. 미래에셋증권은 vocabulary.ttl로 같은 일을 합니다.

온톨로지가 에이전트에서 일하는 네 자리

질문이 들어와서 답이 나가기까지, 모델이 추측하던 일을 하나씩 결정적으로

질문 들어옴근거와 함께 답 나감

의도 이해

"결제 취소"와 "결제 실패"처럼 비슷한 의도를 속성으로 쪼개 구분

신한카드: Domain, Action, Tag 3속성 인텐트 온톨로지

값 확정

사용자의 말을 DB에 있는 실제 값으로 바꾸고, 못 바꾸면 되묻기

미래에셋증권: Ontology Grounding, vocabulary.ttl

관계 탐색

여러 관계를 따라가야 답이 나오는 질문을 그래프 조회로

미래에셋증권: Neptune 관계, 시점 조회 / 5부 데모 앱: multi-hop

규칙 강제

단위, 금지 조건, 업무 상식을 모델 대신 시스템이 적용

미래에셋증권: Semantic Layer / Canva: 결정론적 도구

벡터 검색, 지식 그래프, 온톨로지는 층이다

경쟁이 아니라 역할 분담, 미래에셋증권은 세 가지를 동시에 조회

벡터 검색 (RAG)

저장: 문서 조각과 그 의미 벡터
잘함: 비슷한 내용 찾기
약함: 정확한 값, 개수, 연결

예: "요즘 주목받는 테마 설명해줘"
미래에셋: OpenSearch 의미 검색

지식 그래프

저장: 개체와 관계(트리플)
잘함: 여러 단계로 이어진 사실
약함: 말이 다르면 시작점을 못 찾음

예: "이차전지 테마에 속한 ETF"
미래에셋: Neptune 관계 조회

온톨로지

저장: 개념, 관계, 어휘, 규칙의 약속
잘함: 말과 값을 잇고 규칙을 강제
역할: 위 두 저장소를 어떻게 쓸지 정함

예: "미국국채"를 'BD_OVS_GOV'로 확정
미래에셋: Grounding, Semantic Layer

정리: 온톨로지는 저장소라기보다 설계도입니다. 그래프 DB 없이 파일과 코드로 시작해도 됩니다(다음 데모가 그렇게 만들었습니다).

AWS에서는 무엇으로 만드나

작게는 파일과 코드, 커지면 그래프 DB와 관리형 GraphRAG

파일과 코드로 시작 PoC 1~2주

개념, 별칭, 규칙을 TTL이나 YAML 파일로 두고, 확정 로직은 도구 함수로. 오늘 D1 데모와 미래에셋증권 YAML 규칙표가 이 방식입니다.

Amazon Neptune

관리형 그래프 DB. 속성 그래프(Gremlin, openCypher)와 RDF(SPARQL)를 모두 지원. 관계와 multi-hop 조회가 많아질 때.

Bedrock Knowledge Bases GraphRAG

S3 문서에서 엔터티와 관계를 자동으로 뽑아 Neptune Analytics 그래프로. 벡터 검색 결과를 그래프로 넓혀 답합니다.

GraphRAG Toolkit (오픈소스)

그래프 구축과 검색을 직접 설계하고 싶을 때. 미래에셋증권은 Phase 1에서 이 도구로 Ontology, ER, Search 방법론을 검증했습니다.

출처: Amazon Neptune 문서(What is Amazon Neptune), Bedrock 문서(Build a knowledge base with Amazon Neptune Analytics graphs). GraphRAG는 2026-10-21 문서 기준 서울 리전 목록에 없음: 도입 전 리전 확인 필요

D1 데모: 같은 모델, 세 가지 입력

미래에셋증권 실험을 작게 재현: 가상 ETF 22개, 질문 12개, Claude Haiku 4.5

스키마만

테이블 DDL과 컬럼 주석
지금 많은 Text-to-SQL이 이 상태

온톨로지를 설명

A + 클래스, 관계, 계층, 별칭을 글로 설명
"프롬프트에 온톨로지를 넣었다"

C온톨로지로 확정
B + 사전 조회로 확정한 DB 조건과 업무 규칙
사전에 없는 상품 분류는 되묻기

측정 방법: 질문마다 모드별 1회 호출(temperature 0), 생성 SQL을 실행해 정답 SQL 결과와 같은지 비교. 원장 값은 코드(BD_OVS_GOV, T_BATT), 보수는 bp 단위. 모든 데이터는 가상, 1회 실행, 2026-10-21

D1 영상: 설명할 때와 확정할 때

0:00원장은 코드값으로 저장

0:08어휘: 미국국채의 별칭과 DB 조건

0:14질문 하나를 A, B, C로: A와 B는 빈 결과

0:22질문 12개 전체 실행과 점수

0:53사전에 없는 말: 되묻기

실제 터미널 녹화(2026-10-21), Amazon Bedrock 호출, 무음. 2초 넘는 대기는 2초로 줄임

설명은 값이 아니다: 50%, 33%, 92%

D1 결과(12문항, 1회)와 미래에셋증권 결과(72문항)의 같은 방향

A 스키마만

6/12

B 온톨로지 설명

4/12

C 온톨로지 확정

11/12

참고, 미래에셋증권(국내 ETF 72문항): 스키마만 45%, 온톨로지를 프롬프트에 설명 47.4%, 값 확정 65%, 연합 검색과 Semantic Layer까지 84.7%

설명을 주면 오히려 헷갈린다

B는 개념 이름을 DB 값처럼 썼습니다: thm_cd IN ('미국국채', 'US Treasury', ...)

확정은 같은 모델을 바꾼다

단위(0.1% = 10bp), 계층, 별칭이 조건으로 들어가자 11개를 맞혔습니다.

사전에 없는 말은 되묻는다

C의 오답 1건은 "코스피200"이 사전에 없어 되물은 경우. 사전 범위가 곧 성능입니다.

온톨로지가 늘 이기지는 않는다

D2: 신한카드식 3속성 인텐트 분류를 소형 모델로 재현해 본 결과

회차	A 목록에서 직접 선택	B 3속성 + 그래프 매칭
1차: 속성 정의 초안	24/40 (60.0%)	23/40 (57.5%)
2차: 설명과 속성 정의 수정	40/40 (100%)	24/40 (60.0%)

Amazon Nova Micro, 가상 인텐트 20개(Domain 4, Action 5, Tag 8), 가상 발화 40개, 1회 실행, 2026-10-21. 발화를 설명과 같은 사람이 만들어 쉬운 편

정의가 모호하면 둘 다 무너진다

"한도 올려줘"가 신청인지 변경인지 정하지 않은 1차에서는 두 방식 모두 60% 안팎

작은 규모에서는 직접 선택이 낫다

20개, 설명이 분명하면 소형 모델도 목록에서 바로 고릅니다. 속성 3개를 따로 고르면 오류가 곱해집니다.

신한카드의 조건을 기억하기

51개로 잘게 나뉜 의도, 문맥이 비슷한 쌍, 규제와 비용 때문에 소형 모델만 쓸 수 있는 조건에서 보고된 효과입니다.

온톨로지, 이렇게 작게 시작하세요

미래에셋증권의 순서를 8주 PoC 크기로 줄이면

STEP 1

답해야 할 질문부터

실제 질문 30~50개를 모으고, 정답과 근거를 붙입니다. 이것이 평가셋이 됩니다.

미래에셋: 온톨로지가 답할 질문 목록을 먼저 뽑음

STEP 2

질문에 나온 개념만

질문에 등장한 개념과 관계만 정의합니다. 처음부터 전사 모델을 그리지 않습니다.

예: 상품, 자산분류, 운용사, 계층 3단계

STEP 3

별칭 사전과 규칙

현업이 쓰는 말과 DB 값을 잇고, 담당자의 상식을 규칙으로 적습니다.

예: 미국채는 미국국채, 0.1%는 10bp

STEP 4

측정하고 보강

평가셋으로 단계마다 점수를 재고, 되묻기와 실패 로그로 사전을 채웁니다.

D1: "코스피200" 되묻기가 다음 보강 대상

과제 연결: TASK 01 마이데이터(상품, 자산 용어), TASK 05 운영지식 위키(시스템명, 장애 용어), TASK 04 서류 점검(서류 유형, 필수 항목)이 특히 효과가 큽니다.