옵시디언 세컨드브레인 만들기 (6) — 운영 지침 자동화

 

 CLAUDE.md에서 빼낸 규칙 본문을 지침 문서로 옮기고, 그 규칙의 소급 적용까지 AI에게 맡긴 과정을 정리한다. 규칙을 어느 자리에 둘지, 지침을 몇 개로 나눌지, 일괄 작업을 어떤 절차로 돌릴지가 핵심이다.

 

[지난 (5)편]에서 CLAUDE.md를 줄였다. 그럼 빼낸 규칙은 어디로 갔는가?

---

각 규칙의 위치

 규칙은 내용보다는 load되는 시점으로 자리를 정한다.

(항상 필요한 것과 가끔 필요한 것을 같은 곳에 두면, 가끔 필요한 것은 자리를 차지할 뿐이다)

위치	로딩 시점	내용
CLAUDE.md (관문)	매 세션 전량	항상 적용되는 것, 금지사항, 구조 결정의 이유
지침 문서	해당 작업을 시작할 때 직접	규칙 본문, 분류 기준, 판단 근거
스킬(skill)	호출할 때만	순서가 있는 반복 절차
훅(hook)	정해진 시점에 자동	예외 없이 매번 일어나야 하는 일

 CLAUDE.md는 강제가 아니다. 지시가 반드시 실행돼야 한다면 프롬프트에 적고 지켜지기를 바라는 대신 훅으로 옮겨야 한다. 

 

지침을 나누는 기준

지침을 여러 개로 나눴다. 기준은 적용 범위가 겹치지 않는 폴더, 혹은 하위 분류이다.

아래는 필자 개인 지침의 예시이다.

지침	범위	내용 예시
문서 운영	볼트 전체	문서 유형, frontmatter 표준, 태그·링크 원칙, 도메인 허브 규칙
블로그 작성	블로그 원고에만	topic 분류, 링크, 문체
Work 폴더	200_Work	민감정보 처리, 세미나, 근태 기록

각 영역에 필요한 규칙만 담기게 하는 게 분리의 목적이다.

따라서 같은 규칙을 두 곳에 두지 않는다. 두 지침이 어긋나면 AI는 둘 중 하나를 임의로 고르기 때문.

 

적용 작업 절차

 지침을 만들었다면 이제 기존 문서에 새 규칙을 적용해보자.

필자는 규칙에 맞추어 School 전공노트에 남아 있던 낡은 필드(list/column — Ticktick에서 옮겨오며 생긴 것)를 지우고 type을 붙이는 작업이 6n개 정도 있었다. (사실 이런 일괄 작업은 claude code를 사용하는 것이 토큰도 훨씬 덜 들고 빠르다...)

1. 대상 목록을 먼저 뽑는다. 몇 개인지, 어떤 파일인지 확인한다
2. 파일마다 기록이 아니라 파일 자체를 열어 현재 상태를 확인한다
3. 이미 정리된 것은 건드리지 않는다
4. 끝난 뒤 다시 훑어 빠진 곳을 확인한다

 2번이 실제로 꽤 중요한 것 같다. 

---

중단 - 재개 규칙

작업 중간중간 MCP 연결이 몇 번 끊기면서 진행되었다. 긴 작업에서는 정상적인 일이기 때문에 규칙으로 처리했다.

• 끊기면 정확히 어디까지 했는지 남긴다
• 다시 연결되면 그 지점부터 재확인 후 이어간다
• 재개할 때 남겨둔 기록을 그대로 믿지 않는다

세 번째가 중요한데, 실제로 재확인 과정에서 '처리했다'고 적어둔 항목이 절반만 처리된 상태인 걸 발견했다...🥲

 

문서 간 참조는 위키링크로

 지침 파일 이름을 바꿨더니, 문서끼리 서로를 가리키던 링크 20여 곳이 전부 깨졌다. 위키링크가 아니라 파일 경로 문자열로 적혀 있었기 때문이다.

표기	작동
[[문서 운영 지침]]	옵시디언이 자동으로 갱신
'Obsidian/운영 지침/문서 운영 지침.md'	그대로 남아 깨진 참조가 됨

경로 문자열은 내가 쓰던 표기가 아니라 지침을 정리하는 과정에서 섞여 들어온 것이었다. 그래서 문서끼리의 참조는 위키링크만 쓴다를 규칙으로 박아뒀다.

 

폴더 위치를 상태로 쓰기

한 예시로, 필자의 Inbox에 있는 문서는 무조건 raw다.

• 별도의 raw 폴더를 만들지 않는다
• type: raw 같은 값도 만들지 않는다
• 나가는 순간 정제된 것이고, 그때 type이 붙는다

 폴더 위치가 곧 상태이기 때문이다. 상태를 표시하려고 필드를 새로 만드는 건 이미 폴더가 말해주고 있는 걸 두 번 적는 일이다.

 

 원래 하던 걸 이름만 다시 붙인 것뿐인데도 달라진 게 있었다. 문서를 억지로 분류하지 않게 됐고, inbox를 비우는 기준이 개수가 아니라 문서의 상태로 바뀌었다. 

할 일 목록은 하나로

 지침을 셋으로 나누니 각 지침마다 "해야 할 일" 목록도 따로 생겼다.

처음에는 개선하고 싶은 방향을 얘기하면, 각 지침 안에 정비 목록으로서 담겼다. 그러나 세션마다 세 문서를 다 열어보는 게 번거로워 목록을 전부 하나의 문서 내에 합치고 각 지침엔 포인터만 남겼다.

---

규칙 문서화로 달라진 것

작업 방식이 체계적으로 바뀌었다.

이전	이후
정리 방법을 매번 판단하고 하나씩 지시	규칙을 문서로 박아두고 AI가 적용·검증
결과를 일일이 확인	결과만 검수
통제 지점 없음	큰 작업은 실행 전 계획을 먼저 받음

마지막 줄만 유지하면 나머지는 꽤 믿고 맡길 만했다.

 

규칙을 문서로 만드는 일의 진짜 이점은 내가 뭘 하고 있었는지 알게 되었다는 것이다. 

다음편에서는 허브 문서들을 정리한 방식을 이야기해보겠다. → MOC의 활용