# GIF 안에는 실제로 무엇이 있나

GIF는 네모를 쌓아 올린 것이고, 네모마다 시계 하나와 색 표 하나가 붙어 있습니다.이 형식에 대한 불만은 거의 전부 그 셋 중 하나에서 나옵니다. 각 부분이 무슨 일을하는지, 그리고 당신의 파일이 그중 어디에 용량을 쓰고 있는지 알아내는 법을적었습니다.

[GIF 분석 열기](https://abox.tools/ko/gif-분석/): 프레임, 재생 시간, 팔레트, 그리고 바이트가 어디로 갔는지.

마지막 업데이트 2026년 8월 26일

## 짧은 답

GIF는 캔버스 하나와, 그 위에 칠할 네모들의 목록과, 그 네모 안의 숫자가 무슨 색인지 알려 주는 색 표로 되어 있습니다. 네모마다 세 가지가 붙어 있습니다. 얼마나 오래 띄워 둘지, 그다음 그것을 어떻게 할지, 그리고 필요하다면 자기만의 색 표입니다.

이 형식에서 사람들이 뜻밖이라고 느끼는 것은 거의 전부 그 목록에서 나옵니다. GIF가 터무니없이 크다면 네모가 매번 캔버스 전체이거나, 안에 색 표가 삼백 개 들어 있는 것입니다. 너무 느리게 재생된다면 지연 시간이 어떤 브라우저도 내려가지 않는 바닥 아래에 있는 것입니다. 잔상이 남는다면 *처리 방식*이라 불리는 항목 때문입니다.

특정 파일이 그중 무엇인지 보려면 [GIF 분석](https://abox.tools/ko/gif-분석/)을 열고 파일을 넣어 보세요. 이 페이지의 나머지는 그 숫자들이 무슨 뜻인지에 대한 것입니다.

![GIF의 요약 카드. 버전, 캔버스 크기, 파일 크기, 프레임 수, 몇 번 반복하는지, 몇 가지 색을 쓰는지.](https://abox.tools/screens/whats-inside-a-gif/facts.webp)

재생기가 결코 보여 주지 않는 모든 것을, 파일 하나에서.

## 프레임은 네모이지 그림이 아닙니다

GIF를 재생된 모습으로만 본 사람이 놀라는 대목이 이것입니다. 프레임은 그 순간의 애니메이션 그림이 아닙니다. 자기 위치와 자기 크기를 가진 네모이고, 앞선 프레임들이 남겨 놓은 것 위에 칠해집니다.

그 네모가 캔버스 전체일 수도 있고, 잘못 만든 파일에서는 늘 그렇습니다. 하지만 GIF는 지난 프레임 이후 달라진 부분만 저장해도 됩니다. 그림의 대부분이 가만히 있는 장면에서는, 그것이 12 MB짜리 파일과 900 KB짜리 파일의 차이가 됩니다. 거의 움직이지 않는 창을 녹화한 화면이 작을 수 있는 이유도, 같은 녹화가 허술한 변환기를 거치면 작지 않은 이유도 그것입니다.

애니메이션을 봐서는 어느 쪽인지 알 수 없습니다. 둘은 똑같아 보입니다. 알 수 있는 유일한 방법은 프레임마다 무엇을 저장했는지 보는 것이고, 분석 도구에 그 화면이 있는 것도 바로 이 때문입니다. *각 프레임이 저장한 것만*으로 바꿔 보면, 투명한 배경 위에 작은 모양들이 줄지어 있습니다. 인코더가 제 일을 했다는 뜻이지요. 아니면 그림 전체가 몇 번이고 반복해서 나옵니다. 하지 않았다는 뜻입니다.

이 형식 어디에도 움직임 보상은 없습니다. 영상 코덱이 하듯 “지난번과 같되 왼쪽으로 네 픽셀”처럼 저장되는 일은 결코 없습니다. 달라진 네모만 담는 이 요령이 GIF에 남은 유일한 절약이고, 그 값어치는 상당합니다.

## 지연 시간, 그리고 모든 브라우저가 강제하는 바닥

프레임마다 얼마나 붙잡아 둘지를 100분의 1초 단위로 저장합니다. 이 형식에 있는 단위는 그것뿐이라, 파일이 요구할 수 있는 가장 빠른 값은 0.01 초, 곧 초당 백 프레임이고, 가장 긴 값은 약 655 초입니다.

하지만 초당 백 프레임은 얻지 못합니다. **모든 브라우저가 0.02 초 미만의 지연 시간을 0.10으로 올려 버립니다.** 이 규칙은 1996년 넷스케이프 내비게이터에 적혔습니다. 그 시절의 돌아가는 지구본과 움직이는 “공사 중” 표지판을 위해 쓰였고, 그 뒤의 모든 브라우저가 그대로 베꼈습니다. 아무도 지운 적이 없고, 앞으로도 지우지 않을 것입니다.

그래서 모든 프레임이 0.01 초라고 적힌 GIF는 초당 백 프레임이 아니라 초당 열 프레임으로 재생됩니다. 그것을 만든 쪽이 의도한 것보다 열 배 느리게 도는데, 파일은 그 사실을 전혀 내비치지 않습니다. 안에 든 지연 시간은 요청된 값 그대로니까요. 이 형식에서 가장 흔한 뜻밖의 일이고, 분석 도구가 재생 시간을 둘로 나눠 알려 주는 이유이기도 합니다. 파일이 말하는 시간과, 브라우저가 실제로 만들어 낼 시간입니다.

해결책은, 파일을 어디서 만들든 0.01 대신 0.02를 적는 것입니다. 그러면 초당 50 프레임이 되는데, 그것이 진짜 천장이고 웬만한 용도에는 넘치도록 빠릅니다. 실제로는 0.05 초, 곧 초당 스무 프레임쯤이 요구할 만한 상한입니다.

지연 시간이 알려 주는 것이 하나 더 있습니다. 값이 전부 같다면 그 파일은 고정된 간격의 프레임 묶음으로 만들어진 것입니다. 값이 들쭉날쭉하다면, 여기는 0.04이고 저기는 0.11이라면, 무언가가 영상을 변환하면서 프레임을 버리고 빈자리를 메우려고 이웃을 늘린 것입니다. 그리고 마지막 하나만 나머지보다 훨씬 길다면 그것은 의도적입니다. 애니메이션이 다시 시작하기 전에 한 박자 쉬게 만드는 방법이 그것이니까요.

## 처리 방식: 잔상이 남을지 결정하는 항목

프레임마다 자기 시간이 끝났을 때 화면에 무엇을 남길지 적혀 있습니다. 가능한 답은 넷이고 알아 둘 값어치가 있습니다. 애니메이션이 이상해 보이는 네 가지 방식 중 셋이 이 항목이 잘못된 경우니까요.

- **그대로 둡니다.** 다음 프레임이 그 위에 바로 칠합니다. 프레임이 불투명하고 서로를 완전히 덮을 때 맞는 선택이고, 지울 것이 없으니 가장 값싼 선택이기도 합니다.
- **배경까지 지웁니다.** 다음 프레임이 그려지기 전에 그 프레임의 네모가 닦입니다. 투명을 쓰려면 이것이 필요합니다. 이것이 없으면 다음 프레임의 비쳐 보이는 부분으로 앞 프레임이 드러나고, 낱장 그림들의 애니메이션이 그림 더미로 변합니다.
- **아래 있던 것을 되돌립니다.** 이 프레임이 그리기 전에 캔버스에 있던 것이 제자리로 돌아옵니다. 멈춘 배경 위를 작은 물체가 지나가는 장면이 이렇게 저장됩니다. 프레임마다 물체를 칠하고, 그다음 배경이 돌아오며, 파일에 쓰이는 것은 내내 그 물체의 네모뿐입니다.
- **지정되지 않음.** 파일이 아무 말도 하지 않았습니다. 모든 뷰어가 “그대로 둡니다”로 취급하는데, 대개는 맞고 가끔은 투명한 GIF에 잔상이 남는 이유가 됩니다.

명세와 현실이 갈라서는 지점이 하나 있습니다. “배경까지 지웁니다”는 파일 머리에 적힌 배경색을 가리키지만, 모든 브라우저가 그 색을 무시하고 투명으로 지웁니다. 이십오 년째 그렇습니다. 그 배경색이 나타나리라 기대하고 만든 파일은 만든 사람이 만든 프로그램 안에서는 맞아 보이고, 다른 어디에서나 틀려 보입니다.

## 색 표, 그리고 그것이 치르는 768바이트

GIF의 픽셀은 색이 아닙니다. 최대 256색짜리 표를 가리키는 번호이고, 색 하나는 세 바이트로 저장됩니다. 그러니 꽉 찬 표 하나는 768 바이트이고, 파일은 전부가 함께 쓰는 표를 하나 둘 수도, 프레임마다 하나씩 둘 수도, 둘 다 둘 수도 있습니다.

두 방식 모두 정당하고, 맞바꾸는 것이 다릅니다.

- **함께 쓰는 표 하나**는 파일 전체에 768 바이트면 되고, 색이 프레임 사이에서 흔들리지 않습니다. GIF의 깜빡임, 그러니까 영상에서 만든 파일에서 보이는 그 거슬리는 어른거림은, 팔레트가 프레임마다 튀는 것일 때가 아주 많습니다.
- **프레임마다 하나씩**이면 각 프레임이 공용 표에 없는 색을 쓸 수 있고, 장면이 통째로 바뀔 때 그것이 중요해집니다. 대신 매번 768 바이트가 듭니다. 300프레임짜리 애니메이션이면 픽셀 하나 저장하기 전에 색 표만 230 KB입니다.

조용한 비용이 하나 더 있습니다. 색 표의 길이는 2의 거듭제곱이어야 해서, 아홉 색만 쓰는 프레임도 열여섯 칸짜리 표를 받고, 130색을 쓰는 프레임은 256칸을 받습니다. 어느 정도의 올림은 피할 수 없습니다. 다만 픽셀이 한 번도 가리키지 않는 오천 가지 색을 표가 선언하고 있는 파일은 다른 이야기입니다. 그것은 결국 프레임에 들어간 그림이 아닌 다른 그림을 위해 만들어진 팔레트입니다. 분석 도구가 쓰이지 않은 칸을 표시해 주므로 그 모양이 한눈에 보입니다.

## 바이트가 실제로 가는 곳

GIF의 모든 바이트는 몇 안 되는 자리 중 하나에 있습니다. 파일이 너무 크다고 판단하기 전에 그 자리가 어디인지 알아 둘 값어치가 있습니다.

- **압축된 픽셀.** 건강한 파일에서는 거의 전부입니다. 그림 자체를 LZW에 통과시킨 것인데, 이것은 1984년의 압축 방식으로 스프레드시트 화면을 염두에 두고 설계되었습니다. 평평한 색에 강하고 사진에 약한 이유가 그것입니다.
- **색 표.** 위에서 말한 대로 꽉 찬 표 하나에 768 바이트입니다.
- **프레임마다의 머리말.** 프레임 하나당 시간 정보 여덟 바이트와 기술자 열한 바이트. 보통 파일에서는 아무것도 아니지만, 아주 작은 프레임이 이천 개인 애니메이션에서는 38 KB입니다.
- **블록 포장.** 압축된 데이터는 최대 255 바이트씩 잘리고, 각 토막 앞에 길이 바이트가 하나 붙습니다. 256바이트마다 대략 한 바이트로 피할 수 없고, 달리 보이지 않는 것이라 한 번 볼 값어치가 있습니다.
- **메타데이터.** 주석, 색 프로파일, XMP 덩어리. 정말로 어처구니없는 결과를 만드는 것이 이것입니다. 이미지 편집기가 몇 해 전의 편집을 서술한 40 KB짜리 XML을 남겨 놓을 수 있고, 작은 GIF에서는 그것이 파일의 대부분이 됩니다. 어떤 뷰어도 그것을 그리지 않습니다.

짐작하는 대신 표로 들여다보는 이유는 답이 파일마다 다르고, 해결책이 그 답에서 곧바로 나오기 때문입니다. 95 %가 압축된 픽셀인 파일은 그저 그림이 많은 것이고, 프레임을 줄이거나 크기를 줄이거나 색을 줄이는 것만이 도움이 됩니다. 30 %가 색 표이거나 40 %가 XMP인 파일은 훨씬 값싼 문제를 안고 있습니다.

![GIF의 바이트가 어디로 갔는지 쪼갠 막대와, 프레임마다 크기와 파일 안 비중을 적은 줄들.](https://abox.tools/screens/whats-inside-a-gif/budget.webp)

바이트가 실제로 어디로 갔는지를 한 프레임씩. 너무 큰 GIF는 거의 언제나, 이것을 보면 뻔해지는 이유로 큽니다.

## 반복은 이 형식의 일부가 아닙니다

GIF 명세에는 애니메이션이 반복된다고 적는 항목이 없습니다. 반복은 넷스케이프가 1995년에 만들어 낸 블록에서 나옵니다. 안에 `NETSCAPE2.0`이라는 문자열이 든 “애플리케이션 확장”인데, 그런데도 모두가 구현했고 지금은 인터넷의 모든 움직이는 GIF에 들어 있습니다.

그 말은, 그 블록이 없는 파일은 어느 브라우저에서나 정확히 한 번 재생되고 멈춘다는 뜻입니다. 만든 사람 눈에는 고장 난 것처럼 보이겠지요. 애니메이션이 한 번만 지나가고 만다면 그 블록이 빠진 것입니다. 가장 먼저 확인해 볼 만한 것 중 하나이고, 어떤 뷰어에서도 눈에 보이지 않습니다.

블록은 횟수를 적을 수도 있습니다. 다섯 번 재생하고 멈추라는 식입니다. 0은 영원히를 뜻하고, 거의 모든 파일에 그렇게 적혀 있습니다.

## GIF가 실어 나를 수 있는 다른 것들

그림을 담지 않고, 어떤 뷰어도 건너뛰는 블록이 셋 있습니다.

- **주석.** 자유로운 글로, 보통은 파일을 쓴 프로그램의 이름이고, 가끔은 만든 사람이 공개하려 하지 않았을 무언가입니다. 아무것도 그것을 보여 주지 않지만, 파일의 모든 복사본이 그것을 지고 다닙니다.
- **XMP.** 어도비의 XML 메타데이터입니다. 무엇이 언제, 때로는 누가 파일을 편집했는지가 들어갑니다. 끝에 258 바이트짜리 마법의 꼬리를 달고 오는데, 블록 길이를 맞추기 위한 요령이며, 순진하게 읽으면 화면 한가득 이진 데이터가 쏟아지는 이유이기도 합니다.
- **일반 텍스트.** 1989년 명세에 있는 블록으로, 뷰어에게 격자 칸에 맞춰 그림 위에 글자를 그려 달라고 요청합니다. 아무것도 이것을 구현한 적이 없습니다. 파일에 이 블록이 있어도 거기 적힌 내용은 나타나지 않습니다.

셋 다 파일을 어딘가로 보내기 전에 알아 둘 값어치가 있습니다. GIF 중에서 당신에 대해 무언가를 말할 수 있는 부분이고, 무언가가 일부러 떼어 내지 않는 한 복사와 재업로드를 모두 견디고 살아남으니까요.

## 손상된 파일 읽기

GIF는 잘립니다. 도중에 멈춘 내려받기, 고장 나는 디스크에서 건져 낸 파일, 앱이 절반만 쓴 무언가. 이 형식이 색인이 있는 구조가 아니라 블록의 흐름이기 때문에, 잘린 GIF도 대개 잘린 지점까지는 읽힙니다. 끊긴 자리 앞의 프레임은 모두 온전하고 완전합니다.

알아 둘 값어치가 있습니다. 대부분의 소프트웨어는 그런 파일을 그냥 거부하니까요. 읽을 수 있는 데까지 읽고 어디서 멈췄는지 말해 주는 분석 도구라면, 적어도 얼마나 살아남았는지, 빠진 것이 한 프레임인지 마지막 이백 프레임인지는 알려 줍니다.

반대의 문제도 있습니다. 파일의 끝 표시 *뒤에* 앉아 있는 바이트들입니다. 모든 디코더가 그 표시에서 멈추므로 그것들은 읽히지도 그려지지도 않고, 대개는 무언가 잘못되면서 앞 파일 뒤에 붙어 버린 두 번째 파일입니다. 순수한 무게이고, 잘라 내도 잃을 것이 없습니다.

## 이 가운데 무엇도 업로드가 필요하지 않습니다

GIF의 구조를 읽는 일은 힘든 작업이 아닙니다. 블록 목록을 따라 걷는 일과 작은 압축 해제기 하나가 전부이고, 그것을 하자고 파일을 서버로 보낼 기술적 이유는 한 번도 없었습니다. 여기 [GIF 분석](https://abox.tools/ko/gif-분석/)은 블록 걷기, LZW, 화면에 그려지는 프레임, 바이트 회계까지 전부를 페이지 안에서 합니다.

이 일에서는 그 점이 다른 대부분의 일보다 더 중요합니다. 사람들이 가장 뜯어보고 싶어 하는 파일이야말로 남에게 건네도 될지 가장 확신이 서지 않는 파일인 경우가 많으니까요. 복구한 것, 누군가 보내온 것, 아직 읽어 보지 않은 주석 블록이 들어 있는 것. [파일 업로드에 대한 더 긴 이야기](https://abox.tools/ko/가이드/파일-업로드-안전한가/)는 이 사이트 어디에서보다 여기에 잘 들어맞습니다.