AI 영상 제작팀을 설계시키는 긴 프롬프트를 뜯어봤습니다 — 같은 이야기가 세 번 나옵니다

공유된 화면 캡처 한 장을 받았습니다. 클로드 오퍼스 5.5에게 영상 제작용 AI 에이전트 팀을 설계해 달라고 시키는 프롬프트였고, 화면에 "프롬프트 복사" 버튼이 달려 있었습니다. XML 태그로 칸을 나눈 긴 글이었습니다. 이 글은 그 프롬프트를 돌려 본 기록이 아닙니다. 읽고, 구조를 세어 보고, 제 경험과 견준 기록입니다.

원문은 옮기지 않습니다. 남의 글이기도 하고, 이 글의 요점이 문장이 아니라 구조이기 때문입니다.

먼저 무엇을 시키는 프롬프트인가

영상을 만들어 주는 프롬프트가 아닙니다. 영상을 만들 팀을 설계해 주는 프롬프트입니다. 출력은 영상이 아니라 문서입니다. 팀 구성, 에이전트별 설계도, 제작 흐름도, 프롬프트 모음, 일주일 계획 같은 것들이 줄줄이 나옵니다.

이 차이가 중요합니다. 결과물이 문서라면 모델이 잘했는지는 영상을 만들어 봐야 알 수 있습니다. 문서 단계에서는 그럴듯한지만 보입니다.

숫자를 세어 보니 겹칩니다

캡처를 보면서 가장 먼저 한 일은 번호 매겨진 목록을 세는 것이었습니다.

여기에 규칙 8개와 끝에서 확인할 점검 5개가 따로 붙습니다.

세 목록을 나란히 놓으면 같은 이야기가 세 번 나옵니다. 팀을 정하는 이야기는 절차 3번, 영역 2번, 출력 2번에 있습니다. 설계도는 절차 4번, 영역 3번, 출력 3번입니다. 흐름은 절차 2번과 5번, 영역 4번, 출력 4번입니다. 프롬프트는 절차 6번, 영역 5번, 출력 5번입니다.

그림의 같은 색 점이 그 겹침입니다. 겹치는 것 자체가 나쁜 일은 아닙니다. 모델에게 같은 요구를 순서·구조·형식 세 방향에서 거듭 말해 주는 셈이라 빠뜨릴 확률은 줄어듭니다. 다만 값이 있습니다. 한 군데를 고치면 나머지 두 곳도 고쳐야 합니다. 절차에서 단계 하나를 빼면 영역과 출력에 그 단계 이야기가 남아 서로 어긋납니다.

최적화는 어디로 갔나

세부 영역의 마지막은 최적화입니다. 그런데 출력 9항목 어디에도 최적화라는 이름의 칸이 없습니다.

가장 가까운 것은 "흔한 실수"와 "최종 권고"입니다. 모델이 거기에 최적화 이야기를 풀어 넣을 수도 있습니다. 하지만 이건 제 짐작입니다. 프롬프트가 그렇게 하라고 적어 둔 것은 아닙니다. 짝이 없는 영역은 모델이 어디에 쓸지 스스로 정해야 하고, 그러면 돌릴 때마다 위치가 달라질 수 있습니다.

작은 얘기 같지만 이 프롬프트의 성격을 보여 줍니다. 영역을 적을 때와 출력을 적을 때 서로 대조하며 쓰지 않았다는 흔적입니다. 긴 프롬프트는 이렇게 자랍니다. 한 번에 쓰지 않고 칸을 덧붙이면서 쓰기 때문에, 어느 칸은 짝이 생기고 어느 칸은 안 생깁니다.

점검 5개는 누가 확인하나

끝에 "최종 점검" 다섯 개가 붙어 있었습니다. 이런 칸을 좋아하는 편입니다. 모델에게 "다 쓴 뒤에 이걸 확인하라"고 시키면 빠뜨림이 줄어드는 경우가 실제로 있습니다.

다만 짚어 둘 것이 있습니다. 점검하는 쪽도 같은 모델입니다. 스스로 쓴 글을 스스로 "통과"라고 말하는 것이라, 점검 항목이 많다고 검증이 되지는 않습니다. 확인 가능한 점검과 확인 불가능한 점검은 다릅니다. 예를 들어 "각 에이전트의 입력과 출력이 적혀 있는가"는 글을 읽으면 셀 수 있습니다. "팀이 효율적인가"는 셀 수 없습니다.

저는 영상 하나를 만들 때 이게 필요했습니다

이 프롬프트를 읽으면서 계속 제가 만든 영상 하나를 떠올렸습니다. 저를 소개하는 20초짜리 글자 모션그래픽입니다. 1920×1080, 60프레임이고, 캔버스에 그린 장면을 헤드리스 크롬으로 한 프레임씩 받아 ffmpeg로 묶습니다. 명령 한 줄로 약 30초면 다시 구워집니다.

