• Recovered Factory는 며칠마다 갱신되는
  라이브 데이터를 사람이 매번 편집하지 않고 소셜 영상으로 만들기 위해 웹 기반 “asset bakery” 워크플로를 구축함
• 영상의 원본은 편집 파일이 아니라
  숨겨진 웹 페이지이며, Playwright가 브라우저를 프레임별로 움직이고 ffmpeg가 이를 MP4와 GIF로 묶음
• 짧은
  storyboard.ts와 단일 playhead가 오늘 수치, 페이드, 2024년 12월 시작점, 18개월 성장 구간을 약 14초 클립으로 구성함
• 예약된 GitHub Action은 데이터 변경을 감지해 사이트를 재빌드·재배포하고, 비율과 언어 조합에 따른
  4개 컷을 만들어 CloudFront CDN에 게시함
• YouTube는 미공개 초안 업로드가 가능하지만 Instagram은 바로 공개 게시만 지원해, 최종 검토와 캡션 편집을 위한
  사람의 승인 단계를 유지함

웹 페이지를 영상 원본으로 쓰는 구조

• 영상은 별도 편집 프로젝트가 아니라 웹사이트 안의
  숨겨진 전용 페이지에서 출발함

• 이 페이지는 Reels, Shorts, TikTok에서 쓰는 세로형
  9:16 화면에 맞춰 설계됨

• 화면에는 라이브 사이트의 기존 요소를 재사용함

• 헤드라인

• 큰 기관 수치

• 애니메이션 차트

• 전국 지도

• 작은 크레딧 라인

• 웹 브라우저의 타임라인 애니메이션과 모션 효과를 활용하고, 컴퓨터가 사용자에게 보이지 않는
  헤드리스 브라우저를 제어함

• 일반 웹 페이지처럼 브라우저에서 직접 열어 앞뒤로 넘기며 미리보기와 디버깅을 할 수 있음

• 사이트의 다국어 프레임워크를 그대로 상속해 지원 언어별 영상을 캡처할 수 있음

• 이 프로젝트의 asset bakery, 데이터 파이프라인, 프론트엔드는 open source로 공개되어 있음

storyboard.ts와 playhead

• storyboard.ts 파일 하나가 영상의 타이밍과 변환을 감독의 샷 리스트처럼 정의함

• 구성은 몇 개의 이름 붙은 beat와 지속 시간으로 이뤄짐

• 오늘의 전체 수치를 1.5초 유지

• 0.7초 페이드

• 데이터가 시작되는 2024년 12월 지점을 1.5초 유지

• 이후 18개월 성장 구간을 앞으로 재생

• 다시 오늘 화면에 정착

• 전체 결과물은 약
  14초 클립임

• 차트 그리기, 지도 점 표시, 카운터 증가는 하나의
  playhead에 묶여 움직임

• playhead는 특정 timestamp에서 모든 컴포넌트가 같은 상태를 렌더링하게 해 화면 요소가 서로 어긋나지 않게 함

프레임별로 “굽는” 방식

• 실제 영상 파일은 헤드리스 브라우저에서 웹 페이지를 열고, Playwright로 Chromium을 제어해 만듦

• 처음에는 가상으로 재생 버튼을 누른 뒤 화면 녹화로 캡처할 수 있다고 봤지만, 실시간 녹화는 프레임 누락이나 끊김이 생길 수 있었음

• 같은 영상도 로컬에서는 부드럽게 돌아가고 클라우드 하드웨어에서는 다르게 동작할 수 있었으며, 초기 실험 중에는 때때로 비정상적으로 빠르게 재생되기도 함

• 더 안정적인 결과를 위해 실시간 녹화 대신
  flipbook처럼 프레임을 하나씩 생성함

• 페이지에 “0.04초 시점의 모습을 보여달라”고 지시

• 스크린샷을 찍음

• 0.08초로 이동해 다시 스크린샷을 찍음

• 이 과정을 수백 번 반복함

• 얼어 있는 페이지를 손으로 넘기듯 진행하기 때문에 각 이미지는 완전히 렌더링된 상태로 캡처됨

• 결과는
  결정적이고 테스트 가능하며, 두 번 실행하면 검증 가능하게 동일한 프레임을 얻어야 함

