다양한 화면 밀도의 모바일 환경에서 효율적인 이미지 사용하기

안녕하세요. Platform Software 개발2팀의 이기범입니다. 모바일 기기들의 해상도가 올라감에 따라 화면 밀도가 높아지고 또한 원본 이미지의 퀄리티와 파일 용량도 높아지고 있습니다. Responsive Design을 위한 flexible 이미지라는 것이 이미지를 몇 벌 준비하고 CSS로 선택하는 방법에서 벗어나 이제 좀 더 잘할 필요가 있게 된 것입니다. 이번 포스팅을 통해 서비스에서 전송량과 반응 속도를 최적화하기 위한 이미지 준비와 제공 방안을 알려드리고자 합니다.

Responsive Design을 위한 이미지 딜리버리 솔루션은 진화하고 있습니다.

초기 모바일 서비스들은 웹서비스에서 사용되던 원본 이미지를 그대로 사용하고 브라우저에서 리사이즈 하여 사용하였습니다. 실제 출력 화면보다 큰 용량의 이미지를 사용하여, 트래픽이 크고 응답시간이 느렸던 문제가 있었습니다. 그러다가 모바일 서비스의 중요성이 증가하자 서버에서 단말군별/용도별로 여러 벌의 이미지 생성하여 사용하기 시작했습니다. 최근 대다수 모바일 서비스(Naver, Daum, Yahoo, hoppin, 11st, BestBuy, Groupon)에서 적용 중인 방식이며 트래픽과 응답속도의 향상이 있었습니다. 하지만 이 방식의 단점은 Back-end와 Front-end 개발자가 작업할 양이 많아집니다. 각 단말군별로 코드를 대응해야 하며 이미지 정책을 변경하려면 많은 재작업을 필요로 합니다. 최근에는 단말의 화면크기와 특성을 클라이언트가 서버에 전달하여, 서버에서 이미지를 실시간 생성하여 사용하는 방식이 사용되고 있습니다. RESS(Responsive Design with Server-Side component) 방식으로 최적의 이미지를 실시간으로 생성하므로 트래픽과 응답시간이 줄어듭니다. 각 단말군 별 이미지를 따로 관리할 필요가 없으며, 새로 추가되는 해상도나 정책 변경에도 유연하게 대처할 수 있습니다. Amazon, facebook, Google plus등 기술적으로 앞서가는 모바일 서비스들이 사용중입니다. 가장 적합한 방식이지만, 디스플레이의 발전에 따른 해상도의 증가에 대응한 최적화에는 부족한 부분이 있습니다. 이번 포스팅에서 소개할 RoL(Reduce or Lessen) 이미지 서버와 로더는 RESS 방식의 이미지 딜리버리 솔루션에 더하여 이미지 최적화를 구현하고 개발한 솔루션입니다.

이미지 최적화를 위해서는 이미지 미디어의 속성 그리고 단말기 화면의 속성을 이해해야 합니다. 

웹 서비스에서는 널리 사용하는 검증된 이미지 품질이 존재하며, 화면 밀도 DPR(Device Pixel Ratio) 에 관련된 대응은 일반적으로 하고 있지만 품질은 동일하게 사용하고 있습니다.대략적인 quality 는 85~90(JPEG기준)을 사용하고 있습니다. 평균적인 모니터/노트북 화면과 스마트폰 화면의 화질은 시청거리를 감안하면 1:2 정도입니다. 스마트폰의 화면은 더 가까이에서 이용되기 때문에 기존 PC 웹에서 표시되는 이미지 품질이 어느 정도 검증된 결과라고 가정하면 스마트폰에 표시되는 이미지의 품질은 이보다 낮아도 인지하기 어렵다는 것을 의미합니다. 이미지 파일의 특성상 품질과 파일 크기의 관계는 Linear하지 않으며, 낮은 해상도에서 높은 품질의 이미지보다 높은 해상도에서 낮은 품질의 이미지가 용량면에서 유리합니다. 하지만 낮은 품질의 이미지를 높은 품질의 이미지로 만들면 용량만 커지게 됩니다. 이런 부분은 이미지를 생성하는 서버에서 요청된 품질과 원본의 품질을 판단하여 생성하여야 합니다.

단말 사양과 화면 레이아웃에 따라 이미지 요건을 정하고 원본의 속성까지 감안하면 최적의 이미지를 준비할 수 있습니다.

