로드맵 v4.1 — Phase 구조 재편 (P3 분할 + Phase 7 날짜 미확정 + 정지율 KPI)
작성: 박세린 PM PD 발주: 2026-09-30, "U2 승인" (Phase 구조 재편) PD 결정 3건: 1. Phase 3 분할 승인 (P3a / P3b) 2. Phase 7 날짜 = (3) 정지율 KPI 후 재판정. 하드 날짜를 박지 않는다. 3. U1(Unity 6.7 LTS 직행)은 아직 미결정 — 문서에 확정 서술 금지 메인 세션 해석 메모(원 지시 인용): PD가 "U2"만 주고 3옵션 중 명시 선택을 안 했으나, Phase 4를 이미 날짜→산출물 트리거로 바꾼 결정(sprints/phase4_trigger_gate_2026-09-28.md)과 일관되고 가장 되돌리기 쉬운 선택이라 (3)으로 진행. PD가 뒤집으면 그때 갱신. — 본 문서는 이 해석을 그대로 승계한다. 근거 문서:designs/unity_version_strategy_2026-09-30.md(정현우, §4 로드맵 7단계 재판정 / §1 버전 전략 / §1.4 리스크) /sprints/roadmap_v4_0_2026-09-06.md(트랙 우선순위·2트랙 상한) /sprints/phase4_trigger_gate_2026-09-28.md(트리거 게이트 구조, 원본) /GodBlade_글로벌출시_로드맵.md(원 7단계, 2026-04-20) 정정 실측(코디네이터 보완, 2026-09-30): §2 정지율 KPI 정의를 지표 A(정지 구간)/지표 B(실제 활동일) 2종으로 재정의. 하단 §2 참조. 범위: 본 파일 1개만 신설.roadmap_v4_0/phase4_trigger_gate/roadmap_v3_0_closure/GodBlade_글로벌출시_로드맵.md수정 0, 중복 서술 대신 참조만. 프로토콜: Q→O→D→Dr→A. PD 결정 3건(위)은 잠금. 그 외 KPI 임계값·측정 방식은 박세린 설계 영역(PD 재검토 가능, 잠금 아님) — PD 51 원칙 준수.
§1 Phase 구조 v4.1 (8단)
기간 추정은 가정 A(지표 A, 정지 구간 49%)를 정현우 원 방법론 그대로 적용한 값이다. 이유와 대안(가정 B)은 표 아래 참조.
| Phase | 상태 | 성공 조건(측정 가능) | 기간 추정(가정 A 기준) | 선행 의존 |
|---|---|---|---|---|
| P1 현황 파악 | ✅ 완료 | Strike1/2/3 완료 — 625자산 분류·62.1% 생존·서버 29개 분류(※원문 "15개" 오류, §3) | 실적 완료 | — |
| P2 싱글 설계 | ✅ 완료(명칭 재정의만 남음) | GDD v1~v5 + v3.0 결정 13건 + 어픽스 35건 + 프레스티지 30항목 + 시즌 60일 + 200F 4.255 baseline 존재 | 실적 완료. 문서 명칭·범위 공식화는 윤서아/박세린 후속(일정 영향 0) | P1 |
| P3a 골격·파이프라인 | ✅ 완료(2026-04-21) | Unity6 신규 프로젝트(원본과 물리 분리) + URP 스캐폴드 + Importer 5종 + SO 6종 + MVP 캐릭터 5체 + Addressables 그룹 2개 + Tests.Editor 3종 — 전부 실측 존재 | 실적 완료 | P1, P2 |
| P3b 에셋·셰이더·씬 포팅 + LTS 고정 | ❌ 미착수 | Unity 6 LTS에서 메인 씬 + 전투 씬 1개 동작(원 로드맵 그대로) + 원본 에셋 import + URP 셰이더 이관 + 구 API(WWW/OnLevelWasLoaded/구 Input) 일괄 정리 + LTS 버전 고정 완료 | 원문 2~4개월 → 가정 A 반영 시 4~8개월 (2~4개월 ÷ (1-0.49)). U1 결정 전 착수 불가(§4) | P3a + U1 확정(미결정, §4) |
| P4 싱글 로직 리빌드 | ❌ 미착수(방향 유효) | "처음~중간 보스까지 싱글 플레이 가능"(원문). 착수 자체는 phase4_trigger_gate_2026-09-28.md T1~T4 게이트 충족 시 PD 재상정 | 실효 6~12개월(정현우 실측 보정, 풀타임 감각 "3~6개월" 아님) | P3b 완료 |
| P5 최소 백엔드 | ❌ 미착수(방향 유효, 문구 갱신) | 클라우드 세이브 동작 + 랭킹보드 1개 + Steam custom token 인증 경로 확보(Firebase 1급 미지원, 신규 미해결 항목) | 원문 2~4주 → Steam 인증 포함 시 1~2개월 | P4 |
| P6 로컬라이즈·폴리싱 | ❌ 미착수(선행조건 2건 추가) | 5개 언어 완전 로컬라이즈 빌드 + TMP pre-release(3.2.0-pre.10) 부채 해소 완료 + "하드코딩 텍스트 0" 규칙이 P4 착수 시점부터 이미 적용돼 있었음을 확인 | 2~3개월 | P4 |
| P7 출시·마케팅 | ❌ 미착수, 날짜 미확정(§2) | 목표 플랫폼 제출 완료 | 순작업 자체는 1~2개월이나 캘린더 고정 안 함 | P6, §2 정지율 KPI 재판정 |
순작업 합계(P3b~P7, 가정 A): 4~8 + 6~12 + 1~2 + 2~3 + 1~2 = 14~27개월. 착수 시점(2026-09-30) 기준 환산하면 2027-12 ~ 2029-06 — 날짜는 참고용 폭이며 §2에 의해 확정 짓지 않는다.
가정 A vs 가정 B — 왜 A로 계산했는지, B를 안 쓴 이유
이번 보완 실측으로 지표가 2종이 됐다(§2 정의 참조). 정현우의 "순작업 12~23개월"이라는 값 자체가 어떤 작업 강도(하루 몇 시간, 활동일당 투입)를 전제했는지 원문에 명시가 없다. 두 배수를 그대로 대입하면 결과가 크게 갈린다:
| 배수 근거 | 계산 | 배수 | P3b~P7 순작업 14~27개월(가정 A) 대비 |
|---|---|---|---|
| 가정 A (지표 A, 정지 구간 49%) | 1 ÷ (1-0.49) | 1.96배 | 본 표 채택값 |
| 가정 B 시도 (지표 B, 활동일 21.5%=35/163일) | 1 ÷ 0.215 | 4.65배 | 적용 시 순작업 12~23개월 기준 56~107개월(4.7~8.9년) — 비현실적으로 과대 |
가정 B를 캘린더 배수로 직접 쓰지 않은 이유: 지표 B의 "활동일"은 파일이 바뀐 날일 뿐 그날 몇 시간을 투입했는지는 안 잰다. 정현우의 "순작업 N개월"은 이미 정상 작업일 기준 산정치로 보이므로, 여기에 "활동일 비율"을 다시 곱하면 이중 할인이 된다(하루 1시간만 파일을 만져도 "활동일 1"로 잡히므로 분모가 과하게 작아짐). 반면 지표 A(정지 구간)는 "트랙 자체가 통째로 죽어 있던 날"만 세므로 순작업 산정치에 곱하는 용도로 더 정합적이다. 따라서 본 문서는 가정 A로 기간을 산정하고, 지표 B는 캘린더 배수가 아니라 §2의 전진 KPI(속도 추세 감시)로만 쓴다. 이 판단은 박세린 자율 설계 영역이며 PD 재검토 가능.
§2 Phase 7 = 날짜 미확정 + 정지율 KPI 게이트 (지표 A/B 2종 재정의)
왜 날짜를 박지 않는가
phase4_trigger_gate_2026-09-28.md §1의 근거를 그대로 승계한다 — "v4.0의 2트랙 상한 설계조차 날짜(재개 후 16일)만 지나면 무너졌다. 날짜는 이 프로젝트에서 신호가 아니라 소음이다." Phase 7은 P3b~P6 네 단계 전부가 미착수인 최종 단계이므로, 그 앞 네 단계 중 하나라도 날짜 기반으로 어긋나면 Phase 7 날짜는 자동으로 무의미해진다.
지표 A와 지표 B는 서로 다른 것을 잰다 — 혼용 금지
| 지표 A — 전 트랙 정지 구간 | 지표 B — 실제 활동일 | |
|---|---|---|
| 정의 | 프로젝트가 통째로 멈춘 구간의 일수 비율 | 파일 변경이 하루라도 있었던 날의 비율 |
| 실측 | 163일 중 80일 = 49% (7/4~9/6 64일 + 9/8~9/23 16일) | 163일(2026-04-20~09-30) 중 활동일 35일 = 21.5%, 무활동 128일(78.5%) |
| 월별(지표 B) | — | 4월 3일(507파일) / 5월 13일(305파일) / 6월 10일(105파일) / 7월 3일(55파일) / 8월 0일 / 9월 6일(18파일) → 월 평균 6.5일 ≈ 주 1.5일 |
| 용도 | 사고 기록·회고 전용 — Phase 기간 배수 산정(§1 가정 A) | 속도(velocity) 전진 KPI — Phase 7 재상정 게이트(아래) |
| 쓰지 말아야 할 것 | Phase 7 게이트 임계값으로 직접 사용(콘텐츠 볼륨형 게이트와 혼동 금지) | 78.5%를 "정지율"로 읽지 말 것 — PD는 1인 파트타임(본업 병행)이라 매일 작업 안 하는 것이 정상. 78.5%는 정지가 아니라 파트타임 기저선이다 |
지표 B를 78.5% 정지율로 과장하지 않는 근거: CLAUDE.md 개발 체제 "1인 파트타임 개발자(본업 병행)"가 전제이므로, 매일 활동이 없는 것 자체는 이상 신호가 아니다. 지표 B의 올바른 해석은 "이 프로젝트의 정상 속도 = 월 6.5활동일"이라는 기저선이며, 게이트는 이 기저선 대비 개선/악화 추세를 보는 데 쓴다(절대치 78.5% 통과/미통과가 아님).
정지율 KPI 게이트 — Phase 4 게이트 구조 재사용
phase4_trigger_gate_2026-09-28.md §2~§3의 "측정 방법 1줄 명령 + PD 세션 오픈 시 체크 + 연속횟수로 재판정 상정" 구조를 그대로 가져온다. Phase 4 게이트(T1 그림책편수/T2 웹소설화수 = 콘텐츠 볼륨)와 다른 점은, Phase 7 게이트는 프로젝트 전체 작업 소스(코드+설계+웹+웹소설+그림책, 단 빌드 산출물 제외)를 재는 속도 지표라는 것 — 이것이 Phase 4 게이트와 구별되는 유일한 설계 차이이며, 판정 형식·재상정 방식은 동일 재사용이다.
측정 명령 (코디네이터 실측 검증 완료, node_modules·out·Models 등 빌드/대용량 산출 디렉토리는 경로 자체에서 제외 — 대량 빌드가 활동일을 부풀리는 것 방지):
# 최근 30일 중 활동 있은 날 수 (지표 B, 30일 롤링)
(Get-ChildItem designs,sprints,web\scripts,web\public\picture-book,Unity6\Assets -Recurse -File `
| Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) } `
| ForEach-Object { $_.LastWriteTime.Date } | Sort-Object -Unique).Count
| 항목 | 값 |
|---|---|
| 기저선 | 월 6.5활동일(2026-04-20~09-30 실측, 30일 환산) |
| 개선 임계값 | 30일 중 활동일 ≥ 10일(기저선 대비 +54%, 주 2.3일 수준) — 절대적 고수준이 아니라 기저선 대비 유의미한 개선만 요구 |
| 판정 시점 | 날짜 예약 없음. PD가 세션을 열 때, 직전 측정으로부터 대략 30일 이상 경과했으면 위 명령 1줄 실행(Phase 4 게이트 §3과 동일 습관) |
| 재상정 조건 | 30일 측정이 연속 3회(≈90일에 걸쳐) 임계값(≥10일) 통과 시, 그 세션에서 박세린이 Phase 7 날짜(옵션 가/나/다, unity_version_strategy §4 원문)를 PD에 재상정 |
| 리셋 조건 | 연속 카운트 도중 1회라도 10일 미만이 나오면 카운트 0으로 리셋(재발 자체가 신호 — phase4_trigger_gate §6 "정체 카운트" 로직과 동일: 판정을 시도했는데 개선이 끊긴 경우만 리셋, 세션이 안 열려 판정 자체가 없었던 공백은 리셋 대상 아님) |
| 게이트 성격 | 재판정 상정 조건이지 착수 확정이 아니다. Phase 4 게이트와 동일 — 통과 시 PD에게 "다시 옵션으로 제시"되는 시점일 뿐 |
이 지표의 한계 — 반드시 같이 읽을 것
- mtime은 프록시일 뿐이다. 생각·조사·PD의 판단·구두 결정은 파일을 만들지 않는다. 활동일 0일이 곧 "아무 일도 안 했다"를 증명하지 않는다 — 반대로 "10일 통과"가 곧 유의미한 진전을 증명하지도 않는다(사소한 파일 1건 저장도 활동일 1로 잡힘).
- 대량 빌드 산출은 활동일을 부풀린다. 위 명령이
node_modules/out/Models등을 경로에서 애초에 제외한 것은 이 때문이다. 향후 새 빌드 산출 폴더가 생기면 같은 이유로 경로 목록에서 배제해야 한다.
Phase 4 게이트와의 관계
별개 게이트다. Phase 4 T1~T4가 다 통과해도 지표 B 게이트가 미통과면 Phase 7 날짜는 그대로 미확정. 반대로 지표 B가 3연속 통과했는데 Phase 4가 아직 착수도 안 됐다면, Phase 7 재상정 시 옵션(나)(기간 재설정) 또는 (다)(추가 관찰)만 현실적 — 이 판단은 재상정 시점에 박세린이 잔여 순작업(§1 합계, 그때 가정 A/B 재확인 포함)을 실측으로 재계산해 옵션과 함께 낸다.
§3 로드맵 원문 오류 정정 기록
| # | 위치 | 원문 | 정정 | 근거 |
|---|---|---|---|---|
| 1 | GodBlade_글로벌출시_로드맵.md Phase 1 항목 4 | "서버 15개 역할 분류" | 서버 29개 | Phase 1 Strike 완료 실측, CLAUDE.md "서버 29개 프로젝트" 기재와 정합. unity_version_strategy_2026-09-30.md §4 판정 집계 "원문 수치 오류 2건" |
| 2 | GodBlade_글로벌출시_로드맵.md Phase 5 항목 6 | "기존 C# 서버 15개는 _archive_2021/로 이동" | 항목 자체 폐기. 서버 개수도 29개로 오기 | CLAUDE.md 진행 원칙 1 "원본은 절대 수정 금지 — Program/은 2021 스냅샷" 정면 위반. 원본 read-only 원칙 우선 |
두 항목 모두 GodBlade_글로벌출시_로드맵.md 원문 자체는 수정하지 않는다(범위 제약). 본 표가 정정 기록의 유일한 출처이며, 이후 원문 참조 시 이 표를 우선한다.
§4 U1(Unity 버전 전략) — 미결정 표시
U1은 확정되지 않았다. 정현우는 designs/unity_version_strategy_2026-09-30.md §1.3에서 (c) 6.7 LTS 단일 직행 + 2027-01~02 이동 창 + 2026-12-31 확인 게이트를 권고했으나, 이것은 권고이지 PD 결정이 아니다. PD 51 원칙(잠금 금지, 미래 결정은 옵션 재제시)에 따라 본 문서는 이를 확정으로 서술하지 않는다.
- §1 P3b의 "LTS 고정" 항목은 U1 미결정에 물려 있다. U1이 정해지기 전에는 P3b 착수 자체가 불가 — 어느 버전으로 셰이더·API를 이관할지가 정해지지 않은 상태에서 포팅을 시작하면 재작업 리스크(정현우 표현: "2단 이동 = 2배 비용")가 실현된다.
- 현재 상태:
6000.4.3f1(6.4, 비-LTS, 2026-06-17 EOL) 유지 중. 정현우 표현으로 "무기한 방치(a)가 아니라 조건부 동결"이나, 이 구분 자체가 U1을 (c)로 결정했을 때만 성립하는 조건이다. U1이 아직 안 정해졌으므로 현재는 사실상 (a)와 구분되지 않는 상태로 취급해야 한다. - 옵션 4건(원문
unity_version_strategy§1.2 그대로, 재정리 없이 참조): - (a) 6.4 무기한 유지 — 정현우 폐기 권고
- (b) 6.3 LTS 즉시 이동 — 정현우 "중간 기착지로만 유효, 최종 출시 버전 부적합"
- (c) 6.7 LTS 직행(2027-01~02 이동) — 정현우 권고, PD 미결정
- (d) Unity 7 목표 — 정현우 반대 권고
- 본 문서는 (c)를 채택하지 않는다. P3b 표의 "LTS 고정"은 "어느 버전이든 U1 확정 후 고정"으로만 읽는다.
§5 2026-12-31 Unity 6.7 LTS 확인 점검 — 제안 (phase4_trigger_gate 파일 수정 0)
정현우 경고(unity_version_strategy_2026-09-30.md §8, R-U6-2): "이 트리거가 유일한 안전장치이며, 아무도 확인하지 않으면 동결이 무기한 방치로 퇴화한다." U1이 아직 미결정이므로 이 점검은 U1 결정과 별개로 지금부터 예약해 둔다 — "확인"은 결정이 아니다.
sprints/phase4_trigger_gate_2026-09-28.md는 본 발주 범위상 수정하지 않는다. 대신 그 파일 §3 체크리스트에 다음 1줄을 얹을 수 있는 형태로 제안만 한다(적용은 별도 승인 필요):
[ ] (Phase4 게이트와 무관, 독립 점검) 2026-12-31 도래 시 Unity 6.7 LTS 정식 출시 여부 확인
→ 출시 확인 시: U1 옵션(c) 채택 여부 PD 재상정
→ 미출시 시: U1 옵션(b) 6.3 LTS fallback 즉시 실행 여부 PD 재상정 (unity_version_strategy §1.4 R-U6-2)
이 항목은 Phase 4 T1~T4 AND 게이트, §2 정지율 KPI 게이트 어느 쪽에도 포함되지 않는다 — 독립된 확인 항목이다. Phase 4/§2 게이트는 우리 쪽 산출물(콘텐츠 볼륨·속도)을 묻지만, 이 항목은 "Unity 6.7이 세상에 나왔는가"라는 외부 사실 확인이라 성격이 다르다. 날짜(12/31)는 여기서 예외적으로 유지한다 — 결정 날짜가 아니라 "제3자(Unity사) 사실이 발생했는지 확인하는" 관찰 날짜이기 때문이며, PD 51 원칙이 금지하는 것은 우리 쪽 착수·완료를 날짜에 묶는 것이지, 외부 사실 확인 일정을 잡는 것이 아니다.
PD 1쪽 요약
Phase 8단 상태
- P1 현황파악 — 완료
- P2 싱글설계 — 완료(명칭 재정의만 잔존)
- P3a 골격·파이프라인 — 완료(2026-04-21)
- P3b 에셋·셰이더·씬 포팅+LTS고정 — 미착수, U1 확정 전 착수 불가
- P4 싱글로직 — 미착수, Phase4 게이트(T1~T4) 대기 중(현재 1/4 통과)
- P5 백엔드 — 미착수, Firebase Steam 인증 경로 신규 미해결
- P6 로컬라이즈 — 미착수, TMP pre-release 부채 선행 해소 필요
- P7 출시 — 미착수, 날짜 미확정(§2 정지율 KPI 재판정 대기)
Phase 7 재판정 조건: 두 지표 구분 사용. 지표 A(정지 구간 49%)는 §1 기간 산정 배수로만 사용(사고 기록용), 지표 B(30일 활동일, 기저선 월 6.5일)가 실제 게이트 — 30일 중 활동일 ≥10일이 연속 3회(약 90일) 확인되면 그 세션에서 날짜 옵션(가/나/다) 재상정. 78.5%는 정지율이 아니라 파트타임 기저선이므로 그 자체를 임계치로 쓰지 않음.
U1 대기 항목: Unity 버전 전략 미결정. 정현우 권고는 (c) 6.7 LTS 직행이나 PD 확정 아님. P3b 전체가 이 결정에 물려 있어 U1 없이는 착수 불가.
12/31 점검 제안: Unity 6.7 LTS 정식 출시 여부 확인 1줄을 phase4_trigger_gate §3에 얹는 제안(그 파일 자체는 미수정). 목적은 U1 결정이 아니라 "동결이 방치로 퇴화하는 것" 방지.
정정 2건: 원문 "서버 15개"→29개(2곳), P5 "C# 서버 archive 이동" 항목 폐기(원본 read-only 위반).