KMS 방법론 선택 가이드 - LLM Wiki부터 온톨로지까지
KMS 시리즈를 여기까지 읽었다면, 선택지가 오히려 늘어난 느낌일 수 있습니다. LLM Wiki, Graph RAG, 온톨로지, Agent Memory. 각각 다른 문제를 풀고, 각각 다른 비용이 따릅니다.
이 글은 시리즈의 마무리 편입니다. 상황별로 어떤 방법을 써야 하는지, 어떤 조합이 실용적인지를 정리합니다.
먼저: 무엇을 해결하려는가
방법론을 선택하기 전에 문제를 먼저 정의해야 합니다.
*"AI가 내 맥락을 모른다"* 는 가장 흔한 불만입니다. 매번 배경을 설명해야 합니다. 이것은 의미형 기억 문제입니다. LLM Wiki로 시작하기 적합합니다.
*"AI가 복잡한 질문에 틀린 답을 낸다"* 는 다른 문제입니다. 여러 정보를 연결해서 추론해야 하는데, 그 연결이 안 됩니다. 이것은 구조 문제입니다. GraphRAG가 필요한 신호입니다.
*"팀 전체가 같은 AI를 쓰는데, 사람마다 다른 답을 받는다"* 는 또 다른 문제입니다. 비즈니스 용어의 정의가 일치하지 않아서입니다. 이것은 권위성(authority) 문제입니다. 온톨로지 레이어가 필요한 지점입니다.
*"에이전트가 어제 한 작업의 맥락을 오늘 기억해야 한다"* 는 지속성 문제입니다. Agent Memory 구조가 필요합니다.
선택 기준 1: 규모
가장 단순한 분류 기준입니다.
규모 |
추천 방법 |
이유 |
|---|---|---|
개인 |
LLM Wiki |
시작 비용이 낮고, 직접 쓴 내용이니 검증 가능 |
2-10명 소팀 |
LLM Wiki + 공유 컨벤션 |
팀 공통 용어 정의 필요, 하지만 인프라는 최소화 |
10-100명 중규모 |
GraphRAG |
지식이 복잡해지고 관계 탐색이 필요해지는 시점 |
100명 이상 |
온톨로지 (Genie Ontology류) |
자동 추출 + 권위성 결정 없이는 수동 관리 불가능 |
규모가 작을 때 복잡한 인프라를 도입하면 오버엔지니어링입니다. 반대로 규모가 커졌는데 개인 위키 패턴을 유지하면 충돌과 중복이 쌓입니다.
선택 기준 2: 도메인 안정성
LLM Wiki의 가장 치명적인 약점은 내용이 오래되면 현실과 어긋난다는 것입니다. 도메인이 얼마나 빠르게 변하는지가 방법론 선택에 직접 영향을 줍니다.
도메인 안정성 |
예시 |
추천 |
|---|---|---|
높음 (연 단위 변화) |
글쓰기 톤, 팀 철학, 설계 원칙 |
LLM Wiki 적합 |
중간 (월 단위 변화) |
코딩 컨벤션, 아키텍처 결정 |
Wiki + 주기적 리뷰 루틴 |
낮음 (주 단위 변화) |
인프라 상세, API 스펙, 서버 목록 |
Wiki 부적합. 공식 문서 직접 참조 |
실시간 변화 |
가격, 재고, 사용자 상태 |
Agent Memory 또는 도구 통합 |
Tom Nguyen의 77페이지 AWS 인프라 위키가 실패한 이유가 여기 있습니다. 인프라는 안정성이 낮은 도메인입니다.
선택 기준 3: 질문의 복잡도
단순 사실 확인과 멀티홉 추론은 필요한 구조가 다릅니다.
단순 사실: "우리 팀 배포 프로세스가 뭔가요?" LLM Wiki로 충분합니다. 해당 파일을 컨텍스트에 넣으면 됩니다.
멀티홉 추론: "이 버그가 발생했을 때, 관련된 서비스들의 배포 히스토리와 의존성을 추적해서 원인을 찾아줘." 여러 정보를 연결해서 추론해야 합니다. Graph RAG의 구조가 이런 질문에서 단순 벡터 검색보다 평균 9.7% 높은 정확도를 보입니다(HyGRAG 기준).
단순한 질문만 한다면 GraphRAG의 복잡성은 낭비입니다. 반대로 복잡한 관계 탐색이 자주 필요하다면, LLM Wiki의 느슨한 구조로는 한계가 옵니다.
선택 기준 4: 자동화 필요도
수동으로 관리할 수 있는 규모인지, 자동화가 필요한지도 중요한 기준입니다.
자동화 수준 |
방법 |
비용 |
|---|---|---|
수동 |
LLM Wiki (직접 작성) |
시간 비용, 낮은 인프라 비용 |
반자동 |
launchd/cron + 에이전트 업데이트 |
설정 비용, 낮은 유지비 |
자동 |
Genie Ontology류 |
높은 초기 비용, 장기 유지 용이 |
Doneyli De Jesus가 launchd 7개 잡으로 24시간 AI 비서를 만든 사례는 반자동의 좋은 예입니다. 자동으로 위키가 업데이트되지만, 구조 자체는 여전히 사람이 설계합니다.
조합 패턴
실제로는 하나만 쓰지 않는 경우가 많습니다.
개인 작업자를 위한 기본 조합:
LLM Wiki (의미형 + 절차형 기억)
+ log.md (에피소딕 기억)
+ CLAUDE.md / AGENTS.md (절차형 메모리)
소팀을 위한 확장 조합:
공유 LLM Wiki (팀 공통 용어, 설계 원칙)
+ 개인 Wiki (개인 작업 스타일, 로컬 컨텍스트)
+ 위키링크로 관계 표현 → 점진적 GraphRAG 이행 준비
중규모 조직을 위한 조합:
GraphRAG (지식 탐색 + 관계 추론)
+ 온톨로지 레이어 (용어 권위성 결정)
+ Agent Memory (에이전트 장기 기억)
시작은 항상 작게
이 시리즈를 읽고 "온톨로지를 갖춰야겠다"는 결론이 나왔다면, 잠깐 멈추는 게 좋습니다. 대부분의 문제는 잘 관리된 LLM Wiki 20개 파일로 해결됩니다.
시작점은 이렇습니다.
- 지금 AI에게 매번 설명하는 것이 무엇인지 목록 작성
- 그 중 3개를 마크다운 파일로 정리
- 한 달 써보고 어디서 한계가 오는지 관찰
- 한계가 명확해지면 그때 다음 단계로
GraphRAG가 필요한지는 멀티홉 질문을 자주 하게 될 때 알게 됩니다. 온톨로지가 필요한지는 팀에서 같은 단어로 다른 것을 의미하는 충돌이 생길 때 알게 됩니다.
문제가 보이기 전에 해법을 미리 도입하면, 쓰지 않는 인프라만 남습니다.
이 시리즈의 다른 글: - Karpathy LLM Wiki - 개인 지식을 AI와 공유하는 새로운 방법 — KMS 시리즈 첫 편 - Agent Memory - 에이전트가 기억하는 7가지 방법 - Databricks Genie Ontology - RAG를 넘어선 엔터프라이즈 지식 레이어 - LLM Wiki는 왜 무너지는가 - 4가지 붕괴 모드 - HyGRAG - 단순 벡터 검색이 놓치는 것