# task-119.1 보고서: 아누의 '하기로 한 일을 잊어버리는 문제' 심층 분석

**작성자**: 헤르메스 (개발1팀장)
**작성일**: 2026-03-02
**작업 유형**: 심층 분석 보고서 (코드 수정 없음)

---

## 1. 문제 정의

아누(AI 개발실장)가 대화 중 "이것이 완료되면 저것을 하겠다"고 약속해놓고, 실제 완료 시점에 이행하지 않는 문제.

**구체적 사례**: 아누가 "1팀 완료 후 __pycache__ 정리하고 2팀 위임 진행하겠습니다"라고 발언 → 1팀 완료됨(task-115.1.done 발생) → 아누는 아무것도 안 함 → 제이회장님이 물어봐야 이어서 처리함.

---

## 2. 근본 원인: 5가지 구조적 갭

### 갭 1: 아누의 약속(Promise)이 시스템에 영속화되지 않음
dispatch.py의 `dispatch_result` dict, task-timers.json의 태스크 스키마, event-queue.json의 이벤트 스키마 어디에도 `next_action`, `followup_task`, `on_complete` 같은 필드가 **전혀 없다.** 아누의 약속은 현재 세션의 컨텍스트 윈도우에만 존재하며, 세션 종료 시 100% 소실된다.

### 갭 2: 아누 통보 프롬프트에 후속 액션 맥락이 없음
팀봇 완료 후 아누에게 보내는 cron 프롬프트(`team_prompts.py` 208~209줄)는 "보고서 읽고 보고하라 + .done을 .clear로 rename하라"로 완결된다. "다음에 해야 할 일"을 삽입할 자리가 설계상 없다.

### 갭 3: MEMORY.md가 현재 존재하지 않음
아르고스 검증 결과, `/home/jay/workspace/memory/MEMORY.md`가 삭제/이동된 상태(2026-03-01 CLAUDE.md 개편 시). 세션 간 기억을 담는 핵심 파일이 부재하여 약속 목록을 유지할 물리적 공간 자체가 없다.

### 갭 4: 세션B(통보 세션)는 세션A(약속 세션)와 완전히 독립적
cokacdir --cron --once로 시작되는 아누 통보 세션은 이전 대화 맥락이 전혀 없는 신규 세션이다. 프롬프트에 명시되지 않은 모든 정보는 소멸한다.

### 갭 5: 구두 약속은 시스템에 진입조차 하지 못함
dispatch()를 호출하지 않고 대화 중 구두로만 "나중에 하겠다"고 한 경우, task-timers.json, event-queue.json, 어디에도 기록되지 않는다. 시스템이 인식조차 못한다.

---

## 3. 문제 유형 분류 (5가지)

**유형 1. 세션 간 기억 단절** (가장 빈발)
- 세션A의 약속이 외부 저장소에 미기록 → 세션B에서 소실
- 위험도: 높음

**유형 2. 세션 내 후속 작업 누락**
- 긴 세션 내 초반 약속이 후반에 희석됨
- 위험도: 중간

**유형 3. 조건부 트리거 누락**
- "A 완료 시 B 실행"에서 A 완료는 감지되지만 B 트리거가 없음
- 위험도: 높음

**유형 4. 암묵적 위임 소실**
- 대화 로그에는 약속이 있지만 태스크 시스템에 미등록
- 위험도: 중간

**유형 5. 멀티-스텝 체인 중단**
- A→B→C 체인에서 중간 단계 실패 시 이후 전체 소실
- 위험도: 중간

---

## 4. 해결 방안 분석 (5가지)

### 방안 1: pending-actions 파일 신설
- **개념**: 아누가 약속할 때마다 외부 JSON 파일에 기록
- **수정 범위**: dispatch.py에 `followup_action` 파라미터 추가, 새 JSON 파일 생성
- **복잡도**: 낮
- **장점**: 기존 fcntl 락 패턴 재사용 가능, 구현 간단
- **단점**: 아누가 기록을 "잊으면" 무의미. 메타 자기 인식 요구
- **단독 신뢰도**: 낮음 (다른 방안의 데이터 소스로는 필수)

