14장. 대량 생성과 배치 자동화

한 장을 멋지게 만드는 일과, 백 장을 흔들림 없이 만드는 일은 전혀 다르다. 전자는 미학의 문제에 가깝고, 후자는 시스템의 문제에 가깝다. ComfyUI를 프로덕션 도구로 쓴다는 말은 결국 이 차이를 받아들이는 데서 시작한다. 프롬프트를 잘 쓰는 것만으로는 부족하다. 어떤 값이 고정되어야 하고, 어떤 값이 바뀌어야 하며, 결과물이 어떤 이름으로 어디에 저장되고, 실패한 작업은 어떻게 다시 돌릴지까지 설계해야 한다.

이 장에서는 "많이 만든다"를 단순 반복으로 보지 않는다. 우리가 만들려는 것은 클릭 노가다를 자동화한 워크플로우가 아니라, 사람이 잠든 사이에도 GPU가 질서 있게 일하는 산출 체계다. 핵심은 네 가지다. Auto Queue로 흐름을 끊지 않고, control_after_generate로 바뀌어야 할 값을 자동으로 굴리고, Wildcard로 변주를 설계하고, 메타데이터와 큐레이션으로 결과를 다시 쓸 수 있는 자산으로 만드는 것이다.¹²

14.1 Auto Queue와 control_after_generate

대량 생성의 첫 번째 오해는 "배치를 크게 잡으면 자동화가 된다"는 생각이다. 사실 ComfyUI에는 비슷해 보이지만 역할이 다른 세 가지가 있다. 하나는 한 번에 여러 장을 동시에 만드는 batch size이고, 다른 하나는 같은 워크플로우를 여러 번 예약하는 queue count이며, 마지막은 각 실행이 끝날 때 특정 정수 값을 어떻게 바꿀지 결정하는 control_after_generate다.²³

이 셋을 구분하지 못하면 워크플로우는 금방 꼬인다. batch size는 한 번의 실행 안에서 병렬로 여러 장을 뽑는 방식이라 VRAM을 더 먹는다. 반면 queue는 같은 엔진이 일을 순서대로 처리하도록 예약표를 쌓는 개념이다. 즉, 대량 생산의 기본 축은 대개 queue이고, batch size는 여유 VRAM이 있을 때만 얹는 가속 장치라고 생각하면 이해가 쉽다.²³

실무에서는 보통 이렇게 나눈다.

• 품질 탐색 단계에서는 batch size 1~2, queue 소량

• 생산 단계에서는 batch size를 보수적으로 유지하고 queue를 길게

• 야간 장기 실행에서는 queue를 중심으로 돌리되, 실패 복구가 쉬운 단위로 끊기

ComfyUI의 Queue는 보기에는 "실행" 버튼 같지만, 실제로는 작업 예약 버튼에 가깝다. 현재 워크플로우 상태를 큐에 넣고, 앞선 작업이 끝나면 다음 예약분이 실행된다. 여기서 중요한 포인트가 하나 있다. 큐에 들어간 작업은 나중의 상태가 아니라, 큐에 넣은 순간의 상태를 기준으로 실행된다. 그래서 프롬프트를 바꾸기 전과 후에 큐를 나눠 넣으면 서로 다른 결과가 나오지만, 같은 상태로 20개를 쌓으면 20개 모두 그 순간의 설정을 따른다.¹²

이제 control_after_generate를 보자. 이 옵션은 seed처럼 정수형 입력에 자주 붙어 있으며, 한 번 생성이 끝난 뒤 값을 어떻게 처리할지 정한다. 선택지는 보통 네 가지다.²

• fixed: 값을 유지한다

• increment: 1씩 올린다

• decrement: 1씩 내린다

• randomize: 무작위 값으로 바꾼다

