"북극성은 기능이 아니야. 모든 결정을 대 보는 기준 하나야. 엔진한테는 그게 module 분리고."
북극성이 뭐냐면
아키텍처 결정은 대개 국지적이야. 이 함수, 저 스키마, 여기 경계. 북극성은 그 국지적인 결정들이 전부 향해야 하는 하나의 기준이고. 엔진한테 그 기준은 module 분리야. VAE, text encoder, backbone, sampler, conditioning 을 깨끗한 인터페이스를 가진 독립 단위로 유지하는 것. 붙여 놓는 게 조금 더 빠르거나 코드가 조금 줄어드는 순간에도 그렇게 해.
왜 하필 이거냐면
엔진은 속도나 코드 최소화나 의존성 최소화를 북극성으로 삼을 수도 있었어. 분리를 고른 건 그게 엔진을 앞으로 올 시간에서 살아남게 해 주기 때문이야. 새 모델 계열은 '언젠가 오면' 이 아니야. 몇 달에 한 번씩 와. 속도를 별로 삼으면 지금은 최적이지만 계열이 바뀔 때마다 다시 써야 해. 분리를 별로 삼으면 작은 세금을 계속 내는 대신 새 계열을 매번 범위가 잡힌 일로 받아들이고. 네 분야를 정의하는 성질이 끊임없는 변화라면, 별로 삼을 건 적응력이야.
모든 결정이 통과해야 하는 시험
북극성이 있으면 어떤 변경 제안에든 던질 질문이 하나 생겨. 이게 모듈을 떼어 낼 수 있는 상태로 두나, 아니면 붙여 놓나? 모듈 둘 사이로 손을 뻗어 서로 묶어 버리는 똑똑한 최적화는 이 시험에서 떨어져. 더 빠르더라도. 모듈 사이 인터페이스를 더 또렷하게 만드는 리팩터는 통과하고. 코드가 몇 줄 늘더라도. 별 하나가 천 번의 판단을 반복되는 점검 하나로 줄여 줘.
별이 값을 물릴 때
module 분리는 공짜가 아니야. sampler 랑 backbone 사이에 깨끗한 인터페이스가 있다는 건, 빨리 이기려고 sampler 에서 backbone 속으로 손을 뻗을 수 없다는 뜻이거든. 가끔은 둘을 붙이는 게 정말로 더 빠를 거야. 그래도 그 값을 일부러 치르는 게 규율이야. 안 그러면 뭐가 되냐면, FLUX 다음 게 나오는 날 다시 써야 하는 빠르고 딱 붙은 엔진이 되거든. 이 프로젝트가 통째로 빠져나오려고 존재하는 게 바로 그 구석이야.