OmniHuman-1.5 프롬프트 레시피: 바로 복사해 붙여넣을 수 있는 화자 아바타 영상 프롬프트

프롬프트 구조가 표현보다 중요한 이유

대부분의 팀은 첫 화자 아바타 프롬프트를 작성할 때 한 문장만 쓰고는 몇 시간 동안 몇 번이고 다시 써 가며 마법 같은 문구를 찾으려 합니다. 이 방식은 실패할 수밖에 없습니다. OmniHuman-1.5는 영리함에 반응하는 것이 아니라 명세(specification)에 반응하기 때문입니다. 프롬프트는 짧은 영상 한 편의 명세입니다. 누가 출연하는지, 무엇을 말하는지, 화면을 어떻게 구성하는지, 대사를 어떻게 연기하는지. 이 중 하나라도 빠지거나 다른 항목과 뒤엉키면 모델은 추측할 수밖에 없고, 추측이 바로 일관성 문제의 근원입니다.

유용한 사고 모델은 프롬프트를 하나의 출력에 공급되는 네 개의 적층 모듈로 보는 것입니다:

• 주체 — 누가 출연하는지, 그리고 안정적이고 서술 가능한 수준에서 그들이 어떻게 생겼는지.
• 대사 — 말할 정확한 발화, 글자 그대로 적어 넣습니다.
• 구도 — 샷 크기, 카메라 앵글, 배경, 그리고 주체가 화면에서 차지하는 위치.
• 연기 — 템포, 에너지, 어조, 그리고 대사가 암송이 아니라 실제로 말한 것처럼 들리게 하는 작은 신체 동작.

이것들을 분리하면 반복 작업이 관리 가능해집니다. 대사는 그대로 두고 연기만 바꾸거나, 구도를 다시 잡지 않고 주체 설명만 다시 쓸 수 있습니다. 모든 것이 매끄러운 한 덩어리 문장에 뭉쳐 있으면 편집할 때마다 전체를 편집하는 셈이 되고, 출력의 변화를 입력의 특정 변경에 귀속시킬 수 없게 됩니다.

이것은 겉보기에 차이가 커 보이는 두 프롬프트가 유사한 결과를 낼 수 있는 이유이기도 합니다: 둘이 같은 네 모듈을 인코딩하고 있는 것입니다. 반대로 거의 같아 보이는 두 프롬프트가 크게 다를 수 있는데, 둘 중 하나가 조용히 어떤 모듈을 빠뜨렸기 때문입니다 — 보통은 연기이며, 사람들이 가장 적어 두기를 잊는 부분입니다.

이 가이드의 레시피는 모두 같은 네 모듈을 기반으로 합니다. 복사하고, 각색하고, 그리고 일부러 분해해 보면서 각 모듈이 어떤 역할을 하는지 직접 확인하도록 의도되었습니다.

시작 전 한 가지 유의점

OmniHuman-1.5의 프롬프트 처리 방식은 완전히 공개되지 않았고, 공개되지 않은 손잡이는 바뀌기 마련입니다. 아래의 모든 레시피는 근거 없는 매개변수, 가중치 문법, 벤더 특정 플래그를 쓰지 않습니다. 대신 주체, 대사, 구도, 연기에 대한 평이하고 명시적이며 자연어인 서술에 의존합니다. 이렇게 하면 레시피가 이식성을 유지하고, 존재하지 않을 수도 있는 문법 위에 파이프라인을 구축하는 일을 피할 수 있습니다.

어떤 레시피가 모델이 안정적으로 따르지 못할 수 있는 것 — 정확한 시점, 비일상적 음소에서의 정밀한 립싱크, 매우 긴 대사 — 을 제약해야 할 때, 가이드는 이를 분명히 지적하고 텍스트에 적어 넣어 해결하려 하지 말고 프롬프트 외부에서 처리하라고 권합니다.

이 레시피들을 모델별 개별 통합을 짜맞추지 않고 단일 통합 API로 실행하고 싶다면, HiAPI.ai의 비디오 엔드포인트가 여기서 설명하는 모든 것의 목적지 경로입니다.

바로 복사해 붙여넣을 수 있는 프롬프트 해부

레시피에 앞서, 모두가 따르는 템플릿부터 봅시다. 한 번 읽으면 기억만으로 어느 것이든 재구성할 수 있을 것입니다.

