구글 Flow 무료 이미지로 공학 쇼츠를 만들 때 룩이 어긋나는 이유

같은 도구를 켜고, 같은 룩 문장을 적고, 이미지 열두 장을 뽑는 두 사람이 있다고 해볼게요.

A는 열두 장을 하나씩 따로 만듭니다. 프롬프트는 열두 번 다 똑같이 넣고요.

B는 한 장을 먼저 만들어 둡니다. 그리고 남은 열한 장은 하나씩 뽑을 때마다 먼저 만든 그 장을 참조로 걸어둡니다.

도구도 같고 문장도 같은데 결과는 갈립니다. A의 열두 장은 영상으로 이어 붙이는 순간 컷이 바뀔 때마다 조명이 튀고 색이 달라집니다. B의 열두 장은 한 번에 찍은 것처럼 붙고요.

저는 한동안 A였습니다. 그리고 원인을 계속 프롬프트에서 찾았어요.

결론부터 말씀드리면, 룩은 문장으로 고정되지 않습니다. 이미지로 고정됩니다.

이 글은 생성 이미지를 여러 장 이어 붙여 한 편의 영상으로 쓰려는 분을 위해 썼습니다.

그래픽카드는 따로 장만하지 않았어요.

숫자로 먼저 말씀드리면 이렇습니다. 이미지 12장은 0크레딧이었고, 클립 7개에서만 49크레딧이 나갔어요.

마지막에는 그 49크레딧 중 7크레딧을 엉뚱한 원본에 날린 이야기도 넣었습니다. 원리를 알고도 손이 틀린 경우라서요.

AI 이미지는 생성할 때마다 룩이 새로 뽑힌다

여기서 다루는 사례는 공학 쇼츠다. 구조와 원리를 해부하는 세로 영상이라 같은 대상이 열두 장에 걸쳐 반복해서 나오고, 그래서 장마다 룩이 어긋나면 바로 티가 난다.

이미지 한 장은 만들 때마다 처음부터 다시 계산됩니다.

같은 프롬프트를 열두 번 넣어도 그 열두 번은 서로를 모릅니다. 앞 장이 어떤 조명이었는지, 어떤 색으로 나왔는지 참고하지 않거든요.

흔한 오해가 여기서 생깁니다. 같은 문장을 넣었으니 같은 그림이 나오겠지, 하는 생각이요. 문장이 같으면 방향은 같습니다. 그런데 방향이 같다는 건 결과가 같다는 뜻이 아니에요.

매번 독립된 표본을 하나씩 뽑는 겁니다. 열두 번 뽑으면 서로 다른 결과가 열두 개 나오고요.

그러니 룩을 맞추고 싶으면 문장을 고칠 게 아니라 표본을 묶을 방법을 찾아야 합니다.

룩 문장을 더 길게 쓰기

제가 처음 잡은 처방은 문장을 늘리는 것이었습니다.

조명은 어느 쪽에서 오고, 색감은 어느 톤이고, 표면은 어떤 느낌이어야 하는지를 프롬프트에 길게 적었어요. 열두 장 전부에 같은 문장을 공통으로 붙였고요.

논리는 그럴듯했습니다. 지시가 자세할수록 결과의 흔들림이 줄어들 거라고 봤거든요.

그렇게 열두 장을 뽑았습니다.

그런데 열두 장은 여전히 따로 놀았다

처음엔 지시가 자세할수록 결과가 모인다고 생각했는데, 열두 장을 나란히 늘어놓고 보니 아니었습니다. 여전히 한 장은 밝고 한 장은 어두웠어요.

원인은 하나였습니다. 룩 문장은 매 생성에 같은 지시를 줄 뿐, 같은 결과를 주지는 못합니다.

어긋난 것도 세 가지로 갈렸습니다. 빛이 들어오는 방향이 달랐고, 전체 색조가 달랐고, 표면 질감이 달랐어요.

그래서 방향을 바꿨습니다. 지시를 더 정교하게 쓰는 쪽이 아니라, 아예 기준이 될 그림 한 장을 만들어 나머지에 물리는 쪽으로요.

앵커 한 장을 먼저 만들기

앵커는 나머지 전부가 참조할 기준 이미지 한 장입니다.

만드는 방법은 특별할 게 없습니다. 그냥 첫 장을 만드는 거예요. 다만 이 한 장은 마음에 들 때까지 봅니다.

여기서 판단이 하나 필요합니다. 앵커가 애매하면 나머지 열한 장은 아직 만들지 마세요. 애매한 기준을 열한 번 복제하면 애매함이 열두 배가 되니까요.

이미지 생성은 0크레딧입니다. 그래서 이 한 장은 몇 번이고 다시 뽑아도 손해가 없어요.

