Obsidian의 Zettelkasten을 Claude Code에 읽혀서 사용하고 있습니다. AI가 자신의 노트를 참조하여 조사나 구현의 판단 재료로 삼는, 이른바 '제2의 뇌'를 AI와 공유하는 운용 방식입니다.

이 운용을 하면서 노트 작성 방식에 관한 함정을 발견했습니다. '왜 그것이 문제인가'라는 깨달음에 대한 이야기는 사상 편(note)에 썼으므로, 본 기사에서는 구현에 초점을 맞춥니다. 한마디로 요약하자면 다음과 같습니다.

AI가 recall(축적된 지식을 불러와 사용하는 것)한다는 전제라면,

과도하게 일반화된 명제는 '오독 버그'가 된다. 단, 단정이 적절한 명제도 있으므로 단정을 일률적으로 피하는 것은 오류다.

이 기사에서 다루는 것은 다음 4가지입니다.

• 실패 패턴인 '과도한 일반화(over-generalization)'란 무엇인가
• 단정해도 좋은 명제와의 판정 축
• 규약을 어디에 둘 것인가 (정본 분리의 3층 구조)
• 점검을 단발성으로 끝내지 않고 시스템화하기

무엇이 문제인가 — 과도한 일반화

저는 평소 AI와의 세션이 끝나면 대화 내용을 증류하여 재사용 가능한 보편 지식(Knowledge와 Zettelkasten으로 분류)으로 변환하는 기술을 실행하며, 취사선택 및 조정을 거쳐 Vault에 저장하곤 합니다.

어느 날, 세미나에서 배운 내용을 Zettel로 증류했습니다. 제목은 다음과 같았습니다.

[Ops] 자동화는 전자동이 아니라 반자동(사람의 확인을 한 곳 남겨둠)이 지속된다

저장하자마자 위화감이 들었습니다. 이것은 '사람이 판단·전송하는 업무'에서는 맞지만, 멱등성(Idempotency)이 있고 가역적인 처리, 예를 들어 백업, CI, 자동 테스트에는 해당하지 않습니다. 한정적으로만 성립하는 주장을 무조건적으로 단정하고 있는 것입니다.

사람이 읽는다면 문맥을 보완하여 '전부는 아니겠지'라고 읽고 넘길 수 있습니다. 하지만 AI는 글자 그대로 적용합니다. '자동화 = 반자동'이라는 규칙으로 recall하여, 전자동이 옳은 상황에서도 확인 단계를 거치게 만들려 합니다.

이러한 '한정적인 주장이 무조건적인 명제로 작성된' 상태를, 본 기사에서는 **과도한 일반화 (over-generalization)**라고 부릅니다.

포인트는 이것이 AI에게 읽힌다는 전제하에서 비로소 현상화되는 문제라는 점입니다. 기존의 Zettelkasten론이나 Evergreen notes는 '1노트 1개념', '밀접한 링크'까지는 설파하지만, AI가 recall 한다는 전제의 작성법, 즉 recall 내성에 대해서는 고려하지 않고 있습니다.

판정 축 — 단정 그 자체는 나쁘지 않다

여기서 실수하기 쉬운 것이 '단정형 노트를 일률적으로 수정하는 것'입니다. 이는 과잉 수정이 됩니다. 적절하게 한정된 명제까지 완곡하고 모호하게 만들어 버립니다.

명제는 세 가지로 나누어 생각하면 정리할 수 있습니다.

판정 기준은 심플합니다.

제목이 단정형인지가 아니라,

제목 + 본문에서 적용 조건이 제시되어 있는가.

제목이 다소 강하더라도 본문에 '~일 때', '~가 많다', '예외' 등이 적혀 있어 적용 범위가 한정되어 있다면 문제없습니다. 반대로 제목도 본문도 무조건적이라면 과도한 일반화입니다.

왜 '가치관·원체험·관찰 언명'은 단정해도 괜찮은 걸까요? 이것들은 세상의 법칙을 주장하는 것이 아니라, 자신의 판단 축이나 관측한 사실의 기록이기 때문입니다. AI가 recall 하더라도 '이것은 이 사람의 판단 축이다'라고 취급할 뿐, 스코프 밖으로의 오적용이 일어나지 않습니다.

고치는 법 — 판단 축화와 안전한 리네임

실제로 수정한 예시입니다.

Before:

---
title: 자동화는 전자동이 아니라 반자동(사람의 확인을 한 곳 남겨둠)이 지속된다
---
...

After:

---
title: 자동화에 인간의 승인을 포함할지는 실패의 검지 가능성과 가역성으로 결정한다
---
...

