HTML로 쓰면 영상이 나온다, HeyGen의 오픈소스 HyperFrames

릴리스 노트를 올릴 때마다 같은 모양의 6초짜리 제목 영상을 붙여야 하는 개발자를 떠올려 봅니다. 편집 프로그램을 열기에는 짧고, 그렇다고 손으로 매번 만들자니 제목 문구 하나 바꾸는 일에도 프로젝트 열기, 구간 찾기, 내보내기를 되풀이해야 합니다. HeyGen이 공개한 오픈소스 HyperFrames는 이 영상을 HTML 파일 하나로 적고, 그 페이지를 한 프레임씩 찍어 MP4로 묶는 도구입니다. 이 글은 그 6초짜리 장면 하나를 실제로 짜 보면서 속성과 규칙, 렌더 과정을 따라갑니다. 코드는 공식 문서의 규칙에 맞춰 편집부가 만든 예시이고, 터미널 출력은 직접 돌려 본 것이 아니므로 싣지 않았습니다.

2026-10-27 UTC 기준으로 저장소 별은 72,749개, 포크는 6천 6백여 개이고 라이선스는 Apache-2.0입니다. 이틀 전(10월 25일)에 확인한 별 7만 1천 9백여 개에서 8백 가까이 늘었습니다. 개발 속도도 빠릅니다. 10월 25일 03:49(UTC)의 v0.8.195부터 10월 26일 v0.8.205까지 하루 반 동안 정식 릴리스가 열한 번 나왔고, npm의 최신판은 0.8.205입니다. 필요한 것은 Node.js 22 이상과 FFmpeg이며, 렌더링을 내 컴퓨터에서 하는 동안에는 비용도 계정도 없습니다.

시작하는 길은 세 가지입니다. 문서가 첫 번째로 안내하는 Studio 앱은 만들고 싶은 영상을 말로 설명하면 앱 안의 에이전트가 만들어 주는 방식이고, 무료 HeyGen 계정으로 로그인하며 Mac, Windows(64비트), Linux용이 있습니다. 두 번째는 Claude Code나 Codex 같은 코딩 에이전트에 스킬을 설치하는 길, 세 번째는 CLI를 직접 쓰는 길입니다. 이 글은 세 번째 길로 갑니다. 에이전트가 결국 쓰는 것도 같은 HTML 파일과 같은 CLI 명령이라서, 한 번 손으로 짜 보면 나머지 두 길에서 무슨 일이 일어나는지 읽힙니다.

폴더 하나, 파일 하나에서 시작한다

환경 점검과 새 프로젝트, 브라우저 미리보기는 세 줄입니다.

npx hyperframes doctor           # FFmpeg 등 내 컴퓨터 환경 점검
npx hyperframes init my-video    # 프로젝트 폴더 생성
cd my-video
npx hyperframes preview          # 브라우저 편집기에서 실시간 미리보기

공식 문서가 정의하는 영상 본체는 프로젝트 루트의 index.html 하나입니다. 이 파일이 최상위 구성안이고, 장면이 커지면 compositions/ 폴더에 다른 HTML을 나눠 두고 끼워 넣으며 미디어와 글꼴은 assets/에 모읍니다. 오늘 만드는 장면은 나눌 만큼 크지 않아서 index.html 하나로 끝납니다.

그림 1. 직접 쓰는 것은 파일 하나, 나머지는 명령이 남기는 것(편집부가 이 글의 순서대로 그린 구성)

폴더 이름과 결과 파일 이름은 이 글의 예시일 뿐입니다. 렌더링에 --output을 주지 않으면 결과는 프로젝트의 renders/ 폴더에 쌓입니다.

루트 요소가 영상의 크기와 길이를 정한다

영상 한 편의 바깥 틀은 data-composition-id가 붙은 요소 하나입니다. 이 요소에 가로·세로 픽셀(data-width, data-height)과 시작(data-start="0"), 길이(data-duration)를 적습니다. 문서는 루트에 적은 data-duration이 곧 렌더 길이라고 못 박습니다. 컴파일러가 구성안 스크립트가 돌기 전에 이 값을 읽기 때문에 스크립트나 변수로 나중에 바꿀 수 없습니다. 길이를 생략하면 등록된 타임라인이나 미디어 길이로 추정하지만, 장면 전체를 직접 쥐려면 적어 두는 편이 분명합니다.

