🚨 발생 가능한 문제 상황 🚨

공통 모듈에 동일한 코드와 핵심 기능을 수행하는 코드들이 들어간다.

하지만 여러 어플리케이션에서 각각 필요한 기능들을 추가할 일이 생기고, 의도하거나 의도치않게 이러한 코드들이 공통 모듈에 쌓이게 될 수 있다.

결국 이런 상황이 반복되다보면 공통 모듈은 너무 커지고 많은 일을 하는 반면, 어플리케이션에서 하는 일은 보다 적어지는 이상 현상이 발생하게 된다!

🍝 스파게티 코드

코드가 서로 얽히고 섥혀서 하나의 코드를 수정하였을 때 전체 코드가 영향을 받게 되는 현상이 발생할 수 있다.

A 서비스 -> B 서비스 -> C 서비스 -> D 서비스 -> A 서비스

이 경우 더이상 공통 모듈에 들어간 코드는 처음 의도하였던 코드가 아니게 되버린다.

혼자 개발하는 경우에도 실수를 할 여지가 존재하는데, 여러 명이서 함께 개발하는 경우는? 말하지 않아도 절망적이다..

🎊 의존성 대환장파티

프로젝트에서 사용하는 대부분의 의존성이 공통 모듈로부터 시작된다.

문제는 어플리케이션들이 각자 사용하는 의존성이 다 다를 수 있다는 것이다.

ex) DB가 필요하지 않은 어플리케이션도 공통 모듈을 사용하려면 DB와 커넥션을 맺어야 한다.

의존성을 기반으로 발동되는 스프링 부트의 AutoConfiguration 덕분에 어디선가 의존성 대환장파티가 열리게 되고, 그 어플리케이션은 최적화되지 않게 되어버릴 것이다.

👨‍👩‍👦‍👦 공통 설정

공통 모듈에 공통 설정으로 인해 많은 문제점들이 발생할 수 있다.

Thread Pool, Connection Pool, Timeout 등의 설정도 가장 민감하고 중요한 어플리케이션 기준으로 작동한다.

특히 커넥션 풀의 경우, 공통 설정의 커넥션 설정과 실제로 DB를 사용하는 어플리케이션의 커넥션 설정 정보가 다르다면 큰 문제가 발생할 수 있다.