개발자용 화면 녹화 GIF 자동화 — README 데모를 명령어 한 줄로 만들기

GitHub README에 데모 GIF 하나가 있고 없고의 차이는 크다. 글로 열 줄 설명하는 것보다 3초짜리 GIF 한 장이 프로젝트를 훨씬 잘 팔아 준다. 문제는 만드는 과정이 귀찮다는 것이다. 녹화하고, 변환하고, 용량 줄이고… 이걸 릴리스마다 반복하다 보니 결국 명령어 한 줄로 끝나는 파이프라인을 만들게 됐다. 그 과정을 순서대로 정리한다.

1. GIF가 필요한 곳

개발하면서 GIF를 쓰게 되는 지점은 생각보다 많다.

  • README 상단 데모: 프로젝트 첫인상. 핵심 기능 하나를 5초 이내로.
  • 이슈 리포트: "이런 버그가 있다"는 말보다 재현 GIF 한 장이 정확하다.
  • PR 설명: UI 변경 전/후를 GIF로 붙이면 리뷰가 빨라진다.
  • 블로그·문서: 튜토리얼 중간의 동작 확인용.

동영상(mp4)이 화질도 용량도 유리하지만, GIF는 클릭 없이 자동 재생되고 마크다운에 이미지처럼 박히는 것이 강점이다. GitHub 이슈·PR에는 mp4 첨부도 되지만 README 안에서의 자동 재생은 여전히 GIF가 편하다.

2. 녹화 도구 선택

녹화 자체는 어떤 도구든 mp4만 나오면 된다. 실제로 써 본 조합은 이렇다.

도구용도비고
Windows 캡처 도구·게임 바일반 화면 녹화추가 설치 없음, mp4 저장
OBS Studio정밀한 영역·장시간 녹화설정 자유도 최고
ScreenToGif바로 GIF가 필요할 때프레임 단위 편집 가능
asciinema + agg터미널 데모텍스트 기반 녹화 후 GIF 렌더

나는 "일단 mp4로 녹화하고 변환은 스크립트에 맡긴다"로 통일했다. 편집 없이 빠르게 찍을 때는 Windows 기본 녹화(Win+Alt+R), 영역을 정확히 잡을 때는 OBS를 쓴다. GIF 편집 기능이 있는 ScreenToGif도 좋은 도구지만, 매번 GUI에서 수동 저장하는 흐름이라 자동화와는 결이 달랐다.

3. ffmpeg 변환 — 팔레트가 품질을 가른다

mp4를 GIF로 바꾸는 표준 도구는 ffmpeg다. 그런데 아무 옵션 없이 변환하면 색이 지저분하게 뭉개진다. GIF는 256색 제한이 있는데, 기본 변환은 범용 팔레트를 쓰기 때문이다. 해결책은 2패스 팔레트 방식이다. 먼저 영상에 실제로 쓰인 색으로 최적 팔레트를 만들고(palettegen), 그 팔레트로 변환한다(paletteuse). 요즘은 split 필터로 한 명령에 합치는 것이 관례다.

ffmpeg -i demo.mp4 -filter_complex ^
  "fps=12,scale=800:-1:flags=lanczos,split[a][b];[a]palettegen[p];[b][p]paletteuse" ^
  -loop 0 demo.gif

옵션의 의미를 하나씩 보면:

  • fps=12: 초당 12프레임으로 낮춘다. 30fps 원본 그대로면 용량이 감당이 안 된다.
  • scale=800:-1: 폭 800px, 높이는 비율 유지. flags=lanczos는 기본 보간보다 축소 화질이 좋다.
  • palettegen / paletteuse: 앞서 말한 2패스 팔레트.
  • -loop 0: 무한 반복.
GIF 용량을 결정하는 3요소

용량은 결국 프레임 수 × 해상도 × 색상 수의 싸움이다. 터미널 데모처럼 화면 변화가 적은 영상은 fps를 10까지 내려도 어색하지 않다. 더 줄여야 하면 palettegen=max_colors=128처럼 색을 제한하는 방법도 있다. 여기까지 하고도 크면 gifsicle로 후처리한다.