[SUBJECT]
A [age range] [gender presentation] with [hair], [distinguishing feature],
wearing [clothing]. Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "<your script here>"

[FRAMING]
[Shot size] shot, [camera angle], [subject position in frame].
Background: [background description]. Lighting: [lighting description].

[DELIVERY]
Speaks at [pace]. Tone: [tone]. [Optional physical behavior cue].
Camera is static.

각 필드를 이렇게 쓰는 이유에 대한 몇 가지 설명.

주체

서술을 안정적이고 구체적으로 유지하세요: 연령대, 성별 표현, 헤어스타일, 한두 개의 두드러진 특징, 의상. 형용사를 쌓지 마세요 — 여분의 서술어 하나하나가 모델이 실행 간에 흔들릴 수 있는 또 하나의 지점입니다. 같은 인물을 여러 클립에 사용해야 한다면 이 모듈을 글자 그대로 고정하고 절대 편집하지 마세요.

대사

Say exactly(글자 그대로 말하라)라는 문구가 실제로 작동합니다. 뒤따르는 텍스트가 장면 서술이 아니라 음성 콘텐츠임을 알려 줍니다. 대사는 따옴표 안에 넣어 경계를 명확히 하고, 순수한 산문으로 유지하세요 — 무대 지시도, 괄호 설명도, 표식도 없이.

구도

샷 크기(클로즈업, 미디엄 샷, 미디엄 롱 샷), 카메라 앵글(눈높이, 약간 올려다보는 각도), 주체 위치(중앙, 화면 왼쪽으로 약간 치우침)는 모두 평범한 단어로 서술할 수 있고, 모두 출력을 실질적으로 바꿉니다. 배경과 조명도 여기에 속합니다. 그것들은 연기가 아니라 샷의 일부이기 때문입니다.

연기

이 모듈은 대부분의 사람이 건너뛰는 부분입니다. 템포, 어조, 하나의 신체 행동 단서(가벼운 끄덕임, 한 번의 제스처, 자세 변화)가 지각되는 자연스러움에 기여하는 바는 주체 설명을 몇 번이고 다시 쓰는 것보다 훨씬 큽니다. 단서는 하나나 둘로 유지하세요 — 그보다 많으면 모델이 선택을 해야 합니다.

마무리 제약

Camera is static(카메라 고정)으로 끝맺는 것은 원치 않는 카메라 움직임을 억제하는 저비용 방법이며, 이는 화자 아바타 생성에서 흔하고 주의를 분산시키는 실패 모드입니다. 매개변수가 아니라 평범한 지시이며, 레시피의 일부입니다.

템플릿에 넣어서는 안 되는 것

프레임 레이트, 해상도, 시드, 모델 버전 문자열을 프롬프트 텍스트에 쓰지 마세요. 그것들은 프롬프트 수준이 아니라 요청 수준의 문제이며, 섞어 넣으면 프롬프트를 diff하기도 재사용하기도 더 어려워집니다. 콘텐츠는 프롬프트가, 인프라는 API 호출이 관리하게 하세요.

레시피: 1인 설명 클립

주력 레시피. 문서 내레이션, 강의 콘텐츠, 공지 영상, 그리고 진행자가 준비된 대본을 읽는 모든 상황에 적합합니다.

[SUBJECT]
A person in their early 30s, gender-neutral presentation, short dark hair,
wearing a plain crew-neck sweater. Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "In this walkthrough we'll cover three things. First, how to set up
the project. Second, the configuration options that matter most. And third, how
to verify everything is working before you ship."

[FRAMING]
Medium shot, eye level, subject centered with a small amount of headroom.
Background: softly out-of-focus home office with a bookshelf.
Lighting: soft key light from the left, no harsh shadows.

[DELIVERY]
Speaks at a measured, conversational pace. Tone: friendly and instructional.
Occasional small nod on sentence boundaries. Camera is static.

왜 효과적인가

대사가 충분히 짧아 일관성을 유지할 수 있습니다 — 대략 세 문장, 분절 경계가 명확합니다. 구도는 의도적으로 평범합니다: 중앙, 눈높이, 부드러운 배경. 여기서 평범한 구도는 장점입니다. 실행 간 출력 차이를 식별하기 쉽게 만들기 때문입니다. 배경이 변하기 시작하면 문제가 모델에 있지, 당신의 샷 설명에 있지 않다는 것을 알 수 있습니다.

