GIF는 애니메이션용으로 만든 형식이 아니에요
짧게 반복되는 움직이는 그림을 흔히 '움짤'이라고 부르고, 그 파일은 대개 GIF예요. 그런데 GIF를 정의한 CompuServe의 GIF89a 규격(1990년 7월 31일 판)은 부록에서 이 형식이 애니메이션을 위한 바탕으로 의도된 것은 아니며 제한적으로만 가능하다고 적고 있어요. 원래는 여러 장의 그림을 순서대로 전송하는 형식이었고, 그림마다 다음 그림까지 기다릴 시간을 붙일 수 있었던 것이 애니메이션으로 쓰인 거예요.
지금은 움직이는 그림을 담을 수 있는 형식이 여럿이에요. 웹에서 흔히 고르는 후보는 GIF, MP4나 WebM 같은 영상, 그리고 애니메이션 WebP예요. 아래 표는 각 형식의 공식 규격과 MDN 문서에서 확인한 성질을 정리한 거예요. 영상 형식은 담기는 코덱에 따라 성질이 달라져서, 표에는 이 글의 측정에 쓴 H.264와 VP9 기준으로 확인된 것만 적었어요.
| 성질 | GIF | 애니메이션 WebP | 영상 (video 요소로 재생) |
|---|---|---|---|
| 한 장면의 색 | 색상표에서 고른 최대 256색 | 손실 압축은 YUV 4:2:0, 무손실은 채널당 8비트 ARGB | 코덱이 정해요 |
| 투명 | 색상표의 한 칸을 '그리지 않음'으로 지정 (켜짐·꺼짐 두 가지) | 픽셀마다 0~255 단계의 알파 | 이번에 만든 H.264 파일에는 없었어요 |
| 장면마다의 시간 | 100분의 1초 단위 | 1밀리초 단위 | 영상의 프레임 속도 |
| 반복 | 규격 본문에 없고, 응용 확장 블록으로 표시 | 반복 횟수 칸이 있고 0은 무한 | loop 속성을 붙이면 처음으로 돌아가요 |
| 소리 | 없어요 | 없어요 | 담을 수 있어요 (소리가 있으면 자동 재생이 막혀요) |
WebP의 시간과 투명, 반복은 RFC 9649에서, 영상의 반복과 자동 재생은 MDN의 video 요소 문서에서 확인했어요. RFC 9649는 0밀리초나 10밀리초 이하의 짧은 시간을 어떻게 해석할지는 구현이 정하고, 많은 도구와 브라우저가 GIF처럼 최소 시간을 둔다고 덧붙여요. MDN은 소리가 있는 영상의 자동 재생을 요즘 브라우저가 막는다고 설명해요. 움짤처럼 저절로 반복되게 하려면 소리를 빼거나 음소거 속성을 붙여야 한다는 뜻이에요.
256색이 실제로 뜻하는 것
GIF의 색은 픽셀마다 직접 적는 대신 색상표의 칸 번호로 적어요. 규격은 파일 전체에 쓰는 전역 색상표 하나와, 그림마다 따로 붙이는 지역 색상표를 둘 다 허용하고, 같은 표로 그릴 수 있다면 전역 표 하나만 쓰라고 권해요. 이 사이트의 GIF 인코더 코드는 바로 그 방식을 따라요. 모든 프레임의 색을 함께 세어 색상표 하나를 만들고, 첫 장면부터 끝 장면까지 그 표만 써요. 영상 한 편 전체가 256칸 안에서 색을 나눠 써야 하는 셈이에요.
실제로는 칸이 하나 더 줄어요. 인코더는 앞 장면과 달라진 곳만 다시 그리는 최적화를 쓰는데, 바뀌지 않은 픽셀을 '그리지 않음'으로 표시하려고 색상표 한 칸을 비워 둬요. 그래서 색 수를 256으로 두어도 보이는 색은 255개까지예요. 색을 세는 단계에서는 빨강·초록·파랑을 각각 32단계로 묶어 세기 때문에, 원래 색이 정확히 남지 않을 수 있어요. 여섯 가지 색만 쓴 시험 화면을 넣었더니 바탕의 회색 (236, 238, 242)이 (239, 239, 247)로, 윗부분 띠의 파랑 (52, 101, 164)이 (49, 99, 165)로 저장됐어요. 눈으로는 구별하기 어렵지만, 브랜드 색처럼 값이 정확해야 하는 그림에는 알아 둘 만한 차이예요.
색이 많은 장면에서는 차이가 훨씬 커요. 하늘처럼 번지는 바탕에 잔잡음을 섞은 카메라풍 시험 클립은 원본 50장에 서로 다른 색이 360,696개 들어 있었는데, GIF로 저장하고 다시 읽어 보니 250개만 남았어요. MDN 문서도 색이 풍부한 그림을 GIF로 바꾸면 디더링이 거슬리게 보일 수 있다고 적고 있어요. 하늘이나 피부처럼 부드러운 색 변화가 많은 장면일수록 영상이나 WebP 쪽이 유리한 이유예요.
같은 클립을 다섯 가지로 저장해 보니
형식에 따라 용량이 얼마나 달라지는지 보려고 가로 480·세로 270, 초당 10장으로 5초인 시험 클립 두 개를 만들었어요. 하나는 회색 바탕에 글자 줄이 하나씩 나타나고 마우스 화살표가 움직이는 화면 녹화풍 클립이고, 다른 하나는 앞에서 말한 카메라풍 클립이에요. GIF는 이 사이트 인코더의 기본 설정(256색, 부드러운 색 표현 끔)으로, 나머지는 FFmpeg 9.0.1로 저장했어요. H.264는 crf 23, VP9는 crf 32, 손실 WebP는 품질 75였어요. 괄호 안은 원본과 비교한 PSNR이에요. 숫자가 클수록 원본에 가깝고, 무손실은 원본과 똑같다는 뜻이에요.
| 형식 | 화면 녹화풍 | 카메라풍 |
|---|---|---|
| GIF (이 사이트 인코더) | 19,986바이트 (41.0dB) | 3,530,656바이트 (35.2dB) |
| MP4 · H.264 | 8,392바이트 (40.7dB) | 701,685바이트 (35.4dB) |
| WebM · VP9 | 5,283바이트 (40.5dB) | 102,076바이트 (33.8dB) |
| WebP 손실 | 31,280바이트 (39.6dB) | 355,982바이트 (33.9dB) |
| WebP 무손실 | 7,186바이트 (무손실) | 5,946,450바이트 (무손실) |
화면 녹화풍 클립에서는 다섯 형식 모두 수십 킬로바이트 안에 들었어요. 색이 몇 개 안 되고 바뀌는 곳이 좁아서 GIF의 '바뀐 곳만 다시 그리기'가 잘 통했기 때문이에요. 이런 그림이라면 어디서나 열리는 GIF를 고르는 손해가 크지 않아요. 무손실 WebP가 GIF보다 작으면서 색까지 정확하게 남긴 것도 눈에 띄어요.
카메라풍 클립에서는 순위가 뚜렷하게 갈렸어요. 같은 수준의 PSNR에서 H.264 MP4는 GIF의 약 5분의 1이었고, VP9 WebM은 화질을 조금 더 내준 대신 GIF의 3%에 조금 못 미쳤어요. 무손실 WebP는 오히려 GIF보다 커서, 잡음 많은 장면에서는 '무손실'이 답이 아니라는 것도 보여 줬어요. 부드러운 색 표현을 켠 GIF는 4,072,413바이트로 더 커졌어요. 이 숫자는 인공적으로 만든 두 클립의 결과이고, 설정 하나만 바꿔도 크게 달라질 수 있어요. 순위를 보는 참고로만 써 주세요.
투명한 배경이 필요할 때
투명은 형식 차이가 가장 극명한 부분이에요. 가장자리를 여섯 픽셀에 걸쳐 부드럽게 흐린 동그란 스티커가 위아래로 움직이는 240×240, 20장짜리 시험 클립을 만들어 확인했어요. 한 장면마다 반투명한 가장자리 픽셀이 2,620개 들어 있어요.
| 형식 | 용량 | 반투명 가장자리 (장면당) | 투명한 바탕 |
|---|---|---|---|
| GIF (이 사이트 인코더) | 19,188바이트 | 0개 | 남아요 |
| WebP 손실 | 37,350바이트 | 2,620개 | 남아요 |
| WebP 무손실 | 41,654바이트 | 2,620개 | 남아요 |
| MP4 · H.264 (yuv420p) | 2,424바이트 | 없음 | 사라지고 주황 바탕이 보여요 |
GIF 규격의 투명은 '이 칸 번호가 나오면 화면을 건드리지 않는다'는 약속 하나라서 반쯤 투명한 상태가 없어요. 이 사이트 인코더는 알파 값이 128보다 작으면 투명, 크면 불투명으로 나누기 때문에 흐린 가장자리가 모두 계단처럼 잘려요. 어두운 배경에 올리면 테두리가 거칠게 보이는 까닭이에요. WebP는 픽셀마다 알파를 따로 담아서 가장자리가 그대로 남았어요. 이번 H.264 파일은 알파 칸이 없는 yuv420p라 투명했던 곳이 원래 아래에 깔린 색으로 채워졌어요. 첫 장면의 왼쪽 위 픽셀을 읽어 보니 (254, 119, 79)에 불투명이었어요.
사이트 도구별로도 투명의 운명이 달라요. 사진 GIF 만들기는 사진을 그리기 전에 칸을 흰색, 검정, 회색 가운데 고른 배경색으로 먼저 칠해서 투명한 PNG를 넣어도 결과에는 투명이 남지 않아요. 영상 GIF 변환은 영상 화면을 빈 캔버스에 옮겨 그린 뒤 그 픽셀을 써요. 바탕을 따로 칠하는 단계가 없어서, 브라우저가 투명하게 그려 주는 영상이라면 알파 128을 기준으로 켜짐·꺼짐이 나뉘고, 이번 MP4처럼 알파가 없는 영상은 그대로 불투명하게 나와요. GIF 용량 줄이기는 원본 GIF의 투명을 켜짐·꺼짐 그대로 지키지만, 투명이 있으면 바뀐 곳만 다시 그리는 최적화를 쓰지 않아서 덜 줄어들 수 있어요.
이 사이트 GIF 도구가 하는 일과 못 하는 일
세 도구의 코드를 읽어 보면 결과는 언제나 GIF 한 가지예요. 만든 파일은 image/gif 형식으로 이 기기에서 바로 내려받고, MP4나 WebM, WebP로 저장하는 기능은 없어요. 그러니 위 표의 영상이나 WebP를 만들려면 다른 프로그램이 필요해요. 도구마다 받는 입력과 고를 수 있는 값은 이래요.
- 영상 GIF 변환: 브라우저가 재생할 수 있는 영상이면 무엇이든 받아요. 구간은 60초까지, 초당 장수는 5·8·10·12·15·20 가운데, 가로는 영상 그대로 또는 720px부터 240px까지 골라요. 소리는 GIF에 담기지 않아요.
- 사진 GIF 만들기: 브라우저가 여는 사진을 100장까지 받고, 한 장이 보이는 시간을 0.2초에서 3초 사이에서 골라요. '계속 반복해서 재생'을 끄면 반복 표시를 아예 쓰지 않아서 한 번만 재생돼요.
- GIF 용량 줄이기: GIF만 받아요. 원본에 적힌 반복 횟수를 그대로 옮겨 쓰고, 가로 크기·장수·색 수·미세한 변화 무시를 골라 다시 만들어요.
세 도구가 함께 쓰는 인코더는 장면 시간을 100분의 1초 단위로 바꾸면서 2(0.02초)보다 짧게는 적지 않아요. 반복은 넷스케이프 응용 확장 블록에 '무한'으로 적어요. GIF89a 규격 본문은 응용 확장의 틀만 정하고 반복 횟수 자체는 정하지 않으니, 반복은 규격 바깥의 관례에 기대는 셈이에요.
어떤 형식으로 올릴지 고르는 순서
정답은 올릴 곳과 그림의 성격에 달려 있어요. 아래 순서대로 질문에 답하면 대부분 한 형식으로 좁혀져요.
- 올릴 곳이 받는 형식부터 확인해요. 메신저 채팅방, 커뮤니티 게시판, 문서 편집기마다 받는 파일이 달라요. GIF만 움직이게 보여 주는 곳이라면 고민할 것 없이 GIF예요.
- 소리가 필요한지 봐요. 소리가 있어야 하면 영상밖에 답이 없어요. 대신 자동으로 소리와 함께 재생되지는 않는다는 점을 감안해요.
- 투명한 배경이 필요한지 봐요. 흐린 가장자리까지 살려야 하면 WebP를, 테두리가 또렷한 그림이면 GIF로도 충분해요. 이번에 만든 H.264 MP4로는 투명이 남지 않았어요.
- 그림의 성격을 봐요. 화면 녹화, 글자, 단순한 그림은 GIF로도 작게 나와요. 사람 얼굴이나 풍경처럼 색이 번지는 장면은 영상이 몇 배에서 수십 배 작아요.
- 웹페이지에 직접 넣는다면 대체 형식을 준비해요. MDN은 video 요소 안에 여러 source를 넣어 브라우저가 처음으로 이해하는 것을 쓰게 하라고 안내해요. 영상 하나만 두지 말고 형식을 두 가지쯤 준비해 두면 안전해요.
- GIF로 정했다면 마지막에 줄여요. 영상에서 바로 GIF로 만들 때 크기와 장수를 먼저 정하고, 이미 있는 GIF라면 용량 줄이기로 목표 용량을 맞춰요.
팁 원본은 늘 가장 좋은 형식으로 따로 남겨 두세요. 휴대폰으로 찍은 영상 원본이 있으면 나중에 GIF든 WebP든 다시 만들 수 있지만, 256색으로 줄어든 GIF에서 잃은 색은 어떤 형식으로 바꿔도 되돌아오지 않아요.