만들고 있는 Obsidian 플러그인은 새 원본 문서를 넣으면 AI가 읽고 위키
노트로 정리해준다(/ingest). 그 뒤 위키 전체를 다시 훑으면서 서로
겹치는 노트를 찾아 병합하자고 제안하거나, 지나치게 커진 노트를 쪼개자고
제안하는 별도 명령이 있다(/refactor). 병합 제안은 곧바로 실행되지
않고, 그 전에 “이 둘을 정말 합쳐도 되는가”를 다시 판단하는 감사
LLM 호출을 한 번 더 거친다.
예전 글에서 이 감사를 이미 한 번 손봤었다 — 후보 두 노트만 보여주고 판단하게 하면 자주 틀렸는데, vault 안에 두 후보 모두와 내용이 겹치는 제3의 노트가 있으면 그 존재 자체를 증거로 감사 프롬프트에 같이 넣어주는 방식으로 바꾸자 검증 32번 중 32번이 정확해졌다.
그 뒤로 몇 주가 지났다. wiki 전체를 지우고 처음부터 다시 /ingest한
뒤 이어진 /refactor 스캔 결과를 전수로 감사하다가, 그 감사 장치가
놓친 사례 하나를 발견했다.
병합 제안 하나가 이상했다
새 스캔이 낸 병합 제안 중 하나는 “불안한 리더”와 “불안형 리더” 두 노트를 하나로 합치자는 것이었다. reason에는 “두 문서는 모두 불안형 리더를 주제로 하며 분류와 태그가 동일하고… 같은 리더십 패턴이 서로 다른 명칭으로 분산되어 있다”고 적혀 있었다.
두 노트를 직접 열어봤다. “불안한 리더”는 “불안형 리더”와 “회피형
리더” 두 하위 유형을 아우르는 상위 개념 노트였다 — 본문에 “불안한
리더는 크게 불안형 리더와 회피형 리더로 구분된다”는 문장이 그대로
있었다. “불안형 리더”는 그중 한 하위 유형만 다루는 별개 노트였다.
## Related pages에 상위→하위, 하위→상위 양방향 링크까지 정확히
걸려 있는, 잘 구조화된 계층 관계였다. 이걸 병합했다면 상위 개념 문서가
사라지고, 두 하위 유형을 대비해서 설명하던 맥락도 같이 없어졌을 거다.
예전엔 32번을 다 맞혔는데, 왜 이건 놓쳤을까
이 감사 장치는 방금 설명한, 제3의 노트를 증거로 채워서 32번 다 맞혔던 그 병합 감사가 맞다. 실제로 코드를 열어서 확인했다. 원인은 판단력이 아니라 애초에 이 감사가 켜지지도 않았다는 것이었다.
이 감사는 “임베딩 유사도로 제3의 노트를 찾고, 못 찾으면 곧바로 승인”하는 구조다. 그때 검증한 상황은 전부 “두 후보의 하위 항목이 이미 vault 다른 곳에 독립 노트로 존재하는가”였다 — 그 경우는 제3의 노트라는 증거가 실제로 존재한다. 그런데 “불안한 리더”와 “불안형 리더”는 다르다. 겹치는 건 제3의 노트가 아니라 후보 둘 자신이다. 한쪽이 다른 쪽의 상위 개념이라는 관계는, “제3의 노트와 겹치는가”라는 질문으로는 원천적으로 잡을 수 없는 신호다. 그래서 증거 탐색이 빈손으로 끝났고, 감사 자체가 LLM을 부르지도 않고 조용히 승인해버린 것이다.
이미 있던 기준을 못 찾고 있었다
더 파보니, “포함 관계는 동일성이 아니다”라는 정확한 기준이 이미 코드베이스에 있었다. 제목이 완전히 달라서 클러스터링만으로는 안 묶이는 후보를 찾아내는 별도 검증 단계에 쓰던 프롬프트였다. 거기엔 “한쪽이 다른 쪽의 상위 개념/하위 구성요소/특정 사례인 관계도 다른 개념”이라고 명시돼 있었다. 그런데 이 기준은 그 후보 탐지 단계에서만 쓰이고, 실제로 생성된 병합 제안을 검증하는 게이트로는 한 번도 연결된 적이 없었다.
게이팅을 아예 없애기로 했다
처음엔 “증거가 없을 때만 포함 관계도 같이 확인하도록 예외를 추가하자”는 쪽으로 생각했다. 그런데 그러면 판단 조건이 두 갈래로 갈라져서 다음에 또 비슷한 구멍이 생길 여지가 있었다. 대신 증거 게이팅 자체를 없애고, 매 병합 후보마다 항상 감사 LLM을 거치도록 통일했다. 증거가 있으면 프롬프트에 덧붙이고, 없으면 그냥 문서 두 개만 놓고 판단하게 했다. 프롬프트에는 “포함 관계는 동일성이 아니다”를 새 기준으로 추가했다.
트레이드오프는 명확했다. 증거가 없어도 병합 후보마다 LLM 호출이 하나씩 늘어난다. 그때 “필요 없으면 LLM을 아예 안 부르는” 쪽으로 설계했던 절약분을 이번엔 되돌리는 셈이다. 그래도 이번 오판이 실제 계층 구조를 무너뜨렸을 사례라, 감수하기로 했다.
남는 생각
그 예전 글의 결론은 “본문 전체를 줘도 안 되던 판단이, 필요한 증거 하나를 채워주니 32번 중 32번이 됐다”였다. 이번 이야기는 그 결론을 뒤집는 게 아니라, 그 결론이 다루던 문제의 범위를 좁혀서 보여준다 — 그 감사가 정확히 겨냥한 실패 유형(제3의 노트와 겹침)에서는 여전히 정확했다. 문제는 애초에 이 감사가 다른 실패 유형(후보끼리의 포함 관계)을 겨냥하도록 설계된 적이 없었다는 것이다. “이 감사가 잘 작동하는가”와 “이 감사가 잡도록 만들어진 문제가 실제로 벌어지는 문제 전부인가”는 서로 다른 질문이고, 32번의 성공은 첫 번째만 증명했다.