Skip to main content

Chapter 3. 아키텍처 설계 포인트

프론트엔드 아키텍처를 설계할 때 가장 먼저 결정해야 하는 것은 애플리케이션을 어떤 기준으로 분할할 것인가이다. 특히 Module Federation과 같은 분산 프론트엔드 구조에서는 단순한 코드 분리가 아니라, 조직 구조, 배포 방식, 장애 전파 범위, 팀 간 계약 방식까지 함께 설계해야 한다.

이 장에서는 애플리케이션 분할 기준, federation 대상, 경계 설계 원칙, 운영 구조, 그리고 조직 관점의 고려사항을 중심으로 설계 포인트를 정리한다.

3.1 애플리케이션 분할 기준​

애플리케이션 분할은 기술적인 편의보다 변화가 자주 일어나는 경계, 팀의 책임 범위, 운영 단위를 기준으로 결정하는 것이 좋다.

1) 도메인 기준 분리​

도메인 기준 분리는 비즈니스 영역을 기준으로 애플리케이션을 나누는 방식이다. 예를 들어 상품, 장바구니, 주문, 마이페이지처럼 사용자에게도 명확한 업무 개념을 기준으로 분리한다.

장점

  • 비즈니스 책임과 코드 경계가 일치한다.
  • 팀 ownership을 명확하게 가져가기 쉽다.
  • 기능 확장과 변경 영향 범위를 예측하기 쉽다.

주의점

  • 도메인 간 공통 기능이 많아지면 경계가 흐려질 수 있다.
  • 한 사용자 흐름이 여러 도메인을 넘나들 경우 통합 경험 설계가 중요하다.

적합한 경우

  • 조직이 도메인 중심으로 운영되는 경우
  • 각 영역이 독립적인 로드맵과 배포 주기를 가지는 경우

2) 페이지 기준 분리​

페이지 기준 분리는 화면 또는 라우트 단위로 애플리케이션을 나누는 방식이다. 예를 들어 홈, 검색 결과, 상품 상세, 결제 페이지를 각각 독립 단위로 운영할 수 있다.

장점

  • 분리 기준이 직관적이다.
  • 초기 도입이 쉽고, 라우트 단위 lazy loading과도 잘 맞는다.
  • 페이지 간 직접 의존을 줄이기 쉽다.

주의점

  • 페이지를 넘는 공통 상태나 사용자 흐름 관리가 복잡해질 수 있다.
  • 같은 도메인 로직이 여러 페이지에 중복될 가능성이 있다.

적합한 경우

  • 페이지 간 독립성이 높은 서비스
  • 여러 팀이 서로 다른 화면을 담당하는 구조
  • Micro Frontend를 점진적으로 도입하는 초기 단계

3) 기능 기준 분리​

기능 기준 분리는 검색, 인증, 결제, 추천, 알림처럼 재사용 가능한 기능 단위로 나누는 방식이다.

장점

  • 여러 페이지에서 재사용되는 기능을 한 곳에서 관리할 수 있다.
  • 기능별 전문성을 가진 팀 운영이 가능하다.

주의점

  • UI와 기능이 여러 페이지에 걸쳐 얽히면 의존성이 복잡해질 수 있다.
  • 기능 모듈이 과도하게 커지면 사실상 또 하나의 모놀리식 shared 영역이 된다.

적합한 경우

  • 여러 서비스나 페이지에서 동일 기능을 반복적으로 사용하는 경우
  • UI보다 비즈니스 capability의 재사용성이 중요한 경우

4) 조직/팀 경계 기준 분리​

조직 구조에 맞춰 애플리케이션 경계를 설정하는 방식이다. 즉, 코드의 경계를 팀의 책임 경계와 최대한 일치시키는 접근이다.

장점

  • 개발, 배포, 장애 대응의 책임이 분명해진다.
  • 팀이 독립적으로 의사결정하고 배포하기 쉬워진다.
  • 운영 프로세스와 아키텍처가 일관성을 갖는다.

주의점

  • 조직 구조가 바뀌면 아키텍처도 영향을 받을 수 있다.
  • 기술적으로 자연스러운 경계보다 조직 편의가 우선되면 비효율이 생길 수 있다.

