# 시스템 전수평가 및 개선 — Claude Skill Creator 블로그 기반

## 배경
Anthropic 블로그 "Improving Skill Creator: Test, Measure, and Refine Agent Skills"의 핵심 방법론을 우리 개발 시스템에 적용하여 전수평가하고 개선한다.

## 블로그 핵심 인사이트 (7가지)

### 1. Eval 시스템 (테스트 프레임워크)
- 모든 스킬/워크플로우에 **테스트 프롬프트 세트 + 기대 결과 정의**
- "좋은 결과"를 명확히 정의하고 자동 검증
- 회귀 감지: 이전에 작동하던 것이 깨지는지 자동 감지

### 2. 벤치마크 (성능 측정)
- **통과율**: 스킬이 기대 결과를 만족하는 빈도
- **소요 시간**: 실행 속도 추적
- **토큰 사용량**: 비용/효율성 추적
- 대시보드, CI 연동 가능

### 3. 병렬 실행 격리
- 순차 실행은 느리고 컨텍스트 누적 → 오염
- **독립 에이전트**를 병렬로 실행, 각각 깨끗한 컨텍스트
- 테스트 간 교차 오염 제거

### 4. A/B 비교
- 두 버전을 **맹검 평가**하여 실제 개선 여부 판단
- 변경이 "개선"인지 "변화"인지 구분

### 5. 트리거 최적화
- 너무 넓으면 거짓 양성 (불필요한 트리거)
- 너무 좁으면 거짓 음성 (필요할 때 트리거 안 됨)
- 샘플 프롬프트로 트리거 정확도 테스트

### 6. 회귀 감지
- 모델/인프라 변화에 따른 자동 회귀 테스트
- 실제 업무에 영향 주기 전 조기 경보

### 7. Skill → Specification 진화
- "어떻게(How)" 대신 "무엇을(What)" 기술
- 모델이 개선되면 상세 구현 지시 불필요 → 목표 명세만으로 충분

---

## 우리 시스템 전수평가 대상 파일

아래 파일들을 **전부** 읽고 분석할 것:

### 핵심 인프라
1. `/home/jay/workspace/dispatch.py` — 위임 오케스트레이터
2. `/home/jay/workspace/prompts/DIRECT-WORKFLOW.md` — 팀장 워크플로우
3. `/home/jay/workspace/teams/shared/QC-RULES.md` — QC 규칙
4. `/home/jay/workspace/teams/shared/QC-RULES-EXTENDED.md` — 확장 QC 규칙
5. `/home/jay/workspace/memory/specs/work-level-system.md` — 작업 레벨 시스템
6. `/home/jay/workspace/memory/specs/anu-guide.md` — 아누 가이드
7. `/home/jay/workspace/memory/specs/scqa-report-template.md` — 보고서 템플릿
8. `/home/jay/workspace/memory/task-timer.py` — 작업 시간 추적

### 팀 프롬프트/설정
9. `/home/jay/workspace/prompts/team_prompts.py` — 팀 프롬프트 생성
10. `/home/jay/workspace/memory/organization-structure.json` — 조직 구조
11. `/home/jay/workspace/memory/specs/bot-team-mapping.md` — 봇-팀 매핑

### 대시보드/모니터링
12. `/home/jay/workspace/dashboard/server.py` — 대시보드 서버
13. `/home/jay/workspace/dashboard/index.html` — 대시보드 UI

---

## 평가 기준 (블로그 인사이트 ↔ 우리 시스템 매핑)

### A. Eval 시스템 유무
- 현재: QC-RULES + qc_verify.py로 셀프 QC
- 질문: **위임된 작업이 기대 결과를 만족하는지 자동 검증하는 Eval이 있는가?**
- 질문: 팀이 "성공"이라고 보고했지만 실제로는 실패한 경우(task-787.1 사례)를 자동 감지할 수 있는가?

### B. 벤치마크/성능 추적
- 현재: task-timer로 시간만 추적
- 질문: **팀별/작업 유형별 통과율, 토큰 사용량, 소요 시간을 추적하고 있는가?**
- 질문: 어떤 팀이 어떤 작업에서 효율적인지 데이터 기반 판단이 가능한가?

### C. 병렬 실행 격리
- 현재: 동일 스크립트 동시 실행 시 결과 파일 충돌 발생 (task-786.1에서 발견)
- 질문: **병렬 위임 시 파일/리소스 경쟁 방지 메커니즘이 있는가?**
- git worktree 격리가 있지만, 동일 프로젝트 동시 작업 시 충돌 가능

### D. 위임 정확도 (트리거 최적화)
- 현재: 작업 레벨 시스템(Lv.0-4) + 아누의 판단으로 팀 배정
- 질문: **레벨 판정이 정확한가? 거짓 양성/음성 사례가 있었는가?**
- 사례: 1팀이 2번 실패한 Instagram 건 (task-780.1, 781.1)

### E. 회귀 감지
- 현재: 없음
- 질문: **이전에 성공한 워크플로우가 갑자기 실패할 때 자동 감지하는 시스템이 있는가?**

### F. 보고서 품질 검증
- 현재: QC verify가 파일 존재/포맷만 확인
- 질문: **보고서 내용이 사실인지 교차 검증하는 메커니즘이 있는가?**
- task-787.1처럼 다른 팀 결과를 복사하여 "성공"으로 보고하는 것을 방지할 수 있는가?

### G. 워크플로우 효율성
- 현재: DIRECT-WORKFLOW.md가 "어떻게(How)"를 상세 기술
- 질문: **"무엇을(What)"만 기술하고 팀이 자율적으로 실행하면 품질이 올라갈 것인가?**
- Opus 팀장이 "설계/분배/검토만"하고 코딩은 팀원에게 위임하는 구조가 효율적인가?

---

## 산출물 요구사항

### 산출물 1: 시스템 전수평가 보고서
`/home/jay/workspace/memory/reports/system-eval-v1.md`
- 위 A~G 각 항목에 대해:
  - **현재 상태**: 구체적 근거(파일명:줄번호 수준)
  - **점수**: 1(없음)~5(완벽) 척도
  - **개선 필요도**: 상/중/하
  - **구체적 개선안**: 실현 가능한 수준의 제안

### 산출물 2: 우선순위 개선 목록
`/home/jay/workspace/memory/reports/system-improvements-v1.md`
- 영향도 × 실현 용이성 매트릭스로 우선순위 정렬
- 각 개선 항목에:
  - 예상 효과
  - 필요 작업량 (시간/복잡도)
  - 담당 적합 팀
  - 의존 관계

### 산출물 3: Quick Win 구현 (선택)
- 평가 중 발견한 1~2줄 수정으로 즉시 개선 가능한 항목이 있으면 바로 적용
- 단, 구조 변경은 금지. 설정/상수 수준만 허용.

## 주의사항
- **코드 수정은 Quick Win만 허용**. 나머지는 보고서/제안서만 작성.
- 모든 평가는 **구체적 근거**(파일:줄번호, 실제 사례)와 함께 기술. 추상적 평가 금지.
- Fantasy Approval 금지 — "우리 시스템은 훌륭합니다" 같은 표현 절대 불가. 문제점 위주로 평가.
- 블로그 인사이트 중 우리 시스템에 **적용 불가능한 것**도 그 이유와 함께 명시.