기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
마이크로 프런트엔드와 대체 아키텍처 비교
모든 아키텍처 전략과 마찬가지로 마이크로 프론트엔드 채택 결정은 조직의 원칙에 따라 내려지는 평가 기준을 기반으로 해야 합니다. 마이크로 프론트엔드에는 장단점이 있습니다. 조직에서 마이크로 프런트엔드를 사용하기로 결정한 경우 분산 시스템의 문제를 해결하기 위한 전략이 있어야 합니다.
애플리케이션 아키텍처를 선택할 때 마이크로 프런트엔드에 대한 가장 널리 사용되는 대안은 모놀리스, n-티어 애플리케이션 및 단일 페이지 애플리케이션(SPA) 프런트엔드와 결합된 마이크로서비스입니다. 모두 유효한 접근 방식이며 각 접근 방식에는 장단점이 있습니다.
모놀리스
자주 변경할 필요가 없는 작은 애플리케이션은 모놀리스로 매우 빠르게 제공할 수 있습니다. 상당한 성장이 예상되는 상황에서도 모놀리스는 자연스러운 첫 번째 단계입니다. 나중에 모놀리스를 사용 중지하거나 보다 유연한 구조로 리팩터링할 수 있습니다. 모놀리스부터 시작하여 조직은 시장에 진출하고, 고객 피드백을 받고, 제품을 더 빠르게 개선할 수 있습니다.
그러나 모놀리식 애플리케이션은 신중하게 유지 관리하지 않거나 시간이 지남에 따라 코드베이스의 크기가 증가함에 따라 성능이 저하되는 경향이 있습니다. 여러 팀이 동일한 코드베이스에 크게 기여하면 유지 관리 및 운영에 모두 기여하는 경우는 거의 없습니다. 이로 인해 책임의 불균형이 발생하여 속도에 영향을 미치고 비효율성이 발생합니다. 동시에 모놀리스의 모듈 간에 실수로 결합하면 코드 베이스가 발전함에 따라 의도하지 않은 부작용이 발생합니다. 이러한 부작용으로 인해 오작동 및 중단이 발생할 수 있습니다.
N 티어 애플리케이션
비교적 정적인 진화 속도를 가진 보다 복잡한 애플리케이션은 프런트엔드와 백엔드 사이에 REST 또는 GraphQL 계층이 있는 3계층 아키텍처(프레젠테이션, 애플리케이션, 데이터)로 구축할 수 있습니다. 이는 훨씬 더 유연하며 여러 계층의 팀이 어느 정도 독립적으로 개발할 수 있습니다. n-티어 애플리케이션의 단점은 기능을 배포하기가 훨씬 더 어렵다는 것입니다. 프런트엔드와 백엔드는 API 계약을 통해 분리되므로 주요 변경 사항을 함께 배포하거나 API 버전을 지정해야 합니다.
다음 일반적인 시나리오를 고려하세요. 새 기능을 릴리스하려면 데이터 스키마를 변경해야 하는 경우 제품 소유자가 프런트엔드 팀과 기능 세트에 합의하는 데 며칠이 걸릴 수 있습니다. 그런 다음 프런트엔드 팀은 백엔드 팀에 기능을 개발하고 릴리스하도록 요청합니다. 백엔드 팀은 데이터 소유자와 협력하여 데이터베이스 스키마 업데이트를 릴리스합니다. 그런 다음 프런트엔드 팀이 변경 사항을 개발하고 릴리스할 수 있도록 백엔드 팀이 API의 새 버전을 릴리스합니다. 이 시나리오에서는 각 팀에 변경 사항 개발, 테스트 및 릴리스와 관련된 자체 백로그, 우선순위 및 메커니즘이 있기 때문에 모든 변경 사항을 프로덕션에 전파하는 데 몇 주 또는 몇 달이 걸릴 수 있습니다.
마이크로서비스
마이크로서비스 아키텍처에서 백엔드는 각각 제한된 컨텍스트 내에서 특정 비즈니스 문제를 해결하는 소규모 서비스로 분해됩니다. 또한 각 마이크로서비스는 명확하게 정의된 인터페이스 계약을 노출하여 다른 서비스와 강력하게 분리됩니다.
경계 컨텍스트 및 인터페이스 계약은 잘 만들어진 모놀리스 및 n계층 아키텍처에도 존재해야 합니다. 그러나 마이크로서비스 아키텍처에서는 일반적으로 HTTP 프로토콜과 같은 네트워크를 통해 통신이 이루어지며 서비스에는 전용 런타임 인프라가 있습니다. 이는 각 백엔드 서비스의 독립적인 개발, 제공 및 운영을 지원합니다.
요구 사항에 맞는 접근 방식 선택
모놀리스 및 n-티어 아키텍처는 여러 도메인 문제를 하나의 기술 아티팩트로 번들링합니다. 따라서 종속성 및 내부 데이터 흐름과 같은 측면을 쉽게 관리할 수 있지만 새로운 기능을 제공하기가 더 어렵습니다. 일관성 있는 코드 기반을 유지하기 위해 팀은 처리해야 하는 대규모 코드 기반 때문에 리팩터링 및 디커플링에 시간을 투자하는 경우가 많습니다.
일부 팀에서 개발한 애플리케이션은 마이크로 프런트엔드로 전환할 때 발생하는 추가 복잡성이 필요하지 않을 수 있습니다. 이는 팀이 높은 결합과 릴리스에 대한 긴 리드 타임으로 인한 벌금을 지불하지 않는 경우 특히 그렇습니다.
요약하면 더 복잡하고 분산된 아키텍처는 복잡하고 빠르게 움직이는 애플리케이션에 적합한 선택인 경우가 많습니다. 중소 규모의 애플리케이션의 경우 분산 아키텍처가 모놀리식 아키텍처보다 반드시 우수하지는 않습니다. 특히 애플리케이션이 단기간에 크게 발전하지 않을 경우에는 더욱 그렇습니다.
