마이크로서비스 아키텍처 2025 완전 가이드: 모놀리스에서 MSA로, 그리고 다시 모듈러 모놀리스로

┌─────────────────────────────────────┐
│           Monolith Application      │
│  ┌─────────┐ ┌─────────┐ ┌───────┐ │
│  │  User    │ │  Order  │ │Payment│ │
│  │  Module  │ │  Module │ │Module │ │
│  └────┬─────┘ └────┬────┘ └──┬────┘ │
│       └──────┬─────┴─────────┘      │
│         ┌────▼────┐                 │
│         │  Shared │                 │
│         │   DB    │                 │
│         └─────────┘                 │
└─────────────────────────────────────┘

┌────────┐    ┌────────┐    ┌────────┐
│Service A│    │Service B│    │Service C│
└───┬─────┘    └───┬─────┘    └───┬─────┘
    └──────────────┼──────────────┘
              ┌────▼────┐
              │   ESB   │
              │(Message │
              │  Bus)   │
              └─────────┘

┌─────────┐   ┌─────────┐   ┌─────────┐
│ User    │   │ Order   │   │ Payment │
│ Service │   │ Service │   │ Service │
│  :8080  │   │  :8081  │   │  :8082  │
└──┬──────┘   └──┬──────┘   └──┬──────┘
   │  REST/gRPC  │   Event    │
   ▼             ▼            ▼
┌──────┐    ┌──────┐    ┌──────┐
│UserDB│    │OrderDB│   │PayDB │
└──────┘    └──────┘    └──────┘

Timeline:
2000 ──── 2005 ──── 2014 ──── 2020 ──── 2025
 │         │         │         │         │
 ▼         ▼         ▼         ▼         ▼
Monolith  SOA    Microservices  서비스    Modular
                               메시 확산  Monolith
                                          재부상

# Shopify의 Packwerk를 이용한 모듈 경계 정의
# packages/checkout/package.yml
enforce_dependencies: true
enforce_privacy: true
dependencies:
  - packages/inventory
  - packages/payment

┌─────────────────────────────────────────────┐
│            Modular Monolith                 │
│                                             │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
│  │  User   │  │  Order  │  │ Payment │    │
│  │ Module  │  │ Module  │  │ Module  │    │
│  │         │  │         │  │         │    │
│  │ Public  │  │ Public  │  │ Public  │    │
│  │   API   │◄─►   API   │◄─►   API   │    │
│  │         │  │         │  │         │    │
│  │ Private │  │ Private │  │ Private │    │
│  │  Impl   │  │  Impl   │  │  Impl   │    │
│  └──┬──────┘  └──┬──────┘  └──┬──────┘    │
│     │            │            │            │
│  ┌──▼──┐     ┌──▼──┐     ┌──▼──┐         │
│  │user │     │order│     │pay  │         │
│  │schema│    │schema│    │schema│         │
│  └─────┘     └─────┘     └─────┘         │
│     └────────────┼────────────┘            │
│           ┌──────▼──────┐                  │
│           │  Shared DB  │                  │
│           │ (분리 스키마)│                  │
│           └─────────────┘                  │
└─────────────────────────────────────────────┘

// Java 모듈러 모놀리스 예시 (Spring Modulith)
@ApplicationModule(
    allowedDependencies = {"order", "shared"}
)
package com.example.payment;

// 모듈 간 통신은 이벤트로
@Service
public class PaymentService {

    private final ApplicationEventPublisher events;

    @Transactional
    public PaymentResult processPayment(PaymentRequest request) {
        Payment payment = Payment.create(request);
        paymentRepository.save(payment);

        // 모듈 간 이벤트 발행 (직접 의존 없음)
        events.publishEvent(new PaymentCompletedEvent(
            payment.getId(),
            payment.getOrderId(),
            payment.getAmount()
        ));

        return PaymentResult.success(payment);
    }
}

시작: 새 프로젝트
  │
  ▼
팀 규모가 50명 이상인가? ──Yes──▶ 도메인이 명확히 분리되어 있는가?
  │                                    │
  No                                  Yes ──▶ MSA 고려
  │                                    │
  ▼                                   No ──▶ 모듈러 모놀리스
독립적 확장이 필요한 서비스가 있는가?
  │
  Yes ──▶ 해당 서비스만 분리 (하이브리드)
  │
  No ──▶ 모놀리스 또는 모듈러 모놀리스