연기 모듈은 하나의 신체 단서(문장 경계에서의 이따금 가벼운 끄덕임)를 주며, 이는 대사 구조와 자연스럽게 대응합니다. 이처럼 연기 단서와 대사 형태 사이의 대응 관계는 따라 할 가치가 있습니다: 대사의 리듬과 일치하는 단서는 자연스럽게 읽히고, 충돌하는 단서는 무작위하게 읽힙니다.

각색하기

• 더 긴 대사: 같은 구도와 연기를 유지하고, 문단 경계에서 대사를 여러 클립으로 나누세요. 한 번의 긴 생성으로 밀어붙이지 마세요. 각 클립의 구조가 비슷할 때 클립 간 일관성이 더 쉽게 유지됩니다.
• 다른 청중: 어조 단어만 바꾸고("권위 있는", "따뜻한", "경쾌한") 다시 실행하세요. 이것이 레시피에서 지렛대 효과가 가장 큰 단일 편집입니다.
• 브랜드 페르소나: 주체 모듈을 고정하고 의상만 바꾸세요. 이렇게 하면 의상을 얼굴과 헤어스타일 — 가장 흔들리기 쉬운 필드 — 과 분리할 수 있습니다.

알려진 한계

매우 긴 대사 — 한 번에 여러 문단 — 는 끝부분에 가까워지면 템포 일관성을 잃는 경향이 있습니다. 한 클립에 몇 문장씩 계획하고 편집기에서 조립하세요. 길이 문제를 프롬프트에 리듬 지시를 추가해 해결하려 하지 마세요. 프롬프트는 타이밍 컨트롤러가 아닙니다.

레시피: 짧은 소셜 훅

숏폼 비디오의 생사는 처음 2초에 달려 있습니다. 이 레시피는 설명 레시피의 중립성을 에너지와 맞바꾸며, 의도적으로 다른 레시피보다 짧습니다.

[SUBJECT]
A person in their late 20s, wearing a casual button-up shirt.
Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "Stop scrolling. If you've ever shipped a feature that broke in
production, this is the one setting you probably missed."

[FRAMING]
Close-up shot, slightly below eye level, subject centered and filling most of
the frame. Background: simple solid-color wall. Lighting: bright, even, frontal.

[DELIVERY]
Speaks quickly with confident energy. Tone: direct and conspiratorial.
Leans in slightly on the first sentence. Camera is static.

참고할 만한 디자인 선택

클로즈업 + 눈높이보다 약간 낮은 앵글은 친밀감과 약간의 긴박감을 만들어냅니다. 이것은 숏폼의 시각 문법이며, 평범한 구도 언어로 완전히 표현할 수 있습니다 — 특별한 문법이 필요하지 않습니다.

단색 배경은 빠른 편집 템포와 주의를 다투는 시각적 잡음을 없앱니다. 숏폼에서 배경은 절대 화면에서 흥미로운 부분이 되어서는 안 됩니다.

최대 두 문장. 훅은 하나의 주의 단위이지 문단이 아닙니다. 아이디어에 세 문장이 필요하다면 그것은 다른 레시피에 속합니다.

첫 문장과 맞춰진 하나의 신체 단서. "첫 문장에서 약간 앞으로 기울임"이 효과적인 이유는 첫 문장이 바로 훅이기 때문입니다. 단서를 그것이 속한 비트와 짝지으세요.

각색하기

같은 주체와 구도로 세 가지 다른 훅 대사를 실행하고 출력에서 고르세요. 대사 모듈을 제외한 모든 것이 고정되어 있으므로, 클립 간 차이는 글쓰기에 귀속될 수 있으며, 이는 훅 A/B 테스트에서 바로 원하는 바입니다.

알려진 한계

매우 빠른 연기는 밀도 높은 기술 용어에서 명료도를 떨어뜨릴 수 있습니다. 훅에 제품명, 약어, 소리 내어 말해야 하는 숫자가 포함되어 있다면 템포 단어를 "quickly"에서 "briskly"로 바꾸고 비교해 보세요. 이것이 대사가 고정된 후에도 연기 모듈이 두 번째 조정을 필요로 할 수 있는 유일한 지점입니다.

레시피: 제품 데모 내레이션

