이 프로젝트는 여러 git 리포지토리로 구성되어 있으며, 각 리포지토리는 비즈니스 업무 단위로 나뉘어 있다.
내가 속한 팀은 4가지 업무를 담당하고 있고, 이 중 나는 두가지 업무를 맡았고 각 업무당 또 다시 두개의 git 리포지토리로 나뉜다.

프로젝트의 구조

여기서 다소 희한한 프로젝트의 구조를 엿볼 수 있다. 각 업무마다 Ifr과 If module이 있다. Ifr Module은 외부 업무에서 사용 될 로직이 구현 되어 있고, If Module은 우리 팀의 다른 업무에서 사용이 될 로직이 들어 있다.

Ifr/If Module은 Jar의 형태로 타 업무의 pom.xml에 dependency로 추가가 된다. 다만, 프로젝트가 커질수록 다음과 같은 문제점들이 나타난다:

  1. 의존성 관리 문제
    각 업무가 서로의 If/Ifr 모듈을 의존하고 있는 상황에서, 하나의 모듈이 업데이트 되면 다른 팀 또는 업무에 미치는 영향이 적지 않다. 프로젝트의 업무가 상당히 많은 현재 프로젝트의 특성상, 어떤 모듈이 무엇을 참조하는지 추적하기도 어려워진다. 관리가 어려워지면서 circular dependency의 문제도 발생할 가능성이 있을 것 같다.

  2. 빌드 속도와 생산성 저하
    모든 Ifr/If 모듈이 각각 JAR 파일로 패키징되어야 하고, 다른 업무에서 이 JAR을 다운받아 사용해야 한다. 여기서 빌드 프로세스나 JAR 파일의 배포 속도는 업무를 지연시키는 주요 원인이 될 수 있다. 특히 내가 작업 중인 모듈이 다른 팀의 If 모듈에 의존하고 있고, 그 팀의 빌드가 늦어진다면 내 작업도 덩달아 지연된다.

  3. 낮은 확장성
    이 구조에서 새로운 업무가 추가되어야 할 경우, 2개의 git 리포지토리를 또 추가 해야 한고, 이에 따른 관리 부담이 높아질 수 밖에 없다.