조직 및 작업 방식

모든 아키텍처 전략과 마찬가지로 마이크로 프론트엔드는 조직이 구현하기로 선택한 기술을 훨씬 뛰어 넘는 영향을 미칩니다. 마이크로 프론트엔드 애플리케이션 구축 결정은 비즈니스, 제품, 조직, 운영, 문화 (예: 팀 역량 강화 및 의사 결정 분산) 에 부합해야 합니다. 그 대가로 이러한 유형의 마이크로 프론트엔드 아키텍처는 독립된 팀 간의 커뮤니케이션 오버헤드를 크게 줄여 진정한 민첩한 제품 기반 개발을 지원합니다.

애자일 개발

애자일 소프트웨어 개발이라는 개념은 최근 몇 년 동안 매우 보편화되어 거의 모든 조직이 애자일 작업을 한다고 주장하고 있습니다. 애자일에 대한 결정적인 정의는 이 전략의 범위를 벗어나지만 마이크로 프론트엔드 개발과 관련된 주요 요소를 검토해 볼 가치가 있습니다.

애자일 패러다임의 기반은 Agile Manifesto (2001) 로, 이 선언에서는 네 가지 주요 원칙 (예: “프로세스와 도구에 대한 개인과 상호 작용”) 과 12가지 원칙을 가정했습니다. 스크럼 및 SaFe (스케일드 애자일 프레임워크) 와 같은 프로세스 프레임워크는 애자일 선언문을 중심으로 등장했으며 일상 업무에도 적용되었습니다. 하지만 그 이면에 깔린 철학은 대부분 잘못 이해되거나 무시되고 있습니다.

마이크로 프론트엔드 아키텍처에서는 다음과 같은 애자일 원칙을 반드시 수용해야 합니다.

• “짧은 기간을 선호하여 몇 주에서 몇 달까지 작동하는 소프트웨어를 자주 제공하세요.”

  이 원칙은 점진적으로 작업하고 정기적으로 가능한 한 자주 소프트웨어를 프로덕션에 제공하는 것이 얼마나 중요한지 강조합니다. 기술적 관점에서 볼 때 이는 지속적 통합 및 지속적 전달 (CI/CD) 을 의미합니다. CI/CD에서 구축, 테스트 및 배포를 위한 도구와 프로세스는 각 소프트웨어 프로젝트의 필수 요소입니다. 또한 이 원칙은 런타임 인프라와 운영 책임을 팀이 소유해야 한다는 것을 의미합니다. 독립 서브시스템의 인프라 및 운영 요구 사항이 크게 다를 수 있는 분산 시스템에서는 이러한 소유권이 특히 중요합니다.

• “의욕이 넘치는 개인을 중심으로 프로젝트를 구축하세요. 그들에게 필요한 환경과 지원을 제공하고 그들이 일을 완수할 것이라고 믿으세요.”

  “최고의 아키텍처, 요구 사항 및 설계는 스스로 팀을 구성함으로써 얻을 수 있습니다.”

  이 두 원칙 모두 소유권, 독립성, 책임의 이점을 강조합니다. end-to-end 마이크로 프론트엔드 아키텍처는 팀이 마이크로 프론트엔드를 진정으로 소유할 때만 성공할 수 있습니다. E의 구상부터 설계, 구현, 납품 및 운영에 이르는 모든 nd-to-end 책임을 통해 팀은 실제로 소유권을 행사할 수 있습니다. 팀이 전략적 방향에 대한 자율성을 갖기 위해서는 기술적으로나 조직적으로나 이러한 독립성이 필요합니다. 워터폴 개발 모델을 사용하는 중앙 집중식 조직에서는 마이크로 프론트엔드 플랫폼을 사용하지 않는 것이 좋습니다.

팀 구성 및 규모

소프트웨어 팀이 소유권을 행사하려면 해당 팀이 제공하는 방식과 내용을 포함하여 조직이 지정한 범위 내에서 자체적으로 관리해야 합니다.

효율성을 높이려면 팀이 독립적으로 소프트웨어를 제공할 수 있어야 하고 소프트웨어를 제공하는 최선의 방법을 결정할 권한이 있어야 합니다. 이러한 항목의 기획에 관여하지 않고 외부 제품 관리자로부터 기능 요구 사항을 전달받거나 외부 디자이너로부터 UI 디자인을 받는 팀은 자율적이라고 간주할 수 없습니다. 기능이 기존 계약 또는 기능을 위반할 수 있습니다. 이러한 위반은 추가 논의와 협상이 필요하며, 이로 인해 제공이 지연되고 팀 간에 불필요한 갈등이 발생할 위험이 있습니다.

