Microservices Principles & Decomposition

1. Overview

마이크로서비스 원칙 및 분해(Microservices Principles & Decomposition, MPD)는 관리가 불가능할 정도로 비대해진 모놀리식(Monolithic) 시스템을 '작고 독립적인' 명령 체계로 해체하여, 기술의 자율성과 하드웨어의 유연성을 극대화하는 아키텍처의 민주화입니다.

학습자는 단순히 코드를 파일별로 나누는 것을 넘어, 비즈니스 영역을 기준으로 독립적인 하드웨어 수명주기를 갖게 만드는 **도메인 중심 설계(DDD)**의 수리적 사상을 배웁니다. 특히, 하나의 서비스가 다른 서비스의 장애에 물리적으로 휘둘리지 않게 만드는 **격리(Isolation)**의 법칙과, 각 서비스가 가장 적합한 언어와 DB를 선택하는 **폴리글랏(Polyglot)**의 물리적 이점을 익힙니다. 이를 통해 수천 명의 개발자가 서로의 발을 밟지 않고도 매일 수천 번의 배포를 수행할 수 있는 하이엔드 조직-시스템 일체형 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Core Principles: 강한 응집도(Cohesion), 느슨한 결합(Coupling), 독립적 배포성
• Decomposition Strategies: 비즈니스 케이퍼빌리티(Business Capability) 및 하위 도메인(Sub-domain) 기반 분해
• The Strangler Fig Pattern: 레거시를 안전하게 마이크로서비스로 물리 이행하는 기법
• Service Communication Dynamics: 동기 HTTP/gRPC vs 비동기 메시징의 물리적 선택
• Data per Service: 데이터베이스 공유를 금지하고 물리적으로 격리하는 원칙

Out-of-Scope

• 컨테이너(Docker, K8s)의 세부 설치 및 운영 (07-06-02/03 영역에서 분담)
• 구체적인 리액티브 프로그래밍 코드 상세 (07-04-03 영역에서 분담)

Boundaries

• MPD vs. Distributed Patterns: 분산 패턴(07-01-04)이 '구현 도구' 에 집중한다면, MPD는 '시스템을 어떻게 쪼개고 경계를 칠 것인가'라는 근본적인 구조 설계에 집중하여 구분합니다.

3. Counterexample

• 단순히 "API를 여러 개로 쪼개기"라 설명하는 것은 MPD 학습이 아닙니다. 왜 여러 서비스가 하나의 **공유 데이터베이스(Shared DB)**를 쓸 때 '물리적 결합도'가 발생하여 마이크로서비스의 모든 이점이 수리적으로 소멸하는지 증명할 수 있어야 하며, 서비스들이 너무 잘게 쪼개져 네트워크 통신 횟수($N+1$ 호출)가 기하급수적으로 늘어나는 '나노서비스'의 물리적 재앙을 논증하지 못한다면 MPD의 비용 효율을 이해하지 못한 것입니다.

4. Prerequisites

• Monolithic to Microservices Evolution (Basic): 고전적 아키텍처의 한계 이해가 필수입니다. (07-01-01 MME)
• Domain-Driven Design (Recommended): 바운디드 컨텍스트(Bounded Context) 이해가 권장됩니다. (09-02-04 DDD)

5. Learning Map

1. The Monolith Prison: 하나로 묶여서 같이 죽고 같이 사는 하드웨어 결합의 고통을 인지합니다.
2. Finding the Seams: 비즈니스 논리의 틈새(Seam)를 찾아 '칼'을 대어 물리적으로 자를 부위를 정합니다.
3. Autonomous Cells: 쪼개진 서비스들이 각자의 DB와 프로세스를 가지고 독립적으로 숨 쉬게 만듭니다.
4. Coordinated Dance: 흩어진 세포들이 서로 소통하며 하나의 기능(Flow)을 완성하는 분산 지휘 물리를 완성합니다.

6. Learning Topics

Basic

Core: 마이크로서비스의 3대 철칙 (Core Principles)

• Why to Learn: 유행을 따르는 것이 아니라, 조직의 속도와 하드웨어의 안정성을 물리적으로 얻기 위해서입니다.
• What to Learn:
  • Independent Deployability: 옆 서비스를 끄지 않고도 내 것만 배포할 수 있는 물리적 권리
  • Business Alignment: 기술 계층(UI-Server-DB)이 아닌 비즈니스 가치(주문-결제) 중심의 분할
  • Decentralized Governance: 서비스마다 가장 빠른 하위 기술을 선택하는 자치권
• How to Learn:
  • 소스 코드가 하나일 때와 열 개일 때, 빌드 속도와 하드웨어 리소스 효율의 수리적 격차 측정 실습
  • 모놀리스 시스템에서 발생한 '메모리 릭'이 전체 기능을 마비시키는 물리 과정 분석
