[CS] 모노레포, 모놀리식 아키텍처, 멀티레포, MSA, 마이크로서비스 아키텍처

오늘은 프로젝트 아키텍쳐 관련하여 정리하고자한다.

순서

1. 모놀리식 아키텍처
2. 모놀리식 단점
3. 마이크로서비스 아키텍처 MSA
4. 멀티레포 장점
5. 멀티레포의 단점
6. 모노레포

---

모놀리식 아키텍처, Monolithic Architecture

모놀리식 아키텍처는 전통적인 소프트웨어 프로그램 모델이다. 위의 사진처럼 하나의 서비스를 위해 모든 코드와 프론트/백엔드, 로직 등 한곳에서 관리하고 빌드/배포 운영 하는 것이다. 보통 프로젝트 초기에는 코드 관리, 인지 오버헤드 및 배포의 용이성 면에서 모든 것을 한꺼번에 릴리스할 수 있기 때문에 처음 시작하는 작은 스타트업같은 경우나 소규모의 프로젝트는 흔히 모놀리식 아키텍처로 많이 진행한다고 하고 지금도 많이 쓴다.

모놀리식 단점

하지만 한곳에서 관리하기 때문에 코드관리가 매우힘들고 업데이트 사항이 생길때 여러 사람들과 진행한다고 할때 관리가 쉽지 않게 된다. 만약 한명은 백엔드를 수정하고 있고 한명이 프론트엔드 클라이언트 페이지를 수정하고 있다고 한다면 급하게 클라이언트 페이지에서 에러가 나서 수정하여 배포를 해야하는 상황이라고 생각해보자. 프론트엔드는 자기가 빠르게 처리하여 배포하여야하지만 백엔드와 묶여있기 때문에 최신화되지 않는 버전으로 진행할 수 없기 때문에 기다려야한다. 또한 기술스택이 한정적일 수밖에 없고 독립적으로 원하는 스택을 사용할 수없다. 가잔 보편적인 경우가 Spring MVC의 JAVA+ JSP 이다. 현재 다니고 있는 회사에서도 이러한 방식으로 진행하다가 규모와 관리성을 위하여 내가 들어올 당시 이러한 아키텍처를 MSA로 수정하기로 했다.

Micro Service Architecture, MSA 마이크로서비스 아키텍처

모놀리식 아키텍처의 단점이나 한계로 인해서 생겨난것이 Micro Service 아키텍처이다. 요새는 흔하게 사용되고 있지만 많은 개발자가 현재 진행하고 있는 아키텍처가 MSA 인지 모르고 진행하는경우도 있다. 이에 따라서 우리는 어떠한 흐름으로 프로젝트를 진행하였고 무엇이 MSA인지 설명해보자.

먼저 현재 우리가 프론트엔드, 백엔드를 나눠서 진행하게 될때 기본적으로 프로젝트 형식은 Micro Service Architecture, MSA 로 진행하게 된다고 생각하면 된다. 우리는 단순히 리액트, 뷰, 앵귤러라는 라이브러리/프레임워크를 사용하여 기본적으로 만들어주는 프로젝트 기반으로 서비스를 만들고 이를 github에서 브랜치전략에 맞게 코드를 형상관리(버전관리)를 하게되고 배포를위해서 수동으로 build 하여 AWS 나 Firebase, vercel 등등 배포관련 클라우드를 제공하는 곳에서 이 빌드파일을 자신들의 서비스에 대하여 배포하여 IP,DNS 를 얻게 된다. 또는 CI/CD를 통하여 빌드와 배포를 자동으로 이루어지게 한다.

이러한 서비스에 대한 DB가 필요하다면 백엔드파트에서 서버를 만들고 해당 서버 주소와 각 end point API를 프론트에게 제공하여 데이터를 사용하게 된다. 이렇게 한 서비스에 대하여 프론트와 백엔드를 한개씩 구축하여 별도로 대응되게 된다.
이를 Micrco Service Architecture(MSA로 줄여 쓰겠다)로 프로젝트를 진행했다고 말해야한다. 만약 이러한 서비스를 위해 서비스별 레퍼지토리를 가져 레퍼지토리가 2개이상이라면 MSA로 이루어진 각각 레퍼지토리를 갖는 멀티레포(Multirepo)라고 생각하면된다.

