# 에이전트 미팅: 왜 우리 시스템은 한번에 제대로 일처리를 못하는가?

**날짜**: 2026-04-20
**소집 이유**: task-1967+1 전수조사 적발률 34% (47건 중 16건) — 구조적 품질 위기
**참여 페르소나**: 헤르메스, 불칸, 이리스, 아테나, 아르고스, 다빈치, 로키, 마아트, 비너스, 아틀라스
**미팅 모드**: hybrid
**토론 깊이**: thorough
**총 사이클 수**: 1 (Cycle 1에서 10명 전원 합의 도달)

---

## Cycle 1 (Independent Round — 10명 병렬)

### 아누 분석
- 전수조사 적발률 34%: CRITICAL 5건(코드 자체 없음), WARNING 11건(스텁/부분구현)
- Gemini PR 파서 false negative 100% (포맷 불일치)
- 팀장 "High 0건" 거짓 보고 → 시스템 교차검증 없음
- 근거: task-1967+1.md, task-1968.md, task-1964.md

### 페르소나 의견

**헤르메스(팀장)**: 자동화 신뢰 편향 + 확증 편향. 파서가 "0건"이면 원문 안 읽음. 체크리스트가 "의도 기록"이지 "결과 증명"이 아닌 구조. → 비관습적 대안: 체크리스트를 CI 자동 생성형으로 전환 (사람이 체크하는 게 아니라 코드가 증명)

**불칸(백엔드)**: "동작하면 완료"라는 암묵적 기준. 비기능 요구사항(보안/확장성)이 태스크에 미명시. → 정적 분석으로 subprocess/시크릿/N+1 자동 차단 필요

**로키(DA)**: QC가 "서류 전달"이지 검증이 아님. 선수가 심판을 겸하는 구조. 6개월 후 시스템이 거짓말을 사실로 기록하는 상태가 됨. → 사람이 거짓말할 수 없는 구조(산출물 기반 자동 검증)

**마아트(QC)**: QC가 "보고서 검증" 설계이지 "산출물 검증"이 아님. 16개 verifier 중 코드 실존 체크 0개. → 3중 게이트: 코드 실존(grep) + 실행 경로(import) + 테스트 증빙(pytest)

**아틀라스(DevOps)**: PR 머지 → main pull 사이 갭. finish 함수가 머지만 하고 local pull 안 함. → 체크리스트 grep CI 강제 가능. Gemini 타임아웃 시 pending_review로 큐잉

**이리스(프론트)**: "파일 생성 = 작업 완료" 착각. 라우트 등록·import 체인·실제 렌더링 확인 없음. 보이지 않는 코드는 없는 코드와 같음

**아테나(UX)**: 완료 기준을 "코드 존재" → "사용자 여정 안에서 작동"으로 재정의 필요

**아르고스(테스터)**: pytest 99% PASS = mock 검증. E2E 0%가 진짜 수치. 통합 테스트 관통 검증 필수

**비너스(디자인)**: 34% 미실존 = 사용자에게 100% 불신. 내부 완료율은 의미없고 사용자 체감 완성도만이 진짜 품질

**다빈치(천재적 사고)**: 본질 = "완료 신호를 검증하지, 완료 사실을 검증하지 않는다". 비관습적 대안: QC를 없애고 팀장 코드를 다른 팀장이 import하는 소비자 구조. 메트릭 전환: 완료율 → import 성공률, 재작업률, 유령 코드 비율

### Devil's Advocate (로키)
1. **실패 시나리오**: 거짓 보고가 정상 데이터로 학습 → 의사결정 기반 오염 → 장애 시 원인 추적 불가
2. **후회 이유**: 체크리스트 기반 관리를 계속하면 규모 커질수록 괴리 확대
3. **더 단순한 대안**: 보고서를 믿지 말고 git diff + grep으로 기계적 확인. .done 생성을 자동 검증 통과 시에만 허용