아래가 오늘 만들 장면의 전체입니다. 1920x1080, 6초, 어두운 남색 바탕에 제목이 떠올랐다가 사라지고 마지막 1.5초에 한 줄이 나옵니다.

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=1920, height=1080" />
  <script src="https://cdn.jsdelivr.net/npm/gsap@3.14.2/dist/gsap.min.js"></script>
  <style>
    body { margin: 0; }
    #stage { position: relative; width: 1920px; height: 1080px; overflow: hidden; background: #101828; }
    .clip { position: absolute; inset: 0; display: grid; place-items: center; }
    #headline { font: 800 140px sans-serif; color: #fff; }
    #tagline { font: 700 96px sans-serif; color: #ffb454; }
  </style>
</head>
<body>
  <div id="stage" data-composition-id="launch" data-start="0" data-duration="6"
       data-width="1920" data-height="1080">
    <section id="title" class="clip" data-start="0.5" data-duration="4" data-track-index="1">
      <h1 id="headline">v1.0 is out</h1>
    </section>
    <section id="endcard" class="clip" data-start="title" data-duration="1.5" data-track-index="1">
      <p id="tagline">Read the notes</p>
    </section>
  </div>
  <script>
    const tl = gsap.timeline({ paused: true });
    tl.fromTo("#headline", { opacity: 0, y: 48 }, { opacity: 1, y: 0, duration: 0.8, ease: "power3.out" }, 0.5);
    tl.to("#headline", { opacity: 0, duration: 0.5 }, 4);
    tl.fromTo("#tagline", { opacity: 0, scale: 0.9 }, { opacity: 1, scale: 1, duration: 0.5, ease: "power2.out" }, 4.5);
    window.__timelines = window.__timelines || {};
    window.__timelines.launch = tl;
  </script>
</body>
</html>

스타일에서 눈여겨볼 곳은 #stage입니다. 문서의 최소 예시처럼 루트를 실제 크기를 가진 상자(position: relative, 고정 너비·높이, overflow: hidden)로 만들어야 .clip의 inset: 0이 영상 화면 전체를 기준으로 잡힙니다. 글꼴은 일부러 시스템 글꼴인 sans-serif로 두었는데, 실제 영상에 쓸 글꼴은 파일을 프로젝트에 넣고 @font-face로 선언해 두는 편이 안전합니다.

클립 두 개를 시간 위에 올리는 속성들

화면에 시간을 두고 나타나는 요소를 문서는 클립이라 부릅니다. 클립에는 id, data-start, data-duration을 적습니다. 이미지는 길이를 생략하면 3초가 되고 영상과 오디오는 원본 길이가 되지만, 일반 HTML 요소는 길이가 필수입니다. 문서가 권하는 class="clip"은 없어도 시간은 먹지만 편집기와 lint가 클립으로 알아보게 해 주고 전체 화면 상자 규칙을 공급합니다. data-track-index는 브라우저 편집기에서 보이는 줄 번호일 뿐이며 렌더링은 읽지 않으니, 앞뒤 순서는 CSS의 z-index로 정해야 합니다.

두 번째 클립의 data-start="title"이 눈에 띕니다. 숫자 대신 다른 클립의 id를 적으면 “그 클립이 끝나는 시점”이라는 뜻입니다. 지원하는 꼴은 clip-id, clip-id + 초, clip-id - 초 세 가지이고, 한 구성안 안에서만 가리킬 수 있으며 서로를 가리키는 순환은 안 됩니다. 제목 클립의 길이를 4초에서 3초로 줄이면 끝 카드는 알아서 한 칸 당겨집니다.

초를 프레임으로 바꾸는 계산도 한번 해 둡니다. 기본 fps가 30이므로 6초는 180프레임이고, 프레임 번호는 초에 30을 곱한 값입니다. 제목은 15프레임에서 나타나 120프레임에서 꺼지기 시작하고 135프레임에서 클립이 끝납니다.

그림 2. 클립 둘과 트윈 셋의 시간 배치(프레임 번호는 편집부 계산)

제목 클립이 4.5초에 끝나고 같은 순간 끝 카드가 시작하며, 제목이 꺼지는 트윈(4.0~4.5초)은 클립이 사라지기 직전에 끝나도록 맞춰 둔 것을 볼 수 있습니다. 클립의 보이고 숨김은 프레임워크가 속성에서 계산해 처리하므로, 트윈은 클립이 보이는 동안의 움직임만 맡습니다.

