프로젝트 구조 변화
어제 살펴본 프로젝트 구조를 유지보수, 개발자 생산성, 확장성 측면에서 개선하기 위해 어떤 구조를 적용 시킬 수 있을까?
현재는 ifr 모듈에서 작업을 하고 나서, jenkins에서 파이프라인을 돌린 후, 메인 애플리케이션의 파이프라인을 돌린다. 문제는 ifr을 수정하는 인원이 우리 팀 내에도 많고, 타업무에서도 각자 ifr을 돌린 후 메인 애플리케이션을 또 돌리기 때문에, 빌드 파이프라인이 불필요하게 돌아가는 경우가 많다.
이는 Build Coupling이 높다고 표현할 수 있다. 각 Ifr 모듈의 변화를 적용하기 위해서는 모듈을 우선 빌드 한 후, 메인 애플리케이션을 (이 순서대로) 빌드 해야한다. 변경을 할 때마다 여러 프로젝트를 다시 빌드 해야하기 때문에 이는 개발자 생산성에 큰 타격을 준다.
높은 Build Coupling을 낮추기 위해서 무엇을 할 수 있을까?
한가지 방법은 각 업무를 각각 standalone service으로 바꾸는 것이다. API specification만 처음에 잘 정의한다면 비교적 코드 변경이 적은 메인 애플리케이션은 다시 빌드를 안하고 각 업무 서비스만 다시 빌드하면 된다. 각 Ifr 서비스는 메인 애플리케이션에서 사용 할 수 있는 REST 엔드포인트를 노출시켜주기만 하면 된다. 물론 이 방법은 프로젝트 구조의 복잡성과 운영 비용을 높이고 서로 네트워크를 해야하기때문에 장애 대응에도 어려움을 줄 수 있어서 현실적으로 불가능하다.