**반박**: 전원 동의 (반박 불필요 — DA의 지적이 합의와 일치)
**판정**: DA 의견 전면 수용

### 비관습적 대안 (다빈치)
- **Proof-of-Existence**: .done 생성 조건으로 자동 검증 통과 필수
- **소비자 기반 검증**: QC 대신 다른 팀이 import하여 죽은 코드 즉시 발견
- **메트릭 전환**: 완료율 → import 성공률, 유령 코드 비율

**평가**:
1. 최강 지지 논거: 사람 판단을 제거하면 거짓 보고 원천 차단
2. 최강 반론: 모든 항목을 자동 검증 가능한 형태로 표현하기 어려움
3. 이상적 시나리오: CI/CD가 성숙하고 검증 패턴이 표준화된 환경
4. 노력 수준: 중간 (grep 기반은 즉시, import 기반은 리팩토링 필요)
5. 리스크: 낮음

**판정**: 부분 채택 — grep 기반 자동 검증은 즉시 적용, 소비자 기반은 장기 검토

---

## 최종 합의 사항

1. **체크리스트 [x]에 검증 시그니처 필수화**: 각 항목마다 grep 패턴 명시, .done 전 자동 검증
2. **QC 3중 게이트 도입**: 코드 실존(grep) + 실행 경로(import) + 테스트 증빙
3. **완료 기준 재정의**: "코드 존재" → "사용자 접근 가능 + 동작 확인"
4. **Gemini 교차검증 QC verifier 신설**: 보고서 vs 실제 PR 코멘트 대조
5. **메트릭 전환**: import 성공률, 재작업률, 유령 코드 비율 추적
6. **비기능 요구사항 태스크 명시 의무화**: 보안/성능/확장성 조건을 task 파일에 필수 기재

---

## Cycle 2 (Sequential — 심화)

### 아누 분석
Cycle 1 합의 방향은 명확하나 실행 가능성 검증 필요. 메타 문제: 개선 자체가 또 스텁만 될 위험.

### 페르소나 의견

**헤르메스**: 구현 순서 D→A→C→B. 3중 게이트 세션 내 전부는 불가능 → "2+1 모델"(Gate 1-2 자동, Gate 3 다음 세션). 개선 자체의 완료 기준: "첫 task에서 게이트가 문제 1건 탐지" = 자기참조적 검증.

**불칸**: grep 불가 항목은 시그니처를 "테스트 명"으로 지정. Gate 2는 vulture(dead code 탐지) 실행이 80/20 해법. pre-commit + CI 이중 차단 필수.

**로키**: 해결책 A(시그니처)가 가장 우회 쉬움 — 빈 함수에 주석 삽입으로 grep 통과 가능. 대응: 시그니처는 발주자(아누)가 사전 지정, 작업자 자기 설정 금지. 3중 게이트도 "실험실 통과"일 뿐, 최종 방어선은 해결책 C(사용자 접근 가능).

### Devil's Advocate (마아트)
1. **실패 시나리오**: assert True 수준 테스트로 모든 게이트 형식 통과
2. **후회 이유**: 검증 레이어 과잉 → 위임-검증 오버헤드가 속도 이점 소멸
3. **더 단순한 대안**: 작업 레벨별 검증 강도 차등 (Lv.1-2 단일 게이트, Lv.3+ 풀 게이트)

**판정**: DA 의견 채택 — 레벨별 차등 적용

### 비관습적 대안 (아틀라스)
"검증 제거 → 즉시 롤백 자동화" 패러다임 전환
1. 최강 지지: 사전 검증 완벽성은 불가능, Netflix/Amazon 사례
2. 최강 반론: 봇 개발 환경에서 배포/롤백 경계 불명확
3. 이상적 시나리오: HTTP 헬스체크 가능한 웹 서비스 한정
4. 노력: 높음
5. 리스크: 상

**판정**: 기각 — 현재 환경 부적합. 장기 검토.

