feat(S15P11A705-65): 회원 탈퇴 구현 (소프트 삭제·마스킹·세션 무효화)

[cherry-go-round]

배경 / 목적

MVP 기능범위에 회원 탈퇴가 포함되어 있고 API 명세 §2.1에 DELETE /me가 정의되어 있습니다. 정책 정의서 10장이 소프트 삭제 원칙을, ERD가 마스킹 대상을 정의합니다. 로그인과 독립적으로 검증·배포할 수 있어 별도 티켓으로 분리합니다.

Jira (필수)

• https://ssafy.atlassian.net/browse/S15P11A705-65
• 에픽: S15P11A705-72 [BE] 소셜 로그인 및 계정 관리

상위/관련 GitHub Issue

• 선행: feat(S15P11A705-63): Google 소셜 로그인·로그아웃과 JWT 쿠키 인증 도입 #32 (인증 도입) — 본인 인증이 전제입니다

상세 내용

상세 계약은 08_API_명세 §3.6에 이미 있습니다.

• DELETE /api/core/v1/me, 204. 본인 인증 요구
• member·social_account deleted_at 소프트 삭제
• social_account의 provider_user_id·email 마스킹 (개인정보 파기 대상)
• 해당 회원의 Refresh를 전부 무효화 — 탈퇴는 모든 기기에서 즉시 끊겨야 합니다. /me는 Refresh 쿠키 Path 밖이라 Access 쿠키로 회원을 식별합니다
• 인증 쿠키와 logged_in 표시 쿠키 만료

구현 주의 — repository.delete()를 쓰지 마세요

Member가 쓰는 @SQLDelete + @SQLRestriction 패턴을 SocialAccount에 그대로 적용하면, delete() 호출 시점에 Hibernate가 엔티티를 removed 상태로 보고 마스킹 변경이 flush되지 않습니다. @SQLRestriction 때문에 다시 조회해서 고칠 수도 없습니다.

도메인 메서드로 마스킹과 deleted_at을 한 UPDATE에 담습니다.

public void withdraw() {
    this.providerUserId = "deleted:" + this.id;   // 부분 유니크 충돌을 피할 유일값
    this.email = null;
    softDelete();
}

"마스킹 후 delete()" 순서로도 동작할 가능성이 있지만, removed 상태 엔티티에 UPDATE가 스케줄되는지는 Hibernate 7 기준으로 확인되지 않았습니다. 그 방식을 택한다면 아래 검증 테스트로 먼저 확인하고 결과를 구현 리포트에 남겨주세요.

검증은 native 쿼리로

