# 보고 누락 방지 체계 Agent Meeting 기록
> 날짜: 2026-04-12 | 작업: task-1733.1 | 팀: dev5-team (마르둑 팀장)
> 참가자: 토르(백엔드), 불칸(에러핸들링), 야누스(DevOps), 로키(레드팀), 다빈치(GLM), 비너스(디자인), 아틀라스(QC)
> 모델: Claude소속(토르/불칸/야누스/로키)=Opus지시·Sonnet실행, 비클로드(다빈치/비너스/아틀라스)=Sonnet

---

## Cycle 1 결과 (선행 미팅에서 도출, 본 미팅의 입력)

### 19가지 경우의 수
- A. 생산 실패: #1 context limit, #2 QC gate차단, #3 worktree경로오류, #4 디스크풀
- B. 감지 실패: #5 아누세션부재, #6 compact시유실, #7 대량.done동시도착, #8 watcher충돌
- C. 전달 실패: #9 Telegram rate limit, #10 4096자잘림, #11 silent failure
- D. 인식 실패: #12 정보과부하, #13 긴급/루틴미구분, #14 보고/확인추적없음

### 근본 원인 3가지
1. Polling 의존 — 아누 비활성 시 감지 불가
2. ACK 없음 — fire-and-forget
3. 상태 추적 부재 — .done→.done.clear만

---

## Cycle 2: 복합 시나리오 (14개, #20~#33)

### #20: 묵음 디스크 폭풍 (#4+#11+#3)
디스크풀 + silent failure + worktree경로오류 → 흔적 없는 완전 누락. postmortem 불가. [중간]

### #21: QC 데드락 루프 (#2+#1+#8)
QC차단 + context종료 + watcher충돌 → 상태머신 오염, 잘못된 "정상완료" 보고 가능. [중간]

### #22: 지수 백오프 블랙홀 (#9+#5+#6)
rate limit + 아누부재 + compact유실 → 모든 레이어가 "성공"으로 오판. 재시도 트리거 없음. [높음]

### #23: 서킷브레이커 과잉 억제 (#7+CB+#9)
대량.done + 서킷브레이커 발동 + rate limit → 30분 보고 블라인드 스팟. 보호 메커니즘이 장애 확대. [중간]

### #24: worktree 좀비 + 아카이브 경쟁 (#3+archive+#8)
잘못된 경로 + 24h아카이브 충돌 → 파일 "증발". 추적 불가. [낮음]

### #25: 재위임 무한 루프 (#1+재위임+#2)
context종료 + watchdog재위임 + QC미해소 → 무한 반복 시도. context 비용 소모, "자동 복구 중" 오인식. [중간]

### #26: 에스컬레이션 블랙홀 (#11+escalated+#13)
silent failure + escalated전환 + 긴급/루틴미구분 → 최후 안전망(에스컬레이션) 자체가 노이즈에 묻힘. [높음]

### #27: ACK 스푸핑 상태 오염 (#8+#14+#11)
watcher충돌 + 추적없음 + silent failure → .done.notified가 위조된 확인 상태. 사후 감사에서도 "정상"으로 오진단. [중간]

### #28: 메시지 이중 배달 (#7+#10+#12)
대량.done + 4096잘림 + 정보과부하 → 잘린 보고가 "완전한 보고"로 취급. 메시지 무결성 검증 없음. [높음]

### #29: 재전송 폭풍 → 자기 DDoS (#9+#7+#5)
아누부재 후 복귀 시 밀린 .done 폭격 → thundering herd 패턴. 양성 피드백 루프. [중간]

### #30: 인지과부하 + 긴급신호 소멸 (#12+#13+#14)
대량루틴 + 미구분 + 미추적 → 기술 정상이나 인지 실패. 가장 탐지 어려운 유형. [높음]

### #31: 상태불일치 → 신뢰 붕괴 (#11+#14+#13)
silent failure 반복 → 시스템 신뢰 파괴 → 수동확인 증가 → 운영문화 장애. [높음]

### #32: 측정불가 → 개선불가 루프 (#14+#11+#6)
추적없음 + silent failure + compact유실 → 메타 장애. 75개 시나리오 발생 빈도 자체를 측정 불가. [높음]

### #33: false positive 에스컬레이션 피로 (#8+stale+#12)
watcher충돌 → stale 오판 → 반복 에스컬레이션 → "늑대가 온다" 효과. alarm precision 0 수렴. [중간]

**핵심 발견:** #14(추적 없음)가 가장 많은 복합 시나리오의 공통 촉매.

---

## Cycle 3: 프로세스/절차 관점 (14개, #40~#53)