멈춘 타임라인을 같은 이름으로 등록한다

움직임은 GSAP 타임라인이 맡습니다. 문서가 GSAP을 가장 기본 런타임으로 꼽고 지키라는 규칙은 단출합니다. 타임라인은 { paused: true }로 만들고, window.__timelines에 등록하되 키를 루트의 data-composition-id와 똑같이 적습니다. 오늘 장면의 키가 launch인 이유입니다. 중요한 트윈에는 위치(초)를 명시하고, 양 끝 상태가 중요하면 from()보다 fromTo()가 뒤로 감거나 무작위로 이동해도 안정적이라고 문서가 권합니다.

두 가지는 직접 어겨 보기 전에 알아 두면 좋습니다. 하나는 움직임을 transform과 opacity로 하라는 것입니다. top, left, width, height를 매 프레임 바꾸면 캡처에서 끊기고, 오늘 장면에서 제목이 위로 올라오는 효과를 y로 준 이유가 이것입니다. 다른 하나는 클립 요소 자체에 투명도를 걸지 않는 것입니다. 클립의 보임과 숨김은 프레임워크 몫이어서, 이 장면도 클립은 section에 두고 트윈은 안쪽 h1과 p에 겁니다.

영상이나 오디오를 넣는다면 규칙이 하나 더 붙습니다. 미디어 요소에 play(), pause()를 부르거나 currentTime을 바꾸지 않습니다. 재생과 이동은 HyperFrames의 몫이고, 영상을 움직이거나 줄여야 하면 그것을 감싼 요소를 움직입니다.

90번째 프레임이 찍히는 순간

이 장면의 어느 한 프레임, 예컨대 3초 지점은 어떻게 화면이 될까요. 렌더링은 영상을 재생하지 않습니다. 프레임 번호를 하나씩 올리며 “이 번호의 모양은?“을 묻고, 답은 오직 그 번호에서만 정해집니다. 엔진은 시각을 floor(frame) / fps의 정수 계산으로 구하며 실제 시계는 읽지 않습니다. 프레임 어댑터가 seekFrame(frame)을 받아 모든 애니메이션을 그 시각으로 옮기고, 크롬의 헤드리스 기능 beginFrame이 화면을 한 번에 가져온 뒤 FFmpeg가 프레임을 묶고 오디오를 섞습니다.

그림 3. 프레임 90은 3.0초이고, GSAP 타임라인은 재생되지 않은 채 그 시각으로 이동만 한다

그래서 같은 입력은 같은 영상을 낳는다는 보장이 성립하고, 이 보장을 지키려면 구성안도 협조해야 합니다. 현재 시각을 읽는 Date.now(), 화면 갱신에 기대는 requestAnimationFrame과 시스템 타이머, 시드 없는 Math.random(), 렌더링 도중의 에셋 내려받기가 결과를 흔드는 대표 원인입니다. 프레임 크기와 fps, 변수는 프레임 0이 찍히기 전에 잠기고, 모든 구성안은 끝이 정해진 유한한 길이여야 합니다.

기계가 다르면 글꼴과 크롬 버전 때문에 픽셀이 한 칸씩 달라질 수 있습니다. 완전히 같은 결과가 필요한 자리(CI, 납품 파일)에서는 npx hyperframes render --docker --output output.mp4로 돌립니다. 도커가 크롬 버전과 글꼴 세트, FFmpeg 인코더를 고정하므로 내 컴퓨터가 입력에서 빠집니다. 미리보기와 렌더는 같은 런타임을 쓰므로 모양은 같지만 속도는 다릅니다. 미리보기는 실시간이라 무거운 장면에서 버벅일 수 있어도, 렌더는 한 장씩 처리하므로 프레임을 빠뜨리지 않고 오래 걸릴 뿐입니다.

일부러 어기면 lint가 부르는 이름

규칙은 어기면 대개 오류로 멈추지 않고 조용히 틀린 영상으로 나옵니다. 타임라인을 등록하지 않으면 움직임 없는 정지 화면이 나옵니다. 그래서 렌더 전에 두 단계 검사를 거칩니다. lint는 HTML을 정적으로 읽고, check는 브라우저로 실제 열어 런타임, 레이아웃, 모션, 글자 대비까지 봅니다. 문서의 lint 규칙 목록은 이제 139개 코드이고 코드마다 수준(오류·경고)과 고치는 법이 적혀 있습니다. 오늘 장면에서 만나기 쉬운 것만 추리면 다음과 같습니다.

