온톨로지는 “멋진 지식 그래프”가 아니라 팀의 공통 언어다

온톨로지라는 말을 들으면 보통 머리가 아파집니다. 철학 용어 같고, 지식 그래프 논문 같고, “의미론적 관계” 같은 말이 따라붙습니다. 그런데 실무에서 온톨로지는 훨씬 단순하게 봐도 됩니다.

온톨로지는 우리 서비스에서 쓰는 단어의 뜻과 관계를 정리한 표입니다.

예를 들어 고객지원 AI를 만든다고 합시다. 여기서 “환불”, “취소”, “교환”, “반품”, “클레임”은 비슷해 보이지만 다릅니다. 사용자는 “주문 취소하고 싶어요”라고 말했는데 이미 배송이 시작됐다면, 시스템 입장에서는 취소가 아니라 반품 프로세스가 됩니다. 이 차이를 LLM에게 매번 프롬프트로 설명하면 언젠가 틀립니다. 그래서 단어의 뜻과 관계를 따로 정리해야 합니다. 그게 온톨로지의 시작입니다.

온톨로지가 필요한 순간

아래 문제가 반복되면 온톨로지가 필요합니다.

1. 팀마다 같은 단어를 다르게 쓴다.
2. 검색 결과가 키워드는 맞는데 의미는 틀린다.
3. RAG가 문서를 잘 찾아도 답변이 업무 규칙과 어긋난다.
4. LLM이 “그럴듯한 답”은 하는데 상태, 조건, 예외를 자주 놓친다.
5. 데이터베이스 필드명과 사람이 쓰는 말이 다르다.

이 문제는 모델을 바꾼다고 잘 해결되지 않습니다. 모델은 언어를 잘 다루지만, 회사 내부의 단어가 어떤 업무 규칙을 뜻하는지는 모릅니다.

아주 작은 예시

쇼핑몰 도메인이라면 이렇게 시작할 수 있습니다.

개념: 주문
- 속성: 주문번호, 결제상태, 배송상태, 주문일
- 관계: 주문은 여러 개의 상품을 가진다
- 관계: 주문은 하나의 고객에게 속한다

개념: 취소
- 조건: 결제 완료 후 배송 시작 전까지 가능
- 결과: 결제 승인 취소
- 취소 불가 시: 반품 프로세스로 안내

개념: 반품
- 조건: 배송 완료 후 일정 기간 내 가능
- 결과: 상품 회수 후 환불 심사

이 정도만 있어도 AI 답변 품질이 달라집니다. “취소”와 “반품”을 같은 말로 뭉개지 않기 때문입니다.

온톨로지와 일반 문서의 차이

일반 문서는 사람이 읽기 좋습니다. 온톨로지는 시스템이 헷갈리지 않기 좋습니다.

문서에는 이렇게 적힙니다.

배송이 시작된 주문은 취소할 수 없으며, 고객은 반품 신청을 해야 합니다.

온톨로지에는 이렇게 쪼갭니다.

배송상태 = 배송전 -> 취소 가능
배송상태 = 배송중 또는 배송완료 -> 취소 불가
취소 불가 사유 = 배송 시작
대체 액션 = 반품 신청

LLM에게 필요한 건 두 가지입니다. 사람이 읽는 설명과, 판단에 쓰는 구조화된 규칙입니다. 둘 중 하나만 있으면 답변이 흔들립니다.

처음부터 거창하게 만들지 마세요

온톨로지를 만들 때 가장 흔한 실패는 처음부터 전사 지식 그래프를 만들려는 겁니다. 그렇게 하면 회의만 길어지고 아무것도 못 씁니다.

작게 시작하는 게 맞습니다.

1. AI가 자주 틀리는 질문 20개를 모읍니다.
2. 그 질문에 등장하는 핵심 명사를 뽑습니다.
3. 비슷하지만 다른 단어를 구분합니다.
4. 각 단어에 “조건”, “상태”, “예외”, “다음 액션”을 붙입니다.
5. RAG 답변 전에 이 표를 먼저 참고하게 합니다.

고객지원이면 환불, 취소, 반품부터 시작하면 됩니다. 병원 예약이면 진료, 검사, 수납, 예약변경부터 시작하면 됩니다. 투자 서비스면 종목, 포트폴리오, 리밸런싱, 리스크부터 시작하면 됩니다.

LLM에 어떻게 붙이나

가장 쉬운 방식은 “도메인 사전”으로 붙이는 겁니다.

사용자 질문: 배송 시작했는데 주문 취소 가능해요?

참고할 도메인 규칙:
- 취소: 배송 시작 전까지만 가능
- 배송중 주문: 취소 불가, 반품 프로세스 안내
- 반품: 배송 완료 후 신청 가능

답변 지침:
- 취소 가능 여부를 먼저 말한다
- 불가능하면 이유를 말한다
- 다음 액션을 안내한다

이렇게만 해도 답변은 훨씬 덜 흔들립니다. 더 발전시키면 개념과 관계를 그래프 DB에 넣고, 질문과 관련된 노드만 꺼내 프롬프트에 넣을 수 있습니다.

좋은 온톨로지의 기준

좋은 온톨로지는 멋있어 보이지 않습니다. 대신 실무자가 보면 “아, 이거 때문에 AI가 덜 틀리겠네”라는 느낌이 듭니다.

체크리스트는 이렇습니다.

• 같은 단어가 여러 의미로 쓰이는 문제를 줄였는가
• 상태에 따라 답이 달라지는 조건을 적었는가
• 예외 상황을 따로 적었는가
• 사람이 바로 수정할 수 있는 형태인가
• LLM 프롬프트나 RAG 파이프라인에 쉽게 넣을 수 있는가

온톨로지는 AI 시대의 문서 정리가 아닙니다. 더 정확히는 AI가 회사의 말을 오해하지 않게 만드는 번역표입니다.

지금 할 일

새 도구부터 고르지 마세요. 먼저 스프레드시트 하나를 만드세요.

컬럼은 이 정도면 충분합니다.

개념 | 쉬운 설명 | 비슷하지만 다른 개념 | 조건 | 예외 | 다음 액션 | 참고 문서

그리고 AI가 자주 틀리는 질문부터 채우세요. 30개만 정리해도 RAG 답변 품질이 눈에 띄게 좋아집니다.