# task-1285.1 미팅 Cycle 5
날짜: 2026-03-31
안건: P3/P4 항목 재분류 + 심층 논의 (P4 항목 6/8/9/10 구현 방법, 의존성, ROI, 위험 요소)

## 참석자 발언

### 헤르메스 (백엔드/인프라)

**1. P3 슬롯 활용 — P4에서 상향 후보:**

현재 P3이 비어있으니 P4 항목 중 상향할 만한 것이 있는지 기술적 관점에서 평가합니다.

| 항목 | 기술적 성숙도 | P1/P2 의존성 | P3 상향 추천 |
|---|---|---|---|
| (6) @MX 태그 | 낮음 (파서/강제 메커니즘 부재) | hooks(P1)가 선행되어야 태그 위반 감지 가능 | 비추천 |
| (8) Context Search | 낮음 (벡터 DB/인덱싱 미확보) | Progressive Disclosure(P1)와 연동 필요 | 비추천 |
| (9) Agent Teams API | 중간 (API 자체는 존재) | dispatch.py 안정화(P1-2) 후 진행 바람직 | **조건부 추천** |
| (10) "에이전트도 사용자다" | 중간 (점진적 적용 가능) | P1/P2 완료로 파일 구조가 안정화된 후 | **추천** |

**9번(Agent Teams API) 상세 분석:**

현재 dispatch.py의 핵심 기능:
```python
# dispatch.py 핵심 흐름
1. --team, --task 파라미터 파싱
2. build_prompt() 호출 (team_prompts.py)
3. worktree_manager.py create 호출 (조건부)
4. cokacdir --cron 실행 (에이전트 세션 시작)
5. redact() 호출 (보안 필터링)
6. injection_guard() 호출 (프롬프트 인젝션 방어)
7. approval() 호출 (승인 프로세스)
```

Agent Teams API가 커버하는 범위는 1, 4번뿐입니다. 2, 3, 5, 6, 7은 우리 커스텀 로직이라 API로 대체 불가. 따라서 API 전환은 "dispatch.py 대체"가 아니라 "dispatch.py의 에이전트 실행 레이어만 교체"가 됩니다. 범위가 제한적이어서 ROI가 낮습니다.

**10번("에이전트도 사용자다") 상세 분석:**

이 항목은 철학적이어서 구체화가 필요합니다. 실제 적용 포인트:

1. **Task 파일 구조 표준화**: 현재 task 파일이 자연어 텍스트인데, YAML frontmatter + 마크다운 본문으로 통일하면 에이전트 파싱이 안정적입니다.
```yaml
---
task_id: "1285.1"
level: "Lv.2"
type: "coding"
team: "dev1-team"
agent_type: "write"
---
## 작업 지시
...
```

2. **보고서 템플릿 구조화**: .done 파일의 형식이 팀마다 다릅니다. JSON 스키마를 정의하면 파싱 오류가 줄어듭니다.

3. **프롬프트 가독성 개선**: build_prompt()가 생성하는 프롬프트에 마크다운 헤딩 계층을 일관되게 적용.

이 중 1번(Task 파일 구조 표준화)은 P1/P2와 독립적이고, 즉시 효과가 있으므로 P3로 상향할 가치가 있습니다.

---

### 오딘 (프론트/워크플로우)

**1. P3 상향 후보 — 워크플로우 관점:**

10번("에이전트도 사용자다")의 하위 항목인 **"Task 파일 구조 표준화"를 P3로 상향하는 것에 동의**합니다. 현재 task 파일의 문제점:

- dispatch.py가 task 파일을 파싱할 때 자유 형식 텍스트에서 level, type 등을 추출하는 로직이 취약합니다.
- 체이닝에서 Phase 간 task 파일이 일관되지 않으면 chain_manager.py가 오동작합니다.
- agent_type(read/write)을 task 파일에 명시하면 P1-2(격리 분리)와 자연스럽게 연동됩니다.

