LLM은 영상을 보지 않는다. 읽는다

LLM은 영상을 보지 않는다. 읽는다.
원본 영상들을 폴더에 넣고 Claude Code한테
"이걸로 론칭 영상 만들어줘"
라고 하면 final.mp4가 튀어나온다.
browser-use 팀이 풀어버린 video-use 리포에서 가장 놀라운 건 기술 스택이 아니라 이 한 문장이었다.

숫자부터 보면 이해가 된다.
raw footage 한 편에서 프레임을 전부 뽑으면 대략 30,000장.
프레임당 1,500 토큰으로 잡으면 45M 토큰이다.
그대로 LLM에 밀어넣을 수 없다.
그래서 이 팀이 선택한 건 오디오 트랜스크립트 12KB + 필요할 때만 호출하는 타임라인 PNG였다.
영상을 텍스트로 납작하게 만들어서 읽게 하는 거다.

이 구조가 낯설지 않은 이유가 있다.
browser-use가 그동안 해오던 게 똑같은 원리다.
브라우저 자동화에서도 LLM에게 스크린샷을 주지 않는다.
DOM을 준다. 사람 눈에 보이는 픽셀이 아니라,
기계가 읽을 수 있는 표현으로 추론시킨다.
video-use는 같은 사고방식을 영상에 얹었을 뿐이다.
렌더링된 결과가 아니라 구조화된 표현으로 추론한다.
-> 이게 이 팀의 일관된 문법이다.

파이프라인도 이 원칙을 따른다.
Transcribe로 오디오를 뽑고,
Pack으로 토큰을 압축하고,
LLM Reasons가 편집 판단을 내리고,
EDL(편집 결정 리스트)로 컷을 정리하고,
Render가 최종본을 만들고,
Self-Eval이 컷 경계마다 되돌아가 재검증한다.
필러 단어 제거, 자동 컬러 그레이드, 30ms 오디오 페이드, 서브타이틀 번인, Manim 애니메이션까지 전부 병렬 서브에이전트로 분배한다.

공개된 게 4월 12일이다.
오늘이 4월 19일이니 6일 지났다.
그 사이에 1,352 stars가 붙었다.
속도보다 내가 더 흥미롭게 본 건 이들이 같은 가설을 여러 도메인에 계속 찍어내고 있다는 점이다.
브라우저에서도, 영상에서도, 답은 "LLM에게 픽셀을 주지 말고 표현을 줘라"였다.
다음에 이들이 손대는 도메인이 뭐가 될지 상당히 궁금해진다.