실제로 결과물을 만들어내는 AI 이미지 생성 워크플로우 (Workflows)

지난 화요일, 나는 똑같은 히어로 이미지(hero image)를 재생성하는 데 4시간을 허비했다. 모델이 나빴기 때문이 아니다. Flux.1 Pro와 Midjourney v6는 진정으로 놀라운 성능을 보여준다. 문제는 도구 간의 맥락(context)을 잃지 않으면서 아이디어 구상(ideation), 반복(iteration), 그리고 최종 결과물 전달(delivery) 단계로 개념을 이동시킬 체계적인 방법이 없었다는 점이다. 3시간째에 접어들었을 때, 나는 프롬프트(prompt)를 메모 앱에 복사하여 붙여넣고 별도의 브라우저 탭에서 결과물을 수동으로 비교하고 있었다. 그것은 워크플로우(workflow)가 아니다. 그것은 그저 허둥대는 것(thrashing)일 뿐이다. 세 가지 서로 다른 제품을 위한 이미지 파이프라인(image pipelines)을 출시하며 깨달은 점은, AI 이미지 생성의 병목 현상(bottleneck)은 거의 결코 모델 때문이 아니라는 것이다. 그것은 모델을 둘러싼 연결 조직(connective tissue)의 문제다.

모델 선택 문제는 실재하며, 아무도 솔직하게 말하지 않는다

모든 "AI 이미지 가이드"는 "사용 사례에 맞는 적절한 모델을 선택하세요"라는 말로 시작하지만, 정작 유용한 정보는 모델 목록만 나열할 뿐이다. 그래서 여기 솔직한 버전을 공개한다: Flux.1 Dev/Pro는 일관된 텍스트 렌더링(text rendering)과 사실적인 제품 표면 표현 덕분에 현재 제품 및 UI 목업(UI mockup) 작업에 가장 좋은 선택이다. Midjourney v6는 브랜드 작업을 위한 미적 일관성(aesthetic consistency) 측면에서 승리한다. 만약 50개의 에셋(assets) 전반에 걸쳐 응집력 있는 시각적 언어가 필요하다면, Midjourney의 스타일적 중력(stylistic gravity)을 이길 수 있는 것은 없다. SDXL과 LoRA의 조합은 매 호출마다 프롬프트를 입력하는 오버헤드(overhead) 없이, 추론(inference) 시점에 고유한 스타일이나 캐릭터 일관성을 내장해야 할 때 유일하게 실행 가능한 경로다. DALL-E 3는 이미 OpenAI 스택을 사용 중이며, API의 단순함이 필요하고 보수적인 안전 필터링(safety filtering)을 감수할 수 있는 팀을 위한 것이다.

개발자들이 저지르는 실수는 단일 모델을 중심으로 구축하는 것이다. 그렇게 하면 사용 사례를 과도하게 제한하거나, 여러 개의 스파게티 통합(spaghetti integrations)을 유지 관리하게 된다. 올바른 방법은 초기에 추상화 계층(abstraction layer)을 만드는 것이다. 설령 그것이 작업 유형을 모델 엔드포인트(model endpoints)에 매핑하는 설정 딕셔너리(config dict)일지라도 말이다. 첫 번째 실제 파이프라인을 작성하기 전에 그것부터 구축하라.

프롬프트 아키텍처는 소프트웨어 아키텍처다

이미지 생성을 위한 프롬프트(Prompts)에는 구조가 있습니다. 대부분의 사람들은 이를 하나의 문장으로 작성합니다. 이는 탐색 단계에서는 효과적입니다. 하지만 프로덕션(Production) 단계에서는 작동하지 않습니다.

여러 파이프라인을 반복하며 제가 정착한 구조는 다음과 같습니다:

[Subject + action] :: [Environment/context] :: [Technical spec] :: [Style vector] :: [Negative constraints]

