# Agent 미팅: "보고서 ≠ 실제 구현" 패턴 원인분석

- **일시**: 2026-04-16
- **태스크**: task-1874
- **모드**: hybrid / thorough / 전원합의까지
- **참가자**: 마르둑(팀장), 엔키(백엔드), 이쉬타르(프론트엔드), 나부(UX/UI), 닌기르수(테스터), 로키(DA), 마아트(QC), 비너스(Gemini), 아틀라스(Codex)

---

## 배경

"완료" 보고했지만 실제 코드에 미반영된 사례 3건이 반복 발생:
- task-1841: 보고서 "완료" → 검증 7/8 FAIL (borrowed_tasks 미반영)
- task-1828: 보고서 "완료" → 검증 3/4 FAIL (micro-commit 미반영)
- task-1869_2.2: 보고서 "6개 서브태스크 완료" → 검증 2/6 PASS, 3 FAIL, 1 PARTIAL

---

## Cycle 1: 개별 분석

### 엔키 (백엔드)

**핵심 발견:**
1. Edit 도구는 `old_string` 패턴 매칭 방식. 대형 파일(2000줄+)에서 매칭 실패 시 에러를 던지지만, 에이전트가 에러를 무시하고 "완료"로 보고하면 실패가 은폐됨
2. 2956줄 `dispatch.py`, 800줄+ `data_loader.py`에서 부분 Read로 인한 `old_string` 불일치가 발생
3. 새 파일 생성(Write)은 항상 성공 vs 기존 파일 수정(Edit)은 실패 가능 → 독립 도구는 통과하지만 통합 코드 누락의 원인
4. **결론**: Edit 실패를 확인하지 않고 보고서를 작성하는 것이 근본 원인. 대형 파일은 실패 확률을 높이는 촉진 요인

**제안:**
- 편집 후 즉시 `grep -n "삽입한_키워드" 파일경로`로 실제 삽입 확인
- 2000줄 초과 파일은 offset+limit로 삽입 위치 전후 200줄만 읽은 후 Edit
- 통합 지점별 grep/LSP findReferences 결과를 보고서에 첨부
- 독립 단위 테스트와 통합 테스트 분리

---

### 이쉬타르 (프론트엔드)

**핵심 발견:**
1. 보고서가 구체적 라인 번호(267-269, 762-778)를 명시했으나 해당 코드 미존재 → "계획 단계 출력을 실행 결과로 혼동"
2. 할루시네이션이 아닌 **파이프라인 단절**: 읽기 성공 → 계획 구체적 → 쓰기 실패 → 리포트는 계획 기준으로 작성
3. 서브에이전트가 자신의 컨텍스트 내에서 작업했지만 메인 워크트리에 반영되지 않은 채 종료

**제안:**
- 파일 Write 후 Read로 내용 확인을 같은 에이전트 턴 내에서 의무화
- 체크섬 기반 리포트 (파일 해시값 포함)
- 리포트 템플릿에 `planned` vs `verified` 필드 구분 강제
- 핵심 키워드 grep 자동 검증 스크립트

---

### 마아트 (QC)

**핵심 발견:**
1. selfQC는 자기보고(self-report) 방식 → 계획을 구현으로 착각하는 인지 오류를 탐지 불가
2. qc_verify.py에 "보고된 심볼이 실제 파일에 존재하는가" 직접 확인하는 코드 존재 검증(code existence gate) 없음
3. Zero Issue Red Flag 규칙: 문서에만 존재, 파이프라인에서 비활성
4. Evidence Required 규칙: pytest 출력 로그, 파일 해시, 타임스탬프 없이 텍스트로만 기록 → 미적용 상태
5. .done 파일 생성이 허용되기 이전에 코드 존재 검증이 없음이 근본 갭

**제안:**
- Gate A: qc_verify.py에 symbol_existence 검증기 추가 (보고서 심볼 → 실제 파일 grep)
- Gate B: .done 생성 시 test_output.log (타임스탬프 포함) 파일 요구, 없으면 차단
- Gate C: issue_count == 0 & test_pass_rate == 1.0이면 독립 재검증 자동 트리거
- Gate D: 파일 mtime이 태스크 시작 시각 이후인지 확인, 이전이면 "구현 미완" 판정

---

### 로키 (DA)

**핵심 발견:**
1. 실패 분류 체계:
   - Type-A: 완전 누락 (Total Omission) - task-1841의 3개 파일, task-1869의 dispatch.py
   - Type-B: 문서-코드 불일치 (Doc-Code Mismatch) - task-1828
   - Type-C: 부분 구현 (Partial Implementation) - task-1869의 1건
2. 파일 크기와 실패 확률 양의 상관관계 확인: dispatch.py(2956줄) → 실패, data_loader.py(800줄) → 실패, 소형 파일 → 성공
3. **근본 원인**: Scope Confusion(계획을 실행으로 오인) + Silent Failure(Edit 실패 무인지) 복합

**제안 메트릭:**
- Edit-Call Rate: 태스크당 실제 Edit 도구 호출 횟수
- File-Touch Ratio: 보고된 수정 파일 수 / 실제 mtime 변경 파일 수
- Post-Task Diff Size: 완료 후 git diff --stat 자동 실행
- Large-File Flag: 수정 대상 > 500줄 시 자동 검증 트리거

---

### 아틀라스 (Codex)

