추상화는 자유를 주지만, 과하면 방향 감각을 잃는다

이 문장을 설계 원칙으로 번역하면

• 추상화 = 변경 자유도 확보
• 과한 추상화 = 인지 부하 + 디버깅 불능 + 책임 소재 붕괴

“좋은 추상화”와 “과한 추상화”의 경계

좋은 추상화의 신호

• 변경 이유가 명확함 (DB 교체, 외부 연동 교체, 정책 변경 등)
• 인터페이스가 짧음 (메서드 수·개념 수가 적다)
• 한 방향으로만 의존 (상위 정책 → 하위 구현)
• 삭제해도 아프지 않음 (나중에 걷어낼 수 있다)

과한 추상화의 신호

• 아직 바뀐 적 없는 미래를 대비함
• 이름은 그럴듯한데 실제 책임이 모호함
  (ex. CommonService, AbstractManager, BaseHandler)
• 추상 계층을 3번 이상 타야 흐름이 보임
• 디버깅 시 브레이크포인트가 추상층에만 걸림
• 문서 없이는 코드를 읽을 수 없음

실무에서 쓰는 판단 기준 5문장

아래 중 **2개 이상 “예”**면 추상화 과다입니다.

1. 이 인터페이스를 제거해도 당장 깨지는 사용처가 1곳뿐인가?
2. 구현체가 현재 1개뿐이고, 교체 일정도 없는가?
3. 실제 버그의 원인이 구현이 아니라 추상 계약에 있는가?
4. 신규 인력이 실행 경로를 머릿속에서 그릴 수 없는가?
5. 로그 없이 스택트레이스만 봐서는 무슨 일이 일어났는지 모르는가?

현장에서 통하는 원칙

• 추상화는 “경험된 변화” 뒤에 만든다
• 추상화는 보호막이지 장식이 아니다
• 모든 인터페이스는 언젠가 지울 각오로 만든다
• 읽기 비용이 쓰기 비용보다 싸야 한다

한 줄 리프레이즈

• “추상화는 자유를 주지만, 지도 없는 자유는 길을 잃게 한다.”
• “변경을 막기 위해 만든 추상화가 이해를 막으면 실패다.”