조직 및 작업 방법

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

애자일 개발

애자일 소프트웨어 개발에 대한 아이디어는 최근 몇 년 동안 매우 보편적이 되어 거의 모든 조직이 애자일이라고 주장합니다. 애자일의 결정적 정의는이 전략의 범위를 벗어나지만 마이크로 프런트엔드 개발과 관련된 주요 요소를 검토하는 것이 좋습니다.

애자일 패러다임의 기반은 애자일 매니페스토(2001)입니다. 애자일 매니페스토는 네 가지 주요 원칙(예: "프로세스 및 도구에 대한 개인 및 상호 작용")과 12가지 원칙을 게시했습니다. 스크럼 및 스케일링된 애자일 프레임워크(SAFe)와 같은 프로세스 프레임워크는 애자일 매니페스토를 중심으로 등장했으며 일상적인 관행으로 나아가고 있습니다. 그러나 그 이면의 철학은 대부분 잘못 이해되거나 무시됩니다.

마이크로 프런트엔드 아키텍처의 맥락에서 다음과 같은 애자일 원칙을 수용하는 것이 중요합니다.

• “더 짧은 기간을 선호하면서 몇 주에서 두 달로 작업 소프트웨어를 자주 제공하세요.”

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

• “의미 있는 개인을 중심으로 프로젝트를 구축합니다. 필요한 환경과 지원을 제공하고 작업을 완료할 수 있도록 신뢰합니다.”

  “최고의 아키텍처, 요구 사항 및 설계는 자체 조직 팀에서 나옵니다.”

  이 두 원칙 모두 소유권, 독립성 및 end-to-end 책임의 이점을 강조합니다. 마이크로 프론트엔드 아키텍처는 팀이 실제로 마이크로 프론트엔드를 소유할 때(그리고 소유할 때만) 성공할 수 있습니다. 개념부터의 설계 및 구현, 제공 및 운영에 이르기까지 End-to-end 책임을 통해 팀은 실제로 소유권을 행사할 수 있습니다. 팀이 전략적 방향에 대한 자율성을 가지려면 기술적으로나 조직적으로나 이러한 독립성이 필요합니다. 폭포 개발 모델을 사용하는 중앙 집중식 조직에서는 마이크로 프런트엔드 플랫폼을 사용하지 않는 것이 좋습니다.

팀 구성 및 크기

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

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

동시에 팀이 너무 커져서는 안 됩니다. 대규모 팀에는 더 많은 리소스가 있고 개별 결근을 수용할 수 있지만 커뮤니케이션 복잡성은 각 신규 멤버에 따라 기하급수적으로 증가합니다. 보편적으로 유효한 최대 팀 크기를 설명할 수 없습니다. 프로젝트에 필요한 사람의 수는 팀 성숙도, 기술적 복잡성, 혁신 속도, 인프라와 같은 요인에 따라 달라집니다. 예를 들어 Amazon은 피자 2개 규칙을 따릅니다. 피자 2개에 공급하기에 너무 큰 팀은 더 작은 팀으로 분할해야 합니다. 이는 문제가 될 수 있습니다. 분할은 자연 경계를 따라 이루어져야 하며 각 팀에 작업에 대한 자율성과 소유권을 부여해야 합니다.

DevOps 문화

DevOps는 개발 수명 주기의 단계가 조직 및 기술 관점에서 긴밀하게 통합되는 소프트웨어 엔지니어링 관행을 말합니다. DevOps는 문화와 사고방식에 관한 것이지 역할과 도구에 관한 것이 아닙니다.

일반적으로 소프트웨어 조직에는 설계, 구현, 테스트, 배포 및 운영과 같은 전문가 팀이 있습니다. 팀이 작업을 마칠 때마다 프로젝트를 다음 팀에 인계합니다. 그러나 특수 팀의 사일로를 통해 소프트웨어를 제공하면 인계 중에 마찰이 발생합니다. 동시에 전문가가 좁은 초점으로 작업해야 하는 경우 이웃 도메인에 대한 지식이 부족하고 제품에 대한 체계적인 관점이 없습니다. 이러한 결함은 소프트웨어 제품의 낮은 일관성으로 이어질 수 있습니다.

