GIF 용량 줄이기

움짤을 화질 단계마다 실제로 줄여 보고 고르는 도구입니다

GIF 용량 줄이기는 움직이는 GIF를 다시 써서 파일을 작게 만드는 도구입니다. 무손실부터 최대까지 압축 강도 다섯 단계를 모두 실제로 만들어 보고, 단계마다 결과 크기를 막대로 보여 줍니다. 예를 들어 영상에서 만든 예시 움짤(360 × 240, 32프레임, 1.70 MB)은 '보통' 단계에서 947 KB(−44.1%)가 되었고, 화면 녹화 예시(400 KB)는 화소를 하나도 바꾸지 않는 '무손실' 단계만으로 87 KB(−78.4%)가 되었습니다.

원본과 결과는 한 화면에서 나누는 선을 끌어 같은 자리를 비교하고, 멈춘 뒤 프레임 하나씩 넘겨 볼 수 있습니다. 아래 프레임 지도는 프레임마다 몇 바이트를 쓰는지 보여 주어 어느 장면이 무거운지 알려 줍니다. 목표 용량을 고르면 그 안에 드는 가장 가벼운 단계를 고르고, 그래도 넘으면 가로 크기를 줄여 맞춥니다. GIF는 서버로 보내지 않고 이 브라우저 안에서만 처리합니다.

이럴 때 씁니다

• 올릴 수 있는 용량이 정해진 곳에 낼 때: GitHub 문서에 따르면 이슈·풀 리퀘스트 댓글에 붙이는 이미지와 GIF는 10MB까지입니다. 이슈에 붙일 화면 녹화가 이보다 크면 목표 용량을 10 MB로 고르면 됩니다. 메신저·게시판·메일도 저마다 첨부 한도가 있으니, 올리는 곳의 안내를 확인하고 그보다 조금 작게 맞춥니다.
• 블로그·쇼핑몰 상세 페이지가 느릴 때: 상품 사용 장면처럼 영상에서 만든 움짤은 한 장에 몇 MB씩 되기 쉽고, 페이지에 여러 장이 있으면 휴대폰에서 늦게 열립니다. 화질을 거의 그대로 두는 '가볍게'·'보통' 단계만으로도 크기가 크게 줄어듭니다.
• 화면 녹화 GIF를 문서에 넣을 때: 설명서·사용법 문서에 넣는 화면 녹화는 대부분의 화면이 멈춰 있고 일부만 움직입니다. 이런 GIF는 바뀐 부분만 다시 쓰는 '무손실' 단계에서 화질을 잃지 않고 크게 줄어듭니다.
• 이미 받은 움짤을 다시 올릴 때: 여러 번 저장된 GIF는 프레임마다 전체 화면과 색표를 다시 담고 있는 경우가 많습니다. 원본보다 커지면 이 도구는 원본을 그대로 주므로, 손해 없이 한 번 확인해 볼 수 있습니다.

쓰는 법

1. GIF를 작업면에 놓거나 'GIF 고르기'를 누릅니다. 복사한 GIF는 Ctrl+V로 붙여 넣어도 됩니다. GIF 한 개, 50 MB까지 엽니다.
2. 열자마자 '보통' 단계로 결과를 만들고, 나머지 네 단계도 차례로 만들어 압축 강도 막대에 실제 크기를 채웁니다. 원하는 단계를 누르면 그 결과로 바뀝니다.
3. 올릴 곳의 한도가 있으면 목표 용량(1~15 MB 또는 직접)을 고릅니다. 그 안에 드는 가장 가벼운 단계가 골라지고, '강하게'로도 넘으면 가로 크기를 줄여 맞춥니다.
4. 필요하면 가로 크기(원본·75%·50%·직접)와 프레임(모두·2~4장 중 1장)을 바꿉니다. '직접 고르기'를 열면 색 개수와 손실 정도를 따로 정할 수 있습니다.
5. 무대에서 나누는 선을 끌어 원본과 결과를 비교합니다. '멈춤'을 누르거나 프레임 지도를 누르면 그 프레임에서 멈추고, 앞·뒤 단추나 방향키로 한 장씩 넘깁니다.
6. 'GIF 저장'을 누릅니다. 파일 이름 끝에 크기가 붙습니다(예: 움짤-947kb.gif).

