이미지 URL을 HTML에 넣으면
실제로 무엇이 일어날까?

01 / IMAGE URL

<img src>는 이미지를 코드 안에 저장하는 것이 아니라 주소를 적는 것입니다.

HTML에서 이미지를 보여줄 때 가장 흔한 방식은 <img src="...">입니다. 이때 HTML 안에는 이미지 파일 자체가 들어가는 것이 아니라 이미지가 있는 위치만 기록됩니다.

사용자가 페이지를 열면 브라우저는 HTML을 먼저 받은 뒤, 그 안에 적힌 이미지 URL을 발견하고 해당 서버에 별도의 요청을 보냅니다. 이미지가 20개라면 브라우저는 필요한 이미지들을 각각 요청해 화면에 표시합니다.

02 / STORAGE & DELIVERY

원본 파일을 보관하는 곳과 사용자에게 전달하는 곳은 같을 수도, 다를 수도 있습니다.

이미지를 서비스하려면 먼저 파일이 저장될 공간이 필요합니다. 웹호스팅 서버, 오브젝트 스토리지, 이미지 관리 서비스 등이 원본 저장소 역할을 할 수 있습니다.

규모가 커지면 원본 저장소 앞에 CDN을 두는 경우가 많습니다. CDN은 사용자가 이미지에 접근할 때 매번 원본 서버까지 가지 않도록 여러 지역의 캐시 서버에서 파일을 전달합니다.

구조를 단순화하면

• Storage: 원본 파일을 보관
• CDN: 자주 요청되는 파일을 가까운 곳에서 전달
• HTML: 파일의 URL을 참조
• Browser: URL을 보고 실제 이미지를 요청

03 / TRAFFIC

같은 이미지 URL을 여러 사이트에서 호출하면 이미지 트래픽은 그 이미지 서버에 누적됩니다.

이미지를 한 번 업로드한 뒤 여러 웹사이트에서 같은 URL을 사용하면 저장 공간은 한 파일만 사용합니다. 하지만 방문자가 페이지를 열 때마다 이미지 데이터는 전송되어야 합니다. 따라서 저장 용량과 전송량은 별개의 문제입니다.

예를 들어 1MB 이미지가 10,000번 실제 전송된다면 단순 계산으로 약 10GB 수준의 데이터 전달이 발생할 수 있습니다. 실제 전송량은 캐시, 압축, 브라우저 동작과 CDN 정책에 따라 달라집니다.

04 / WHY CDN

CDN은 단순히 URL을 만들어주는 서비스가 아니라 전달 부담을 분산하는 계층입니다.

방문자가 늘어날수록 이미지, 영상, CSS, JavaScript 같은 정적 파일의 반복 요청이 많아집니다. CDN은 이런 정적 콘텐츠를 캐시해 원본 서버의 부하를 줄이고 사용자와 가까운 위치에서 전달하는 역할을 합니다.

• 원본 서버 요청 감소
• 지역에 따른 전송 지연 완화
• 대량 정적 파일 전달에 유리
• 브라우저 캐시 정책과 함께 활용 가능
• 서비스에 따라 이미지 리사이징·압축 기능 제공

그래서 웹빌더나 커머스 플랫폼이 대량의 이미지를 다룰 수 있는 이유는 단순히 큰 서버 하나에 모두 저장해서가 아니라 저장소와 CDN, 캐시 정책을 함께 운영하기 때문입니다.

05 / PRACTICAL SETUP

작게 시작할 때는 구조를 복잡하게 만들 필요가 없지만, 소유권과 이전 가능성은 생각해야 합니다.

포트폴리오나 기업 사이트처럼 이미지 수가 제한적이라면 현재 사용하는 플랫폼의 CDN이나 안정적인 이미지 호스팅을 활용해도 충분한 경우가 많습니다. 반면 여러 사이트에서 같은 자산을 공유하거나 서비스 사용자가 직접 이미지를 업로드한다면 별도 Storage와 CDN 구조를 검토하는 편이 좋습니다.

실무에서 먼저 확인할 것

• 이미지를 누가 업로드하고 관리하는가
• 파일이 어느 계정과 서비스에 종속되는가
• 원본 파일 백업이 가능한가
• 도메인이나 플랫폼 이전 시 URL을 유지할 수 있는가
• 월간 저장량보다 실제 전송량이 얼마나 되는가
• 이미지 크기 최적화와 WebP/AVIF 같은 포맷을 사용할 수 있는가