Interface, DIP, IoC 에 대한 비유

 

 

사진: Unsplash의Med Badr Chemmaoui

개요

Interface, DIP, IoC 에 대한 이해를 돕는 비유를 해보려 한다.

한 줄 정의

• 인터페이스(Interface): 객체 간의 상호 작용을 정의하는 추상 타입으로, 구현 세부 사항을 숨기고 공통 동작을 명세한다.
• DIP(Dependency Inversion Principle): 고수준 모듈이 저수준 모듈에 의존하지 않고, 둘 다 추상화에 의존하도록 하는 설계 원칙이다.
• IoC(Inversion of Control): 객체의 생성과 의존성 주입을 외부 컨테이너나 프레임워크에 맡겨서 객체의 제어 흐름을 반전시키는 패턴이다.

인터페이스(Interface)

인터페이스는 채용 공고의 직무기술서(JD, Job Description)에 비유할 수 있다.

회사는 “Golang 백엔드 개발자”를 찾는다고 채용공고를 한다.

• 회사에 입사하게 되면 “동작”하기를 바라는 것을 명시한 것이다.
• 회사와 입사자는 이러한 JD에 대해 합의를 하고 “계약”을 한다.
• 입사한 이후 계약에 따른 동작을 해내지 못한다면(인터페이스를 만족하지 못한다면) 계약을 만족하지 못하는 것이다.
• 이렇게 JD 라는 인터페이스를 이용하게 된다면 직원이 더 좋은 조건으로 이직하고 난 다음에도, 이와 같은 JD를 만족하는 직원을 찾아서 대체하도록 하면 된다.

DIP(Dependency Inversion Principle)

채용을 하는데 있어서 DIP를 따르지 않으면 어떻게 될까?

능력있는 지인을 직원으로 뽑았는데 이 직원은 다재다능하다.

• 백엔드 개발은 물론, 프로토타입 수준의 프론트엔드도 가능하다.
• 심지어는 회계 업무도 일정부분은 도와주고 채용 사이트 관리까지 챙겨준다.

이처럼 함께 있을 때에는 좋았는데, 이 직원이 이민을 가게 되어 더 이상 일할 수 없게 되어버렸다. 이 사람이 하던 일을 대체할 사람을 어떻게 뽑아야 할지 감이 오지 않는다.

• 회사가 이 직원에게 의존하고 있으며
• 회사와 직원이 강하게 결합(coupling) 되어 있어서 문제가 발생한 것이다.

DIP를 적용해보자

• 회사는 특정 직원에게(구현체) 의존하지 않는다. 회사는 JD에 의존한다(인터페이스, 혹은 추상 클래스)
  • 회사가 필요로 하는 인력이 해주었으면 하는 일(동작)을 JD(인터페이스)로 명시하는 것이다.
• 구직을 하는 이들도 이제는 JD에 의존을 한다. JD라는 인터페이스에서 요구하는 동작에 맞춘 자격을 갖추는 것이다.

IoC(Inversion of Control)

IoC가 없다면

• 프로젝트의 개발 팀장은 직원을 직접 뽑고, 가르쳐야 한다.
• 이 직원은 연차가 늘어나며 프로젝트의 여기저기에 관여하게 된다. 강한 결합이 일어나게 되는 것이다.
• 직원이 복권에 당첨되어 회사를 그만두게 되면 팀장은 절로 한숨이 나온다. “이런 친구를 또 어디서 뽑아서, 언제 교육시켜야 하지?”

IoC가 있다면?

• 프로젝트 팀은 필요로 하는 인원을 JD(인터페이스)로 명시하여 인사팀에 던지기만 하면 된다.
  • 물론 실제로는 채용시에 팀장이 함께 면접을 봐야 하겠지만 비유의 과장을 양해 바란다.
• 프로젝트 개발 팀장은 직원을 뽑는 권한(Control)을 더 이상 가지지 않는다.
  • 채용의 권한은 프로젝트 팀 외부(여기서는 인사팀)에서 가지고 있는 것이다.