Claude Code 자동 메모리와 Obsidian: 검증 가능한 맥락 보관하기

개인의 작업 선호를 보관하려면 Claude Code의 auto memory부터 시작하기 편합니다. 팀이 논의하고 도구 간에 옮겨야 하는 결정에는 책임자와 출처를 적은 별도의 Markdown 기록이 더 유용합니다. Obsidian은 이런 저장소의 편집기로 사용할 수 있습니다. 다만 설치만으로 기록이 에이전트에 연결되지는 않습니다.

모든 정보에 한 가지 방식을 고를 필요는 없습니다. 기록의 정확성을 누가 책임지는지에 따라 맥락을 나누세요. 예를 들어 “짧은 답변을 선호한다”는 개인 메모리에, “팀이 보고서를 새 서비스로 옮기고 있다”는 결정 링크가 있는 공유 기록에 둘 수 있습니다. 현재 코드에서 확인할 수 있는 경로나 명령은 저장소를 직접 확인하면 불필요한 사실 복사본을 관리하지 않아도 됩니다.

실제로 무엇이 저장되는가

Claude Code 문서는 auto memory를 프로젝트의 로컬 Markdown 파일로 설명합니다. /memory로 열어 수정하거나 삭제할 수 있습니다. 같은 Git 저장소의 worktrees는 메모리를 공유하지만 기기 사이에 자동으로 옮겨지지는 않습니다. /context는 로드된 memory files를 확인하는 데 도움이 됩니다. 디스크에 기록이 있다는 사실만으로 현재 대화에 내용이 들어갔다고 볼 수는 없습니다.

Obsidian vault는 기록과 설정을 담는 폴더입니다. 일반 Markdown 파일은 앱 밖에서도 사용할 수 있습니다. 에이전트가 사용하려면 읽을 파일을 별도로 지정하고 접근을 허용해야 합니다. 이 방식에 Obsidian 플러그인이나 MCP 서버는 필요하지 않습니다.

질문	Auto memory	독립적인 Markdown vault
누가 기록을 제안하는가	작업 중 Claude가 제안하고 사람이 확인	기록 작성자 또는 명시적으로 요청받은 에이전트
논란이 있는 사실은 누가 수정하는가	프로젝트 사용자	지정된 결정 책임자
변경을 동료에게 어떻게 보여주는가	선택한 기록을 명시적으로 전달	파일 또는 합의한 Git diff 전달
다른 기기로 어떻게 옮기는가	별도로 이전 준비	폴더 접근 또는 동기화 준비
오래된 정보는 어디서 찾는가	저장된 기록	출처와 다음 검토 날짜

오른쪽 열은 권장 운영 방식입니다. Obsidian으로 폴더를 연다고 Git, 책임자, 검토 기한이 자동으로 생기지 않습니다.

메모리 검증을 위한 모델 연결 준비하기

Claude Code에서 API를 통해 두 방식을 시험하려면 BetterToken의 Anthropic-compatible 연결을 사용할 수 있습니다. 먼저 BetterToken의 Claude Code 가이드에 따라 자신의 API Key와 /v1이 없는 Base URL https://bettertoken.ai를 설정하세요. 클라이언트를 재시작하고 짧은 메시지에 대한 응답을 받습니다. 이 단계는 모델 접근을 확인하며, 다음 단계에서 기록의 사용을 검증합니다.

비교할 때는 같은 모델과 같은 과제를 유지합니다. 먼저 기록을 읽게 하고, 수정한 뒤 새 대화에서 같은 질문을 반복합니다. 연결 변경이 실험의 추가 변수가 되지 않도록 하기 위해서입니다. BetterToken은 API 호출을 제공하고 auto memory와 vault는 여전히 도구 측에서 관리합니다. 에이전트가 읽은 내용은 모델 요청에 포함될 수 있으므로 기밀이 없는 학습용 기록을 사용하고 API Key를 vault에 저장하지 마세요.

BetterToken으로 Claude Code를 설정하고 기록 하나를 검증한 뒤 아래 예시로 진행하세요.

하나의 사실에 하나의 기본 위치 정하기

