2nd/10_Wiki/Topics/Architecture/Monolithic-vs-Microservices.md

---
category: Architecture
tags: [auto-wikified, technical-documentation, merged, architecture]
title: Microservices
description: "마이크로서비스(Microservices)는 애플리케이션을 비즈니스 기능 단위로 구성된 작고 독립적인 서비스들로 분할하는 분산 시스템 아키텍처 스타일입니다 [1, 2]."
last_updated: 2026-05-04
---

# Microservices


## 📌 Brief Summary
마이크로서비스(Microservices)는 애플리케이션을 비즈니스 기능 단위로 구성된 작고 독립적인 서비스들로 분할하는 분산 시스템 아키텍처 스타일입니다 [1, 2]. 각 컴포넌트는 개별적으로 작동하고 테스트 및 배포될 수 있어 대규모 개발 팀에 민첩성을 제공하며 시스템의 장애 복구 능력(failover)과 복원력을 향상시킵니다 [1, 3]. 그러나 내부의 복잡성이 서비스 간의 네트워크 통신으로 이동하기 때문에, 고도의 자동화와 오케스트레이션이 필수적으로 요구되는 접근 방식입니다 [4, 5].

## 📖 Core Content
*   **핵심 철학 및 설계 원칙**
    *   마이크로서비스 아키텍처는 **"한 가지 일을 잘 수행하라(Do one thing and do it well)"**는 유닉스 철학과 일맥상통합니다 [1].
    *   이 아키텍처의 주요 특징으로는 **서비스를 통한 컴포넌트화, 비즈니스 기능 중심의 조직 구성, 스마트 엔드포인트와 단순한 파이프(dumb pipes), 분산된 거버넌스와 데이터 관리, 인프라 자동화, 장애를 고려한 설계(Design for failure)** 등이 있습니다 [1].
    *   각 서비스는 언어에 구애받지 않으므로(Language agnostic) HTTP나 경량 메시징과 같은 프로토콜을 통해 Java, Node.js, Go 등 다양한 플랫폼으로 구현될 수 있습니다 [2].

*   **백엔드 프레임워크별 마이크로서비스 구현**
    *   **Spring Boot & Spring Cloud:** 서비스 디스커버리(Eureka), 회로 차단기(Hystrix), 지능형 라우팅(Zuul), 클라이언트 사이드 로드 밸런싱(Ribbon) 등 분산 시스템의 공통 패턴을 신속하게 구현할 수 있는 Netflix OSS 통합을 지원합니다 [6, 7]. 현재는 Spring Cloud Load Balancer와 같은 커뮤니티 주도의 솔루션으로 진화하며 엔터프라이즈 마이크로서비스의 핵심 뼈대를 제공하고 있습니다 [8].
    *   **NestJS:** TCP, Redis, Kafka, RabbitMQ, gRPC 등 **다양한 전송 계층(Transport layers)을 내장**하여 마이크로서비스 간의 원활한 통신(요청-응답 및 이벤트 기반 메시지 패턴)을 완벽하게 지원합니다 [9]. 대규모 팀에서 모놀리스를 마이크로서비스 경계로 분할할 때 자연스러운 모듈 시스템을 제공합니다 [9].
    *   **Django & DRF:** 논리적 컨텍스트를 개별 앱으로 분리하고, 전체 프로젝트를 여러 개의 Django 프로젝트로 분할하여 독립적인 마이크로서비스로 구성한 후 Docker-compose나 Kubernetes를 통해 오케스트레이션하는 방식으로 확장할 수 있습니다 [10].

*   **대규모 분산 시스템의 성능 분석 및 모니터링**
    *   Netflix와 같은 대규모 시스템에서는 단일 관점으로 전체의 성능을 파악하는 것이 불가능합니다 [11]. 
    *   이를 해결하기 위해 업스트림 및 다운스트림 종속성을 시각화하는 Slalom, 인프라의 성능 병목 현상을 파악하는 Mogul, 인스턴스 수준의 초고해상도 메트릭을 제공하는 Vector 등 **매크로에서 마이크로 뷰를 자유롭게 전환할 수 있는 정밀한 분석 도구**들이 필수적으로 동반되어야 합니다 [11-15].

