RESTful 웹 서비스 구축 - # Project 04

Spring Boot (+ RESTful)

RESTful 웹 서비스 구축 - # Project 04 - 이미지 업로드 (5)

wy-family 2025. 1. 7. 23:58

질문 8. 개발한 프로그램에서 파일 이미지 업로드 REST API 가 @PostMapping("/{book_id}/{type}/upload") 이런식으로 했었어. 그렇다보니, 이미지 파일을 업로드할 때, book_id 가 만약에 1, 2, 3, 4 이렇게 여러 가지의 이미지를 대량으로 업로드하는 건 불가능해. 그냥 book_id 가 1에 해당하는 이미지들만 업로드가 가능하지. 그리고 거기서 여러가지의 이미지를 업로드할 수는 있긴 하지만, type 이 동일해야 해. type 을 입력해야 하다보니, type 은 1, 2, 3 밖에 없지만 1, 2, 3 을 동시에 업로드할 수가 없는거야. 당장 어떤 코드를 알고 싶다는건 아니지만, 내가 궁금한 건, type 이 1, 2, 3 이든 상관없고 book_id 도 1, 2, 3, 4, 뭐든 상관없이 다 뒤죽박죽 다 섞여있는 상태로 한꺼번에 대용량으로 업로드를 할 수가 있을까? 그리고나서 각각의 이미지들에 type 정보와 연결된 book_id 정보를 입력하면 딱! 딱! 알아서 척척 진행될 수 있도록 코드를 짤 수는 없는걸까? 아니면 애초에 이미지를 업로드할 때, 각각의 이미지들의 type 정보와 book_id 정보를 받아서 할 수도 있을것이고.

내가 또 궁금한 건, 보통 실제로는 어떤 방식으로 구현을 하게 되는걸까? 나는 공부 중이고 학습 중이라 그렇지만 현실, 현업에서는 어떤 식으로 구현을 하게 되는걸까? 뭘 고려하게 되는걸까?

좋은 질문이에요! 이미지 업로드 API에서 유연성과 대량 업로드 처리는 현실에서 자주 직면하는 문제입니다. 이를 해결할 수 있는 방법과, 현실에서 실제로 어떤 식으로 구현되고 고려되는지 상세히 설명해드릴게요.

1. 현재 문제점 요약

현재 API의 구조:

@PostMapping("/{book_id}/{type}/upload")

문제 1: book_id와 type이 고정.
- 한 번에 하나의 book_id에만 이미지를 업로드 가능.
- type도 고정되어, 여러 type의 이미지를 동시에 업로드할 수 없음.
문제 2: 유연하지 않음.
- 여러 책(book_id)과 여러 type의 이미지를 동시에 업로드하려면, API 호출을 반복적으로 수행해야 함.

2. 어떻게 해결할 수 있을까?

(1) 이미지별로 book_id와 type 정보를 포함

업로드하는 각 이미지에 book_id와 type 정보를 포함하면 해결 가능합니다.
업로드할 데이터를 JSON으로 전달하여, 이미지와 메타데이터(book_id, type)를 함께 처리하는 방식입니다.

데이터 구조 예시 (JSON)

[
    {
        "book_id": 1,
        "type": 1,
        "file": "image1.png"
    },
    {
        "book_id": 2,
        "type": 2,
        "file": "image2.png"
    },
    {
        "book_id": 3,
        "type": 3,
        "file": "image3.png"
    }
]

(2) 서버에서 처리하는 방식

서버는 JSON 데이터를 받아 각 이미지를 분리하고, 각각의 book_id와 type에 따라 처리.
처리 과정:
1. JSON 데이터를 파싱하여 이미지 파일과 메타데이터(book_id, type)를 매핑.
2. 각 이미지를 book_id와 연결된 디렉토리에 저장.
3. 메타데이터(type, book_id, 파일 이름)를 데이터베이스에 저장.

(3) 장점

유연성: book_id와 type이 다양한 이미지들을 한 번에 처리 가능.
대량 업로드 지원: 여러 개의 이미지를 하나의 요청으로 처리.
확장성: 메타데이터 구조를 확장하면 더 많은 정보를 추가할 수 있음(예: 이미지 제목, 태그 등).

3. 현실에서 어떻게 구현할까?

현업에서는 요구사항과 시스템 제약 조건에 따라 다양한 방식으로 구현됩니다. 주요 고려사항은 다음과 같습니다.

(1) REST API 설계

단일 요청으로 여러 파일과 메타데이터를 처리할 수 있도록 API 설계.
예: @PostMapping("/upload-images").

API 구조

@PostMapping(value = "/upload-images", consumes = "multipart/form-data")
public ResponseEntity<?> uploadImages(@RequestPart("files") MultipartFile[] files,
                                      @RequestPart("metadata") String metadataJson) {
    // metadataJson을 파싱하여 각 파일의 book_id와 type 매핑
    // 파일 저장 및 데이터베이스 업데이트 처리
}

(2) 클라이언트 요청 방식

클라이언트는 이미지와 함께 메타데이터를 포함하여 요청.
메타데이터에는 book_id, type 정보가 포함.

요청 예시 (HTTP)

요청 헤더:

Content-Type: multipart/form-data

요청 바디:

files[]: 업로드할 이미지 파일들.
metadata: JSON 형식으로 각 파일의 메타데이터 포함.

(3) 고려해야 할 사항

1) 대용량 파일 처리

파일 크기와 요청의 크기를 제한해야 서버가 과부하되지 않음.
Spring Boot에서 파일 크기 제한:

spring:
  servlet:
    multipart:
      max-file-size: 50MB
      max-request-size: 500MB

2) 데이터 무결성

book_id와 type이 데이터베이스에 유효한 값인지 검증.
업로드 실패 시 적절한 에러 응답 반환.

3) 성능 최적화

대량 업로드의 경우, 파일 저장과 데이터베이스 업데이트를 병렬 처리하거나 비동기 처리로 구현.
예: 파일 저장 작업은 별도 쓰레드에서 실행.

4) 보안

업로드 파일의 타입과 확장자 확인:

