# 시스템 전수평가 보고서 v1.0

> 평가 기준: Anthropic "Improving Skill Creator" 블로그 7대 인사이트 ↔ 우리 시스템 매핑
> 평가일: 2026-03-22
> 평가자: 헤르메스 (개발1팀장)
> 대상 파일: 13개 (핵심 인프라 8개 + 팀 설정 3개 + 대시보드 2개)

---

## 시스템 개요

현재 시스템은 아누(오케스트레이터)가 다수의 봇(B/C/D/E)에게 작업을 위임하는 다중 에이전트 파이프라인이다. 주요 구성요소는 다음과 같다.

**작업 관리:** `dispatch.py` (위임 진입점), `task-timer.py` (시간 추적), `finish-task.sh` (작업 완료 처리)

**품질 검증:** `qc_verify.py` (10개 verifier 자동 실행), `QC-RULES.md` v3.0 (Fantasy Approval 방지 규칙)

**격리/안전:** `worktree_manager.py` (git worktree 격리), `bot-team-mapping.md` (봇-팀 매핑)

**프롬프트 생성:** `team_prompts.py` (팀별 동적 프롬프트), `work-level-system.md` (Lv.0~4 레벨 정의)

**모니터링:** `server.py` + `index.html` (React/Tailwind 대시보드)

**조직:** `organization-structure.json` (86KB, 7개 팀 역할/스킬/KPI 정의)

운영 현황: 759건 완료, 평균 소요시간 1623초(약 27분), dev1 28.7분 / dev2 26.5분 / dev3 21.3분.

---

## 평가 항목별 분석

### A. Eval 시스템 (기대 결과 자동 검증)

**점수: 3/5 | 개선 필요도: 상**

**현재 상태:**

`qc_verify.py`에 10개의 verifier가 정의되어 있으며(ALL_CHECKS: `api_health`, `file_check`, `data_integrity`, `test_runner`, `tdd_check`, `schema_contract`, `pyright_check`, `style_check`, `scope_check`, `critical_gap`), post-task 단계에서 자동 실행된다. `qc_verify.py:34-45`의 ALL_CHECKS 목록이 이를 확인해준다. `QC-RULES.md:60-93`에는 Fantasy Approval 방지와 Evidence 필수 조항이 명문화되어 있다. `dispatch.py:242-257`에서 qc_verify를 호출하는 흐름도 확인된다.

**핵심 갭:**

현재 Eval은 "파일이 있나?", "pytest가 통과하나?", "pyright 에러가 있나?" 수준에 머문다. 작업 지시서(task instruction)에 기술된 기능이 실제로 구현되었는지 자동 검증하는 "기능 검증 Eval"이 존재하지 않는다. task-787.1에서 다른 팀의 결과물을 복사하여 "성공"으로 보고한 사례가 발생했음에도 자동 감지가 불가능했다. `critical_gap` verifier도 파일/코드 수준 검증에 그칠 뿐, 작업 지시와 결과물의 의미적 일치 여부를 판단하지 못한다. 결국 "작업 지시의 기능이 실제로 구현되었나?"는 아누가 수동으로 판단해야 한다.

**개선안:**

1. 각 작업 지시서에 "검증 시나리오(acceptance criteria)" 필드를 추가하고, `qc_verify.py`가 해당 시나리오를 자동 실행하는 `functional_eval` verifier를 신설한다.
2. task-787.1류 복사 탐지를 위해 결과물 해시 비교 또는 diff 기반 유사도 검사를 MANDATORY_CHECKS에 추가한다.
3. `scope_check` verifier를 확장하여 task instruction의 요구사항 키워드와 deliverable 파일 내 키워드 매칭을 수행하는 1차 의미론적 검증을 도입한다.

---

### B. 벤치마크/성능 추적

**점수: 2/5 | 개선 필요도: 상**

**현재 상태:**

`task-timer.py:148-158`에서 저장하는 필드는 `start_time`, `end_time`, `duration_seconds`, `status` 수준이다. `dispatch.py:404-411`의 `timer_cmd` 인자에도 토큰 관련 파라미터가 없다. 대시보드(`server.py` + `index.html`)는 실시간 상태를 시각화하지만 히스토리컬 분석 기능은 제공하지 않는다. `pipeline-status.json`은 진행 중 작업의 스냅샷만 보관한다.

**핵심 갭:**

- 토큰 사용량이 전혀 추적되지 않는다. 비용 최적화나 모델별 효율 비교가 불가능하다.
- `task-timers.json`에는 `status`(running/completed/stale)만 기록된다. QC PASS/FAIL 결과가 기록되지 않아 팀별 통과율 산출이 불가능하다.
- 어떤 팀이 어떤 작업 유형(Lv.0~4)에서 효율적인지 데이터 기반으로 판단할 근거가 없다.
- 평균 소요시간(dev1 28.7분, dev2 26.5분, dev3 21.3분) 격차의 원인이 추적되지 않는다.

