[Arch] MSA || Monlolithic

내가 경험한 프로젝트의 아키텍처들은 경력에 비해 상당히 다양하다.

우리 회사의 특성 상 정해진 솔루션이 있고 매번 똑같은 구조의 프로젝트만 경험할 것이라고 예상했으나 

고객사에 기존에 개발되어있던 Legacy 프로젝트가 있다면 꼭 그렇지 않다는 사실을 알게 되었다. 

 

내가 경험한 프로젝트 구조들은 다음과 같다.

 

1. 학원프로젝트

2. (React + Redux) Monolithic Arch.(MA)를 채용한 고객사의 Legacy 프로젝트

3. (React + Mobx) MSA 를 채용한 우리회사의 솔루션이 들어간 프로젝트

4. (React + React-Query) MSA(MonoRepo)를 채용한 우리 회사의 버전업 솔루션 프로젝트

 

이 중 오늘은 Monolithic Arch. 와 MSA간의 차이에 대해서 이야기해보고자 한다.

모두 내 경험을 바탕으로 모르는 부분은 구글링을 통해 주워들은 이야기이니 만약 틀렸다면 비난과 조언 감사히 받아들입니다.

 

1.Architecture?

적어도 최소한 신입 SI 개발자의 경우 아키텍처에 관련한 이야기를 듣기는 어려울 것이라고 생각한다.

사실 우리 회사가 특이한 것임에 분명하기 때문이다. 

아키텍처는 소프트웨어의 설계 다. 어떤 식으로 프로젝트를 구성하고, 구조를 어떻게 잡을 것인지 그런 것에 대한 이야기다.  

와닿지 않으니 일과 관련해서 예를 들자면, 어떤 식으로 패키지를 구분할 것인지, 전체적인 소프트웨어를 구상했을 때 어떤 데이터 전달 구조를 가지는 것이 가장 효율적일지, Git을 통한 협업 및 버전 관리 등에서 어떤 모양의 프로젝트가 관리가 용이할지 이런 문제에서 시작된 개념인 것이다. 

 

2. Monolithic Arch. (MA)

그렇다면 모놀리식 아키텍처는 무엇인가?

Monolithic의 사전적 정의는 "단단히 짜여 하나로 되어 있는" 이다. 

즉, 프로그램을 생각 했을 때도 하나의 프로젝트 내에 관련 컴포넌트를 모두 담고 있으며,

그 하나만으로 하나의 Application을 보여줄 수 있는 아키텍처이다. 

쉽게 말하면, 흔히 CRA를 통해 React App을 하나 만들면 나오는 그 기본 프로젝트가 MA라는 전통적인 어플리케이션의 모양이라고 할 수 있다. 

하지만 이 형태로 개발을 진행했을 경우, 장기적으로 추가적인 개발을 한다고 했을 때 프로젝트의 볼륨이 상당히 커지게 되며 그만큼 프로그램을 사용하는데에 부담을 갖게 된다. 또한, 이런 한계 때문에 확장의 용이성을 챙기기가 어려워진다는 단점이 생긴다. 

때문에 볼륨의 부담이 적은 소규모 프로젝트, 개발 후 추가적인 확장이 더 이상 생기지 않을 프로젝트 정도에 사용하기 좋은 아키텍처라고 보여진다.

 

 

3. MSA (Micro-Service-Architecture)

앞의 모놀리식을 생각하면 MSA에 대해서 유추할 수 있을 것이다.

모놀리식 아키텍처에서 발생하는 문제점들을 해결하기 위해 만들어진 아키텍처이다.

쉽게 얘기하면 하나의 Application을 여러 개의 Micro Service로 쪼개어 개발하는 형태이다. 

 

그렇기 때문에 실제 모든 컴포넌트를 통합해 라우팅해주고, 공통으로 사용될 기능, 공통으로 보여지는 컴포넌트를 가지고 있는 Main Application 하나와 실제 사용할 기능들을 담고 있는 Micro Service들로 구분하여 개발하게 된다. 

MA와 비교했을 때 당연히 MA의 문제점을 해결하기 위해 만들어졌다보니, 확장성이 용이하고 대규모 프로젝트를 할때도 Micro Service로 쪼개어지는 점 때문에 상대적으로 볼륨의 부담을 덜 수 있다는 장점이 있다. 

 

하지만 이 역시도 단점이 존재한다. 하나의 Application을 만들기 위해 구성해야하는 프로젝트의 수가 많다보니, 각 MS 를 개발하는 팀들 간의 의사소통이 어려워지고, 전체 Flow를 파악하는데 상당한 시간을 소요해야한다는 단점이 있다.