수신자 등록 카톡 초대 전환 — 이메일 등록·인증 대체 #944

2026-09-08 범위 분리·착수 조건

초대 생성·수락·계정 연결 계약과 검증을 #1948로 분리했다. 이 이슈는 확정 계약에 따른 화면·공유·상태 배선을 소유한다. 기존의 다음 주 회의 게이트는 사용하지 않으며 #1948 및 BE#227의 준비 완료를 따른다.

📜 Overview (Required)

08-23 회의에서 수신자 등록을 이메일에서 카톡 초대로 전환하기로 결정했다. 근거는 수신자 안내 이메일을 서비스가 직접 발송하는 방식의 법적 이슈(회의록: "이메일 - 법적 이슈 ㅇ", "우리 앱에서 보내면 불법임")와 이메일 오타로 인한 오등록. FE 팀 할 일 "카카오 화면"의 수신자 등록 파트.

새 플로우 (회의록 기준)

1. 발신자가 수신자 등록 → 수신자에게 카톡 공유로 등록 요청 전송
2. 수신자 수락 → 랜딩페이지 → Play스토어 앱 링크 → 앱 설치 · 회원가입(카카오)
3. 가입한 계정이 발신자의 수신자로 연결; 이후 통지(사후 전달 포함)는 "팀 단위에서 카톡으로"

현재 범위: 계약 준비 확인

• #1948과 BE#227의 확정 초대·수락·계정 연결·화면 계약을 확인한다.
• 이메일 입력 제거, 카카오 공유 방식, 대기 상태 UI 등 미확정 구현 체크리스트는 철회한다.
• 확정 계약과 현재 등록 흐름의 차이를 확인한 뒤 필요한 구현 범위를 정한다. 기존 이메일 흐름을 미리 삭제하거나 임시 초대 화면으로 대체하지 않는다.

영향 이슈 (이메일 등록 전제로 작성됨; 전환 확정 시 재검토): #768 #739 Afternote/Afternote-BE#287 #595 #577 #593

📍 Note (Optional)

• 회원가입 카카오 단일화(온보딩 파트)는 회원가입 카카오 단일화 — 이메일 가입·계정 찾기 갈래 제거 #943
• 출처: 08-23 회의록

2026-09-27 재작성 제거

PR #2109의 신규 Nav2 목적지 등록, 현재 destination 검사, 인증 후 navigate 및 popBackStack/popUpTo 배선은 #1702에서 교체됩니다. 이 구현을 먼저 병합하는 순서를 철회하고 PR을 닫습니다. 기능 완료로 처리하지 않습니다. 원래 브랜치와 검증 기록은 보존하며, 재개 시 확정된 계약과 남은 범위를 다시 확인합니다.

실제 선행은 #1702의 최종 앱 루트입니다. 기존 화면 진입을 임의로 제거하거나 소비 없는 초대 화면만 먼저 병합하지 않습니다. #1702의 담당별 로컬 스택 준비가 끝난 뒤 새 루트 계약에서 진입·인증 복귀·종료를 한 번만 구현합니다.

2026-10-04 등록 화면 MVI 전환을 이 이슈에서 함께 한다

설정의 수신자 등록 화면(ReceiverRegisterViewModel)은 아직 MviViewModel 을 상속하지 않고, 성공 신호를 Channel 로 보낸다. 이 ViewModel 이 부르는 POST users/receivers 는 BE origin/main(b7a6789, 2026-10-04)의 UserController 에 없다. 남은 수신자 매핑은 GET·PATCH·DELETE 뿐이고 생성은 ReceiverInvitationController 로 옮겨 갔다. 그래서 지금 MVI 로 감싸면 이 이슈에서 생성 호출·상태·신호를 다시 짜게 되어 따로 전환하지 않는다.

• 초대 흐름으로 바꾸는 등록 화면 ViewModel 은 MviViewModel 을 상속하고, 성공·실패 신호는 UiState 필드와 Intent.ConsumeXxx 로 소비한다(docs/convention/mvi.md, refactor: ViewModel 이벤트 → UI state 흡수 마이그레이션 (전수 9개 VM) #228).
• 위 전환이 들어가면 refactor(platform): 최종 앱 루트 책임 판정과 MVI 전환 종료 검사 (#1809 분리) #2022 의 MVI 종료 검사에서 이 화면의 예외를 지운다.