Context Vault: 맥락은 보이고 Git은 숨기는 협업 가이드

PoC 검증 상태

2026-07-16에 분리된 데모 환경에서 작업 흐름과 안전 계약을 검증했다. 현재 SRL 저장소는 배포 대상이 아니다.

Validated PoC

자동 검증

49/49 automated tests를 통과했다. 정해진 입력에 정해진 안전 상태와 보존 기록이 나오는지를 확인한 결과다.

리서치 시나리오

4/4 research cases를 완료했다. 서로 다른 업무 질문에서 같은 기록 순서와 출처 표기가 유지되는지 확인했다.

브라우저 표시

4 reports × 390/1440 = 8/8 browser combinations를 확인했다. 휴대폰 폭과 넓은 화면에서 보고서가 읽히는지 검증했다.

독립 검토

scoped architect CLEAR/APPROVE와 executor QA passed 상태다.

이 결과는 결정론적 업무 흐름과 안전 계약이 재현된다는 증거다. 실제 Claude 리서치의 품질이나 운영 배포 준비 상태를 증명하는 결과는 아니다.

로컬 프로젝트 검증 보고서 보기

자동 동기화: Git이 아니라 안전 상태를 본다

Git은 파일 변경 이력을 안전하게 맞추는 내부 장치다. 팀원에게 Git 질문이나 명령을 요구하지 않는다.

Preservation first

평소에는 조용히 맞춘다

정상적인 local·remote·divergent edits는 자동으로 commit → fetch → merge → push한다. 팀원은 Git 질문이나 명령을 받지 않는다.

일시적 네트워크 문제

연결이 잠시 끊긴 경우에만 다시 시도한다. 내용이나 의도에 대한 확인을 네트워크 오류로 바꾸지 않는다.

같은 파일 충돌은 멈추고 보존한다

same-file·binary·modify-delete 충돌에서는 local/remote refs와 copies, tombstones, manifest를 모두 남기고 유형화된 blocked state를 표시한다.

조용히 한쪽을 고르지 않는다

ours 또는 theirs를 몰래 선택하지 않는다. “어느 내용이 현재 의도에 맞는가?”는 사람에게 묻는 내용·의도 질문이며, Git 동기화 질문이 아니다.

선택된 방식은 보존 우선 혼합형이다. 일반적인 변경은 자동으로 합치되, 충돌은 양쪽을 보존하고 사람이 내용과 의도를 판단할 수 있을 때까지 차단한다.

리서치 흐름: 질문부터 근거 있는 보고서까지

팀원은 자연어로 요청하거나 /context-research-workflow를 사용한다. 기술 명령을 외울 필요는 없다.

Traceable research

자연어 요청 예시

/context-research-workflow 팬 경험 개선안을 조사해줘. 현재 회의 녹취와 대표 방향, 리더 지시를 먼저 확인하고, 내 해석·차이·질문을 남긴 뒤 근거가 있는 Markdown과 HTML 보고서로 정리해줘.

1. 녹취

회의에서 나온 원문을 출발점으로 둔다.

2. CEO 방향

대표의 장기 목적과 제약을 분리해 읽는다.

3. 리더 지시

이번 업무의 우선순위와 승인 기준을 연결한다.

4. 팀원 해석

해석·차이·질문을 명시해 숨은 가정을 드러낸다.

5. 네 관점

네 가지 페르소나로 반대 근거와 빈틈을 검토한다.

6. 종합·산출

종합 후 Markdown과 HTML 보고서를 만든다.

순서는 transcript → CEO direction → leader order → member interpretation/difference/question → four personas → synthesis → Markdown/HTML이다. 근거가 없는 주장은 미확정으로 남긴다. 인용에는 파일 경로, 발췌문, SHA-256(파일이 바뀌지 않았는지 확인하는 긴 지문)을 함께 기록한다.

네 가지 활용 사례

업무 분야가 달라도 같은 구조는 “누가 무엇을 근거로 판단했는지”를 남긴다.