### #40: 파견 후 수신 ACK 블랙홀
디스패치→첫하트비트 구간에 수신 확인 없음. 봇이 태스크를 못 받았어도 10분 stale까지 미감지. [높음]

### #41: .done과 보고서 내용 원자성 불일치
.done 존재 ≠ 보고서 완성. 부분완료 + .done생성 → 불완전 보고 전달. [높음]

### #42: 진전 없는 하트비트 감지 불가 (Silent Progress Failure)
하트비트만 보내고 실질 진전 없는 루프. watchdog은 "정상"으로 판단. "진전 검증" 단계 부재. [높음]

### #43: 에스컬레이션 후 핸드오프 프로토콜 부재
.done.escalated 감지 후 아누 행동 지침(runbook) 없음. 중복 전송/미처리 위험. [중간]

### #44: 아누 감지→읽기→전송 구간 블랙박스
아누의 내부 처리 과정에 상태 기록 없음. compact 시 "아직 읽어야 함" 컨텍스트 유실. [높음]

### #45: 다중 완료 동시 도착 시 우선순위 정책 없음
done-watcher가 파일시스템 순서로 처리. 긴급 보고서가 루틴 뒤로 밀릴 수 있음. [중간]

### #46: 보고서-요구사항 불일치 검증 부재
봇의 "완료" 주장 vs 실제 태스크 요구사항 비교 없음. 불완전 완료가 연쇄 실패 유발. [높음]

### #47: 제이의 ACK 부재 (단방향 통신)
아누→제이만 존재. 제이→아누 확인 없음. 전송 성공 ≠ 제이 인식. [높음]

### #48: 태스크 디스패치 레코드 영속성 부재
아누 compact 시 "어떤 봇에 뭘 할당했는지" 기억 상실. .done↔태스크 맵핑 불가. [높음]

### #49: 재시도 폭풍과 중복 보고 위험
notify + done-watcher + 수동개입이 동시 트리거 → 제이에게 동일 보고 3회 전송. [중간]

### #50: 아누의 동시 다중 역할 인지 과부하
디스패처+모니터+리더+전달자 역할 전환 비용. 새 알림에 반응하며 읽던 보고서 중단. [중간]

### #51: 보고서 포맷 불일치
봇마다 보고 형식 상이. 표준화 변환 단계 없음. [중간]

### #52: 종단간(E2E) 측정 부재
디스패치→수신ACK→하트비트→완료→감지→전달→확인 각 구간 타임스탬프 없음. 병목 식별 불가. [높음]

### #53: 보고 품질 등급 체계 부재
개별 보고서 완성도 점수 없음. 80% 완성 보고서 반복 제출 시 누적 저하 미감지. [중간]

