Obsidian에 LLM Wiki 만들기 4편 — 자율 Ingest 엔진으로 진화하기까지

이 글은 Obsidian에 LLM Wiki 만들기 시리즈의 4편이다.

앞선 세 편이 채팅 기능을 다듬는 이야기였다면, 여기서부터는 플러그인의 성격 자체가 바뀐다. 단순히 물어보면 답하는 채팅창에서, 원본 자료를 스스로 읽고 위키 문서로 정리하는 자율 에이전트로 — 지금 이 시리즈의 제목이기도 한 “LLM Wiki” 개념이 본격적으로 들어오는 지점이다.

공간을 나눠서 권한을 주기

에이전트에게 파일을 마음대로 만들고 고치게 허용하는 건 위험하다. 그래서 vault 안의 공간을 두 구역으로 나눴다.

• 안전 구역(/wiki/): AI가 정리한 위키 문서가 쌓이는 곳. 여기는 사용자 승인 없이 자율적으로 파일을 만들고 고칠 수 있게 허용.
• 보호 구역(그 외 전부): 원본 자료나 다른 노트가 있는 곳. 여기는 AI가 뭔가 만들려고 하면 먼저 승인을 받아야 하는 게이트키퍼(Dispatcher)를 통과해야 한다.

이 구조가 제대로 작동하는지 두 가지 시나리오로 테스트했다.

테스트 1(안전 구역): “wiki/test-agent.md 파일을 하나 생성해 줘”라고 시키니, AI가 명령을 내리고 Dispatcher가 그걸 실행해서 실제로 파일이 만들어졌다. 정상.

테스트 2(보호 구역): “보관함 최상위에 danger-test.md를 생성해 줘”라고 시켰다. 기대한 동작은 파일 생성이 차단되고 화면에 승인 대기 경고가 뜨는 것이었다.

파일은 안 만들어졌는데, 경고도 안 뜬다

테스트 2 결과가 이상했다. 스크린샷을 첨부해서 그대로 리포트했다.

테스트1은 잘 작동했어. 테스트2는 첨부 파일을 보다싶이 실제로 파일이 생성되지는 않았는데, 채팅창에 뭔가 제대로 표시를 하거나 경고 알람등이 안 뜨네

원인은 두 가지가 겹쳐서 발생한 거였다.

1. AI의 “섀도우 복싱”: AI가 도구 사용법을 너무 잘 숙지한 나머지, 시스템이 실제로 명령을 실행한 결과를 기다리지 않고 스스로 [시스템 결과]: 생성 성공 같은 가짜 텍스트를 미리 지어내서 출력해버렸다. 실제로는 파일이 안 만들어졌는데, 채팅창엔 마치 성공한 것처럼 보이는 문장이 떠 있었던 거다. 정확히는 그 가짜 성공 텍스트조차 화면에 제대로 안 뜨는 표시 버그까지 겹쳐서, 결과적으로 “아무 일도 안 일어난 것처럼” 보였다.
2. 경고가 눈에 안 띔: 원래 있던 Notice 알림은 화면 우측 상단에 작게 떴다가 금방 사라지는 방식이라, 정작 차단이 실제로 발생했을 때도 놓치기 쉬웠다.

즉 AI를 못 믿을 상황이 실제로 벌어진 거였다 — 시킨 대로 실행했다고 보고했지만, 사실은 실행되지 않았다. 이게 왜 위험한지는 명확하다. 만약 이 경고를 못 보고 “그렇구나”하고 넘어갔다면, 실제로는 아무 작업도 안 됐는데 됐다고 믿고 있었을 거다.

해결책

• AI가 스스로 지어낸 가짜 [시스템 결과] 텍스트를 화면에 뿌리기 전에 정규식으로 걸러서 잘라낸다 — 진짜 시스템이 낸 결과만 보이게.
• 차단이 발생하면 작은 Notice 알림 하나로 끝내지 않고, 채팅창 안에 붉은색 경고 블록쿼트로 크게, 확실히 보이게 만든다.

안전장치를 깔고 나서 본격적으로 확장

권한 구조와 검증이 자리잡고 나서야 “자율 Ingest 엔진”을 4단계로 설계했다.

1. 다중 명령 처리 + UI 마스킹: AI가 한 응답에서 여러 개의 명령을 내려도 순서대로 실행하고, 채팅창에서 [CALL: ...] 같은 기계어는 안 보이게 가린다.
2. 원본 삭제 동기화: /wiki 문서 안에 적힌 출처(Source: raw/파일명.md)를 확인해서, 그 원본이 vault에서 사라지면 위키 문서도 자동으로 같이 지운다. 쓰레기 데이터가 쌓이는 걸 막는 안전장치다.
3. 재귀 스캔 + 자동 Ingest: /raw/ 아래를 전부 훑어서, 아직 /wiki에 요약이 없는 신규 파일만 골라 AI에게 넘기고 1:1로 요약 문서를 만들게 한다.
4. 청킹 + 진행도 UI: 신규 파일이 한꺼번에 많이 들어오면 토큰 한도를 고려해서 묶음 단위(예: 3개씩)로 나눠 순차 처리하고, ⏳ 1/3 그룹 처리 중... 같은 진행 상황을 보여준다.

이 4단계 설계가 지금 플러그인의 /ingest 명령으로 그대로 살아있다. raw/에 쌓아둔 원본과 wiki/에 이미 정리된 문서를 비교해서 신규 파일만 골라내는 로직도, 이때 세운 “이미 처리된 것과 신규를 어떻게 구분할지”에 대한 답이 지금까지 이어진 거다.

돌아보며

이 시리즈를 쓰면서 다시 느낀 건, 지금 잘 작동하는 기능 뒤에는 대부분 한 번쯤 이렇게 믿었던 게 깨지는 순간이 있었다는 거다. AI가 스스로 실행했다고 보고했지만 실제로는 아니었던 이 사건이, 결국 지금 이 플러그인 안에 있는 “안전 구역/보호 구역” 구분과 승인 절차의 출발점이 됐다. 비슷한 시기에 겪었던 또 다른 승인 관련 사고 — 뉴스 요약 자동화 프로젝트 쪽에서 AI가 승인 없이 블로그 코드를 고쳐서 배포까지 깨뜨린 이야기는 다른 글에 따로 정리해뒀다.