After는 결론을 말하지 않습니다. 대신 '무엇으로 결정되는가'를 쓰고 있습니다. 이렇게 하면 전자동과 반자동 모두를 하나의 노트로부터 도출할 수 있습니다.

리네임은 alias로 안전하게

제목을 바꾸면 파일명도 바뀌고, 과거의 Wikilink가 끊깁니다. Obsidian의 자동 링크 업데이트는 GUI를 실행할 때만 작동하므로, AI나 스크립트로 직접 리네임하면 참조가 깨집니다.

대책은 구 제목을 aliases에 남겨두는 것입니다.

title: 新 카테고리는 기존의 신뢰 자산을 승격시킨 자가 제패하기
aliases:
...

이렇게 하면, 과거의 데일리 노트(Daily Note)나 로그로부터의 [[…제패하다]]

라는 링크도 그대로 해결됩니다. 실제로 이 방법으로 리네임(Rename)을 해보니, git도 rename(유사도 94%)으로 인식해 주었습니다.

규약을 어디에 둘 것인가 — 정본 분리의 3층 구조

"명제는 판단 축(Judgment Axis)으로 작성한다"라는 규칙을 정했다고 가정했을 때, 그것을 어디에 작성할 것인가. 이는 AI 운용에 있어 은근히 중요한 문제입니다. 장소를 잘못 선택하면 효과가 없거나 방해가 됩니다.

후보들을 비교해 보겠습니다.

결론적으로, 저는 3층으로 나누어 배치했습니다.

• 정본: _Meta/Vault운용/_index.md에 이유와 예시를 포함하여 규약 본체를 작성
• 상시 로드 요약: 프로젝트 CLAUDE.md에 한 줄로 요약 (Vault 작업 시 AI가 반드시 읽으므로 자동으로 적용됨)
• 행동 트리거: 메모리는 "규약을 따른다"라는 포인터(Pointer)만 갖게 하고, 규칙 본체는 중복시키지 않음

이는 "변하기 쉬운 정보일수록, 변경 비용이 낮은 곳에 정본을 단 하나만 둔다"라는 정본 분리의 사고방식입니다. 정본이 여러 곳에 흩어지면, 한쪽만 수정하여 모순이 발생하게 됩니다.

단발성으로 끝내지 않기 — 기존 노트의 점검과 시스템화

새로운 규약을 저장한 후, 기존 노트에도 해당되는 것이 없는지 점검했습니다.

결과는, 67건 중 실질적으로 수정한 것은 1건뿐이었습니다. 대부분은 이미 조건 내재형·판단 축형·관찰 명제형으로 작성되어 있었고, 과도한 일반화는 거의 없었습니다. 운용의 품질이 높다면 피해도 작다는 뜻입니다.

다만, 이것을 규약을 바꿀 때마다 수동으로 하는 것은 지속 가능하지 않습니다. 그래서 Vault 유지보수용 스킬(자작 vault-knowledge-curator)에 점검 항목으로 포함시켰습니다.

### 명제의 스코프 참칭(과도한 일반화) 검출
1. 04_Zettelkasten의 제목 + 본문 리드(Lead) 확인
2. 일반화 마커("항상", "반드시", "모두", "가장" 등)로 후보 추출
...

출력은 다음과 같은 테이블 형식으로 합니다.

여기서도 중요한 것은, "단정을 일률적으로 판단 축화하지 않는다"를 안티 패턴(Anti-pattern)으로 명시하는 것입니다. 가치관이나 관찰 명제까지 건드리면 품질이 저하됩니다. 검출 로직에도 "제목 + 본문으로 판정한다"를 심어둡니다.

요약

AI에게 읽히는 Zettelkasten의 작법을 4가지 포인트로 정리합니다.

• 명제는 "단정인가 판단 축인가"를 적용 범위에 따라 선택한다 — 단정이 나쁜 것이 아니라, 과도한 일반화가 나쁜 것이다.
• 판정은 제목뿐만 아니라 본문도 본다 — 본문이 범위를 한정하고 있다면 단정이어도 괜찮다.
• 규약은 정본 분리의 3층 구조로 둔다 — 정본(_Meta) + 상시 로드 요약(CLAUDE.md) + 포인터(메모리).
• 점검은 시스템화한다 — 규약을 도입하면 기존 노트도 점검하고, 이를 스킬의 감사 항목으로 영구화한다.

AI가 자신의 지식을 읽고 움직이는 시대, 노트는 "장차 recall 될 자산"이 됩니다. 그 전제에 서면 작성의 요구 수준이 한 단계 올라갑니다. 이것이 이번에 얻은 지견이었습니다.

Discussion