Repository navigation
fix(afternote): 갤러리 수신자 직접 입력이 임시 id 로 전송 — 입력한 이름·관계 유실, 엉뚱한 수신자 지정 위험 #680
Description
📜 Overview (Required)
GALLERY 카테고리만 수신자 추가가 다이얼로그 직접 입력이고, 나머지 세 카테고리는 수신자 선택 화면으로 간다 (AfternoteEditorContent.kt 실측 — MEMORIAL 245행·SOCIAL/BUSINESS 299행은 onNavigateToSelectReceiver, GALLERY 265행만 showAddAfternoteEditorReceiverDialog).
다이얼로그 경로는 서버 수신자 id 가 없어 클라이언트가 임시 id 를 만든다.
// EditorFormMutations.withReceiverAppended
id = (afternoteEditReceivers.size + 1).toString()그런데 등록 시 수신자 id 추출은 이렇다.
// AfternoteNavGraphEditor — onRegisterClick
selectedReceiverIds = form.afternoteEditReceivers.mapNotNull { it.id.toLongOrNull() }"1" 은 1L 로 변환에 성공하므로 걸러지지 않고, AfternoteEditorFormMapper.buildCreateInput 의 GALLERY 분기가 그대로 receiverIds 에 실어 보낸다.
결과가 둘이다.
- 입력한 이름·관계가 서버에 전달되지 않는다. payload 에는
receiverIds만 있고 name/label 필드가 없다 — 다이얼로그에 적은 내용이 통째로 버려진다. - 임시 id 가 실제 수신자 id 로 해석된다. 작성자에게 1번 수신자가 존재하면 의도하지 않은 사람이 수신자로 지정된다. 디지털 유산 전달 대상이 잘못 잡히는 경로다.
작업: GALLERY 도 수신자 선택 화면 경로로 통일한다.
📌 Child Issue(Optional)
No response
📍 Note (Optional)
- 서버가
receiverIds를 어떻게 검증하는지는 미확인이다(코드 경로만 실측). 존재하지 않는 id 면 거절될 수도, 본인 수신자면 통과할 수도 있는데 어느 쪽이든 사용자에게는 "갤러리 수신자 지정이 안 된다" 로 드러난다. - 통일하면 파사드의 수신자 추가 경로도 하나로 줄어든다. 지금
onAddReceiver(임시 id·중복 검사 없음)와onAddReceiverIfAbsent(서버 id·중복 검사)가 갈려 있는 이유가 id 출처 차이인데, 다이얼로그가 사라지면 후자만 남는다.AddAfternoteEditorReceiverDialog·afternoteEditReceiverNameState·relationshipSelectedValue도 함께 정리 대상이다. ⚠️ 시안 미대조 — 위 결함 서술은 전부 코드 실측이며 시안 기준값과 대조한 것이 아니다. 다만 해결 방향은 시안 확인이 선행돼야 한다: 갤러리 수신자 추가가 시안에 직접 입력으로 그려져 있다면 "선택 화면으로 통일"이 답이 아니라 서버에 이름·관계를 보낼 수 있게 하는 BE 계약 변경이 선행이다. 착수 전2. Screen Design의 갤러리 에디터 프레임을 찾아 대조할 것.
Activity
OnlyReadOneBook commentedon Aug 2, 2026
시안 대조 완료 — 해결 방향(선택 화면 통일)이 시안과 정합한다 (2026-08-02)
본문 Note 가 "착수 전
2. Screen Design의 갤러리 에디터 프레임을 찾아 대조할 것" 이라고 게이트를 걸어 뒀는데, 누가 언제 하는지가 비어 있었다. Figma REST 로 제가 대조했다.갤러리 에디터 프레임 3벌 — 전부 목록 형태다
700:37975700:38183700:38506"관계 + 이름" 쌍이 이미 채워진 목록이고, 이름·관계를 받는 입력 필드는 어느 프레임에도 없다. 즉 다이얼로그 직접 입력을 그린 시안이 아니다.
비즈니스 에디터와 같은 패턴이다 —
700:38735역시수신자 추가 / 친구 / 김지은 / 친구 / 김혜성. 카테고리별로 수신자 입력 방식이 갈리게 그려진 것이 아니라, 같은 컴포넌트를 공유한다.선택 화면 시안은 따로 존재한다 —
115:15841수신자 선택 화면: 검색 필드(Text Field) +아들 / 김혜성반복 목록. 에디터의 수신자 항목과 같은 표기 형식이라, 에디터에 채워진 항목이 이 화면에서 고른 결과라는 해석과 맞아떨어진다.결론
본문이 제시한 "GALLERY 도 수신자 선택 화면 경로로 통일"이 시안과 정합하다. Note 가 걱정한 반대 갈래 — "시안에 직접 입력으로 그려져 있다면 BE 계약 변경이 선행" — 은 성립하지 않는다. 직접 입력 다이얼로그는 시안에 없고, 따라서 이름·관계를 서버로 보내는 계약 확장도 필요 없다.
이 이슈의 시안 게이트는 해소됐다. 함께 정리 대상으로 적힌
AddAfternoteEditorReceiverDialog·afternoteEditReceiverNameState·relationshipSelectedValue제거도 같은 근거로 유효하다.AfternoteEditorContent.kt·AfternoteNavGraphEditor.kt는 열린 PR #605·#621·#655·#679·#682 가 전부 수정 중이다(#602 와 같은 사유). 그쪽이 정리된 뒤 착수하는 것이 맞다.OnlyReadOneBook commentedon Aug 4, 2026
정정 — 직접 입력 시안 존재, “선택 화면으로 통일” 결론 취소 (2026-08-04)
이전 댓글에서 갤러리 에디터 프레임에 이름·관계를 입력하는 화면이 없다고 판단했지만, 동일 프레임의 팝업 상태를 누락해 잘못 결론 내렸다.
700:38506애프터노트 수정페이지 안에는popup(700:38654)이 있고, 다음 직접 입력 필드가 실제로 존재한다.700:38659수신자 이름700:38663수신자와의 관계700:38672전화번호로 추가하기700:38677연락처에서 추가하기700:38657추가하기앞선 갤러리 프레임 계열에도
700:38481·700:38490·700:38500·700:38462로 같은 필드가 있다. 따라서 직접 입력 다이얼로그는 시안에 없는 FE 임의 구현이 아니다.수정된 결론
receiverId처럼 전송하는 문제는 그대로 유효하다.POST /users/receivers로 계정 수신자를 생성하고POST /afternotes에는 기존receiverId만 연결할 수 있다. 애프터노트 전용 수신자의 이름·관계를 함께 생성하는 계약은 없다.추가하기가 ① 계정 수신자를 영구 생성한 뒤 해당 애프터노트에 연결하는 것인지, ② 해당 애프터노트에만 존재하는 수신자를 만드는 것인지 제품·BE 계약을 확정해야 한다.이 댓글이 이전의 “시안 게이트 해소 / 선택 화면 통일” 판정을 대체한다.
OnlyReadOneBook commentedon Aug 8, 2026
착수 전 확인 사항(본문 Note 의 시안 대조·서버 검증)을 실측했다.
시안 대조 — 갤러리 수신자 추가는 직접 입력 팝업으로 실재한다. 갤러리 에디터 프레임(팝업 열림) 에
popup프레임: 수신자 이름 · 수신자와의 관계 · 전화번호로 추가하기 · 연락처 가져오기 · 추가하기. 이메일 필드는 없다.서버 계약 실측 (Swagger + BE 소스 직독):
POST /api/v1/afternotes의receivers[]는receiverId(int64) 단일 필드 — 이름·관계를 실을 자리가 없다.AfternoteRelationService.resolveReceivers가 존재 검증(RECEIVER_NOT_FOUND)과 소유 검증(NOT_ENOUGH_PERMISSION)을 모두 수행 — 임시 id 1,2,3… 은 대부분 등록 실패로 끝나고, 본인 소유 저번호 수신자가 있을 때만 오지정이 성립한다(본문 Note 미확인 항목 해소).POST /users/receivers는email필수(수신자 본인 인증용) — 팝업 입력(이름·관계·전화번호)만으로는 정식 수신자를 만들 수 없어, 시안 팝업은 현 BE 계약 위에서 성립하지 않는다.방향 확정 — 본문 원안(선택 화면 경로 통일)으로 진행. 시안 팝업을 살리는 (b)류 접근은 위 email 필수로 막혀 있고, #540 의 PM 논의 흐름(기존 수신자 선택 + 신규는 정식 등록 화면 경유)이 팝업을 대체하는 방향이라 다이얼로그 폐기가 그와 정합한다.
잔여 명시: 이 수정으로 갤러리
+버튼은 소셜·추모와 같은onNavigateToSelectReceiver경로가 되는데, 그 라우팅 자체가 미결선(no-op)인 것은 #540 범위다(에뮬 실측 2026-08-08: 소셜·갤러리 모두 탭 무반응). #540 해소 시 갤러리도 함께 동작한다.OnlyReadOneBook commentedon Aug 8, 2026
착수 전 시안 대조 결과(Note 요구 항목) — 시안은 직접 입력이 맞습니다.
2. Screen Design애프터노트 작성 페이지 대역의 갤러리 에디터 프레임에 수신자 직접 입력 다이얼로그가 그려져 있습니다.2026-08-08 이후 버전 스냅샷 diff 로도 이 프레임들은 무변경이라 현행 정본입니다.
같은 프레임의 처리 방법 항목 "추가 수신자에게 정보 전달 — 설정된 수신자 이외의 추가적인 수신자를 지정"과 묶어 보면, 이 다이얼로그는 등록된 수신자 목록에 없는 제3자를 이름·관계·전화번호로 지정하는 수단이라 선택 화면 경로로 대체되지 않습니다. Note 의 분기대로 해결 방향은 다이얼로그 유지 + 서버가 이름·관계를 받는 계약 변경 선행입니다.
(참고: 선택 화면 경로로 통일하는 수정을 먼저 만들어 두었으나 — feat/680 의 b9415a3 — 위 대조 결과와 충돌해 PR 미생성 상태로 보류합니다.)
OnlyReadOneBook commentedon Aug 8, 2026
Note
바로 위 코멘트의 판정을 정정합니다.
위에서 "시안은 직접 입력이 맞다 → 다이얼로그 유지 + BE 계약 변경 선행"으로 판정했는데, 그 다이얼로그 프레임에 달린 댓글 스레드를 빠뜨린 오판이었습니다.
다이얼로그 프레임 700-38183 의 핀 스레드 — 08-04 질의(댓글 1870829478) "애프터노트 작성 화면에만 미등록 수신자 직접 추가 기능이 있고, 타임레터·마인드레코드는 기존 수신자 선택만 제공됩니다. 의도된 차이인가요?"에 전건호 PM 이 08-06 답글(댓글 1873986804)로 방향을 확정했습니다.
즉 시안의 직접 입력 다이얼로그는 이 답글로 폐기 방향이 확정된 낡은 프레임이고, 본 이슈의 "수신자 선택 화면 경로로 통일" 작업이 그대로 유효합니다. 위 코멘트의 보류도 해제하고 PR 을 진행합니다. 시트 형태·신규 등록 진입·복귀 자동 선택은 #540 의 구현 사양이 됩니다.