"자기 모양을 코드에 박아 넣은 파이프라인은 이미 아는 모양만 만들어 낼 수 있어."
안 될 때까지는 잘 되던 툴
몇 년 동안, 자기 머신에서 open-weight 이미지 모델을 돌리는 제일 편한 방법은 monolithic 웹 UI 였어. 그중 제일 많이 쓰이는 건 생성 전체를 처리 함수 하나에 다 엮어 놨고. 모델 고르고 프롬프트 치고 generate 누르면 긴 파이프라인이 처음부터 끝까지 한 번에 돌아. 진짜 잘 만든 소프트웨어야. 그리고 transformer 시대가 그대로 걸어 들어간 구조적 천장이 하나 있어.
'monolithic 파이프라인' 이 실제로 뜻하는 것
옛날 파이프라인은 함수 하나에 전제 세 개를 구워 넣었어. backbone 은 U-Net, text encoder 는 CLIP, sampler 는 정해진 몇 개(Euler, DPM++, DDIM) 중 하나. SD1.5 랑 SDXL 시대에는 이 전제가 모든 모델한테 참이었어. 그러니까 박아 넣는 게 공짜로 속도를 벌어 줬지. 모양이 하나뿐이니까 파이프라인이 그 모양을 알고 있어도 됐던 거야.
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 도 옛날 것들이 아니고. flow-matching 모델은 flow-match scheduler 를 원해.
U-Net 이랑 CLIP 이랑 Euler 를 박아 놓은 파이프라인에는 이 셋 중 뭘 넣을 자리도 없어. fork 떠서 모델 하나쯤 패치할 수는 있어. 그런데 다음 계열이 나오면 그 패치가 또 깨져. monolith 는 변종은 받아들여도 새로운 종류는 못 받아들여.
fork 로는 안 되는 이유
커뮤니티 fork 들이 transformer 모델을 monolithic UI 에 패치해 넣기는 해. 돌아가기도 하고. 단, 누군가 패치해 준 그 모델에 한해서야. 그리고 그 패치 하나하나는 여전히 옛날 모양을 전제한 파이프라인에 볼트로 조여 붙인 예외 처리야. 아키텍처가 패치랑 싸우는 거지. 모델 계열 다섯 개쯤 지나면 예외 처리 다섯 개랑 아무도 통째로는 이해 못 하는 파이프라인이 남아. 증상만 패치하는 건 천장을 안 올려 줘. 비계로 가려 놓을 뿐이야.
교훈은 이미지 모델보다 커
이게 forcing function 의 일반적인 모양이야. 툴이 자기 세계 전체에 참이던 전제를 코드에 새겨 넣는다. 그러다 세계가 바뀐다. 그 전제가 천장이 된다. 이때 정직한 대응은 더 세게 패치하는 게 아니야. 아예 박아 넣은 모양이 없는 아키텍처는 어떤 모양일지 물어보는 거지. 다음 트랙이 바로 그 얘기야.