동시에 팀의 규모가 너무 커져서는 안 됩니다. 팀 규모가 클수록 더 많은 리소스를 보유하고 개인의 결석을 수용할 수 있지만, 새로운 구성원이 생길 때마다 의사소통의 복잡성은 기하급수적으로 증가합니다. 보편적으로 유효한 최대 팀 규모를 명시하는 것은 불가능합니다. 프로젝트에 필요한 인원은 팀 성숙도, 기술적 복잡성, 혁신 속도, 인프라 등의 요인에 따라 달라집니다. 예를 들어 Amazon은 피자 두 판이라는 규칙을 따릅니다. 즉, 너무 커서 피자 두 판을 먹일 수 없는 팀은 소규모 팀으로 나누어야 합니다. 이는 어려운 일일 수 있습니다. 분할은 자연스러운 경계를 따라 이루어져야 하며 각 팀에게 업무에 대한 자율성과 소유권을 부여해야 합니다.

DevOps 문화

DevOps 개발 라이프사이클의 단계가 조직 및 기술 관점에서 긴밀하게 통합되는 소프트웨어 엔지니어링 프랙티스를 말합니다. 일반적인 생각과 달리 에서는 DevOps 문화와 사고방식에 대한 내용이 많고 역할과 도구에 대한 내용은 거의 없습니다.

일반적으로 소프트웨어 조직에는 설계, 구현, 테스트, 배포 및 운영과 같은 전문가로 구성된 팀이 있었습니다. 팀이 작업을 완료할 때마다 프로젝트를 다음 팀으로 넘겨주곤 했습니다. 하지만 전문 팀의 사일로를 통해 소프트웨어를 제공하면 인계 과정에서 마찰이 발생합니다. 동시에 전문가가 좁은 초점을 두고 작업해야 하는 경우 주변 영역에 대한 지식이 부족하고 제품을 체계적으로 볼 수 없게 됩니다. 이러한 결함으로 인해 소프트웨어 제품의 일관성이 떨어질 수 있습니다.

예를 들어, 소프트웨어 설계자가 다른 팀의 누군가가 구현할 솔루션을 설계할 때 구현의 고유한 측면 (예: 종속성 불일치) 을 간과할 수 있습니다. 그런 다음 개발자는 단축키 패치 (예: 몽키 패치) 를 사용하거나 설계자와 개발 팀 간에 공식화된 back-and-forth 협상이 시작됩니다. 이러한 프로세스를 관리하는 데 따르는 오버헤드 때문에 개발은 더 이상 민첩하지 않습니다 (유연하고 적응력이 뛰어나며 점진적이며 비공식적이라는 의미에서는).

이 용어는 DevOps 주로 문화와 관련이 있지만 실제로 이를 가능하게 하는 기술과 프로세스를 의미합니다. DevOps DevOps CI/CD와 밀접한 관련이 있습니다. 개발자가 추가 소프트웨어 구현을 마치면 Git과 같은 버전 제어 시스템에 이를 커밋합니다. 기존에는 빌드 시스템이 소프트웨어를 빌드하고 통합한 다음, 어느 정도 통합된 중앙 집중식 프로세스를 통해 테스트 및 릴리스하도록 했습니다. CI/CD를 사용하면 소프트웨어 구축, 통합, 테스트 및 릴리스가 기본적으로 자동화됩니다. 주어진 프로젝트에 맞게 특별히 조정된 구성 파일을 통해 프로세스가 소프트웨어 프로젝트 자체에 포함되는 것이 이상적입니다.

가능한 많은 단계가 자동화됩니다. 예를 들어 거의 모든 유형의 테스트를 자동화할 수 있으므로 수동 테스트 방식을 줄여야 합니다. 이러한 방식으로 프로젝트를 설정하면 소프트웨어 제품에 대한 업데이트를 높은 신뢰도로 매일 여러 번 제공할 수 있습니다. 지원하는 또 다른 기술은 IaC (코드형 인프라) DevOps 입니다.

일반적으로 IT 인프라를 설정하고 유지 관리하려면 하드웨어 (데이터 센터에 케이블 및 서버 설치) 와 운영 소프트웨어를 설치하고 유지 관리하는 수동 작업이 필요했습니다. 이는 필요했지만 많은 단점이 있었습니다. 설치에는 시간이 많이 걸리고 오류가 발생하기 쉬웠습니다. 하드웨어가 과도하게 프로비저닝되거나 제대로 프로비저닝되지 않아 과도한 지출이 발생하거나 성능이 저하되는 경우가 많았습니다. IaC를 사용하면 클라우드 서비스를 자동으로 배포하고 업데이트할 수 있는 구성 파일을 통해 IT 시스템의 인프라 요구 사항을 설명할 수 있습니다.

