공수 추정 전면 재환산 표준 (2026-10-02)

작성: 박세린 PM PD 발주: 2026-10-02, "안건 3 승인" — R-U7-6 (정현우, designs/unity_version_strategy_2026-09-30.md:864) 기반 전면 재환산 범위: 본 파일 1개만 신설. roadmap_v4_1_phases_2026-09-30.md / roadmap_v4_0_2026-09-06.md / phase4_trigger_gate_2026-09-28.md / roadmap_v3_0_closure / combat_system_* / CLAUDE.md 수정 0. §2는 "열거만" — 개별 문서 수정 안 함(Karpathy Surgical Changes). 협업 프로토콜: Q→O→D→Dr→A 완료분(PD 안건 3 승인) 인수. 본 문서는 Draft 단계 산출물.

PD 1쪽 요약

• 환산 표준 1줄: 모든 공수는 Nh ÷ 3~6h/주(중앙값 4.5h/주)로 환산. 풀타임(40h/주) 환산 표기 전면 폐기.
• 재환산 대상: 문서 7개, 수치 지점 18건 발견. 우선순위 1~2(combat 180h + FlatBuffer 50h/80h) 가 일정 판단에 가장 직접적으로 쓰임 — 이 2건이 각각 Phase 4 예산과 이미 실행된 FlatBuffer Self-build 결정의 기반 수치.
• Phase 기간 재산정: v4.1의 "가정 A(1.96배)"는 틀리지 않았으나 레이어가 다른 보정(정지 구간만 반영, 활동 중 속도 낙관은 미반영) → 과소 보정 확정. 증거: Phase 4 하위 작업 1건(전투 포팅 180h)만 정직하게 재환산해도 6.9~13.9개월인데, 가정 A는 Phase 4 전체를 6~12개월로 잡음. 하위 작업 1건이 전체 예산을 잠식/초과.
• 출시일 함의: 2027-03 (C)+(B) 결정(Steam 출시예정 페이지+위시리스트, 플레이빌드=Phaser 웹게임 재사용)은 영향 0 — 이 결정 자체가 Unity 빌드를 요구하지 않음. 영향 받는 쪽은 Unity 플레이 가능물(Phase 4 본판) — 기존 "6~12개월" 추정이 더 늘어날 가능성이 높으나 날짜는 잠그지 않음(v4.1 §4 U1 미결정·PD 51 원칙과 동일 처리).
• 재발 방지: CLAUDE.md 반영 제안 1줄(§5) — 수정은 PD 승인 후.

§1 환산 표준 확정

1.1 실측 기저선 (재확인, v4.1 §2 동일 수치 승계)

78.5%(무활동일 비율)를 "정지율"로 과장하지 않는다 — 1인 파트타임 기저선이며, 이 3~6h/주 자체가 이미 그 무활동일을 포함해 163일 전체를 평균 낸 값이다(§3 참조, 가정 A와의 관계).

1.2 환산 공식

주 소요 = Nh ÷ 속도(h/주)
하한(최단) = Nh ÷ 6
상한(최장) = Nh ÷ 3
중앙값     = Nh ÷ 4.5
개월 환산  = 주 ÷ 4.33

풀타임(40h/주) 환산은 쓰지 않는다. 1인 파트타임 프로젝트에서 "3주 풀타임" 같은 표기는 실제 투입 속도와 무관한 가상의 참고치이며, 지금까지 "6주 파트타임" 류 표기가 20h/주를 암암리에 가정해 혼선을 낳은 원인 그 자체다(R-U7-6).

1.3 변환 테이블 (검산 완료)

PD 제시 범위(80/120/180/240h → 13~27 / 20~40 / 30~60 / 40~80주) 검산 결과: 일치.

§2 영향 문서 인벤토리 (열거만 — 개별 수정 0)

우선순위 = "일정 판단에 실제로 쓰이는 정도" 기준. 1이 최우선.

우선순위 1 — Phase 4 예산에 직결 (combat system, 쌍둥이 문서 2개)

우선순위 2 — FlatBuffer Self-build (이미 실행된 아키텍처 결정의 기반 수치)

