"seam 은 지금 그려. 구현은 나중에 그 사이로 통과시키고. 인터페이스로 자리를 잡아 두는 게, 미리 다 짓지 않고도 열어 두는 방법이야."
언젠가 필요해질 것들의 지도
엔진을 직접 갖기로 하면 위험한 질문이 따라와. 얼마나 짓지? 상상되는 걸 다 지으면 출시도 못 해 보고 가라앉아. 오늘 필요한 것만 지으면 스스로를 가두고. ceiling matrix 는 그 질문에 답하는 도구야. 엔진한테 언젠가 필요할 수 있는 능력을 격자에 다 늘어놓고, 하나하나에 세 상태 중 하나를 붙이는 거지.
축은 둘
matrix 에는 축이 두 개 있어. 하나는 modality, 이미지냐 비디오냐. 다른 하나는 weight 가 어디 있냐, 네가 직접 돌리는 local open weight 냐 네트워크로 부르는 closed-weight API 냐. 그러면 칸이 넷 나와. local 이미지, local 비디오, API 이미지, API 비디오. 각 칸이 상태를 하나씩 받아.
'인터페이스로 잡아 둠' 이 핵심 수야
제일 중요한 건 가운데 상태야. local 이미지 생성은 구현돼 있어. local 비디오는 아니고. 그런데 요청 스키마에는 이미 video 라고 적을 수 있는 modality 자리가 있어. seam 이 있는 거지. 나중에 비디오 작업 흐름이 진짜로 구현을 요구하면, 이미 쓰고 있던 호출자를 하나도 안 깨고 그 seam 사이로 지어 넣으면 돼. 문은 지금 그려 놓고 통과는 나중에 하는 거야.
modality: image | video 를 넣는 건 거의 공짜인데 백째 날의 API 파손을 막아 줘. 첫날 비디오 파이프라인을 짓는 건 엄청 비싸고, 정작 필요해질 때쯤엔 틀린 설계일 수도 있고. 자리는 싸게 잡고, 짓기는 늦게 해.이게 그냥 YAGNI 는 아닌 이유
"어차피 안 쓸 거야(YAGNI)" 는 투기적인 기능을 짓지 말라고 말해. 맞는 말이야. 그런데 곧이곧대로만 적용하면 그 기능들이 들어갈 자리도 남기지 말라는 말이 돼. 그러면 정말로 필요해지는 날 모든 클라이언트로 번지는 파손으로 값을 치르게 되지. ceiling matrix 는 그 사이를 지나가. 투기적인 기능은 안 짓고(YAGNI 는 지키고), 그 인터페이스 seam 만 잡아 둬(그래서 나중에 짓는 게 파손이 아니라 추가가 되고). 싼 seam 에 미뤄 둔 구현.
범위 밖에는 이유가 붙어야 해
세 번째 상태도 똑같이 엄격해. 어떤 능력은 일부러 빠져. 그리고 matrix 는 뺐다가 아니라 왜 뺐는지를 적어. training 도구는 엔진이 inference 전용이라서 범위 밖이야. face-swap 기능은 그것대로의 이유로 범위 밖이고. 이유를 적어 두면 나중의 너나 다른 기여자가 그 결정을 맨바닥부터 다시 다투지 않아. '범위 밖' 을 '까먹은 것' 으로 오해하지도 않고.