Sora 2 프롬프트 가이드 2026: API 종료 전에 남겨야 할 샷 설계

2026년에 Sora 2 프롬프트를 배운다면 먼저 관점을 바꿔야 한다. 새 앱 사용법을 따라 하는 것이 아니라, 나중에 다른 영상 모델이나 제작 경로로 옮길 수 있는 샷 설계로 남기는 것이 핵심이다. OpenAI는 Sora Web/App 경험이 2026년 4월 26일에 중단되었다고 안내했고, Sora API도 2026년 9월 24일에 종료될 예정이라고 설명한다. 그래서 안전한 작성 순서는 분명하다. API 설정과 프롬프트 문장을 분리하고, 각 아이디어를 검토 가능한 샷 설계로 적고, 접근 권한, 정책, 비용, API 생명주기가 원인일 때는 문장 수정을 멈춰야 한다.

지금 필요한 Sora 2 프롬프트 가이드

지금 도움이 되는 것은 화려한 프롬프트 100개가 아니다. 실제로 필요한 것은 경로, 설정, 피사체, 동작, 카메라, 빛, 색, 소리, 기대 결과, 중단 규칙을 한 장에 남기는 습관이다. 이 구조는 특정 인터페이스보다 오래 남는다. Sora 경로가 끝나거나 다른 도구로 옮겨야 할 때도, 샷의 의도와 검토 기준은 그대로 사용할 수 있다.

한국어 독자는 프롬프트 예시, 작성 가이드, API 파라미터, 카메라 프레이밍, 엑셀 템플릿 같은 단서를 함께 기대한다. 이 언어 감각은 중요하지만, 그대로 본문을 복잡하게 만들 필요는 없다. 독자가 원하는 것은 "어떤 문장을 넣으면 되나"보다 "어떤 항목을 따로 적어야 실패를 줄이나"에 가깝다. 먼저 지금 쓸 수 있는 경로를 확인하고, 그 다음 샷을 설계하고, 마지막에 결과를 기록해야 한다.

API 설정과 프롬프트 문장을 분리한다

Sora 2에서 재시도가 낭비되는 가장 흔한 이유는 프롬프트 문장에 요청 설정까지 떠넘기는 것이다. 문장은 화면과 소리를 지시한다. 모델, 크기, 길이, 캐릭터, 참고 이미지, 호출 경로는 요청 설정이나 작업 기록에 따로 적어야 한다.

본문을 쓰기 전에 다음 표를 먼저 채운다.

예를 들어 "세로 12초 Pro 영상으로 만들어줘"를 문장 안에만 쓰면 검토가 어렵다. 더 좋은 기록은 seconds: 12, size: 720x1280, 모델, 참고 입력을 설정 쪽에 적고, 문장에는 보는 사람이 어떤 장면을 보아야 하는지만 쓰는 것이다.

기본 구조는 이렇게 나눌 수 있다.

hljs text复制
Request layer:
Route:
Model:
Size:
Seconds:
Character or input reference:

Prompt layer:
Subject:
Action beats:
Camera and framing:
Motion:
Lighting and palette:
Audio:
Constraints:

Log layer:
Expected result:
Observed result:
Next move:
Stop rule:

이 분리는 2026년에 더 중요하다. 경로 자체가 시간 제한을 가진다. API가 사라지면 더 멋진 형용사가 접근을 되돌리지 못한다. 정책 때문에 거절된 요청이라면 같은 의도를 부드럽게 숨기는 방식도 해결책이 아니다. 분리된 기록은 원인이 문장인지, 설정인지, 권한인지, 비용인지, 생명주기인지 빠르게 보게 해준다.

실무에서는 "요청 카드"와 "샷 카드"를 따로 둔다. 요청 카드는 경로, 모델, 크기, 길이, 참고 입력, 날짜만 기록한다. 샷 카드는 피사체, 동작, 카메라, 조명, 소리, 제약, 합격 기준만 기록한다. 결과가 짧으면 길이와 동작을 보며, 방향이 틀리면 크기와 구도를 본다. 피사체가 흔들리면 기준 이미지와 피사체 고정 문장을 본다. 오류가 권한이나 정책을 말한다면 문장에 형용사를 더하지 않는다.