각 세그먼트(Segment)는 독립적으로 조정 가능합니다. 클라이언트가 "더 영화적인 느낌(cinematic)을 주세요"라고 말하면, 스타일 벡터(Style vector)만 수정하면 됩니다. QA에서 아티팩트(Artifact)가 발견되면, 부정 제약 조건(Negative constraints)을 추가합니다. 프롬프트 전체를 다시 쓰는 일은 절대 하지 마십시오. 그러면 모든 설정이 초기화됩니다.

Flux 또는 SDXL API를 사용하는 팀의 경우, 이는 템플릿 시스템(Templating system)으로 깔끔하게 매핑됩니다. 피사체(Subject)에 대한 설명을 환경 기술자(Environment descriptors)와 분리하여 저장하십시오. 그리고 버전을 관리하십시오. 프롬프트 구성 요소를 설정(Config)처럼 다루십시오. 코드 내의 인라인 문자열(Inline strings)이나 자유 형식(Free-form)이 아니라, 스키마(Schema)가 있는 구조화된 데이터(Structured data)로 취급해야 합니다.

다른 사람들이 말하지 않는 사실이 하나 더 있습니다: 품질 파이프라인에서 부정 프롬프트(Negative prompts)가 작업의 30%를 수행하고 있다는 점입니다. 아티팩트 유형(흐릿함, 과포화, 해부학적 오류, 텍스트 왜곡 등)별로 정리된 잘 관리된 부정 프롬프트 라이브러리는 프로덕션 자산입니다. 이를 자산으로서 대우하십시오.

반복 루프(Iteration Loops): 대부분의 파이프라인에서 시간이 낭비되는 지점

단순한 이미지 생성 워크플로우에서 개발자의 시간이 대략적으로 소비되는 비율은 다음과 같습니다:

• 10% 초기 프롬프트 작성
• 15% 1차 생성
• 60% 수동 비교 및 반복(Iteration)
• 15% 최종 선택 및 내보내기(Export)

문제는 바로 이 60%입니다. 탭, 도구, 해상도를 넘나드는 수동 비교는 느리고 손실이 많습니다. 어떤 시드(Seed)가 어떤 결과를 만들어냈는지, 어떤 파라미터(Parameter) 변경이 어떤 개선을 가져왔는지 추적하기가 어렵습니다. 해결책은 더 빠른 생성이 아니라, 구조화된 반복(Structured iteration)입니다.

실제로 구조화된 반복(Structured iteration)이 어떻게 이루어지는지 살펴보면 다음과 같습니다. 모든 생성 실행(generation run) 시 출력물과 함께 전체 파라미터 세트(모델, 프롬프트, 네거티브 프롬프트, 시드, CFG scale, 스텝 수)를 기록합니다. 각 실행 결과를 서로 고립시켜 비교하는 것이 아니라, 기준점(baseline)과 비교해야 합니다. 효과적인 방향을 찾았다면, 처음부터 다시 시작하지 말고 해당 시드(seed)에서 파생(branch)시키십시오. 이는 당연해 보이지만, 대부분의 도구가 이를 강제하지 않기 때문에 체계적으로 수행하는 사람은 거의 없습니다.

생성 파이프라인(generation pipelines)을 구축하는 개발자라면, 첫날부터 모든 것을 구조화된 형식으로 기록하십시오. run_id, parameters_json, output_path, rating을 포함한 로컬 SQLite 테이블만 있어도 반복(iteration)의 역학이 완전히 바뀝니다. 무엇이 효과적이었는지 추측하는 단계에서 벗어날 수 있습니다.

ControlNet과 참조 이미지: 대부분의 팀이 놓치는 핵심 열쇠

만약 ControlNet이나 이미지 투 이미지(image-to-image) 워크플로우를 사용하지 않고 있다면, 당신은 매번 처음부터 생성하고 있는 것이며 왜 일관성(consistency)을 유지하기 어려운지 의문을 품고 있는 것입니다. 참조 이미지(Reference image) 워크플로우는 실제 이미지 생성(production image generation)에서 가장 레버리지가 높은 기술이지만, 이 분야에 새로 진입한 팀들이 가장 활용하지 않는 기술이기도 합니다.