Use cases

시장 출시

대표 방향과 현장 가설이 어떻게 출시 우선순위로 연결되는지 보여 준다.

팬 경험

팬의 목소리, 팀의 해석, 아직 확인되지 않은 가정을 구분해 보여 준다.

협력사 운영

요청·합의·변경 이유를 추적해 담당자가 바뀌어도 운영 맥락을 이어 준다.

위험·컴플라이언스

정책상 멈춘 이유와 보존된 근거를 남겨 임의의 우회나 조용한 삭제를 막는다.

대표님의 문제의식

우선순위가 높은 문제는 PPT를 다시 뽑는 일이 아니라, 대표님의 의도와 리더의 해석이 팀원 작업 중 계속 보이지 않는 것이다.

Starting point

반복 설명 비용

대표님은 같은 방향성과 판단 기준을 여러 번 설명하게 되고, 팀원은 최신 의도와 이전 의사결정의 연결을 놓치기 쉽다.

의도 희석

대표 요구사항, 리더 지시, 팀원 판단이 한 파일 안에 섞이면 무엇이 상위 의도이고 무엇이 개인 해석인지 금방 흐려진다.

개인 Claude 대화의 단절

각자 Claude를 잘 써도 개인 채팅방에 갇히면 회사 기억이 되지 않는다. 공유 가능한 맥락과 개인 메모를 분리해서 운영해야 한다.

자료 공유가 아니라 맥락 조립

확정된 원칙, 아직 열린 질문, 리서치 근거, 반대 논리, 다음 액션이 한곳에 남아야 팀원이 같은 출발점에서 판단할 수 있다.

잘못된 방향을 늦게 발견

작업 전후에 현재 의도, 공유 정책, 실행 순서를 확인하는 게이트가 없으면 범위 이탈과 누락을 산출물 막판에야 발견한다.

PPT/PDF 재출력은 후순위 병목

재출력 자체가 1순위 문제는 아니다. 정본 맥락이 없기 때문에 좋은 판단을 매번 보고용 문서로 다시 포장하게 되는 결과에 가깝다.

따라서 이 스킬의 첫 목적은 더 예쁜 문서 작성이 아니라, 대표님의 의도와 리더의 해석이 작업 중 계속 보이게 만드는 것이다.

솔루션: 같은 맥락을 보고, 각자의 해석을 남긴다

팀장이 말한 의도를 그대로 복사하는 시스템이 아니라, 팀원이 그 의도를 어떻게 이해했는지 계속 드러내는 작업 구조다.

Solution map

Obsidian 팀이 읽고 고치는 공유 볼트

Claude 맥락을 읽고 답하는 실행 도우미

Markdown 사람과 AI가 같이 읽는 문서

Git 누가 언제 바꿨는지 남기는 정본

Web Guide 설치와 사용법을 쉽게 배포

CLAUDE.md 00_project_card.md slides_md/index.md

일상 업무 볼트의 현재 프로젝트

# Project Context 이 폴더에서 리서치, 기획안, 마크다운 슬라이드, 최종본을 같이 관리한다.

## Leader Intent 안혜린 리더의 우선순위와 승인 기준을 기록하고 수정 이력을 남긴다.

리더가 먼저 시작해도, 팀원이 먼저 시작해도 된다

초기 상태는 provisional로 두고, 리더 의도가 들어오면 같은 프로젝트 카드에 보완한다.

## Output Check 최종 산출물이 현재 맥락, 공유 가능성, 실행 순서와 이어지는지 점검한다.

대표 요구사항 리더 지시 팀원 해석 마크다운 슬라이드 점검 기록