앵커가 확정될 때까지 다음으로 넘어가지 않는 것, 이게 이 방식의 전부입니다.

나머지 열한 장을 그 한 장에 물리기

앵커가 정해지면 그다음은 반복 작업입니다.

새 이미지를 만들 때마다 앵커를 참조 이미지로 붙입니다. 프롬프트에는 그 장에서 달라져야 할 내용만 적고요.

여기서도 오해가 하나 있습니다. 참조를 붙이면 앞 장과 똑같은 그림이 나올까 봐 걱정하는 경우인데요. 참조는 복사가 아닙니다. 내용은 프롬프트가 정하고, 참조는 그 내용을 어떤 빛과 색으로 그릴지를 정합니다.

역할이 나뉘어 있는 겁니다. 참조 이미지는 무엇을 그릴지가 아니라 어떻게 보이게 할지를 담당합니다.

그래서 열한 장 각각의 프롬프트는 오히려 짧아집니다. 룩을 설명할 필요가 없어졌으니까요.

실제로 뽑은 열두 장이다. 앵커를 물리기 전에는 이 격자 안에서 밝기와 색이 제각각이었다.

앵커가 고정하는 것은 조명 방향·색조·질감이다

앞에서 어긋났던 세 가지가 그대로 고정 대상이 됩니다.

첫 번째는 빛이 들어오는 방향입니다. 한 장은 왼쪽에서, 다음 장은 정면에서 빛이 들어오면 이어 붙였을 때 바로 티가 나거든요.

두 번째는 전체 색조입니다. 같은 물건이라도 한 장이 노랗고 한 장이 푸르면 다른 곳에서 찍은 그림이 됩니다.

세 번째는 표면 질감입니다. 매끈하게 나왔다가 거칠게 나왔다가 하면 같은 물건으로 안 보여요.

앵커는 이 셋의 기준값을 화면으로 제시합니다. 문장은 "따뜻한 조명"까지만 말할 수 있지만, 이미지는 그 따뜻함이 정확히 어느 정도인지를 보여주거든요.

그러니 룩 문장을 다듬는 데 쓸 시간을 앵커 한 장 고르는 데 쓰는 편이 낫습니다.

독립 생성과 앵커 참조는 같은 조건에서 이렇게 갈린다

말로만 하면 감이 안 오죠. 두 방식을 같은 조건으로 놓고 비교해봤습니다.

같은 조건	열두 장을 각각 독립으로 생성	앵커 한 장을 참조로 물림
공통 룩 문장	열두 장 모두 동일	열두 장 모두 동일
조명 방향	장마다 다름	앵커와 같음
전체 색조	장마다 다름	앵커와 같음
표면 질감	장마다 다름	앵커와 같음
영상으로 이어 붙였을 때	컷이 바뀔 때마다 보임	열두 장 그대로 사용
이미지 생성 비용	0크레딧	0크레딧

표에서 볼 건 맨 윗줄과 맨 아랫줄입니다. 룩 문장도 같고 비용도 같은데 가운데 세 줄이 갈립니다. 바뀐 건 참조 이미지를 붙였느냐 하나뿐이고요.

같은 값을 내고 다른 결과를 받는 방식이라면, 안 쓸 이유가 없습니다.

영상으로 이어 붙이면 어긋남이 전부 보인다

이미지를 한 장씩 볼 때는 어긋남이 잘 안 보입니다.

각각은 다 괜찮은 그림이거든요. 밝기가 조금 다른 정도는 따로 보면 그냥 다른 사진처럼 느껴집니다.

문제는 영상입니다. 컷이 바뀌는 순간 두 장이 같은 화면에서 앞뒤로 붙어요. 사람 눈은 이때 차이를 바로 잡아냅니다.

그래서 정지 이미지로 쓸 때는 그냥 넘어가던 것이 영상에서는 못 넘어갑니다. 이미지 일관성은 영상으로 만들 때 비로소 비용이 되는 문제입니다.

이어 붙일 계획이라면 첫 장을 만들기 전에 앵커부터 정해두세요.

프롬프트의 부정문은 배제가 아니라 호출이다

두 번째 원리로 넘어갑니다.

프롬프트는 그리라는 목록이지 지우라는 목록이 아닙니다. 없어야 할 것을 적으면 빠지는 게 아니라 오히려 그려져요.

저는 "글자 없이"라고 적었는데 화면에 글자가 나왔습니다. 처음엔 도구가 이상한 줄 알았어요.

원리를 알고 보면 당연합니다. 모델 쪽에서는 그 단어를 받은 거예요. 이름을 부른 것 자체가 호출입니다.

그러니 없애고 싶은 게 있으면 그 이름을 프롬프트에서 지우는 것부터 하면 됩니다.

없어야 할 것은 아예 적지 않는다