String contentType = file.getContentType();
if (!Arrays.asList("image/png", "image/jpeg").contains(contentType)) {
    throw new InvalidFileException("Invalid file type");
}

5) 클라우드 스토리지

대용량 파일 업로드는 로컬 서버가 아닌 클라우드 스토리지(AWS S3, Google Cloud Storage 등)를 사용하는 것이 일반적.
클라우드에 직접 업로드한 후 URL만 저장.

4. 실제 업로드 시의 흐름

클라이언트에서 여러 이미지를 JSON과 함께 업로드 요청.
서버에서 JSON 데이터를 파싱하여 파일과 메타데이터를 매핑.
각 이미지를 저장하고 데이터베이스에 메타데이터 삽입.
처리 결과를 클라이언트에 반환.

5. 결론

해결 방법

각 이미지에 book_id와 type 정보를 포함하여 업로드.
서버에서 JSON 데이터를 처리하고, 각 파일을 적절히 저장.

현업에서의 구현

단일 API로 여러 파일과 메타데이터를 처리할 수 있도록 설계.
클라우드 스토리지와 연계하여 대용량 파일도 문제없이 처리.
데이터 무결성 검증과 보안을 강화.

질문 9. @PostMapping("/{book_id}/{type}/upload", consumes = {"multipart/form-data"}) 라고 했어. book_id 와 type 은 @PathVariable 로 받으면서, 왜 MultipartFile[] files 는 @RequestPart 로 받는거야? 둘의 차이가 뭐길래?

좋은 질문이에요! @PathVariable과 @RequestPart를 사용하는 이유와 차이점을 상세히 설명해 드릴게요.

1. @PathVariable과 @RequestPart의 역할

(1) @PathVariable

@PathVariable은 URL 경로에 포함된 값을 추출하는 데 사용됩니다.

특징

경로 변수(Path Variable): URL의 특정 부분에서 값을 가져옵니다.
RESTful API 설계에서 리소스를 식별하는 데 사용됩니다.

예시

@PostMapping("/{book_id}/{type}/upload")
public ResponseEntity<?> uploadFiles(
    @PathVariable Long book_id, 
    @PathVariable int type) {
    // book_id와 type 값을 URL에서 추출
}

요청 URL: POST /1/2/upload

book_id: 1로 매핑.
type: 2로 매핑.

사용 목적

URL 경로에 포함된 값을 가져오는 데만 사용됩니다.
보통 리소스를 식별하거나 동작의 맥락(Context)을 설정하는 데 사용됩니다.

(2) @RequestPart

@RequestPart는 HTTP 요청의 multipart/form-data 형식에서 특정 데이터를 추출하는 데 사용됩니다.

특징

**폼 데이터(Form Data)**의 특정 부분(Part)을 처리합니다.
파일, JSON 데이터, 텍스트 등 다양한 데이터를 처리할 수 있습니다.

예시

@PostMapping("/{book_id}/{type}/upload")
public ResponseEntity<?> uploadFiles(
    @PathVariable Long book_id, 
    @PathVariable int type,
    @RequestPart MultipartFile[] files) {
    // 파일 데이터를 MultipartFile[]로 추출
}

요청 바디:

Content-Type: multipart/form-data
files: [file1.png, file2.png, file3.png]

files 부분이 MultipartFile[] files로 매핑.

사용 목적

요청 본문(Request Body)에서 특정 데이터를 추출.
보통 파일 업로드, JSON 데이터 전송 등에서 사용됩니다.

2. 둘의 차이점

구분	@PathVariable	@RequestPart
역할	URL 경로에서 값 추출	요청 본문에서 특정 데이터를 추출
적용 대상	경로 변수 (URL의 일부분)	multipart/form-data 요청의 특정 파트
데이터 위치	URL (예: /1/2/upload)	요청 바디 (예: 파일, JSON 등)
사용 시점	리소스 식별 (book_id, type)	파일이나 JSON 데이터를 처리할 때

3. 왜 @PathVariable과 @RequestPart를 따로 사용하는가?

(1) 서로 역할이 다름

book_id와 type은 리소스의 식별자로, API 설계에서 URL 경로에 포함되는 것이 일반적입니다.
파일 데이터(MultipartFile[])는 **요청 본문(Request Body)**에 포함되어야 하므로, 이를 처리하려면 @RequestPart를 사용해야 합니다.

(2) HTTP 프로토콜의 구조

HTTP 요청은 크게 3가지로 나뉩니다:

URL (Path): 리소스 식별.
헤더 (Headers): 메타데이터.
본문 (Body): 요청 데이터.

@PathVariable: URL에서 데이터를 가져옴.
@RequestPart: 요청 본문에서 데이터를 가져옴.

4. 왜 파일은 @PathVariable로 받을 수 없는가?

파일은 보통 URL에 포함되지 않고, **요청 본문(Request Body)**에 바이너리 데이터로 포함됩니다. 이는 HTTP 요청 규격에 따른 것입니다:

URL에는 텍스트 기반 데이터만 포함 가능.
파일 업로드는 바이너리 데이터를 포함하는 multipart/form-data 형식으로 전송.

5. 실무에서의 활용

(1) RESTful API 설계

리소스 식별: @PathVariable로 처리.
파일 업로드: @RequestPart로 처리.

(2) 여러 데이터 타입 처리

파일 업로드와 함께 JSON 메타데이터를 전송하는 경우:

@PostMapping("/upload")
public ResponseEntity<?> uploadWithMetadata(
    @RequestPart("files") MultipartFile[] files,
    @RequestPart("metadata") String metadataJson) {
    // 파일과 JSON 메타데이터 처리
}

6. 요약

@PathVariable:
- URL 경로에서 데이터를 추출.
- 보통 리소스 식별자(예: book_id, type)에 사용.
@RequestPart:
- multipart/form-data 요청 본문에서 데이터를 추출.
- 보통 파일이나 JSON 데이터에 사용.
둘의 차이:
- @PathVariable: URL의 일부.
- @RequestPart: 요청 본문의 일부.
실무에서의 역할 분담:
- 리소스와 동작의 컨텍스트는 @PathVariable로 처리.
- 파일, 메타데이터 등은 @RequestPart로 처리.