폴더	무엇을 넣나	예시
`00_Inbox/`	정리 전 녹취, 급한 요청, 팀원이 먼저 던진 아이디어	회의 녹취록, 미분류 메모, 임시 링크
`10_Projects/`	기한, 책임자, 산출물이 있는 활성 업무	`26.07.W2.AI전략발표.slides`, `26.07.W2.시장조사.research`
`20_Areas/`	계속 운영되는 유닛 업무와 반복 루틴	리더 방향, 주간 회의, 사업기획 운영 원칙
`30_Resources/`	재사용할 리서치, 템플릿, 이미지, 레퍼런스	슬라이드 템플릿, 시장 자료, 경쟁사 사례
`40_Archive/`	종료된 프로젝트, 지난 버전, 회고	최종본, 종료 보고, 사용하지 않는 초안
`90_System/`	Claude 규칙, hooks, 템플릿, 자동화 파일	`CLAUDE.md`, `.claude/rules/`, 폴더 생성 템플릿

1. 일상 업무 볼트로 확장한다

대표 요구사항, 리더 지시뿐 아니라 리서치, 보고서, 마크다운 슬라이드, 최종본까지 같은 볼트에서 관리한다. Claude는 매번 이 정본 맥락을 먼저 읽고 답한다.

2. 프로젝트 안에서 산출한다

별도 산출물 루트를 만들지 않고, 프로젝트 폴더 안에 리서치, 초안, 슬라이드, 최종본을 둔다. 근거와 결과가 분리되지 않는다.

3. 지시와 해석을 분리한다

리더가 무엇을 지시했는지와 팀원이 그것을 어떻게 이해했는지를 따로 쓴다. 필요하면 오버라이드와 반문도 같은 흐름 안에 남긴다.

4. 큰 이탈만 질문한다

낮은 위험은 기록으로 남기고, 방향이 크게 바뀌거나 공유 정책과 충돌할 때만 Claude가 질문한다. 업무 흐름은 빠르게 유지된다.

어디서든 시작한다

리더가 프로젝트를 만들 수도 있고, 팀원이 Inbox나 프로젝트 카드로 먼저 시작할 수도 있다.

PARA에 배치한다

기한과 산출물이 있으면 Projects, 반복 운영이면 Areas, 재사용 자료면 Resources에 둔다.

의도를 보완한다

리더 방향이 나중에 들어와도 project card와 direction 파일에 덧붙여 현재 기준으로 만든다.

해석하고 만든다

팀원은 자기 해석과 실행 순서를 남긴 뒤 리서치, 기획안, 마크다운 슬라이드를 만든다.

점검 후 공유한다

최종본이 현재 의도, 근거, 공유 정책과 연결되는지 확인하고 필요한 것만 위로 보고한다.

쉽게 말하면	기술적 구현	팀원이 보는 결과
일상 업무를 같은 볼트에 모은다	`00_Inbox/`, `10_Projects/`, `20_Areas/`, `30_Resources/` PARA 구조	리서치, 프로젝트, 산출물이 어디에 있어야 하는지 바로 보인다
프로젝트 안에서 산출물을 만든다	`10_Projects/26.07.W2.업무명.type/04_outputs/`와 `09_final/`	마크다운 슬라이드, 보고서, 근거 자료가 같은 맥락에 남는다
내가 어떻게 이해했는지 보인다	`02_tasks/{member}/00_task_card.md`에 개인 해석과 실행 순서 기록	리더 지시와 팀원 해석의 차이가 숨지 않는다
다르게 판단해도 이유가 남는다	`OVR_...`, `LOVR_...` 파일로 override, 반문, 수정 지시 기록	복종 여부보다 판단 근거와 리스크를 검토할 수 있다
잘못된 방향을 빨리 잡는다	점검 기록과 `missing_interpretation`, `stale_instruction`, `scope_drift` 체크	진행 중에 반문, 수정, 재실행 결정을 남긴다

Scenario A

리더가 먼저 프로젝트를 세팅했다

리더가 10_Projects/26.07.W2.업무명.type/과 방향 파일을 만든다.
팀원은 자기 task card에 해석과 실행 순서를 적는다.
Claude는 작업 전 현재 리더 의도와 산출물 기준을 같이 보여준다.