에이전트 팀은 없었습니다. 대신 파일이 세 개 있었습니다.

• 디자인 문서: 색은 네 가지만, 서체는 무엇, 한 장면에서 포인트색이 차지하는 면적은 몇 퍼센트 이하, 하는 식으로 정해 둔 계약서입니다. 영상을 고칠 때 저는 이 문서만 보고 판단합니다.
• 박자표: 몇 초에 어느 글자가 들어오고 나가는지를 적은 JSON입니다. 영상과 음악이 어긋나는지는 이 표를 보면 압니다.
• 싱크 검사 스크립트: 박자표와 실제 렌더 결과가 맞는지 숫자로 비교합니다.

이 셋을 위 프롬프트의 단계에 대 보면 디자인 문서는 "인수인계 설계"에, 싱크 검사는 "검토·QA"에 가깝습니다. 그런데 둘 다 모델의 말이 아니라 파일과 숫자였다는 점이 달랐습니다. 점검 항목을 글로 적어 두는 것과, 돌리면 통과·실패가 나오는 검사를 갖는 것은 다른 일이었습니다.

처음엔 15초였고, 글자가 보이질 않았습니다

처음에는 15초로 만들었습니다. 보여 준 사람이 "글자가 읽히기 전에 지나간다"고 했습니다. 재 보니 한 장면에서 글자가 온전히 보이는 시간이 0.3~0.6초였습니다. 등장하는 연출과 퇴장하는 연출에 시간을 다 쓰고 있었던 겁니다. 그래서 20초로 늘리고 머무는 시간을 따로 확보했습니다.

이 문제는 어떤 설계 프롬프트에서도 나오지 않았을 겁니다. 영상을 틀어 보고 시간을 재야 보이는 문제이기 때문입니다. 위 프롬프트의 출력 항목 어디에도 "머무는 시간"은 없습니다. 문서 단계에서 잡을 수 있는 종류의 문제가 아닙니다.

이 프롬프트에서 가져다 쓸 것

비판만 하려는 글은 아닙니다. 가져다 쓸 만한 것이 분명히 있었습니다.

1. 입력과 출력을 에이전트마다 적게 하는 칸. 인수인계가 어디서 끊기는지는 이걸 적어 봐야 보입니다. 혼자 만드는 작업에도 "이 단계가 받는 것, 내놓는 것"을 한 줄씩 쓰면 빠진 연결이 드러납니다.
2. 흔한 실수를 먼저 쓰게 하는 칸. 모델이 아는 실패 사례를 미리 꺼내 놓게 합니다. 다만 모델이 아는 실패와 내 작업에서 날 실패는 다를 수 있습니다.
3. 일주일 계획. 설계가 끝이 아니라 일정으로 닫힙니다. 실행까지 가는 문서인지 아닌지가 여기서 갈립니다.

반대로 쓰지 않을 것도 있습니다. 8단계 절차와 7영역, 9항목을 그대로 겹쳐 쓰는 구조는 따라 하지 않을 생각입니다. 하나만 남기고 나머지는 거기서 뽑아 쓰는 쪽이 고치기 쉽습니다. 제가 모션 프롬프트 연재에서 쓰는 방식도 그렇습니다. 모션 프롬프트 ① 이징은 "부드럽게" 대신 곡선 이름을 적으라는 한 가지만 다룹니다. 칸 하나가 지시 하나에 대응하게 쪼개 두면 어긋날 일이 적습니다.

확인하지 못한 것

• 프롬프트를 돌려 보지 않았습니다. 이 구조로 실제로 어떤 팀 설계가 나오는지, 그 설계로 영상이 만들어지는지는 모릅니다. 위 이야기는 전부 구조를 읽은 데서 나온 것입니다.
• 캡처에 안 보이는 부분이 있을 수 있습니다. "프롬프트 복사" 화면이라 길이가 잘렸을 수 있고, 최적화 칸이 어딘가에 따로 다뤄질 가능성을 배제하지 못합니다.
• 누가 어떤 목적으로 쓴 프롬프트인지 모릅니다. 영상 제작 현업의 것인지, 시연용 견본인지 알 수 없어서 좋고 나쁨은 평가하지 않았습니다. 구조의 특징만 적었습니다.
• 생성형 영상 도구로 만들어 본 경험이 없습니다. 제가 만든 영상은 코드로 그린 글자 모션이라, 사진 같은 영상을 뽑는 도구와는 작업이 다릅니다. 비교가 맞는 곳은 "문서와 검사의 관계"까지입니다.
• 9항목이 많은지 적은지 판단할 근거가 없습니다. 세어 보니 겹친다는 것까지만 확인했습니다.

돌려 볼 때가 오면 결과를 이 글 아래에 덧붙이겠습니다.