refactor(afternote): data/mapper 명명·배치 정리 — 같은 방향 매핑이 파일 3개·함수명 2종으로 갈림 #932

2026-08-24 2차 정정 (구현 착수 실측, develop efbb1256 기준). 아래 표·처방 중 3건을 고친다.

1. 표의 ReceiverAfternoteListItemDtoToDomain.kt · response/ReceivedAfternoteDetailMapper.kt 2행은 범위 밖이다.
   이슈 작성(08-23 20:26 KST) 뒤 PR refactor(afternote): 수신자 흐름 전체(155파일)를 :feature:receiver 로 이전 — 열람 관문 소유 해소 #919(refactor/615, develop 머지 08-24 13:35 KST)가 수신자 흐름 전체를
   :feature:receiver 로 옮겼다. 현재 feature/afternote/data/mapper/ 는 8개다.
2. "함수명도 toDto/toRequest 중 하나로 통일" 은 철회한다. 레포 표준을 실측하니 두 이름은 같은 뜻이 아니다 —
   toRequest = 요청 바디 루트(*RequestDto), toDto = 그 안에 실리는 부분 DTO.
   mindrecord DiaryMapper.kt 가 한 파일에서 TodayMood.toDto() 와 DiaryCreatePayload.toRequest() 를 함께 쓴다.
   afternote 의 InputToDto(부분) / InputToRequest(루트) 분업은 이미 그 규약과 일치해, 하나로 합치면 오히려 표준에서 이탈한다.
   실제 함수명 이탈은 따로 있다 — 상세 응답의 toDetailDomain (레포 표준은 toDomain, receiver·mindrecord·timeletter 전부 toDomain).
3. "refactor(afternote): 응답 DTO 보정형 기본값 정리 — 누락 계약을 빈 값으로 은폐하지 않는다 (#789·#790 애프터노트 판) #957 과 한 PR 로 묶으면 충돌이 적다" 는 철회한다. 접촉면이 갈린다 — refactor(afternote): 응답 DTO 보정형 기본값 정리 — 누락 계약을 빈 값으로 은폐하지 않는다 (#789·#790 애프터노트 판) #957 은 DTO 파일 3종(AfternoteDto·ReceiverAfternoteDto·MusicDto),
   이 이슈는 mapper 파일. 겹치는 파일이 없어 묶을 이유가 없고, refactor(afternote): 응답 DTO 보정형 기본값 정리 — 누락 계약을 빈 값으로 은폐하지 않는다 (#789·#790 애프터노트 판) #957 은 실서버 응답 실측이 선행 조건이라 일정도 다르다. 단독 PR 로 간다.

2026-08-24 범위 축소. 종전 본문의 "DTO 에 계약 근거 주석 부재 8건" 항목을 철회한다 —
엔드포인트는 ApiService 와 Swagger 에, nullable 근거는 BE @Schema(description) 에 이미 있다.
FE 가 그걸 KDoc 으로 복제하면 정본이 둘로 갈리고, BE 가 바뀔 때 FE 주석만 낡아 거짓이 된다.
실제로 Detail.kt 의 계약 설명 주석은 전부 낡아 #676 에서 삭제됐다.
매퍼 명명·배치 정리만 남긴다.

feature/afternote/data/mapper/ 만 명명 규칙이 레포 표준과 갈려 있어, 매핑 하나를 찾으려면 파일 세 개를 열어야 한다.

레포 표준

core/data/mapper/{auth,delivery,user}/*Mapper.kt      도메인별 폴더 + Mapper 접미사
feature/mindrecord/data/mapper/*Mapper.kt             평면 + Mapper 접미사   (4개)
feature/timeletter/data/mapper/*Mapper.kt             평면 + Mapper 접미사   (2개)

afternote 만 5종

• 도메인 → wire 매핑 하나를 찾으려면 InputToDto · PlaylistInputToDto · InputToRequest 세 파일을 다 열어야 한다.
• response/ 하위 폴더는 있는데 대칭인 request/ 가 없어 요청 매퍼만 루트에 평면으로 남아 있다.

할 일

방향(요청/응답)과 대상 도메인이 파일명으로 드러나게 정리하고, 함수명도 toDto/toRequest 중 하나로 통일한다.
같은 모듈 DTO 를 #957 이 건드리므로 한 PR 로 묶으면 충돌이 적다.

조사했으나 문제가 아니었던 것

재조사 방지용으로 남긴다.

• AfternoteAuthoringFailureMapper 가 mapper/ 밖(repositoryimpl/author/)에 있는 것은 이탈이 아니다.
  core/data/repoimpl/account/AccountFailureMapper.kt 도 같은 배치라, 실패 매퍼는 구현 옆이라는 별도 패턴으로 일관된다.
• presentation 계층의 매퍼 6개(AfternoteDetailSuccessMapper · ReceivedAfternoteDetailSuccessMapper ·
  AfternoteEditorFormMapper · SongMapper · MindRecordUiMapper 등)는 DTO 를 전혀 참조하지 않는다.
  전부 도메인 → UI 매핑이라 presentation 에 있는 것이 정상이다.
• MappingUtils.categoryToAfternoteType 과 AfternoteCategoryCodec.afternoteTypeFromServerCategory 는 중복이 아니다.
  전자가 후자를 호출하고, 값 표의 정본이 어디인지 KDoc 에 명시돼 있다.