AI가 Obsidian 메모의 오래된 내용을 사실로 사용하지 못하게 하기 위해, 맨 앞에 3가지 항목을 추가한 이야기

Obsidian에 메모를 쌓아두다 보면, 예전 계획, 변경 전 사양, 이미 해결된 문제까지 검색 결과로 나타납니다. 사람이라면 날짜나 선후 관계를 통해 '이건 오래됐다'고 알아차리지만, AI에게 여러 메모를 한꺼번에 전달하면, 오래된 내용을 현재의 사실처럼 사용할 때가 있습니다.

특히 곤란한 경우는, 오래된 메모의 글은 자세하고 새로운 메모는 짧을 때입니다. AI는 상세하게 쓰인 쪽을 중요한 정보로 취급하여, 이미 변경된 방침을 답변에 섞어 넣기도 합니다.

그래서 저는 AI에게 읽히는 Obsidian 메모의 맨 앞에 다음 세 가지 항목을 두도록 했습니다.

상태: 현재 유효
확인일: 2026-10-11
출처: PUBLISH_SCHEDULE.json 및 공개 페이지

단지 이 세 항목만으로도, AI에게 '본문을 읽고 신구(新舊)를 추측하게 하는' 상태에서 '사람이 확인한 상태를 읽게 하는' 상태로 바꿀 수 있습니다.

이 글에서는 상태, 확인일, 출처를 어떻게 활용하여 오래된 메모를 지우지 않으면서도 현재 위치를 명확히 할 수 있는지 소개합니다.

파일의 업데이트 날짜가 새롭다고 해서 내용도 새로운 것은 아닙니다.

예를 들어, 과거 계획 메모에 오탈자 수정만 가하면 파일의 업데이트 날짜는 오늘이 됩니다. 하지만 그 계획 자체가 채택되지 않았을 수도 있습니다.

반대로, 몇 달 전에 결정한 규칙이 지금도 유효할 때도 있습니다.

2026-07-26에 결정
외부 공개 직전에는 Human Approval 필요
현재도 유효

이 규칙은 날짜가 오래되었다고 무효인 것이 아닙니다. 새로운 결정으로 변경되지 않았다면, 현재도 사용하는 규칙입니다.

따라서 저는 파일의 업데이트 날짜만으로는 신구(新舊)를 판단하지 않습니다. 메모 안에 '현재 유효한지', '언제 확인했는지', '무엇을 근거로 했는지'를 적습니다.

첫 번째 항목은 상태입니다. 너무 세부적으로 늘리면 혼란스러우므로, 저는 다음 네 가지를 사용합니다.

상태: 현재 유효
내용: Vol.69는 공개됨

공개 전 원고라면, 상태는 초안입니다.

상태: 초안
내용: Vol.70 기사 안

AI가 원고를 완성했다고 해서 '공개됨'으로 만들지 않습니다. Qiita에 투고하고 공개 페이지를 확인한 후에, 사람이 상태를 업데이트합니다.

상태가 적혀있지 않은 오래된 메모는 AI에게 추측하게 하지 않고 '확인 대기'로 취급합니다.

두 번째는 확인일입니다. 이것은 '파일을 편집한 날'이 아니라, '사람이 내용을 확인한 날'입니다.

확인일: 2026-10-11
확인 내용: 공개 URL, 기사 ID, 작성자, 투고일, 태그

확인일이 있으면 AI는 정보의 신선도를 비교할 수 있습니다. 다만, 확인일이 새롭다고 해서 반드시 정확한 것은 아닙니다. 무엇을 확인했는지도 함께 남깁니다.

예를 들어, 제목만 확인한 기록에서 본문이나 태그까지 확인되었다고 말할 수는 없습니다.

확인일: 2026-10-11
확인 범위: 제목만
본문: 미확인
...

이렇게 적으면 AI가 확인 범위를 넓혀 해석하기 어려워집니다.

정기적으로 바뀌는 정보에는 다음 확인 조건도 추가합니다.

다음 확인: 새로운 기사를 공개했을 때

매일 모든 메모를 검토할 필요는 없습니다. 내용이 변하는 사건을 재확인의 계기로 삼습니다.

세 번째는 출처입니다. '어디에 쓰여 있는지'뿐만 아니라, '무엇을 확인하기 위한 출처인지'도 남깁니다.

출처: docs/qiita/PUBLISH_SCHEDULE.json
확인 가능 내용: 기사 예정일, 상태, 기사 ID, 공개 URL
출처: Qiita의 공개 페이지
...

출처가 없으면 AI가 작성한 요약을 다른 AI가 사실로 재활용하여, 어느새 근거를 알 수 없게 만들 때가 있습니다.

1차 정보를 확인할 수 있는 경우에는 그 파일명, URL, 기사 ID 등을 남깁니다. 다만, URL에 인증 정보나 비밀 파라미터가 포함되는 경우는 메모에 붙이지 않습니다. 고객 정보나 개인 정보도 AI에게 전달하는 공유 범위에서 제외합니다.