적합한 경우

  • 여러 프론트엔드 팀이 병렬로 개발하는 환경
  • 독립 배포와 빠른 의사결정이 중요한 환경

3.2 어떤 것을 federation할지​

Module Federation을 도입한다고 해서 모든 것을 federation 대상으로 삼을 필요는 없다. 핵심은 독립적으로 배포할 가치가 있는 단위를 선별하는 것이다.

1) 페이지​

페이지 단위 federation은 가장 이해하기 쉽고 운영이 단순한 방식이다. 호스트 애플리케이션이 라우팅을 담당하고, 특정 페이지를 remote로 불러오는 구조가 대표적이다.

권장 상황

  • 독립 배포가 필요한 화면이 명확한 경우
  • 팀별 담당 페이지가 구분되는 경우
  • Micro Frontend를 안정적으로 시작하고 싶은 경우

특징

  • 경계가 명확하다.
  • 장애 격리와 롤백이 비교적 쉽다.
  • 초기 도입 난이도가 낮다.

2) 라우트​

라우트 단위 federation은 페이지보다 더 세밀하게 엔트리를 나누는 방식이다. 예를 들어 /mypage/orders, /mypage/profile처럼 하위 라우트별로 분리할 수 있다.

장점

  • 세부 영역별 독립 배포가 가능하다.
  • 큰 페이지를 내부 기능 단위로 분리할 수 있다.

주의점

  • 라우트 경계가 너무 잘게 쪼개지면 운영 복잡도가 급격히 올라간다.
  • 사용자 경험이 하나의 흐름인데 구현은 여러 remote로 나뉘면 통합 책임이 중요해진다.

3) UI 컴포넌트​

버튼, 카드, 모달, 테이블 같은 UI 컴포넌트를 federation하는 방식이다.

권장도

  • 일반적으로는 신중해야 한다.

이유

  • UI 컴포넌트는 배포 단위보다 패키지 공유가 더 적합한 경우가 많다.
  • 작은 컴포넌트 단위 federation은 런타임 의존성과 성능 부담을 키울 수 있다.
  • 버전 불일치가 사용자 경험 문제로 바로 드러날 수 있다.

권장 원칙

  • 범용 UI 컴포넌트는 가능하면 패키지나 디자인 시스템으로 배포한다.
  • federation은 “독립적으로 진화해야 하는 큰 단위”에 우선 적용한다.

4) 비즈니스 모듈​

상품 가격 계산, 주문 검증, 권한 판별, 추천 로직 같은 비즈니스 모듈을 federation하는 방식이다.

장점

  • 핵심 비즈니스 로직을 여러 앱에서 일관되게 사용할 수 있다.
  • 기능 단위 ownership이 명확해진다.

주의점

  • 다른 remote가 해당 비즈니스 모듈에 강하게 의존하면 coupling이 커진다.
  • 런타임 로딩 실패 시 주요 기능이 동시에 깨질 수 있다.

권장 원칙

  • 강한 재사용성과 독립 배포 필요성이 모두 있을 때만 federation한다.
  • 단순 유틸리티 수준이라면 shared package가 더 적절하다.

5) 디자인 시스템​

디자인 시스템을 federation 대상으로 둘 수도 있지만, 일반적으로는 패키지 배포 방식이 더 안정적이다.

이유

  • 디자인 시스템은 일관성이 핵심이므로 버전 제어가 중요하다.
  • 런타임 federation보다 빌드 타임 의존이 예측 가능성이 높다.
  • 스타일, 토큰, 컴포넌트 버전 차이가 발생하면 화면 품질이 흔들릴 수 있다.

권장 원칙

  • 디자인 시스템은 기본적으로 npm package 또는 내부 라이브러리로 관리한다.
  • 실험적 기능이나 큰 위젯 단위만 예외적으로 federation을 검토한다.

3.3 경계 설계 원칙​

분산 프론트엔드 구조에서 가장 중요한 것은 경계를 얼마나 명확하게 설계하느냐이다. 좋은 경계는 팀 간 협업 비용을 줄이고, 배포와 장애 대응을 단순하게 만든다.

