전체 외장뇌 운영 규칙

이 Vault는 여러 프로젝트와 학습에서 오래 재사용할 개인 지식을 관리한다. 프로젝트별 작업 현황이나 공식 저장소를 대체하지 않는다.

정본 접근

개인 Vault의 정본은 비공개 GitHub Markdown이며 정상 읽기·쓰기는 personal_vault MCP로 수행한다. Obsidian 로컬 사본은 검사 인터페이스다. 최초 이전·장애 복구의 관리자 Git 작업과 일상 저장을 구분한다. 현재 연결·백업·검증 상태는 원격 Vault 운영 전환에서 확인한다.

문서 생성·수정·삭제는 원격 Vault 묶음 저장 계약에 따라 AWS 초안에 모은다. 한 사용자 작업의 관련 변경을 전체 diff로 검토하고 대화에서 승인된 버전만 한 commit으로 확정한다. 초안 저장은 정본 반영 완료가 아니다.

작업 순서

1. 작업을 Capture, Distill, Connect, Review, Project promotion 중 하나로 분류한다.
2. 원문이나 프로젝트의 공식 원천을 확인하고 출처와 확인 시각을 남긴다.
3. 기존 노트를 재사용하며 가장 작은 범위로 수정한다.
4. 내부 링크, JSON 설정, 출처와 검증 상태를 확인한다.

대화나 작업에서 결론이 보이더라도 canonical Vault에 자동으로 기록하지 않는다. 사용자가 캡처·증류·정리·승격을 명시적으로 요청한 시점을 변경 시작 경계로 삼고, 그 뒤에만 전체 원천과 기존 Vault를 대조해 반영한다. 자세한 근거는 지식 승격은 사용자가 명시적으로 시작한다에 둔다.

폴더 역할

• 00 Inbox/: 아직 분류하지 않은 빠른 Capture
• 01 Daily/: 날짜별 생각·관찰·후속 작업
• 10 Projects/: 프로젝트의 안정적인 설명과 프로젝트 Vault 링크
• 20 Areas/: 종료 시점 없이 계속 관리할 책임·관심 영역
• 30 Knowledge/Sources/: 독립적으로 보존하기로 한 외부 자료 하나의 출처와 원문을 복사하지 않은 Vault용 요약
• 30 Knowledge/Atomic/: 근거가 연결된 재사용 가능한 주장 하나
• 30 Knowledge/Maps/: 질문이나 주제 중심의 기존 노트 연결
• 40 Reviews/: 주간 회고와 Inbox·seed 정리
• 90 Archive/: 더 이상 활성화되지 않은 노트
• 99 Templates/: 새 노트의 시작 형식

출처와 검증

• 다른 Source의 맥락으로 언급된 링크는 그 자료를 독립적으로 보존하거나 근거로 재사용할 필요가 있을 때만 별도 Source Note로 만든다. 그렇지 않으면 원문 링크와 역할을 기존 Source에 남긴다.
• Source Note에는 원문 URL 또는 파일 위치, 작성자, 게시일과 확인 날짜를 남긴다.
• Source Note의 summary_by에는 요약 작성자나 사용한 에이전트·모델을 기록한다. 여러 주체가 요약을 실질적으로 수정했다면 YAML 목록으로 모두 남긴다. 내 말로 요약은 원문을 그대로 옮기지 않은 Vault용 요약이라는 뜻이며, summary_by: DanzzaN이 아니면 DanzzaN이 직접 쓴 문장이라는 뜻이 아니다.
• 에이전트가 요약을 작성할 수 있다. 사용자의 직접 발화, 후속 정정, 사용자가 채택한 에이전트 해석, 아직 채택되지 않은 해석·제안을 증류 과정에서 구분하고, 사용자의 후속 정정을 기존 해석보다 우선한다. 이 구분은 판별 과정이지 최종 목차가 아니다. 최종 Source Note는 현재 채택된 내용을 주제별로 하나의 설명에 통합하고, 출처 차이나 불확실성이 이후 해석을 바꿀 때만 짧은 경계 설명이나 별도 구획을 남긴다.
• 사실, 직접 확인한 결과, 해석과 제안을 구분한다.
• AI가 만든 요약과 Atomic Note는 verified: false로 시작한다. 인용한 원천을 직접 대조한 뒤에만 true로 바꾼다. verified는 원문과 노트의 충실도를 뜻하며, 사용자의 문구 승인이나 원문 속 외부 주장의 객관적 진실을 뜻하지 않는다.
• 개인 경험·동기·회고에서는 DanzzaN의 현재 기억이 1차 원천이다. 외부 자료는 있으면 보조할 수 있지만 필수 조건이 아니다. 기억의 불확실성을 그대로 기록하며, 이때 verified: true는 노트가 현재의 회고와 그 불확실성에 충실하다는 뜻이지 과거 사실을 객관적으로 입증했다는 뜻이 아니다.
• Atomic Note는 주장 하나만 다루고 최소 하나의 Source 또는 승격 원문을 연결한다.
• 비밀정보, 토큰, 실제 .env 값과 민감한 개인정보는 기록하지 않는다.

