테마
웹 개발의 진화: 모놀리스에서 마이크로프론트엔드까지
백엔드에서 시작된 마이크로서비스 원칙이 프론트엔드까지 확장되는 과정을 이해한다.
학습 목표
- 마이크로서비스 아키텍처(MSA)의 핵심 개념을 이해한다
- 웹 개발이 모놀리스에서 마이크로프론트엔드로 진화한 과정을 설명할 수 있다
- 마이크로프론트엔드의 정의와 등장 배경을 파악한다
- 아키텍처 선택이 장기적 생산성에 미치는 영향을 이해한다
1. 마이크로서비스 아키텍처(MSA)란?
마이크로서비스 아키텍처는 하나의 거대한 애플리케이션을 작고 독립적인 서비스들의 집합으로 분해하는 소프트웨어 설계 방식이다. 각 서비스는 자체적인 데이터 저장소를 갖고, 독립적으로 배포되며, 명확한 인터페이스(API)를 통해 다른 서비스와 통신한다.
이 개념은 원래 백엔드 시스템에서 시작되었다. 넷플릭스, 아마존, 우버 같은 대규모 서비스 기업들이 모놀리식 백엔드의 한계에 부딪히면서 서비스를 잘게 쪼개기 시작한 것이 그 출발점이다.
MSA의 핵심 원칙은 다음과 같다:
| 원칙 | 설명 |
|---|---|
| 독립적 배포 | 각 서비스를 다른 서비스에 영향 없이 배포할 수 있다 |
| 기술 이질성 | 서비스마다 최적의 기술 스택을 선택할 수 있다 |
| 장애 격리 | 하나의 서비스 장애가 전체 시스템을 무너뜨리지 않는다 |
| 팀 자율성 | 각 팀이 자신의 서비스에 대한 완전한 소유권을 갖는다 |
| 비즈니스 역량 중심 | 기술 계층이 아닌 비즈니스 기능 단위로 분리한다 |
마이크로프론트엔드는 바로 이 MSA 원칙을 프론트엔드 영역에 적용한 것이다. 이 진화 과정을 단계별로 살펴보자.
2. 웹 개발 아키텍처의 진화 과정
웹 개발의 아키텍처는 크게 네 단계를 거쳐 발전해왔다. 각 단계는 이전 단계의 문제점을 해결하기 위해 등장했다.
2.1 1단계: 모놀리스 (Monolith)
웹 개발의 초기 형태는 모놀리스였다. 프론트엔드, 백엔드, 데이터베이스가 모두 하나의 시스템 안에 존재하고, 하나의 팀이 전체를 관리했다.
특징:
- 서버사이드 렌더링(SSR)이 기본이었다 (JSP, PHP, ASP, Rails ERB 등)
- HTML, CSS, JavaScript가 서버 코드 안에 섞여 있었다
- 하나의 코드베이스, 하나의 빌드, 하나의 배포
- 팀 구성도 하나의 전담 팀이 전체를 담당
장점: 단순하고 이해하기 쉽다. 초기 개발 속도가 빠르다.
한계: 시스템이 커지면 코드 간 결합도가 높아지고, 한 부분의 수정이 다른 부분에 예상치 못한 영향을 준다. 배포 주기가 길어지고, 팀 간 조율 비용이 기하급수적으로 증가한다.
2.2 2단계: 프론트엔드/백엔드 분리
모놀리스의 한계를 극복하기 위해 프론트엔드와 백엔드를 분리하는 움직임이 일어났다. SPA(Single Page Application) 프레임워크(Angular, React, Vue)의 등장이 이를 가속화했다.
특징:
- 프론트엔드가 독립적인 애플리케이션으로 분리
- REST API 또는 GraphQL을 통해 프론트엔드와 백엔드가 통신
- 프론트엔드 팀과 백엔드 팀이 분리
콘웨이의 법칙(Conway's Law):
"조직의 커뮤니케이션 구조를 그대로 반영하는 시스템을 설계하게 된다." — 멜빈 콘웨이, 1967
이 분리는 단순히 기술적 결정이 아니라, 조직 구조의 변화이기도 했다. 프론트엔드 전문가와 백엔드 전문가를 따로 두는 것이 효율적이라는 판단에서 비롯되었다. 콘웨이의 법칙이 말하듯, 조직이 분리되면 시스템도 자연스럽게 분리된다.
장점: 각 영역의 전문성을 높일 수 있다. 독립적인 기술 선택이 가능하다.
한계: 프론트엔드가 하나의 거대한 SPA로 남아 있어, 프론트엔드 내부의 복잡도 문제는 해결되지 않는다.
2.3 3단계: 백엔드 마이크로서비스
백엔드가 하나의 큰 서비스에서 여러 개의 작은 서비스로 분해되었다. 각 서비스가 특정 비즈니스 도메인(사용자 관리, 주문, 결제 등)을 담당한다.
특징:
- 백엔드가 도메인별로 독립 서비스로 분리
- 서비스 간 API 또는 메시지 큐로 통신
- Aggregation Layer의 등장: BFF(Backend For Frontend), API Gateway, GraphQL
BFF(Backend For Frontend) 패턴:
프론트엔드가 여러 백엔드 서비스를 직접 호출하면 복잡해지므로, 프론트엔드와 백엔드 사이에 중간 계층을 둔다. 이 계층이 여러 서비스의 데이터를 모아서 프론트엔드가 필요한 형태로 가공해준다.
장점: 백엔드의 확장성과 유연성이 크게 향상된다.
한계: 프론트엔드는 여전히 하나의 모놀리스로 남아 있다. 백엔드가 아무리 잘게 나뉘어도, 프론트엔드가 병목이 될 수 있다. 여러 팀이 하나의 프론트엔드 코드베이스에서 작업하면서 충돌이 발생한다.
2.4 4단계: 마이크로프론트엔드
마침내 마이크로서비스의 원칙이 프론트엔드까지 확장된다. 프론트엔드도 독립적으로 개발, 배포, 운영 가능한 작은 애플리케이션들의 조합으로 구성된다.
특징:
- 프론트엔드가 여러 독립적인 마이크로앱으로 분해
- 각 마이크로앱이 독립적으로 개발, 테스트, 배포
- 엔드투엔드(End-to-End) 팀이 프론트엔드부터 백엔드까지 담당
3. 마이크로프론트엔드의 정의
마이크로프론트엔드에 대한 가장 널리 인용되는 정의는 다음과 같다:
"독립적으로 제공 가능한 프론트엔드 애플리케이션이 더 큰 전체로 구성되는 아키텍처 스타일" — Cam Jackson, Martin Fowler's Blog (2019)
이 정의에서 핵심 키워드를 분석하면:
- 독립적으로 제공 가능한(independently deliverable): 각 부분이 다른 부분과 무관하게 개발, 테스트, 배포될 수 있다
- 프론트엔드 애플리케이션: 사용자에게 보이는 UI 영역이다
- 더 큰 전체로 구성되는: 개별 조각들이 모여 하나의 일관된 사용자 경험을 만든다
- 아키텍처 스타일: 하나의 고정된 기술이 아니라, 다양한 방식으로 구현 가능한 설계 철학이다
4. 엔드투엔드 팀 구조
마이크로프론트엔드의 가장 큰 조직적 변화는 엔드투엔드 팀(목적 조직, 크로스 펑셔널 팀) 구조로의 전환이다.
기능 조직 vs 목적 조직
| 구분 | 기능 조직 (모놀리식) | 목적 조직 (마이크로프론트엔드) |
|---|---|---|
| 팀 구성 | 기술 역할 기준 (FE팀, BE팀) | 비즈니스 도메인 기준 (검색팀, 결제팀) |
| 의사소통 | 팀 간 잦은 조율 필요 | 팀 내에서 대부분 해결 |
| 배포 | 전체 합의 후 일괄 배포 | 각 팀이 독립적으로 배포 |
| 책임 범위 | 기술 계층에 한정 | 기능의 전체 수명 주기 |
| 자율성 | 낮음 (의존성 높음) | 높음 (독립적 결정 가능) |
기능 조직에서는 하나의 기능을 완성하려면 프론트엔드 팀, 백엔드 팀, QA 팀, 운영 팀이 모두 관여해야 한다. 팀 간 커뮤니케이션 비용이 높고, 일정 조율이 어렵다.
목적 조직에서는 하나의 팀이 특정 비즈니스 기능에 대한 프론트엔드부터 백엔드, 테스트, 배포까지 전체를 책임진다. 팀 내에서 대부분의 의사결정이 이루어지므로 속도가 빠르다.
5. 디자인 스테미너 가설: 좋은 아키텍처의 가치
마틴 파울러(Martin Fowler)는 **"디자인 스테미너 가설(Design Stamina Hypothesis)"**을 통해 소프트웨어 설계의 중요성을 설명했다.
가설의 핵심 내용:
설계 없이 개발하면 초반에는 빠르게 진행된다. 아키텍처를 고민하거나 설계할 시간을 코딩에 투입하기 때문이다. 하지만 시간이 지나면서 기술 부채가 쌓이고, 코드가 복잡해지며, 새로운 기능을 추가하는 비용이 기하급수적으로 증가한다.
좋은 설계로 개발하면 초반에는 느리다. 아키텍처를 설계하고, 추상화를 만들고, 인터페이스를 정의하는 데 시간이 걸린다. 하지만 이 투자 덕분에 코드의 복잡도가 관리되고, 새로운 기능 추가가 지속적으로 빠른 속도를 유지한다.
교차 지점(Crossover Point) 이후에는 좋은 설계가 설계 없는 접근보다 누적 기능량에서 앞서게 된다. 그리고 시간이 갈수록 그 격차는 점점 더 벌어진다.
마이크로프론트엔드와의 관련성:
마이크로프론트엔드는 초기에 상당한 설계 비용이 드는 아키텍처다. 그러나 디자인 스테미너 가설에 따르면, 시스템이 충분히 커지는 시점에서는 이 초기 투자가 큰 보상을 가져다 준다. 반대로 말하면, 시스템이 작고 단순하다면 이 투자가 오히려 과도한 비용이 될 수 있다.
6. 항상 절대적으로 맞는 아키텍처는 없다
소프트웨어 아키텍처에서 가장 중요한 원칙 중 하나는 **"은탄환은 없다(No Silver Bullet)"**는 것이다. 마이크로프론트엔드가 항상 모놀리식보다 우월한 것은 아니다.
모놀리식이 더 적합한 경우:
- 소규모 팀 (5명 이하)이 개발하는 프로젝트
- 초기 스타트업 제품으로 빠른 출시가 최우선인 경우
- 비즈니스 도메인이 단순하고 명확히 분리되기 어려운 경우
- 트래픽이 적고 확장 요구가 낮은 내부 도구
마이크로프론트엔드가 적합한 경우:
- 여러 팀이 하나의 대규모 프론트엔드를 함께 개발하는 경우
- 독립적인 배포 주기가 필요한 경우
- 서로 다른 기술 스택을 사용해야 하는 레거시 통합 상황
- 제품의 규모가 크고, 비즈니스 도메인이 명확히 분리되는 경우
올바른 아키텍처 선택 기준:
- 팀 규모와 구조: 팀이 얼마나 크고, 어떻게 조직되어 있는가?
- 시스템 복잡도: 비즈니스 도메인이 얼마나 복잡한가?
- 성장 전망: 앞으로 시스템이 얼마나 커질 것인가?
- 배포 빈도: 얼마나 자주, 독립적으로 배포해야 하는가?
- 기술 부채: 기존 레거시 시스템과의 통합이 필요한가?
아키텍처 결정은 순수한 기술적 판단이 아니라, 조직, 비즈니스, 기술을 종합적으로 고려한 전략적 결정이다.
핵심 정리
| 핵심 개념 | 요약 |
|---|---|
| MSA | 하나의 큰 시스템을 작고 독립적인 서비스의 집합으로 분해하는 아키텍처 |
| 웹 개발의 4단계 진화 | 모놀리스 -> FE/BE 분리 -> BE 마이크로서비스 -> 마이크로프론트엔드 |
| 마이크로프론트엔드 정의 | 독립적으로 제공 가능한 프론트엔드 애플리케이션이 더 큰 전체로 구성되는 아키텍처 스타일 |
| 엔드투엔드 팀 | 비즈니스 도메인 기준으로 FE/BE/QA/Ops를 하나의 팀에 구성 |
| 콘웨이의 법칙 | 소프트웨어 구조는 조직의 커뮤니케이션 구조를 반영한다 |
| 디자인 스테미너 가설 | 좋은 설계는 초기에 느리지만 장기적으로 더 빠른 개발을 가능하게 한다 |
| 은탄환은 없다 | 상황에 맞는 아키텍처를 선택하는 것이 가장 중요하다 |
다음 단계
이번 장에서는 마이크로프론트엔드가 왜 등장했는지, 그 역사적 맥락과 핵심 개념을 살펴보았다. 다음 장에서는 모놀리식 프론트엔드와 마이크로프론트엔드를 8가지 구체적인 기준으로 비교하여, 각각의 장단점을 더 명확하게 이해한다.