URL (Path) 에 대해서는 @PathVariable,
본문 (Body) 에 대해서는 @RequestPart 라면,
헤더 (Headers)는 메타데이터라는데
일단 헤더 부분은 무엇이며
메타데이터가 뭘 의미하는 것인지,
그리고 그건 어떻게 받아내는지 알려줄래?

좋은 질문이에요! **HTTP 헤더(Headers)**와 메타데이터가 무엇인지, 그리고 Spring에서 이를 어떻게 처리하고 받아내는지 하나씩 설명드릴게요.

1. HTTP 헤더(Headers)란?

(1) 헤더의 역할

HTTP 헤더는 요청(Request) 또는 응답(Response)과 함께 전송되는 **추가 정보(메타데이터)**를 담고 있습니다.

요청에 대한 부가 정보를 서버에 전달하거나, 응답에 대한 정보를 클라이언트에 전달하는 데 사용됩니다.
메타데이터는 요청 본문(Body)와는 독립적으로, 요청 자체를 설명하는 데 사용됩니다.

(2) HTTP 요청의 구조

HTTP 요청은 보통 다음과 같이 구성됩니다:

POST /api/upload HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer token123
User-Agent: PostmanRuntime/7.29.0

{
  "file": "image.png"
}

구성 요소:

URL (Path): /api/upload (리소스 식별).
Headers:
- Content-Type: 요청 본문의 데이터 형식(예: application/json).
- Authorization: 인증 토큰.
- User-Agent: 클라이언트 정보.
Body:
- 요청 데이터(예: 파일, JSON).

(3) 헤더에서 메타데이터란?

메타데이터는 요청 또는 응답에 대한 추가 정보입니다.
예를 들어:

요청 데이터를 설명:
- Content-Type: 본문의 데이터 형식.
- Content-Length: 본문의 크기.
클라이언트 정보를 설명:
- User-Agent: 클라이언트의 소프트웨어 정보.
인증 및 권한:
- Authorization: 사용자 인증 정보.

2. Spring에서 HTTP 헤더 처리

(1) 헤더 값을 받아내기

Spring에서는 요청 헤더를 처리하기 위해 @RequestHeader 어노테이션을 사용합니다.

예: 특정 헤더 값 추출

@PostMapping("/upload")
public ResponseEntity<?> uploadFile(
    @RequestHeader("Authorization") String authHeader) {
    System.out.println("Authorization Header: " + authHeader);
    return ResponseEntity.ok("Header processed");
}

요청:

POST /upload HTTP/1.1
Authorization: Bearer token123

출력:

Authorization Header: Bearer token123

(2) 헤더 전체를 가져오기

모든 헤더를 가져오려면 HttpHeaders 객체를 사용합니다.

예: 모든 헤더 출력

@PostMapping("/upload")
public ResponseEntity<?> uploadFile(@RequestHeader HttpHeaders headers) {
    headers.forEach((key, value) -> {
        System.out.println(key + ": " + value);
    });
    return ResponseEntity.ok("Headers processed");
}

(3) 헤더의 기본값 설정

헤더가 없을 경우 기본값을 설정할 수 있습니다:

@PostMapping("/upload")
public ResponseEntity<?> uploadFile(
    @RequestHeader(value = "Custom-Header", defaultValue = "Default-Value") String customHeader) {
    System.out.println("Custom Header: " + customHeader);
    return ResponseEntity.ok("Header processed");
}

요청에 Custom-Header가 없으면, 기본값 Default-Value가 사용됩니다.

3. Spring에서 헤더를 활용하는 이유

(1) 인증 및 권한

헤더는 인증 토큰, 세션 ID 등 사용자 인증 정보를 포함하는 데 자주 사용됩니다.

예: Authorization: Bearer token123.

(2) 요청 데이터 설명

요청 본문의 형식(Content-Type).
요청 데이터의 길이(Content-Length).

(3) 사용자/클라이언트 정보

User-Agent: 요청을 보낸 클라이언트의 정보.
예: User-Agent: Mozilla/5.0.

4. 현업에서의 헤더 활용

(1) 인증 및 보안

REST API 인증:
- OAuth2, JWT 등에서 토큰을 헤더로 전달:

Authorization: Bearer <token>

CORS 설정:
- 클라이언트 도메인 확인:

Origin: https://example.com

(2) 데이터 형식 관리

서버와 클라이언트 간 데이터 형식 정의:

Content-Type: application/json
Accept: application/json

(3) 트래픽 분석 및 로깅

User-Agent 헤더로 클라이언트의 정보를 분석:

User-Agent: PostmanRuntime/7.29.0

5. 요약

헤더란?
- 요청과 응답의 메타데이터를 담는 영역.
- 본문(Body) 데이터 외에 추가적인 정보를 제공합니다.
Spring에서 헤더 처리
- @RequestHeader를 사용해 헤더 값을 가져옵니다.
- 모든 헤더는 HttpHeaders 객체로 받을 수 있습니다.
실무 활용
- 인증, 데이터 형식 관리, 클라이언트 정보 추적 등에서 자주 사용됩니다.

질문 10. 그런데, @RequestPart(required = true) MultipartFile[] files 에서, 왜 <> 가 아니고 [] 인 이유가 뭐야? 몇개의 파일을 업로드하게 될지 모르는거니까 <> 여야 하는거 아닌가? 내가 잘 못 이해하고 있는게 있으면 상세하게 설명해주라.

좋은 질문이에요! MultipartFile[]와 List<MultipartFile>의 차이와 왜 []를 사용했는지, 그리고 올바른 이해를 돕기 위해 상세히 설명드릴게요.

1. MultipartFile[]와 List<MultipartFile>의 차이

(1) MultipartFile[]

Java 배열로 선언된 형태입니다.
배열은 크기가 고정되며, 특정 타입의 객체를 연속적으로 저장합니다.

장점

배열은 단순하며, 처리 속도가 빠릅니다.
메모리 효율성이 좋습니다(배열은 고정 크기).

예시

@PostMapping("/upload")
public ResponseEntity<?> uploadFiles(@RequestPart MultipartFile[] files) {
    for (MultipartFile file : files) {
        System.out.println(file.getOriginalFilename());
    }
    return ResponseEntity.ok("Files processed");
}

