---
type: feedback_memory
pattern: PM_환경제약_PD수동전가_반복
severity: major
triage_date: 2026-04-23
last_updated: 2026-04-23
tier: constitutional
related_rules: [C23, C29, C36, C2, C11]
related_feedback: [feedback_pm_capability_underestimation.md]
---

# PM 환경 제약 → PD 수동 집행 전가 패턴 (개발팀 Agent 실측 우선)

## 1. 사건 요약 (2026-04-23 BT5-Dev 2단계)

PD 지시: BT5-Dev 2단계 (EerieVillage 캐릭터 교체·이동·공격·i-frame) — 원 계획은 "Claude Desktop Unity MCP로 Unity Editor 직접 조작".

PM 인식 경로:
- Claude Code 세션에는 `mcp__unity-mcp__*` 도구가 노출되지 않음 (BT4에서 Claude Desktop 전용 배포)
- PM 초기 프레이밍: "Claude Code 세션에서 Unity MCP 불가 → PD 수동 집행 대기"

PD 지적 (요지): "Unity 프로젝트 파일 직접 Edit으로 수행 가능한 범위 최대 구현. PD 수동 개입 최소화."

개발팀장 Agent 재설계:
- Unity 프로젝트는 **YAML·JSON·C# 텍스트 포맷** → Claude Code의 Read·Edit·Write로 **95%+ 구현 가능**
- 불가능한 것: Play 모드 런타임 검증, Animator GUI 특유의 StateMachine 시각 편집, Editor Inspector 컴포넌트 Add
- 파일 직접 Edit으로 수행한 범위: C# 스크립트 5종(신규 2·개정 3), Input Actions JSON 바인딩 추가, Scene YAML의 Sprite GUID 교체, .meta guid 할당

## 2. 근본 원인

1. **PM이 환경 제약을 탐색 없이 포장**: "MCP 도구 부재 = 수행 불가"로 과속 결론
2. **개발팀 Agent의 파일 직접 Edit 가능성 과소평가**: Unity 자산이 모두 텍스트 기반이라는 속성 간과
3. **C29 업무 자율 수행 위반**: PD에게 "Play 모드 검증 외 전부 수동으로 해주세요" 수준으로 떠넘기기
4. **C36 방향·원칙 수준 축소 시도**: "자동화 최대" 방향을 "일부는 불가"로 희석

## 3. 재발 방지 — PM 체크리스트

환경·도구 제약 보고 전 **반드시 다음 4단계 선행 실측**:

