2026-07-29

2026년 GitHub·Discord·Slack GIF 업로드 용량 제한 (그리고 변환보다 트림이 먼저인 이유)

버그 재현이나 기능 데모 영상을 몇 초 분량으로 잘라서 GIF로 변환했는데, 그래도 업로드가 거부된 경험이 있을 것이다. 개발자들이 이런 클립을 가장 많이 올리는 세 곳 — GitHub, Discord, Slack — 은 저마다 다른 용량 상한을 두고 있고, 그중 둘은 최근 2년 사이에 그 숫자가 바뀌었다. 지금 시점의 정확한 숫자와 출처, 그리고 그 상한 아래로 맞추는 진짜 핵심 요령을 정리했다 — GIF 품질 설정을 만지는 것보다, 애초에 인코더에 얼마나 긴 영상을 넣었는지가 훨씬 더 크게 작용한다.

지금 실제로 적용되는 세 가지 상한

2026년 중반 기준:

• GitHub: 이미지·GIF는 10MB. 이슈, 풀 리퀘스트, 코멘트에 파일을 첨부하는 것에 대한 GitHub 공식 문서는 명확하다: "이미지와 GIF는 10MB", "그 외 모든 파일은 25MB", 그리고 실제 영상 파일의 경우 "무료 GitHub 플랜 소유 저장소에 업로드하는 영상은 10MB"인 반면 유료 플랜에서는 "100MB"다. 일반 git 저장소에는 "미디어 자산 업로드" 버튼이 따로 없기 때문에, README에 GIF를 넣는 흔한 방법은 먼저 새 이슈나 풀 리퀘스트 코멘트 창에 파일을 드래그해 넣는 것이다 — GitHub는 그 파일에 대해 호스팅된 URL을 생성해 주고, 그 URL을 README의 마크다운에 붙여넣을 수 있다. 실제로 그 이슈에 파일이 첨부된 건 아니지만 말이다. 다만 결국 같은 업로드 경로를 타기 때문에, 그 URL도 똑같이 이미지·GIF 10MB 제한을 통과해야 한다.
• Discord: 2024년 9월부터 무료 사용자는 10MB. Discord 공식 계정이 직접 이 변경을 발표했다 — 무료 등급 상한을 25MB에서 다시 10MB로 낮춘 것이다. 당시 보도(Dataconomy, Dexerto)는 Discord가 밝힌 이유를 그대로 인용했다: "스토리지 관리에는 비용이 든다"는 것과, 어차피 대다수 사용자의 파일이 이미 10MB 미만이었다는 것이다. Nitro Basic은 상한을 50MB로, 정식 Nitro는 500MB로 올려준다. 알아둘 만한 세부사항 하나: 이 상한은 파일 하나가 아니라 메시지 하나에 첨부된 모든 파일의 합산 용량에 적용된다 — 작은 GIF 여러 개를 한 메시지에 넣으면 그 GIF들이 같은 10MB 예산을 나눠 쓰는 셈이다.
• Slack: 무료 플랜을 포함한 모든 플랜에서 파일당 1GB. Slack 자체 고객센터 문서는 파일 하나가 최대 1GB까지 가능하다고 밝히고 있고, Free 플랜에 대해 별도로 더 낮은 상한을 언급하지 않는다 — 그래서 Slack에서는 순수한 파일 용량이 업로드를 막는 경우가 거의 없다. Slack Free에서 진짜 걸리는 건 용량이 아니라 보존 기간이다: Slack 공식 문서는 Free 플랜에서는 최근 90일치 메시지·파일 기록만 보이고, 1년이 지난 데이터는 순차적으로 삭제된다고 명시하고 있다. 8개월 전에 Slack Free에서 공유한 데모 GIF는 나중에 찾으려 할 때 이미 사라졌을 수 있다 — "업로드가 거부됐다"와는 다른 종류의 실패지만, 나중에 그 링크를 다시 참조할 계획이라면 마찬가지로 중요한 문제다.

같은 분량이라도 GIF가 영상보다 훨씬 더 커지는 이유

위 GitHub 숫자 자체가 힌트다: 영상은 무료 10MB·유료 100MB인데, 같은 화면 크기의 이미지나 GIF는 플랜과 무관하게 10MB로 고정돼 있다. 이 차이는 GIF와 요즘 영상 코덱이 압축을 완전히 다른 방식으로 풀기 때문에 생긴다. VP9나 H.264 같은 영상 코덱은 대부분의 비트를 각 프레임을 주변 프레임으로부터 예측하는 데 쓴다 — 화면에서 실제로 바뀐 부분만 다시 인코드하면 된다. GIF에는 그런 프레임 간 예측이 아예 없다. 팔레트 수가 제한된, 프레임 단위 방식으로 설계됐고, 그것도 1987년의 웹을 염두에 둔 방식이지 매끄러운 움직임을 위한 게 아니다. 화면 녹화 8초짜리를 GIF로 만들면, 시각적으로 똑같은 내용을 WebM이나 MP4로 만들었을 때보다 눈에 띄게 더 커질 수 있다 — 그래서 어떤 플랫폼의 영상 업로드 상한은 여유 있게 통과하는 클립이, GIF로 변환하는 순간 이미지 전용 첨부만 받는 곳에서는 거부당하는 일이 생긴다.