실질적인 패턴은 다음과 같습니다. 시각적 차원별로 정리된 **참조 라이브러리(reference library)**를 유지하십시오. 구도 참조(composition references), 조명 참조(lighting references), 스타일 참조(style references), 피사체 참조(subject references) 등으로 분류합니다. 새로운 생성 작업을 시작할 때, 1~3개의 참조 이미지를 선택하여 ControlNet의 depth/pose/canny를 통해 적용하거나, 제어된 디노이징 강도(denoising strength)를 가진 img2img를 통해 적용합니다.

디노이징 강도(Denoising strength)는 대부분의 개발자가 무시하거나 최대치로 올려버리는 조절 다이얼입니다. 일관성 작업을 위해서는 이 값을 0.4에서 0.65 사이로 유지해야 합니다. 0.4 미만이면 생성하는 것이 아니라 필터링을 하는 것에 가깝습니다. 0.7을 넘어가면 참조 이미지를 잃게 됩니다. 0.4~0.65 구간이 바로 반복(iteration)이 일어나는 지점입니다. 이 수치를 반드시 기억하십시오.

특히 이미지 생성 워크플로우 (Workflows)에서 가장 어려운 문제인 캐릭터 일관성 (Character Consistency)을 위해서는, 미세 조정 (Fine-tuning) 없이 현재 가장 좋은 접근 방식은 다음의 조합입니다: 상세한 캐릭터 참조 이미지, 신체 포지셔닝을 위한 ControlNet OpenPose, 그리고 이를 기반으로 분기할 고정된 시드 (Locked seed). 완벽하지는 않습니다. 완벽한 것은 아무것도 없으니까요. 하지만 재현 가능 (Reproducible)하며, 이는 완벽함보다 더 중요합니다.

자동화 및 API 통합: 접착제 구축하기

어떠한 규모에서든 이미지 생성을 실제로 배포하기 위한 실제 워크플로우는 다음과 같습니다:

1. 구조화된 프롬프트 생성 (템플릿 시스템 또는 언어 모델 (Language Model)로부터)
2. 파라미터 로깅 (Parameter logging)을 포함한 멀티 모델 디스패치 (Multi-model dispatch)
3. 자동화된 품질 필터링 (CLIP 스코어링, 미적 스코어링 (Aesthetic scoring), 해상도 체크)
4. 예외 케이스를 위한 인간 검토 큐 (Human review queue)
5. 다운스트림 시스템 (Downstream systems)으로의 내보내기 파이프라인 (Export pipeline)

3단계는 대부분의 팀이 격차를 보이는 지점입니다. 모든 결과물을 타겟 브리프 (Target brief)와 비교하여 CLIP 유사도 점수 (CLIP similarity score)로 실행하는 데는 몇 초밖에 걸리지 않으며, 기술적으로는 괜찮지만 의미론적으로(Semantically) 틀린 생성물 중 약 30%를 걸러낼 수 있습니다. 미적 스코어링 모델 (LAION에서 여러 개를 출시함)은 놓치기 쉬운 흐릿하거나 채도가 과도한 (Oversaturated) 결과물을 잡아냅니다. 이것은 인간의 검토를 대체하는 것이 아니라, 인간의 검토를 감당 가능한 수준으로 만드는 분류 (Triage) 작업입니다.

API 통합의 경우: Replicate는 현재 Flux 및 SDXL 모델을 일관된 업타임 (Uptime)으로 실행할 수 있는 가장 마찰이 적은 (Lowest-friction) 방법입니다. Stability AI의 API는 프로덕션 (Production) 환경에서 더 안정적이지만 모델의 다양성은 적습니다. 만약 프로덕션 환경에서 ComfyUI 워크플로우가 필요하다면, Modal이 적절한 인프라 선택입니다. Modal은 제가 시도해 본 그 어떤 것보다 GPU 콜드 스타트 (Cold-start) 문제를 더 잘 처리합니다.