예를 들어 소프트웨어 아키텍트가 다른 팀의 누군가가 구현할 솔루션을 설계하는 경우 구현의 고유한 측면(예: 종속성 불일치)을 간과할 수 있습니다. 그런 다음 개발자는 바로 가기(예: 몽키 패치)를 사용하거나 아키텍트와 개발 팀 간에 공식화된 back-and-forth 작업을 시작합니다. 이러한 프로세스 관리의 오버헤드로 인해 개발은 더 이상 민첩하지 않습니다(유연, 적응, 증분 및 비공식적).

DevOps라는 용어는 주로 문화와 관련이 있지만 실제로 DevOps를 가능하게 하는 기술과 프로세스를 의미합니다. DevOps는 CI/CD와 밀접한 관련이 있습니다. 개발자가 소프트웨어 증분 구현을 완료하면 Git과 같은 버전 제어 시스템에 이를 커밋합니다. 일반적으로 빌드 시스템은 소프트웨어를 빌드 및 통합하고 보다 통합되지 않은 중앙 집중식 프로세스에서 소프트웨어를 테스트 및 릴리스합니다. CI/CD를 사용하면 소프트웨어의 구축, 통합, 테스트 및 릴리스가 고유하고 자동화됩니다. 이 프로세스는 특정 프로젝트에 맞게 조정된 구성 파일을 통해 소프트웨어 프로젝트 자체의 일부인 것이 이상적입니다.

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

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

이 모든 것이 마이크로 프런트엔드와 어떤 관련이 있나요? DevOps, CI/CD 및 IaC는 마이크로 프런트엔드 아키텍처를 보완하는 데 이상적입니다. 마이크로 프론트엔드의 이점은 빠르고 원활한 전송 프로세스에 의존합니다. DevOps 문화는 팀이 end-to-end 책임을 가진 소프트웨어 프로젝트를 소유하는 환경에서만 영향을 미칠 수 있습니다.

여러 팀에서 마이크로 프런트엔드 개발 오케스트레이션

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

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

플랫폼 팀은 마이크로 프런트엔드 팀이 차별화되지 않은 과중한 작업으로부터 벗어날 수 있도록 지원합니다. 이 지원에는 컨테이너 런타임, CI/CD 파이프라인, 공동 작업 도구 및 모니터링과 같은 인프라 서비스가 포함될 수 있습니다. 그러나 플랫폼 팀을 설정해도 개발이 운영에서 분리되는 조직으로 이어져서는 안 됩니다. 그 반대의 경우도 마찬가지입니다. 플랫폼 팀은 엔지니어링 제품을 제공하고 마이크로 프런트엔드 팀은 플랫폼에서 서비스에 대한 소유권과 런타임 책임을 집니다.

지원 팀은 거버넌스에 집중하고 마이크로 프런트엔드 팀 간의 일관성을 보장하여 지원을 제공합니다. (플랫폼 팀은 이에 관여해서는 안 됩니다.) 지원 팀은 UI 라이브러리와 같은 공유 리소스를 유지 관리하며 프레임워크, 성능 예산 및 상호 운용성 규칙 선택과 같은 표준을 생성합니다. 동시에 새로운 팀 또는 팀원에게 거버넌스에서 정의한 표준 및 도구를 적용하는 교육을 제공합니다.

배포

마이크로 프론트엔드 팀에서 자율성의 북극성은 다른 마이크로 프론트엔드 팀과 독립적인 프로덕션 경로가 있는 자동화된 파이프라인을 확보하는 것입니다. 공유 없음 원칙을 따르는 팀은 독립적인 파이프라인을 구현할 수 있습니다. 라이브러리를 공유하거나 플랫폼 팀에 의존하는 팀은 배포 파이프라인에서 종속성을 관리하는 방법을 결정해야 합니다.

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

• 프런트엔드 자산을 빌드합니다.

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

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

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

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

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