1. 배경
현재 저희 팀은 모든 사내 프로젝트를 멀티 레포로 운영하고 있습니다. 프로젝트를 새로 시작할 때마다, 매번 새로운 마음가짐으로 요구사항에 맞는 기술 스택을 고르고, 환경 설정을 처음부터 다시 하곤 했습니다. 그렇게 하나씩 만들어진 프로젝트는 현재까지 5개+a에 이르렀습니다.
그런데 최근, 두 가지 과제와 마주하게 되었습니다.
- 공통 디자인 시스템을 도입해야 한다.
- 통합 관제 시스템을 구축해야 한다.
통합 관제 시스템을 구축하기 전에 공통 디자인 시스템을 먼저 적용하는 것이 순서라고 판단했고, 어떤 방식으로 공통 디자인 시스템을 만들어야 할지 여러 방면으로 조사했습니다.
여러 프로젝트에서 공통으로 사용할 디자인 시스템을 구축하는 방법은 일반적으로 두 가지입니다.
- npm 라이브러리로 배포하여, 각 프로젝트에서 import해서 사용하는 방식
- 모노레포로 구성하여 공통 패키지를 직접 참조하는 방식
현재 상황에서 가장 빠르게 적용할 수 있는 방법은 npm 배포 방식입니다. 배포된 라이브러리를 각 멀티레퍼에서 사용하면 되는 방식이죠. 하지만 이 방식은 장기적으로 봤을 때 몇 가지 불편함이 따릅니다. 예를 들어, UI에 변경 사항이 생기면 이를 사용하는 모든 프로젝트에서 버전 업데이트를 별도로 해줘야 하고, 그때마다 일일이 릴리즈하고 배포하는 번거로움이 생깁니다.
물론 GitHub Actions 등을 활용해 트리거 기반 자동 배포도 가능하겠지만, 그렇게까지 복잡하게 구성하기보다는, 지금 하나라도 프로젝트가 적은 이 시점에 모노레포 전환을 도전하는 것이 낫겠다는 판단을 했습니다.
모노레포 도입 시 장점
모노레포 환경을 선택하면 다음과 같은 장점이 있습니다:
- 공통 패키지에서 코드 수정이 이루어졌을 때, 그 내용을 사용하는 모든 프로젝트에 즉시 반영할 수 있습니다. 앞서 언급한 버전 관리 문제를 자연스럽게 해결할 수 있는 구조입니다.
- 중복 코드를 하나의 패키지로 중앙 집중화하여 관리할 수 있습니다. 예를 들어, ESLint나 Prettier 같은 코드 규칙 설정을 공통화하면, 전체 프로젝트가 동일한 개발 환경과 규칙을 따르도록 할 수 있습니다.
저희 회사의 개발팀, 그 안에서도 프론트엔드 팀은 대체로 소규모인데요, (지금은 저 한 명입니다.) 작은 규모의 팀이 여러 프로젝트를 병렬로 운영해야 할 경우, 각각의 프로젝트마다 개발 스택이 달라지면 팀원 입장에서는 러닝 커브가 매우 높아집니다. 새로운 인원이 들어올 때마다 각 프로젝트의 환경을 새로 익혀야 하고, 이는 결국 생산성과 협업 모두에 악영향을 줍니다. 담당자가 다 퇴사하고 나서 모든 프로젝트를 담당하게 된 입장에서 이 불편함은 더 크게 느껴졌어요.
결론적으로 종합적인 상황을 따져봤을 때, 장기적인 운영 관점에서 모노레포로 전환하는 것이 좋겠다는 판단을 내리게 되었습니다.
2. 도입 절차
무언가를 시작하기에 앞서, 앞으로 어떤 절차로 환경을 구축할 것인가를 정리했습니다. 크게 나누어보면,
- 각 프로젝트에서 필요한 부분 리팩토링
- 모노레포로 이전에 앞서 확인 사항 점검하기
- 모노레포 초기 환경 설정하기
- 공통 디자인 시스템 사전 준비하기
- 브랜치 전략 수립 및 CI/CD 연결하기
이런 식으로 단계를 나누었습니다.
1. 프로젝트 리팩토링
앞서 말씀드렸듯이 회사의 프로젝트들은 각기 다른 라이브러리를 사용하고 있습니다. 빠른 개발 및 출시가 필요하다거나, 담당자에게 익숙하거나, 혹은 프로젝트의 목적에 맞는 라이브러리를 그 때마다 선택해 사용하곤 했는데요, ... 필요성 더 작성하기.
모든 프로젝트의 번들러를 Vite로 통일했습니다. CRA의 지원 중단 문제도 있었습니다.
또한, 각 프로젝트에서 더이상 사용하지 않는 라이브러리를 정리했습니다.
2. 확인해야 할 것 정리하기
- 커밋 & PR 정리
- github secret-key와 integration tool 확인하기