2026-10-06

GIPHY Clips는 30초·100MB 제한, 무료 GIF Maker엔 길이 제한이 아예 없다 (GIPHY 자체 문서 기준)

"GIPHY에 영상을 업로드한다"는 말은 목적지 하나, 규격 하나처럼 들린다. 실제로는 둘이다 — 그리고 용량 제한도, 길이 제한도, 심지어 누가 쓸 수 있는지도 서로 다르다. GIPHY Clips는 GIPHY 자체 표현으로 "GIFs with Sound"(사운드가 있는 GIF)다 — 무음으로 반복되는 이미지가 아니라 오디오가 있는 진짜 영상이고, GIPHY 자체 지원 문서는 이걸 만드는 게 누구에게나 열려 있지 않다고 명시한다. 반면 giphy.com/create 의 평범한 GIF Maker는 누구나 쓸 수 있는 쪽이고, 영상을 넣으면 무음 GIF가 나오며, 자체 페이지 어디에도 길이 제한을 명시하지 않는다 — "6초", "15초"처럼 여러 관련 없는 가이드가 마치 GIPHY 자체 규정인 것처럼 반복하는 구체적인 초 단위 숫자와는 맞지 않는다.

GIPHY Clips: 구체적인 숫자, 그리고 대부분이 먼저 걸리는 진짜 조건

GIPHY 자체 Clips Best Practices 지원 문서는 GIF Maker 페이지와 달리 구체적이다: 클립은 최대 30초, 최대 100MB, MP4·MOV·WebM 형식, 9:16에서 16:9 사이 비율, 최대 4K 해상도, 초당 24 또는 30프레임을 명시한다. 이 숫자들은 트림·변환의 목표로 삼을 만해 보이지만 — 같은 문서는 이 글을 읽는 대부분에게 더 중요한 사실을 명시한다: "Clips creation is only available for upgraded Brands and Artists"(클립 제작은 업그레이드된 브랜드·아티스트 계정에만 허용된다). 이미 있는 클립을 보고 공유하는 건 누구나 가능하지만, 자기 영상으로 새 클립을 만드는 건 그렇지 않다 — 먼저 업그레이드된 채널을 신청해야 한다. 자신의 계정이 그게 아니라면, 위의 30초·100MB 규격은 지금 당장 쓸 수 있는 경로가 아니다 — NearVid가 뭔가를 못 해서가 아니다.

업그레이드 채널이 없는 대부분이 실제로 쓰는 GIF Maker

업그레이드된 채널이 없는 사람이 대신 도착하는 페이지 — giphy.com/create/gifmaker — 는 자체 인터페이스 기준으로 "JPG, PNG, GIF, MP4, MOV, or WebM"을 입력으로 받아 영상을 무음 반복 GIF로 바꿔준다. 이 페이지는 자체 본문 어디에도 길이 제한을 명시하지 않는다. "GIPHY의 제한"이라며 떠도는 구체적인 초 단위 숫자들은 이 조사에서 확인한 이 페이지나 다른 어떤 GIPHY 페이지에서도 나오지 않은, 관련 없는 가이드들의 주장이다 — 그래서 여기엔 사실로 적지 않는다. 공식적으로 문서화된 숫자 하나는 완전히 다른 페이지에서 나온다: GIPHY 자체 업로드 API 문서는 "We accept animated GIFs or video files up to 100MB"(애니메이션 GIF 또는 영상 파일을 최대 100MB까지 받는다)라고 명시한다 — Clips가 쓰는 것과 같은 상한이며, GIF Maker 페이지 자체는 이 숫자를 따로 반복하지 않는데도 업로드 쪽에서는 동일하게 적용된다.

GIPHY의 두 업로드 경로는 길이 제한도, 이용 자격도 공유하지 않는다 — 공유하는 건 100MB 용량 상한뿐이고, 그마저도 두 화면 중 어디에도 적혀 있지 않은 제3의 문서에 있다.

NearVid의 기존 10초 GIF 상한은 어디서 왔나

NearVid의 GIF 내보내기는 원래부터 소스 구간을 10초로 제한해 왔다 — GIPHY에 맞추려고 고른 숫자가 아니라 제품에 이미 있던 숫자다: workspace.js는 이를 const cap = 10으로 하드코딩하고 있고, 그 주석은 제품의 "10초 이하 권장" 지침을 근거로 들며 제안이 아니라 강제로 적용한다. 이 숫자는 GIPHY가 실제로 명시하는 모든 길이 수치보다 편안하게 아래에 있다 — Clips의 30초 상한도, GIF Maker 페이지 자체에 아예 없는 길이 제한도 모두. 이번 조사를 위해 급조한 우연의 일치가 아니라, 조사를 시작하기 전부터 소스에 이미 있던 그 숫자를 직접 확인한 것이다.