• 프레임 수를 두 배로 늘리면 렌더링에 필요한 계산 시간과 저장 공간도 대략 두 배가 됨

서버 렌더링을 안정화하는 세부 처리

• 전국 지도는 MapLibre GL JS를 사용하며, 일반적으로 GPU를 기대하는 WebGL 코드로 렌더링함

• 서버에는 GPU가 없으므로 Chromium이
  소프트웨어 렌더링을 사용하도록 설정함

• 실제 그래픽 하드웨어보다 느림

• 거의 모든 플랫폼에서 같은 품질로 실행 가능함

• 각 프레임은 PNG가 아니라
  JPEG로 저장함

• 스크린샷에서 PNG 인코딩이 느린 부분임

• 결과 영상은 동일하게 보이므로 수백 프레임 전체에서 속도 이득이 생김

• 헤드리스 브라우저가 컨테이너 안의 bare server에서 안정적으로 실행되도록 몇 가지 플래그가 필요하며, 전체 세부 사항은 공개 저장소에 있음

• 생성된 수백 장의 이미지는 ffmpeg로 MP4와 반복 GIF로 이어 붙임

GitHub Action 기반 자동화

• 전체 과정은 예약된
  GitHub Action으로 실행되는 자동 데이터 파이프라인에 연결됨

• 하루에 몇 번 데이터가 바뀌었는지 확인함

• 새 데이터가 들어오면 작업은 다음을 수행함

• 사이트 재빌드

• 사이트 재배포

• 정사각형/세로 비율과 영어/스페인어 조합의
  4개 컷 생성

• CloudFront CDN에 게시

• 공개 다운로드 페이지는 지원 언어별 최신 컷을 제공함

• 마지막 단계에는 YouTube 초안 업로드와 Instagram 게시 알림이 포함됨

자동화와 편집 통제의 경계

• 이 프로젝트는 완전 자동화를 배제하지 않지만, 모든 영상이 나가기 전
  사람의 검토를 유지함
• 헤드라인과 캡션에 대한 편집 통제, 최종 리뷰, 게시 방식 판단은 사람이 맡음
• 입력 데이터가 나쁘거나 시스템이 잘못된 결과를 만들 수 있기 때문에 맹목적인 자동 게시를 피함
• YouTube는 공식 API로 미공개
  초안 영상을 생성함
• Instagram API는 바로 공개 게시만 지원하므로, 새 데이터가 있을 때마다 YouTube 초안을 만들고 Instagram 게시를 수동으로 만들라는 이메일 알림을 보냄

웹 디자인으로 끝나는 소셜 영상 제작

• 이 방식의 장점은 영상 디자인이 곧
  웹 디자인이 된다는 점임

• After Effects, 수동 재내보내기, 오래된 수치, 바쁜 웹 프로듀서에 의존하지 않음

• 색상이나 라벨 변경은 한 줄 수정으로 끝나고, 다음 렌더링에 반영됨

• 전체 시스템은 기존 도구 주위의 몇백 줄짜리 glue code로 구성됨

• 데이터 파이프라인

• 헤드리스 브라우저

• 사이트에서 이미 쓰는 지도와 차트

• ffmpeg

• 실행 비용은 월 몇 달러 수준임

• 비교 대상으로 든 Missouri Vehicle Stops MCP는 현재 월 약
  50달러 비용이 드는 것으로 보임

• asset bakery는 MCP보다 사용자당 비용이 낮고, MCP는 더 깊은 데이터 참여를 제공하는 도구에 가까움

전략과 “shortcut”의 역할

• 고품질 공유용 자동 생성 자산으로 주류 플랫폼에 대응하면서, 깊이 관여하는 사용자를 위해 MCP 같은 현대적 데이터 도구도 함께 지원하는 전략임
• 목표는 바이럴 서커스나 불명확한 일반 대중, 모두에게 맞는 단일 제품이 아님
• shortcut은 속임수가 아니라 이미 있는 자원을 활용해 더 멀리 가고 덜 소진되기 위한 방법임
• GitHub Action으로 기존 자원을 묶으면, 영상을 만들고 싶거나 상황이 정말 요구할 때만 영상에 대해 생각하면 됨

댓글과 토론