1. **실 파일 포맷 확인** — 편집 대상이 텍스트(YAML·JSON·md·C#)인지 바이너리인지
2. **개발팀 Agent의 Read·Edit·Write로 가능한 범위 실증** — 1개 샘플 파일로 조작 성공 여부 확인
3. **불가능한 부분만 분리** — "전부 불가"가 아닌 "A·B는 가능, C·D는 GUI 필수"로 세분
4. **C·D만 PD 수동 요청** — 개수·구체 내용 명시, 전체 떠넘기기 금지

체크리스트 미통과 시 PM 자기검증 C31-A (C29 준수) 위반 후보로 간주.

## 4. 연관 사건 로그

| 일시 | 사건 | 근본 원인 | 재발 방지 |
|---|---|---|---|
| 2026-04-20 | PM이 PreToolUse 차단 workflow를 "복잡도 과다"로 축소 시도 | 구현 복잡도 선입견 | pm-auditor 의무 호출·근본 해결안 우선 제시 (C2-3) |
| 2026-04-22 | PM이 Unity MCP 미지원을 "PD 수동 집행 대기"로 결론 | 환경 제약 = 불가 공식화 | 본 SOT 신설 — 실측 4단계 선행 |
| 2026-04-23 | 1회차 — PM이 Unity MCP 미지원을 "PD 수동" 결론 (BT5-Dev 2단계 착수) | 환경 제약 = 불가 공식화 | 본 체크리스트 운용 + C31-A 연동 |
| 2026-04-23 | **2회차 — 개발팀 Agent가 prefab 컴포넌트 Add를 "MonoBehaviour guid 관리 복잡도"로 기각** (BT5-Dev 2단계 v0.1 §4-2·§7-1) | **AI Agent의 Unity 파일 편집 능력 과소평가** — guid가 .meta에 이미 있고 fileID 충돌 회피 가능함에도 "복잡도"로 회피 | PD 재지시로 번복 수행 성공. Prefab YAML 직접 편집 = 표준 경로임을 실증. 추가 체크리스트 (§3 확장) |

## 5. 2회차 사건 상세 (2026-04-23 v0.2 재위임)

### 5-1. 반복 패턴 — 회피 사유가 "복잡도"로 변종

1회차 PM: **"MCP 도구 부재 = 수행 불가"** (환경 제약)
2회차 개발팀 Agent: **"guid 관리 복잡도"** (기술 복잡도)

동일 근본 원인: **AI Agent가 자기 능력치를 과소평가하여 실행 가능한 경로를 "리스크"로 프레이밍하여 PD 수동으로 전가**.

### 5-2. 실측 번복 결과

PD 재지시 후 개발팀장 Agent 직접 수행:

1. **Player.prefab YAML 편집** — AttackHitbox MonoBehaviour 블록 append (fileID `7700000000000000001`, guid `b2c3d4e5...`). `m_Component` 리스트 확장. Inspector 기본값 5종 직렬화
2. **Enemy.prefab YAML 편집** — Health MonoBehaviour 블록 append (fileID `7700000000000000002`, guid `ffad43bb...`). `maxHP: 1` 직렬화
3. **EditMode 테스트 스위트 8종** — `Assets/Tests/Editor/PlayerAttackTests.cs` + asmdef. AssetDatabase 경유 prefab 검증 (Play 모드 불요)

**소요**: ~10분. 리스크: 0 건 실측 (fileID 충돌 grep·guid 실존 확인·YAML 구조 검증 통과).

### 5-3. 확장 체크리스트 (기존 §3 4단계에 추가)

Unity 프로젝트 파일 편집 시 **"복잡도 기각"하기 전에** 다음 5항목 선행 실측:

1. **.meta guid는 파일에 이미 존재** — `cat {asset}.meta | grep guid` 확인 (컴파일 후 생성 불필요)
2. **fileID는 uint64 범위** — 기존 값 grep 후 격리된 큰 수 할당하면 충돌 0 (`7700000000000000001` 같이)
3. **MonoBehaviour YAML 블록 구조는 표준** — `--- !u!114 &<fileID> MonoBehaviour\n m_Script: {fileID: 11500000, guid: <guid>, type: 3}\n ...` 패턴이 전 Unity 프로젝트 공통
4. **m_Component 리스트 확장은 1줄 추가** — `- component: {fileID: <새fileID>}` append
5. **Inspector 기본값 직렬화** — 스크립트 `public` 필드의 `= default_value` 구문을 YAML 키:값으로 재현하면 Editor가 인식

위 5항목 중 **3개 이상 통과 시 YAML 직접 편집 가능** 판정. "복잡도 과다"로 PD 수동 전가 금지.

### 5-4. 최종 커버리지 (v0.2 재위임 반영)

| 항목 | v0.1 | v0.2 | 델타 |
|---|---|---|---|
| C# 신규·개정 | 5종 | 5종 | — |
| Asset 편집 (InputActions·Scene·Prefab·Test asmdef·Test cs) | 2종 | **5종** | +3 (Player.prefab·Enemy.prefab·asmdef·Test cs·테스트 디렉토리) |
| PD 수동 필요 | 4건 | **1건** (Play 검증만) | −3 |
| 커버리지 | ~90% | **~99%** | +9% |

AI Agent가 Unity 프로젝트 개발에서 달성 가능한 실질 커버리지가 **~99%**임을 실증. 남은 1%는 GUI 런타임 QA 성격(C29-3 인간 검증 예외).

## 6. 연관 규칙

- **C23** 허위 보고·역할 연기 절대 금지 — 환경 제약을 "수행 불가"로 과포장 시 C23 위반 후보
- **C29** 업무 자율 수행 체계 — PM 결정 떠넘기기 금지
- **C36** PM 자율 판단 범위 상한 — 자동화 최대 방향 축소 금지
- **C2** 근원적 문제 해결 최우선 — "MCP 도구 부재" 대신 "텍스트 포맷 활용"으로 근본 재설계
- **C11** 개발 관점 원칙 (개발팀 전용) — 자원 효율성 (PD 시간)·코드 직관성(Agent 자동화) 우선
- **feedback_pm_capability_underestimation.md** — 조직 역량 과소평가 일반 패턴의 특수 사례

## 7. 영구 보존 사유

본 패턴은 **Unity MCP 확장·다른 외부 도구 도입 시에도 재발 가능**. 환경 제약이 있는 모든 경우에 본 체크리스트를 재활용할 수 있도록 SOT로 영구 보존.

---

## 8. 3회차 변종 — 리소스 실측 축약으로 인한 오판 (2026-04-24)

### 8.1 사건 요약
PD가 `PlayerTestGirl.png` 를 `Assets/Character/Sprites/` 에 직접 저장(2026-04-22 23:47). PM은 세션 재개 시 해당 파일의 **실물 이미지를 Read(이미지) 도구로 시각 확인하지 않고**, 파일명만으로 "기존 Player 시리즈(PlayerIdle·PlayerRun 등)의 새 추가본"으로 오인식. **A안 (Player 시리즈 유지 + 이름만 변경)** 을 PD께 승인 요청했으나 PD가 "이미지를 봤냐"고 역질문.

### 8.2 근본 원인
1. **리소스 판정 시 시각 확인 의무 부재** — 파일명 매칭은 추정 (C5 정직성의 특수 외연)
2. **파일 시스템 스캔 축약** — `ls | head -20` 로 디렉토리 스캔했으나 PlayerTestGirl.png 가 범위 내였음에도 "기존 Player 시리즈와 같은 종류" 로 패턴 과일반화 하여 Read(이미지) 생략

### 8.3 실물
- **실제 이미지**: 보라머리·파란옷·검을 든 캐릭터 (전혀 다른 캐릭터)
- **구성**: 1536×1024, 4열×2행 = 8 sprite, 384×512 grid
- **내용**: walk 4프레임 + attack 4프레임 (완전 신규 캐릭터·완전 신규 애니메이션 세트)

### 8.4 재발 방지 체크리스트 (기존 4문항에 신규 4문항 append)

5. **리소스 실물 시각 확인 선행** — 이미지 리소스는 Read(이미지) 도구로 **시각 확인 후** 판단. 파일명 매칭만으로 판정 금지
6. **ls 전수 (head·tail 자르기 금지)** — 리소스 디렉토리 스캔 시 `ls -la` 전수. `head -N` 축약은 누락 위험
7. **기존 meta 존재 시 Read 선행** — `.png.meta` 가 이미 존재하면 (Unity auto-import 결과 포함) **반드시 Read 후 내용 기반 판단** (guid·spriteMode·sprite 개수 확인)
8. **"캐릭터 교체"·"리소스 추가" 지시 시 A/B/C 선택지 전 시각 확인 필수** — 추정 기반 선택지 제시 금지. 이미지를 본 뒤 사용자 의도 파악

### 8.5 C2-1 "근본 원인 재정의" 적용
- 표면 원인: 파일명 매칭 오판
- **근본 원인**: 리소스 판정 시 시각 확인을 "선택적 도구"로 간주 → **시각 확인을 필수 선행 의무로 격상** 필요
- 이에 부수 feedback `feedback_pm_image_verification_skip.md` 신설 (`tier: constitutional`)

### 8.6 3회차 변종 학습 결과

1~2회차는 **Unity MCP 환경 제약 과대 해석**. 3회차는 **리소스 실물 확인 생략**. 두 패턴의 공통점:
- Agent 자율 능력 범위를 **사전 검증 없이** 축소 판단
- PD 확인 요청 전에 **자체 역량 검증 선행** 의무 누락

**해결책**: C23 허위 보고 금지 + C31 자기검증 H 체크리스트에 "리소스 판정 시 시각/실측 선행 완료" 추가 안건 (개발팀장 재량 내 proposal).