삭제 표시된 행은 @SQLRestriction 때문에 리포지토리로 보이지 않습니다. 마스킹 확인은 JdbcTemplate으로 합니다 (#25의 MemberSoftDeleteTests와 같은 방식).

이번 범위 밖

해당 테이블이 아직 없어 구현할 수 없는 항목입니다. 문서에 남기고 후속으로 넘깁니다.

• record·context·collection·collection_record·follow 연쇄 소프트 삭제 (정책 10장)
• AI 파생 데이터 무효화 — ai.context_ai_state의 두 status → CANCELLED, ai.context_embedding.is_deleted = true (docs#14). context가 생긴 뒤 붙습니다. 물리 삭제가 아니라 무효화 표시입니다

place는 공용 데이터라 삭제 대상이 아닙니다.

할 일

• SocialAccount.withdraw() 도메인 메서드
• DELETE /me 컨트롤러·서비스
• 회원 단위 Refresh 전체 무효화
• 쿠키 3종 만료 (Access·Refresh·logged_in)
• native 쿼리 기반 검증 테스트
• 범위 밖 항목과 후속 조건을 문서에 기록

완료 조건

• 인증된 사용자가 DELETE /me를 호출하면 member와 social_account의 deleted_at이 설정된다
• provider_user_id와 email이 마스킹되어 원본 값이 조회되지 않는다 (native 쿼리로 검증)
• 마스킹과 deleted_at이 한 트랜잭션에서 모두 반영된다 — 둘 중 하나만 적용되는 경우가 없다
• 탈퇴 후 기존 인증 쿠키로 보호 경로를 요청하면 401
• 탈퇴 후 Redis에 해당 회원의 Refresh Token이 하나도 남지 않는다
• 응답에서 인증 쿠키와 logged_in 쿠키가 모두 만료된다
• 미인증 DELETE /me는 401
• 탈퇴한 계정과 동일한 provider·provider_user_id로 다시 로그인하면 신규 회원으로 가입된다
• 연쇄 소프트 삭제·AI 파생 데이터 무효화가 범위 밖인 사실과 후속 조건이 문서에 기록된다
• PostgreSQL Testcontainers 기반 통합 테스트로 위 항목을 검증한다
• ./gradlew clean check --no-daemon 통과

[colosair]

탈퇴 구현 시 AI 파생 데이터 무효화가 함께 들어가야 합니다

Team-PinLog/docs#14(§3.6, 2026-07-29 병합)가 탈퇴 시 처리할 항목에 두 줄을 추가했습니다.

대상	처리
ai.context_ai_state	두 status를 CANCELLED로 전이
ai.context_embedding	is_deleted = true 표시

나머지 삭제 경로 셋은 #80에서 구현했습니다 — Context 삭제(§6.5) · Context 수정의 구 Context(§6.4) · Record 삭제(§6.6). 회원 탈퇴(§6.9)만 남았는데, 현재 domain/member에 service·controller가 없어 붙일 자리가 없었습니다.

붙이는 방법

#80이 domain/ai/repository/AiDerivedDataRepository를 만들어 뒀습니다. 탈퇴 서비스에서 기존 삭제 트랜잭션 안에 호출만 하면 됩니다.

세 가지만 유의해 주세요.

• 별도 트랜잭션으로 분리하지 마세요. 06 §6.6이 근거로 든 것이 *"동일 인스턴스이므로 단일 트랜잭션으로 처리된다"*이고, 분리하면 부분 실패가 남습니다
• CANCELLED 전이에 조건을 걸지 마세요. COMPLETED·FAILED도 덮어야 합니다 — ai.context_keyword에는 is_deleted에 해당하는 컬럼이 없어 키워드 조회 제외를 keyword_status가 단독으로 담당합니다. COMPLETED를 남기면 탈퇴한 사용자의 키워드가 계속 노출됩니다
• is_deleted UPDATE의 영향 행이 0이어도 정상입니다 — Embedding 생성 전에 삭제된 경우입니다

배경과 트레이드오프는 #80의 BD-35에 있습니다. 구현하시다 애매한 지점이 있으면 알려 주시면 확인하겠습니다.

관련: Team-PinLog/back#61 · S15P11A705-124

[minyongP]

탈퇴 구현에 한 줄이 추가로 필요해졌습니다. #61에서 확정된 계약이 탈퇴 경로에도 걸립니다.

Context가 사라지는 네 지점 전부에서 ai 스키마의 파생 데이터를 무효화해야 합니다(06 §1.3 쓰기 매트릭스·§6.9, 계약 정본은 Team-PinLog/docs#14). #80이 그중 세 곳(Context 삭제·Context 수정의 구 Context·Record 삭제)에 적용했고, 회원 탈퇴는 백엔드에 경로 자체가 없어 제외했습니다.

#80이 머지되면 탈퇴 삭제 절차 끝에 이 한 줄을 붙이면 됩니다.

aiDerivedDataRepository.invalidate(contextIds);

AiDerivedDataRepository가 백엔드에서 ai 스키마에 쓰는 유일한 경로이고, ai.context_ai_state의 두 status를 CANCELLED로, ai.context_embedding.is_deleted를 true로 만듭니다. 영향 행이 0이어도 정상입니다(파생 데이터 생성 전에 삭제된 경우).

같은 삭제 트랜잭션 안에서 호출해야 합니다 — 원자성이 이 방식을 고른 이유입니다(BD-35).

#61은 쓰기 주체 확정이 목적이었고 그건 끝나서 닫았습니다. 이 항목만 여기로 옮깁니다.

[colosair]

참조 번호 정정 — BD-35 → BD-37

인계 내용은 정확합니다. 문서 번호 하나만 바로잡습니다.

윗 코멘트가 원자성 근거로 가리킨 BD-35는 재배정됐습니다. #80과 #81이 같은 번호를 파일명만 다르게 선점하고 있었고, 나중에 머지되는 쪽이 옮기는 규칙에 따라 #80이 옮겼습니다. #81이 먼저 머지돼 BD-35·BI-21은 이제 Refresh 재사용 관련 문서입니다.

찾으실 것	현재 번호
AI 파생 데이터 무효화를 삭제 트랜잭션 안에 두기로 한 결정	BD-37 (BD-37-ai-derived-invalidation-inside-deletion-transaction.md)
그 구현 기록	BI-23 (BI-23-2026-07-29-ai-derived-invalidation-on-delete.md)

BD-36·BI-22가 아니라 +2인 것은 그 둘을 #82가 선점 중이기 때문입니다.

붙이실 때 두 가지만

호출 위치 — 같은 삭제 트랜잭션 안이어야 한다는 지적 그대로입니다. 덧붙이면 Collection 잠금(findByIdForUpdate)보다 앞에 두시는 편이 낫습니다. #80의 cascadeDelete가 그 순서이고, 롤백 테스트(invalidationRollsBackWhenTheDeletionTransactionFails)가 그 위치를 전제로 짜여 있습니다. AI 워커는 ai 스키마만 만지므로 잠금 순환은 생기지 않습니다.

시그니처 — invalidate(List<Long> contextIds)입니다. 빈 목록이면 아무것도 하지 않고, 영향 행 0도 정상입니다(파생 데이터 생성 전 삭제).

AI 파트 확인 사항

ai 스키마에 쓰는 코드가 늘어나는 것이라 경계를 다시 적어 둡니다. 이 호출이 건드리는 것은 두 테이블의 두 종류 컬럼뿐입니다.

ai.context_ai_state      embedding_status · keyword_status → 'CANCELLED', updated_at
ai.context_embedding     is_deleted = true, updated_at

'CANCELLED' 어휘와 is_deleted의 의미는 AI 파트 소유입니다. AiDerivedDataRepository 밖에서 ai. 스키마에 직접 쓰지만 않으시면 경계 위반은 없습니다 — invalidate 호출 한 줄만 추가하시면 됩니다.

#80 머지 후에 착수해 주십시오. 현재 back#81 머지로 색인 충돌이 나서 해소 중입니다.

[colosair]

#80이 머지됐습니다 — db6bd81. AiDerivedDataRepository가 dev에 있으니 탈퇴 경로에 한 줄 붙이실 수 있습니다.

aiDerivedDataRepository.invalidate(contextIds);   // domain.record.repository

참조 문서는 위 코멘트에 적은 대로 **BD-37·BI-23**입니다(BD-35·BI-21은 Refresh 재사용 쪽입니다). 삭제 트랜잭션 안에서, Collection 잠금보다 앞에 두시면 됩니다.

막히는 지점이 있으면 알려 주십시오 — ai 스키마 쪽 계약은 AI 파트가 답하겠습니다.

[minyongP]

@cherry-go-round S15P11A705-147(#93, 머지 완료)에서 작성자 미탈퇴 판정을 MemberRepository.isActive 한 곳으로 모았습니다. 탈퇴 구현에 앞서 알아두면 좋을 세 가지가 있어 남깁니다.

1. 읽는 쪽은 이미 정리됐습니다. 탈퇴 시 member.deleted_at만 세팅되면 공개 조회 세 경로가 자동으로 숨깁니다.

• CollectionService.getDetailPublic — 404
• FollowService.follow — 404
• FollowService.listFollowedCollections — 빈 목록

세 경로 모두 Member의 @SQLRestriction("deleted_at IS NULL")에 기대고 있어서 새로 붙일 코드는 없습니다. 나중에 탈퇴 정책이 바뀌면(유예 기간, 마스킹 후 유지 등) 만질 자리는 MemberRepository.isActive 하나입니다. 그 세 경로는 PublicCollectionApiTests·FollowApiTests로 고정돼 있습니다.

2. 티켓 본문의 범위 전제가 낡았습니다. S15P11A705-65에 "Record·Context·Collection·CollectionRecord·Follow의 연쇄 소프트 삭제는 해당 도메인 테이블이 아직 없으므로 이번 범위에서 제외"라고 적혀 있는데, 그 테이블들은 S15P11A705-66~-71로 모두 들어왔습니다. 착수 전에 범위를 지금 기준으로 다시 보셔야 합니다.

3. AI 파생 데이터 무효화가 탈퇴 경로에만 비어 있습니다. AiDerivedDataRepository.invalidate가 붙은 곳은 셋입니다.

• RecordDeletionService.deleteContext (Context 삭제)
• RecordDeletionService.cascadeDelete (Record 삭제)
• RecordService.replaceContext (Context 교체 시 구 Context)

S15P11A705-124가 요구한 네 번째 지점인 회원 탈퇴는 경로 자체가 없어 미충족 상태입니다(DELETE /v1/me도, 탈퇴 서비스도 아직 없습니다). S15P11A705-77 항목 7(08 §3.6 탈퇴 처리 대상 표에 AI 파생 데이터 누락)도 같은 자리로 배정돼 있어, 문서와 구현을 함께 맞추시면 좋을 것 같습니다.

무효화는 물리 삭제가 아니라 ai.context_ai_state를 CANCELLED로, ai.context_embedding.is_deleted를 true로 두는 표시이고, 삭제 트랜잭션 안에서 수행하는 것이 BD-37로 정해져 있습니다.

필요하면 편하게 물어보세요.