[개인 공부] 온톨로지(Ontology): 개념 정리, 프로젝트 적용 계획

안녕하세요! 오늘은 온톨로지에 대해 공부한 내용을 공유하려고 합니다.

처음 온톨로지라는 단어를 접했을 때, 철학 용어인 줄 알았다. 실제로 맞다. 그런데 이 개념이 컴퓨터 과학, 특히 AI와 데이터 분야에서 핵심적인 역할을 하고 있다는 걸 알게 되면서 제대로 정리해보고 싶었습니다.

---

1. 온톨로지란 무엇인가

온톨로지는 원래 철학에서 "존재론"을 의미한다. 세상에 존재하는 것들이 무엇이고, 그것들이 어떤 관계를 맺고 있는지를 탐구하는 학문이다.

그런데 이걸 컴퓨터 과학으로 가져오면 의미가 조금 구체적으로 바뀐다. 컴퓨터 과학에서의 온톨로지는 특정 도메인(영역) 내의 개념들과 그 개념들 사이의 관계를 명시적이고 형식적으로 정의한 모델이다.

쉽게 말하면 이렇다. 사람이 "사과"라고 하면 과일인지, 회사(Apple)인지, 문맥에 따라 다르게 이해한다. 하지만 컴퓨터는 그런 판단을 스스로 하지 못한다. 그래서 "사과는 과일이다", "과일은 식물에서 나온다", "식물은 생물이다"처럼 개념 간의 관계를 명확하게 구조화해서 컴퓨터가 이해할 수 있도록 만들어 놓은 것, 그것이 온톨로지다.

여기서 내가 중요하다고 느낀 점은, 온톨로지가 단순한 용어 사전이나 데이터베이스 스키마가 아니라는 것이다. 용어 사전은 단어의 뜻만 나열하고, 데이터베이스 스키마는 저장 구조를 정의한다. 반면 온톨로지는 개념 간의 의미적 관계(상위-하위, 부분-전체, 인과 등)까지 표현한다. 즉, 데이터에 "의미"를 부여하는 구조인 셈이다.

---

2. 온톨로지의 핵심 구성 요소

온톨로지가 어떤 것들로 이루어져 있는지 정리하면 다음과 같다.

• 클래스(Class): 개념의 범주. 예를 들어 "동물", "차량" 같은 것이다.
• 인스턴스(Instance): 클래스에 속하는 구체적인 개체. "동물" 클래스의 인스턴스는 "내 집 고양이 나비"가 될 수 있다.
• 프로퍼티(Property): 개념의 속성이나 개념 간의 관계. "고양이는 포유류에 속한다"에서 "속한다"가 프로퍼티다.
• 제약조건(Constraint): 관계에 적용되는 규칙. "포유류는 반드시 척추동물이어야 한다" 같은 것이다.

이 요소들이 결합되면서, 단순한 데이터 나열이 아니라 지식의 구조가 만들어진다. 이 부분이 온톨로지의 핵심이라고 생각한다.

---

3. 온톨로지는 어디에서 사용되는가

처음에는 학술적인 개념이라고만 생각했는데, 실제로 온톨로지가 활용되는 분야는 생각보다 넓었다.

3-1. 시맨틱 웹(Semantic Web)

온톨로지가 가장 대표적으로 쓰이는 분야다. 팀 버너스리가 제안한 시맨틱 웹은, 웹 상의 데이터에 의미를 부여해서 기계가 데이터를 이해하고 처리할 수 있게 만드는 것이 목표다. 여기서 OWL(Web Ontology Language), RDF(Resource Description Framework) 같은 온톨로지 표현 언어가 사용된다. 웹 페이지의 정보가 단순 텍스트가 아니라 구조화된 지식이 되는 것이다.

3-2. 인공지능 / 지식 그래프

구글의 검색 엔진이 대표적인 예다. "아인슈타인의 생일"을 검색하면 단순히 키워드가 포함된 문서를 보여주는 것이 아니라, "아인슈타인 → 생년월일 → 1879년 3월 14일"이라는 지식 그래프를 기반으로 직접 답을 보여준다. 이 지식 그래프의 뼈대가 바로 온톨로지다.

3-3. 의료 / 바이오 분야