GIF에는 용량 예측치가 없다 — 빠뜨린 게 아니라 의도적으로

NearVid는 WebM과 MP4 변환 작업의 품질 선택 옆에 고정 비트레이트 프리셋과 길이를 곱한 실시간 "≈" 예상 용량을 보여준다(workspace.js의 updateQualityEstimate()에서 확인). 이 함수는 GIF 작업에서는 일찍 반환되며 아무것도 보여주지 않는다 — state.op !== 'webm' && state.op !== 'mp4' 조건이 값을 채우는 대신 필드를 비워버린다. GIF는 인코딩된 영상처럼 고정된 비트레이트가 없다 — 같은 10초, 같은 너비, 같은 프레임레이트라도 영상 속 색상과 움직임이 프레임마다 얼마나 바뀌는지에 따라 결과 용량이 크게 달라지고, 이는 비트레이트 곱하기 길이 공식으로는 설명할 수 없다. 틀리기 쉬운 숫자를 보여주는 대신 GIF 필드를 비워두는 것은, NearVid가 탐색 못한 파일의 길이에 대해 이미 적용하고 있는 "정직한 미확인" 원칙을 한 군데 더 적용한 것뿐이다.

Clips 자격이 있다면: GIF 내보내기가 아니라 트림·변환

클립은 오디오를 유지한다 — 즉 오디오 트랙을 아예 건드리지 않는 GIF 내보내기 경로는 쓸 수 없다는 뜻이다. NearVid의 무손실 트림은 재인코딩 없이 정확한 시작·끝 지점에서 자르고, Convert to WebM 또는 Convert to MP4(브라우저 지원 여부로 게이팅되는 WebCodecs/Mediabunny 경유 H.264+AAC)는 GIPHY 자체 문서가 Clips용으로 명시한 세 형식 중 하나를 만들어낸다. 두 작업 모두 프레임레이트를 다시 맞추거나 프레임을 리사이즈하지 않는다 — 원본 영상이 이미 24 또는 30fps가 아니거나 이미 9:16~16:9 사이가 아니라면, NearVid를 거치기 전에도 거친 뒤에도 그대로다. NearVid가 기계적으로 처리해주는 건 클립 길이를 30초 이하로, 그리고 지원 형식 컨테이너로 맞추는 것뿐이다 — 오디오를 포함해서, 기기 안에서, 브라우저 탭을 벗어나지 않고.

이게 할 수 없는 것

NearVid는 GIPHY에 업로드하지 않고, 업그레이드된 브랜드·아티스트 채널을 신청하거나 확인해주지도 않으며, 프레임을 GIPHY의 비율 범위에 맞게 크롭·리사이즈하지도 않고, 전용 GIF 도구처럼 색상 팔레트나 프레임 수를 최적화해주지도 않는다. NearVid가 실제로 해주는 건 양쪽 경로 모두에서 순전히 기계적인 두 가지다: 재인코딩 없이 길이를 정확히 맞추는 것, 그리고 클립의 경우 오디오를 유지한 채 지원 형식 컨테이너를 만들어주는 것 — 원본 영상이 이미 있는 바로 그 기기 안에서.

정리

GIPHY Clips와 GIPHY의 평범한 GIF Maker는 하나의 제한을 공유하는 하나의 기능이 아니라, 서로 다른 규격을 가진 두 개의 도구다: Clips는 최대 30초·100MB로 제한되지만 제작 자체가 업그레이드된 브랜드·아티스트 채널에만 허용되고, 누구나 쓸 수 있는 GIF Maker는 자체 페이지에 길이 제한을 전혀 명시하지 않은 채 GIPHY API 문서가 별도로 명시하는 동일한 100MB 업로드 상한 아래에만 있다. NearVid의 GIF 내보내기는 이 조사를 시작하기 전부터 이미 10초로 제한돼 있었고, 이는 두 숫자 모두보다 편안하게 아래에 있으며, GIF 결과물에 대해서는 추측 대신 의도적으로 용량 예측치를 보여주지 않는다. Clips를 위해서라면 — 오디오를 포함해서 — 트림과 Convert to MP4·WebM이 길이와 컨테이너를 정확히 맞춰준다; 비율과 프레임레이트는 여전히 원본 영상이 갖추고 들어와야 하는 몫이다.