프롬프트 모음이 아니라 샷 설계를 쓴다

샷 설계는 작은 제작 카드다. 프롬프트 갤러리의 예쁜 한 문장이 아니라, 촬영팀과 편집자가 볼 수 있는 지시서에 가깝다. 길게 쓰는 것이 목적이 아니라, 결과를 판단할 수 있게 쓰는 것이 목적이다.

다음 필드를 사용한다.

출력은 항상 이 카드와 비교한다. 카메라는 좋지만 컵 모양이 변했다면 카메라는 유지하고 피사체 고정을 강화한다. 동작이 너무 빠르다면 seconds나 action beats를 바꾼다. 시스템이 요청을 거절한다면 같은 의도를 더 은근히 쓰지 말고 원인을 진단한다.

팀 작업에서도 샷 설계가 유용하다. 마케팅 담당자는 장면의 목적을 확인하고, 디자이너는 색과 브랜드 위험을 보며, 개발자는 경로와 파라미터를 본다. 한 사람이 "더 고급스럽게"라고 말하고 다른 사람이 "더 영화처럼"이라고 말하는 상태에서는 재시도가 계속 흐려진다. 카드가 있으면 한 번에 한 필드만 고칠 수 있다.

모호한 아이디어를 제어 가능한 샷으로 바꾸기

좋은 예시는 편집 결정을 보여준다. 단순한 복사 문장은 경로, 설정, 합격 기준이 없으면 제작 워크플로의 절반만 채운다.

이 예시를 그대로 외우지 말고 변환 방식을 가져가야 한다. 먼저 피사체를 고정하고, 그 다음 2~4개의 보이는 변화를 순서대로 적고, 카메라와 움직임을 정한 뒤, 마지막에 제약과 합격 기준을 붙인다. 제품 영상에서는 글자와 형태 위험이 중요하고, 짧은 스토리 장면에서는 동작의 안전 경계가 중요하며, 자연 장면에서는 물리적 행동과 과장 방지가 중요하다.

API 종료 전에 prompt log를 남긴다

prompt log는 개별 시도를 지식으로 바꾼다. 로그가 없으면 매번 새로운 문장 문제처럼 보인다. 로그가 있으면 참고 이미지, 길이, 정책, 비용, 경로, 장면 중 무엇이 결과를 바꿨는지 볼 수 있다.

한 줄 로그는 짧아도 된다.

로그는 지루할수록 좋다. 어떤 필드가 바뀌었고, 결과가 어떻게 바뀌었으며, 언제 멈춰야 하는지를 보여주기 때문이다.

특히 다음을 기록한다.

• 참고 이미지가 문장보다 결과를 더 크게 바꾸는 경우.
• 캐릭터, 제품, 피사체 일관성 테스트.
• 길이를 늘릴수록 motion error가 늘어나는 경우.
• 안전하게 다시 쓴 뒤에도 invalid prompt나 policy rejection이 반복되는 경우.
• 비용 때문에 재시도마다 이유가 필요한 작업.
• API 종료 이후 다른 경로로 옮겨야 할 작업.

실패도 반드시 남긴다. 영상 생성에서는 성공 문장보다 실패 기록이 더 유용할 때가 많다. 어떤 장면에서 가짜 글자가 생기는지, 어떤 움직임이 형태를 무너뜨리는지, 어떤 길이가 동작을 잃게 하는지, 어떤 정책 경계는 우회하면 안 되는지를 알려주기 때문이다. 나중에 다른 모델로 옮길 때 이 기록이 빠른 대조 테스트가 된다.

외부 서비스가 더 빠르다, 싸다, 안정적이다라고 말하더라도 그 문장을 사실처럼 기록하지 않는다. 경로 소유자와 자신의 테스트로 확인하지 않았다면 공급자 주장으로만 적고, 샷 설계의 검토 기준과 섞지 않는다.

다음 단계가 프롬프트가 아닌 경우

문장 수정은 원인이 아직 문장일 때만 유효하다. 원인이 다른 소유자에게 넘어갔는데도 계속 문장을 고치면 진단이 늦어진다.

안전이나 권리와 관련된 요청에서는 중단 규칙이 더 빨라야 한다. 유명인을 암시하거나, 저작권 캐릭터를 돌려 말하거나, 필터 회피를 요청하거나, 속이는 표현으로 감싸서는 안 된다. 허용되는 작업인데 설명이 모호하거나 구조가 약할 때만 다시 쓴다.