압축 강도 다섯 단계는 이렇게 다릅니다

단계가 올라갈수록 원본과 다른 화소를 더 많이 허용합니다. 아래 표의 크기는 두 예시를 이 도구로 실제로 줄여 잰 값이고, PSNR은 원본과 결과의 화소 차이를 데시벨로 나타낸 값입니다. 높을수록 원본에 가깝습니다. 영상 움짤 예시에서는 35 dB 안팎인 '보통'까지는 2배로 확대해 나란히 놓아도 차이가 잘 보이지 않았고, 30 dB 아래인 '강하게'·'최대'에서는 흰 배경에 잔점이 생기고 사과·배 같은 매끈한 면이 거칠어졌습니다. 같은 숫자라도 GIF마다 보이는 정도가 다르니 기준으로만 쓰세요.

• 영상 움짤은 무손실로 줄지 않았습니다: 이 예시는 화면이 천천히 확대되고 화소마다 잡음이 있어 모든 프레임의 모든 화소가 바뀝니다. 바뀐 화소만 다시 쓸 곳이 없으니 무손실 결과가 원본보다 작아지지 않았고, 이 도구는 원본을 그대로 줍니다.
• 화면 녹화는 무손실이 대부분을 했습니다: 원본은 프레임마다 전체 화면을 다시 담고 있었지만, 실제로 바뀐 곳은 숫자·그래프·커서뿐입니다. 그 부분만 쓰자 −78.4%가 되었고, 손실 단계로 더 줄여도 몇 KB 차이입니다.
• '강하게'부터는 색이 줄어듭니다: 128색·64색으로 줄이면 하늘이나 어두운 천처럼 색이 이어지는 면에 계단(띠)이 생기고, 손실 LZW의 가로 줄무늬가 보이기 시작합니다. 그래서 막대에 빗금을 쳐 구분하고, 목표 용량을 맞출 때도 '최대'는 자동으로 고르지 않습니다.

화질을 잃지 않고 줄어드는 이유

GIF 사양(GIF89a)은 프레임마다 이미지 설명 블록에 화면 기준 왼쪽·위 위치와 가로·세로 크기를 적게 합니다. 그래서 프레임 하나가 화면 전체가 아니라 그 안의 작은 사각형일 수 있습니다. 또 프레임마다 투명 번호를 하나 정할 수 있고, 사양에 따르면 그 번호가 나온 화소는 화면을 바꾸지 않으므로 앞 장면이 그대로 보입니다. 이 도구는 이 두 가지를 써서 화소를 바꾸지 않고 크기를 줄입니다.

1. 바뀐 곳만 감싼 사각형: 앞 프레임과 달라진 화소를 모두 감싸는 가장 작은 사각형만 저장합니다. 커서만 움직이는 화면 녹화라면 프레임 하나가 손톱만 한 사각형이 됩니다.
2. 사각형 안의 같은 화소는 투명 번호로: 사각형 안에서도 바뀌지 않은 화소는 투명 번호로 비웁니다. 같은 번호가 길게 이어지면 LZW 압축이 아주 잘 됩니다. 다만 흩어진 화소가 조금씩 바뀌는 장면은 오히려 원래 색을 쓰는 편이 작을 때가 있어, 프레임마다 두세 가지 방식을 모두 압축해 보고 가장 작은 것을 씁니다.
3. 같은 장면은 시간만 합치기: 앞 프레임과 화소가 완전히 같은 프레임은 저장하지 않고, 그 표시 시간을 앞 프레임에 더합니다. 전체 재생 시간은 그대로입니다.
4. 색은 원래 그대로: 모든 프레임의 색이 합쳐서 255개 이하면 전체 색표 하나에, 그보다 많으면 프레임마다 그 사각형에 쓰인 색만 담은 색표에 원래 색을 그대로 적습니다.

투명했던 자리가 다시 투명해져야 하는 GIF(배경이 투명한 스티커처럼 움직이는 그림)는 앞 프레임을 '배경으로 지우기'(처리 방법 2)로 바꿔 그 자리를 비운 뒤 다음 프레임을 그립니다. 이렇게 만든 결과는 원본과 화소 단위로 같은지 이 도구의 시험에서 프레임마다 대조했습니다.