이 모든 것이 마이크로 프론트엔드와 무슨 관련이 있을까요? DevOps, CI/CD 및 IaC는 마이크로 프런트엔드 아키텍처를 이상적으로 보완합니다. 마이크로 프론트엔드의 이점은 빠르고 원활한 전송 프로세스에 달려 있습니다. 팀이 책임을 가지고 DevOps 소프트웨어 프로젝트를 소유하는 환경에서만 문화가 번창할 수 있습니다. end-to-end

여러 팀에 걸쳐 마이크로 프론트엔드 개발을 오케스트레이션합니다.

여러 부서 간 팀으로 마이크로 프론트엔드 개발을 확장할 때 두 가지 문제가 발생합니다. 먼저, 팀이 자체적으로 패러다임을 해석하고, 프레임워크와 라이브러리를 선택하고, 자체 도구 및 도우미 라이브러리를 만들기 시작합니다. 둘째, 완전히 자율적인 팀은 저수준 인프라 관리와 같은 일반적인 기능을 책임져야 합니다. 따라서 여러 팀으로 구성된 마이크로 프런트엔드 조직에 지원 팀과 플랫폼 팀이라는 두 팀을 추가로 도입하는 것이 좋습니다. 이러한 개념은 분산 시스템을 사용하는 현대 IT 조직에서 널리 채택되고 있으며 팀 토폴로지에도 잘 설명되어 있습니다.

다음 다이어그램은 세 개의 마이크로 프런트엔드 팀에 도구, 라이브러리, 표준 및 테스트를 제공하는 지원 팀을 보여줍니다. 플랫폼 팀은 동일한 세 개의 마이크로 프론트엔드 팀에 인프라, 공유 런타임 기능 및 도메인 서비스를 제공합니다.

플랫폼 팀은 마이크로 프론트엔드 팀을 차별화되지 않은 과중한 업무에서 해방시켜 이들을 지원합니다. 이러한 지원에는 컨테이너 런타임, CI/CD 파이프라인, 협업 도구 및 모니터링과 같은 인프라 서비스가 포함될 수 있습니다. 하지만 플랫폼 팀을 구성한다고 해서 개발이 운영과 분리되는 조직이 생겨서는 안 됩니다. 그 반대입니다. 플랫폼 팀은 엔지니어링 제품을 제공하고 마이크로 프론트엔드 팀은 플랫폼 내 서비스에 대한 소유권과 런타임 책임을 집니다.

지원 팀은 거버넌스에 초점을 맞추고 마이크로 프론트엔드 팀 전반의 일관성을 보장함으로써 지원을 제공합니다. (플랫폼 팀은 이에 관여해서는 안 됩니다.) 지원 팀은 UI 라이브러리와 같은 공유 리소스를 유지 관리하고 프레임워크 선택, 성능 예산, 상호 운용성 규칙과 같은 표준을 만듭니다. 동시에 새로운 팀이나 팀원에게 거버넌스에서 정의한 표준 및 도구를 적용하는 데 필요한 교육을 제공합니다.

배포

마이크로 프론트엔드 팀의 자율성을 위한 최우선 과제는 다른 마이크로 프런트엔드 팀으로부터 독립된 프로덕션 경로를 갖춘 자동화된 파이프라인을 구축하는 것입니다. 아무것도 공유하지 않는 원칙을 따르는 팀은 독립적인 파이프라인을 구현할 수 있습니다. 라이브러리를 공유하거나 플랫폼 팀에 의존하는 팀은 배포 파이프라인의 종속성을 관리하는 방법을 결정해야 합니다.

일반적으로 각 파이프라인은 다음을 수행합니다.

• 프론트엔드 에셋을 빌드합니다.

• 자산을 호스팅에 배포하여 사용합니다.

• 새 버전을 고객에게 제공할 수 있도록 레지스트리 및 캐시를 업데이트합니다.

실제 파이프라인 단계는 기술 스택과 페이지 구성 접근 방식에 따라 달라집니다.

클라이언트측 구성의 경우 이는 애플리케이션 번들을 호스팅 버킷에 업로드하고 CDN에서의 캐싱을 통해 소비자에게 릴리스하는 것을 의미합니다. 서비스 워커와 함께 브라우저 캐싱을 사용하는 애플리케이션은 서비스 워커 캐시를 업데이트하는 방법도 구현해야 합니다.

서버측 컴포지션의 경우 이는 일반적으로 새 버전의 서버 구성 요소를 배포하고 새 버전을 검색할 수 있도록 마이크로 프론트엔드 레지스트리를 업데이트하는 것을 의미합니다. 블루/그린 또는 카나리아 배포 패턴을 사용하여 새 버전을 점진적으로 출시할 수 있습니다.