서버와 클라이언트를 하나의 레포로 관리하면 모노레포인가?

이 글은 MSA 혹은 Monorepo를 실제 서비스에서 구축해본 경험이 없는 초보 개발자의 글입니다.
정확하지 않은 정보가 있다면 피드백 부탁드립니다.

 

모노레포는 서로 다른 프로젝트를 하나의 레포에 관리할 때 사용하는 전략이다.

 

여기서 서로 다른 프로젝트는 어떤 의미일까? 만약 할 일 관리 앱에서 클라이언트와 서버가 있는데 이를 하나의 레포에서 관리한다고 하면 모노레포 전략이 필요할까?

모노레포의 의의

모노레포는 MSA의 단점에서 나온 전략이다. Micro Service Architecture는 서비스, 즉, 프로젝트가 각각 분리되어있는 환경이다. MSA는 어떻게 나왔을까?

 

다이어리 앱을 만든다고 가정해보자. 다이어리에는 할 일 관리와 달력이 필요하다. 다이어리 앱이 점점 고도화되면서 할 일 관리와 달력이 점점 복잡해지고 있다고 생각해보자. 할 일 관리 서비스와 달력 서비스를 분리한다면 관리가 수월해질 것이다. 이 때 다이어리라는 하나의 서비스를 할 일 관리와 달력이라는 작은(micro) 단위의 서비스로 분리하는 것이 MSA다.

 

여기서 분리된 할 일 관리와 달력은 서로 다른 프로젝트로서 각각의 레포지토리를 갖는다. 이 다이어리 앱에서 새로운 서비스인 다이어리 꾸미기 기능을 추가한다면 어떻게 해야할까? 새로운 micro service가 필요하기 때문에 새로운 레포지토리를 만들고 그 서비스에 필요한 초기 환경 세팅을 해야한다. 새로운 서비스가 만들어질 때마다 이를 반복해야 하는데 이는 중복되는 일이다. 또한 각 프로젝트마다 의존성 관리를 따로 해줘야한다. 즉, 일의 중복 방지와 일관적 관리를 위해 모노레포가 등장했다. 모노레포는 재사용 가능한 모듈로 이루어진 모듈러 레포를 만들기 위해 다양한 전략을 사용한다.

 

다시 처음의 질문으로 돌아가보자. 할 일 관리 앱에서 서버와 클라이언트가 있다. 이를 하나의 저장소에서 관리한다면 모노레포 전략이 필요할까?

 

하나의 프로젝트에서 클라이언트와 서버는 중복되는 작업이 거의 없다. 있다고 해도 lodash나 Day.js 정도의 유틸성 라이브러리 뿐이다. 하나의 레포에 서버와 클라이언트가 같이 있다고 해도 서버에서 react 코드를 다시 만들일은 없고 클라이언트에서 express 코드를 다시 만들 일도 없다. 중복되는 라이브러리 사용이 적기 때문에 일관적 관리의 필요성도 적다. 단순히 서버와 클라이언트로 나뉜다고해서 굳이 모노레포 전략을 사용할 필요가 없다. 할 일 관리 앱에서 하나의 레포에 서버와 클라이언트에서 관리한다면 그것은 모노레포보다는 모놀리식(monolithic)에 가까울 것이다.

Monolith와 Monorepo는 서로 다른 저장소 전략이다 (사진 출처 : 참고자료 medium)

 

모놀리식(monolithic)은 단순히 하나의 저장소에 하나의 프로젝트가 있는 것이다. 다이어리 앱이 할 일 관리 서비스와 달력 서비스로 나뉘기 전, 아직 복잡하지 않을 때 하나의 프로젝트로 관리 될 때를 말한다.

 

정리하자면 하나의 레포(monolithic)로 관리되던 다이어리 앱이 고도화되면서 하나의 서비스가 작은 서비스로 분리하기 위해 나온것이 MSA(Micro Service Architecture)이고, 분리된 서비스를 관리할 때 생긴 비효율적 작업을 관리하기위해 Monorepo 전략이 나온 것이다. 규모에 따라 다르겠지만, 할 일 관리 앱에서 서버와 클라이언트가 나뉜다고 해서 모노레포 전략을 쓸 필요는 없을 것 같다.

 

참고 자료

Monorepo vs Multi-repo vs Monolith

모노레포 - 마이크로 아키텍처를 지향하며