개드리퍼건 어느 커뮤니티건 컴퓨터에 관심이 조금이라도 있는 사람은 webp 움짤이 뭔지 알것임.  

gif는 기본적으로는 압축도 안되고, 256색밖에 지원을 안해서 화질구지에 깨지기도 하고 용량도 미쳐날뛰는 포맷임. (요즘엔 이것도 마개조해서 다소 압축되기도 함. gifsicle같은 툴이 지원)

반면에 webp는 각 프레임이 지들이 만든 vp8로 압축되어 있으며, 기본적으로 모든 프레임이 모든 픽셀의 정보를 담아야하는 gif와 달리 해당 프레임에서 변화가 있는 부분만 담는다던지 하는 방식으로 추가적인 용량저하를 꾀하고 있음. 

결과적으로 모두들 알다시피 gif에 비해 상당한 용량 절감과 압도적인 화질을 가짐. 

그리고 구글이 만든 크로미움에서는 기본적으로 지원하고, 크로미움이 상당히 잘 만든 오픈소스라 이곳저곳에서 갖다쓴 덕에 크롬, 현재의 엣지, 기타 이러저러 크로미움 기반의 프로그램들에서도 잘 동작함. 

근데 디스코드같은데 프로그램에서는 왜 이 좋은 포맷을 아직도 지원을 안해서 움짤이 똥으로 나오나? 윈도우 기본 이미지 뷰어는 왜 아직도 webp를 지원 안하나? (기본뷰어를 누가써? 하는건 차치하고) 등등
이 좋은걸 기본적으로 지원안하는곳이 많은 이유가 뭘까?

원인은 구글의 행태에 있음. 

애초에 webp는 첨부터 구글이 노리고 만든건 아니었다. 유튜브가 커지면서 트래픽이 급증했고, 고성능 코덱의 필요성은 늘어가는 상황에서 유료코덱인 h264/265 는 사용하기 싫었던 구글은 vp8이라는 코덱을 만든 회사를 인수했음. 그러면서 그걸 기반으로 vp9코덱을 개발하게 되었음. 그리고 vp9코덱 영상이 담길 webm도 만들고. 실제로 지금 유튜브 내부 영상들을 뜯어보면 죄다 webm으로 되어있다. 

그리고 그 와중에 구글도 덩치가 크니까 온갖 서비스에서 이미지 보내는데도 트래픽을 사용하는데, 유튜브 영상뿐만 아니라 이 이미지들도 대체할겸, 기존의 낡은 이미지 포맷들도 대체가능하게끔 만들자 해서 만든게 vp8을 기반으로 한 webp임. 

제법 거창하게 썼지만 기존꺼를 모두 대체가능한 webp포맷을 만드는거 자체는 굉장히 간단함. 이미 지들이 갖고있는 vp8로 압축하기만 해도 jpeg, png 정지영상은 모두 정복되고, gif는 그걸 이어붙이기만 하면 되니까. 
실제로 아주 결과물이 훌륭해서, webp는 제대로 지원한다는 가정 하에 기존의 웹에서 많이 쓰이는 저 세 이미지포맷은 모두 충분히 대체할 정도의 성능을 가지게 됐음. 

근데 뭐가문제냐?

문제는 만들어 놓은 다음에 이 움짤을 실제로 보는법을 제대로 안 만들어놨다는거임. 
이 webp를 다른 사람들이 쉽게 다루게끔 하기 위해서 구글이 libwebp라는 라이브러리를 만들었거든. 근데 이새끼가 정지영상만 지원하고 animated(움짤)은 지원하지 않는다 이거야.

webp가 걍 이미지는 쉽게 디코딩되고 다른거로 변환도 되는데 움짤은 그게 안돼

이러면 무슨 일이 생기냐? 

기본적으로 webp를 지원하지 않는 크로미움이 아닌 친구들은 프로그램 개발자가 webp 움짤 구조 문서를 보고 수작업으로 디코더를 구현해야한다 이거야. 프로그램을 쪼금이라도 짜본 사람은 여기서 씨발! 할거임. 이런건 그냥 갖다쓰기만 해도 돼야지 뭔 시발 직접 짜고앉았느냐 이말이야. webp가 웹상 이미지 포맷 정복해서 안하면 병신소리 듣는거 아닐바에야 안하고 만다 할거야. 

이게 webp움짤이 아직도 지원 안되는곳이 많은 이유임. 

게다가 저 '직접 구현해야한다' 때문에 webp를 gif나 mp4등의 다른 포맷으로 바꿔주는 각종 사이트같은데서도 각기 다른 잘못된 결과물을 내뱉기도 함. 
제일 많이들 쓰는 ezgif - 디코더에 버그가 있는지 길이가 길고 용량이 큰 경우 종종 중간에 잘림
webp.to - 프레임 딜레이 파싱에 문제가 있는지 종종 움짤 재생속도가 빨라짐
또 어딘지 기억안나는데, 실제로 바뀐 프레임 데이터만 있어도 되는걸 구현 안해서 그런 webp는 막 움짤이 찌그러짐