작성 provenance

• 오래 보존하는 노트의 첫 실질 초안을 작성한 주체를 created_by에 기록한다. 사람이 직접 작성했다면 사람 이름을, 에이전트가 작성했다면 codex, claude처럼 안정적인 주체 이름을 쓴다.
• AI가 실질적으로 작성했다면 creator_model, creator_reasoning, source_task도 기록한다. 모델명과 추론 수준은 작성 당시 UI·런타임·로그에 노출된 정확한 값만 쓰며, 확인할 수 없으면 추정하지 않고 not_exposed로 남긴다. 사람에게 해당하지 않는 AI 실행 속성은 not_applicable로 쓴다.
• 다른 주체가 주장·요약·결론을 실질적으로 다시 썼다면 최초 작성자 필드는 보존하고 material_contributors YAML 목록에 주체 | model=... | reasoning=... | task=... 형식의 서명을 추가한다. 오탈자, 링크, 형식과 frontmatter 정규화만 고친 경우에는 추가하지 않는다.
• Source Note의 author는 원자료 저자, summary_by는 Vault용 요약 작성자다. 둘 다 일반 노트의 생성 provenance를 대신하지 않는다.
• 작성 provenance는 추적과 재현을 위한 정보다. 작성자의 권위, 사용자의 승인, 원문 충실도나 객관적 진실을 뜻하지 않으며 verified와 별도로 판정한다.

개인 맥락과 AI 연속성

• 개인 경험·가치·동기·변화를 남기는 일차 목적은 글쓰기나 자기소개서용 재료 수집이 아니라, 현재와 미래의 AI가 누적된 자기진술과 불확실성을 바탕으로 DanzzaN의 판단 배경을 더 잘 이해하고 답하도록 하는 것이다. 글쓰기는 사용자가 명시적으로 요청할 때의 별도 활용이다.
• 이 Vault는 완전한 기억이나 완전한 DanzzaN 모델을 목표로 하지 않는다. 인간의 기억, Markdown의 기록과 AI의 해석이 모두 불완전할 수 있음을 전제로, 직접 진술·AI 해석·미확인·후속 정정을 구분하며 유용한 맥락 연속성을 점진적으로 높인다. 노트의 양과 구조적 엄밀성은 이를 돕는 수단이지 완전함의 증명이 아니다.
• 구체적인 시기·사례·규칙·행동·환경은 해당 맥락을 이해하는 데 필요하거나 DanzzaN이 자연스럽게 설명할 때 기록한다. 개인 맥락 노트를 완성하거나 검증한다는 이유만으로 반드시 채울 결손으로 취급하지 않는다.
• AI는 기록된 맥락을 응답에 활용하되, 기록되지 않은 세부 내용을 추정해 사용자를 아는 것처럼 꾸미지 않는다. 현재 AI의 지속적인 인간 이해와 Markdown에 근거한 맥락 연속성은 서로 다른 보장이다.
• 노트 내용은 Codex·Claude·로컬 LLM을 비롯한 후속 도구가 재사용할 수 있도록 모델에 독립적으로 작성하고, AI가 실질적으로 작성·수정한 부분의 출처만 별도로 기록한다.

프로젝트 Vault와 승격 계약

• 각 프로젝트 Vault는 Current, Snapshot, Issue·PR·CI, 브랜치·커밋, 일정, 프로젝트 회의와 결정 원문을 소유한다.
• 이 Vault의 Project Note는 안정적인 설명과 프로젝트 Vault를 여는 링크만 소유한다. 실시간 현황을 복제하지 않는다.
• 프로젝트 노트는 다음 조건을 모두 만족할 때만 이 Vault로 승격한다.
  1. 특정 Issue나 현재 구현을 몰라도 독립적으로 이해할 수 있다.
  2. 다른 프로젝트나 장기 학습에 다시 쓸 수 있다.
  3. 원천을 추적할 수 있고 사실·해석·제안을 구분했다.
• 승격할 때 원문 파일을 복사하거나 자동 동기화하지 않는다. 전역 노트(Atomic·Source)로 다시 쓰고 다음 속성을 기록한다.
  • origin_project: 원래 프로젝트 이름
  • source_note: 프로젝트 원문 경로 또는 obsidian://open?path=... 링크
  • promoted_at: 전역 지식으로 승격한 날짜
• 승격 뒤에도 프로젝트 원문은 프로젝트 맥락과 근거를 보존한다. 같은 현황값을 두 Vault에서 따로 유지하지 않는다.
• 승격 과정에서 원문보다 구체화한 내용 중 원본 프로젝트의 구현·테스트·리뷰에 필요한 행동 제약은, 승격 완료로 표시하기 전에 프로젝트 에이전트가 접근 가능한 Atomic 또는 Map에 프로젝트용 표현으로 되비춘다. 전역 노트 전체를 복제하지 않으며, 교차 Vault 링크만으로 이 실행 가시성을 충족했다고 보지 않는다.
• 두 Vault 사이에는 자동 양방향 동기화를 두지 않는다. 교차 Vault 탐색은 일반 [[위키 링크]] 대신 obsidian://open?path=... 링크를 사용한다.

