안녕하세요 JOBIS에서 프론트엔드 개발을 담당하고 있는 정지관입니다.
오늘은 제가 JOBIS를 개발하면서 저희 서비스에 모노레포를 도입하게 된 배경과 왜 Nx를 도입하게 되었는지 소개해드리려고 합니다.
기존 JOBIS의 프론트엔드 구조
현재 JOBIS는 총 3개의 웹사이트로 구성되어 있습니다.
- 모집의뢰서를 관리하고 학생 지원을 관리하는 선생님용 웹
- 학교로 학생들을 채용하기 위한 모집의뢰서를 작성할 수 있는 기업용 웹
- 학생들이 의뢰가 들어온 기업으로 지원할 수 있는 학생용 웹
기존의 JOBIS 프론트엔드는 3개 웹사이트를 각각의 레포지토리로 관리하는 멀티레포 구조를 사용하고 있었습니다. 또한 저희는 팀 생산성을 향상하고 디자인을 통일하기 위한 디자인 시스템 레포지토리를 따로 운영하고 있었고 웹뷰 레포지토리 또한 분리하고 있어 사실상 jobis 프론트엔드는 총 5개의 레포지토리로 관리되고 있었습니다. (디자인 시스템에 관한 글은 따로 쓸 예정입니다.)
멀티레포의 장점은 각각의 프로젝트가 독립적으로 운영되면서 다른 프로젝트와 의존성을 가지지 않아 빠른 개발이 가능하고 비교적 크기가 가볍워 프로젝트 관리가 수월하다는 점이었습니다.
기존 구조의 문제점
하지만 이렇게 운영 및 개발을 하다보니 기존에 저희가 사용하는 멀티레포 구조에서는 몇가지 불편함이 존재한다는 것을 느끼기 시작하였습니다.
- 프로젝트마다 서로 다른 컨벤션
- 여러 레포지토리로 프로젝트가 관리되다 보니 eslint, prettier 등의 설정이 달라 코드 스타일이나 포매팅과 관련해서 레포지토리 별로 통합되지 못하는 부분이 있었습니다.
- 중복되는 코드 증가
- 각 레포지토리마다 동일한 중복코드가 많이 발생하는 경우가 잦았습니다. 또한 저희 프로젝트는 변경사항도 잦은 팀이었기에 중복되는 코드의 수정사항이 생길 경우 수정해야하는 저장소가 많아지므로 유지보수성을 해칠 수 있습니다.
- 저장소의 수가 많아질수록 관리가 복잡
- 저장소 수가 계속 증가함에 따라 버전, 의존성 관리가 복잡졌습니다. 또한 코드 리뷰에 있어서도 여러 레포지토리에 신경을 써야해 팀원들이 불편함을 느꼈습니다.
모노레포
따라서 저희는 모노레포 도입을 통해 이러한 문제를 해결하고자 하였습니다. 시작에 앞서 모노레포란 무엇인지에 대하여 먼저 알아봅시다.
모노레포란?
모노레포란 버전 관리 시스템에서 두 개 이상의 프로젝트 코드가 동일한 저장소에 저장되는 소프트웨어 개발 전략을 말합니다. 따라서 하나의 레포지토리에서 여러개의 프로젝트를 관리할 수 있습니다.
모노레포의 장점
- 전체 코드의 일관성: 하나의 저장소에서 코드를 관리하기 때문에 eslint, preiiter와 같은 설정을 통합하여 모든 팀원이 동일한 코드 컨벤션을 가질 수 있게 해줍니다.
- 공유 라이브러리: 여러 프로젝트에서 공유되는 라이브러리를 관리하는데 효율적입니다.
- 단일 버전 관리: 모든 코드가 하나의 버전 관리 체계에서 관리되기 때문에, 버전 충돌 문제를 최소화할 수 있습니다.
모노레포의 단점
- 복잡성 증가: 여러 프로젝트를 하나의 저장소에서 관리하므로 코드 충돌 등의 문제가 발생할 가능성이 높아집니다.
- 빌드 시간 증가: 모든 프로젝트를 함께 빌드해야 하므로 빌드시간이 증가할 수 있습니다.
- 변경 사항에 민감: 하나의 프로젝트에서 발생한 변경 사항이 전체 시스템에 영향을 미칠 수 있습니다.
왜 Nx인가?
그렇다면 저희 팀은 왜 Nx를 선택하게 되었을까요?
많은 사용자 수
위 사진은 모노레포 도구들에 대한 다운로드 수 현황을 나타내는 그래프입니다.
모노레포 툴로 대표적인 nx, lerna, turbo를 비교해 보았는데요. nx가 다른 툴들에 비하여 2배이상 높은 다운로드 수를 기록하고 있는 것을 볼 수 있었습니다. 또한 지속적인 업데이트를 통한 프로젝트를 관리하고 있는 것을 볼 수 있었는데요.
이는 nx의 커뮤니티 규모가 크며 도움 받을 수 있고 공유할 수 있는 환경이 크다는 것을 의미한다고 생각하였습니다.
많은 기능 지원
위 사진과 같이 모노레포의 대표적인 툴들의 기능을 비교해 보았을 때 많은 기능을 지원하는 것을 확인할 수 있었습니다. 무조건 기능이 많다고 좋은 것은 아니지만 저희 팀은 속도와 구조 측면에서 강점이 있는 것에 집중하였습니다. 그 결과 yarn과 lerna는 저희의 선택 안에서 제외하는 결정을 하게 되었습니다. 또한 결정적으로 서비스들은 이미 독립적인 레포 환경에서 배포 관리되며 실 서비스에 문제가 되는 부분이 없어 저희는 이러한 기능들에 대해서 더 알아보고 적용해보며 공부할 환경이 되었기에 Nx를 적용해보기로 하였습니다. 기능에 대한 더 자세한 내용은 아래에서 확인해봅시다.
의존성 그래프
Nx는 현재 패키지 간의 의존성 그래프를 확인할 수 있는 기능을 지원하고 있습니다.
저희 서비스는 유지보수를 계속해서 해 나가야하기 때문에 처음 들어온 팀원들도 현재 서비스의 구조에 대한 이해를 쉽게 할 수 있도록 하기 위해 선택하였습니다.
캐싱
Nx는 캐싱 기능을 제공합니다. 앞서 말씀드렸다시피 저희 팀은 속도와 관리 측면에서 강점이 있는 툴을 선택하려고 하였습니다. Nx에서는 동일한 명령어를 실행하면 캐싱된 부분을 통해 동일한 것을 두 번 빌드하거나 테스트하지 않도록 합니다. 따라서 이러한 기능을 활용한다면 빌드나 테스트 시간을 줄일 수 있을 것이라고 생각하였습니다.
affected
Nx에서는 affected라는 스크립트를 지원합니다. 이를 통해서 변경사항에 대해 의존하고 있는 빌드 및 테스트 작업만 수행할 수 있습니다. 앞서 나왔던 모노레포의 단점 중 하나의 수정사항에 대하여 모든 프로젝트가 빌드가 되면서 빌드 시간이 증가할 수 있다는 치명적인 단점이 존재하였으나 affected를 이용하면 수정사항에 대하여 관련이 있는 필요한 부분만 빌드 하게 되기 때문에 모노레포의 단점을 해소할 수 있다고 생각하였습니다.
Scaffold
스케폴딩이란 새로운 프로젝트를 생성할 때 초기 코드를 쉽게 생성하는 것을 말합니다. Nx는 다양한 플러그인 혹은 로컬 Generator를 통해 새로운 프로젝트를 생성할 때 초기설정을 팀에 쉽게 생성할 수 있습니다.
Nx console
다른 모노레포 툴과 비교하였을 때 Nx는 Nx console이라는 VS Code에서 Nx를 쉽게 사용하기 위한 GUI 툴을 제공합니다. Nx console을 사용하여 새로운 프로젝트 또는 내부 패키지를 작성, 빌드나 테스트를 세팅하고 실행 작업도 손쉽게 할 수 있을 것 같아 보였습니다. 이 부분은 개발자 경험을 향상 시킬 수 있는 부분이라고 생각되었습니다.
마무리
이번 글에서는 저희 팀이 모노레포를 도입하게된 배경에 대하여 알아보았습니다.
다음 글에서는 저희가 이렇게 도입한 모노레포를 어떻게 구축 및 배포를 하였는지에 대해 다뤄보도록 하겠습니다.
참고자료