의료 분야에서는 질병, 증상, 약물, 유전자 간의 관계가 매우 복잡하다. 이걸 체계적으로 정리하기 위해 SNOMED CT, Gene Ontology 같은 대규모 온톨로지가 구축되어 활용되고 있다. 서로 다른 병원 시스템 간에 데이터를 교환할 때도 온톨로지가 중간 다리 역할을 한다.

3-4. 자연어 처리(NLP)

자연어 처리에서 단어의 의미를 파악하거나 문맥을 이해하는 데 온톨로지가 활용된다. 예를 들어 챗봇이 사용자의 질문을 이해할 때, 단어 간의 관계를 온톨로지로 정의해두면 더 정확한 응답이 가능해진다.

3-5. 데이터 통합 / 상호운용성

서로 다른 시스템이 같은 개념을 다른 용어로 사용하는 경우가 많다. A 시스템에서는 "고객"이라 하고, B 시스템에서는 "사용자"라 할 때, 온톨로지를 통해 두 용어가 같은 개념임을 매핑할 수 있다. 기업의 데이터 통합이나 시스템 간 연동에서 이 문제가 빈번하게 발생하기 때문에, 온톨로지의 역할이 중요하다.

---

4. 내 프로젝트에 온톨로지를 적용할 수 있을까?

온톨로지 개념을 공부하면서, 자연스럽게 내가 진행 했던 프로젝트에 적용할 수 있는지 고민이 생겼다.

현재 내 프로젝트(AgentShield)는 LLM 보안 검증 플랫폼이다. 테스트베드 챗봇이 ChromaDB 기반의 implicit RAG를 사용하고 있는데, 구조를 간단히 정리하면 이렇다.

• data/testbed_kb/에 쇼핑몰 도메인 markdown 문서 11개가 있다 (환불, 배송, 멤버십, 결제, 개인정보 등).
• 문서를 청크 단위로 분할해서 ChromaDB에 인덱싱한다.
• 사용자 메시지가 들어올 때마다 /kb/search로 유사 문서를 검색하고, 검색된 snippet을 system prompt에 주입해서 응답을 생성한다.

전형적인 벡터 유사도 기반 RAG다. 이 구조에서 온톨로지를 도입하면 뭐가 달라질까?

4-1 현재 RAG의 한계

기본 RAG는 "키워드/의미가 비슷한 문서를 찾아오는 것"에 집중한다. 이 방식의 문제가 뭔지 내 프로젝트 맥락에서 생각해보면 이렇다.

 

첫 번째, 개념 간 관계를 모른다.

• 예를 들어 공격자가 "환불 절차 알려줘"라고 물으면 RAG가 환불 문서를 가져온다. 그런데 환불 문서 안에 "고객 주문번호 조회 → 결제 취소 → 계좌 환불"이라는 프로세스가 있고, 이 프로세스에서 "결제 취소"는 별도의 결제 문서에 있는 API 권한과 연결된다. 벡터 검색만으로는 이 연결을 자동으로 따라가지 못한다. 검색 쿼리에 "결제"가 없으면 결제 문서는 검색되지 않는다.

두 번째, 민감도 분류가 문서 단위에 묶여 있다.

• 현재는 frontmatter의 audience/sensitivity 태그로 문서를 kb_public_docs, kb_internal_runbooks, kb_poisoned_docs 컬렉션으로 분류하고 있다. 하지만 하나의 문서 안에도 공개 가능한 정보와 민감한 정보가 섞여 있을 수 있다. 문서 단위가 아니라 개념 단위로 민감도를 관리할 수 있다면, Judge나 Blue Agent가 더 정밀하게 판단할 수 있지 않을까 생각했다.

세 번째, 공격 패턴 간의 관계를 구조화할 수 없다.

• OWASP LLM01(프롬프트 인젝션)과 LLM06(민감정보 노출)은 서로 독립된 카테고리처럼 보이지만, 실제로는 "프롬프트 인젝션을 통해 민감정보를 노출시키는" 복합 공격이 존재한다. 현재 구조에서는 이런 카테고리 간 관계가 명시적으로 정의되어 있지 않다.

4-2 온톨로지를 도입하면 달라지는 점