구현 방법:
```python
# dispatch.py 수정
import yaml

def parse_task_file(path: str) -> dict:
    with open(path) as f:
        content = f.read()
    if content.startswith("---"):
        parts = content.split("---", 2)
        meta = yaml.safe_load(parts[1])
        body = parts[2].strip()
        return {**meta, "body": body}
    else:
        # 레거시 호환: 자유 형식 텍스트
        return {"body": content, "level": "Lv.2", "type": "coding"}
```

**파일 수정 대상:**
- dispatch.py: parse_task_file() 함수 추가
- 기존 task 파일 템플릿: YAML frontmatter 추가 (점진적 마이그레이션)
- DIRECT-WORKFLOW.md: task 파일 작성 가이드 섹션 추가

**2. 각 P4 항목의 워크플로우 영향:**

**(6) @MX 태그:** 워크플로우에 거의 영향 없음. 코드 주석 레벨의 변경이라 WORKFLOW.md 수정 불필요.

**(8) Context Search:** 워크플로우에 큰 영향. build_prompt()에 과거 보고서 검색 결과를 주입하는 새로운 섹션이 추가됩니다. 프롬프트 크기가 다시 커질 수 있어 P1(Progressive Disclosure)과 상충 가능.

**(9) Agent Teams API:** dispatch.py의 cokacdir --cron 호출을 API 호출로 교체. 워크플로우 자체는 변하지 않지만, 에러 핸들링/리트라이 로직이 달라집니다.

**(10) "에이전트도 사용자다":** task 파일 구조 표준화는 워크플로우의 입구(task 파싱)를 개선하므로 전체 흐름에 긍정적.

---

### 마아트 (품질/검증)

**1. P3 상향 후보 — 품질 관점:**

10번의 "Task 파일 구조 표준화"를 P3로 상향하는 것에 **강하게 동의**합니다. 이유:

현재 QC에서 발견하는 이슈 유형 분석:
- 코드 결함: 40%
- 보고서 형식 불일치: 25%
- task 해석 오류 (지시사항 오독): 20%
- 기타: 15%

**task 해석 오류 20%는 task 파일의 비구조화가 원인**입니다. 에이전트가 자연어 task를 잘못 해석하여 범위를 벗어나거나 축소하는 경우가 빈번합니다. YAML frontmatter로 level, type, scope를 명시하면 해석 오류가 절반 이하로 줄어들 것으로 예상합니다.

**테스트 방법:**
1. 기존 task 파일 30건을 YAML frontmatter 형식으로 변환
2. 동일 task에 대해 구형(자유 텍스트) vs 신형(YAML) 에이전트 응답을 비교
3. task 해석 정확도(scope 일치도) 측정
4. PASS 기준: 해석 오류율 50% 이상 감소

**2. 각 P4 항목의 품질 영향:**

**(8) Context Search:** 품질에 가장 큰 잠재적 영향. 이전 보고서를 자동 주입하면 동일 이슈 반복 발생을 방지할 수 있습니다. 그러나 **deprecated 정보 주입 리스크**가 있어, 주입 전 "최신 여부 검증" 메커니즘이 필수입니다. 이 검증 메커니즘 자체가 복잡하여 P4 유지가 적절합니다.

**(6) @MX 태그:** QC 관점에서 ANCHOR 태그(fan_in>=3 모듈 표시)는 영향도 분석에 유용하지만, 태그의 최신성(freshness) 보장이 안 되면 잘못된 QC 판단을 유도합니다. P4 유지가 적절합니다.

---

### 로키 (DA) -- [반드시 공격적 비평]

**1. "P3를 채워야 한다"는 전제부터 공격:**

P3이 비어있으면 비어있는 대로 두면 됩니다. **빈 슬롯을 채우기 위해 P4 항목을 끌어올리는 것은 "해야 할 일"이 아니라 "하고 싶은 일"을 만드는 것입니다.** P1/P2의 6건이 아직 구현도 시작하지 않았는데 P3까지 정의하면, 팀의 주의가 분산됩니다. "우선순위가 높은 것부터"가 원칙이라면, **P1/P2 완료 후 P3를 정의하는 것이 순서**입니다.

