Monolithic to Microservices Evolution

1. Overview

모놀리식에서 마이크로서비스로의 진화(Monolithic to Microservices Evolution, MME)는 시스템의 '규모'와 '변경 속도'가 하드웨어 단일기의 한계를 넘어설 때, 소프트웨어를 어떤 물리적 단위로 쪼개고 연결할 것인지 결정하는 현대 아키텍처의 패러다임 전환을 다룹니다.

과거의 시스템은 하나의 큰 덩어리(Monolith)로 존재하며 메모리 내 함수 호출로 소통했습니다. 학습자는 비즈니스 성장에 따라 이 덩어리가 왜 물리적 배포 지옥과 성능 병목을 유발하는지 배웁니다. 특히, 서비스를 독립적인 네트워크 프로세스로 분리하는 **마이크로서비스 아키텍처(MSA)**의 수리적 사상과, 그 대안으로 떠오르는 **모듈형 모놀리스(Modular Monolith)**의 경계 설계를 익힙니다. 이를 통해 '언제 시스템을 쪼개야 하는가'와 그에 따른 물리적 비용(네트워크 지연, 정합성 부하)을 정밀하게 산출하는 역량을확보합니다.

2. Scope & Boundaries

In-Scope

• Monolith Physics: 단일 프로세스 아키텍처의 공유 메모리 장점과 확장성 한계
• Microservices Anatomy: 서비스 경계 획정(Bounded Context), 독립 배포 단위의 물리 조건
• Modular Monolith: 네트워크 분리 없이 논리적 경계만 구축하는 하이브리드 수리 모델
• Evolutionary Strategies: Strangler Fig 패턴 등을 이용한 점진적 물리 이행 절차

Out-of-Scope

• 개별 서비스 내부의 상세 코딩 패턴 (09-02-XX 영역에서 분담)
• 쿠버네티스 등 인프라 레벨의 오케스트레이션 상세 (07-06-02 영역에서 분담)

Boundaries

• MME vs. Distributed Principles: 분산 시스템 원칙(07-02-XX)이 '분산 환경의 정답'에 집중한다면, MME는 '중앙에서 분산으로 넘어가는 의사결정과 아키텍처 변천사'에 집중하여 구분합니다.

3. Counterexample

• 단순히 "작게 쪼개는 것이 정답"이라 설명하는 것은 MME 학습이 아닙니다. 왜 마이크로서비스가 단일 기기 성능보다 못한 '네트워크 오버헤드'를 발생시키는지 수리 증명할 수 있어야 하며, 데이터베이스를 쪼개지 않은 채 서비스만 분리하여 발생하는 분산 트랜잭션 지옥 시나리오를 논증하지 못한다면 MME의 아키텍처적 무게를 이해하지 못한 것입니다.

4. Prerequisites

• Process & Thread Mechanics (Basic): 단일 프로세스 실행 한계 이해가 필수입니다. (03-02-01 PTM)
• Software Design Principles (Recommended): 결합도와 응집도 기초 이해가 권장됩니다. (09-01-01 기초 역량)

5. Learning Map

1. The Single Giant: 모든 기능이 하나의 메모리 공간을 공유할 때 얻는 물리적 안락함을 이해합니다.
2. Breakdown Logic: 비즈니스 도메인을 기준으로 시스템의 물리적 균열(Seams)을 찾아냅니다.
3. The Network Wall: 함수 호출이 패킷 전송으로 변할 때 하드웨어가 겪는 '지연 시간의 충격'을 배웁니다.
4. Resilient Modularization: 쪼갠 뒤에도 시스템이 하나의 큰 목표를 향해 유기적으로 작동하게 만드는 물리 체계를 완성합니다.

6. Learning Topics

Basic

Core: 모놀리식 아키텍처의 물리적 실체 (Monolith Basics)

• Why to Learn: 분산을 배우기 전, 중앙 집중식 시스템이 왜 수십 년간 표준이었는지 그 물리적 효율을 알기 위해서입니다.
• What to Learn:
  • Single Process/Binary: 모든 코드가 하나의 물리적 메모리 영역에 로드되는 구조
  • Shared Database: 데이터 정합성을 DB 엔진 하나에 전적으로 의존하는 장치
  • Deployment Unit: 수정 시 시스템 전체를 다시 올려야 하는 물리적 제약
• How to Learn:
  • 간단한 쇼핑몰 코드를 하나의 실행 파일로 빌드해 보고, 전역 변수 공유가 얼마나 물리적으로 빠른지 분석 실습
  • 코드 한 줄 고치기 위해 수 GB의 바이너리를 다시 배포할 때의 시간 비용 산출
• Implement: 여러 모듈이 참조로 얽힌 단일 프로젝트 구조 설계 및 빌드 파이프라인 구성

Recommended

Core: 모듈형 모놀리스와 논리적 경계 (Modular Monolith)

