스토리보드 생성기는 이미지 생성기가 아니다: Story Graph로 창작 하네스를 만드는 법

스토리보드 생성기를 만들 때 가장 쉬운 착각은 “장면을 여러 장 이미지로 뽑으면 된다”는 생각이다. 겉으로는 그럴듯하다. 프롬프트를 넣고, 이미지가 나오고, 마음에 들지 않으면 다시 생성한다. 그런데 이 방식은 조금만 길어져도 금방 무너진다.

인물의 얼굴이 바뀐다. 장면의 시간대가 흔들린다. 앞 컷에서 들고 있던 물건이 다음 컷에서 사라진다. 대사는 반복되고, 구도는 비슷해지고, 독자가 따라가야 할 감정선은 중간에서 끊긴다. 결국 창작자는 이미지를 고르는 사람이 아니라 오류를 수습하는 사람이 된다.

내가 흥미롭게 보는 방향은 다르다. 스토리보드 생성기는 이미지 생성기가 아니라 창작 하네스여야 한다. 즉, 한 번의 그림 생성보다 더 앞에 있는 구조가 중요하다. 이야기의 상태를 기록하고, 컷의 역할을 정하고, 캐릭터와 세계의 일관성을 붙잡고, 사람이 중간에 개입해 고칠 수 있게 만든 다음, 그 계획을 기반으로 이미지를 생성해야 한다.

최근 살펴본 내부 실험 Aether Storyboard도 바로 이 문제를 향하고 있었다. 핵심 문장은 단순했다. 소설과 웹툰이 하나의 Story Graph에서 함께 진화해야 한다는 것. 이 문장을 제대로 받아들이면 스토리보드 생성기의 기준이 바뀐다.

생성보다 먼저 있어야 하는 것

좋은 스토리보드 도구는 “무엇을 그릴까”보다 먼저 “무엇을 유지할까”를 물어야 한다.

층	질문	산출물
Premise	이 작품은 어떤 감정과 장르를 향하는가	로그라인, 장르, 톤
Story Graph	인물, 사건, 세계 상태는 어떻게 연결되는가	캐릭터, 장소, 갈등, 선택지
Panel Plan	각 컷은 어떤 역할을 맡는가	establish, setup, beat, payoff, transition
Render	컷 계획을 어떻게 시각화할 것인가	이미지, 구도, 조명, 스타일
Lettering	텍스트는 어디에 놓이고 어떻게 읽히는가	대사, 캡션, 효과음, 식자
Export	어느 플랫폼에 맞게 내보낼 것인가	세로 웹툰, 책형, 플랫폼별 이미지

이 표에서 중요한 지점은 이미지 생성이 네 번째에 있다는 것이다. 앞의 세 단계가 약하면 이미지는 아무리 좋아도 작품이 되기 어렵다. 반대로 앞의 구조가 단단하면 이미지 모델이 바뀌어도 작업의 중심은 흔들리지 않는다.

이 관점은 내가 계속 정리해 온 PCHL Engineering과도 이어진다. 프롬프트는 요청이고, 컨텍스트는 재료이며, 하네스는 작업을 반복 가능하게 만드는 장치다. 스토리보드에서는 이 하네스가 곧 Story Graph다.

Story Graph는 창작의 단일 원천이다

Story Graph는 단순한 줄거리 요약이 아니다. 작품 안에서 바뀌면 안 되는 것과 바뀌어도 되는 것을 나누는 작업대다.

예를 들어 주인공의 성격, 친구와의 관계, 사건의 원인, 장소의 분위기, 반복되는 상징, 조명의 흐름, 색감의 변화가 여기에 들어간다. 웹툰이라면 캐릭터 외형도 중요하다. 머리 모양, 눈매, 의상, 몸짓, 자주 쓰는 표정은 모두 다음 컷의 기준이 된다.

Story Graph가 없으면 모델은 매번 새로 상상한다. 그러면 창작자는 매번 “아니, 이 인물이 아니야”라고 말해야 한다. Story Graph가 있으면 모델은 매번 새로 시작하지 않는다. 이미 정해진 세계 안에서 다음 컷을 만든다.

