안녕하세요 DeepBio에서 Backend 개발을 담당하고 있는 정현정입니다. 🐰

DeepBio는 인공지능을 활용한 의료데이터 분석 소프트웨어인 DeepDx를 제공하고 있습니다. DeepDx는 여러 마이크로 서비스로 이루어져 있습니다.

모놀리식 아키텍처에서는 애플리케이션 내의 모든 기능과 서비스가 단일 유닛으로 개발되고 운영됩니다. 이러한 방식은 개별 기능의 최적화를 어렵게 만들며, 특정 부분의 규모 확장이 어려워집니다.

서비스의 다양성과 규모 증가에 따라, 이러한 모놀리식 아키텍처의 한계를 극복하기 위해 마이크로서비스 아키텍처로 전환하는 것이 필요합니다.

DeepDx는 여러 마이크로 서비스로 구성되어 있으며, 각 마이크로 서비스의 소스 코드는 개별 저장소에서 관리되고 있었기 때문에 멀티 레포 방식이었습니다. 그래서 오늘은 이 멀티 레포 방식을 모노레포로 전환한 이야기를 해보려 합니다.

모노레포 도입 배경

각 마이크로 서비스의 개발이 멀티 레포 방식으로 관리되는 것은 각 서비스의 자율성을 높이지만, 그만큼 개별적인 개발, 린팅, 테스트, 빌드, CI/CD 파이프라인이 존재하게 됩니다. 이는 개발 프로세스의 독립성을 유지하는 편리함이 있는 대신 추가 비용이 발생할 수 있다는 단점도 가지게 됩니다.

요약하자면, 자율성은 고립으로부터 제공되지만, 고립은 협업을 방해할 수 있습니다.

DeepDx의 멀티 레포에서 발생한 어려움은 다음과 같습니다.

1. 통일성 없는 개발 규칙린팅, Git commit 메시지 작성 방식, Pull Request description 방식 등이 통일되어 있지 않거나, 통일되어 있더라도 각 규칙을 개별적으로 설정해주어야 하는 불편함이 있습니다.
2. 기능 개발 시 여러 서비스에 전부 코드 수정이 필요한 경우각각의 서비스마다 Pull Request(이하 PR)가 필요하며, PR 설명에 추가로 어떠한 Repository의 어떤 PR이 관련된 것인지 기재해야 합니다.
3. 서비스 간의 중복 코드공통으로 사용하는 기능이 각각의 저장소에서 개발되어 중복 코드가 증가합니다.
4. 제품 버전 관리의 복잡성 증가여러 Repository에서 개발된 개별의 서비스가 모여 한 제품이 될 경우, 버저닝을 매칭시켜주기위한 별도의 관리 문서가 필요합니다.
5. Git Submodule로 공유되는 패키지 관리 어려움서브모듈을 통해 공유되는 패키지를 관리하는 것이 어려움이 있습니다.

저희 개발팀의 개발 효율성을 현저하게 저해하는 이런 요소들을 파악하여 없애고, 개발 프로세스를 향상하기 위해 모노레포를 도입하기로 결정했습니다.

모노레포 도입

모노레포를 도입하는데에는 총 5가지 단계의 큰 산을 넘어야 하였습니다. 그 각각의 단계에 대해서 설명드릴게요!

Press enter or click to view image in full size

1. 기존 멀티 레포의 Git commit history와 함께 소스 코드 모두 합치기