클라이언트는 단말의 종류, 화면 밀도, 화면 레이아웃에 따라 적당한 이미지의 형식, 크기 및 품질을 계산하여 서버에 요청하고, 서버는 원본 이미지의 크기/품질에 따라 실제로 제공할 이미지의 형식, 크기 및 품질을 결정하게 됩니다.

RoL(Reduce or Lessen) 이미지 서버/로더

기술한 내용을 바탕으로 서버와 클라이언트 로더를 구성한 솔루션이 RoL이미지 서버/로더 입니다. RoL은 Reduce traffic and/or Lessen latency with best practices 의 약자로써 서비스에서 사용되는 이미지의 트래픽을 줄이고 응답속도를 빠르게 하는데 목적을 두고 있습니다. REST API형태의 서버 솔루션과 web(javascript), 안드로이드 로더를 개발하여 신규 및 기존 프로덕트에도 적용이 용이하게 개발되어 있습니다. 현재 T map과 OK Cashbag, Syrup의 쿠폰 이미지, benepia 모바일 서비스에 적용되어 있으며 회사 내 공용 플랫폼으로 다양한 서비스에 적용 예정입니다.

RoL 이미지 서버

RoL 이미지 서버는 이미지 조작 및 변환 기술, 이미지 딜리버리 기술(Cache and/or CDN), 이미지 관리 툴을 조합하여 다양한 서비스에서 사용할 수 있는 공용 컴포넌트 및 프레임웍이며, URL에 포함된 이미지의 크기와 품질에 따라 원본 이미지를 재생성하는 방식입니다.

그림1. 이미지 서버의 구조

RoL 이미지 로더

RoL 이미지 로더는 이미지 서버를 활용하여 RESS 및 기타 이미지의 효율적인 Fetch & Display에 대한 처리를 구현하는 클라이언트 라이브러리입니다.

  • 가상 좌표를 활용, 단말별 최적의 이미지의 크기와 품질을 결정하여 서버에 요청합니다.
  • 간단한 옵션 설정으로 서비스에 적합한 이미지 설정을 지원합니다.
    • DataSaving : 서비스 특성에 따른 품질 조절
    • webp : 지원단말을 판별하여 제공
    • Vertical Split : 세로로 긴 이미지를 분할하여 제공
    • LazyLoad, Sharding, Fallback..

예를 들어 DPR3의 스마트폰(갤럭시 S5)에서 css pixel 300×150 jpg 이미지 요청 시 아래와 같은 로직으로 이미지를 생성하여 반환하게 됩니다.

  • 서버에 요청되는 URL Scheme : ~/w900h450-,q50/rolPic.webp
  • DPR에 대응하여 사이즈를 요청 (900×450)
  • 품질 최적화 (q50)
  • 브라우저 환경에 따라 포멧 지원 (webp)
  • OK Cashbag 에 적용된 트래픽과 응답속도 절감 효과
    페이지 ScreenShot 적용 전 적용 후
    포인트박스 상세 Loading Time : 2.23s
    Image Size : 1.6MB
    Loading Time : 1.96s (12%)
    Image Size : 838KB (48%)
    상품 쿠폰   Loading Time : 2.60s
    Image Size : 2.7MB
    Loading Time : 0.86s (67%)
    Image Size : 231KB (91%)
    매장 상세 Loading Time : 8.04s
    Image Size : 13MB
    Loading Time : 1.3s (84%)
    Image Size : 539KB (99%)

RoL(Reduce or Lessen) 서버/로더의 이미지 최적화 설계 사례

  • 이미지 서버와 로더의 기능을 구축하고 품질에 대한 최적화는 아래와 같은 방법으로 설계하였습니다.
  • 화면 픽셀의 실제 크기를 고려하여 이미지의 품질 결정 방법 (기본값  결정)
    1. PC에서 제공하는 이미지의 기준 품질을 확인
    2. 시거리를 감안하여 PC와 화면 픽셀의 실질 크기가 대등하다고 생각되는 기준 스마트폰 결정
    3. 더 높은 밀도의 스마트폰에 대해 기준 스마트폰의 화면해상도에 맞춘 이미지를 제공하는 것을 가정하여 용량 확인
    4. 더 높은 밀도의 스마트폰에 대해 화면 해상도에 맞춘 이미지를 제공할 때 기준 이미지 용량과 유사한 용량이 되는 이미지의 품질 확인 (같은 용량이지만 품질은 높다. Compressive Image)
    5. 여러 이미지에 대해 3~4을 반복하여 이미지 품질의 평균값을 계산
  • 데이터 절감량을 높이거나 낮출 때의 품질 결정 방법
    1. 여러 가지 이미지에 대해 품질이 별로 나빠지지 않지만 데이터 절감을 할 수 있는 절감 품질/절감률을 결정
    2. 기준 절감률과 유사한 정도로 용량이 증감되는 이미지의 품질 확인
  • 위의 기준에 따라 RoL은 고밀도 이미지 처리 시 40%이상, 서비스 특성에 따른 data-saving 옵션과 webp format지원 등으로 15~35%의 이미지 전송 트래픽을 절감하고 있습니다.
  • Test Case
    원본이미지 RoL이미지 서버/로더를 활용
    고밀도 화면에 대응 DPR=2, quality=85, filesize = 102KB DPR=3, quality=50, filesize = 82KB
    전송량 최적화 DPR=2, quality=85, filesize = 99KB DPR=2, quality=75, filesize = 65KB

