# [Claude Code] AI에게 '워크스페이스를 만드는 워크스페이스'를 만들게 하고, 원리까지 파헤쳐 봤다
## 📝 한줄 요약
Claude Code로 "다른 작업 환경을 자동으로 만들어주는 환경(메타하네스)"을 구축한 뒤, 만드는 데서 멈추지 않고 그 작동 원리를 끝까지 질문해 가며 이해하고, 직접 개선하고, 실제로 잘 작동하는지 검증까지 한 5일간의 기록입니다.
바쁘시면 이것만 읽어도 돼요:
- 사용 도구와 목표: Claude Code로 "워크스페이스를 만드는 워크스페이스"를 만들고, 그 원리를 비개발자도 이해할 수 있을 만큼 파고들었음
- 과정 중 깨달은 점: AI에게 " 만들어줘"만 하면 결과물은 나오지만 원리는 남지 않는다 → 라인별로 "왜?"를 물어야 내 것이 된다
- 핵심 해결 방법: 궁금한 점을 물어보고 그 질문과 답을 전용 학습 문서에 차곡차곡 축적 (나만의 교재가 됨)
- 특별히 인상적이었던 순간: "내가 궁금해할 만한 걸 미리 분석해서 채워줘"라고 했더니, AI가 내 질문 패턴을 알아채고 다음에 물어볼 내용까지 선제적으로 정리해준 순간
- 확장성/재사용성: 완성된 시스템은 아키타입(용도)만 고르면 PPT든 개발이든 워크스페이스를 자동 생성 — 실제로 2종을 만들어 검증 완료
- 배운 교훈: 결과물을 만드는 것보다 "왜 이렇게 동작하는가"를 이해하는 것이 진짜 실력으로 남는다
## 🎯 이런 분들께 도움돼요
- Claude Code 같은 AI 도구를 쓰긴 쓰는데 "이게 왜 이렇게 동작하지?"가 늘 답답한 비개발자
- 단순 질문을 넘어 AI 작업 환경(워크스페이스·스킬·커맨드) 구조를 직접 만들어보고 싶은 분
- 같은 과정을 듣는 GPTers 수강생 동료 — "이 과제 어떻게 소화했나" 궁금한 분
- AI에게 단순히 시키는 게 아니라, 질문하며 원리를 배우는 학습법이 궁금한 분
## 😫 문제 상황 (Before)
저는 개발자가 아닙니다. 강의 과제로 "**워크스페이스를 만드는 워크스페이스**(메타하네스)"라는 걸 만들게 됐어요. 쉽게 말하면, 제품을 직접 찍어내는 게 아니라 제품을 찍어낼 공장을 설계하는 설비 같은 겁니다.
문제는, AI에게 "만들어줘"라고 하면 결과물은 척척 나오는데 정작 저는 그게 왜 그렇게 동작하는지 하나도 모른다는 점이었어요. 폴더가 수십 개, 설정 파일이 수십 개인데 "이 파일은 언제 쓰이는 거지?", "이건 왜 있는 거지?"를 물어볼 엄두도 안 났습니다.
복붙하듯 불안하게 쓰는 느낌. 결과물은 있지만 내 손에 남는 건 없는 그 답답함이 이 작업을 깊게 파고들게 된 계기였습니다.
## 🛠️ 사용한 도구
- 도구명: Claude Code (VS Code + CLI, Windows 환경)
- 모델: Claude Sonnet / Opus (작업 난이도에 따라 전환)
- 특이사항: 끼리끼리(kkirikkiri) 플러그인을 활용해 내가 만든 시스템을 스스로 점검
---
## 🗺️ 잠깐 — '메타하네스'가 어떻게 생겼고 어떻게 동작하냐면
본격적인 작업기를 읽기 전에, 많이들 궁금해하시는 "그래서 그게 정확히 뭔데? 어떻게 생겼는데?"를 그림으로 먼저 보여드릴게요.
### ① 실행 흐름 — "만들어줘" 한마디에서 워크스페이스가 나오기까지
명령어 하나(`/init`)를 실행하면, 아래 6단계를 순서대로 밟습니다. 앞 단계를 끝내지 못하면 다음 단계로 넘어가지 않아요.
`
사용자: "워크스페이스 만들어줘"
│
▼
┌──────────────────────────────────────────────┐
│ Phase 0 · 현황 감사 │
│ 같은 목적의 워크스페이스가 이미 있나? 확인 │
└──────────────────────────────────────────────┘
│ (신규 생성으로 확정)
▼
┌──────────────────────────────────────────────┐
│ Phase 1 · 인터뷰 5문항 🗣️ │
│ 용도(아키타입) 고르기 + Q1~Q5 질문 │
│ ※ 사용자 확인 전에는 절대 다음으로 안 넘어감 │
└──────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ Phase 2 · 폴더 만들기 📁 │
│ 빈 폴더(그릇)만 먼저 생성 │
└──────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ Phase 3 · 규칙 설명서 작성 📜 │
│ "이 공간의 정체성·할 일·금지사항" 채우기 │
└──────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ Phase 4 · 실제 콘텐츠 생성 ★ 🛠️ │
│ 명령어·작업 가이드·양식 파일을 직접 만듦 │
└──────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ Phase 5 · 지식 자료 첫 입력 📚 │
└──────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ Phase 6 · 검증 → 기록 ✅ │
│ 구조검사 + 동작테스트 통과 → 변경이력 한 줄 │
└──────────────────────────────────────────────┘
│
▼
✨ 새 워크스페이스 완성### ② 각 단계가 "정해진 표준 파일"을 보고 따른다 (일관성의 비결)
매번 즉흥적으로 만드는 게 아니라, 단계마다 미리 정해둔 표준 파일을 읽고 그대로 따릅니다. 그래서 누가 언제 돌려도 비슷한 품질이 나와요.
단계 읽는 핵심 파일 무슨 역할
──────────────────────────────────────────────────────────────
Phase 1 ──→ 20-archetypes/ (용도 5종 목록) 어떤 용도인지 고르기
└─→ (5문항 인터뷰) 재료 수집
Phase 2 ──→ 01-FOLDER_NUMBERING.md 폴더 번호 규칙
└─→ scripts/init-workspace.ps1 폴더 자동 생성
Phase 3 ──→ 20-archetypes/{용도}.md ★먼저 읽기 반쯤 채워진 설명서 골격
├─→ 04-CLAUDE_MD_GUIDE.md 12개 항목 작성법
└─→ 02-FILE_NAMING.md 용어 통일 규칙
Phase 4 ──→ templates/clip-templates.md (글쓰기·학습·리서치용)
│ 또는 phase4-cmdloop.md (개발·지식베이스용)
└─→ templates/README_TEMPLATE.md 사용설명서 골격
Phase 6 ──→ /validate (구조검사)
├─→ /ws-qa (동작테스트)
└─→ CHANGELOG.md 변경이력 기록
> 본문 6번 에피소드에서 다룬 "저사양 모델 보완"의 핵심이 바로 여기예요 — 같은 자료 폴더를 20-knowledge-base로 이름을 하나로 통일(`02-FILE_NAMING.md`)했더니, 똑똑하지 않은 모델도 헷갈리지 않게 됐습니다.
### ③ 폴더 구조 — 완성된 워크스페이스는 이렇게 생겼다
번호는 00, 10, 20…처럼 10칸씩 띄워뒀어요. 나중에 사이에 새 폴더를 끼워 넣을 여유를 두기 위해서입니다.
[워크스페이스 이름]/
├── CLAUDE.md ← AI가 가장 먼저 읽는 "규칙·정체성" 설명서
├── README.md ← 사람이 처음 보는 "사용 설명서"
├── CHANGELOG.md ← 변경 이력 기록장
├── .claude/
│ ├── commands/ ← 슬래시 명령어(/specify 등) 정의
│ └── skills/ ← 작업 진행 규칙 (워크스페이스의 두뇌)
├── 00-system/ ← 말투·언어·금지사항 설정
├── 10-planning/ ← 입력 자료 (개발용은 10-spec/)
├── 20-knowledge-base/ ← 참고 자료·도메인 지식
├── 30-templates/ ← 복붙용 양식·체크리스트
├── 40-drafts/ ← 작업 중 임시 파일
├── 50-my-work/ ← 내 산출물 전용
├── 90-output/ ← 최종 결과물
└── _meta/ ← 세션 기록·진행 상황이 세 가지(흐름·참조 파일·폴더 구조)가 머릿속에 그려지면, 아래 작업기가 훨씬 잘 읽히실 거예요.
---
## 🔧 작업 과정
### 1. 일단 만들긴 했다 — 그런데 작동 원리를 모르겠다
강의 초반에는 과제대로 메타하네스를 만들었습니다. 표준 문서 18개, 용도별 템플릿(아키타입) 5종, 자주 쓰는 명령어 4개까지 갖춘 제법 그럴듯한 시스템이 완성됐죠. 개인 프로젝트용 워크스페이스도 하나 만들어봤고요.
그런데 다 만들고 나니 오히려 더 답답해졌습니다. "이걸 실행하면 워크스페이스가 하나 만들어진다는데, 처음부터 끝까지 무슨 일이 일어나는 거지?"
그래서 작정하고 물어봤습니다.
```
커맨드를 실행하면 워크스페이스가 하나 만들어진다.
처음부터 워크스페이스가 만들어질 때까지의 흐름과,
각 단계에서 어떤 파일이 작용하는지 알려주세요.
나는 이 워크스페이스의 구조, 작동 방식과 원리를 이해하고 싶다.
```
AI는 단계별 흐름과 각 단계에서 작동하는 파일을 차근차근 설명해줬습니다. 여기서 멈추지 않고 한 발 더 들어갔어요.
```
이 흐름에서 한 번도 참조되지 않은 파일들이 있어.
이 파일들은 언제 참조되어 사용되는가? 이 워크스페이스에서 이 파일의 목적은 무엇인가?
```
"안 쓰이는 것 같은 파일"의 정체를 물으니, 다른 명령어가 쓰는 파일인지, 시스템 내부에서 자동으로 쓰이는 파일인지 분류해서 알려줬습니다. 이때부터 안개가 걷히기 시작했어요.
---
### 2. "왜?"를 라인별로 묻고, 그 질문과 답을 문서로 쌓았다
제일 핵심이 된 작업입니다. 가장 중요한 설정 파일 하나를 띄워놓고, 한 줄 한 줄 짚어가며 질문했어요.
```
이 파일을 심층분석할 거다. 이 파일을 읽고 나의 질문에 대답해줘.
```
```
대괄호 같은 표시는 언제 쓰는가? {} 괄호는 또 언제 쓰는가?
```
이런 식으로 사소해 보이는 표기법부터, 각 단계에서 어떤 질문을 던져야 하는지, "한 번에 쭉 진행하는 방식"과 "반복하며 다듬는 방식"이 어떻게 다른지까지 꼬치꼬치 물었습니다.
그리고 중요한 건 — 물어보고 끝내지 않았다는 점이에요. 질문과 답을 별도 학습 문서에 차곡차곡 정리해달라고 했습니다.
```
지금까지 내가 질문하고 네가 대답한 내용을 요약해서 학습 문서에 추가해줘.
맨 뒤에 추가하지 말고, 원본 파일의 순서에 맞게 끼워 넣어줘.
```
이렇게 하니 원본 설정 파일의 흐름을 그대로 따라가는 나만의 해설서가 만들어졌습니다. 나중에 다시 봐도, 남에게 설명할 때도 쓸 수 있는 자산이 생긴 거죠.
여기서 "오!" 했던 순간이 나옵니다. 어느 순간 이렇게 부탁했어요.
```
이 학습 문서는 내가 궁금한 점을 물어보며 기록한 거다.
내가 궁금해하는 패턴을 파악해서, 다음 부분부터는 내가 궁금해할 만한 내용을 미리 분석해서 추가해줘.
```
그랬더니 AI가 제 질문 스타일을 알아채고, 제가 아직 묻지도 않은 부분까지 "이건 이런 게 궁금하실 것 같아서"라며 선제적으로 정리해줬습니다. 단순히 답변하는 도구가 아니라, 제 학습 흐름을 읽고 한 발 앞서 가이드하는 느낌이었어요.
---
### 3. 전문가(강사) 샘플과 내 것을 나란히 놓고 개선했다
원리를 어느 정도 이해하고 나니, "내가 만든 게 잘 만든 걸까?"가 궁금해졌습니다. 마침 강사님이 전문가 샘플을 제공해주셨어요.
```
이건 이 분야 전문가인 강사가 샘플로 준 파일이다.
이 내용과 내 메타하네스를 비교하고, 개선하는 데 도움이 되는 게 있는지 확인해줘.
```
AI는 두 결과물을 비교해 개선 포인트를 뽑아줬고, 저는 그걸 실제로 적용했습니다. 예를 들면 이런 것들이었어요 — 안 쓰이는 빈 폴더 정리, 중복된 시작 안내 합치기, 핵심 설명서를 200줄 이내로 압축해 군더더기를 덜어내기. "전문가는 더 단순하게 만든다"는 걸 비교하면서 체감했습니다.
이때 한 가지 원칙을 지켰어요 — 되돌릴 수 없는 작업(폴더 삭제 등)은 AI에게 맡기지 않았습니다.
```
삭제는 네가 하지 마, 내가 할게. 삭제할 폴더만 알려줘.
```
이렇게 "분석·제안은 AI, 위험한 실행은 사람"으로 역할을 나누니 안심하고 정리할 수 있었습니다. 안 쓰이는 폴더와 파일을 참조 관계를 추적해 골라냈고, 군더더기를 덜어낸 깔끔한 시스템이 됐어요.
---
### 4. 내가 만든 시스템을 AI로 스스로 점검했다
흥미로운 시도였습니다. 끼리끼리(kkirikkiri)라는 플러그인을 써서, 내가 만든 메타하네스가 정말 다양한 용도에서 잘 작동하는지 스스로 점검하게 했어요.
> 참고로 이 시스템은 용도(아키타입)를 글쓰기 · 학습 · 리서치 · 개발 · 지식베이스 5가지 중에서 고르면, 그에 맞는 워크스페이스를 만들어줍니다. 그래서 "5가지 용도 모두에서 잘 만들어지는가?"를 점검해야 했어요.
```
여러 용도(아키타입)에 대해서, 내 산출물인 워크스페이스가 잘 돌아가도록
너를 점검할 거야. 끼리끼리 플러그인을 쓰려고 하는데 좋은 방법이야?
```
대표 용도 2종을 먼저 점검하고, 나머지 3종까지 전체를 훑었습니다. 점검은 막연한 "괜찮네"가 아니라 점수로 나왔어요 — 글쓰기 94점, 지식베이스 90점, 학습 96점, 리서치 99점, 개발 99점. 그리고 5가지 용도에서 공통으로 발견된 결함을 하나씩 고쳤습니다.
여기서 중요한 깨달음이 있었어요. 결함을 개별 워크스페이스가 아니라 "공장"(메타하네스) 자체에 고쳤다는 점입니다. 한 번 고치니 앞으로 만들 모든 워크스페이스에 자동으로 반영됐어요. AI가 만든 것을 다시 AI로 점검하고, 뿌리에서 고치는 경험이었습니다.
---
### 5. 진짜 검증 — 실제 워크스페이스 2종을 만들어봤다
마지막은 진검승부였습니다. "공장 설계도가 좋아 보여도, 진짜 제품이 나와야 의미가 있다"는 생각으로 실제 워크스페이스 2개를 만들어 검증했어요.
① 발표용 PPT 워크스페이스
```
공공데이터 탐색 도우미 Final Project PPT 12~15장 작성.
대상은 대학교 2학년 학생, 발표 전 PPT 완성이 목표.
구조 설계 → 슬라이드 초안 → 내용 보완 → 최종 검토 순서로.
```
② AI 서비스 개발 워크스페이스 (JobFit)
```
개발을 위한 워크스페이스를 만들 거다.
JobFit이라는 생성형 AI 취업 코칭 서비스이고,
공고 분석 챗봇을 데모로 구현하는 걸 목표로 한다.
```
두 워크스페이스 모두 정상적으로 생성됐고, 구조 검증까지 통과했습니다. "내가 만든 공장이 정말로 제품을 찍어낸다"는 걸 두 눈으로 확인한 순간이었어요.
---
### 6. 막혔던 부분 — 저사양 모델에서 품질이 떨어졌다
순탄하지만은 않았습니다. 워크스페이스를 만들 때 어떤 AI 모델을 쓰느냐에 따라 결과 품질이 눈에 띄게 달라지는 문제를 발견했어요. 낮은 등급 모델을 쓰면 대화 내용이 부실해지고, 꼭 거쳐야 할 질문 단계를 건너뛰기도 했습니다.
```
모델 등급이 낮을수록 출력이 부실하고 질문 단계를 생략하기도 한다.
이런 현상을 보완하고 싶다. 보완 계획을 수립해줘.
```
AI와 함께 단계별 보완 계획을 세웠는데, 원인을 파고드니 의외로 단순하고 누구나 공감할 만한 것이었어요.
- 같은 것을 여러 이름으로 부르고 있었다. 예를 들어 자료를 담는 폴더를 어떤 곳에선 그냥 knowledge, 다른 곳에선 20-knowledge-base처럼 다르게 적어뒀더니, 똑똑하지 않은 모델은 이걸 서로 다른 폴더로 착각했어요. → "한 개념은 한 이름으로" 통일했습니다.
- 설명서가 너무 길었다. 한 파일에 내용이 900줄 가까이 쌓이니, 약한 모델은 뒷부분을 슬슬 흘렸어요. → 파일을 절반(약 470줄)으로 쪼개서, 필요한 부분만 집중해 읽도록 했습니다.
- 꼭 거쳐야 할 질문을 건너뛰었다. → "이 질문은 반드시 확인받고 넘어가라"는 통과 관문을 단계마다 박아뒀어요.
사람한테 일을 맡길 때 "알아서 잘해"가 아니라 "용어를 통일하고, 설명을 짧게 끊어주고, 빼먹으면 안 되는 건 못박아 두는 것"과 똑같은 원리였습니다. 덕분에 저사양 모델에서도 품질이 들쭉날쭉하지 않게 됐어요.
---
## ✅ 결과 (After)
### Before vs After
| 항목 | Before | After |
| ------------------ | ----------------------------- | ---------------------------------------------------- |
| 시스템에 대한 이해 | 결과물은 있지만 원리는 깜깜 | 각 파일이 왜 있는지 알고 주도적으로 수정 |
| 작업 태도 | 복붙하듯 불안하게 사용 | "왜 이렇게 동작하는지" 알고 사용 |
| 검증 여부 | 잘 만들어졌는지 확신 없음 | 실제 워크스페이스 2종 생성으로 검증 완료 |
| 품질 점검 | 막연한 "괜찮겠지" | 5가지 용도 점수화(90~99점) + 공통 결함 뿌리에서 수정 |
| 모델 안정성 | 저사양 모델에서 품질 들쭉날쭉 | 보완 적용 후 저사양에서도 단계 유지 |
| 남은 자산 | 결과물 폴더뿐 | 나만의 학습 해설서 + 검증된 템플릿 |### 결과물
- 원리를 이해하고 직접 개선·검증한 메타하네스 시스템
- 라인별 질문을 정리한 나만의 학습 해설서
- 검증을 통과한 워크스페이스 2종(PPT용·개발용)
## 💬 이 과정에서 배운 AI 활용 팁
### 효과적이었던 것
1. "만들어줘"에서 멈추지 말고 "왜 이렇게 동작해?"를 라인별로 물어라. 결과물은 AI가 주지만, 원리는 질문해야 내 것이 된다.
2. 질문과 답을 전용 문서에 순서대로 쌓아라. 흩어진 대화가 아니라, 다시 보고 남에게 설명할 수 있는 나만의 교재가 된다.
3. AI가 만든 것을 다시 AI로 검증하라. 점검 도구로 스스로 결함을 찾게 하고, 실제로 만들어보며 품질을 확인한다.
4. 전문가 샘플과 나란히 비교하라. "내 것 잘 됐나?"를 혼자 고민하지 말고, 좋은 기준과 비교하면 개선점이 선명해진다.
### 이렇게 하면 안 돼요
1. 되돌릴 수 없는 작업(폴더 삭제 등)을 AI에게 통째로 맡기지 마라. 분석·제안은 AI에게, 삭제 같은 위험한 실행은 목록만 받아 사람이 직접.
2. 모델 등급을 신경 안 쓰면 품질이 들쭉날쭉해진다. 저사양 모델을 쓸 거라면, 설정에 "단계를 빼먹지 말라"는 명시적 지시를 미리 보강해두자.
## 🌍 다른 업무에 적용한다면?
"만들고 → 원리를 이해하고 → 검증한다"는 이 사이클은 어디에나 적용됩니다. 회사 보고서 자동화, 발표 자료 템플릿, 반복 업무 자동화 — 무엇을 만들든 "왜 이렇게 동작하는지" 질문하고 기록하는 습관만 있으면, 다음에 비슷한 일이 왔을 때 처음부터 다시 헤매지 않습니다.
## 🚀 앞으로의 계획
검증용으로 만든 JobFit(생성형 AI 취업 코칭 서비스)을 실제 개발로 이어가 보려 합니다. 공고 분석 챗봇 데모를 진짜 동작하는 형태로 구현하는 게 목표예요. 이번에 "워크스페이스를 만드는 워크스페이스"의 원리를 이해한 만큼, 이번엔 그 위에서 진짜 제품을 만들어보는 다음 단계로 넘어가려 합니다.
## 📋 재사용 가능한 프롬프트
### 프롬프트 1: AI 결과물의 작동 원리 이해하기
> [내가 만든 결과물/파일]을 심층분석할 거다. 이 파일을 읽고 나의 질문에 대답해줘.
> 처음부터 끝까지의 흐름과, 각 단계에서 어떤 부분이 작용하는지 설명해줘.
> 나는 결과물의 구조와 작동 원리를 이해하고 싶다.
> [내가 만든 결과물/파일] 부분은 본인 상황에 맞게 변경하세요
### 프롬프트 2: 질문과 답을 나만의 학습 문서로 축적하기
> 지금까지 내가 질문하고 네가 대답한 내용을 요약해서 [학습 문서 이름].md에 추가해줘.
> 맨 뒤에 추가하지 말고, 원본의 순서에 맞게 끼워 넣어줘.
> 그리고 내가 궁금해하는 패턴을 파악해서, 다음에 내가 궁금해할 만한 내용도 미리 분석해 추가해줘.
> [학습 문서 이름] 부분은 본인 상황에 맞게 변경하세요
### 프롬프트 3: 전문가 샘플과 비교해 개선하기
> 이건 [이 분야 전문가]가 만든 샘플이다.
> 이 내용과 내 [결과물]을 비교하고, 개선하는 데 도움이 되는 게 있는지 확인해줘.
> 단, 삭제 같은 되돌릴 수 없는 작업은 네가 하지 말고 목록만 알려줘. 실행은 내가 한다.
> [이 분야 전문가], [결과물] 부분은 본인 상황에 맞게 변 경하세요
### 프롬프트 4: 저사양 모델에서도 품질이 흔들리지 않게 보완하기
> 내 [작업 지시 문서]를 낮은 등급 모델로 실행하면 단계를 건너뛰거나 품질이 들쭉날쭉해진다.
> 다음 3가지 관점으로 점검하고 보완해줘.
> ① 같은 개념을 여러 이름으로 부르는 곳이 있으면 하나의 용어로 통일
> ② 한 파일이 너무 길면, 필요한 부분만 읽도록 나누기
> ③ 꼭 거쳐야 하는 질문·단계는 "건너뛰지 말고 반드시 확인"하도록 못박기
> [작업 지시 문서] 부분은 본인 상황에 맞게 변경하세요
---
## 📂 부록 — workspace-standards 전체 구조
실제로 어떤 폴더와 파일로 이뤄져 있는지 궁금한 분들을 위해 전체 트리를 첨부합니다.
workspace-standards/
│
├── CLAUDE.md # 메타하네스의 정체성·규칙 (가장 중요)
├── README.md # 레포 소개 + 문서 안내
├── CHANGELOG.md # 변경 이력 기록장
├── AGENTS.md # 역할 슬롯 5종 정의
├── QUICKSTART.md # 5분 빠른 시작 가이드
├── DEVLOG.md # 개발 로그
│
├── 00-GETTING_STARTED.md ┐
├── 01-FOLDER_NUMBERING.md │
├── 02-FILE_NAMING.md │
├── 03-CLAUDE_CODE_CONFIG.md │
├── 04-CLAUDE_MD_GUIDE.md │
├── 05-MIGRATION_GUIDE.md │
├── 06-CLAUDE_CODE_AGENT_METHODOLOGY.md │
├── 07-SECURITY_SECRETS.md │ 표준 문서 19개 (00~18)
├── 08-TEMPLATE_QA.md │ — 워크스페이스를 만드는
├── 09-MULTI_CLI_GUIDE.md ├─ 규칙·방법론·개념 모음
├── 10-EXAMPLE_METHODOLOGY.md │
├── 11-MEMORY_SYSTEM.md │
├── 12-HOOK_AUTOMATION.md │
├── 13-MODULAR_RULES.md │
├── 14-CLAUDE_TEMPLATE_SCHEMA.md │
├── 15-STRUCTURE_JSON_SCHEMA.md │
├── 16-SCALE_MODES.md │
├── 17-TRIGGER_BOUNDARIES.md │
├── 18-HARNESS_CONCEPTS.md ┘
│
├── .claude/ # Claude Code 설정
│ ├── commands/ # 슬래시 명령어 4종
│ │ ├── init.md # /init — 새 워크스페이스 생성
│ │ ├── validate.md # /validate — 구조 검증
│ │ ├── migrate.md # /migrate — 기존 폴더 변환
│ │ └── ws-qa.md # /ws-qa — 동작 품질 테스트
│ ├── agents/ # 역할 카드 5종
│ │ ├── workspace-builder.md # 워크스페이스 생성 안내자
│ │ ├── structure-validator.md # 구조(12섹션) 감사자
│ │ ├── migration-planner.md # 기존 폴더 전환 계획자
│ │ ├── domain-adapter.md # 도메인 맞춤 안내자
│ │ └── quality-checker.md # 시나리오 기반 QA 검토자
│ ├── skills/ # (생성 워크스페이스용 스킬 자리)
│ └── settings.local.json # 로컬 권한·설정
│
├── 20-archetypes/ # 용도별 설명서 골격 5종
│ ├── writer-agent.md # 글쓰기
│ ├── study-agent.md # 학습
│ ├── research-agent.md # 리서치
│ ├── development-agent.md # 개발
│ └── knowledge-base-agent.md # 지식베이스
│
├── templates/ # 복붙용 원본 템플릿
│ ├── CLAUDE_TEMPLATE.md # CLAUDE.md 범용 뼈대 (빈 칸 채우기용)
│ ├── README_TEMPLATE.md # 사용설명서 골격
│ ├── clip-templates.md # 글쓰기·학습·리서치 모드 골격
│ ├── phase4-cmdloop.md # 개발·지식베이스 모드 골격
│ ├── requirements-traceability.md # 완성도 추적표 (요구↔충족 근거)
│ ├── hidden-requirements-checklist.md # 숨은 요구사항 점검표
│ ├── dev-project.md # 개발 프로젝트 템플릿
│ ├── content-project.md # 콘텐츠 프로젝트 템플릿
│ └── research-project.md # 리서치 프로젝트 템플릿
│
├── scripts/ # 자동화 스크립트
│ ├── init-workspace.ps1 # 폴더 생성 (Windows)
│ ├── init-workspace.sh # 폴더 생성 (Mac/Linux)
│ ├── init-workspace-legacy.sh # 마이그레이션용
│ ├── validate.sh # 구조 검증
│ └── auto-fix.sh # 구조 자동 복구
│
├── 30-examples/ # 완성 예시 워크스페이스 6종 (산출물 위치)
│ ├── writer-test/ # 글쓰기 예시
│ ├── research-test/ # 리서치 예시
│ ├── dev-test/ # 개발 예시
│ ├── dev-cmdloop-example/ # 개발(커맨드 루프) 예시
│ ├── kb-test/ # 지식베이스 예시
│ └── study-test/ # 학습 예시 ↓ (대표로 펼침)
│ ├── CLAUDE.md # 이 학습 공간의 규칙
│ ├── README.md # 사용 설명서
│ ├── CHANGELOG.md # 변경 이력
│ ├── .claude/ # 명령어·역할 카드
│ │ ├── commands/ # study·summarize·quiz·review·done
│ │ └── agents/concept-explainer.md # 개념 설명 역할 카드
│ ├── 10-inbox/ # 새로 배운 것 임시 보관
│ ├── 20-active/ # 학습 중인 주제
│ ├── 30-library/ # 정리된 지식 (예: SQL활용/)
│ ├── 30-templates/concept-card.md # 개념 카드 양식
│ ├── 90-archive/ # 완료·보관
│ └── _meta/ # 진행·퀴즈 점수·세션 기록
│
├── 40-input/ # 작업 입력
├── 90-output/ # 작업 출력
│
├── _meta/ # 세션 로그·점검 기록
│ ├── session-log.md # 세션 작업 기록
│ ├── context-handoff.md # 세션 간 인수인계
│ ├── progress.md # 단계별 진행 현황
│ ├── decisions.md # 설계 결정 기록
│ ├── RUBRIC_archetype-audit.md # 끼리끼리 점검 채점 기준
│ └── DIAGNOSIS_archetype-audit.md # 점검 진단 결과
│
> 나머지 예시 5종(writer·research·dev·dev-cmdloop·kb-test)도 위 study-test처럼 CLAUDE.md + README + .claude/ + 10단위 폴더를 갖춘 완성 워크스페이스입니다. 메타하네스가 "공장"이라면, 이 6개는 그 공장이 실제로 찍어낸 "제품 샘플"인 셈이에요.