1) remote 간 의존 최소화​

remote끼리 직접 참조하거나 서로의 내부 구현에 의존하는 구조는 피해야 한다. remote는 가능하면 host를 통해 조합되고, 서로를 몰라도 동작하도록 설계하는 것이 좋다.

원칙

  • remote 간 직접 import를 최소화한다.
  • 데이터 전달은 명시적인 props, 이벤트, API 계약으로 제한한다.
  • 상태 공유가 필요하더라도 전역 결합을 최소화한다.

2) 계약(interface) 명확화​

federation 구조에서는 코드보다 계약이 더 중요하다. remote가 외부에 노출하는 것은 화면, 컴포넌트, 함수가 아니라 명확한 인터페이스여야 한다.

포함되어야 할 요소

  • 입력 props 또는 파라미터
  • 반환 타입과 이벤트 형식
  • 에러 처리 방식
  • 버전 호환 정책
  • 로딩/실패 시 동작 규칙

권장 원칙

  • TypeScript 타입만으로 끝내지 말고 문서화된 계약을 함께 운영한다.
  • breaking change 기준을 팀 간 합의한다.

3) shared 범위 최소화​

shared 설정은 편리하지만, 범위가 넓어질수록 시스템 전체가 느슨한 모놀리스처럼 변한다.

문제점

  • 공통 의존성 버전 충돌 가능성이 커진다.
  • 특정 shared 라이브러리 변경이 전체 앱에 영향을 줄 수 있다.
  • remote의 독립성이 줄어든다.

권장 원칙

  • truly shared한 항목만 공유한다.
  • React, React DOM처럼 런타임 중복이 치명적인 항목 위주로 제한한다.
  • 사내 유틸까지 무분별하게 shared에 넣지 않는다.

4) 공통 라이브러리 기준 정의​

공통 라이브러리는 “여러 군데서 쓴다”는 이유만으로 만들면 안 된다. 명확한 기준 없이 공통화를 진행하면 오히려 변화 비용이 커진다.

공통화 판단 기준

  • 3개 이상 영역에서 반복적으로 사용되는가
  • 의미와 사용 방식이 안정적인가
  • 변경 주기가 과도하게 빠르지 않은가
  • 공통화로 인해 각 팀의 독립성이 심하게 줄지 않는가

원칙

  • 공통화는 재사용보다 안정성을 우선한다.
  • 자주 바뀌는 기능은 각 도메인 내부에 두는 편이 낫다.

3.4 운영 구조 설계​

아키텍처는 코드 구조만이 아니라 배포, 호환성, 장애 대응까지 포함해야 완성된다.

1) 독립 배포 전략​

Micro Frontend의 핵심 가치는 각 팀이 독립적으로 배포할 수 있다는 점이다.

설계 포인트

  • remote는 가능한 한 개별 CI/CD 파이프라인을 가진다.
  • host는 remote의 최신 버전을 동적으로 로드하되, 통제 가능한 방식으로 운영한다.
  • 배포 순서 의존이 생기지 않도록 backward compatibility를 고려한다.

중요한 점

  • 독립 배포는 가능해야 하지만, 무분별한 즉시 반영은 운영 리스크가 될 수 있다.
  • 필요하면 승인된 버전만 참조하는 방식도 고려해야 한다.

2) 버전 호환 전략​

독립 배포 환경에서는 host와 remote, 또는 remote와 shared 라이브러리 간 버전 호환이 핵심 이슈가 된다.

권장 전략

  • contract first 원칙을 적용한다.
  • semantic versioning 기준을 운영한다.
  • breaking change는 사전 공지와 호환 기간을 둔다.
  • 가능하면 하위 호환 가능한 인터페이스를 유지한다.

실무 포인트

  • “최신 배포 = 항상 안전”이 아니다.
  • 호환성 테스트가 없는 독립 배포는 장애 전파 경로가 된다.

3) 장애 격리 전략​

한 remote의 실패가 전체 서비스 중단으로 이어지지 않도록 해야 한다.

