들어가며
사이드 프로젝트에서 푸시 알림을 활용한 서비스를 개발하고 있습니다. 개발하는 과정에서, 팀원과 node 버전이 맞지 않아서 개발하는데 어려움을 겪었습니다. node 버전을 프로젝트마다 다르게 설정할 수 있다면 좋겠다고 생각했습니다. 이 글은 개발자 이동욱 님의 nodeenv를 활용한 프로젝트별 node 가상 환경 관리 글과 심재철 님의 모노 레포 글을 참고해서 작성됐습니다.
모노 레포
프로젝트 구조를 구성하는 방식은 크게 모놀리스, 멀티 레포, 모노 레포 3가지로 나눌 수 있습니다. 모놀리스는 하나의 레포지토리 안에 하나의 패키지 안에 여러 개의 서비스가 폴더로 구분됩니다. 멀티 레포 구조는 하나의 레포지토리 안에 하나의 패키지안에 하나의 서비스가 들어갑니다. 마지막으로 모노 레포 구조는 하나의 레포지토리 안에 큰 공통 패키지 하나 안에 여러 개의 서브 패키지들(서비스)이 들어있습니다.
각 프로젝트 구조는 장단점이 있습니다. 모놀리스의 경우, 비슷한 여러 개의 소규모 프로젝트들을 한 번에 관리할 때 좋은 구조라고 생각합니다. 멀티 레포 구조는 각 서비스를 별도 관리해서 서비스 간 의존성을 줄이고 싶을 때 사용하면 좋은 구조라고 생각합니다. 모노 레포 구조는 마찬가지로 서비스의 규모가 커졌을 때, 각 서비스 간 분리도 되면서 공통 구조를 가져가고 싶을 때 사용하면 좋다고 생각합니다.
그럼 모노 레포를 사용했을 때의 장점은 무엇이 있는지 조금 더 자세히 알아보겠습니다.
모노 레포의 장점
첫 번째 장점은 모노 레포를 활용하면 의존성 관리가 간편해진다는 점입니다. 하나의 공통 패키지안에 여러 서브 패키지들이 있기 때문에 각 서브 패키지들이 공통으로 사용하는 의존성들은 공통 패키지에 넣으면 됩니다. 각 서브 패키지별로 다르게 사용해야 하는 의존성들은 각 서브 패키지에 명시하면 됩니다. 멀티 레포였으면 이렇게 여러 개의 레포지토리에서 공통으로 사용하는 의존성 관리를 하기가 어려워집니다.
두 번째 장점은 이슈 관리가 간편해진다는 점입니다. 멀티 레포였으면 각 레포지토리 별로 이슈가 분산되는 문제가 있습니다. A와 B레포지토리 둘 다에서 발생한 문제인데 어떤 경우에는 A 레포에만 이슈를 올리고 B는 빠트릴 수 있습니다. 하지만 모노 레포는 하나의 레포지토리에 모두 코드가 몰려있으므로 그 레포지토리에서 이슈를 생성하고 히스토리가 쌓이게 할 수 있습니다.
모노 레포의 단점
모노 레포를 활용하면, 버전 관리가 상당히 힘들어진다는 단점이 있으며 Repository 크기가 크기 때문에 repo기반으로 동작하는 도구들의 속도가 느려진다는 특징이 있습니다.
모노 레포 vs 멀티 레포
멀티 레포는 말 그대로 레포지토리가 여러 개 있다는 뜻입니다. 레포지토리가 여러 개로 관리되면 권한 관리를 레포지토리 별로 따로 할 수 있기에 편리할 수 있습니다. 또한 멀티 레포는 각 직원에게 필요한 레포지토리의 권한만 주어서 관리하게 할 수 있다는 장점이 있습니다. 모노 레포가 멀티 레포보다 좋은 점은, 모노 레포는 공통화가 쉽다는 것입니다. 서비스가 한두 개 일 땐 상관없는데 이게 50개 100개가 되는 경우에 멀티 레포로 이 모든 서비스를 관리하게 되면 굉장히 힘들어집니다. 따라서, 모노 레포로 프로젝트를 구성해두면 하나의 큰 패키지안에 여러 개의 서브 패키지들로 서비스들을 관리할 수 있기 때문에 멀티 레포보다 훨씬 관리하기가 편합니다. 이런 점들을 잘 고려해서 프로젝트 구조를 구성해야 합니다.
왜 모노 레포로 개발하는가?
평소 모놀리스 방식으로 개발하곤 했습니다. 개발하면서 느꼈던 문제는, 서비스가 커지게 된다면, 관심사를 분리하기 어렵다는 점이었습니다. 각각의 서버는 역할과 책임이 분리되어야 하는데, 하나의 서버에 모든 역할과 책임이 들어있었기에, 하나의 서버가 장애가 나면 전체 서비스가 장애가 나는 문제가 있었습니다. 그래서 서버의 관심사를 분리하기 위해 모놀리스에서 멀티 레포로 분리하려 했습니다. 하지만 이때는 이슈 관리가 무척 힘들었습니다. 여러 서버를 동시에 수정해야 했는데, 그런 방법을 알지 못했고, 수정하는 시간이 무척이나 많이 들었습니다. 그럼 이번 기회에 모노 레포를 활용해서 서브 패키지를 분리해서 의존성을 관리해봐야겠다고 생각했습니다. 그렇게 된다면 여러 서버를 관리해야 할 때 효율적으로 서버를 관리할 수 있겠다고 생각했습니다.
서비스 소개
현재 프로젝트를 위해 2개의 하위 프로젝트가 있는 상태입니다.
- 푸시 서버
- API 서버
이때 배포되는 서버도 다르고 다른 코드 베이스를 가지고 있는데, 이들이 공통적으로 필요로 하는 Entity는 어떻게 관리해야 할까요?
저는 모노 레포 활용을 위해 apps와 libs를 나눠서 작업을 진행했습니다.
여기서 apps 폴더는 별도의 서버로 배포될 애플리케이션입니다. apps에는 푸시, api 서버가 존재하고, 각 서버는 단독 실행이 가능합니다.
libs의 경우 공유 라이브러리를 모아둔 곳입니다. apps에서 이들을 의존해서 사용합니다. 모노 레포 방식으로 개발을 하다 보니, 개발을 위해 다른 서버가 필요하다면, apps에 별도로 배포할 애플리케이션을 생성하면 되기에, 확장성에 있어서 편리하다고 생각하고 사용하고 있습니다. 만약 모노레포를 활용해서 개발하는 방법을 알고 싶으시면 이동욱님의 글을 참고해주세요.
마치며
앞으로도 팀의 발전을 돕는 개발자가 되기 위해 노력하려 합니다. 팀에 필요한 부분이 무엇일지 고민하면서, 팀에 도움이 된다면, 열심히 공부해서 실무에 적용할 수 있는 개발자가 되기 위해 노력하고 싶습니다. 팀의 성장에 기여할 수 있는 개발자가 되겠습니다.
참고 및 출처
1. NestJS & TypeORM 환경에서 Monorepo 구성하기 - 기본 환경 구성 및 명령어
지난 시간에 yarn workspace 를 활용한 Monorepo를 소개 드렸는데요. 이번 시간에는 NodeJS의 대표적인 MVC/DI 프레임워크인 NestJS 를 활용한 모노레포 구성을 진행해보겠습니다. 가끔 NestJS를 Spring 프레임
jojoldu.tistory.com
2. NestJS & TypeORM 환경에서 Monorepo 구성하기 - TypeORM 추가하기
지난 시간 에 이어, Monorepo로 구성된 프로젝트에 TypeORM을 추가해보겠습니다. 1. 환경 설정 저 같은 경우 PostgreSQL을 사용할 예정이라 pg 를 기반으로 진행하겠습니다. 필요한 패키지들을 먼저 추가
jojoldu.tistory.com
모노레포
프로젝트 구조를 구성하는 방식 3가지가 위에 나와있다. 모놀리스, 멀티레포, 모노레포이다.
simsimjae.medium.com
'Project > 서버 개발' 카테고리의 다른 글
| [Project] 프로젝트 삽질기23 (feat Enum) (0) | 2022.04.22 |
|---|---|
| [Project] 프로젝트 삽질기22 (feat Exception) (0) | 2022.04.21 |
| [Project] 프로젝트 삽질기20 (feat Node 버전 관리) (0) | 2022.04.18 |
| [Project] 프로젝트 삽질기19 (feat if else 리팩터링) (0) | 2022.04.13 |
| [Project] 프로젝트 삽질기18 (feat 쿼리 튜닝, 인덱스) (0) | 2022.04.11 |
