Service와 Interface

Service를 구현할때 Interface를 써야할까?

 

 Spring을 사용하다 보면 많은 서적과 안내서에 Interface를 이용하여 Service를 구현하도록 설명합니다. 하지만 왜 Interface를 활용해야하는지에 대해 자세하게 설명하는 경우는 못 본 것 같습니다. 그래서 생각없이 Interface를 사용하여 Service를 구현하는 케이스를 종종보게 됩니다. 우리는 여기서 고민해야하는 지점은 Service를 구현할 때 Interface를 써야하는가 그리고 왜 사용해야 하는가입니다. 

 

 해당 내용은 제 생각으로 정답이 아니며 각자의 철학과 사고를 바탕으로 판단해야합니다.

 

저는 Service를 구현할때 interface를 써야할까 라는 질문은 No라고 말하고 싶습니다. 

 

 먼저 Interface를 사용하는 이유를 우선 생각해야 하는데요, Service를 추상화하여 쉽게 구현체를 변경할 수 있다는 점에 있어 결합도를 낮추고 유연한 개발이 가능하다는 점이 있습니다. 또 Spring에서 AOP나 Transaction 사용하기 위해 프록시가 필요했고 이를 위해 Interface를 활용했습니다.

 

Interface사용 이유

 1. 추상화를 통해 구현체 변경이 쉬움

 2. 결합도를 낮추어 유연한 개발이 가능함

 3. AOP를 위해 Interface사용 (프록시를 위해)

---

 그럼 이런 Interface사용으로 인해 오는 부작용을 알아봐야합니다. Interface를 생성하게 된다면 항상 각 함수를 Interface에도 정의해주어야 합니다. 미래의 Service를 미리 판단하여 추상화할 수 있는 사람은 없으며 미리 판단하는 것은 좋은 선택이 아닙니다. 따라서 생산성에 일부 악영향을 미치게 됩니다.

 

 조금 더 생각해보면 사실 우리는 특수한 경우가 아니라면 Controller에서 Service를 교체할 필요가 없습니다. 일반적인 도메인에서 동일한 서비스 여러 구현체를 통해 만들어야 하는 경우를 본적이 극히 드물기 때문입니다. 또한 이는 각 서비스가 단일 역할을 제공하기 위해서도 좋은 선택이 아니라고 생각합니다. 구현체를 변경할 필요가 없고 생산성에 악영향을 미친다는 점에서 Interface사용 이유인 1번과 2번을 부정하게 됩니다.

 

 또한 AOP나 Transaction을 위한 Interface사용도 Spring이 발전함에 따라 별도의 기술(CGLIB)을 활용해 동적 프록시를 사용하므로 그 필요성을 잃었습니다.

 

 상황에 따라 판단해야 하지만 결과적으로 우리는 Service구현을 위해 Interface를 반드시 사용할 필요가 없다고 말하고 싶습니다.

 

 우리는 사용 이유를 판단하고 해당 이유에 대한 부작용 그리고 현실적인 생산성등 다양한 요소를 종합적으로 판단하여 유연하게 개발할 필요가 있습니다. 모든 개발에는 반드시와 정답은 없으며 유연하게 판단하는 습관이 필요합니다.