이 기능이 진가를 발휘하는 시점은 "같은 구조를 유지하면서 한 요소만 체계적으로 바꿀 때"다. 예를 들어 광고 배너 50개를 만들되, 모델·LoRA·프롬프트 템플릿은 고정하고 시드만 바꾸고 싶다면 seed + randomize 조합이 가장 단순하다. 반대로 한 장면을 기준으로 구성 차이를 미세하게 비교하고 싶다면 seed + fixed가 맞다. 또 시드 라이브러리를 구축하며 결과를 순차 검토할 때는 increment가 의외로 유용하다. 오늘의 좋은 시드가 내일도 다시 잡히기 때문이다.

여기서 실무 감각이 갈린다. 많은 초보자는 randomize를 켜고 "다양해졌네"에서 멈춘다. 하지만 프로덕션에서는 다양성보다 통제된 다양성이 중요하다. 무작위는 많아 보이지만, 다시 찾기 어렵다. 그래서 대량 생성에서 추천하는 기본값은 다음과 같다.

특히 상업 작업에서는 먼저 50~100개의 시드를 짧게 테스트해 "구도와 조명이 안정적인 시드"를 골라두고, 그 시드를 프로젝트 자산처럼 재사용하는 편이 효율적이다. 한마디로, 시드를 복권 번호가 아니라 렌즈 세트처럼 다루는 것이다.⁴

Auto Queue는 여기에 리듬을 붙인다. 현재 실행이 끝나면 다음 실행을 자동으로 이어서 돌리기 때문에, 사람 손이 끊기지 않아도 작업이 이어진다.² 다만 Auto Queue를 켠다고 해서 곧바로 생산 체계가 되는 것은 아니다. 아래 세 가지가 같이 갖춰져야 한다.

• 바뀌는 값이 무엇인지 명확해야 한다

• 저장 규칙이 결과를 설명할 수 있어야 한다

• 실패했을 때 어디부터 다시 돌릴지 알 수 있어야 한다

예를 들어 제품 썸네일 80장을 만든다고 해보자. 이때 가장 나쁜 방식은 화면을 보며 prompt를 조금씩 바꿔 80번 Queue를 누르는 것이다. 가장 좋은 방식은 하나의 마스터 워크플로우를 고정하고, 시드·배경 키워드·카피만 바뀌게 설계해 Auto Queue로 넘기는 것이다. 전자는 손이 많이 가고 실수도 많다. 후자는 느려 보여도, 다음 주에도 똑같이 재생산할 수 있다.

대량 실행에서는 큐를 무한정 길게 쌓는 것보다 청크(chunk) 단위로 나누는 습관이 중요하다. 500개 작업이라면 50개씩 10청크로 나누면 검수, 중단, 재시작, 실패 복구가 훨씬 쉽다.¹ GPU는 체력이 좋지만, 사람의 기억력은 생각보다 짧다.

14.2 Wildcard로 수백 가지 변주 자동 생성

Queue가 컨베이어 벨트라면, Wildcard는 그 위로 올라가는 부품 상자다. 결국 대량 생성은 "무엇을 얼마나 바꿀 것인가"의 설계 문제인데, Wildcard는 그 변화의 단위를 문장 안에 질서 있게 심어 넣는다.⁵⁶

가장 단순한 방식은 인라인 문법이다. 예를 들어 {clean|minimal|luxury} 같은 식으로 한 자리에서 여러 선택지를 돌릴 수 있다. 파일 기반 Wildcard는 더 실무적이다. __background/studio__, __cta/sale__처럼 폴더와 텍스트 파일로 관리하면 프롬프트가 짧아지고, 팀 내에서 자산처럼 공유하기 쉬워진다.⁵⁶⁷

핵심은 Wildcard를 "랜덤 문구 생성기"로 쓰지 않는 것이다. 실무에서는 다음 세 층으로 나누는 편이 좋다.

• 고정층: 브랜드 톤, 카메라 언어, 해상도, 품질 토큰

• 반고정층: 프로젝트별 스타일, LoRA 트리거, 구도 규칙

