
AI로 이미지를 생성할 때, 왜 매번 결과가 다를까?
어떻게 하면 내가 원하는 구도를 딱 맞출 수 있는거지?
그 비밀은 바로 '컨디셔닝(Conditioning)'
0. 컨디셔닝(Conditioning) : AI의 자유에 '조건' 설정
AI의 세상에는 상상할 수 없을 만큼 거대한 랜덤박스가 존재한다.
여기에 "이런 조건을 지켜서 그려줘" 처럼 생성 과정에 적용할 조건을 제시하는 행위 전반을 컨디셔닝이라고 부른다.
무엇을 '주제'로 만들지와, '어떤 방식으로' 만들지를 안내하는 가이드라인.
1) 프롬프트(Prompt): 무한한 랜덤박스에서 조각 뽑기
프롬프트는 컨디셔닝의 가장 기본이 되는 '텍스트 조건'.
내가 입력한 프롬프트(Prompt)는 랜덤 박스에서 어떤 조각들을 꺼낼지 결정하는 ‘요청서’와 같다.
예를 들어, [붉은 눈의 소년]이라고 입력했다고 가정하면,
- ‘붉은’의 랜덤: 채도가 높은 빨강, 검붉은 색, 노을빛 붉은색 등 수만 가지 붉은색 중 하나가 선택.
- ‘눈’의 랜덤: 동그란 눈, 가로로 긴 눈, 동공의 모양, 속눈썹의 각도 등 '눈'이라는 카테고리 안의 수많은 선택지 중 하나.
- ‘소년’의 랜덤: 머리 모양, 나이대, 표정 등이 랜덤으로 결정.
매번 결과가 다른 이유는 뽑을 때마다
수많은 랜덤 요소들이 만나 하나의 이미지로 합쳐져 결과로 나온다.

내가 요청한건 왼쪽 이미지였는데, 하나의 프롬프트만 입력했을 경우 오른쪽처럼 요청 사항이 적용 안 되는 경우가 많았다.
“프롬프트를 못 썼다”기보다, 프롬프트가 모델 내부에서 처리되는 방식(token/chunk 한계, 조건 간 간섭) 때문에 생기는 일이 더 흔하다. 프롬프트가 길어지면 뒤쪽 내용이 약해지거나 무시된 것처럼 보일 수 있고, 색을 여러 개 요구하면 요소별로 분리되지 않고 전체 톤처럼 한 색이 퍼져 섞여 보이기도 한다.
AI에게 말을 잘 거는 것보다, AI가 이해한 조건들을 구조적으로 전달하는 방식이 결과에 더 큰 영향을 준다.
2) Token
토큰(Token)은 AI가 프롬프트 문장을 “그대로 문장”으로 읽는 게 아니라, 내부에서 처리 가능한 작은 단위로 쪼개서 이해하는 최소 단위를 말한다. 입력한 문장은 모델 입장에선 여러 개의 토큰으로 분해되고, 모델은 이 토큰들을 바탕으로 의미를 해석하고 결과를 만들어낸다.
* 왜 토큰이 중요할까?
토큰 수가 늘어날수록 모델이 한 번에 처리해야 하는 정보량이 많아지고, 그만큼 “무엇을 더 중요하게 반영할지”가 흔들릴 수 있다.
그래서 이미지 생성에서도 프롬프트가 길어지면(토큰이 많아지면) 뒤쪽에 적은 내용이 약하게 먹거나, 여러 속성(예: 색/스타일/소품)이 서로 섞여 보이는 현상이 체감되곤 한다.
* 토큰은 어떻게 쪼개질까?
토큰은 꼭 “단어 1개 = 토큰 1개”가 아니고, 단어가 더 작은 조각(부분 단어, 문자, 문장부호 등)으로 나뉠 수도 있다.
예를 들어 긴 단어/복잡한 표현/특수문자가 섞이면 토큰이 생각보다 더 많이 늘어날 수 있다.
※ 핵심 키워드는 앞쪽에 두고, 중복되는 표현은 줄이면 토큰 낭비를 줄이는 데 도움이 된다.
※ 정확히 분리돼야 하는 속성 (예: A는 빨강, B는 파랑)은 문장으로 길게 늘이기보다 구조적으로 나눠 전달하는 방식이 더 안정적일 때가 많다.
2) Token 75
‘Single Prompt’는 토큰이 77 안쪽일 때는 모델이 한 번에 무난하게 처리해서, 의도한 대로 이미지가 잘 나오는 경우가 많다.
다만, 실제로 프롬프트에 "쓸 수 있는 내용'은 77 전체가 아니라, 앞뒤에 붙는 득수 토큰을 제외한 75 토큰 정도가 실사용 구간이라 길이를 꽉 채우면 뒤쪽 문장이 밀리기 시작한다.
그리고 이 한도를 넘어가면 프롬프트가 청크(chunk) 단위로 나뉘어 처리되기 시작한다. 이 구간부터는 문장 뒤쪽에 적은 내용일수록 영향력이 약해지거나, 일부가 적용되지 않은 것처럼 보일 수 있다. (예: 뒤에 넣은 배경/소품/색감이 잘 안 먹는 느낌)
즉, “프롬프트를 못 썼다” 보다 “길이가 길어져서 처리 방식이 바뀌었다”가 원인일 때가 많다.
이럴 때 해결 방향은 세 가지다.
① 프롬프트를 짧고 핵심 위주로 다시 정리해서 75 토큰 안에 넣기.
② 길게 써야 한다면, 중요한 내용을 앞쪽에 배치(우선순위 올리기)
③ Conditioning의 다른 기능 추가 사용하기
Test) Single Prompt