**개선안:**

1. `task-timer.py`의 저장 스키마에 `qc_result`(PASS/FAIL), `token_input`, `token_output`, `task_level`, `team_id` 필드를 추가한다.
2. `dispatch.py`의 `timer_cmd` 인자를 확장하여 Claude API 응답의 `usage` 객체를 파싱해 기록한다.
3. `server.py`에 히스토리컬 분석 엔드포인트(`/api/metrics/history`, `/api/metrics/team`)를 추가하고, 대시보드에 팀별 통과율/평균 소요시간/토큰 소비 추이 차트를 구성한다.

---

### C. 병렬 실행 격리

**점수: 3.5/5 | 개선 필요도: 중**

**현재 상태:**

봇B/C/D/E가 물리적으로 분리된 인스턴스로 운영되어 팀 간 격리는 구조적으로 확보된다. `worktree_manager.py`가 git worktree 격리를 제공해 코드 충돌을 방지한다. `task-timer.py:90-112`에서 `fcntl.LOCK_EX`를 사용해 `task-timers.json` 동시 쓰기를 보호한다. `DIRECT-WORKFLOW.md:59-66`에 "병렬 Tool 호출 안전 규칙"이 명시되어 있다. `bot-team-mapping.md`에 "같은 봇은 순차 처리"가 명시되어 동일 봇 내 직렬화가 보장된다.

**핵심 갭:**

`dispatch.py:384-402`에서 같은 팀에 이미 running 태스크가 있을 경우 경고(warning)를 출력하지만 차단(blocking)하지는 않는다. 동일 프로젝트를 같은 팀이 동시 작업하면 worktree 충돌이 발생할 수 있는 경로가 닫혀 있지 않다. 파일 락은 메타데이터 파일에만 적용되며 실제 코드베이스 충돌은 worktree 격리에만 의존한다.

**개선안:**

1. `dispatch.py:384-402`의 중복 경고를 soft block으로 격상한다. 동일 팀 + 동일 프로젝트 조합에서 running 태스크가 있으면 확인 프롬프트를 강제한다.
2. `worktree_manager.py`에 프로젝트별 락 레이어를 추가하여 동일 프로젝트에 대한 동시 worktree 생성을 원자적으로 방지한다.
3. stale 전환(2시간 초과) 시 남겨진 worktree를 자동 정리하는 훅을 `cleanup_stale()` 내부에 추가한다.

---

### D. 위임 정확도 (트리거 최적화)

**점수: 2.5/5 | 개선 필요도: 상**

**현재 상태:**

`work-level-system.md:79-88`에 Lv.0~4 판정 기준 질문 5개가 정의되어 있고, 아누가 "수정 위치 명확?", "아키텍처 변경?" 등 질문으로 레벨을 주관적으로 판정한다. `dispatch.py:642-643`에서 Lv.0 작업은 dispatch 불필요 경고를 출력한다. `team_prompts.py:30-73`의 `TEAM_INFO`는 `leader`, `role`, `type`, `members` 필드만 보유하며 팀별 전문 스킬이나 강점 도메인은 기술되지 않는다.

**핵심 갭:**

레벨 판정이 아누의 주관적 판단에 전적으로 의존한다. task-780.1과 task-781.1에서 Instagram 관련 작업이 2회 연속 실패했음에도 같은 팀에 동일 유형 작업이 반복 배정되었다. 팀별 실패 이력 기반 배정 로직이 존재하지 않는다. `TEAM_INFO`에 역량 정보가 없어 적합 팀 선정이 휴리스틱에 의존한다.

**개선안:**

1. `task-timers.json`에 `qc_result`를 기록하기 시작하면(항목 B 개선 전제), `dispatch.py`에 팀별 도메인 성공률 테이블을 구성하고 배정 시 참조하는 `smart_routing` 로직을 추가한다.
2. `team_prompts.py`의 `TEAM_INFO`에 `expertise`(전문 도메인 목록)와 `recent_failures`(최근 실패 태스크 ID) 필드를 추가한다.
3. 레벨 판정 자동화를 위해 task description을 입력으로 받아 키워드 기반 레벨 추천(`Lv.0~4 추천 + 신뢰도 %`)을 출력하는 `level_recommender.py` 유틸을 신설한다.

---

### E. 회귀 감지

**점수: 2/5 | 개선 필요도: 상**

**현재 상태:**

