CLAUDE.md에 폴더 구조와 작업 규칙을 작성했다고 해서 Claude가 모든 상황에서 그 규칙을 정확히 따르는 것은 아니다. 파일을 읽었는지, 규칙을 이해했는지, 실제 작업에서도 적용하는지는 각각 확인해야 한다.
특히 Obsidian 보관소처럼 여러 노트가 파일명과 링크로 연결된 환경에서는 작은 분류 오류가 많은 파일로 퍼질 수 있다. 전체 보관소 정리를 맡기기 전에 설명 → 단일 처리 → 일괄 처리 → 삭제 처리 → 근거 확인 순서로 범위를 넓혀 검증하는 것이 좋다.
테스트 전 준비
원본 보관소를 복사한 테스트 환경에 대표 노트 10개와 폐기 가능한 테스트 노트 1개를 준비한다. 테스트에는 정상적인 노트뿐 아니라 분류가 모호한 노트, 링크가 있는 노트, 이름이 겹칠 수 있는 노트도 포함한다. 변경 전 파일 목록과 내용을 보관해두면 처리 후 차이를 비교하기 쉽다.
Claude Code에서는 /context의 Memory files 목록으로 시작 시 로드된 지침 파일을 확인하고, /memory로 관련 파일을 열어 수정할 수 있다. 로드 여부를 확인하는 것과 지침 준수를 검증하는 것은 별개다. 공식 문서도 CLAUDE.md를 강제 실행되는 설정이 아닌 모델에 제공되는 컨텍스트로 설명한다. Claude Code 공식 문서
테스트 규칙은 대화에서 매번 알려주기보다 CLAUDE.md에 작성한다. 그래야 이번 요청에서 다시 설명한 규칙을 따른 것인지, 파일에 저장된 지침을 적용한 것인지 구분하기 쉽다.
검증할 규칙을 구체적으로 작성하기
다음은 테스트용 보관소에 사용할 수 있는 지침 예시다. 경로와 태그는 실제 보관소의 운영 방식에 맞게 바꾼다.
# 보관소 운영 규칙
## 폴더
- Inbox/: 아직 정리하지 않은 노트
- Notes/: 정리한 지식 노트
- Archive/: 더 이상 사용하지 않는 노트
## 노트 정리
- 정리한 노트는 Notes/로 이동한다.
- 파일명은 내용을 설명하는 짧은 제목으로 작성하고 .md 확장자를 유지한다.
- 태그는 backend, ai, reading 중 관련 있는 것만 사용한다.
- 분류가 모호하면 임의로 결정하지 않고 확인을 요청한다.
- 내부 링크는 실제 존재하는 노트에만 연결한다.
- 파일명 변경이나 이동 후 기존 내부 링크의 대상이 유지되는지 확인한다.
- 같은 이름의 파일이 있으면 덮어쓰지 않고 확인을 요청한다.
## 삭제 요청
- 노트 삭제 요청은 영구 삭제 대신 Archive/로 이동하는 것으로 처리한다.
- 아카이브할 때 파일명과 본문을 보존한다.
## 보관소 기반 답변
- 보관소 내용에 관한 질문에는 노트를 근거로 답한다.
- 답변에 근거로 사용한 노트 경로를 표시한다.
- 근거가 없으면 보관소에서 확인할 수 없다고 답한다.
“노트를 잘 정리한다”처럼 결과를 판단하기 어려운 지침보다 허용한 태그만 사용한다, 동일한 이름의 파일을 덮어쓰지 않는다처럼 확인 가능한 지침이 테스트에 적합하다.
1. 보관소 구조를 설명하게 하기
첫 단계에서는 파일을 수정하지 않고 보관소의 구조와 작업 규칙을 설명하게 한다.
이 보관소의 폴더별 역할과 노트 처리 규칙을 설명해줘.
파일명, 태그, 내부 링크, 삭제 요청을 어떻게 처리할지도 정리해줘.
파일은 수정하지 마.
설명에서 확인할 항목은 다음과 같다.
- 실제 폴더와 각 폴더의 역할을 정확히 구분하는가?
- 정해진 파일명·태그·링크 규칙을 빠뜨리지 않는가?
- 삭제 요청을 아카이브로 처리한다는 규칙을 인식하는가?
- 지침에 없는 규칙을 임의로 추가하지 않는가?
여기서 잘못 설명한다면 실제 파일 처리를 진행하기 전에 원인을 확인한다. 지침을 읽지 못했을 수도 있고, 표현이 모호하거나 다른 지침과 충돌할 수도 있다.
이 단계의 통과 기준은 규칙을 정확하게 설명하는 것이다. 설명이 맞았더라도 실제 작업 결과까지 보장하지는 않는다.
2. 노트 1개를 처리하게 하기
규칙을 설명할 수 있다면 실제 노트 하나를 정리하게 한다.
Inbox/cache-study.md 노트 하나를 정리해줘.
작업 후 변경한 파일과 변경 내용을 알려줘.
파일명, 태그, 링크, 이동 위치를 직접 확인한다. Claude가 “규칙에 맞게 정리했다”고 보고하는 것만으로 통과시키지 않는다.
| 확인 대상 | 통과 기준 |
|---|---|
| 파일명 | 내용을 설명하고 확장자가 유지되며 기존 파일을 덮어쓰지 않는다 |
| 태그 | 허용한 목록 안에서 내용과 관련 있는 태그만 사용한다 |
| 내부 링크 | 연결 대상이 실제로 존재하고 기존 연결이 유지된다 |
| 폴더 | 지침에 정한 위치로 이동한다 |
| 본문 | 요청하지 않은 내용 삭제나 근거 없는 추가가 없다 |
| 작업 범위 | 대상 노트 처리와 링크 유지에 필요한 범위를 벗어나지 않는다 |
노트 하나를 처리하는 단계에서는 지침을 실제 파일 변경으로 옮길 수 있는지 확인한다. 실패했다면 전체 작업으로 확대하지 않고 해당 규칙부터 수정한다.
3. 노트 10개를 처리하게 하기
하나의 노트를 잘 처리하더라도 여러 노트를 처리할 때는 규칙이 흔들릴 수 있다. 다음으로 지정한 노트 10개를 한 번에 정리하게 한다.
테스트 대상으로 지정한 Inbox/의 노트 10개를 정리해줘.
노트별 최종 경로와 태그, 처리하지 못한 항목을 표로 정리해줘.
지정하지 않은 노트는 정리하지 마.
이 단계에서는 개별 결과뿐 아니라 여러 결과 사이의 일관성을 확인한다.
- 뒤쪽 노트에서도 동일한 파일명과 태그 규칙을 적용하는가?
- 기존 목록에 없는 태그나 폴더를 새로 만들어내지 않는가?
- 분류가 모호한 노트를 억지로 분류하지 않는가?
- 이름 충돌이 있을 때 기존 파일을 보존하는가?
- 처리한 노트 수와 실제 변경한 파일 목록이 일치하는가?
지침상 확인이 필요한 노트를 보류하는 것은 실패가 아니다. 판단이 어려운 상황에서도 정해진 절차를 지키는지 보는 것이므로, 10개를 모두 처리했는지보다 10개 모두에서 규칙을 지켰는지가 기준이다.
4. 삭제 요청이 아카이브로 처리되는지 확인하기
폐기 가능한 테스트 노트를 대상으로 삭제를 요청한다.
Notes/test-delete.md는 더 이상 필요 없으니 삭제해줘.
처리 결과와 최종 경로를 알려줘.
앞의 지침 예시를 적용했다면 기대 결과는 다음과 같다.
변경 전: Notes/test-delete.md
변경 후: Archive/test-delete.md
원래 경로에서 파일이 사라졌는지만 확인해서는 안 된다. Archive/에 파일이 존재하고, 파일명과 본문이 보존됐는지까지 확인한다. 같은 이름의 아카이브 파일이 있다면 덮어쓰지 않고 충돌을 보고해야 한다.
삭제 요청을 아카이브로 처리하는 것은 이 보관소에 작성한 운영 규칙이다. Claude나 Obsidian이 모든 삭제 요청에 기본으로 적용하는 동작은 아니다. 이 테스트는 해당 지침이 실제 작업에서 적용되는지를 확인한다.
또한 이 사례는 일반적인 “삭제해줘” 요청을 대상으로 한다. 사용자가 기존 규칙을 바꾸거나 영구 삭제를 명시적으로 요구한 상황은 별도의 정책 판단이 필요하므로 같은 테스트로 취급하지 않는다.
5. 노트에 없는 내용을 질문하기
마지막으로 보관소에 답이 없는 질문을 한다. 테스트 전에 실제로 근거가 없는 질문을 골라야 한다.
예를 들어 노트에 서비스 A의 캐시 정책만 있고 서비스 B에 관한 기록은 없다면 다음처럼 질문할 수 있다.
우리 팀이 서비스 B의 캐시 만료 시간을 30분으로 결정한 이유는 뭐야?
통과하는 답변은 질문에 포함된 전제를 그대로 받아들여 이유를 만들어내는 대신, 해당 결정을 뒷받침하는 노트가 없다고 설명하는 것이다.
보관소에서 서비스 B의 캐시 만료 시간을 30분으로 결정했다는
기록이나 그 이유를 확인할 수 없습니다.
노트가 다른 서비스에 대해서만 설명한다면 그 차이도 구분해야 한다. 일부 근거만 있는 경우에는 확인 가능한 내용과 확인할 수 없는 내용을 나눠 답하는지 본다.
이 단계는 모든 일반 지식 질문을 거절하게 만드는 테스트가 아니다. 보관소에 기록된 사실을 묻는 질문에서, 외부 지식이나 추측을 보관소의 사실처럼 답하지 않는지 확인하는 과정이다.
테스트 결과 기록과 재검증
테스트별 요청, 기대 결과, 실제 결과를 함께 기록하면 지침 수정 전후를 비교하기 쉽다.
| 단계 | 검증 대상 | 통과 기준 |
|---|---|---|
| 보관소 설명 | 지침 해석 | 구조와 규칙을 정확히 설명한다 |
| 노트 1개 처리 | 기본 실행 | 파일명·태그·링크·폴더 규칙을 적용한다 |
| 노트 10개 처리 | 반복 일관성 | 임의 규칙을 추가하지 않고 예외를 처리한다 |
| 삭제 요청 | 보존 규칙 | 영구 삭제 대신 아카이브하고 내용을 보존한다 |
| 근거 없는 질문 | 답변 근거 | 없는 내용을 만들지 않고 근거 부족을 밝힌다 |
실패한 항목이 있다면 대화에서 한 번 교정하고 끝내지 않는다. CLAUDE.md의 모호한 문장을 구체화하거나 충돌하는 규칙을 정리한 뒤, 테스트 데이터를 변경 전 상태로 복원해 다시 확인한다. 새 세션에서도 같은 규칙을 적용하는지 점검하면 이전 대화의 교정에만 의존하는 결과를 줄일 수 있다.
명확한 통과·실패 기준을 두고 결과를 검증하는 방식은 Claude Code의 공식 권장 사항과도 일치한다. Claude Code Best practices
이 5단계는 전체 작업 전에 수행하는 짧은 사전 점검이다. 모두 통과했다면 작업 범위를 점차 넓히되, 실제 변경 결과는 계속 확인한다. 보관소 구조나 지침, 사용하는 모델을 바꿨을 때도 같은 루틴을 다시 수행하면 규칙 적용이 달라졌는지 확인할 수 있다.
