fix: 공유앨범 목록 썸네일 fallback 처리

[jaehunshin-git]

📌 Summary

• 공유앨범 목록 썸네일 후보를 READY 상태이며 비어 있지 않은 썸네일 오브젝트 키가 있는 활성 사진으로 제한했습니다.
• 앞선 PENDING·FAILED·사용 불가·soft-delete 사진을 건너뛰고 뒤의 준비된 사진으로 최대 3장을 채우도록 수정했습니다.
• API 명세와 iOS 연동 가이드의 fallback 동작 설명을 구현과 일치시켰습니다.
• close [Fix] 공유앨범 목록 썸네일 fallback 처리 #101

✅ Tasks

• repository 조회 단계에 썸네일 상태·오브젝트 키·soft-delete 조건 적용
• null 또는 공백 썸네일 오브젝트 키 방어
• 앨범 사진 추가 시각 오름차순 및 최대 3장 제한 유지
• 앞선 사용 불가 사진 뒤의 READY 사진 fallback 통합 테스트 추가
• 후보 0장 및 준비된 사진 3장 미만 edge-case 통합 테스트 추가
• 서비스 단위 테스트와 API 문서 갱신

🔥 Troubleshooting

• 기존에는 사진 3개를 먼저 제한한 뒤 서비스에서 READY 여부를 필터링해, 뒤의 준비된 사진이 후보에 들어오지 못했습니다.
• 필터 조건을 repository 쿼리로 이동해 PageRequest(3) 적용 전에 사용할 수 없는 썸네일을 제외했습니다.
• 상태가 READY여도 키가 null 또는 공백이면 presigned URL 발급 대상으로 사용하지 않도록 방어했습니다.

📸 API Test Results

검증 항목	결과
JDK 21 ./gradlew spotlessCheck	✅ 통과
PostgreSQL Testcontainers fallback·edge-case API 통합 테스트	✅ 통과
JDK 21 ./gradlew test 전체 테스트	✅ 통과

검증한 경계 조건: 최대 3장 제한, 앨범 추가 순서, 앞 3장 사용 불가 시 fallback, 후보 0장, 후보 1~2장, PENDING, FAILED, soft-delete, null·공백 키.

🔍 To Reviewer

• 썸네일 상태와 오브젝트 키 조건을 조회 쿼리에서 적용하는 방식이 적절한지 확인 부탁드립니다.
• 앨범 사진 추가 시각(SharedAlbumPhoto.createdAt, 동점 시 ID) 기준 정렬은 기존 계약대로 유지했습니다.

[hamtorygoals]

이 PR이 바꾸는 동작을 다시 정리하면: 앨범에 가장 먼저 추가된 사진 13번의 썸네일이 아직 PENDING/FAILED면 건너뛰고, 뒤에 있는 이미 READY인 사진으로 그 자리를 채우는 방식이에요. 그리고 원래 13번 사진의 썸네일이 나중에 READY가 되면, 정렬 기준(sap.createdAt asc)이 그대로라 다음 조회부터는 그 사진이 원래 자리를 되찾고 임시로 채워졌던 사진은 밀려나게 됩니다.

이 부분이 #99(PR #100)에서 의도적으로 정한 정책과 반대 방향이라 공유해요. 그때 정한 건 "썸네일이 아직 준비 안 된 사진은 건너뛰고, 다른 사진으로 채우지 않는다"였는데(06-shared-album.md, 의사결정 로그 API-15 참고), 이유는 이 thumbnails가 단순 콘텐츠 미리보기가 아니라 앨범 목록에서 그 앨범 자체를 시각적으로 식별하는 용도이기 때문이었어요.

구글 포토/애플 사진 공유 앨범 같은 경우도 커버·썸네일이 처리 중이면 다른 사진으로 대체하지 않고 플레이스홀더(로딩/블러 상태)를 보여주다가 준비되면 그 자리에 실제 이미지로 바꾸는 쪽이 일반적입니다. 반대로 지금 이 PR처럼 준비된 것부터 채워 넣는 fallback 방식은, 사용자가 "이 앨범 = 이 사진 조합"으로 기억하고 있는 도중에 새로고침할 때마다 표지가 바뀌어 보일 수 있어서, 앨범 식별용 썸네일보다는 순수 콘텐츠 미리보기 그리드에 더 어울리는 패턴이라고 생각해요.

그래서 이건 버그 수정이라기보다는 UX 정책 선택의 문제로 보여, 기획 쪽에도 의도를 여쭤봤습니다. 답변은 "사용자가 아무 조작도 안 했는데 표지가 임의로 바뀌는 것보다는, 썸네일이 아직 준비되지 않았더라도 다른 사진으로 채우지 않고 기다리는 편이 낫다"였어요. 이 기준에 따라 이번 PR의 fallback 방향은 승인되지 않는 것이 좋을 것 같습니다.