이미지 업로드 - presignedURL vs 서버로 이미지를 보내고 서버에서 S3로?

[hwhyeons]

.

[dlsnfl0615]

Presigned Url 사용

장점

1. 서버 부하 감소
2. access 키 노출 없이 s3로 업로드 가능
3. 만료시간 설정해서 통제 가능

단점

1. url 발급 이후 통제 못함
2. 업로드 완료 여부 서버가 바로 알 수 없음
3. 업로드 파일 내용 자체 검증 불가
4. S3 버킷에 클라이언트를 위한 CORS 설정 별도로 해줘야 함

업로드 됐는지 확인하기

키가 존재하는지 확인해보면 됨

public boolean isFileUploaded(String bucketName, String key) {
    try {
        HeadObjectRequest headRequest = HeadObjectRequest.builder()
                .bucket(bucketName)
                .key(key)
                .build();

        s3Client.headObject(headRequest); // 존재하면 정상 응답, 없으면 예외
        return true;

    } catch (NoSuchKeyException e) {
        return false; // 아직 업로드 안 됨
    }
}

서버에서 S3에 업로드 된 파일이 악성 파일인지 확인하기

1. Amazon GuardDuty Malware Protection for S3

// EventBridge 룰이 트리거하는 Lambda 예시
public void handleScanResult(GuardDutyEvent event) {
  String scanStatus = event.getMalwareScanStatus();
  String key = event.getObjectKey();

  if ("THREATS_FOUND".equals(scanStatus)) {
      s3Client.deleteObject(bucket, key); // 즉시 삭제
      fileMetaService.markAsRejected(key);
      notificationService.alertAdmin("악성 파일 탐지: " + key);
  } else {
      fileMetaService.markAsSafe(key);
  }
}

• 설정 방법
  • GuardDuty 콘솔 → Malware Protection for S3 활성화
  • 대상 버킷 지정
  • 업로드된 객체마다 자동으로 스캔 실행
  • 스캔 결과에 따라 태그 부여 (GuardDutyMalwareScanStatus: THREATS_FOUND 또는 NO_THREATS_FOUND)
  • 이 태그 변경을 EventBridge로 감지해서 후속 처리(격리, 알림, 삭제)

2. 파일 시그니처로 확인하기

public boolean isActuallyImage(byte[] fileBytes) {
    // PNG 시그니처: 89 50 4E 47
    // JPEG 시그니처: FF D8 FF
    if (fileBytes.length < 4) return false;

    byte[] header = Arrays.copyOfRange(fileBytes, 0, 4);
    return Arrays.equals(header, new byte[]{(byte)0x89, 0x50, 0x4E, 0x47}) // PNG
        || (header[0] == (byte)0xFF && header[1] == (byte)0xD8);           // JPEG
}

서버 경유해서 업로드

장점

1. 업로드 파일에 대한 사전 검증 가능

• 바이러스/악성코드 스캔
• 이미지 리사이징, 썸네일 생성, 워터마킹
• 파일 확장자/MIME 타입 검증 (실제 바이너리 시그니처 확인 등, 더 엄격한 검증 가능)
• 파일 크기 제한을 서버 로직으로 유연하게 제어

4. 업로드 성공/실패를 서버가 즉시 확실하게 알 수 있음

단점

1. 서버 부하, 업로드 속도 느려짐 등등..

[seoki180]

성능/서버 자원 관점 정리 (presigned vs 서버 경유)

위에서 장단점·검증은 잘 정리돼서, 저는 "실제로 톰캣 자원을 얼마나 먹는지" 수치 관점으로 보탤게요. (Spring Boot + 내장 Tomcat 기준, 값은 기본 설정 + 모델 계산이라 회선 속도에 따라 달라짐)

Spring 기본값부터 (큰 파일 받으려면 먼저 손봐야 함)

설정	기본값
spring.servlet.multipart.max-file-size	1MB
spring.servlet.multipart.max-request-size	10MB
spring.servlet.multipart.file-size-threshold	0B (→ 파일을 디스크 temp로 스풀)
server.tomcat.threads.max	200 (동시 처리 상한)

