[reinvent 2025] AWS에서 대규모 웹 아키텍처 설계

들어가며

이번 칼럼에서는 ‘AWS에서 대규모 웹 아키텍처 설계’ 세션을 청취하고, 웹 아키텍처를 대규모로 확장할 때 필수적인 마이크로 프런트엔드(Micro-frontends, MFEs)의 설계 및 AWS 배포 전략에 대한 신규 기술 및 업데이트된 정보를 공유드리겠습니다.

해당 세션을 신청한 이유는 모놀리식 아키텍처에서 벗어나 분산된 프런트엔드 아키텍처(마이크로 프런트엔드)로 전환할 때 발생하는 문제와 실제 해결책을 배우기 위함이었습니다.

이번 세션에서 주목할 내용은 MFE와 UI 컴포넌트의 명확한 구분, AWS 기반의 CSR/SSR 배포 패턴, 그리고 MFE 간의 상태 비공유 상호작용(Decoupled Interaction) 입니다.

마이크로 프런트엔드 (MFE)와 컴포넌트의 차이점 이해

마이크로 프런트엔드는 때때로 잘못 구현되어 아키텍처 자체의 문제로 비난받는 경우가 많기 때문에, 컴포넌트와 명확하게 구분하는 것이 중요합니다.

MFE는 비즈니스 서브 도메인의 기술적 표현이며, 독립적인 구현을 가지고, 단일 팀이 소유하고, 공유 코드를 최소화해야 합니다.

이는 백엔드 시스템에서 Domain Driven Design을 사용하는 것과 유사하며, UI 재사용 가능한 컴포넌트와는 다릅니다.

반면, 일반적인 UI 컴포넌트가 높은 재사용성을 목표로 하는 반면, MFE는 독립적인 비즈니스 로직 구현을 최우선으로 한다는 점에서 두 개념은 명확히 다릅니다.

세션에서는 청중과 함께 일반적인 웹 요소를 MFE로 볼 것인지 UI 컴포넌트로 볼 것인지 논의했습니다.

• Header: 일반적으로 UI 컴포넌트로 간주되지만, 여러 국가/언어/서비스를 처리하는 복잡성 때문에 전용 팀이 필요하고 변경 빈도와 복잡성이 높다면 MFE로 분류될 수 있습니다.

• Modal Window: 대부분의 경우 재사용 가능하고 사용자 정의가 가능한 UI 컴포넌트이지만, 사용자 유형이나 복잡한 설정 등 많은 비즈니스 로직을 포함하고 자주 업데이트해야 하는 경우 MFE로 분류될 수 있습니다.

• Catalog (제품 목록): 일반적으로 MFE로 간주됩니다. 카탈로그 부분은 변경 빈도가 높고, 다른 팀과 조정 없이 여러 번 배포되어야 하기 때문에 MFE로 분류하는 것이 적절합니다.

Aurora는 Fast Cloning 기술을 사용해 변경된 블록만 복사하는 구조이기 때문에, TB 단위 대용량 데이터베이스도 빠르고 비용 효율적으로 Green 환경을 생성할 수 있다는 점이 특징으로 설명되었습니다.

AWS를 활용한 MFE 배포 전략: CSR과 SSR

마이크로 프런트엔드를 AWS에 배포하는 방법으로는 클라이언트 측 렌더링(CSR)과 서버 측 렌더링(SSR) 모두 실행 가능한 접근 방식입니다.

1. 클라이언트 측 렌더링 (CSR) 아키텍처 CSR은 정적 파일 아티팩트(JavaScript, HTML, CSS 등)를 생성하며, AWS에서는 이 아티팩트들을 Amazon S3에 저장하고 Amazon CloudFront를 통해 제공하는 것이 일반적입니다.

• S3 사용: 팀별로 별도의 S3 버킷을 사용할 수도 있지만, 관리 오버헤드를 줄이기 위해 하나의 버킷을 공유하되 CI/CD 파이프라인에서 팀별/MFE별로 경로(Prefix)를 구분하여 배포하는 전략도 효과적입니다.

• 캐싱 전략: 캐싱은 S3와 CloudFront 사이, 그리고 CloudFront와 브라우저 사이에 두 레이어로 이루어집니다. CSS나 폰트 같은 아티팩트에는 긴 캐시 시간(예: 1년)을 설정하고, 캐시 버스팅(Cache busting, 캐시 무효화) 전략을 통해 파일명에 해시값 등을 포함하여 새로운 리소스를 요청하게 하는 것이 권장됩니다.

• Lambda@Edge를 활용한 라우팅: CloudFront의 Lambda@Edge를 사용하여 라우팅 로직을 추가할 수 있습니다. 예를 들어, 기존 모놀리식 SPA에서 MFE로 마이그레이션할 때, 트래픽의 일부(예: 20%)만 새 MFE로 보내고 나머지는 레거시로 보내는 카나리 릴리즈(Canary Release) 또는 블루/그린 배포를 구성하여 트래픽을 조정할 수 있습니다.

