DIP: 추상화로 의존을 뒤집자!

“고수준 모듈이 저수준 모듈에 끌려다니지 않게 해라.”
― 의존 역전 원칙(Dependency Inversion Principle)

SOLID의 마지막 퍼즐, DIP는 “설계 방향을 아래에서 위로 뒤집는” 순간 코드를 한층 유연하게 만듭니다. 국내 인기 블로그에서도 스프링·안드로이드 예제로 꾸준히 조회 수를 올리는 이유가 바로 여기에 있죠.

---

1. DIP란 무엇인가?

• 정의:
  1. 고수준 모듈(비즈니스 규칙)은 저수준 모듈(구현 세부)과 직접 의존하지 않는다.
  2. 양쪽 모두 추상화(인터페이스·추상 클래스) 에 의존해야 한다.
  3. 추상화는 구체화에 의존해서는 안 된다.
• 한마디 요약: “구체가 아니라 계약에 기대라.”

---

2. DIP가 깨질 때 벌어지는 일

• 비즈니스 로직 락인: 구현 세부 변경이 배포 리스크로 직격탄.
• 테스트 지옥: 실 컨크리트 객체에 의존 → Mock 주입 불가.
• 레이어 꼬임: 서비스 계층이 DB·네트워크 코드와 얽히며 스파게티화.

---

3. Kotlin 예제로 보는 Before ↔ After

❌ Before — 구체 클래스 직접 의존

class EmailSender {
    fun send(msg: String) = println("Email: $msg")
}

class AlarmService {
    private val sender = EmailSender()   // 저수준 구현에 직접 의존

    fun alert() = sender.send("Warning!")
}

Email 대신 SMS가 필요해지면 AlarmService를 수정해야 합니다.

✅ After — 추상화로 뒤집기

interface MessageSender { fun send(msg: String) }

class EmailSender : MessageSender {
    override fun send(msg: String) = println("Email: $msg")
}

class SmsSender : MessageSender {
    override fun send(msg: String) = println("SMS: $msg")
}

class AlarmService(private val sender: MessageSender) {  // 추상화에 의존
    fun alert() = sender.send("Warning!")
}

이제 새 채널 = 새 클래스 추가로 끝! AlarmService 코드는 손대지 않습니다. blog.ramoo.net

---

4. 실무 적용 4-Step

1. 변화 축 파악: 로그, 알림, 결제처럼 자주 바뀌는 기능을 표시.
2. 역방향 의존성 주입: 스프링 @Configuration·Koin 모듈로 인터페이스 구현체를 주입.
3. 계약 테스트: 상위 모듈용 Contract Test로 추상화 규약을 고정.
4. 정적 분석 설정: SonarQube “High Coupling” 룰과 DI 컨테이너 의존성 그래프를 주기적으로 확인.

---

5. 오늘 바로 실행해 볼 것

• 서비스 클래스에서 new 키워드로 직접 생성하는 부분 찾기 → 인터페이스로 추상화.
• DI 설정 파일에 새 구현체를 등록해 주입 교체가 정말 되는지 테스트.
• PR 리뷰 체크리스트에 “추상화에 의존하는가?” 항목 추가.