service를 Interface를 통해 구현하는 이유?

MVC패턴으로 작업하거나 기존의 소스들을 보다보면

항상 interface를 먼저 작성하고 impl 클래스를 구현한다.

하지만 지금까지 해온 프로젝트들 중에서 interface가 없어도 아무런 문제가 없는 경우가 상당히 많았다.

interface를 써야한다고 누군가를 설득해야할 때 이런 경우 설명할 수 없었다.

해봤자 교과서에 나오는 결합도를 낮추고 다형성을 추구한다는 말로는 명확히 설명할 수 없다.

스프링 관련 책에서 postProcessor관련 부분을 보는 중

객체를 캐시가능한 개체로 교체하게 되면 인터페이스가 아닌 기존 설정 클래스로 불러오는 과정에서 에러가 발생한다.

이전 객체는 새 객체로 교체 되었기 때문이다.

이런 경우 인터페이스를 통해 불러오게 된다면 같은 인터페이스를 구현한 객체들을 교체해도 예외가 발생하지 않는다.

간신히 interface와 serviceImpl의 필요성을 느낄 수 있었다.

그런데 스프링 AOP로 구현한다면 proxy객체로 반환할 텐데 이 경우 그대로 serviceImpl을 쓸 수 있는 것 아닌가 생각이 든다.

테스트를 해봐야 하는데 음...