2. 서버 측 렌더링 (SSR) 아키텍처 SSR은 주로 유기적인 SEO와 빠른 Core Web Vitals를 달성하고자 할 때 필요하며, CSR보다 복잡합니다.

• 일반적인 SSR 구조: CloudFront 아래에 Application Load Balancer (ALB)가 있고, 그 뒤에 ECS Fargate 클러스터가 노드/JavaScript 환경에서 렌더링을 처리하는 방식이 흔합니다.

• 동적 데이터 처리: Formula 1 웹사이트의 사례처럼, 뉴스처럼 동적인 콘텐츠는 CloudFront에서 짧은 TTL(예: 1분 또는 30초)을 설정하여, 트래픽이 수백만 사용자에게 폭증할 때 이 캐시가 트래픽을 흡수하도록 해야 합니다.

• Lambda를 활용한 Next.js: API Gateway와 Lambda 함수를 사용하여 Next.js 애플리케이션을 실행할 수도 있습니다. 이 방식에서는 Lambda가 헤더와 푸터가 포함된 템플릿을 렌더링하고, Module Federation과 같은 기술을 사용하여 S3에 있는 MFE 청크를 지연 로드(Lazy Load)합니다. 이 덕분에 메인 템플릿 부분은 안정적으로 유지하고 메인 콘텐츠 부분(페이지)만 자주 변경해야 할 때 테스트 비용을 절감할 수 있습니다.

결합도를 낮춘 MFE 상호작용 패턴: BFF와 오케스트레이터

대규모 아키텍처에서 MFE의 독립적인 배포를 유지하려면 공유 상태(Shared State)와 강한 결합(Tight Coupling)을 피해야 합니다.

1. 백엔드 포 프런트엔드 (Backend for Frontend, BFF) MFE의 독립적인 데이터 요구 사항을 충족하기 위해 수직적 아키텍처를 채택해야 하며, 이는 프런트엔드뿐만 아니라 해당 MFE만을 위한 백엔드 부분까지 모듈화하는 것을 의미합니다.

• BFF 구현: BFF는 일반적으로 API Gateway, Lambda, 그리고 DynamoDB와 같은 서버리스 데이터베이스로 구성되며, 해당 MFE의 요청 패턴에 최적화되어 구축됩니다.

• 독립적인 소유권: 이 BFF는 해당 MFE를 담당하는 팀이 소유하므로, 다른 팀과의 엄격한 API 계약(Public Contract)에 얽매일 필요 없이 필요에 따라 언제든지 변경하고 발전시킬 수 있습니다. 이는 다른 MFE와 공유될 경우 발생하는 조직적 결합 및 확장성 문제를 방지합니다.

2. MFE 간의 상호작용: 페이지 오케스트레이터 항공편 검색 페이지처럼 검색 양식 MFE와 결과 목록 MFE가 상호 작용해야 할 때, 이들 간에 직접적인 결합을 만들지 않아야 합니다.

• 이벤트 기반 상호작용: 검색 양식 MFE가 검색 버튼을 클릭하면, 검색 정보가 담긴 이벤트(Event)를 페이지 컨텍스트로 방출(emit)합니다.

• 오케스트레이터 역할: 이벤트를 듣는 오케스트레이터(Orchestrator)(페이지 수준의 이벤트 리스너/이미터)가 이벤트를 포착하여, 필요한 경우 데이터를 변환하고, 결과 목록 MFE가 예상하는 형식으로 업데이트 이벤트를 전달합니다. 그러면 결과 목록 MFE는 자신의 BFF를 통해 필요한 데이터를 가져와 업데이트합니다.

• 이러한 방식은 두 MFE가 서로의 존재를 알지 못하게 하여 높은 수준의 디커플링(Decoupling)을 유지할 수 있도록 합니다.

결론

마이크로 프런트엔드는 단순한 컴포넌트와 다르며, 이 아키텍처를 도입하려면 마인드셋의 변화가 필요합니다. MFE는 마이크로서비스와 마찬가지로 만능 해결책(Silver Bullet)이 아니므로, 아키텍처 결정은 조직 구조, 엔지니어링 문화, 그리고 해결하려는 목표라는 맥락에 의해 주도되어야 합니다. CSR과 SSR 모두 AWS에서 MFE를 활용하는 실행 가능한 접근 방식이며, CloudFront, S3, Lambda, Fargate 등 다양한 AWS 서비스가 이러한 분산 아키텍처를 지원합니다.

세션에서 강조했듯이, 복잡성을 무분별하게 추가하는 것은 피해야 하며, 필수적인 복잡성(Essential complexity)만 추구해야 합니다.

즉, MFE는 팀의 자율성(Autonomy)과 독립적인 배포(Independent Deployment)를 가능하게 하여 개발 속도를 높이는 것이 목표이며, 작은 팀이나 단순한 시스템에는 모놀리식 아키텍처가 더 나은 선택일 수 있습니다.

AWS에서 MFE에 대한 보다 깊은 지침은 AWS 직원들이 거의 1년에 걸쳐 작성한 백서인 AWS Prescriptive Guidance를 참고할 수 있습니다.