• 가변층: 배경, 소품, 감정, 카피, CTA, 색상, 시간대

이렇게 나누면 변주는 많아지지만 브랜드 일관성은 유지된다. 반대로 모든 요소를 Wildcard로 열어두면 처음엔 재밌지만, 곧 "같은 캠페인인데 왜 이렇게 다 다르지?"라는 질문을 듣게 된다.

PromptFlow 같은 커스텀 노드는 이런 Wildcard 운영을 더 체계적으로 만든다. 인라인 선택지, 파일 Wildcard, 필드별 랜덤/증가 모드, 그리고 조합을 미리 보여주는 Variations 기능이 있어, 실제 생성 전에 경우의 수를 검토할 수 있다.⁵ 이 미리보기는 생각보다 중요하다. 4개의 필드에 각 5개 선택지만 있어도 경우의 수는 625개다. 컴퓨터는 웃지만, 검수자는 울 수 있다.

실전에서는 다음 원칙이 특히 중요하다.

조합 수를 먼저 계산하라

배경 5 × 의상 4 × 조명 3 × 카피 6이면 360가지다. 이때 정말 360장이 필요한지, 아니면 그중 60장만 샘플링하면 되는지 먼저 정해야 한다. 대량 생성의 병목은 GPU보다 검수에서 더 자주 생긴다.

Wildcard 파일은 카테고리보다 용도로 나눠라

colors.txt, objects.txt처럼 추상적으로 쪼개는 것보다 ecom_background_clean.txt, ua_hook_3s.txt, fashion_pose_front.txt처럼 결과물 용도에 맞춰 나누는 편이 유지보수가 쉽다. 그래야 다른 모델로 옮겨도 자산을 재사용할 수 있다.⁷

재현 가능한 랜덤을 써라

Wildcard도 시드와 결합하면 재현성을 가질 수 있다. 즉, 랜덤처럼 보이지만 같은 시드에서는 같은 조합이 나오게 설계할 수 있다.⁶ 이건 프로덕션에서 엄청난 장점이다. 팀장이 "3번 결과만 다시 뽑아봐"라고 말했을 때, 진짜 3번 결과가 다시 나와야 하기 때문이다.

프롬프트 템플릿을 먼저 고정하라

매번 새 문장을 쓰는 방식은 대량 생산에 맞지 않는다. 인물용, 제품용, 장면용 기본 템플릿을 만들고 변수만 비워두는 편이 훨씬 안정적이다.⁴ 좋은 템플릿은 창의력을 줄이는 것이 아니라, 창의력이 낭비되는 지점을 줄인다.

ComfyUI용 배치 노드도 이 과정을 더 기계적으로 만들어준다. 예를 들어 여러 줄 텍스트를 프롬프트 리스트로 쪼개는 노드, 폴더의 이미지를 순서대로 읽는 노드, 그리고 프롬프트 묶음과 이미지 묶음을 곱셈처럼 결합하는 구조를 쓰면 3개의 스타일 × 5개의 원본 이미지 = 15개의 결과 같은 매트릭스를 손으로 만들 필요가 없다.⁸

이 조합형 사고는 아주 중요하다. 대량 생성은 보통 "100번 반복"이 아니라 "5×4×5의 설계"에 가깝다. 반복보다 조합이 더 강력하다.

14.3 마케팅 크리에이티브 100개 만들기 — 실전 케이스

이제 실제로 100개의 마케팅 크리에이티브를 만든다고 가정해보자. 예시는 모바일 앱 광고나 이커머스 배너처럼, 메시지는 다양하지만 브랜드 룩은 유지되어야 하는 상황이다.

목표는 단순하다. 한 개의 마스터 워크플로우로 100개의 비교 가능한 결과를 만드는 것이다. 여기서 중요한 단어는 "비교 가능한"이다. 결과가 많아도 축이 제멋대로면 A/B 테스트가 아니라 랜덤 구경이 된다.