• Implement: 각자의 영역에만 집중하는 두 개의 독립된 API 서버(예: UserSvc, ProductSvc) 구성 예시

Recommended

Core: 도메인 기반 시스템 분해 (Decomposition Math)

• Why to Learn: 잘못 쪼개서 통신 비용만 늘어나는 최악의 상황을 물리적으로 방지하기 위함입니다.
• What to Learn:
  • Bounded Context: 데이터의 의미가 일관되게 유지되는 수리적 경계
  • High Cohesion / Low Coupling: 내부 결속은 강하게, 외부 연결은 가늘게 만드는 설계 극치
  • Interaction Map: 서비스들이 서로를 얼마나 자주 부르는지 시각화하는 물리 관계도
• How to Learn:
  • 쇼핑몰 도메인을 '주문', '인벤토리', '배송' 컨텍스트로 분류하고 겹치는 데이터(예: 상품명)의 처리 방식 설계
  • 서비스 간 의존성 그래프를 그려보고 '순환 의존(Circular Dependency)'의 물리적 위험성 산출
• Implement: 특정 바운디드 컨텍스트 내에서만 통용되는 데이터 모델(DTO) 정의

Practical

Core: 서비스 간 통신과 데이터 격리 (Communication & Data)

• Why to Learn: 네트워크라는 물리적 장애물 위에서 성능과 정합성을 동시에 잡기 위해서입니다.
• What to Learn:
  • Distributed Data: 원격지에 흩어진 데이터를 '조인' 없이 가져오는 물리적 기법
  • API Gateway: 수많은 서비스의 입구를 하나로 묶는 물리 중개 장치
  • Circuit Breaking in Communication: 통신이 끊어질 때를 대비한 하드웨어 안전 회로
• How to Learn:
  • 공유 DB 환경에서 하나의 테이블 스키마 변경이 열 개의 서비스를 어떻게 물리적으로 고장내는지 재현 실습
  • REST, gRPC, MQ 중 호출 빈도와 데이터 크기에 따른 최적의 물리 프로토콜 선정
• Implement: API 게이트웨이 뒤에서 두 서비스를 순차적으로 호출하여 결과를 합치는 CompositeSvc

Advanced

Core: 전환 전략과 시스템 진화 물리학 (Migration Physics)

• Why to Learn: 거대한 라이브 서비스를 멈추지 않고 엔진을 마이크로서비스로 갈아끼우기 위함입니다.
• What to Learn:
  • Strangler Fig Application: 낡은 시스템을 조금씩 감싸며 결국 대체하는 물리적 전이
  • Legacy Bridge: 구시스템과 신시스템 사이에서 데이터를 동기화하는 물리적 연결 통로
  • Testing at Scale: 수천 개의 서비스가 연동되는 환경에서의 수리적 실효성 검증
• How to Learn:
  • 프록시(Proxy)를 이용해 낡은 API 주소를 신규 마이크로서비스로 하나씩 돌리는(Routing) 실습
  • 전환 과정에서 데이터 불일치($Inconsistency$)가 발생할 확률을 수리적으로 모델링
• Implement: 신구 시스템에 데이터를 동시에 쓰고 정합성을 검증하는 MigrationVerification 도구

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Design / Software Structure and Architecture (Distributed architectures) — Structural context.
• [P1] CS2023 - SE/Software Engineering (Component-based software engineering) — Design requirements.

Secondary

• [Building Microservices] Sam Newman — The definitive guide to the "why" and "how".
• [Microservices Patterns] Chris Richardson — Practical decomposition strategies.

Industry

• [Martin Fowler: Microservices Guide] — The seminal blog post.
• [AWS: Microservices on AWS] — Cloud-native implementation guide.

9. Final Checklist

Primary

• '마이크로서비스' 아키텍처가 왜 '독립적 배포성'을 물리적 최우선 가치로 두는지 설명 가능한가? (P2)
• '비즈니스 도메인' 기반 분해가 왜 하드웨어 운영 측면에서 '응집도'를 높이는지 수리적으로 논증할 수 있는 가? (P1)

Secondary

• '데이터베이스 공유'가 마이크로서비스로의 확장을 물리적으로 가로막는 결정적 장애물임을 소통 가능한가?
• 스트랭글러 피그(Strangler Fig) 패턴을 사용하여 대규모 기간계 시스템의 리스크를 줄이며 전환하는 수순을 입증할 수 있는 가?

Industry

• 팀의 인원수와 비즈니스 복잡도를 고려하여 마이크로서비스의 '적정 개수'를 수리적 한계($Overhead$) 내에서 제안할 수 있는 가? (SFIA)
• 서로 다른 두 서비스가 동일한 '사용자'라는 개념을 다룰 때, 각 바운디드 컨텍스트에서 모델이 어떻게 물리적으로 달라야 하는지 분석할 수 있는 가?