Multi Repository vs Mono Repository 회고

같은 부서내의 예전 프로젝트에서 Mono-repository로 개인 경험으로 1년간 개발 해보고 (프로젝트 자체는 3~4년 정도 진행했습니다)

대략 2년간의 현재 프로젝트를 Multi-Repository로 개발 해 본 경험을 바탕으로 회고를 해봤습니다.

예전 프로젝트의 Repository 사용 방식

1. 기존에는 대략 3~4년간 여러 모듈이 mono repository에서 개발 되었습니다.

• 그러다 보니 mono-repo에 대한 반감이 어느정도는 있었던것 같습니다.

2. Public Github를 사용 하고 있어 AWS로 CI/CD 인프라를 구축하고, Github Actions로 CI/CD를 사용하고 있었습니다.

새로운 프로젝트를 진행함에 따라서 위의 경험에 더불어 아래와 같은 요구사항이 있었는데요.

 

Multi-Repository로 개발을 하고자 하는 요구사항

1. 기존 프로젝트는 여러 모듈이 하나로 결합해서 진행하다보니 Merge Conflict에 대한 경험/두려움

• 좀 더 정확하게는 내 일을  되는데에 방해 받고 싶지 않다에 가까운 내용인듯합니다.
• Mono-repo 방식으로 개발 했을 때의 부정적인 경험이기도 하구요.

2. 여러 부서가 새로운 기능을 개별적으로 개발하고 싶은 욕구

• 1번과 비슷한 요구사항이나 개별 Repository (서비스)로 분리함으로써 생산성 및 추가 기능을 쉽고 개별적으로 modular하게 개발해보자 이런 개념에 가까운것 같습니다.

3. 소프트웨어 개발자로써 마이크로서비스 개발 욕심

• 외부 서비스들에서는 마이크로서비스를 많이 도입하는데 우리도 도입해보자에 가까웠던것 같습니다.
• 당연히 장점은 1,2를 포함하긴하지만, 우리 프로젝트와 팀 규모/실력에 어울리는가는 크게 고려하지는 않았던것같습니다.
  • 하면 하지! 정도의 마인드라고하면 좋을지요 ㅎㅎ

4. Repository 별로 개발 언어를 달리 할 수 있음

• Repository가 분리 되어 있으니 당연하게도 각자가 필요한 언어로 사용할 수 있습니다.
• 물론 Mono-repo 방식도 별도 디렉토리를 갖게하면 불가능하지는 않으나 깔끔하지는 않을 수 있습니다.

5. 모듈별로 개발 버전 및 이미지를 생성할 수 있음.

• 우리는 Docker-like 서비스를 개발했으므로 메인 모듈 및 다른 모듈에서 서로 다른 산출물을 생성하도록 할 수 있었습니다.
• 이것은 장점이 될 수도 있고 단점이 될 수도 있었습니다.
• 3번과도 일부 연관이 있습니다.

 

위와 같은 요구사항이 있어서 multi-repo를 도입 하도록 개발자들의 여론이 이루어졌던것으로 기억합니다.

(대략 2년전이라 정확하지 않긴합니다)

또한, 이 논의를 할때 주로 아키텍트, 리더 레벨에서만 논의를 했기에 제가 논의한 주체는 아니여서  multi-repository 방식의 어떤 단점들을 고려했는지는 정확하게 모르겠습니다.

 

그래서 multi-repo의 구조는 어떻게 되어있느냐고 하면 아래와 같은 그림으로 표현 가능했습니다.

Multi-Repository의 초기 개발 구조 

Multi-Repository로 가자는 의견대로 개발은 했으나, 딱히 Repository의 구조를 제시해주지는 않았습니다.

개발자들 재량으로 대략 2달간 아래와 같이 개발되었습니다. (2023년 7월쯤)

Repository 설명

1. Packaging repository : Document Repository를 제외한 모든 모듈을 포함하여 패키징 하는 Repository, E2E 테스트 CICD 동작 하는 곳 (공통 개발)
2. Document Repository : 모든 repository의 통합이 힘들어 하나의 document repository를 두어 모든 doc 문서를 유지를 하는 곳
3. Main Module 1 : 주요 모듈을 개발하는 목적 (내부 부서 1), Docker like 서비스입니다.
4. Main Module 2 : 주요 모듈을 개발하는 목적 (내부 부서 2)
5. Shared Library : Main module 1,2의 통신을 위해서 필요로 하는 공통 모듈 (내부 부서 1,2)
6. Build Repository : AWS 인프라에서의 빌드와 사내 개발망에서의 빌드 방식을 일원화 하기 위한 Repository

이렇게 설명이 가능합니다.

 

