기록을 저장하는 것에서 연결하는 것으로: 온톨로지와 AI 세컨드 브레인

게시 2026/07/10

By woolam

조회 23 분읽는 시간

온톨로지를 알아보게 된 이유

AI 세컨드 브레인이라는 개념을 알아보다가 온톨로지(Ontology)라는 낯선 용어를 만났다. 처음에는 AI 세컨드 브레인을 메모를 저장해 두었다가 자연어로 검색하는 시스템 정도로 생각했다. 그런데 내용을 따라가다 보니 단순히 기록을 찾는 것만으로는 충분하지 않은 경우가 있었다.

예를 들어 Redis라는 단어가 포함된 메모를 찾는 일은 어렵지 않다. 하지만 Redis를 캐시로 사용한 기록과 분산 락으로 사용한 기록을 구분하고, 각 선택의 이유를 비교하려면 단어보다 기록의 의미와 관계를 알아야 한다.

이번 글에서는 온톨로지를 깊은 이론으로 다루기보다, 처음 접한 개발자의 관점에서 택소노미·지식 그래프·RAG·AI 세컨드 브레인이 어떻게 이어지는지 정리해 보려고 한다.

RAG의 검색 단계가 아직 낯설다면 먼저 RAG의 핵심은 생성이 아니라 검색이다를 읽어 보면, 아래에서 설명할 구조를 이해하는 데 도움이 된다.

AI 세컨드 브레인의 핵심은 정보를 많이 저장하는 것이 아니라, 기록의 의미와 관계를 파악해 과거의 지식을 현재의 문제에 다시 활용할 수 있게 만드는 것이다.

1. 온톨로지란 무엇인가

온톨로지는 쉽게 말해 특정 분야의 개념과 관계를 정의한 의미 지도다. 어떤 개념이 존재하는지, 각 개념에 어떤 속성이 있는지, 개념끼리 어떤 관계를 맺는지를 정한다.

Kafka를 학습하며 남긴 내용을 예로 들어 보자.

Kafka는 메시징 기술이다.
Kafka는 이벤트를 전달한다.
Consumer는 이벤트를 처리한다.
이벤트 처리 실패는 재시도를 발생시킨다.
재시도 횟수를 초과한 이벤트는 DLT로 이동한다.

이 문장에는 Kafka, Consumer, 이벤트, 재시도, DLT라는 개념이 있다. 동시에 종류, 전달, 처리, 발생, 이동이라는 관계도 있다. 온톨로지는 단어를 같은 폴더에 모으는 데서 멈추지 않고 이런 의미 구조를 정의한다.

Kafka ──종류──> 메시징 기술
Kafka ──전달한다──> 이벤트
Consumer ──처리한다──> 이벤트
처리 실패 ──발생시킨다──> 재시도
재시도 초과 ──이동시킨다──> DLT

다만 온톨로지를 만든다고 AI가 모든 문서를 저절로 완벽하게 이해하는 것은 아니다. 어떤 개념과 관계를 사용할지 설계하고, 실제 기록을 그 구조에 연결하며, 바뀐 지식을 계속 관리해야 한다.

2. 택소노미, 온톨로지, 지식 그래프의 차이

세 개념은 서로 이어지지만 같은 것은 아니다.

택소노미: 지식을 분류한다

택소노미(Taxonomy)는 정보를 상위 개념과 하위 개념으로 나누는 계층 구조다. 핵심 질문은 “무엇이 어떤 분류에 속하는가?”다.

기술
└─ 백엔드
   └─ 메시징
      └─ Kafka

온톨로지: 의미와 관계의 규칙을 정의한다

온톨로지는 상위·하위 분류를 포함할 수 있지만, 그것보다 넓게 개념의 속성과 여러 관계를 정의한다. 핵심 질문은 “이 개념은 무엇이며 다른 개념과 어떤 관계를 가지는가?”다.

지식 그래프: 실제 지식을 연결한다

지식 그래프(Knowledge Graph)는 개념과 실제 대상을 노드로, 관계를 간선으로 표현한 지식 구조다. 온톨로지가 제공한 개념과 관계를 스키마로 활용할 수 있지만, 모든 지식 그래프가 반드시 엄격한 온톨로지를 먼저 요구하는 것은 아니다.

Kafka ──사용됨──> 결제 완료 이벤트 전달
Kafka ──관련됨──> 중복 소비 문제
중복 소비 문제 ──해결됨──> 멱등성 처리

비교 기준	택소노미	온톨로지	지식 그래프
핵심 역할	지식을 분류한다	개념·속성·관계를 정의한다	실제 지식과 관계를 연결한다
구조	트리 또는 계층	관계와 규칙을 포함한 의미 모델	노드와 간선으로 된 그래프
대표 관계	상위·하위, 포함	종류, 사용, 처리, 발생 등	구체적인 대상 사이의 관계
실제 예시	메시징 아래 Kafka 배치	Kafka가 이벤트를 전달한다고 정의	Kafka가 결제 이벤트 전달에 사용된 사례 연결

택소노미는 지식을 분류하고, 온톨로지는 관계의 규칙을 정의하며, 지식 그래프는 그 규칙을 기반으로 실제 지식을 연결한다.