Scenario B

팀원이 먼저 시작하고 리더가 나중에 보완했다

팀원이 00_Inbox/나 provisional project card로 임시 구조를 만든다.
리더가 나중에 우선순위, 승인 기준, 제외 범위를 보완한다.
Claude는 기존 작업 중 stale instruction과 유지할 부분을 표시한다.

Scenario C

마크다운 슬라이드를 먼저 만들어야 한다

04_outputs/slides_md/에 초안을 만들고 근거는 03_research/에 둔다.
슬라이드가 먼저 나왔더라도 project card에 목적과 기준을 되채운다.
최종본은 09_final/로 승격하면서 연결된 의도와 근거를 남긴다.

Scenario D

대표가 미팅에 참여했다

대표 발언은 팀장 지시보다 상위 요구사항으로 분리한다.
팀장은 실행상 필요한 조정과 예외를 리더 오버라이드로 남길 수 있다.
팀원은 두 층의 의도를 모두 보면서 자기 작업 기준을 정한다.

여기까지가 사람이 이해해야 할 해결 방식이다. 다음 섹션은 이 구조가 전사로 확장되어도 유닛 자율성과 거버넌스를 함께 지키는 운영 모델이다.

전사 확장과 거버넌스

이 구조는 한 팀의 문서 정리 도구로 끝나면 안 된다. 전사 표준은 작게 두고, 각 유닛은 독립 운영하며, 리스크와 의사결정만 위로 올라가야 한다.

Scale model

전사 공통 기준은 최소화한다

모든 유닛이 같은 방식으로 따라야 하는 것은 폴더 뼈대, 명명 규칙, 공유 정책, 맥락 점검 기준 정도로 제한한다. 세부 업무 방식은 유닛별로 달라도 된다.

유닛은 독립적으로 운영한다

사업기획, 디자인, 개발, 운영 유닛은 각자의 볼트와 `CLAUDE.md`를 가진다. 유닛 리더는 자기 팀의 지시, 해석, 산출물 흐름을 직접 관리한다.

필요한 것만 위로 보고한다

모든 작업을 중앙에서 보지 않는다. 전략 변경, 예산·인력, 대외 리스크, 유닛 간 충돌처럼 위계 판단이 필요한 경우만 요약 패킷으로 보고한다.

거버넌스는 통제가 아니라 기록 체계다

누가 무엇을 왜 바꿨는지, 어떤 근거로 오버라이드했는지, 어떤 결정이 상위 요구사항으로 승격됐는지를 남기는 것이 핵심이다.

전사 표준

공통 폴더, 이름 규칙, 공유 정책, 맥락 점검 기준만 정한다. 유닛별 업무 방식까지 중앙에서 정하지 않는다.

유닛 볼트

각 유닛은 독립 볼트를 운영하고, 자기 팀의 리더 의도와 팀원 해석을 자체적으로 관리한다.

프로젝트 실행

프로젝트와 리서치는 유닛 안에서 빠르게 움직인다. 산출물, 근거, 점검 기록은 같은 흐름에 둔다.

상향 보고

전략·예산·인력·대외 리스크·유닛 간 충돌이 생기면 핵심 요약과 선택지를 위로 올린다.

피드백 반영

대표 또는 전사 판단은 상위 요구사항으로 남고, 관련 유닛의 `CLAUDE.md`와 작업 지시에 다시 내려간다.

운영 층위	각 층위가 책임지는 것	보고 또는 점검 기준
전사	공통 명명 규칙, 공유 정책, 보안 기준, 점검 기준, 대표 요구사항	유닛 간 충돌, 대외 리스크, 예산·인력 결정, 전략 방향 변경
유닛	유닛별 `CLAUDE.md`, 리더 지시, 팀원별 해석, 프로젝트 우선순위	리더 오버라이드, 반복되는 scope drift, 공유 정책 위반 가능성
프로젝트/리서치	실행 순서, 근거 자료, 반문, 산출물, 점검 기록	오래된 지시로 작업했거나 최종 산출물이 근거와 분리된 경우
상향 보고 패킷	현황 요약, 충돌 지점, 선택지, 추천안, 결정 요청	원문 전체가 아니라 의사결정에 필요한 맥락만 올린다