어기는 것	lint 코드	수준
window.__timelines.launch = tl; 줄을 지움	gsap_timeline_not_registered	오류
키를 main으로 바꿔 루트 id와 어긋나게 함	timeline_id_mismatch	오류
#title 섹션에 직접 opacity 트윈을 검	gsap_animates_clip_element	오류
제목에 Date.now()나 Math.random()을 씀	non_deterministic_code	오류
top·left·width·fontSize를 트윈함	gsap_non_transform_motion	오류
종료 없는 repeat: -1을 씀	gsap_infinite_repeat	오류(길이를 정해 두면 경고)
클립에서 class="clip"을 뺌	timed_element_missing_clip_class	경고
CSS transition으로 움직임을 줌	css_transition_used	경고

영상이 들어가는 장면이라면 video_missing_muted(소리 유무를 알 수 없음), self_closing_media_tag(<video />로 닫으면 뒤 요소를 삼킴), missing_local_asset(없는 파일을 가리킴) 같은 코드도 만나게 됩니다. 수준의 뜻은 문서에 정리되어 있습니다. 오류는 check를 기본으로 실패시키고, 경고는 --strict를 줄 때만 실패이며, render는 --strict-all일 때만 경고에서 멈춥니다.

직접 깨뜨려 보는 것이 가장 빨리 익는 방법입니다. 한 번에 하나만 어기고 확인한 뒤 되돌리는 순서를 권합니다.

1. index.html을 복사해 두고 window.__timelines.launch = tl; 줄만 지운 뒤 npx hyperframes lint를 돌려 오류 코드가 붙는지 봅니다.
2. 줄을 되살리고 키만 main으로 바꿔 어긋남이 다른 코드로 잡히는지 비교합니다.
3. 되돌린 다음 제목 섹션에 직접 투명도 트윈을 걸어 보고, 같은 효과를 안쪽 h1에 걸면 사라지는지 확인합니다.
4. 마지막으로 class="clip"만 빼서 경고가 오류와 어떻게 다르게 취급되는지, check --strict와 비교해 봅니다.

스냅샷 세 장과 시험 렌더, 그다음 최종 렌더

연속 재생에서는 멀쩡해 보이는데 특정 프레임으로 바로 이동하면 틀리는 타임라인이 있으므로, 렌더 전에 시점 몇 곳을 정지 화면으로 찍어 눈으로 봅니다. 이 장면에서는 비어 있어야 할 0초, 제목이 다 떠오른 1.3초, 끝 카드가 나온 5초가 알맞습니다.

npx hyperframes snapshot --at 0,1.3,5
npx hyperframes render --quality draft --output review.mp4
npx hyperframes render --output final.mp4

로컬 렌더의 품질 이름은 draft, looks, high이며 아무것도 안 주면 looks(CRF 16)입니다. 문서는 1080p에서 시각적으로 무손실에 가깝다고 설명합니다. draft는 캡처와 인코더 품질만 낮추고 시간 배치는 바꾸지 않으니, 길이와 소리를 확인하는 시험용으로 충분합니다. 형식은 MP4가 기본이고 MOV(알파가 있는 ProRes 4444), WebM(알파가 있는 VP9), GIF, PNG 시퀀스, HLS도 --format으로 고릅니다. 투명 배경이 필요하면 html과 body에 배경을 칠하지 않아야 하고, 우리 장면처럼 바탕을 꽉 채운 영상에는 투명이 의미가 없습니다.

4K는 구성안의 배치를 그대로 두고 --resolution 4k로 높은 해상도로 찍는 방식입니다. 정수 배(1080p의 2배)만 되고 HDR과는 한 번에 쓸 수 없으며, 1080p 원본 영상이나 고정 크기 캔버스는 4K로 찍어도 디테일이 늘지 않습니다. 글자와 SVG, CSS 도형만 더 또렷해집니다.

렌더링한 파일에는 hyperframes_renderer와 hyperframes_version 태그가 컨테이너 메타데이터로 들어갑니다. 서명이 없는 진단용 힌트일 뿐 출처 증명이 아니고, ffmpeg -i out.mp4 -map_metadata -1 -c copy clean.mp4로 지울 수 있습니다.

