정말 미리 썻어야 한데.. 이제야 씁니다. 게을러 빠져서
RAG는 '깎고', 옵시디언 LLM 위키는 '연결한다' — 법령 실무를 위한 AI 지식베이스 구축기
📝 한줄 요약
법령·기준서를 다루는 실무에서 AI가 근거를 정확히, 그리고 맥락까지 이어서 잡게 하고 싶었다. 그래서 일반적인 RAG 대신 옵시디언 기반 LLM 위키로 지식을 양방향 연결하고, 과거 근거 검색은 SQL + FTS5로 구현방식이 품에 대한 공수가 많이 들어가 옵시디언 기반 LLM WIKI를 통해 편리함을 구축했다. 이 방식을 내 모든 AI에 동일하게 적용하고 있다.
바쁘시면 이것만 읽어도 돼요:
왜 LLM 위키인가: 일반 전통적인 RAG는 핵심 문장을 파편으로 콕콕 집어온다. LLM 위키는 양방향 링크라 근거를 이어서 읽는다. (아래 환율 예시가 핵심) 따라서 LLM WIKI 방식으로 나중에 온톨로지까지 이어지는 하이브리드 RAG를 구축하고자 했다. 출처 확인이 필수인 실무라 정확성·재현성이 우선. 의미 유사도(Vector RAG)보다 실제 기준서 문단을 그대로 끌어오는 데 유리하므로 LLM WIKI이다.
왜 옵시디언인가: LLM 위키 개념(양방향 링크) + 기본이 md 파일이라 컴퓨터가 잘 읽음 + 그래프·메타데이터 구성이 편하다. 한 도구로 끝난다.
약점 보완: FTS5는 추상적 질문에 약한데, LLM WIKI는 LLM이 의도를 먼저 파악하고 검색하게 하니 보완됐다.
한 줄로: RAG는 '깎는' 느낌, 옵시디언 LLM 위키는 '연결하는' 느낌이다.
🎯 이런 분들께 도움돼요
법령·기준서·계약서처럼 출처와 근거가 생명인 분야에서 AI를 쓰는 분
AI가 답은 하는데 맥락을 빼먹어서 못 믿겠는 분
전통적인 RAG·Vector DB를 검토하다 "이게 정말 정확한가?"가 걸렸던 분
노션·옵시디언에 자료는 있는데 AI가 그걸 제대로 못 읽는 분
😫 문제 상황 (Before)
나는 법령·기준서 관련 실무를 한다. 이 일은 단순히 답을 내는 게 아니라 보고하고 검토하고 사람이 판단하는 일이다. 그래서 AI에게 가장 중요한 건 두 가지였다 — 근거가 정확할 것, 그리고 그 근거의 맥락까지 이어서 읽을 것.
처음엔 일반적인 방법(RAG)을 떠올렸다. 자료를 잔뜩 넣어두고 질문하면 관련 부분을 찾아오는 방식. 그런데 실무에 대보니 두 군데서 막혔다.
맥락이 끊긴다 — RAG는 핵심 문장을 파편으로 집어온다. 의미가 비슷한 조각은 잘 찾지만, 그 조각에 딸린 전제·예외·후속 판단을 같이 끌고 오지 못할 수 있다.
근거가 흔들린다 — 의미 유사도로 찾다 보면 "비슷하지만 직접적인 근거는 아닌" 문단이 올라온다. 출처 확인이 필수인 일에선 치명적이다.
내가 원한 건 분명했다. AI(Hermes)가 근거를 확실히 잡고, 끊지 않고 이어 읽는 구조. 그 답으로 찾은 게 카파시(Andrej Karpathy)가 공유한 LLM 위키 패턴이었고, 이 방식이 잘 맞아서 내 모든 AI에 동일하게 적용하게 됐다.
🛠️ 사용한 도구
옵시디언(Obsidian): 마크다운 + 양방향 위키링크 + 그래프뷰. LLM 위키의 집. 기준서, 법령 등 근거 검색 엔진
AI 파트너(Hermes 기반): 자료를 요약·교차연결·정리하고 일관성을 지키는 사서 역할.
설계 토대: 카파시의 LLM 위키 패턴 + AKM(지식 운영 루프) 확장. 우르보로스와 오토리서치의 결합스킬
🔧 작업 과정
🧠 1막 — 왜 LLM 위키인가 (핵심)
이게 모든 결정의 출발점이라 정확히 비교부터 했다.
전통적인 RAG는 파편 기억법 같은 느낌이다. 핵심 문장을 콕콕 집어오는데, 파편화돼 있어서 자연어로 이어지기 힘들 수 있다. 예를 들어 어딘가에 이렇게 저장돼 있다고 하자:
A. A회사는 환율변동효과로 1분기 영업이익이 좋다.
B. 원/달러가 떨어지면 영업이익이 떨어진다.
C. 환율이 재조정되면 밸류에이션도 재조정돼야 한다.
여기서 "A회사 영업이익 어때?"라고 물으면 —
우리가 생각하는 RAG는 "영업이익 좋음"이라고 답한다. A만 읽고 B와 C를 못 끌고 올 수 있다는 거다.
반면 LLM 위키는 태그·링크 관계가 양방향이라 B, C를 근거로 붙여 읽는다:
"A회사는 영업이익은 좋지만, 환율이 빠지면 밸류 조정이 필요합니다."
이 차이가 실무에선 결정적이다. 보고서는 "좋다"로 끝나면 안 되고, "좋지만 이런 조건이 붙는다"까지 가야 하니까. 그래서 RAG는 '깎는' 느낌, 옵시디언 LLM 위키는 '연결하는' 느낌이라고 표현 하고 싶다. 따라서 옵시디언으로 LLM WIKI를 구조화 한다면 더 편하게 RAG를 구축할 수 있는 방법이 된다.
🔗 2막 — 왜 LLM 위키를 옵시디언으로 짓는가
LLM 위키의 본질은 양방향 링크로 지식을 엮는 것이다. 그 그릇으로 옵시디언이 가장 잘 맞은 이유:
개념이 일치한다 — LLM 위키 = 양방향 링크 구조 = 옵시디언이 원래 하는 일.
뭘 어떻게 적든 기본이 md 파일 — 평문 마크다운이라 컴퓨터(AI)가 잘 읽는다. 특수 포맷에 갇히지 않는다.
링크·그래프·메타데이터 구성이 편하다 — 보기 좋고 읽기 쉽다. 사람이 검토하기에도 최적.
한 도구로 끝난다 — 별도 DB나 인프라 없이 옵시디언 하나로 구성된다.
그래서 지식 자체는 옵시디언 LLM 위키로 연결해 쌓았다. 아래는 실제 그래프뷰다.
▲ 옵시디언 그래프뷰. 각 색이 하나의 분야를 이룬다. 수천 개의 노트가 외딴 점이 아니라 서로 연결돼 하나의 유기적 덩어리가 되고, 분야끼리도 다리로 이어진다. 이게 "깎기"가 아니라 "연결"의 실제 모습이다.
🗂️ 3막 — 근거 검색은 LLM WIKI 양방향성으로 이루어지며 보완이 된다.
지식 연결은 위키로 했지만, 회계기준서 및 법령 근거를 정확히 끌어오는 검색은 Vector DB 기반 RAG가 아니라 옵시디언 LLM WIKI구조를 택했다. 이유는 두 가지.
① 정확성·재현성이 우선이다. 업무상 기준서에 대한 출처 확인이 필수라, 정확도가 최우선이라고 판단했 다. FTS5는 검색 기반이라 실제 기준서 문단들을 그대로 끌어오는 데 유리하고, 같은 질문에 같은 결과가 나오는 재현성도 뛰어나다. 그게 양방향성으로 묶여있다면 서로 보완하면서 출처를 가져올 수 있다.
반면 Vector DB RAG는 의미 유사도로 검색하기 때문에, 의미는 비슷하지만 직접적인 근거는 아닌 문단이 나올 수 있다. 정확성·재현성 측면에서 더 낫다고 봤다.
② 전통적인 RAG의 LLM WIKI으로 보완된다. SQL+FTS5는 사용자가 "정확한 용어"를 못 대고 추상적으로 물으면, 의도를 못 잡고 엉뚱한 기준서를 가져올 리스크가 있다. 사용자가 질문을 던지면 LLM이 먼저 의도를 파악한 뒤 그 도구로 검색하게 했다. 추상적으로 물어도 LLM이 의도를 풀어 검색어를 보완해준다.
※ 전통적인 RAG를 무조건 배척하는 건 아니다. 다만 RAG를 제대로 쓰려면 Chunk 단위로 들어가야하고 이걸 조금더 편하고 양방향 링크를 해주는 도구가 LLM WIKI라 생각한다. 이 기반으로 RAG + 온톨로지 기반으로 업그레이드가 될 것이다.
📐 4막 — 무너지지 않게: 3층 구조와 규칙
위키가 커져도 무너지지 않으려면 골격이 필요했다. 분야가 달라도 같은 3층으로 지었다.
1층 — 원본(raw): 긁어온 기준서·법령·기사 원문. 절대 수정하지 않는 불변 자료.
2층 — 정제 지식: 원본을 읽고 요약·연결한 개념/실체 페이지.
3층 — 규칙(SCHEMA): 파일명 규칙, 태그 분류, "언제 새 페이지를 만들고 언제 합치는지" 기준.
여 기에 두 규칙을 강제했다: 모든 페이지는 최소 2개의 다른 페이지와 연결(외딴 노트 금지), 모든 작업은 로그에 기록(언제 뭘 넣었는지 추적). 그리고 각 위키는 자기 '입구'(규칙·목차·현재상태)를 가져서, AI가 매 작업 전 그 입구부터 읽고 시작한다 — 중복 생성과 누락 연결을 막는 장치다.
🔧 5막 — '운영 루프'로: AKM 차용 + 자동 적재
쌓기만으로는 신뢰도 관리가 안 됐다. AI가 자동 생성한 페이지와 내가 검증한 페이지가 같은 무게로 취급됐다. 그래서 AKM(지식 운영 패턴)에서 세 가지를 빌렸다:
신뢰도 사다리:
원본 → 미검증 → 검토됨 → 정본 → 폐기. 자동 생성 페이지는 '미검증'에서 시작하고, 검증해야 승급한다.다음 행동 큐: 페이지마다 "합칠 것 / 검증할 것 / 발전시킬 것" 꼬리표. 위키가 할 일 목록을 품는다.
되돌아 배우기: 실패하면 "어느 층의 문제였나"를 따져 그 층(규칙·페이지·신뢰도)을 고친다.
그리고 가장 큰 도약 — 일부 위키엔 자동 적재를 붙였다. 정해진 시각에 봇이 알아서 자료를 수집해 원본 층에 저장하고, 관련 페이지를 갱신하고, 목차를 다시 세고, 특이사항을 보고한다. 내가 손대지 않아도 위키가 매일 두꺼워진다.
🧹 6막 — 진짜 적은 '부족'이 아니라 '중복과 고아'
자라면서 깨달은 게 있다. 지식베이스가 망가지는 건 자료가 모자라서가 아니다. 같은 내용이 다른 이름으로 중복되고, 아무 데서도 연결 안 된 외딴 노트(고아)가 생기기 때문이다.
그래서 그래프뷰를 정기적으로 점검한다. 외딴 점이 보이면 연결하고, 중복은 정본 하나로 합치고(삭제는 휴지통으로, 복구 가능하게), 원본 층은 절대 안 건드린다. 위키가 중심으로 동그랗게, 유기적으로 연결된 하나의 덩어리가 되도록.
✅ 결과 (After)
RAG vs 옵시디언 LLM 위키 (내 기준)
항목
Vector RAG
옵시디언 LLM 위키 + FTS5
비유
깎기 (파편을 콕콕)
연결하기 (근거를 이어서)
맥락
조각만, 전제·예외 누락 가능
양방향 링크로 B·C까지 붙여 읽음
근거 정확성
의미 유사 ≠ 직접 근거
실제 기준서 문단 그대로
재현성
임베딩 의존, 흔들릴 수 있음
검색 기반, 같은 질문=같은 결과
추상적 질문
약함
MCP Tool+LLM 의도 파악으로 보완
구축 공수
Chunk 분할 등 큼
옵시디언 하나로, md만으로
결과물
옵시디언 LLM 위키(양방향 링크) — 지식 연결의 그릇
SQL + FTS5 근거 검색 엔진 (MCP Tool) — 정확성·재현성
카파시 3층 구조 + AKM 신뢰도·운영 루프
일부 위키 자동 적재 파이프라인
이 방식 전체를 내 모든 AI에 동일하게 적용
큰 카데고리에서의 옵시디언 화면이다.
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
"깎기 vs 연결하기"로 먼저 판단: 내 일이 파편 검색으로 충분한지, 맥락 연결이 필요한지부터 정하면 RAG/위키 선택이 쉬워진다. 법령·보고 업무는 후자였다.
구조를 먼저, 자동화는 나중: 수작업으로 구조가 검증된 뒤 자동 적재를 붙였다. 빈 구조에 자동화부터 얹었으면 쓰레기를 자동 생산했을 것이다.
이렇게 하면 안 돼요
맥락이 필요한 일에 파편 검색만 쓰기: "좋음"으로 끝나는 답은 보고서가 못 된다.
원본을 수정하기: 출처 자료를 고치면 근거 추적이 무너진다. 수정은 정제 페이지에서, 원본은 불변으로.
신뢰도 없이 섞기: 자동 생성과 검증 완료를 같은 무게로 두면, 약한 추정이 슬그머니 '사실'로 굳는다.
🌍 다른 업무에 적용한다면?
법무·규정 검토: 출처 확인이 필수인 모든 분야에 LLM WIKI 조합이 그대로 맞는다.
개인 연구·공부: 논문·자료를 양방향으로 엮으면 시간이 갈수록 답이 빨라지는 지식베이스가 된다.
팀 매뉴얼: 신뢰도 사다리로 "초안 vs 확정"이 구분돼 협업 문서의 신뢰가 올라간다.
🧬 사실, 온톨로지 확장의 베이스는 이미 깔려 있다
"나중에 RAG + 온톨로지로 업그레이드"라고 썼지만, 정리하다 보니 깨달은 게 있다 — 우리는 이미 온톨로지의 기반을 깔아놓고 있었다. 이미 회계의 XBRL자료와 법령정보의 LLM WIKI구조화가 name tag로 양방향이 이루어져있기 때문이다. 현재 7000개 이상의 md파일이 유기적으로 연동되어있기 때문이다.
온톨로지의 핵심은 타입이 있는 엔티티 + 타입이 있는 관계다. 그런데 LLM 위키를 제대로 지으면 이게 저절로 쌓인다:
① 클래스 체계는 이미 있다 — 각 페이지의
type필드가 그것이다. 법령이면본법(statute) → 시행령(enforcement_decree) → 시행규칙(enforcement_rule), 그리고판례(precedent). 본법▷시행령▷시행규칙이라는 위임 계층은 그 자체로 온톨로지의 상위/하위 관계다.② 인스턴스(노드)도 이미 수천 개 — 법령 본법/시행령/시행규칙 풀세트, 판례, 개념 페이지, 엔티티 페이지가 전부 온톨로지의 개체다.
③ 남은 건 '관계에 이름표 붙이기'뿐 — 지금은
[[링크]]로 연결은 돼 있지만, 그 링크가 무슨 관계인지(위임한다 / 개정한다 / 모순된다 / 근거가 된다 / 적용된다)는 아직 술어가 없다. 여기에 술어만 달면주어 - 술 어 - 목적어트리플, 즉 온톨로지가 된다. (AKM에서 빌린contradictions필드가 이미 그 첫 싹이다.)
즉 LLM 위키를 양방향 링크로 지어온 것 자체가, 온톨로지의 노드와 클래스를 품은 채 자라온 셈이다. 양방향 링크는 "관계는 있는데 이름표만 없는" 상태고, 확장은 맨땅이 아니라 이 위에서 자연스럽게 이어진다.
🚀 앞으로의 계획
RAG + 온톨로지로 검색 고도화 — 맨땅이 아니다. 엔티티 타입·계층 관계는 이미 위키에 깔려 있고(위 참조), 링크에 술어(관계 타입)만 붙이면 트리플 그래프가 된다. 여기에 RAG를 얹는 방향.
위키가 수백 노트로 커지면 보완 자료로 그래프 기반 검색(GraphRAG) 검토 — 온톨로지가 갖춰질수록 효과가 커진다.
자동 적재 패턴을 더 많은 분야 위키로 확장
