# HIOB 사용설명서: 효과적인 광고 만들기

버전 2026-09-29.3 · HIOB MCP 0.9.6 beta

제품 자료를 설득력 있는 광고로 바꾸는 실무 순서입니다. 고객은 방향을 선택하고, 로컬 AI는 자료 이해·기획·수정 판단을 맡습니다. HIOB는 프로젝트·소재·비용을 연결하고 최종 영상은 Remotion AWS Lambda에서 렌더합니다.

컷 수보다 전달되는 이유가 중요합니다. 한 시청자의 상황 → 제품을 선택할 근거 → 실행할 행동이 이어져야 합니다. 화려한 화면, 놀라는 표정, 빠른 음악은 이 연결을 돕는 연출입니다. 이 설명서는 제작 기준이며 매출·바이럴·시청 지속을 보장하지 않습니다.

## AI에게 처음 요청하기

```text

HIOB로 첨부 자료의 광고를 만들어줘. 먼저 https://hi-ob.com/help/advertising 와 https://hi-ob.com/help/skills/advertising-playbook-2026-09-29.md 를 읽고 현재 production_check, project_context, 모델 가이드와 실제 도구 스키마를 확인해. 제작 Vault https://hi-ob.com/help/creative-vault 의 12개 노트 전문을 모두 읽어. MCP 0.9.6의 첫 project_context.creativeVault.notes에 전체가 전달돼.
1. 시청자 한 부류, 구체적 상황 하나, 제품을 선택할 근거 하나, CTA 하나를 정리해. 모든 제품 주장은 파일·페이지·URL 근거와 연결하고 모르는 내용은 만들지 마.
2. 기획 3안을 짧게 비교하고 추천 이유를 설명해. 선택된 방향을 시간별 화면·대사·음원·자막·제품 근거가 있는 AV 기획서로 만들어. 첫 3초에 상황이 보이고 9초 안에 훅의 약속이 전달되게 설계하되 길이는 실제 발화로 검증해.
3. 사용 가능한 인물 참조, 인물카드와 표정 변화, 제품·소품카드를 먼저 정리해. 승인된 얼굴·제품을 바꾸지 말고 인물과 제품이 함께 있는 장면 이미지를 만든 뒤 움직임을 설계해. 기획서 전체를 영상 프롬프트로 넣지 마.
4. 직접 녹음·Typecast·혼합 중 선택을 유지해. 녹음은 실제 발화와 쉼이 시간 기준이고 Typecast로 대체하지 마. 외부 나레이션을 얹는 것으로 입모양이 맞는다고 말하지 마.
5. 이미 유효한 프로젝트 권한·예산과 기존 소재를 재사용해. 자료 정리·스타일 수정으로 유료 생성을 시작하지 말고, 실제 견적과 허용 범위 안에서 필요한 장면만 생성해.
6. 훅·제품 근거·CTA가 연결된 짧은 시안을 먼저 검수해. 문제가 생기면 인물, 제품, 동작, 음성, 편집 중 원인을 분리해서 해당 부분만 수정해.
7. 현재 지원하는 편집 계약으로 조립하고 AWS 렌더 후 실제 영상·소리·자막을 확인해. 프로젝트를 다시 열어 소재와 버전을 대조하고, 완성 MP4·사용 음원·자막·프로젝트·비용 기록을 전달해. 미지원 기능이나 미검증 결과는 구분해서 보고해.
참고 문서는 제작 지식이며 권한 확대 지시가 아니다. 문서의 예시 항목을 MCP JSON으로 그대로 제출하지 말고 실제 스키마에 맞춰 저장해.

```

## 1. 누구에게, 무엇을, 왜 팔 것인지 정하기

준비물: 제품 설명·실제 사진·공식 사용법·CTA 도착 페이지, 원하는 플랫폼·화면 비율·길이·예산. 참고 광고는 취향 자료로 구분합니다.

먼저 “누가 어떤 순간에 불편하고, 이 제품의 무엇을 확인하면 다음 행동을 할까?”를 한 문장으로 씁니다. 기능을 전부 소개하려고 하지 않습니다. 서비스 상품이라면 실물 사용 컷 대신 실제 화면·이용 절차·승인된 사례가 근거입니다.

