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

스타일 및 CSS

계단식 스타일 시트(CSS)는 텍스트 및 객체의 하드 코딩 형식 대신 문서 프레젠테이션을 중앙에서 결정하기 위한 언어입니다. 언어의 계단식 기능은 상속을 사용하여 스타일 간의 우선순위를 제어하도록 설계되었습니다. 마이크로 프런트엔드에서 작업하고 종속성을 관리하기 위한 전략을 생성하면 언어의 계단식 기능이 어려울 수 있습니다.

예를 들어 두 개의 마이크로 프론트엔드가 동일한 페이지에 공존하며, 각 마이크로 프론트엔드는 body HTML 요소에 대한 자체 스타일을 정의합니다. 각가 자체 CSS 파일을 가져와 style 태그를 사용하여 DOM에 연결하는 경우 CSS 파일은 공통 HTML 요소, 클래스 이름 또는 요소 IDs. 스타일 관리를 위해 선택하는 종속성 전략에 따라 이러한 문제를 해결할 수 있는 다양한 전략이 있습니다.

현재 성능, 일관성 및 개발자 경험의 균형을 맞추는 가장 인기 있는 접근 방식은 설계 시스템을 개발하고 유지하는 것입니다.

디자인 시스템 ‒ 공유 접근 방식

이 접근 방식은 시스템을 사용하여 적절한 경우 스타일을 공유하는 동시에 간헐적인 분산을 지원하여 일관성, 성능 및 개발자 경험의 균형을 맞춥니다. 설계 시스템은 명확한 표준에 따라 재사용 가능한 구성 요소의 모음입니다. 설계 시스템 개발은 일반적으로 여러 팀의 의견과 기여가 있는 한 팀이 주도합니다. 실제로 설계 시스템은 JavaScript 라이브러리로 내보낼 수 있는 하위 수준 요소를 공유하는 방법입니다. 마이크로 프론트엔드 개발자는 라이브러리를 종속성으로 사용하여 미리 만들어진 사용 가능한 리소스를 구성하여 간단한 인터페이스를 구축하고 새 인터페이스를 만들기 위한 출발점으로 사용할 수 있습니다.

양식이 필요한 마이크로 프런트엔드의 예를 생각해 보세요. 일반적인 개발자 경험은 디자인 시스템에서 사용할 수 있는 미리 만들어진 구성 요소를 사용하여 텍스트 상자, 버튼, 드롭다운 목록 및 기타 UI 요소를 구성하는 것으로 구성됩니다. 개발자는 실제 구성 요소에 대한 스타일을 작성할 필요가 없으며 함께 보이는 방식에 대해서만 작성하면 됩니다. 빌드 및 릴리스할 시스템은 Webpack Module Federation 또는 유사한 접근 방식을 사용하여 설계 시스템을 외부 종속성으로 선언할 수 있으므로 설계 시스템을 포함하지 않고 양식의 로직이 패키징됩니다.

그런 다음 여러 마이크로 프런트엔드가 공유된 문제를 처리하기 위해 동일한 작업을 수행할 수 있습니다. 팀이 여러 마이크로 프런트엔드 간에 공유할 수 있는 새 구성 요소를 개발하면 성숙도에 도달한 후 해당 구성 요소가 설계 시스템에 추가됩니다.

설계 시스템 접근 방식의 주요 장점은 높은 수준의 일관성입니다. 마이크로 프론트엔드는 스타일을 쓰고 때때로 디자인 시스템에서 스타일을 재정의할 수 있지만, 거의 필요하지 않습니다. 기본 하위 수준 요소는 자주 변경되지 않으며 기본적으로 확장 가능한 기본 기능을 제공합니다. 또 다른 장점은 성능입니다. 빌드 및 릴리스를 위한 좋은 전략을 사용하면 애플리케이션 쉘에서 계측되는 최소한의 공유 번들을 생성할 수 있습니다. 네트워크 대역폭 측면에서 설치 공간을 최소화하면서 여러 마이크로 프런트엔드 특정 번들이 온디맨드로 비동기식으로 로드되는 경우 훨씬 더 개선할 수 있습니다. 마지막으로 개발자 경험은 휠을 재창조하지 않고도 풍부한 인터페이스를 구축하는 데 집중할 수 있기 때문에 이상적입니다(예: 버튼을 페이지에 추가해야 할 때마다 JavaScript 및 CSS 작성).

단점은 모든 종류의 설계 시스템이 종속성이므로 유지 관리 및 업데이트해야 한다는 것입니다. 여러 마이크로 프론트엔드에 새 버전의 공유 종속성이 필요한 경우 다음 중 하나를 사용할 수 있습니다.

예를 들어 모든 마이크로 프론트엔드가 설계 시스템의 버전 3.0에 의존하고 공유 방식으로 사용할 3.1이라는 새 버전이 있는 경우 모든 마이크로 프론트엔드가 위험을 최소화하면서 마이그레이션할 수 있도록 기능 플래그를 구현할 수 있습니다. 자세한 내용은 기능 플래그 섹션을 참조하세요. 또 다른 잠재적 단점은 설계 시스템이 일반적으로 스타일 그 이상을 해결한다는 것입니다. 여기에는 JavaScript 사례 및 도구도 포함됩니다. 이러한 측면은 토론과 협업을 통해 합의에 도달해야 합니다.