`QC-RULES.md:124-143`에 테스트 회귀 방지 규칙 3종이 명시되어 있다. `qc_verify.py`의 `tdd_check` verifier가 TDD 순서를 검증하고, `test_runner` verifier가 pytest exit code를 확인한다. `task-timer.py:632-688`의 `cleanup_stale()`이 2시간 초과 running 태스크를 stale로 전환하여 비정상 종료를 감지한다.

**핵심 갭:**

현재 회귀 감지는 "개별 작업 내 회귀"에 국한된다. dispatch→실행→보고의 시스템 전체 파이프라인이 이전에는 정상이었다가 갑자기 실패하는 "시스템 수준 회귀"를 감지하는 메커니즘이 없다. stale 전환은 비정상 종료 감지는 하지만 원인 분석을 하지 않는다. CI/CD 파이프라인 연동이 없다. 모델 변경(claude-opus-4-5 → claude-opus-4-6 등)에 따른 자동 회귀 테스트가 없어 모델 업그레이드 시 품질 저하를 즉시 탐지할 수 없다.

**개선안:**

1. `cleanup_stale()` 함수에 stale 원인 분류 로직을 추가한다. 타임아웃인지, 프로세스 크래시인지, API 오류인지를 로그에서 역추적하여 `stale_reason` 필드에 기록한다.
2. 시스템 전체 파이프라인 회귀 감지를 위해 "canary task" 개념을 도입한다. 일정 주기(예: 24시간마다)로 표준 벤치마크 태스크를 실행하고 결과를 과거 기준과 비교하는 `regression_runner.py`를 작성한다.
3. 모델 변경 이벤트 발생 시 `regression_runner.py`를 자동 트리거하는 훅을 `dispatch.py`의 모델 설정 로드 지점에 추가한다.

---

### F. 보고서 품질 검증

**점수: 2/5 | 개선 필요도: 상**

**현재 상태:**

`qc_verify.py:47`에서 `MANDATORY_CHECKS`는 `data_integrity`와 `file_check` 두 개만 지정되어 있다. `file_check`는 파일 존재 여부와 0 bytes 여부만 확인한다. `data_integrity`는 `task-timers.json`과 `.done` 파일의 교차 검증을 수행하지만 보고서 내용은 검토하지 않는다. `QC-RULES.md:86-87`에 Evidence 필수 조항이 있고 SCQA 템플릿이 정량 데이터를 의무화하지만, 내용 검증은 마아트가 critical 이상에서만 수동 수행한다.

**핵심 갭:**

보고서 "내용"이 실제로 수행된 작업을 반영하는지 자동 교차 검증하는 메커니즘이 없다. task-787.1처럼 다른 팀의 결과를 복사한 경우 파일 크기 체크를 통과한다. normal 레벨 작업은 셀프 QC만 수행하며 독립 검증자가 없다. `events/` 디렉토리에 `.done` 파일이 1개밖에 없고 나머지는 `.done.clear`로 아카이브되어 있어 교차 검증 모집단 자체가 축소되어 있다.

**개선안:**

1. `file_check` verifier를 확장하여 보고서 필수 섹션(Situation, Complication, Question, Answer, 정량 데이터 포함 여부)의 존재를 정규식으로 검증하는 `report_structure_check`를 MANDATORY_CHECKS에 추가한다.
2. 결과물 해시를 `task-timers.json`에 기록하고, 동일 해시가 다른 task에 이미 등록된 경우 "복사 의심" 플래그를 자동 발행하는 `duplicate_check` verifier를 신설한다.
3. normal 레벨에서도 무작위 샘플링(예: 20%)으로 마아트 독립 검증을 트리거하는 `random_audit` 메커니즘을 `dispatch.py` 완료 처리 흐름에 추가한다.

---

### G. 워크플로우 효율성

**점수: 3/5 | 개선 필요도: 중**

**현재 상태:**

`DIRECT-WORKFLOW.md`는 147줄에 걸쳐 Step 1~8의 "어떻게(How)"를 상세히 기술한다. `team_prompts.py:118-148`의 `_build_cowork_section`이 약 140줄 분량의 협업 지침을 매 호출마다 프롬프트에 포함시킨다. "팀장(Opus)은 직접 코딩하지 않는다" 원칙, 마이크로태스크 분해 규칙, Context Pressure Hierarchy 등이 명문화되어 있다.

**핵심 갭:**

