네이버웍스 연동 플랫폼이 엔티티와 서비스 계층까지 담은 공통 라이브러리를 여러 앱이 공유하면서, 하나의 요구사항이 여러 저장소와 배포 단계로 흩어지고 공통 코드가 손대지 못하는 레거시가 되는 문제에서 출발한다. 이를 멀티 모듈로 전환하며 어떤 기준으로 경계를 그었는지, 그리고 그 개선을 실행하기 위해 무엇이 먼저 필요했는지를 함께 짚는다.
핵심 포인트- 변화가 적고 시스템에 독립적인 문자열 유틸부터 글로벌 유틸 모듈로 안전하게 분리하고, 시스템 없이 성립하는 핵심 규칙·데이터는 도메인 엔티티로, 시스템이 있어야 도는 흐름은 유스케이스로 구분
- 입출력에서 먼 도메인과 저수준 인프라(DB·캐시)는 변경 속도가 달라 별도 모듈로, REST Docs·Spring Batch처럼 기능마다 다른 의존성, 앱 제작자·사용자·관리자라는 액터별 책임을 모듈 경계 기준으로 삼음
- 공통 모듈의 유스케이스를 걷어내고 액터가 다른 우발적 중복은 그대로 두며, Enable 어노테이션+ImportSelector로 필요한 인프라만 선택, 좁은 기본 가시성·Gradle implementation·ArchUnit·전원 리뷰로 경계를 강제하고 서비스 분리는 실익이 생길 때까지 미룸
- 입사 직후 개선안이 반응을 못 얻은 경험을 통해, 제안의 품질만큼이나 제안자에 대한 신뢰 자본이 도전적 과제를 맡는 전제임을 강조
왜 읽나공통 라이브러리 결합에 지친 팀이 멀티 모듈 경계를 변경 속도·기능·액터 기준으로 긋고 도구로 강제하려는 이들에게, 기술 설계와 조직 신뢰를 함께 다루는 실전 회고.