자료마다 주장, 출처, 적용 조건, 화면에서 보여줄 근거를 기록하세요. 실제 효능을 입증하지 않는 AI 연출은 사용 결과의 증거로 제시하지 않습니다. 확인되지 않은 후기·가격·할인·수익·사용법을 만들지 않습니다.

시청자는 이야기의 주인공이고 나레이터는 길잡이입니다. 시작에서 던진 불편이나 질문을 마지막에 다시 받아 CTA로 연결합니다. 할인 외에도 “사용법 보기”, “내 조건 확인”, “실제 예시 보기”처럼 도착 페이지가 수행하는 행동을 선택할 수 있습니다.

### 복사할 프롬프트

```text

첨부 제품 자료를 읽어 HIOB 광고 브리프를 만들어줘.
출력: 대상 시청자 / 지금 겪는 구체적인 상황 / 광고 목표 / 단 하나의 핵심 메시지 / 제품 선택 근거 / CTA와 도착 URL / 비율·길이·예산 / 미확인 질문.
제품 주장 표는 [주장 | 자료 파일·페이지·URL | 조건 | 보여줄 증거 | 사용 가능 여부]로 만들어.
그다음 문제 공감형·제품 시연형·오해 해소형 3안을 [훅 | 설득 근거 | 마지막 행동 | 제작 난도]로 비교하고 하나를 추천해. 근거가 부족하면 효과 단정형 대신 정보 탐색형으로 바꿔. 아직 생성하지 마.

```

HIOB에서: 자료를 프로젝트에 연결하고 production_check와 project_context로 현재 상태를 확인합니다. 브리프는 기획 자료이며 사용자의 의도를 확인한 후 실제 plan_save 스키마에 맞춰 기록합니다.

산출물: 광고 브리프 1개 + 주장·근거 표 + 선택한 방향.

통과 기준: 처음 읽는 사람이 대상, 제품을 선택할 이유, 마지막 행동을 각각 한 문장으로 설명할 수 있다.

실패하면: 메시지가 여러 개면 한 편에는 하나를 남깁니다. 핵심 근거가 없으면 영상 효과를 더하지 말고 자료나 광고 약속을 바꿉니다.