9.8초가 25.0초가 되는 CSS 한 줄

장면이 커지면 렌더 시간이 문제가 됩니다. 공식 성능 문서의 측정이 이 감각을 잡아 줍니다. 1920x1080, 300프레임짜리 같은 구성안이 9.8초에 렌더링됐는데, CSS 선언 하나를 바꾸자 25.0초가 걸렸습니다. 세 번 돌린 중앙값이고, 화면이 같다는 것은 픽셀 비교로 확인했다고 합니다.

그림 4. 화면은 같고 CSS 한 줄만 다르다(HyperFrames 문서의 측정값, 비율은 편집부 계산)

비율은 2.55배입니다. 프레임당 렌더 속도로 바꾸면 초당 약 30.6프레임에서 12프레임으로 떨어진 셈입니다(300프레임을 걸린 시간으로 나눈 편집부 계산). 우리 장면은 가벼워서 와닿지 않을 수 있지만, 같은 장면을 매주 수십 편 뽑는 파이프라인이라면 시간이 그대로 곱해집니다.

문서는 증상별로 어디부터 볼지 적었습니다. 한 장면에서만 미리보기가 끊기면 큰 블러·마스크·그림자·움직이는 레이어가 많은지 보고, 이미지가 처음 나올 때 멈추면 원본 이미지가 너무 큰 것입니다. 큰 filter: blur()와 backdrop-filter, 그림자가 붙은 요소 수십 개의 동시 움직임, 영상 크기보다 훨씬 큰 원본 이미지가 대표적으로 비쌉니다. 1920x1080 구성안에는 3840x2160 원본이면 2배 화면까지 충분하고 그보다 큰 원본은 메모리와 디코딩만 늘립니다. 정적인 블러나 질감 더미는 미리 렌더링한 이미지로 바꾸라고 합니다. 투명 WebM은 CPU를 많이 쓰는 VP9 인코더라 MP4보다 훨씬 오래 걸립니다. 추측하지 않고 재라는 처방도 있습니다. preview를 띄운 채 크롬 개발자 도구의 Performance를 녹화하면 Paint나 Composite는 필터·그림자·마스크, Layout은 배치 계산, Script는 작성한 코드를 가리킵니다. 한 번에 한 가지만 바꾸고 다시 재서 병목이 움직인 쪽을 남기라는 것입니다.

같은 파일을 어디서 돌릴까, 그리고 에이전트에게 넘기면

여기까지는 내 컴퓨터에서 render를 돌렸습니다. 같은 프로젝트를 다른 곳에서 돌릴 수도 있고, 갈림길은 크롬과 FFmpeg를 누가 운영하느냐입니다.

그림 5. 경로를 고르는 기준은 누가 크롬과 FFmpeg를 돌리느냐

공식 문서는 사람이나 CI가 시작하는 일이면 CLI, Node 서비스가 시작하면 @hyperframes/producer를 쓰라고 안내합니다. 인프라를 맡기려면 hyperframes auth login과 hyperframes cloud render 두 줄이면 프로젝트를 올려 결과를 renders/로 받아 옵니다. 옵션은 fps 1~240, 품질 draft·standard(기본)·high, 형식 mp4·webm·mov, 해상도 1080p·4k이고 4K는 1.5배로 과금됩니다. 프로젝트 압축은 200MB까지이며, 5MB 이상 미디어는 따로 올라가 서명 없는 공개 주소로 연결됩니다. 올리기 전에 --dry-run으로 목록을 확인하고 불필요한 파일은 .hyperframesignore에 적어 제외합니다. 내 클라우드 계정에서 분산 렌더링하려면 AWS Lambda나 Google Cloud Run이 있습니다. Lambda는 Step Functions가 영상을 조각으로 나누고, 조각별로 병렬 렌더링한 뒤 합치는 구조이며 요금은 실행 시간과 메모리를 곱한 GB-초에 상태 전환 요금이 붙습니다. 문서가 진행 상황 예시로 보인 480프레임, 람다 5개, 0.0214달러는 예시일 뿐 비용의 기준이 되지 못합니다. 클라우드 경로에는 아직 HLS 출력이 없습니다.