서버 경유가 먹는 자원

• 메모리(힙): getInputStream() 스트리밍이면 수십 KB로 적음. 하지만 getBytes()나 threshold를 크게 잡으면 파일크기 × 동시요청수가 그대로 힙에 → OOM 1순위 사고
• 디스크 temp: 기본 설정에선 파일크기 × 동시업로드 수. 예) 100MB × 동시 100건 = temp 10GB
• 스레드 점유: 업로드 끝날 때까지 워커 스레드 1개를 물고 있음

스레드 점유 시간 계산 (100MB, 클라 10MB/s 가정)

클라→서버 : 100MB ÷ 10MB/s = 10초
서버→S3   : 100MB ÷ 100MB/s = 1초
합계 ≈ 11초 동안 워커 스레드 1개 점유

→ 스레드 200개 기준 동시성 천장 ≈ 200 ÷ 11 ≈ 18 uploads/s, 그리고 이 사이 일반 API 요청까지 스레드가 굶음

Presigned는 발급이 CPU 25ms라 스레드를 ~5ms만 점유 → 파일 전송은 서버를 아예 안 거침(부하 ≈ 0)

네트워크(비용/한계 직결)

• 서버 경유: 바이트가 서버를 2번 통과 (in 100MB + out 100MB = 파일당 200MB 트래픽)
• Presigned: 서버 트래픽 ≈ 0 (클라 ↔ S3 직접)

요약 (100MB, 동시 100건)

지표	서버 경유	Presigned
워커 스레드	100개 × ~11초 점유	~5ms
힙(스트리밍)	수십 MB	~0
힙(getBytes)	10GB → OOM	~0
temp 디스크	10GB	0
서버 네트워크	20GB in+out	~수 MB
동시성 천장	~18/s	~수만/s

결론 제안 (하이브리드)

• 작은 파일(≤5MB, 스트리밍 구현): 서버 경유도 동시 수백 건까진 무난. 검증/리사이즈 붙이기 쉬우니 이쪽이 단순함으로 이김
• 큰 파일(수십MB+)·동시 업로드 많음: presigned. 스레드×시간·temp 디스크가 선형으로 터지는 걸 근본 회피
• 정석은 섞기: 썸네일/아바타 등 작은 건 서버 경유, 큰 첨부는 presigned + (업로드 후) S3 이벤트로 검증/스캔 — 위 댓글의 GuardDuty/시그니처 검증이 여기에 자연스럽게 붙음

위 GB·초 수치는 "10MB/s 업로드, 200스레드, 비오버랩" 가정의 모델 계산입니다. 느린 모바일 회선이면 스레드 점유가 수십 초로 늘어 서버 경유가 훨씬 불리해집니다.

[seoki180]

스프링 구현 관점 보충 (빈 등록 · 코드 스켈레톤 · presigned 보안)

성능 얘기에 이어, 실제 Spring Boot에서 어떻게 짜는지와 놓치기 쉬운 포인트를 정리합니다. (AWS Java SDK v2 기준)

빈 등록 — 두 방식은 서로 다른 클라이언트가 필요

@Bean
S3Client s3Client() { return S3Client.builder().region(REGION).build(); }        // 서버 경유(PutObject)용

@Bean
S3Presigner s3Presigner() { return S3Presigner.builder().region(REGION).build(); } // presigned 발급용 (별도 빈!)

S3Presigner를 안 만들고 S3Client로 presign 하려다 막히는 경우가 많음. 둘은 별개 빈.

1) 서버 경유 — 구현 + multipart 튜닝

@PostMapping(value="/upload", consumes=MULTIPART_FORM_DATA_VALUE)
public UploadResponse upload(@RequestParam("file") MultipartFile file) throws IOException {
    String key = "uploads/" + UUID.randomUUID() + ext(file);
    s3Client.putObject(
        PutObjectRequest.builder().bucket(bucket).key(key)
            .contentType(file.getContentType()).build(),
        RequestBody.fromInputStream(file.getInputStream(), file.getSize())); // getBytes() 금지 → OOM
    return new UploadResponse(key, publicUrl(key));
}

