코드가 아니라 '사람'이 병목입니다
사실 이건 px 단위로 봐야 하는 문제가 아닙니다. 오히려 조직도를 펼쳐놓고 봐야 하는 문제에 가깝습니다. dev.to에 올라온 Marco Quintella의 "Micro-frontends as a Organization" 시리즈가 정면으로 짚는 지점이 바로 이겁니다—프론트엔드 모놀리스는 코드 때문에 실패하는 게 아니라, 'human scale' 때문에 실패한다는 것. Conway's Law를 인용하며 "50명의 개발자가 하나의 React 레포에서 작업하면 커뮤니케이션 자체가 1차 병목"이라고 단언하는데, 솔직히… Figma에서 글로벌 CSS 한 줄 고쳤다가 다른 팀 레이아웃이 깨지는 경험, 저도 수없이 했습니다.
분산 모놀리식이라는 최악의 시나리오
MFE를 도입했다고 안심하면 안 됩니다. 기획자가 이걸 의도한 건지 의심이 드는 패턴이 하나 있는데, 바로 분산 모놀리식(Distributed Monolith)입니다. 레포는 나눴지만, MFE A가 MFE B의 글로벌 스테이트를 직접 읽고 있거나, 모든 모듈이 동일 버전의 UI 라이브러리를 강제하거나, 5개 팀이 동시에 배포 승인을 받아야 하는 "릴리스 트레인"이 돌고 있다면—그건 MFE가 아니라 모놀리스를 다섯 조각으로 찢어놓은 것에 불과합니다. Marco가 제시하는 진짜 MFE의 세 기둥은 명확합니다: 배포 독립성, 장애 격리, 점진적 기술 진화. 결제 팀이 5분 만에 핫픽스를 배포할 수 없다면, 한 모듈의 에러가 전체를 화이트 스크린으로 만든다면, 여러분은 아직 MFE를 하고 있는 게 아닙니다.
RSC vs Client Component, 그 경계에서 벌어지는 진짜 트레이드오프
여기서 시선을 Next.js 쪽으로 돌려보면, Velog에 공유된 위젯 아키텍처 사례가 이 문제를 마이크로 레벨에서 정확히 재현합니다. 네비게이션 하나를 설계하는데 useNavigation 커스텀 훅으로 비즈니스 로직을 분리하고, 전용 Context를 "중앙 방송국"으로 두어 Props 드릴링을 끊고, NavigationWidget이라는 Self-contained 엔트리 포인트로 조립하는 구조인데—사용자 입장에서는 그냥 네비게이션일 뿐이지만, 이 설계의 핵심 고민은 "순수 UI에도 'use client'가 불가피한가?"라는 질문입니다.
RSC의 이점은 분명합니다. 번들 사이즈 절감, 서버 사이드 데이터 페칭, Lighthouse 점수 개선. 하지만 RSC를 유지하려면 데이터를 부모에서 수동으로 넘겨야 하고, 그 순간 위젯은 레이아웃의 종속물이 됩니다. 이 글의 저자는 "어디에 꽂아도 즉시 돌아가는 독립 모듈"로서의 가치를 우선했고, 저는 이 판단이 맞다고 봅니다. 사실 이건 flexbox vs grid 같은 취향 문제가 아니라, 컴포넌트의 결합도를 어디서 끊느냐에 대한 아키텍처 결정입니다. 프로젝트가 커질수록 Props 경로를 추적하는 비용은 기하급수적으로 늘어나니까요.
디자인 일관성: 가장 비싼 추상화 비용
Marco가 MFE의 비용으로 꼽은 항목 중 하나가 Design Consistency입니다. "고도로 성숙한 버전 관리형 디자인 시스템 없이는 모든 MFE가 '그 색상의 미묘하게 다른 shade'를 가지게 된다"는 경고인데, 이거 1px이라도 어긋나면 밤을 새우는 사람으로서 정말 공감합니다. 디자인 토큰이 중앙에서 배포되지 않으면 팀마다 primary-blue가 #2563EB이기도 하고 #3B82F6이기도 한 지옥이 펼쳐집니다.
이 맥락에서 dev.to의 Google Fonts 페어링 프리뷰 도구 사례가 흥미롭습니다. 100개 이상의 폰트 조합을 라이브로 미리보고, CSS를 원클릭 복사하는 DX. 바닐라 JS로 만들었지만 핵심은 "디자인 의사결정의 마찰을 줄이는 것"입니다. 카테고리 필터가 검색보다 효과적이었고, 커스텀 텍스트 입력이 가장 많이 사용되었다는 피드백은—결국 개발자도 "내 콘텐츠로 직접 확인"하고 싶어한다는 사용자 여정의 증거입니다. 여기서 로딩 스켈레톤 넣고, lazy load로 초기 12개만 보여주는 전략까지 적용했다면 Lighthouse 점수도 나쁘지 않았을 겁니다.
시사점: 스케일링의 병목은 항상 '경계 설계'
세 가지 소스를 관통하는 키워드는 결국 경계(boundary)입니다. MFE에서는 팀 간 컨텍스트 경계, Next.js 위젯에서는 서버/클라이언트 컴포넌트 경계, 디자인 시스템에서는 토큰과 컴포넌트의 버전 경계. 이 경계를 잘못 그으면 분산 모놀리식이 되고, Props 지옥이 되고, shade가 미묘하게 달라지는 디자인 파편화가 됩니다.
전망: '고통이 먼저, 아키텍처는 그다음'
Marco의 조언이 가장 현실적입니다—"작은 팀이 빠르게 배포하고 있다면 이 아키텍처를 무시하라." MFE든 위젯 패턴이든 디자인 토큰 시스템이든, 도입의 트리거는 하이프가 아니라 고통이어야 합니다. 배포 큐가 3일이 걸리기 시작할 때, Props가 7단계를 관통할 때, Figma Dev Mode에서 토큰이 코드와 안 맞을 때—그때 비로소 경계를 다시 그을 타이밍입니다. Module Federation의 번들 사이즈 오버헤드, Context API의 리렌더링 비용, 디자인 토큰 버저닝의 운영 부담까지. 사실 이건 "이 라이브러리 도입하면 bundle size가…" 같은 고민의 연장선이고, 프론트엔드 스케일링에서 공짜 점심은 없다는 오래된 진실의 반복입니다.