아니 구글이 안만들면 인터넷의 친절하고 오지랖넓은 오픈소스 프로그래머들이 만들거 아님?? 이라고 할 수도 있는데, 이건 그런것마저 제대로된게 없음. 이 부분은 webp가 다소 타이밍이 운이 안좋았음. 
html5의 등장때문임. 

html5에서 새로 표준으로 추가된 video 태그는 웹브라우저가 기본적으로 동영상 디코딩을 지원하게끔 만들었음. 그 전에는 어도비 플래시 플레이어같은걸 박아서 동영상을 재생했었지. 많이들 기억할거야. 한마디로 웹사이트에서 동영상을 지원한다는건 상당히 번거로운 일이었음. 

근데 html5의 등장으로 <video src="파일"> 한줄로 그냥 동영상을 사용자들한테 틀수있게 된거야. 

근데 그게 webp움짤 지원 안되는거랑 무슨상관이냐면, 
이미 그전부터 대중적으로 사용되던 h264 코덱을 이용한 동영상이 저 video태그 한방에 모든 브라우저에서 그냥 재생되는데, 뭐하려 webp 쓰냐 이거야. h264 영상이 움짤용도에 있어서 webp따위는 우습게 찌바르는데. 

webp는 기본적으로 동영상이 아니고 이미지야. webp움짤이라 하더라도 근본은 이미지고, 그렇기때문에 기본적으로 움짤의 구현방식은 각 프레임의 데이터를 담고있어야함. 
근데 동영상은 아니거든. 일정 시간 간격으로 키프레임이라고 하는 기준 프레임을 제외하면, 어느부분이 어떻게 바뀌었나 하는걸 기준으로 만들어져있어. 
결과적으로 말하면 움짤 용도에 있어서도 webp는 죽었다깨나도 동영상을 따라갈수가 없어. 용량부분에서 압도적으로 쳐발리게 되어있음. 그냥 이미지와 동영상의 태생적 차이로 그럴수밖에 없는거야. 

이런 상황이라서 webp 뭐하러씀? 걍 동영상 쓰고말지 하는식이라 굳이 만들지조차 않는거야. 

결과적으로 webp움짤은 성능은 좋은데 다루기는 불편한 포맷이 돼서, 유저레벨이 아닌 개발레벨에선 존나 찬밥포맷이 됐어. 개드립에서도 webp움짤을 동영상으로 변환 안하는 이유중 하나가 아마 이거때문일거야.
1. gif처럼 용량이 큰거도 아니고 개수가 많은것도 아니라 사이트에 부담되는 수준은 아님
2. libwebp에서 지원하면 당연히 mp4로 변환 하겠지만 디코더를 직접 만들라고?? 굳이? 다른 시급한일 하고 말지. 
3. 요새 브라우저 대세는 어차피 크로미움이라 webp 움짤 대부분 잘보는데 그냥 뱉어~

그런데 웹상 유저들한테는 이 webp 움짤의 이미지가 엄청 좋아. 위에서 언급한거처럼 기존 정지영상과 gif 모두 대체 가능할정도로 성능은 좋으니까. 위에 디코더를 직접 구현해야하는 그런건 일반 유저들 눈에는 안보이는 부분이라 알 필요도 없는 것이고. 

그래서 그런 유저들 중심으로 구글을 제외한 웹에서도 계속 명맥을 이어오고 있고 '이거 왜 지원 안함?' 소리가 계속 나오고 있는거임. 
그리고 구글이 libwebp에서 움짤을 지원하지 않는 이상, 앞으로도 지원 안하는곳이 추가적으로 지원을 늘릴 가능성은 매우 낮음.

아 물론 이게 애플 레벨에서조차 귀찮을 수준은 절대 아니고 먼지수준이나 될까하는 수준임. 
그니까 위의 단점에도 불구하고 아이폰에서 webp움짤이 제대로 안되는건 그냥 구글꺼니까 안만들고 유기했을 가능성이 100%라고 생각함 ㅋㅋ 
근데 그렇다 하더라도 libwebp에서 지원하면 제대로 지원할거야. 코드 몇줄조차 필요하지 않을테니까. 

그니까 아이폰에서 안나오는 이유는 애플 구글 둘 다 방구한번 뀌는거에 불과한 수준의 작업을 유기하고있기 때문임. 둘중 하나라도 하면 되는데..

3줄요약
1. webp 움짤 존나 좋은데 아직도 지원 안하는새끼들은 뭐냐?
2. webp가 존나 잘만든 고성능 포맷은 맞는데
3. 구글이 만들어놓고 지원 안해주고 유기한거임
3-1. 아 물론 아이폰은 애플도 지들이 안하는거 맞음 ㅋㅋㅋ