테스트를 위해
① Checkpoint : novaFurryXL_ilV150
② Negative : 심플하게 적고 공용으로 사용.
③ Single Prompt : 프롬프트는 일부러 길고 복잡하게 구성해서(요소가 많고 색 요청이 많음) 토큰/청크 한계를 넘기고, 그로 인해 내용이 서로 간섭하도록 만들었다. (가중치 (), 수치 사용 X)
④ VAE는 Checkpoint VAE 사용. Rora는 사용 X.



* 프롬프트가 길어지자 색 간섭이 눈에 띄게 발생했다.
① 특히 머리색을 “흰색+검은색 반반(뚜렷한 경계)”로 요청했는데도, 눈동자 색으로 넣은 빨강/파랑과 머리색의 흰/검 중에서 랜덤으로 나오는 등 한 색으로만 튀어나오는 경우가 많았다.
② 눈동자는 성공 확률이 상대적으로 높았지만, 양쪽이 한 가지 색으로 통일되는 결과도 자주 나왔다.
이 결과는 “문장을 못 써서”라기보다, 프롬프트가 길어지면서 75 토큰 단위로 청크가 나뉘어 처리되고 77 토큰 제한을 우회하기 위해 분할 처리하는 과정에서 토큰 영향력이 분산되거나 특정 구간이 더 강하게 먹는 현상 때문에 생길 수 있는 전형적인 패턴이라고 했다.
* 프롬프트가 75토큰 단위 내에 작성되는 경우
처음 테스트할 때는 프롬프트가 짧아서 75 토큰(한 번에 처리되는 범위) 안에 들어갔다.
이 경우에는 Single Prompt만으로 뽑은 결과물이 오히려 Conditioning Concat/Combine을 쓴 것보다 결과가 더 좋게 나왔다.


프롬프트가 짧아서 75 토큰 안에 들어가면, “그 한 문장”이 이미 CLIP 텍스트 인코더가 한 번에(한 시퀀스로) 안정적으로 소화할 수 있는 범위라서 Single Prompt로 충분히 깔끔한 결과물이 나온 거 같다.
반대로 짧은 프롬프트를 억지로 Concat/Combine를 사용한 것은.
“도움이 꼭 필요한 상황”이 아닌데 conditioning을 인위적으로 쪼개고 섞는 과정이 들어가서, 원래 한 덩어리로 잘 정렬되던 조건들의 정렬이 흔들렸던 거 아닐까? 싶다. 기능을 사용하는 게 무조건 좋은 건 아니었다. 맞는 상황에 사용하자.


확실한 건, 프롬프트가 길어지면 프롬프트만으로는 한계가 바로 나타났고, 여러 기능들을 사용해서 분리하고 추가적으로 요청 하는 것이 원하는 방향으로 이미지를 얻을 수 있었다.
'디지털 > ComfyUI' 카테고리의 다른 글
| [ComfyUi] DWPose로 사진 포즈 고정하기 (0) | 2026.02.12 |
|---|---|
| [ComfyUi] Conditioning Concat (Text) (0) | 2026.02.11 |
| [ComfyUi] 설치 가이드 ComfyUI Manager (0) | 2026.02.06 |
| [Comfy UI] 설치 가이드 ComfyUI Portable (0) | 2026.02.06 |
| [Comfy UI] 설치 가이드 ComfyUI Desktop (0) | 2026.02.05 |