이 한계들을 온톨로지로 어떻게 보완할 수 있는지 정리해봤다.

 

1. 지식 그래프 기반 RAG (GraphRAG)로 확장

단순 벡터 검색 대신, 온톨로지로 개념 간 관계를 그래프로 구축하면 "환불" → "결제 취소" → "결제 API 권한" 같은 연결을 따라갈 수 있다. 사용자가 "환불"을 물어봤을 때, 관련된 상위/하위 개념과 연결된 프로세스까지 함께 검색되는 것이다. 이렇게 되면 Red Agent가 우회 공격을 시도할 때, 테스트베드가 관련 맥락을 더 넓게 파악하고 응답할 수 있게 된다.

 

2. 민감도를 개념 단위로 세분화

온톨로지에서 각 개념(클래스)에 민감도 속성을 부여할 수 있다. 예를 들면 이런 식이다.

고객정보(Class) - sensitivity: high
  ├── 이름 - sensitivity: medium
  ├── 주문번호 - sensitivity: low
  └── 결제수단 - sensitivity: critical

환불절차(Class) - sensitivity: medium
  ├── 환불요청 - sensitivity: low
  └── 계좌환불실행 - sensitivity: high (내부 API 호출 필요)

이렇게 하면 Judge가 응답을 판정할 때, 노출된 정보가 어떤 개념에 속하는지, 그 개념의 민감도가 어느 수준인지를 구조적으로 참조할 수 있다. 현재의 패턴 매칭이나 LLM 판단보다 일관성 있는 기준이 될 수 있다고 생각한다.

 

3. 공격 카테고리 온톨로지

OWASP LLM Top 10의 공격 유형들을 온톨로지로 정의하면, 카테고리 간의 관계(선행조건, 복합 공격 경로)를 명시할 수 있다. Red Agent가 다음 라운드 전략을 세울 때, "LLM01 공격이 실패했으니 LLM06 경로로 우회"가 아니라 "LLM01→LLM06 복합 경로가 존재하고, 중간에 LLM02(데이터 유출)를 거치는 패턴이 있다"는 식으로 구조화된 전략을 참조할 수 있다.

---

5. 기존 RAG vs 온톨로지 기반 RAG, 핵심 차이

	기존 벡터 RAG	온톨로지 기반 RAG
검색 방식	임베딩 유사도	유사도 + 개념 그래프 탐색
관련 문서 발견	쿼리에 등장하는 키워드/의미에 의존	상위·하위·연관 개념을 따라 자동 확장
민감도 판단	문서/컬렉션 단위 태그	개념 단위 속성으로 세밀하게 제어
공격 경로 분석	카테고리 독립 처리	카테고리 간 선행조건·복합 경로 명시
유지보수	문서 추가/삭제만으로 반영	개념·관계 정의를 함께 관리해야 함

결국 벡터 RAG는 "비슷한 걸 잘 찾아오는 것"에 강하고, 온톨로지 기반은 "왜 이것이 연관되는지 구조적으로 아는 것"에 강하다. 내 프로젝트에서 Judge가 증거 기반 판정을 하고, Red Agent가 공격 전략을 세울 때, 이 "구조적으로 아는 것"이 유의미한 차이를 만들 수 있다고 본다.

---

6. 마무리

온톨로지의 개념을 정리하면서, 단순한 학술 개념이 아니라 실제 시스템의 지식 표현 방식에 직접적으로 영향을 주는 구조라는 점을 다시 확인했다. 특히 내 프로젝트처럼 여러 에이전트가 도메인 지식을 기반으로 판단을 내려야 하는 구조에서는, 데이터에 의미와 관계를 부여하는 온톨로지의 역할이 분명히 존재한다고 생각한다.

 

다만 이건 아직 이론적인 분석이다. 실제로 온톨로지를 도입했을 때 Judge의 판정 정확도가 올라가는지, Red Agent의 공격 전략이 더 정교해지는지는 직접 비교해봐야 안다. 다음 단계로 별도 브랜치를 만들어서 기존 벡터 RAG와 온톨로지 기반 RAG를 동일 조건에서 비교 실험해볼 계획이다. 그 결과는 이후 포스팅에서 다루도록 하겠습니다.