"부품은 빌려. framework 는 거절해. 그 차이가 네 API 를 영영 누가 갖는지를 정해."
같은 라이브러리를 쓰는 두 가지 방식
Hugging Face 의 diffusers 는 diffusion 모델 쪽의 표준 연장통이야. 엔진은 여기에 깊게 기대. 그러면서 대부분을 거절하기도 하고. 모순이 아니라 규율이야. diffusers 는 부품 창고로 쓸 수도 있고(컴포넌트만 빌려서 직접 조립) framework 로 쓸 수도 있어(파이프라인 클래스가 네 구조를 지시하게). 엔진은 앞쪽만 하고 뒤쪽은 금지해.
빌려 오는 것 (부품)
diffusers 는 훌륭한 저수준 조각들을 내놓고, 엔진은 이것들을 자유롭게 써.
- 로더 — safetensors 파일 읽고 tensor 를 올려 주는 것들.
- 모듈 클래스 — 직접 인스턴스로 만들 수 있는 VAE, U-Net, DiT, MMDiT 구현.
- scheduler 구현 — Euler, DPM++, DDIM, flow-match. 이미 제대로 돼 있어.
- attention 커널 — 다시 짜고 싶지 않은 최적화된 것들.
이것들이 부품이야. 하는 일이 좁고 혼자 설 수 있는 컴포넌트. 집어 들어서 네 인터페이스 뒤에 두고, 엔진은 네 방식대로 조립해.
거절하는 것 (framework)
diffusers 는 파이프라인 클래스도 내놔. 전부 알아서 엮어 주고 호출 한 번으로 생성까지 해 주는 SomePipeline.from_pretrained(...) 같은 것들. 편해. 그리고 framework 이기도 하고. 파이프라인 클래스마다 나름의 고집이 있어. 동기냐 비동기냐, 에러를 어떻게 다루냐, kwarg 를 어떤 식으로 받냐, conditioning 을 어떤 관례로 붙이냐, 캐시를 어디 두냐. 그중 하나를 네 API 로 내보내는 순간 그 고집을 전부 네 공개 약속으로 받아들인 거야.
이 구분이 왜 그렇게 큰 문제냐면
함정을 구체적으로 보자. route 가 diffusers 파이프라인이 돌려준 걸 그대로 돌려주면, 클라이언트 전부가 — 작업실도, 뇌도, 앞으로 생길 도구들도 — diffusers 의 출력 모양에 묶여. diffusers 가 그 모양을 바꾸는 날, 혹은 모델 하나를 다른 backend 로 갈아 끼우고 싶은 날, 클라이언트가 전부 깨져. diffusers 에 의존한 게 아니라 결혼한 거고, 클라이언트를 전부 사돈으로 만든 거야. 부품을 네 인터페이스로 감싸 두면 이혼할 길이 늘 열려 있어.
덤으로 딸려 오는 것
이 규율에는 보너스가 있어. 새 모델 계열이 나오면 diffusers 가 대개 며칠 안에 파이프라인 클래스를 추가하거든. 그 파이프라인을 내보내지는 않아. 대신 새 backbone 을 어떻게 엮는지 보여 주는 참고 구현으로 읽어. 그러고 네 인터페이스 뒤에 네 모듈을 짓는 거야. diffusers 가 살아 있는 문서가 되는 거지. 새 고집은 안 물려받으면서 새 배선만 배우는 제일 빠른 길이야.