앱 서비스에서 이미지 사용에 대한 고민
서비스를 만들 때 이미지에 대한 정책은 어떻게 정해야할까. 콘텐츠 제작 / 인프라 / 앱 측면에서
앱 서비스에서 제공하는 모든 것들은 비용으로 환산할 수 있다. 우스갯소리로 이미지 호스팅 비용 때문에 망한다는 이야기가 있기도하다. 여러가지 방법을 이용하여 줄일 수 있어서 실제로 일어나지는 않을 일이다.
최근 회사에서 여러가지 비용 줄이기를 하고 있는데, 그 중 하나가 이미지 호스팅 비용 줄이기였다. 여태 돈이 많이 나가던걸 몰랐던게 아쉽다.
- 스플래시 스크린 900KB -> 100KB
- 이벤트를 위한 이미지(들) 5MB -> 400KB
이 두가지가 주범이었는데 CDN을 이용하더라도 꽤 많은 비용을 발생시켰다. 앱에서는 대부분 캐시를 하고 있어서 그나마 조금은 막을 수 있었겠지만 아니었다면 기하급수적으로 늘었을 것이다. 그냥 앱을 켜놓기만 해도 캐러셀이 돌아가는 동안 이미지를 계속 요청할거고 그때마다 돈이 나갔을 것이다.
개발자들이 알아서 해주면 좋겠지만 어느정도는 서비스를 만드는 모든 사람들이 알고 있으면 정책을 정할 때 도움이 될 것 같다. 예를 들면 '사용자는 관리자 페이지에서 배너 이미지를 올릴 수 있다' 라는 사용자 스토리가 있을 때, '배너 이미지' 에 관한 정책을 정해야한다.
콘텐츠 제작자들은 이미지 너비/높이를 고민할테고 (혹은 비율), 개발자들은 업로드할 수 있는 파일의 크기가 중요하다. 정책을 정하는 입장에서 이를 알아서 해주세요 할 수 있지만, 다음과 같이 제안할 수 있다.
특정 인터넷 속도(LTE, WiFi 등)에서 100ms 이내에 불러 올 수 있게 해야한다.
이를 달성하려면 콘텐츠 제작자들과 개발자는 제약 조건 안에서 최대한의 퀄리티를 달성할 수 있도록 고민할 것이다.
네트워크 | 평균 속도(Mbps) | 100ms 동안 전송 가능한 데이터량 |
|---|---|---|
3G | 1 Mbps | 100ms × 1 Mbps = 12.5 KB |
LTE | 10 Mbps | 100ms × 10 Mbps = 125 KB |
WiFi | 30~100 Mbps | 100ms × 30 Mbps = 375 KB 이상 |
3G 기준이라면 12.5KB를 이야기하겠지만 현실적으로 말이 안되는 이야기고, 대략적으로 125KB ~ 375KB 정도 사이에서 이미지 용량이 정해져야 적절하다고 할 수 있다.
상황에 따라서 네트워크의 속도와 얼마나 빠르게 가져와야하냐를 기준으로 정하면 납득할 수 있는 기준이 나오지 않을까 싶다.
그렇다면 앱쪽에서는 어떤 것을 해야할까.
- 화면에 나올 때만 이미지를 불러온다.
- 혹은, 작은 썸네일을 먼저 불러오고 특정 시간 이상 화면에 노출된 경우에 더 높은 해상도의 이미지를 불러온다
- 한번 불러오면 HTTP 요청해서 가져오는 이미지는 사용자의 기기에 캐시한다.
캐시 기간은 다음에 업데이트할 가능성이 있는 대략적인 시간으로 설정한다.
예: 마케팅 이미지가 1주일에 한번씩 변경된다면 5일 정도
보통의 앱 개발 도구는 1번은 자연스럽게 달성된다. 사용자가 보고 있는 뷰포트 안에 있는 이미지만 HTTP 요청을 하기 때문이다. 두번째는 조금 손이 가는데, 서버에 작은 이미지와 원본 이미지 둘 다 가지고 있어야한다.
조금이라도 손이 덜 가게 하려면 Blurhash를 사용할 수 있다.
서버에 이미지와 Blurhash 문자열 LEHV6nWB2yk8pyo0adR*.7kCMdnj 을 함께 저장한다. 앱에서는 Blurhash 문자열을 이용한 흐릿한 이미지를 먼저 보여주고 Fade In 효과와 함께 원본 이미지를 가져오도록 할 수 있다.
이를 이용하면 이미지 요청량을 많이 줄일 수 있다.
개발하는 쪽 백엔드, 프론트엔드에서 챙겨야하는 일들은 위의 내용과 같다. 여러가지 개발도구를 이용해서 이미지를 최적화할 수 있는데 콘텐츠 제작자가 사용하는 도구에서 제공하는 이미지 압축 또는 최적화 도구보다는 항상 용량이 컸다.
업로드하는 부분에서부터 사용하는 부분까지 한단계씩 챙기면 꽤 많은 이미지 호스팅 트래픽을 줄일 수 있다.
알아서 하겠지 하고 지나갔다가 최근에 꽤 아프게 맞고서야 수습을 하고있다.