트레이드오프: HTTP 요청 수 감소 vs 데이터 크기 증가
상위 맥락
03. 데이터 최적화와 비동기 < 04. 파일 업로드와 자원 관리 < 02. Spring MVC2 핵심 기술과 설계 < MVC < Spring < Web
핵심 정리
자료에서 데이터 최적화의 핵심 트레이드오프는 Base64 인코딩을 사용할 때 발생합니다. Base64는 이미지를 HTML이나 JSON 안에 직접 넣을 수 있으므로 별도의 HTTP 요청을 줄입니다. 하지만 바이너리를 텍스트로 바꾸면서 데이터 크기가 증가하고, 정적 파일처럼 브라우저 캐싱을 활용하기 어렵습니다.
HTTP 요청 수 감소의 장점
전통적인 이미지 로딩은 HTML이나 JSON을 받은 뒤 이미지 URL에 대해 추가 HTTP 요청을 보냅니다. Base64를 사용하면 이미지 데이터가 응답 안에 함께 들어오므로 추가 요청이 필요 없습니다. 특히 Ajax 업로드 후 미리보기처럼 즉시 화면에 표시해야 하는 상황에서는 빠른 피드백을 제공할 수 있습니다.
데이터 크기 증가의 비용
Base64는 원본 바이너리보다 문자열 크기가 커집니다. 따라서 큰 이미지를 Base64로 넣으면 HTML 또는 JSON 응답 자체가 무거워집니다. 또한 동일 이미지를 여러 번 사용해도 정적 리소스 캐싱을 이용하기 어렵기 때문에, 페이지를 다시 받을 때마다 큰 문자열을 다시 내려받을 수 있습니다.
선택 기준
자료의 흐름은 다음 기준으로 정리할 수 있습니다.
- 작은 이미지, 일회성 미리보기, 캐싱 효용이 낮은 동적 리소스: Base64가 적합합니다.
- 큰 이미지, 반복 사용 리소스, 캐싱이 중요한 파일: MultipartFile 저장 후 ResourceHandler로 URL 서빙하는 방식이 적합합니다.
한 문장 요약
Base64는 HTTP 요청 수를 줄이는 대신 응답 데이터 크기 증가와 캐싱 불리함을 감수하는 방식이므로, 작은 일회성 리소스와 큰 반복 리소스를 구분해 적용해야 합니다.
핵심 연결
MultipartFile, Base64와 함께 읽으면 좋습니다.