아키텍처 설계에 대한 방법론 및 고찰

프론트엔드 아키텍쳐를 짜는 부분에 대해서 고민을 많이 하고 있다. 점점 더 커지는 애플리케이션의 규모, 예상할 수 없는 요구사항으로 언제 어떻게 변경될 지 모르는 코드 등 맞닥뜨리게 되는 여러 상황을 최대한 유연하게 대처하기 위해 다양한 방식을 공부하고 있고 공부한 내용을 정리하여 기록해놓겠다.

참고로 아래에 정리한 내용은 프론트엔드 소스를 설계한다 가정하고 학습하였음을 사전에 알린다. 

 

 

 

1. 가장 전통적인 형태, 모놀리스 아키텍쳐

 

Monolith는 사전적 의미로는 하나의 거대한 암석으로 된 기둥따위로 거대한 하나의 조직을 나타내기도 한다. 이런 의미와 같이 모놀리스 아키텍처는 단일 단위로 구성되어 있는 아키텍처로 모든 로직이 한 곳에 존재한다. 하나의 코드베이스가 존재하고, 하나의 배포 단위를 거치며, 하나의 프로세스로써 이루어지는 것이다. 

 

모놀리스 아키텍처는 이러한 구성으로 인해 몇 가지 장점을 가질 수 있다.

첫 째, 개발의 효율성이 높아진다. 하나의 코드베이스만이 존재하므로 전체적인 코드 구조를 파악하는데 상대적으로 빠르게 진행될 수 있고 또 중복되는 코드를 재활용하기에 용이하다.  

둘 째, 단순한 운영체계를 가짐으로 인프라의 관리가 편하고 디버깅과 테스트하기에 편리하며 이로 인해 관련된 비용 투자를 낮출 수가 있다.

셋 째, 빠른 개발 속도를 가질 수 있다. 위의 장점들을 기반으로 하여 모놀리스 아키텍처는 이래저래 별도의 복잡한 아키텍처의 구성없이 빠르게 원하는 목적에 금방 도달할 수 있다.

 

모놀리스 아키텍처의 모든 장점들은 사실 규모가 작거나 요구사항으로 인해 변경이 잦지 않는 프로젝트에서 유효한 편이다. 애플리케이션의 크기가 커지고 또 쉼없는 요구사항으로 인해 계속 변경되는 서비스라면 의존성 관리 등 코드의 관리가 점차 어렵게 되고 하나의 소스를 매 번 통째로 빌드하고 관리해야하는 방식은 다소 불편함을 야기할 수 있다.

 

그리고 시대가 흐를 수록 프로젝트나 서비스들은 그 규모가 커지면 커졌지 작아지는 일은 드물어지고 있다. 그에 따라 모놀리스 아키텍처는 점차 그 사용이 줄어들고 하나로 관리하는 모놀리스와 반대되는, 여러 개로 나누어 관리하는 마이크로 아키텍처가 대두되게 된다.

 

 

 

 

2. 마이크로 아키텍처

 

micro는 이 곳 저 곳에서 쓰여 정확한 뜻은 모르더라도 그 의미는 다들 알 것이다. 사전적 의미로는 작은, 소규모의 뜻으로 말그대로 작게 나누어져 있는 의미이다. 마이크로 아키텍처는 모놀리스와 반대로 하나의 서비스가 여러 단위로 구성되어 있는 아키텍처이다. 단위를 나누는 기준은 보통 기능 단위라 하지만 여러 글을 살펴보면 나누는 기준은 생각보다 다 제각각이었다. 어떻게 나누던 결국 하나의 서비스를 각각 독립적인 서비스들로 분해하여 관리하는 방식으로 각 서비스들은 자체적으로 관리되며 서로 통신하면서 최종적으로 전체적인 애플리케이션을 형성하게 된다.

 

< MFA? >

프론트엔드 코드를 분해하기 위해 마이크로 아키텍처를 찾다보면 MFA라는 말이 나오는데, 별거는 아니고 Micro Frontend Architecture의 준말로 그냥 마이크로 아키텍처에 맞춰 프론트엔드 구조를 짜는 것을 의미한다. 굳이 이렇게 이름을 별도로 가져온 것이 뭔가...재밌었다ㅎㅎ

 

마이크로 아키텍처를 구성함으로써 얻을 수 있는 장점은 아래와 같다.

첫 째, 코드의 의존성 관리가 용이해진다. 한 서비스가 여러 서비스로 분리되어 각 서비스 별로 관리되는데, 모두 독립적인 개체이다보니 처음부터 서로에게 의존성을 가지기가 어려운 구조를 갖추게 되어 의존성 관리가 간편해진다.

둘 째, 서비스를 쉽게 확장 할 수 있다. 서비스를 추가하여도 기존의 서비스들은 영향 받지 않기에 새로운 가능을 추가하여 문제가 일어나도 해당 부분만 조명하면 되기에 장애 관리적인 면에도 용이하다.

셋 째, 새로운 기술을 사용함에 부담이 없다. 각 서비스는 별도의 관리이기때문에 새로 추가되는 기능에 있어서는 기존의 기술 스택을 따라갈 필요없이 해당 기능에 가장 잘 맞는 기술 스택으로 새롭게 구성하여도 문제가 없다. 

 

이 밖에도 많은 장점이 있지만 결국 모든 장점은 마이크로 아키텍처의 분리된 구성이라는 특징으로 인해 형성되게 된다. 

마이크로 아키텍처로 코드를 설계하는 방법은 하나로 정해져있기보다는 다양한 방식이 있는데 멀티레포라던가 모노레포 등이 그 예시일 것이다. 

 

 

 

 

마무리

 

오늘 글은 애플리케이션의 아키텍처를 어떻게 구성할지에 대한 큰 구조를 바라보았다. 

아키텍처를 설계하는 데 공수를 들이는 것은 내가 만들고 있는 서비스가 언제 어떤 정책을 가지더라도 방해되지 않고 쭉 위로 성장할 수 있게 할 수 있는 작업인 듯 하다. 서비스에 가장 알맞는 아키텍처를 생각한 후 그에 그치지 않고 어떤식으로 해당 아키텍처를 구성해야 할 지에 대한 추가 학습도 분명 필요할 것이다. 

오늘의 학습을 통해 얻은 것은 아키텍처에는 정답이 없다는 것이다. 아주 옛날의 방식이라도 그것이 내가 만들고 있는 서비스에 가장 맞는 방식이라면 해당 방식을 채용해야 하는 것이다. 더 나아가 개발의 모든 방법론은 정답이 없는 것 같다. 그렇기에 하나의 기술을 단순히 사용하는 데 그치는 것이 아닌 그 기술이 나타난 이유 그리고 사용한 배경까지 모두 주의 깊게 살펴보아 언제든 동일한 상황이 등장했을 때 활용할 수 있도록 해야할 것이다.