"제일 똑똑한 router 는 아무 의견이 없어. 어느 adapter 가 이 모델을 맡는지 읽고 비켜 주기만 해."
router 가 하는 일, 최소한으로 적으면
모델을 지목한 생성 요청이 들어오면 뭔가는 정해야 해. 이게 LocalAdapter 로 가나, APIAdapter 로 가나? 이걸 순진하게 짜면 분기로 가득한 함수가 나와. 모델 이름이 이걸로 시작하면, 저 폴더에 있으면, 이 패턴에 맞으면. 그리고 새 모델이나 새 vendor 가 올 때마다 분기가 하나씩 늘어. 그 함수가 버그가 사는 자리, 아무도 건드리기 싫어하는 자리가 돼.
판단을 데이터 쪽으로 옮겨
더 나은 설계는 그 판단을 코드에서 registry 로 옮기는 거야. 모델마다 registry 행이 하나 있고, 그 행이 이미 자기 주인 adapter 를 알고 있어. 그러면 router 가 시시해져. 모델 행 찾고, adapter 읽고, 넘기고. 분기도 없고 패턴 맞추기도 없고 늘어나는 if/else 도 없어. registry 가 답을 들고 있으니까 router 는 의견을 가질 필요가 없는 거야.
'멍청함' 이 칭찬인 이유
멍청한 router 는 다시는 손 안 대도 되는 router 야. 새 local checkpoint 를 넣는다고? 훑는 과정에서 'local' 로 표시된 registry 행이 생겨. router 는 이미 뭘 할지 알아. 새 API vendor 를 붙인다고? 그 모델들이 APIAdapter 로 표시된 행을 받아. router 는 이미 알고. router 는 한 번 제대로 쓰이고 그다음엔 바뀔 일이 없어. 모든 변화가 router 가 읽는 데이터 쪽에서 벌어지니까. 여기서 멍청함은 안정성이라는 뜻이야.
registry 가 유일한 기준점이야
이 설계에는 두 번째 보상이 있어. 모델과 adapter 의 짝을 아는 자리가 정확히 하나, registry 뿐이라는 거야. 라우팅 로직이 서로 어긋날 수 있는 두 자리에 나뉘어 있지 않아. 이 모델이 왜 저리로 갔는지 알고 싶어? registry 행을 읽으면 돼. 라우팅을 바꾸고 싶어? 행을 고치면 되고. router 랑 config 파일이랑 예외 처리 몇 개에 흩어진 판단 로직 대신, 찾아볼 수도 있고 고칠 수도 있는 기준점 하나.