"ComfyUI 가 어떤 모델이든 흡수하게 만드는 그것이, 매일 쓰기 진 빠지게 만드는 그것이랑 같아."
천장이 없는 툴
monolith 의 문제가 하드코딩된 모양이면, 뻔한 해법은 하드코딩된 모양이 없는 툴이야. 그 툴은 존재해: 모든 단계 — 모델 로드, 텍스트 인코딩, sampling, 디코딩 — 가 네가 엮는 별도 노드인 node-graph 이미지 생성기. 새 모델 family? 새 노드 타입 하나 추가. 내부가 너무 모듈화돼서 구워 넣은 게 없어. 천장이 사라졌어.
왜 모듈성이 node graph 에 사는지
node-graph 툴이 어떤 모델이든 흡수할 수 있는 이유는 내부가 진짜로 분리됐기 때문이야: VAE, text encoder, backbone, sampler, conditioning 이 깨끗한 인터페이스를 가진 독립 단위야. node graph 는 그 분리를 눈에 보이게 만든 것뿐이야 — 화면의 각 박스가 그 모듈 단위 중 하나야. 이게 Ember 가 훔치는 핵심 통찰이고, 다음 트랙 전체가 이것에 대한 거야.
비용: 그래프는 매일의 surface 가 아니야
여기 trade-off 가 있어. node-graph 툴에서 이미지 하나 생성하려면, 그래프를 조립해(또는 로드하거나 손봐): 이 노드가 저 노드를 먹이고, 이 파라미터 여기 설정하고, 저 edge 거기 다시 엮고. 커스텀 워크플로를 짓는 power user 한텐 그 통제가 선물이야. 그냥 그리다가 가끔 "이 영역 다듬어" 하고 싶은 사람한텐, 모든 생성마다의 마찰이야. 유연함이랑 매일-쓰기 비용이 같은 기능이야.
거짓 선택
그래서 풍경이 거짓 선택을 줘: 천장 낮은 단순한 툴, 또는 매일의 surface 가 무거운 무제한 툴. 대부분 하나 고르고 단점을 안고 살아. forcing function 은 그럴 필요 없다는 걸 깨닫는 거야 — (유연한 툴의) 모듈화된 내부랑 (편한 툴의) 단순한 surface 가 분리 가능하고, 각각 하나씩 가져오는 걸 막는 게 없다는 걸.
Ember 가 각각에서 가져오는 것
Ember 의 설계는 둘 다에서의 노골적인 절도야: node-graph 툴한테 무제한 천장을 주는 깊은 module 분리를 가져오고, monolith 가 하는 식으로 그 위에 단순한 recipe 기반 API 를 얹어 — monolith 의 하드코딩된 모양은 빼고. 밖은 단순, 안은 모듈화. node graph 는 자기가 온 toolbox 에 남고.