┌─────────────── E-Commerce Domain ───────────────┐
│                                                  │
│  ┌──────────────┐    ┌──────────────┐           │
│  │  Catalog     │    │  Order       │           │
│  │  Context     │    │  Context     │           │
│  │              │    │              │           │
│  │ - Product    │    │ - Order      │           │
│  │ - Category   │    │ - OrderItem  │           │
│  │ - Price      │    │ - Shipment   │           │
│  └──────────────┘    └──────────────┘           │
│                                                  │
│  ┌──────────────┐    ┌──────────────┐           │
│  │  Identity    │    │  Payment     │           │
│  │  Context     │    │  Context     │           │
│  │              │    │              │           │
│  │ - User       │    │ - Payment    │           │
│  │ - Role       │    │ - Refund     │           │
│  │ - Permission │    │ - Invoice    │           │
│  └──────────────┘    └──────────────┘           │
└──────────────────────────────────────────────────┘

┌────────────┐                    ┌────────────┐
│  Upstream  │                    │ Downstream │
│  Context   │ ──Conformist────▶  │  Context   │
│            │                    │            │
│  (Order)   │ ──ACL──────────▶  │ (Payment)  │
│            │                    │            │
│            │ ──OHS/PL───────▶  │ (Shipping) │
└────────────┘                    └────────────┘

ACL: Anti-Corruption Layer (번역 계층)
OHS: Open Host Service (공개 API)
PL:  Published Language (공유 스키마)

// 1. Aggregate 기준 분해
// Order Aggregate Root
public class Order {
    private OrderId id;
    private CustomerId customerId;
    private List<OrderLine> lines;
    private OrderStatus status;
    private Money totalAmount;

    // Aggregate 내부의 비즈니스 로직
    public void addItem(ProductId productId, int quantity, Money price) {
        OrderLine line = new OrderLine(productId, quantity, price);
        this.lines.add(line);
        this.totalAmount = calculateTotal();
    }

    public void confirm() {
        if (this.lines.isEmpty()) {
            throw new OrderException("빈 주문은 확정할 수 없습니다");
        }
        this.status = OrderStatus.CONFIRMED;
    }
}

// order_service.proto
syntax = "proto3";

package order.v1;

service OrderService {
  // 단항 RPC
  rpc CreateOrder (CreateOrderRequest) returns (CreateOrderResponse);

  // 서버 스트리밍 - 주문 상태 업데이트
  rpc WatchOrderStatus (WatchRequest) returns (stream OrderStatusUpdate);

  // 클라이언트 스트리밍 - 대량 주문 등록
  rpc BulkCreateOrders (stream CreateOrderRequest) returns (BulkCreateResponse);

  // 양방향 스트리밍 - 실시간 주문 처리
  rpc ProcessOrders (stream OrderAction) returns (stream OrderResult);
}

message CreateOrderRequest {
  string customer_id = 1;
  repeated OrderItem items = 2;
  ShippingAddress shipping = 3;
}

message OrderItem {
  string product_id = 1;
  int32 quantity = 2;
  int64 price_cents = 3;
}

message CreateOrderResponse {
  string order_id = 1;
  OrderStatus status = 2;
  int64 total_cents = 3;
}

enum OrderStatus {
  ORDER_STATUS_UNSPECIFIED = 0;
  ORDER_STATUS_PENDING = 1;
  ORDER_STATUS_CONFIRMED = 2;
  ORDER_STATUS_SHIPPED = 3;
  ORDER_STATUS_DELIVERED = 4;
}

Producer                         Consumer
┌─────────┐    ┌─────────┐    ┌─────────┐
│ Order   │───▶│  Kafka  │───▶│ Payment │
│ Service │    │ Topic:  │    │ Service │
│         │    │ orders  │    │         │
└─────────┘    └─────────┘    └─────────┘
                    │
                    ├────────▶ ┌─────────┐
                    │          │Inventory│
                    │          │ Service │
                    │          └─────────┘
                    │
                    └────────▶ ┌─────────┐
                               │Notific- │
                               │ation    │
                               │ Service │
                               └─────────┘

// Kafka Producer - 주문 이벤트 발행
@Service
public class OrderEventPublisher {

    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;

