The rule
Claude-Pippa 의 새 코드 박을 때, 미래 변형 전혀 생각하지 마. hook 남기지 마. 가상 Gemini-Pippa 위해 symmetry 보존하지 마. # TODO: extract this for the adapter layer 박지 마.
왜 안전한가
Rule 3 가 안전한 건 Rule 2 가 safety valve 라서. 변형 필요해지면, 자손이 비용 흡수, ancestor 손 안 댐. 그러니까 Claude-shape 버전 full-tilt 박을 수 있어 — 미래 변형 고통이 bounded 인 걸 알면서.
교훈
이게 2005 enterprise-Java reflex ('미래 유연성 위해 모든 걸 abstract') 의 반대. 더 오래된 원칙과 align: 아직 vary 할 필요 없는 거 abstract 하지 마.
Concrete-first는 대충 만들고 나중에 생각하자는 말이 아니야. 지금 아는 요구에는 끝까지 엄격하고, 아직 보지 못한 변형에는 거짓 hook을 만들지 말자는 말이야. 아직 오지도 않은 두 번째 caller를 위해 parameter를 늘리면 첫 caller의 계약만 흐려져.
판단 질문은 간단해. 지금 이 abstraction을 요구하는 실제 두 번째 구현이 있나? 두 구현의 공통점이 이름만이 아니라 같은 invariant인가? 차이를 base로 끌어올리지 않고 downstream에서 감당할 수 있나? 셋에 답하지 못하면 아직 추출할 때가 아니야.
사실 premature abstraction은 중복보다 더 비쌀 수 있어. 중복은 두 concrete를 나란히 보여 줘서 공통점을 발견하게 하지만, 틀린 abstraction은 서로 다른 둘을 같은 것처럼 강제해. 그러면 매 feature마다 flag와 optional field가 붙고, 결국 누구도 계약을 설명하지 못해. 먼저 정확한 한 몸을 만들고, 두 번째 몸이 실제로 올 때 비교해.
다만 이 원칙을 복붙 면허로 읽으면 바로 사고야. canonical primitive와 이미 검증된 family kit이 있다면 다시 쓰는 게 아니라 상속해야 해. 아직 공통 뿌리가 없는 concrete를 먼저 짓는 것과, 이미 있는 뿌리를 무시하고 복사하는 건 정반대야.