우선순위 3 — Sp02 재개(9/15) 직결 (패왕전기 흡수 전제)

우선순위 4 — 리스크 시나리오 (발생 확률 낮으나 발생 시 왜곡 최대)

우선순위 낮음 — 영향 미미 (참고 열거만, 재환산 불필요)

해당 없음 (false positive로 확인, 재환산 대상 아님)

집계: 재환산 필요 7개 파일, 18개 수치 지점. 영향 없음 3개, 해당 없음 3개 (오탐 제외).

§3 Phase 기간 재산정 (roadmap_v4_1_phases_2026-09-30.md §1 대상, 그 파일은 미수정)

3.1 가정 A(1.96배)와 본 표준의 관계 — 검증 결과

v4.1 §1은 "가정 A"(지표 A, 정지 구간 49% → 배수 1÷(1-0.49)=1.96배)로 P3b~P7 기간을 산정했다. 본 표준(3~6h/주)과 비교한 결과:

이 둘은 서로 다른 레이어를 잰다 — 대체 관계가 아니라 잠재적 중복 관계.

• 가정 A: "프로젝트 전체가 통째로 멈춘 날" 비율(지표 A, 49%)만 반영. 활동이 있던 날 그 안에서 얼마나 빨리 일했는지는 묻지 않는다.
• 본 표준(3~6h/주): 월 6.5활동일 × 2~4h를 163일 전체 기간(정지 구간 포함)으로 평균 낸 값이다. 즉 정지 구간이 이미 분모에 들어가 있다.
• 따라서 raw 공수(h)가 있는 항목에는 본 표준 단독 적용이 맞다 — 가정 A를 추가로 곱하면 정지 구간을 두 번 반영하는 이중 할인이 된다.
• raw 공수가 없고 "개월" 수치만 있는 항목(P3b/P5/P6 원문)은 그 "개월" 추정이 애초에 어떤 주당 속도를 가정했는지 기록이 없어 가정 A 적용이 유일하게 재현 가능한 근사치였다. 그러나 그 적용 자체가 "활동 중 속도는 낙관적(20h/주급)이었을 가능성"을 전혀 걸러내지 못한다 — 이번 §2에서 발견된 5.0배(균일) 낙관이 바로 그 누락분이다.

판정: 가정 A는 틀리지 않았다(정지 구간은 실재한다). 그러나 단독 적용은 과소 보정이다. 결정적 증거 — Phase 4 하위 작업 1건(전투 포팅)만 raw 공수(180h)로 직접 재환산해도 6.9~13.9개월이 나오는데, 가정 A는 Phase 4 전체를 6~12개월로 잡았다. 하위 작업 1건이 전체 예산과 같거나 넘는다는 것은 가정 A 산출치가 이미 범위를 벗어났다는 뜻이다.

3.2 재산정 결과 (v4.1 §1 표 대상, 참고용 — 그 파일은 미수정)

결론: P3b/P5/P6은 가정 A 공식조차 명시적으로 적용되지 않은 정성적 숫자이고, P4만 가정 A 공식(1.96배)이 적용됐으나 전투 포팅 단독 재환산과 충돌 — 네 Phase 전부 재산정 전까지 "확정 기간"으로 쓰면 안 된다. 참고용 5.0배 상한은 §2에서 발견한 균일 낙관 배수를 그대로 투영한 가정일 뿐, 각 Phase의 실제 공수 분해가 아니다 — 하한·상한 모두 다음 h 분해 전까지는 폭(range)으로만 취급.

§4 출시일 함의 (날짜 미잠금, 범위만)

