# task-899.1 완료 보고서: 자동화 오케스트레이터 에이전트 설계
> 팀: dev2-team | 팀장: 오딘 | 작업일: 2026-03-24

---

## SCQA

**S**: 현재 아누(대화형 오케스트레이터)는 제이회장님이 대화를 걸어야만 동작하며, 정해진 흐름(마케팅→개발→QC)도 매 단계 아누가 수동으로 판단·위임해야 한다. chain_manager.py가 단일팀 순차 체이닝을 처리하지만 크로스팀 파이프라인은 여전히 아누의 수동 개입이 필수이다.

**C**: 이로 인해 (1) 마케팅 완료 후 개발 위임까지 아누가 깨어날 때까지 대기 (최악 11시간 사례 있음), (2) 매 체이닝마다 아누 Opus 세션 1개(~8,000 토큰, ~$0.60) 소모, (3) 반복 자동화(ThreadAuto 일일 발행)도 아누 수동 트리거 필요라는 3중 병목이 발생한다.

**Q**: 사전 정의된 크로스팀 파이프라인을 아누 개입 없이 자율 실행하면서, 보안/권한/토큰 제어를 유지할 수 있는 아키텍처는 무엇인가?

**A**: `auto_orch.py` — 30초 주기 systemd timer로 구동되는 파일 기반 상태 기계. YAML 파이프라인 정의를 읽어 기존 chain.py + dispatch.py를 무수정 조합 호출하며, 오케스트레이션 자체는 Claude 세션 0개(토큰 0)로 동작한다. 로키 6대 보안 기준 + 펜리르 P0 4건을 전부 MVP에 포함하여 설계 완료. 에이전트 미팅 4사이클, 4인 만장일치 합의 달성.

---

## 작업 내용

에이전트 미팅 4사이클 진행:
- **사이클 1**: 4인 개별 제안 (오딘 아키텍처, 야누스 인프라, 로키 10대 위험, 펜리르 17 침투 시나리오)
- **사이클 2+3**: 통합 설계 결정 (보안 완화 전부 반영, 아키텍처 확정)
- **사이클 4**: 잔여 불확실성 3건 해소 (토큰 한도, uid 검증, 알림 처리)

### 핵심 설계 결정

- **형태**: 30초 systemd timer + stateless Python tick
- **아누 관계**: 독립 피어 (하위도 대체도 아님)
- **통합**: chain.py + dispatch.py 무수정 subprocess 호출
- **보안**: TeamLock(팀 뮤텍스), gates(승인 파일), DAG 검증, 토큰 한도, 시크릿 스캔, 이벤트 버스
- **토큰**: 오케스트레이션 0 토큰, 일일 한도 1M tokens (~$18/일 max)
- **규모**: 총 ~500 LOC (auto_orch 300 + validator 80 + event_bus 50 + token_ledger 60)

---

## 산출물

| 파일 | 설명 |
|------|------|
| `memory/meetings/task-899.1-automation-agent.md` | 에이전트 미팅 전체 기록 (4사이클) |
| `memory/specs/automation-agent-spec.md` | 최종 설계서 (11개 섹션, YAML 스키마, 디렉토리 구조, 보안 아키텍처, 구현 계획) |
| `memory/reports/task-899.1.md` | 본 보고서 |

---

## 발견 이슈 및 해결

### 자체 해결 (5건)
1. **오딘-야누스 이름 충돌** — auto_orch.py로 통일 (기존 네이밍 컨벤션 일관성)
2. **폴링 간격 이견 (5s vs 30s)** — 30초 채택 (CPU 효율 + 작업 최소 단위 수 분)
3. **chain.py 래퍼 vs 독립 상태 기계** — 래퍼 + 독립 상태 디렉토리 하이브리드
4. **DAILY_HARD_LIMIT 수치** — 1M tokens 산정 (Sonnet 15세션/일 기준 + 안전 여유)
5. **알림 스킵 vs escaping** — shlex.quote() + 폴백 메시지로 항상 발송

### 범위 외 미해결 (2건)
1. **injection_guard.py 하드블록 패치** — 설계만 완료, 실제 코드 수정은 별도 구현 task 필요 (범위 외: 본 task는 설계 전용)
2. **notify-completion.py shell=False 패치** — 동일, 구현 task에서 처리 필요

---

## 셀프 QC 체크리스트

- [x] 1. 다른 파일에 영향: 코드 변경 없음 (설계 문서만 생성). 구현 시 영향 받는 파일은 설계서에 명시
- [x] 2. 엣지 케이스: 로키 10대 위험 + 펜리르 17개 침투 시나리오로 포괄적 엣지 케이스 분석 완료
- [x] 3. 작업 지시 일치: "에이전트 미팅 → 만장일치 합의 → 최종 설계 문서 작성" 지시 정확 이행
- [x] 4. 에러 처리/보안: 보안 아키텍처 5계층(입력 검증/접근 제어/자원 제한/감사/롤백) 설계
- [x] 5. 테스트 커버리지: 코딩 작업 아님 (설계 문서). 구현 Phase에서 테스트 계획 포함
- [x] 6. 이슈 전부 해결: 설계 범위 내 이슈 5건 자체 해결, 코드 수정 2건은 범위 외(구현 task)

---

## 횡단조직 소환 기록

| 에이전트 | 목적 | 소환 시각 |
|----------|------|-----------|
| 로키 (보안팀장) | 보안/권한/충돌 리스크 DA | 2026-03-24 13:58 |
| 야누스 (DevOps센터) | 인프라/데몬/서비스 관점 | 2026-03-24 13:58 |
| 펜리르 (보안팀원) | 침투/악용 시나리오 분석 | (로키 미팅 내 동시 소환) |

---

## QC 자동 검증

본 작업은 설계 전용(Lv.1 문서 작업)이므로 코딩 관련 검증(pyright, pytest, style_check)은 해당 없음. 보고서 파일 존재 + data_integrity 검증만 수행.