설계 원칙

  • remote 로딩 실패를 개별적으로 처리한다.
  • host는 remote 실패를 감지하고 대체 UI를 노출할 수 있어야 한다.
  • 특정 기능 장애가 전체 라우팅이나 렌더링 실패로 이어지지 않도록 boundary를 둔다.

적용 예시

  • Error Boundary
  • remote timeout 처리
  • 기능 단위 disable switch
  • 이전 안정 버전 fallback

4) fallback UI 전략​

federation 구조에서는 로딩 지연과 remote 실패를 전제로 UI를 설계해야 한다.

필수 고려 요소

  • 로딩 중 skeleton 또는 placeholder
  • 로드 실패 시 재시도 UI
  • 기능 일부만 사용할 수 없는 상황에 대한 대체 경험
  • 사용자에게 노출할 메시지 수준과 운영 로그 수준 분리

원칙

  • “아무것도 보이지 않음”은 최악의 경험이다.
  • fallback은 단순 예외 처리용이 아니라 운영 안정성을 위한 UX 설계다.

3.5 조직 관점 고려사항​

분산 프론트엔드 아키텍처는 기술 문제가 아니라 조직 운영 모델과 함께 설계해야 한다.

1) 팀 ownership​

각 remote 또는 분할 단위는 명확한 owner를 가져야 한다.

포함 범위

  • 기능 개발
  • 품질 관리
  • 장애 대응
  • 배포 승인
  • 계약 변경 관리

ownership이 불명확하면 코드 경계가 분리되어 있어도 실제 운영은 분리되지 않는다.

2) 배포 책임 분리​

독립 배포를 하려면 팀이 단지 코드를 작성하는 수준을 넘어, 배포 결과에 책임을 지는 구조가 필요하다.

필요 요소

  • 팀별 배포 권한
  • 롤백 절차
  • 장애 알림 체계
  • 운영 지표 모니터링

3) 공통 가이드라인 필요성​

여러 팀이 독립적으로 움직이더라도 최소한의 공통 규칙은 필요하다.

예시

  • 라우팅 규칙
  • shared 사용 기준
  • 계약 정의 방식
  • 에러 처리 원칙
  • 로그/모니터링 포맷
  • 접근성, 성능, 보안 기준

공통 가이드라인이 없으면 독립성은 확보되더라도 전체 시스템 일관성이 무너진다.

4) 리뷰/호환성 검증 프로세스​

독립 배포 환경에서도 팀 간 변경 영향은 사라지지 않는다. 따라서 구조적으로 호환성 검증 프로세스를 운영해야 한다.

권장 프로세스

  • interface 변경 시 사전 리뷰
  • shared 의존성 변경 시 영향 범위 점검
  • contract test 또는 integration test 운영
  • staging 환경에서 host-remote 조합 검증
  • breaking change 승인 절차 마련

핵심

  • 코드 리뷰만으로는 충분하지 않다.
  • federation 구조에서는 “실행 시점의 조합 검증”이 중요하다.

정리

아키텍처 분할은 단순한 파일 구조 설계가 아니라, 비즈니스 경계, 팀 구조, 배포 방식, 장애 격리 전략을 함께 결정하는 작업이다.

실무적으로는 다음 원칙이 유효하다.

  1. 분할 기준은 도메인과 팀 책임을 우선으로 한다.
  2. federation 대상은 페이지나 큰 기능 단위부터 시작한다.
  3. remote 간 직접 의존을 줄이고 계약을 명확히 한다.
  4. shared 범위는 최소화하고 공통화는 엄격하게 판단한다.
  5. 독립 배포, 호환성 검증, fallback UI를 운영 구조에 포함한다.
  6. 기술 아키텍처와 조직 운영 모델을 함께 설계한다.

결국 좋은 분산 프론트엔드 아키텍처는 “잘 나뉜 코드”가 아니라, 독립적으로 개발·배포·운영할 수 있으면서도 전체 사용자 경험은 일관되게 유지되는 구조라고 볼 수 있다.

원하면 다음 단계로 바로 이어서 “문서체로 더 다듬은 버전” 또는 “표 중심 요약본” 형태로 재작성해드릴 수 있습니다.