테스트 4분, 머지 충돌 공포, 버튼 색 하나에 팀 세 개 조율
dev.to에 올라온 한 마이크로 프론트엔드 이야기는 숫자 하나로 시작한다. 28만 줄짜리 React 모놀리스. 테스트 스위트 실행에 4분, PR은 머지 충돌이 두려워 며칠씩 대기, 버튼 색상 하나 바꾸려면 세 팀이 릴리즈를 맞춰야 했다. 이걸 읽는 순간 손발이 오그라드는 이유는 많은 팀이 이미 그 안에 있거나, 그 직전이기 때문이다.
마이크로 프론트엔드는 이 문제를 풀기 위한 구조적 선택이다. 마이크로서비스가 백엔드에 독립 배포 단위를 도입한 것처럼, UI도 팀별로 독립된 앱으로 쪼개는 것이다. Shell(호스트)이 Dashboard, Orders, Settings 같은 MFE를 런타임에 조합한다. 각 팀은 자신의 MFE를 독립적으로 빌드하고 배포한다. 이론은 단순하다. 문제는 항상 구현 단계에서 터진다.
통합 전략의 선택이 아키텍처의 운명을 가른다
빌드타임 통합, iframe 런타임 통합, Module Federation—세 가지 전략 중 어느 것을 선택하느냐가 '아키텍처가 문제를 해결하는지, 새 문제를 추가하는지'를 결정한다. 빌드타임 통합은 npm 패키지로 MFE를 묶는 방식인데, 솔직히 말하면 마이크로 프론트엔드가 아니다. 배포 커플링이 그대로 남기 때문이다. iframe은 격리와 독립 배포를 완벽하게 보장하지만 접근성 문제와 크로스 프레임 통신 비용이 따라온다.
현재 가장 현실적인 선택은 Webpack 5의 Module Federation이다. remoteEntry.js를 CDN에 배포하면 Shell은 다음 페이지 로드 시 새 버전을 자동으로 가져온다. Shell 재배포 없이 Orders 팀이 독립 배포하는 것이 가능해진다. 그런데 여기서 진짜 함정이 시작된다.
아무도 경고하지 않는 다섯 가지 실전 문제
의존성 지옥: singleton: true 설정 없이 각 MFE가 React를 따로 로드하면, 같은 페이지에 React 두 인스턴스가 올라온다. Context, Hooks, Refs가 조용히 깨진다. 에러 메시지도 친절하지 않다.
공유 상태의 함정: 전역 Redux 스토어나 Context를 MFE 간에 공유하는 순간, 모놀리스를 트렌치코트 입힌 채로 다시 만드는 것이다. Orders MFE가 Shell을 import하면 독립 배포 자체가 불가능해진다. 대신 CustomEvent 기반 경량 이벤트 버스로 '최소 필요 계약'만 공유해야 한다.
디자인 시스템 드리프트: 경계를 명확히 하지 않으면 각 MFE가 제각각 버튼 컴포넌트를 만들고, 6개월 후 앱이 다섯 명이 대화한 적 없는 디자이너들의 합작처럼 보인다. 공유 디자인 시스템 패키지를 Module Federation의 shared 설정으로 잠그는 것이 유일한 해법이다.
AI가 이 문제를 더 급하게 만든다
이쯤에서 다른 기사를 꺼내야 한다. 백엔드 개발자 관점에서 AI 시대의 아키텍처를 다룬 글은 불편한 질문을 던진다: AI가 API를 생성하고, SQL을 작성하고, 서비스 전체를 스캐폴딩하는 시대에 아키텍처 복잡도가 여전히 필요한가?
역설적으로, 답은 '더 필요하다'다. AI 코딩 에이전트는 빠르지만 경계가 없으면 비즈니스 로직을 중복 생성하고, 일관성 없는 패턴을 도입하고, 이미 존재하는 추상화를 무시한다. 아키텍처는 더 이상 개발자만을 위한 가이드가 아니다. AI 에이전트가 '어디에 무엇을 놓을 것인지'를 판단하는 운영 가이드가 되어야 한다.
프론트엔드 맥락으로 번역하면 더 구체적이다. AI가 컴포넌트를 생성할 때 경계가 모호한 모놀리식 구조에서는 어디든 코드를 밀어 넣는다. 반면 Shell과 MFE의 경계, 이벤트 버스의 계약, 디자인 시스템 패키지의 버전이 명확히 정의된 구조에서는 AI도 그 경계를 따른다. 구조가 AI의 동작 범위를 제한하는 가드레일이 된다.
AI가 '어디를 볼지'를 알려주는 워크플로우
GitHub Copilot CLI를 40개 이상의 오픈소스 org에 걸쳐 PR 트리아지에 활용한 사례는 이 구조 이야기의 실무 버전이다. gh copilot suggest "explain the architecture of this repo", gh copilot suggest "where is the streaming response handler"—핵심은 AI가 코드를 대신 작성하는 것이 아니라 '어디를 봐야 하는지'를 먼저 파악하는 데 쓰인다는 점이다.
47초짜리 트리아지 사례가 인상적이다. 처음 보는 Python MCP SDK 레포에서 스트리밍 핸들러가 마지막 토큰을 가끔 드롭하는 이슈를 Copilot CLI로 파일을 찾고, 조기 리턴 조건을 설명받고, 수정 후 회귀 테스트까지 생성했다. PR 초안 47초. 리뷰는 이틀. 수정은 맞았다. 이 흐름에서 AI는 '이해의 대체재'가 아니라 '이해의 가속기'로 쓰였다.
그러나 Copilot CLI가 명확히 못 하는 것도 있다. 크로스 파일 상태 추론, 두 패치 중 어느 것이 더 나은지 판단, 코드베이스 이해 자체의 대체. "Copilot을 써서 코드를 찾아라. Copilot으로 코드 읽기를 피하지는 마라." 이 한 줄이 AI 도구 활용의 핵심 원칙이다.
시사점: 경계 설계가 AI 시대의 프론트엔드 기초 공사다
세 기사가 같은 방향을 가리킨다. 마이크로 프론트엔드 실전 경험은 경계 없는 모놀리스의 비용을 보여주고, AI 에이전트 시대의 아키텍처 논의는 그 경계가 이제 AI의 동작 범위를 제한하는 구조적 가이드가 된다고 말한다. Copilot CLI 활용 사례는 그 경계가 명확한 코드베이스에서 AI가 실제로 더 정확하게 작동함을 실무로 보여준다.
MFE로 분리하든 잘 설계된 모놀리스를 유지하든, 지금 당장 물어봐야 할 질문은 하나다: 이 코드베이스에서 AI가 새 기능을 추가할 때 어디에 놓아야 하는지 명확한가? 그 질문에 답하기 어렵다면, 경계 설계가 다음 스프린트의 가장 중요한 작업이다.
전망: 아키텍처 리터러시가 AI 시대 프론트엔드 역량의 축이 된다
빌드타임과 런타임 통합 전략의 트레이드오프를 이해하고, 이벤트 버스로 MFE 간 계약을 설계하고, 디자인 시스템 버전을 공유 의존성으로 잠그는 능력—이것들은 AI가 점점 더 많은 코드를 생성할수록 더 희소해지는 인간의 판단 영역이 된다. AI는 코드를 빠르게 만들지만 경계를 설계하지는 않는다. 그 설계를 먼저 해두는 팀이 AI의 속도를 제대로 빌릴 수 있는 팀이다.