YEYETILCraftsPostsAbout

[TIL] 애플리케이션을 어떻게 나눠서 만들고 배포할 것인가

2026. 05. 01.Yeji Kim
Frontend

1. 모놀리식 (Monolithic Architecture)

하나의 애플리케이션 안에 모든 기능이 함께 들어있는 구조다. 쇼핑몰을 예로 들면,

text
쇼핑몰 서버
 ├─ 회원 기능
 ├─ 상품 기능
 ├─ 장바구니 기능
 ├─ 주문 기능
 ├─ 결제 기능
 └─ 관리자 기능

이 모든 게 하나의 코드베이스, 하나의 서버, 하나의 배포 단위 로 묶인다.

장점

초기 개발이 쉽다. 프로젝트 구조가 단순하고, 기능 간 호출이 그냥 함수 호출이다.

ts
const user = getUser(userId);
const order = createOrder(user, items);

작은 서비스나 초기 스타트업 제품에선 모놀리식이 오히려 더 효율적일 수 있다.

단점

서비스가 커지면 문제가 생긴다.

  • 회원 기능만 수정해도 전체 서버 재배포
  • 결제 기능에 장애가 나면 전체 서비스에 영향
  • 코드베이스가 커지면서 팀 간 충돌 증가

작을 땐 빠르지만, 커질수록 복잡도가 한 덩어리로 뭉치는 구조다.

2. MSA (Microservice Architecture)

큰 애플리케이션을 여러 작은 서비스로 쪼개는 구조. 같은 쇼핑몰을 이렇게 나눈다.

text
회원 서비스
상품 서비스
장바구니 서비스
주문 서비스
결제 서비스
알림 서비스

각 서비스는 독립적으로 개발·배포·확장 된다.

text
Frontend
   ↓
API Gateway
   ↓
 ├─ User Service
 ├─ Product Service
 ├─ Order Service
 ├─ Payment Service
 └─ Notification Service

장점

  • 독립 배포 - 결제만 수정했으면 결제만 배포
  • 선택적 확장 - 트래픽 많은 서비스만 따로 스케일
text
상품 서비스: 서버 10대
회원 서비스: 서버 3대
결제 서비스: 서버 5대
  • 소유권 분리 - 결제팀은 결제만, 검색팀은 검색만 책임

단점

복잡도가 올라간다. 모놀리식에서 함수 호출이면 끝났던 게, MSA에선 네트워크 요청이 될 수 있다.

text
Order Service → User Service
Order Service → Product Service
Order Service → Payment Service

그래서 신경 써야 할 게 많아진다.

text
네트워크 장애
API 계약
인증/인가
분산 트랜잭션
로그 추적
모니터링
서비스 간 의존성
배포 순서
데이터 정합성

MSA는 단순히 "쪼개면 좋은 구조"가 아니라, 조직과 시스템이 충분히 커졌을 때 필요한 복잡도 관리 방식에 가깝다.

3. Micro Frontend

MSA의 아이디어를 프론트엔드에 적용한 구조. 백엔드를 서비스별로 쪼개듯, 프론트엔드도 화면/도메인 단위로 쪼갠다.

text
Shell App
 ├─ User Frontend
 ├─ Product Frontend
 ├─ Cart Frontend
 ├─ Order Frontend
 └─ Payment Frontend

Shell App이 전체 레이아웃, 라우팅, 공통 인증, 공통 네비게이션을 담당하고, 각 Micro Frontend는 자기 도메인 화면만 책임진다.

라우팅 단위 분리

text
/product  → Product Frontend
/cart     → Cart Frontend
/payment  → Payment Frontend

각 팀이 자기 영역을 독립 개발/배포한다. 이론적으로는 기술 스택도 자유롭게 섞을 수 있다.

text
상품팀: React + Vite
결제팀: React + Webpack Module Federation
관리자팀: Vue

다만 실제론 운영 복잡도 때문에 완전히 자유롭게 섞는 경우는 드물다. 디자인 시스템이나 공통 인증·상태 관리를 일관되게 가져가야 하기 때문일듯

프론트엔드에서 챙겨야 할 것들

MSA의 백엔드 고민과 비슷하지만, 프론트엔드 고유의 이슈가 더 있다.

  • 번들 크기·중복 - React, lodash 등 라이브러리 중복 로딩
  • 공통 디자인 시스템 - 같은 버튼이 앱마다 달라 보이면 안 됨
  • 공유 상태 - 로그인 정보, 장바구니 상태 등을 어떻게 공유?
  • 라우팅 일관성 - Shell이 라우터를 갖되, 자식 앱이 자기 sub-route를 다룸
  • 인증 토큰 공유 - 한 번 로그인하면 모든 영역에 적용
  • 버전 정합성 - 결제팀의 v2 배포가 상품팀 v1과 충돌 안 해야 함

4. 셋의 관계

한 줄로 정리하면:

text
모놀리식      = 하나의 큰 애플리케이션
MSA         = 여러 작은 서비스로 나누는 구조
Micro Frontend = 프론트엔드를 여러 작은 앱/도메인으로 나누는 구조

5. 복잡도는 사라지지 않고 위치가 바뀐다

쪼갠다고 복잡도가 사라지는 게 아니라, 복잡도의 위치가 바뀐다. 쪼개는 것 자체가 목적이 되면 안 된다. 무엇을 위해 쪼개는지가 명확해야 그 후의 복잡도 비용이 정당화되는 것 같다.

모놀리식의 복잡도 - 코드 내부

text
큰 코드베이스
강한 모듈 간 의존성
배포 단위가 큼

MSA / Micro Frontend의 복잡도 - 시스템 경계

text
서비스 간 통신
배포 조율
버전 관리
공통 디자인 시스템
인증 공유
장애 격리
관측성

그래서 무조건 쪼개자는 게 아니라, 다음 4가지를 보고 결정해야 하면 좋을 듯하다.

  • 팀 규모 - 팀별 독립 소유권이 필요할 만큼 큰가?
  • 배포 빈도 - 도메인별 배포 주기가 정말 다른가?
  • 장애 격리 필요성 - 한 영역 장애가 전체를 죽이면 큰일나는가?
  • 도메인 복잡도 - 도메인 경계가 명확하게 그려지는가?