(2) List<MultipartFile>

Java의 **컬렉션(Collection)**으로 선언된 형태입니다.
리스트는 크기가 동적이며, 객체를 순서대로 저장합니다.

장점

리스트는 유연성이 뛰어납니다. 크기가 동적으로 변하며, 삽입/삭제가 용이합니다.
더 많은 유틸리티 메서드를 제공합니다(예: add, remove, contains).

예시

@PostMapping("/upload")
public ResponseEntity<?> uploadFiles(@RequestPart List<MultipartFile> files) {
    for (MultipartFile file : files) {
        System.out.println(file.getOriginalFilename());
    }
    return ResponseEntity.ok("Files processed");
}

2. 왜 MultipartFile[]를 사용하는가?

Spring에서 multipart/form-data 요청을 처리할 때 기본적으로 배열([])을 사용하도록 설계되었기 때문입니다.

(1) 요청 데이터 형식

클라이언트가 여러 파일을 업로드할 때, HTTP 요청은 보통 다음과 같은 형식으로 전달됩니다:

Content-Disposition: form-data; name="files"; filename="file1.png"
Content-Disposition: form-data; name="files"; filename="file2.png"

이 요청은 서버에서 MultipartFile[]로 쉽게 매핑됩니다.

(2) 배열이 더 간단

Spring은 단순하고 빠른 처리를 위해 배열을 기본값으로 사용합니다:

배열([])은 크기가 고정되지만, 클라이언트가 보낸 모든 파일을 한 번에 처리하기엔 충분합니다.

3. 그렇다면 List<MultipartFile>는 사용할 수 없는가?

아니요, 사용할 수 있습니다! Spring은 List<MultipartFile>도 지원합니다.
다만, List를 사용할 경우 Spring 내부에서 배열을 리스트로 변환하는 추가 작업이 발생합니다.

Spring의 동작

클라이언트가 multipart/form-data 요청을 보냄.
Spring이 파일을 MultipartFile[]로 매핑.
선언된 파라미터가 List<MultipartFile>라면, 내부적으로 배열을 리스트로 변환.

코드 예시

@PostMapping("/upload")
public ResponseEntity<?> uploadFiles(@RequestPart List<MultipartFile> files) {
    for (MultipartFile file : files) {
        System.out.println(file.getOriginalFilename());
    }
    return ResponseEntity.ok("Files processed");
}

4. 언제 []와 List<>를 사용할까?

상황	배열 []	리스트 List<>
단순 다중 파일 처리	MultipartFile[]	가능하지만 필요 이상으로 복잡함
추가 데이터 조작(삽입/삭제 등) 필요	적합하지 않음	List<MultipartFile> 권장
동적 데이터 처리	배열은 크기 고정	List는 크기 동적으로 변경 가능
Spring 기본 동작	기본적으로 배열 사용	Spring이 자동 변환 수행

5. 결론

왜 MultipartFile[]를 사용했을까?

Spring은 기본적으로 배열([])을 사용해 multipart 데이터를 처리합니다.
MultipartFile[]는 단순하고 빠르며, 다수의 파일을 처리하기에 충분한 기능을 제공합니다.

List<MultipartFile>는 언제 사용하나?

추가적인 유연성이 필요할 때.
- 파일 목록을 동적으로 조작하거나, 추가 데이터를 함께 다뤄야 할 때.

올바른 이해

MultipartFile[]와 List<MultipartFile>는 모두 사용할 수 있지만, Spring의 기본 설계가 배열 중심이라는 점을 기억하면 이해가 쉬워집니다. Spring 내부 동작에서 필요하다면 배열을 리스트로 변환해 주므로, 개발자는 필요한 상황에 맞게 선택하면 됩니다.

추가로, MultipartFile[] 이 아니라, MultipartFile<> 이면 어떻게 되는걸까?

**MultipartFile<>**는 문법적으로 잘못된 표현입니다.

Java의 제네릭(Generic) 문법에서는 **<> 안에 타입 변수(Type Parameter)**가 들어가야 합니다. 따라서 **MultipartFile<>**처럼 단일 타입을 제네릭으로 사용할 수 없습니다.

자세히 설명할게요!

1. 제네릭(Generic) 문법의 규칙

Java에서 **제네릭(Generic)**은 <> 안에 타입 변수를 넣어서 다양한 타입을 처리할 수 있도록 설계된 기능입니다.

제네릭 문법

올바른 제네릭 문법: List<String>, Map<Integer, String>.
잘못된 문법: MultipartFile<> (제네릭은 컬렉션 타입이나 일반 클래스에서 사용됩니다).

예: 제네릭을 사용하는 경우

List<String> names = new ArrayList<>();
Map<Integer, String> users = new HashMap<>();

위 코드에서:

List<String>: 문자열(String) 타입의 리스트를 의미.
Map<Integer, String>: 키가 정수(Integer), 값이 문자열(String)인 맵을 의미.

2. 왜 MultipartFile<>는 안 되는가?

이유 1: MultipartFile은 단일 파일을 처리하는 인터페이스

**MultipartFile**은 단일 파일을 나타내는 Spring의 인터페이스입니다.
따라서, 제네릭을 적용할 필요가 없습니다.
- MultipartFile 자체로 단일 파일을 의미합니다.

public interface MultipartFile {
    String getOriginalFilename();
    InputStream getInputStream();
    long getSize();
    // 기타 메서드...
}

이유 2: 제네릭은 컬렉션(Collection)에 사용되는 경우가 많음

제네릭은 리스트(List), 맵(Map), 셋(Set) 같은 컬렉션 타입에서 주로 사용됩니다.
이는 Java가 타입 안정성을 보장하기 위해 제공하는 기능입니다.

예: 제네릭을 사용하는 경우

List<MultipartFile> files = new ArrayList<>();

위 코드에서 **List<MultipartFile>**은 MultipartFile 객체들의 리스트를 의미합니다.
이 경우 제네릭을 사용하는 이유는 리스트가 어떤 타입의 객체를 포함하는지 명확하게 정의하기 위해서입니다.

