Repository navigation
수신자 등록 성공 후 안내·이동 방식을 PM에게 확인한다 #593
Description
작업 유형
enhancement — 신규 기능·기존 기능 개선
주 담당 모듈
setting — 설정
개요
등록 성공과 취소가 같은 복귀로 표시된다는 QA 관찰을 보존한다. 이를 기획 판단이 불필요하다고 단정한 기존 기록과 스낵바·토스트·목록 이동 구현 예약은 철회한다.
PM 확인이 필요한 결정
설정에서 등록 성공한 뒤 안내만 표시할지, 목록으로 이동할지, 기존 화면으로 돌아갈지와 취소 동작을 PM에게 확인한다. 카카오 초대 전환 #1948/#944의 접수·수락 구분도 함께 확인한다.
완료 기준
PM의 명시적인 답변과 적용 범위·근거 링크를 기록한다. 답변 전에는 구현·재개·테스트 완료 체크리스트를 예약하지 않는다. 결정 후 최신 코드와 계약을 대조해 실제 필요한 작업만 정의한다. 디자이너에게 질문하거나 태그하지 않으며, 미답변이나 과거 FE 재량 위임을 승인으로 해석하지 않는다.
정리 근거
2026-09-13 사용자 요청에 따라 미확정 구현 예약을 제거했다. 기능 구현 완료를 의미하지 않는다. 기존 댓글의 실측은 참고 자료이며, 상충하는 옛 구현 지시는 현재 범위를 대체하지 않는다.
Activity
[-]fix(setting): 수신자 등록 성공 안내 부재 — 성공과 취소가 화면상 구분되지 않음[/-][+]수신자 등록 성공 안내 부재 — 성공과 취소가 화면상 구분되지 않음[/+][-]수신자 등록 성공 안내 부재 — 성공과 취소가 화면상 구분되지 않음[/-][+]수신자 등록 성공 후 안내·이동 방식을 PM에게 확인한다[/+]OnlyReadOneBook commentedon Sep 13, 2026
PM 전건호에게 Figma 댓글로 질문했다(2026-09-13). 이 이슈는 그동안 PM 확인 대기로 분류돼 있었지만 실측해 보니 어느 채널에도 발신 기록이 없었다. 이번이 첫 발신이다.
4327:64515수신자 등록 (정리 Screen Design > 설정 > 수신자 등록/수정)message_meta로 보내 알림이 가도록 했다. 평문@이름은 알림이 가지 않는다.물은 것은 묵은 본문의 질문을 그대로 옮긴 것이 아니라 origin/develop 86ab223 실코드와 현재 시안으로 다시 벼린 것이다.
본문에 있었지만 이번 질문에서 뺀 축:
(1) «취소 동작 확인» 축을 뺐다. 취소는 popBackStack 한 가지로 이미 일관되고 이견이 없다. 남은 문제는 성공이 취소와 구별되지 않는다는 것뿐이라 질문을 그쪽으로 좁혔다. (2) «스낵바냐 토스트냐» 같은 표시 수단 세부를 뺐다. 수단은 #446 의 공통 안내 체계가 정할 몫이고, PM 에게 필요한 답은 무엇을 보여주느냐다. (3) 이메일 등록·인증을 전제로 한 축을 통째로 뺐다. BE#289 로 POST users/receivers 가 사라져 «등록 직후 새 receiverId» 라는 값 자체가 계약에 없다. 그래서 «목록으로 이동» 을 물을 때 목록이 무엇을 보여주는지(대기 상태)까지 함께 물었다. (4) 수신자 수정 성공도 같은 popBackStack 문제를 갖고 있지만 초대 전환과 무관한 별건이라 이 댓글에서 뺐다. 답이 오면 등록 규칙을 수정에 그대로 적용할지 FE 가 정한다.
OnlyReadOneBook commentedon Sep 13, 2026
질문 발신 뒤, 답이 오기 전에 확정할 수 있는 것만 실측해 둔다. 코드는 0줄이다. 다음 착수자가 등록 POST 가 서버에 없는 줄 모르고 성공 표시를 구현하거나, 곧 갈아엎힐 develop 모양 위에 착수하는 것을 막는 데 이 기록의 용도가 있다.
기준점은 FE
origin/develop7d87aa3f4, BEorigin/main3593aa30이다. 앞선 코멘트가 인용한86ab2238c는 오늘 사이에 움직였고, 아래 줄 번호는 전부7d87aa3f4에서 다시 뗐다.1. 등록 성공 경로가 배포 계약에 없다
BE
3593aa30의src/main/java/com/afternote/domain/user/controller/UserController.java는 클래스에@RequestMapping("/api/v1/users")를 걸고(24행) 수신자 매핑을 여섯 개 가진다.@GetMapping("/receivers")@GetMapping("/receivers/{receiverId}")@PatchMapping("/receivers/{receiverId}/message")@PatchMapping("/receivers/{receiverId}/relation")@PatchMapping("/receivers/{receiverId}")@DeleteMapping("/receivers/{receiverId}")@PostMapping("/receivers")는 없다. 경로 자체는 GET 으로 살아 있으므로POST /api/v1/users/receivers는 404 가 아니라 405 다. 이건 BE 소스 전수에서 낸 판정이고 실서버 호출로 찍어 본 값은 아니다.FE 는 그 POST 를 그대로 부른다.
core/network/.../UserApiService.kt:39의@POST("users/receivers"), BASE_URL 은core/network/build.gradle.kts:13의https://afternote.kro.kr/api/v1/, 호출 사슬은core/data/.../UserReceiverRepositoryImpl.kt:115,125를 거쳐ReceiverRegisterViewModel.kt:59다.그래서
ReceiverRegisterViewModel.kt:66-67의RegisterSuccess는 현 서버 상대로 도달 자체가 불가하다. 이 이슈가 보존하려는 QA 관찰(성공이 취소와 구별되지 않는다)은 지금 실서버에서 재현되지 않는다. PM 답이 와도 그 규칙이 붙을 성공 분기는 카톡 초대 전환(#944, #1948) 이후의 등록이다.2. 적용 범위 쟁점은 설정 안 세 곳이다
성공과 취소가 같은 복귀인 자리는
feature/setting/.../navigation/SettingNavGraph.kt에 셋이다.onBackClick과onRegisterSuccess가 둘 다actions::onRecipientRegisterBackactions::onRecipientEditBackactions::onAfterDeliveryBack셋의 종점은 모두
app/.../navigation/AppNavigationActions.kt:234-236의popBackStack()하나다. 2026-09-13 에 발신한 질문은 이 중 등록 하나만 물었다. 답이 오면 수정과 전달 조건에 같은 규칙을 얹을지는 FE 가 정한다.3. 편집 표면이 열린 스택에 물려 있다
지금 develop 모양에 코드를 붙이면 두 번 재작성된다.
#1962(
codex/1695-setting-nav3, draft, basedevelop)가SettingNavGraph를SettingNavHost로 갈아엎는다. 동일성 문제는 그대로다.SettingNavHost.kt:155-158에서 등록의onBackClick과onRegisterSuccess가 둘 다actions::popBack, 169 에서 수정, 180 에서 전달 조건도 같다. 라우트 이름은AfterDeliveryRoute에서DeliveryConditionsRoute로 바뀐다.그 위에 스택된 #1967(
refactor/1502-setting-state-mvi, basecodex/1695-setting-nav3)이ReceiverRegisterScreen을internal로 내리고(ReceiverRegisterScreen.kt:61) 성공 소비를ObserveSignal로 바꾼다(69-73). ViewModel 계약도ReceiverRegisterContract.kt의Register·ConsumeSuccessintent 와Registering·Registered·Failed·SuccessConsumedreducer event 로 바뀐다.답이 온 뒤 착수자는 develop 모양이 아니라 이 두 PR 이 머지된 모양 위에 써야 한다.
4. 표시 수단은 이미 있다
설정에 실패용
SnackbarHost가 두 곳 살아 있다.NotificationSettingScreen.kt:60,94,108과ConnectedAccountsScreen.kt:36,44이고, 공용 껍데기는core/ui/.../scaffold/FlowStepScaffold.kt:66,93-94가 선택적snackbarHostState로 받는다. 답이 오면 새 안내 체계를 만드는 일이 아니라 기존 패턴에 성공 문구를 얹는 일이다. 다만 공통 안내 체계의 소유는 #446 이고 그쪽도 PM 대기다.본문이 develop 실태와 어긋나는 항목
origin/develop전수 검색에서receiver-invitations·ReceiverInvitation·invitationToken이 하나도 걸리지 않는다. enhancement(receiver): 카카오 초대 생성·수락·계정 연결 계약을 확정하고 검증한다 #1948 본문 기준 초대 계약은 BE PR [feat] 카카오톡 초대 기반 수신자 등록 및 JWT 인증 전환 Afternote-BE#289 로 2026-09-08 배포됐고 거절 상태와 거절 API 는 서버에 없다.popBackStack()단일 종점으로 다시 확인했다.본문은 고치지 않았다. 위 항목들은 완료 기준을 좁히는 것이 아니라 그 기준을 적용할 전제를 갱신하는 것이라 코멘트에 남긴다.
관계 상태
#593을 쓴 PR 은 0건이다. 이 이슈를 문 PR 은 지금까지 없다.blocked_by와blocking이 모두 0건이라, 카톡 초대 전환 대기와 PM 답변 대기가 이슈 관계로는 표현돼 있지 않다.OnlyReadOneBook commentedon Sep 18, 2026
PM 결정 대기 항목은 깃허브 이슈로 두지 않고 피그마 질문 한 자리에만 둔다(2026-09-18 결정). 이 이슈의 질문은 피그마 스레드에 걸려 있다: https://www.figma.com/design/UP9ZR186jHvRBicjA2SOea/?node-id=4327-64515#1923877281 답이 오면 그 답을 근거로 구현 이슈를 새로 만든다.