Read Original
#Frontend

micro frontends가 미리캔버스 프론트엔드팀이 일하는 방식을 바꾸는 이유

micro frontends가 미리캔버스 프론트엔드팀이 일하는 방식을 바꾸는 이유
01

Summary

분산 모놀리스는 잊어라! 미리캔버스가 6 레이어 MFE로 일하는 방식을 혁신한 비결

코드의 단순 분할을 넘어, 공유의 본질을 계약으로 바꾸고 조직의 협업 생산성을 극대화하는 프론트엔드 아키텍처

본 아티클은 미리캔버스 프론트엔드팀이 대규모 모놀리스 코드에서 겪은 검증 병목과 협업 부조화를 마이크로 프론트엔드(MFE) 아키텍처를 도입해 극적으로 돌파한 여정을 소개합니다. 저자는 '분산된 모놀리스'라는 전형적인 설계 실패를 예방하기 위해 변화율을 중심으로 6개 레이어를 구축하고 이를 빌드 수준에서 강제하는 고도의 설계 기법을 제시합니다. 엔지니어링의 변화가 어떻게 역 콘웨이의 법칙을 이끌어 조직의 일하는 방식까지 성공적으로 변화시켰는지 상세히 분석합니다.

  • 01단순 코드 쪼개기와 구별되는, 공유의 형태를 계약(Contract)으로 바라보는 진정한 MFE 지향점 정의
  • 02시각적 변화가 잦은 Fragment와 안정적인 도메인 Entity의 변화율 차이를 활용한 6 레이어 아키텍처 배치 전략
  • 03상수 대신 검증 함수를 노출하고 백엔드 DTO를 discriminated union으로 어댑팅하여 변경 내성을 높인 퍼블릭 API 캡슐화 기법
  • 04빌드 시스템 수준에서 상위 레이어의 무단 참조를 방지하고 영향 범위를 사전에 시각화하는 강력한 약속 강제
  • 05조직의 구조에 발맞춰 화면(Fragment) 영역과 공통 도메인 영역의 책임 소유권을 명확히 분리하여 업무 간섭 차단

RECOMMENDATION

서비스 규모가 커지며 여러 팀 간의 배포 충돌과 코드 오염으로 골머리를 앓는 테크 리더와 시니어 프론트엔드 엔지니어에게 적극 권장합니다. 특히 런타임 페더레이션 환경에서 모듈 간 느슨한 결합을 유지하기 위한 API 수준의 캡슐화 전략이 실무적으로 큰 영감을 줍니다.

The Problem

미리캔버스 서비스가 고도화되면서 작은 기능 수정 하나도 서비스 전체의 검증 및 롤백 범위로 번지는 문제가 발생했습니다. 또한 목적조직과 기능조직의 협업 경계가 불명확하여 도메인 지식 없이 코드를 수정하고 중복 코드가 대량 발생하는 구조적 한계가 있었습니다.

The Solution

런타임 페더레이션 기반의 마이크로 프론트엔드를 선택하고, 전체 시스템을 변화율 관점에서 고려된 6개 레이어 아키텍처로 재배치하였습니다. 구체적인 데이터 구조 대신 함수 및 판정 형태의 Public API만 좁게 노출하여 결합도를 낮추고, 레이어 참조 규칙을 빌드 그래프 수준에서 강제하였습니다.

The Result

결과적으로 변경 영향 범위가 정적으로 추적 가능해지고 검증과 롤백의 단위가 독립된 Fragment로 격격하게 좁혀졌습니다. 또한 목적조직은 화면과 비즈니스 흐름을, 기능조직은 핵심 도메인 레이어를 소유하고 좁은 인터페이스로만 협업함으로써 소유권 분리와 업무 효율화를 동시에 이뤄냈습니다.

Trade-off

완벽히 감추기 어려운 프래그먼트 간의 상호작용이나 글로벌 이벤트 페이로드 등의 미묘한 영역이 아직 완결되지 않은 한계로 존재합니다. 또한 아키텍처의 형식적인 유지를 막고 조직의 실제 협업과의 정합성을 유지하기 위해 주기적인 점검과 지속적인 모니터링 공수가 필요합니다.

03

Key Concepts

Concept · 01

마이크로 프론트엔드 (Micro Frontends)

웹 애플리케이션을 하나의 거대한 덩어리가 아니라, 독립적으로 개발 및 배포 가능한 작은 컴포넌트 단위로 나누어 런타임에 통합하는 설계 기법입니다. 이를 통해 서비스 규모 확장에 따른 검증 및 롤백 비용의 대칭성을 완화하고 팀별 자율성을 극대화합니다.

  • 미리캔버스에서는 런타임에 모듈들을 통합하는 런타임 페더레이션 방식을 채택하여 운영 중입니다.
  • 모듈 간 공유를 구현체가 아닌 좁은 계약(인터페이스) 중심으로 설계해 결합도가 전이되는 것을 막습니다.
Concept · 02

변화율 (Rate of Change) 기반 레이어 설계

소프트웨어를 구성하는 모듈들을 각 기능의 고유한 변화 빈도(Volatility)에 따라 계층화하여 배치하는 설계 기법입니다. 자주 변하는 레이어는 전파 범위가 좁은 곳에 두고, 자주 변하지 않는 레이어는 전파 범위가 넓은 곳에 배치해 변경에 따른 부작용을 최소화합니다.

  • 미리캔버스는 Application, Fragment, Service, Feature, Entity, Shared라는 6개 레이어를 정의했습니다.
  • 가장 변화율이 높은 Fragment는 상위에, 가장 변화율이 낮지만 영향력이 큰 Entity는 하위에 배치하여 변경 영향도의 총량을 조율했습니다.
Concept · 03

역 콘웨이의 법칙 (Inverse Conway's Law)

시스템 아키텍처가 결국 설계하는 조직의 소통 구조를 반영한다는 '콘웨이의 법칙'에 착안하여, 이상적인 기술 아키텍처를 실현할 수 있도록 팀 구조 및 R&R을 인위적으로 조정하고 맞추는 소프트웨어 공학 전략입니다.

  • 6 레이어 컴포넌트 구조에 부합하도록 화면 중심의 '목적조직'과 도메인 핵심을 소유한 '기능조직'의 역할을 정의했습니다.
  • 목적조직과 기능조직의 인터랙션 지점을 내부 코드가 아닌 상호 합의된 'Public Interface' 영역으로 격리시켜 협업 마찰을 근본적으로 제거했습니다.