[RosieOh]

남은 도메인 경계 위반 237건 중 → user 가 92건으로 가장 큰 덩어리입니다. 각 도메인이 User 로 무엇을 하는지 세어 보다가 발송 경로에서 이걸 발견했습니다.

무슨 일이 일어나나

탈퇴는 물리 삭제가 아닙니다(User.withdraw() — #146에서 양쪽 경로를 통일했습니다). 행이 남고 isActive=false, deletedAt 이 찍히며 이메일은 deleted_<id>@deleted.local 로 익명화됩니다. 그런데 그 사용자가 남긴 대기 등록·알림 설정·푸시 토큰은 그대로 남습니다.

어린이집 대기를 걸어 둔 사람이 탈퇴한다
→ 대기 기록은 WAITING 으로 남아 있다
→ 그 시설에 자리가 난다
→ FacilityVacancyNotifier 가 entry.getUser() 로 알림을 만들고 발송한다
→ 탈퇴한 계정의 기기로 푸시가 가고, 익명화된 주소로 메일이 나간다

NotificationDispatcher 는 수신자가 null 인지만 봤습니다.

User recipient = notification.getUser();
if (recipient == null) { ... return false; }
// 탈퇴·비활성 여부는 보지 않는다

막는 자리는 한 곳

발송 경로는 넷이지만(리마인더 배치, 빈자리·마감 알림, 사용자 API, 어드민) 전부 이 디스패처를 거칩니다. 그래서 여기 하나에 조건을 넣었습니다 — 경로마다 검사를 넣으면 다음 경로가 생길 때 또 빠집니다. (#145 에서 어드민 발송이 디스패처를 아예 거치지 않던 것을 고친 덕에 이제 네 경로가 모두 여기로 모입니다.)

관리자가 비활성화한 계정도 같게 봅니다. 로그인할 수 없는 계정에 알림을 보낼 이유가 없습니다.

인앱 알림 레코드 자체는 막지 않습니다. 이미 저장된 뒤라 여기서 되돌릴 수 없고, 조회 API 가 인증을 요구하므로 탈퇴 계정은 어차피 볼 수 없습니다.

테스트

먼저 실패를 확인했습니다 — 탈퇴·비활성 계정 모두 Expecting value to be false but was true.

차단이 과하면 아무에게도 알림이 가지 않으므로 "정상 계정은 차단되지 않는다" 도 함께 고정했습니다.

기존 테스트 하나가 깨졌습니다

NotificationChannelAvailabilityTest 의 수신자 픽스처가 isActive 를 설정하지 않아 "비활성" 으로 읽혔습니다. 실제 저장된 사용자는 @PrePersist 가 true 로 채우므로 픽스처를 맞췄고, 왜 명시해야 하는지 주석으로 남겼습니다.

판단: isActive == null 을 "받을 수 없음" 으로 봅니다. 저장된 사용자에게는 null 이 생기지 않고(위 @PrePersist), 발송 경로에서는 모르는 상태를 보내지 않는 쪽이 안전합니다.

숫자

• 전체 테스트 650개, 실패 0