# 옵시디언에 축적되는 지식을 실제 삶에 적용하기 위한 SKILL 제작 및 경험 공유 - 작성자: [씩씩한 사서](https://community.clauders.ai/member/imported-member-SPj0Rg4PPt) - 공간: [노트 / 글쓰기](https://community.clauders.ai/writing) - 게시: 2026-04-05 - 연재: [Obsidian AI 지식 볼트](https://community.clauders.ai/series/obsidian-ai-knowledge-vault) 6/6편 - 태그: #옵시디언 - 주소: https://community.clauders.ai/writing/post/%EC%98%B5%EC%8B%9C%EB%94%94%EC%96%B8%EC%97%90-%EC%B6%95%EC%A0%81%EB%90%98%EB%8A%94-%EC%A7%80%EC%8B%9D%EC%9D%84-%EC%8B%A4%EC%A0%9C-%EC%82%B6%EC%97%90-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0-%EC%9C%84%ED%95%9C-skill-%EC%A0%9C%EC%9E%91-%EB%B0%8F-%EA%B2%BD%ED%97%98-%EA%B3%B5%EC%9C%A0-8473b0f9-673f-8f6a-92e5-1604d642d0e6 --- ### 왜 "묶음 처리"인가 Inbox에 쌓인 클리핑은 하나하나 처리하려 들면 에너지가 분산된다. 같은 주제의 클리핑이 5~8개 쌓였을 때가 **프로젝트로 전환할 신호**다. 이미 관심이 충분히 축적되었다는 뜻이기 때문이다. ### 실제 사례 — 하네스 클리핑 → 프로젝트 전환 2026-03-29 ~ 2026-04-04 사이에 하네스 관련 클리핑이 자연스럽게 쌓였다. ``` 📎 2026-03-30-harness-design-long-running-apps.md 📎 2026-04-01-claude-skills-deep-dive.md 📎 2026-04-01-demystifying-evals-ai-agents.md 📎 2026-04-01-effective-harnesses-long-running-agents.md 📎 2026-04-03-agentic-ai-harness-skill-module.md 📎 2026-04-04-everything-claude-code-agent-harness.md ``` 이 상태에서 "이제 실제 하네스를 설계해야 한다"는 압력이 생겼다. `/proj-init`은 단순한 질문지 생성이 아니다 — **쌓인 클리핑을 소화하여 실행으로 전환하는 게이트**다. ``` /proj-init --role po "에이전틱 AI 기반 전주기 품질 평가 하네스 및 통합 워크플로우 구축" \ 📎 2026-04-03-agentic-ai-harness-skill-module.md ``` 소스 파일을 지정하면 Inbox 클리핑 내용이 인터뷰 질문지의 초안 답변으로 자동 채워진다. 클리핑에서 이미 수집된 정보를 다시 타이핑할 필요가 없다. ### 일정 반영까지 연결 청사진이 생성되면 Phase를 실제 일정 블록에 등록해야 "실행"이 시작된다. ``` /proj-init → (답변 작성) → /proj [init파일] → 청사진 생성 (Phase 마감일 포함) → /cal-slot 4 [blueprint] --phase 1 # Phase 1에 4개 TimeSlot 배정 ``` `/cal-slot`은 오늘 이후 가용 슬롯을 스캔해서 Phase 1 TODO를 실제 날짜에 배치한다. 클리핑 → 질문지 → 청사진 → 일정 등록까지 끊김 없이 이어진다. 복수 프로젝트를 병행할 때는: ``` /cal-proj-day # 오늘 슬롯을 긴급도 기반으로 프로젝트별 분배 ``` ### Step 1. `/proj-init`으로 인터뷰 질문지 생성 ``` /proj-init --role po "에이전틱 AI E2E 품질 하네스 구축" ``` `po` 역할 템플릿은 이 역할에서 반드시 답해야 하는 항목들을 강제한다. - 핵심 비즈니스 문제 & 배경 - 이해관계자 파악 (영향력, 기대치, 파악 상태) - 성공 기준 & KPI (정량 측정 가능 여부) - 제약 조건 (마감일, 예산, 기술 제약) - 범위 & 우선순위 (In Scope / Out of Scope) - 마일스톤 & 결과물 **산출물**: `00. Inbox/01. Actions/진행중/2026-04-04-proj-init-agentic-ai-e2e-quality-harness.md` ### Step 2. `/proj`로 청사진 + 워크스페이스 생성 ``` /proj 00. Inbox/01. Actions/진행중/2026-04-04-proj-init-agentic-ai-e2e-quality-harness.md ``` 이 단계가 하는 일은 세 가지다. **첫째**, 인터뷰 답변을 분석해 Phase 구조를 설계한다. ``` Phase 1 — 정의·기준 수립 (due 2026-04-07) → 이해관계자 인터뷰 + 품질 평가 기준(Rubric) 확정 Phase 2 — MVP 하네스 구현 (due 2026-04-10) → Claude Code SKILL 기반 E2E 평가 자동화 Phase 3 — 워크플로우 통합·2건 검토 (due 2026-04-17) → Spec Designer, AX과제등록평가 품질 검토 완료 Phase 4 — 검수·릴리즈·보고 (due 2026-04-24) → 팀원 사용 가이드 + 이재훈 위원 최종 보고 ``` **둘째**, vault를 탐색해서 기존 지식을 연결한다. ``` 🔴 핵심 연계: [[📎 2026-04-04-everything-claude-code-agent-harness]] [[📎 2026-04-03-agentic-ai-harness-skill-module]] [[2026-04-01-harness-ai-agent-workflow]] [[📎 2026-04-01-demystifying-evals-ai-agents]] 🟡 참고: [[📎 2026-04-01-effective-harnesses-long-running-agents]] [[2026-04-01-agent-capability-maturity-model]] [[2026-04-02-spec-designer-task-summary-draft]] ← 검토 대상 에이전트 ``` **셋째**, 워크스페이스 폴더를 생성하고 인터뷰 파일을 이동한다. ``` 10. CMDS Process/13. Develop/agentic-ai-e2e-quality-harness/ ├── connect/ ← 수집 자료 (Inbox 클리핑 이동 대상) ├── merge/ ← 통합 분석 ├── develop/ ← 구현 산출물 └── _interviews/ ← proj-init 파일 자동 이동 (버전 관리) ``` **산출물**: - `00. Inbox/01. Actions/진행중/2026-04-04-proj-agentic-ai-e2e-quality-harness-blueprint.md` - 워크스페이스 폴더 구조 ### Step 3. `/proj-log`로 진행상황 기록 Phase를 진행하면서 중요한 발견이나 결정이 생길 때마다 호출한다. ``` /proj-log 2026-04-04-proj-agentic-ai-e2e-quality-harness-blueprint.md \ "이재훈 위원 1:1 완료. Rubric 초안 승인. 사내 LLM API는 Claude Claude-sonnet-4-6 wrapper로 제공 확인." ``` Inbox 파일을 워크스페이스로 이동할 때: ``` /proj-log [blueprint] --import "📎 2026-04-04-everything-claude-code-agent-harness.md" # → 파일 유형 자동 판단 → connect/ 로 이동 ``` Phase 완료 시: ``` /proj-log [blueprint] "Phase 1 완료 — Rubric 확정, 이해관계자 승인" --done ``` ### Step 4. `/proj-map`으로 Phase 전환 시 지식 맵 갱신 ``` /proj-map 2026-04-04-proj-agentic-ai-e2e-quality-harness-blueprint.md ``` 지식 맵은 "지금 어디에 있고, 무엇이 비어 있고, 다음에 어디로 가야 하는가"를 보여준다. ``` ✅ 확립됨 - 품질 기준 = 기능 정확도(1차) + 장애 가능성(2차) + 개선 개발(3차) - Claude Code SKILL 기반 하네스가 사내 LLM API와 호환됨 확인 ❓ 갭 - Spec Designer PRD 문서 수령 필요 (하지성 선임 담당) - 평가 재현성 확보 방안 미확정 🚀 다음 탐구 질문 - 비결정론적 응답의 허용 편차 범위를 어떻게 정의할 것인가? - SKILL 실행 결과를 어떤 형태로 이재훈 위원에게 보고할 것인가? ``` ### 왜 청사진 하나로 관리하는가 프로젝트가 완료되면 `connect/`, `merge/`, `develop/` 안의 파일들은 각자의 지식 카테고리로 흩어진다. 청사진은 이 모든 파일을 링크로 연결하는 **인덱스 파일**로 남는다. ``` /proj-close 2026-04-04-proj-agentic-ai-e2e-quality-harness-blueprint.md ``` **재배치 결과:** ``` connect/ → 80. References/82. Web Articles/agentic-ai-e2e-quality-harness/ 📎 2026-04-04-everything-claude-code-agent-harness.md (참고 자료) 📎 2026-04-03-agentic-ai-harness-skill-module.md (참고 자료) merge/ → 20. Literature Notes/agentic-ai-e2e-quality-harness/ 통합 분석 노트, 종합 인사이트 develop/ → 40. Docs/46. My Docs/agentic-ai-e2e-quality-harness/ 하네스 아키텍처 설계서 E2E 평가 자동화 SKILL 코드 에이전트 2건 품질 검토 리포트 팀원 사용 가이드 청사진 + _interviews/ → 70. Outputs/74. Projects/agentic-ai-e2e-quality-harness/ 2026-04-04-proj-agentic-ai-e2e-quality-harness-blueprint.md ← 인덱스 _interviews/2026-04-04-proj-init-...-v1.md 2026-04-24-agentic-ai-e2e-quality-harness-retro.md ← 회고 ``` ### 청사진이 인덱스 역할을 하는 구조 ``` ## 🔗 관련 파일 ### 참고 자료 (connect/) → [[📎 2026-04-04-everything-claude-code-agent-harness]] → [[📎 2026-04-03-agentic-ai-harness-skill-module]] ### 통합 분석 (merge/) → [[agentic-ai-quality-harness-synthesis]] ### 구현 산출물 (develop/) → [[agentic-ai-harness-architecture-spec]] → [[agentic-ai-e2e-skill-code]] → [[spec-designer-quality-report]] → [[ax-task-quality-report]] ### 회고 → [[2026-04-24-agentic-ai-e2e-quality-harness-retro]] ``` 유사 과제가 생겼을 때 청사진 파일 하나를 열면 이 프로젝트의 전체 지식 네트워크에 즉시 접근할 수 있다. ### 지식 카테고리별 재사용성 분류 `/proj-close`는 파일 이동 전에 각 산출물의 재사용 가능성을 분류한다. 유형 내용 이동 위치 **보편 원칙** "Claude Code SKILL 기반 하네스가 사내 LLM API와 호환되는 조건" `30. Permanent Notes/` **역할 방법론** "PO가 에이전트 품질 게이트를 설계할 때의 체크리스트" `30. Permanent Notes/` **도메인 지식** "E2E 평가 자동화 아키텍처 설계서" `40. Docs/46. My Docs/` **실패 교훈** "사내 인프라 제약으로 LangSmith 도입 불가 — 내재화 방향이 최적" 청사진 회고 섹션 **재사용 코드** "에이전트 품질 체크리스트 SKILL" `40. Docs/46. My Docs/` 이 분류가 이뤄질 때 vault는 프로젝트가 반복될수록 약해지는 게 아니라 **점점 강해지는 자산**이 된다. ### 개념: 목표에서 역산하는 지식 수집 지식 수집은 "흥미로운 것을 닥치는 대로 모으는 행위"가 아니라 **1~3년 목표를 향해 필요한 지식을 선택적으로 채워가는 행위**여야 한다. World Map은 이 전제를 시각화한다. 나의 지식 체계(CMDS 600-900 카테고리)가 어느 꼭지는 이미 채워져 있고, 어느 꼭지는 비어 있고, 어느 프로젝트가 어느 꼭지를 채웠는지를 한눈에 보여준다. ### 1~3년 목표 설정 ``` 1년 목표 (2026): [601] AI 에이전트 품질 관리 체계 확립 → E2E 하네스 구축 완료 ✅ (이번 프로젝트) → 사내 에이전트 5건 품질 검토 경험 축적 → LLMOps 운영 가이드라인 1차 완성 [630] 주식 자동매매 시스템 MVP → 백테스팅 프레임워크 구축 → 전략 1개 실운영 테스트 3년 목표 (2028): [801] AI 기반 사업화 아이디어 1건 실제 론칭 → SaaS 형태 또는 사내 서비스 정식 채택 → 수익 모델 검증 완료 [602] LLMOps 전문가 포지셔닝 → 사내 AI 품질 표준 정책 수립 주도 → 외부 공유 (발표 또는 블로그) 3회 이상 ``` ### 이번 프로젝트가 채운 꼭지 ``` CMDS World Map — 2026-04-04 기준 [601 AI Agent Development] ████████░░ 80% (이번 프로젝트로 크게 전진) ↑ E2E 하네스 + 품질 평가 기준 + 2건 실전 검토 [602 MLOps & LLMOps] ████░░░░░░ 40% ↑ 하네스 아키텍처로 LLMOps 기초 연결됨 [491 Codes] ██████░░░░ 60% ↑ Claude Code SKILL 기반 하네스 코드 축적 [640 Productivity] ███████░░░ 70% ↑ proj- SKILL 시스템 자체가 이 카테고리의 산출물 [630 Investment & Trading] ███░░░░░░░ 30% ← 다음 집중 필요 [801 Business Plans] ██░░░░░░░░ 20% ← 장기 목표 카테고리 ``` ### 프로젝트 → 지식 꼭지 연결 방식 프로젝트를 시작할 때부터 "이 프로젝트는 CMDS World Map의 어느 꼭지를 채우기 위한 것인가?"를 청사진 YAML에 명시한다. ``` knowledge-space: "10. CMDS Process/13. Develop/agentic-ai-e2e-quality-harness" target-cmds: - "[[📚 601 AI Agent Development]]" # 주 기여 - "[[📚 602 MLOps & LLMOps]]" # 부 기여 - "[[📚 491 Codes]]" # 코드 산출물 ``` `/proj-close` 이후 각 산출물이 해당 CMDS 카테고리에 재배치될 때, World Map의 해당 꼭지가 실질적으로 채워진다. ### 향후 프로젝트 로드맵 — 목표에서 역산 ``` 2026 Q2 (4~6월): ▶ [현재] E2E 품질 하네스 구축 → [601] 채움 ▶ [다음] 주식 자동매매 백테스팅 → [630] 채움 2026 Q3 (7~9월): ▶ LLMOps 운영 가이드라인 문서화 → [602] 채움 ▶ 사내 에이전트 추가 3건 검토 → [601] 심화 2026 Q4 (10~12월): ▶ AI 사업화 아이디어 구체화 → [710] [801] 채움 ▶ CMDS 시스템 외부 공유 → [640] 완성 2027~2028: ▶ [801] 사업 계획 실행 → 사업화 또는 사내 서비스 론칭 ▶ [602] LLMOps 전문가 포지셔닝 확립 ``` World Map 관점에서 보면 매 프로젝트는 "무엇을 만들었는가"가 아니라 **"지식 체계의 어느 꼭지를 얼마나 채웠는가"**로 평가된다. ## 언제 proj- SKILL을 써야 하는가 상황 추천 접근 단발 태스크 (1~3일) 단순 TODO 관리 → Project SKILL 불필요 Inbox 클리핑 5개 이상 동일 주제 축적 `/proj-init` 트리거 신호 — 프로젝트로 전환 역할 불명확한 탐색 `/proj-init` (역할 선택 포함) → `/proj` 역할 명확한 중기 프로젝트 (1~4주) `/proj-init --role [코드]` → 전체 사이클 장기 프로젝트 (1개월+, 지식 축적) 4개 스킬 전부 + `/proj-map` Phase 전환마다 복수 프로젝트 병행 `/cal-proj-day` 로 긴급도 기반 슬롯 배분 ## 결론 — 지식 수집과 실행이 같은 레일 위에 있어야 한다 이 시스템의 구조는 단순하다. ``` [Inbox에 쌓인 지식] ─▶ [프로젝트로 전환] ─▶ [일정에 반영] ↑ ↓ [지식 카테고리에 재배치] ◀─ [완료 회고] ◀─ [실행·기록] ``` 수집과 실행이 분리되어 있으면 Inbox는 영원히 쌓인다. 완료와 지식화가 분리되어 있으면 경험이 사라진다. `proj-` SKILL은 이 두 분리를 없앤다. 그리고 World Map은 이 순환이 1~3년 목표를 향해 **의도적으로 설계되고 있는지**를 확인하는 기준점이다. 프로젝트를 반복할수록 vault가 강해지는 구조, 그것이 `proj-` SKILL + World Map 조합의 목표다.