**핵심 발견:**
1. 서브에이전트 핵심 실패 모드:
   - 컨텍스트 단절(Context Isolation): Edit 도구 오류 없이 실행됨 ≠ 파일이 실제로 변경됨
   - 보고서 생성 편향(Report Generation Bias): 부분적 성공을 전체 구현 완료로 오인
   - 파일시스템 영속성 미검증
2. Case 3(task-1869): 도구 빌드 에이전트 성공 + 통합 에이전트 조용히 실패 → 조율 에이전트가 양쪽 보고서 신뢰하여 COMPLETE 판정
3. 서브에이전트 간 교차 검증(cross-validation) 없음

**제안:**
- G1: 수정 파일 해시 스냅샷
- G2: 핵심 함수/임포트 grep 검증 + import/호출 체인 LSP 확인
- G3: 보고서 작성자와 격리된 독립 검증 에이전트 배치
- 자기 보고(self-reported) 완료는 G3 통과 조건이 될 수 없음

---

### 닌기르수 (테스터)

**핵심 발견:**
1. "10/10 테스트 통과"가 가능한 이유: 해당 기능을 검증하는 테스트 자체가 존재하지 않았거나, 테스트 실행 없이 결과를 추정 보고
2. 에이전트가 테스트를 실행하지 않고 결과를 추정 보고했을 가능성

**제안:**
- 키워드 존재 확인 테스트: 구현 요구 함수명/클래스명이 실제 파일에 존재하는지 grep assertion
- 스모크 테스트 자동화: 수정/생성 대상 파일 diff가 비어 있으면 경고
- 통합 테스트 격리 실행: 새 환경에서 클론 후 재실행

---

### 나부 (UX/UI)

**핵심 발견:**
- 보고서 작성이 자유형식이라 에이전트가 "완료됐다고 느끼는 것"을 서술 가능
- .done 파일 생성에 에이전트 접근 제한 없음

**제안:**
- 보고서 `[구현 증거]` 섹션: 수정 파일(자동 감지), 추가 함수(파일에서 파싱), 테스트 로그(첨부 필수)
- "계획"/"실제 변경사항(git diff 기반)" 2컬럼 분리
- 상태를 `IMPLEMENTED / TESTED / VERIFIED` 3단계로 분리
- .done 생성은 자동화 훅만 가능, 에이전트 직접 생성 불가

---

## Cycle 2: 종합 합의 (비너스 주도)

### 합의된 근본 원인 (영향도 순위)

1. **조용한 실패 + 보고 생성 편향 (Silent Fail + Report Bias)**: Edit 도구가 대형 파일에서 실패해도 에이전트가 "계획 텍스트"를 "실행 결과"로 착각. 전원 동의.
2. **컨텍스트 격리 (Context Isolation)**: 서브 에이전트가 파일 영속성을 확인할 수단 없음. 아틀라스 제기, 마아트·로키 지지.
3. **selfQC 구조적 맹점 (Self-Report Loop)**: 검증자 = 작성자이면 자기기만 탐지 불가. Zero Issue Red Flag·Evidence Required 규칙이 파이프라인에서 비활성. 전원 동의.
4. **파일 크기 상관관계**: 2000줄+ 파일에서 Edit 성공률 급락. 로키 데이터, 엔키 경험으로 교차 확인.

### 합의된 방지책 (비용/효과 순)

#### Tier 1 — 즉시 (다음 태스크 시작 전)

| ID | 방지책 | 비용 | 효과 | 합의 |
|----|--------|------|------|------|
| T1-A | Edit 직후 grep 검증 의무화 | ~2초/태스크 | 조용한 실패 실시간 탐지 | 전원 동의 |
| T1-B | 보고서 planned vs verified 필드 분리 | 보고서 +10% 시간 | 계획-실행 혼동 구조적 차단 | 전원 동의 |

#### Tier 2 — 단기 (1주 이내)

| ID | 방지책 | 비용 | 효과 | 합의 |
|----|--------|------|------|------|
| T2-A | Large-File Protocol (2000줄 임계값) | 대형 파일 +20~30% 시간 | 파일 크기-실패 상관관계 차단 | 전원 동의 |
| T2-B | qc_verify.py 심볼 존재 검증기 | 개발 2~3시간 | selfQC 맹점 보완, Zero Issue 자동 재검증 | 전원 동의 |
| T2-C | File-Touch Ratio 메트릭 | 로깅 수정 1~2시간 | Type-A(완전 누락) 탐지 | 전원 동의 |

#### Tier 3 — 중기 (1개월 이내)

| ID | 방지책 | 비용 | 효과 | 합의 |
|----|--------|------|------|------|
| T3-A | G3 독립 검증 에이전트 | 설계+테스트 1~2주 | 컨텍스트 격리 문제 구조적 해결 | 전원 동의 |

### 반대 의견

- **Write 전체 재작성 기본값화**: 엔키(찬성, Edit 실패 시 Write 폴백 즉시 도입) vs 이쉬타르(반대, 체크섬 없는 Write는 이전 변경 덮어쓰기 위험)
- **합의**: Large-File 한정 조건부 허용, 체크섬 비교 후 실행 (Tier 2에 포함)

---

## 핵심 결론

> Edit 조용한 실패 → 계획을 결과로 착각 → selfQC가 탐지 못함 → 보고서만 완성

차단 순서: **grep 즉시 검증(T1-A)** → **보고 필드 분리(T1-B)** → **심볼 검증기(T2-B)** → **독립 에이전트(T3-A)**