이 Repository 구조는 Multi-Repository 시작 후  2~3달 간 여기까지 개발을 진행 했기 때문이지 추가적인 다른 모듈을 개발한다면 훨씬 더 많은 Repository로 늘어날 가능성이 있었습니다.

따라서, 더 늘어날 경우 발생하는 문제들을 막기 위해서 Mono-Repository로의 재전환을 목표로 한 회의가 열렸습니다.

 

Mono Repo로의 재전환에 대한 논의

Multi-repository로 개발 도중에 발생하는 문제가 여럿 있어 재 논의를 진행했었습니다.

아래와 같은 문제들이 있었습니다.

Multi-Repository  방식의 문제점

1. 문서의 파편화

• 여러개의 Repository로 개발 하게 되어 각 Repository의 문서들을 통합적으로 관리 할수가 없었던 문제가 있었습니다.
• 공통 문서를 위해 문서 공통 repository를 만들고 관리 해야 했습니다.
• 그렇지 않으면 문서를 통합적으로 확인할 수 없고, 문서를 확인 하기 위한 시간이 많이 들었습니다.

2. 6~7개나 되는 git repo를 관리 해야 하는 문제

• 많은 Repository를 관리 한다는 부담을 개발자들에게 지워주었습니다.

3. repository의 개수가 늘어나는 만큼 관리가 필요한 CI/CD 파이프라인과 테스트 코드들

• 많아지는 Repository만큼 그 코드를 테스트하기 위한 별도 Github action 코드가 생겨나고, 테스트 코드/패키지들이 각자 Repository의 방식으로 생성되었습니다.
• 따라서, 개별 Repository의 CI/CD에 대해서는 각 부서의 DevOps 대응팀에서 별도로 관리하게 됩니다.
• 공통 모듈의 경우 주로 DevOps 관리자가 하게 되어 개발 + DevOps 팀의 부담이 추가 되었습니다.
• 그리고 Repository가 많아짐에 따라 최종 패키지 제품을 배포에 걸리는 시간이 선형적으로 늘어났습니다.

4. 많아지는 Repository 만큼 서로 어떤것을 개발하고 있는지를 확인하기 힘들다는 문제

• 어떻게 보면 당연한데 본인이 개발하고 있는 Repository 외의 기능은 뭐가 추가되는지를 확인하기 힘듭니다.
• 또한, 소통이 부족한 문화였어서 더 그랬을 수 있습니다.
• 그리고 메인 모듈 2개가 공통으로 개발하는 경우 비슷한 기능이 양쪽 Repository에 모두 들어갈수도 있습니다.

 

제가 생각했을때의 추가적인 문제는 하나 더 있었는데 아래와 같습니다.

저의 주관적인 의견입니다.

5. 사내에서는 Slack 등 메신저 앱을 사용하지 못해 사내 인프라와 연동되지 않아 생기는 이슈 대응 속도의 저하 

• 사내에서는 Slack등의 Github 및 다른 프로그램과 연동이 잘 되는 메신저를 사용할 수 없어서, 코드리뷰, CI/CD에 대한 Alert 방법이 전무해 이를 확인하기가 쉽지 않았습니다.
  • 다만, 만약에 Slack 등을 사용했다고 하더라도 잘 대응이 되었을것 같지는 않기는 합니다..
  • 이유는 일정 기간 Slack을 사용한 적이 있었는데, 팀 협업 메신저에 익숙하지 않은 것 + CI/CD 해결에 대한 관심도가 떨어졌던것 등의 이유로 대응성이 그렇게 좋지는 않던것 같습니다.
• 추가로 대부분의 경우 사내에서 사용하는 메신저만 확인하는 경향이 있어 해당 앱에 추가기능을 넣는 방법이 아니면 관심도가 많이 떨어지는 경향이 짙었다고 봅니다.
  • 다만, 사내의 메신저는 사실상 직접 만드는 앱을 허용하고 있지 않고
  • 가능한 앱도 있었으나 앱 만드는 과정이 상당히 까다로워 쉽게 개발을 진행하거나 접근할 엄두를 못내는 문제가 있습니다.
• Repository가 하나였다면 하나의 CI/CD만 보면 되니 이정도로 느리진 않았을것 같습니다.

 

논의의 결론

Multi-Repository 정책은 유지하는것으로 결정되었습니다.

 

(추정) Multi-repo를 Mono-repo로 합치는데도 시간이 필요하니 당시에는 MVP 제품 개발이 먼저지 개발 및 CI/CD 환경을 다시 바꾸는데에는 시간이 걸릴것이고 그게 아까웠을것으로 생각됩니다.

 그 우선순위에 따라 Multi-repo를 유지하도록 했던것 같습니다. 

  

