온톨로지 개념 잡기: APP 서비스의 데이터를 똑똑하게 연결하는 방법

온톨로지 개념 잡기

APP 서비스의 데이터를 똑똑하게 연결하는 방법

앱에 데이터가 많다고 검색이 잘 되는 것은 아닙니다.

어떤 곳에서는 회원, 다른 곳에서는 고객, 또 다른 곳에서는 사용자라고 부르면 같은 사람을 찾는 일부터 어려워집니다. 주문, 결제, 오류의 관계도 정리되어 있지 않다면 검색 결과를 다시 사람이 읽고 연결해야 합니다.

이 문제를 해결하는 출발점이 온톨로지입니다.

온톨로지는 “무엇이 있고, 서로 어떤 관계인지”를 정해 둔 데이터의 약속입니다.

1. 분류표·온톨로지·지식 그래프의 차이

세 단어를 간단히 나누면 이렇습니다.

• 분류표: 무엇이 어떤 종류인지 나눕니다. 상품, 주문, 결제처럼 메뉴를 정하는 일입니다.
• 온톨로지: 그 대상의 의미와 관계를 정합니다. APP 서비스는 결제 기능을 제공한다처럼 연결 방법을 약속합니다.
• 지식 그래프: 실제 대상을 연결해 둔 결과입니다. 쇼핑 앱 A는 결제 기능을 제공한다처럼 구체적인 사실이 들어갑니다.

책장으로 비유하면 분류표는 책을 분야별로 나누는 표이고, 온톨로지는 “저자는 책을 쓴다” 같은 관계의 규칙입니다. 지식 그래프는 실제 책과 저자와 주제를 연결한 목록입니다.

2. 일반적인 APP 서비스로 이해하기

특정 제품이 아니라 어느 쇼핑 APP 서비스라고 생각해 보겠습니다.

APP 서비스 ── 제공한다 ──> 결제 기능
결제 기능 ── 처리한다 ──> 주문
주문 ── 발생시킨다 ──> 결제 이벤트
결제 이벤트 ── 확인한다 ──> 오류·장애
오류·장애 ── 대응한다 ──> 담당자·처리 방법

이렇게 연결해 두면 단순히 “결제”라는 단어가 들어간 문서를 찾는 데서 끝나지 않습니다.

• 이 오류는 어떤 기능에서 발생했는가?
• 영향을 받은 주문은 무엇인가?
• 누가 처리하는가?
• 비슷한 과거 장애와 해결 방법은 무엇인가?

처럼 관계를 따라 질문할 수 있습니다.

3. 온톨로지를 이루는 네 가지

클래스: 어떤 종류인가

APP 서비스, 기능, 주문, 장애처럼 대상을 묶는 큰 범주입니다.

인스턴스: 실제 대상은 무엇인가

쇼핑 앱 A, 결제 기능, 주문번호 1001처럼 실제로 기록되는 대상입니다.

쉽게 말하면 앱 서비스는 종류이고, 쇼핑 앱 A는 그 종류에 속한 실제 대상입니다.

속성: 어떤 값을 가지는가

버전, 상태, 담당자, 발생 시각, 처리 완료 여부처럼 대상에 붙는 정보입니다.

결제 오류 ── 발생 시각 ──> 2026-08-31 10:30
결제 오류 ── 상태 ──────> 처리 중
결제 기능 ── 담당 조직 ──> 운영팀

관계: 무엇과 무엇이 연결되는가

제공한다, 사용한다, 처리한다, 발생시킨다, 대응한다처럼 동사로 적으면 의미가 분명해집니다.

관련 있음 하나로 모든 것을 연결하면 그래프는 커지지만, 왜 연결됐는지 설명하기 어려워집니다.

4. RDF·OWL·SKOS·SHACL·PROV는 무엇인가

어려운 이름을 한꺼번에 외울 필요는 없습니다. 각각 맡은 일이 다릅니다.

