Unity 버전 전략 + 로드맵 7단계 재판정 (2026-09-30)

개정 이력

v1.1 로 판단이 바뀐 근거 (조정자 조사 + 본인 교차 검증)

출처: Path to CoreCLR, 2026 Upgrade Guide · Unite Seoul 2026 Keynote Recap · Unity 7 · Project Auditor introduction (6000.4 매뉴얼) · Burst 1.8 CHANGELOG · Unity 7 roadmap (Game Developer)

작성: 정현우 (code-lead) / 발주: PD / 상태: 분석·권고 (코드 변경 0, 업그레이드 실행 0) 판정 기준일: 2026-09-30 / 로드맵 원문 작성일 2026-04-20 (163일 경과) 산출 제약: 본 파일 1개만. 다른 파일 수정 0 (Karpathy Surgical Changes) PD 51 원칙 준수: 미래 결정은 잠금 X. 단 §1 버전 전략은 권고 1개 명시.

0. 브리핑 사실 정정 2건 (먼저 읽어주십시오)

메인 세션이 넘긴 외부 사실은 대부분 정확했습니다. 다만 판단을 바꾸는 오차 2건이 있어 먼저 정정합니다.

정정 1 — 우리가 걱정할 EOL 은 6.0 LTS(10/16) 가 아니라 6.4 (이미 3.5개월 전 종료)

브리핑은 "Unity 6.0 LTS 보안 지원 종료 2026-10-16 (16일 뒤)" 를 리스크로 제시했습니다. 그런데 우리는 6.0 LTS 에 없습니다. 6000.4.3f1 = 6.4 = 비-LTS Update 릴리스이고, Unity 의 비-LTS 지원 정책은 "다음 릴리스가 나올 때까지" 입니다.

출처: endoflife.date/unity, Unity 6 Releases & Support

의미: 옵션 (a) "6.4 유지" 는 "지원받는 버전에 머무르는 선택" 이 아니라 이미 무지원 상태를 연장하는 것입니다. 이 사실이 §1 의 결론 구조를 바꿉니다.

정정 2 — Unity 7 은 domain reload 를 "도입" 하는 게 아니라 "전체 재로드를 없애는" 것

브리핑 문구 "domain reload 도입" 은 뒤집혀 있습니다. Unity 는 이미 스크립트 변경마다 domain reload 를 합니다 — 그게 Play Mode 진입이 느린 원인입니다. Unity 7 의 변화는 전체 도메인 재로드를 증분/부분 재로드로 대체하는 것입니다. 그리고 그 가속 일부(Fast Enter Play Mode 계열)는 Unity 7 이 아니라 6.6 에 먼저 들어옵니다.

출처: Unite Seoul 2026 Keynote Recap, Unity is replacing Mono with CoreCLR

의미: "CoreCLR 를 얻으려면 Unity 7 로 가야 한다" 가 아닙니다. 실익의 상당 부분은 6.x LTS 에서 취할 수 있고, 우리가 스스로 코드 규칙으로 취할 수 있는 부분도 있습니다 (§2, §6-2).

v1.1 보정: 이 정정 자체는 유효합니다. 다만 거꾸로 읽으면 안 됩니다 — 신규 사실 ② 에 따라 CoreCLR 자체를 피할 수는 없습니다 (6.7 LTS 가 마지막 Mono, 다음 릴리스 = Unity 7 에서 Mono 소멸). 즉 "Unity 7 로 가지 않아도 CoreCLR 이득 일부는 얻는다"는 참이지만, "CoreCLR 을 안 받을 수 있다"는 거짓입니다. 그리고 "6.8" 은 별도 릴리스가 아니라 Unity 7 의 개명 전 이름입니다 (2025-12 전면 재작성 계획 취소 후). 따라서 우리가 갈 수 있는 정류장은 6.7 LTS 가 마지막입니다.

1. 버전 전략 — v1.1 확정: (d) Unity 7 / 4단계 경로 S0~S4 (PD U1 결정)

1.1 우리 실측 (PD 브리핑 재확인 + 추가 측정)

⭐ 중요 발견: URP 에셋에 Compatibility Mode 키가 없습니다 = Render Graph 기본 경로. Unity 6.3 LTS 에서 URP Compatibility Mode 가 완전 제거되었으므로(Upgrade to Unity 6.3 LTS), 6.3 이상으로 올릴 때 가장 큰 URP 블로커는 이미 통과한 상태입니다. 이동 비용 추정을 낮추는 유리한 사실입니다.

1.2 4 옵션 비용·리스크 비교

출시 목표 2028-01 을 각 지원 종료일과 겹쳐서 봅니다.

Unity 의 "zero rebuilding" 은 Unity 마케팅 문구이고 우리가 검증한 사실이 아닙니다. 아키텍처 직접 연장이라는 주장은 신뢰할 만하나, 우리 프로젝트에서 실제로 무엇이 깨지는지는 아무도 모릅니다. 1인 파트타임이 그 첫 검증자를 자원할 이유가 없습니다.

v1.1 주의: 위 §1.2 표의 판정 열은 v1.0 시점 판단이며 v1.1 §1.3 으로 대체되었습니다. 특히 (c)와 (d)를 "대안"으로 놓은 전제가 신규 사실 ①로 무효화되었습니다 — 둘은 순서입니다. 표의 지원 커버·이동 비용·리스크 열은 사실이므로 그대로 유효합니다.

1.3 v1.1 확정 — (d) Unity 7 타깃 / 4단계 경로 S0~S4

PD U1 결정 (2026-09-30): Unity 7 로 간다. 방향은 확정이며 본 문서는 재론하지 않습니다. 문제는 "갈지" 가 아니라 "오늘 존재하지 않는 엔진에 EOL 상태에서 어떻게 안전하게 도달하는지" 입니다. 오늘 Unity 7 은 없습니다 (베타 2026-12, 정식 Q1 2027). 우리는 EOL 6.4 에 있습니다. 그래서 단일 점프가 아니라 4단계로 쪼갭니다.

경로 한 줄: 6.4 (EOL, 지금) → S0 사전 감사 → S1 6.7 LTS (마지막 Mono = 베이스캠프) → S2 같은 6.7 LTS 에서 CoreCLR 실험 플레이어로 float A/B → S3 Unity 7 베타 평가만 → S4 Unity 7 정식 채택

⚠️ 되돌릴 수 없는 문이 하나 있습니다. Mono 는 Unity 7 에서 옵션으로도 남지 않습니다(신규 사실 ②). 즉 롤백 가능 창은 S4 진입 직전까지만 존재합니다. S2 의 float 검증이 그 문을 넘기 전 마지막 관문이고, 그래서 이번 개정의 핵심을 §9 에 뒀습니다.