손실 압축은 무엇을 버리나요

GIF는 화소 번호를 LZW(Welch 1984)로 압축합니다. 앞에서 나온 번호 줄을 사전에 모아 두고, 같은 줄이 다시 나오면 사전 번호 하나로 적는 방식입니다. 사전 번호는 최대 12비트라 사전에는 4,096개까지 들어갑니다. 손실 LZW는 사전에서 줄을 찾을 때 색이 아주 조금 다른 화소도 같은 것으로 보고 더 긴 줄을 이어 씁니다. gifsicle의 --lossy 옵션과 같은 생각이며, 줄이 길어질수록 적을 번호가 줄어 파일이 작아집니다.

• 무엇이 달라지나: 화소 하나하나가 원래 색과 조금 다른 비슷한 색으로 바뀝니다. 차이는 다음 화소로 넘겨 평균 색이 유지되게 하지만, 단계가 높으면 가로로 긴 줄무늬가 보입니다. 사진 같은 영상 움짤에서 효과가 크고, 단색 면이 많은 화면 녹화는 효과가 작습니다.
• 비슷한 화소 그대로 두기: 영상에서 만든 움짤은 멈춘 배경도 잡음 때문에 프레임마다 화소가 조금씩 바뀝니다. 손실 단계에서는 앞 화면과 색 차이가 아주 작은 화소를 바뀌지 않은 것으로 보고 투명 번호로 비웁니다. 비교는 늘 지금 프레임의 원래 색과 하므로, 프레임이 지나도 차이가 쌓이지 않습니다.
• 투명한 곳은 건드리지 않습니다: 투명과 불투명은 손실 단계에서도 서로 바꾸지 않습니다. 스티커처럼 배경이 투명한 GIF는 윤곽이 그대로 남습니다.

색 개수를 줄이면 생기는 일

GIF의 색표는 2, 4, 8 … 256처럼 2의 거듭제곱 크기이고, 한 색표에는 최대 256색이 들어갑니다. 색을 128개나 64개로 줄이면 화소 번호에 필요한 비트가 줄어 파일이 작아집니다. 이 도구는 모든 프레임에서 고루 뽑은 화소로 median cut(Heckbert 1982)을 써서 색을 고르고, 모든 프레임이 같은 전체 색표를 쓰게 합니다. 프레임마다 색이 달라지지 않아 깜빡임이 적고, 프레임마다 색표를 따로 적지 않아도 됩니다.

• 원색 그림·아이콘·화면 녹화는 색이 적어서 64색에서도 차이가 작습니다.
• 하늘·피부·그림자처럼 색이 이어지는 사진은 128색부터 띠가 보일 수 있습니다. 오차 확산(디더링)은 쓰지 않습니다. 디더링은 프레임마다 점무늬가 달라져 바뀐 화소가 늘고 파일이 커지기 때문입니다.
• 장면이 여러 번 바뀌는 긴 움짤은 장면마다 색이 달라서, 전체 색표 하나로 줄이면 어떤 장면의 색이 더 거칠어질 수 있습니다. 이런 GIF는 '보통'까지 쓰거나 가로 크기를 줄이는 편이 낫습니다.

가로 크기와 프레임을 줄이면

가로를 줄이면 세로도 같은 비율로 줄어 화소 수는 그 제곱으로 줄어듭니다. 가로 75%는 화소 56%, 50%는 25%입니다. 프레임을 솎으면 2장 중 1장만 남기고, 빠진 장면의 시간은 남은 프레임에 더해 전체 길이는 그대로 둡니다. 아래는 '보통' 단계를 그대로 두고 크기와 프레임만 바꾼 결과이며, 괄호 안은 원본 대비 줄어든 비율입니다.

영상 움짤은 가로를 줄이거나 프레임을 솎을수록 거의 화소 수에 비례해 줄었습니다. 화면 녹화는 바뀌는 부분이 작아서, 가로를 반으로 줄여도 줄어드는 폭이 영상보다 작습니다. 작은 글자가 있는 화면 녹화는 가로를 줄이면 글자를 못 읽게 되기 쉬우니, 크기보다 단계를 먼저 바꿔 보는 편이 좋습니다.