3. AI 세컨드 브레인은 일반 메모 앱과 무엇이 다른가

일반 메모 앱은 기록을 보관하고 사람이 다시 찾아 읽는 데 초점이 있다. AI 세컨드 브레인은 저장된 정보를 다시 찾고, 관련 기록과 연결하고, 현재 질문에 맞게 요약하거나 재구성하는 데 초점을 둔다.

일반 메모 앱	AI 세컨드 브레인
사용자가 폴더와 태그를 직접 관리한다	AI가 기록 내용을 분석할 수 있다
제목이나 키워드를 기억해야 찾기 쉽다	상황을 설명하는 질문으로도 검색할 수 있다
문서를 다시 열어 직접 읽는다	관련 기록을 모아 요약하고 재구성할 수 있다
기록의 보관이 중심이다	기록의 재활용이 중심이다

다음 기록을 저장했다고 가정해 보자.

Kafka Consumer에서 메시지 처리가 실패하면 3회 재시도한 뒤 DLT로 전송한다.

나중에는 정확한 문장을 기억하지 못하고 이렇게 질문할 수 있다.

예전에 메시지가 계속 실패했을 때 어떻게 처리하기로 했지?

AI 세컨드 브레인은 질문과 기록에 같은 단어가 있는지만 비교해서는 안 된다. 계속 실패가 재시도 횟수 초과와 관련 있고, 그다음 처리 대상이 DLT라는 의미를 찾아 답해야 한다.

4. RAG 기반 세컨드 브레인의 기본 구조

AI 세컨드 브레인의 가장 단순한 출발점으로 RAG(Retrieval-Augmented Generation)를 생각할 수 있다. 기록을 검색 가능한 형태로 저장해 두고, 질문이 들어오면 관련 기록을 찾아 LLM에 근거로 제공하는 방식이다.

사용자 기록 저장
  → 기록을 작은 단위로 분리
  → 임베딩 생성
  → 벡터 데이터베이스에 저장
  → 질문과 의미적으로 유사한 기록 검색
  → 검색 결과를 LLM에 전달
  → 질문에 맞는 답변 생성

여기서 임베딩은 문장의 의미적 특징을 숫자 벡터로 표현하는 과정이다. 벡터 데이터베이스는 질문 벡터와 가까운 기록을 찾아 준다. 덕분에 질문과 기록의 표현이 완전히 같지 않아도 관련 내용을 검색할 수 있다.

임베딩과 벡터 데이터베이스의 역할을 더 자세히 보고 싶다면 Vector DB 완전 정복: 개념부터 실무 활용까지를 함께 참고할 수 있다.

RAG의 역할은 크게 세 가지다.

질문과 관련된 사용자 기록을 검색한다.
LLM이 사용자의 실제 기록을 근거로 답하게 한다.
모델이 학습 과정에서 얻은 일반 지식에만 의존하지 않도록 돕는다.

하지만 의미적으로 비슷한 문서를 찾는 것과 문서 사이의 관계를 정확히 이해하는 것은 다른 문제다. RAG만으로는 같은 기술이 서로 다른 역할로 사용됐는지, 어떤 결정이 어떤 문제를 해결했는지를 항상 명확하게 구분하기 어렵다.

5. RAG와 온톨로지는 각각 어떤 역할을 하는가

RAG와 온톨로지는 경쟁하거나 서로를 대체하는 기술이 아니다. 해결하려는 문제가 다르다.

RAG가 하는 일

질문과 의미적으로 비슷한 문서나 문장 조각을 찾는다.
자연어 질문으로 관련 기록을 검색하는 데 강하다.
검색한 기록을 LLM의 답변 근거로 제공한다.

온톨로지가 하는 일

개념이 무엇이고 서로 어떤 관계를 맺는지 정의한다.
같은 기술이 서로 다른 역할로 쓰인 경우를 구분하도록 돕는다.
관계를 따라 지식을 탐색하거나 확장할 기준을 제공한다.

Redis에 관한 두 기록을 예로 들어 보자.

기록 A: Redis를 상품 검색 결과 캐시에 사용했다.

기록 B: Redis를 주문 처리의 분산 락에 사용했다.

RAG는 두 기록을 모두 Redis 관련 문서로 찾을 수 있다. 온톨로지로 사용 역할과 해결 대상을 정의해 두었다면 다음처럼 의미를 더 명확히 나눌 수 있다.

Redis ──캐시로 사용됨──> 상품 검색 성능 개선
Redis ──분산 락으로 사용됨──> 주문 동시성 제어

RAG는 관련 정보를 찾는 방법이고, 온톨로지는 정보의 의미와 관계를 정의하는 방법이다.

6. 온톨로지가 AI 세컨드 브레인에 주는 가치

같은 단어의 서로 다른 역할을 구분한다

Redis는 캐시, 세션 저장소, 분산 락, 메시징 등 여러 역할로 쓰일 수 있다. 단어가 같다는 이유만으로 기록을 한 덩어리로 보면 각 설계 판단의 맥락이 섞인다. 기술, 사용 역할, 해결하려는 문제를 구분하면 같은 Redis 기록도 목적별로 탐색할 수 있다.