1단계: 마스터 워크플로우를 잠근다

먼저 모델, 해상도, 업스케일 유무, LoRA 스택, 저장 노드, 후처리 노드를 고정한다. 이 단계에서는 프롬프트를 화려하게 바꾸지 않는다. 기본 미감과 산출 포맷을 먼저 잠그는 것이 우선이다. 한마디로 주방 설비를 먼저 고정하고, 그 다음 소스를 바꾼다.

2단계: 변수 축을 3개만 남긴다

100개를 만들 때 변수 축이 7개면 검수 지옥이 열린다. 보통은 다음 세 축이면 충분하다.

• 후킹 카피: 예를 들어 5종

• 비주얼 컨셉: 예를 들어 4종

• CTA 또는 배경 변주: 예를 들어 5종

그러면 5 × 4 × 5 = 100이다. 이 숫자는 아름답다. 많은데, 아직 사람이 읽을 수 있다.

3단계: 프롬프트를 템플릿화한다

예를 들어 제품 광고용 템플릿을 다음처럼 설계할 수 있다.

high-end product photography, __visual_concept__, brand-consistent lighting, clean composition, __background__, emphasis on product clarity, marketing creative, headline feeling: __hook__

여기서 visual_concept, background, hook만 바뀌게 한다. 나머지는 고정한다. 이렇게 해야 테스트 축이 깨지지 않는다.

4단계: 시드 정책을 정한다

광고 테스트에서는 보통 두 가지 전략을 쓴다. 하나는 각 조합마다 같은 시드군을 써서 메시지 차이만 비교하는 방식이고, 다른 하나는 시드도 바꿔 실제 운용 상황에 가까운 변주를 보는 방식이다. 초반에는 전자가 좋고, 후반 확장 단계에서는 후자가 좋다.

실무적으로는 다음 식이 안전하다.

5단계: Queue를 청크로 나눠 돌린다

100개를 한 번에 태우지 말고, 20개씩 다섯 묶음으로 돌린다. 각 묶음이 끝날 때 대표 이미지만 빠르게 확인한다. 프롬프트 오탈자, LoRA 과적용, 저장 경로 실수는 보통 첫 10장 안에서 들통난다. 대량 생산의 지혜는 문제를 빨리 발견하는 데 있다.

6단계: 파일명에 테스트 축을 심는다

저장 파일명이 ComfyUI_00001.png 식이면 100장을 만든 의미가 반쯤 사라진다. 파일명만 봐도 무엇이 바뀐 결과인지 드러나야 한다. 예를 들면 다음과 같다.

ua_spring_hook03_scene02_cta04_seed12031.png

이 한 줄만으로도 나중에 성과 데이터를 붙이기 쉬워진다. 어떤 조합이 클릭률이 좋았는지, 다시 뽑아야 하는지, 비슷한 계열을 더 만들지 판단할 수 있다.

7단계: 낙오분을 별도 재처리한다

100개 중 7개가 별로라고 해서 전체를 다시 돌리면 GPU가 삐진다. 낙오분만 따로 모아 재실행하는 구조가 효율적이다. 그래서 프롬프트 리스트, 시드 리스트, 저장 규칙이 분리되어 있어야 한다. 그래야 7개만 정확히 다시 만든다.

여기서 커스텀 배치 노드는 꽤 쓸모가 있다. 여러 줄 프롬프트를 자동 분리하거나 폴더의 이미지를 순서대로 읽어들이고, 원본 파일명을 유지한 채 저장 흐름으로 넘길 수 있어 반복 작업을 줄여준다.⁸ 더 큰 규모에서는 API가 강력하지만, 100개 안팎의 실무 산출은 UI 기반 배치 설계만으로도 충분히 생산적이다.¹

14.4 결과물 메타데이터 관리와 큐레이션 자동화

