# Codegraph-Anu 정착/폐기 결정 보고서

- **결정일**: 2026-05-08
- **결정**: **트랙 A 정착 유지 / 트랙 B 폐기**
- **근거 보고서**: `codegraph-anu-phase2-poc.md` (1주 KPI 측정 결과)

---

## 결정 요약

| 트랙 | 대상 | 결정 | 사유 |
|---|---|---|---|
| 트랙 A | 자체 AST 스크립트 (`scripts/ast_dependency_map.py` + dispatch.py 통합) | **정착 유지** | timeout 0%, 응답 5초 이내, 단위테스트 6/6 PASS, 회귀 0 |
| 트랙 B | code-review-graph MCP (외부 패키지 + InsuRo 그래프 + dev7 봇 등록) | **폐기** | PoC 1주 동안 dev7-team의 InsuRo+MCP task 0건 → 측정 불가 + `.mcp.json` 셋업 1일 후 다른 봇이 자동 untrack |

---

## 폐기 사유 (트랙 B)

### 1. KPI 미충족

- **토큰 30%+ 절감**: 측정 불가 (Group A: dev7+InsuRo+MCP n=0)
- **회귀 0건**: 트랙 A는 충족, 트랙 B는 사용 자체가 없어 평가 불가
- **daemon 다운 0건**: daemon 미등록 (Phase 3 연기 사항), stdio on-demand serve라 정의 자체 불성립

3 조건 동시 충족 실패.

### 2. 운영 모델 부적합

- **dev7-team의 작업 도메인 = workspace 인프라**, InsuRo 도메인 작업 빈도가 거의 0
  - PoC 기간 dev7-team 주요 task는 task-2388 (dispatch.py 모듈 분리) 등 workspace 인프라
  - InsuRo cwd dev팀 task 80건 중 dev7-team 비중은 1건
- **`.mcp.json`은 다른 봇의 정리 대상**: 2026-05-02 task-2363에서 마르둑 봇이 "작업 외 부산물"로 untrack
  - InsuRo는 공유 프로젝트라 dev7-team 외 봇이 일관성 검사 시 PoC 인프라를 노이즈로 인식
  - PoC 격리(1봇 + 1프로젝트)가 오히려 다른 봇의 정리 압력을 받는 구조
- **봇 자발적 호출 동기 부재**: plan.md 리스크 #2에서 식별된 위험이 그대로 실현됨

### 3. 기술적 인프라는 정상 작동

기술 스택 자체에 결함은 없음:
- code-review-graph 2.3.2 InsuRo 빌드 8초, 27MB (예상치 내)
- FastMCP 2.14.7 정상 부팅
- 그래프 통계 정상 (377 files / 2,986 nodes / 28,984 edges)

→ 폐기 사유는 **운영 모델 부적합**이지 도구의 기술적 결함이 아님. 향후 봇 활동 패턴이 바뀌면 재도입 검토 가능.

---

## 폐기 후 처리 (cleanup TODO)

별도 cleanup task로 처리:

1. **InsuRo 측 정리**:
   - `/home/jay/projects/InsuRo/.code-review-graph/graph.db` (27MB) 삭제
   - `/home/jay/projects/InsuRo/.gitignore`에서 `code-review-graph` 관련 라인 제거 (선택)
   - `.mcp.json`은 이미 task-2363에서 제거됨 (추가 작업 불필요)

2. **시스템 측 정리**:
   - `pipx uninstall code-review-graph` (선택, pipx 패키지는 다른 용도가 없으면 제거)
   - `/home/jay/.cache/anu-ast/` 캐시는 트랙 A가 사용하므로 유지

3. **plan/checklist 갱신**:
   - `memory/plans/codegraph-anu/checklist.md` Step 2.5/2.6 폐기 결정 반영
   - Phase 3/4는 폐기 표기

---

## 트랙 A 유지 근거

| 지표 | 결과 |
|---|---|
| AST timeout 발생률 | 0% (목표 0%) |
| 평균 응답 시간 | cold 5.56s / warm 0.18s (목표 5초 이내) |
| affected_files 자동 보강 | 활성 (dispatch.py:1027, 3147) |
| 단위 테스트 | 6/6 PASS (`tests/test_ast_dependency_map.py`) |
| 회귀 | 0건 |
| 운영 부담 | 디스크 캐시 + 제외 디렉토리 외 추가 운영 없음 |

→ 트랙 A는 KPI 전부 충족. 그대로 유지하며 dispatch 자동 보강 용도로 운영.

---

## 학습 포인트 (다음 PoC 적용 사항)

### 1. 봇 활동 패턴 사전 검증 필수

PoC 설계 시 "1봇 + 1프로젝트"로 줄이기 전에 **그 1봇이 1프로젝트에서 실제로 작업하는 빈도**를 task-timer 통계로 사전 검증.
이번에는 dev7-team의 InsuRo 작업 빈도가 거의 0인데 이를 사전 확인 없이 PoC 대상으로 선정.

### 2. 공유 프로젝트의 PoC 인프라는 보호 메커니즘 필요

InsuRo처럼 여러 봇이 작업하는 공유 프로젝트에서 PoC 부산물을 그대로 두면 다른 봇의 일관성 정리 작업에 휩쓸림.
다음에는 PoC `.mcp.json`/설정 파일에 README/주석으로 PoC 진행 중 + 보호 마커를 명시하거나, dev 봇 글로벌 정책에 PoC 보호 가이드 추가.

### 3. 측정 지표 = 데이터 발생 보장이 아님

KPI를 명확히 정의(30%+ 절감)했지만 데이터 발생을 강제하는 메커니즘이 없었음. 다음 PoC는:
- 셋업 직후 첫 task 위임 시 graph 도구 호출 가이드를 봇 prompt에 주입
- 1주 측정 기간 중간(D+3) 체크포인트에서 데이터 발생 여부 점검
- 데이터 0건 발견 시 즉시 PoC 수정 또는 조기 종료

### 4. 4월 흐지부지 → 5월 측정 불가, 둘 다 같은 본질

4월 실패 = 측정 안 함 + 흐지부지. 5월 = 측정 시도했으나 데이터 발생 0 + 사실상 흐지부지.
교훈: **데이터 발생 자체를 보장하는 셋업 게이트가 측정 지표보다 선행해야 함**.

---

## 다음 단계

- [x] 본 결정 보고서 작성
- [x] Phase 2.5 KPI 측정 보고서 (`codegraph-anu-phase2-poc.md`)
- [ ] cleanup task 위임 (트랙 B 잔존물 정리, dev7-team 또는 inhouse)
- [ ] checklist.md Phase 3/4 폐기 표기 갱신
- [ ] 제이회장님 텔레그램 보고