    public void publishOrderCreated(Order order) {
        OrderCreatedEvent event = OrderCreatedEvent.builder()
            .orderId(order.getId())
            .customerId(order.getCustomerId())
            .items(order.getItems())
            .totalAmount(order.getTotalAmount())
            .timestamp(Instant.now())
            .build();

        kafkaTemplate.send("orders.created", order.getId(), event)
            .whenComplete((result, ex) -> {
                if (ex != null) {
                    log.error("이벤트 발행 실패: orderId={}",
                        order.getId(), ex);
                    // 보상 로직 또는 재시도
                }
            });
    }
}

// Kafka Consumer - 결제 처리
@Service
public class PaymentEventConsumer {

    @KafkaListener(
        topics = "orders.created",
        groupId = "payment-service",
        containerFactory = "kafkaListenerContainerFactory"
    )
    public void handleOrderCreated(OrderCreatedEvent event) {
        log.info("주문 이벤트 수신: orderId={}", event.getOrderId());
        paymentService.processPayment(event);
    }
}

동기 호출이 필요한가?
  │
  Yes ──▶ 외부 클라이언트 대상인가?
  │          │
  │        Yes ──▶ REST (OpenAPI)
  │          │
  │        No ──▶ 고성능 필요? ──Yes──▶ gRPC
  │                    │
  │                  No ──▶ REST
  │
  No ──▶ 순서 보장이 필요한가?
            │
          Yes ──▶ Kafka (파티션 키로 순서 보장)
            │
          No ──▶ 팬아웃이 필요한가?
                    │
                  Yes ──▶ SNS + SQS / Kafka 토픽
                    │
                  No ──▶ SQS / RabbitMQ

Without Service Mesh:          With Service Mesh:

┌─────────┐  ┌─────────┐     ┌─────────┐  ┌─────────┐
│Service A│──│Service B│     │Service A│  │Service B│
│         │  │         │     │ ┌─────┐ │  │ ┌─────┐ │
│(retry,  │  │(retry,  │     │ │Proxy│─┼──┼─│Proxy│ │
│ auth,   │  │ auth,   │     │ │(side│ │  │ │(side│ │
│ metrics)│  │ metrics)│     │ │car) │ │  │ │car) │ │
└─────────┘  └─────────┘     │ └─────┘ │  │ └─────┘ │
                              └─────────┘  └─────────┘
   모든 서비스에                   통신 관심사를
   통신 로직 구현                  인프라로 위임

# VirtualService - 카나리 배포
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts:
    - order-service
  http:
    - match:
        - headers:
            x-canary:
              exact: "true"
      route:
        - destination:
            host: order-service
            subset: v2
    - route:
        - destination:
            host: order-service
            subset: v1
          weight: 90
        - destination:
            host: order-service
            subset: v2
          weight: 10
---
# DestinationRule - 서킷 브레이커
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: order-service
spec:
  host: order-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: DEFAULT
        http1MaxPendingRequests: 100
        http2MaxRequests: 1000
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

주문 생성 시나리오:
1. Order Service: 주문 생성
2. Inventory Service: 재고 차감
3. Payment Service: 결제 처리
4. Notification Service: 알림 발송

만약 3단계에서 결제 실패하면?
-> 1, 2단계 롤백 필요!

┌─────────┐  OrderCreated  ┌─────────┐  StockReserved  ┌─────────┐
│  Order  │──────────────▶│Inventory│───────────────▶│ Payment │
│ Service │               │ Service │                │ Service │
└─────────┘               └─────────┘                └─────────┘
     ▲                         ▲                          │
     │    StockRelease         │   PaymentFailed          │
     │    (보상)               │◀──────────────────────────┘
     │◀────────────────────────┘
     │    OrderCancelled (보상)

                    ┌────────────────┐
                    │  Order Saga    │
                    │  Orchestrator  │
                    └───┬──┬──┬──┬──┘
           1.주문생성  │  │  │  │  4.알림
                ┌──────┘  │  │  └──────┐
                ▼         │  │         ▼
          ┌─────────┐     │  │   ┌──────────┐
          │  Order  │     │  │   │Notificat-│
          │ Service │     │  │   │ion Svc   │
          └─────────┘     │  │   └──────────┘
              2.재고차감   │  │  3.결제
                    ┌─────┘  └─────┐
                    ▼              ▼
              ┌─────────┐   ┌─────────┐
              │Inventory│   │ Payment │
              │ Service │   │ Service │
              └─────────┘   └─────────┘

// Saga Orchestrator 구현
@Service
public class OrderSagaOrchestrator {