아래의 그림을 통해 어떠한 구조인지 이해할 수 있다.

예를들어 어드민 페이지 와 고객 페이지를 갖는 서비스라고 했을때 별도의 어드민 레퍼지토리 와 고객 레퍼지토리를 만들어 진행하게 된다.
경로는 예를들어 어드민은 admin.Testservice.com 로 배포하여 운영하고, 고객은 customer.TestService.com 이라고 배포하여 운영한다고 했을때 각각의 MSA 형식으로 구조를 만들어 관리한다고 생각하면 된다. 서비스는 하나지만 그에 대응하는 레퍼지토리가 2개 이므로 이를 멀티레포 라고 한다.

MSA, 멀티레포의 장점

또한, 만약에 어드민 페이지와 고객페이지의 사용하는 기술스택이 달라야하고 해당 서비스에 대해서 최적화된 라이브러리/프레임워크로 진행해야한다고 할때 위와같은 그림으로 이루어지게 될것이다. 따라서 MSA로 멀티레포로 운영시에 각각의 기술스택 선택에 있어서 영향을 받지 않기 때문에 매우 자유롭고, 팀원들과 코드관리에 있어서 서로 다르게 진행하기 때문에 의존성이 적고 각자의 퍼포먼스를 내기 좋다.복잡하지 않고 독립적으로 빌드/배포가 가능하기 때문에 빠른 생산성과 쉬운 관리성을 갖는다.

멀티레포 단점

그런데 이렇게 좋은 멀티레포로 진행하다보면 많은 단점들도 있었다. 만약 한 서비스가 10개이상의 레퍼지토리를 갖는다고 생각하거나 지속적으로 새로운 서비스를 위해 레퍼지토리를 추가하여 패키지관리를하고 셋팅에 필요한 부분들이 계속해서 중복생성한다고 했을때 이를 위해서 들여야하는 시간은 여간 귀찮기도하고 소요도 많이 된다. 그렇다고해서 ZIP 파일로 셋팅한 부분에대해서 수동으로 저장하고 사용한다고 하더래도 웹팩관리, 추가적인 라이브러리나 빠져야하는 라이브러리, 해당 라이브러리들의 다른 버전을 사용해야한다고 하면 조금만 바꿔야할때도 일일히 수정해야하기 때문에 불편하다.

또한 어드민 페이지와 고객페이지에서 중복되는 코드가 있다면 같은 코드를 중복해서 사용하지만 다른 스타일로 만드는등 한다면 추후에 서로 협업하거나 이해해야하는 관계가 생길때 또는 통일을 위한 리펙토링을 해야한다고 할때 매우 힘들게 된다. 너무 독립적이다 보니 서로 멀어지는 현상이 발생하는 것이다. 예를들어 같은 API 통신을 사용한다고 했을때 이를위해서 굳이 어드민/고객을 나눠서 사용할 필요가 없고 같이 사용하면 되는데 멀티레포에서는 그렇지 못하기 때문이다.

모노레포

이러한 단점들로 인해서 모노레포 라는 개념이 생기게 되었다. 위의 사진처럼 각각 독립된 레포지토리를 사용하는게 아닌 하나의 레퍼지토리로 모든 프로젝트를 관리하는 모노레포를 도입하게 된다. 모놀리식, Monolithic 아키텍처와 혼동하면 안되는데 모노레포는 레퍼지토리만 하나로 사용할뿐 개별적으로 패키지를 관리하고 빌드/배포가 가능하다. 공용으로 사용할 패키지들이나 컴포넌트, API 등을 범용적으로 사용할 수 있고, 별도로 다른 패키지나 버전을 사용한다고 했을때는 해당 프로젝트안에서의 package로 관리 업데이트할 수 있기 때문에 매우 유용하다.

결론: 모놀리식 -> MSA, 단일레포 -> 멀티레포 -> 모노레포

이러한 이유로 모노레포를 도입하게 되었다. 다음에는 어떻게 모노레포를 구현하고 관리 하는지에 대해서 설명하도록 하겠다.