영상 제작의 진입장벽이 무너지고 있다. 그런데 무너지는 방식이 예상과 다르다. 생성 AI가 픽셀을 뚝딱 만들어내는 것이 아니라, AI 에이전트가 코드를 써서 영상을 조립하는 쪽으로 흐름이 기울고 있다. HyperFrames와 Remotion이 나란히 등장하면서 이 패러다임이 선명해졌다.
두 프레임워크는 같은 문제를 다른 철학으로 푼다. Remotion은 React 컴포넌트가 곧 영상 프레임이다. TypeScript, Fast Refresh, npm 생태계—웹 개발자가 이미 쓰는 도구를 그대로 영상으로 확장한다. 재사용 가능한 컴포넌트, 상태 기반 애니메이션, 풍부한 생태계가 강점이다. 반면 번들러가 필요하고, GSAP 같은 클럭 기반 애니메이션은 렌더링 시 wall-clock으로 재생되어 프레임 정확도가 흔들린다.
HyperFrames는 정반대 방향에서 온다. 빌드 단계 없이 index.html이 그대로 영상 컴포지션이 된다. React도, 독자적 DSL도 없다. 순수 HTML + CSS + GSAP만으로 MP4를 뽑아낸다. 얼핏 단순해 보이지만 이 선택에는 뚜렷한 의도가 있다. AI 코딩 에이전트—Claude Code, Codex, Cursor—가 가장 자연스럽게 다루는 언어가 바로 HTML이기 때문이다. 에이전트가 "10초짜리 제품 소개 영상, 페이드인 타이틀, 배경 음악 포함"이라는 자연어를 받아 HTML을 직접 작성하고, 결과를 즉시 미리보기하고, 수정 루프를 돌리는 워크플로우에 최적화된 구조다. 결정적(Deterministic) 렌더링으로 동일 입력은 동일 출력을 보장하니, 자동화 파이프라인에 꽂기도 깔끔하다.
프론트엔드 개발자 관점에서 이 둘의 대비는 흥미로운 설계 질문을 던진다. 에이전트 친화성을 위해 추상화를 얼마나 걷어낼 것인가? React의 컴포넌트 모델은 인간 개발자에게 강력한 도구지만, 에이전트 입장에서는 번들러 설정, JSX 변환, 타입 오류 등 마찰 포인트가 늘어난다. HTML은 그 마찰이 없다. 에이전트가 파일을 열고, 수정하고, 브라우저에서 확인하는 루프가 단순해진다. HyperFrames가 Apache 2.0 라이선스로 상업적 사용에 제한을 두지 않은 것도 에이전트 기반 자동화 파이프라인을 염두에 둔 포지셔닝으로 읽힌다.
그런데 여기서 한 발 물러서면 더 근본적인 문제가 보인다. 에이전트가 HTML을 빠르게 쓸 수 있다고 해서 좋은 영상이 나오는 건 아니다. 어떤 장면 순서로, 어떤 텍스트를, 어떤 흐름으로 구성할지—이 '무엇을 만들지'가 정리되지 않은 채로 에이전트에게 던지면, 에이전트는 그럴듯하지만 엉뚱한 결과를 빠르게 만들어낸다. 수정하고, 다시 설명하고, 다시 수정하는 루프가 시작된다.
LAO는 바로 그 앞단을 건드리는 도구다. macOS 네이티브 앱으로, 아이디어를 Claude Code·Codex 같은 개발 AI가 실행할 수 있는 구조화된 설계서로 변환해준다. IdeaBoard에서 방향을 탐색하고, Design Workflow에서 화면·흐름·데이터·API 단위로 분해한 뒤, Work Graph와 Deliverable Spec으로 결과를 남긴다. 핵심 통찰은 단순하다. "긴 채팅은 시간이 지나면 맥락이 흐려진다. 사람도 헷갈리고 AI도 헷갈린다." 그래서 대화 대신 구조화된 결과물을 기준점으로 삼는다.
세 도구를 하나의 워크플로우로 이어보면 윤곽이 잡힌다. LAO로 '무엇을 만들지' 설계서를 정리하고 → HyperFrames나 Remotion에 에이전트 스킬을 붙여 실제 영상 코드를 생성하고 → 결과를 즉시 미리보기하며 반복한다. 빠른 프로토타이핑 → 검증 → 고도화라는 흐름이 에이전트 레이어에서 그대로 구현된다. 여기서 LAO가 풀려는 문제는 단순히 설계 메모 앱이 아니다. 에이전트에게 넘기는 인풋의 품질을 높이는 장치다.
시사점은 명확하다. AI 에이전트가 빠르게 구현할 수 있다면, 잘못된 방향도 빠르게 구현된다. 영상 자동화 파이프라인을 구축할 때도, 코드 생성 워크플로우를 설계할 때도—생성 속도를 끌어올리는 것보다 에이전트에게 넘기기 전 구조를 잡는 단계가 실질적인 병목이다. HyperFrames의 에이전트 친화적 단순함과 Remotion의 React 생태계 활용은 각각의 맥락에서 유효한 선택지다. 하지만 두 도구 모두, 에이전트에게 주는 컨텍스트가 명확하지 않으면 그 능력의 절반도 쓰지 못한다.
앞으로 주목할 방향은 두 가지다. 첫째, 에이전트 친화적 설계가 프레임워크 선택의 기준으로 자리잡을 것이다. '개발자가 쓰기 편한가'보다 '에이전트가 실수 없이 다룰 수 있는가'가 더 중요한 평가 축이 된다. 둘째, LAO 같은 '설계 전 단계' 도구의 역할이 커진다. 에이전트 도구가 고도화될수록 오히려 '무엇을 만들지 정확히 정리하는 단계'의 가치가 올라간다. 실행이 빨라질수록, 방향을 잡는 판단이 더 결정적이다.