Context Vault Workflow Skill 사용법

대표님의 문제의식

우선순위가 높은 문제는 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

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

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

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

설치

초기 설치는 스킬로 돕고, 계정/권한처럼 사람이 확인해야 하는 단계는 체크리스트로 분리한다.

Claude Code / Codex

개인 PC 전체

Claude Code를 쓰는 개인 환경 전체에서 항상 호출할 수 있다.

Windows PowerShell

$src = "D:\work\srl-ai-creative-unit\10_Projects\2026.07 Claude 맥락공유 시스템\60_Skills\context-vault-workflow"
$dst = "$env:USERPROFILE\.claude\skills\context-vault-workflow"
New-Item -ItemType Directory -Force -Path (Split-Path $dst) | Out-Null
Copy-Item -Recurse -Force -LiteralPath $src -Destination $dst

볼트 프로젝트 전용

사업기획유닛 볼트 안에서만 스킬이 동작하게 할 때 사용한다.

Windows PowerShell

$vault = "D:\Dropbox\BusinessPlanning_Unit_Vault"
$src = "D:\work\srl-ai-creative-unit\10_Projects\2026.07 Claude 맥락공유 시스템\60_Skills\context-vault-workflow"
$dst = Join-Path $vault ".claude\skills\context-vault-workflow"
New-Item -ItemType Directory -Force -Path (Split-Path $dst) | Out-Null
Copy-Item -Recurse -Force -LiteralPath $src -Destination $dst

Mac 또는 Codex

Mac은 같은 폴더 구조로 복사하고, Codex는 `.codex/skills`에 둔다.

Mac Bash

SRC="/path/to/srl-ai-creative-unit/10_Projects/2026.07 Claude 맥락공유 시스템/60_Skills/context-vault-workflow"
DST="$HOME/.claude/skills/context-vault-workflow"
mkdir -p "$(dirname "$DST")"
rm -rf "$DST"
cp -R "$SRC" "$DST"

Codex PowerShell

$src = "D:\work\srl-ai-creative-unit\10_Projects\2026.07 Claude 맥락공유 시스템\60_Skills\context-vault-workflow"
$dst = "$env:USERPROFILE\.codex\skills\context-vault-workflow"
New-Item -ItemType Directory -Force -Path (Split-Path $dst) | Out-Null
Copy-Item -Recurse -Force -LiteralPath $src -Destination $dst

사람이 먼저 확인할 준비

팀원 PC에 Obsidian을 설치하고 최신 installer로 업데이트한다.
Obsidian Settings → General에서 Command line interface를 켜고 `obsidian version`으로 확인한다.
팀원은 회사 메일을 GitHub 계정에 연결하고 초대 메일을 받을 수 있게 한다.
리더 또는 지정된 관리자가 회사 리포를 만들고 팀원을 초대한다.

스킬이 자동 생성할 초기 뼈대

`README.md`: 처음 열었을 때 보이는 운영 안내.
`CLAUDE.md`: Claude가 항상 먼저 읽는 리더 의도와 작업 원칙.
`.claude/rules/`: 경로별 공유 정책, 명명 규칙, 맥락 점검 기준.
`.claude/settings.json`: 큰 이탈만 질문하게 하는 hook 템플릿.
`00_Inbox/`, `10_Projects/`, `20_Areas/`, `30_Resources/`, `40_Archive/`, `90_System/` 기본 폴더.
`02_tasks/{member}/01_team_shared/`, `02_local_private_do_not_sync/`, `03_redacted_to_share/` 개인별 공유 경계.

실행 구조

모든 일을 매번 스킬로 호출하지 않는다. 초기 설치와 구조 변경은 스킬, 일상 운영은 `CLAUDE.md`, rules, hooks가 뒤에서 받는다.

Bootstrap + auto gates

초기 설치만 스킬로 시작

새 볼트, 새 팀원, 새 리포, 구조 마이그레이션처럼 한 번 제대로 세팅해야 하는 일은 명시 호출한다.

Claude Code

/context-vault-workflow 사업기획유닛 맥락공유 볼트 초기 설치를 진행해줘. 팀원은 리더 안혜린, 이지현, 한정윤, 김하경이야. Obsidian CLI, GitHub 리포/초대, README, CLAUDE.md, rules, hooks, 폴더 구조, 개인 공유/비공유 폴더까지 체크리스트와 파일로 세팅해줘.

일상 작업은 `CLAUDE.md`가 받는다

팀원이 회의록, 리서치, 마크다운 슬라이드, 보고 산출물 작업을 시작하면 Claude는 먼저 루트와 프로젝트 폴더의 `CLAUDE.md`를 읽는다.

현재 대표 요구사항과 리더 의도를 확인한다.
팀원이 해석을 적었는지 확인한다.
공유 가능 정보와 비공유 정보를 분리한다.
작업 결과를 해당 프로젝트 또는 리소스 폴더 안에 남긴다.

rules와 hooks는 조용히 백업한다

반복 확인은 팝업으로 묻지 않고 기록으로 남긴다. hooks는 큰 이탈 신호가 있을 때만 멈추고 질문한다.

낮은 위험: `00_project_card.md`와 dashboard에 조용히 표시.
중간 위험: 작업 말미에 수정 제안으로 제시.
높은 위험: Claude 인터랙티브 질문으로 진행 전 확인.

큰 이탈 때만 질문한다

질문 게이트는 사용자를 자주 방해하지 않는 것이 원칙이다. 아래 상황에서만 진행을 멈춘다.

대표 요구사항과 리더 지시가 충돌한다.
팀원 오버라이드가 산출물 방향을 크게 바꾼다.
비공유 정보가 공유 산출물의 핵심 근거가 된다.
오래된 지시로 최종 산출물을 만들 가능성이 높다.

운영 원칙

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

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에 기록하고, 큰 방향 이탈만 질문해줘.

공식 근거와 원본

설치 경로와 스킬 구조는 Claude Code 및 Agent Skills 공식 문서 구조를 따른다.

References

Claude Code Skills Agent Skills Overview Obsidian CLI GitHub Organization Invitations

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

Markdown 가이드	`10_Projects/2026.07 Claude 맥락공유 시스템/20260708_Claude_맥락공유_Skill_설치_사용법.md`
Skill 원본	`10_Projects/2026.07 Claude 맥락공유 시스템/60_Skills/context-vault-workflow/SKILL.md`