[프로젝트 관리] 리포지토리 전략

2024-04-12 hit count image

프로젝트를 관리하기 위한 리포지토리 전략인 모놀리스(Monolith), 멀티 레포(Multi Repo), 모노레포(Monorepo)에 대해서 알아보도록 하겠습니다.

개요

프로젝트를 개발할 때, 하나의 리포지토리로 구성할지, 여러 리포지토리로 구성할지 리포지토리 전략을 정하게 됩니다. 이번 블로그 포스트에서는 프로젝트를 관리하기 위한 리포지토리 전략인 모놀리스(Monolith), 멀티 레포(Multi Repo), 모노레포(Monorepo)에 대해서 알아보도록 하겠습니다.

블로그 시리즈

이 블로그는 시리즈로 제작되었습니다. 다음 링크를 통해 다른 블로그 포스트도 확인해 보시기 바랍니다.

리포지토리 전략

리포지토리 전략에는 다음과 같이 모놀리스(Monolith), 멀티 레포(Multi Repo), 모노레포(Monorepo)가 있습니다.

Repository strategy
  • 모놀리스: 모놀리스는 하나의 서비스를 하나의 프로젝트로 만들고 하나의 리포지토리로 관리하게 됩니다.
  • 멀티 레포: 멀티 레포는 하나의 서비스를 여러 프로젝트로 나누고 여러 리포지토리로 관리하게 됩니다.
  • 모노레포: 모노레포는 하나의 서비스를 여러 프로젝트로 나누고 하나의 리포지토리로 관리하게 됩니다.

모놀리스(Monolith)

모놀리스(Monolith)는 소프트웨어 프로젝트를 단일한 코드베이스로 구성된 단일 애플리케이션으로 설계하는 프로젝트 관리 기법입니다. 모놀리스 아키텍처에서는 애플리케이션의 모든 컴포넌트가 하나의 코드베이스에 통합되어 개발, 배포, 운영이 이루어집니다.

모놀리스의 장점

  • 간편한 관리와 유지보수: 단일 코드베이스로 구성되어 있기 때문에 전반적인 관리와 유지보수가 비교적 간편합니다.
  • 통합 테스트 용이성: 전체 시스템이 하나의 단일 애플리케이션으로 구성되어 있어 통합 테스트가 용이합니다.
  • 초기 개발 속도 향상: 처음에는 모든 것이 한 곳에 있어 개발이 빠르게 진행될 수 있습니다.

모놀리스의 단점

  • 확장성 제약: 애플리케이션의 크기가 커질수록 확장이 어려워질 수 있습니다.
  • 기술 스택 종속성: 단일 기술 스택에 의존하게 되어 다양한 기술 도입이 어려울 수 있습니다.
  • 배포의 어려움: 전체 애플리케이션을 수정하고 배포해야 하기 때문에 작은 변경 사항의 배포가 어려울 수 있습니다.

모놀리스 도입시 고려 사항

다음과 같은 경우라면, 모놀리스 도입을 고려해볼 수 있습니다.

  • 작은 규모의 프로젝트: 작은 프로젝트라면 초기에 개발 속도를 높일 수 있습니다.
  • 쉬운 유지보수가 필요한 경우: 간단한 애플리케이션에서는 유지보수가 편리할 수 있습니다.
  • 기술 스택이 명확한 경우: 특정 기술 스택에 대한 확고한 결정이 내려진 경우 모놀리스가 유용할 수 있습니다.
  • 팀 규모가 작은 경우: 작은 팀이 협업하고 개발하는 경우에는 모놀리스가 효과적일 수 있습니다.

그러나 프로젝트의 규모와 요구사항이 증가할수록, 분산 아키텍처나 마이크로서비스 아키텍처 등 다른 아키텍처도 고려해야 합니다. 이는 애플리케이션의 확장성, 유연성, 독립성 등을 높여줄 수 있습니다.

멀티 레포(Multi Repo)

멀티 레포(Multi Repo)는 소프트웨어 프로젝트를 여러 개의 독립적인 저장소(리포지토리)로 나누어 개발하는 프로젝트 관리 기법입니다. 각각의 저장소는 특정 기능, 모듈 또는 서비스에 대응하며, 개발, 배포, 운영이 분리되어 이루어집니다.

멀티 레포의 장점

  • 독립적인 개발 및 배포: 각 저장소는 독립적으로 개발, 테스트, 배포될 수 있어 빠른 개발 주기가 가능합니다.
  • 스케일링 용이성: 특정 모듈이나 서비스의 부하가 증가하면 해당 저장소만 확장하여 시스템의 전반적인 성능을 향상시킬 수 있습니다.
  • 기술 스택 다양성: 각 저장소는 독립적인 기술 스택을 선택할 수 있어, 특정 기술에 의존하지 않고 여러 기술을 조합하여 사용할 수 있습니다.
  • 분리된 코드베이스: 각 저장소는 특정 기능이나 업무 영역에 집중되어 코드의 가독성과 유지보수가 향상될 수 있습니다.

