문제분석¶
이 순간에도 셀 수 없이 많은 이미지가 끊임없이 생산되고 소비된다. 대표적인 문제점들과 개선포인트를 알아보자.
배치 = 실패¶
많은 이미지들이 백엔드의 배치 시스템으로 생산된다.
작업 목록을 작성한다.
대상 서버들을 산정한다.
프로세스를 수행한다.
………..기다린다……..
…기도한다…기도한다…기도한다…기도한다…기도한다
완료
메시지를 보며 신의 존재를 느낀다.

레거시
는 다소 부정적인 의미를 가지는데 대충 <구축해서 돌고 있지만, 건드릴 수 없는 시스템>
정도로 이해할 수 있다.
최악은 배치를 관리할 목적으로 만들어진 DB(데이터 베이스) 기반 시스템이다.
DB를 넣는 순간 주객이 전도되어 DB 관리가 첫 번째 미션이 된다.

기획이 바뀌는 순간 모든 배치는 수습해야할 대상이 되버리고 긴 겨울이 시작된다.
리스크는 민첩성의 부족¶
서비스는 어디로 튈지 모르는 생물이다. 이미 고정된 상태로 저장된 셀 수 없이 많은 이미지에 어떻게 민첩성을 부여해야 할까?
모든 상품 이미지에 대해 신규 썸네일 해상도를 지원하는데 얼마나 소요될까요?
최신 아이폰 해상도에 맞추어 모든 상품기술서를 변경하는데 얼마나 소요될까요?
오늘 밤 신규 상품이 유입되는데 내일 아침 서비스에 노출할 수 있을까요?
바뀐 로고를 대표이미지에 노출할 수 있을까요?

파편화¶
서비스가 성장하면서 다양한 이유로 시스템 및 저장공간의 파편화가 발생한다.
기술부채 상환실패
예상치 못한 성장
조직/회사 통합
비용

이미지 서비스가 파편화되면 서비스 민첩성과 일관성이 떨어질뿐만 개발 복잡도가 기하급수적으로 상승한다.
저장비용¶
당연히 저장비용은 공짜가 아니다.
원본 이미지
리사이즈 1,2,3,4,5,6…
썸네일, 검색용, 장바구니,…
파트너 제휴, SNS 노출,….
기획1, 기획2, 기획3….

저장된 이미지에 대해서는 영원히 비용을 지출하게된다. 소비패턴이 점점 짧아지는 환경에서 지나친 낭비가 아닐 수 없다.
전송 최적화¶
CDN(Contents Delivery Network)은 가장 합리적인 전송 시스템이고 대부분 용량에 기반하여 과금된다. 최적화는 다음 3가지를 만족해야 한다.
전송비용(=용량)
화질
사용자 경험성

이미지 서비스의 전송 최적화는 스토리지로부터 시작하여 사용자에게 전달되기까지의 과정을 의미한다.
개발된지 30년이 넘은 JPEG
이 아직도 현역이라는 점은 곱씹어 볼만하다.