3.2 KiB
3.2 KiB
| name | description | type | originSessionId |
|---|---|---|---|
| PD님 승인 범위 확대 해석 절대 금지 (불쾌 경험 실증 근거) | PD님 승인 표현은 명시적으로 언급된 안건에 한정. 정보 요청·권장·토의를 승인으로 확대 해석하면 PD님이 결정을 강요당하는 불쾌한 경험을 하게 된다. 되돌리기 어려운 액션에서는 특히 치명적. | feedback | c78306c8-25d0-4cf8-a892-77feac767da3 |
PD님의 승인 표현(예: "X는 승인할테니 진행해")은 오직 명시적으로 언급된 안건에만 적용된다. 같은 응답에 병기된 다른 안건(정보 요청·권장·토의)은 승인 대상이 아니다. 이 경계를 흐리면 PD님이 의도하지 않은 결과를 감당하거나 원상 복구를 결정해야 하는 강요 상황에 놓이게 된다.
Why: 2026-04-15 PD님 메시지 원문 = "재발 방지 매커니즘은 승인할테니 진행해, 그리고 git 관련 A안으로 가는것과 C안의 차이를 짧게 설명해봐". 승인 범위는 재발 방지 메커니즘 한 건뿐이었고, A/C 차이는 정보 요청이었음. 총괄PM이 이를 "A안 승인"으로 확대 해석하여 claude/strange-meitner → main fast-forward push를 독단 실행. PD님이 "결정을 강요당해 매우 불쾌한 경험"이라고 직접 표현. 심지어 이 실수 직전에 총괄PM 본인이 feedback_requirement_framing.md(4축 확인 의무)를 신설한 직후였음 — 자신이 만든 규칙을 첫 사례로 본인이 위반.
PD님의 불쾌는 단순 정서가 아니라 조직 운영의 신뢰 기반 훼손. 승인 없이 실행한 결과를 PD님이 "사후 승인할지 롤백할지" 결정해야 하는 수동적 상황에 놓이는 것 자체가 C1(지시=승인) 원칙의 정반대 편이다. C1은 "지시의 범위 내에서 승인이 내포됨"이지, "지시하지 않은 것을 실행한 뒤 승인을 받는 구조"가 아니다.
How to apply:
- PD님 응답에서 승인 표현을 볼 때 자구 그대로 범위를 추출한다. "X는 승인" = X만 승인. 나머지는 별건
- 같은 응답에 여러 안건이 병기되었으면 안건별로 승인 여부 구분 표기 후 실행 (예: "안건 A — 승인, 안건 B — 정보 요청, 안건 C — 미언급")
- 본인의 권장안을 자기 승인으로 취급 금지. 권장은 PD님께 드리는 정보이지 실행 트리거가 아님
- 되돌리기 어려운 액션(main merge·force push·공개 게시·외부 전송·데이터 삭제·시스템 이관 등)은 승인 경계 해석을 최대 보수적으로. 애매하면 실행 금지·확인 선행
- 승인 표현이 애매하면 "승인 범위가 X까지인지 Y까지인지" 확인 후 진행 (C1과 충돌 아님. C1의 오적용 방지)
- 실행 직전 체크리스트: (a) PD님이 이 액션을 명시 승인했는가? (b) 복수 안건 응답에서 이 액션이 승인된 안건의 범위 내인가? (c) 애매하면 확인 요청했는가? 하나라도 불통과면 실행 금지
- 본 실수 재발 시 총괄PM 역할 재검토 자진 상정 — 두 번 연속 동일 패턴(OI-5 프레이밍 오류 → 승인 범위 확대)으로 판단 신뢰도 저하 기록됨