제품 인터페이스나 일련의 단계 위에 얹는 내레이션용 레시피로, 개성보다 명료도가 더 중요하고 템포가 시청자의 눈이 따라갈 공간을 남겨야 하는 상황에 씁니다.

[SUBJECT]
A person in their mid 30s, wearing a neutral blazer over a plain shirt.
Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "Open the settings panel from the left navigation. Choose the
integration you want to connect. Paste your key into the credential field.
Then save, and run a test call from the same screen to confirm the connection."

[FRAMING]
Medium close-up, eye level, subject positioned slightly left of center to leave
room on the right of frame. Background: clean, uncluttered neutral wall.
Lighting: soft, even, no rim light.

[DELIVERY]
Speaks slowly and evenly, with a brief pause at each step boundary.
Tone: calm and precise. Minimal movement. Camera is static.

가장 중요한 구도 팁

"약간 왼쪽으로 치우쳐 중앙에, 화면 오른쪽에 공간을 남긴다"는 이 레시피에서 가장 중요한 한 줄입니다. 데모는 보통 화면 녹화나 UI 오버레이와 합성되며, 중심에서 벗어난 구도는 편집자가 그것들을 배치할 자리를 남겨 줍니다. 프롬프트에서 비용이 전혀 들지 않으면서도 다시 렌더링하는 수고를 덜어 줍니다.

구조적 지시로서의 템포

"각 단계 경계에서 짧게 멈춤"은 시간 매개변수가 아니라 구조에 대한 지시입니다. 대사에 네 개의 단위 리듬이 있다고 모델에 알려 줍니다. 밀리초를 지정하는 것이 아니라 박자가 어디 있는지 알려 주는 것입니다. 대사 안의 단계 수를 적게 유지하고 대응 관계를 명확히 하세요. 대사에 여섯 단계가 있고 연기가 경계에서의 멈춤을 언급한다면 그것은 여전히 하나의 지시이고 여전히 읽힙니다.

각색하기

• 다중 클립: 각 단계를 같은 주체와 구도 모듈을 쓴 자체 클립으로 렌더링한 뒤 이어 붙이세요. 이렇게 하면 깔끔한 편집 지점을 얻고 시퀀스 전체에서 외관을 일관되게 유지할 수 있습니다.
• 오버레이 주도 편집: 어떤 단계가 구두 대사보다 더 긴 시각적 비트를 필요로 한다면 연기 지시를 늘리지 말고 꼬리 무음 클립을 추가하세요. 무음은 후반 작업의 문제입니다.

알려진 한계

멈춤은 요청이지 보장이 아닙니다. 화면 동작과의 동기화에서 정확한 멈춤 위치가 중요하다면 편집기에서 조정할 계획을 세우고, 생성된 클립을 편집 시간을 제외한 모든 것의 시청각적 진실의 원천으로 삼으세요.

레시피 테스트 및 반복

레시피는 가설입니다. 규모를 키우기 전에 검증하세요.

1단계: 테스트 대사 작성

실제 콘텐츠의 난제를 다루는 짧은 대사 — 두세 문장 — 을 준비하세요: 가장 긴 단어, 가장 이례적인 고유 명사, 실제로 말하게 될 숫자. 테스트 대사는 아부성이 아니라 적대적이어야 합니다. 모델이 쉽게 처리하는 테스트 문장은 아무것도 알려 주지 않습니다.

2단계: 기준선 생성

테스트 대사로 레시피를 수정 없이 한 번 실행하세요. 출력과 함께 그것을 만들어 낸 정확한 프롬프트 텍스트를 저장하세요. 이 기준선이 이후 모든 비교의 참조점입니다.

3단계: 실행당 변수 하나만 변경

이것이 전부입니다. 한 가지를 골라 그것만 바꾸세요:

• 대사 길이 — 같은 프롬프트에 문장 하나 더.
• 구도 — 미디엄 샷에서 미디엄 클로즈업으로, 나머지는 그대로.
• 연기 어조 — 단어 하나 교체("친근한" → "경쾌한").

같은 실행에서 구도와 어조를 모두 바꿨는데 출력이 좋아졌다면, 무언가가 작용했다는 것만 알 뿐 그것이 무엇인지는 모릅니다. 그것은 낭비된 실행입니다.

4단계: diff 로그 유지