이미 Responsive Design 개념으로 개발되어 RESS방식으로 이미지를 사용하고 있는 사이트에서도 RoL의 최적화 로직을 사용하면 추가적으로 이미지 트래픽을 절감할 수 있습니다. 또한 RoL Analysis Bookmarklet을 개발하여 기존 사이트에 RoL을 적용하면 얻는 절감량을 예상할 수 있도록 했습니다.

  • T store의 모바일 페이지에 RoL Analysis Bookmarklet을 적용하여 트래픽을 측정한 결과(chrome yslow plugin 사용)
    적용 전
    RoL Analysis 분석 후
    filesize : 3030KB filesize : 704KB (reduce:76%)

지금까지 다양한 화면 밀도의 모바일 환경에서 효율적인 이미지를 사용하기 위한 설계방식과 최적화 과정, 그리고 RoL 이미지 서버/로더를 사용하여 향상된 여러 예제를 소개해 드렸습니다. 단순히 해상도에 대응하는 것 외에도 이미지의 특성을 이해하고 서비스와 디바이스에 적합한 이미지를 사용하는 것은 서비스의 퍼포먼스를 크게 향상시킬 수 있는 방법입니다.

감사합니다.

이기범 Platform SW개발2팀

SK플래닛 TechProduct 본부에서 Frontend개발 및 이미지서버/로더의 라이브러리 개발을 진행하고 있습니다.

공유하기

  • 김선호

    이미지 서버 구축을 고려하고 있었는데 좋은 글 감사합니다 ^^

    저희도 imagemagick을 이용해서 구현하려고 합니다.

    제가 걱정하는 부분은
    실시간으로 이미지를 생성하는 방법이긴 합니다만, 자주 쓰이는 리소스(포인트박스, 매장상세, 상품쿠폰)에 한해서 캐싱을 한 후 쓰이기 때문에 응답속도가 빠른것 아닌가요?

    불특정 다수가 조회하는 일반적인 게시글에 대해서 본 이미지 ROL 시스템을 적용했을 때 예상되는 문제점같은게 있을까요??
    제 생각에는 접속자 수에 따라 이미지서버를 몇개 더 두어야 하는게 아닌가 싶기도 하구요;;
    그런 점에서는 다수의 디바이스별 이미지 사이즈를 제작 후 스토리지에 저장하는게 더 싸게먹히지 않을까라는 생각이 듭니다.
    반응속도도 오히려 더 빠를 것 같구요…
    (까려고 하는게 아니고 저희가 이거를 도입했을때 예상되는 문제점을 나열해 본 것입니다 ^^;;)

    VR콘텐츠 부동산 관련 서비스이어서 게시글 하나당 50M가 넘기도 하거든요;;
    혹시 조언주실만한 내용이 있을까요??

    • 이기범

      안녕하세요. 작성자입니다.

      캐싱된 이미지의 hit율도 역시 중요한 요소입니다.
      최초 변환 생성시 이미지 변환 작업에 있어서 부하가 있는 면은 함께 고려해야 합니다.
      제시한 방향은 갈수록 다양해지는 환경에서 추가 비용없이 대응가능한 부분을 우선적으로 한 부분이며, 장기적으로 비용측면에서도 유리할 것으로 판단합니다.
      웹에서 이미지가 차지하는 트래픽이 가장 많은 부분이기 때문에 글 도입부에 작성한 내용처럼 여러 이미지를 제작하여 사용하는 방식도 사이트의 성능을 고려하여 개발 가능한 부분입니다.

      VR콘텐츠일 경우에는 접근 디바이스 특성상 이미지 품질이 굉장히 높아야 할것으로 느껴지는데요, 트래픽과 품질사이의 적절한 값을 도출하는 것이 중요할 것 같습니다.