---
id: P-REINFORCE-AI-048
category: "10_Wiki/💡 Topics/Software Architecture"
confidence_score: 0.99
tags: [microservice, architecture, distributed system, scalability]
last_reinforced: 2026-06-XX
github_commit: "[P-Reinforce] Processed Microservices-Architecture.md"
---

# [[Microservices-Architecture|Microservices-Architecture]] (마이크로서비스 아키텍처)

## 📌 한 줄 통찰 (The Karpathy Summary)
> 하나의 거대한 애플리케이션을 작고 독립적인 서비스들의 집합으로 나누어, 각 서비스를 독립적으로 개발, 배포, 확장할 수 있게 하는 분산 시스템 설계 방식이다.

## 📖 구조화된 지식 (Synthesized Content)
- **정의:** 단일 책임 원칙(SRP)을 아키텍처 수준까지 끌어올린 개념이다. 비즈니스 도메인별로 독립적인 서비스 경계(Bounded Context)를 설정하고, 각 서비스를 자체 데이터베이스와 통신 메커니즘으로 운영한다.
- **장점 (Scalability & Resilience):** 
    1. **독립적 배포:** 특정 기능의 장애가 전체 시스템에 영향을 미치지 않는다 (Fault Isolation).
    2. **기술 스택 자유도:** 각 서비스는 가장 적합한 언어와 데이터베이스를 선택할 수 있다 (Polyglot Persistence/Programming).
    3. **확장성:** 트래픽이 몰리는 특정 서비스만 독립적으로 자원을 증설할 수 있다.
- **주요 과제 및 해결책:**
    1. **분산 트랜잭션 관리:** 여러 서비스에 걸친 데이터 일관성 유지가 어렵다. (해결책: Saga 패턴, 이벤트 기반 아키텍처).
    2. **서비스 간 통신 오버헤드:** 네트워크 호출이 빈번하여 지연 시간이 발생할 수 있다. (해결책: API Gateway 도입, 메시지 큐 활용).

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 마이크로서비스가 모든 문제의 해결책은 아니다. 서비스 경계 설정 실패(Poor Bounded Context Identification)는 오히려 복잡성만 높이는 '분산 트랜잭션 지옥'을 만들 수 있다.
- **정책 변화:** MSA 도입 시, 서비스 간 통신 규약 (API Contract) 정의가 가장 중요한 첫 번째 단계이며, 이를 위한 API 게이트웨이 및 서비스 메시(Service Mesh)의 활용이 표준으로 자리 잡고 있다.

## 🔗 지식 연결 (Graph)
- Parent: [[Microservices-Architecture|Microservices-Architecture]]
- Related: [[Bounded Contexts|Bounded Contexts]] , [[Event Storming|Event Storming]] , [[API-First Architecture|API-First Architecture]]
- Raw Source: 00_Raw/Microservices-Architecture.md
---