모노레포란?

참고자료

https://www.youtube.com/watch?v=9RSNWt3AU-M

하나의 레포지토리에서 독립적인 여러 프로젝트를 관리하는 방법

Multi Repo

• 기존 Github에서 만드는 레퍼지토리 하나하나하나를 각각 독립적으로 사용하는 방식

Mono Repo

• 하나의 레퍼지토리에서 여러개의 프로젝트를 한번에 관리하는 방식

🤔 왜 모노레포를 쓰는걸까?

장점

1. 빠른 코드 수정
   • utilA, utilB를 변경하더라도 App에 바로 반영이 된다.
   • 멀티 레포의 경우 버전을 올리고 의존성을 다시 설치해야만 사용할 수 있었다는 단점이 있었다.
     • 즉, 멀티 레포에서 버전을 변경하고 싶다면 레포지토리 하나하나 접근해서 버전을 변경해야한다.
2. 각 레포마다 사용했던 같은 코드들의 중복 제거
   • 레포 마다 매번 작성하던 util, component를 한곳에 관리하여 코드의 중복을 줄이고, 생산성을 높일 수 있다.

     • 예를 들어 custom buttom 등등

       → 이러한 것들을 하나의 레포지토리의 Package 로써 관리를 할 수 있다는 장점이 있음

3. 수월한 코드 리팩토링
   • 코드를 한번에 관리하기 때문에 대규모 리팩토링이 쉬워짐
     • 물론 대규모 리팩토링은 최대한 지양하는 것이 좋다.
4. 코드 컨벤션 통일
   • 멀티 레포에서는 각 레포마다 다른 컨벤션을 가졌다면 모노레포에서는 한곳에서 관리하여 통일하기 수월함
   • eslint 패키지를 만들고 각 패키지에 주입하면 컨벤션 관리에 용이
5. 통합 CI와 Test 관리
   • 한꺼번에 ci를 돌릴 수 있고 test를 돌릴 수 있음.
     • 멀티 레포의 경우 수정 사항이 생기면 각 레포마다 테스트를 돌렸다면 yarn test 과 같은 명령어 한번으로 전체 테스트가 가능하다.

단점

1. 의존성 관리 복잡
   • 서로 의존성 연결이 쉽기 때문에 과도한 의존 관계가 생길 수 있음
   • A 패키지에 B 패키지를 의존하게 하면 C패키지에 B 패키지를 명시하지 않아도 B패키지를 사용할 수 있음.
     • 이는 배포할 때 문제는 야기함
   • 예를 들어 프로젝트에서 editor 라는 패키지를 design-system을 패키지에 주입할 수 있지만. design-system은 editor를 주입할 수 없음
2. 무거운 프로젝트 (CI 속도 저하)
   • 하지만 멀티 레포에서는 하나의 변경 사항이 다른 레포에 어떤 영향을 주었을지 잘 모르고, 전부 테스트를 돌려야 했음
   • 모노레포로 옮기면서 생긴 오히려 장점같은 단점
3. Code ownership 위배
   • 적은 팀이 사용한다면 상관 없겠지만, 많은 팀이 하나의 레포를 관리한다면 코드 오너십을 위배하여 관리 체계가 혼동 될 수 있음

모노레포를 선택하게 된 계기

“hops” 라는 제품에는 여러 시점이 존재한다.

1. Hops의 개발자 시점

• Hops 솔루션을 개발하기 위한 UI를 개발해야 함 (App)
• Hops로 개발하는 개발자가 쓸 수 있는 UI를 제공해 주어야 함 (@hops/ui)
  • UI는 추후 라이브러리로 배포 될 수 있어야 함
• UI와 App 에 공통적으로 디자인 시스템을 적용 해야함 (@hops/design-system)
• 컴파일을 통해 리액트로 코드를 추출할 수 있어야 함 (@hops/compile)

2. Hops로 백오피스를 만드는 개발자 시점

• 제공된 UI로 백엔드 로직을 연결해야 함
• 추후 원하면 리액트로 커스텀 개발을 진행해야 함
• 코드를 다운 받아서 로컬 개발을 할 수 있어야 함

3. Hops로 백오피스를 운영하는 운영팀 시점

• Hops를 통해 회사 제품의 운영을 해야함
• 백오피스를 수정하지는 못해야 함

결론

• 개발한 UI를 Hops의 개발자 뿐만 아니라 Hops로 백오피스를 만들 고객사의 개발자도 쓸 수 있어야 한다!
  • React로 컴파일을 해서 로컬에서 개발이 가능 하도록 하기 때문
• 물론 UI만 라이브러리 레포로 만들어서 사용해도 됨
• 하지만 모노레포를 적용함으로써 관리 코스트의 이점을 생각
• 또한 앞으로 공통으로 쓰일 많은 패키지들을 위해 모노레포를 적용하기로 결정

🌈 모노레포의 대표적인 구성들

구성 방법 전체

도구 없이 패키지 매니저로 구성하기

모노레포 빌드 시스템 도구와 함께 구성하기

😮 왜 터보레포일까?

---

• Turborepo 스케폴딩은 요즘 잘 지원되고 있음.

Yarn	Lerna	Nx	Turborepo
- zero install, pnp 개념 사용 가능	- 가장 많이 쓰이며 오래됨 - 최근 관리자가 바뀜 → nx 만드는 곳	- 툴체인이 많음 - 프레임워크 컨셉	- Vercel에서 인수 - Next.js, Typescript 기본 사용 - 캐싱으로 빌드 최적화 가능

실제로 Turborepo, Nx, Yarn workspace를 만들어 보았을 때?

• 세팅은 역시 Turborepo, Nx가 빠르다는 인상
• Turborepo가 Next.js, Vercel, Typescript에 친화적이라 쓰고 싶었지만, yarn Plug’n’Play (a.k.a “PnP”) 기능을 지원하지 않음
• NX는 다 해주지만 너무 커다란 프레임워크 느낌
• Yarn workspace 세팅 해봤는데 단독으로 쓰기에는 다른 툴체인에 비해 부족함

결론!

아무래도 원래 쓰는 스택을 생각하면 최대한 활용도가 높아보이는 Turborepo 채택!

🛠️ Turborepo 적용하기 (예시)

turborepo 구성을 살펴보자

apps

• apps/docs
• apps/web

packages

• packages/eslint-config-custom
• packages/tsconfig
• packages/ui