# 큰 파일 받으려면 기본값(1MB/10MB) 반드시 상향
spring.servlet.multipart.max-file-size: 50MB
spring.servlet.multipart.max-request-size: 50MB

• 핵심: getInputStream() 스트리밍으로 받기(getBytes()는 힙에 통째 → OOM)

2) Presigned — 2단계 + 완료 콜백

// (1) 발급
@PostMapping("/upload/presign")
public PresignResponse presign(@RequestBody PresignRequest req) {
    String key = "uploads/" + UUID.randomUUID() + "-" + req.filename(); // key는 서버가 생성
    PutObjectRequest obj = PutObjectRequest.builder()
        .bucket(bucket).key(key).contentType(req.contentType()).build();  // contentType 서명에 포함
    PresignedPutObjectRequest p = s3Presigner.presignPutObject(
        PutObjectPresignRequest.builder()
            .signatureDuration(Duration.ofMinutes(5))                      // 짧은 만료
            .putObjectRequest(obj).build());
    return new PresignResponse(key, p.url().toString());
}

프론트: PUT presignedUrl (헤더 Content-Type 일치 필수) → S3 직접
그다음: POST /upload/complete { key } → 서버가 HeadObject로 존재 확인 후 DB 확정

• 위 댓글의 HeadObject 존재 확인이 바로 이 complete 단계에 들어감

presigned 보안 체크리스트

• key는 서버가 생성 — 클라가 보낸 경로 그대로 쓰면 path traversal / 남의 파일 덮어쓰기 위험
• 만료 짧게(1~5분), contentType(가능하면 contentLength 범위)까지 서명에 포함
• 발급 엔드포인트에 인증·권한·rate limit (URL 찍어내는 입구라 방치하면 무한 발급)
• 버킷 Block Public Access ON + 다운로드는 presigned GET 또는 CloudFront OAC
• S3 CORS 설정 (위 댓글에서 언급된 그거 — PUT, 프론트 Origin, Content-Type 헤더 허용)

한 줄 결론

빈 2개 등록해두고 작은 파일은 (1) 서버 경유 / 큰 파일은 (2) presigned 로 라우팅하는 하이브리드가 구현 난이도 대비 가장 무난합니다.

[seoki180]

서버 경유 심화: MVC(블로킹) vs WebFlux(비동기) 다이렉트 업로드

같은 "서버 경유"라도 MVC 블로킹이냐 WebFlux 비동기냐에 따라 스레드 거동이 완전히 다릅니다. 차이는 딱 하나 — 업로드가 진행되는 동안 스레드가 묶여 있느냐, 풀려 있느냐.

방식 A — MVC(서블릿) 블로킹

