MCP 서버를 통해 AI 에이전트에게 Floniks를 넘기고, 템플릿 라이브러리의 빈 구멍을 메우라고 요청했습니다. 이후 한 시간 동안 에이전트는 노드 카탈로그를 조회하고, 세 개의 다단계 파이프라인을 설계하고, 실행하고, 실제 버그를 두 개 만나고, 둘 다 원인을 규명하고, 이를 우회하도록 설계를 다시 짜고, 결과물을 공개 템플릿으로 게시했습니다. 아무도 에디터를 열지 않았습니다. 아래는 그 기록입니다.
이 글을 쓰는 이유는, 흥미로운 지점이 "에이전트가 이미지를 생성했다"가 아니기 때문입니다. 그 정도는 이제 많은 도구가 합니다. 흥미로운 지점은 디버깅 과정입니다.
요청 내용, 그리고 그것이 진짜였던 이유
템플릿 라이브러리에는 구멍이 있었습니다. 스토리보드, TVC 프리비즈, 숏드라마 기획 같은 상업 프리프로덕션 작업을 노린 랜딩 페이지는 있는데, 약 400개의 워크플로 템플릿 중 그것들에 실제로 대응하는 것은 0개였습니다. 검색으로 들어온 사람은 클릭할 곳이 없었습니다.
그래서 과제는 구체적이었습니다. 구멍을 찾고, 그것을 메울 파이프라인을 설계하고, 작동을 증명하고, 배포한다.
1단계: 먼저 상황을 파악한다
에이전트의 첫 수는 무언가를 생성하는 것이 아니었습니다. list_node_types를 호출해 카탈로그를 읽었습니다——입력, 처리, AI 모델, 출력 네 갈래에 걸친 33종의 노드. 이어서 list_model_aliases를 호출해 어떤 모델이 활성화되어 있고 각각 실행당 얼마인지 확인했습니다.
그다음 예상 밖의 일을 했습니다. get_workflow로 이미 작동하는 기존 템플릿을 가져와, 그 노드와 엣지 JSON을 연구한 뒤에야 자기 것을 쓰기 시작한 것입니다. 추측하는 대신, 이미 성립한 형태를 베낀 셈입니다.
2단계: 처음 고장 난 것
첫 파이프라인은 storyboardSplit 노드——대본을 숏 리스트로 바꾸는 LLM 단계——를 사용했습니다. 에이전트는 배선하고 실행했고, 작업은 1단계 6퍼센트에서 멈춘 채 다시는 움직이지 않았습니다.
오류 없음. 실패 상태 없음. 그저 영원히 끝나지 않는 작업이었습니다.
에이전트는 자신이 방금 저장한 그래프에 get_workflow를 호출해, 보낸 것과 저장된 것을 대조했습니다. 차이는 한 줄이었습니다. storyboardSplit 노드가 "model": []을 달고 돌아온 것——모델이 필수인 노드에 빈 모델 배열. 이것은 우리 쪽 버그이고, 게다가 고약한 종류입니다. 스스로를 드러내지 않기 때문입니다. 타입 검사는 통과합니다. 저장도 성공합니다. 실행만 끝나지 않습니다.
에이전트는 수정을 기다리지 않고 설계를 다시 했습니다. LLM 분할기를 빼고, 대신 명시적이고 편집 가능한 네 개의 숏 프롬프트를 썼습니다——결과적으로 이쪽이 더 나은 템플릿이 되었습니다. 사용자는 불투명한 분할에 맡기는 대신, 각 숏을 직접 보고 고칠 수 있습니다.
3단계: 두 번째로 고장 난 것, 그리고 제품을 좋게 만든 수정
다시 설계한 파이프라인은 작동했습니다. 다만 이미지를 네 장이 아니라 정확히 한 장만 반환했습니다.
가장 쉬운 해석은 "노드가 불안정했다"입니다. 에이전트는 그 해석을 받아들이는 대신 검증했습니다. 같은 그래프를 한 번 더 실행한 것입니다. 두 번째도 한 장——그런데 다른 한 장이었습니다. 첫 실행은 프레임 2, 두 번째는 프레임 1.
이로써 노드 고장은 배제되고, 의심은 실행 엔진으로 향합니다. 에이전트의 그래프는 서로 독립된 네 개의 사슬이었습니다——프롬프트 넷, 생성 노드 넷, 출력 넷, 어느 것도 서로 닿지 않는. 즉 네 개의 비연결 부분 그래프입니다. 앞서 연구한 작동하는 참조 템플릿은 모든 분기가 하나의 공유 루트에서 뻗어 있었습니다. 결론: 다중 출력 실행은 그래프 전체가 단일 연결 요소여야 한다.
수정 방식이 여기서부터 본론입니다. 에이전트는 가짜 공유 루트를 덧붙이는 대신, 프레임을 사슬로 이었습니다——각 프레임이 직전 프레임을 시각 참조로 삼아 생성되도록:
프롬프트 1 → 프레임 1 ─┬→ 출력 1
└→ 프레임 2 ─┬→ 출력 2
└→ 프레임 3 → …
단일 연결 요소가 되었으므로 실행 엔진은 모든 출력을 반환합니다. 그리고 각 프레임이 직전을 참조하므로, 같은 인물이 네 개의 숏을 관통합니다——바로 이 템플릿이 풀려던 문제 그 자체입니다. 런타임의 제약이 기능으로 바뀐 것입니다.
4단계: 결과물을 봐야만 드러나는 디테일
처음 성공한 실행은 2048×2048——정사각형——으로 돌아왔습니다. 프롬프트에 평범한 문장으로 16:9 화각을 요구했는데도 말입니다.
화면비는 모델 파라미터이지, 산문 속에서 건네는 제안이 아닙니다. 에이전트는 get_model_params를 호출해 aspect_ratio의 기본값이 1:1이고 허용값에 16:9가 있음을 확인한 뒤, 노드 설정에 써넣고 다시 실행했습니다. 두 번째: 2560×1440.
작지만 무게가 있는 일입니다. 자기 프롬프트만 읽는 에이전트였다면 정사각형 스토리보드를 배포하고도 영영 몰랐을 것입니다. 이 에이전트는 결과물을 확인했습니다.
무엇이 배포되었나
세 개의 템플릿, 각각 실제로 생성된 네 컷을 미리보기로 갖고 있습니다:
- Script → 4-Shot Cinematic Storyboard——16:9. TVC 프리비즈와 광고 기획용.
- Short Drama: Script → 4 Vertical Key Scenes——9:16. 서사의 전환에 맞춰 컬러 그레이드가 차가운 파랑에서 따뜻한 금빛으로 의도적으로 이동합니다.
- Character Sheet: One Description → 4 Consistent Views——정면, 4분의 3, 전신, 그리고 로케이션 컷 하나.
셋 다 템플릿 라이브러리에 공개되어 있고, 셋 다 에디터를 한 번도 열지 않은 채 MCP 서버를 통해 작성·실행·검증·게시되었습니다.
진짜 효과가 나는 지점: 프롬프트가 아니라 애셋
위의 세 템플릿은 파이프라인입니다. 그 아래 깔린 더 큰 발상은, 피사체를 매번 다시 묘사해야 할 대상으로 다루기를 그만두면 무슨 일이 일어나는가입니다.
Floniks는 두 종류의 영속 애셋을 보관합니다. create_character는 참조 시트——정면·측면·후면 뷰——를 만들어 그 캐릭터의 정본 외형으로 저장합니다. create_location은 두 가지를 생성합니다. 영화적인 설정 숏과, 같은 장소를 서로 다른 카메라 앵글에서 잡은 6분할 그리드입니다. 로케이션은 여기에 더해 persistent_props——거기서 찍을 때마다 반드시 등장해야 하는 물건——과 time_of_day를 갖습니다.
바로 이 마지막 디테일이 핵심입니다. 소품 목록이 프롬프트가 아니라 장소에 묶여 있기에, 같은 금 간 거울이 1화에서도 40화에서도 같은 구석에 놓여 있을 수 있습니다.
피사체가 애셋이 되는 순간 경제성이 뒤집힙니다. 인물을 프롬프트로 묘사하는 것은 매번 주사위를 다시 던지는 일입니다. 애셋을 참조하는 비용은 거의 없고, 소재가 쌓일수록 더 안정적으로 변합니다.
거기서 열리는 것들의 일부:
- 전속 모델. 한 사람을 주조한 뒤 일상 코디, 헤어 변경, 시즌 룩북, 여행 배경으로 돌립니다. 월요일과 금요일의 얼굴이 흔들리지 않으므로, 피드 전체가 소재 모음이 아니라 한 사람으로 읽힙니다.
- 상설 세트. 카페, 쇼룸, 아파트——
persistent_props로 연속성을 고정하고,time_of_day로 같은 공간의 새벽·낮·황혼·밤 버전을 뽑습니다. - 연속 드라마. 캐릭터와 로케이션을 함께 씁니다. 12화는 1화의 배역과 세트를 그대로 재사용하며, 어느 쪽도 다시 묘사할 필요가 없습니다.
- 브랜드 마스코트 / 버추얼 호스트. 하나의 캐릭터 애셋에서 캠페인·시즌·공지 변주를 무한히——전부 틀림없이 같은 형상으로.
- 디지털 대변인. 캐릭터를 아바타·음성 기능에 연결하면, 같은 진행자가 모든 설명 영상에 원하는 음색으로 등장합니다. 카메라는 필요 없습니다.
- 한 번 촬영의 다국어 버전. 같은 캐릭터, 같은 세트에서 시장별로 음성과 자막만 교체합니다.
- 음악과 뮤직비디오. 릴리스를 가로질러 일관된 아티스트 상을 유지하고, 같은 그래프 안에서
textToMusic·audioBeatDetect·tempoMatchedCut이 영상을 트랙에 맞춰 자릅니다. - 프로덕션 바이블. 만화·게임·애니메이션에서는 캐릭터 시트 자체가 납품물입니다. 정면·측면·후면 그리드는 미술팀이 실제로 손에 두고 쓰는 바로 그것입니다.
정직하게 밝힐 결함이 하나 있습니다. 현재 상품/SKU 애셋 타입은 없습니다. 캐릭터와 로케이션은 1급 시민이지만 상품은 아닙니다. 이커머스 작업에서는 상품 이미지를 워크플로 안의 참조 이미지로 넘깁니다——그것으로 작동하고, 저희 상품 촬영 템플릿이 그렇게 돌아갑니다——그러나 저장되고 주소 지정 가능한 SKU와는 다릅니다. 다음에 와야 할 애셋 타입으로 명백하며, 저희도 인지하고 있습니다.
셋을 합치면——저장된 애셋, 저장된 파이프라인, 그 둘을 모두 호출할 수 있는 에이전트——일상적 산출에 사람이 개입할 필요가 사라집니다. 에이전트가 캐릭터를 나열하고, 하나 고르고, 파이프라인을 돌리고, 게시합니다. 이 루프야말로 이 모든 것을 만들 가치가 있는 이유입니다.
"이미지를 만드는 에이전트"와 무엇이 다른가
대부분의 크리에이티브 MCP 서버가 노출하는 것은 생성 엔드포인트입니다. 모델을 지정해 이미지를 요청하면 URL이 돌아옵니다. 에이전트는 리모컨입니다.
이번에 에이전트가 한 일은 종류가 다릅니다. 사용 가능한 부품을 읽고, 다단계 그래프를 조립하고, 실행하고, 실행 상태가 아니라 결과물을 검사하고, 결함을 둘 찾아내고, 각각에 가설을 세우고, 그중 하나는 통제된 두 번째 실행으로 검증하고, 그에 맞춰 아키텍처를 다시 설계했습니다. 그리고 결과를 다른 사람이 재사용할 수 있는 자산으로 게시했습니다.
그것은 리모컨이 아닙니다. "모델을 호출한다"와 "파이프라인을 소유한다"의 차이이고, 이는 렌더 결과만이 아니라 워크플로 그래프 자체가 API로 주소 지정 가능하기 때문에 비로소 가능합니다.
덧붙이자면 이 버그 두 개는 감사히 받겠습니다. 이런 식으로 발견되는 편이 발견되지 않는 것보다 낫습니다.
자주 묻는 질문
MCP 서버를 쓰려면 코드를 작성해야 하나요? 아닙니다. Claude Desktop 같은 호환 클라이언트에서 Floniks를 MCP 서버로 연결한 뒤, 평범한 말로 요청하면 됩니다. 도구 호출은 대신 처리됩니다.
에이전트 실행도 제 크레딧을 쓰나요?
씁니다. 에이전트가 시작한 실행도 직접 시작한 실행과 같은 잔액을 사용하며, 모델별 실행당 비용은 실행 전에 list_model_aliases로 확인할 수 있습니다. 에이전트가 먼저 get_credit_balance를 호출할 수도 있습니다. 크레딧은 만료되지 않습니다——계정에 들어오면 다 쓸 때까지 남아 있습니다.
워크플로가 중간에 실패하면 어떻게 되나요?
실패한 실행의 크레딧은 자동으로 환불되고, get_task가 실패 상태와 함께 오류를 반환하므로 에이전트가 재시도할지, 파라미터를 바꿀지, 다시 설계할지 판단할 수 있습니다. 위 실행에서는 멈춘 작업이 쓸 만한 출력을 내지 못했고, 에이전트는 맹목적으로 재시도하는 대신 방향을 바꿨습니다.
에이전트가 남들이 쓸 템플릿을 게시할 수 있나요?
가능합니다. create_template이 워크플로를 미리보기 이미지가 달린 공개 템플릿으로 게시합니다. 이 글의 세 템플릿이 그렇게 나왔습니다.
왜 병렬 생성 대신 사슬로 잇나요? 사슬로 이으면 각 프레임이 직전 프레임을 시각 참조로 쓸 수 있고, 그것이 숏 사이에서 같은 인물을 유지하는 방식입니다. 병렬이 더 빠르지만 인물이 흔들립니다——얼굴이 바뀌고 옷이 바뀝니다——그리고 그것이야말로 이 템플릿들이 막으려고 존재하는 실패입니다.
해보기
세 파이프라인은 템플릿 라이브러리에 있습니다——하나를 열고, 숏 프롬프트를 자신의 이야기로 바꾼 뒤 실행해 보세요. 에이전트로 구동하고 싶다면 MCP 서버가 같은 그래프를 호출 가능한 도구로 노출하고 있고, 워크플로 에디터에서는 에이전트가 실제로 무엇을 조립했는지 볼 수 있습니다.