TL;DR
한 줄 브리프를 받아 샷별 속성(character, action, camera, duration, mood)을 출력하고 각 샷을 비디오/이미지 모델에 넘기는 에이전트를 구현하면서 플래너가 자유문을 반환해 포맷 오류와 오탐이 발생하는 문제를 경험했다. 문제 해결을 위해 JSON Schema로 구조를 엄격히 규정하고 additionalProperties를 false로 설정하며 샷 수를 6으로 제한하고 각 필드 길이를 약 15단어로 검증한 뒤 툴 호출 전 검증을 통과하지 못하면 최대 3회까지 재시도하는 제어 흐름을 도입했다. 미디어 추론 계층은 Atlas Cloud MCP 서버를 통해 여러 모델을 callable tools로 추상화했고 이로 인해 모델별 API 래퍼가 필요 없어졌으나 플래너의 샷 타이밍 판단 오류(예: 3초짜리 샷에 8초 할당)는 여전히 규칙 기반 보정이나 플래너 개선이 병행되어야 하는 한계를 드러냈다.
실용적 조언
- 플래너 출력이 툴 호출의 직접 입력이 되는 파이프라인에서는 입력·출력 계약을 코드로 명시해야 안정성이 확보된다. 구체적으로 JSON Schema로 required 필드와 타입을 강제하고 additionalProperties를 false로 설정하면 플래너가 임의 필드를 생성해 downstream을 깨뜨리는 사례를 방지할 수 있다. 또한 각 필드의 길이를 제한하고 샷 수 상한을 두면 지나치게 상세한 자연어 출력을 억제하여 미디어 모델 프롬프트로서의 적합성을 높일 수 있다.
- 재시도 루프는 형식적 오류를 자동으로 교정하는 데 유효한 패턴이며 검증 실패 시 오류 메시지와 함께 최대 시도 횟수를 제한하는 것이 중요하다. 이 글에서는 최대 3회 재시도를 적용해 대부분의 포맷 문제를 해결했고, 재시도 시에는 검증 오류를 모델에 명시적으로 포함하여 정정 방향을 제시해야 재현성이 높아진다. 재시도 메커니즘과 함께 로그와 오류 사유를 저장하면 어떤 유형의 출력 오류가 반복되는지 파악해 플래너 prompt나 규칙을 개선하는 근거로 활용할 수 있다.
- 미디어 모델을 다수 운영하는 경우에는 각 모델의 API 차이를 추상화하는 중간 서버 또는 MCP(Marketplace/Manager/Connector) 계층을 도입하는 것이 유지보수 비용을 줄인다. Atlas Cloud MCP 같은 계층은 여러 모델을 callable tool로 노출하여 에이전트가 단일 인터페이스로 툴을 호출하게 하며, 이로 인해 에이전트 개발자는 모델별 래퍼를 구현할 필요 없이 샷 플래닝과 검증 로직에 집중할 수 있다. 다만 이 접근은 MCP가 제공하는 파라미터 세트에 맞춰 플래너 출력을 규격화해야 하므로 스키마 설계와 MCP 인터페이스 동기화가 필수이다.
섹션별 상세
용어 해설
- JSON Schema
- — JSON 스키마는 JSON 문서의 구조와 필드 타입을 기계가 검증할 수 있게 정의하는 형식이다. 입력 객체에 required, additionalProperties, 문자열 길이 제한 등 규칙을 적용하여 플래너가 반환하는 출력이 툴 호출에 적합한 구조인지 자동으로 검사한다. 올바른 스키마 검증은 downstream 미디어 생성 도구가 예측 불가능한 자유문을 받지 않도록 막아 형식 오류와 호출 실패를 줄이는 데 중요하다.
- Planning Model
- — 플래닝 모델은 자유문 브리프를 입력으로 받아 샷 리스트나 스크립트 같은 구조화된 계획을 생성하는 언어 모델 계열이다. 입력을 파싱하고 샷 단위의 속성(character, action, camera, duration, mood)을 출력하며, 이 출력은 이후 미디어 생성 툴에 전달되어 장면별 자산을 만든다. 플래너의 출력 품질이 전체 워크플로의 정확도와 재현성에 직접 영향을 미친다.
- Media Generation
- — 미디어 생성은 이미지·비디오 모델을 사용해 텍스트 프롬프트로 시각 자산을 생성하는 작업이다. 각 샷의 character, action, camera, duration, mood 같은 구조화된 속성을 받아 해당 장면의 프레임이나 클립을 생성하고, 생성 모델의 입력 파라미터와 추론 API를 통해 결과물이 출력된다. 에이전트는 이 과정을 자동화하여 샷별로 적절한 모델 호출과 파라미터 전달을 담당한다.
- Retry Loop
- — 재시도 루프는 플래너 출력이 스키마 검증을 통과하지 못했을 때 피드백을 생성하고 재요청을 수행하는 제어 구조이다. 검증 실패 시 오류 메시지와 함께 최대 시도 횟수(예: 3회)만큼 모델에 재요청을 보내 형식적 오류를 교정하도록 유도한다. 이 방식은 불완전한 자연어 출력을 자동으로 정형화할 기회를 제공하여 툴 호출 실패를 줄인다.
코드 예제
{
"brief": "30s promo for a coffee brand, morning vibe",
"shots": [
{
"character": "young founder holding coffee",
"action": "opens the cafe door at sunrise",
"camera": "slow push-in from outside window",
"duration": 4,
"mood": "warm, quiet, early morning"
},
{
"character": "barista pouring latte",
"action": "steam rises as the cup is placed down",
"camera": "close-up, slight handheld movement",
"duration": 3,
"mood": "cozy, premium, tactile"
}
]
}플래너가 반환해야 하는 샷 목록 예시 JSON로, brief와 shots 배열에 각 샷의 character, action, camera, duration, mood 필드를 포함하는 구조를 보여준다.
언급된 도구
이미지·비디오 모델을 callable tools로 노출하여 에이전트와 모델 간 인터페이스를 추상화하는 서버 역할
재사용 가능한 에이전트 스킬 패키지 예시로서 워크플로 구성과 스킬 포맷을 참고할 수 있는 리포지토리
에이전트 스킬과 워크플로 재사용 사례를 모아놓은 컬렉션으로 구현 패턴 참고용
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.