### 방안 2: cron 통보 프롬프트 강화
- **개념**: 완료 통보 시 pending-actions의 후속 작업을 프롬프트에 자동 삽입
- **수정 범위**: team_prompts.py의 통보 프롬프트 템플릿 수정
- **복잡도**: 낮~중
- **장점**: 세션B 관점에서 가장 자연스러운 해결. 추가 인지 부담 없음
- **단점**: 방안 1 의존성. pending-actions에 기록이 없으면 강화도 없음
- **단독 신뢰도**: 중간

### 방안 3: dispatch 체이닝 (A→B 자동 연쇄)
- **개념**: dispatch 시 on_complete 체인 등록, 완료 시 자동으로 후속 작업 실행
- **수정 범위**: dispatch.py + task-timer.py + event-queue.py 모두 수정
- **복잡도**: 높
- **장점**: 사람의 기억에 의존하지 않는 유일한 방안. "잊어도 실행됨"
- **단점**: dispatch.py ↔ task-timer.py 순환 의존, 무한 루프 위험, 판단 필요 작업에 부적합
- **단독 신뢰도**: 기계적 작업에 한해 높음

### 방안 4: MEMORY.md에 약속 목록 섹션 유지
- **개념**: MEMORY.md의 [COMMITMENTS] 섹션에 미이행 약속 목록 관리
- **수정 범위**: MEMORY.md 복원 + 구조 추가
- **복잡도**: 낮
- **장점**: 인간 가독성 높음, 기존 인프라 활용
- **단점**: 읽었지만 실행하지 않음이 가능. 연결 고리 약함
- **단독 신뢰도**: 낮음

### 방안 5: 세션 시작 hook에서 미이행 약속 자동 경고
- **개념**: 모든 세션 시작 시 pending-actions를 체크하여 미이행 약속 경고 주입
- **수정 범위**: UserPromptSubmit hook 또는 CLAUDE.md에 자동 체크 로직 추가
- **복잡도**: 중
- **장점**: "약속을 안 지키려면 의도적으로 무시해야 함" — 기본값을 이행으로 설정
- **단점**: 방안 1 의존성
- **단독 신뢰도**: 높음 (데이터가 있을 때)

---

## 5. 방안별 비교 및 기각/채택 사유

| 방안 | 사용 편의성 | 실패 가능성 | 습관 형성 | 기각/채택 |
|------|-----------|-----------|---------|---------|
| 1. pending-actions | 낮음 | 매우 높음 | 낮음 | 단독 기각. 데이터 소스로 채택 |
| 2. cron 프롬프트 강화 | 높음 | 중간 | 높음 | **1순위 채택** |
| 3. dispatch 체이닝 | 매우 높음 | 낮음 | 높음 | 중기 과제로 채택 (위험 관리 필요) |
| 4. MEMORY.md 약속 섹션 | 중간 | 높음 | 중간 | 보조 수단으로 채택 |
| 5. 세션 시작 hook | 매우 높음 | 중간 | 매우 높음 | **2순위 채택** |

**기각 사유 상세**:
- 방안 1 단독: "약속을 잊는 주체에게 약속을 기록하라"고 요구하는 자기 참조적 모순
- 방안 4 단독: "읽었지만 행동하지 않음"이 가능한 수동적 구조

---

## 6. 최종 권고: 3계층 방어 구조

### 핵심 원칙
> **아누의 선의에 의존하는 구조는 실패한다. 시스템이 강제하거나 기본값을 이행으로 설정해야 한다.**

### 계층 1 — 예방 (약속 발생 시점)
- **방안 1 + 3 조합**: dispatch() 호출 시 `followup_action` 파라미터로 후속 작업을 pending-actions.json에 기록. 판단 불필요한 기계적 작업은 체이닝으로 자동 실행 예약.

### 계층 2 — 전달 (이벤트 발생 시점)
- **방안 2**: 완료 통보 cron 프롬프트에 pending-actions의 후속 작업을 자동 삽입. 세션B가 "보고 + 후속 작업 처리"를 한 번에 지시받음.