대량 생성에서 가장 늦게 배우는 사실이 하나 있다. 만드는 일보다, 만든 것을 다시 찾는 일이 더 중요하다는 점이다.

이미지가 5장일 때는 기억이 메타데이터를 대신한다. 하지만 500장이 되면 기억은 즉시 퇴사한다. 그래서 프로덕션에서는 결과물 관리를 세 층으로 나눠야 한다.

• 파일명 메타데이터

• 이미지 내부 메타데이터

• 외부 매니페스트 또는 로그

파일명 메타데이터: 가장 먼저 보는 정보

파일명은 가장 저렴한 데이터베이스다. 운영 원칙은 단순하다. 프로젝트명, 변주축, 시드, 버전을 최소한으로 넣는다. 길다고 나쁜 게 아니라, 모호한 것이 나쁘다.

추천 순서는 다음과 같다.

프로젝트_캠페인_포맷_변수1_변수2_seed_버전

예를 들면 다음과 같다.

cosmetic_q3_square_cleanbg_offerB_seed44102_v2.png

이렇게 저장하면 폴더 정렬만으로도 비슷한 결과를 묶어 볼 수 있다. 0 채움 숫자를 쓰는 것도 중요하다. 01, 02, 03 식으로 맞춰야 정렬이 사람 마음을 배신하지 않는다.⁸

이미지 내부 메타데이터: 재현성의 보험

ComfyUI 생태계의 큰 장점 중 하나는 생성 결과물에 워크플로우 정보를 담아둘 수 있다는 점이다. 공식 예제 저장소의 이미지들도 메타데이터를 포함하고 있어, 이미지를 다시 불러오면 사용된 워크플로우를 복원할 수 있다.⁹ 즉, PNG 한 장이 단순 결과물이 아니라 "이 이미지를 만든 레시피 카드"가 될 수 있다.

이 기능은 대량 생성에서 특히 중요하다. 왜냐하면 좋은 이미지는 항상 예상보다 늦게 발견되기 때문이다. 오늘은 그냥 지나친 47번 결과가, 다음 주 회의에서 갑자기 "이거 느낌 좋다"가 될 수 있다. 그때 메타데이터가 남아 있지 않으면 감탄만 남고 재현은 사라진다.

더 엄격한 운영이 필요하다면 메타데이터 전용 노드를 붙여 프롬프트, 시드, sampler, scheduler 같은 핵심 정보를 선택적으로 저장할 수도 있다.¹⁰¹¹ 클라이언트 납품본에는 불필요한 정보를 줄이고, 내부 검수본에는 최대한 많은 정보를 남기는 식으로 이원화하는 것도 좋다.

외부 로그와 매니페스트: 검색 가능한 기록

파일명과 내부 메타데이터만으로는 부족한 순간이 온다. 예를 들어 "지난달 여름 캠페인 중 CTA가 Buy Now였고, 초록 배경 계열만 다시 뽑자" 같은 질문에는 외부 로그가 필요하다. 그래서 대량 생성에서는 이미지 바깥에도 기록이 있어야 한다.

가장 단순한 형태는 CSV나 JSON 매니페스트다. 한 줄에 한 결과씩 아래 정보를 적는다.

• 출력 파일명

• 프롬프트 템플릿 이름

• 사용한 Wildcard 항목

• seed

• 모델·LoRA 버전

• 생성 시각

• 내부 평점 또는 채택 여부

이 정도만 있어도 큐레이션 속도가 완전히 달라진다. 나중에 "채택률이 높은 시드군", "반응이 좋은 배경 키워드", "자주 망하는 조합"을 역으로 찾을 수 있기 때문이다. 대량 생성의 진짜 자산은 이미지 자체만이 아니라, 어떤 조합이 잘 먹히는지에 대한 운영 데이터다.

Queue 이력도 자산으로 다뤄라

