[RosieOh]

Refs #49 · A + B 둘 다

먼저 재봤습니다

MinIO 를 띄워 5MB × 20개(100MB)를 올리고 측정했습니다.

상태	메모리
유휴	54MB
100MB 업로드 후	66MB

실측 배분이 약 800MB / 1GB(여유 200MB) 이므로 1GB 인스턴스에도 들어갑니다.

구현은 하나입니다

엔드포인트와 path-style 을 설정으로 받으므로 AWS S3·MinIO·R2 에 같은 코드가 붙습니다. 어디에 저장하는지는 배포 환경이 정합니다.

STORAGE_TYPE=local   디스크 (기본). 단일 인스턴스 전제
STORAGE_TYPE=s3      S3 호환. 엔드포인트를 주면 MinIO 로 간다

• 로컬·CI: STORAGE_TYPE=s3 docker compose --profile s3 up → MinIO + 버킷 생성까지 한 번에
• 운영: 서버 .env 에 STORAGE_TYPE=s3 를 두면 배포가 carecode-minio 를 띄우고, 이후 배포는 앱만 교체합니다 — 데이터가 그 컨테이너 안에 있습니다. 127.0.0.1 에만 바인딩합니다. 외부 S3·원격 MinIO 를 쓰면 띄우지 않습니다

검증을 먼저 빼냈습니다

크기·확장자·Content-Type·시그니처·악성코드 검사가 LocalFileStorageService 안에 있었습니다. S3 구현을 그냥 더하면 그 검사를 건너뜁니다. "어디에 저장하는가" 와 무관한 규칙이므로 UploadPolicy 로 모았고, 구현체는 검사를 통과한 바이트만 저장합니다.

"확장자와 내용이 다른 파일은 S3 경로에서도 거부한다" 를 테스트로 고정했습니다.

S3 구현이 공개 URL 을 돌려주지 않는 이유

건강기록 첨부는 민감정보라 주소만 알면 열리는 상태로 둘 수 없습니다(#152 에서 정적 서빙을 프로필 이미지로 좁힌 것과 같은 경계). 다운로드는 소유권을 확인하는 애플리케이션 경로를 거칩니다.

로컬에서 S3 로 바꾸면 예전 행은 /files/... 를 들고 있습니다. toKey 가 그 접두사도 떼어 줍니다 — 안 하면 이전 첨부를 영영 읽지 못합니다.

테스트는 MinIO 에 실제로 붙습니다

목으로는 "SDK 를 올바르게 불렀는가" 만 보게 됩니다. path-style 접근, 없는 키의 예외 종류 처럼 실제로 틀리는 것은 서버가 있어야 드러납니다. 9개 통과 확인했습니다.

이미지를 받을 수 없는 환경에서는 스위트를 깨뜨리지 않고 건너뜁니다(-PminioImage=... 로 대체 이미지 지정 가능). CI 는 공식 이미지를 받으므로 거기서 실제 검증됩니다.

곁에서 찾은 것 — 첫 배포가 DB 연결로 멈출 상태였습니다

앱 컨테이너는 브리지 모드인데 문서는 "앱은 같은 호스트의 127.0.0.1 로 붙는다" 고 적고 있었습니다. 컨테이너 안의 127.0.0.1 은 그 컨테이너 자신이라 호스트의 DB·Redis 에 닿지 않습니다.

운영 배포가 한 번도 성공하지 못해(#94) 드러나지 않은 항목입니다. 배포에 --add-host=host.docker.internal:host-gateway 를 붙이고, .env 의 접속 주소를 host.docker.internal 로 적도록 문서에 명시했습니다.

서버 .env 를 확인해 주세요. 127.0.0.1 로 적혀 있으면 시크릿을 넣은 첫 배포가 기동 단계에서 멈춥니다.

숫자

• 전체 테스트 675개, 실패 0 (MinIO 9개는 이미지 미수신 환경에서 skip)