이 플러그인이 하는 일 — LLM으로 Obsidian 노트 자동 정리
먼저 배경부터. 개인적으로 만들고 있는(아직 공개 전인) 플러그인이 하나 있다. Obsidian이라는 메모 앱 위에서 LLM으로 노트를 정리해 주는 플러그인이고, 핵심 기능은 두 개다.
첫째, 노트 정리 기능(이하 ingest)은 뉴스 기사나 블로그 글 같은 원본 텍스트(“raw” 문서)를 읽어서, 그 안에 담긴 개념·인물·사건 하나하나를 독립된 메모(“wiki” 노트)로 쪼개 만든다. 예를 들어 “AI 시대에 살아남는 리더의 8가지 습관”이라는 기사 하나를 넣으면, 그 기사가 언급한 8가지 습관 각각과 기사에 나온 인물이 전부 별도의 노트로 나뉘어 생성된다. 한 노트가 하나의 명확한 개체·개념만 다루게 만드는 이 원칙을 이 플러그인에서는 “아토믹화(atomicity)“라고 부른다. 노트 하나가 여러 주제를 뭉텅이로 담고 있으면 나중에 검색도, 다른 노트와의 연결도 애매해지기 때문이다.
둘째, 위키 정리 기능(이하 refactor)은 그렇게 쌓인 노트들을 나중에 다시 훑어서, 사실은 같은 걸 다루는 노트 두 개가 따로 존재하면 병합을 제안하고, 반대로 한 노트에 여러 개념이 뭉쳐 있으면 분할을 제안한다. ingest가 새로 들어오는 글을 잘게 쪼개는 입구라면, refactor는 그렇게 쌓인 창고를 정리하는 역할이다.
이 시리즈는 ingest의 품질(=쪼개는 게 얼마나 정확한가)을 놓고 몇 주에 걸쳐 벌어진 조사 기록이다. 이 조사를 하게 만든 계기는 아주 단순한 관찰 하나였다.
같은 원본, 같은 결과일 줄 알았다 — LLM 결과 재현성
이 플러그인을 실제로 굴리는 테스트 볼트(vault, Obsidian이 부르는 “작업 폴더” 단위)가 하나 있다. 이 볼트는 Obsidian LiveSync라는 별도 플러그인으로 노트북 두 대(이 글에서는 “노트북 1”, “노트북 2”라고 부르기로 한다)에서 실시간으로 동기화되고, 그와는 별도로 그 볼트의 raw/wiki 폴더 내용을 git 저장소로도 관리한다 — 그래야 노트 내용을 시점별로 비교하고 감사할 수 있으니까.
이 테스트 볼트에는 뉴스 기사·블로그 글 30개가 raw 원본으로 들어있다. 노트북 1에서 이 30개를 전부 ingest로 새로 처리했더니 wiki 노트 189개가 나왔다. 같은 원본 30개를, 같은 버전의 플러그인으로, 노트북 2에서 다시 처리했다. 나온 노트는 63개였다.
3배 가까운 차이였다. 원본도 같고 플러그인 버전도 같은데, 기기를 바꿨다는 이유만으로 결과가 이렇게까지 벌어질 이유가 없었다. 개별 사례를 몇 개 열어보니 차이는 더 뚜렷했다. “The 10 Best Open-Source Coding LLMs Right Now”라는 원문 하나를 놓고, 노트북 1 결과물은 GLM 5.2·Kimi K2·DeepSeek V4·Qwen3 Coder·MiniMax M3 등 원문이 언급한 모델 하나하나가 전부 독립된 노트로 나뉘어 15개가 만들어졌다. 같은 기사를 처리한 노트북 2 쪽 결과물은 노트 3개뿐이었고, 개별 모델 이름은 대부분 노트 제목·본문에서 사라져 있었다. “AI 시대, 대체 불가능한 리더가 되는 8가지 방법”이라는 기사도 마찬가지였다 — 노트북 1은 8가지 습관과 인물을 각각 나눠 노트 10개를 만들었는데, 노트북 2는 그 8가지를 통째로 뭉쳐 “AI 시대 대체 불가능한 리더십”이라는 노트 1개로 만들어버렸다.
같은 입력, 같은 소프트웨어인데 결과가 이렇게 다르다는 건 둘 중 하나였다. 플러그인 안에 기기 환경에 따라 달라지는 버그가 있거나, 아니면 두 기기의 설정값 자체가 서로 달랐거나.
용의자를 하나 찾았다 — LLM 청크 사이즈(chunk size)
플러그인 설정을 뒤져보니 ingestChunkSize라는 값이 있었다. ingest가
raw 원본을 한 번의 AI 호출로 몇 개씩 묶어서 처리할지 정하는
숫자다. 이 값이 크면 여러 원본을 한 번에 묶어 보내니 API 호출
횟수가 줄어 전체 처리 시간이 짧아지지만, 그만큼 한 번의 호출에
쑤셔 넣는 내용이 많아진다는 뜻이기도 하다.
두 기기의 값을 확인해보니 노트북 1은 2, 노트북 2는 6으로 설정돼 있었다. 당장 심증이 가는 용의자였다 — 한 번에 처리하는 양이 3배 차이 나니, 결과 노트 수가 3배 가까이 차이 나는 것도 앞뒤가 맞아 보였다. 하지만 심증만으로 결론을 내릴 순 없었다. 정말 이 숫자 하나가 원인인지, 아니면 다른 뭔가가 더 섞여 있는 건 아닌지 확인하려면 나머지 조건을 전부 고정한 채로 이 값 하나만 바꿔가며 실측해봐야 했다.
그래서 같은 원본 30개를 놓고, 청크 크기만 바꿔가며 다시 돌리는 통제 실험을 설계했다. 그 결과 — 그리고 그 결과가 예상보다 훨씬 더 많은 걸 알려줬다는 이야기가 다음 편이다.
2편에서 이어진다.