Monorepo

모노레포는 여러 애플리케이션과 패키지를 하나의 저장소에서 함께 관리하는 방식이다. 반대로 서비스나 패키지마다 저장소를 따로 두면 멀티레포, 또는 폴리레포라고 부른다.

모노레포가 좋은 이유는 변경의 흐름을 한곳에서 볼 수 있다는 점이다. 예를 들어 공통 UI 패키지를 수정하면서 웹 앱도 같이 고치고, 한 PR 안에서 테스트까지 돌릴 수 있다. 패키지 사이의 버전도 맞추기 쉽고, 큰 리팩터링을 할 때 영향 범위를 찾기도 편하다.

하지만 저장소가 커질수록 빌드와 테스트가 무거워진다. 모든 프로젝트가 같은 저장소에 있기 때문에 권한을 세밀하게 나누기도 어렵다. 초기에 워크스페이스, 캐시, 의존성 그래프, CI 설정을 제대로 잡지 않으면 “한곳에 모아둔 것” 이상의 장점을 얻기 어렵다.

언제 잘 맞을까

프론트엔드 앱 여러 개가 공통 디자인 시스템을 공유하거나, 서버와 SDK가 같은 타입 정의를 사용해야 하는 경우에는 모노레포가 잘 맞는다. 변경을 같이 배포해야 하는 코드가 많을수록 한 저장소에서 관리하는 장점이 커진다.

반대로 팀과 서비스의 경계가 명확하고, 배포 주기도 완전히 다르며, 서로 공유하는 코드가 거의 없다면 멀티레포가 더 단순할 수 있다. 모노레포는 무조건 더 현대적인 구조라기보다, 공통 변경을 얼마나 자주 다루는지에 따라 선택하는 운영 방식에 가깝다.

간단한 구조 예시

monorepo-demo/
  apps/
    web/
  packages/
    ui/
    utils/

{
  "name": "monorepo-demo",
  "private": true,
  "workspaces": ["apps/*", "packages/*"]
}

이 정도 구조만으로도 로컬 패키지를 서로 참조할 수 있다. 실제 프로젝트에서는 여기에 Turborepo, Nx 같은 도구를 붙여 변경된 패키지만 빌드하거나 테스트하도록 만든다. 핵심은 저장소를 하나로 합치는 것이 아니라, 의존 관계를 추적해서 필요한 작업만 빠르게 실행하는 데 있다.