Governance A

유닛은 독립 운영하지만 전략 충돌이 생겼다

유닛 리더가 충돌 지점을 `LOVR` 또는 보고 패킷으로 요약한다.
대표 요구사항, 리더 판단, 팀원 해석 중 어디서 충돌이 생겼는지 표시한다.
상위 결정이 내려오면 해당 유닛의 `CLAUDE.md`와 작업 지시에 반영한다.

Governance B

전사 표준이 바뀌어 유닛 업무가 수정된다

전사 표준 변경은 상위 요구사항으로 기록하고 적용 범위를 명시한다.
각 유닛은 자기 프로젝트 중 영향을 받는 항목만 확인한다.
수정된 작업은 이전 지시를 지우지 않고 변경 이력으로 남긴다.

전사 확대의 핵심은 모든 맥락을 중앙으로 모으는 것이 아니라, 각 유닛이 자기 맥락을 책임지고 필요한 순간에만 의사결정 가능한 형태로 위로 올리는 것이다.

내일의 분리 데모/파일럿

관리자가 제공하는 demo_vault-skill-pack.zip으로 별도 데모 볼트에서만 시작한다. 현재 SRL 저장소는 설치·배포 대상이 아니다.

Administrator-provided

팀원이 하는 일

관리자가 안내한 데모 볼트를 열고, 업무 질문을 자연어로 입력한다. Git 명령, 계정 설정, 충돌 해결 명령은 팀원 작업이 아니다.

관리자가 하는 일

분리된 데모 환경에 패키지를 준비하고, 참여 범위와 접근 권한을 안내한다. 패키지 안의 안내에 따라 검증된 범위만 시연한다.

데모에서 확인할 것

맥락과 해석이 기록되는지, 정상 변경이 자동으로 맞춰지는지, 충돌이 보존된 차단 상태로 보이는지를 확인한다.

아직 제공하지 않는 것

운영용 설치 프로그램, 상시 감시 프로그램(watcher), 운영 상태 화면은 아직 없다. 이 페이지는 이를 제공한다고 주장하지 않는다.

관리자/레거시 원본 자료

과거 부트스트랩 안내와 원본 스킬 자료는 관리자 검토용 레거시 소스다. 팀원용 데모 절차나 운영 설치 안내가 아니다.

안전 게이트: 지금은 켜지지 않는다

아래 조건이 모두 검증될 때까지 현재 SRL hook 활성화와 운영 롤아웃은 명시적으로 차단한다.

Blocked for production

crash_safe_finalization
중단·재시작 뒤에도 마지막 상태를 안전하게 마무리하는 처리가 필요하다.
hostile_remote_quarantine
신뢰할 수 없는 원격 변경은 가져오기 전에 격리·검사해야 한다.
managed_auth_protected_branch
관리되는 인증과 보호된 브랜치가 필요하다.
ntfs_apfs_whole_tree_collision
실제 NTFS/APFS 전체 트리에서 충돌을 시험해야 한다.
layered_secret_private_policy
비밀·개인정보를 여러 단계에서 막는 정책이 필요하다.
watcher_installer_status_ui
감시 프로그램, 설치 프로그램, 상태 화면이 필요하다.
recovery_quota_retention
복구 사본의 용량 한도와 보관 기간 검토가 필요하다.

이 게이트는 불편을 위한 절차가 아니다. 충돌이나 오류 때 데이터를 잃지 않고, 누가 무엇을 판단해야 하는지 분명히 하기 위한 운영 전제다.

운영 원칙

