수신자 열람 흐름 23개 파일이 afternote 모듈 리소스를 차용 — 수신자 전용 87개가 남의 소유, #926(홈) 밖 잔여 전량 #1066

:feature:receiver:presentation 의 열람 흐름 화면들이 자기 모듈이 아니라 :feature:afternote:presentation 의 R 을 통해 문자열·이미지를 가져다 쓴다. 이름이 이미 receiver_* 인 문자열 78개가 애프터노트 모듈의 strings.xml 에 들어 있다.

실측 기준 리비전: 6b381db8 (origin/develop)

어쩌다 이렇게 됐나

#615/PR #919 가 수신자 흐름 155파일을 이 모듈로 옮길 때 리소스는 의도적으로 두고 갔다. PR 본문 「경계 처리」:

리소스 이동 없음 — received_* 계열 문자열을 author 상세 화면들도 공유 사용해 프리픽스 분리가 불가. 이동 파일들의 기존 import ...afternote.presentation.R 이 그대로 유효하므로 본문 무변경. 수신자 전용 리소스 재배치는 후속.

#926(PR #1061)이 그 「후속」 중 수신자 홈 2파일만 처리한다. 이 이슈는 그 밖에 남는 전량이다.

실측

:feature:receiver:presentation 에서 com.afternote.feature.afternote.presentation.R 을 import 하는 파일은 25개(main)이고, #926 이 가져가는 홈 2개를 빼면 23개 + 유닛테스트 3개다. 참조하는 고유 리소스 심볼은 97개(string 87 · drawable 10).

심볼 97개는 세 갈래다

#919 가 "프리픽스 분리가 불가"라고 본 것은 C 10개에만 해당한다. 나머지 87개는 애프터노트 쪽 참조가 0건이라 그냥 옮기면 된다.

C 10개: core:ui 승격은 답이 아니다 (하나 빼고)

공유의 원인을 따라가 보면 리소스가 아니라 같은 UI 를 두 벌 그리고 있는 것이다.

양쪽 다 passwordVisible 토글을 각자 들고, 같은 DetailSection·DetailInfoRow(이미 공유 중)를 쓰고, 같은 문자열 6개를 참조한다. 문자열을 core:ui 로 올리면 두 벌 중복은 그대로 둔 채 참조처만 바꾸는 것이 된다 — 차용은 사라지지만 원인은 남는다.

판단 기준 — 참조 모듈 수가 아니라 "그리는 컴포넌트의 소유"

core:ui 의 strings.xml 18개가 어떻게 거기 있게 됐는지 실측하면 규칙이 나온다. 전부 core:ui 자신이 소유한 컴포넌트가 쓰는 문자열이다.

"타임레터"·"수신인 지정 완료" 처럼 도메인 어휘로 보이는 것도 여러 feature 가 참조해서 올라온 게 아니라, 그 문구를 그리는 컴포넌트(바텀탭·배지)가 코어에 있어서 딸려온 것이다. stringResource 로 이들을 참조하는 feature 모듈은 하나도 없다.

그래서 기준은 이렇게 선다.

• 리소스는 그것을 그리는 컴포넌트를 따라간다. 코어에 리소스를 두려면 그것을 쓰는 UI 가 코어에 있어야 한다 — refactor(receiver): 수신자 홈의 afternote R 차용 해소 — 소셜 아이콘·getIconResForType core:ui 승격, VM res id 매핑 제거 #926 이 AfternoteSourceIcon 을 core:ui 컴포넌트로 만들고 아이콘 4종을 함께 올린 것이 이 형태다.
• 두 모듈이 같은 문자열을 참조한다는 것 자체가 대개 같은 UI 를 두 벌 그리고 있다는 신호다. 참조 수를 근거로 코어에 올리면 중복 두 벌이 각자 코어를 보는 상태로 고정된다.

이 기준으로 보면 #926(코어행)과 이 이슈의 C 갈래(애프터노트 존치)가 갈리는 이유도 분명하다.

왜 고쳐야 하나

소유권이 흐려 남의 모듈 파일에서 충돌한다. 애프터노트의 strings.xml 은 항목 285개 중 118개(41%)가 receiv* 다. 수신자 문구 하나를 고치려면 애프터노트 모듈을 건드려야 하고, 반대로 애프터노트 담당이 자기 모듈 문자열을 정리하다 수신자 화면을 깬다. 수신자 모듈 자신의 strings.xml 은 22개뿐이다.

컴파일로도 테스트로도 안 잡힌다. 다른 모듈의 R 참조는 의존이 살아 있는 한 정상 컴파일된다. #1061 이 붙인 ReceiverHomeResourceKonsistTest 도 홈 패키지 한정이라, 이 23개 파일에서는 같은 차용이 지금도 새로 추가될 수 있다.

범위 밖 (같이 하지 않는다)

• implementation(projects.feature.afternote.presentation) 의존은 남는다. 리소스와 별개로 코드 심볼 27종을 실제로 쓴다 — reporting.AfternoteFailureStage/recordAfternoteFailure (각 6곳) · shared.detail.* 컴포저블 · shared.model.MessageBlockUiModel · author.navigation.DetailLoading/LoadError/DesignPendingContent 등. 이 이슈의 목표는 리소스 소유권 정정이지 의존 제거가 아니다.
• 계측(shouldReportInReceiverFlow·수신 스테이지)의 애프터노트 잔류는 refactor(afternote): 수신자 흐름 전체(155파일)를 :feature:receiver 로 이전 — 열람 관문 소유 해소 #919 가 별도 판단으로 미뤄 둔 몫 그대로.

완료 조건

• A 78개 · B 9개를 :feature:receiver:presentation 소유로 이동(B 는 리네임 포함), 참조 23파일 + 테스트 3파일 갱신
• AccountSection 두 벌을 shared/detail 하나로 통합 — 계정 섹션 문자열 6 + ic_lock 차용이 함께 소멸
• ic_playback — 재생 오버레이 통합 또는 core:ui 승격
• detail_title 은 애프터노트 존치, afternote_detail_load_error 는 core_ui_network_error_* 수렴 여부만 결론(실행은 refactor(core): 에러 문구 운반 타입 이원화 해소 — ErrorPayload 를 core UiText 로 수렴 #604 와 함께)
• ReceiverHomeResourceKonsistTest 의 가드를 수신자 presentation 전 패키지로 확대 — 자신이 아닌 feature 의 R import 금지
• 스크린샷 baseline 무변경 확인(리소스 이동·리네임은 렌더 결과에 영향 없음)

선행

이름 규칙의 정본은 #1071 이다. 이 이슈가 옮기는 87개는 옮기는 김에 최종 이름까지 맞춘다 — 같은 리소스를 두 번 만들지 않기 위해서다. :feature:receiver:presentation 의 프리픽스는 기존 22개가 전부 receiver_home_* 이므로 receiver_ 이고, A 갈래 78개는 이미 이 규칙을 만족해 이동만 하면 된다. #1071 1단계(리네임 0건, 설정만 추가)가 먼저 들어가면 빌드가 이를 강제한다.

PR #1061(#926) 착륙 후 착수한다 — 홈 2파일과 소셜 패턴 아이콘의 core:ui 승격 형태가 확정돼야 C 갈래 판단의 선례가 생긴다.