feat: 탈퇴자의 채팅 메시지를 삭제 대신 "(알 수 없음)"으로 표기 #849

어떤 기능인가요?

탈퇴자의 채팅 메시지를 삭제하는 대신, 발신자를 (알 수 없음)으로 표기하고 메시지는 남기는 방향을 검토합니다.

현재 동작 (#848)

• 1:1 채팅방: 참여자 한 명이 사라지면 유지될 수 없으므로 방 전체를 삭제
• 그룹 채팅방: 방과 다른 멤버는 유지하고, 탈퇴자의 메시지·읽음 상태·참여자 행만 삭제

왜 바꾸려는가

그룹 대화에서 한 사람의 메시지만 빠지면 남은 대화가 읽히지 않습니다. 질문이 사라지고 "응 그게 맞아" 같은 답변만 남습니다. 그룹 채팅방을 만드는 경로는 아직 없지만, 도입되면 바로 드러나는 문제입니다.

1:1 채팅방에도 같은 방식을 적용할지는 따로 판단이 필요합니다. 상대는 누구와 대화했는지 이미 알고 있어서 표기를 가리는 실익이 적고, 상대가 떠난 1:1 방은 더 쓸 수도 없습니다.

논의가 필요한 사항

발신자 표기를 가려도 메시지 본문은 그대로 남습니다. 대화에는 이름, 연락처, 학교, 지원 현황이 들어갈 수 있어서, 이건 표기 방식이 아니라 탈퇴자 데이터를 어디까지 보관할지의 문제입니다. 세 가지 선택지가 있습니다.

두 번째가 절충안으로 검토할 만합니다.

구현 시 걸리는 제약

스키마 사슬

chat_message.sender_id는 NOT NULL이고 chat_participant.id를 참조합니다. 메시지를 남기려면 참여자 행을 남겨야 하는데, chat_participant.site_user_id도 NOT NULL이고 site_user를 참조합니다. 사슬을 끊으려면 둘 중 하나를 택해야 합니다.

• sender_id를 nullable로 바꾸고 탈퇴 시 NULL 처리
• site_user 행을 지우지 않고 닉네임·이메일·프로필만 비우는 tombstone 방식 (물리 삭제 자체를 포기)

읽기 경로

• ChatService:139 buildParticipantIdToParticipantMap이 senderId로 참여자를 조회해 발신자 정보를 만듭니다. 발신자가 없는 메시지를 다룰 수 있어야 합니다.
• 1:1 목록 조회는 더 까다롭습니다. ChatService:177 findPartner가 상대 참여자를 못 찾으면 CHAT_PARTNER_NOT_FOUND, ChatService:109가 상대 SiteUser를 못 찾으면 USER_NOT_FOUND를 던집니다. 이 메서드는 채팅방 목록 전체에 적용되므로, 방 하나가 깨지면 목록 API 전체가 실패합니다.

작업 상세 내용

• 보관 방식 결정 (위 세 가지 중 선택)
• 1:1 채팅방에도 적용할지 결정
• 스키마 변경 (sender_id nullable 또는 tombstone 설계)
• 발신자 렌더링 경로에 플레이스홀더 처리
• 1:1 목록 조회의 상대 조회 실패 경로 재설계 (적용하는 경우)
• UserRemovalScheduler의 채팅 삭제 로직 수정

참고할만한 자료

• fix: 외래키로 인해 물리적 탈퇴가 되지 않는 문제 수정 #848 — 현재 동작을 구현한 PR
• src/main/java/com/example/solidconnection/scheduler/UserRemovalScheduler.java — deleteOneOnOneChatRooms, deleteGroupChatParticipation
• src/main/resources/db/migration/V24__add_chat_related_tables.sql — 채팅 테이블 제약