monorepo란?
monorepo란 싱글 레포지토리에 잘 정의된 관계를 가진 여러 다른 프로젝트들이 있는 것을 말한다. 모놀리식과는 다르다!
polyrepo
모노레포에 반대되는 개념으로 polyrepo가 존재한다. 폴리레포는 일반적으로 어플리케이션을 개발하는 방법으로, 팀마다 제품마다 혹은 프로젝트마다 레포가 존재하는 것을 의미한다. 그래서 보통 각 레포는 하나의 빌드 결과물과 하나의 빌드 파이프라인을 가지게 된다. 폴리레포를 사용하는 가장 큰 이유는 팀의 자율성이다. 팀에서 자체적으로 어떤 라이브러리를 선택할 건지, 언제 배포할 건지를 정할 수 있기 떄문이다.
polyrepo의 단점
복잡한 코드 sharing과 코드 중복
폴리레포 환경이라면 레포지토리 간의 코드를 공유하기 위해서 shared code(예를 들어 공통 라이브러리 같은)를 위한 레포지토리를 따로 만들 것이다. 그리고 그 레포지토리를 위한 초기 셋팅을 다시 해야한다. lint 설정하고 젠킨스 설정하고 배포할 패키지 준비하고 써드파티 라이브러리 간의 버전 문제도 해결해야 한다. 결국 이전 레포지토리의 코드를 복붙하는데 똑같은 코드인데 또 써야 하나 싶고... 번거롭다.
코드 변경 시 비용
폴리레포 환경에서 공통 라이브러리에 버그 혹은 변경점이 발생했다면 해당 라이브러리를 참조하고 있던 여러 레포지토리에 영향이 가지 않도록 셋팅해야 한다.
일관되지 않은 tooling
폴리레포 환경에서 각 프로젝트들은 각자의 테스트, 빌딩, 배포, 린트 설정을 가질 것이다. 각자 다른 셋팅으로 인해 개발자 입장에서는 여러 개의 명령어를 따로 기억해서 실행해야 하는 번거로움이 발생한다.
monorepo의 장점
이런 폴리레포의 단점을 해결하는게 모노레포이다.
새로운 프로젝트 생성시 overhead가 없음
모노레포 환경에서는 동일한 CI 셋팅과 린트 설정을 사용할 수 있다. 코드 복붙 안해도 된다.
일관된 versioning
그리고 하나의 레포지토리를 통해 버전 관리를 한번에 할 수 있다. 레포지토리가 각자 존재한다면 계속 버전을 맞춰줘야 하는데 그러지 않아도 된다.
atomic changes
변경 사항을 atomic하게 관리할 수 있다. 폴리레포 환경에서 하나의 레포지토리 코드가 변경된다면 다른 레포지토리 코드도 그에 맞게 변경하고 각각 커밋을 해야 한다. 하지만 모노레포에서는 각 프로젝트마다 변경사항을 적용한 후 하나의 커밋으로 등록가능하다.
팀 간 협업이 쉬워진다.
여러 팀이 같은 코드의 모노 레포를 기반으로 일하고 있기 때문에 협업이 쉬워진다. 그리고 코드에 대한 소유권도 자유로워진다.
무조건 monorepo이 옳은 것은 아니다.
모노레포 역시 단점이 존재한다.
폴리리포주의자가 모노리포를 반대하는 3가지 이유
장점과 단점을 잘 비교하여 선택하는게 좋을 듯 하다.
monorepo 설정하기
monorepo를 설정하기 위한 여러 tool이 있지만 아래 두 가지를 사용하려고 한다.
- pnpm workspace 사용하기
- gradle multimodule 사용하기