또 하나의 중단 규칙은 생명주기다. 2026년 9월 24일 이후에도 반복되어야 하는 제작이라면 Sora 전용 설정에 모든 절차를 묶지 않는다. 샷 설계, settings, accepted output, result notes를 남기고 다른 영상 경로에서 테스트할 준비를 한다. 자산은 임시 경로가 아니라 설계 기록이다.

한 번의 프롬프트를 돌리는 실무 순서

실제 프로젝트에서는 루프를 짧게 유지한다.

1. route와 현재 상태를 먼저 적는다.
2. model, size, seconds, reference를 문장에서 분리한다.
3. subject, action beats, camera, motion, lighting, audio, constraints로 샷을 쓴다.
4. route가 여전히 작업을 지원할 때만 생성한다.
5. 막연한 감상이 아니라 expected result와 비교한다.
6. 한 번에 하나의 주요 변수만 바꾼다.
7. 두 번의 집중 실패 후에는 로그에 명확한 다음 원인이 없으면 멈춘다.
8. accepted brief, settings, output, migration note를 저장한다.

시작 문장은 다음 정도면 충분하다.

hljs text复制
Create an 8-second video shot of [subject anchor] in [setting].
The shot begins with [starting frame], then [action beat 1], [action beat 2], and [ending beat].
Use [camera framing] with [camera movement], keeping [protected detail] stable throughout.
Lighting should be [lighting], with [palette] and [depth or texture cue].
Audio should include [ambient sound or silence] and avoid [unwanted sound].
Do not add readable brand text, public logos, celebrity likenesses, or extra characters.
The acceptable result is [specific output standard].

이 문장이 특별해서 좋은 것이 아니다. 중요한 것은 주변의 기록이다. route, settings, expected result, stop rule이 있을 때만 문장이 제작 도구가 된다. 스타일이 바뀌면 필드를 바꾸고, 모델이 바뀌면 경로 메모를 바꾼다.

자주 묻는 질문

2026년에도 Sora 2 프롬프트를 배울 가치가 있나요?

있다. 다만 새 앱 절차로 배우는 것이 아니라 이동 가능한 샷 설계로 배울 때 가치가 있다. Web/App은 중단되었고 API도 예정된 종료일이 있으므로, 구조와 로그를 남기는 데 초점을 맞춰야 한다.

Sora 2 프롬프트에는 무엇을 써야 하나요?

피사체, 장면, 동작, 카메라, 움직임, 조명, 색, 소리, 제약, 기대 결과를 쓴다. model, size, seconds, characters, input reference는 request settings에 분리한다.

model, size, seconds는 프롬프트 문장인가요?

아니다. 이것들은 요청 설정이다. 문장에서 리듬을 설명할 수는 있지만, 길이와 출력 형식의 실제 소유자는 경로가 지원하는 파라미터다.

Sora 2 프롬프트 생성기를 써도 되나요?

초안 도우미로는 쓸 수 있다. 그러나 결과를 자신의 샷 설계로 다시 쓰고, route, settings, expected result, log를 붙인 뒤에 저장해야 한다.

invalid prompt는 더 좋은 문장으로 고칠 수 있나요?

원인이 모호함이나 구조 부족이면 가능하다. 그러나 허용되지 않는 요청, 접근 불가, 비용 문제, API 종료는 문장 수정으로 해결되지 않는다.

프롬프트는 길수록 좋은가요?

아니다. 샷을 판단할 수 있을 만큼이면 충분하다. 동작이 있는 100~150단어 수준의 구조화된 설계가 형용사로 가득한 긴 문장보다 다루기 쉽다.

참고 이미지나 characters가 문장 세부사항을 대신할 수 있나요?

대신할 수 없다. 참고 입력은 외형을 고정하는 데 도움이 되지만, action, camera, motion, lighting, constraints는 여전히 필요하다.

Sora API 종료 이후에는 어떻게 해야 하나요?

같은 route가 계속된다고 가정하지 않는다. 샷 설계, settings, accepted output, result notes를 남기고 다른 영상 경로에서 다시 테스트한다.