같은 장면을 에이전트에게 맡기면 사람이 쓴 이 파일을 에이전트가 쓰게 됩니다. 설치는 스킬을 심는 것으로 시작합니다. Claude Code는 플러그인 마켓플레이스로 설치할 수 있습니다.

npx hyperframes skills update                       # 핵심 스킬 4개를 현재 main 기준으로 설치
claude plugin marketplace add heygen-com/hyperframes
claude plugin install hyperframes@hyperframes       # Claude Code 플러그인, 호출은 /hyperframes:hyperframes

스킬 사본을 가져오는 npx skills add heygen-com/hyperframes는 레지스트리 사본이라 최신 코드보다 몇 시간 늦을 수 있어서, 최신본이 필요하면 skills update가 낫다고 README가 안내합니다. 핵심 스킬은 네 가지입니다. /hyperframes는 영상 제작의 계약과 작업 순서를, /hyperframes-cli는 생성·검사·렌더·게시 명령을 맡고, /hyperframes-registry는 전환·자막·차트·지도 같은 약 450개 기성 블록을, /media-use는 음악·효과음·이미지·음성 같은 미디어 확보를 맡습니다. Figma와 슬라이드 덱, Remotion 이전용 스킬은 필요할 때 설치합니다. 빠른 시작 문서가 권하는 첫 요청은 “/hyperframes로 https://example.com 의 10초짜리 제품 소개 영상을 만들어 줘”이고, 에이전트는 작업 폴더를 남기고 브라우저 편집기를 엽니다.

비교 대상은 React로 영상을 쓰는 Remotion입니다. HyperFrames 문서는 Claude Code(Opus 5.5)에 같은 요청을 한 번씩 주었더니 HyperFrames는 11분 50초에 HTML 4개 파일(822줄)로, Remotion은 12분 30초에 TypeScript 10개 파일(1,037줄)과 약 950MB의 node_modules로 MP4를 냈다고 적었습니다. 개발사가 한 번 돌린 실험이고 문서도 한 번으로 품질을 가를 수 없다고 인정하니, 남는 차이는 결과물이 React 프로젝트냐 브라우저로 열 수 있는 HTML이냐입니다. 같은 문서는 Remotion이 더 오래되어 템플릿과 운영 사례가 많고 클라우드 렌더링이 더 성숙하며, React를 이미 쓰는 팀에는 컴포넌트와 타입 검증된 입력이 그대로 이어지는 장점이 있다고 적습니다. Remotion에서 넘어오는 remotion-to-hyperframes 스킬은 상태 기반 움직임이나 MUI 같은 UI 키트는 억지로 근사하지 않고 거부한 뒤 이유를 알려 주며, 프레임별 유사도(SSIM)로 검증합니다. 방향은 한쪽뿐입니다.

에이전트에게 길게 맡기기 전에 데이터가 어디로 가는지 정리해 두면 좋습니다.

• 로컬 렌더링은 프로젝트가 내 컴퓨터를 떠나지 않지만, 클라우드 렌더링은 프로젝트를 HeyGen에 올립니다. 5MB 이상 미디어는 서명 없는 공개 주소의 에셋이 되니 --dry-run으로 목록부터 봅니다.
• CLI는 명령 이름과 렌더 성능 같은 익명 통계를 보내며, 프로젝트 이름이나 영상 내용은 보내지 않는다고 문서가 밝힙니다. 끄려면 npx hyperframes telemetry disable을 씁니다.
• 에이전트의 프롬프트는 쓰는 에이전트의 제공 업체로 가고 요금도 그 요금제에서 나갑니다. HeyGen 음성·아바타·생성 클립·클라우드 렌더링만 크레딧이 듭니다.
• 에이전트가 만든 구성안은 CDN의 GSAP처럼 외부 스크립트와 미디어 주소를 불러오는 웹 페이지입니다. 자동 파이프라인에 넣을 때는 주소를 검토하고, 스크립트와 미디어는 프로젝트 안에 두는 편이 렌더링 중 외부 접근 금지 규칙에도 맞습니다.
• Claude.ai나 ChatGPT에서 쓰는 호스팅 커넥터는 HeyGen 계정 안에서 영상을 만들어 로컬 프로젝트 폴더와 로컬 렌더링을 쓸 수 없습니다. 파일로 남겨 검증하려면 로컬 경로가 맞습니다.