모던 웹 어플리케이션은 데스크탑 어플리케이션과 비교해도 손색없는 성능과 사용자 경험을 제공하는 것이 필수가 되었고, 이에 따라 개발 규모와 복잡도도 상승했다. 이에 따라 기존의 모놀리스 방식에서 마이크로 서비스 방식으로 변화하는 추세가 나타났다. 이후 자연스럽게 많은 패턴과 라이브러리가 출현했고, 규모가 더욱 커짐에 따라 필연적으로 프레임워크가 등장했다.
Monolithic (모놀리틱)
Monolithic 아키텍처는 모든 비즈니스 관련 사항을 하나의 코드 베이스에 결합하는 단일 컴퓨팅 네트워크이다. 이 경우에 Application에 변경사항이 생기면 전체 스택을 업데이트해야하기 때문에, 업데이트에 제한이 많고 시간이 오래 걸린다. 물론 프로젝트 초기에는 코드 관리, 인지 overhead, 배포의 용이성면에서 장점을 가질 수 있다. 반면 Monolithic의 주요 문제는 예상치 못한 결합, 높은 테스트 비용, 늦은 출시 사이클인데, 이는 Monolithic의 특성상 변경에 의한 영향이 크기 때문이다. 또, 기술 채택의 장벽과 유연성 부족에서의 문제도 있으며, 일부의 변경에도 전체를 재배포해야하는 문제가 있다.
Microservices (마이크로 서비스)
Microservices는 독립적으로 배포 가능한 일련의 서비스를 이용하는 아키텍처이다. 이 아키텍처에서는 주요 비즈니스와 도메인별 문제를 별도의 독립적인 코드 베이스로 분리한다. 각각의 작업이 서로 독립적으로 작동하도록 작은 프로세스로 분리되어있기 때문에, 복잡성을 눈으로 볼 수 있고 관리하기 쉬워진다. 유연한 확장과 빠른 업데이트 반영이 큰 장점이며, 개별 서비스의 버그와 결함이 분리되어있기 때문에 유지보수가 더 쉬워지고 테스트 편의성도 증가한다. 또 전체 Application 중단의 위험없이 특정 서비스에 대한 변경 사항을 배포할 수 있다. 하지만 개별적으로 단위가 나눠지다보니, 각각의 microservice는 테스트 도구, 배포 플레이북, 호스팅 인프라, 모니터링 도구 등, Monolithic 아키텍처보다 더 많은 인프라 비용이 필요하다. 또 각각의 서비스를 관리하고 조율하기 위한 비용도 필요하며, 관리가 잘 되지 않으면 무분별한 개발 확산이 일어나 개발 속도가 느려지고 운영 성능이 저하된다.
이에 CBD(Component based development) 방법론을 기반으로 한 SPA(Single Page Application)이 대중화되면서 Angular, React, Vue.js, Svelte 등 다양한 SPA 프레임워크와 라이브러리가 활성화되었다.
CBD (Component Based Development)
재사용 가능한 컴포넌트의 개발 또는 상용 컴포넌트를 조합하여 Application의 개발 생산성과 품질을 높이고, 시스템 유지보수 비용을 최소화할 수 있는 개발 방법론이다. 비즈니스 로직이 각 컴포넌트로 독립되어 있어, 유연성에서 장점이 있고, 기술적 측면에서는 응집도를 높이고 결합도를 낮추어 유지보수에서 유리하다.
[javascript deep dive] 도서
https://www.atlassian.com/ko/microservices/microservices-architecture/microservices-vs-monolith