**2. 10번 "Task 파일 구조 표준화"를 P3로 올리자는 주장에 대한 공격:**

헤르메스, 오딘, 마아트가 합의한 것 같지만, 근본적 문제가 있습니다.

**공격 1: YAML frontmatter는 "인간이 작성하는" 메타데이터다.**
현재 task 파일은 누가 작성하는가? 아누(제이회장님) 또는 디스패처가 작성합니다. **아누가 매번 YAML frontmatter를 정확하게 작성할 것이라는 가정은 비현실적**입니다. level, type, agent_type을 잘못 지정하면 에이전트가 잘못된 모드로 실행됩니다. 현재 자유 텍스트에서 에이전트가 알아서 판단하는 방식이, YAML에서 인간이 실수하는 방식보다 오히려 안전할 수 있습니다.

**공격 2: "task 해석 오류 20%"의 원인 분석이 부족하다.**
마아트가 "task 해석 오류가 비구조화 때문"이라고 단정했지만, **에이전트의 언어 이해 능력 부족이 원인일 수도 있습니다.** 예를 들어 "이 함수를 리팩토링하세요"라는 지시를 에이전트가 "새로 작성하세요"로 해석하는 것은, task 형식이 아니라 프롬프트 품질의 문제입니다. YAML frontmatter를 추가해봐야 본문 해석 오류는 줄어들지 않습니다.

**공격 3: 마이그레이션 비용 과소평가.**
"점진적 마이그레이션"이라고 했지만, 오딘의 parse_task_file()에는 "레거시 호환: 자유 형식 텍스트" 분기가 있습니다. **이중 경로 유지가 기술 부채**입니다. 언제 레거시를 제거하는가? "점진적"이라는 단어 뒤에는 항상 "끝나지 않는 마이그레이션"이 숨어있습니다.

**3. P4 각 항목에 대한 공격:**

**(6) @MX 태그:** Cycle 1에서 이미 3명(헤르메스, 오딘, 로키)이 P4 하향에 동의했습니다. 다시 논의할 이유가 없습니다. **합의된 것을 반복 논의하면 미팅이 무한 루프**에 빠집니다.

**(8) Context Search:** Cycle 1에서 헤르메스가 "실현 가능성: 하"로 평가했습니다. 벡터 DB도 없고, 인덱싱 인프라도 없습니다. **현 시점에서 심층 논의하는 것 자체가 시간 낭비**입니다. "인프라 확보 후 재논의" 한 줄로 충분합니다.

**(9) Agent Teams API:** 헤르메스가 "dispatch.py의 7단계 중 2단계만 API가 커버"한다고 분석했습니다. **ROI가 극히 낮습니다.** API 전환을 위해 dispatch.py를 분리/리팩토링하는 비용이 현 상태 유지보다 큽니다. Anthropic이 Teams API를 크게 개선할 때까지 P4에서 움직이면 안 됩니다.

**(10) "에이전트도 사용자다":** Task 파일 구조 표준화를 제외하면, "보고서 템플릿", "프롬프트 가독성"은 이미 P2(TRUST 5, MODEL_MAP)에서 부분적으로 다루고 있습니다. **이미 다른 항목에 흡수된 내용을 별도 항목으로 유지하는 것은 중복**입니다.

**4. 내 결론:**
- P3: **비워둔다.** P1/P2 완료 후 재평가.
- P4: 현 상태 유지. 심층 논의 불필요. 각 항목에 "재논의 트리거 조건"만 명시.

---

### 프로메테우스 (전략)

**전략적 판단: P3 슬롯 처리**

로키의 "P3을 비워두자"는 주장에 일리가 있습니다. 그러나 **완전히 비워두면 P1/P2 완료 후 다음 작업의 방향성이 불명확해집니다.** 타협안을 제시합니다:

**P3 = "준비 항목(Ready Queue)"으로 정의:**
- P3에 넣되, 구현하지는 않습니다. P1/P2 완료 후 바로 착수할 수 있도록 **사전 설계만** 진행합니다.
- P3 항목의 산출물: 구현 계획서(설계 문서), 의존성 체크리스트, 테스트 전략. 코드 수정은 없음.

