AI Agent로 Obsidian 개인 비서를 오래 쓰는 법 - 지침과 장기 메모리 운영 실전편

Obsidian 구조를 잘 만들어도 오래 가는 건 별개다. 시간이 지나면 AGENTS.md는 두꺼워지고, 장기 메모리와 임시 판단이 섞이고, 새 규칙이 생길 때마다 어디를 고쳐야 할지 헷갈리기 시작한다. 1편과 2편이 왜 이 시스템을 다시 시도하게 됐는지와 구조를 어떻게 나눴는지를 다뤘다면, 이번 글은 새 정보가 생겼을 때 실제로 무엇을 읽고 어디를 고치는지를 다룬다.

들어가기에 앞서: 구조 다음에는 운영이 남는다

2편에서 구조를 나눴다면, 3편에서는 그 구조를 어떻게 덜 망가지게 유지하는지 본다. 폴더, 허브, AGENTS.md, 플레이북, 스킬을 한 번 만들어 둔다고 끝나지 않는다. 실제 운영에서는 새로운 사실이 일간 노트에 들어오고, 사용자 선호가 더 분명해지고, 작업 절차가 길어지면서 문서 역할이 계속 흔들린다.

이 글에서는 실제 vault의 AGENTS.md, 에이전트 문서 운영, 개인 정보 업데이트 플레이북, 장기 메모 업데이트 검증 체크리스트(13_my 업데이트 검증 체크리스트), daily-note-followup 스킬을 바탕으로, 공개 가능한 범위만 일반화해 excerpt로 보여준다. 핵심은 처음부터 완벽한 문서를 쓰는 것이 아니라, 사용할수록 더 얇고 정확한 문서 체계로 수선하는 것이다.

운영 원칙

문서 유지보수는 “무엇을 안다”보다 “이 정보가 어떤 종류인가”를 먼저 가르는 일에 가깝다. 그래서 새 입력이 오면 기록보다 분류를 먼저 한다.

기본 분기 표

상황	먼저 묻는 질문	기본 수정 대상
오늘 있었던 사건이나 일정	이 정보가 날짜를 벗겨도 남을 가치가 있는가	일간 기록
반복해서 드러난 선호나 판단 기준	단발 사건이 아니라 장기 패턴인가	대표 장기 메모 노트
여러 번 반복될 작업 절차	누가 다시 같은 작업을 수행할 가능성이 높은가	00_agent_docs/플레이북
모든 작업에 공통으로 적용되는 규칙	이 규칙이 vault 전역 불변식인가	AGENTS.md
환경이나 도구의 안정적인 사실	절차가 아니라 기준점인가	00_agent_docs/장기 메모리

세 가지 운영 기준

일회성인가 장기적인가

같은 정보라도 날짜성 사건이면 일단 일간 기록에 남기고, 날짜를 벗겨도 다시 참고할 가치가 있을 때만 장기 메모로 올린다. 장기 기억은 많이 쌓는 것보다, 나중에도 다시 쓸 수 있는 정보만 남기는 쪽이 더 중요하다.

전역 규칙인가 작업 절차인가

모든 일을 AGENTS.md에 적기 시작하면 금방 라우터가 아니라 매뉴얼이 된다. 전역 불변 규칙은 AGENTS.md, 단계별 수행 절차는 플레이북, 실제 실행 순서는 스킬로 내려보내는 분리가 핵심이다.

새 문서가 필요한가 기존 문서를 갱신하면 되는가

운영 문서는 새 파일을 만드는 비용도 크다. 같은 축의 정보가 이미 있으면 먼저 기존 문서에 흡수하고, 문서가 길어져 역할이 갈릴 때만 분리한다. 이 기준이 없으면 같은 규칙이 여러 파일에 중복되기 쉽다.

실전 장면 1: 새 정보가 생겼을 때

새 입력이 들어오면 바로 장기 메모를 고치는 게 아니라, 먼저 그것이 사건인지 패턴인지 해석 수정 신호인지 분리해야 한다. 이 단계가 빠지면 장기 메모가 일기 복사본처럼 변한다.

대표 excerpt

개인 정보 업데이트 플레이북의 기본 흐름

실제 플레이북을 단순화하면 아래 순서에 가깝다.

1. 입력의 핵심 사실을 먼저 뽑는다.
2. 이 입력이 일간 노트에 남길 사건인지부터 판단한다.
3. 관련 일간 기록과 기존 장기 메모 노트를 먼저 읽는다.
4. `새 사실`, `기존 패턴의 추가 증거`, `기존 해석 수정 신호`로 구분한다.
5. 장기 가치가 높을 때만 해당 대표 장기 메모 노트로 승격한다.

검증 체크리스트가 마지막에 묻는 질문

실제 체크리스트의 요지는 “썼는가”가 아니라 “비교했는가”다.