현재 프롬프트 설계가 "무엇을(What)"보다 "어떻게(How)"에 과도하게 치중한다. `_build_cowork_section` 140줄이 매 태스크마다 토큰으로 소비된다. 759건 완료 기준으로 이 섹션 하나가 소비하는 누적 토큰은 상당하다. 하지만 task-787.1 같은 실패 사례가 반복되는 현 상황에서는 How 기술 축소가 품질 저하 리스크를 수반한다. 모델 성능이 향상될수록 이 제약이 불필요한 오버헤드가 될 가능성이 있다.

**개선안:**

1. Skill→Specification 진화 전략을 단계적으로 적용한다. 우선 항목 A의 기능 검증 Eval이 안정화된 이후, `_build_cowork_section`을 외부 참조 방식(`@cowork-rules.md` 포인터)으로 대체하여 즉각 토큰 절감을 도모한다.
2. 작업 레벨별로 프롬프트 길이를 차등 적용한다. Lv.0~1은 경량 프롬프트, Lv.3~4는 전체 How 프롬프트를 사용하는 `adaptive_prompt` 전략을 `team_prompts.py`에 구현한다.
3. `DIRECT-WORKFLOW.md`의 Step별 준수율을 `qc_verify.py`의 `scope_check`가 측정하도록 확장하여, 어떤 Step에서 실패가 집중되는지 데이터를 수집한 후 불필요한 규칙을 제거한다.

---

## 종합 점수표

| 항목 | 설명 | 점수 | 개선 필요도 |
|------|------|------|------------|
| A | Eval 시스템 (기능 검증 자동화) | 3/5 | 상 |
| B | 벤치마크/성능 추적 | 2/5 | 상 |
| C | 병렬 실행 격리 | 3.5/5 | 중 |
| D | 위임 정확도 (트리거 최적화) | 2.5/5 | 상 |
| E | 회귀 감지 | 2/5 | 상 |
| F | 보고서 품질 검증 | 2/5 | 상 |
| G | 워크플로우 효율성 | 3/5 | 중 |
| **합계** | | **18/35 (51.4%)** | |

**개선 우선순위:** B(토큰/QC결과 추적) → F(보고서 내용 검증) = E(회귀 감지) → A(기능 검증 Eval) → D(위임 정확도) → G(워크플로우 효율성) → C(병렬 격리)

B가 최우선인 이유: B의 개선(QC PASS/FAIL 기록)이 D(실패 이력 기반 배정)와 A(기능 검증 결과 추적)의 선행 조건이기 때문이다.

---

## 블로그 인사이트 중 적용 불가능한 항목

Anthropic "Improving Skill Creator" 블로그의 7대 인사이트 중 우리 시스템 맥락에서 현재 직접 적용이 어려운 항목은 다음과 같다.

**1. 자동화된 Skill 평가 루프 (Automated Skill Evaluation Loop)**

블로그에서는 Skill Creator가 생성한 스킬을 자동으로 실행하고 점수를 매기는 평가 루프를 가정한다. 우리 시스템에서 "스킬"에 해당하는 단위는 task instruction + deliverable이지만, 이 쌍을 정의하고 자동 채점하려면 각 작업 유형별 정답 기준(ground truth)이 필요하다. 현재 759건의 완료 태스크 중 정답 기준이 명시된 태스크는 없다. 이 인사이트를 적용하려면 신규 태스크부터 acceptance criteria를 의무 기재하는 프로세스 변경이 선행되어야 한다.

**2. 모델 자체 스킬 개선 (Model Self-Improvement of Skills)**

블로그 맥락에서는 모델이 자신의 스킬 실패를 분석하여 스킬 정의를 자동 수정한다. 우리 시스템에서 이에 해당하는 것은 `team_prompts.py`의 프롬프트 자동 개선이다. 그러나 현재 프롬프트 변경은 코드 수정(사람이 개입)을 통해서만 이루어지며, 에이전트가 자신의 프롬프트를 수정할 권한이 없다. 이 구조는 의도적 설계(Human-in-the-loop 유지)로, 단기간 내 적용은 바람직하지 않다.

**3. 대규모 병렬 Eval (Large-Scale Parallel Evaluation)**

블로그에서는 수백 개의 Eval을 병렬로 실행하여 빠른 피드백 루프를 형성한다. 우리 시스템은 봇 4개(B/C/D/E)로 물리적 병렬성이 제한된다. 동일 프로젝트 내 병렬 Eval 실행은 항목 C에서 지적한 worktree 충돌 리스크를 수반한다. 인프라 확장 없이는 이 인사이트의 완전한 적용이 어렵다.

---

*본 보고서는 팀장 헤르메스의 분석 데이터를 기반으로 불칸(백엔드 개발자)이 작성하였다. Fantasy Approval 금지 원칙에 따라 문제점 중심으로 서술하였으며, 모든 근거는 파일명:줄번호 수준으로 명시하였다.*