"자기 모양을 하드코딩한 파이프라인은 이미 아는 모양만 생성할 수 있어."
안 될 때까지 잘 됐던 툴
수년간, 자기 머신에서 open-weight 이미지 모델을 돌리는 편한 방법은 monolithic 웹 UI 였어 — 가장 인기 있는 건 생성 전체를 하나의 처리 함수에서 조립해. 모델 고르고, 프롬프트 치고, generate 누르면, 긴 파이프라인이 끝에서 끝까지 돌아. 진짜 좋은 소프트웨어야. 그리고 transformer 시대가 곧장 걸어 들어간 구조적 천장이 있어.
'monolithic 파이프라인' 이 실제로 뜻하는 것
고전 파이프라인은 세 가지 가정을 한 함수에 구워 넣어: backbone 은 U-Net, text encoder 는 CLIP, sampler 는 고정 family(Euler, DPM++, DDIM)에서 나와. SD1.5 / SDXL 시대엔 그 가정들이 모든 모델에 참이라, 구워 넣는 게 비용 0 에 속도를 사줬어. 모양이 하나뿐이라 파이프라인이 그 모양을 알았던 거야.
transformer 시대가 모든 가정을 위반해
그러더니 transformer 기반 이미지 모델이 도착했어 — SD3, FLUX, PixArt, Hunyuan-DiT, AuraFlow — 그리고 세 가정을 한꺼번에 깼어:
- backbone 이 더 이상 U-Net 이 아니야. DiT 나 MMDiT(diffusion transformer)야.
- text encoder 가 더 이상 CLIP 만이 아니야. FLUX 는 CLIP 을 T5-XXL encoder 랑 짝지어; conditioning 모양이 바뀌어.
- sampler 가 더 이상 옛 family 가 아니야. flow-matching 모델은 flow-match scheduler 를 원해.
U-Net + CLIP + Euler 를 하드코딩한 파이프라인엔 이 중 어느 것을 위한 슬롯도 없어. fork 해서 모델 하나를 패치할 순 있어도, 다음 family 가 네 패치를 깨. monolith 는 변형은 흡수해도 — 새 종류는 못 흡수해.
fork 가 왜 너를 못 구해
커뮤니티 fork 들이 transformer 모델을 monolithic UI 에 패치하긴 해, 작동도 하고 — 누군가 패치한 특정 모델에 한해서. 근데 각 패치는 여전히 근본적으로 옛 모양을 가정하는 파이프라인에 볼트로 조인 특수 케이스야. 아키텍처가 패치랑 싸워. 모델 family 다섯 개 뒤면, 특수 케이스 다섯 개랑 아무도 완전히 이해 못 하는 파이프라인이 남아. 증상을 패치하는 건 천장을 안 옮겨 — 그냥 비계 뒤에 숨길 뿐이야.
교훈은 이미지 모델보다 커
이게 forcing function 의 일반적인 모양이야: 툴이 자기 세계 전체에 참이던 가정을 encode 하고, 세계가 바뀌고, 가정이 천장이 돼. 정직한 대응은 더 세게 패치하는 게 아니야. 어떤 아키텍처가 구워 넣은 모양이 없을지 묻는 거야 — 그게 정확히 다음 트랙 주제고.