3. MultipartFile<>와 MultipartFile[]의 차이

구분	설명	사용 가능 여부
MultipartFile<>	잘못된 문법 (제네릭이 필요하지 않음)	❌ 사용 불가
MultipartFile[]	MultipartFile 객체의 배열	✅ 사용 가능
List<MultipartFile>	MultipartFile 객체의 리스트	✅ 사용 가능

4. 왜 제네릭이 필요한가?

Java의 제네릭은 타입 안정성과 유연성을 보장하기 위해 존재합니다.
예를 들어, 제네릭을 사용하지 않으면, 리스트에 어떤 타입의 객체가 들어가는지 알 수 없습니다.

제네릭을 사용하지 않는 경우:

List files = new ArrayList<>();
files.add("text");         // 문자열 추가
files.add(new File("image.jpg")); // 파일 추가

Object file = files.get(0);

위 코드에서는 리스트에 어떤 타입의 객체가 들어갔는지 알 수 없기 때문에, 타입 변환이 필요합니다.

제네릭을 사용하는 경우:

List<MultipartFile> files = new ArrayList<>();
files.add(new MockMultipartFile("file1.jpg", new byte[0]));
MultipartFile file = files.get(0);

제네릭을 사용하면 타입 안전성이 보장되어, 타입 변환 없이 안전하게 객체를 사용할 수 있습니다.

5. 결론: MultipartFile<>는 왜 안 되는가?

**MultipartFile**은 단일 파일을 처리하는 인터페이스이므로, 제네릭을 사용할 필요가 없습니다.
제네릭(<>)은 컬렉션 타입에서 사용되며, 주로 List<MultipartFile> 또는 Map<String, MultipartFile> 형태로 사용됩니다.
**배열 형태(MultipartFile[])**와 리스트 형태(List<MultipartFile>) 모두 사용 가능하지만, 제네릭 없이 MultipartFile<>는 문법적으로 잘못된 표현입니다.

6. 언제 배열([])과 리스트(List<>)를 사용해야 할까?

상황	추천 타입	이유
파일 개수가 고정된 경우	MultipartFile[]	배열이 더 단순하고 빠름.
파일 개수가 유동적인 경우	List<MultipartFile>	리스트는 크기가 동적으로 변함.
추가적인 조작이 필요한 경우	List<MultipartFile>	리스트가 더 많은 유틸리티 메서드 제공.

7. 요약

MultipartFile<>는 문법적으로 잘못된 표현입니다.
**MultipartFile**은 단일 파일을 처리하는 인터페이스이므로, 제네릭이 필요하지 않습니다.
다중 파일을 처리할 때는 배열(MultipartFile[]) 또는 **리스트(List<MultipartFile>)**를 사용합니다.
제네릭은 주로 컬렉션 타입에서 사용되며, 타입 안전성을 보장하기 위해 필요합니다.

new ArrayList

new ArrayList란?

new ArrayList는 Java의 컬렉션(List 인터페이스)을 구현한 클래스인 ArrayList 객체를 생성하는 구문입니다.
**ArrayList**는 동적 크기를 가진 배열로, 객체들을 순서대로 저장하고 필요에 따라 크기가 자동으로 조정됩니다.

1. 기본 문법

List<String> list = new ArrayList<>();

List<String>: Java의 인터페이스인 List를 사용하여 참조 변수 선언.
new ArrayList<>(): ArrayList 클래스의 객체 생성.

2. 왜 ArrayList를 사용할까?

ArrayList는 Java에서 가장 널리 사용되는 리스트 구현 클래스입니다.
다음과 같은 상황에서 사용됩니다:

✅ 장점

크기가 동적으로 변경됩니다.
- 배열은 크기가 고정되지만, ArrayList는 데이터를 추가하면 크기가 자동으로 늘어납니다.
데이터 순서 유지.
- 데이터가 추가된 순서를 그대로 유지합니다.
검색 속도 빠름.
- 인덱스를 기반으로 데이터를 빠르게 검색할 수 있습니다.
다양한 유틸리티 메서드 제공.
- add(), remove(), contains(), size() 등 다양한 메서드를 제공합니다.

❌ 단점

삽입/삭제 속도 느림.
- 중간에 데이터를 삽입하거나 삭제할 때, 나머지 요소들을 이동해야 하기 때문에 속도가 느릴 수 있습니다.
메모리 낭비 가능성.
- 초기 크기보다 더 많은 데이터를 저장할 때, 새로운 배열을 생성하고 기존 데이터를 복사하는 과정에서 메모리 낭비가 발생할 수 있습니다.

3. ArrayList 생성 방법

다양한 생성자 오버로딩을 제공합니다.

(1) 기본 생성자

List<String> list = new ArrayList<>();

기본 크기(용량)로 ArrayList를 생성합니다.

(2) 초기 용량 지정

List<String> list = new ArrayList<>(50);

초기 용량을 50으로 설정하여 ArrayList를 생성합니다.

(3) 다른 컬렉션으로부터 생성

List<String> anotherList = new ArrayList<>(existingList);

기존 리스트나 컬렉션으로부터 새로운 ArrayList를 생성합니다.

4. 주요 메서드

메서드	설명
add(E element)	요소 추가.
remove(Object o)	요소 삭제.
get(int index)	인덱스에 있는 요소 가져오기.
size()	리스트의 크기(요소 개수) 반환.
contains(Object o)	특정 요소가 리스트에 포함되어 있는지 확인.

5. 예제 코드

(1) 문자열 리스트 생성

List<String> names = new ArrayList<>();
names.add("Alice");
names.add("Bob");
names.add("Charlie");

System.out.println(names); // [Alice, Bob, Charlie]

(2) 요소 제거

names.remove("Bob");
System.out.println(names); // [Alice, Charlie]

(3) 요소 검색

System.out.println(names.get(0)); // Alice
System.out.println(names.contains("Charlie")); // true

6. ArrayList와 배열([])의 차이

항목	배열 []	ArrayList
크기	고정 크기	동적 크기
데이터 타입	기본 데이터 타입 및 객체 타입	객체 타입만 가능
메모리 관리	고정 메모리	동적으로 메모리 관리
메서드 지원	메서드 없음	다양한 유틸리티 메서드 제공