## 🛑 v1.2 — 아래 S0~S4 표는 폐기되었습니다 PD 추가 지시 (2026-09-30): "이건 없고 이제 처음부터 최신 버전 unity 7 로 개발" / "6.7 LTS 이동 이건 없애도 됨." | 단계 | v1.2 처분 | |---|---| | S1 (6.7 LTS 경유) | 폐기 — PD 지시 | | S2 (Mono ↔ CoreCLR float A/B) | 폐기 — 비교 대상 소멸 (§12.4 에서 V1·V2 로 대체) | | S0 (사전 감사) | 부분 승계 — Project Auditor 는 §12.3 에서 성격 변경, golden-vector 하네스는 §12.4 로 승계 | | S3 (Unity 7 베타 평가) | 승계 + 성격 변경 — "평가만" 이 아니라 개발 시작점이 됨 (§12.1 이 이 변경의 대가를 계산) | | S4 (Unity 7 정식 채택) | 승계 — 다만 "채택"이 아니라 "정식 전환" | 아래 S0~S4 표와 §9 의 S2 관련 서술은 판단 이력으로만 읽으십시오. 유효한 경로는 §12 입니다. §1.1 실측 / §1.2 지원 종료일 / §1.4 리스크 / §2 CoreCLR 실익 / §3 패키지 / §4 로드맵 / §9.1~9.4 의 float 사실·노출면 실측·fallback 4안 은 전부 유효합니다 (엔진 선택과 무관한 사실이므로).

S4 와 2027-04 Phase 4 스토어 제출이 정면으로 겹칩니다. PD 결정이 필요한 유일한 잔여 항목입니다:

.0f1 을 바로 쓰지 않는 이유 (S1·S4 공통): 6.0 LTS 는 현재 6000.0.84f1 = 84 패치, 6.3 LTS 는 6000.3.24f1 = 24 패치. LTS·메이저 초기 릴리스는 통상 6~10주 안정화가 필요합니다. .0f1 에 올라타면 우리가 Unity 의 QA 를 대신합니다.

(v1.0 이력) 조건부 동결의 정의 — S0 에 그대로 승계됩니다

(a) 무기한 방치와 다른 점:

왜 지금 6.3 으로 안 가고 기다리는가 (2단 이동을 버리는 이유):