### 계층 3 — 확인 (세션 시작 시점)
- **방안 5 + 4 조합**: 모든 세션 시작 시 hook이 미이행 약속을 체크하여 경고. MEMORY.md의 약속 섹션은 인간 가독성 보조.

### 구현 우선순위
1. **즉시**: 방안 2 (cron 프롬프트 강화) — 코드 변경 최소, 즉각 효과
2. **단기**: 방안 1 + 5 (기록 + hook) — 데이터 구조 설계 + hook 구현
3. **중기**: 방안 3 (체이닝) — 순환 의존성/무한 루프 안전 장치 설계 필요
4. **지속**: 방안 4 (MEMORY.md) — 인간 가독성 보조

---

## 7. 현재 시스템 상태 검증 결과 (아르고스)

- **MEMORY.md**: 존재하지 않음 (2026-03-01 개편 시 삭제/이동). 백업만 존재.
- **task-timers.json**: 좀비 reserved 5건 (task-43.1, 45.1, 75.1, 116.1, 117.1)
- **.done 미처리**: task-118.1.done 1건 미처리
- **cron 프롬프트**: "다음 해야 할 일" 정보 미포함 확인

---

## 8. 생성/수정 파일 목록

| 파일 | 동작 | 변경 사유 |
|------|------|---------|
| teams/dev1/plan-task-119.1.md | 생성 | 작업 계획서 |
| memory/reports/task-119.1.md | 생성 | 최종 분석 보고서 |
| memory/events/task-119.1.done | 생성 | 완료 이벤트 파일 |

---

## 9. 테스트 결과
- 해당 없음 (코드 수정 없는 분석 보고서 작업)

## 10. 버그 유무
- 해당 없음

## 11. 비고
- 아르고스 검증에서 발견된 좀비 reserved 작업 5건과 미처리 .done 1건은 이 task의 범위 밖이나, 별도 정리 작업 권고
- MEMORY.md 부재는 이 문제의 직접적 악화 요인이므로 복원 권고

---

## 12. 셀프 QC

**1. 이 변경이 다른 파일에 영향을 미치는가?**
코드 변경 없음. 보고서와 이벤트 파일만 생성하므로 다른 파일에 영향 없음.

**2. 이 로직의 엣지 케이스는 무엇인가?**
분석 보고서이므로 로직 엣지 케이스 해당 없음. 다만, 권고 방안 구현 시 엣지 케이스로: pending-actions.json이 깨진 경우, 약속 기록 없이 hook만 작동하는 경우, 체이닝 무한 루프 등을 고려해야 함.

**3. 이 구현이 작업 지시와 정확히 일치하는가?**
작업 지시: "코드 수정 없음. 심층 분석 보고서만." → 코드 수정 없이 4개 분석 범위(문제 본질, 기존 메커니즘, 해결 방안, 장단점+실현가능성) 모두 포함. 일치함.

**4. 에러 처리와 보안은 확인했는가?**
코드 수정 없으므로 직접적 에러/보안 이슈 없음. 권고 방안에서 pending-actions.json의 파일 락, 체이닝 깊이 제한 등 보안 고려사항을 명시함.

**5. 테스트가 모든 경로를 커버하는가?**
코드 수정 없으므로 해당 없음. 대신 아르고스가 현재 시스템 상태를 실증 검증하여 분석의 사실 근거를 확보함.

---

## 13. 팀장 검토 결과

- **불칸 (백엔드)**: 1차 검토 통과, 수정 사항 없음. 4개 갭 지점을 코드 라인 단위로 근거 제시. dispatch.py, task-timer.py, event-queue.py의 스키마 필드 부재를 정확히 식별.
- **아테나 (UX/UI)**: 1차 검토 통과, 수정 사항 없음. 5가지 문제 유형 분류와 3계층 방어 구조 제안이 체계적. "아누의 선의에 의존하는 구조는 실패한다"는 핵심 원칙이 명확.
- **아르고스 (테스터)**: 1차 검토 통과, 수정 사항 없음. MEMORY.md 부재, 좀비 작업 5건, 미처리 .done 1건 등 실증 데이터 확보. 분석의 사실 근거 강화에 기여.