[소프트웨어] 모노 리포지토리와 멀티 리포지토리
- 용어
- 애플리케이션 또는 서비스: 어떤 기능을 수행하는 소프트웨어 단위
- 컴포넌트: 독립적으로 배포 가능한 가장 작은 단위
모놀리식 리포지토리
모놀리식(monolithic) 리포지토리란 하나의 소스 코드 리포지토리(저장소)에 모든 애플리케이션 소스 코드를 위치시키는 소스 코드 저장소 관리 형태를 말한다.
관심사의 분리를 통해 소스 코드를 별도의 컴포넌트로 관리해야 하는 경우 하위 폴더나 하위 패키지로 분리할 수 있다. 이때 배포 가능한(deployable) 가장 작은 단위인 컴포넌트를 각각 배포하거나 여러 컴포넌트를 혼합하여 하나의 배포 가능한 파일로 만들 수 있다. 컴포넌트가 배포 가능하다고 해서 실행 가능한(executable) 것은 아니다. 실행 가능한 컴포넌트는 하나의 독립적인 서비스 역할을 수행할 수 있다.
자바 언어의 경우 배포 가능한 컴포넌트는 jar(java archive) 파일이며 이 jar 파일은 다른 애플리케이션의 라이브러리로 포함시키는 플러그인으로 만들거나 적절한 메인 컴포넌트(메인 클래스)를 구성하여 다양한 플랫폼에서 실행 가능한 파일로 만들 수 있다. 자바 웹 애플리케이션의 경우 여러 jar 파일들을 결합하여 하나의 배포 가능한 아카이브 파일인 war(web archive)로 만들 수 있다. 즉, 자바의 jar 파일은 기본적으로 배포 가능하며 경우에 따라 실행 가능한 컴포넌트가 된다.
모놀리식 리포지토리 구조는 보통 하나의 CD 파이프라인을 통해 배포 및 실행 가능한 파일을 생성한다. 하나의 배포 가능한 파일이 하나의 실행 가능한 파일이 될 수도 있고 여러 배포 가능한 파일들을 결합하여 하나의 실행 가능한 파일을 만들 수도 있다. 컨테이너 기술을 이용하면 모놀리식 리포지토리를 사용하더라도 분리된 컴포넌트 별 빌드 및 배포와 테스트를 독립적으로 보다 손쉽게 가능하다.
빌드 도구의 모듈 또는 프로젝트 개념은 애플리케이션을 단일 컴포넌트로 구성할지, 다중 컴포넌트로 구성할지 제어할 수 있게 해준다. 컴포넌트는 하나의 애플리케이션의 동작을 위해 단순히 로드하는 라이브러리이거나 하나의 독립적인 서비스가 될 수도 있다. 모놀리식 리포지토리, 멀티 프로젝트 구조는 빌드 도구의 멀티 모듈(멀티 프로젝트) 빌드 지원 기능을 사용하여 하나의 리포지토리로 여러 컴포넌트 소스 코드를 관리하는 방법이다.
모놀리식 리포지토리와 마이크로서비스 아키텍처
모놀리식 리포지토리는 모놀리식 아키텍처 구조를 사용하는 애플리케이션에서 흔하게 사용된다. 모놀리식 아키텍처 구조를 따르는 애플리케이션의 규모가 거대해지면서 결합도를 낮추고 응집도를 높이기 위해 마이크로서비스 아키텍처 도입의 필요성과 방대해진 소스 코드 분리의 필요성이 생겨나게 될 것이다. 하지만 마이크로서비스 아키텍쳐가 모놀리식 리포지토리 형태를 사용할 수 없는 것은 아니다.
모놀리식 리포지토리라고 해서 각각의 서비스가 하나의 프로그래밍 언어로만 작성되는 것은 아니다. 서로 다른 기술을 사용하는 서비스 간 독립성은 배포 가능한 단위인 컴포넌트 간 아키텍처 경계 및 의존성에 의해 좌우된다.
각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트 간 통신 방식을 특정 형태로 제한하지 않는 마이크로서비스 아키텍처에서 각각의 서비스들이 네트워크를 통해 서로 통신하는 경우 서비스 간 결합도는 낮은 상태일 것이다. 이런 각각의 서비스들을 하나의 리포지토리로 관리한다고 해서 결합도가 올라가는 것은 아니다. 코드 의존 관계를 잘 관리하면 코드 변경으로 인한 영향도는 기존 그대로 유지할 수 있다.
멀티 리포지토리
멀티(multi) 리포지토리란 애플리케이션(또는 라이브러리) 별로 소스 코드 리포지토리(저장소)를 분리하여 독립적으로 위치시키는 소스 코드 저장소 관리 형태를 말한다.
멀티 리포지토리는 관심사의 분리를 통해 소스 코드를 별도의 서비스 및 컴포넌트로 관리할 목적으로 리포지토리 수준으로 분리한 형태이다.
각각의 리포지토리를 컴포넌트로 만들어서 각각 배포 및 실행 가능한 파일로 만들거나 여러 리포지토리를 서로 결합하여 하나의 배포 및 실행 가능한 파일로 만들 수 있다.
멀티 리포지토리와 마이크로서비스 아키텍처
멀티 리포지토리는 마이크로서비스 아키텍처 구조를 사용하는 애플리케이션에서 흔하게 사용된다. 하나의 리포지토리를 하나의 서비스로 구성하는 경우 각각의 마이크로서비스의 소스 코드는 별도의 리포지토리로 분리되어 관리된다.
모놀리식 아키텍쳐 구조를 사용하는 애플리케이션이 멀티 리포지토리 형태로 소스 코드를 관리할 수도 있다. 애플리케이션이 깃의 서브모듈을 사용하거나 동적으로 로드할 라이브러리를 포함시키는 경우가 이에 해당된다.
컴포넌트의 분리 기준, 개발과 배포의 독립성 및 유연성
컴포넌트의 응집도 및 결합도와 관련된 법칙들이 존재한다. 응집도가 높은 컴포넌트는 공통 폐쇄 원칙(CCP; Commom Closure Principle)을 따를 것이다. 이 원칙에 따라 동일한 이유로 동일한 시점에 변경되는 클래스들을 하나의 컴포넌트로 결합했다면 코드 변경이 여러 컴포넌트에 걸쳐 발생되지 않고 단일 컴포넌트에서 발생하게 된다.
서로 다른 이유로 변경되는 대상은 크게 계층(layer)과 유스케이스(usecase)가 있다. 계층은 애플리케이션의 논리적 분리 경계이다. 계층의 예로는 UI(프레젠테이션 계층), 비즈니스 로직(비즈니스 또는 서비스 계층), 데이터 저장 기술(영속성 계층) 등이 있다. 유스케이스는 애플리케이션의 기능 또는 행위를 말한다. 애플리케이션의 수평적 계층 분할, 수직적 유스케이스 분할을 통해 서로 다른 이유로 변경되는 대상을 분리할 수 있다.
코드 변경이 단일 컴포넌트로 제한되면 개발과 배포의 독립성 및 유연성이 높아진다. 변경이 발생했을 때 서로 다른 컴포넌트 각각에 대한 개발 프로세스는 서로 독립적이다. 또한 변경된 해당 컴포넌트만 재배포함으로써 서비스에 변경 사항을 적용할 수 있다. 변경된 컴포넌트에 의존하지 않는 다른 컴포넌트는 다시 배포할 필요가 없다. 즉, 서로 다른 이유로 변경되는 대상의 변경과 신규 추가가 용이해진다.
모놀리식 리포지토리와 멀티 리포지토리의 선택 기준은 애플리케이션의 복잡도 및 결합도와 관련이 깊다. 공통 폐쇄 원칙을 잘 따르는 컴포넌트로 이루어진 애플리케이션의 경우 각각의 컴포넌트는 독립적으로 버전 및 배포 관리가 이루어지므로 멀티 리포지토리나 모놀리식 리포지토리의 각 단점을 잘 보완할 수 있을 것이다. 반면 시스템의 복잡도가 증가하여 코드 변경이 여러 컴포넌트에 걸쳐 일어날 수 밖에 없다면 컴포넌트 간 의존성 관리가 유용한 모놀리식 리포지토리가 유리할 것이다.
멀티 리포지토리 구성에서 하나의 기능 변경이 여러 컴포넌트(서비스)에 걸쳐 일어나는 경우 각각의 리포지토리에서 변경 사항 반영, 빌드 및 배포가 수행되어야 한다. 반면 모놀리식 리포지토리, 멀티 프로젝트 구성일 경우 하나의 리포지토리 내에서 변경 사항 반영이 이루어지며 빌드 및 배포는 컴포넌트 별로 독립적으로 수행할 수 있다.
Comments