온톨로지와 메모리 시스템 (1/13) — Claude Code에서 온톨로지가 필요한 이유

-

AI 에이전트가 늘어날수록 관계 설계가 성능을 결정한다

핵심 요약

  • 온톨로지는 에이전트 간 관계와 의존성을 정의한 구조적 지도
  • Claude Code에서 CLAUDE.md와 메모리 시스템이 온톨로지의 실체가 된다
  • 여러 Claude Code 프로젝트를 운영하면 공유 지식과 사용자 관점이 전체 시스템의 일관성을 만든다
  • Claude Code뿐 아니라 다른 AI 시스템도 같은 온톨로지에 참여할 수 있다

배경

Claude Code로 프로젝트를 운영하다 보면, 자연스럽게 에이전트가 늘어납니다. 앱 개발용 하나, 서버 관리용 하나, 콘텐츠 작성용 하나. 각각 잘 돌아갑니다.

그런데 다수의 에이전트를 넘어가면 구조적 문제가 드러납니다. "이 에이전트가 만든 데이터를 저 에이전트가 쓸 수 있나?" "새 프로젝트를 만들면 기존 에이전트와 어떻게 연결하지?" "사용자의 작업 방식을 에이전트마다 따로 정의해야 하나?"

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

본문

1. 온톨로지란 무엇인가

온톨로지(Ontology)는 원래 "존재에 대한 연구"를 뜻하는 철학 용어입니다. IT에서는 의미가 구체적으로 바뀝니다: 개체들 사이의 관계를 정의한 구조적 지도입니다.

AI 에이전트 온톨로지는 세 가지를 정의합니다:

① 누가 있는가 (개체) 시스템에 어떤 에이전트들이 존재하고, 각각 무슨 역할을 하는가.

② 누가 누구와 연결되는가 (관계) 어떤 에이전트가 어떤 에이전트에게 데이터를 보내는가. 어떤 기술을 공유하는가. 어떤 콘텐츠가 어디로 흘러가는가.

③ 공유하는 규칙은 무엇인가 (공유 지식) 모든 에이전트가 알아야 하는 사용자의 성향, 작업 원칙, 판단 기준은 무엇인가.

데이터베이스 스키마가 데이터 간 관계를 정의하듯, 온톨로지는 에이전트 간 관계를 정의합니다. 스키마 없는 데이터베이스가 혼란이듯, 온톨로지 없는 멀티 에이전트도 혼란입니다.

2. Claude Code에서 온톨로지가 작동하는 방식

Claude Code에는 온톨로지를 구현할 수 있는 구조가 이미 갖춰져 있습니다.

CLAUDE.md — 에이전트의 기억이자 정체성

모든 Claude Code 프로젝트는 CLAUDE.md를 매 세션 시작 시 자동으로 읽습니다. 여기에 프로젝트의 목적, 규칙, 구조가 들어갑니다. 이것이 개별 에이전트의 정체성입니다.

CLAUDE.md는 두 계층으로 구성됩니다: - 글로벌 CLAUDE.md (~/.claude/CLAUDE.md): 모든 프로젝트에 공통 적용 - 프로젝트 CLAUDE.md (프로젝트 루트): 해당 프로젝트에만 적용

이 구조가 온톨로지의 핵심입니다. 글로벌 CLAUDE.md에 전체 에이전트 목록, 관계도, 공유 규칙을 정의하면 — 어떤 프로젝트를 열든 전체 시스템 맥락을 알고 시작합니다.

메모리 시스템 — 대화를 넘어서는 기억

Claude Code의 메모리는 세션 간에 유지됩니다. 사용자에 대한 이해, 작업 피드백, 프로젝트 상태가 축적됩니다.

이 메모리가 온톨로지와 결합하면 다음 메커니즘이 작동합니다: - 에이전트 A에서 학습한 사용자 성향(예: 데이터 기반 판단 선호)이 글로벌 컨텍스트에 기록됨 - 글로벌 CLAUDE.md를 통해 에이전트 B도 같은 사실을 세션 시작 시 자동으로 읽음 - 처음 사용하는 프로젝트여도 사용자 성향에 맞게 즉시 작동

사용자 관점을 에이전트마다 재정의할 필요가 없습니다. 한 번 공유된 정책은 전체 시스템에 적용됩니다.

3. 여러 Claude Code를 쓸 때 온톨로지의 장점

Claude Code 프로젝트를 하나만 쓰면 온톨로지가 필요 없습니다. 두세 개까지도 머릿속으로 관리가 됩니다. 그 이상부터 차이가 나기 시작합니다.

① 지식 재사용

Flutter 앱 프로젝트에서 해결한 상태 관리 패턴은 온톨로지에 기술 관계로 명시됩니다. 다른 Flutter 프로젝트는 "형제 프로젝트의 기존 패턴 확인"을 온톨로지 경로로 수행합니다. 같은 문제를 두 번 풀지 않습니다.

