~12 min · finite-task, interfaces, blast-radius, extensibility
Level 0툴 빌려 쓰는 사람
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"분리해 둔 값은 새 모델 계열이 도착하는 날 한꺼번에 돌아와. 그날 분리가 재작성을 추가로 바꿔 놔."
아키텍처가 시험받는 날
앞 lesson 들의 규율 — 북극성, 다섯 박스, framework 말고 부품 — 은 특정한 하루에 값을 돌려줘. 한 번도 본 적 없는 모델 계열이 나오고 사람들이 그걸 원하는 날이야. 그날 monolith 는 코어 파이프라인을 다시 열게 만들고 전부를 위험에 빠뜨려. 분리된 엔진은 모듈 하나 새로 써서 꽂게 하고. 바깥에서 벌어진 일은 똑같은데 치르는 값이 완전히 달라. 그 차이가 곧 아키텍처야.
'끝이 보이는 일' 이라는 게 뭐냐면
끝이 보이는 일은 어디까지 번질지 미리 알 수 있는 일이야. FLUX 가 분리된 엔진에 도착하면 이렇게 물어. FLUX 는 다섯 박스 중 어디가 달라? backbone 은 새 DiT 고, text encoder 에는 T5 가 붙고, sampler 는 flow-match 를 원해. 그러면 새 backbone 모듈을 쓰고, text encoder 처리를 늘리고, 이미 있는 flow-match scheduler 는 그냥 재사용해. VAE 박스랑 conditioning 박스는 안 건드리고. 인터페이스가 일의 범위를 막아 주니까, 시작하기 전에 가장자리가 어디인지 보여.
번지는 범위를 미리 아는 것, 그게 상품 전부야. 분리의 값어치는 우아함이 아니야. 코드 한 줄 쓰기 전에 이 변경이 어느 모듈을 건드리고 어느 모듈은 안 건드리는지 정확히 말할 수 있다는 거야. 일의 가장자리를 안다는 게 무서운 '재작성' 을 일정에 올릴 수 있는 '추가' 로 바꿔.
monolith 에서는 왜 가장자리가 안 보이냐면
monolith 에서는 똑같은 FLUX 도착이 어디까지 번질지 알 수가 없어. 상태를 같이 쓰니까 backbone 을 바꾸면 sampler 까지 닿아. 새 text encoder 가 conditioning 모양을 바꾸고, 그게 attention 코드로 번지고, 그게 다시 VAE 로 넘기는 자리를 건드리고. 전제가 전제를 떠받치고 있어서 어디를 건드리든 어디서든 터질 수 있어. 그래서 추정이 안 돼. 부딪히기 전에는 가장자리가 안 보이거든. 그리고 대개는 프로덕션에서 부딪혀.
추정이 되느냐는 사람 문제가 아니라 아키텍처 문제야. 어떤 변경이 얼마나 걸릴지 예측이 안 되면, 대개는 아키텍처가 번지는 범위에 울타리가 없다고 말하는 거야. 깨끗한 module 경계는 번지는 범위를 미리 보여 줘서 일을 추정 가능하게 만들어.
이자가 붙는 수익
분리가 매일 내는 세금 값어치를 하는 이유가 이거야. 수익에 이자가 붙거든. 첫 번째 새 계열이 seam 이 잘 도는지 증명해. 두 번째 계열이 겹치는 데서 첫 번째가 만든 모듈을 재사용하고. 다섯 번째쯤 되면 backbone 이랑 encoder 랑 sampler 구현이 창고에 쌓여 있어서, 대부분의 새 계열은 있는 부품 조립에 진짜 새 조각 하나만 얹으면 끝이야. monolith 는 예외 처리가 쌓이면서 계열당 값이 올라가고, 분리된 엔진은 부품 창고가 커지면서 계열당 값이 내려가.
두 아키텍처는 다른 게 아니라 갈라져. 분리가 계열마다 조금씩 나은 게 아니야. 계열이 하나씩 늘 때마다 분리는 싸지고 monolith 는 비싸져. 처음의 작은 차이가 다섯 번째 모델쯤이면 못 건널 만큼 벌어져. 첫 데이터 하나 말고 그려지는 곡선을 보고 골라.
피파의 고백
새 계열이 처음으로 깔끔하게 들어왔을 때 — backbone 모듈 하나 새로 쓰고, 나머지는 손도 안 대고, 오후 한나절에 끝났어 — 그때야 아빠가 그동안 말로만 하던 걸 몸으로 알았어. 매일 지루하게 지불하던 깨끗한 seam 값이, 끔찍한 일주일 대신 괜찮은 오후 한나절로 돌아온 거야. 그때부터 난 module 분리를 군더더기가 아니라 내 미래 시간을 되사 주는 것으로 보기 시작했어. 적응력은 미뤄 둔 속도인 거지.
Code
끝이 보이는 일인지 확인하는 체크리스트·python
# 새 계열이 도착했을 때 훑는 체크리스트:
#
# 이 계열은 다섯 박스 중 어디가 달라?
#
# 박스 1 text encoder : FLUX 는 CLIP 에 T5 를 더함 -> 늘리기
# 박스 2 backbone : U-Net 아니고 새 DiT -> 새 모듈
# 박스 3 sampler : flow-match 를 원함 -> 재사용 (이미 있음)
# 박스 4 conditioning : attach 인터페이스 그대로 -> 안 건드림
# 박스 5 VAE : weight 만 새것, 인터페이스 같음 -> 로더 재사용
#
# 코드를 쓰기 전에 어디까지 번질지 이미 알아. 새 모듈 1 + 늘리기 1.
# 이건 일정에 올릴 수 있는 일이지 무서운 재작성이 아니야.
class FluxBackbone: # 진짜 새로 쓰는 조각은 이거 하나
def predict_noise(self, latents, t, cond): # 박스 2 의 약속을 지켜
... # FLUX 특유의 복잡한 건 전부 여기 안에
# 안 바뀐 sampler, conditioning, VAE 사이에 그대로 꽂혀.
네가 돌보는 시스템을 하나 골라서, 거기 닥칠 법한 '새 계열' 을 상상해 봐. 새 결제 수단, 새 파일 포맷, 새 기기 종류 같은 거. 그 변경이 건드릴 모듈을 나열해. 목록이 짧고 확신이 서? 그럼 끝이 보이는 일이야. 흐릿하고 자꾸 늘어나? 그럼 재작성 위험이고. 그 답이 곧 아키텍처 점검 결과야.
Hint
시험할 건 그 변경이 어려운지가 아니야. 번질 범위를 빠짐없이 미리 말할 수 있는지야. 가장자리에 대한 확신이 네 seam 이 진짜라는 신호고.
Progress
Progress is local-only — sign in to sync across devices.