서론

회사에서도 사용할 계획을 갖고있고, 개인 프로젝트들도 하나의 저장소에서 관리를 하면 좋겠다는 생각으로 공부를 시작했어요. 이 글에서는 단순히 Monorepo(=모노레포)가 무엇인지에 대해서 알아보겠습니다.

본론

모노레포와 어울려보아요.

모노레포는 여러 개의 프로젝트들의 관계를 명확히 정의하여, 하나의 저장소에서 관리하는 방법을 이야기 합니다. 그리고 하나의 프로젝트를 하나의 저장소에서 관리하는 방법을 polyrepo(=폴리레포)라고 부릅니다. 이 글에서는 모노레포의 반대가 되는 개념을 폴리레포라고 가정하여 이야기 해 보겠습니다.

저는 지금까지 개발을 하면서, 괘나 많은 프로젝트를 시도해 본 것 같아요. 이렇게 개발을 하는 사람이라면, 아마도 단 한 건의 개발만 하지는 않을 것입니다. 아래에는 여러 건의 프로젝트를 시도할 때에 대한 내용으로 봐주세요.

폴리레포 방식으로 여러 건의 프로젝트를 개발 한다면, 아래와 같은 특징이 있어요.

• 다른 프로젝트의 내용을 공유하려면 배포나 버저닝과 같은 꽤나 번거로운 작업을 해야합니다.
• 공통적인 기능을 수행하는 코드의 작성을 여러 프로젝트마다 해야합니다.
• 여러 프로젝트에서 같은 라이브러리를 사용한다면, 라이브러리의 버전들을 관리 해야합니다.
• 프로젝트의 설정이나 린팅, 빌드와 같은 명령어들을 각각 따로 관리해야 합니다.

(너무 안좋게 말 한 것 같지만, 맞는 말이긴 하네요…😵‍💫)

반면에, 모노레포 방식으로 여러건의 프로젝트를 개발 한다면, 아래와 같은 특징이 있어요.

• 같은 저장소에 있는 프로젝트 끼리는 내용을 공유하기 위해서 배포나 버전닝과 같은 번거로운 작업을 하지 않아도 됩니다.
• 공통적인 기능을 수행하는 코드의 작성은 딱 한 번만 하면 됩니다.
• 같은 저장소 내에서 같은 라이브러리를 사용한다면, 모든 프로젝트에서 사용하는 라이브러리의 버전을 관리하는 것이 용이합니다.
• 같은 저장소 내에서 프로젝트의 설정이나 린팅, 빌드와 같은 명령어들을 딱 한 곳만 보고 관리하면 됩니다.

모노레포에 대해서 굉장히 좋게 작성을 해 보았습니다. 그렇다면, 무조건 모노레포가 좋을까요? 그냥 전세계에 있는 모든 프로젝트들을 하나의 저장소에서 관리하면 될까요? …ㅎㅎ 당연히 아니겠죠.

본론의 가장 첫 문장에서 이야기하였던 “모노레포는 여러 개의 프로젝트들의 관계를 명확히 정의하여, 하나의 저장소에서 관리하는 방법을 이야기 합니다.“라는 말처럼 모노레포는 명확히 정의할 수 있는 관계를 갖는 프로젝트의 집합이어야 합니다.

만약에 아래와 같은 프로젝트들을 모노레포로 관리한다고 생각해 볼게요.

1. React와 typescript로 개발된 웹 프론트엔드 프로젝트, 할일목록을 작성합니다.
2. Java spring으로 개발된 웹 백엔드 프로젝트, 오픈 마켓의 유저 정보를 관리합니다.
3. Rust로 개발된 CLI 프로젝트, 오늘 먹을 저녁 메뉴를 추천해 줍니다.

각 프로젝트의 관계, 혹은 공통된 집합을 찾을 수 있나요? 저는 프로그램이라는 것 말고는 찾을 수가 없네요.

이러한 프로젝트들을 과연 같은 저장소에 둔다고 해서 위에서 이야기한 특징이 이점이 될까요?

• 같은 저장소에 있는 프로젝트 끼리는 내용을 공유하기 위해서 배포나 버전닝과 같은 번거로운 작업을 하지 않아도 됩니다.
  • → Java로 작성된 내용을 Typescript로 작성된 프로젝트로 내용을 공유하기도 어려울 뿐만 아니라, 도메인이 너무 다른 주제이다보니, 공유할만한 로직 또한 많지 않을 것 같습니다.
• 공통적인 기능을 수행하는 코드의 작성은 딱 한 번만 하면 됩니다.
  • → 언어가 모두 다르기 떄문에, 코드를 공유할 수 없습니다.
• 같은 저장소 내에서 같은 라이브러리를 사용한다면, 모든 프로젝트에서 사용하는 라이브러리의 버전을 관리하는 것이 용이합니다.
  • → 허허허…