**핵심 프로세스 갭 3가지:**
1. 양방향 ACK 프로토콜 전면 부재 (#40, #47)
2. 아누 내부 처리가 완전한 블랙박스 (#44, #50)
3. 태스크 정체성(identity) 추적 부재 (#48, #46)

---

## Cycle 4: 장기 운영 관점 (14개, #60~#73)

### #60: task-timers.json 무한 증가 → 파싱 붕괴 [치명]
6개월 후 수천 항목. JSON read-modify-write 패턴의 I/O 선형 증가. 디스크풀 시 JSON 중간 잘림 → 전체 파싱 실패 → 타이머 에스컬레이션 전면 무력화.

### #61: .done 상태 파일 좀비 고착 [높음]
3개월 후 중간 상태(.done.processing, .done.escalated) 영구 고착 파일 수십~수백 개. CPU 낭비 + 수동 복구 불가.

### #62: CircuitBreaker 영구 개방 [높음]
상태가 메모리에만 존재. 재시작 시 초기화되어 보호 효과 무력화. 또는 파일 기반 시 잘못된 파일 잔존으로 영구 OPEN.

### #63: 재시도 폭풍 & 신뢰 붕괴 [높음]
1년 후 중복 알림 일상화 → 운영자가 "또 중복이겠지" → 실제 에스컬레이션도 무시.

### #64: systemd Timer Drift & Silent Death [치명]
NTP 동기화/절전 복귀 시 타이머 오차. OOM killer 시 재시작 안 되는 케이스. "active" 표시지만 실제 프로세스 사망.

### #65: 3자 Configuration Drift [높음]
.env.keys, systemd unit, 스크립트 하드코딩 3곳 버전 불일치. 간헐적 실패, 재현 불가.

### #66: 아카이브 레이스 & inode 고갈 [높음]
mv 중 순간 파일 부존재 → 오판. archive/ 수만 파일 → inode 고갈(df -h로 미탐지).

### #67: Token Rotation 메타 장애 [치명]
토큰 갱신 절차 부재. 갱신 창에서 알림 실패. 만료 토큰 시 자기 장애를 자기 보고 불가(메타 장애).

### #68: 이벤트 큐 엔트로피 붕괴 [치명]
memory/events/ 파일 무한 축적. ext4 수십만 파일 시 glob() 수초. done-watcher 30초 루프 완료 불가 → 사실상 정지.

### #69: 하트비트 팬텀 파일 [중간]
세션 비정상 종료 후 좀비 하트비트. ID 재사용 시 활성 세션이 stale로 오판.

### #70: 알림 피로 & 신호 소멸 [높음]
3~6개월 후 "읽지 않고 닫기" 패턴 형성. 인지적 투명화. 시스템 정상이나 인간이 안 읽음.

### #71: 보고 이력 인지 불가 [중간]
1년 후 수천 파일, 불일관 명명, 감사 시 특정 시점 상태 재구성 불가.

### #72: 메트릭 기준선 부재 (Boiling Frog) [높음]
서서히 저하(98%→94%→87%→71%)되는데 추세 계산 프로세스 없음. 경보 없이 죽어감.

### #73: 로그 순환 부재 자기강화 루프 [높음]
1년 후 100MB+ 로그. 장애 진단 시 I/O 부하 → done-watcher 지연 → 진단 행위가 장애 악화.

---

## Cycle 5: 사용자 행동 패턴 (14개, #80~#93)

### #80: 배치 소비자 vs 실시간 스트림 불일치
Jay는 09/18시 배치 확인. 시스템은 즉시 push. 시간적으로 앞선 보고일수록 누락 확률 높음.

### #81: 세션 경계 부재 (read cursor 없음)
Telegram에 "어디까지 읽었는지" 커서 없음. offset 없는 sequential scan 반복.

### #82: ACK 루프 부재 (전달≠인식)
Telegram 200 OK = network ACK. Application-level ACK 없음. fire-and-forget.

### #83: 과부하 시 역전 (긴급 상황에 신호 손실)
긴급 상황일수록 메시지 폭증 → Jay 주의 분산 → 가장 중요한 메시지가 가장 쉽게 누락. alarm storm 패턴.

### #84: 관찰 불가능성 (일일 상태 집계 불가)
"오늘 완료된 작업 목록" = Telegram 수동 스크롤. 대시보드/digest 없음.

### #85: 알림 피로 (우선순위 없는 단일 채널)
P1/P2/P3 구분 없음. quiet hours 없음. 주말도 평일 동일.

### #86: 신호 매몰 공격 (노이즈로 중요 신호 덮기)
긴급 보고 직전 10개 루틴 → 스크롤 피로. 사회공학 DDoS.

### #87: 단일 채널 SPOF (Telegram 의존)
Telegram 무음 설정, 앱 알림 off, 다른 채팅에 밀림 → 전체 보고 시스템 무효화.

### #88: Pull vs Push 역전 (Jay는 Pull 소비자)
Jay는 능동적 pull. 시스템은 push only. "오늘 요약", "긴급만" pull 불가.

### #89: 메시지 비구조화 (필터링·집계 불가)
SCQA = schema-less 텍스트 블랍. "이번 주 발견 버그만" 추출 불가.

### #90: 시각적 위계 부재 (긴급/루틴 동일 표시)
모든 보고가 동일 텍스트 블록. 모바일 F-pattern 스캔에 최악.

### #91: 액션 아이템 매몰 (CTA 본문 묻힘)
결정/승인 요구가 400자 중간에 숨김. Jay 미인식 → 작업 방치 또는 아누 임의 결정.

### #92: 측정 불가 (소비율·읽음 추적 없음)
Jay가 몇 개 읽었는지, 평균 응답 시간, 무시 패턴 — 아무것도 측정 안 됨.

### #93: 누적 품질 저하 (무시 패턴 감지 불가)
초기에는 전부 읽다가 서서히 무시. 인지과학적 필연. 감지 프로세스 없음.

---

## Cycle 6: 분류 및 방어 메커니즘 설계

### 75개 시나리오 → 6개 범주 분류

| 범주 | 근본 원인 | 시나리오 수 |
|------|-----------|------------|
| A: 원자성 붕괴 | .done/보고서/상태전환 비원자적 | 13개 |
| B: 감지 신뢰성 붕괴 | Polling 의존, 파이프라인 불투명 | 15개 |
| C: 전달 보장 부재 | 단일 채널, ACK 없는 단방향 | 12개 |
| D: 상태 추적 부재 | 이벤트 소싱 없음, 영속 저장소 없음 | 13개 |
| E: 인지 과부하 & 신호 소멸 | 우선순위 없는 단일 채널, 비구조화 메시지 | 15개 |
| F: 메타 시스템 저하 | 자기 모니터링 부재 | 7개 |

### 6개 방어 메커니즘

**DM-A: 트랜잭션 완료 레지스트리 (TCR)** — 13개 시나리오 방어
- task-registry.json WAL 방식, .done에 report_hash 필수 포함
- task-timers.json 30일 TTL + 10MB rotation
- 노력: 단기 1-2주

**DM-B: 이벤트 소싱 파이프라인 (ESP)** — 15개 시나리오 방어
- inotifywait 기반 push 감지, event-queue.db (SQLite) ordered queue
- CircuitBreaker SQLite 저장, 500ms batch window 우선순위 정렬
- 노력: 단기 1-2주, DM-A 의존

**DM-C: 다중 채널 전달 + ACK 루프 (MDA)** — 12개 시나리오 방어
- Primary Telegram → Fallback 로컬큐 → Fallback2 이메일
- /ack {task_id} 명령, idempotency key, 4096자 자동분할
- 노력: 단기 1-2주, DM-A+B 의존

**DM-D: 영속적 상태 원장 (PSL)** — 13개 시나리오 방어
- report-ledger.db: tasks/reports/deliveries/sessions 테이블
- Jay read cursor, ACK 추적, E2E 지연 측정, 이벤트 소싱(immutable append-only)
- 노력: 중기 1-2개월, DM-A~C 의존

**DM-E: 구조화 알림 + 인지 필터 (SNF)** — 15개 시나리오 방어
- 3단계 우선순위(🔴CRITICAL/🟡NORMAL/⚪INFO), CTA 명시, /summary pull 지원
- INFO digest로 노이즈 억제, 보고서 완결성 점수 자동 산출
- 노력: 즉시 1-2일

**DM-F: 자기 진단 대시보드 (SDD)** — 7개 시나리오 방어
- metrics.db 5분 집계, 첫 2주 기준선 자동설정, 2σ 이탈 시 CRITICAL
- 일별 health report, 로그 rotation 7일+30일압축
- 노력: 중기 1-2개월, DM-A~E 의존

---

## Cycle 7: 우선순위 및 아키텍처 합의

### 구현 로드맵

| 기간 | 방어 메커니즘 | 비고 |
|------|-------------|------|
| Week 1-2 | DM-E (SNF) | 즉시 구현, 인지 개선 효과 즉각적 |
| Week 3-4 | DM-A (TCR) | 원자성 기반 확보 |
| Week 5-6 | DM-B (ESP) | 감지 신뢰성 (DM-A 이후) |
| Week 7-8 | DM-C (MDA) | 전달 보장 (DM-B 이후) |
| Month 2-3 | DM-D (PSL) | 상태 통합 (DM-A~C 이후) |
| Month 3-4 | DM-F (SDD) | 자기진단 완성 (전체 이후) |

### 최종 5계층 아키텍처

- **Layer 0 (Prevention):** TCR 원자적 완료 — 실패를 불가능하게
- **Layer 1 (Detection):** ESP inotify 즉시 감지 — 수초 내 감지
- **Layer 2 (Recovery):** MDA 다중채널 + PSL 상태 — 자동 복구
- **Layer 3 (Escalation):** CRITICAL 전용 채널 + 핸드오프 프로토콜 — 인간 개입
- **Layer 4 (Audit):** SDD 지속 감시 + 일별 health report — 증명 및 개선

### 합의 결과

전원 합의 (6 동의 + 1 조건부 동의)
- 토르: ✓ 기술적 구현 가능성 확인
- 불칸: ✓ (조건: PSL SERIALIZABLE 격리수준)
- 야누스: ✓ (조건: metrics.db 월별 archiving)
- 로키: △ (조건: SQLite백업, ACK보강, rate limit → 백로그 등록)
- 다빈치: ✓ PSL immutable append-only 설계 강력 동의
- 비너스: ✓ (조건: 메시지 템플릿 2주 A/B 테스트 반복 개선)
- 아틀라스: ✓ (조건: 보고 누락 제로 SLA + 위반 시 자동 포스트모템)

---

## 부록: 백로그 조건 항목 (1차 구현 후 즉시 착수)

1. PSL DB 격리수준 SERIALIZABLE 적용 (불칸)
2. metrics.db 월별 archiving 정책 (야누스)
3. SQLite WAL 모드 + 정기 백업 (로키)
4. /ack 명령 challenge-response 보강 (로키)
5. 발신 에이전트별 rate limit (로키)
6. 메시지 템플릿 2주 반복 A/B 테스트 프로세스 (비너스)
7. 보고 누락 제로(0건) SLA 설정 (아틀라스)
8. SLA 위반 시 자동 포스트모템 트리거 (아틀라스)
9. 75개 시나리오 트레이서빌리티 매트릭스 문서화 (아틀라스)