GIF의 지연 시간은 1/100초 단위입니다. 사파리가 쓰는 WebKit의 소스에는 Firefox처럼 0.01초 이하로 적힌 프레임을 0.1초로 보여 준다는 설명이 있습니다. 그래서 이 도구는 프레임을 합칠 때 0이나 0.01초로 적힌 프레임을 0.1초로 셈해 더합니다. 합치지 않는 프레임의 지연 값은 원본 그대로 둡니다.

목표 용량은 이런 순서로 맞춥니다

1. 지금 가로·프레임 설정으로 무손실부터 '강하게'까지 차례로 실제로 만들어 보고, 목표 이하가 되는 첫 단계(가장 가벼운 단계)를 고릅니다. 원본이 이미 목표 이하이고 무손실로도 줄지 않으면 원본을 그대로 줍니다.
2. '강하게'로도 넘으면 '강하게'를 둔 채 가로를 줄입니다. 크기가 대략 화소 수에 비례한다는 점을 써서 다음 가로를 어림하고, 실제로 만들어 재기를 몇 번 되풀이해 목표 안에 드는 가장 큰 가로를 찾습니다.
3. 찾은 가로에서 다섯 단계를 다시 재고, 그 가로에서 목표 안에 드는 가장 가벼운 단계를 보여 줍니다. 결과 칸에 '가로를 360 → 300px로 줄였습니다'처럼 무엇을 바꿨는지 적습니다.
4. 단계를 직접 누르면 그 단계를 그대로 쓰고, 목표를 넘으면 붉은 글씨로 알려 줍니다.

크기는 1 KB = 1,000바이트, 1 MB = 1,000,000바이트로 셉니다(국제단위계 접두어). 화면에 보이는 숫자는 올림이라, '2 MB 이하'라고 나오면 실제 바이트도 2,000,000 이하입니다. 올리는 곳이 MiB(1,048,576바이트)로 셈하면 같은 숫자에서 조금 더 여유가 있습니다.

프레임 지도 읽는 법

프레임 지도의 가로는 시간이고, 칸 하나가 원본 프레임 하나입니다. 칸의 폭은 그 프레임이 보이는 시간이라, 오래 멈추는 마지막 장면은 넓게 보입니다. 회색 막대는 원본에서 그 프레임이 쓴 바이트, 주황 막대는 결과에서 쓴 바이트입니다. 높이는 제곱근 눈금이라 작은 프레임도 보입니다.

• 첫 프레임이 가장 큽니다: 첫 프레임은 화면 전체를 그려야 해서 늘 큽니다. 화면 녹화 예시는 첫 프레임 뒤로 주황 막대가 아주 낮아지는데, 바뀐 곳만 저장하기 때문입니다.
• 빗금 칸은 결과에 따로 없는 프레임입니다: 앞 프레임과 같아서 시간만 합쳐졌거나, 프레임 솎기로 빠진 프레임입니다. 그 시간 동안에는 앞 프레임이 보입니다.
• 막대가 솟은 곳은 장면이 바뀐 곳입니다: 영상 움짤에서 막대가 갑자기 높아지는 칸은 화면 전체가 바뀐 장면입니다. 그 구간이 길면 프레임 솎기의 효과가 큽니다.

지도를 누르면 그 프레임에서 멈추고, 무대에 원본과 결과의 같은 시각 프레임이 나옵니다. 방향키로 한 프레임씩 넘기며 손실이 눈에 띄는 장면을 찾을 수 있습니다.

자주 틀리는 경우

