Microservices Principles & Decomposition

1. Overview

마이크로서비스 원칙과 분해(Microservices Principles & Decomposition)는 수백 명의 개발자가 하나의 거대한 코드베이스(Monolith)에서 서로의 발목을 잡으며 배포를 두려워하던 구시대의 비극을 끝내고, 비즈니스 도메인(Domain)을 기준으로 시스템을 쪼개어 각 팀이 독립적으로 질주할 수 있게 만드는 MSA의 철학적 토대를 해부합니다.

학습자는 단순히 "코드를 여러 개의 파일로 나누는 것"이 아니라, "데이터베이스와 배포 파이프라인까지 완벽하게 찢어내는" **독립 배포성(Independent Deployability)**의 진짜 의미를 뜯어봅니다. 나아가 거대한 코끼리를 어떻게 조각낼 것인가에 대한 해답으로, 콘웨이의 법칙(Conway's Law)과 도메인 주도 설계(DDD)를 결합하여 바운디드 컨텍스트(Bounded Context) 단위로 경계를 긋는 분해(Decomposition) 전략을 장악합니다. 마지막으로, 서비스들이 쪼개지면서 필연적으로 발생하는 네트워크 지연(Latency), 분산 트랜잭션, 데이터 중복이라는 끔찍한 트레이드오프(Trade-off)의 비용을 계산하고 이를 극복하는 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Monolith vs Microservices: 강결합(Coupling)의 한계와 독립 배포성(Independent Deployability)의 가치.
• Conway's Law (콘웨이의 법칙): 조직 구조가 소프트웨어 아키텍처를 결정한다는 철학.
• Decomposition Strategies: 비즈니스 역량(Business Capability) 기반 분해 vs 서브도메인(Sub-domain) 기반 분해.
• Bounded Context (바운디드 컨텍스트): 모호한 비즈니스 경계를 나누는 DDD의 핵심 개념.

Out-of-Scope

• Docker/Kubernetes 구현: 컨테이너 인프라 기술 $\rightarrow$ 07-06-02 Containerization 영역.
• 분산 트랜잭션 (Saga Pattern): 쪼개진 DB 간의 정합성 유지 $\rightarrow$ 07-02-04 Distributed Transactions 영역으로 위임.

Boundaries

• Service-Oriented Architecture(SOA) vs Microservices: 2000년대의 SOA는 수많은 서비스를 무거운 중앙 통제 버스(ESB)로 엮어 "재사용성(Reusability)"을 추구하다 실패했습니다. 반면 현대의 마이크로서비스는 중앙 통제를 버리고 가벼운 통신(HTTP/gRPC)을 사용하며, 재사용성보다 "독립 배포와 대체 가능성(Replaceability)"을 최우선으로 삼는다는 명확한 사상적 차이를 긋습니다.
• DB Per Service (서비스당 DB): 코드는 5개로 쪼갰는데 DB는 예전처럼 1개(Shared DB)를 같이 쓴다면, 이는 마이크로서비스가 아니라 '분산 모놀리스(Distributed Monolith)'라는 최악의 형태입니다. 진정한 분해는 DB 스키마와 물리적 저장소까지 완전히 쪼개어, A 서비스가 죽거나 DB 락(Lock)이 걸려도 B 서비스는 멀쩡히 돌아가야 함을 경계선으로 삼습니다.

3. Counterexample

• 분산 모놀리스(Distributed Monolith)의 비극: 서버를 '주문', '결제', '배송' 3개로 멋지게 쪼갰습니다. 그런데 주문 서버 배포를 하려면 반드시 결제 서버 코드도 살짝 고쳐야 하고, 배송 서버 API도 동시에 업데이트해서 3개를 "금요일 자정에 동시에 배포(Big Bang Deployment)"해야만 에러가 안 납니다. 네트워크 통신 오버헤드(지연)는 다 뒤집어쓰면서, 모놀리스의 단점(결합도)은 그대로 남아있는 극악의 안티 패턴입니다. 원인은 도메인 경계(Bounded Context)를 잘못 그었거나 3개가 하나의 DB를 공유(Shared DB)하고 있기 때문입니다.
• 이력서 주도 개발 (Resume-Driven Development): 하루 접속자가 50명이고 팀원이 2명인 스타트업에서, "요즘은 MSA가 대세니까!"라며 게시판 하나를 10개의 마이크로서비스로 쪼갰습니다. 코드 짜는 시간보다 서비스 간의 인증(JWT)과 네트워크 타임아웃 디버깅, 쿠버네티스 헬스체크 설정에 팀의 리소스를 $90\%$ 낭비하다 회사가 망합니다. 모놀리스 퍼스트(Monolith First) 원칙을 무시하고, 비즈니스 복잡도가 아닌 '유행'에 따라 시스템을 쪼갠 맹목적 공학의 참사입니다.

4. Prerequisites

• 도메인 주도 설계 (Basic): 애그리거트와 바운디드 컨텍스트. (06-02-04 Domain-Driven Data)
• 비동기 통신 (Basic): Pub/Sub과 메시지 큐. (07-04-02 Event-driven Flows)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 거인의 몰락, 모놀리스 딜레마 (The Monolith Dilemma)

• Why to Learn: 처음에는 완벽했던 단일 코드베이스(Monolith)가 비즈니스가 성장함에 따라 어떻게 괴물(Big Ball of Mud)로 변하여 배포를 가로막는지 그 생애 주기를 이해하기 위함입니다.
• What to Learn:
  • Concepts: Monolithic Architecture, Tight Coupling (강결합), Cognitive Load (인지 부하), Big Bang Deployment, Independent Deployability (독립 배포성).
  • Skills: 모놀리스의 병목 현상(빌드 시간, 테스트 시간, 배포 두려움) 지표화.
• How to Learn:
  • 1단계: 스파게티의 저주: 500만 줄의 코드가 한 프로젝트에 있습니다. A 개발자가 '리뷰' 로직을 수정했는데, 그게 '결제' 모듈과 변수를 공유하고 있어서 결제가 터집니다. 아무도 코드를 건드리기 두려워하는 강결합의 공포를 해부합니다.
  • 2단계: 자유의 획득(독립 배포): MSA의 핵심은 "결제팀은 리뷰팀이 뭘 하든 말든, 오늘 하루에 결제 서버만 100번 배포할 수 있다"는 것입니다. 언어(Java vs Go)도 마음대로 고를 수 있는 자유도를 뜯어봅니다.
• Implement: 모놀리스 vs MSA 의존성 시각화. 3개의 기능(User, Order, Payment)이 하나의 전역 객체(Global State)를 공유하여 수정 시 사이드 이펙트가 나는 파이썬 코드(Monolith)와, 이를 완전히 독립된 3개의 클래스(객체)로 찢고 오직 메시지(Event)로만 통신하게 만들어 결합도를 끊어낸 리팩터링 결과 비교 데모.

Recommended

Core Topic 02: 조직이 곧 시스템이다, 콘웨이의 법칙 (Conway's Law & Teams)

• Why to Learn: 시스템 아키텍처를 아무리 멋지게 설계해 봤자, 회사 조직도(팀 구조)와 일치하지 않으면 결국 조직도 모양대로 시스템이 뒤틀려버린다는 통찰을 쥐기 위함입니다.
• What to Learn:
  • Concepts: Conway's Law (콘웨이의 법칙), Inverse Conway Maneuver (역콘웨이 기동), Cross-functional Teams (목적 조직), Two-Pizza Team.
  • Skills: 프론트/백엔드/DBA로 나뉜 기술 조직(Silo)을 도메인 목적(예: 결제 스쿼드) 중심 조직으로 재설계.
• How to Learn:
  • 1단계: 콘웨이의 법칙: "소프트웨어 구조는 그것을 만드는 조직의 소통 구조를 닮는다." 프론트팀, 백엔드팀, DB팀 3개로 나뉘어 있으면 어떤 서비스를 만들든 프론트 $\rightarrow$ API $\rightarrow$ DB의 3계층 아키텍처가 억지로 탄생하는 기현상을 해부합니다.
  • 2단계: 역 콘웨이 기동: MSA를 잘하려면 시스템을 쪼개기 전에 먼저 '결제 스쿼드(프론트+백엔드+기획자)' 8명짜리 팀을 떼어내야 합니다. 이 피자 두 판(Two-Pizza) 크기의 자율적인 팀 구조가 결국 훌륭한 독립적 마이크로서비스를 낳는 역콘웨이 역학을 뜯어봅니다.
• Implement: 커뮤니케이션 오버헤드 계산기. 10명짜리 1팀일 때 통신 경로(Nodes) 수 $N(N-1)/2 = 45$개. 이를 3명, 3명, 4명짜리 3개 팀(마이크로서비스)으로 쪼갰을 때 내부 통신 경로가 급격히 줄어들어 인지 부하(Cognitive Load)가 낮아지는 공식을 수학적으로 증명하는 콘솔 시뮬레이션.

Practical

Core Topic 03: 코끼리를 썰어라, 분해 전략 (Decomposition Strategies)

• Why to Learn: 쪼개는 게 좋다는 건 알겠는데, "어디서부터 어떻게 잘라야" 하나의 서비스가 너무 비대하지도 않고 너무 작지도 않은 황금 비율(Right-sized)을 찾을 수 있는지 도출하기 위함입니다.
• What to Learn:
  • Concepts: Decompose by Business Capability (비즈니스 역량 기반), Decompose by Subdomain (서브도메인 기반 - DDD), Bounded Context, Database per Service.
  • Skills: Strangler Fig Pattern (스트랭글러 패턴)을 활용한 모놀리스 $\rightarrow$ MSA 점진적 분해 및 DB 스키마 분리.
• How to Learn:
  • 1단계: 어색한 쪼개기(명사 기반): "사용자(User)"라는 단어로 무작정 서비스를 만듭니다. 결제팀도 유저 정보가 필요하고, 배송팀도 유저 주소가 필요하니 모든 서비스가 유저 서비스에 API를 던집니다. 유저 서비스가 트래픽을 못 버티고 죽으면 전사 시스템이 몰락하는 안티 패턴을 해부합니다.
  • 2단계: 문맥 기반 쪼개기(Bounded Context): 결제팀이 보는 '유저'는 신용카드 정보입니다. 배송팀이 보는 '유저'는 집 주소입니다. 굳이 하나의 '유저 서비스'로 묶지 말고, 각 팀이 자신의 DB에 필요한 유저 데이터만 중복으로(Data Duplication) 들고 있게 하여 API 호출(결합도)을 끊어버리는 도메인 주도 쪼개기를 뜯어봅니다.
• Implement: Strangler Fig Pattern 라우팅 시뮬레이터. 클라이언트가 API Gateway를 찌름. 기존 모놀리스(/api/v1/*)가 모든 걸 처리하다가, 새로 쪼개진 '결제' 서비스가 완성되면 Gateway 룰을 수정하여 /api/v1/payment 트래픽만 새로운 마이크로서비스 컨테이너로 조용히 빼돌리고, 모놀리스의 코드는 썩게(Strangulate) 놔두는 라우팅 데모.

Advanced

Core Topic 04: 자유의 대가, MSA 청구서 (The Cost of Microservices)

• Why to Learn: 마이크로서비스는 은탄환(Silver Bullet)이 아니라 극악의 복잡도를 돈(인프라 비용)과 타협하는 행위임을 인지하고, 언제 모놀리스로 돌아갈지(Rollback)를 결정하는 아키텍트의 냉혹함을 갖추기 위함입니다.
• What to Learn:
  • Concepts: Network Latency (네트워크 지연), Distributed Transactions (분산 트랜잭션), Observability Overhead, Fallacies of Distributed Computing.
  • Skills: 서비스 분해 전과 후의 인프라 유지 보수 비용 및 네트워크 홉(Hop) 증가에 따른 응답 시간(Latency) 트레이드오프 계산.
• How to Learn:
  • 1단계: 네트워크라는 환상: 모놀리스에서는 주문과 결제가 메모리 함수 호출(0.001ms)로 끝납니다. MSA로 쪼개면 HTTP 네트워크를 타야 합니다(10ms). 만약 1번의 유저 요청이 10개의 마이크로서비스를 거쳐야(Chain) 한다면, 순수 네트워크 지연만 100ms가 넘어가는 '네트워크 홉(Hop)'의 재앙을 해부합니다.
  • 2단계: 트레이드오프의 저울: "팀원이 5명 이하라면 무조건 모놀리스로 짜라." MSA는 서비스 메시(Service Mesh), 중앙 집중형 로깅, 분산 추적(Tracing), CI/CD 파이프라인 수십 개를 관리해야 하는 인프라 지옥을 동반합니다. 넷플릭스나 우버 규모가 아니면 모놀리스(혹은 Modular Monolith)가 훨씬 더 훌륭한 엔지니어링 선택임을 뜯어봅니다.
• Implement: 네트워크 지연(Latency) 증폭 시뮬레이터. 함수 호출 A -> B -> C (모놀리스, 지연 0). 이를 A --(HTTP)--> B --(HTTP)--> C 로 시뮬레이션하고, 네트워크 실패 확률 $1\%$를 주입했을 때 전체 트랜잭션 성공 확률이 어떻게 기하급수적으로 떨어지는지($0.99 \times 0.99 \dots$) 수치로 출력하여 분산 시스템의 연약함(Fragility) 증명.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Software Architecture (Microservices)
• [P5] SFIA - Enterprise IT Architecture (ARCH) - Microservices Architecture

Secondary

• [Building Microservices] Sam Newman - Microservices Principles and Conway's Law
• [Domain-Driven Design] Eric Evans - Bounded Contexts

Industry

• [MartinFowler.com] - Microservices Resource Guide (Strangler Fig Pattern)
• [Netflix TechBlog] - Mastering Chaos - A Netflix Guide to Microservices

9. Final Checklist

Primary

• 수백 명의 개발자가 단일 코드베이스(Monolith)에서 작업할 때 필연적으로 발생하는 인지 부하(Cognitive Load)의 한계와 배포 공포증(Big Bang)을 MSA가 어떻게 해소하는지 설명할 수 있는가?
• 콘웨이의 법칙(Conway's Law)에 따라, 마이크로서비스 아키텍처를 성공적으로 안착시키기 위해 프론트/백엔드 직군별 조직이 아닌 비즈니스 목적 중심의 교차 기능 팀(Cross-functional Team)으로 개편해야 하는 이유를 증명할 수 있는가?

Secondary

• 도메인 주도 설계(DDD)의 바운디드 컨텍스트(Bounded Context)를 활용하여, 전사 공통의 'User' 테이블을 억지로 하나로 유지하는 대신 각 서비스가 자신만의 User 데이터를 중복 저장(Data Duplication)하게 찢어내는 결합 분리 전략을 논증할 수 있는가?
• 낡은 모놀리스 시스템을 한 번에 MSA로 뒤엎는 빅뱅 리라이트(Big Bang Rewrite)의 파국을 피하기 위해, 스트랭글러 패턴(Strangler Fig Pattern)과 API Gateway를 결합한 점진적 트래픽 전환(Routing) 전략을 설계할 수 있는가?

Industry

• 모놀리스 환경에서는 0.1ms면 끝날 함수 호출이 MSA 환경에서는 네트워크 홉(Hop)을 거치며 50ms의 지연(Latency)으로 증폭되는 비용을 식별하고, 언제 서비스 분해를 멈춰야 할지 타협점을 평가할 수 있는가?
• 5개의 서비스로 쪼갰지만 이들이 여전히 하나의 통합 데이터베이스(Shared DB)를 쿼리하고 있다면, A 서비스의 DB 락(Lock)이 B 서비스의 장애로 번지는 '분산 모놀리스(Distributed Monolith)'의 치명적 안티 패턴임을 구조적으로 해부할 수 있는가?