    public Mono<OrderResult> createOrder(CreateOrderCommand command) {
        return Mono.just(new SagaState(command))
            // Step 1: 주문 생성
            .flatMap(state -> orderService.createOrder(state.getCommand())
                .map(order -> state.withOrder(order)))

            // Step 2: 재고 예약
            .flatMap(state -> inventoryService
                .reserveStock(state.getOrder())
                .map(reservation -> state.withReservation(reservation))
                .onErrorResume(e -> compensateOrder(state, e)))

            // Step 3: 결제 처리
            .flatMap(state -> paymentService
                .processPayment(state.getOrder())
                .map(payment -> state.withPayment(payment))
                .onErrorResume(e ->
                    compensateReservation(state, e)))

            // Step 4: 완료
            .flatMap(state -> {
                orderService.confirmOrder(
                    state.getOrder().getId());
                return Mono.just(OrderResult.success(state));
            });
    }

    private Mono<SagaState> compensateReservation(
            SagaState state, Throwable e) {
        log.warn("결제 실패, 재고 보상 시작: orderId={}",
            state.getOrder().getId());
        return inventoryService
            .releaseStock(state.getReservation())
            .then(compensateOrder(state, e));
    }

    private Mono<SagaState> compensateOrder(
            SagaState state, Throwable e) {
        log.warn("주문 보상 시작: orderId={}",
            state.getOrder().getId());
        return orderService
            .cancelOrder(state.getOrder().getId())
            .then(Mono.error(
                new SagaFailedException("Saga 실패", e)));
    }
}

         ┌─────────────┐
         │ Observability│
         └──────┬──────┘
     ┌──────────┼──────────┐
     ▼          ▼          ▼
┌─────────┐ ┌──────┐ ┌─────────┐
│  Logs   │ │Metrics│ │ Traces │
│(이벤트) │ │(수치) │ │(요청흐름)│
└─────────┘ └──────┘ └─────────┘
 무엇이       얼마나     어디서
 발생했는가   발생하는가  발생했는가