② 데이터 흐름 파악

주식 분석 에이전트의 인사이트는 콘텐츠 에이전트의 블로그 소재로 흘러갑니다. 이 흐름이 온톨로지에 [data] 관계로 명시되어 있으면, 콘텐츠 에이전트는 입력 소스와 형식을 처음부터 알고 작동합니다.

③ 사용자 관점의 일관성

가장 핵심적인 효과입니다. 글로벌 CLAUDE.md에 사용자의 판단 기준, 가치관, 선호 방식을 정의하면 — 다수의 에이전트 모두가 같은 사람을 같은 방식으로 이해합니다.

개발 에이전트는 사용자가 데이터 기반 판단을 선호한다는 것을 알고, 콘텐츠 에이전트도 같은 원칙으로 글을 씁니다. 에이전트마다 따로 설명할 필요가 없습니다.

④ 새 에이전트 온보딩

새 에이전트를 추가할 때, 온톨로지가 없으면 처음부터 다시 설정합니다. 온톨로지가 있으면 글로벌 CLAUDE.md를 읽는 것만으로 전체 시스템 맥락, 사용자 성향, 기존 에이전트와의 관계를 즉시 파악합니다.

4. 다른 AI도 같은 온톨로지에 참여할 수 있다

온톨로지의 실체는 CLAUDE.md라는 마크다운 파일입니다. Claude Code 전용이 아닙니다.

GPT, Gemini, 로컬 LLM도 읽을 수 있습니다. 마크다운은 어떤 AI든 이해할 수 있는 포맷이니까요. 시스템 프롬프트나 컨텍스트에 같은 온톨로지 파일을 주입하면, 다른 AI도 동일한 관계 지도와 사용자 관점을 공유합니다.

실제 활용 예시: - Claude Code가 주 에이전트, GPT가 팩트체크 보조 → 같은 온톨로지로 역할 분담 명확 - 로컬 LLM이 데이터 전처리, Claude Code가 분석 → 데이터 관계가 온톨로지에 정의됨 - 새로운 AI 서비스를 추가할 때 → 온톨로지에 역할과 관계만 추가하면 됨

AI 종류가 아니라 역할이 기준입니다. 온톨로지는 특정 AI에 종속되지 않는, 시스템 수준의 설계도입니다.

5. 온톨로지의 세 가지 관계 유형

에이전트 사이의 관계는 크게 세 종류로 분류합니다.

데이터 관계 [data] — 한 에이전트의 출력이 다른 에이전트의 입력

오픈클로 관리 → 홈서버 관리자: 분석 인사이트 → 대시보드 표시
주식 정보 관리 → 글 작성 디렉터: 투자 분석 → 블로그 소재

기술 관계 [tech] — 같은 스택을 공유하여 패턴 재사용

콰이어트 ↔ 성장 일지: Flutter UI 패턴, 상태 관리 공유
프롬프트 하네스 → 모든 프로젝트: 하네스 구조 제공

콘텐츠 관계 [content] — 도메인 지식이 다른 에이전트의 소재

나의 삶 정리 → 글 작성 디렉터: 경험/의사결정 → 블로그 소재
주식 정보 관리 → 글 작성 디렉터: 분석 인사이트 → 콘텐츠 소재

이 관계를 CLAUDE.md에 테이블로 관리합니다. 새 에이전트가 추가되면 어떤 관계 유형으로 연결되는지 즉시 정의합니다.

설계 시 주의사항

  • 온톨로지를 너무 일찍 만들 필요는 없습니다. 에이전트가 소수일 때는 머릿속으로 충분합니다. 관리 부담이 커지는 시점부터 문서화를 시작하는 것이 적절합니다.

  • 글로벌 CLAUDE.md가 너무 길어지면 역효과입니다. 프롬프트가 길수록 앞부분 참조 비중이 낮아집니다. 온톨로지는 간결하게, 상세 규칙은 각 프로젝트 CLAUDE.md에 넣는 것이 효과적입니다.

  • 관계는 양방향인지 단방향인지 구분해야 합니다. "A → B" (A가 B에게 보냄)와 "A ↔ B" (서로 주고받음)는 다릅니다. 단방향을 양방향으로 착각하면 없는 의존성을 기대하게 됩니다.

마무리

온톨로지는 거창한 개념이 아닙니다. "내 에이전트들이 어떻게 연결되어 있는지 적어둔 문서" 입니다.

그런데 이 문서 하나가 만드는 차이가 큽니다. 지식이 재사용되고, 사용자 관점이 일관되고, 새 에이전트가 즉시 시스템에 합류하고, Claude Code가 아닌 다른 AI도 같은 맥락에서 작동합니다.

2편에서는 이 온톨로지를 실제로 어떻게 구현하는지 — 메시지 허브 설계, 컨텍스트 격리, 메모리 계층 구조를 다룹니다.

시리즈 전체 안내: 시리즈 목차

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »