[Web] 모노레포(Mono Repo)

등장 배경

덩어리채 만들던 과거 코드와는 달리 최신 코드들은 전부 모듈화가 되어있다.

모듈화의 이점으로는 여러 가지가 있지만 역시 유지보수와, 재사용성이 가장 큰 이점이다.

코드를 큰 덩어리채 만들어 굴린다면 한 부분을 유지 보수하기 위해 코드 전체를 수정해야 하고, 의존성 파악 또한 복잡해진다.

또한 썼던 코드를 다른 곳에 재활용하기 어려워진다.

모듈화 전

모듈화 후

사진출처: https://d2.naver.com/helloworld/0923884

 

멀티레포(multi repo) === 폴리레포(poly repo)

멀티레포란 말 그대로 여러 레포지토리를 만들어 프로젝트를 운영하는 방식이다.

각자 독자적인 레포지토리로 구성되어 있기에 각 팀별 자율성이 보장되고 빠른 개발이 가능한 장점이 있지만, 문제점들도 가지고 있다.

대표적으로

• 프로젝트 생성 시의 반복적인 업무: 프로젝트 생성 시마다 레포지토리 생성, 개발 환경 구축, CI/CD 구축, 빌드 후 배포 등 반복적인 업무가 지속된다.
• 코드 컨벤션 통일의 어려움: 레포지토리를 나눈 기준에 따라 코드 컨벤션을 맞추기가 어려워질 수 있다.
• 관리 포인트의 증가: 레포지토리가 많아짐에 따라, 관리 포인트가 늘어나 업무가 과중된다. 시간이 지날수록 이는 곧 프로젝트의 레거시 파악이 어려워지는 결과를 초래할 수 있다.
• 다른 레포지토리의 변경 사항 추적이 어려움: 팀원 간 지속적으로 소통하고, 피드백하지 않는 이상 본인이 맡지 않은 다른 레포지토리의 변경 사항 추적이 원활하지 않을 수 있다.

모노레포(mono repo)

모노레포란 여러 개의 개별 프로젝트를, 잘 정의된 관계를 통해서 하나의 Repo에 담은 것이다.

멀티레포와는 상반되는 개념으로, 버전 관리 시스템에서 두 개 이상의 프로젝트 코드가 동일한 저장소에 저장되는 소프트웨어 개발전략이다.

단순히 여러 프로젝트가 하나의 저장소를 사용해서 모노레포라고 부르기에는 부족하고, 프로젝트 간의 관계를 파악해야한다.

모노레포는 프로젝트 사이에 의존성이 존재하거나 같은 제품군 등 정의된 관계들을 효율적으로 관리해준다.

모노레포의 대표적인 장점으로는

• 더 쉬운 프로젝트 생성: 반복되던 과정들을 기존 DevOps를 이용하므로 새 프로젝트 오버헤드 발생이 없다.
• 더 쉬운 의존성 관리: 의존성 패키지가 같은 저장소에 있기에 관리가 용이하다.
• 단일화된 관리 포인트: 개발환경 및 DevOps에 대한 업데이트를 한 번에 반영할 수 있다.
• 변경 사항 추적 용이: 커밋할 때마다 모든 것이 같이 작동하기에, 다른 레포지토리에서의 변경 사항 추적이 용이하다.

모노레포

사진출처: https://d2.naver.com/helloworld/0923884

 

모노레포(mono repo) 구성

https://dev.to/limal/simplify-your-monorepo-with-npm-7-workspaces-5gmj

최상단 root folder로 모노레포를 구성한 사진이다.

모노레포 내 전체적으로 관리되는 Dependency 및 Workspace에 대한 정보들은 root package.json에서 통합된 채로 관리된다.

즉, 공통적인 설정을 각 서비스별로 할 필요가 없어진다. 물론, 개별적인 설정이 필요할 경우 package.json에서 추가 설정이 가능하다.

https://classic.yarnpkg.com/blog/2018/02/15/nohoist/

왼쪽 사진과 오른쪽 사진을 비교해보면 동일한 의존성을 가지는 모듈들이 중복 제거된 점이 비교될 것이다.

동일한 의존성을 가지는 모듈들을 최상단 계층으로 Hoisting 하여 효율적으로 접근할 수 있도록 변경됐다.

콴다 프론트엔드 팀의 모노레포 디렉토리 구조를 살펴보겠다.

...
├─ services
│    ....
│  ├─ service-a
│  └─ services-b
...
├─ libraries
│    ....
│  ├─ libraries-a
│  └─ libraries-b
└─ package.json

서비스 별로 다른 프로젝트들이 services 디렉토리 안에 모여있고, 프로젝트에서 사용하는 기타 라이브러리들은 libraries 디렉토리에 모여있다. 

// libraries/qanda-design-system

{
  "name": "qanda-design-system",
  "version": "1.0.1",
  "dependencies": {
    ...
  }
}

// services/project-a

{
  "name": "projectA",
  "dependencies": {
    "qanda-design-system": "1.0.1"
  }
}

위와 같이 프로젝트에서 라이브러리를 사용하기 위해 libraries에 있는 라이브러리를 services/project-a의 package.json에서 dependencies로 호출하면 참조하게 된다.

 

...
├─ services
│    ....
│  ├─ service-a
│  │   ├─ .eslintrc
│  └─ services-b
│      └─ .eslintrc
...
└─ .eslintrc

모노레포는 Lint 환경에서도 장점을 보인다.

멀티레포를 사용한다면 린트 설정을 공통으로 가져가게 되더라도, 설정 파일은 레포지토리 별로 각각 존재해야 한다.

하지만 모노레포를 사용하게 되면 공통으로 사용되는 린트 설정은 root 디렉토리에 통일시키고, 각 프로젝트 별로 린트 설정이 추가로 필요하다면 린트 파일을 개별적으로 따로 설정하면 돼서 코드 컨벤션 관리가 훨씬 수월하다.

 

References

팀워크 향상을 위한 모노레포(Monorepo) 시스템 구축

모노레포의 문화적 의의

https://d2.naver.com/helloworld/0923884