썸네일 이미지 용량 최적화를 고민해보았다

최근 Next.js를 건드려보며 Image 컴포넌트에 적절하게 리사이징 해주는 기능이 있는 것을 보고 다른 서비스에도 이런 리사이징이 있으면 좋겠다는 생각을 했다.

문제는 프론트엔드 서버 내부에 이미지가 저장되어 있어서 적절히 리사이징 해줄 수 있는 것이 아니고, 프런트가 따로 있고 이미지는 AWS S3에서 받아오는 방식이라는 것이다. 즉 S3에 미리 리사이징 이미지를 저장해둬야 했다.

이미지를 줄여야 한다.

서비스에는 크게 2가지 종류의 이미지가 있었다. 수동으로 S3에 직접 업로드하는 샘플 이미지와, 각 개체마다 서비스를 통해 S3으로 업로드하는 개별 이미지였다.

우선 샘플 이미지를 생각했기에 가장 먼저 생각한 방법은, S3에 이미지가 업로드되었을 때 람다등을 통해서 자동으로 이미지 리사이징을 진행하는 것이었다.

이때의 장점은 아래가 있을 듯했다.

• 일괄적으로 샘플 이미지와 개별 이미지에 적용할 수 있는 방법이었다.
• 원래처럼 S3으로 업로드만 해주면 되기에 서비스에 코드 변경이 필요 없었다.
• 서버에서 이미지 리사이징을 하지 않기에 서버에 부담이 적다.

단점은 이런 것들이 생각났다.

• 람다를 실행시키는 비용이 생길 수 있다.

 

다른 방법으로는 서버에서 업로드 시에 이미지를 리사이징 하는 방법이었다.

장점과 단점은 위의 반대로, 개별 이미지에만 적용시킬 수 있는 방법이었고, 서버에 부하가 갈 수 있었다.

 

하지만 결국 선택한 건 서버를 이용한 방법이었는데, 이유로는 당장 서버 사용량이 크지 않고 테스트해 보아도 리사이징에 큰 시간이 걸리지 않았고, 다음에 샘플 이미지에 대해서는 따로 람다를 이용한 방법으로 시도하면서 2가지 방법을 모두 해보고 싶었기 때문이다. 또한 Pillow 라이브러리도 조금 살펴보고 싶었다.

 

이미지를 얼마나 줄여야 할까.

리사이징 방법은 정했다. 그렇다면 리사이징은 어떤 크기로 해야 할까? 우선 다양한 크기로 여러 개로 리사이징하는 방법도 있을 것이다. 리엑트의 Image에서는 그때그때 크기를 조절할 수 있었지만 이번에는 미리 정해두어야 했다(물론 AWS로 이미지를 받으면서도 동적으로 하는 방법이 있을 것이다). 일단 썸네일 이미지이기에 어떤 사이즈로 보일 지를 고민해야 하는데, 다행히도 대부분 모바일로의 이미지만 서빙하기에 커봤자 모바일의 width인 360px정도로 충분할 것으로 보였다.

 

원래 이미지들은 대략 1000px대의 width를 가지고 있었고, 이를 300px로 줄임으로써 대략 90%가량의 용량 이득을 볼 수 있었는데, 한 변의 길이가 2배 줄어들면 크기는 4배 줄어드는 효과로 인함이었다. 이렇게 해서 나오는 용량은 대략 15kb 정도를 전후해서 나오는 듯했고 300px 정도로 리사이즈 해도 될 것으로 보였다.

 

다만 PC기준으로 이후에 이미지를 서빙한다면 대략 600px width까지도 필요할 듯하여 600px로 변경했다. 이유는 600px로 변환해도 용량이 40kb로 충분히 작았기 때문에, 좀 더 나은 해상도와 이후를 생각하여 조금 더 크게 크기를 잡았다.

 

이렇게 이미지를 리사이징만 하면 끝일까? 무언가 잊고 있는 듯했다.

 

포맷

그렇다 포맷이다. jpg이니 png이니 gif이니 뭔가 생소하면서도 들어본 개념이다. 언젠가 포맷별로도 차이가 있는 것을 본 적 있었고 최근에 webp라는 확장자를 많이 본 것이 기억났다. 그래서 바로 포맷을 비교해 보았다.

 

우선 원래 기존에 자주 쓰이는 jpg와 png 등으로 원래는 저장되어 있었다. 이를 webp로 서빙하면 조금 더 용량을 아낄 수 있을 듯했다. webp는 과거에는 브라우저 호환성 문제가 있었지만 현재는 대부분의 웹브라우저에서 지원하고 있어 인터넷 익스플로러가 아닌 이상 문제가 없을 듯했다. 과감히 IE는 버리기로 결정했다.

다만 webp 움짤등의 경우에는 애플 개열 기기에서 랙이 걸리는 문제가 있는 듯했으나 썸네일은 모두 정적이미지라 상관이 없을 듯했다.

 

바로 webp로의 전환을 시도했고 추가적으로 10% 정도의 용량 절약을 할 수 있는 것으로 보였다.

잠깐, 그렇다면 webp보다 좋은 포맷은 없을까? 물론 있다. webp는 구글에서 2010년에 만든 포맷인데 시대의 흐름에 따라서 최근에 나온 HEIF나 AVIF 등은 webp보다 좋은 효율을 보이는 듯했다. 다만 이들은 호환성에서 아직 부족한 부분이 많았고, 이에 webp가 조금 더 적절해 보였다.

 

이로써 얻어낸 것들

우선 더 적은 용량으로 S3의 저장 비용을 줄일 수 있었다.

이뿐만 아니라 작은 이미지=더 빠른 속도로 적당히 화질을 타협하는 수준에서 속도를 크게 올릴 수 있었고, 아주 무섭기로 유명한 AWS의 네트워크 비용도 줄일 수 있을 것으로 보인다.

 

다음에 해볼 것들

이번에 해보지 못했던 람다를 이용한 이미지 리사이징과, AWS에 비해 네트워크 비용이 저렴한 것으로 유명한 클라우드 플레어의 저장소를 사용해보고 싶다. 다만 한국의 망사용료를 생각해 보았을 때... 한국에서도 저렴한지는 이후에 확인해 보아야겠다.