gifsicle -O3 --lossy=80 demo.gif -o demo-small.gif

-O3는 최적화 레벨, --lossy는 약간의 손실을 허용하는 대신 용량을 더 깎는 옵션이다. 데모 GIF 용도에서는 80 정도로도 열화가 거의 눈에 띄지 않았다.

4. 명령어 한 줄로 자동화

이제 이 과정을 묶는다. 목표는 togif demo.mp4 한 줄이다.

화면 녹화에서 README까지 자동화 파이프라인

Windows PowerShell이라면 프로필($PROFILE)에 함수를 등록한다.

function togif {
  param(
    [Parameter(Mandatory)] [string]$Input,
    [int]$Fps = 12,
    [int]$Width = 800
  )
  $out = [IO.Path]::ChangeExtension($Input, ".gif")
  $filter = "fps=$Fps,scale=${Width}:-1:flags=lanczos," +
            "split[a][b];[a]palettegen[p];[b][p]paletteuse"
  ffmpeg -i $Input -filter_complex $filter -loop 0 $out
  if (Get-Command gifsicle -ErrorAction SilentlyContinue) {
    gifsicle -O3 --lossy=80 $out -o $out
  }
  Get-Item $out | Select-Object Name, @{n="MB";e={[math]::Round($_.Length/1MB,2)}}
}

macOS/Linux(WSL 포함)라면 .bashrc에 같은 내용을 함수로 넣으면 된다.

togif() {
  local in="$1" fps="${2:-12}" width="${3:-800}"
  local out="${in%.*}.gif"
  ffmpeg -i "$in" -filter_complex \
    "fps=$fps,scale=$width:-1:flags=lanczos,split[a][b];[a]palettegen[p];[b][p]paletteuse" \
    -loop 0 "$out" && gifsicle -O3 --lossy=80 "$out" -o "$out"
  du -h "$out"
}

이후 워크플로는 이렇게 단순해진다. ① Win+Alt+R로 녹화 → ② togif demo.mp4 → ③ 나온 GIF를 리포지토리에 커밋. 상황에 따라 fps나 폭만 인자로 조절한다. ffmpeg와 gifsicle은 winget(winget install ffmpeg, winget install gifsicle)이나 각 OS 패키지 매니저로 설치할 수 있다.

5. 자주 겪는 문제와 해결

파이프라인을 굴리면서 실제로 부딪힌 문제 몇 가지도 남겨 둔다.

  • 글자가 흐릿하게 뭉개진다: 대부분 해상도를 너무 줄인 탓이다. 코드나 터미널 텍스트가 들어간 데모라면 폭을 800px 아래로 내리지 않는 것이 좋다. 반대로 녹화할 때부터 창 크기를 줄이고 에디터 글꼴을 키워서, 축소 자체가 덜 필요하게 만드는 것이 근본 해결책이었다.
  • 그라데이션 배경에 띠가 생긴다: 256색 한계로 생기는 밴딩 현상이다. paletteuse의 디더링 옵션(paletteuse=dither=floyd_steinberg 등)을 조절하면 완화된다. 애초에 데모 녹화 시 단색 배경 테마를 쓰면 용량도 줄고 밴딩도 사라진다.
  • 마우스 커서가 안 보인다/거슬린다: 녹화 도구 설정에 커서 포함 여부 옵션이 있다. 클릭 위치가 중요한 데모라면 커서 강조를 켜고, 텍스트 중심 데모라면 커서를 빼는 편이 깔끔하다.
  • 변환 결과가 뚝뚝 끊겨 보인다: fps를 너무 내린 경우다. 스크롤이나 애니메이션이 들어간 데모는 12~15fps, 정적인 터미널 데모는 10fps가 적정선이었다.