진짜 핵심 요령: 변환 전에 먼저 트림한다

NearVid의 트림은 재인코딩이 아니라 무손실 스트림 복사다 — 다른 무엇을 하기 전에, 버그나 기능이 실제로 보이는 딱 그 몇 초만 남기고 잘라내는 게 먼저다. 이 순서는 생각보다 훨씬 중요하다: GIF나 WebM 인코더는 결과물의 모든 프레임 하나하나에 출력 바이트를 써야 하므로, 나중에 조정하는 어떤 프레임별 품질 설정보다도 입력 영상의 길이가 최종 파일 크기에 가장 크게 작용한다. 40초짜리 화면 녹화를 실제로 필요한 8초로 먼저 잘라내고 나서 변환하면, 40초 전체를 변환해서 상한 아래로 겨우 들어가길 바라는 것보다 훨씬 작은 파일이 나온다 — 그리고 이 과정은 별도 비용이 들지 않는다. NearVid의 트림은 컨테이너만 복사할 뿐, 프레임을 디코드하거나 재인코드하지 않기 때문이다.

목적지가 애니메이션 이미지가 아니라 실제 영상 첨부를 받아준다면 — Discord의 파일 첨부와 Slack의 파일 업로드는 둘 다 그렇다 — 같은 트림된 클립을 GIF 대신 WebM으로 변환하는 편이 대체로 용량 면에서 더 유리하다. 앞서 말한 이유와 같다: 움직임을 인식하는 영상 압축이 GIF의 프레임 단위 방식보다 같은 화면을 훨씬 효율적으로 처리하기 때문이다. GIF는 애니메이션 이미지가 정말 필요한 특정 자리에만 남겨 두면 된다 — <video> 임베드 없이 인라인으로 재생되는 README 애니메이션이라든가, 이미지만 인라인으로 미리보기 하는 채팅 환경 같은 곳이다. 그리고 크롬이나 다른 크로미움 계열 브라우저에서 WebCodecs를 지원하는 경우, NearVid는 같은 트림된 클립으로 실제 MP4도 내보낼 수 있다 — WebM이 아니라 일반적인 영상 컨테이너를 기대하는 목적지에 유용하다. 이 경로는 기능 감지 방식이라 모든 브라우저에서 되는 건 아니므로, 됐다고 가정하지 말고 실제로 MP4가 나왔는지 확인해 보는 게 좋다.

NearVid가 실제로 하는 일과 하지 않는 일

범위를 정확히 짚자면: NearVid는 GitHub·Discord·Slack 각각의 구체적인 상한을 알지 못하고, 특정 바이트 수를 목표로 맞춰주지도 않는다 — "10MB 이하로 자동 압축" 같은 자동 리사이즈나 자동 비트레이트 조절 기능은 없다. 길이를 트림하고, GIF·WebM으로(또는 지원되는 경우 MP4로) 변환한 뒤, 결과 파일의 크기를 게시하려는 곳의 상한과 직접 비교해 확인해야 한다. NearVid가 실제로 하는 일은 이 모든 과정 — 트림, WebM/GIF 변환, 조건부 MP4 내보내기, 표지 이미지를 위한 정지 프레임 추출 — 을 전부 브라우저 탭 안에서 온디바이스로 처리하는 것이다. 그래서 더 작은 결과물을 만들기 위해 먼저 원본 큰 파일을 어딘가에 업로드할 필요가 없다.

정직한 요약

현재 숫자는 이렇다: GitHub는 플랜과 무관하게 이미지·GIF를 10MB로 제한한다(실제 영상 파일은 무료 10MB·유료 100MB). Discord는 2024년 9월에 무료 등급 상한을 25MB에서 10MB로 낮췄고, Nitro Basic과 정식 Nitro는 각각 50MB, 500MB다. Slack은 모든 플랜에서 파일당 1GB까지 허용하지만, 무료 플랜의 기록 보존 기간은 90일에서 최대 1년으로 제한돼 있다. 이 숫자들은 나중에 GIF 품질 설정을 아무리 만져도 바뀌지 않는다 — 인코더에 넘기는 입력 영상의 길이가 그 뒤에 오는 어떤 설정보다 더 크게 작용하기 때문이다. 그래서 무엇으로 변환하기 전에, 정말 필요한 그 몇 초만 먼저 잘라내는 게 가장 먼저 해야 할 일이다.