당신의 이미지는 어디로? (Feat. Base64)

365.48km·2023년 10월 11일
0
post-thumbnail

내용

기존의 했던 방식은 Base64로 변환처리를 하면 당연히 압축으로 인한 데이터 손실이 있다고 판단됐기 때문에 formData 형식에 맞게 요청을 하고 이미지를 S3의 bucket과 같은 저장소로 보내거나

Firebase와 같은 클라우드 데이터베이스의 경우 Firebase storage 와 같은 bucket 저장소를 사용했다. 물론 이는 중요했고, 비교적 용량이 큰 이미지들 예를 들어서 상세 페이지에 필요한 이미지들과 같은 것들은 변환 처리를 하게 되면 압축 과정에서 잃게 되는 것들이 많고 해상도가 깨질 수 도 있다. 그리고 가장 중요한 것은 Base64 의 변환 방식은 인코딩하기 위해서는 제한된 용량이 있었다. 그렇기에 결국엔 압축을 위해서 용량의 한계도 있는 것을 이것을 과연 써야 하나? 그렇기에 많은 사람들이 Base64의 인코딩 방식에 회의적인 시각이 보였다.

과연 그럴까?

사실 모든 기능들엔 이유가 있음을 확인하였다. 분명한것은 Base64는 단점이 극단적으로 부각이 된다. 데이터의 용량 , CSS를 통한 이미지 랜더링 저하, 캐시기능 저하 하지만 이것은 어디까지나 큰 용량의 이미지라면 그럴 수있다.

반면에 썸네일 이나 아이콘과 같은 작은 저용량의 이미지들을 필요로 하는 DOM에 대해서는 과연 고용량의 이미지가 필요할까? 작은 용량에 대해서 반드시 그럴 필요는 없고 변환을 통해서 DB에 바로 저장을 하는 것이 더 편하고 효율적이라는 것을 깨달았다.

느낀점

어느 기술이든 과유불급일 수 있다. 마치 많은 사람들이 Base64는 절대 쓰면 안되는 것 처럼 표현되어 있는데 너무 과하게 쓰면 그렇겠지만 장단점을 잘 파악하고 적재적소에 잘 사용한다면 base64 인코딩도 그렇게 나쁜 것만은 아니다.

Base64는 절대 쓰면 안되는 것 처럼 표현되어 있지만 너무 과하게 쓰면 그렇겠지만 장단점을 잘 파악하고 적재적소에 잘 사용한다면 base64 인코딩도 그렇게 나쁜 것만은 아니다.

profile
이게 마즐까?

0개의 댓글