┌─────────────────────────────────────────────────────┐
│                    Application                      │
│  ┌─────────────────────────────────────────────┐   │
│  │        OpenTelemetry SDK                    │   │
│  │  ┌──────────┐ ┌──────────┐ ┌──────────┐   │   │
│  │  │  Tracer  │ │  Meter   │ │  Logger  │   │   │
│  │  └──────────┘ └──────────┘ └──────────┘   │   │
│  └────────────────────┬────────────────────────┘   │
└───────────────────────┼─────────────────────────────┘
                        │ OTLP
                        ▼
              ┌─────────────────┐
              │  OTel Collector │
              │  ┌───────────┐  │
              │  │ Receivers │  │
              │  │Processors│  │
              │  │ Exporters │  │
              │  └───────────┘  │
              └────┬──┬──┬──────┘
                   │  │  │
          ┌────────┘  │  └────────┐
          ▼           ▼           ▼
     ┌─────────┐ ┌────────┐ ┌─────────┐
     │  Jaeger │ │Promethe│ │  Loki   │
     │ (Traces)│ │us/Mimir│ │ (Logs)  │
     │         │ │(Metrics│ │         │
     └─────────┘ └────────┘ └─────────┘
          │           │           │
          └─────┬─────┘───────────┘
                ▼
          ┌───────────┐
          │  Grafana  │
          │(Dashboard)│
          └───────────┘

// Spring Boot + OpenTelemetry 자동 설정
// build.gradle
// implementation 'io.opentelemetry.instrumentation:
//   opentelemetry-spring-boot-starter'

// 커스텀 스팬 생성
@Service
public class OrderService {

    private final Tracer tracer;

    public Order createOrder(CreateOrderRequest request) {
        Span span = tracer.spanBuilder("order.create")
            .setAttribute("order.customer_id",
                request.getCustomerId())
            .setAttribute("order.item_count",
                request.getItems().size())
            .startSpan();

        try (Scope scope = span.makeCurrent()) {
            // 주문 생성 로직
            Order order = processOrder(request);

            span.setAttribute("order.id", order.getId());
            span.setAttribute("order.total",
                order.getTotal().doubleValue());
            span.setStatus(StatusCode.OK);

            return order;
        } catch (Exception e) {
            span.setStatus(StatusCode.ERROR, e.getMessage());
            span.recordException(e);
            throw e;
        } finally {
            span.end();
        }
    }
}

RED Method (서비스 관점):
┌──────────────────────────────────────┐
│ R - Rate:     초당 요청 수           │
│ E - Errors:   에러율 (%)             │
│ D - Duration: 응답 시간 (p50/p95/p99)│
└──────────────────────────────────────┘

USE Method (리소스 관점):
┌──────────────────────────────────────┐
│ U - Utilization: 리소스 사용률       │
│ S - Saturation:  대기열 길이         │
│ E - Errors:      리소스 에러 수      │
└──────────────────────────────────────┘

                    ┌─────────────────────┐
                    │    API Gateway      │
   Client ────────▶│                     │
                    │ - 인증/인가          │
                    │ - Rate Limiting     │
                    │ - 요청 라우팅        │
                    │ - 로드 밸런싱        │
                    │ - 응답 캐싱          │
                    │ - 요청/응답 변환     │
                    │ - Circuit Breaker   │
                    │ - 로깅/모니터링      │
                    └──┬──────┬──────┬────┘
                       │      │      │
                       ▼      ▼      ▼
                    ┌─────┐┌─────┐┌─────┐
                    │Svc A││Svc B││Svc C│
                    └─────┘└─────┘└─────┘

┌────────┐     ┌──────────────┐
│  Web   │────▶│  Web BFF     │──┐
│ Client │     │(GraphQL)     │  │
└────────┘     └──────────────┘  │
                                 │    ┌──────────┐
┌────────┐     ┌──────────────┐  ├───▶│ Order    │
│ Mobile │────▶│ Mobile BFF   │──┤    │ Service  │
│  App   │     │(REST, 경량)  │  │    └──────────┘
└────────┘     └──────────────┘  │
                                 │    ┌──────────┐
┌────────┐     ┌──────────────┐  ├───▶│ User     │
│  IoT   │────▶│  IoT BFF     │──┤    │ Service  │
│ Device │     │(MQTT 변환)   │  │    └──────────┘
└────────┘     └──────────────┘  │
                                 │    ┌──────────┐
                                 └───▶│ Product  │
                                      │ Service  │
                                      └──────────┘

Phase 1: Blue(현재) 운영 중
┌─────────────┐     ┌──────────┐
│ Load        │────▶│ Blue v1  │  (100% 트래픽)
│ Balancer    │     │ (Active) │
└─────────────┘     └──────────┘
                    ┌──────────┐
                    │ Green v2 │  (대기 중)
                    │ (Idle)   │
                    └──────────┘

Phase 2: Green으로 전환
┌─────────────┐     ┌──────────┐
│ Load        │     │ Blue v1  │  (대기)
│ Balancer    │     │ (Idle)   │
└─────────────┘     └──────────┘
       │            ┌──────────┐
       └───────────▶│ Green v2 │  (100% 트래픽)
                    │ (Active) │
                    └──────────┘

# Kubernetes + Argo Rollouts 카나리 배포
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: order-service
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause:
            duration: 5m
        - analysis:
            templates:
              - templateName: success-rate
            args:
              - name: service-name
                value: order-service
        - setWeight: 25
        - pause:
            duration: 10m
        - analysis:
            templates:
              - templateName: success-rate
        - setWeight: 50
        - pause:
            duration: 15m
        - setWeight: 100
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service
          image: order-service:v2
          ports:
            - containerPort: 8080

Phase 1: 프록시 배치
┌────────┐     ┌──────────┐     ┌────────────┐
│ Client │────▶│  Proxy   │────▶│  Monolith  │
└────────┘     │(Facade)  │     │  (모든기능) │
               └──────────┘     └────────────┘

Phase 2: 일부 기능 분리
┌────────┐     ┌──────────┐     ┌────────────┐
│ Client │────▶│  Proxy   │─┬──▶│  Monolith  │
└────────┘     │          │ │   │ (기능 축소) │
               └──────────┘ │   └────────────┘
                            │
                            └──▶┌────────────┐
                                │ New Service│
                                │ (분리된기능)│
                                └────────────┘

Phase 3: 대부분 기능 이관
┌────────┐     ┌──────────┐     ┌────────────┐
│ Client │────▶│  Proxy   │─┬──▶│  Monolith  │
└────────┘     │          │ │   │ (최소 기능) │
               └──────────┘ │   └────────────┘
                            │
                            ├──▶┌────────────┐
                            │   │ Service A  │
                            │   └────────────┘
                            ├──▶┌────────────┐
                            │   │ Service B  │
                            │   └────────────┘
                            └──▶┌────────────┐
                                │ Service C  │
                                └────────────┘

Phase 4: 모놀리스 제거
┌────────┐     ┌──────────┐
│ Client │────▶│  API GW  │─┬──▶ Service A
└────────┘     └──────────┘ ├──▶ Service B
                            └──▶ Service C

1. 분석 (2~4주)
   ├── 도메인 모델링 (Event Storming)
   ├── 의존성 분석 (코드/데이터)
   └── 우선순위 결정

2. 기반 구축 (4~8주)
   ├── CI/CD 파이프라인
   ├── 컨테이너/오케스트레이션 환경
   ├── 관측성 스택
   └── API Gateway 배치

3. 첫 서비스 분리 (4~6주)
   ├── 가장 독립적인 도메인 선택
   ├── Anti-Corruption Layer 구현
   ├── 데이터 마이그레이션
   └── 듀얼 라이트 / 이벤트 브리지

4. 반복 분리 (서비스당 2~4주)
   ├── 다음 서비스 분리
   ├── 모놀리스 코드 제거
   └── 통합 테스트

5. 모놀리스 제거
   ├── 잔여 기능 이관
   ├── 데이터 정리
   └── 인프라 해제

// Dual Write 패턴 - 전환 기간 동안 양쪽에 쓰기
@Service
public class UserServiceMigration {

    private final MonolithUserRepository monolithRepo;
    private final NewUserServiceClient newServiceClient;
    private final FeatureFlag featureFlag;

    public User createUser(CreateUserRequest request) {
        // 항상 모놀리스에 쓰기 (기존)
        User user = monolithRepo.save(toEntity(request));

        // 새 서비스에도 쓰기 (마이그레이션)
        try {
            newServiceClient.createUser(
                toNewServiceRequest(user));
        } catch (Exception e) {
            log.warn("새 서비스 동기화 실패, 나중에 재시도", e);
            migrationQueue.enqueue(new SyncEvent(user));
        }

        return user;
    }

    public User getUser(String userId) {
        // Feature Flag로 읽기 전환
        if (featureFlag.isEnabled("read-from-new-service")) {
            try {
                return newServiceClient.getUser(userId);
            } catch (Exception e) {
                log.warn("새 서비스 읽기 실패, 폴백", e);
                return monolithRepo.findById(userId);
            }
        }
        return monolithRepo.findById(userId);
    }
}

분산 모놀리스 체크리스트:
[ ] 하나의 서비스를 배포하려면 다른 서비스도 함께 배포해야 한다
[ ] 서비스 간 동기 호출이 3단계 이상 연쇄된다
[ ] 여러 서비스가 같은 데이터베이스를 직접 읽고 쓴다
[ ] 서비스 간 공유 라이브러리의 버전을 맞춰야 한다
[ ] 하나의 서비스 장애가 전체 시스템을 다운시킨다
[ ] 서비스 경계가 기술 레이어(프론트/백/DB)로 나뉘어 있다

3개 이상 해당되면 분산 모놀리스일 가능성이 높습니다.

문제: 동기 체인
Client -> Order -> Inventory -> Payment -> Shipping
                                           (3초)
         전체 응답시간: 3초 + 각 서비스 처리시간
         하나라도 실패하면 전체 실패

해결: 비동기 이벤트 + 응답은 즉시
Client -> Order (200 OK, 주문 접수됨)
              |
              +-- Event: OrderCreated
              |        |
              |        +-- Inventory (비동기 처리)
              |        +-- Payment (비동기 처리)
              |        +-- Shipping (비동기 처리)
              |
              +-- 상태 조회 API 제공

모놀리스:
├── Spring Boot + JPA
├── Django + PostgreSQL
├── Rails + PostgreSQL
└── Next.js Full Stack

모듈러 모놀리스:
├── Spring Modulith
├── .NET Aspire
├── Go (모듈 패턴)
└── Rust (Workspace)

마이크로서비스:
├── 통신: gRPC (내부) + REST (외부)
├── 메시징: Kafka / RabbitMQ
├── 오케스트레이션: Kubernetes
├── 서비스 메시: Istio / Linkerd
├── 관측성: OpenTelemetry + Grafana
├── CI/CD: ArgoCD / GitHub Actions
└── API Gateway: Kong / Envoy Gateway