[클라이언트] ──파일 스트림──> [Tomcat Worker Thread #1] ──putObject──> [S3]
                              └── 업로드 시작~끝까지 이 스레드가 계속 점유 ──┘

Worker Thread #1 타임라인:
0s   요청 수신, 스레드 #1 할당
     ▓▓▓▓▓▓▓▓▓▓ 클라→서버 수신 (10초, 블로킹 대기)
10s  ▓▓ 서버→S3 전송 (1초, 블로킹 대기)
11s  응답 반환, 스레드 #1 해제
→ 11초 내내 스레드가 '네트워크 대기'로 점유됨 (놀면서 붙잡음)
→ 스레드 200개 = 동시 200업로드가 물리적 상한

방식 B — WebFlux(Netty) 비동기

[클라이언트] ══파일 조각들(DataBuffer)══> [Netty Event Loop] ══S3AsyncClient══> [S3]
              조각 올 때만 잠깐 처리 후 스레드 즉시 반납

Event Loop 타임라인 (▓=작업, ░=다른 요청 처리):
0s   조각1 ▓ ░░░░ 조각2 ▓ ░░░░ 조각3 ▓ ░░░░ ...
     (같은 스레드가 그 사이 다른 업로드/API도 처리)
11s  마지막 조각 + S3 완료 콜백 ▓ → 응답
→ 업로드는 여전히 11초지만, 스레드는 그 11초를 '점유'하지 않음
→ 이벤트 루프 4개(코어수)로 수천 동시 업로드 처리 가능

동시 업로드 3개일 때 비교

── MVC (스레드 : 업로드 = 1 : 1) ──
Thread#1: [====== 업로드A 11초 점유 ======]
Thread#2: [====== 업로드B 11초 점유 ======]
Thread#3: [====== 업로드C 11초 점유 ======]
Thread#4~200: 남은 요청 대기... 업로드 많으면 고갈

── WebFlux (스레드 : 업로드 = N : 1) ──
EventLoop#1: [A조각][B조각][C조각][A조각][다른API][B조각]...
             스레드 하나가 A·B·C + 일반요청을 잘게 번갈아 처리

정리표

항목	MVC(블로킹)	WebFlux(비동기)
I/O 대기 중 스레드	점유(놀면서 붙잡음)	반납(다른 일 함)
업로드 : 스레드	1 : 1	N : 1
업로드 소요시간	11초	11초 (동일)
동시 업로드 상한	~스레드풀(200)	~커넥션(수천)
느린 업로더 100명	스레드 100개 묶임 → 고갈	이벤트 루프 안 막힘
치명적 실수	거의 없음(단순)	체인에 블로킹 1개 → 전체 마비
코드 난이도	쉬움	어려움(Mono/Flux/버퍼 반납)

오해 방지 2가지

1. 개별 업로드가 빨라지는 게 아님. 11초짜리는 둘 다 11초. WebFlux가 개선하는 건 속도가 아니라 같은 스레드로 몇 개를 동시에 감당하냐(처리량).
2. WebFlux는 공짜가 아님. 이득은 "스레드가 I/O 대기에 안 묶인다" 뿐. 체인에 블로킹(JDBC, 블로킹 S3Client, 무거운 CPU)이 하나라도 있으면 이벤트 루프가 막혀 MVC보다 더 심하게 죽음 → "전 구간 논블로킹"이 전제.

⚠️ WebFlux 다이렉트 구현 시 반드시 블로킹 S3Client가 아니라 S3AsyncClient를 쓸 것. WebFlux 컨트롤러에서 블로킹 클라이언트를 부르면 이벤트 루프(코어 수개)가 막혀 서버 전체가 멈춤.

결론: WebFlux는 스레드 고갈을 기술로 푸는 것, presigned는 파일 바이트를 서버에서 치워서 문제 자체를 없애는 것. 큰 파일·고동시성이면 presigned 우선, 그게 불가능할 때 WebFlux를 고려.

[hwhyeons]

1. 프론트 → 백엔드
   업로드 세션 생성 요청
2. 백엔드
   DB에 WAITING_UPLOAD 저장
   staging 객체 키 생성 (백엔드가 identity-verification/staging/23/8f14e45f.jpg 와 같은 이름만듦)
   Presigned POST 또는 PUT 반환
3. 프론트 → S3
   이미지 직접 업로드
4. 프론트 → 백엔드
   업로드 완료 요청
5. 백엔드 → S3
   HeadObject로 실제 파일 검증
   DB 상태를 UPLOADED로 변경
6. 사용자
   제출 버튼 클릭
7. 백엔드
   staging 파일을 final 경로로 조건부 복사
   DB에 final 객체 키 저장
   상태를 SUBMITTED로 변경
8. 관리자
   짧은 GET Presigned URL로 파일 조회
   APPROVED 또는 REJECTED 처리

[seoki180]

결론

upload 로직 자체는 presignedURL로 구현

단 클라이언트에서 호출할떄 upload , 실제 api 를 두개로 나눠서 보내도록 구현