7. 실무에서의 활용

데이터 목록 관리:
- 사용자가 업로드한 파일 목록, 상품 목록 등.
동적 데이터 처리:
- 데이터를 추가/삭제할 수 있는 유연한 데이터 구조가 필요할 때.

8. 자주 쓰는 패턴: 인터페이스로 선언, 클래스 구현으로 생성

List<String> list = new ArrayList<>();

왜 인터페이스로 선언할까?

인터페이스(List)로 선언하면, 다양한 구현체(ArrayList, LinkedList 등)로 변경할 수 있는 유연성이 생깁니다.
필요에 따라 LinkedList로 변경할 수도 있고, Vector로 변경할 수도 있습니다.

9. 요약

**new ArrayList<>()**는 동적 크기를 가진 배열을 생성하는 코드입니다.
ArrayList는 크기가 자동으로 조정되는 리스트로, Java에서 가장 많이 사용하는 컬렉션 중 하나입니다.
List 인터페이스로 선언하고 ArrayList로 생성하는 것이 실무에서 권장되는 패턴입니다.

new ArrayList<> 라던지 new HashMap<> 에서는 되는데, 왜 MultipartFile<> 은 안되는걸까?

아주 좋은 질문이에요!

new ArrayList<>나 new HashMap<>에서는 제네릭(Generic) 문법이 사용되는데, 왜 MultipartFile<>는 안 되는지 차근차근 설명드릴게요. 핵심 개념인 **제네릭(Generic)**과 인터페이스/클래스의 차이를 이해하면 쉽게 이해할 수 있을 거예요.

1. 왜 new ArrayList<>는 되는데 MultipartFile<>는 안 될까?

간단히 말하면:

ArrayList<>와 HashMap<>는 클래스이기 때문에 객체를 생성할 때 제네릭을 사용할 수 있습니다.
반면, MultipartFile은 인터페이스이기 때문에 객체를 직접 생성할 수 없습니다.

2. 클래스와 인터페이스의 차이

클래스

객체를 생성할 수 있는 설계도입니다.
예: ArrayList, HashMap, File.

ArrayList<String> list = new ArrayList<>();

인터페이스

객체 생성이 불가능한 추상적인 타입입니다.
인터페이스는 **규격(메서드 선언)**만 정의하고, **구현체(클래스)**가 있어야 객체를 생성할 수 있습니다.
예: List, Map, MultipartFile.

MultipartFile file = new MockMultipartFile(...); // 구현체가 필요

3. 제네릭(Generic) 문법의 핵심

제네릭이란?

제네릭은 클래스나 메서드에서 사용할 타입을 외부에서 지정할 수 있도록 하는 문법입니다.

제네릭의 사용 조건

제네릭은 클래스나 인터페이스에 사용됩니다.
제네릭을 사용할 수 있는 클래스는 객체를 생성할 수 있는 클래스여야 합니다.

4. 왜 MultipartFile<>는 안 될까?

MultipartFile의 정의

public interface MultipartFile {
    String getOriginalFilename();
    InputStream getInputStream();
    long getSize();
    // 기타 메서드...
}

MultipartFile은 인터페이스이므로, 객체를 직접 생성할 수 없습니다.
대신, 구현 클래스가 필요합니다.

구현 클래스 예시: MockMultipartFile

MultipartFile file = new MockMultipartFile("file1.jpg", new byte[0]);

5. 왜 new ArrayList<>는 가능한가?

ArrayList의 정의

public class ArrayList<E> extends AbstractList<E> implements List<E> {
    // 구현 코드...
}

ArrayList는 클래스이므로, 객체를 생성할 수 있습니다.
제네릭을 사용해 리스트에 저장할 타입을 지정할 수 있습니다:

List<String> list = new ArrayList<>();

6. 인터페이스 타입에 객체를 할당하는 방법

인터페이스 타입의 변수에 객체를 할당하려면, **구현체(클래스)**를 사용해야 합니다.

예: MultipartFile 인터페이스

MultipartFile file = new MockMultipartFile("file1.jpg", new byte[0]);

예: List 인터페이스

List<String> list = new ArrayList<>();

7. 정리

구분	클래스	인터페이스
객체 생성 가능 여부	가능 (new ArrayList<>)	불가능 (new MultipartFile<>)
제네릭 사용 가능 여부	가능 (ArrayList<E>)	인터페이스 타입 변수로 사용 가능
예시	new ArrayList<>();	MultipartFile file = new MockMultipartFile();

8. 추가 질문: 왜 인터페이스 타입을 사용하나요?

인터페이스 타입을 사용하는 이유는 유연성과 확장성 때문입니다.

유연성: 코드가 특정 구현 클래스에 의존하지 않으므로, 필요에 따라 구현체를 바꿀 수 있습니다.

MultipartFile file = new MockMultipartFile(...);
MultipartFile file = new StandardMultipartFile(...);

확장성: 새로운 구현체를 추가할 수 있습니다.
- 예: 새로운 파일 업로드 라이브러리를 추가할 때 코드 변경이 최소화됩니다.

9. 결론

new ArrayList<>와 new HashMap<>는 클래스 객체를 생성할 때 사용 가능한 문법입니다.
MultipartFile<>는 잘못된 문법이며, 인터페이스 타입에는 객체를 할당할 수 없습니다.
인터페이스 타입의 변수에 값을 할당하려면 구현 클래스의 객체를 생성해야 합니다.

10. 보너스: 구현체 없이 인터페이스 타입을 사용하는 경우

만약 구현체 없이 MultipartFile 같은 인터페이스 타입을 사용하려면 익명 클래스나 람다식을 사용할 수 있습니다.

예: 익명 클래스 사용

MultipartFile file = new MultipartFile() {
    @Override
    public String getOriginalFilename() {
        return "file1.jpg";
    }
    @Override
    public InputStream getInputStream() {
        return new ByteArrayInputStream(new byte[0]);
    }
    @Override
    public long getSize() {
        return 0;
    }
    // 기타 메서드 구현...
};

이제 왜 new ArrayList<>는 되는데 MultipartFile<>는 안 되는지 이해가 되셨나요?