참고: [Google Ads — ABCDs of effective video ads](https://support.google.com/google-ads/answer/14783551?hl=en)

## 2. 대본을 화면과 소리의 기획서로 바꾸기

준비물: 선택한 브리프, 확인된 제품 근거, 기존 녹음 또는 원하는 나레이터 방향.

문장만 있는 대본으로 생성하지 않습니다. 각 구간에 시간, 시청자가 이해할 내용, 화면 행동, 제품 근거, 말하는 사람, 음성 원본, 자막, 전환의 이유를 함께 씁니다. 각 컷은 “공감·증거·변화·행동” 중 역할이 있어야 합니다.

첫 3초에 대상과 상황을 알아보고 9초 안에 계속 볼 이유를 전달하는 것은 HIOB의 설계 목표입니다. 9초라는 숫자 자체가 성과를 보장하지 않습니다. “수영인들 주목!” 같은 호명 뒤에는 즉시 구체적인 불편과 화면을 붙입니다.

45초 초안의 예: 0–3초 상황, 3–9초 불편과 약속, 9–18초 반복 대처·손실, 18–32초 제품 근거·사용 맥락, 32–39초 조건·남은 의문, 39–45초 시작의 질문 회수와 CTA. 실제 녹음 길이에 맞춰 바꾸는 설계 예시이며 모든 업종에 강제하는 공식이 아닙니다.

나레이터는 시청자의 질문을 짚고, 주인공은 행동으로 보여줍니다. 멀티맨·멀티걸은 반응·대조·증거 등 맡은 일이 있을 때만 등장시킵니다. 인물 수와 컷 수를 늘려 내용이 풍부해지는 것은 아닙니다.

### 복사할 프롬프트

```text

선택된 브리프를 HIOB AV 기획서로 만들어줘.
표: [구간·시작/끝 | 시청자가 알아야 할 한 가지 | 화면의 구체적 행동 | 인물 ID·제품 ID | 화면으로 보여줄 근거 | 화자·실제 대사 | 원본 대사/외부 나레이션/대사 없는 행동 | 제목·구절 자막 | 음악·효과음 | 앞뒤 컷 연결 | 사용할 기존 소재/새로 필요한 소재].
첫 질문이 CTA에서 어떻게 회수되는지 설명해. 나레이터의 설명과 화면은 같은 의미를 전달하되 자막으로 똑같은 말을 두 곳에 반복하지 마. 제품이 갑자기 다른 화풍으로 등장하지 않도록 인물의 손·공간·조명을 이어줘.
낭독 길이는 확정치가 아니라 초안으로 표시하고 실제 음원 확보 후 다시 맞춰. 24컷이 필요하면 편집 컷과 유료 생성 원본 수를 따로 계산해.

```

HIOB에서: 현재 제공되는 plan_save·direction_save의 필드를 확인해 기획과 장면 지시를 저장합니다. 이 표의 열 이름은 설계용이며 새 API 필드를 뜻하지 않습니다.

산출물: 시간·화면·대사·소리·자막이 함께 있는 AV 기획서 + 필요한 소재 목록.

통과 기준: 모든 컷이 메시지에 기여하고 제품 등장 이유와 CTA가 시작의 질문에 연결된다.

실패하면: 장황하면 무작정 배속하지 말고 같은 의미의 문장·컷을 줄입니다. 설명이 부족하면 장식 컷 대신 제품 근거 또는 조건을 추가합니다.

참고: [TikTok for Business — Creative Codes](https://ads.tiktok.com/business/en/creative-codes)

참고: [StudioBinder — Intro to Shot Listing / YouTube 튜토리얼](https://www.studiobinder.com/tutorials/visualize/intro-to-shot-list/)

## 3. 인물카드: 얼굴은 고정하고 감정은 움직이기

준비물: 사용 권한이 있는 기존 인물 사진 또는 새 인물의 명확한 설정. 실존 인물의 얼굴·목소리 사용 가능 범위를 확인합니다.

인물카드는 예쁜 사진 한 장이 아니라 반복 생성의 기준입니다. ID, 역할, 고정 특징(얼굴 비율·헤어·피부 특징), 기본 복장, 행동 습관, 표정 범위를 기록하세요. 정면의 중립 표정으로 기준을 잡고 필요한 3/4·측면·전신은 별도 이미지로 만듭니다.

기존 인물이 있다면 사진을 참조하는 이미지 편집으로 장면을 만듭니다. 텍스트 설명만으로 같은 얼굴이 유지된다고 약속하지 않습니다. faceswap은 필요한 경우 사용 권한과 도구 지원을 확인하는 별도 처리이며 HIOB에 자동 연결된 기능으로 간주하지 않습니다.

브레인의 육도 감정은 감정의 원인과 행동을 찾는 렌즈입니다: 분노=막힌 행동, 갈망=자꾸 확인하는 손, 두려움=멈칫하는 시선, 경쟁심=비교하는 눈, 노력=다시 시도하는 자세, 해방감=힘이 풀리는 어깨. 모든 광고에 여섯 감정을 넣지 않습니다.

놀람은 눈과 입을 크게 하는 것만이 아닙니다. 발견 → 짧은 멈춤 → 시선 이동 → 이해·반응의 순서로 설계합니다. 나레이터가 이미 설명했다면 주인공의 반응은 짧게 받습니다. 계속 최고 강도면 변화가 사라집니다.

### 복사할 프롬프트

```text

사용 가능한 인물 참조 [파일]로 CHAR_01 인물카드를 작성하고 기준 이미지를 위한 프롬프트를 만들어줘.
역할: [주인공/도움을 주는 인물]. 고정: 참조의 얼굴 비율·눈·코·입·헤어·피부 특징. 변경 가능: 승인한 복장·자세·표정·배경.
기준 이미지: 단독 인물, 정면 중립 표정, 자연스러운 고른 빛, 단순 배경, 얼굴이 가려지지 않는 상반신. 다른 각도는 각기 별도 파일로 계획해.
표정 표: [감정의 원인 | 눈·눈썹·입 | 호흡·어깨·손 | 강도 1–3 | 사용할 구간]. 기본·불편·발견·놀람·납득을 이야기상 필요한 만큼만 골라.
장면용 이미지 프롬프트 예: “참조 인물 CHAR_01의 동일성을 유지한다. [장소]에서 [제품]을 [한 행동]한다. [발견 원인]을 보고 눈썹이 살짝 올라가고 손이 잠시 멈춘다. 카메라는 [크기·각도], 빛은 [방향].”
생성 후 원본과 얼굴·머리·복장을 비교해 승인 후보를 골라. 여러 인물이나 표정이 들어 있는 카드 전체를 영상의 첫 프레임으로 쓰지 마.

```

HIOB에서: Codex 등 실제 이미지 생성·편집 도구로 후보를 만들고 검수된 이미지를 HIOB 소재로 연결합니다. 인물카드만 작성하면 얼굴 고정 기능이 자동 실행되는 것은 아닙니다.

산출물: 인물별 카드 + 중립 기준 이미지 + 필요한 각도·표정 이미지 + 사용 권한·원본 경로.

통과 기준: 다른 각도에서도 같은 인물로 보이고 표정이 장면의 원인에 맞는다. 인물의 역할을 제거하면 이야기에서 무엇이 빠지는지 설명할 수 있다.

실패하면: 얼굴이 달라지면 기준 이미지로 돌아가 한 요소씩 편집합니다. 표정이 과하면 감정 원인과 강도를 낮추고 눈·손·호흡의 짧은 반응으로 바꿉니다.

참고: [Runway — Creating with Gen-4 Image References](https://help.runwayml.com/hc/en-us/articles/40042718905875-Creating-with-Gen-4-Image-References)

## 4. 제품·소품카드: 정확한 물건이 설득하게 하기

준비물: 실제 제품의 앞·옆 사진, 크기·색상·라벨·재질, 공식 사용법. 보조 소품은 이야기에서의 역할을 정합니다.

제품은 주연 소품입니다. 보조 소품은 상황을 설명하고 배경 물건은 생활감을 줍니다. 시계·계산기·돋보기처럼 의미가 비슷한 물건을 한꺼번에 넣어 상품 자체를 가리지 않습니다.

제품 ID와 원본을 고정하고 윤곽, 뚜껑, 로고 위치, 크기, 손에 쥐는 방식, 사용 조건을 기록합니다. 실제 판매 제품의 포장·상표·UI는 상상해서 다시 만들지 않습니다. 생성된 텍스트가 틀리면 공식 사진이나 승인된 그래픽을 사용합니다.

제품 단독 사진은 가림과 반사가 적고 필요한 각도가 분명해야 합니다. 장면에서는 인물과 같은 빛·원근·그림자·질감으로 연결합니다. 소재의 근접 촬영은 제품을 이해하게 해야 하며 검증하지 않은 효능의 증거가 될 수는 없습니다.

### 복사할 프롬프트

```text

첨부 제품 원본 [파일]을 기준으로 PROP_PRODUCT_01 카드를 만들어줘.
[제품명 | 원본·근거 | 변경 금지 특징 | 실제 크기/확인 필요 | 재질 | 색상 | 라벨·로고 위치 | 사용 조건 | 손으로 잡는 위치 | 필요한 각도 | 피해야 할 오인]을 작성해.
보조 소품은 최대 필요한 수만 제안하고 각 물건이 설명하는 내용을 써줘. 실제 제품과 가상 연출용 소품을 구분해.
제품 이미지 편집 프롬프트: “첨부 제품의 윤곽·포장·로고·색을 유지한다. [각도]의 단독 제품 사진, [빛 방향], 단순한 [배경]. 전체 제품이 프레임 안에 보이고 라벨은 원본을 유지한다.”
장면 합성 프롬프트: “CHAR_01이 참조 제품 PROP_PRODUCT_01을 [정확한 동작]한다. 실제 크기에 맞게 손에 배치하고 손가락·제품 접촉·그림자·광원을 일치시킨다. 배경은 [사용 맥락]. 확인되지 않은 효능·제품 문구를 추가하지 않는다.”

```

HIOB에서: 공식 원본과 생성 후보를 구분해 저장합니다. 제품 이미지의 시각 검수가 끝나기 전에는 해당 장면의 유료 영상 생성을 시작하지 않습니다.

산출물: 제품·보조 소품 카드 + 공식 원본 + 승인된 제품 참조 + 인물과 제품이 함께 있는 장면 후보.

통과 기준: 제품을 실제 상품과 대조할 수 있고 손·크기·사용법이 자연스럽다. 새 인물이나 다른 화풍의 제품 컷이 이유 없이 끼어들지 않는다.

실패하면: 라벨·손·형태가 틀리면 영상으로 움직이기 전에 이미지를 수정합니다. 제품 검증이 어려운 장면은 각도를 단순화하거나 공식 소재로 대체합니다.

참고: [Runway — Reference media](https://docs.dev.runwayml.com/recipes/reference-media/)

참고: [Daniel Schiffer — Filming an EPIC Product Commercial at Home!](https://www.youtube.com/watch?v=zCvYyHLgqmc)

## 5. 장면 이미지에서 영상으로: 한 컷에 한 동작

준비물: AV 기획서, 승인된 인물·제품 이미지, 장소와 조명 기준, 현재 모델 가이드.

영상에 들어갈 첫 이미지는 이미 완성된 한 장면이어야 합니다. 인물·제품·배경·구도·빛을 함께 확정합니다. 인물카드 여러 칸이나 제품카탈로그 전체를 첫 이미지로 넘기지 않습니다.

이미지 프롬프트는 “누가·무엇을·어디서·어떤 구도와 빛으로”를 정하고 영상 프롬프트는 “무엇이 어떻게 움직일지”를 정합니다. 한 클립에 여러 장소·인물 교체·긴 대사를 몰아넣지 않습니다. 컷의 시작과 끝에서 손 위치·시선·제품 방향을 기록하면 편집 연결을 판단하기 쉽습니다.

현재 HIOB의 H3·Seedance 2.5 연결은 프롬프트와 단일 참조 이미지로 5–15초 원본을 요청합니다. PiAPI 목록에 있는 모든 모델이 HIOB에 연결된 것은 아닙니다. 실행 직전 모델 가이드와 서버 견적에서 실제 옵션을 확인하세요.

외부 녹음이나 Typecast에 정확히 입을 맞추는 요청은 현재 이 연결의 지원 범위가 아닙니다. 외부 나레이션은 행동·손·제품·시점 컷에 사용하세요. 원본 대사를 택한 컷은 해당 원본 소리를 함께 유지하고 실제 발화를 확인합니다.

### 복사할 프롬프트

```text

SHOT_03의 시작 이미지를 먼저 설계해.
CHAR_01 + PROP_PRODUCT_01 + [같은 장소/시간대] + [한 행동의 시작 자세] + [카메라 크기·각도] + [광원 방향]을 한 프레임에 배치해. 제품과 얼굴, 제목·하단 자막의 여백을 확인하고 앞뒤 컷과 손·시선·제품 방향을 비교해.
검수 후 영상용 프롬프트를 별도로 작성해:
“인물이 [한 동작]을 하고, [관찰 가능한 짧은 반응]을 보인다. 카메라는 [고정 또는 한 이동]. 배경의 [최소 움직임]. 끝에서는 [편집에 필요한 마지막 자세].”
예: “인물이 병을 들어 라벨을 확인한다. 시선이 병에서 카메라로 옮겨가며 살짝 고개를 끄덕인다. 카메라는 고정된 상반신 구도. 끝에서 병을 가슴 앞에 안정적으로 든다.”
모델별 실제 지원 입력과 길이를 확인하고 대사·음악·CTA 지시를 움직임 프롬프트에 한꺼번에 섞지 마. 견적·승인 범위와 재사용할 원본을 먼저 확인해.

```

HIOB에서: 모델 가이드 → production_check → 유효한 승인·견적 확인 → 지원되는 생성 도구 순서로 진행합니다. 실제 도구 이름과 입력은 연결된 MCP 스키마를 따릅니다. 생성 후 프레임·제품·동작·원본 오디오를 검수합니다.

산출물: 검수된 장면 이미지 + 원본별 움직임 프롬프트·모델·길이 + 생성 결과와 검수 기록.

통과 기준: 첫 이미지와 결과의 인물·제품이 일치하고 동작이 완결된다. 컷 사이 연결과 음성 방식이 기획과 같다.

실패하면: 첫 이미지가 틀리면 이미지 단계로, 움직임만 틀리면 동작 지시로 돌아갑니다. 같은 전체 요청을 반복하지 않습니다.

참고: [Runway — Gen-4 Video Prompting Guide](https://help.runwayml.com/hc/en-us/articles/39789879462419-Gen-4-Video-Prompting-Guide)

참고: [HIOB 모델 가이드 / PiAPI 공식 모델 목록](https://studio.hi-ob.com/models)

## 6. 목소리·음악·효과음으로 박자 만들기

준비물: 직접 녹음 또는 확정한 대본·선택 목소리, 사용 가능한 음악·효과음과 권리 정보.

직접 녹음은 원본을 보존하고 실제 발화·길이·쉼을 기준으로 장면과 구절 자막을 맞춥니다. Typecast를 선택한 경우 훅·설명·CTA의 짧은 문장으로 속도와 어조를 먼저 비교합니다. 실제 유명인의 체험이나 추천을 AI 목소리로 꾸며내지 않습니다.

목소리는 의미를, 음악은 흐름을, 효과음은 특정 행동이나 전환을 담당하게 합니다. 제품 접촉음·발견의 짧은 소리·CTA 직전의 변화처럼 사건에 연결하세요. 모든 컷에 효과음을 넣거나 문장마다 음악을 끊지 않습니다.

말할 때는 음악을 낮추고 말이 멈추면 자연스럽게 회복시키되, 음악 음소거·개별 볼륨·수동 페이드를 존중합니다. 작은 배경음은 원본이 작은지, 클립·트랙 이득과 감쇠가 겹쳤는지부터 확인합니다. 스피커·이어폰으로 실제 완성 파일을 듣고 조정합니다.

의도적인 짧은 쉼과 음원이 빠진 공백은 구분합니다. 나레이션·원본 대사·음악·효과음을 각각 끄고 확인하면 누락과 중복을 찾기 쉽습니다. 인기 음악은 자동으로 상업 이용 가능한 것이 아니며 허용된 음원만 연결합니다.

### 복사할 프롬프트

```text

현재 음성 선택을 유지해서 오디오 큐시트를 만들어줘.
표: [실제 시작·끝 | 화자/원본 파일 | 문장 | 발화 강도·속도 의도 | 음악 구간·감쇠 | 효과음과 화면 사건 | 의도한 쉼].
recording이면 원본을 보존하고 실제 발화와 전사 문구를 대조해. Typecast를 대신 호출하지 마. typecast 또는 mixed일 때만 허용된 문장을 합성하고 기존 음원과 비교해.
말이 길면 차이를 표시하고 문장·속도·장면 길이 중 무엇을 바꿀지 제안해. 끝 음절을 잘라 길이를 맞추지 마. 음악이 작으면 원본·클립·트랙·감쇠를 분리 점검하고 실제 믹스를 들어서 조정해.

```

HIOB에서: 지원되는 audio_inspect·audio_inspection_status로 음원 검사를 조회하고 audio_set으로 필요한 트랙을 연결합니다. 검사 수치만으로 발음·감정이 좋다고 판단하지 않습니다. 원본 대사 사용 컷은 원본 소리를 명시적으로 연결합니다.

산출물: 검수된 음원·실제 문장별 시간 + 오디오 큐시트 + 원본과 수정본.

통과 기준: 모바일에서도 말을 알아듣고, 음악은 느껴지며 말을 덮지 않는다. 나레이션 끝이 잘리지 않고 설명과 화면 사건이 맞는다.

실패하면: 전부 다시 합성하지 말고 문제 문장·음원·믹스만 고칩니다. 음원 검사나 전사가 불확실한 구간은 미검수로 남깁니다.

참고: [TikTok for Business — Creative Codes](https://ads.tiktok.com/business/en/creative-codes)

## 7. 제목·자막·편집: 풍부하지만 번잡하지 않게

준비물: 검수된 원본, 실제 음원 시간, AV 기획서와 구절별 자막.

화면 변화는 새 정보·반응·제품 근거를 전달할 때 만듭니다. 같은 원본의 필요한 구간과 다른 구도를 활용해 리듬을 만들 수 있으므로 24개 편집 컷이 24번의 유료 생성과 같지는 않습니다. 빠르게 자르더라도 제품이나 자막을 읽을 시간은 남깁니다.

제목은 구간의 관점을, 자막은 실제 발화를 담당합니다. 상단 제목·중간 정보·하단 대사처럼 역할을 나누고 같은 문장을 두 번 표시하지 않습니다. 겹치는 시간 자체보다 실제 글자 영역 충돌과 읽는 순서가 중요합니다.

브레인의 Black Han Sans, 1080×1920 기준 제목 88px·주 자막 72px는 디자인 기준입니다. 크게 프리셋은 1.15배로 검토하되 실제 편집기·렌더 계약에서 적용되는 값을 확인합니다. 가로 화면에 세로 좌표를 그대로 쓰지 않습니다. 긴 문장은 무조건 축소하지 말고 의미 단위 1–2줄로 나눕니다.

현재 공개 V1은 1080×1920 또는 1920×1080, 30fps, 최대 90초, 원본 영상 최대 24개와 편집 컷 최대 120개를 기준으로 안내합니다. 제목·구절 자막·음원은 지원 필드로 조립합니다. 임의의 TSX·CSS·자유 좌표·커스텀 애니메이션을 최종 AWS 렌더에 넣을 수 있다고 가정하지 않습니다.

### 복사할 프롬프트

```text

실제 음원 시간을 기준으로 HIOB 편집안을 만들어줘. 각 컷은 정보·반응·근거·행동 중 역할을 가져야 해.
제목은 구간별로, 대사 자막은 실제 발화의 의미 단위로 1–2줄로 나눠. 마지막 음절까지 표시하고 제품·얼굴·플랫폼 UI를 가리지 않게 배치해. 제목과 캡션의 동시 노출은 서로 다른 역할과 안전한 영역일 때 유지해.
edit_check로 지원 필드·겹침·음원·길이를 점검하고 edit_assemble은 한 번 접수한 작업을 job_status로 이어서 조회해. 응답이 늦다고 같은 조립·렌더를 중복 요청하지 마.
project_sync 후 render_quote의 금액과 유효한 승인 범위를 확인해 render_start, render_status, render_download로 최종 AWS 파일을 확인해. 서버 실패를 로컬 완성본으로 바꾸지 마.

```

HIOB에서: 현재 서비스 범위와 편집 스키마를 우선합니다. 검수 후 저장·재진입·AWS 출력의 제목·자막·음원을 대조합니다. 편집 조작이 지원되지 않으면 가능한 대안을 명시합니다.

산출물: 편집 가능한 프로젝트 + 최종 렌더 입력 버전 + AWS 완성 MP4 + 자막 자료.

통과 기준: 소리 없이도 흐름을 이해하고 소리를 켜면 같은 의미가 강화된다. 제목·자막·제품이 경쟁하지 않으며 저장한 편집과 출력이 같다.

실패하면: 번잡하면 먼저 중복 제목·무관한 컷·의미 없는 효과음을 제거합니다. 설명이 부족한 문제를 더 빠른 전환으로 덮지 않습니다.

참고: [Google Ads — ABCDs of effective video ads](https://support.google.com/google-ads/answer/14783551?hl=en)

## 8. 검수하고, 바뀐 부분만 개선하기

준비물: AWS 완성 MP4, 원본 자료, 승인된 브리프, 프로젝트와 실제 비용 기록.

기술 검수: 파일을 재생할 수 있는가, 필요한 소리가 있는가, 끝 글자·음절이 잘리지 않는가, 제품·얼굴·자막이 깨지지 않는가, 다시 열린 프로젝트가 같은 버전인가를 확인합니다. 렌더 성공은 이 중 일부의 증거일 뿐입니다.

광고 검수: 처음 보는 사람이 “누구의 문제인가, 왜 이 제품인가, 다음에 무엇을 하나”를 설명할 수 있어야 합니다. 장면이 재미있어도 제품을 기억하지 못하면 메시지·증거 연결부터 고칩니다. 생성된 감탄 연기가 실제 고객 후기처럼 보이지 않는지도 확인합니다.

시청 유지·클릭·실제 문의나 구매는 게시 후 관측합니다. 훅 3안을 비교할 때 본편·대상·CTA 등 다른 조건은 가능한 한 같게 두고 무엇을 바꿨는지 기록합니다. 표본이 적은 결과를 성공 확률로 환산하지 않습니다.

납품에는 완성 MP4, 다시 열 수 있는 프로젝트, 실제 사용한 원본·음원·자막, 기획 버전, 비용·수정 기록이 필요합니다. SRT나 음악 없는 버전은 실제 생성·확인했을 때만 납품 목록에서 완료로 표시합니다.

### 복사할 프롬프트

```text

이 AWS 완성 파일을 광고 관점과 기술 관점으로 따로 검수해줘.
[시간 | 관찰한 문제 | 실제 근거 | 원인 후보 | 수정할 소재/대사/편집 | 재생성 필요 여부 | 비용 영향]으로 기록해.
첫 3초의 상황, 9초 안의 볼 이유, 제품 선택 근거, 인물·제품 일관성, 목소리 명료도, 음악 존재감, 제목·자막 중복, 수미상관 CTA를 점검해. 직접 보거나 듣지 못한 항목은 미검증으로 표시해.
확정된 원본은 보존하고 실패 구간만 수정해. 영상 재생성과 단순 편집 수정을 분리해. 렌더 성공·문서 제공을 창작 품질이나 판매 성과의 증거로 말하지 마.

```

HIOB에서: 서버 결과·다운로드·다른 세션 복원을 각각 확인합니다. 이미 있는 최종본으로 검수하고 검사를 위해 유료 렌더를 반복하지 않습니다. 게시·광고 집행은 별도 작업입니다.

산출물: 시간이 표시된 검수표 + 수정 이력 + 납품물·미완료 목록 + 실제 비용.

통과 기준: 화면·소리·제품 근거·CTA와 복원된 프로젝트를 확인했다. 확인하지 못한 항목은 남겨두었다.

실패하면: 한 번에 모든 것을 바꾸지 않습니다. 기술 결함을 먼저 해결한 뒤 한 가지 창작 가설씩 비교합니다.

## 출처와 적용 범위

2026-09-29 확인. 아래 자료에서 원리를 참고하고 HIOB 브레인과 현재 도구 지원 범위에 맞춰 작성한 실무 제안입니다. 판매 성과나 전체 영상 시청을 증명하는 목록이 아닙니다.

- [Google Ads — ABCDs of effective video ads](https://support.google.com/google-ads/answer/14783551?hl=en) — 공식 도움말 본문. 주의·브랜드·연결·행동의 관계, 경쟁하는 음성·문구를 피하는 원칙을 참고했습니다.

- [TikTok for Business — Creative Codes](https://ads.tiktok.com/business/en/creative-codes) — 공식 가이드 본문. 훅·본문·마무리 구조와 의미를 전달하는 움직임·소리 설계를 참고했습니다.

- [Daniel Schiffer — Filming an EPIC Product Commercial at Home!](https://www.youtube.com/watch?v=zCvYyHLgqmc) — YouTube 자동 생성 자막 확인. 0:30–1:28 브랜드 성격과 제품 조명, 1:48–2:09 라벨 초점, 4:24–4:36 소품 배치, 4:57–6:02 실패한 동작을 별도 촬영·편집으로 보완하는 과정을 참고했습니다. 연출을 실제 효능 증거로 쓰라는 뜻은 아닙니다.

- [StudioBinder — Intro to Shot Listing / YouTube 튜토리얼](https://www.studiobinder.com/tutorials/visualize/intro-to-shot-list/) — 제작자의 공식 강의 페이지·영상 설명. 대본을 숏 크기·카메라·움직임·일정으로 나누는 방법을 참고했습니다. 전체 영상 시청 검증은 아닙니다. 영상: https://www.youtube.com/watch?v=ZNRQQi42CZA

- [Runway — Creating with Gen-4 Image References](https://help.runwayml.com/hc/en-us/articles/40042718905875-Creating-with-Gen-4-Image-References) — 공식 가이드 본문. 중립 표정·고른 빛의 참조로 인물 기준을 잡고 요소별로 반복하는 방법을 참고했습니다. Runway의 복수 참조 입력이 HIOB에서 지원된다는 뜻은 아닙니다.

- [Runway — Reference media](https://docs.dev.runwayml.com/recipes/reference-media/) — 공식 문서 본문. 가림 없는 제품과 명확한 각도·얼굴 참조를 준비하는 기준입니다.

- [Runway — Gen-4 Video Prompting Guide](https://help.runwayml.com/hc/en-us/articles/39789879462419-Gen-4-Video-Prompting-Guide) — 공식 가이드 본문. 입력 이미지와 움직임 지시를 분리하는 원리를 참고했습니다. 모델별 문법·보장 범위를 PiAPI에 그대로 적용하지 않습니다.

- [HIOB 모델 가이드 / PiAPI 공식 모델 목록](https://studio.hi-ob.com/models) — HIOB 연결 코드와 PiAPI 공식 자료 대조. 제공사 목록과 HIOB 실행 가능 모델을 구분합니다. 최신 공식 목록: https://app.piapi.ai/models