2026-08-09

화면 녹화를 슬랙 커스텀 이모지 GIF로 만드는 법 (슬랙 128KB 제한 안에서)

화면 녹화나 통화 녹화에서 딱 좋은 3초 — 리액션, 반복되는 드립, 타이밍 절묘한 에러 다이얼로그 — 를 잘라내서 슬랙 커스텀 애니메이션 이모지로 만들고 싶을 때가 있다. GIF로 내보내서 업로드하면 슬랙이 거부한다. 워크스페이스가 애니메이션 이모지를 막아둬서가 아니라, 거의 항상 파일이 슬랙이 실제로 허용하는 크기보다 크기 때문이다. 실제 제한이 뭔지, 평범하게 내보내면 왜 대부분 그 제한을 넘어서는지, 그리고 업로드를 몇 번씩 반복하지 않고도 NearVid의 GIF 옵션으로 그 제한 안에 들어가는 법을 정리했다.

슬랙이 실제로 요구하는 것

커스텀 이모지 추가에 대한 슬랙 자체 고객센터 문서는 명확하게 말한다: "128KB 미만의 정사각형 이미지, 투명 배경이 가장 잘 동작합니다. 이미지는 JPG, PNG, GIF 형식일 수 있습니다." 애니메이션 이모지에 대해서는 같은 문서가 별도의 상한을 하나 더 얹는다: "GIF는 최대 50프레임까지 포함할 수 있습니다." 서로 다른 두 제한이 겹쳐 있는 셈이다 — 용량 예산과 프레임 예산 — 그리고 하나를 통과해도 다른 하나에서 걸릴 수 있다.

표현을 정확히 짚어둘 필요가 있다: 정사각형·투명 배경 부분에 대해 슬랙 자신이 쓴 표현은 "가장 잘 동작합니다"이지 "필수"가 아니다. 정사각형이 아니거나 투명 배경이 없는 GIF가 128KB나 50프레임을 넘는 경우처럼 곧바로 거부되는 건 아니다 — 다만 슬랙 스스로 권장하는 형태이고, 16:9 화면 녹화 클립을 작고 둥근 이모지 자리에 욱여넣는 건 딱 정사각형이 "가장 잘 동작하는" 그런 이미지에 해당한다.

평범하게 내보내면 왜 금방 128KB를 넘는가

128KB는 아주 작은 예산이다 — 휴대폰으로 찍은 사진 한 장보다도 작은 경우가 많다. 애니메이션 GIF는 담고 있는 프레임 하나하나에 바이트를 써야 하는데, NearVid의 기본 GIF 설정(10fps, 너비 320px)은 이런 한계를 겨냥한 게 아니라 평범하게 보기 좋은 클립을 겨냥해 맞춰져 있다. 이 예산을 좌우하는 변수는 크게 둘이다:

• 프레임 수. 초당 프레임 수에 재생 시간(초)을 곱한 값이 전체 프레임 수이고, 그 프레임 하나하나가 바이트를 소모한다. 10fps로 10초면 100프레임 — 용량 예산을 따지기도 전에 이미 슬랙의 50프레임 상한의 두 배다.
• 프레임당 픽셀 수. 더 넓게 내보내면 프레임마다 인코드해야 할 픽셀이 늘어난다. GIF는 팔레트 기반이고 프레임 간 예측이 거의 없는 압축 방식이라(영상 코덱의 모션 보상 프레임 간 예측 같은 게 없다), 이 바이트 증가는 해상도에 대해 최신 영상 코덱보다 훨씬 더 선형에 가깝게 늘어난다.

재생 시간은 이 둘을 동시에 곱하는 입력값이다 — 클립이 길어지면 프레임 수도 늘고, 뭔가 움직이는 장면이라면 프레임마다 인코드해야 할 변화량도 늘어난다. 그래서 가장 나중이 아니라 가장 먼저 줄여야 할 값이 바로 재생 시간이다.

여기서 NearVid가 실제로 주는 세 가지 조절값

NearVid의 GIF 내보내기는 정확히 세 가지 조절값을 제공하고, 각각이 슬랙의 두 상한에 다르게 걸린다:

• 재생 시간 — 먼저 트림한다. NearVid의 트림은 무손실 스트림 복사다 — 실제로 원하는 초만 남기고 잘라내는 데 별도 비용이 들지 않고, GIF 인코딩이 시작되기도 전에 끝난다. 전체 클립을 그대로 내보내고 요행을 바랄 이유가 없다. NearVid의 GIF 내보내기는 요청 값과 무관하게 재생 시간을 10초로 강제 상한한다 — 도구 자신의 소스 코드 주석이 밝히듯 "GIF는 금방 커지기 때문에" 존재하는 상한이다. 슬랙 이모지를 만들 땐 이 10초 상한에 바짝 붙는 게 아니라 훨씬 아래로 잘라내야 한다.
• 프레임레이트 — fps 프리셋으로. NearVid는 5·10·15fps라는 고정된 세 가지 옵션만 제공한다, 자유 슬라이더가 아니다. 가장 낮은 5fps 프리셋에서 10초 클립은 정확히 50프레임 — 슬랙의 상한에 여유 하나 없이 딱 걸쳐 있는 셈이다. 5fps에서 재생 시간을 10초보다 훨씬 짧게 줄이면 프레임 수도 그만큼 비례해서 줄어든다 — 이게 핵심이다. 5fps에 2초면 10프레임이고, 슬랙 상한 안에 여유 있게 들어간다.
• 너비 — 너비 프리셋으로. NearVid는 240·320·480px라는 고정된 세 가지 프리셋을 제공하고, 높이는 항상 원본의 종횡비 그대로 자동으로 계산한다(내부 ffmpeg 필터의 scale=width:-1). 정사각형으로 잘라주는 크롭 옵션은 없다 — 16:9 화면 녹화는 어떤 너비 프리셋으로 내보내도 16:9 그대로, 크기만 작아진다. 여기서 실제로 골라야 할 건 가장 좁은 240px 프리셋이다 — 프레임 수가 이미 작은 상태에서는 fps보다 픽셀 수를 줄이는 쪽이 용량 예산에 더 크게 작용한다.

업로드를 반복하지 않고 도달하는 순서

종합하면, 재시도를 가장 줄이는 순서는 이렇다. 먼저 트림으로 1~3초 정도까지 잘라낸다 — 엔진의 10초 상한과 슬랙의 50프레임 상한 둘 다보다 훨씬 아래로. 그다음 NearVid가 제공하는 두 축에서 가장 좁은 프리셋인 5fps·240px로 GIF를 내보낸다. 업로드하기 전에 실제 결과 파일 크기를 직접 확인한다 — NearVid의 WebM·MP4 내보내기는 품질 선택 옆에 "≈" 예상 용량을 실행 전에 미리 보여주지만, 이 추정치는 GIF 출력에는 아예 적용되지 않는다. 그래서 여기엔 미리보기 숫자가 없고, 내보내기가 끝나야 실제 크기를 알 수 있다. 그래도 128KB를 넘는다면 다음으로 줄여야 할 건 다시 재생 시간이지 fps나 너비가 아니다 — 1초를 더 잘라내는 쪽이 프리셋을 더 낮추는 것보다 용량에 훨씬 크게 작용한다.

NearVid가 여기서 하지 않는 일

범위를 정확히 짚자면: NearVid는 정사각형으로 크롭하거나 투명 배경을 넣어주지 않고, 슬랙의 제한 자체를 전혀 알지 못한다 — "128KB 목표" 모드나 슬랙 전용 프리셋은 없고, 어디에도 대신 업로드해주지 않는다. 너비 프리셋은 240px에서 멈춘다 — 특정 클립의 내용상 240px로도 충분히 작지 않다면 그보다 더 좁은 값을 직접 입력할 방법이 없다. fps 프리셋도 5fps에서 멈추므로 2초에 10프레임보다 더 낮게는 갈 수 없다. 세 가지 내보내기 모두 여전히 전부 온디바이스로 실행된다 — 클립이 GIF로 바뀌는 동안 브라우저 탭을 벗어나지 않는다 — 하지만 특정 클립을 특정 외부 용량 상한 아래로 맞추는 일은 여전히 직접 확인하고 재시도하는 수작업이지, NearVid가 보장해 주는 일은 아니다.

정직한 요약

슬랙 자체 도움말 문서는 커스텀 이모지 GIF에 대해 실제로 서로 다른 두 상한을 둔다: 128KB 미만, 그리고 최대 50프레임. NearVid의 기본 GIF 설정은 둘 중 어느 쪽도 겨냥하고 있지 않지만, 트림·fps· 너비 조절값을 의도적으로 조합하면 도달할 수 있다: 먼저 1~3초로 트림하고(무료, 무손실), NearVid가 제공하는 것 중 가장 좁은 5fps·240px 프리셋으로 내보낸 다음, 실제 결과 파일 크기를 직접 확인한다 — GIF 출력은 WebM이나 MP4와 달리 NearVid의 "≈" 용량 추정치가 미리 나오지 않기 때문이다. 셋 중 가장 크게 작용하는 조절값은 재생 시간이다 — fps나 너비를 다시 만지기 전에 먼저 그것부터 손대는 게 맞다.