기밀이 없는 기록 하나로 시작합니다. 예시에서는 팀이 내보내기 형식을 논의하며 값과 이름은 가상입니다. decisions/report-export.md를 저장하세요.

# Report export decision

Status: proposed
Owner: reporting-team
Verified: 2026-09-08
Review-by: 2026-09-22
Source: team decision record to be attached

The proposed export format is CSV.
This is not an approved production requirement.
Before implementation, ask the owner for the approved decision.

이렇게 쓰면 제안과 필수 요구사항을 구분할 수 있습니다. 실제 프로젝트에서는 작업, 회의록, 결정 문서처럼 접근 가능한 출처를 기재하세요. 확인되지 않은 동안은 에이전트도 불확실성을 유지해야 합니다.

새 대화에서 구체적으로 요청합니다.

Read decisions/report-export.md.
What export format is proposed, and is it approved for production?
Cite the file and identify the missing evidence.
Do not change code or infer approval from the proposal.

기대 답변은 CSV가 제안됐고 production approval은 없으며 결정의 출처가 필요하다는 것입니다. 이는 검증 기준이며 모델의 정답을 보장하지 않습니다. 에이전트가 “CSV를 구현해야 한다”고 답하면 어떤 파일을 읽고 무엇을 인용했는지 살펴보세요. 중복 기록, 이전 대화 또는 상태의 잘못된 해석이 원인일 수 있습니다.

수정과 삭제 검증하기

학습용 기록의 형식을 JSONL로 바꾸고 상태는 proposed로 유지합니다. 새 대화를 시작해 같은 질문을 반복하세요. 에이전트는 JSONL과 기존 제한을 말해야 합니다. CSV를 반환한다면 또 다른 충돌 규칙을 추가하지 말고 오래된 값의 출처를 찾으세요.

그다음 일반 파일 관리자로 학습용 기록을 삭제하고 또 다른 새 대화에서 승인된 형식 결정이 어디에 있는지 질문합니다. 다른 출처가 없다면 정보가 부족하다는 답이 유용합니다. 예전 값으로 답한다면 다른 복사본이나 출처가 남아 있다는 뜻이므로 /memory, 프로젝트 파일, 지침을 확인해야 합니다.

기록을 삭제해도 Git history, 백업, 동기화 기기, 이미 열린 대화에서 자동으로 사라지지는 않습니다. 이 시험은 새 대화의 동작을 검증하며 데이터 완전 삭제를 검증하지 않습니다. API keys, 비밀번호, 개인정보를 연습에 포함하지 마세요.

오류의 비용에 맞게 운영하기

혼자 작업하고 메모리의 대부분이 개인 선호라면 auto memory를 유지하고 프로젝트가 크게 바뀐 후 기록을 검토하세요. 어떤 사실이 팀의 행동을 좌우한다면 기본 버전을 관리되는 문서로 옮깁니다. auto memory에는 결정 자체를 복제하는 대신 최신 출처를 찾을 위치를 남길 수 있습니다.

필요하면 /memory로 auto memory를 끌 수 있습니다. 공식 설정인 autoMemoryEnabled가 이 기능을 제어합니다. 비활성화가 기존 파일과 이미 로드된 맥락의 확인을 대신하지는 않습니다.

팀 vault에서는 중요한 기록의 책임자와 검토 계기를 정하세요. API 변경, 프로젝트 취소, 마이그레이션 완료 등이 계기가 될 수 있습니다. 날짜는 잊힌 기록을 발견하는 데 도움이 되지만 자동 만료를 만들지는 않습니다. Git을 사용한다면 commit 전에 정확한 파일을 확인하고 개인 설정과 첨부파일이 든 폴더 전체를 추가하지 마세요.

결정 하나에 대해 새 대화에서 세 질문을 하는 것으로 시작합니다. 무엇을 알고 있는지, 무엇이 바뀌었는지, 무엇이 더 이상 확인되지 않는지입니다. 답이 최신 파일을 인용하고 불확실한 상태를 유지한다면 선택한 보관 방식이 목적을 충족합니다. 그렇지 않으면 출처와 읽는 순서를 먼저 고치세요. 편집기를 바꾸는 것만으로 모순이 해결되지는 않습니다.