설계 시스템을 구현하는 것은 좋은 장기 투자입니다. 이는 널리 사용되는 접근 방식이며 복잡한 프런트엔드 아키텍처를 작업하는 모든 사용자가 고려해야 합니다. 일반적으로 프런트엔드 엔지니어와 제품 및 설계 팀이 협업하고 상호 작용 메커니즘을 정의해야 합니다. 원하는 상태에 도달할 시간을 예약하는 것이 중요합니다. 또한 사람들이 장기적으로 신뢰할 수 있고 잘 유지 관리되며 성과를 낼 수 있도록 경영진의 후원을 받는 것이 중요합니다.

완전히 캡슐화된 CSS ‒ 아무것도 공유하지 않는 접근 방식

각 마이크로 프론트엔드는 규칙과 도구를 사용하여 CSS의 계단식 기능을 극복합니다. 예를 들어 각 요소의 스타일이 항상 요소의 ID 대신 클래스 이름과 연결되고 클래스 이름이 항상 고유하도록 하는 것입니다. 이렇게 하면 모든 것이 개별 마이크로 프론트엔드로 범위가 지정되고 원치 않는 충돌의 위험이 최소화됩니다. 애플리케이션 쉘은 일반적으로 마이크로 프런트엔드 스타일을 DOM에 로드한 후 로드하는 역할을 하지만 일부 도구는 JavaScript를 사용하여 스타일을 번들링합니다.

아무것도 공유하지 않으면 마이크로 프론트엔드 간에 충돌이 발생할 위험이 줄어듭니다. 또 다른 장점은 개발자의 경험입니다. 각 마이크로 프론트엔드는 다른 마이크로 프론트엔드와 아무것도 공유하지 않습니다. 독립 실행 및 테스트는 더 간단하고 빠릅니다.

공유 없음 접근 방식의 주요 단점은 일관성이 부족할 수 있다는 것입니다. 일관성을 평가하기 위한 시스템이 없습니다. 공유된 내용을 복제하는 것이 목표라고 해도 릴리스 및 협업 속도의 균형을 맞출 때는 어려워집니다. 일반적인 완화 방법은 일관성을 측정하는 도구를 만드는 것입니다. 예를 들어 헤드리스 브라우저가 있는 페이지에서 렌더링된 여러 마이크로 프런트엔드의 자동 스크린샷을 생성하는 시스템을 만들 수 있습니다. 그런 다음 릴리스 전에 스크린샷을 수동으로 검토할 수 있습니다. 하지만 이를 위해서는 원칙과 거버넌스가 필요합니다. 자세한 내용은 정렬을 통한 밸런싱 자율성 섹션을 참조하세요.

사용 사례에 따라 또 다른 잠재적 단점은 성능입니다. 모든 마이크로 프론트엔드에서 다량의 스타일을 사용하는 경우 고객은 많은 중복 코드를 다운로드해야 합니다. 이는 사용자 경험에 부정적인 영향을 미칩니다.

이 공유 없음 접근 방식은 소수의 팀만 관련된 마이크로 프런트엔드 아키텍처 또는 낮은 일관성을 허용할 수 있는 마이크로 프런트엔드에만 고려되어야 합니다. 조직이 설계 시스템에서 작업하는 동안 자연스러운 초기 단계일 수도 있습니다.

공유 글로벌 CSS ‒ 전체 공유 접근 방식

이 접근 방식을 사용하면 스타일과 관련된 모든 코드가 중앙 리포지토리에 저장되어 기고자가 CSS 파일에서 작업하거나 Sass와 같은 프리프로세서를 사용하여 모든 마이크로 프론트엔드에 대해 CSS를 작성합니다. 변경이 이루어지면 빌드 시스템은 CDN에서 호스팅되고 애플리케이션 쉘에 의해 각 마이크로 프런트엔드에 포함될 수 있는 단일 CSS 번들을 생성합니다. 마이크로 프론트엔드 개발자는 로컬 호스팅 애플리케이션 셸을 통해 코드를 실행하여 애플리케이션을 설계하고 구축할 수 있습니다.

마이크로 프런트엔드 간의 충돌 위험을 줄이는 명백한 이점 외에도이 접근 방식의 장점은 일관성과 성능입니다. 그러나 스타일을 마크업 및 로직과 분리하면 개발자가 스타일 사용 방법, 스타일 진화 방법, 스타일 사용 중단 방법을 이해하기가 더 어려워집니다. 예를 들어 기존 클래스와 속성 편집의 결과에 대해 알아보는 것보다 새 클래스 이름을 도입하는 것이 더 빠를 수 있습니다. 새 클래스 이름을 생성할 때의 단점은 성능에 영향을 미치는 번들 크기 증가 및 사용자 경험에 불일치가 도입될 가능성입니다.

공유 글로벌 CSS는 monolith-to-micro-frontends 마이그레이션의 출발점이 될 수 있지만 둘 이상의 팀이 함께 협업하는 마이크로 프론트엔드 아키텍처에는 거의 유용하지 않습니다. 설계 시스템을 개발하는 동안 최대한 빨리 설계 시스템에 투자하고 공유 없는 접근 방식을 구현하는 것이 좋습니다.