Monolithic to Microservices Evolution

1. Overview

모놀리식에서 마이크로서비스로의 진화(Monolithic to Microservices Evolution)는 하나의 거대한 프로세스 안에서 모든 코드가 얽혀 돌아가던 전통적 아키텍처가, 폭발하는 트래픽과 거대해진 조직의 속도를 감당하기 위해 어떻게 수백 개의 독립된 서비스로 쪼개지는지 해부합니다.

학습자는 단일 데이터베이스와 함수 호출(In-process)로 이루어진 **모놀리스(Monolith)**의 완벽한 트랜잭션과 통신 속도 이면에서, 코드베이스가 커질수록 배포 속도가 0에 수렴하는 '빅 볼 오브 머드(Big Ball of Mud)' 안티 패턴을 뜯어봅니다. 나아가 코드를 네트워크 경계 너머로 찢어발겨 각각 독립적인 DB와 배포 파이프라인을 갖게 하는 **마이크로서비스 아키텍처(MSA)**를 해부합니다. 마지막으로, 단순히 코드를 쪼개는 것을 넘어 Conway's Law(콘웨이의 법칙)에 따라 조직 구조와 소프트웨어 구조를 일치시키는 엔터프라이즈 설계 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• 모놀리식 아키텍처 (Monolithic Architecture): 단일 코드베이스, 인메모리(In-process) 함수 호출, 스케일 업(Scale-up), 로컬 트랜잭션.
• 마이크로서비스 아키텍처 (MSA): 분산 배포, Bounded Context(도메인 주도 설계), API 게이트웨이(API Gateway), 독립적 데이터베이스(Database per service).
• 분산 통신 (Distributed Communication): 동기적 REST/gRPC 호출과 비동기 메시지 큐(Event-driven)의 물리적 차이.
• 콘웨이의 법칙 (Conway's Law): 조직의 의사소통 구조가 소프트웨어 아키텍처를 결정한다는 설계 역학.

Out-of-Scope

• Kubernetes 및 Docker 깊은 인프라 구성: 컨테이너 오케스트레이션 및 파드(Pod) 설정 $\rightarrow$ 09-02 CI/CD & DevOps 영역으로 위임.
• 분산 트랜잭션 (Saga Pattern): 2PC, Saga 보상 트랜잭션 깊이 파기 $\rightarrow$ 07-02-04 Distributed Transactions 영역.

Boundaries

• In-process vs Out-of-process: 모놀리스에서 A 객체가 B 객체를 호출하는 속도는 나노초(ns) 단위이며 100% 성공합니다. 하지만 마이크로서비스에서 A 서비스가 B 서비스를 호출하는 것은 네트워크를 타야 하므로 밀리초(ms) 단위로 100만 배 느려지고, 중간에 패킷이 유실되거나 타임아웃이 발생할 수 있습니다. 마이크로서비스는 이 '네트워크의 불확실성과 지연시간(Latency)'을 대가로 '조직의 배포 독립성'을 획득하는 극단적인 철학적 트레이드오프입니다.

3. Counterexample

• 분산 모놀리스 (Distributed Monolith): MSA를 하겠다고 코드를 50개 서비스로 쪼개어 배포했습니다. 그런데 서비스 A가 실행되려면 서비스 B의 DB 테이블 구조를 알아야 하고, 배포할 때마다 A, B, C를 동시에 버전을 맞춰 배포해야만 에러가 안 납니다. 이는 MSA의 장점(독립 배포)은 전부 잃어버리고, 네트워크 지연시간과 분산 디버깅이라는 단점만 폭탄처럼 안게 된 최악의 안티 패턴입니다.
• 스타트업의 성급한 MSA 도입: 트래픽도 적고 팀원도 3명뿐인 초기 스타트업이 넷플릭스 아키텍처를 따라 하겠다고 10개의 마이크로서비스를 구축합니다. 비즈니스 로직을 짜는 시간보다 서비스 간 API 통신 맞추고 인프라를 유지보수하는 데 모든 리소스를 낭비하다가 파산합니다. MSA는 '성능'이 아니라 '조직적 스케일링(개발자 100명 이상)'을 위해 억지로 삼키는 쓴 약임을 망각한 참사입니다.

4. Prerequisites

• 소프트웨어 공학 기초 (Basic): 모듈화, 응집도(Cohesion)와 결합도(Coupling). (09-01 Software Engineering)
• 네트워크 통신 (Basic): HTTP 프로토콜, TCP 타임아웃 개념. (08-01 OSI Model)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 거인의 몰락, 모놀리스의 부패 (The Monolith: Strength & Decay)

• Why to Learn: MSA가 무조건 좋다는 환상을 버리고, 모놀리스가 90%의 프로젝트에서 정답인 이유와, 그것이 언제 한계에 부딪혀 산산조각 나야 하는지 물리적/조직적 임계점을 파악하기 위함입니다.
• What to Learn:
  • Concepts: 모놀리식 아키텍처, 3-Tier 아키텍처, 스파게티 코드, 강한 결합(Tight Coupling), 인메모리 통신, 단일 실패점(SPOF).
  • Skills: 모놀리스 런타임 성능 우위 분석, 배포 병목 현상(Release Train) 식별.
• How to Learn:
  • 1단계: 모놀리스의 강력함: 메모리를 공유하므로 결제 모듈에서 유저 모듈의 함수를 호출하는 시간이 0.0001ms. 트랜잭션이 실패하면 DB 엔진이 한 방에 ROLLBACK 해주는 무결성의 평화를 뜯어봅니다.
  • 2단계: 머드볼(Big Ball of Mud): 코드가 100만 줄이 넘어가고 개발자가 50명이 됩니다. 내가 결제 코드를 수정했는데, 실수로 유저 테이블에 접근하는 코드를 건드려 전체 서버가 다운됩니다. 누군가 코드를 1줄만 고쳐도 100만 줄짜리 코드를 다시 컴파일하고 빌드하는 데 1시간이 걸리는 '배포 공포증'을 해부합니다.
• Implement: 파이썬 의존성 스파게티 시뮬레이션. Payment 모듈이 User 객체의 내부 변수를 직접 수정하고, Order 모듈이 얽혀있는 구조 작성. User 구조체의 변수명을 하나 바꿨더니 컴파일 시 수십 곳에서 에러가 터지는 강결합(Tight Coupling) 참사 데모.

Recommended

Core Topic 02: 경계를 그어라, 마이크로서비스와 Bounded Context (Microservices & Boundaries)

• Why to Learn: MSA의 핵심은 단순히 서버를 여러 개 띄우는 것이 아니라, 각 서버가 '자신만의 도메인 지식'과 '자신만의 DB'를 가지고 남의 일에 간섭하지 않게 물리적 벽을 치는 것임을 장악하기 위함입니다.
• What to Learn:
  • Concepts: MSA (Microservices Architecture), DDD (Domain-Driven Design), Bounded Context (제한된 문맥), Database-per-Service.
  • Skills: 거대 스키마를 도메인별 다중 DB로 물리적 쪼개기(Decomposition).
• How to Learn:
  • 1단계: 독립된 공화국(Bounded Context): '상품(Product)'이라는 단어는 결제 팀에게는 '가격'이고, 배송 팀에게는 '무게와 부피'입니다. 이들을 하나의 거대 Product 테이블에 욱여넣지 않고, 각자의 서비스(결제 서비스, 배송 서비스) 내부에 독립된 모델로 찢어내는 도메인 분리 뼈대를 해부합니다.
  • 2단계: Database per Service: 결제 서비스는 결제 DB(MySQL)만, 배송 서비스는 배송 DB(MongoDB)만 바라봅니다. 다른 서비스의 DB에 직접 SELECT 쿼리를 날리는 것을 아키텍처 수준에서 원천 차단하고 오직 API로만 대화하게 강제하는 물리적 분리를 뜯어봅니다.
• Implement: 도메인 분할 논리 모델링 스크립트. 모놀리스 형태의 Global_DB 딕셔너리에 얽힌 데이터를, Order_Service_DB와 Shipping_Service_DB 두 개의 격리된 메모리 공간으로 찢어내기. 한 서비스가 다른 서비스 데이터를 얻으려면 직접 변수 접근이 불가능하고 HTTP Mock 함수 request_api()를 거쳐야만 하는 캡슐화 데모.

Practical

Core Topic 03: 네트워크의 기만, 함수 호출에서 API 통신으로 (The Network Fallacy)

• Why to Learn: "분산 컴퓨팅의 8가지 오류(Fallacies of Distributed Computing)" 중 첫 번째인 '네트워크는 신뢰할 수 있다'는 환상을 박살 내고, 타임아웃과 재시도(Retry) 폭풍에 대비하는 방어적 런타임 엔지니어링을 세우기 위함입니다.
• What to Learn:
  • Concepts: In-process vs Out-of-process, Network Latency, 타임아웃(Timeout), 부분 실패(Partial Failure), 멱등성(Idempotency).
  • Skills: 동기식 API 호출(REST/gRPC) 시나리오 설계, 장애 전파(Cascading Failure) 방어.
• How to Learn:
  • 1단계: 0.1ms에서 10ms로: 함수 호출이 네트워크 계층을 타며 직렬화/역직렬화(JSON) 및 TCP Handshake를 거치느라 속도가 100배 느려지는 물리적 오버헤드를 해부합니다.
  • 2단계: 부분 실패(Partial Failure): 결제 서비스가 배송 서비스에 API를 날렸는데, 3초 동안 응답이 없습니다. 실패한 것인가요, 아니면 처리 중인데 아직 응답만 안 온 것인가요? 모놀리스에선 절대 존재하지 않던 슈뢰딩거의 고양이(불확실성 상태)를 뜯어봅니다.
• Implement: Python 소켓 통신 실패 시뮬레이터. Service_A가 Service_B에 랜덤한 확률로 응답 지연(sleep 5초)을 일으키도록 호출. Service_A에 2초 타임아웃을 걸어두면, B는 결제 처리를 해버렸는데 A는 실패로 간주하고 유저에게 에러를 뱉는 "분산 환경 정합성 파괴" 상황 콘솔 출력 데모.

Advanced

Core Topic 04: 콘웨이의 법칙과 트레이드오프 철학 (Conway's Law & Trade-offs)

• Why to Learn: 넷플릭스와 아마존이 MSA를 한 진짜 이유는 기술적 성능 향상이 아니라, 수천 명의 개발자가 서로 회의(Communication)하지 않고 각자 기능을 배포하기 위한 조직 공학적 결단이었음을 증명하기 위함입니다.
• What to Learn:
  • Concepts: Conway's Law (콘웨이의 법칙), 역 콘웨이 전략(Inverse Conway Maneuver), 조직 통신 비용 (O(N^2)), 인프라 복잡도 폭발(Observability, CI/CD).
  • Skills: 팀 규모 대비 아키텍처 적합성 평가, 마이크로서비스 도입 임계점(Threshold) 판단.
• How to Learn:
  • 1단계: 콘웨이의 법칙: "소프트웨어 구조는 그것을 설계하는 조직의 통신 구조를 닮는다". 백엔드 팀 100명이 하나의 코드베이스를 만지면 git merge 하느라 하루가 다 갑니다. 조직을 5명짜리 '피자 두 판 팀(Two-Pizza Team)' 20개로 찢고, 각 팀에 1개의 서비스를 할당하는 역설계를 해부합니다.
  • 2단계: 청구서 도착: 배포는 빨라졌지만 인프라 팀의 지옥이 시작됩니다. 20개의 서비스가 쏟아내는 로그를 중앙에서 추적해야 하고(Distributed Tracing), 서비스 간 통신 장애를 잡기 위해 Service Mesh를 깔아야 하는, 어마어마한 운영 비용(Operational Complexity) 트레이드오프를 저울질합니다.
• Implement: 개발자 커뮤니케이션 오버헤드 공식 $O(N^2)$ 계산기. 개발자가 5명일 때 의사소통 채널은 $5 \times 4 / 2 = 10$개. 개발자가 50명일 때는 $50 \times 49 / 2 = 1225$개. 이를 5명짜리 마이크로 팀 10개로 쪼갤 때(팀 내 10개, 팀 간 API 통신 10개 = 총 100개 채널) 의사소통 비용이 어떻게 수학적으로 붕괴하는지 렌더링하는 그래프 스크립트.

7. Terminology

8. References

Primary

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

Secondary

• [Building Microservices] Sam Newman - Microservices Concepts and Bounded Contexts
• [Domain-Driven Design] Eric Evans - Bounded Context and Ubiquitous Language

Industry

• [Martin Fowler's Bliki] - Microservices vs Monolith, Bounded Context
• [AWS Architecture Center] - Introduction to Microservices on AWS and Two-Pizza Teams

9. Final Checklist

Primary

• 모놀리식 환경에서의 인메모리(In-process) 객체 호출과 마이크로서비스 간의 원격 API 호출(Out-of-process)이 겪는 1,000배 이상의 지연 시간(Latency) 차이를 물리적으로 증명할 수 있는가?
• 마이크로서비스가 1개의 통합 DB를 공유하지 않고, 철저하게 Database per Service(서비스별 독립 DB) 원칙을 지켜야만 하는 트랜잭션 의존성 방어 논리를 설명할 수 있는가?

Secondary

• 분산 컴퓨팅 환경에서 '네트워크 타임아웃'이 발생했을 때, 서버 B가 작업을 수행했는지 안 했는지 알 수 없는 부분 실패(Partial Failure) 상황의 위험성을 해부할 수 있는가?
• 분산 모놀리스(Distributed Monolith) 안티 패턴이 어떻게 MSA의 장점(배포 독립성)은 파괴하면서 분산 시스템의 단점(운영 복잡성)만 극대화하는지 논증할 수 있는가?

Industry

• "조직의 구조가 아키텍처를 결정한다"는 콘웨이의 법칙(Conway's Law)을 기반으로, 100명의 개발팀을 어떻게 피자 두 판(Two-Pizza) 크기로 쪼개어 역 콘웨이 전략을 구사할지 아키텍처링 할 수 있는가?
• MSA 환경에서 여러 서비스에 걸친 데이터 조회(예: 내 주문 내역 + 상품 정보 + 배송 상태)를 수행할 때 발생하는 API 분산 호출 병목을 API Gateway나 CQRS 패턴으로 어떻게 우회할지 설계할 수 있는가?