다만, Multi-repo 정책의 단점으로 나온 부분을 해소하기 위해서 아래와 같은 추가 적인 결정사항들이 아래와 같습니다.

1. 통합 Repo 관리 방안은 추가로 아키텍트/시니어가 정책을 수립한다. (이후의 행보로 봤을 때는 추가로 논의되지는 않은거 같긴 합니다 ㅋㅋ;;)
2. Doc repository는 별도의 repo로 관리한다.
3. Mono-repo의 장점인 타 부서의 개발 현황 공유는 매주 Weekly를 통해서 공유하도록 한다.
   • 이 부분은 잘 지켜져서 현재까지도 Weekly Meeting으로 어떤 개발 사항이 진행되는지를 공유하고 있습니다.

 

그리고 이때의 논의에서 추가로 1년 6개월 정도가 지난 지금의 Repository 구조는 아래와 같습니다.

 현재의 Repository 구조

기존과 달라진 점은 추가적으로 3개정도의 module (repository)가 추가되었다는 것입니다.

그 중 2개는 외부 부서에서 개발된 Repository 입니다.

 

그리고 Document Repository는 기존의 경우 문서 및 배포를 둘 다 담당하는 Repository였으나

현재는 각 Repository에서 각각 문서를 관리하고 Document Repository는 배포만을 담당하도록 변경되었습니다.

이에 대한 내용은 아래 문서들을 읽어보시길 바랍니다.

우리 부서에 맞는 ADR (Architecture Decision Record) 템플릿 작성과 ADR 시스템 도입

우리 부서에 맞는 ADR (Architecture Decision Record) 템플릿 작성과 ADR 시스템 도입

ADR 도입기 - (2) Doc as a code의 Deploy, user guide와 SRS 관리 방법 검토

ADR 도입기 - (2) Doc as a code의 Deploy, user guide와 SRS 관리 방법 검토

 

 

나의 회고

여기서 부터는 제가 느낀점을 위주로 적어보려고 합니다.

 

실제로 개발하는 입장에서 느낀점

1. CI/CD를 관리하는 주체는 따로 있음

• 아무리 다양한 팀에서 동시에 개발할 수 있다고 해도 이 프로젝트를 메인으로 이끄는 팀이 대부분의 과정을 담당함. CI/CD는 사실상 메인 모듈 팀, 그중에서도 DevOps 관련 자들의 과제가 되었습니다.
• 이게 가장 큰 문제였던것 같네요.

 

2. 전체 CI/CD 파이프라인 중 테스트 코드 작성의 경우 일부를 해외 연구소에 넘겨 Offloading을 하려고함.

• 해외 연구소는 Github Actions를 많이 사용해보지 않아 대부분의 경우 협업시 우리에게 도움을 많이 요청했음 (Context Switching이 심할정도로 잦았습니다.)
• 해당 테스트 코드의 품질 또한 훌륭한지 의문이였습니다.
  • 테스트를 만든것 자체는 의미가 있으나, 자세히 보면 메인 팀에서 재사용하기 쉽지 않은 아쉬운 테스트 코드 퀄리티, 디버깅 하는사람을 고려하지 않은 과할정도로 많은 테스트 로그 등
• 테스트가 고장 난 경우에도 이게 어떤 문제 때문인지를 보기 위해서 분석해야 하는데 분석을 위한 시간이 더 많이 드는 경우가 많음.
  • 품질에 대한 의심이 있어 테스트가 잘못된 게 아닐까 하는 의심이 먼저 들 때가 많습니다.
• 다만 이것은 Multi-repo로 부터 발생한 문제인지는 아직은 잘 모르겠습니다.
• 하지만, Mono-Repo였다면 PR이나 테스트 등을 개발자들이 확인하기 쉽기에 봤을 확률이 높으니 이에 대한 관심이 더 많지 않았을까 생각이 듭니다.

 

3. 패키징 모듈의 경우 주로 AWS 인프라에서만 잘 도는 경우가 있었습니다.

• 패키징 방식이나 패키징 내용물에 대한 검증이 필요 한 경우 로컬 개발환경에서도 확인이 필요한 경우가 있습니다.
• 이를 해결하기 위해서 로컬 환경에서 똑같이 빌드를 하려고 하면 메인 모듈이 아닌 다른 모듈에서 로컬 개발 환경을 고려하지 않아서 생기는 문제가 있었습니다.
  • 이는 다른 모듈의 코드 문제인 경우가 많은데 이를 해결하기 위해서는 CI/CD를 잘 아는 사람이 본인 코드베이스가 아닌 코드들을 직접 보면서 버그 리포트 (혹은 수정까지)해서 유관부서에 해결을 요청 해야 합니다.
  • 마치 Mono-repo의 단점인 "Merge Conflict에 대한 경험/두려움" 을 빠르게 막지 못하고 나중에 막게되는 현상과 비슷합니다.
