Obsidian × LLM 2년 운영 실측 — 4만 노트 개인 RAG의 최종 아키텍처 5층

조각은 다 검증했다 — 이제 조립도를 그릴 차례

이 시리즈에서 개인 지식관리 × LLM 주제를 조각조각 실측해 왔습니다. 온톨로지맵으로 나만의 RAG 만들기, 30시간 벤치마크(내 금고 vs AI가 만든 위키, 72:70), 검색 방식 비교(하이브리드 5.5배), 앱 없이 검색하는 오픈소스 벼리까지. 독자 질문이 어느 순간부터 같은 곳을 가리켰습니다 — “그래서 전체 그림이 어떻게 되나요?”

이 글은 그 답입니다. 새 실측 주장은 없습니다. 검증된 조각들을 운영 2년여의 최종 배치도로 조립한 편입니다.

5층 아키텍처 — 지식은 쌓는 게 아니라 돌리는 것

각 층은 독립적으로 교체 가능합니다. 노트 앱을 바꿔도(L1), 검색 엔진을 바꿔도(L2), 대형언어모델을 바꿔도(L4) 나머지 층은 그대로 살아남습니다 — 이것이 ‘도구’가 아니라 ‘아키텍처’에 투자해야 하는 이유입니다.

원소 노트 + 머리말 한 줄 — AI가 읽는 지식의 형식

저장층의 규율은 단 두 가지입니다.

첫째, 한 파일 = 한 개념(원소 단위). “회의록 2026-05” 같은 통짜 파일이 아니라, 그 회의에서 나온 결정·패턴·체크리스트를 각각 한 파일로 쪼갭니다. 검색이 문서가 아니라 개념을 돌려주게 만들기 위해서입니다.

둘째, 머리말(frontmatter) 한 줄. 파일 상단에 유형·주제·출처를 적는 몇 줄의 속성이 검색층의 ‘손잡이’가 됩니다. 거창한 분류 체계는 필요 없습니다 — 오히려 유지가 안 돼서 무너집니다.

하이브리드가 5.5배 — 키워드와 벡터는 경쟁자가 아니다

4만 노트쯤 되면 “LLM에게 폴더를 통째로 읽히면 되지 않나”가 통하지 않습니다. 느리고, 비싸고, 맥락 창을 넘칩니다. 그래서 검색층이 별도로 필요한데, 여기서 2년의 결론은 명확합니다.

중요한 건 순서가 아니라 합치는 것입니다. 지식노동의 질문 절반은 “그 단어가 뭐였지”(키워드형)이고, 나머지 절반은 “비슷한 걸 어디서 봤는데”(의미형)입니다. 한쪽만 켜면 절반의 질문에서 지식베이스가 침묵합니다.

앱 없이, 0.4초, 0원 — 헤드리스 상주 서버

처음엔 노트 앱을 열어 두고 그 검색 기능을 LLM이 부르게 했습니다. 작동은 하지만 두 가지가 걸렸습니다 — 앱이 꺼져 있으면 지식도 꺼진다는 것, 그리고 호출마다 초 단위로 느리다는 것.

최종 배치는 헤드리스(화면 없는) 상주 서버입니다. 가벼운 임베딩 모델을 로컬에 올려 두고, LLM이 소켓으로 물으면 0.4초대에 답합니다. GPU도, 클라우드 구독도 쓰지 않습니다 — 지식은 내 컴퓨터 밖으로 나가지 않습니다(망분리 환경에서도 같은 구조가 성립하는 이유입니다).

인용하게 하고, 되돌려 넣어라

소비층의 규율은 하나입니다 — 인용 없는 답은 받지 않는다. LLM에게 지식베이스를 붙이는 목적은 “더 그럴듯한 답”이 아니라 “출처가 달린 답”입니다. 어느 노트에서 온 주장인지 파일명이 딸려 오도록 강제하면, 환각은 대부분 그 관문에서 걸러집니다.

순환층은 가장 자주 무너지는 층입니다. 오늘 LLM과 함께 만든 보고서·회고·결정이 그대로 산출물 폴더에 잠들면, 지식베이스는 과거만 아는 창고가 됩니다. 저는 작업이 끝날 때마다 한 가지 질문을 겁니다 — “이 결과물에서 다음에도 쓸 원소는 무엇인가?” 그 원소(패턴·체크리스트·결정 이유)만 노트로 쪼개 L1에 되돌려 넣습니다. 이 루프가 돌기 시작하면 지식베이스는 쓸수록 강해집니다.

개인의 아키텍처가, 여섯 현장에서 같은 값을 냈다

이 5층 구조는 제 개인 환경의 설계도지만, 원리는 기업 워크숍 현장에서 반복 검증됐습니다. 회사와 도메인이 바뀌어도 결론이 같았습니다 — “자료가 곧 품질”.

이 아키텍처의 실측 성적표

4만 노트가 없어도 시작하는 법

이 설계도의 조각 실측들