근데 파일 개수가 고정된 경우일수가 있는건가..?
어떤 경우는 1개일수도 있고, 어떤 경우는 10개 일수도 있는데, 그러면 크기가 다른거 아닌가?

아주 좋은 질문이에요! 파일 개수가 고정된 경우와 유동적인 경우에 대해 혼란이 생길 수 있는데, 현실적으로는 파일 개수가 고정된 경우는 거의 없습니다. 대부분의 경우, 파일 개수는 유동적이기 때문에 이를 유연하게 처리할 수 있어야 합니다.

그럼에도 불구하고 MultipartFile[] (배열)과 List<MultipartFile> (리스트)의 선택이 실무에서 왜 필요한지, 각각의 장단점과 현실적인 사용 사례를 통해 자세히 설명해드릴게요.

🔎 1. 파일 개수가 고정된 경우가 정말 있을까?

일반적으로 파일 개수는 유동적입니다.

사용자가 업로드하는 파일 개수를 미리 알 수 없는 경우가 대부분입니다.
- 예: 프로필 사진 업로드 → 1개.
- 예: 상품 이미지 업로드 → 최대 10개.
- 예: 대량 파일 업로드 → 수백 개.

하지만 일부 특정한 경우에는 파일 개수가 고정될 수도 있어요.

✅ 고정된 경우의 예시

신분증 업로드 (앞면, 뒷면)
- 사용자는 반드시 **2개의 이미지 파일(앞면, 뒷면)**을 업로드해야 함.
- 이 경우 MultipartFile[]로 **크기가 고정된 배열(2개)**을 사용하면 적절합니다.
이력서와 자기소개서 파일 업로드
- 반드시 이력서와 자기소개서 2개의 파일만 업로드해야 함.
- 이 경우에도 배열로 처리하는 게 더 단순합니다.

❌ 하지만, 대부분의 경우 파일 개수는 유동적입니다.

예를 들어:

사용자가 상품 이미지를 업로드할 때, 몇 개를 업로드할지 모릅니다.
어떤 사용자는 1개만 올리고, 어떤 사용자는 10개를 올릴 수 있습니다.

이런 경우에는 배열(MultipartFile[])보다는 리스트(List<MultipartFile>)가 더 적합합니다.

💡 2. 배열(MultipartFile[]) vs 리스트(List<MultipartFile>) 비교

항목	배열 (MultipartFile[])	리스트 (List<MultipartFile>)
크기	고정 크기	동적 크기
유연성	제한적 (배열 크기 변경 불가)	매우 유연 (필요에 따라 크기 변경 가능)
사용 사례	파일 개수가 고정된 경우	파일 개수가 유동적인 경우
유틸리티 메서드 제공	없음	있음 (add(), remove(), contains() 등)

🔨 3. 왜 Spring에서 기본적으로 MultipartFile[]을 사용할까?

Spring에서는 배열(MultipartFile[])을 기본값으로 사용합니다.
이유는 배열이 처리 속도가 더 빠르고 간단하기 때문입니다.

하지만 실무에서는 유동적인 파일 개수 처리가 필요하므로, List<MultipartFile>도 자주 사용합니다.

배열이 빠른 이유

배열은 메모리 공간이 연속적으로 할당되기 때문에, 데이터 접근 속도가 빠릅니다.
배열 크기를 한 번 정하면 변경할 수 없으므로, 메모리 관리가 효율적입니다.

🧩 4. 실무에서는 어떻게 처리할까?

✅ 리스트(List<MultipartFile>)를 사용하는 경우가 많습니다.

왜냐하면:

파일 개수가 유동적인 경우가 대부분이기 때문입니다.
리스트는 크기가 동적으로 변하며, 유틸리티 메서드(add(), remove(), size() 등)를 제공하므로 관리가 편리합니다.

✅ 실무 코드 예시 (리스트 사용)

@PostMapping("/upload")
public ResponseEntity<?> uploadFiles(@RequestPart List<MultipartFile> files) {
    for (MultipartFile file : files) {
        System.out.println("Uploaded file: " + file.getOriginalFilename());
    }
    return ResponseEntity.ok("Files uploaded successfully!");
}

장점

사용자가 업로드한 파일 개수에 관계없이 유연하게 처리 가능.
유틸리티 메서드를 활용해 파일을 동적으로 추가/제거할 수 있음.

✅ 배열(MultipartFile[])을 사용하는 경우

@PostMapping("/upload")
public ResponseEntity<?> uploadFiles(@RequestPart MultipartFile[] files) {
    for (MultipartFile file : files) {
        System.out.println("Uploaded file: " + file.getOriginalFilename());
    }
    return ResponseEntity.ok("Files uploaded successfully!");
}

장점

처리 속도가 빠름.
코드가 단순함.

단점

파일 개수가 고정되어 있어 유동적인 상황에 적합하지 않음.

🤔 5. 그럼 언제 배열을 사용하고, 언제 리스트를 사용할까?

배열(MultipartFile[])을 사용할 때

파일 개수가 고정된 상황.
- 예: 신분증 업로드 (앞면/뒷면).
- 예: 특정한 요구사항으로 파일 개수가 정해진 경우.

리스트(List<MultipartFile>)를 사용할 때

파일 개수가 유동적인 상황.
- 예: 상품 이미지 업로드.
- 예: 여러 개의 문서 파일 업로드.
- 예: 대량 파일 업로드.

🧪 6. 실무에서 고려해야 할 것

파일 크기 제한
- 업로드할 파일의 개수뿐 아니라, 각 파일의 크기와 전체 요청 크기도 제한해야 합니다.
- Spring Boot 설정 예시:

spring:
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 50MB

파일 확장자 및 타입 검증
- 사용자가 잘못된 파일(예: .exe, .bat)을 업로드하지 못하도록 파일 확장자와 타입을 검증해야 합니다.
보안
- 대용량 파일 업로드 시, 서버가 과부하되지 않도록 비동기 처리나 클라우드 스토리지 연동을 고려합니다.

📝 7. 결론