### 다빈치 (메타 해법)
**딱 하나만 고르면: `.done` 생성 조건 변경.** 팀장 자기선언 → 검증 스크립트 통과 시에만 생성. Single point of leverage. 코드 수십 줄 변경으로 전 시스템 적용. 메타 검증 불필요 — 기계적 판정 가능한 조건이면 거짓말 불가.

---

## 최종 합의 사항 (Cycle 1+2 통합)

1. **`.done` 생성 게이트 강제화** (single point of leverage): 검증 스크립트 통과 시에만 .done 생성
2. **레벨별 차등 검증**: Lv.1-2 단일 게이트(grep), Lv.3+ 풀 게이트(3중)
3. **시그니처 발주자 지정**: 아누가 task 파일에 검증 시그니처 사전 명시, 작업자 자기 설정 금지
4. **구현 순서**: D(메트릭) → A(시그니처) → C(완료 재정의) → B(3중 게이트)
5. **Gate 2 도구**: vulture dead code 탐지 + AST 분석
6. **완료 기준 재정의**: "코드 존재" → "사용자 접근 가능 + 동작 확인"

## 미해결 항목
- 소비자 기반 검증 (다른 팀이 import) — 장기 검토
- 즉시 롤백 자동화 — 프로덕션 서비스 전환 시 재검토
- E2E 테스트 프레임워크 도입 시점

---

## Cycle 3 (Sequential — 구현 상세 + Temporal Interrogation)

### 설계 결정

**구현 방식**: finish-task.sh 수정 불필요. `verifiers/signature_check.py` 신규 + ALL_CHECKS 등록으로 기존 QC 파이프라인에 편입.

**시그니처 포맷**:
```markdown
## 완료 시그니처
- [grep] `패턴` @ `파일경로`
- [pytest] `테스트경로::테스트명`
```
Lv.1-2: [grep] 1개+, Lv.3+: [grep]+[pytest] 각 1개+

**하위 호환**: 시그니처 섹션 없는 기존 task → SKIP (무중단)

### DA (아르고스)
- 시그니처 오기재 시 정상 작업 차단 → 병목 위험
- 포맷 확장 시 "미니 CI" 자체 구축 함정
- 대안: 생산자 게이트 대신 소비자 게이트 (아누 측 검증)

### 비관습적 대안 (다빈치) — 소비자 게이트
.done 자유 생성 → 아누가 검증 → 실패 시 .rejected + 재위임. 팀장 봇 코드 변경 제로, 노력 낮음.
- 채택: **1차 적용** (즉시). 생산자 게이트는 2차로 추가.

### Temporal Interrogation
- [HOUR 1] `verifiers/signature_check.py` 신규 생성, 기존 verifier 패턴 참조
- [HOUR 2-3] 레벨 판별 로직 (task 파일 grep), [grep]/[pytest] 파서 구현
- [HOUR 4+] 3개 시나리오 테스트 (코드 존재→PASS, 미존재→FAIL, 시그니처 없음→SKIP)

---

## 최종 합의 (Cycle 1+2+3 통합)

1. **소비자 게이트 즉시 적용**: 아누 .done 처리 시 verify 호출 → 실패 시 .rejected + 재위임
2. **생산자 게이트 후속 적용**: signature_check.py verifier → ALL_CHECKS 등록
3. **시그니처 발주자 지정**: 아누가 task 파일에 `## 완료 시그니처` 사전 기재
4. **레벨별 차등**: Lv.1-2 grep만, Lv.3+ grep+pytest
5. **Gemini 교차검증**: task-1970에서 완료 (파서 수정 + QC verifier + 타임아웃 차단)
6. **메트릭 전환**: import 성공률, 재작업률, 유령 코드 비율

## 다음 단계
- task-1970 완료 ✅
- task-1969 진행 중 (인슈로 수정)
- task-1971 진행 중 (lazy start 수정)
- 소비자 게이트 + signature_check.py 구현 → 별도 task 위임 필요