오버 엔지니어링이란?
현재 필요한 기능보다 더 과도하게 개발하는 것을 의미한다.
예를 들면 A 기능이 있으니까 B 기능도 필요하지 않을까 해서 임의로 쓰지도 않는 기능을 만들거나, 나중에 어떤 기술을 써야 하지 않을가 싶어서 미리 현재 필요 없는 기술을 도입한다거나 하는 것이다.
오버 엔지니어링에 대한 고민을 하게 된 이유 🤔
토이 프로젝트 진행 시 인터넷 강의를 들으면서 '어? 좋아보이는 구조인데?' 하면서 깊은 고민 없이 구조 변경을 한 것이었다.
이제 와서 구조를 전체적으로 보니까 너무 복잡해보여서 내가 오버 엔지니어링을 했던 건 아닐까 하는 고민이 들었다.
그 당시에는 JPA와 결합성을 줄이고 도메인 위주 개발하기 좋다고 토이 프로젝트 작업을 하면서 헥사고날 아키텍처로 진행을 했었다.
그걸 레시피 저장소를 작업하면서 전체적으로 계층형 아키텍처에서 헥사고날 아키텍처로 대공사를 했었다.
이제 와서 코드 리팩토링을 하기 위해 전체적으로 살펴보는데 사실상 Entity와 거의 동일하게 사용하고 있으면서 구조만 이렇게 복잡하게 만들어 놓은 게 의미가 있나 싶은 거다..
검색해보면 도메인 주도 개발, DIP 원칙을 지켜주는 헥사고날 아키텍처가 훨씬 더 좋은 거라고만 느껴진다.
그래서 이미 만들어놓은 것도 아깝기도 하고 이게 역시 더 좋은 거 아니야? 싶은 마음에 생각이 왔다 갔다 하더라 ㅎㅎ
결론적으로 오버 엔지니어링이라고 느꼈다. 🫠
해당 기술를 도입하게 된 이유가 어떠한 문제를 내가 느꼈고 그걸 해결하기 위해서 도입을 했다면 충분한 것 같다.
하지만 내 경우에는 사실상 '이게 더 좋다더라~' 해서 도입한 거였고 현재 기술적으로 복잡한 구조가 아니라서 오히려 복잡성이 높아지는 느낌이었다.
똑같은 작업을 또 하게 되어 바보짓을 하는 것처럼 느껴질 수도 있지만 현재로는 계층형 아키텍처로 충분한 구조라고 느껴졌다.
추후에 구조가 복잡해지고 도메인이 DB 구조와 확연히 차이가 생기거나 했을 경우에는 의존성 제거를 위해 다시 도입하는 게 맞는 것 같다.
헥사고날 아키텍처 사용하는 것 자체가 확장성이 높아지는 거라서 유지한 상태로 둬도 되지 않을까 싶기도 했다..
하지만 그걸 복잡하게 느낀다는 것 자체가 내가 제대로 이해하고 사용한다는 느낌이 아니라서 수준에 맞게 다시 계층형 아키텍처를 사용하면서 조금씩 필요에 따라 구조를 변경해 나가는 게 맞는 것 같다.