- 이번 입력은 새로운 사실인가, 기존 패턴의 추가 증거인가, 기존 해석 수정 신호인가
- 직접 비교해야 할 기존 노트는 무엇인가
- 이미 기록된 사건의 연속 설명은 아닌가
- 기존 기록과 충돌하거나 수정해야 할 내용은 없는가
- 일반화 가능한 성향이나 기준이 드러났다면 어느 상시 노트에 올려야 하는가

입력 분기 표

입력 종류	남길 위치	바로 올리면 안 되는 경우
그날의 사건, 약속, 이동	일간 기록	날짜를 벗긴 장기 의미가 아직 불명확할 때
사용자가 직접 말한 안정적인 선호	대표 장기 메모 노트	한 번만 나온 감상인데 반복성이나 명시성이 약할 때
기존 패턴을 강화하는 추가 증거	기존 장기 메모 노트 업데이트	이미 기록된 사건의 후속 설명일 뿐인지 확인 전일 때
기존 해석을 뒤집는 신호	장기 메모와 필요 시 분석 스냅샷까지 재검토	기존 노트와 비교 없이 새 사실처럼 병렬 추가할 때

바로 적용할 규칙

• 일단 일간 기록에 남기고, 장기 가치가 확인되면 장기 메모로 승격한다.
• 장기 메모를 반영하기 전에는 같은 축의 기존 노트를 먼저 읽어 중복과 충돌을 확인한다.
• 새 입력이 해석을 바꾸는 신호라면, 상시 노트만 고치지 말고 분석 스냅샷까지 같이 볼지 판단한다.

실전 장면 2: 새 규칙이 생겼을 때

새 규칙은 많아지는데 AGENTS.md는 얇게 남아 있어야 한다. 그래서 규칙이 생길 때 가장 먼저 할 일은 “무슨 규칙인가”를 분류하는 것이다.

대표 excerpt

AGENTS.md가 직접 소유하는 것

실제 AGENTS.md의 역할을 줄이면 아래 세 줄로 요약된다.

- 역할은 `전역 불변 규칙 + 작업 트리거 + 정답 문서 안내`로 한정한다.
- 새 노트가 생겼다는 이유만으로 이 문서를 갱신하지 않는다.
- 폴더 역할, 경로 패턴, 예외 규칙, 문서 라우팅이 바뀔 때만 갱신한다.

운영 문서의 분류 기준

00_agent_docs/운영/에이전트 문서 운영.md는 새 규칙을 어디로 보낼지 이렇게 자른다.

- 전역 불변 규칙, 공통 경로 패턴, 예외 규칙이면 `AGENTS.md`
- 사용자 선호나 금지사항이면 `사용자 요구사항/`
- 단계별 수행 절차면 `플레이북/`
- 안정적인 환경 정보면 `장기 메모리/`

규칙 배치 표

새 규칙 예시	들어갈 위치	이유
“새 노트를 만들기 전 기존 노트를 먼저 검색한다”	AGENTS.md	vault 전역에 적용되는 불변 규칙이기 때문
“Day Planner용 ## 일정에는 링크를 넣지 않는다”	일일기록 일정 작성 플레이북	특정 작업의 문법과 플러그인 제약이기 때문
“사용자는 특정 형식의 응답을 선호한다”	사용자 요구사항	전역 구조 규칙이 아니라 사용자 선호이기 때문
“메인 TODO 보드는 Base Board로 렌더링한다”	장기 메모리	자주 참조하지만 절차가 아닌 안정적 환경 사실이기 때문

바로 적용할 규칙

• AGENTS.md는 라우터처럼 쓰고, 설명서처럼 키우지 않는다.
• 같은 규칙이 반복 실행 절차라면 플레이북으로 내리고, 실제 순서는 스킬이 읽게 만든다.
• 새 규칙이 생겼을 때는 “어디를 고칠까”보다 “이 규칙의 수명이 얼마나 긴가”를 먼저 본다.

실전 장면 3: 스킬이 문서를 읽고 움직일 때

실제 운영에서는 스킬이 문서를 대신 읽고 움직이기 때문에, 문서 수정은 곧 실행 규칙 수정이 된다. 이 점을 이해하면 왜 AGENTS.md를 얇게 유지해야 하는지도 같이 설명된다.

대표 excerpt

daily-note-followup 스킬은 vault를 수정하기 전에 참조할 문서를 직접 지정해 둔다. 실제 스킬 파일의 핵심만 추리면 이런 구조다.

Before mutating the vault, use these canonical references:

- `00_agent_docs/플레이북/Base Board 작업 지침.md`
- `00_agent_docs/플레이북/일일기록 일정 작성 플레이북.md`
- `00_agent_docs/플레이북/개인 정보 업데이트 플레이북.md`
- `00_agent_docs/플레이북/13_my 업데이트 검증 체크리스트.md`

이 한 덩어리만 봐도 역할 분리가 분명하다. AGENTS.md는 작업 트리거와 섹션 경계만 알려주고, 실제 문법과 검증 질문은 플레이북과 체크리스트가 맡는다. 스킬은 그 문서를 읽는 실행기다.