• 지금의 환경에서 생각을 해보자면 사내 개발환경과 일치하는 Github Runner를 추가로 두어 이런 현상들을 막아 볼수 있겠다는 생각이 듭니다.

 

4. 문서화의 경우 어떻게든 해결할 방법 있었으므로 크게 문제는 아니였던것 같습니다.

• 문서화를 쉽게 할 수 있도록 불필요한 프로세스를 없애고 문화를 만들어가는것 그게 어려운 일이지 문서화 및 배포 방법 자체가 어려운것은 아니었던 것 같습니다.

 

5. Repository를 나눌 정도의 마이크로 서비스는 우리 제품에는 어울리지 않고 불필요하다는 점

• 저도 당시에는 마이크로 서비스에 대한 선망(?) 혹은 기대감이 있었으나 실제로 우리 제품을 돌아봤을 때는 그정도 까지는 필요없지 않나 생각이 들었습니다.
  • 별도 관리 할 정도로 다양한 기능을 제공하지도 않고
  • 서로 개별 서비스로 동작하기도 힘들기에 그런식으로 개발하면 오히려 분리된 부분을 테스트 하기가 어려워 지는 문제가 있었던것 같습니다.

 

 

회고를 해봤을 때 개선 해야할 부분

1. 개발 문화와 그에 대한 인식

뭐가 문제인가를 고민 해 봤을때 우리는 아래와 같은 특징을 가지고 있었습니다.

• 실제로 본인에게 문제가 오지 않으면 미리 대비 하지 않는 점
  
  • 다만, 이것은 언젠가 누군가는 해결 해야 한다는 점
  • 그리고 빠르게 해결하지 않으면 추후에 더 오랜 디버깅 시간 및 사람이 필요하다는 점을 간과한 점인데 이를 시스템적으로 막을 방법이 있을지 고민해보면 좋을 것 같습니다.
• 성과로 인정받지 않으면 안하려는 문화
  • 실제로 영향을 준건지 아닌지는 모호합니다.
  • 그런 문화가 일부 있다고 생각은 들기는 하는데, 그게 실제 대응에 얼마나 영향을 미치는지는 수치적으로 표현 할수가 없네요.
• 애매하게 R&R을 나눠서 담당자가 명확히 나누어진 문화
  • CI/CD에 담당자가 있으면 같은 제품을 만들었음에도 불구하고 누구는 이슈 대응을 해야하고 누구는 안해봤으니 안해도 되는 인식이 무의식적으로 생기는 듯 합니다.
    • 테스트를 만들라해서 최대한 추가하기 쉽게 테스트를 만듭니다.
    • 테스트에서 문제가 생깁니다.
    • 테스트를 만드는 사람이 당신이니 당신이 1차적으로 문제를 확인하고 해결할 수 있으면 해결하라
    • 와 같은 순서로 일이 진행됩니다.
  • 프로젝트가 고도화 되면 될수록 이는 더 심해지죠
  • 그러면 리더 급 들도 문제가 생기면 빠른 해결을 위해 해봤던 사람에게 계속 이슈 해결을 줄 수 밖에 없습니다.
  • 미리부터 이런 인식을 깰 수 있도록 협업하는 문화, 서로 관심을 가지고 도와주는 문화가 정착되어있었으면 조금 달랐을까 생각이 들기도 합니다.

이런 문화라는게 사실은 회사/부서에서는 성과를 측정하는 방식에 영향을 받는다고 생각하기에
이런 문화를 잘 정착할 수 있도록 성과 지표를 리더급에서 잘 세우는 고민이 필요하다는 생각이 듭니다.

 

2. 우리는 어떤 제품인지에 대한 정확한 인식

• 우리 제품은 어떤 고객을 대상으로하고 어떤 제품을 제공할 것인지 정확하게 이해 했다면 굳이 Multi-repo라는 선택을 했을까 의문이 듭니다.
  • 개별 서비스가 각각 필요에 따라서 Scale-up 이 가능한 서비스가 아닌데 말이죠

 

처음부터 Mono-Repo로 가져 갔으면 생기지 않았을 문제를 불필요하게 겪은 느낌은 들기는 합니다.
하지만, 한편으로는 경험/지식이 부족해서 겪어보지 않고는 몰랐던게 많아 어쩔수 없는 부분이라고 생각이 듭니다.

 

이 회고를 바탕으로 비슷한 고민을 할 때 더 좋은 방향으로 갈 수 있도록 될 수 있으면 좋을것 같습니다.