이 차이는 작아 보이지만 실제 작업에서는 결정적이다. 이미지 생성기는 순간의 품질을 만든다. Story Graph는 연속성을 만든다.

컷 계획은 사람이 먼저 검토할 수 있어야 한다

스토리보드 생성에서 내가 가장 중요하게 보는 기능은 “생성 전 검토”다. 바로 그림으로 가면 고치기 어렵다. 하지만 컷 계획을 먼저 보여주면 사람은 빠르게 판단할 수 있다.

이 컷은 도입인가, 전환인가, 감정의 고조인가. 대사가 반복되는가. 주인공이 아닌 인물이 너무 오래 중심에 있는가. 장면 전환이 갑작스럽지는 않은가. 클라이맥스가 너무 빨리 왔는가.

Aether Storyboard의 흥미로운 점도 여기에 있다. 한 번에 여러 컷의 초안을 만들되, 각 컷을 establish, setup, beat, payoff, transition 같은 역할로 나누고, 장면, 대사, 초점 인물, 캡션, 전환 모티프, 스타일 변형을 편집할 수 있게 한다. 이렇게 하면 생성된 이미지를 보고 뒤늦게 수습하는 것이 아니라, 생성 전에 이야기의 뼈대를 손볼 수 있다.

창작 도구에서 이 차이는 크다. “다시 그려줘”는 비용이 큰 명령이다. “이 컷의 역할을 전환으로 바꾸고, 초점 인물을 친구로 바꿔줘”는 훨씬 정확한 명령이다.

일관성은 프롬프트 길이가 아니라 구조에서 나온다

이미지 생성에서 일관성을 지키려고 프롬프트를 계속 길게 쓰는 경우가 많다. 하지만 프롬프트가 길어진다고 항상 일관성이 좋아지는 것은 아니다. 오히려 중요한 정보가 묻히고, 반복 지시가 많아지고, 모델이 어느 조건을 우선해야 하는지 헷갈릴 때도 있다.

그래서 필요한 것은 일관성 엔진이다. 거창한 말처럼 보이지만 원리는 단순하다.

일관성 대상	기록해야 할 것	흔한 실패
캐릭터	외형, 성격, 말투, 관계	얼굴과 성격이 컷마다 달라짐
세계	장소, 시간대, 조명, 색감	같은 장면인데 배경이 바뀜
사건	원인, 결과, 선택지	왜 그런 행동을 하는지 끊김
감정	긴장, 완화, 반전, 여운	컷은 예쁜데 흐름이 없음
텍스트	대사, 캡션, 효과음	말풍선이 어색하거나 반복됨

이 표가 있으면 생성은 훨씬 좁은 문제로 바뀐다. “무엇이든 멋지게 그려줘”가 아니라 “이 상태를 유지하면서 다음 컷의 역할을 수행해줘”가 된다. 이것이 Consistency by Construction, 즉 생성 이후에 고치는 방식이 아니라 생성 조건 자체를 일관성 있게 만드는 방식이다.

한국 웹툰에서는 식자와 export가 본체에 가깝다

한국어 웹툰 제작에서는 이미지 자체만큼 식자가 중요하다. 대사가 어디에 놓이는지, 말풍선이 시선을 가리지 않는지, 효과음이 장면의 리듬을 살리는지, 캡션이 과한 설명으로 흐름을 끊지 않는지가 독서 경험을 결정한다.

그래서 스토리보드 생성기는 텍스트를 이미지 안에 대충 박아 넣는 방식으로 끝나면 안 된다. 대사와 캡션과 효과음은 편집 가능한 층이어야 한다. 생성 이미지 위에 텍스트를 다시 올리고, 위치와 크기와 강조를 조정할 수 있어야 한다.

또 하나는 export다. 작업자는 네이버, 카카오, 레진, 글로벌 플랫폼, 책형 미리보기처럼 서로 다른 규격을 생각해야 한다. 이 단계가 없으면 도구는 데모로는 재미있지만 실제 제작 흐름에는 들어가기 어렵다.