처방은 단순합니다. 지우고 싶은 이름을 빼고, 있어야 할 것만 남기면 됩니다.

아래는 같은 의도를 두 가지 방식으로 쓴 겁니다.

[X] 없어야 할 것을 적는 방식
    렌즈 클로즈업, 글자 없이, 로고 없이

[O] 있어야 할 것만 적는 방식
    렌즈 클로즈업, 매트한 검은 배경, 왼쪽 위 측면광

위쪽은 "글자"와 "로고"라는 단어를 프롬프트에 넣은 겁니다. 아래쪽은 그 단어를 아예 빼고, 대신 화면을 무엇으로 채울지를 적었어요. 빈 곳을 다른 것으로 채워두면 넣지 말라고 말할 필요가 없어집니다.

프롬프트를 고칠 때 "없이"가 들어간 표현부터 찾아서 지우면 됩니다.

한글 글자는 생성 모델에 맡기지 않는다

세 번째 원리입니다. 화면에 한글이 들어가야 한다면 그건 생성 모델의 일이 아닙니다.

한글은 틀립니다. 획이 하나 빠지거나 없는 글자가 나와요.

여기서 많이 하는 시도가 프롬프트를 더 정확하게 쓰는 겁니다. 저도 그랬고요. 그런데 이건 문장을 잘 쓰고 못 쓰고의 문제가 아니라 모델이 글자를 그림으로 그리기 때문에 생기는 일이라, 프롬프트로는 안 풀립니다.

더 큰 문제는 수정 비용이에요. 글자 하나가 틀렸다는 이유로 그림 전체를 처음부터 새로 만들게 되거든요.

그러니 이미지에는 글자를 넣지 않는다고 아예 정해두는 편이 낫습니다.

글자는 생성이 아니라 합성으로 얹는다

그럼 글자는 어디서 넣느냐. 저는 Remotion(코드로 영상을 그리는 도구)으로 따로 합성했습니다.

생성 모델이 만든 건 배경 그림까지입니다. 그 위에 올라가는 한글 라벨과 숫자, 그리고 자막은 전부 코드로 그렸어요.

코드로 그리면 글자가 틀릴 일이 없습니다. 제가 적은 문자열이 그대로 화면에 나오니까요.

고칠 때도 다릅니다. 오탈자가 보이면 문자열만 손봐서 렌더를 한 번 더 돌리면 끝이에요. 이미지는 건드리지 않습니다.

그림과 글자는 같은 도구로 만들 게 아니라 나눠서 만들 대상입니다. 역할을 나누면 각각을 따로 고칠 수 있게 되거든요.

이미지에 글자를 넣으려던 계획이 있다면 그 글자를 빼서 나중에 얹을 목록으로 옮기세요.

이미지가 0크레딧이라 앵커는 몇 번이고 다시 뽑는다

여기서 비용 구조를 짚고 갑니다. 이게 위 원리들을 실제로 쓸 수 있게 만드는 조건이거든요.

이미지 생성은 0크레딧입니다. 4초짜리 영상 클립은 7크레딧이고요.

그래서 순서가 정해집니다. 이미지를 전부 먼저 만들어서 눈으로 확인하고, 마음에 들 때만 클립으로 넘어갑니다.

크레딧을 아끼겠다고 클립부터 만들면 안 됩니다. 마음에 안 드는 원본으로 클립을 뽑으면 그 7크레딧은 돌아오지 않으니까요.

제가 만든 한 편은 이미지 열두 장에 클립 일곱 개였습니다. 열두 장이 0크레딧, 클립 일곱 개가 49크레딧. 합쳐서 49크레딧입니다.

공짜인 단계에 최대한 오래 머무는 게 이 구조에서 이득입니다.

이 크레딧은 구독과 무관하게 들어온다

여기서 제가 틀렸던 걸 짚고 갑니다.

날마다 들어오는 50크레딧을 저는 구독자에게만 붙는 몫이라고 읽었습니다. 화면 배너에 Your Google AI plan now comes with 50 additional Flow credits daily 라고 떠 있었고, 제 계정에 PLUS 배지가 있었으니까요.

틀렸습니다. 저 문장의 additional 은 구독자에게 주는 월 배정분 위에 매일치가 하나 더 붙는다는 의미였습니다. 매일치는 결제와 무관한 별개의 몫이고, 결제하지 않은 계정에도 똑같이 들어옵니다.

이 무료 몫에는 제약이 붙습니다. 그날 남긴 몫은 이월되지 않고 소멸합니다. 그리고 구글이 밝힌 피크 구간, 협정세계시로 새벽 2시부터 5시 사이에는 결제하지 않은 계정이 영상 생성을 못 할 수 있습니다. 한국 시간으로는 낮 11시에서 2시입니다.