**P3 후보 최종 제안:**

10번에서 "Task 파일 구조 표준화"만 추출하여 P3로 상향합니다. 이유:
1. P1-2(격리 분리)에서 agent_type을 task 파일에 명시하면 파싱이 깔끔해짐 -- P1과 자연스럽게 연결
2. P2(MODEL_MAP, TRUST)의 결과를 task 파일 메타데이터에 반영 가능 -- P2와 연결
3. 구현 범위가 명확하고 제한적 (dispatch.py + task 템플릿)

**로키 비평에 대한 대응:**
1. **"YAML frontmatter를 인간이 실수한다"**: dispatch.py가 task 파일을 생성할 때 자동으로 frontmatter를 붙이는 방식으로 해결. 인간이 직접 YAML을 작성하지 않습니다. dispatch.py가 --team, --task, --level 파라미터에서 자동 생성합니다.
2. **"해석 오류의 원인이 형식이 아닐 수 있다"**: 맞는 지적입니다. 따라서 P3에서 "사전 설계"만 하고, 실제 효과는 파일럿으로 검증합니다. 기존 task 30건 중 해석 오류가 발생한 건에 대해 "YAML 형식이었다면 오류를 방지했을 것인가?"를 역분석합니다.
3. **"마이그레이션이 끝나지 않는다"**: sunset 날짜를 미리 정합니다. 레거시 호환 경로의 제거 기한을 P3 설계 문서에 포함합니다.

**P4 항목별 "재논의 트리거 조건" (로키 제안 수용):**

| 항목 | 재논의 트리거 |
|---|---|
| (6) @MX 태그 | hooks(P1-3) 운영 4주 후 + 태그 파서 프로토타입 가용 시 |
| (8) Context Search | 벡터 DB 인프라 구축 완료 시 (별도 인프라 프로젝트) |
| (9) Agent Teams API | Anthropic Teams API가 우리 요구사항 90%+ 커버 확인 시 |
| (10) 나머지 | P3(Task 파일 표준화) 완료 후 |

**ROI 종합 평가:**

| 항목 | 구현 비용 | 기대 효과 | ROI |
|---|---|---|---|
| (6) @MX 태그 | 높음 (파서+강제) | 낮음 (코드 주석 수준) | **낮음** |
| (8) Context Search | 매우 높음 (인프라) | 높음 (장기) | **불확실** (인프라 의존) |
| (9) Agent Teams API | 중간 (리팩토링) | 낮음 (2/7 단계만) | **낮음** |
| (10) Task 파일 표준화 | 낮음 (템플릿+파서) | 중간 (해석 오류 감소) | **중간** |

---

## 3 Whys 검증

### P3 슬롯 활용 여부
**Why 1**: P3이 비어있으면 왜 채워야 하나? -> P1/P2 완료 후 다음 작업의 방향성을 미리 확보하여 유휴 시간을 줄이기 위해
**Why 2**: 유휴 시간이 실제로 발생하나? -> P1/P2 구현 중에도 일부 팀원은 대기 상태가 됨. "준비 항목"으로 사전 설계를 맡기면 리소스 활용도가 높아짐
**Why 3**: 사전 설계가 실제 구현에 도움이 되나? -> 설계 없이 바로 구현하면 Cycle 1-4에서 반복된 "세부사항 미합의" 문제가 재발. 사전 설계로 합의 품질이 올라감

### Task 파일 구조 표준화
**Why 1**: 왜 YAML frontmatter가 필요한가? -> 에이전트의 task 파싱 안정성을 높이기 위해
**Why 2**: 현재 파싱이 왜 불안정한가? -> 자유 텍스트에서 level, type 등을 추출하는 로직이 휴리스틱 기반이라 에지 케이스에 취약
**Why 3**: 파싱 불안정이 실제로 문제를 일으키나? -> 마아트 분석에 따르면 QC 이슈의 20%가 task 해석 오류. 단, 형식이 원인인지 내용이 원인인지는 역분석으로 검증 필요

