AI 이미지·동영상 생성 플랫폼을 쓰다 보면 '워크플로우(Workflow)'라는 메뉴를 자주 마주칩니다. Tensor.Art에는 수천 개의 공개 워크플로우가 있고, OpenArt는 Suite라는 이름으로 도구 파이프라인을 제공합니다. ComfyUI를 기반으로 한 노드 그래프 화면은 처음 보면 회로도처럼 복잡해 보입니다.
반면 많은 사람이 실제로 하는 방법은 훨씬 단순합니다. 프롬프트를 입력해 이미지를 만들고, 결과가 마음에 들지 않으면 다른 도구로 이어서 편집합니다. 배경을 제거하고, 포즈를 바꾸고, 동영상으로 변환하는 일련의 과정을 수동으로 한 단계씩 진행합니다.
두 방식의 차이는 무엇이고, 워크플로우는 단계별 프롬프트로 대체할 수 있을까요.
워크플로우란 무엇인가
워크플로우의 핵심은 노드(node) 기반 파이프라인입니다. AI 이미지 생성 과정을 각각의 기능 단위로 분해하고, 그 결과물을 선(edge)으로 연결해 자동으로 순차 실행합니다.
예를 들어 Flux 모델로 이미지를 생성하고 업스케일하는 워크플로우는 다음과 같은 노드들로 구성됩니다.
CheckpointLoader — 모델 파일 불러오기
LoRALoader — 추가 학습 파일 적용 (3개)
CLIPTextEncode — 텍스트 프롬프트를 벡터로 변환 (긍정/부정)
EmptyLatentImage — 빈 잠재 공간 생성
KSampler — 노이즈 제거로 이미지 생성
VAEDecode — 잠재 벡터를 픽셀 이미지로 변환
UpscaleModelLoader + ImageUpscaleWithModel — 업스케일
SaveImage — 저장
이 모든 과정이 하나의 JSON 파일에 담겨 있고, '실행' 버튼 하나로 처음부터 끝까지 자동으로 처리됩니다.
Tensor.Art의 'Flux with LoRA + Upscale' 워크플로우입니다. 화면 중앙의 미리보기 패널에 체크포인트 로드, LoRA 로드 노드가 연결된 그래프가 표시됩니다. 이 워크플로우는 4,100회 이상 실행됐고 1,600회 이상 다운로드됐습니다.
플랫폼별 워크플로우 현황
Tensor.Art — ComfyUI 클라우드 실행
Tensor.Art의 Workflows 페이지입니다. 각 카드에 노드 수(14 Nodes, 19 Nodes, 24 Nodes 등)가 표시됩니다. FACE, CLOTHES, CHARACTER, UPSCALE, IP ADAPTER, INPAINT, OUTPAINT, CONTROLNET, LORA, VIDEO 등 카테고리로 분류됩니다.
ComfyUI를 로컬에 설치할 필요 없이 브라우저에서 바로 실행할 수 있습니다. 다른 사람이 공유한 워크플로우를 한 번 클릭으로 실행하고, 마음에 들면 JSON 파일로 다운로드해 수정할 수 있습니다.
OpenArt — Suite 방식의 도구 파이프라인
OpenArt는 원래 ComfyUI 워크플로우 갤러리로 시작했지만, 현재는 OpenArt Suite라는 형태로 전환됐습니다. Frame to Video, Text to Video, Motion Sync, Lip-Sync, Replace Character, Upscale Video 등 개별 도구들을 선택해 순서대로 사용하는 방식입니다.
노드 그래프 화면 대신 각 기능을 독립적인 도구 카드로 제공합니다. 기술적 배경 없이도 시작할 수 있게 진입 장벽을 낮춘 구조입니다.
ComfyUI — 워크플로우의 원형
ComfyUI는 워크플로우의 원점입니다. 로컬 PC에 설치하거나 Tensor.Art, RunComfy, ThinkDiffusion 같은 클라우드 서비스를 통해 사용합니다. 노드를 자유롭게 배치하고 연결해 완전히 커스터마이즈된 파이프라인을 만들 수 있습니다.
Civitai는 모델과 함께 워크플로우 JSON을 공유합니다. 특정 모델로 특정 스타일의 결과를 얻기 위한 검증된 파이프라인을 모델과 함께 배포하는 방식입니다.
기타 플랫폼
Leonardo.ai는 'Realtime Canvas'와 'Alchemy'라는 이름으로 파이프라인 기능을 제공합니다. Stability AI는 API를 통한 파이프라인 구성을 지원합니다. Midjourney는 현재까지 워크플로우 방식을 채택하지 않고 단일 프롬프트 방식을 유지합니다.
워크플로우를 단계별 프롬프트로 대체할 수 있는가
결론부터 말하면 대부분은 가능하지만, 일부는 불가능하거나 현실적으로 어렵습니다.
워크플로우의 각 노드가 하는 일은 사실 우리가 이미 단계별로 수동으로 하는 것들입니다. 이미지 생성 → 업스케일 → 배경 제거 → 포즈 변환 → 동영상 생성의 과정을 XBRUSH 같은 도구로 순서대로 수동 실행하면 워크플로우와 유사한 결과를 얻을 수 있습니다. 각 단계의 결과물을 눈으로 확인하면서 다음 단계로 넘어가기 때문에, 중간에 방향을 조정할 수 있다는 장점도 있습니다.
그러나 다음의 항목들은 단계별 프롬프트 방식으로 대체하기 어렵습니다.
대체하기 어려운 것들 — 항목별 상세
1. KSampler 파라미터의 수치 제어
이미지를 생성하는 핵심 노드인 KSampler에는 결과물의 품질과 성격을 결정짓는 여러 파라미터가 있습니다.
Steps (20~50) — 노이즈 제거 반복 횟수입니다. 20단계면 빠르지만 디테일이 거칠고, 50단계면 세밀하지만 시간이 두 배 이상 걸립니다. 그림체에 따라 최적값이 다릅니다.
CFG Scale (1~30) — 프롬프트를 얼마나 강하게 따를지를 결정합니다. 낮으면(1~5) AI가 프롬프트를 느슨하게 해석해 창의적이고 자연스러운 이미지를 만들고, 높으면(15~20) 프롬프트의 모든 단어를 강제하려다 오히려 색이 과포화되고 과장된 결과가 나옵니다. 같은 프롬프트라도 CFG 7과 CFG 15는 완전히 다른 이미지입니다.
Denoise Strength (0.0~1.0) — img2img에서 원본 이미지를 얼마나 유지할지 결정합니다. 0.3이면 원본을 거의 유지하며 미세하게 수정하고, 0.9면 원본 구도만 남기고 거의 새 이미지를 만듭니다. 이 수치 하나가 편집 강도를 결정합니다.
Sampler와 Scheduler 조합 — euler_a, dpm++2m, lcm, ddim 등의 알고리즘을 선택하고 karras, exponential 같은 스케줄러와 조합합니다. 같은 프롬프트·같은 씨드라도 알고리즘에 따라 선이 날카로운 일러스트가 나올 수도, 부드러운 유화 질감이 나올 수도 있습니다.
단계별 프롬프트 방식에서는 이 파라미터들을 플랫폼 UI가 제공하는 슬라이더로만 제어합니다. 플랫폼에 따라 CFG가 아예 노출되지 않거나 제한된 범위만 허용하고, sampler 선택 옵션이 없는 경우도 많습니다.
2. Latent 공간 직접 연결 — 렌더링 없는 데이터 전달
AI가 이미지를 생성할 때 내부적으로 다루는 데이터는 픽셀이 아니라 잠재 벡터(latent vector)입니다. 생성이 완료되면 VAEDecode 노드가 이 벡터를 픽셀로 변환합니다.
워크플로우에서 img2img를 할 때의 경로:
입력 이미지 → VAEEncode(픽셀 → latent) → KSampler(편집) → VAEDecode(latent → 픽셀) → 출력
단계별 프롬프트 방식에서의 경로:
결과 이미지(픽셀) → 저장 → 다음 도구에 업로드 → 플랫폼이 내부적으로 재인코딩 → 처리 → 출력
차이는 "재인코딩"에 있습니다. 픽셀을 다시 latent로 변환하는 과정마다 미세한 정보 손실이 생깁니다. 단계를 여러 번 거칠수록 누적됩니다. 워크플로우에서는 한 노드의 latent 출력을 다음 노드에 직접 넘겨 이 손실을 건너뜁니다.
예를 들어 이미지를 생성하고 바로 세밀한 부분을 인페인팅할 때, 워크플로우에서는 첫 생성의 latent 상태를 그대로 인페인팅 KSampler에 전달할 수 있습니다. 단계별 방식은 항상 렌더링된 이미지 파일을 다음 도구에 업로드해야 합니다.
3. 여러 LoRA 동시 적용과 강도 조절
LoRA는 기본 모델에 추가 학습을 적용하는 파일입니다. 캐릭터 스타일 LoRA, 조명 스타일 LoRA, 특정 포즈 LoRA를 동시에 올릴 수 있고, 각각의 영향력을 0.0~1.0 사이 수치로 독립적으로 지정합니다.
워크플로우 예시:
CheckpointLoader → LoRALoader(스타일, strength 0.6) → LoRALoader(캐릭터, strength 0.8) → LoRALoader(조명, strength 0.4) → CLIPTextEncode → KSampler
이 경우 스타일은 60%, 캐릭터 특징은 80%, 조명 방향은 40%의 강도로 혼합됩니다. 숫자 하나를 바꾸면 그 LoRA만 강하게 또는 약하게 적용되고, 나머지는 그대로입니다.
단계별 프롬프트 방식에서는 LoRA 강도 조절 UI가 없거나 단순히 켜고 끄는 정도만 지원하는 플랫폼이 많습니다. 세 가지 LoRA를 서로 다른 강도로 동시에 적용하는 것은 대부분의 플랫폼 UI에서 지원되지 않습니다.
4. ControlNet — 참조 이미지로 구조 정밀 제어
ControlNet은 참조 이미지에서 특정 정보를 추출해 이미지 생성의 조건으로 사용합니다. 워크플로우에서의 흐름은 이렇습니다.
참조 이미지 → 전처리 노드(포즈 추출 / 엣지 추출 / 깊이맵 추출) → ControlNetApply(conditioning strength 지정) → KSampler에 추가 조건으로 삽입
전처리 단계에서는 어떤 정보를 추출할지 선택합니다.
OpenPose — 사람의 관절 좌표(17개 포인트)만 추출. 새 이미지에서 정확히 같은 자세를 재현
Canny Edge — 이미지의 윤곽선만 추출. 같은 구도로 다른 스타일 생성
Depth Map — 원근감과 깊이 정보 추출. 3D 공간 구조를 유지하면서 외관을 교체
Lineart — 선화 추출. 웹툰 선화를 채색하거나 변형할 때 활용
그리고 conditioning strength(0.0~2.0)로 이 정보를 얼마나 강하게 반영할지 지정합니다. 1.0이면 구조를 강하게 따르고, 0.5면 느슨하게 참조합니다.
단계별 프롬프트 방식의 포즈 변환 기능(XBRUSH의 자세바꾸기 등)도 내부적으로 이 원리를 사용하지만, 어떤 전처리 알고리즘을 쓸지, conditioning strength를 얼마로 할지는 사용자에게 노출되지 않습니다. 워크플로우에서는 이 수치를 직접 실험하며 결과물의 자유도를 조절할 수 있습니다.
5. IP-Adapter — 이미지 스타일을 조건으로 삽입
IP-Adapter는 특정 이미지의 스타일, 색감, 얼굴 특징, 구도를 숫자 벡터로 인코딩해 이미지 생성의 조건으로 삽입하는 기술입니다. 텍스트 프롬프트로 설명하기 어려운 "이 그림체", "이 분위기"를 참조 이미지 한 장으로 전달합니다.
워크플로우에서:
참조 이미지 → IPAdapterEncoder → IPAdapterApply(weight 0.0~1.0 지정) → KSampler 조건에 합산
핵심은 weight 값입니다. 0.3이면 "이 스타일을 살짝 참조"가 되고, 0.9면 "이 이미지와 최대한 비슷하게"가 됩니다. 텍스트 프롬프트의 영향력과 IP-Adapter의 영향력 비율을 수치로 조절하면, "이 캐릭터 얼굴을 유지하면서 이 배경 스타일을 적용"처럼 두 조건을 혼합하는 섬세한 제어가 가능합니다.
단계별 프롬프트 방식에서 "참조 이미지" 기능을 제공하는 플랫폼도 있지만, 내부 weight 수치나 어떤 레이어에 적용할지는 선택할 수 없습니다.
6. 씨드(Seed) 관리와 XY Plot 탐색
씨드는 이미지 생성의 난수 출발점입니다. 같은 씨드 = 항상 동일한 결과. 다른 씨드 = 같은 프롬프트에서 다른 이미지.
워크플로우에서 씨드를 고정하면 변수를 하나씩 바꿔가며 순수한 A/B 비교가 가능합니다. "씨드 42423, CFG 7 vs CFG 12에서 결과물이 어떻게 달라지는가"를 정확하게 비교할 수 있습니다.
더 나아가 XY Plot 노드를 활용하면 파라미터 조합 전체를 한 번의 실행으로 렌더링합니다.
X축: CFG = 5, 7, 9, 12 / Y축: Steps = 20, 30, 40
→ 12개의 조합을 한 번에 생성해 최적 설정 탐색
단계별 프롬프트 방식에서는 씨드 고정 기능이 없는 플랫폼이 많고, 파라미터 조합 탐색은 수동 반복입니다. 12번을 일일이 실행하고, 각각 저장하고, 비교해야 합니다.
7. 중간 결과물의 분기와 재활용
워크플로우에서 하나의 노드 출력은 여러 노드로 동시에 연결할 수 있습니다.
예시 분기 구조:
이미지 생성 결과(latent)
├── 경로 A: VAEDecode → 업스케일 → 저장
├── 경로 B: VAEDecode → 배경 제거 → 저장
└── 경로 C: 인페인팅 KSampler → VAEDecode → 저장
하나의 이미지를 세 가지 방향으로 동시에 처리해 비교합니다. 실행 시간은 세 번이 아니라 공통 앞부분 1회 + 분기 이후만 3회입니다.
또 다른 활용: 특정 단계의 결과를 저장하면서 동시에 다른 파이프라인의 입력으로도 넘길 수 있습니다. 같은 캐릭터 이미지를 생성하고, 동시에 포즈 A 버전과 포즈 B 버전을 각각 ControlNet에 넘겨 두 버전을 한 번에 만드는 식입니다.
단계별 프롬프트 방식에서 세 방향으로 분기하려면 세 번 별도로 실행하고 파일을 각각 관리해야 합니다.
8. 커스텀 노드로 기능 무한 확장
ComfyUI는 Python 기반 커스텀 노드를 설치해 기능을 확장합니다. 커뮤니티가 개발한 커스텀 노드는 수백 개에 달합니다.
ReActor — 특정 얼굴을 다른 이미지의 얼굴로 교체
AnimateDiff — 스틸 이미지 생성 모델로 애니메이션 프레임 일괄 처리
WAS Node Suite — 이미지 전처리, 마스크 연산, 텍스트 처리 등 200여 가지 유틸리티
ComfyUI-VideoHelperSuite — 비디오 프레임 분리, 합성, 음향 처리
PromptQueue — 여러 프롬프트를 줄 세워 순차 자동 실행
단계별 프롬프트 방식에서는 플랫폼이 제공하는 도구 외에 추가할 수 없습니다. 플랫폼이 지원하지 않는 기능은 사용 자체가 불가능합니다.
장단점 비교
워크플로우의 장점
완전한 재현성 — JSON 파일 하나로 동일한 결과를 언제든 재현. 팀 내 공유도 파일 하나면 됩니다
정밀한 파라미터 제어 — 모든 수치를 직접 지정. 같은 모델로도 설정에 따라 완전히 다른 결과를 얻을 수 있습니다
자동화 — 버튼 하나로 전체 파이프라인 실행. 배치 처리, 반복 생성에 효율적입니다
커뮤니티 지식 활용 — Tensor.Art나 Civitai의 검증된 워크플로우를 그대로 가져다 쓸 수 있습니다
커스터마이징 무제한 — 원하는 노드를 추가하고 연결해 누구도 만든 적 없는 파이프라인을 구성할 수 있습니다
워크플로우의 단점
높은 학습 곡선 — ComfyUI의 노드 구조, 각 노드의 입출력 타입, CLIP/VAE/KSampler의 역할을 이해해야 합니다
오류 대응이 어렵다 — 14개 노드 중 어느 연결이 잘못됐는지 추적하기 까다롭습니다
중간 결과 확인이 불편하다 — 전체 파이프라인을 실행하기 전까지 중간 상태를 보기 어렵습니다
모델 의존성 — 워크플로우가 특정 모델 파일명을 하드코딩하고 있어, 다른 환경에서는 경로를 직접 수정해야 합니다
단계별 프롬프트의 장점
즉시 시작 가능 — 설치나 학습 없이 브라우저에서 바로 시작할 수 있습니다
시각적 피드백 — 각 단계의 결과를 눈으로 확인하면서 다음 단계를 결정합니다
유연한 방향 전환 — 중간 결과가 마음에 들지 않으면 언제든 다른 도구나 프롬프트로 전환할 수 있습니다
낮은 진입 장벽 — 기술적 배경 없이도 좋은 결과를 얻을 수 있습니다
단계별 프롬프트의 단점
낮은 재현성 — 같은 프롬프트를 다시 써도 동일한 결과가 보장되지 않습니다
반복 작업의 비효율 — 동일한 과정을 여러 이미지에 적용하려면 매번 수동으로 반복해야 합니다
파라미터 제어의 한계 — 플랫폼이 제공하는 UI 범위 내에서만 조정 가능합니다
실전에서 두 방식이 합쳐지는 방향
흥미로운 점은 두 방식이 점점 서로를 닮아간다는 것입니다.
OpenArt가 ComfyUI 워크플로우 갤러리에서 Suite 방식으로 전환한 것처럼, 플랫폼들은 노드 그래프의 복잡함을 숨기고 개별 도구 카드로 추상화하는 방향으로 가고 있습니다. XBRUSH의 편집 메뉴(배경 제거, 자세바꾸기, 인페인팅)나 동영상 생성 기능도 사용자가 직접 노드를 연결하지 않아도 동일한 파이프라인 효과를 얻을 수 있게 해줍니다.
반대로 단계별 프롬프트 사용자들도 자신만의 워크플로우를 문서화하기 시작합니다. "이미지 생성할 때 이 설정, 이 순서로 하면 좋더라"는 경험이 쌓이면 자연스럽게 재현 가능한 레시피가 됩니다.
Tensor.Art의 Canvas 기능입니다. "Boundless Creativity, Infinite Canvas"라는 슬로건처럼, 단순한 텍스트 입력창에서 모델과 비율을 선택해 이미지를 생성하는 방식으로 진입 장벽을 낮추면서, 내부적으로는 ComfyUI 기반 파이프라인이 동작합니다.
어떤 방식을 선택해야 하는가
목적에 따라 선택이 달라집니다.
워크플로우가 적합한 경우: 동일한 스타일로 많은 이미지를 반복 생성할 때, 팀과 정확한 설정을 공유해야 할 때, ControlNet·IP-Adapter·다중 LoRA처럼 정밀한 조건 제어가 필요할 때, 기술적 배경이 있고 학습에 시간을 투자할 수 있을 때.
단계별 프롬프트가 적합한 경우: 새로운 아이디어를 빠르게 탐색하고 싶을 때, 각 단계의 결과를 보면서 방향을 결정하고 싶을 때, 기술적 배경 없이 바로 시작하고 싶을 때, 소수의 결과물로도 충분할 때.
두 방식은 대립하지 않습니다. 단계별 프롬프트로 좋은 결과를 찾아내고, 그 과정을 워크플로우로 정리하는 흐름이 현실에서 가장 자연스럽습니다. 워크플로우는 단계별 프롬프트의 반복 실험이 쌓인 결과물이기도 합니다.