concrete-first, 예측해서 일반화 안 해

"눈앞의 진짜 것을 지어. 추상은 두 번째 진짜 사례가 공통 자리를 요구할 때 뽑아."

지금까지 걸어온 척추

이 퀘스트의 여러 트랙에서 규칙 하나가 조용히 중요한 결정을 맡아 왔어. 이제 이름을 붙여 보자. concrete-first, 미리 일반화하지 않기. 눈앞의 구체적이고 진짜인 사례부터 지어. 일반적이고 유연해서 앞으로도 버틸 버전은 두 번째 구체 사례가 실제 공통점을 보여주기 전에는 만들지 않아. 미리 만든 일반성은 미래에 대한 추측이고, 틀리면 복잡성만 남겨.

여러 결정에서 같은 모양이 보여

이 퀘스트에서 concrete-first가 나타난 곳:
  Track 4  엔진과 첫 UI의 vertical slice로 API 계약 검증
  Track 5  MIR 구현을 parts로 감싸고 제품 계약은 직접 소유
  Track 7  실제 playback 문제에 필요한 web 경계부터 검증
  Track 8  v1의 구체 범위를 먼저 끝내고 추측성 기능은 보류

서로 다른 결정이지만 원칙은 하나야. 매번 유혹은 일반 버전을 미리 만드는 것이었어. 미래의 모든 클라이언트를 위한 API, 특정 MIR framework, 아직 필요가 확인되지 않은 배포 추상, 기능을 빠짐없이 채운 v1이 그럴듯해 보였지. 하지만 구체적인 사용 흐름을 먼저 증명하고, 일반성은 실제 두 번째 사례가 올 때까지 기다리는 편이 더 정직해.

필요해질 때 추상화해

긍정형으로 말하면 '필요해질 때 추상화하라'야. 추상을 미리 짓지 말고 구체적인 것을 제대로 지어. 같은 구조를 실제로 공유하는 두 번째 사례가 나타나면 그때 눈앞의 사례 둘에서 공통점을 뽑아. 여기서 하는 일은 특수화가 아니라 추상화야. 진짜 사례에서 뽑은 추상도 틀릴 수 있으니 세 번째 사례와 변경 비용으로 계속 검증해야 해. concrete-first는 추상을 금지하는 교리가 아니라, 추상에 증거를 요구하는 규율이야.

Code

규칙 하나, 여러 얼굴, 퀘스트 전반·text

이 퀘스트에서 concrete-first가 나타난 곳:
  Track 4  엔진 + 첫 UI의 vertical slice로 API 계약 검증
  Track 5  MIR 구현은 adapter 뒤에 두고 제품 계약을 소유
  Track 7  실제 playback 문제에 필요한 web 경계부터 검증
  Track 8  v1의 구체 범위부터 끝내고 추측성 기능은 보류

# 필요할 때 추상화해.
# 두 번째 실제 사례에서 공통점을 뽑고, 세 번째로 검증해.

Exercise

코드에서 실제 소비자가 하나뿐인 추상 하나를 찾아. 진짜 반복에서 뽑았는지, 오지 않은 두 번째 사례를 예측해 만든 건지 확인해. 두 번째 사례가 있다면 공통점과 차이를 적고, 세 번째 사례가 왔을 때 지금 추상이 버틸지도 시험해 봐.

Hint

소비자가 하나인 추상은 아직 검증되지 않은 추측일 수 있어. 그렇다고 무조건 인라인할 필요도 없어. 제거 비용, 변경 빈도, 경계가 주는 테스트 가치까지 보고 판단해.