"더 이상 존재하지 않는 변화 위에 얹힌 추상화는 유연함이 아니라 안 일어난 미래의 박물관이야. 지워. 그 미래가 진짜 오면 그때 다시 만들면 돼."
추상화를 쓸모없게 만든 방향 전환
초기에는 작업실이 생성을 여러 backend 로 보낼 수 있었어. 그래서 라우팅 enum 이 있었지. 가능한 backend 를 이름으로 다 늘어놓은 타입 말이야. 그때는 분별 있는 선택이었어. 그러다 엔진이 하나로 합쳐졌어. 엔진 하나가 모든 생성의 유일한 backend 가 된 거야. 하룻밤 사이에 그 라우팅 enum 이 값을 정확히 하나만 들게 됐어. backend 사이의 변화를 받아 내려고 만든 추상화인데 그 변화가 사라진 거지.
concrete-first 로 내린 결정
선택지가 둘이었어. 언젠가 두 번째 backend 가 돌아올지도 모르니 값 하나짜리 enum 을 '혹시 몰라' 남겨 두거나, 아니면 지우고 라우팅 로직을 직접 호출로 접어 버린 다음 진짜 두 번째 backend 가 실제로 도착할 때만 추상화를 다시 들이거나. 고른 건 지우는 쪽이었어. 값 하나짜리 enum, 한 군데로만 보내는 router, 더 이상 안 갈라지는 갈림길 위의 추상화. 전부 죽은 껍데기야. 뒤에 아무것도 없는 복잡함이지.
'혹시 몰라' 가 함정인 이유
값 하나짜리 enum 을 남겨 두는 게 신중해 보여. 두 번째 backend 가 돌아오면 어쩌려고? 그런데 '혹시 몰라' 추상화는 꾸준히 세금을 물려. 읽는 사람마다 한 군데로만 보내는 router 가 왜 있는지 이해해야 하고, 고칠 때마다 아무것도 안 하는 우회로를 지나야 하고, 새로 온 사람은 존재하지도 않는 다른 경우를 찾느라 시간을 버려. 값은 꾸준히, 모두한테, 영영 나가는데 이득은 영영 안 올지도 몰라. 나쁜 거래야.
깨끗하게 지어 놨으니 다시 만드는 게 싸
지우는 게 안전한 이유가 있어. 진짜 두 번째 backend 가 언젠가 도착하면, 라우팅 추상화를 다시 들이는 건 범위가 잡히고 잘 아는 일이야. 나머지 시스템이 깨끗한 seam 으로 지어져 있으니까(module 분리 규율 전체 말이야). 영영 필요 없을 거라는 데 거는 게 아니야. 필요해지면 다시 넣는 게 재작성이 아니라 끝이 보이는 일일 거라는 데 거는 거지. 깨끗한 아키텍처가 '지금 지우고 나중에 다시 넣기' 를 도박이 아니라 안전한 수로 만들어 줘.