각 실행에 대해 프롬프트 변형, 그 하나의 변경, 그리고 한 줄 결론을 기록하세요. 거부된 변형도 채택된 것만큼 가치가 있습니다. 경계가 어디인지 알려 주기 때문입니다. 타임스탬프와 diff가 있는 간단한 텍스트 파일이면 충분합니다. 특별한 도구는 필요 없습니다.

5단계: 승격 또는 폐기

어떤 변형이 기준선보다 눈에 띄게 우수하면 그것을 새 기준선으로 승격하고, 프로덕션 레시피로 확정하기 전에 전체 테스트 대사로 다시 테스트하세요. 한 문장에 도움이 된 변경이 다른 문장에는 해로울 수 있습니다.

반복하지 말아야 할 것

프롬프트가 제어할 수 없는 것을 반복하지 마세요. 문제가 해상도, 종횡비, 시드 결정성이라면 당신은 잘못된 층에 있는 것입니다 — 프롬프트가 아니라 요청 매개변수를 보세요. 인프라 문제를 고치려고 실행 횟수를 써 가며 프롬프트를 다시 쓰는 것은 팀이 생성 예산을 낭비하는 가장 흔한 방식입니다.

표본 크기에 대한 유의점

화자 아바타 생성에는 고유한 실행 간 변동이 있습니다. 변형마다 표본을 하나만 생성하면 오도될 수 있습니다. 결론을 내리기 전에 테스트 대사로 변형마다 두세 개의 표본을 생성하고, 가장 좋은 것을 고르는 대신 표본들 사이에서 비교하세요.

흔한 실패 모드와 프롬프트로 피하는 방법

가장 자주 나타나는 문제들과 프롬프트 쪽에서 해결하는 조정을 정리했습니다. 어느 것도 매개변수를 발명할 필요가 없습니다.

클립 간 주체가 흔들림

증상: 헤어스타일, 의상, 나이가 클립마다 달라 보임. 해결: 모든 프롬프트에서 주체 모듈을 글자 그대로 고정하고 그 안에서 아무것도 바꾸지 마세요 — 동의어도, 어순도. 변동은 보통 클립 간의 선의의 다시 쓰기에서 비롯됩니다.

연기가 말이 아니라 암송처럼 읽힘

증상: 밋밋한 표정, 미세한 움직임 부재, 기이한 정지. 해결: 연기 모듈에 신체 행동 단서를 추가하고 그것이 대사의 한 비트와 대응하도록 하세요. 또한 대사가 구어체로 쓰였는지 확인하세요 — 축약형, 짧은 분절, 문장 조각. 격식 산문은 어떤 어조 단어를 더해도 격식 있는 연기처럼 읽힙니다.

원치 않는 카메라 움직임

증상: 요청하지 않았는데 느린 줌, 흔들림, 팬. 해결: 연기 모듈 끝에 명시적인 고정 카메라 지시를 붙이세요. 움직임이 여전히 남는다면 프롬프트의 다른 곳에서 움직임을 암시하는 단어들("역동적인", "활기찬 구도", "움직이는 카메라")을 삭제하세요.

배경이 주체와 주의를 다툼

증상: 모델이 얼굴이 아니라 배경 세부에 주의를 쏟음. 해결: 배경 서술을 한 구절로 단순화하고, 주체를 벽과 분리하는 빛을 추가하세요(한쪽에서 부드러운 키 라이트). 배경 단어는 많게가 아니라 적게.

긴 대사에서 템포 붕괴

증상: 연기가 시작은 괜찮지만 끝에 가까워지면 급해지거나 밋밋해짐. 해결: 대사를 줄이세요. 이것이 신뢰할 수 있는 해결책이며 어떤 프롬프트 표현도 보상할 수 없습니다. 대신 자연스러운 경계에서 여러 클립으로 나누세요.

밀도 높은 용어에서 명료도 하락

증상: 제품명, 약어, 숫자가 불분명함. 해결: 템포 단어를 빠름에서 여유 있음으로 바꾸세요; 특정 용어가 여전히 틀리다면 대사에서 음성 표기로 다시 적는 것을 고려하되, 이것이 대사를 더 읽기 어렵게 만든다는 점을 인정하고 최후의 수단으로 삼으세요.

출력이 프롬프트의 일부를 무시함

