[fix] 사진 해상도 무제한으로 인한 썸네일 생성 메모리 폭증 위험

[hamtorygoals]

📄 Description

이슈 #70(PHOTO-02/03 파일 수·용량 제한) 검증 과정에서 발견한 별도 문제입니다.

ThumbnailProcessingService.process()는 원본을 통째로 다운로드해 ThumbnailImageProcessor.createThumbnail()에서 ImageIO.read()로 완전히 압축 해제(디코딩)한 뒤 리사이즈·재인코딩합니다. 이 디코딩 단계의 메모리 비용은 압축 파일 크기가 아니라 해상도(픽셀 수)에 비례합니다.

그런데 PhotoUploadCompleteRequest.width/height는 클라이언트가 EXIF에서 추출해 보낸 값을 검증 없이 그대로 저장하는 메타데이터일 뿐이고, 실제 다운로드된 원본의 해상도 자체를 제한하는 로직은 시스템 어디에도 없습니다. PHOTO-02가 검증하는 건 sizeBytes(≤20MiB)와 contentType뿐입니다.

즉 압축률이 높은 포맷·설정을 쓰면 20MiB 이하이면서도 해상도가 매우 큰 이미지를 업로드할 수 있고, 이 경우 썸네일 생성 시 서버 메모리 사용량이 예상보다 훨씬 커질 수 있습니다.

실측 결과 (조사용 벤치마크, ThumbnailMemoryBenchmarkTest)

• 12MP(4032×3024) 이미지: 파일 크기를 0.3MiB12.4MiB로 40배 이상 바꿔도 디코딩+리사이즈+인코딩 피크 메모리 증가량은 7174MiB로 거의 고정
• 48.8MP(8064×6048) 이미지: 파일 크기가 **더 작음(0.76MiB < 1.34MiB)**에도 피크 메모리는 3.4배 더 큼(252MiB)
• thumbnailExecutor 최대 동시성(6개) 실행 시 12MP 기준 합산 피크 증가량 약 350~380MiB

결론적으로 파일 크기 상한(20MiB)은 이 위험을 전혀 통제하지 못하며, 배포 인스턴스가 6GB ARM 공유 인스턴스(prod·dev 컨테이너 동시 운영, cgroup 메모리 제한 없음)라는 점을 고려하면 실제 위험 요인입니다.

✅ Tasks

• 해상도 상한을 어떻게 통제할지 결정 — (a) PHOTO-02/03에서 width×height 상한 검증 추가, 또는 (b) ThumbnailImageProcessor가 원본을 풀 해상도로 디코딩하지 않도록 ImageReadParam 서브샘플링 등으로 다운샘플 디코딩 방식 변경
• 선택한 방식에 대해 다양한 해상도·파일 크기 조합으로 메모리 사용량 재측정
• 검증/변경 사항을 docs/apidoc/07-photo-management.md, 의사결정 로그에 반영

📎 ETC

• 관련 조사와 측정 방법: 이슈 [Feat] 사진 업로드 파일 수 및 용량 제한 조정 #70, src/test/java/org/zipzip/zipzipserver/domain/photo/service/ThumbnailMemoryBenchmarkTest.java(-PincludeBenchmark로 실행)
• 관련 이슈: [fix] 썸네일 큐 초과 시 성공한 업로드가 500으로 응답될 위험 #86 (썸네일 큐 초과 시 응답 실패 위험) — 이 이슈와 함께 썸네일 처리 경로 전반의 자원 안전성을 다룸