6. 리포지토리에 넣는 팁

  • 경로: GIF는 docs/ 폴더에 모은다. 코드와 섞이지 않고, README에서는 ![demo](docs/demo.gif)로 참조한다.
  • 용량 상한: GitHub는 개별 파일 첨부·표시에 용량 제한이 있으므로 GIF는 수 MB 이내를 목표로 한다. 10MB를 넘기면 다이어트가 필요하다는 신호다.
  • 재촬영 대비: GIF의 원본 mp4를 함께 보관해 두면(리포지토리 밖에라도) UI가 바뀌었을 때 재변환이 쉽다.
  • 바이너리 히스토리 주의: GIF를 자주 갈아끼우면 git 히스토리가 무거워진다. 교체가 잦은 프로젝트라면 릴리스 첨부나 이슈 첨부 URL을 README에 링크하는 방법으로 히스토리 오염을 피할 수 있다.

한 번 세팅해 두니 데모 GIF 만들기가 "귀찮은 일"에서 "녹화 버튼 누르고 명령어 한 줄"로 바뀌었다. README 품질은 곧 프로젝트 첫인상이니, 이 정도 투자면 충분히 남는 장사다.

함께 보면 좋은 글: 윈도우11 화면녹화 방법 4가지

※ 이 글의 도구 버전과 명령 옵션은 2026년 기준이며 변경될 수 있습니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

메일 주소 하나 만들려다 브랜드를 세웠다 — 1인 스튜디오 브랜딩 실전기

이미지
메일 주소 하나 만들려다, 브랜드를 통째로 세웠다 1인 스튜디오 브랜딩 실전기 — 도메인 · 메일 · 로고 · 상표 출원까지 직접 해본 기록 시작은 단순했다. " 내이름@내스튜디오.com 같은 전문적인 메일 주소 하나 갖고 싶다." 딱 그거였다. 그런데 그 한 가지 바람이 도메인 선정, 브랜드 네이밍, 상표 검색, 로고 제작, 메일 서버 인증, 상표 출원까지 줄줄이 이어졌다. 결국 1인 개발/콘텐츠 스튜디오 ‘에이븐스튜디오(Aeven Studio)’ 의 기반을 통째로 세우게 됐다. 같은 길을 걸을 다른 1인 창작자들을 위해, 부딪힌 함정과 배운 것을 정리한다. 1. 자체 메일 서버? 결론은 ‘관리형’ 처음엔 멋있어 보여서 메일 서버를 직접 굴려볼까 했다. 알아보니 개인이 자체 발송 서버를 운영하는 건 생각보다 가시밭길이다. 가정용 IP는 대부분 스팸 차단 목록에 기본 등록돼 있어 받는 쪽이 거부한다. 발송 포트(25번)가 막혀 있고, 역방향 DNS(PTR)를 내 맘대로 못 건다. AWS EC2조차 25번 포트가 기본 차단이고 IP 평판이 좋지 않다. 결론: 비즈니스 메일이라면 Google Workspace · Zoho · 네이버웍스 같은 관리형 서비스 가 정답이다. 서버·보안·스팸·도달률이라는 골치 아픈 문제를 통째로 넘길 수 있다. 나는 익숙함과 생태계 통합 때문에 Google Workspace로 정했다. 2. 이름 짓기 — 가장 오래 헤맨 구간 여기서 제일 많이 배웠다. 좋은 이름을 정하는 건 ‘감각’의 문제가 아니라 세 개의 관문을 동시에 통과 시키는 문제였다. 이름 하나가 통과해야 할 세 관문 후보 이름 "이거 어때?" 관문 ① 상표 KIPRIS 검색 내 사업류에 살아있는 유사 상표 없어야 'AI' 등 설명적 단어는 식별력 없음 관문 ② 도메인 진짜 병목 구간 어감 좋은 단어는 .com이 이미 선점됨 해법: .kr/.app 수용 또는 조어(coined word) 관...
자세한 내용 보기

클로드 Fable 5와 Opus 4.8 비교 - 차이점, 가격, 무료 기간 종료 후 변화까지 총정리 (7월 최신)