• Why to Learn: 마이크로서비스의 복잡도 없이도 대규모 협업이 가능한 '성숙한 단일 구조'를 구축하기 위함입니다.
• What to Learn:
  • Logical Separation: 네임스페이스나 패키지를 이용한 물리적 침범 금지 수리 모델
  • Encapsulated DB Schema: 테이블은 공유하되 접근 권한을 모듈별로 격리하는 물리학
  • Interface-only Dev: 모듈 간 소통을 오직 명세된 인터페이스로 제한하는 규칙
• How to Learn:
  • 의존성 그래프 도구를 이용해 모듈 간에 '순환 참조'가 발생하는 물리적 악순환 추적 실습
  • 공유 테이블을 사용하는 두 모듈의 락(Lock) 경합 분석
• Implement: 빌드 시 모듈 간 의존성 규칙을 위반하면 에러를 내는 ArchitectureGuardian 스크립트

Practical

Core: 마이크로서비스로의 물리적 분해 (Microservices Extraction)

• Why to Learn: 변화의 속도가 다른 기능을 독립적인 네트워크 단위로 떼어내어 생산성을 높이기 위해서입니다.
• What to Learn:
  • Bounded Context: 비즈니스 가치가 물리적 통일성을 갖는 최소 단위 도출
  • Shared-nothing Architecture: 서비스가 각자의 DB와 하드웨어 자원을 소유하는 물리학
  • Polyglot Persistence: 기능에 따라 다른 저장소(SQL/NoSQL)를 선택하는 물리적 유연성
• How to Learn:
  • '사용자' 테이블을 독립 서비스로 떼어낼 때, 기존 주문 테이블과의 '외래 키' 관계가 물리적으로 끊기는 대처 방안 설계 실습
  • 동기(HTTP) 호출과 비동기(Message) 호출의 지연 시간 차이 수리 산출
• Implement: 특정 기능을 별도 프로세스로 분리하고 가벼운 TCP 통신으로 연동하는 기초 분산 프로토타입

Advanced

Core: 이행 전략과 거버넌스 (Evolutionary Governance)

• Why to Learn: 운영 중인 거대 시스템을 중단 없이 조각내어 옮기는 '공중 급유' 기술을 확보하기 위함입니다.
• What to Learn:
  • Strangler Fig Pattern: 낡은 기능을 새로운 서비스가 뒤덮으며 삼키는 물리적 이행 모델
  • Database De-composition: 공유 데이터베이스를 데이터 유실 없이 쪼개는 수리 절차
  • Service Discovery Mechanics: 흩어진 서비스들의 물리 주소를 실시간으로 찾아내는 인프라
• How to Learn:
  • 트래픽의 10%만 새로운 서비스로 보내며 안정성을 검증하는 '카나리(Canary)' 물리 워크로드 설계 실습
  • 마이크로서비스가 너무 많아져서 발생하는 '분산 지옥(Microservices Premium)'의 비용 임계점 분석
• Implement: 프록시 설정을 통해 점진적으로 요청을 구버전에서 신버전으로 돌리는 MigrationTrafficRouter

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Design / Architecture Styles (Distributed systems) — Structural context.
• [P1] CS2023 - SE/Software Engineering (Architectural design) — Core requirements.

Secondary

• [Monolith to Microservices] Sam Newman — The definitive guide to evolution.
• [Building Microservices] Sam Newman — Core principles of the architecture.

Industry

• [AWS: Microservices on AWS (Whitepaper)] — Scalable industry patterns.
• [Martin Fowler: Microservices Guide] — High-level definitions and trade-offs.

9. Final Checklist

Primary

• '모놀리식' 시스템에서 '마이크로서비스'로 넘어갈 때, 하드웨어 성능 측면에서 반드시 감수해야 할 '네트워크 지연' 비용을 수리적으로 설명 가능한가? (P1)
• '독립적 배포 가능성(Independent Deployability)'이 시스템의 물리적 운영 구조를 어떻게 바꾸는지 기술할 수 있는 가? (P2)

Secondary

• '모듈형 모놀리스'가 왜 신규 프로젝트 환경에서 '마이크로서비스'보다 물리적 관리 비용 면에서 유리할 수 있는지 입증할 수 있는 가?
• Bounded Context를 잘못 설정했을 때 발생하는 '분산된 거대 찰흙덩어리(Distributed Monolith)'의 물리적 폐해를 소통 가능한가?

Industry

• 서비스 마이그레이션 계획 수립 시, 'Strangler Fig' 패턴을 적용하여 데이터 유실 없는 물리적 이행 시나리오를 제안할 수 있는 가? (SFIA)
• 대규모 MSA 환경에서 서비스 간 호출 깊이($Depth$)가 물리적 응답 시간($RTT$)에 미치는 파괴적인 영향을 분석하고 해결책을 제시할 수 있는 가?