• RDF: 주어-관계-대상 형태로 데이터를 연결하는 기본 표현입니다. 예: 쇼핑 앱 A - 제공한다 - 결제 기능.
• OWL: 클래스와 관계의 의미를 더 자세히 정의하고, 정해 둔 규칙으로 추가 정보를 추론합니다.
• SKOS: 분류표, 동의어, 상위·하위 카테고리를 관리하는 데 적합합니다.
• SHACL: 데이터에 필요한 항목이 들어 있는지 검사합니다. 예: 장애에는 발생 시각과 상태가 있는가?
• PROV-O: 이 정보가 어디에서 왔고, 언제 만들어졌으며, 누가 처리했는지 기록합니다.

W3C의 RDF 1.1 문서는 RDF의 기본 단위를 subject·predicate·object triple로 설명합니다. OWL 2 Primer는 클래스·속성·개체와 추론을, SKOS Reference는 지식 분류체계를 다룹니다. 데이터 검증은 SHACL, 출처와 처리 과정은 PROV-O에서 확인할 수 있습니다.

5. LLM 지식베이스에서 왜 중요한가

LLM에게 문서만 많이 보여 주면 그럴듯한 답은 만들 수 있어도, 대상과 관계를 정확히 짚기 어려울 수 있습니다.

온톨로지를 함께 사용하면 질문을 다음 순서로 좁힐 수 있습니다.

질문
 ↓
권한·개인정보 범위 확인
 ↓
대상과 관계 찾기
 ↓
관련 문서 검색
 ↓
출처·기준일·검증 상태 확인
 ↓
근거를 보여 주는 답변

여기서 가장 중요한 원칙은 기록되지 않은 정보와 틀린 정보를 구분하는 것입니다. 문서에 없다고 해서 반드시 거짓은 아닙니다. 아직 확인하지 않은 것일 수 있습니다.

그래서 지식베이스에는 다음 상태를 따로 적는 것이 좋습니다.

• 확인 전
• 검증 필요
• 확인됨
• 해당 없음

그리고 개인 기록, 회사 자료, 누구나 볼 수 있는 일반 지식을 검색 단계부터 구분해야 합니다.

6. 처음 만드는 사람을 위한 가장 쉬운 시작법

처음부터 거대한 온톨로지를 만들 필요는 없습니다.

1. 반복해서 받는 질문 5개를 적습니다.
2. 질문에 나오는 대상 5~8개만 고릅니다. 예: 서비스, 기능, 사용자, 주문, 이벤트, 장애, 담당자.
3. 관계를 동사로 5개 정도 정합니다. 예: 제공한다, 사용한다, 발생시킨다, 대응한다, 담당한다.
4. 각 정보에 출처와 기준일을 붙입니다.
5. 실제 질문을 다시 던져 검색과 답변이 좋아졌는지 확인합니다.

작게 시작하면 잘못 정한 분류나 관계를 쉽게 고칠 수 있습니다. 사용하지 않는 클래스와 관계를 미리 많이 만들수록 관리 비용만 커집니다.

7. 자주 하는 실수

• 그래프를 그렸으니 온톨로지가 완성됐다고 생각하기
• 모든 관계를 관련 있음으로 적기
• 상품이라는 종류와 쇼핑 앱 A라는 실제 대상을 섞기
• 출처와 날짜 없이 사실처럼 기록하기
• 검색 결과를 보여 준 뒤에야 권한을 확인하기
• AI가 추론한 내용을 원문에서 확인된 사실처럼 쓰기

온톨로지는 AI의 정답을 보장하는 마법이 아닙니다. 사람들이 같은 단어를 같은 의미로 쓰고, 데이터 사이의 연결을 반복해서 재사용하도록 돕는 약속입니다.

마무리

온톨로지를 한 문장으로 다시 정리하면 이렇습니다.

분류표가 “무엇인가”를 알려 준다면, 온톨로지는 “무엇과 어떻게 연결되는가”를 알려 줍니다.

처음에는 APP 서비스의 사용자-주문-결제-오류-담당자 정도만 연결해도 충분합니다. 여기에 출처와 기준일을 붙이고, 실제 질문으로 확인하면 검색은 단순한 단어 찾기에서 관계를 이해하는 도구로 발전합니다.

참고 링크

• W3C — RDF 1.1 Concepts and Abstract Syntax
• W3C — OWL 2 Web Ontology Language Primer
• W3C — SKOS Reference
• W3C — Shapes Constraint Language (SHACL)
• W3C — PROV-O: The PROV Ontology