장시간 배치에서는 큐 자체를 저장하고 복원할 수 있으면 훨씬 편하다. Queue Manager 계열 확장은 큐를 로컬 데이터베이스에 보존하고, 일시정지·재개, 보관, 내보내기·가져오기, 워크플로우별 필터링 같은 기능을 제공한다.¹² 즉, 큐가 일회성 임시 목록이 아니라 다시 재생 가능한 작업 세트가 된다.

특히 유용한 기능이 Workflow Name을 파일명 prefix에 연결하는 방식이다. 이렇게 하면 어떤 워크플로우에서 나온 결과인지 파일명 수준에서 바로 드러난다.¹² 대량 생산에서는 이 작은 차이가 엄청 크다. 폴더를 열었을 때 "이게 어떤 실험이었지?"라고 묻는 시간이 줄어들기 때문이다.

큐레이션 자동화: 다 만들고 고르는 것이 아니라, 고르기 쉽게 만들기

좋은 큐레이션 자동화는 AI가 대신 취향을 결정하는 것이 아니다. 사람이 고르기 쉬운 형태로 결과를 정리해 주는 것이다. 가장 실용적인 방식은 다음과 같다.

• 1차: 파일명과 폴더 규칙으로 자동 분류

• 2차: 저해상도 컨택트 시트 또는 썸네일 묶음 생성

• 3차: 별점, keep/reject, 메모를 붙인 로그 저장

• 4차: keep 목록만 재업스케일 또는 후처리

이 흐름이면 GPU는 전부 최고 품질로 뽑지 않아도 된다. 먼저 비교 가능한 초안을 많이 만들고, 살아남은 것만 비싼 후처리를 태우면 된다. 프로덕션에서는 "좋은 이미지를 만드는 비용"보다 "좋은 이미지를 빨리 찾는 비용"을 줄이는 쪽이 더 자주 이긴다.

대량 생성의 운영 원칙

이 장의 내용을 한 줄로 줄이면 이렇다. 자동화는 버튼을 덜 누르는 기술이 아니라, 결과를 다시 사용할 수 있게 만드는 기술이다.

ComfyUI에서 대량 생성을 잘한다는 것은 다음을 뜻한다.

• Queue가 길어져도 무슨 일이 일어나는지 설명할 수 있다

• control_after_generate로 바뀌는 값을 통제할 수 있다

• Wildcard를 써도 브랜드 일관성을 잃지 않는다

• 결과물의 출처를 파일명과 메타데이터로 추적할 수 있다

• 실패한 일부만 다시 돌릴 수 있다

한 장의 명작은 감각에서 나온다. 하지만 백 장의 안정된 산출은 구조에서 나온다. 그리고 ComfyUI가 정말 강한 순간은 바로 여기다. 노드 하나하나가 예술가의 손맛을 없애는 것이 아니라, 손맛이 필요한 곳과 필요 없는 곳을 분리해 준다. 사람은 선택과 판단에 집중하고, 기계는 밤새 흔들림 없이 반복한다. 그때부터 ComfyUI는 단순한 생성기가 아니라, 진짜 프로덕션 라인이 된다.

참고

¹ComfyUI Batch Processing: How I Automate 1000+ Image Generations

³ComfyUI Masterclass Part 4: Faster Batch Processing

⁴Z-Image Batch Image Generation Secrets: My Painful Experience Producing 100 Images

⁵GitHub - maartenharms/comfyui-promptflow

⁶ComfyUI-stable-wildcards detailed guide

⁷Wildcard 를 이용한 프롬프트 관리 및 사용방법 - comfyui 에서 프롬프트관리 (2)

⁸GitHub - Hahihula/ComfyUI-batching-nodes

⁹ComfyUI Examples

¹⁰Metadata Hub: Mastering ComfyUI Nodes for Effective Metadata Generation

¹¹Mastering ComfyUI_SelectiveMetadata: Optimize Metadata in Your ComfyUI Workflows

¹²GitHub - QuietNoise/comfyui_queue_manager