이미지를 뽑는 데 크레딧이 0이라는 조건도 구독 여부와 무관합니다. 앞에서 설명한 앵커 방식은 구독 없이 그대로 쓸 수 있어요.

돈이 빠지는 단계는 클립을 뽑을 때 하나뿐이니, 이미지까지만 필요한 분은 여기서 멈추면 됩니다.

클립의 원본은 몇 번째가 아니라 어떤 이름인가로 지정한다

마지막 원리입니다. 이미지를 클립으로 바꿀 때 어떤 이미지를 원본으로 쓸지 지정해야 하는데요.

여기서 목록의 몇 번째 것, 이런 식으로 고르면 안 됩니다.

이유가 있습니다. 항목을 선택하면 그게 맨 앞으로 올라오면서 나머지 순서가 한 번씩 밀리거든요. 조금 전에 세 번째였던 것이 지금은 세 번째가 아닙니다.

그래서 순서는 좌표가 아니에요. 목록이 안 바뀐다는 전제가 깔려 있어야 순서가 좌표가 되는데, 여기선 그 전제가 깨집니다.

몇 번째냐로 고를 게 아니라 어떤 이름이냐로 지목해야 합니다. 이름은 목록이 흔들려도 그 이미지를 계속 따라다니니까요.

클립을 만들기 전에 지금 고른 원본의 제목을 눈으로 한 번 확인하세요.

순서로 골랐다가 7크레딧을 엉뚱한 원본에 썼다

이건 제가 실제로 겪은 일입니다.

순서로 원본을 골랐고, 클립을 만들었고, 나온 영상이 제가 생각한 그림이 아니었어요. 다른 이미지가 원본으로 들어가 있었습니다.

7크레딧이 나갔고 돌아오지 않았습니다. 하루치가 50크레딧이니까 그날 만들 수 있는 클립 하나가 그냥 없어진 거예요.

원리를 몰라서 틀린 게 아니라는 게 이 실수의 성격입니다. 목록이 밀린다는 걸 알면서도 순서로 골랐거든요.

그래서 저는 이걸 판단이 아니라 절차로 옮겼습니다. 클립 단계에 들어가기 전에 원본을 제목으로 확인하는 순서를 하나 끼워 넣는 것으로요.

그래픽카드 없이 열두 장과 클립 일곱 개가 나왔다

도입에서 A와 B 이야기를 했죠. 그 B의 방식으로 만든 결과를 그대로 적습니다.

앵커 한 장을 먼저 만들고, 나머지 열한 장을 전부 그 한 장의 참조로 물렸습니다. 그렇게 나온 열두 장을 영상에 그대로 썼어요. 룩을 맞추려고 손댄 장은 없습니다.

여기에 클립 일곱 개를 얹어 49크레딧. 화면의 한글과 수치와 자막은 전부 코드로 합성했고요.

그래픽카드는 한 장도 안 샀습니다. 이미지 단계는 0크레딧이고, 계산이 필요한 부분은 전부 남의 서버에서 돌았거든요.

그러니 룩이 흩어지는 문제는 장비나 예산이 아니라 순서의 문제였습니다. 기준 한 장을 먼저 만드느냐, 열두 장을 동시에 시작하느냐의 차이요.

원리 네 가지와 오늘 해볼 것 네 가지

여기까지의 원리를 네 줄로 접습니다.

1. 룩은 문장이 아니라 기준 이미지 한 장으로 고정하기
2. 없어야 할 것은 적지 않고, 있어야 할 것만 적기
3. 글자는 생성 모델이 아니라 코드로 얹기
4. 클립의 원본은 몇 번째가 아니라 어떤 이름인가로 지정하기

그리고 오늘 바로 해볼 수 있는 것도 네 가지입니다. 위 네 줄과 하나씩 짝입니다.

1. 앵커 한 장만 먼저 만들고 거기서 멈춰보기 — 마음에 들 때까지 다시 뽑아도 0크레딧입니다
2. 지금 쓰는 프롬프트에서 "없이"가 들어간 표현 찾아 지우기
3. 이미지에 넣으려던 한글을 빼서 나중에 얹을 목록으로 옮기기
4. 클립을 만들기 전에 원본 제목을 눈으로 확인하기

넷 중 하나만 고르신다면 첫 번째를 권합니다. 앵커 한 장을 다시 뽑는 데는 돈이 안 들지만, 그 한 장이 틀린 채로 열한 장이 나가면 열두 장을 다 버려야 하거든요.

앵커를 물리는 순간과 원본을 제목으로 지목하는 순간이 실제 화면으로는 어떻게 보이는지, 영상에 그대로 담아뒀어요: 앵커를 걸고 원본을 이름으로 지목하는 화면 전체