모노레포(monorepo)도입에 대한 고민(1)

권준혁·2022년 7월 10일

monorepo nx

monorepo

목록 보기

2/2

모노레포란?

버전 관리 시스템에서 두 개 이상의 프로젝트 코드가 동일한 저장소에 저장되는 소프트웨어 개발 전략

1. 배경

Monolith Application란 고전적인 소프트웨어 개발방식으로서 모듈화 없이 소프트웨어를 개발합니다.

1-1. 모듈화를 하지 않았을 때 발생하는 문제 (monolith)

코드들이 직접적으로 의존한다.
관심분리가 안돼 유지보수가 어렵다.
작은 작업에서도 매번 거대한 코드를 관리해야한다.

따라서 많은 비효율과 제약이 발생하게 됩니다.

1-2. 모듈화 (modular)

전체를 교체하거나 관리할 필요없이 필요한 부분만 수정,관리할 수 있다.
핵심은 재사용성!

모듈화를 사용하지 않는 애플리케이션은 특수한 경우를 제외하곤 거의 없습니다. 자바스크립트에서도 import문, require문으로 모듈시스템을 지원하고 있습니다..
모듈화된 코드들은 일반적으로 재사용성을 고려해 작성하게 되는데,
위 사진에서 i18n모듈의 useKorean()을 다른 Application에서 사용하고 싶을 때를 예로 들 수 있습니다.

1-3. 멀티레포,폴리레포 (multirepo,polyrepo)

1-2 모듈화에서 그림처럼 각 모듈들이 고유한 저장소를 갖는 구조입니다.

각 모듈이 고유한 저장소를 가지기 때문에 자율성이 높고 배포,테스트,빌드같은 독립적인 개발과정이 가능합니다.
멀티레포 환경에서 자율성이 높다는 것이 장점인 이유는 각 팀원의 개발과정이 다른 팀원에게 영향을 미치지않기 때문입니다.
현재 대부분의 애플리케이션을 개발하는 표준적인 방법이기도 합니다.

이렇게 Google, Microsoft, Facebook, Stripe 같은 회사들이 Monorepo방식을 채택하는 이유, 그리고 Polyrepo의 단점은 무엇일까요?
방금 전 장점으로 밝혔던 자율성의 이면이 있기 때문인데, 자율성이 곧 고립을 발생시키기 때문입니다.
각 팀원의 개발과정이 다른 팀원에게 영향을 미치지 않는다는 장점(자율성)이 있으면서도 완전히 독립적이기 때문에 고립이 발생합니다.

폴리레포 환경에서 공유하고싶은 모듈이 있을 때
독립적으로 관리되는 모듈레포에서 코드중복 발생 (라이브러리관리 포함)
각 레포에서 라이브러리 관리가 힘들다.
각 레포는 building, testing, serving, linting, deploying같은 명령을 위해사용 하는 명령집합의 통합에서 발생하는 mental overhead

1-4. 모노레포 (monorepo)

1-3. 폴리레포 에서 발생하는 문제들을 모노레포가 해결해줄 수 있습니다.

새로운 프로젝트 생성에 부담이 없다.
의존 패키지가 같은 저장소에 있어 관리가 용이하다.
하나의 레포이기 때문에 공통모듈을 관리하기가 용이
개발환경에서 다양한 도구들을 일관되게 구축할 수 있어 편하고, 한번에 업데이트도 가능 (extension, lint 등)

단순히 여러개의 프로젝트가 하나의 저장소를 사용한다고해서 momorepo라고 부르긴 어렵습니다.

2. 모노레포에서 고려해야할 측면

출처
https://monorepo.tools/#monorepo-features
https://d2.naver.com/helloworld/0923884#ch1

1. 관리 측면

코드 공유: 서로 다른 프로젝트 간에 쉽게 소스 코드를 공유
일관성 있는 도구: 서로 다른 프로젝트들(심지어 서로 다른 프레임워크를 사용하더라도)에서 일관된 개발 경험을 제공
스케폴딩: 새로운 프로젝트를 생성할 때 초기 코드를 쉽게 생성
프로젝트 제약 및 가시성(visibility): 저장소 내에서 의존 관계를 제한하는 규칙 정의 지원. 예를 들어, 일부 프로젝트를 팀 전용으로 표시하거나 특정 프레임워크을 사용 중임을 기술.