• 2027-03 (C)+(B) 결정 — 영향 0. 이 결정은 Steam "출시 예정" 페이지 + 위시리스트(플레이 빌드 불필요) + 플레이 가능물은 기존 Phaser 웹게임(Steam = Electron wrap)이다. Unity 플레이 빌드를 요구하지 않으므로 본 재환산(Phase 4 Unity 작업)과 직접 교차 영향 없음.
• 영향 받는 대상 = Unity 플레이 가능물(Phase 4 본판). §3 재산정에 따르면 Phase 4는 기존 가정 A 산출치(6~12개월)보다 더 길어질 가능성이 높다(하위 작업 1건이 이미 그 범위를 채움). 구체적 날짜는 잠그지 않는다 — roadmap_v4_1_phases_2026-09-30.md §4(U1 미결정)·PD 51 원칙(미래 결정은 옵션 재제시, 즉시 결정만 잠금)과 동일하게 처리.
• Unity 7 직행 확정(PD 금번 확정) 자체는 본 재환산과 별개 트랙 — Unity 7 Preview 2026-12 / 정식 Q1 2027 일정이 그대로면 Unity 데모 자체가 그 이후로 이월되는 것은 기존 전제와 동일, 본 재환산이 추가로 당기거나 미루지 않음.
• 권고: Phase 4 착수 시점(Phase4 게이트 T1~T4 충족 후) 재상정 세션에서, 전투 포팅(180h, 확정 재환산치 보유)을 기준 서브시스템으로 두고 나머지 서브시스템(인벤토리/퀘스트/시즌/어픽스)도 동일 표준으로 h 분해 후 재합산 — 그 전까지 "Phase 4 = 6~12개월"이라는 숫자를 캘린더에 쓰지 말 것.

§5 재발 방지 규칙 (제안 — CLAUDE.md 미수정, PD 승인 시 반영)

제안 문구 (CLAUDE.md "진행 원칙" 또는 "에이전트 협업 프로토콜"에 추가 후보):

공수(h) 추정 시 주당 가용시간을 반드시 명시하고, 1인 파트타임 프로젝트는 실측 3~6h/주(중앙값 4.5h/주)를 기본값으로 쓴다. "풀타임 N주" 환산 표기는 쓰지 않는다. "활동일 N일 ≈ 풀타임 M개월 상당" 같은 괄호 환산을 쓸 때는 그 세션 길이 정의(CLAUDE.md "2~4시간 집중 단위")를 반드시 재확인한다.

재발 사례 기록 (문서에 남겨 재발 방지, 메인 세션 자가 지적):

메인 세션도 같은 유형의 실수를 했다 — designs/unity_version_strategy_2026-09-30.md:657에서 "실측 활동일 월 6.5일 → 약 32활동일(풀타임 1.5개월 상당)"이라고 서술했다. 이 괄호가 1일 8h를 암시해 ≈256h로 예산을 부풀렸다(동 :659 자체 정정 기록). 실제는 CLAUDE.md의 "세션 = 2~4시간 집중 단위" 정의에 따라 32활동일 = 32세션 = 64~128h다. 2.7배 과대(256h ÷ 평균 96h). 이 괄호 환산 자체가 R-U7-6(공수 문서 전반 5배 낙관)과 동일 계열의 오류이며, 같은 문서 안에서 발견·자가 정정까지 된 사례다 — 앞으로 "활동일 → 개월 상당" 괄호 환산을 쓸 때는 반드시 이 사례를 대조 확인한다.

연계 문서

• designs/unity_version_strategy_2026-09-30.md §12.1.2 R-U7-6 (본 발주 origin), §2(라인 322, 657~666) — 괄호 환산 2.7배 자가 정정 기록
• sprints/roadmap_v4_1_phases_2026-09-30.md §1(가정 A 원 산정, 미수정) §2(지표 A/B 정의)
• designs/combat_system_porting_strategy_v1_2026-05-05.md, designs/combat_system_core_assets_inventory_v1_2026-05-05.md (우선순위 1 원 출처, 미수정)
• designs/flatbuffer_3way_agreement_d_plus_2_pre.md, designs/flatbuffer_intermediate_layer_2026-05-18.md, designs/flatbuffer_poc_setup_2026-05-04.md (우선순위 2·4 원 출처, 미수정)
• designs/code-lead/unity_sp02_absorption_plan_v1.md (우선순위 3 원 출처, 미수정)
• CLAUDE.md "진행 원칙" 2번("1인 파트타임 현실 반영... 2~4시간 집중 단위") — §5 제안 문구의 근거