106 lines
6.5 KiB
Markdown
106 lines
6.5 KiB
Markdown
---
|
|
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께서 개발실 의견과 교차 검토 후 통합안을 구성해 주시기 바랍니다.
|