[Spring/TIL] Service 인터페이스와 ServiceImpl 클래스 구조를 나누는 이유와 나의 생각

Service와 ServiceImpl

 

Java + Spring을 사용한 프로젝트를 개발할 때 보통 위와 같이 Service인터페이스와 ServiceImpl을 나눠서 개발을 했습니다.

 

프로젝트를 진행하면서 이유도 모른 체 친구가 이게 좋다고 해서  만들어서 사용하다가 이번에 그 이유에 대해 알고 싶어서 공부해 보고 간단하게 정리를 해보려고 합니다.

 

0. 왜 이러한 구조를 사용할까요?

 

김영한 님의 강의에서도 언급이 되었고, 많은 블로그에서 이러한 구조를 사용하는 이유에 대해서도 많이 정리를 해놨습니다.

 

인터페이스와 구현체를 분리함으로써 구현체를 독립적으로 확장할 수 있으며, 구현체 클래스를 변경하거나 확장해도 이를 사용하는 클라이언트의 코드에 영향을 주지 않도록 하기 위함이기 때문인데요.

 

이러한 구조로 프로젝트를 설계했을 때, interface에서 정의한 기능을 새로운 방식으로 구현해야 한다면 사용해야 하는 곳에서 구현체만 손쉽게 바꿀 수 있기 때문에 Service를 인터페이스로 만들고, 해당 기능을 ServiceImpl라는 클래스 로 구현하는 것입니다.

 

정리해 보면 Service를 인터페이스와 구현체를 분리하는 목적은 하나의 역할을 여러 방식으로 구현함으로써 보다 자유로운 확장을 보장하는 것이죠. 이 방법으로 객체지향 5원칙 SOLID원칙 중 OCP (Open Closed Principle) 원칙을  지킬 수 있게 됩니다.

 

1. 과연 이 방법은 좋은 걸까요?

 

이 구조를 왜 사용하는지는 알았습니다. 원칙을 지키고 정석이기 때문이라는 점을요.

 

하지만 제가 실무에서나 프로젝트에서 이 구조의 장점을 제대로 활용한 적은 없었습니다.

 

결론부터 말하자면 위에서 설명한 구조가 좋은 구조라고 생각지 않습니다. 우선 인터페이스를 두어서 얻는 이점은 세부 구현체를 숨기고 인터페이스를 바라보게 함으로써 클래스 간의 의존관계를 줄이는 것, 다형성을 사용하는 것 이 핵심이라고 생각합니다.

 

하지만 실제로 대부분의 프로젝트에서는 인터페이스와 구현체 클래스 사이의 관계가 1:1의 관계로 구성되어 실질적으로 인터페이스, 클래스 구조를 사용하는 것에 대한 이점을 전혀 가져가지 못함에도 불구하고 관습적으로 이러한 추상 패턴을 적용하고 있습니다.

 

2. 그러면 사용하는 것이 맞을까요?

 

최근에 개발을 하면서 생각을 한 부분이기도 한데요.

 

'누가 좋다더라', '원칙적으로는 이게 맞다' 등의 조언을 들었을 때 무조건적으로 받아들이고 현재 진행 중인 개발에 적용을 시키는 건 잘못 됐다고 생각합니다.

 

물론 좋은 개발이 있고 나쁜 개발이 있지만 현재 진행 중인 개발을 가장 잘 이해하고 있는 건 저이고 어떠한 구현이 현재 적합할지 판단해야 하는 것도 저이기 때문이죠.

 

결국 선택은 프로젝트를 설계하고 개발하는 사람의 몫이라고 생각합니다. 하지만 이러한 구조를 사용한다면 사용하는 이유와 근거에 대해서는 알고 있고, 말할 수 있어야 한다고 느꼈습니다. 반대 상황도 마찬가지고요.

 

현재 프로젝트에서 위와 같은 구조를 사용하고 있는 입장에서 개인적인 생각을 정리해 보겠습니다.

먼저 개발을 할 때 확장가능성을 열어두는 것이 중요한 부분 중 하나라고 생각을 합니다.

 

현재는 인터페이스와 구현체 클래스가 일대일 관계를 맺고 있을지라도 언제 서비스가 커져서 구현체 클래스가 확장될지를 모르기 때문이죠.

 

장기적인 관점에서 미래에 유연하게 대처하기 위해 위와 같은 구조를 사용하는 것이 좋아 보입니다.

(물론 절대 바뀌지 않는다고 판단되는 기능의 경우는 단일클래스로 기능을 구현하려고 합니다.)

 

다음으로는 협업에서의 장점입니다.

 

인터페이스는 하나의 큰 뼈대라고 생각하면 되는데요. 현재 프로젝트 같은 경우에도 친구와 진행하고 있는데 함수명, 리턴 타입 등 많은 부분을 만들어놓은 인터페이스를 확인하면서 개발을 진행할 수 있습니다.

 

협업을 할 때 큰 뼈대를 공유한다는 점에서 큰 이점으로 작용할 수 있다고 생각합니다.

 

3. 정리

 

습관적으로 인터페이스와 구현체 클래스를 나누는 추상화를 사용하면서 궁금했던 점들을 간단하게 정리해 봤습니다.

 

뭐든지 알고 써야 한다는 생각을 다시 한번 했고, 위에서도 언급했듯이 선택은 프로젝트를 설계하고 개발하는 사람의 몫이고 그 선택을 잘할 수 있는 능력을 잘 길러봐야겠습니다.

 

감사합니다.