[Pattern] Microservices vs Monolith: 언제 분리, 언제 통합

Microservices, Monolith, Modular monolith, Service boundary, Conway's Law, Distributed monolith

정의

	Monolith	Modular Monolith	Microservices
배포 단위	1개	1개 (모듈 명확)	N개
데이터	단일 DB	단일 DB (스키마 분리)	DB per service
통신	함수 호출	함수 호출	네트워크 (HTTP/gRPC)
운영 복잡도	낮음	낮음	높음
스케일링	전체 함께	전체 함께	service 별 독립
장애 격리	약함	약함	강함 (이상적)
적합 팀	< 30	< 100	100+

결정 트리

flowchart TD
    Q1{팀 크기}
    Q1 -->|< 10| Mono[Monolith]
    Q1 -->|10-50| Q2{성장 속도?}
    Q2 -->|느림| Mono
    Q2 -->|빠름| MM[Modular Monolith]
    Q1 -->|50-200| MM
    Q1 -->|200+| MS[Microservices]
    MM -->|"진짜 필요해지면"| MS

시작은 Monolith (Fowler 의 “Monolith First”)

flowchart LR
    Start[새 프로젝트] --> Mono[Monolith로 시작]
    Mono --> Grow[성장 + 도메인 명확]
    Grow --> MM[Modular Monolith]
    MM --> Carve[필요시 service 분리]
    Carve --> MS[Microservices 일부]

Microservices 가 진짜 도움될 때

flowchart TD
    Q1{독립 배포 절실?}
    Q1 -->|예| C1[조건 1 ✓]
    Q2{팀 별 자율성 절실?}
    Q2 -->|예| C2[조건 2 ✓]
    Q3{스케일 차이 큼?}
    Q3 -->|예| C3[조건 3 ✓]
    C1 & C2 & C3 -->|모두 ✓| Go[Microservices 도입]

Distributed Monolith (안티 패턴)

flowchart LR
    A[Service A] -->|동기 호출| B[Service B]
    B -->|동기 호출| C[Service C]
    C -->|동기 호출| D[Service D]
    Note1[하나 다운 = 전체 다운]

증상:

• 여러 service 가 함께 배포 되어야 함 (calling contract 변경 시)
• 한 service 다운 = 전체 다운
• 분산의 비용 + monolith 의 결합 동시
• 코드 변경 영향이 service 경계 넘김

Service Boundary 가르는 기준

flowchart TD
    Best[좋은 boundary]
    Best --> B1["Domain (DDD bounded context)"]
    Best --> B2["Team ownership (Conway's Law)"]
    Best --> B3[데이터 모델 자연 분리]
    Bad[나쁜 boundary]
    Bad --> X1["기술 계층 (API / DB / UI)"]
    Bad --> X2["유사 데이터 기준 (DB 테이블 1:1)"]
    Bad --> X3["CRUD 단위 (UserService, OrderService 의 진짜 분리는 어디서?)"]

Conway’s Law

“시스템 구조는 그것을 만든 조직의 의사소통 구조를 닮는다”

flowchart TB
    Team1["Team A<br/>(독립 의사소통)"] --> Service1[Service A]
    Team2["Team B<br/>(독립 의사소통)"] --> Service2[Service B]
    Team3["Team C<br/>(독립 의사소통)"] --> Service3[Service C]
    Team1 -.협업.-> Team2
    Service1 -.API.-> Service2

팀 경계와 service 경계의 일치 가 Conway’s Law 의 실용적 활용. 한 service 가 두 팀에 걸치면 운영 사고.

Inverse Conway Maneuver

반대로 service 구조부터 정해 → 팀 구조 맞추기. 큰 조직 재편 에서 사용.

분리 비용 카탈로그

flowchart TB
    Cost[Microservices 의 추가 비용]
    Cost --> Net[네트워크 호출]
    Cost --> Obs["관측성 (Tracing 필수)"]
    Cost --> Auth[mTLS / Service Mesh]
    Cost --> Data["데이터 일관성 (Saga)"]
    Cost --> Deploy[K8s, CI/CD 복잡도]
    Cost --> Test[Contract / E2E 테스트]
    Cost --> Skill[엔지니어 학습 비용]

모듈 모놀리스 (Modular Monolith)

flowchart TB
    subgraph App[Single deployable]
        U[User module]
        O[Order module]
        P[Payment module]
    end
    U -.interface only.-> O
    O -.interface only.-> P
    App --> DB[(단일 DB<br/>스키마 분리)]

• 모듈 간 직접 호출 금지. interface만.
• 같은 DB, 다른 스키마.
• 나중에 service 분리 쉬움.
• 대부분의 회사가 결국 여기서 멈춤 (충분).

흔한 함정

관련 위키

• api-gateway
• saga-pattern
• cqrs, event-sourcing
• Service Mesh
• distributed-systems-distributed-transaction