[설계] 프로젝트 아키텍처로 멀티 모듈을 선택한 이유
나는 멋쟁이사자처럼 커뮤니티 개발 프로젝트에서 백엔드 리드를 맡아, 서버 리드와 함께 어플리케이션 설계에 대하여 같이 고민하였다. 우리는 이 프로젝트를 ver1.0으로 끝낼 생각이 없었고, 향후 계속 유지보수를 해야 하는 프로젝트로 계획하고 있었기에 유지보수성을 어떻게 가져갈지 고민하지 않을 수 없었다.
우리는 기획팀의 화면정의서를 바탕으로 요구사항을 정리하였고, 기본적으로 백오피스, 채팅, 그리고 클라이언트를 위한 API 서버를 구현해야 함을 이해했다. 이를 구현함에 있어서 각각의 서비스는 반드시 같은 버전으로 업데이트 될 필요가 없다. 다시 말해서, 백오피스 버전을 업그레이드 했다고 해서 클라이언트를 위한 API 코드들까지 전부 리빌드할 필요가 없다는 의미이다. 이처럼 빌드 종속성을 최대한 느슨하게 하는 것이 향후 기술 업데이트에 더욱 용이할 것으로 보았고 이를 구현하기 위한 구조를 조사하였다.
검색 결과 다음과 같은 선택지가 있었다.
- 싱글 모듈 멀티 프로젝트
- 커스텀 라이브러리 제작
- 멀티 모듈 싱글 프로젝트
싱글 모듈 멀티 프로젝트
싱글 모듈 멀티 프로젝트로 구성하게 되면, 여러 IDE를 띄워야 함은 물론, 코드의 중복이 불가피하게 갈수록 많아질 수 밖에 없다. 이는 만약 하나의 공통 코드를 수정하면 다른 프로젝트도 전부 수정해줘야하며, 이는 아직까지 전부 사람이 관리해야 한다는 관점에서 휴먼 에러가 발생하기 너무 쉬운 구조이다.
커스텀 라이브러리 제작
커스텀 라이브러리를 제작하게 되면, 멀티 프로젝트의 문제였던 코드의 과도한 중복은 해결할 수 있지만, 커스텀 라이브러리를 별도로 빌드 및 배포해둬야 하며, 수정할 때마다 이를 매번 재배포해줘야 하는 문제가 있다. 만약 이렇게 구성하는 코드가 매우 제너럴하여 많은 프로젝트에서 재사용 하는 경우라면 이 방법이 효율적일 수 있는데, 하나의 프로젝트에서만 활용하기 위해서라면 과한 아키텍처일 것이다.
멀티 모듈 싱글 프로젝트
멀티 모듈 싱글 프로젝트로 구성하면 하나의 프로젝트 아래에서 각 모듈은 별도로 빌드할 수 있으며, 각 모듈간 hierarchy를 구성하여 공통된 코드를 효율적으로 관리할 수 있다. 또한 하나의 프로젝트 내에서 관리하기 때문에 라이브러리를 제작하는 것에 비해 간단하게 공통 코드를 관리할 수 있게 된다.
우리 프로젝트는 지속적인 버전 관리를 예정하고 있었으며, 수정에 닫히고 추가에 열린 구조이면서 중복을 최소화하도록 모듈을 구성할 수 있는 멀티 모듈 아키텍처를 선정하였다.