Redis를 캐시 관점에서 더 살펴본 기록으로는 Spring Cache: 캐시 Key 설계부터 동기화, RedisTemplate 동작 원리까지도 연결해 볼 만하다.

문서에 직접 적혀 있지 않은 연결을 탐색한다

서로 다른 문서에 다음 내용이 나뉘어 있을 수 있다.

Kafka → 이벤트가 중복 전달될 수 있음
중복 전달 → 멱등성 필요
멱등성 구현 → Redis를 활용할 수 있음

관계가 명시적으로 연결되어 있다면 한 문서에 모든 내용이 없어도 Kafka의 중복 처리 문제에서 Redis 활용 기록까지 따라갈 수 있다. 다만 이런 연결은 자동으로 항상 옳게 생기는 것이 아니므로 출처와 검증 기준이 필요하다.

지식을 일관된 기준으로 정리한다

어떤 문서는 재처리, 다른 문서는 재시도, 또 다른 문서는 retry라고 쓸 수 있다. 공통 개념과 관계를 정의하면 표현이 달라도 같은 기준으로 정리할 수 있다.

관계 중심 질문에 대응한다

단순 검색 질문은 관련 문서를 찾는 것만으로 답할 수 있다.

Redis에 대해 작성한 기록을 찾아줘.

반면 다음 질문은 역할과 설계 판단의 관계를 구분해야 한다.

Redis를 캐시로 사용했을 때와 분산 락으로 사용했을 때의 설계 판단을 비교해줘.

두 번째 질문에는 Redis라는 공통 키워드 외에도 사용 역할, 목적, 장단점, 결정 근거가 필요하다. 온톨로지와 지식 그래프는 이런 관계 중심 탐색을 보완할 수 있다.

7. 모든 세컨드 브레인에 온톨로지가 필요한 것은 아니다

온톨로지가 유용하다고 해서 처음부터 반드시 도입해야 하는 것은 아니다. 구조가 하나 추가되는 만큼 비용도 생긴다.

도메인의 개념과 관계를 먼저 설계해야 한다.
실제 기록의 엔티티와 관계를 추출해 구조에 연결해야 한다.
지식과 용어가 변하면 온톨로지도 함께 갱신해야 한다.
관계가 늘어날수록 검증과 관리 비용이 증가한다.
잘못 설계한 개념이나 관계는 검색과 해석을 오히려 제한할 수 있다.
기록이 적은 개인 메모에는 과한 설계가 될 수 있다.

특히 온톨로지가 세밀할수록 항상 좋은 것은 아니다. 모든 문장을 억지로 정해진 관계에 끼워 맞추면 새롭거나 모호한 기록을 놓칠 수 있다. 자연어 검색의 유연함과 구조화된 관계 탐색 사이에서 균형을 잡아야 한다.

개인용 AI 세컨드 브레인이라면 다음 순서가 현실적으로 보인다.

태그, 임베딩, 벡터 검색, RAG로 작게 시작한다.
기록이 늘면서 원하는 내용을 찾지 못하는 사례를 모은다.
관계 중심 질문이 반복될 때 필요한 개념과 관계만 정의한다.
온톨로지와 지식 그래프를 RAG의 보완 수단으로 점진적으로 도입한다.

개인 메모처럼 데이터가 작고 관계가 단순한 환경에서는 RAG만으로도 충분할 수 있다. 반면 의료·법률·기업 문서·개발 의사결정 기록처럼 용어의 의미와 관계를 정확히 구분해야 하는 환경에서는 온톨로지와 지식 그래프의 가치가 커질 수 있다.

8. 학습 후 느낀 점

처음에는 AI 세컨드 브레인을 메모를 저장하고 자연어로 검색해 주는 시스템 정도로 생각했다. 이번에 개념을 정리하면서 중요한 것은 기록의 양보다 기록을 어떤 의미로 해석하고 어떤 관계로 연결할 수 있는가라는 점을 알게 되었다.

RAG는 자연어 질문으로 관련 기록을 찾고, 실제 기록을 LLM의 답변 근거로 제공하는 데 효과적이다. 하지만 복잡한 관계나 같은 개념의 여러 역할을 명확하게 표현하는 데는 한계가 있을 수 있다. 온톨로지는 그 부분을 보완할 수 있지만, 구조를 설계하고 실제 기록과 연결하고 계속 관리하는 비용이 필요하다.

그래서 개인용 AI 세컨드 브레인을 만든다면 먼저 RAG 중심으로 시작하는 편이 현실적이라고 느꼈다. 이후 기록이 늘고 관계 기반 질문이 실제로 많아질 때, 필요한 범위부터 온톨로지와 지식 그래프를 점진적으로 도입하면 된다.

좋은 AI 세컨드 브레인은 기억을 많이 쌓아 둔 창고가 아니라, 필요한 순간에 과거의 기록을 의미와 관계에 따라 다시 꺼내 쓸 수 있게 하는 시스템이다.

함께 읽으면 좋은 글

AI, Knowledge Management