작성과 연결

• 절차·운영 계약·에이전트 지침을 작성하거나 수정할 때는 에이전트 문서 작성을 읽고 행동 지침의 작성 기준을 적용한다. 개념·경험·성찰은 각 문서의 설명 목적에 맞게 구성한다.

• 제목과 실제 파일명은 목록·검색·그래프·본문 링크에서 무엇을 읽게 될지 예상할 수 있게 쓴다. Atomic은 주장과 적용 범위를 드러내고, Map·Project·Source는 주제·프로젝트·원자료 등 각 문서의 역할에 맞게 정한다. 길이를 줄이는 것 자체를 목표로 삼지 않으며, 분야별 이름·안정적인 식별자·이관 기준은 해당 작업 계약을 따른다.

• 도입과 소제목은 문서가 다루는 내용과 문단 사이의 흐름을 드러내게 쓴다. 불필요한 제목 반복이나 추상적인 안내 문장은 실제 내용에 맞게 고친다. 글의 전개와 문체는 문서 목적에 맞추며, 모든 노트에 같은 구성을 적용하지 않는다.

• 문장을 다듬을 때도 위의 출처와 검증 기준에 따라 주장·근거·인용·출처·불확실성을 보존한다. 외부 저자의 조언, 에이전트의 해석, 사용자가 채택한 판단을 구분하고 개인 기록의 원래 목적을 유지한다.

• Markdown의 의미와 구조를 작업 초안에서 단계적으로 구상한 뒤, 내용이 안정되면 폴더·frontmatter·템플릿·링크 계약을 적용한다. 스키마는 구상을 시작하는 틀이 아니라 최종 저장과 검증의 계약이다.

• Source → Atomic → Map 흐름으로 증류하고, 기존 사실을 Map에 복제하지 않는다. Map의 묶음·순서·링크 주변 설명을 함께 살펴 현재 주제에서 연결된 내용을 따라갈 수 있게 한다. 관계가 제목이나 본문에서 충분히 드러나면 이를 활용하며, 모든 링크에 관계 유형·방향·설명 필드를 요구하지 않는다.

• Source와 Atomic은 다대다 관계다. Atomic의 동일성은 원천이 아니라 주장·적용 범위·보장 수준으로 판단하며, Source가 다르다는 이유만으로 새 Atomic을 만들지 않는다.

• 새 Atomic을 만들기 전에 기존 Atomic의 제목·본문과 관련 Map을 검색한다. 같은 주장은 기존 Atomic에 근거 Source를 추가하고, 새 Source가 보강·정정·확장한 범위만 본문과 보장 경계에 반영한다.

• 주제가 비슷해도 대상·범위·보장 수준이 다르면 별도 Atomic으로 유지하고 연결한다. Source끼리 충돌하며 채택 판단이 끝나지 않았다면 하나의 주장으로 합치지 않고 이견과 미해결 상태를 보존한다.

• 독립적으로 재사용할 주장이 아닌 사례·임시 구현안·변동 상태는 Atomic으로 만들지 않고 Source·Project·Current에 둔다.

• Project와 Area는 지식의 소유자가 아니라 적용 맥락이다. 개념 설명은 Atomic Note에 두고 연결한다.

• 템플릿의 소제목은 작성의 출발점이다. 내용에 맞게 바꾸거나 생략하며, 빈 필드와 예시 문구는 최종 노트에 남기지 않는다.

개인사이트는 정리해 둔 내용을 관심 있는 사람이 찾아와 읽는 자리다. 원천 Markdown의 제목·본문을 그대로 제공하므로 의미·문장·구조·연결은 원천에서 다듬는다. 방문자 유입이나 자기 홍보를 위해 기록을 다시 구성하지 않으며, 발표 자료·광고에서 쓰는 표현을 지양한다. 글자 크기·읽기 폭·여백·시각적 강조·사이트의 중복 표시는 화면에서 조정한다. 화면을 맞추려고 내용을 과도하게 줄이거나 별도 사이트용 제목을 만들지 않는다. 이 방향과 글 전개·문체를 아직 정하지 않은 범위는 개인사이트 설계와 운영의 의사결정 - Codex 대화 > 원천 Markdown을 그대로 읽는 문서 작성에 둔다.

완료 기준

• 새 [[위키 링크]]는 실제 노트로 해석되어야 한다. 파일명이나 소제목을 바꾸면 영향을 받는 내부 링크와 앵커를 확인하고 필요한 수정을 같은 묶음에 포함한다.
• 변경한 .obsidian/*.json은 JSON 파싱에 성공해야 한다.
• 승격 노트에는 origin_project, source_note, promoted_at이 있어야 한다.
• 새로 만들거나 실질적으로 다시 쓴 노트에는 작성 provenance가 있어야 하며, 노출되지 않은 모델·추론 수준을 추정하지 않아야 한다.
• 원천을 확인하지 못한 내용은 verified: false로 남기고 보고한다.
• 이 Vault의 별도 백업이 구성되기 전에는 백업되었다고 간주하지 않는다.