모두
모두콘텐츠
얼마 전 작은 쇼핑몰의 이미지가 간헐적으로 깨져서 서버를 확인했습니다. 저장 공간은 절반 넘게 남아 있었는데, 월 전송량 한도를 먼저 채운 상태였습니다. 이미지호스팅을 고를 때 디스크 용량만 보면 이런 일이 생깁니다. 저장량, 방문자에게 보내는 데이터, 순간 요청 수를 따로 계산해야 합니다.
이미지 파일 수보다 한 장의 크기부터 잰다
상품 사진 1,000장이 있다고 해보죠. 화면에 표시되는 파일이 장당 평균 300KB라면 필요한 저장 공간은 약 300MB입니다. 숫자만 보면 가장 싼 요금제로도 충분해 보입니다. 그런데 원본을 함께 보관하고 썸네일과 상세 화면용 파일까지 만들면 저장량은 두세 배로 늘 수 있습니다. 업로드할 때 원본 크기가 제각각이라면 평균 대신 실제 파일의 총량을 확인하는 편이 정확합니다.
서버가 업로드 때마다 이미지를 변환하는지도 확인해야 합니다. 이미 만들어 둔 파일을 전달하는 일과, 큰 원본을 매 요청마다 줄이고 압축하는 일은 서버에 주는 부담이 다릅니다. 후자라면 방문자가 많지 않아도 CPU와 메모리가 먼저 부족해질 수 있습니다. 보통은 업로드 시 필요한 크기를 만들고, 방문자 요청에는 완성된 파일을 보내는 구성이 운영하기 쉽습니다.
- 현재 파일의 총량과 최근 한 달 증가량을 확인합니다.
- 원본, 썸네일, 상세 이미지가 각각 몇 벌 저장되는지 셉니다.
- 백업 파일을 같은 계정에 보관한다면 그 공간도 별도로 더합니다.
전송량은 페이지 조회 수로 계산한다
한 페이지에 평균 300KB 이미지가 5장 있고 월 1만 번 열리면, 단순 계산으로 이미지 전송량은 약 15GB입니다. 월 10만 번이면 150GB가 됩니다. 방문자 수가 아니라 페이지 조회 수를 써야 하고, 한 사람이 여러 페이지를 보는 사이트라면 그만큼 더 잡아야 합니다. 화면 밖 이미지까지 한꺼번에 불러오는 구조라면 실제 전송량은 예상보다 커질 수 있습니다.
브라우저 캐시가 잘 작동하면 재방문자의 요청은 줄어듭니다. 반대로 이미지 주소가 자주 바뀌거나 캐시 설정이 짧으면 같은 파일을 반복해서 보내게 됩니다. CDN을 붙였을 때도 숫자를 구분해야 합니다. 캐시 적중률이 90%라면 원본 서버가 보내는 양은 크게 줄지만, CDN이 방문자에게 보내는 데이터 자체가 사라지는 건 아닙니다. 원본 서버의 전송량과 CDN의 전송량이 각각 어떻게 청구되는지 봐야 합니다.
순간 접속도 한 번 계산해두면 좋습니다. 평균 300KB 파일 요청이 초당 100건 몰리면 이미지 데이터만 초당 약 30MB, 대략 240Mbps입니다. 실제 전송 속도는 캐시 상태와 파일 크기에 따라 달라지지만, 월 전송량이 넉넉하다는 이유만으로 순간 부하까지 견딘다고 볼 수는 없습니다. 행사나 게시물 확산이 잦다면 평소 평균보다 피크 시간의 요청 기록이 더 쓸모 있습니다.
규모에 맞춰 호스팅 방식을 고른다
월 조회 수가 적고 이미지 변환도 업로드 때 끝난다면 기존 웹호스팅에 함께 두는 방식이 가장 단순합니다. 이미지 때문에 곧바로 VPS를 열 필요는 없습니다. 먼저 현재 요금제의 저장량, 월 전송량, 순간 트래픽 제한을 확인하세요. 일부 요금제는 전송량을 넉넉하게 표시해도 파일 보관 방식이나 외부 사이트에서의 이미지 호출에 조건을 둡니다.
이미지가 빠르게 늘고 여러 서버에서 같은 파일을 써야 한다면 객체 스토리지와 CDN 조합이 편합니다. 서버를 옮겨도 이미지 저장소를 그대로 둘 수 있고, 방문자 요청을 원본 서버가 모두 처리하지 않아도 됩니다. 다만 저장 공간만 보고 가격을 비교하면 틀리기 쉽습니다. 저장 비용에 요청 횟수, 외부 전송량, 이미지 변환 비용을 더해 월 예상액을 계산해야 합니다. 작은 사이트에서는 관리 항목이 늘어나는 비용이 절감액보다 클 수도 있습니다.
VPS가 필요한 경우는 이미지 변환 작업을 직접 제어하거나 기존 서비스와 파일 처리 과정을 밀접하게 묶어야 할 때입니다. VPS로 옮긴다고 백업이나 전송량 문제가 자동으로 해결되지는 않습니다. 운영체제 업데이트, 디스크 감시, 장애 복구까지 직접 맡아야 하니 그 작업 시간을 요금 차이와 함께 보게 됩니다.
이전과 백업에서 이미지가 가장 자주 빠진다
이미지를 옮길 때는 파일만 복사하고 끝내면 안 됩니다. 게시글이나 상품 정보에 저장된 이미지 경로, 접근 권한, 캐시 설정이 함께 맞아야 합니다. 저는 먼저 파일 수와 총 용량을 비교하고, 오래된 글과 최근 글을 골라 실제 화면에서 열리는지 확인합니다. 이전 도중 새로 올라온 파일이 빠지지 않도록 최종 동기화 시점도 정해둡니다. 캐시가 남아 있으면 이전이 성공한 것처럼 보일 수 있으니, 원본 저장소의 파일도 직접 확인해야 합니다.
백업은 운영 서버와 다른 저장 위치에 두는 편이 안전합니다. 같은 계정의 다른 폴더에 복사해둔 파일은 계정 문제나 실수로 함께 사라질 수 있습니다. 삭제나 덮어쓰기에 대비해 이전 버전을 일정 기간 보관하고, 한 달에 한 번은 일부 이미지를 실제로 복원해 확인합니다. 백업 작업이 성공했다고 표시되는 것과 파일을 되살릴 수 있는 것은 별개입니다.
공개 이미지는 다른 곳에서 무단으로 불러가면 전송량이 늘 수 있습니다. 외부 호출 제한을 걸 수 있지만 정상적인 공유까지 막히는지 먼저 확인해야 합니다. 비공개 이미지라면 단순히 경로를 숨기는 것으로 끝내지 말고 접근 권한을 검사해야 합니다. 결국 이미지호스팅은 큰 서버를 고르는 문제보다, 내 파일이 얼마나 쌓이고 얼마나 자주 전달되는지 측정하는 일에 가깝습니다. 그 수치가 잡히면 저렴한 요금제로 충분한 구간도 꽤 선명해집니다.
