여섯 개를 다 보고 나서 — 지금 만드는 것과 비교해보니

지난 글까지 여섯 개를 하나씩 봤다. 이번엔 이 여섯 개를 한 판에 놓고, 지금 만드는 플러그인과 종합적으로 비교한다.

한눈에 — 여섯 개 + 지금 만드는 것

시크릿 저장 — 바로 손봐야 할 하나

여섯 개 중 검증 가능했던 두 곳(obsidian-llm-wiki, AI Wiki)이 전부 API 키를 동기화 대상(data.json)에서 빼뒀다. 지금 만드는 플러그인은 apiKey/openaiApiKey/claudeApiKey가 평범한 설정 필드로 data.json에 저장되고 있고, 지금 CouchDB(LiveSync)로 볼트를 동기화하고 있으니 이 키들이 그대로 동기화 서버에 올라가고 있다는 뜻이다. 이번 조사 전체에서 가장 실질적이고 급한 발견이었다.

검색 방식 — RAG가 다수파, 그래프는 소수파지만 근거가 있다

여섯 개 중 명확히 확인된 것만 보면 RAG(임베딩) 계열이 다수고, obsidian-llm-wiki만 그래프+PPR로 임베딩을 아예 안 쓴다. 근데 이 소수 선택엔 근거가 있었다 — 자체 벤치마크로 순수 kNN 대비 우위를 주장하고 있고, 이론적으로도 “의미적으로 비슷해 보이는데 실제로는 무관하다”는 위험이 링크 기반 그래프에서는 구조적으로 줄어든다(링크가 있어야만 관련 있다고 취급하니까). 다만 링크가 안 걸린 진짜 관련 정보를 놓칠 수 있다는 대가도 있다.

아키텍처 — 모놀리식에서 서비스 레이어까지 스펙트럼

GenWiki(파일 1개, 1099줄) → 지금 만드는 것(main+ChatView 이원화) → Auto LLM Wiki(Provider 인터페이스로 최소 분리) → AI Wiki(컨트롤러 분리) → obsidian-llm-wiki(믹스인으로 잘게 쪼갬) → AI RAG + LLM Wiki(서비스 30개)까지, 규모가 커질수록 자연스럽게 이 스펙트럼을 따라 이동하는 걸로 보였다. 지금 규모에서 서비스 레이어까지 갈 필요는 없어 보이지만, 기능이 더 늘어나면 컨트롤러 분리 정도는 고려할 만하다.

차별점이라고 생각했던 것 — 다시 파보니 둘 다 근거가 없었다

여섯 개를 다 열어봐도 하나같이 “지식(개념·엔티티) 위키”에 집중하고 있었다. 팀원의 성장 궤적·약속·1:1 면담록·프로젝트 역사를 대화하듯 추적한다는, 지금 만드는 플러그인의 원래 목표는 이 여섯 개 어디에도 없었다. 그래서 처음엔 이걸 “남는 차별점”으로, RAG의 오탐 문제를 그래프 방식 대비 약점으로 정리했다. 근데 둘 다 더 파보니 근거가 없었다.

관리자 시점 사람 추적은, 코드를 직접 뜯어보니 지금 아키텍처가 못 뒷받침한다는 게 드러났다. 엔티티 페이지가 새 정보를 받을 때마다 기존 내용에 하나의 서술로 병합되는 구조라, “몇 번째 만남에서 무슨 얘기를 했는지” 같은 회차 경계 자체가 병합 과정에서 사라진다 — “두 번째 1:1이 뭐였어?” 같은 질문에 지금 구조로는 답 못 한다. 만들려면 아키텍처를 새로 짜야 하는데, 그럴 계획은 없다.

RAG 오탐도 마찬가지였다. “직접 겪은 사례가 있다”고 썼던 근거는 사실 RAG 파이프라인(RagRetriever) 밖(기능 설계 논의)에서 난 사건이었고, RagRetriever 자체를 실제 볼트(329개 실제 노트)로 두 번(다른 모델로 한 번씩) 실측해봐도 오탐이 한 건도 안 나왔다. 검증 게이트를 만들 근거가 없었다.

정리

이번 시리즈에서 실제로 액션으로 이어진 건 결국 하나였다 — API 키를 동기화 안 되는 곳(local.json)으로 옮긴 것. 나머지 둘(RAG 검증 게이트, 관리자 시점 사람 추적)은 처음엔 그럴듯해 보였지만, 더 파보니 둘 다 근거가 확인 안 된 채로 단정했던 것들이었다. 코드를 직접 열어보고 실제로 돌려보지 않았으면, 이 셋 중 뭐가 진짜고 뭐가 아닌지 끝까지 몰랐을 거다.