refactor(core): MVI 전환과 Navigation 3 이관의 접점 판정 — 네비게이션을 Intent 로 접을지 #1810

작업 유형

refactor — 동작 변경 없는 구조·책임·경계 개선

주 담당 모듈

core — 코어

개요

MVI 전환(#1811)이 진행 중인 Navigation 3 이관과 만나는 지점을 판정한다. 코드 변경이 목적이 아니라 방침 확정이 목적이다.

이 이슈가 좁혀진 경위

처음 이 이슈는 RuleUp 의 NavigationHelper(네비게이션을 단일 Flow 로 모으고 ViewModel 이 직접 호출)를 도입해 화면 콜백 332개를 걷어내자는 제안이었다. 그 제안은 내린다 — 레포가 이미 반대 방향으로 가고 있다.

• Navigation 3 로컬 스택 이관이 진행 중이다. 마음의 기록 허브를 Navigation 3 로컬 스택으로 — #1697 파일럿 #959 파일럿 → refactor(mindrecord): Navigation 3 파일럿을 전체 entry 계약으로 확장 #1697 전체 entry 계약 → refactor(setting): 설정 흐름을 Navigation 3 로컬 스택으로 이관 #1695(setting) · refactor(timeletter): 타임레터 흐름을 Navigation 3 로컬 스택으로 이관 #1696(timeletter) · refactor(platform): 소관 그래프를 Navigation 3 로컬 스택으로 이관 #1698(platform). 이 방향은 네비게이션 결정을 feature 로컬 entry 계약에 두고 앱 셸과 최소 boundary 로 만난다. 단일 헬퍼로 모으는 것과 정반대다.
• TimeLetter 단순 back 위임 5개를 공통 명령으로 통합 #1301 이 콜백 처리 방침을 이미 정했다. 「Screen 의 이벤트 콜백 이름은 유지하고, 각 NavGraph 에서 기능별 공통 popBack() 에 매핑한다」 — 화면 이벤트와 내비게이션 명령의 책임 분리가 이미 설계돼 있다.

그래서 무엇을 판정하는가

MVI 전환은 «사용자 입력을 Intent 로 접는 것»이고, Nav3 이관은 «목적지 결정을 어디에 두는가»다. 두 축이 만나는 지점만 정한다.

• 네비게이션 의도를 Intent 로 표현할 것인가, 화면 콜백으로 계속 올릴 것인가. Nav3 entry 계약이 목적지를 갖는다면 ViewModel 은 몰라도 된다 — 그 경우 콜백이 남는 것이 정상이다.
• MviEffect 로 네비게이션을 보내는 경우가 있는가. 있다면 Nav3 entry 계약과 만나는 방식을 정한다(예: 저장 성공 후 pop 처럼 ViewModel 이 시점을 아는 경우).
• 기존 *NavActions 7종(AfternoteNavActions · ReceivedAfternoteNavActions · MindRecordNavActions · SettingNavActions · TimeLetterNavActions · ReceiverNavActions · OnboardingNavActions)과 ReceiverHomeActions 의 거취. Nav3 이관 후에도 남는지, MVI 전환이 이 파일들을 건드려도 되는지.
• 콜백 332개는 MVI 전환의 목표에서 뺀다. 네비게이션분은 Nav3 이관과 TimeLetter 단순 back 위임 5개를 공통 명령으로 통합 #1301 이 처리한다. MVI 전환 이슈들은 Screen/Content 2단 분리까지만 하고 콜백 개수는 건드리지 않는다.

완료 조건

• 위 네 가지 판정이 docs/convention/mvi.md 에 적힌다 (test(platform): MVI 계약 konsist 강제 + docs/convention/mvi.md 신설 #1801 이 만드는 문서)
• Nav3 이관 이슈들과 MVI 전환 이슈들이 서로의 범위를 침범하지 않는 경계가 문장으로 확정된다
• 코드 변경 0줄로 닫을 수 있다 — 방침만 정해지면 완료다

자식 이슈

No response

참고

Nav3 계열: #959 (파일럿) · #1697 (전체 entry 계약) · #1695 · #1696 · #1698 · #1301 (back 위임 통합)

원 제안의 참조 구현(도입하지 않음, 판정 근거로만 남긴다): RuleUp NavigationHelper

2026-09-13 현재 계약 대조와 독립 완료 근거

현재 develop 816e9272c의 ReceiverNavHost는 화면 콜백을 ReceiverLocalNavActions에 매핑하고, AfternoteNavActions는 화면 이벤트와 이동 명령을 분리한다고 명시한다. 공용 MviViewModel은 Intent·UiState·ReducerEvent만 가지며 ObserveSignal이 UiState 신호를 결과 콜백과 소비 Intent에 연결한다. 기존 receiver 및 afternote MVI 구현에서도 저장·인증 성공 신호가 같은 경계를 소비한다.

따라서 이 이슈의 네 가지 접점 판정은 현재 제공된 프로덕션 계약으로 문서화할 수 있다. 전체 entry 이관 #1697의 미완료 범위나 앱 루트 #1702의 전환 완료를 기다려야 하는 작업이 아니므로 #1697 blocked_by를 제거한다. 각 화면의 미확정 제품 목적지나 이전에 취소된 전역 NavigationHelper를 구현하지 않는다.

문서와 같은 오해를 만드는 MviContract.kt 설명은 KDoc만 함께 정리한다. 타입·실행 코드·공개 범위·화면 동작은 바꾸지 않는다. ReceivedAfternoteNavActions가 이미 별도 계약으로 존재하여 판정 대상 수를 7종으로 바로잡았다. 구현·문서 검증 결과는 연결 PR에서 확인한다.