이미지 생성 워크플로우 체크리스트

생성하기 전에:

• 작업 유형 식별 (제품, 브랜드, UI, 캐릭터, 환경)
• 습관이 아닌 작업 유형에 기반하여 모델 선택
• 프롬프트를 세그먼트별로 구조화 (피사체, 환경, 기술적 요소, 스타일, 부정 프롬프트)
• 일관성이 중요한 경우 참조 이미지 (Reference images) 선택
• 시드 (Seed) 전략 정의 (일관성을 위해 고정하거나, 탐색을 위해 무작위 설정)

반복 과정 중 (During iteration):

• 모든 파라미터를 출력물과 함께 기록
• 임시방편이 아닌 기준점 (Baseline)과 비교
• 디노이징 강도 (Denoising strength)를 의도적으로 설정 (최댓값으로 설정하지 않음)
• 관찰된 새로운 아티팩트 (Artifacts)를 반영하여 부정 프롬프트 (Negative prompt) 업데이트

최종 전달 전 (Before delivery):

• CLIP 또는 미적 점수 (Aesthetic score) 필터 적용
• 대상 사용 사례에 맞춰 해상도 및 포맷 확인
• 재현성 (Reproducibility)을 위해 시드 및 파라미터 보관

AI Handler가 이를 접근하는 방식

제 개인 프로젝트와 다른 개발자들이 구축하는 과정을 지켜보며 계속 마주쳤던 문제는, 기존의 어떤 도구도 제대로 된 워크플로우 구조를 강제하지 않는다는 점이었습니다. Discord에서 Midjourney를 실행하고, Replicate에서 Flux를 사용하며, 로컬에서 SDXL을 돌리고, API를 통해 DALL-E를 사용할 수는 있지만, 여러분의 프롬프트 라이브러리, 파라미터 이력, 참조 이미지, 모델 라우팅 로직, 그리고 출력물 검토 큐 (Review queue)가 한데 모여 있는 단일 장소는 없습니다. 결국 서두에서 설명한 것처럼 화요일 오후 4시간을 허비하게 되는 것입니다.

AI Handler는 바로 이 문제를 해결하기 위해 제가 만들고 있는 통합 AI 워크플로우 도구입니다. 이미지 생성 모듈은 구조화된 프롬프트 템플릿 제작, 단일 인터페이스를 통한 멀티 모델 디스패치 (Multi-model dispatch), 모든 출력물과 연동된 자동 파라미터 기록, 참조 이미지 관리, 그리고 점수 기반의 검토 큐를 제공합니다. 추상화 계층 (Abstraction layer)은 실질적이며 일급 객체로 취급됩니다. 작업 유형에 따라 모델 라우팅을 구성하면 시스템이 API의 차이점을 처리합니다. 모든 것은 사용자가 소유하고 쿼리할 수 있는 형식으로 기록됩니다.

더 넓은 비전은 이미지 생성 (image generation), 텍스트 생성 (text generation), 에이전트 워크플로우 (agent workflows), 그리고 데이터 파이프라인 (data pipelines)이 동일한 파라미터 로깅 (parameter logging), 버전 관리 (versioning), 그리고 리뷰 인프라 (review infrastructure)를 공유하는 도구를 만드는 것입니다. 왜냐하면 이 모든 분야에서 워크플로우 문제는 동일하기 때문입니다.

AI Handler는 2026년 6월에 출시됩니다. 현재 베타 사용자를 모집 중입니다. 특히 공개 출시 전에 워크플로우를 스트레스 테스트 (stress-test)하고자 하는, 프로덕션 이미지 파이프라인 (production image pipelines)을 구축 중인 개발자와 팀을 찾고 있습니다. 베타 액세스 권한을 원하시면 **ceo@eternalsix.com**으로 이메일을 보내주세요.