멀티 레포의 단점

  • 종속성 관리의 어려움: 다양한 저장소 간에 종속성을 관리하는 것이 복잡할 수 있습니다.
  • 전체 시스템 통합의 어려움: 각 저장소가 독립적으로 개발되다가 통합할 때 충돌이 발생할 수 있으며, 이를 해결하는 데 시간이 소요될 수 있습니다.
  • 종합적인 시각의 부재: 전체 시스템을 이해하고 관리하기 어려울 수 있으며, 특히 통합된 시각이 필요한 경우에는 어려움이 있을 수 있습니다.

멀티 레포 도입시 고려 사항

다음과 같은 경우, 멀티 레포 도입을 고려해볼 수 있습니다.

  • 대규모 프로젝트: 프로젝트가 크고 다양한 기능이나 모듈을 포함하는 경우, 각각을 독립적으로 관리할 필요가 있을 때 사용할 수 있습니다.
  • 팀 간 협업: 여러 개의 팀이 동시에 작업을 수행하고 서로 독립적으로 개발하려는 경우, 멀티 레포가 효과적일 수 있습니다.
  • 서비스 지향 아키텍처(SOA) 또는 마이크로서비스 아키텍처: 멀티 레포는 각각의 서비스를 독립적으로 관리하는데 유용하며, 이는 SOA 또는 마이크로서비스 아키텍처와 잘 맞을 수 있습니다.

멀티 레포는 분산된 환경에서 팀의 협업과 빠른 개발 주기를 지원하는데 적합하며, 특히 서비스 지향 아키텍처에서는 각각의 서비스를 개별적으로 관리하는 것이 중요하게 여겨집니다.

하지만, 팀 규모가 작거나 프로젝트 규모가 작은 경우, 너무 많은 기술 스택과 리포지토리 관리의 어려움이 발생할 수 있습니다.

모노레포(Monorepo)

모노레포(Mono-repo)는 소프트웨어 프로젝트를 하나의 대규모 코드 저장소(리포지토리)로 구성하여 개발하는 프로젝트 관리 기법입니다. 이 방식에서는 모든 소스 코드, 라이브러리, 모듈이 하나의 중앙 위치에 저장되고 관리됩니다.

모노레포의 장점

  • 종속성 관리 용이: 하나의 코드베이스에서 모든 종속성을 관리하므로 의존성 충돌 및 버전 관리가 용이합니다.
  • 전체 시스템 이해 용이: 프로젝트의 전반적인 구조와 동작을 이해하기 쉽습니다. 전체 시스템을 한눈에 파악할 수 있습니다.
  • 코드 재사용성: 모든 모듈 및 라이브러리가 하나의 저장소에 있으므로 코드 재사용이 쉽습니다.
  • 통합 테스트 용이성: 전체 시스템에 대한 통합 테스트가 간편하게 수행될 수 있습니다.

모노레포의 단점

  • 대규모 프로젝트 관리 어려움: 프로젝트의 규모가 커질수록 빌드 시간이 증가하고, 모든 코드에 대한 팀 간의 협업이 어려워질 수 있습니다.
  • 기술 스택 선택의 제약: 하나의 저장소에서 작업하기 때문에 특정 기술 스택에 제약을 받을 수 있습니다.
  • CI/CD 성능 저하: 대규모 모노레포에서는 지속적 통합 및 배포 성능이 저하될 수 있습니다.

모노레포 도입시 고려 사항

다음과 같은 경우, 모노레포 도입을 고려해볼 수 있습니다.

  • 프로젝트가 중소 규모일 때: 규모가 작은 프로젝트에서는 하나의 저장소로 관리하는 것이 편리할 수 있습니다.
  • 팀 간 협업이 필요한 경우: 모든 팀이 하나의 저장소에서 작업하면 코드 공유 및 협업이 용이합니다.
  • 종속성 관리가 중요한 경우: 프로젝트 내에서 종속성이 복잡하게 얽혀 있을 때 모노레포가 관리하기 쉽습니다.
  • 단일 기술 스택 사용이 필요한 경우: 특정 기술 스택을 일관되게 사용해야 할 때 모노레포가 적합할 수 있습니다.

모노레포는 특히 작은 규모의 프로젝트나 팀 간 협업이 필요한 경우에 유용하며, 특정 기술 스택을 통일해야 하는 경우에도 효과적일 수 있습니다. 그러나 프로젝트의 규모나 복잡성이 증가하면서 모노레포의 한계가 나타날 수 있습니다.

완료

이번 블로그 포스트에서는 프로젝트 관리 기법인 리포지토리 전략에 대해서 알아보았습니다. 특정 전략이 좋고 나쁘고는 없습니다. 자신의 프로젝트의 규모와 요구사항에 맞게 적절한 전략을 선택하시면 됩니다.

제 블로그가 도움이 되셨나요? 하단의 댓글을 달아주시면 저에게 큰 힘이 됩니다!

앱 홍보

책 홍보

블로그를 운영하면서 좋은 기회가 생겨 책을 출판하게 되었습니다.

아래 링크를 통해 제가 쓴 책을 구매하실 수 있습니다.
많은 분들에게 도움이 되면 좋겠네요.

스무디 한 잔 마시며 끝내는 React Native, 비제이퍼블릭
스무디 한 잔 마시며 끝내는 리액트 + TDD, 비제이퍼블릭
[심통]현장에서 바로 써먹는 리액트 with 타입스크립트 : 리액트와 스토리북으로 배우는 컴포넌트 주도 개발, 심통
Posts