만들고 있는 Obsidian 플러그인은 원문 자료(raw 파일)를 넣으면 LLM이 읽고 개념별 wiki 노트로 나눠 정리해준다. 그러다 보니 원문 내용이 노트로 옮겨지는 과정에서 뭔가 빠지거나 중복되는 버그가 계속 나오고, 나는 그걸 확인하려고 원문 파일 하나하나를 거기서 만들어진 노트들과 대조하는 전수 감사를 Claude Code의 서브에이전트(작업을 나눠 맡기는 별도 AI 에이전트)들에게 나눠 맡겨 왔다. 서브에이전트는 파일마다 빠진 게 없으면 CLEAN, 있으면 무엇이 빠졌는지를 보고한다.
1편에서는 플러그인 안에 있는 감사 장치(노트 병합 전에 LLM이 한 번 더 판단하는 단계)가 설계상 못 보던 실패 유형을 찾았다. 이번엔 플러그인이 아니라, 그런 결과를 확인하는 데 매번 쓰던 내 방법 — 서브에이전트 전수 감사 — 에서 같은 종류의 구멍이 나왔다.
”근래에 안 나타나는 이슈가 있나” 질문에 제대로 된 답이 안 나왔다
플러그인의 GitHub 이슈 목록을 놓고, 최근엔 재현이 안 되는 게 있는지 Claude에게 물었다. Claude는 지난 전수 감사 결과를 근거로 몇 개를 골라 답했다. 그래서 되물었다. “136, 143, 95, 97, 50번 이슈는 왜 안 봤지? 노트 전수 조사하면서 봐야 하는 거 아냐?” 직전에 56개 raw 파일 전체를 서브에이전트 3배치로 감사했다고 보고해놓고, 정작 그 결과를 이슈 하나하나에 제대로 대조하지 않은 것이었다.
서브에이전트가 CLEAN이라고 한 파일 중 2개가 틀려 있었다
서브에이전트가 CLEAN으로 보고한 파일들을 이슈 목록과 맞춰보다가, 리스트(불릿) 밀도가 높은 파일 몇 개를 직접 열어봤다. “EDGE AI London 2026 행사 및 시장 인사이트”는 파트너사 14곳이 파생 노트 어디에도 없었다 — 이미 열려 있던 이슈와 정확히 같은 패턴이었다. “AI is removing the middle class of software engineering”도 마찬가지로, 같은 작업 중에 이미 한 번 놓친 적 있는 체크리스트 항목이 이번에도 그대로 빠져 있었다. 리스트 밀도 상위 4개를 골라 대조했더니 2개가 틀려 있었다 — 절반이었다.
AI 감사가 리스트 항목을 하나씩 안 세고 뭉뚱그려 판정하고 있었다 — 프롬프트 A/B 테스트
서브에이전트에게 준 지시는 “raw 파일 전체를 읽고, 파생 노트 전체를 읽고, 비교하라”였다. 이 지시로는 짧은 인용문이나 숫자 하나는 잘 잡아내지만, 열 몇 개짜리 나열형 리스트 앞에서는 항목을 하나씩 대조하는 대신 전체 인상만 보고 “다 있다”고 판단해버리는 경우가 있었다. 같은 파일, 같은 지시를 다시 줘봐도 재현되는 문제라, 우연이 아니라 지시 자체의 구조적 빈틈이었다.
이걸 확인하려고 A/B 테스트를 했다. 같은 파일에 프롬프트 A(기존의 “읽고 비교하라”)와 프롬프트 B(“먼저 원문의 모든 불릿·나열 항목을 번호 매겨 체크리스트로 만들고, 그 다음 항목 하나씩 개별적으로 있는지 없는지 판정하라, 여러 항목을 한 문장으로 뭉뚱그려 ‘커버됨’이라고 쓰지 마라”)를 각각 돌렸다. A는 71초 만에 끝났고 똑같은 항목을 또 놓쳤다. B는 304초 (A의 4.3배) 걸렸지만 그 항목을 정확히 MISSING으로 잡아냈다. 배치 안에서 두 미스 다 파일 순서상 끝자락이 아니라 중후반부였다는 것도 확인했다 — “지쳐서 대충 본다”는 가설은 아니었고, 원인은 파일 안의 리스트 밀도였다.
체크리스트를 강제하는 프롬프트로 리스트 누락을 잡았다 (불릿 개수 랭킹 스팟체크)
B 프롬프트를 배치 전체에 쓰는 건 현실적이지 않았다(4.3배 느리고, 리포트 분량도 감당하기 어려울 만큼 커진다). 대신 절차를 한 단계 더 넣었다: 배치 감사가 끝나면 raw 파일들을 불릿 개수로 랭킹을 매기고, 그중 상위 파일들 — 서브에이전트가 CLEAN이라 보고한 것 포함 — 을 직접(서브에이전트에게 다시 맡기지 않고) 스팟체크한다. 여기서 실제 누락이 나온 파일만 B 프롬프트로 넘겨 정밀 재확인한다. 이 절차를 문서 하나에 정리해서, 다음에 이 감사를 또 돌릴 때 프롬프트를 기억에 의존해 재구성하지 않도록 해뒀다.
남는 생각
다른 시리즈의 9편과 이 시리즈 1편은 둘 다 “플러그인의 감사 장치가 어디까지 진짜로 맞는지” 실측한 이야기였다. 이번엔 그 감사 장치가 맞는지 확인하려고 매번 쓰던 방법 — 서브에이전트에게 전수 대조를 맡기는 것 — 자체를 실측 앞에 세워야 했다. “서브에이전트가 CLEAN이라고 했다”는 것과 “서브에이전트가 실제로 모든 항목을 하나씩 확인했다”는 것은 다른 문장이었고, 그 차이가 리스트 밀도가 높은 파일에서만 조용히 드러났다. 감사를 도구에 맡기는 것 자체는 여전히 유효하다 — 다만 그 도구의 “다 봤다”는 말을 그대로 믿기 전에, 최소한 몇 개는 내 눈으로 직접 세어봐야 한다는 것만 이번에 다시 확인했다.