문서 계층과 실행 계층

계층	맡는 역할	바꾸면 같이 영향을 받는 것
AGENTS.md	전역 경계, 라우팅, 예외 규칙	어떤 문서를 먼저 읽어야 하는지
플레이북	작업별 절차와 문법	특정 작업의 판단 기준과 출력 형식
체크리스트	누락 방지용 검증 질문	비교, 승격, 보류 판단의 정확도
스킬	실제 실행 순서와 응답 계약	어떤 문서를 언제 읽고 어떤 작업을 자동 반영하는지

바로 적용할 규칙

• 작업 절차를 바꾸고 싶다면 스킬만 고치지 말고, 스킬이 읽는 기준 문서부터 점검한다.
• 실행 결과가 흔들릴 때는 스킬 프롬프트보다 플레이북과 체크리스트의 authoritative copy가 어디인지 먼저 본다.
• AGENTS.md까지 세부 절차를 밀어 올리지 않아야, 같은 규칙을 한 군데만 고쳐도 실행 계층 전체가 같이 정렬된다.

실전 장면 4: 문서가 비대해질 때

문서가 망가지는 신호는 보통 길이보다 역할 혼합에서 먼저 보인다. 조사 노트가 운영 문서에 섞이거나, 최신성이 높은 사실이 장기 메모리에 들어오기 시작하면 구조는 서서히 무너진다.

대표 excerpt

운영 문서가 막는 비대화

실제 운영 문서는 00_agent_docs에 이런 것을 두지 말라고 못 박는다.

- 주제별 조사 노트, 원시 데이터, 서비스별 산출물을 두지 않는다.
- 새 문서를 추가할 때는 먼저 기존 문서와 중복 여부를 확인한다.
- 내용이 폐기되었거나 더 이상 유효하지 않으면 삭제하거나 관련 문서에 통합한다.

장기 메모리에 남길 것과 빼야 할 것

장기 메모리 문서는 범위를 더 좁게 잡는다.

여기에 기록할 것

- 현재 vault의 핵심 구조와 운영 방식
- 자주 참조하는 메인 보드, 허브 노트, 기준 폴더
- 설치된 핵심 플러그인과 그 역할

기록하지 않을 것

- 최신성이 매우 높은 사실
- 특정 조사 작업의 결과
- 금방 폐기될 임시 판단

비대화 신호 표

비대화 신호	의미	필요한 조치
00_agent_docs 안에 조사 노트와 원시 데이터가 쌓인다	운영 문서와 작업 산출물의 경계가 흐려졌다	해당 주제 폴더로 이동하고 운영 문서에는 라우팅만 남긴다
같은 규칙이 AGENTS.md, 플레이북, 스킬에 반복된다	authoritative copy가 불분명하다	한 문서를 기준 문서로 정하고 나머지는 참조 관계로 정리한다
장기 메모리에 최신성이 높은 사실이 들어간다	장기 메모리가 캐시가 아니라 로그처럼 쓰이고 있다	일간 노트나 해당 작업 노트로 내려보낸다
새 노트가 생길 때마다 AGENTS.md를 고치고 싶어진다	전역 규칙과 폴더 인덱스를 혼동하고 있다	허브나 운영 문서로 보내고 AGENTS.md는 구조 변경 때만 갱신한다
완료된 마이그레이션 기록, 차수, 수량이 운영 문서에 남는다	유지 정책과 작업 로그가 섞였다	관련 TODO나 작업 노트로 옮긴다

바로 적용할 규칙

• 문서가 길어졌다는 사실보다, 한 문서가 두 역할 이상을 동시에 맡기 시작했는지를 먼저 본다.
• 지우는 것도 유지보수다. 더 이상 유효하지 않은 운영 정보는 남겨두지 말고 삭제하거나 통합한다.
• 장기 메모리는 “오래 남아야 하는 것”만 넣고, “최근에 알게 된 것”은 자동 승격하지 않는다.

마무리

Obsidian 개인 비서를 오래 쓰는 일은 좋은 구조를 한 번 만드는 것으로 끝나지 않는다. 새 정보가 들어올 때마다 사건과 장기 맥락을 구분하고, 새 규칙이 생길 때마다 전역 규칙과 작업 절차를 분리하고, 스킬이 읽는 기준 문서를 계속 authoritative copy로 유지해야 한다.

그래서 3편의 핵심은 거창한 유지보수 철학이 아니다. AGENTS.md는 얇게, 플레이북은 구체적으로, 장기 메모리는 좁게, 스킬은 그 문서를 읽는 실행기로 두는 것이다. 다음 편에서는 왜 VS Code 대신 Obsidian을 작업 공간으로 쓰는지, 그리고 실제로 남겨둔 핵심 플러그인들이 이 흐름을 어떻게 받쳐주는지 이어서 정리해보겠다.