Repository navigation
수신자 프로필 사진이 시안에만 있다: 배지를 붙일지 걷을지 확인한다 #2064
Description
작업 유형
enhancement — 신규 기능·기존 기능 개선
주 담당 모듈
setting — 설정
개요
수신자 등록·수정 화면의 프로필 사진 자리에 시안은 사진 추가 배지를 두는데, 사진을 담을 자리가 FE 모델에도 서버 응답에도 없다.
- 시안: 수신인 등록의 프로필 그룹은 아바타(
92:8264인스턴스, 134×136)와plus_button(52:7886인스턴스, 48×48) 둘로 이뤄져 있다. - 코드:
ReceiverDetail(core/model/src/main/kotlin/com/afternote/core/model/user/UserModel.kt:17)에 이미지 필드가 없고, 등록·수정 요청도 이름·관계·연락처·이메일·메시지만 보낸다. 화면은 언제나 기본 아바타만 그린다.
#2003 이 이 자리를 core 자산으로 옮기면서 배지는 그리지 않았다. 선택 경로가 없는 배지를 그리면 눌러도 아무 일이 없고, 그런 상호작용은 접는 것이 docs/convention/composable-callback-defaults.md 의 처분 기준이기 때문이다. 그래서 지금 이 화면은 시안과 달리 배지가 없는 상태다.
완료 조건
- 수신자에게 사진을 붙이는 것이 현재 범위인지 PM 에 확인한다
- 범위라면 서버 계약(수신자 이미지 필드와 업로드 경로)을 확인하고
ProfileImagePicker로 배선한다. 발신자 프로필이 쓰는ProfilePhotoSourceState가 그대로 재사용된다 - 범위가 아니라면 시안에서 배지를 걷도록 요청하고 이 이슈를 닫는다
자식 이슈
참고
RecipientSetScreen 은 #1064 가 화면째 지우므로 이 이슈의 대상이 아니다.
화면 증거
오른쪽이 시안 프로필 그룹 4327:64518 로, 아바타에 사진 추가 배지가 붙어 있다. 가운데가 #2003 적용 후 현행 화면이고 배지가 없다.
Activity
OnlyReadOneBook commentedon Sep 13, 2026
PM 전건호에게 Figma 댓글로 질문했다(2026-09-13). 이 이슈는 그동안 PM 확인 대기로 분류돼 있었지만 실측해 보니 어느 채널에도 발신 기록이 없었다. 이번이 첫 발신이다.
4327:64518수신자 등록 화면의 아바타 + plus_button 그룹 (정리 Screen Design > 설정 > 수신자 등록 > Frame 3245 > Frame 1321318011)message_meta로 보내 알림이 가도록 했다. 평문@이름은 알림이 가지 않는다.물은 것은 묵은 본문의 질문을 그대로 옮긴 것이 아니라 origin/develop 86ab223 실코드와 현재 시안으로 다시 벼린 것이다.
본문에 있었지만 이번 질문에서 뺀 축:
(1) 본문의 «#2003 이 core 자산으로 옮기면서 배지를 안 그려 지금 화면에 배지가 없다» 는 전제를 뺐다. 86ab223 에 ProfilePhotoWithAddBadge 는 존재하지 않고 배지는 여전히 그려져 있다. #2003 은 OPEN 이고 PR #2067 도 OPEN(base 가 feat/1438-profile-photo 라 develop 에 안 들어왔다). (2) 본문의 «서버 계약(수신자 이미지 필드와 업로드 경로) 확인» 은 뺐다. PM 답이 1번일 때만 생기는 BE 몫이고, 지금 계약에는 필드 자체가 없다. (3) 본문이 시안 근거로 적은 노드 4327-64519 는 아바타 인스턴스 하나일 뿐 배지를 포함하지 않는다. 배지까지 든 그룹은 부모 4327:64518 이라 앵커를 그쪽으로 옮겼다. (4) 카톡 초대 전환(BE#289, 2026-09-08)으로 수신자가 자기 카카오 계정을 갖게 되므로 «발신자가 올린다» 만 묻지 않고 계정 사진 승계를 선택지 2로 넣었다.
OnlyReadOneBook commentedon Sep 13, 2026
답을 기다리는 동안 상태를 굳혀 둔다. 2026-09-13 22:27 KST, FE
origin/develop7d87aa3, BEmain기준이다. 답이 오면 이 이슈를 다시 조사하지 말고 여기서 바로 착수하면 된다.기다리는 답
PM 전건호에게 Figma 댓글 스레드 1923877263으로 물었다(2026-09-13T12:02:20Z 발신, 앞 코멘트). 선택지는 셋이다. (1) 발신자가 수신자 사진을 올린다, (2) 수신자가 수락한 카카오 계정 사진을 승계한다, (3) 사진을 안 쓰고 시안에서 배지를 걷는다.
발신에서 이 글까지 1시간 25분 지났다. 이번 세션은 Figma MCP 가 미인증이고 REST 도 쓰지 않아 답글 수를 다시 세지 못했다. 앞 코멘트 시점의 실측은 답글 0건이었다. 착수 전에 그 스레드를 먼저 열어 볼 것.
BE 실코드: 수신자 이미지 필드도 업로드 경로도 없다
gh api repos/Afternote/Afternote-BE/contents/로main을 직접 읽었다.src/main/java/com/afternote/domain/receiver/model/Receiver.java의 컬럼은id,userId,acceptedUserId,name,relation,phone,email,message,sortOrder와afternoteReceivers연관뿐이다. 이미지 컬럼이 없다.domain/receiver/dto23개 파일에 수신자 사진용 요청이 없다.ReceiverPresignedUrlRequest는 이름만 비슷하고, 코드 검색상domain/receiver/controller/ReceivedRecordController.java한 곳에서만 쓰인다. 수신자 기록함 첨부 업로드용이다.domain/user/dto/ReceiverDetailResponse.java,ReceiverListResponse.java,UserPatchReceiverRequest.java어디에도 이미지 필드가 없다.domain/user/controller/UserController.java의 수신자 엔드포인트는GET /receivers,GET /receivers/{id},PATCH /receivers/{id},PATCH /receivers/{id}/message,PATCH /receivers/{id}/relation,DELETE /receivers/{id}다.POST /users/receivers가 없다(BE#289).domain/receiver/controller/ReceiverInvitationController.java의POST /api/v1/receiver-invitations/{token}/accept하나다. 그 뒤Receiver.fromAcceptedInvitation이 수락한 회원의name,phone,email을 그대로 채우고acceptedUserId를 남긴다.domain/user/model/User.java:40에profileImageUrl(length 1000)이 있고,domain/auth/service/social/KakaoLoginService.java:77,85가 카카오profile_image_url을 그대로 넣는다.여기서 갈래별 비용이 갈린다. (1)번은 receiver 테이블 컬럼 신설과 presigned URL 경로와 쓰기 엔드포인트가 전부 새로 필요하고, 그 값을 실어 보낼 등록 요청 자체가 BE 에 없다. BE 이슈도 아직 서 있지 않다. (2)번은
Receiver.acceptedUserId에서User.profileImageUrl로 조인해 응답 필드 하나를 늘리면 끝이라 새 컬럼도 업로드 경로도 필요 없다.답이 "붙인다"로 올 때 FE 가 손댈 자리
배지를 실제로 그리는 것은 (1)번일 때뿐이다. (2)번은 발신자가 고를 수 없으니 배지 없이 사진만 표시한다.
공통으로 건드리는 자리는
feature/setting/presentation/src/main/kotlin/com/afternote/feature/setting/presentation/screen/ReceiverRegisterScreen.kt:184-203이다. 지금은Box(134.dp)안에ic_default_profile을fillMaxSize로 깔고, BottomEnd 48dp 칸에ic_plus를requiredSize(72.dp)로 그리는 인라인 블록이고clickable이 없다. 이 블록은 등록·수정 공용이다. 같은 파일 94행ReceiverRegisterContent를ReceiverEditContent.kt:31이title,actionText만 바꿔 재사용한다.core/ui/src/main/kotlin/com/afternote/core/ui/ProfileImage.kt:50의ProfileImagePicker(onPickClick = ...)로 갈아끼운다. 이미 온보딩과 애프터노트와 발신자 등록이 쓰는 컴포넌트라 새로 만들 것은 없다.ProfileImage(displayImageUri = ...)를 쓴다.core/model/src/main/kotlin/com/afternote/core/model/user/UserModel.kt:17의ReceiverDetail,core/network/src/main/kotlin/com/afternote/core/network/dto/UserDto.kt:11(UserCreateReceiverRequestDto)·:20(UserPatchReceiverRequestDto)·:79(ReceiverDetailDto),core/network/src/main/kotlin/com/afternote/core/network/service/UserApiService.kt:39,51의 요청 바디. 전부 BE 가 필드를 낸 뒤에 손댄다.feature/setting/presentation/src/screenshotTestDebug/reference/com/afternote/feature/setting/presentation/screen/ReceiverEditScreenScreenshotTestKt/아래receiverEditScreenCompactScreenshot_c2abd7e6_0.png,receiverEditScreenScreenshot_748aa731_0.png.(1)번에는 발이 하나 더 걸린다.
UserApiService.kt:39가 아직@POST("users/receivers")를 부르는데 BE 에는 그 엔드포인트가 없다. 사진을 등록 폼에 붙이는 일은 이 폼이 계속 존재하는지부터 정해져야 한다.답이 "걷는다"로 올 때 FE 가 손댈 자리
FE 코드 변경은 #2003 의 PR #2067 이 이미 들고 있다. 그 PR 이 같은 자리를 표시 전용
ProfileImage()로 바꾸고,component/ProfilePhotoWithAddBadge.kt(84줄)와res/drawable/ic_plus.xml을 지우고, 위 골든 2장을 갱신한다. 다만 base 가feat/1438-profile-photo라#2044 → #2067순으로 들어온다. 둘 다 OPEN 이다.그래서 (3)번으로 답이 오면 이 이슈에 남는 일은 디자이너에게 시안의
plus_button을 걷어 달라고 요청하고 닫는 것뿐이다. (2)번으로 와도 배지가 걷히는 것은 같고 사진 표시만 더 붙는다.본문이 지금 실태와 어긋나는 항목
ReceiverRegisterScreen.kt:198의ic_plus). fix(setting): 프로필 사진 자리가 앱 나머지와 다른 자산·배지로 그려진다 (#1782 후속) #2003 도 PR fix(setting): 프로필 사진 자리를 core 자산·배지로 맞춘다 (#2003) #2067 도 OPEN 이고 base 가feat/1438-profile-photo라 develop 에 들어온 적이 없다.ProfilePhotoSourceState는 develop 전수 grep 0건이다.feat/1438-profile-photo(PR fix(setting): 프로필 사진 선택·촬영·업로드·저장 연결 (#1438) #2044, OPEN, basehandoff/1920-setting-1hyok)에만 있다. 이 재사용을 전제로 잡으면 fix(setting): 프로필 사진 변경이 통째로 미구현 — 플러스 배지 무동작·서버 이미지 미표시·profileImageUrl null 하드코딩 #1438 이 선행이 된다.ProfilePhotoWithAddBadge도 develop 0건으로, PR fix(setting): 프로필 사진 자리를 core 자산·배지로 맞춘다 (#2003) #2067 이 지우는 대상으로만 존재한다.4327-64519에 대해, 앞 코멘트가 REST 로 재서 아바타 인스턴스 하나이고 배지까지 든 그룹은 부모4327:64518이라고 기록해 두었다. 이번 세션에서는 Figma 를 열 수 없어 그 값을 다시 재지는 못했다.RecipientSetScreen은 참조 0건 잔재 5파일 삭제 — 도달 불가 화면 1 · 대체된 ViewModel 1 · 죽은 컴포넌트 2 #1064 가 화면째 지운다"는 유효하다.RecipientSetScreen.kt:38이 develop 에 살아 있고 참조 0건 잔재 5파일 삭제 — 도달 불가 화면 1 · 대체된 ViewModel 1 · 죽은 컴포넌트 2 #1064 는 OPEN 이며 워크트리.codex/worktrees/1064-setting-unused가 따로 있다.미착수 확인
브랜치 0건(
git ls-remote --heads origin | grep 2064), 커밋 0건(git log origin/develop --grep=2064), 워크트리 0건, PR 0건이다.gh pr list --search 2064에 #2067 이 걸리는 것은 그 PR 본문이 "수신인 등록의 배지는 #2064 로 분리했습니다" 라고 이 이슈를 가리키기 때문이고, PR 자체는 #2003 의 것이다.blocked_by와blocking모두 빈 배열인데, PM 답 대기는 GitHub 의존으로 표현할 수 없는 종류라 이건 정상이다.OnlyReadOneBook commentedon Sep 18, 2026
PM 결정 대기 항목은 깃허브 이슈로 두지 않고 피그마 질문 한 자리에만 둔다(2026-09-18 결정). 이 이슈의 질문은 피그마 스레드에 걸려 있다: https://www.figma.com/design/UP9ZR186jHvRBicjA2SOea/?node-id=4327-64518#1923877263 답이 오면 그 답을 근거로 구현 이슈를 새로 만든다.