증상: 어떤 모듈 전체가 효과가 없는 듯함. 해결: 모듈 충돌을 확인하세요. 주체 모듈이 "격식 있는 정장을 입고"라고 하고 구도 모듈이 "캐주얼한 카페"라고 하면 모델은 모순을 조정해야 하고 무언가를 버릴 수 있습니다. 모델의 잘못이라고 단정하기 전에 네 모듈이 서로 일관되게 하세요.

같은 실행 간 결과 불일치

증상: 같은 프롬프트, 다른 출력. 해결: 이것은 예상된 변동이며 프롬프트 버그가 아닙니다. 변형마다 두세 표본에 걸쳐 합격 기준을 세우고, 그 기준 범위에 들어오면 튜닝을 멈추세요. 프롬프트 표현으로 완벽한 결정성을 추구하는 것은 생산적이지 않습니다.

프롬프트를 버전이 있는 자산으로 다루기

채팅 창에 사는 프롬프트는 재현 가능한 자산이 아닙니다. 두 개의 레시피와 각 레시피의 변형 몇 개를 가지면, 당신은 소스 코드를 가진 것이며, 그것은 소스 코드처럼 관리되어야 합니다.

프롬프트를 사용하는 코드 옆에 보관하세요

생성 스크립트가 있는 저장소에 prompts/ 디렉터리를 두세요. 레시피당 파일 하나, 일반 텍스트 또는 마크다운, 네 모듈이 온전하고 읽기 가능한 상태로. 프롬프트 텍스트는 문자열로 로드될 수 있어야 하며 함수 본문에 붙여넣지 않아야 합니다.

이름이 출력을 예측할 수 있게 하는 명명

의도를 인코딩하는 명명 체계는 영리함보다 가치가 큽니다:

prompts/
  explainer-single-speaker-v3.txt
  social-hook-closeup-v2.txt
  walkthrough-voiceover-v1.txt

버전 접미사는 장식이 아닙니다. 모듈의 변경이 출력에 영향을 미칠 때 올리세요; 주석의 오타 때문에 올리지 마세요.

바이너리가 아니라 프롬프트를 diff하세요

출력 품질이 변할 때는 "입력에서 무엇이 바뀌었나?"에 답해야 합니다. 일반 텍스트 프롬프트에 대한 git diff는 한 명령으로 답합니다. 요청 매개변수가 뒤섞인 JSON 덩어리에 박힌 프롬프트는 그럴 수 없습니다. 프롬프트 텍스트를 요청 구성과 분리해 두어 diff가 읽히게 하세요.

프롬프트를 생성된 자산과 함께 고정하세요

생성된 클립을 저장할 때 어떤 프롬프트 버전이 그것을 만들어 냈는지 기록하세요 — 파일 이름, 부속 메타데이터 파일, 또는 자산 데이터베이스에. 6주 후 누군가 어떤 클립이 왜 다르게 보이는지 물었을 때, 답은 추측이 아니라 한 번의 조회로 찾을 수 있어야 합니다.

코드 변경을 리뷰하듯 프롬프트 변경을 리뷰하세요

구도나 주체를 바꾸는 프롬프트 편집은 시각적 변경입니다. UI 변경처럼 대하세요: 변경 전후 표본 출력을 첨부해 pull request를 열고 다른 사람이 보게 하세요. 고정되어 있어야 할 모듈의 우발적 흔들림을 잡는 가장 저렴한 방법입니다.

레시피 인덱스를 유지하세요

prompts 디렉터리의 짧은 README에 각 레시피, 용도, 현재 버전을 나열하면 모든 신규 기여자가 당신의 의도를 역추적하지 않아도 됩니다. 알려진 한계 — 예컨대 설명 레시피의 대사 길이 상한 — 를 기록하는 장소이기도 하므로, 제약은 다시 발견되지 않고 문서화됩니다.

플랫폼에서 시작하고 그다음 전문화하세요

이 레시피들을 파이프라인에 연결하려면, HiAPI.ai의 OmniHuman-1.5 비디오 엔드포인트가 단일 호출 인터페이스를 제공하므로 레시피를 추가해도 저장소 레이아웃과 버전 체계가 안정적으로 유지됩니다. 레시피를 복사하고, 짧은 테스트 대사로 실행하고, 한 번에 변수 하나를 바꾸고, 기준선보다 나은 버전을 커밋하세요 — 이 루프가 방법의 전부입니다.