Monorepo를 버리기로 했다

Monorepo를 도입하게 된 이유

현재 재직중인 회사에서 yarn workspace를 사용한 Monorpo로 프론트 시스템을 구축했었다.

Monorepo를 도입하며 아래의 효과를 기대했다.

중복되는 패키지에 대한 활용도 향상

- 예를 들어 ESlint 또는 Prettier와 같이 각 패키지별 동일한 설정이 필요한 경우, Root 패키지에 한번만 설정해두면 모든 하위 프로젝트에서 동일하게 사용한다.

- rollup이나 webpack과 같은 번들러를 사용하기 위한 종속성을 Root에 설치하면 각 앱별로 동일한 종속성을 바라보게 되므로 한번의 설치로 각 프로젝트에 번들러를 적용할 수 있고, 프로젝트의 절대적인 크기는 줄어들게된다. 

컴포넌트 재사용성을 Application(이하 앱) 단위가 아닌 프로젝트 단위로 활용

- ui를 제공하는 컴포넌트를 다른 프로젝트에 개발한 후 앱에서 사용할 수 있었다.

- ui를 개발하는 패키지를 Workspace 내부에 개발하여 빌드해두고, 여러 다른 앱에서 해당 컴포넌트를 동일하게 사용한다면 개발 생산성 향상 및 디자인이 일관적이게 될 것이다.

발생한 문제점

- Monorepo를 이용하여 패키지 별 의존성이 같은 것으로 연결된다.  

- 22년 말 노드 버전을 업데이트 하지 않으면 안되는 상황이 발생했다. Monorepo의 구축 당시 node의 버전은 14버전을 활용했고, 14버전은 23년 4월을 마지막으로 EOL(End-Of-Life)가 되었다. nodejs의 공식적인 지원이 종료되는 EOL은 보안취약점에 대한 패치가 없고 호환성도 떨어지게 되며, 새로운 라이브러리가 필요할 때 큰 제약사항이 생긴다.

- 이에 따라 node 버전을 업데이트 하는 과정을 거쳤는데 모든 앱에 걸쳐 맞물려 있는 버전 의존성 때문에 수많은 오류를 만나게 되었다.

- 각각의 앱에서 사용하는 라이브러리의 업데이트도 골치인데, 공통 라이브러리의 업데이트는 더 골치인 상황이었다.

- 어떤 앱에서 발생한 문제점에 대한 해결을 할때마다 다른 앱에서 사이드 이펙트가 나타났다.

- 예를 들어, 3개의 앱에서 사용하는 어떤 라이브러리에서 오류가 발생했다고 하자.

   1. 그 중 한개의 앱에서 발생하는 오류를 해결하기 위한 조치를 했다.

   2. 그리고 다른 앱에서 발생하는 오류를 해결하기 위한 조치를 했다.

   3. 1번에서 해결한 문제가 2번에 대한 조치가 끝나고 1번 앱에서 다른 문제가 발생했다.

   4. 3번 문제를 해결하기 위해 두 앱이 모두 오류가 나지 않도록 조치를 했다.

   5. 3번째 앱에서 발생한 오류를 해결했다.

   6. 3번째 앱에서 발생한 오류를 해결하니 1번, 2번 앱에서 다시 오류가 발생했다.

- 이러한 오류 하나하나를 해결해나가는데 쓸데없는 시간낭비가 크게 발생했고, 개발에 병목현상이 생겨 Monorepo를 활용하기 어렵다고 판단이 되었다.

- 또한 yarn berry를 도입하게 되었는데 이는 프로젝트 별 root의 종속성을 바라보지 않는다. 따라서 공통 종속성을 사용하기 위한 Monorepo를 사용할 필요가 없어졌다.

- 주니어 개발자들로 이루어진 팀에서의 Monorepo 활용이 어렵고,(같이 참여한 개발자의 퇴사로 Monorepo를 어느정도 이해하고 활용할 수 있는 개발자는 나 하나 뿐이었다.) 소규모 프로젝트에서는 굳이 Monorepo를 사용할 필요가 없다고 느껴졌다.

- 따라서 신규 프로젝트에서는 Monorepo에 포함 시키지 않도록하였다. 그리고 Monorepo에 포함된 몇몇 앱들이 너무 레거시하다고 판단하여 버전을 픽스 해두고 새로운 버전으로 앱을 재개발하기로 함에 따라 Monorepo를 더이상 키우지 않기로 했다.