이 시스템의 핵심은 지시의 복종 여부가 아니라 의도의 해석과 변경 이력을 보이게 하는 것이다.

Daily flow

정리 전 자료는 먼저 `00_Inbox/`에 넣고, 기한과 산출물이 생기면 `10_Projects/`로 승격한다.
작업자는 먼저 `00_project_card.md`에서 현재 의도와 상태를 확인한다.
새 작업 전 `My Interpretation of Leader Intent`를 3줄 이내로 적는다.
대표 요구사항 또는 리더 지시와 다르게 판단하면 `OVR_YYYYMMDD_###.md`로 남긴다.
공유하기 애매한 정보는 원문 대신 프로젝트의 `12_redacted_context/`에 요약만 둔다.
개인 메모는 `02_tasks/{member}/02_local_private_do_not_sync/`에 두고 git/공유 대상에서 제외한다.

대표 요구사항	`20_Areas/Unit_Context/05_CEO_REQUIREMENTS.md`에 장기 제약과 전략 요구사항으로 기록한다.
리더 지시	프로젝트의 `01_direction/`과 `00_intent_resolution.md`에 작업 순서, 승인 기준, 수정 지시를 연결한다.
팀원 해석	프로젝트의 `02_tasks/{member-name}/`에 본인이 이해한 리더 의도와 실행 계획을 남긴다.
수정/반문	`06_questions_overrides/LOVR_...` 또는 `06_questions_overrides/OVR_...`에 이유와 리스크를 남긴다.
최종 산출물	별도 산출물 루트를 만들지 않고 해당 프로젝트의 `09_final/`에 둔다.

맥락 점검 신호

작업 흐름은 빠르게 정렬되어야 한다. 맥락 점검은 의도, 공유 정책, 실행 순서가 자연스럽게 이어지는지 확인한다.

Context check

missing_interpretation
작업은 있는데 팀원 해석이 없다.
stale_instruction
이전 리더 지시를 기준으로 작업했다.
orphan_output
산출물이 요구사항, 업무지시, 근거와 연결되지 않았다.
private_without_summary
비공개 정보가 공유 산출물에 영향을 줬지만 요약이 없다.
scope_drift
합의된 의도 밖으로 작업 범위가 이동했다.
blocked_by_policy
공유 정책 때문에 공개 또는 실행을 멈춰야 한다.

Check prompt

이번 주 프로젝트, 리서치, 슬라이드 폴더를 맥락 점검 기준으로 확인해서 missing_interpretation, stale_instruction, orphan_output, scope_drift만 우선 표시해줘. 낮은 위험은 dashboard에 기록하고, 큰 방향 이탈만 질문해줘.

공식 근거와 원본

보존 우선 동기화 설계를 검토할 때 참고한 공식 문서와 로컬 검증 원본이다.

References

SparkleShare Syncthing conflicts git-annex conflict variants Obsidian Git GitJournal Unison Claude Code Skills Obsidian CLI

무료 Cloudflare Pages 링크는 URL을 아는 사람이 열 수 있는 공개 링크다. 민감한 회의 원문, 개인 평가, 사담, 비공개 의사결정 자료는 이 HTML 안내 사이트에 올리지 않는다.

선택한 방식: 보존 우선 혼합형

SparkleShare·Obsidian Git처럼 Git 기반 이력의 장점, Syncthing·Unison의 충돌 인식, git-annex의 변형 보존 관점을 결합했다. 평소에는 자동 동기화하고, 충돌은 숨기거나 한쪽을 선택하지 않고 양쪽을 보존해 사람이 의도를 판단하게 한다.

Markdown 가이드	`10_Projects/2026.07 Claude 맥락공유 시스템/20260708_Claude_맥락공유_Skill_설치_사용법.md`
Skill 원본	`10_Projects/2026.07 Claude 맥락공유 시스템/60_Skills/context-vault-workflow/SKILL.md`
PoC 검증 보고서	../20260715_배포용볼트_PoC_검증보고.md