1. 지금부터 2027-02 까지 Unity 트랙에서 할 일은 게임플레이 0 → 설계·데이터 파이프라인이며, 이는 에디터 버전과 무관합니다 (TSV/FlatBuffer 스키마, SO 설계, 테스트 설계 = .md + C# 소스 레벨).
2. 6.4 EOL 의 실질 위험은 스토어 제출 시점에만 발생합니다. 우리는 2027-04 Phase 4 이전 제출 계획 0 → 2027-02 이동은 충분히 선행.
3. 2단 이동(6.3 → 6.7)은 URP 승격을 두 번, 패키지 일괄 갱신을 두 번 겪습니다. 1인 파트타임에 2배 비용 + 2배 회귀 리스크. Unity 트랙은 4/21 이후 기능 진전 0 — 이동 작업이 두 번 수행될 확률은 한 번 수행될 확률보다 현저히 낮습니다.
4. 이동 비용은 자산이 스캐폴드라서 지금과 2027-01 사이에 큰 차이가 없습니다 (동결 중 작업 범위를 §1.3 표대로 제한하는 조건 하에).

.0f1 회피 논거: v1.1 §1.3 으로 이동 (S1·S4 공통 적용).

1.4 리스크 재등록 (v1.1, 박세린 PM)

v1.0 의 R-U6-1~4 를 (d) 기준으로 갱신하고 Unity 7 고유 리스크 3건을 신설합니다.

R-U6-4 의 성격이 바뀌었습니다. v1.0 에서는 "미검증 추정이므로 (d) 반대 근거"로 썼습니다. v1.1 에서는 확정 사실이지만 완화 가능한 리스크입니다 — 같은 Unity 문서가 IL2CPP is not affected 를 명시했고, 우리 출하 경로가 바로 IL2CPP 입니다. 반대 근거가 아니라 관리 대상으로 전환합니다. 상세는 §9.

2. CoreCLR / domain reload 가 1인 파트타임에 주는 실익

2.1 추정 (계산 근거 명시 — 이하 수치는 추정입니다)

현재 프로젝트 규모: C# 24 파일 / 7,827 LOC / 패키지 9개 / asmdef 3종.

이 규모에서 스크립트 컴파일 + domain reload = 회당 3~8초 수준으로 추정합니다. 참고로 제가 리드한 서머너즈워 Unity 6 마이그레이션은 50만 LOC 에서 30~60초였습니다 — 우리는 그 1.5% 규모입니다. 이 비교가 중요합니다.

2.2 결론 — 실익 있지만 버전 전략을 바꾸지 않습니다

우리 병목은 컴파일 시간이 아닙니다. 세션 간 공백입니다.

• 로드맵 작성 2026-04-20 → 현재 163일 경과
• Unity 트랙 최종 기능 커밋 2026-04-21 → 기능 진전 0일
• 전 트랙 정지 2회: 7/4~9/6 64일 + 9/8~9/23 16일 = 80일 (163일 중 49%)

세션당 2분 회수는 163일 공백 앞에서 무의미합니다. 그 2분을 얻기 위해 메이저 .0 런타임 교체 리스크(§1.2 (d), R-U6-4)를 지는 것은 비용/편익 역전입니다.

2.3 단, Phase 4 시점에는 재계산이 필요합니다

Phase 4 (싱글 로직 리빌드) 에서 코드량이 7,827 → 8만 LOC 수준으로 10배 늘면:

6~12% 는 무시할 수 없습니다. 그 시점(2028년)에 Unity 7 은 이미 1년+ patch 누적 상태입니다. → 2028년 중반 라이브 유지보수 단계에서 Unity 7 재평가 슬롯을 두는 것이 맞습니다. 지금 채택할 이유는 아닙니다.

2.4 CoreCLR 을 기다리지 않고 지금 회수하는 방법 (권고)

6.6 이상에서 Fast Enter Play Mode (Domain Reload / Scene Reload 끄기) 를 켜면 CoreCLR 없이도 진입 시간의 대부분을 회수합니다. 다만 이건 코드가 static 상태에 의존하지 않아야 켤 수 있습니다.

지금 우리 Runtime 코드는 5 파일뿐입니다. Phase 4 에서 게임플레이 로직을 쓰기 전에 규칙을 박으면 비용 0 입니다. 나중에 8만 LOC 에서 static 상태를 걷어내는 비용은 수십 시간입니다.

→ §6 즉시 할 일 2번으로 올립니다. 버전 무관, 지금 가능, CoreCLR 기다리는 것보다 회수가 큽니다.

2.5 (v1.1 추가) Fast Enter Play Mode 는 이제 선택이 아니라 의무입니다

신규 사실 ⑤: Fast Enter Play Mode 는 6.6 부터 신규 프로젝트 default이고, Unity 7 시점에는 유일한 옵션입니다. Domain Reload 를 켜 두는 선택지가 사라집니다.

즉 §2.4 가 v1.0 에서 "선택적 선행 투자" 였던 것이 (d) 결정과 함께 S4 진입의 전제조건이 되었습니다. 다행히 2026-09-30 자로 이미 이행 완료했습니다 (PD U3 승인 → 별도 보고):

• static 가변 상태 감사 24파일 전수 → 위반 0건 (Runtime 5파일에 static 이 하나도 없음)
• SO [NonSerialized] lazy 캐시 3종이 Domain Reload 끔 상태에서 stale 서빙되는 문제 발견 → IRuntimeCacheOwner + [InitializeOnEnterPlayMode] 훅으로 차단
• asmdef 4종 규칙 문서화 (Unity6/Assets/Editor/FAST_ENTER_PLAYMODE_RULES.md)
• ProjectSettings/EditorSettings.asset 은 건드리지 않음 (승인 범위 밖 + 컴파일·실행 검증 불가) → 옵션 실제 활성화는 PD 확인 후 별건

S0 추가 검증 항목: §10 Project Auditor 의 Domain Reload 탭이 제 정적 감사(위반 0건)를 Unity 도구로 교차 확인해 줍니다. 1인 체제에서 얻기 어려운 독립 검증이라 S0 의 실질 산출물로 잡습니다.

3. 패키지 갱신 우선순위 (모바일 iOS/Android 실효 기준)

3.1 원칙 — 에디터 이동(6.7 LTS)과 한 번에

지금 패키지만 올리면 EOL 에디터(6.4) + 최신 패키지 = Unity 가 검증하지 않은 조합입니다. 리스크만 늘고 얻는 게 없습니다. 예외는 §3.3 (즉시 처리할 부채 2건).

v1.1 예외 추가 — Project Auditor: 6.4 에는 에디터 Module 로 내장되어 있어 패키지 설치가 필요 없습니다(신규 사실 ④). 즉 S0 에서 쓰는 도구는 이 §3.1 원칙의 적용 대상이 아닙니다. 상세 §10.

3.2 6.7 LTS 이동 시 동시 적용 (우선순위)

Addressables 2.2.2 → 2.7 구간에 치명적 breaking change 는 확인되지 않았습니다. Analyze Rule toolset / Event Viewer API 는 2.0.3 에서 이미 제거되었으므로 우리(2.2.2)에게는 해당 없습니다. 출처: Addressables 2.7 CHANGELOG

3.3 동결 기간에도 지금 처리할 부채 2건 (에디터 이동과 무관)

1. activeInputHandler: 2 (Both) → New 단독으로 좁히기. 레거시 Input 경로가 열려 있으면 모바일 빌드에 불필요한 오버헤드가 남습니다. 지금 게임플레이 로직이 0 이라서 깨질 것이 없는 유일한 창입니다. Phase 4 이후에는 위험한 변경이 됩니다. → §6 즉시 할 일 3번
2. TMP pre-release 부채 티켓 등록. 지금 교체하지 않되, Phase 6 진입 게이트로 박습니다.

3.4 6.7 LTS 이동 시 함께 적용할 2가지 (6.3 LTS 신규 기능)

• pinnedPackages (6.3 LTS 신규 — 직접 의존 패키지 버전 고정). 우리 패턴에 정확히 필요합니다: 세션 간 공백이 길고, Unity 가 패키지를 자동 resolve 해 manifest 를 바꿔버리는 사고가 이미 한 번 발생했습니다 — 커밋 a9cce41 chore: Unity auto-regenerated packages-lock.json and ProjectSettings after package resolve. 이동 시 필수 적용.
• URP Settings Analyzer (Project Auditor 모듈 — 모바일 URP 설정 오류 자동 검출). 1인 체제에 정확히 맞는 도구입니다.

실측 플래그 (판정은 한지우 graphics-lead 영역이므로 제가 결정하지 않고 넘깁니다): m_SupportsHDR: 1 (모바일 HDR on — 재검토 대상), m_MSAA: 1, m_ShadowCascadeCount: 1, m_RenderScale: 1.

4. 로드맵 7단계 재판정

판정: 유효 2 / 수정 5 / 폐기 0 (+ 세부 항목 폐기 1건)

Phase 1 — 현황 파악 (2~4주) → 유효 (완료)

Strike 1/2/3 완료 (625 자산 분류, 62.1% 생존), 서버 29개 분류 (22개 폐기 확정), graphify 지식 그래프 구축. 명칭만 정정: 로드맵이 지정한 산출물 GodBlade_현황지도.md 는 실제로 Phase1_Strike1/2/3_*.md 로 대체되었습니다. 로드맵 Phase 1 항목 4 의 "서버 15개" 는 실제 29개 — 원문 수치 오류.

Phase 2 — 싱글 전용 설계 (2~3주) → 수정

로드맵은 "2~3주 / GDD v1 1건" 이었으나 실제로는 과잉 달성: GDD v1~v5 + v3.0 결정 13건 + 어픽스 35건 + 프레스티지 30항목 + 시즌 60일 + 200F 4.255 baseline + 무한던전/프레스티지/방치/어픽스/시즌 설계 APPROVED. 반대로 로드맵 원래 항목 중 "진행 구조 재설계 (오픈월드/챕터/스테이지)" 와 "글로벌 시장 호환성 점검" 은 방치형 RPG + 무한던전 확정으로 대체되어 원문 형태로는 수행되지 않았습니다. → 내용상 완료. 문서 명칭·범위 재정의 필요 (윤서아 game-designer / 박세린 PM 영역, 제 판정 범위 아님).

Phase 3 — Unity 6 LTS 마이그레이션 (2~4개월) → 수정. "완료" 로 볼 수 없습니다 ⚠️

이번 분석의 핵심 정정입니다. PD 질문 "P3 를 완료로 볼 수 있는지" 에 대한 답은 아니오입니다.

로드맵이 정의한 Phase 3 성공 조건 = "Unity 6 에서 메인 씬 + 1개 전투 씬 동작".

실제로 완료한 것은 "Unity 6 신규 프로젝트 골격 + URP 스캐폴드 + SO 데이터 파이프라인(Importer 5종/SO 6종) + MVP 캐릭터 5체 + Tests.Editor 3종" 입니다. 7,827 LOC 중 Runtime 게임플레이는 5 파일(SimpleCharacterController, SimpleFollowCamera, PartAttacher, SmokeTester, MilestoneGranter)뿐입니다.

추가로 "Unity 6 LTS" 라는 조건 자체를 현재 위반 중입니다 (6.4 = 비-LTS, EOL — §1.1).

권고: Phase 3 을 둘로 분할

P3b 기간은 원문 2~4개월이 그대로 남아 있고, 오히려 상향해야 합니다. 원본 클라이언트가 2019.4.11f1 이고 625 자산 중 62.1% 생존 = 실제 import 대상이 큽니다. 원본 API 잔재(WWW, 구 Input, OnLevelWasLoaded)는 아직 한 건도 손대지 않았습니다.

Phase 4 — 싱글 로직 리빌드 (3~6개월) → 유효 (미착수)

방향·항목 모두 유효합니다. 특히 항목 1("서버에서 처리하던 전투 검증 → 클라 SO + 매니저")은 project_server_no_combat_logic.md 의 실측(원본 서버에 전투 계산 로직 없음)과 정합합니다 — 제 철학 2 그대로입니다.

다만 "3~6개월" 은 풀타임 감각입니다. 1인 파트타임 + 실적(163일 중 80일 전 트랙 정지 = 49%)을 반영하면 실효 6~12개월로 봐야 합니다. 낙관 금지 원칙상 명시합니다.

항목 5("밸런스 데이터를 SO 또는 CSV로 분리")는 이미 v3.0 #3 결정으로 FlatBuffer 중간 레이어(Datasheets/TSV → .fbs → Unity SO + Phaser JSON 동시 export) 로 상향되었습니다 → 로드맵 문구 갱신 대상.

Phase 5 — 최소 백엔드 (2~4주) → 수정

Firebase 결정은 아직 맞습니다. 단 로드맵 문구가 낡았습니다.

• 로드맵 항목 1: "Firebase vs Supabase 결정 (기본 추천 Firebase)" → 이미 종결되었으나 결론이 "둘 중 하나" 가 아닙니다. v3.0 #3 DB 통합 결정 = Firestore = 게임 진실 영구 단일 source / Supabase = 웹 메타·UGC·결제 / FlatBuffer = Datasheets 동시 임베드. "vs" 가 아니라 경계가 분리된 병행입니다. PD 질문 "웹 트랙은 Supabase 를 쓰는데 Firebase 결정이 맞나" 에 대한 답: 충돌 아님. 의도된 분리입니다.
• Firebase 를 게임 측에 유지하는 근거: Firestore 의 모바일(iOS/Android) SDK 성숙도 + 오프라인 캐시가 방치형 RPG 세이브 패턴에 맞습니다. 웹 트랙은 Supabase 로 이미 진행 중이므로 교체 비용이 큽니다.
• ⚠️ 미해결 플래그: Steam 플랫폼 인증은 Firebase 가 1급 지원하지 않습니다 → custom token 경로가 필요합니다. 우리 목표 플랫폼에 Steam 이 있으므로 이건 실제 작업 항목입니다. Firebase/백엔드는 제 약점 영역이므로 김민준(web-lead) 협업 + Firestore schema 작성은 김민준 담당으로 넘깁니다.
• 로드맵 항목 6 "기존 C# 서버 15개를 _archive_2021/ 로 이동" → 폐기. CLAUDE.md 철학 3(원본 Program/ = SVN 2021 스냅샷, read-only) 과 정면 충돌합니다. 원본은 옮기지 않습니다. 또 "15개" 는 실제 29개 — 원문 수치 오류.
• 기간 "2~4주" 는 인증(Steam custom token 포함) + 클라우드 세이브 충돌 해결 정책까지 넣으면 낙관치입니다.

Phase 6 — 로컬라이즈 & 폴리싱 (2~3개월) → 수정

내용·항목 모두 유효합니다. 두 가지 선행 조건을 추가 권고합니다:

1. TMP 3.2.0-pre.10 (pre-release) 를 물고 CJK 5개 언어 폰트 아틀라스 작업에 들어가면 안 됩니다 (§3.2 P2). Phase 6 진입 게이트로 박습니다.
2. "하드코딩 텍스트 0" 은 Phase 6 이 아니라 Phase 4 코드 작성 규칙으로 앞당길 것. 로드맵 Phase 6 항목 2 는 "모든 하드코딩 텍스트 → 키 기반 추출" = 사후 추출입니다. 8만 LOC 에서 사후 추출 비용은 처음부터 키로 쓰는 비용의 10배입니다. 제 영역이므로 Phase 4 착수 시 규칙으로 박겠습니다.

Phase 7 — 출시 (1~2개월) → 수정

기간 산술로는 2028-01 이 성립합니다. 실적 기반으로는 성립하지 않습니다.

여기에 실적 정지 비율(163일 중 80일 = 49%)을 반영하면 2028-04 ~ 2029-08. 정지율을 절반(25%)으로 개선한다고 가정해도 2028-01 ~ 2029-01.

2028-01 은 정지율 0% 를 가정한 낙관치입니다. 날짜 재설정은 PD 결정 사항이므로 제가 잠그지 않습니다 (PD 51 원칙). 옵션만 제시합니다:

• (가) 2028-01 유지 + 범위 축소 (5개 언어 → 2개 언어 1차 출시, Steam 선행 / 모바일 후행)
• (나) 2028-04 ~ 2028-10 로 재설정 + 범위 유지
• (다) 정지율 목표를 KPI 로 박고 (예: 분기당 정지 ≤ 14일) 6개월 후 실적으로 재판정

판정 집계

5. Unity AI 도입 여부 → 권고: 보류 (도입 X)

5.1 확인한 사실

• Unity AI = Muse 후계. Unity 6.2 에서 rollout. Muse 실험 패키지는 sunset, Sentis 는 Inference Engine 으로 존속.
• Unity Personal: 14일간 1,000 credit 무료 트라이얼 → 이후 $10/월 1,000 credit.
• Pro/Enterprise/Industry 는 agentic assistant 를 구독에 포함.
• Unity AI 는 Unity 자체 모델이 아니라 third-party 모델을 사용합니다.
• Unity Personal 무료 기준 매출/펀딩 $200K (2024-10-17 $100K→$200K 상향) → PD 해당 없음.

출처: Unity rolls out Unity AI in Unity 6.2, Unity AI features, Unity Plans & Pricing

5.2 용도별 판정

5.3 도입 결정 전 확인이 필요한 라이선스·약관 항목 (제가 확정할 수 없는 것)

1. 생성물의 상업 사용 권리 및 소유권 — Unity AI 가 third-party 모델을 쓴다고 명시되어 있습니다. 모델별 학습 데이터·상업 라이선스 조건이 Unity 약관에 어떻게 승계되는지 확인 필요.
2. 생성 에셋을 최종 출하 빌드에 포함할 때의 조건 — "플레이스홀더 전용" 제한이 있는지.
3. credit 소진 정책 — 1,000 credit 이 실제 몇 번의 생성인지, 이월 여부.
4. Personal $200K 기준 초과 시 AI 구독이 Pro 로 강제 전환되는지.
5. ⚠️ 프로젝트 코드·에셋이 컨텍스트로 업로드되는 범위 — 이게 가장 중요합니다. PD 전역 규칙("작업 비노출 규칙", 2026-09-08 제정: 사용자 작업 산출물을 명시 요청 없이 외부에 전송 금지)과 충돌 가능성이 있습니다. 특히 원본 Program/ 2021 스냅샷이 컨텍스트로 올라가면 안 됩니다.

5.4 권고

Unity AI 도입 보류. 근거: ① 코드 리팩터는 Claude Code 와 중복 지불, ② 에셋 생성은 한지우 파이프라인과 중복, ③ Sentis 는 현 용도 0, ④ §5.3-5 가 PD 작업 비노출 규칙과 충돌 가능. 월 $10 은 작은 금액이지만, 얻는 것이 없습니다. 예외 경로: 14일 무료 트라이얼로 "플레이스홀더 에셋" 단일 용도만 PoC 하는 것은 가능. 단 §5.3-5 (원본 코드 컨텍스트 차단) 확인이 선행 조건이며, PD 승인 필요.

6. 즉시 할 일 top 3 (모두 버전 업그레이드 실행 아님 — 제약 준수)

v1.1 갱신. v1.0 의 3건 중 2번(Fast Enter Play Mode 규칙)은 2026-09-30 이행 완료(§2.5), 3번(activeInputHandler + TMP)은 PD 별건 보류 상태 그대로입니다. (d) 결정으로 1번을 아래로 교체하고 Project Auditor 를 신규 1위로 올립니다.

1. ⭐ Project Auditor CoreCLR 사전 감사 — 2~3h (S0 필수 산출물)

우리 6.4 에 에디터 Module 로 내장되어 있어 패키지 설치 0 (신규 사실 ④). Preferences → Use Roslyn Analyzers 켜고 분석 → Domain Reload 탭. 이게 지금 할 수 있는 가장 가치 높은 일입니다. 이유 3개:

1. Unity 7 이행 비용을 처음으로 측정합니다. 지금까지 P3c 기간 추정(1~2개월)은 근거가 없습니다 — 이 감사 결과가 첫 실측입니다.
2. 제 정적 감사(static 위반 0건)를 Unity 도구로 교차 검증합니다. 1인 체제에서 얻기 어려운 독립 확인입니다.
3. 버전 이동 전에 코드를 고칠 수 있습니다. 이동 후에 발견하면 이동 실패와 코드 문제가 뒤섞여 원인 분리가 안 됩니다.

산출: 이슈 목록 + 건수·유형별 분류 1쪽. 코드 수정은 이 감사 결과를 PD 에게 보고한 뒤 별건.

2. ⭐ 200F golden-vector 하네스 골격 — 3~4h (S2 게이트의 전제)

§9.3 설계대로 빈 하네스를 먼저 만듭니다. 지금 벡터를 채울 수 없습니다 — Unity 측 밸런스 산술이 0이기 때문입니다(§9.2). 그래서 만드는 것은 "측정"이 아니라 "측정 장치" 입니다. 왜 지금인가: Phase 4 에서 산술이 들어올 때 하네스가 이미 있으면 드리프트가 생긴 그날 잡힙니다. 없으면 수개월 뒤 한가영 주간 검증에서 뭉뚱그려 발견되고, 그때는 원인 후보가 수십 개입니다. ⚠️ Unity6/Assets/_Project/Tests/Editor/ 경로가 U3 승인 범위 밖입니다 → PD 경로 승인 필요.

3. 리스크 재등록 + 12/31 게이트 갱신 제안 — 0h (본 문서가 그 자체)

박세린 PM 에게 §1.4 갱신본 전달: R-U6-1~4 갱신 + R-U7-1(롤백 불가) / R-U7-2(제출 충돌) / R-U7-3(써드파티 SDK) 신규 3건. 12/31 게이트 확인 항목 갱신은 §11 에 제안만 했습니다 (sprints/phase4_trigger_gate_2026-09-28.md 는 수정 금지 지시 준수).

(보류 유지) activeInputHandler Both → New + TMP pre 부채

v1.0 §6-3 그대로. 1~2h. S0 동결 기간 중 가능하나 이번 발주 범위 아님.

7. 리스크·미해결

8. 분업 인수인계

9. (v1.1 신설) 부동소수점 재검증 계획 — 이번 개정의 핵심

9.1 확정 사실과 면제 조항

Unity 공식 (Path to CoreCLR, 2026 Upgrade Guide):

"The new CoreCLR runtime is compliant with the IEEE 754 standard for floating point operations. This may be different from what Mono's JIT produced, and so the results of floating point calculations may be a little different in some situations." "IL2CPP is not affected by this change."

두 번째 문장이 첫 번째 문장보다 우리에게 중요합니다. 출하 경로가 면제됩니다.

정책 결론 (권고): 출하 빌드는 전 플랫폼 IL2CPP 로 고정합니다. 그러면 float 리스크는 "플레이어에게 다른 밸런스가 나간다"가 아니라 "에디터에서 하는 검증이 출하 빌드와 어긋난다" 로 축소됩니다. 후자는 심각하지만 관리 가능하고, 전자보다 한 등급 낮은 문제입니다. R-U6-4 영향도를 고→중으로 내린 근거가 이것입니다.

9.2 오늘의 노출면 실측 — 지금 검증하면 아무것도 증명되지 않습니다

Unity6 전체 코드에서 부동소수점이 등장하는 지점을 전수 조사했습니다.

결정적 사실: Unity C# 안에 밸런스 산술이 없습니다. 200F 4.255 / 4.21 / 약 4.20 곱 체인은 designs/ TSV + 윤서아·한가영 시뮬 시트에서 계산됩니다 (affix_pool_sp04_supplement_v1.md:198 — "B04 프레스티지 × 어픽스 = 2.30 × 1.82 = 약 4.19~4.20배"). Unity 측이 하는 일은 파싱해서 SO 에 담는 것뿐입니다.

따라서:

1. 오늘 CoreCLR 에서 200F 를 재검증하면 드리프트 0 이 나옵니다. 그리고 그 결과는 아무것도 보증하지 않습니다 — 노출면이 없어서 0 이 나온 것이지, 안전해서 0 이 나온 게 아닙니다. 이 구분을 못 하면 "검증 통과" 라는 잘못된 안전감만 남습니다.
2. 진짜 검증 시점은 Phase 4 입니다. 전투 공식 / 어픽스 곱연산 / 프레스티지 PP 단일 곱 경로 / 방치 보상 곡선이 Unity C# 로 들어오는 순간 노출면이 0 → 수백 지점으로 늘어납니다.
3. 그래서 S0 에서 만들 것은 "측정"이 아니라 "측정 장치" 입니다 (§6-2).

9.3 무엇을 / 어떻게 — golden-vector 하네스

위험의 정체: 크기 드리프트가 아니라 임계값 뒤집힘

크기로는 안 깨집니다. 0.12% 편차 / 마진 90% 인 현재 baseline 이 1e-7 차이로 0.5% 를 넘을 수 없습니다. 위험은 비교가 뒤집히는 경로입니다:

하네스 설계

S2 A/B 방법 (인과 분리)

같은 6.7 LTS, 같은 프로젝트, 같은 커밋에서 스크립팅 런타임만 Mono ↔ Experimental CoreCLR Desktop Player 로 교체해 동일 하네스를 실행합니다. 에디터 버전·패키지·데이터가 전부 고정이므로 변수가 런타임 하나입니다. 이것이 6.7 LTS 를 경유하는 두 번째 이유입니다 — 첫째는 EOL 탈출, 둘째는 이 A/B 가 6.7 LTS 에서만 성립한다는 것입니다 (Unity 7 에는 Mono 가 없어서 비교 대상이 사라집니다).

9.4 실패 시 대응 — fallback 4안 (비용 낮은 순)

S2 에서 0.5% 초과 또는 임계값 뒤집힘이 확인되면:

Burst FloatMode.Deterministic 판정 — 우리 200F 대안이 아닙니다

조정자 질문에 대한 답입니다. Burst 1.8.25 에서 FloatMode.Deterministic 이 지원되지만 우리 200F 경로에는 쓸 수 없습니다:

1. manifest 에 Burst 가 없습니다 (Packages/manifest.json 9개 의존성에 com.unity.burst 부재 — 실측)
2. 우리 산술이 Burst job 이 아닙니다. Importer·SO 의 일반 C# 코드입니다. Burst 는 [BurstCompile] job/함수포인터만 컴파일합니다
3. 64-bit 전용입니다 (공식 changelog 명시) → Android armv7 32-bit 타깃을 남긴다면 적용 불가

단 무한던전 1만 마리 시뮬(류재현 DOTS)에는 유효합니다 — 그 경로는 실제로 Burst job 이 될 것이고, 64-bit 타깃(iOS arm64 / Android arm64)이면 조건도 맞습니다. §8 류재현 인계 ③ 으로 넘겼습니다. 다만 그건 "cross-CPU 결정론"(같은 코드, 다른 CPU)이고 우리 문제는 "cross-runtime"(Mono vs CoreCLR)이라 문제가 다릅니다. 혼동하면 안 됩니다.

9.5 게이트

10. (v1.1 신설) Project Auditor — 지금 당장 할 수 있는 것

10.1 가용성 (확인됨)

우리 6.4 에서 추가 설치 0 으로 지금 됩니다. v1.0 이 이걸 "6.7 이동 시"로 미뤘던 것은 오판이었습니다.

10.2 실행 방법

1. Preferences → Use Roslyn Analyzers 켜기
2. Project Auditor 분석 실행
3. Domain Reload 탭 확인 → CoreCLR 이행 시 코드 리로드 비호환 지점이 여기 나옵니다

10.3 우리에게 주는 3가지

1. P3c(CoreCLR 이행) 기간의 첫 실측. 현재 추정 "1~2개월"은 근거가 없습니다. 이슈 건수가 나오면 처음으로 근거 있는 추정이 됩니다.
2. U3 작업의 독립 교차 검증. 제 정적 감사 결론(static 가변 위반 0건 / SO 캐시 3종)을 Unity 도구가 확인해 줍니다. 1인 체제에서 얻기 힘든 2차 의견입니다. 불일치가 나오면 제 감사가 틀린 것이므로 즉시 보고합니다.
3. URP Settings Analyzer 동시 확보 — 같은 Project Auditor 모듈입니다(v1.0 §3.4). 모바일 URP 설정 오류 자동 검출 → 한지우 플래그(m_SupportsHDR: 1 등)에 근거 제공.

10.4 한계 (정직하게)

• 제가 실행할 수 없습니다. Unity Editor 를 열 수 없는 환경입니다. PD 가 실행하거나, PD 가 화면/로그를 넘겨주시면 제가 분류하겠습니다.
• Roslyn Analyzer 기반이므로 정적 분석의 한계를 그대로 갖습니다. 리플렉션 경로(우리 MVP Builder 들이 GetField(..., BindingFlags.NonPublic | BindingFlags.Instance) 를 씁니다 — 실측)는 놓칠 수 있습니다.
• Domain Reload 탭이 6.4 Module 버전에 실제로 존재하는지는 미확인입니다. 문서가 언급한 것은 Project Auditor 2.0.0 기준입니다. 없으면 S0 이탈 조건대로 6.3 LTS 로 임시 이동해 감사합니다 (§1.3 S0 ③).

11. (v1.1) 2026-12-31 게이트 확인 항목 — 갱신 제안만

sprints/phase4_trigger_gate_2026-09-28.md §3 에 독립 점검으로 등록되어 PD 승인된 상태입니다. 그 파일은 수정하지 않았습니다 (지시 준수). (d) 결정으로 확인 항목의 목적이 바뀌었으므로 아래를 제안합니다 — 채택 여부는 박세린 PM / PD 판단입니다.

가장 중요한 제안은 3번입니다. 이 프로젝트는 7/4~9/6 64일, 9/8~9/23 16일 두 차례 전 트랙 정지 이력이 있고 Unity 트랙은 4/21 이후 기능 진전 0 입니다. 날짜만 확인하는 게이트는 그 패턴을 막지 못합니다. 산출물 존재를 묻는 게이트여야 S0 가 실제로 수행됩니다.

12. (v1.2 신설) Unity 7 직행 + 2027-03 데모 제출 — 유효 경로

12.0 새 전제

6.7 LTS 는 선택지에서 제거되었습니다. 재론하지 않습니다.

12.1 일정 충돌 판정 — 2027-03 Unity 7 데모 제출 = N (불가능)

세 가지가 각각 독립적으로 이 결론을 냅니다. 하나만 해소해도 나머지 둘이 남습니다.

12.1.1 관문 1 — Preview 엔진으로 상용 출하가 되는가? 법적으로 불명확 / 기술적으로 부적합

약관 두 개가 서로 다른 말을 합니다. 제가 확인한 그대로 옮깁니다.

제 판정: Steam/App Store 일반 판매가 "no less protective" 조건을 충족하는지는 제가 답할 수 없습니다. 법률 판단이고 저는 자격이 없습니다. PD 확인 항목으로 올립니다.

다만 법적 판단이 어떻게 나오든 기술적으로는 부적합합니다 — 이게 결정적입니다:

1. 패치 스트림 없음. 데모/EA 는 출시 후 버그 대응이 전제입니다. Preview 엔진은 주간 패치가 아니라 다음 Preview 로 굴러갑니다. 크래시 하나 만나면 대응 수단이 0 입니다. 제 철학 1(라이브 안정성 절대 사수) 정면 위반.
2. 스토어 SDK 요건 미인증. iOS/Android 를 포함하면 Apple Xcode/iOS SDK, Google targetSdk 요건을 Preview 엔진이 충족한다는 보증이 없습니다.
3. 되돌릴 곳이 없음. 6.7 LTS 경유를 폐기했으므로 "제출 실패 시 안정 버전으로 재빌드" 경로가 존재하지 않습니다 (R-U7-1 재정의).

12.1.2 관문 2 — 예산. ⚠️ 먼저 환산을 정정해야 합니다

조정자 제시: "실측 활동일 월 6.5일 → 약 32 활동일(풀타임 1.5개월 상당)".

이 괄호가 예산을 2~4배 부풀립니다. "풀타임 1.5개월" 은 1일 8h 를 암시해 ≈256h 가 됩니다. 그런데 CLAUDE.md 는 이 프로젝트의 세션을 "2~4시간 집중 단위" 로 정의합니다. 활동일 1일 = 1세션 = 2~4h 입니다.

교차 검증 하나 더: designs/combat_system_porting_strategy_v1_2026-05-05.md:180 이 "A+ 총합 180h = 4.5주 풀타임 또는 9주 파트타임" 이라고 적었습니다 → 그 문서가 가정한 파트타임 속도는 20h/주입니다. 실측(월 6.5일 × 2~4h = 3~6h/주)의 약 4배입니다. 즉 우리 기존 공수 문서들은 전부 실측보다 4배 빠른 속도를 가정하고 있습니다. 이 4배 격차를 교정하지 않으면 어떤 일정도 성립하지 않습니다.

그리고 엔진이 12월에야 나오므로 예산이 둘로 쪼개집니다:

데모 구현은 전부 엔진 의존입니다. 따라서 가용 예산은 96h 가 아니라 59h (39~78h) 입니다.

12.1.3 관문 3 — 데모 최소 공수 vs 엔진 예산

기술 최소 집합입니다. 콘텐츠 범위(층 수·캐릭터 수·언어 수)는 윤서아 영역이라 건드리지 않고, "기술적으로 N까지 가능" 형태로만 씁니다.

⚠️ 이 추정은 "Unity 7 이 우리가 하려는 걸 방해하지 않는다"를 가정합니다. Preview 엔진에서 그 가정은 성립하지 않습니다 — 엔진 버그 우회 비용은 위 표에 0h 로 잡혀 있습니다. 실제로는 20~40% 오버헤드를 봐야 하지만, 측정 근거가 없어 곱하지 않았습니다. 즉 113~162h 는 낙관치입니다.

기술 절삭 5건 (콘텐츠 결정이 아니라 기술 구현 축소):

절삭 후 = 72~113h (중앙 ~92h)

12.1.4 판정

# 판정: N. 2027-03 Unity 7 데모 스토어 제출은 불가능합니다. 중앙값 1.56배 초과이고, 유일하게 성립하는 조합은 "모든 항목이 최소치 + 예산이 최대치 + 엔진 버그 0 + 추가 정지 0" 입니다. 이 프로젝트는 163일 중 80일(49%) 전 트랙 정지 이력이 있고 Unity 트랙은 4/21 이후 기능 진전 0 일입니다. 최선 조합을 계획으로 쓸 근거가 없습니다. 그리고 예산이 맞더라도 §12.1.1 관문 1(Preview 엔진 출하) 이 따로 남아 있습니다. 예산 문제를 해결해도 제출 가능 여부가 해결되지 않습니다.

12.1.5 PD 선택지 4개

권고: (C) + (B) 조합. 2027-03 에 Steam 페이지로 날짜를 지키고, 플레이 가능한 것은 이미 존재하는 웹게임 자산으로 제공합니다(차도윤 가용성 확인 조건). Unity 데모는 (A) 로 2027-Q3. 이렇게 하면 PD 의 2027-03 마일스톤·Unity 7 직행·라이브 안정성 세 가지가 전부 살아남고, 포기하는 것은 "2027-03 에 Unity 로 만든 플레이 빌드" 하나뿐입니다.

12.2 2026-12 까지 무엇을 하는가 — 엔진 비의존 창 39~78h

Unity 7 을 기다리는 2~3개월은 놀 필요가 없습니다. 다만 정직하게 분리해야 합니다.

엔진 비의존 = 지금 가능 (권장 순서)

반드시 엔진을 기다려야 하는 것

씬·프리팹·셰이더·머티리얼 / 전투 구현 / UI / 세이브 / Addressables 빌드 / 플랫폼 빌드 / 모든 Play 검증 / D0 프로젝트 구축. → 12월 이전에 이걸 시작할 방법은 없습니다. 6.4 에서 만들어 Unity 7 로 옮기는 것은 "처음부터 Unity 7" 지시와 정면 충돌하고, 옮기는 비용이 만드는 비용에 추가됩니다.

12.3 "처음부터" 의 범위 — 신규 프로젝트 권고 + 기존 Unity6/ 는 read-only 기준선 보존

권고

Unity 7 에서 신규 프로젝트를 만듭니다. 기존 Unity6/ 를 업그레이드하지 않습니다. 그리고 기존 Unity6/ 를 삭제하지 않고 read-only 참조 기준선으로 보존합니다.

신규인 이유 3개

1. 6.4(EOL 비-LTS) → Unity 7(메이저) 은 아무도 검증하지 않은 경로입니다. Unity 의 "zero rebuilding" 은 6.x LTS→7 을 말하는 것이고 EOL 중간 릴리스에서의 점프는 보증 대상이 아닙니다.
2. 자산이 스캐폴드(7,827 LOC, 전투 0)라 신규가 더 쌉니다. 업그레이드 트러블슈팅 비용 > 재구축 비용.
3. Unity 7 의 새 default(Fast Enter Play Mode 강제, CoreCLR, .NET 10/C# 14)에 맞춘 프로젝트 설정이 처음부터 깔립니다. 6.4 프로젝트를 끌고 가면 구 설정 잔재를 계속 의심해야 합니다.

보존하는 이유 — R-U7-1 재정의의 유일한 완화책 v1.1 의 R-U7-1 은 "Mono 로 롤백 불가" 였습니다. v1.2 에서는 "돌아갈 곳이 아예 없음" 으로 악화됩니다 — 처음부터 Unity 7 이면 "이전엔 잘 됐다"는 비교점이 존재하지 않아 문제 원인 분리가 어려워집니다. Unity6/(6.4, Mono) 를 동작하는 Mono 기준선으로 남겨두면 최소한 "Importer 가 같은 TSV 에서 같은 SO 를 만드는가"를 대조할 수 있습니다. 보존 비용 0, 가치 큼.

이관 방법 — 결과물이 아니라 레시피를 옮깁니다

우리에게 결정적으로 유리한 점: MVP 캐릭터 5체와 SO 에셋은 Editor 스크립트가 재생성합니다. 즉 .asset/.controller 파일을 옮기는 게 아니라 생성기를 옮기고 다시 돌립니다. 이게 "처음부터"를 현실적으로 만드는 핵심입니다.

이관 = D0 = 12~18h 로 잡은 근거가 이 표입니다. 순수 재구축(P3a 실적 ~2개월)보다 훨씬 짧은 이유는 레시피가 전부 코드로 남아 있기 때문입니다.

Project Auditor 의 성격 변경 (§10 갱신)

v1.1 §10 은 "Unity 7 이행 시 고칠 코드를 미리 찾는다" 였습니다. 처음부터 Unity 7 이면 이행할 코드가 없습니다. 그래도 여전히 유용하지만 목적이 다릅니다:

• ❌ (폐기) Unity 7 이행 비용 측정
• ✅ (유효) 이관할 C# 24파일이 CoreCLR/Domain Reload 에서 문제를 일으키는지 사전 확인 — 이관 대상 선별. 특히 제 U3 정적 감사(static 위반 0건)의 독립 교차 검증
• 추정 2~3h 유지. 우선도는 하향 (12월까지 할 일 중 5순위, §12.2)

12.4 float 리스크 재정의 — 조정자 판단 검증

조정자 판단: "이건 마이그레이션 드리프트 리스크였다. 마이그레이션을 안 하면 드리프트가 발생할 대상이 없고, 검증 기준은 Mono 결과가 아니라 designs/ TSV·시트의 권위값이 된다."

판정: 방향은 맞습니다. 다만 결론이 불완전합니다 — 리스크는 소멸하지 않고 이동합니다.

맞는 부분 (2건)

1. ✅ S2 A/B 폐기는 타당합니다. Mono→CoreCLR 전환 사건이 없으므로 "우리 숫자가 변했다"를 측정할 before/after 가 존재하지 않습니다. 비교 대상 소멸이 맞습니다.
2. ✅ 권위값이 TSV·시트라는 것도 맞습니다. 제 §9.2 실측이 이를 뒷받침합니다 — Unity C# 안에 밸런스 산술이 0개이고, 4.255 / 4.21 / 약 4.20 곱 체인은 시트에서 계산됩니다 (affix_pool_sp04_supplement_v1.md:198 "2.30 × 1.82"). Unity 는 float.TryParse(InvariantCulture) 로 파싱만 합니다.

불완전한 부분 (결정적)

⚠️ Unity 7 에서 에디터는 CoreCLR, 출하 빌드는 IL2CPP 입니다. 그리고 Unity 공식이 "IL2CPP is not affected by this change" 라고 말한 것은, 곧 IL2CPP 와 CoreCLR 이 서로 다를 수 있다는 뜻입니다. 우리 밸런스 검증은 에디터에서 돕니다.

어떤 의미에서는 더 나쁩니다. 일회성 관문이었던 것이 상시 조건이 됩니다. "마이그레이션을 안 하니 안심"은 위험한 결론입니다.

그래서 S2 를 무엇으로 대체하는가 — V1 + V2

하네스는 살아남습니다. §9.3 설계(golden vector / 비교 2종 분리 / 파싱 벡터 필수 포함)를 그대로 쓰고, 목적만 "이전↔이후" → "에디터↔디바이스" 로 바꿉니다. §12.2-2 에서 기대값을 시트로 먼저 만들어 두는 것이 V1·V2 공용 기반이 됩니다.

IL2CPP 고정 결정(PD 결정 2번)이 데모에 적용되는가 — 예, 적용 권고. 다만 float 리스크가 사라지지는 않습니다.

• 적용하면 출하 빌드에 CoreCLR 이 안 들어가므로 "플레이어에게 다른 밸런스가 나간다"는 없습니다. 여기까지는 리스크 제거입니다.
• 그러나 에디터는 여전히 CoreCLR 이므로 "우리가 에디터에서 검증한 값이 플레이어가 보는 값과 다를 수 있다" 는 남습니다. 이게 V2 가 필요한 이유이고, IL2CPP 고정으로 해결되지 않는 잔여분입니다.
• Steam 데모도 IL2CPP 권고 (Mono/CoreCLR 데스크톱 플레이어 배포는 어셈블리 노출 + patch 스트림 문제).

§9.4 fallback 4안(F1 경계 양자화 → F2 정수 basis point → F3 double → F4 decimal)은 전부 그대로 유효합니다. 대상이 "마이그레이션 드리프트"에서 "런타임 간 불일치"로 바뀌었을 뿐 처방은 동일합니다. Burst 판정(우리 대안 아님 / 류재현 DOTS 인계)도 유지됩니다.

12.5 EOL 체류 재평가 — 조건부 허용. 단 체류가 길어졌습니다

허용 판정: 예, 단 조건부. EOL 의 실질 피해 3종을 분해하면:

③ 의 완화가 자동으로 달성됩니다: §12.2 에 따르면 12월까지 할 일이 전부 엔진 비의존(설계서·시트·스키마·인벤토리)이라 에디터를 거의 쓰지 않습니다. Project Auditor 2~3h 가 유일한 에디터 사용입니다.

→ v1.1 S0 금지사항(제출 0 / 신규 써드파티 SDK 0 / 셰이더·씬·플랫폼 빌드 작업 0)을 그대로 유지하면 6~9개월 체류가 관리 가능합니다. 금지사항이 §12.2 작업 계획과 충돌하지 않습니다.

12.6 리스크 재등록 (v1.2)

R-U7-6 이 이번 개정에서 가장 광범위한 발견입니다. 2027-03 하나의 문제가 아닙니다. combat_system_porting_strategy_v1 의 180h, Phase 4 의 "3~6개월", P3b 의 "2~4개월" 이 전부 같은 4배 낙관을 공유합니다. 제출 날짜를 어떻게 정하든 이 환산 오류를 먼저 교정해야 합니다.