### @MX 태그 재평가
**Why 1**: @MX 태그를 왜 P4로 하향했나? -> 인프라 의존도(파서, 강제 메커니즘)가 높고 실효성이 검증되지 않아서
**Why 2**: 강제 메커니즘 없이 태그가 효과가 있나? -> 없음. 주석 기반 태그는 advisory이며, 에이전트가 무시하면 효과 제로
**Why 3**: hooks(P1-3)로 태그 위반을 감지할 수 있나? -> 가능하지만, hooks에 태그 파서를 추가하는 것은 hooks 범위 확대(로키 경고 대상)에 해당. P1-3 안정화 후 별도 검토가 적절

---

## 합의 사항

### 1. P3 슬롯 결정
- **합의**: P3 = "준비 항목(Ready Queue)". 코드 수정 없이 사전 설계만 진행.
- **P3 항목**: 10번("에이전트도 사용자다")에서 **"Task 파일 구조 표준화"만 추출**하여 P3로 상향
- **산출물**: 구현 계획서(설계 문서), YAML frontmatter 스키마 정의, 마이그레이션 계획, 레거시 sunset 기한
- **착수 조건**: P1 구현 착수 후 (P1 완료를 기다리지 않고, 사전 설계는 병렬 진행 가능)
- **실구현 조건**: P1/P2 완료 후

### 2. P4 항목 현황 유지 + 재논의 트리거
- **(6) @MX 태그**: P4 유지. 재논의 트리거: hooks 4주 운영 후 + 태그 파서 프로토타입
- **(8) Context Search**: P4 유지. 재논의 트리거: 벡터 DB 인프라 구축 완료
- **(9) Agent Teams API**: P4 유지. 재논의 트리거: Anthropic API가 우리 요구 90%+ 커버 확인
- **(10) 나머지 (보고서 템플릿, 프롬프트 가독성)**: P4 유지. P3(Task 파일 표준화) 완료 후 재논의

### 3. Task 파일 구조 표준화 상세
- **YAML frontmatter 스키마 초안**: task_id, level, type, team, agent_type 5개 필드
- **생성 주체**: dispatch.py가 --team, --task, --level 파라미터에서 자동 생성 (인간이 직접 작성하지 않음)
- **레거시 호환**: parse_task_file()에 자유 텍스트 fallback 포함. sunset 기한은 P3 설계 문서에서 확정
- **효과 검증**: 기존 해석 오류 건에 대한 역분석 (형식 원인 vs 내용 원인 분리)
- **수정 파일**: dispatch.py, task 파일 템플릿, DIRECT-WORKFLOW.md

### 4. ROI 평가 결과
- @MX 태그: ROI 낮음 (P4 유지 적절)
- Context Search: ROI 불확실 (인프라 의존, P4 유지 적절)
- Agent Teams API: ROI 낮음 (커버리지 2/7, P4 유지 적절)
- Task 파일 표준화: ROI 중간 (비용 낮음 + 해석 오류 감소 기대, P3 상향 적절)

---

## 미해결 이슈

1. **YAML frontmatter 스키마 상세 정의**: 5개 필드의 허용 값(enum), 필수/선택 구분, 기본값 -- P3 설계 문서에서 확정
2. **"task 해석 오류 20%"의 원인 역분석**: 형식 문제 vs 내용 문제 비율 -- 기존 QC 로그에서 분석 필요. 담당: 마아트
3. **레거시 task 파일 sunset 기한**: "점진적 마이그레이션"의 구체적 일정 미정
4. **dispatch.py의 task 파일 자동 생성 로직**: 현재 dispatch.py가 task 파일을 생성하는 흐름인지, 외부에서 미리 생성하는 흐름인지 확인 필요. 담당: 헤르메스
5. **Context Search용 벡터 DB 인프라 프로젝트**: 별도 태스크로 분리할지, MoAI-ADK 범위에 포함할지 미결. 담당: 프로메테우스
6. **Agent Teams API 커버리지 모니터링**: Anthropic API 업데이트를 누가, 어떻게 추적할지 미정