모노 레포(Monolithic Repository)

오늘은 모노 레포 구조에 대하여 소개해보려고 합니다.

회사에서 업무를 하다보면, 프로젝트 별로 레포를 구분하기도 하는데 프로젝트가 점점 많아지면서 레포지토리 갯수가 그만큼 많아지게 되면, 유지보수 측면에서는 점점 복잡하게 됩니다.

프로젝트가 나뉘어져서 레포지토리가 나뉘더라도, 사용하는 라이브러리나 코드는 비슷하다보니 모노 레포를 적용하면 훨씬 관리가 용이해지는 효과를 볼 수 있습니다.

 

아래의 링크는 'Why Google Stores Billions of Lines of Code in a Single Repository'라는 제목으로 구글에서는 왜 하나의 레포로 관리하고 있는지 설명하는 글입니다.

https://dl.acm.org/doi/pdf/10.1145/2854146

 

위의 글에서 설명하는 모노 레포의 장점을 좀 더 나열해보겠습니다.

- Unified Versioning: 버전 관리를 한 번에 할 수 있는 장점이 있습니다.

- Extensive Code Sharing & Reuse: 코드의 재사용과 공유가 용이합니다.

- Simplified Dependency Management: 라이브러리 버전 관리가 한 군데서 하기 때문에 단순해집니다.

- Atomic Changes: 동일한 변경 사항을 여러 프로젝트에 한 번에 적용하기 편리합니다.

- Large Scale refactoring: 여러 프로젝트에 걸친 대규모 리팩토링도 한번에 진행할 수 있습니다.

- Flexible Team Boundaries and Code Ownership: 팀 간 협업이나 코드의 오너쉽이 자유로워집니다.

 

단점도 적혀 있어서 한 번 정리해보겠습니다.

- Tooling Investments for Both Development and Execution: 개발 및 실행 환경이 거대해지는 단점이 있습니다.

- Effort Invested in Code Health: 오래된 라이브러리나 코드 관리를 계속 해야만합니다.

- Code Ownership: 오너쉽이 자유로워지면 오히려 책임을 서로 전배하는 등 문제가 될 수 있습니다.

 

장점과 단점을 한 번 소개해보았는데 제 경우에는 팀 내에서만 모노 레포 구조를 적용하고 있다보니 오너쉽에 대한 부분은 해당사항이 없고, 단점에 있는 개발 및 실행환경의 경우에는 파이썬으로 서빙을 위주로 하고 있다보니 개발 환경이 커지는 단점은 딱히 못 느끼고 있으며 오래된 라이브러리나 코드 관리에 대한 부분은 오히려 회사에서도 주기적으로 취약점에 대하여 조치를 하도록 안내하고 있었어서 원래 하던 것들이라 단점은 전혀 못 느끼고 위에 열거한 모든 장점만 누리고 있습니다.

 

구체적으로 소개해보면 fastapi로 서빙하는 코드들이 많은데 fastapi 관련된 설정들을 모두 한 곳에 유틸리티로 만들어놓고 가져다 사용하면서 각 프로젝트에서는 api만 구현할 수 있어서 너무 편하게 사용하고 있습니다.

 

모노 레포에 대하여 소개는 이쯤으로 하고, 깃헙에서 어떻게 구성하면 편하게 사용할 수 있는지 조금 더 소개해보겠습니다.

repository
├── project_A
│   └── code
├── project_B
│   └── code
├── utils
│   └── code
└── README

코드는 우선 위와 같이 공통 모듈로 사용하는 것은 utils로 구성해두고, 각 프로젝트를 디렉토리로 만들고 공통 모듈은 가져다 사용하는 구조로 코드를 구성하면 됩니다.

 

github actions를 사용하여 CI(Continuous Integration)을 구성할 때, 전체 대상이 아닌 각 프로젝트에 대해서 CI는 별도로 구성을 할 수도 있는데 그 부분도 조금 더 소개해보겠습니다.

github actions에는 paths 옵션을 활용하여 특정 디렉토리에 대한 수정이 있을 때만 실행되도록 조건을 설정할 수 있습니다.

# ci.yaml
name: ci - project A
on:
  push:
    paths:
      - 'project_A/**'
      - 'utils/**'
jobs:
  ....

위와 같이 paths 옵션을 구성하여 yaml 파일을 생성하게 되면, 위의 yaml파일은 project_A, utils에 변화가 있을 경우에만 실행되게 됩니다.

 

ml을 하다보면 워낙 프로젝트를 여러가지하게 되는 경우가 특히 많은 것 같은데, 그런 경우에는 모노 레포 구조를 적극 도입해보시면 유지 보수가 훨씬 용이해질 수 있으니 한번 고려해보시는게 좋을 것 같습니다.