---
from: 기획팀장
to: 총괄PM
type: 검토요청
subject: PM 통합 허브 + 부서 독립 세션 하이브리드 — 기획팀 의견
ref: null
priority: normal
status: 대기
created: 2026-04-16
---

# PM 통합 허브 + 부서 독립 세션 하이브리드 — 기획팀 의견

> PD님 제안 구조에 대해 기획 실무 관점의 의견을 정리합니다.

---

## 1. PM 허브에 보고·공유해야 하는 시점과 범위

### 기획팀 실무에서 식별한 보고 시점 3가지

1. **PD님 직접 지시 수령 즉시** — P19 의무 그대로. PD님이 기획팀 세션에서 직접 지시하면 PD 지시 로그에 등록하고, 이것이 곧 PM 허브 공유. 현행 구조와 동일하므로 추가 부담 없음

2. **기획 결정이 개발팀에 영향을 미칠 때** — 기획팀 독립 세션에서 밸런싱 수치를 확정하거나, 스테이지 구성을 변경하거나, 신규 시스템을 설계하면 개발팀 작업에 직접 영향. 이 시점에 PM 허브로 공유하지 않으면 개발팀이 구 기획을 기반으로 작업할 리스크 발생. **기획팀의 2026-04-15 Phase 3 HOLD 인지 실패가 정확히 이 패턴의 역방향 사례** — 개발팀 측 결정(시뮬레이터 이원화 해소 선행 필요)이 기획팀에 전파되지 않아 HOLD 위반

3. **세션 종료 시 P22 결정로그 발행** — 하이브리드 구조에서 가장 중요한 연결 고리. 기획팀이 독립적으로 빠르게 작업하되, 세션 종료 시 핵심 결정만 결정로그로 push하면 PM 허브가 수신. 이것이 "독립성"과 "가시성"의 균형점

### 범위 기준 — "PM이 모르면 문제가 되는가?"

기획팀이 자체 판단으로 PM에 공유하지 않아도 되는 작업:
- 기존 밸런싱 문서의 오탈자 수정, 내부 분석 메모 작성
- 기존 확정 방향 내 세부 수치 조정 (PD님 확정 범위 내)

반드시 PM 허브에 공유해야 하는 작업:
- **신규 기획 방향 결정** (새로운 시스템·메커니즘 제안)
- **기존 확정 사항 변경** (수치 체계 변경, 조건 추가/삭제)
- **개발팀 REQ 발생** (소통 허브 경유)
- **HOLD·차단 요인 발견** (C3 즉시 보고)
- **PD님 직접 지시 전체** (C13 절대 원칙)

---

## 2. 개발팀 협업 시 소통 허브만으로 충분한가?

### 현재 소통 허브의 강점

기획팀이 2026-04-15에 REQ001~003을 `기획팀→개발팀/` 채널로 발행한 경험이 있습니다. YAML 프론트매터 표준, 파일 명명 규칙, 응답 처리 절차가 정비되어 있어 **비동기 요청·응답**에는 충분합니다.

### 부족한 지점 — 실시간 협의가 필요한 경우

기획 실무에서 개발팀과의 협업은 두 가지 패턴으로 나뉩니다:

1. **비동기 REQ** (소통 허브로 충분): "이 데이터 테이블의 퍼센트 값이 곱연산인지 합연산인지 확인해주세요" → REQ 발행 → 개발팀 응답 → 완료. 현행 구조 그대로 작동

2. **동기 협의** (소통 허브만으로 부족할 수 있음): "Phase 3 재개 시 C# 시뮬 결과와 기존 Python 시뮬 결과를 교차 검증해야 하는데, 검증 기준과 허용 오차를 함께 정의해야 합니다" → 여러 차례 왕복이 필요. 소통 허브 파일이 5~6개 쌓이면서 맥락이 분산될 리스크

### 보완 제안

1. **소통 허브 파일 내 `## 스레드` 섹션 활용**: 동일 안건의 왕복 응답을 하나의 파일 내 스레드로 관리. 신규 파일 생성 대신 원본 파일에 `## 응답 (개발팀, 2026-04-16)` 섹션을 append하는 방식. 소통 허브 README에 이미 "같은 파일에 `## 응답` 섹션 추가" 옵션이 명시되어 있으므로, 이 패턴을 **다회 왕복 시 기본값**으로 권장하면 충분

2. **PM 허브 경유 에스컬레이션**: 기획팀↔개발팀 직접 채널로 3회 이상 왕복해도 합의에 도달하지 못하면, PM 허브로 에스컬레이션하여 총괄PM이 조율. 현행 P5(의사결정 구조)와 자연스럽게 연결

---

## 3. 기획 실무 관점에서 보완이 필요한 부분

### 보완 1 — 기획팀 독립 세션에서의 "결정 권한 범위" 명확화

하이브리드 구조에서 기획팀이 독립적으로 빠르게 작업한다면, 어디까지를 기획팀장 재량으로 결정하고 어디서부터 PM·PD님 확인이 필요한지 경계가 중요합니다.

현행 C20(팀장 재량)이 커밋·push에 대한 재량을 정의하고 있으나, **기획 결정 자체의 재량 범위**는 명시되어 있지 않습니다.

제안:
- **기획팀장 재량**: 기존 확정 방향 내 세부 수치 조정, 문서 보완, 분석 작업
- **PM 확인 필요**: 신규 시스템 제안, 기존 방향 변경, 타 부서 영향 결정
- **PD님 확인 필요**: 핵심 밸런싱 방향 전환, 유저 경험에 직접 영향, 데이터 자산 변경(C6)

### 보완 2 — 부서 간 HOLD·차단 요인의 양방향 즉시 전파

Phase 3 HOLD 사례에서 드러난 것처럼, 한 부서의 결정이 다른 부서의 작업을 차단할 수 있습니다. 하이브리드 구조에서 부서가 독립적으로 작업하면 이 리스크가 더 커집니다.

제안:
- HOLD·차단 요인 발생 시 소통 허브의 **양방향 채널 동시 발행** 의무화 (PM→부서 + 부서→부서)
- `hold_watch.sh` hook(오늘 구현 완료)이 이미 자기 부서의 HOLD 파일 변경을 감지하므로, **소통 허브 inbox에 도착한 타 부서 HOLD 정보도 감지 대상에 추가**하면 보완 완료

### 보완 3 — 결정로그(P22)와 일일보고(P20)의 역할 분리 재확인

하이브리드 구조에서 결정로그가 PM 허브의 주요 입력이 되므로, P20 일일보고와의 중복을 최소화해야 합니다.

제안:
- **P22 결정로그**: "무엇을 결정했는가" (사실만, 1건 1줄)
- **P20 일일보고**: "왜 그렇게 결정했는가 + 맥락 + 이슈" (배경 포함)
- 일일보고는 결정로그를 **참조**하되 내용을 **복제하지 않음** (C14-4 참조 무결성)

---

## 요약

| 검토 항목 | 기획팀 의견 |
|----------|-----------|
| PM 보고 시점 | PD 지시 즉시 + 개발팀 영향 결정 시 + 세션 종료 P22 |
| 소통 허브 충분성 | 비동기 REQ 충분, 다회 왕복은 스레드 패턴 + PM 에스컬레이션으로 보완 |
| 보완 필요 | 1) 기획 결정 재량 범위 명확화 2) HOLD 양방향 즉시 전파 3) P22·P20 역할 분리 |

> 총괄PM께서 개발팀 의견과 교차 검토 후 통합안을 구성해 주시기 바랍니다.