• 확장자만 .gif로 바꾼 파일: PNG·JPG·WebP의 이름만 바꾼 파일은 GIF가 아니라 열리지 않습니다. 사진 여러 장을 움짤로 만들려면 GIF 만들기를, 동영상을 움짤로 만들려면 동영상 GIF 변환을 씁니다.
• 가로를 반으로 줄이면 파일도 반이 된다는 생각: 화소는 4분의 1이 되지만, 파일 크기는 장면이 얼마나 바뀌는지에 따라 다릅니다. 위 표처럼 영상과 화면 녹화가 다르게 줄어듭니다.
• 프레임 솎기로 빨라진다는 생각: 빠진 프레임의 시간은 남은 프레임에 더하므로 재생 시간은 그대로입니다. 움직임만 덜 부드러워집니다.
• 이미 줄인 GIF를 또 줄이기: 손실 단계로 줄인 GIF를 다시 줄이면 손실이 쌓입니다. 원본이 있으면 원본에서 한 번에 원하는 단계로 줄이는 편이 깨끗합니다.
• '무손실'이 늘 작아질 거라는 기대: 이미 잘 줄여 둔 GIF는 다시 써도 작아지지 않습니다. 이때 이 도구는 원본을 그대로 주고, 결과 칸에 그 사실을 적습니다.
• MB와 MiB 혼동: 한도가 '10MB'여도 서비스에 따라 10,000,000바이트일 수도, 10,485,760바이트일 수도 있습니다. 목표를 한도보다 조금 작게 잡으면 안전합니다.

한계

• GIF 한 개, 50 MB, 프레임 1,000장, 가로 × 세로 × 프레임 수 1억 5천만 화소까지 엽니다. 가로·세로는 각각 8,000px까지입니다. 이 숫자는 GIF 형식의 한도가 아니라 브라우저가 멈추지 않게 이 도구가 정한 범위입니다.
• 표의 크기는 2026-10-21에 이 도구의 엔진으로 잰 값입니다. 엔진이 같으면 어느 브라우저에서도 같은 크기가 나오지만, 엔진을 고치면 달라질 수 있습니다.
• 단계별 화질은 PSNR 같은 숫자로만 정하지 않았습니다. 같은 단계라도 GIF마다 눈에 보이는 정도가 다르니 무대에서 직접 확인하세요.
• 결과는 늘 GIF입니다. 길이가 긴 영상 움짤은 같은 화질의 MP4·WebM 동영상이나 움직이는 WebP가 훨씬 작습니다. web.dev는 웹 페이지의 큰 GIF를 동영상으로 바꾸라고 권합니다. 올리는 곳이 동영상을 받는다면 그쪽이 낫습니다.
• 주석·XMP 같은 덧붙은 정보와 인터레이스 저장은 결과에 남기지 않습니다. 반복 횟수(계속 반복·한 번 재생·n번)는 원본 그대로 둡니다.
• 무대의 재생은 브라우저가 두 GIF를 따로 재생하는 것이라, 아주 긴 GIF에서는 원본과 결과가 조금 어긋날 수 있습니다. 같은 시각을 정확히 비교하려면 멈춘 뒤 프레임을 넘겨 보세요.

기준: 2026-10-21에 아래 문서의 해당 문장을 확인했습니다. 크기 숫자는 이 도구의 엔진으로 예시 GIF를 줄여 잰 값입니다.

출처

• 01W3C — Graphics Interchange Format Version 89a이미지 설명 블록의 위치·크기, 색표 크기 2^N+1, 처리 방법 0~3, 지연 시간(1/100초), 투명 번호, LZW 코드 최대 12비트
• 02gifsicle 설명서 — --lossy, --optimize손실 LZW로 화소 색을 바꿔 크기를 줄이는 옵션과 프레임 최적화 단계
• 03Welch, T. A. (1984). A Technique for High-Performance Data Compression. Computer, 17(6), 8–19LZW 압축
• 04Heckbert, P. (1982). Color image quantization for frame buffer display. SIGGRAPH '82, 297–307median cut 색 줄이기
• 05GitHub Docs — Attaching files이미지와 GIF는 10MB까지
• 06web.dev — Replace animated GIFs with video for faster page loads큰 GIF를 동영상으로 바꾸면 크게 작아짐
• 07WebKit — ScalableImageDecoder.cpp0.01초(10 ms) 이하로 적힌 프레임은 Firefox처럼 0.1초로 보여 준다는 주석
• 08NIST — Prefixes for binary multipleskilo = 10³, kibi = 2¹⁰

자주 묻는 질문

함께 쓰는 도구