출처에 접근할 수 없는 AI를 사용할 경우에는 '출처 있음'과 '그 AI가 확인 완료'를 혼동하지 않도록 합니다.

출처: 공개 페이지 URL 있음
AI에 의한 확인: 미실시
사람에 의한 확인: 2026-10-11에 실시

상태, 확인일, 출처는 본문 끝이 아니라 맨 앞에 배치합니다.

---
상태: 현재 유효
확인일: 2026-10-11
...

Obsidian의 속성(Property)으로 작성해도 좋고, 일반 본문으로 작성해도 무방합니다. 중요한 것은 AI가 본문을 요약하기 전에 상태를 읽을 수 있는 위치에 두는 것입니다.

Markdown 형식이기 때문에, 로컬 파일을 참조할 수 있는 ChatGPT, Claude, Cursor 등 다양한 AI에게 동일한 메모를 지정하기 쉽습니다. 특정 AI만 기억하는 상태를 줄이고, 원본에 기록된 현재 지점부터 시작할 수 있습니다.

다만, Obsidian 파일이 AI가 자동으로 읽을 수 있는 것은 아닙니다. 사용하는 AI는 로컬 파일 접근 기능과 적절한 권한이 필요합니다. Vault 전체가 아니라 작업에 필요한 폴더나 파일만 지정해야 합니다.

오래된 정보를 발견했다고 해서 바로 삭제하지 않습니다. 당시의 판단 이유가 나중에 유용할 수 있기 때문입니다.

예를 들어, 이전 방침을 다음과 같이 업데이트합니다.

상태: 이력(履歴)
당시 확인일: 2026-09-01
현재 정보: DECISIONS/2026-10-10-article-source.md 참조
...

오래된 메모에서 현재 메모로의 참조를 추가하면, AI든 인간이든 다음에 읽어야 할 장소를 알 수 있습니다.

반면, 같은 파일의 본문만 새로운 내용으로 덮어쓰면, 왜 판단이 바뀌었는지 알 수 없게 됩니다. 삭제나 대량의 수정은 사람이 차이점(diff)을 확인한 후에 진행합니다.

모든 메모에 수동으로 3가지 항목을 추가하는 것은 힘듭니다. 그래서 AI에게 대상 폴더를 한정하여, 정보가 부족한 메모를 찾아달라고 요청합니다.

지정한 Obsidian 폴더 내의 Markdown 파일을 확인해 주세요.
각 파일별로 다음 내용을 목록화해 주세요.
- 파일명
...

AI의 역할은 오래된 메모를 멋대로 정리하는 것이 아닙니다. 인간이 봐야 할 후보군을 줄이는 것입니다.

목록을 확인한 후, 인간이 '현재 유효', '이력', '확인 대기' 등을 결정합니다. AI에게는 승인된 결과만 메모에 반영하도록 합니다.

일일 메모(Daily Note)는 그날의 기록입니다. 과거 일일 메모까지 현재 상태로 덮어쓰면, 당시 무슨 일이 있었는지 알 수 없게 됩니다.

따라서, 일일 메모는 이력으로 남기고, 현재 지점을 정리하는 파일을 별도로 만듭니다.

daily/2026-10-10.md 당일 기록
CURRENT_CONTEXT.md 현재 유효한 정보
DECISIONS/... 판단 및 변경 이유
...

AI에게는 처음에 CURRENT_CONTEXT.md를 읽게 하고, 필요할 때만 일일 메모나 의사결정 기록으로 돌아가도록 합니다.

모든 것을 최신 상태로 덮어쓰기보다는, 현재 지점과 이력의 역할을 분리하는 것이 AI에게 전달할 정보를 줄일 수 있습니다.

Obsidian 메모는 많아질수록 편리해지지만, 오래된 내용과 현재 내용이 뒤섞이면, AI가 과거 계획을 현재 사실처럼 사용할 때가 있습니다.

그래서 저는 AI에게 읽게 하는 메모의 맨 앞에 다음 3가지 항목을 배치합니다.

• 상태: 현재 유효(現在有效), 이력(履歴), 확인 대기(確認待ち), 초안(下書き)
• 확인일: 인간이 무엇을 확인했는지 날짜
• 출처: 어떤 파일이나 공개 페이지를 근거로 했는지

게다가, 오래된 메모는 지우지 않고 이력으로 남기고, 현재 정보에 대한 참조를 추가합니다. AI에게 상태를 결정하게 하지 말고, 부족한 항목과 확인 필요 후보군을 정리하도록 합니다.

AI에게 대량의 메모를 읽게 하기 전에, 인간이 확인한 현재 지점을 간결하게 보여주는 것만으로도, AI가 달라도 동일한 원본에서 작업을 시작하기 쉬워집니다.

이 글은 Obsidian을 여러 AI로 참조할 수 있는 Markdown 원본으로서 사용하며, 현재 지점(現在地), 이력(履歴), 출처(出典), Human Approval를 분리해 온 본 프로젝트의 운영을 바탕으로 구성되었습니다.