이미지
2026년 6월 9일, Anthropic이 5세대 모델 가족의 첫 주자인 Claude Fable 5 를 공개했다. 기존 최상위 모델이던 Opus 4.8과 무엇이 다른지, 구독 플랜에서는 어떻게 제공되는지, 그리고 출시 직후 벌어진 접근 중단 사태까지, 실제 사용 과정에서 확인한 내용을 정리한다. 새 모델을 써볼지 고민 중이거나 갑자기 모델 접근 오류를 만난 사람에게 도움이 될 것이다. Fable 5란 어떤 모델인가 Fable 5는 Anthropic의 모델 계층에서 가장 위에 있는 Mythos급(Mythos-class) 모델이다. 기존 계층이 Haiku → Sonnet → Opus 순서였다면, 이제 그 위에 Mythos 등급이 추가된 셈이다. 배경을 보면 Anthropic은 같은 해 4월에 Mythos를 먼저 공개했지만, 고급 사이버보안 능력 때문에 일부 승인된 고객에게만 제한적으로 배포했다. Fable 5는 그 Mythos 기술에 안전장치를 더해 일반 사용자도 쓸 수 있게 만든 버전이다. 함께 발표된 Claude Mythos 5는 여전히 일반 출시되지 않았으며, 두 모델은 본질적으로 같은 기반 모델이다. Fable 5 vs Opus 4.8 - 핵심은 용도의 차이 두 모델의 가장 중요한 차이는 성능 수치가 아니라 용도 다. Fable 5는 모델이 스스로 작업을 분해하고 조사하고 만들고 검증하는 장기 비동기 프로젝트 에 적합하고, Opus 4.8은 복잡한 작업을 사람과 주고받으며 처리하는 빠른 동기적(실시간) 협업 에 적합하다. Fable 5의 강점으로 알려진 내용은 다음과 같다. Claude Code 같은 에이전트 환경에서 며칠 동안 작업을 지속 하며, 단계별로 계획하고 하위 에이전트에 위임하고 자기 작업을 검증한다. 5천만 줄 규모의 Ruby 코드베이스에서, 팀이 수작업으로 2개월 넘게 걸릴 전체 마이그레이션을 하루 만에 수행한 사례가 소개됐다. 파일과 PDF 안에 중첩된 다이어그램·차트·표를 이해하는 비전 능력이 강화되어 금융·법률...
자세한 내용 보기

구글 labs-fx - 제미나이 - 클라우드 차이점 알아보기

이미지
구글의 AI 서비스가 많아지면서 labs.google/fx, Gemini, Google Cloud(Vertex AI) 가 각각 뭐고 어떻게 다른지 헷갈리기 쉽다. 세 가지는 경쟁 관계가 아니라 계층이 다른 서비스 다. 하나씩 정리해본다. labs.google/fx란? 구글 랩스(Google Labs)의 창작 도구 모음 이다. "구글의 AI 실험들이 모여 있는 곳"이라는 슬로건 그대로, 아직 정식 제품은 아니지만 일반인에게 공개해서 써보게 하는 생성형 AI 창작 도구들의 허브다. 이미지·영상·음악 생성에 특화되어 있다. 대표 도구 Flow (flow.google) — 텍스트로 이미지·영상을 만드는 통합 창작 스튜디오. Veo(영상)·Imagen(이미지) 기반으로 ImageFX·Whisk를 흡수했고, 현재는 labs.google/fx에서 독립했다. MusicFX — 텍스트→음악/사운드 생성기 (labs.google/fx 잔류) Project Genie — 가상 세계를 생성·탐험하는 실험 도구 (labs.google/fx 잔류) ImageFX·Whisk — 종료됨. 기능은 Flow로 통합 2026년 7월 현재, 직접 들어가 보니 지금 labs.google/fx 홈에는 Project Genie와 MusicFX 두 개만 남아 있다. "무엇이든 만들어 보세요"라는 카피 아래 두 카드가 전부이고, 상단에 "flow.google에서 Flow를 사용해 보세요" 라는 배너가 떠 있다. ImageFX·Whisk는 Flow로 흡수됐고, 그 Flow는 flow.google이라는 독립 사이트로 분리 됐다. 이용에는 구글 계정 로그인이 필요하다.      2026년 7월 현재 labs.google/fx 홈 — Project Genie와 MusicFX만 남았다 Flow는 이렇게 생겼다 flow.google 홈은 "Make your own Tools in Google Flow...
자세한 내용 보기