마이크로 프론트엔드와 대체 아키텍처 비교 - AWS 권장 가이드

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

마이크로 프론트엔드와 대체 아키텍처 비교

모든 아키텍처 전략과 마찬가지로 마이크로 프론트엔드를 채택하는 결정은 조직의 원칙에 따른 평가 기준을 기반으로 해야 합니다. 마이크로 프론트엔드에는 장단점이 있습니다. 조직에서 마이크로 프론트엔드를 사용하기로 결정했다면 분산 시스템의 문제를 해결할 수 있는 전략을 마련해야 합니다.

애플리케이션 아키텍처를 선택할 때 마이크로 프론트엔드의 가장 인기 있는 대안은 모놀리스, n-티어 애플리케이션, 단일 페이지 애플리케이션 (SPA) 프런트엔드와 결합한 마이크로서비스입니다. 모두 유효한 접근 방식이며 각 접근 방식에는 장단점이 있습니다.

모노리스

자주 변경할 필요가 없는 작은 애플리케이션도 모놀리스로 매우 빠르게 제공할 수 있습니다. 상당한 성장이 예상되는 상황에서도 모놀리스는 자연스러운 첫 단계입니다. 나중에 모노리스를 폐기하거나 더 유연한 구조로 리팩토링할 수 있습니다. 모노리스로 시작하면 조직은 시장에 진출하고, 고객 피드백을 받고, 제품을 더 빠르게 개선할 수 있습니다.

그러나 모놀리식 애플리케이션은 주의 깊게 관리하지 않거나 시간이 지남에 따라 코드베이스의 크기가 커지면 성능이 저하되는 경향이 있습니다. 여러 팀이 동일한 코드베이스에 크게 기여하더라도 이들 모두가 코드베이스의 유지 관리 및 운영에 기여하는 경우는 거의 없습니다. 이로 인해 책임의 불균형이 초래되고, 이는 속도에 영향을 미치고 비효율성을 초래합니다. 동시에, 모놀리스 모듈 간의 부주의한 결합은 코드 베이스가 발전함에 따라 의도하지 않은 부작용으로 이어집니다. 이러한 부작용으로 인해 오작동과 정전이 발생할 수 있습니다.

N-티어 애플리케이션

비교적 정적인 속도로 발전하는 보다 복잡한 애플리케이션을 프런트엔드와 백엔드 사이에 REST 또는 GraphQL 계층이 있는 3계층 아키텍처 (프레젠테이션, 애플리케이션, 데이터) 로 구축할 수 있습니다. 이는 훨씬 더 유연하며, 서로 다른 계층의 팀이 어느 정도 독립적으로 개발할 수 있습니다. n-tier 애플리케이션의 단점은 기능을 배포하기가 훨씬 더 어렵다는 것입니다. 프런트엔드와 백엔드는 API 계약을 통해 분리되므로 주요 변경 사항을 함께 배포하거나 API 버전을 관리해야 합니다.

다음과 같은 일반적인 시나리오를 생각해 보십시오. 새 기능을 릴리스할 때 데이터 스키마를 변경해야 하는 경우 제품 소유자가 프론트엔드 팀과 일련의 기능에 동의하는 데 며칠이 걸릴 수 있습니다. 그러면 프론트엔드 팀이 백엔드 팀에 자체 측에서 기능을 개발하고 출시해 달라고 요청하게 됩니다. 백엔드 팀은 데이터 소유자와 협력하여 데이터베이스 스키마 업데이트를 릴리스할 것입니다. 다음으로 백엔드 팀에서 새 버전의 API를 릴리스하여 프론트엔드 팀이 변경 사항을 개발하고 릴리스할 수 있도록 합니다. 이 시나리오에서는 모든 변경 사항을 프로덕션에 적용하는 데 몇 주 또는 몇 달이 걸릴 수 있습니다. 각 팀마다 변경 사항을 개발, 테스트 및 릴리스하기 위한 자체 백로그, 우선 순위 및 메커니즘이 있기 때문입니다.

마이크로서비스

마이크로서비스 아키텍처에서는 백엔드가 소규모 서비스로 분해되며, 각 서비스는 제한된 컨텍스트 내에서 특정 비즈니스 문제를 해결합니다. 또한 각 마이크로서비스는 명확하게 정의된 인터페이스 계약을 제공함으로써 다른 서비스와 강하게 분리됩니다.

바운디드 컨텍스트와 인터페이스 컨트랙트는 잘 만들어진 모놀리스 및 n-티어 아키텍처에도 존재해야 한다는 점을 언급할 필요가 있습니다. 그러나 마이크로서비스 아키텍처에서는 네트워크 (일반적으로 HTTP 프로토콜) 를 통해 통신이 이루어지며 서비스에는 전용 런타임 인프라가 있습니다. 이는 각 백엔드 서비스의 독립적인 개발, 제공 및 운영을 지원합니다.

요구 사항에 맞는 접근 방식 선택

모놀리스 및 n-티어 아키텍처는 여러 도메인 문제를 하나의 기술적 아티팩트로 묶습니다. 따라서 종속성 및 내부 데이터 흐름과 같은 측면은 쉽게 관리할 수 있지만 새로운 기능을 제공하기가 더 어려워집니다. 일관된 코드 베이스를 유지하기 위해 팀은 처리해야 하는 코드베이스가 크기 때문에 리팩토링과 디커플링에 시간을 투자하는 경우가 많습니다.

몇몇 팀이 개발한 애플리케이션은 마이크로 프론트엔드로 이전하는 데 따르는 추가적인 복잡성이 필요하지 않을 수도 있습니다. 결합률이 높고 변경 사항을 릴리스하는 데 걸리는 리드 타임이 길어지는 페널티를 팀이 지불하지 않는 경우 특히 그렇습니다.

요약하면, 복잡하고 빠르게 변화하는 애플리케이션에는 더 복잡한 분산형 아키텍처가 적합한 경우가 많습니다. 중소 규모 애플리케이션의 경우 분산 아키텍처가 모놀리식 아키텍처보다 반드시 우수하지는 않습니다. 특히 애플리케이션이 단기간에 크게 발전하지 않는 경우에는 더욱 그렇습니다.