## ⚖️ Trade-offs & Caveats
*   **복잡성의 이동과 운영 오버헤드 증가:** 마이크로서비스로의 전환이 시스템의 절대적인 복잡성을 줄여주지는 않습니다. 컴포넌트 내부의 복잡성을 컴포넌트 간의 통신 복잡성으로 이동시킬 뿐입니다 [4, 5]. 따라서 효율적인 배포, 디버깅, 로깅을 위해 반드시 고도화된 오케스트레이션과 자동화 인프라를 먼저 구축해야 합니다 [5, 16].
*   **추적 및 디버깅의 난해함:** 단일 애플리케이션 내에서 모든 것이 처리되는 모놀리스와 달리 분산 시스템에서는 오류 추적이 매우 어렵습니다. 이 때문에 추적성(Traceability)을 확보하기 위해 모든 로깅 이벤트에 **요청 ID(Request ID)**를 반드시 기록해야 하는 추가적인 설계 부담이 발생합니다 [5, 16].
*   **컴포넌트 경계 분할의 위험성:** 명확한 컴포넌트 경계를 정의하지 못하면 개발과 유지보수가 오히려 퇴보하게 됩니다 [4]. 이와 관련하여 업계 전문가인 마틴 파울러(Martin Fowler)는 **"처음부터 마이크로서비스 아키텍처로 시작하지 말고 모놀리스로 시작하라"**고 권장하며, 모놀리스가 문제를 일으킬 때 비로소 마이크로서비스로 분할할 것을 조언합니다 [17].
*   **조직 규모에 따른 제약:** 20명 미만의 소규모 개발팀이라면 마이크로서비스를 도입하기보다는 모놀리스로 시작하는 것이 유지보수에 유리합니다 [16]. 또한 고부하 환경에서는 동기식 HTTP 통신이 병목이 될 수 있으므로, 초기부터 메일, 알림, 로깅과 같은 작업에 **자동 백프레셔(Back pressure)가 가능한 비동기 메시징**을 도입하는 것이 권장됩니다 [16].

---
*Last updated: 2026-05-03*

## 📚 Legacy Insights & Additional Context
> [!NOTE]
> Below is content merged from previous versions of this documentation.

## 📌 한 줄 통찰 (The Karpathy Summary)
> "단단한 한 덩어리의 성(Castle)인가, 유기적으로 연결된 수많은 기지(Off-post)인가." 전체 서비스를 하나의 실행 단위로 묶을 것인지, 아니면 기능별로 쪼개어 네트워크로 통신하게 할 것인지에 대한 아키텍처의 거대한 양갈래 길이다.

## 📖 구조화된 지식 (Synthesized Content)
- **Monolithic (모놀리식)**:
    - **Pros**: 개발이 단순하고, 통합 테스트가 쉬우며, 배포가 간편함.
    - **Cons**: 하나만 고장 나도 전체 서비스 다운. 코드 베이스가 커지면 빌드 시간이 기하급수적으로 늘어남.
- **Microservices (MSA)**:
    - **Pros**: 기능별 독립적인 기술 스택 사용 가능. 특정 기능만 부분적 스케일링 가능. 장애 격리 우수.
    - **Cons**: 네트워크 지연 발생. 분산 데이터 무결성 보장 어려움. 인프라 구축 비용 폭증.
- **Decision Rule**: "서비스가 충분히 커서 팀 간 소통 비용이 개발 비용을 압도할 때만 MSA로 간다."

## ⚠️ 모순 및 업데이트 (RL Update)
- 최근에는 MSA의 과도한 복잡성에 실망한 기업들이 다시 모놀리식으로 돌아오는 '회귀 현상'이 있다. 하지만 단순히 과거로 가는 것이 아니라, 모놀리식의 편의성과 마이크로서비스의 명확한 경계(Bounded Context)를 결합한 **'Modular Monolith'**가 현실적인 최적 대안으로 급부상하고 있다.

## 🔗 지식 연결 (Graph)
- Related: [[Event-Driven-Architecture|Event-Driven-Architecture]] , Domain-Driven-Design
- Pattern: Saga-Pattern