• 같은 저장소 내에서 프로젝트의 설정이나 린팅, 빌드와 같은 명령어들을 딱 한 곳만 보고 관리하면 됩니다.
  • → 나는 뭐가 뭔지 모르ㄱㅔ다ㅏ@$%

어지럽네요. 😵‍💫

그렇다면, 아래와 같은 프로젝트들을 모노레포로 관리한다고 생각해 볼게요.

1. React와 Typescript로 개발된 웹 프론트엔드 프로젝트, 할일 목록을 작성합니다.
2. NestJs(node.js)와 Typescript로 개발된 백엔드 프로젝트, 할일 목록을 작성합니다.
3. React와 Typescript로 개발된 웹 프론트엔드 프로젝트, 일기를 작성합니다.

위 프로젝트들은 과연 모노레포의 특징들이 이점이 될까요?

• 같은 저장소에 있는 프로젝트 끼리는 내용을 공유하기 위해서 배포나 버전닝과 같은 번거로운 작업을 하지 않아도 됩니다.
  • → 모두 Typescript로 작성이 되어 있기 때문에, 모든 내용은 쉽게 공유할 수 있습니다.
• 공통적인 기능을 수행하는 코드의 작성은 딱 한 번만 하면 됩니다.
  • → 이 또한 모두 Typescript로 작성이 되어 있기 때문에, 그리고 1번과 2번은 도메인이 같기 때문에, 공통적인 로직이 딱 한 번의 작성으로 공유가 될 수 있습니다.
• 같은 저장소 내에서 같은 라이브러리를 사용한다면, 모든 프로젝트에서 사용하는 라이브러리의 버전을 관리하는 것이 용이합니다.
  • → 히히히
• 같은 저장소 내에서 프로젝트의 설정이나 린팅, 빌드와 같은 명령어들을 딱 한 곳만 보고 관리하면 됩니다.
  • → React와 NestJS라는 점이 달라서 각 린팅 및 빌드 부분은 다르겠지만, Typescript를 사용함에 있어서 공통적인 린팅 및 빌드를 할 수 있습니다.

이처럼 1번, 2번 그리고 3번은 Typescript를 사용한다는 점에서 언어의 공통적인 관계를 형성하고, 1번과 2번은 도메인이 같다는 관계를 갖고 있기 때문에, 모노레포를 사용함에 있어서 이점이 생기죠.

이렇게 프로젝트들 끼리 적절한 관계를 가지고 있디면, 모노레포를 사용하여 모노레포의 이점을 누리는 것이 좋습니다. 지금까지 너무 장점만 이야기 하였는데, 왜 모든 사람들이 모노레포를 쓰지는 읺을까요? 아래와 같은 단점도 갖고 있기 때문입니다.

• 코드가 너무 커져 특정 코드를 찾는 것이 어려울 수 있고 코드가 너무 커져 버그를 찾고 수정하기가 어려울 수 있습니다.
• 빌드 및 테스트가 더 오래 걸릴 수 있습니다. 모노레포에 여러 프로젝트의 코드가 모두 저장되면 빌드 및 테스트가 더 오래 걸릴 수 있습니다. 이는 모든 코드를 빌드하고 테스트해야 하기 때문입니다. 이것은 특히 많은 프로젝트가 있는 경우 시간이 많이 걸릴 수 있습니다.
• 모노레포는 모든 팀 구성원이 모든 프로젝트에 액세스할 수 있어야 하기 때문에 보안 위험이 될 수도 있습니다. 이는 악의적인 팀 구성원이 프로젝트 중 하나에 침입하여 다른 프로젝트에 액세스할 수 있기 때문입니다.

결론

모노레포는 제대로 사용하면 매우 유용한 도구가 될 수 있지만 잘못 사용하면 프로젝트에 해를 끼칠 수도 있습니다. 따라서 프로젝트에 모노레포를 사용할지 여부를 결정하기 전에 장단점을 신중하게 고려하는 것이 중요합니다.

다음은 모노레포 사용을 고려하기 전에 스스로에게 물어봐야 할 몇 가지 질문입니다.

• 여러 팀에서 함께 작업합니까? 그렇다면 모노레포가 협업을 개선하는 데 도움이 될 수 있습니다.
• 여러 프로젝트에서 코드를 재사용합니까? 그렇다면 모노레포가 코드 재사용을 개선하는 데 도움이 될 수 있습니다.
• 저장소 크기가 너무 커지지 않을까 걱정되십니까? 그렇다면 모노레포는 좋은 선택이 아닐 수 있습니다.
• 코드가 너무 복잡해질까 걱정되십니까? 그렇다면 모노레포는 좋은 선택이 아닐 수 있습니다.
• 버그와 충돌 가능성이 너무 높아질까 걱정되십니까? 그렇다면 모노레포는 좋은 선택이 아닐 수 있습니다.

이러한 질문에 답한 후 모노레포가 프로젝트에 적합한지 여부를 결정할 수 있습니다.

참조

• https://monorepo.tools/