배열(MultipartFile[]): 파일 개수가 고정된 경우에 사용.
리스트(List<MultipartFile>): 파일 개수가 유동적인 경우에 사용.
👉 실무에서는 리스트(List<MultipartFile>)를 사용하는 경우가 더 많습니다.

당신이 쓴 코드에서 MultipartFile[]을 사용했는데, 왜 유동적인 개수의 파일이 업로드되는 걸까?

이 질문의 핵심은 Java 배열([])의 특징과 Spring이 이를 어떻게 처리하는지에 있습니다.

💡 1. MultipartFile[]은 고정된 배열이 아니다?

우리가 흔히 말하는 배열은 고정 크기라고 알고 있지만, Spring에서는 배열을 유연하게 처리합니다.

✅ Spring의 배열 처리 방식

클라이언트가 1개든 100개든 파일을 업로드하면, Spring이 이를 배열로 자동 매핑합니다.
이때 배열의 크기는 클라이언트가 보낸 파일 개수에 따라 동적으로 결정됩니다.

즉, 배열 크기는 코드에서 고정하지 않아도 되며, 클라이언트가 업로드한 파일 개수에 따라 달라지는 것입니다.

🔎 예제 코드로 살펴보기

@PostMapping("/upload")
public ResponseEntity<?> uploadFiles(@RequestPart MultipartFile[] files) {
    System.out.println("파일 개수: " + files.length);
    for (MultipartFile file : files) {
        System.out.println("파일 이름: " + file.getOriginalFilename());
    }
    return ResponseEntity.ok("Files uploaded successfully!");
}

클라이언트 요청 1: 파일 1개 업로드

파일 개수: 1
파일 이름: file1.jpg

클라이언트 요청 2: 파일 3개 업로드

파일 개수: 3
파일 이름: file1.jpg
파일 이름: file2.jpg
파일 이름: file3.jpg

🧩 2. 왜 배열인데 크기가 동적일까?

Java의 배열은 고정 크기지만, Spring의 매핑 과정에서 배열 크기를 동적으로 처리하기 때문입니다.

✅ Spring의 처리 과정

클라이언트가 파일을 업로드하면, HTTP 요청은 multipart/form-data 형식으로 전달됩니다.
Spring은 파일의 개수에 맞게 배열을 동적으로 생성합니다.
- 클라이언트가 1개 파일을 업로드하면 배열 크기는 1.
- 클라이언트가 10개 파일을 업로드하면 배열 크기는 10.

🤔 3. 그렇다면 배열 대신 List<MultipartFile>를 써야 할까?

사실, MultipartFile[]와 List<MultipartFile> 둘 다 사용 가능합니다.
둘 중 무엇을 선택할지는 유연성과 코드 가독성을 기준으로 결정합니다.

상황	MultipartFile[] 사용	List<MultipartFile> 사용
단순한 파일 업로드 처리	적합	적합
파일 추가/삭제 조작 필요	부적합	적합
코드 가독성	상대적으로 덜 직관적	더 직관적

🛠 4. 실무에서 권장하는 방식

1) 파일 개수가 유동적이라면 List<MultipartFile>를 사용하는 것이 더 적절합니다.

@PostMapping("/upload")
public ResponseEntity<?> uploadFiles(@RequestPart List<MultipartFile> files) {
    System.out.println("파일 개수: " + files.size());
    for (MultipartFile file : files) {
        System.out.println("파일 이름: " + file.getOriginalFilename());
    }
    return ResponseEntity.ok("Files uploaded successfully!");
}

✅ 5. 그렇다면 왜 Spring 문서에는 MultipartFile[]가 더 많이 등장할까?

Spring 문서나 튜토리얼에서 MultipartFile[]를 더 자주 사용하는 이유는 단순성 때문입니다.

배열은 Java의 기본 타입이기 때문에 가볍고 빠릅니다.
Spring 내부에서 배열을 리스트로 변환하는 작업이 필요 없으므로 성능이 약간 더 좋습니다.

하지만, 실무에서는 List<MultipartFile>가 더 유연하고 관리하기 편하기 때문에 자주 사용됩니다.

📋 6. 요약

MultipartFile[]는 고정 크기가 아니며, Spring이 요청에 따라 배열 크기를 동적으로 결정합니다.
파일 개수가 유동적인 상황에서는 List<MultipartFile>를 사용하는 것이 더 직관적이고 관리하기 쉽습니다.
Spring에서 배열(MultipartFile[])을 사용하는 이유는 단순성과 성능 때문입니다.
실무에서는 유연성을 고려해 List<MultipartFile>를 더 자주 사용합니다.

💡 추가 팁: 클라이언트가 파일을 하나만 업로드해도 배열이나 리스트로 처리된다.

MultipartFile[] files;  // 파일 1개 업로드 시 배열 크기: 1
List<MultipartFile> files;  // 파일 1개 업로드 시 리스트 크기: 1

이제 왜 배열을 사용했음에도 유동적인 파일 개수가 처리되는지 이해가 되셨나요? 😊

'Spring Boot (+ RESTful)' 카테고리의 다른 글

RESTful 웹 서비스 구축 - # Project 04 - 이미지 업로드 (7) (0)	2025.01.09
RESTful 웹 서비스 구축 - # Project 04 - 이미지 업로드 (6) (0)	2025.01.08
RESTful 웹 서비스 구축 - # Project 04 - 이미지 업로드 (4) (0)	2025.01.06
RESTful 웹 서비스 구축 - # Project 04 - 이미지 업로드 (3) (0)	2025.01.05
RESTful 웹 서비스 구축 - # Project 04 - 이미지 업로드 (2) (0)	2025.01.04

현재글RESTful 웹 서비스 구축 - # Project 04 - 이미지 업로드 (5)

wy_family

wy-family 님의 블로그 입니다.

Docker, 데브옵스, CICD, restful, Python, 진로계획, restfulapi, spring, 티스토리챌린지, aws, 오블완, restapi, 진로고민, CI, 서버배포, 백엔드, chatbot, it학습, KDT, Django, Pipeline, PostgreSQL, 자바, Rest, 웹개발, GitLab, SpringBoot, java, 스마트팩토리, cd,

Today :
Yesterday :

일	월	화	수	목	금	토
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31