Repository navigation
fix(setting): 프로필 사진 자리가 앱 나머지와 다른 자산·배지로 그려진다 (#1782 후속) #2003
Description
작업 유형
bug — 버그·오동작
주 담당 모듈
setting — 설정
개요
수신자 등록·수정의 공용 본문이 사용하는 표시 전용 아바타의 자산과 배지 기하를 확인된 시안에 맞춘다.
2026-10-07 develop 929fa8ca73233d4ffae6b1e6ca5ca85c4efa0300 기준:
- 프로필 수정 화면은 PR #2152에서 core
ProfileImagePicker와 실제 사진 선택 흐름으로 전환됐다. 이 부분은 추가 구현 대상에서 제외한다. ReceiverRegisterContent가ProfilePhotoWithAddBadge를 사용하고,ReceiverEditContent도 이 본문을 재사용한다. 등록·수정 양쪽에 표시되는 공용 영역이다.ProfilePhotoWithAddBadge는 표시 전용이다. 현재 클릭·사진 선택 계약을 확장하지 않고 시각적 불일치만 수정한다.
시안의 core 자산 일치 판정은 기존 실측 댓글에 있다. 아바타는 컴포넌트 92:8264, 배지는 52:7886이다.
현재 setting 기본 자산의 어깨 폭은 뷰포트의 57.7%이고, 시안과 core 자산은 약 70%다. 배지는 48dp 칸에 72dp 벡터를 그려 칸을 넘치며 원의 크기와 중심도 시안과 다르다.
완료 조건
- 시안의 아바타·배지 자산과 기하를 판정한다. 기존 실측 근거를 참조한다.
- 프로필 수정 화면을 실제 사진 선택 콜백이 연결된 core
ProfileImagePicker로 전환한다. PR #2152에서 완료됐다. - 수신자 등록·수정 공용 표시 영역의 아바타를 확인된 core 자산에 맞추고 배지의 크기·위치를 시안에 맞춘다.
- 기존 표시 전용 계약을 유지한다. 사진 선택·업로드를 추가하거나 배지 제공 여부를 새로 결정하지 않으며 no-op 콜백을 만들지 않는다.
- 실제 소비처를 대조해 참조가 없어진 자산만 정리한다. 설정 첫 화면이 사용하는 기본 아바타를 일괄 삭제하지 않는다. 컴포넌트 삭제 자체를 완료 조건으로 삼지 않는다.
- 관련 화면의 스크린샷 baseline을 갱신하고 전후 결과를 PR에 첨부한다.
선행 관계와 제외 범위
#1438의 프로필 사진 기능은 완료됐고 현재 잔여 시각 변경의 선행이 아니다.
#944는 수신자 등록의 초대 계약·상태·진입 흐름을 전환한다. 현재 수신자 수정 화면도 이 표시 영역을 소비하며, #944가 공용 표시 컴포넌트를 교체한다는 확정 근거는 없다. 따라서 같은 파일의 등록 흐름을 바꾼다는 이유로 #944를 이 이슈의 blocked_by로 연결하지 않는다. 이 이슈는 등록 API·ViewModel·상태·내비게이션 배선을 수정하지 않는다. 착수 시 최신 전환 diff에서 표시 영역의 실제 교체가 확인되면 해당 범위의 순서를 다시 판정한다.
수신자 사진 제공 방식은 기존 Figma 질문에서 별도로 확인한다. 사진 기능과 배지 제공 여부를 결정하는 구현은 이 이슈의 완료 조건에서 제외한다. #1820·#1821은 다른 피처의 콜백 정리이므로 이 이슈의 선행이 아니다.
화면 증거
기존 적용 전후 비교와 시안 프로필 그룹이다. 과거 PR #2067은 병합 없이 닫혔으므로 이 그림을 현재 develop의 적용 완료 근거로 취급하지 않는다.
구현·검증 결과
PR #2293에 구현과 CI 표준 baseline 2개를 반영했다. 전후 픽셀 변경은 두 화면 모두 아바타·배지 영역에 한정된다. 최신 HEAD a0e08c76a300076ec282a6a9dd1f54f359cb41e3의 스크린샷·Android lint·ktlint·CodeQL 검사가 통과했고 단위 테스트 검사도 통과했다. 최신 리비전 검증 실행. 이슈는 PR 병합 때 닫는다.
Activity
github-actions commentedon Sep 13, 2026
bug 이슈는 사이드바 Fields > Priority 로 심각도를 지정해야 합니다. 판정 기준:
값이 비어 있어도 이슈를 닫지는 않습니다. 이 안내는 이슈당 한 번만 답니다.
OnlyReadOneBook commentedon Sep 13, 2026
실측: 시안은 core 자산이다. 본문 전제 셋도 함께 대조했다
착수 게이트였던 완료 조건 1번을 Figma REST 로 떴고, 본문이 근거로 든 전제들을
origin/develop86ab223에서 다시 셌습니다.시안 판정
두 화면 모두 같은 그룹
Group 3297하나를 씁니다. 그 안에 프로필 컴포넌트 인스턴스와 배지 컴포넌트 인스턴스가 들어 있습니다.4327:71106의 프로필 노드4327:711104327:64515의 프로필 노드4327:64519둘 다 componentId 가
92:8264(134 x 135.5)이고, 짝이 되는 배지는 componentId52:7886(48 x 48)입니다.92:8264의 기하를geometry=paths로 받아 컴포넌트 원점 기준으로 재니core_ui_ic_profile_placeholder와 경로 단위로 같습니다.92:8264core_ui_ic_profile_placeholder(viewport 134 x 136)#616161#616161ic_default_profile(viewport 60)의 어깨는 x 12.678-47.322 로 폭 34.644, 뷰포트 대비 57.7% 입니다. 시안의 94/134 = 70.1% 와 다릅니다.배지도 core 쪽과 맞습니다. 시안 인스턴스는 134 박스 안에서 x 86-134, y 87-135 에 놓인 48 x 48 이고, 검은 원(
#212121)이 그 칸을 지름 48 로 꽉 채웁니다. core 의ProfileImagePicker는PlusBadgeButton(size = 48.dp)을 BottomEnd 에 둡니다. develop 의 setting 쪽은 48dp 칸에ic_plus를requiredSize(72.dp)로 그리고, 그 벡터에서 실제 칠해지는 원은 viewport 80 안 지름 48 중심 (40, 36) 이라 43.2dp 이고 칸 중심에서 위로 어긋납니다.본문 전제 대조
본문이 "refactor(setting): 네 화면에 복제된 프로필 이미지 크기 134dp 를 단일 출처로 모은다 #1782 는 setting 두 화면의 복제를
ProfilePhotoWithAddBadge하나로 모으는 데까지만 했고" 라고 완료형으로 쓰는데,origin/develop에 그 심볼은 0건입니다(전수 grep). 파일도 없습니다. 그 컴포넌트는 아직 열려 있는 PR 두 개에만 있습니다. refactor(setting): 복제된 프로필 이미지 크기 134dp 를 단일 출처로 모은다 (#1782) #2009(refactor(setting): 네 화면에 복제된 프로필 이미지 크기 134dp 를 단일 출처로 모은다 #1782)과 fix(setting): 프로필 사진 선택·촬영·업로드·저장 연결 (#1438) #2044(fix(setting): 프로필 사진 변경이 통째로 미구현 — 플러스 배지 무동작·서버 이미지 미표시·profileImageUrl null 하드코딩 #1438)이고, fix(setting): 프로필 사진 선택·촬영·업로드·저장 연결 (#1438) #2044 의 base 는 develop 이 아니라handoff/1920-setting-1hyok입니다. develop 의ProfileEditScreen.kt:132-151과ReceiverRegisterScreen.kt:184-203은 여전히 같은 블록을 복제한 상태입니다.완료 조건 3번이 막으려는 no-op 콜백은 지금 만들 자리가 없습니다. fix(setting): 프로필 사진 선택·촬영·업로드·저장 연결 (#1438) #2044 의
ProfilePhotoWithAddBadge는onAddClick: (() -> Unit)?로 콜백을 nullable 로 두고 디폴트를 주지 않습니다.ProfileEditScreen.kt:199-204는 실제 picker 핸들러를 넘기고(저장 중이면null),ReceiverRegisterScreen.kt:182는onAddClick = null을 넘깁니다. 배지 클릭 배선 자체가 fix(setting): 프로필 사진 변경이 통째로 미구현 — 플러스 배지 무동작·서버 이미지 미표시·profileImageUrl null 하드코딩 #1438 의 범위에서 이미 다뤄지고 있습니다.완료 조건 3번이 근거로 든 refactor(mindrecord): 화면 no-op 콜백 31건 — #1540 에서 MVI 재작성분 분리 #1820 과 refactor(timeletter): 화면 no-op 콜백 24건 — #1541 에서 MVI 재작성분 분리 #1821 은 이 화면과 무관합니다. refactor(mindrecord): 화면 no-op 콜백 31건 — #1540 에서 MVI 재작성분 분리 #1820 은 mindrecord 의 no-op 콜백 31건(
area:mindrecord), refactor(timeletter): 화면 no-op 콜백 24건 — #1541 에서 MVI 재작성분 분리 #1821 은 timeletter 24건(area:timeletter)입니다.github-actions commentedon Sep 13, 2026
이 이슈를 맡은 PR 은 #2067 다 (base
feat/1438-profile-photo).base 가 기본 브랜치(
develop)가 아니라서 GitHub 은 이 이슈의 Development 칸에아무것도 표시하지 않는다. 본문에
Closes #N이 있어도 마찬가지다 — 그 링크는 기본 브랜치를target 하는 PR 에서만 만들어진다.
PR 이 닫히거나 머지되면 이 이슈의
pr-open라벨은 다음 리컨사일에서 떨어진다.