스토리보드 생성기가 창작 하네스가 되려면 마지막 산출물이 단일 이미지가 아니라 제작 가능한 패키지여야 한다.

모델 폴백과 BYOK는 창작자의 통제권 문제다

이런 도구에서 모델 선택은 단순한 성능 문제가 아니다. 창작자의 비용, 속도, 프라이버시, 안정성 문제와 연결된다.

어떤 날은 고품질 모델이 필요하다. 어떤 날은 빠르게 초안을 많이 뽑아야 한다. 어떤 순간에는 할당량이 막히거나, 특정 모델이 잠시 불안정할 수 있다. 그러면 작업이 멈추지 않도록 폴백이 있어야 한다. 무거운 모델에서 가벼운 모델로, 이미지 모델에서 텍스트 계획 단계로, 자동 생성에서 사람의 편집 루프로 내려올 수 있어야 한다.

BYOK도 같은 이유로 중요하다. Bring Your Own Key는 단지 API 키를 직접 넣는 기능이 아니다. 창작자가 자신의 비용과 사용량과 데이터 흐름을 이해하고 통제한다는 뜻이다. 취미 도구라면 몰라도, 장기적으로 운영할 창작 OS라면 이 부분을 숨기면 안 된다.

LLM Wiki로 남겨야 할 노드

이 실험을 블로그의 LLM Wiki 관점에서 보면 다음 노드로 나눌 수 있다.

노드	설명	다음에 연결할 글
Story Graph	이야기의 단일 원천	캐릭터 DNA, 세계 상태
Panel Plan	생성 전 검토 가능한 컷 계획	컷 역할, 전환 모티프
Consistency Engine	반복 생성에서 흐름을 지키는 장치	캐릭터 일관성, 장면 기억
Editable Lettering	한국어 웹툰 식자와 텍스트 편집	말풍선, 캡션, 효과음
Platform Export	제작 가능한 산출물	세로 웹툰, 책형, ZIP export
Human Edit Loop	사람이 중간에 개입하는 루프	재생성, 검수, 버전 관리

이 구조는 베이지안 동적 번역기: 번역 프롬프트를 하네스로 묶는 법에서 본 번역 하네스와도 닮았다. 번역에서는 원문, 독자, 용어, 검수 기준을 기록해야 한다. 스토리보드에서는 캐릭터, 세계, 컷 역할, 시각 모티프, 식자 기준을 기록해야 한다.

또 닥터 그레고리 하우스 프롬프트: 페르소나는 말투가 아니라 진단 절차다에서 말한 것처럼, 도구의 힘은 말투가 아니라 절차에서 나온다. 스토리보드 생성기도 “감성적인 웹툰 작가처럼 그려줘”가 아니라 “이야기를 진단하고, 컷의 역할을 나누고, 일관성을 검수하고, 수정 루프를 돌려라”로 가야 한다.

내가 만들고 싶은 방향

스토리보드 생성은 앞으로 세 방향으로 발전해야 한다고 본다.

첫째, 프롬프트 입력창보다 편집 가능한 계획표가 앞에 있어야 한다. 창작자는 모델에게 모든 것을 맡기는 사람이 아니라 이야기의 방향을 조정하는 감독이어야 한다.

둘째, 이미지보다 관계가 먼저 저장되어야 한다. 캐릭터와 사건과 세계가 연결된 상태로 남아야 다음 컷이 앞 컷을 배신하지 않는다.

셋째, 결과물은 감상용 이미지가 아니라 제작 가능한 파일이어야 한다. 식자, export, 버전 기록, 재생성 이력이 붙어야 실제 작업에 들어간다.

결국 스토리보드 생성기의 목표는 “그럴듯한 그림 몇 장”이 아니다. 창작자가 자기 이야기를 잃지 않으면서 더 빠르게 실험하고, 더 쉽게 고치고, 더 안정적으로 완성하도록 돕는 것이다.

이 관점에서 스토리보드 생성기는 작은 이미지 앱이 아니라 창작 하네스다. 그리고 좋은 창작 하네스는 AI가 대신 상상하는 도구가 아니라, 사람이 상상한 것을 오래 버티게 만드는 구조다.