Trade-Off(구조의 안정성 vs 단순한 개발의 편리성)

Trade-Off(구조의 안정성 vs 단순한 개발의 편리성)

스프링 데이터 JPA 예제를 수행한 것을 다시 한번 돌아보며, 느낀 것들을 기록한다.

우선,
DI, OCP를 지키기 위해 어댑터를 도입한 코드의 클래스 의존 관계와, 런타임 객체 의존 관계를 살펴보자.

중간에서 JpaItemRepositoryV2가 어댑터 역할을 해준 덕분에 ItemService가 사용하는 ItemRepository 인터페이스를 그대로 유지할 수 있고, 클라이언트인 ItemService의 코드를 변경하지 않아도 되는 장점이 있다.

그런데, 여기서 고민이 생긴다.

• 구조를 맞추기 위해서, 중간에 어댑터가 들어가면서 전체 구조가 너무 복잡해지고 사용하는 클래스도 많아지는 단점이 생겼다.
• 실제 이 코드를 구현해야하는 개발자 입장에서 보면 중간에 어댑터도 만들고, 실제 코드까지 만들어야 하는 불편함이 생긴다.
• 유지보수 관점에서 ItemService를 변경하지 않고, ItemRepository의 구현체를 변경할 수 있는 장점이 있다.  DIP, OCP 원칙을 지킬 수 있다는 좋은 점이 분명히 있다. 하지만 반대로 구조가 복잡해지면서 어댑터 코드와 실제 코드까지 함께 유지보수해야 하는 어려움도 발생한다.

여기서 완전히 다른 선택을 할 수도 있다.

ItemService 코드를 일부 고쳐서 직접 스프링 데이터 JPA를 사용하는 방법이다.
DI, OCP 원칙을 포기하는 대신에, 복잡한 어댑터를 제거하고, 구조를 단순하게 가져갈 수 있는 장점이 있다.

그렇게 한다면, 클래스 의존관계는 아래와 같을 것이다.

• ItemService에서 스프링 데이터 JPA로 만든 리포지토리를 직접 참조한다. 물론 이 경우 ItemService 코드를 같이 변경해야 한다.

이것이 바로 트레이드 오프다.

• DI, OCP를 지키기 위해 어댑터를 도입하고, 더 많은 코드를 유지한다.
• 어댑터를 제거하고 구조를 단순하게 가져가지만, DI, OCP를 포기하고, ItemService 코드를 직접 변경한다.

결국 여기서 발생하는 트레이드  오프는 [구조의 안정성 vs 단순한 개발의 편리성] 사이의 선택이다.
이 둘 중에 하나의 정답만 있을까? 그렇지 않다. 어떤 상황에서는 구조의 안정성이 매우 중요하고, 어떤 상황에서는 단순한 것이 더 나은 선택일 수 있다.

개발을 할 때는 항상 자원이 무한한 것이 아니다. 그리고 어설픈 추상화는 오히려 독이 되는 경우도 많다.
무엇보다 추상화도 비용이 든다. 인터페이스도 비용이 든다. 여기서 말하는 비용은 유지보수 관점에서의 비용을 뜻한다.
이 추상화 비용을 넘어설 만큼 효과가 있을 때 추상화를 도입하는 것이 실용적일 것이다.

본인이 진행하는 프로젝트의 규모가 작고, 속도가 중요하고, 프로토타입 같은 시작 단계라면 단순하면서 라이브러리의 지원을 최대한 편리하게 받는 구조가 더 나은 선택일 수 있다.
하지만, 이 구조는 레포지토리의 구현 기술이 변경되면 수 많은 코드를 변경해야 하는 단점이 있다.

이런 선택에서 하나의 정답은 없다. 이런 트레이드 오프를 알고, 현재 상황에 더 맞는 적절한 선택을 하는 좋은 개발자가 있을 뿐이다.
이런 트레이드 오프를 고민하고, 현재 상황에 맞는 더 나은 선택을 하기 위해 많이 고민해야겠다. 
그 시간들이 많이 쌓이면 분명 좋은 SoftwareEngineer가 되어 있을 것이다.

산업경영공학을 전공하며, 지도교수님께서 추천해주신 (A.L바바라시 저) "링크" 라는 책에서 읽었던 구절이 생각나는 고민이었다.

" 최적화가 무조건 긍정적인가? 최적의 조직화는 기업을 비탄력적으로 만든다.
전체 최적화의 관점에서 일을 하는 노력을 지속하지 않는다면
"효과성"이 전제되지 않은 상태에서 "효율성" 극대화를 추구하게 되고,
기본과 원칙에서 벗어나는 것이다."