모놀리스→멀티모듈→마이크로서비스 전환 로드맵

왜 ‘3-스텝 전환’이 필요할까?

대다수 스프링 서비스는 처음엔 빠른 개발을 위해 모놀리스로 시작합니다. 하지만 트래픽이 늘고 팀이 커지면 배포 지연·빌드 시간 폭증·의존성 지옥에 갇히죠. 이때 “멀티모듈 → 마이크로서비스” 두 단계를 밟으면 리스크 없이 확장성을 확보할 수 있습니다.

---

Ⅰ. 모놀리스 점검 & 모듈 경계 그리기

1. 도메인·레이어 매듭짓기
   • DDD - 핵심 / 지원 / 인터페이스 레이어로 코드를 재배치
   • 순환 참조 탐지 스크립트로 늦은 빚 차단
2. 코드 헬스 체크리스트
   • 빌드 시간 ≥ 5 분? → 분리 효과가 큼
   • PR 당 충돌 파일 수가 30+? → 멀티모듈 시급

Tip : 이 단계에서 곧바로 마이크로서비스로 뛰어들면 데이터 분리·연쇄 배포 때문에 실패 확률이 급등합니다.

---

Ⅱ. 멀티모듈로 안전하게 쪼개기

1. Gradle 멀티모듈화
   • settings.gradle.kts 에 include("member","order","payment")
   • 루트 subprojects { … } 로 공통 플러그인 통합
2. 공통 코드 추출 → common-util, shared-kernel
3. 테스트 격리 강화
   • java-test-fixtures, Testcontainers, WireMock
4. 모듈별 CI
   • GitHub Actions matrix (job = module)로 병렬 빌드
5. 배포 단위
   • 우선은 단일 WAR/JAR로 묶어 배포 → 운영 안정성 유지

멀티모듈 단계에서 개발-빌드 속도를 끌어올리고, 경계가 흐릿한 코드에 가드레일을 설치합니다.

---

Ⅲ. 마이크로서비스로 단계적 추출

1. 서비스 추출 원칙
   • 변화 빈도 & 독립 스케일링이 높은 도메인부터 (예: 결제, 추천)
   • 데이터 독립성 확보 → 전용 스키마 or DB
2. 인프라 구축
   • API Gateway (Spring Cloud Gateway)
   • 서비스 디스커버리 (Eureka / Consul)
   • 공통 설정 (Spring Cloud Config)
3. 통신 방식
   • Sync → REST + OpenFeign
   • Async → Kafka / RabbitMQ 이벤트 발행
4. 배포 전략
   • Docker → ECR, Helm → EKS/Kubernetes
   • Canary, Blue-Green로 무중단 배포
5. 운영 가시성
   • Distributed Tracing (Zipkin / OpenTelemetry)
   • Grafana + Prometheus 지표 대시보드
6. 조직 & 문화
   • 모듈 = 코드 경계, 마이크로서비스 = 팀 경계
   • “You Build It, You Run It” – 팀이 서비스 전체 라이프사이클 담당

---

전환 타임라인 (실전 평균)

• 0-3 개월 – 도메인 리팩터링 & 멀티모듈 완성
• 4-6 개월 – 첫 핵심 서비스 분리, 공통 인프라 구축
• 6-12 개월 – 점진적 추출 + 레거시 축소, 운영 최적화

---

흔한 함정 3가지

1. 데이터베이스 공유 유지 → 서비스 간 강결합 지속
2. 하나의 CI/CD 파이프라인에 모든 서비스 묶기 → 배포 지연 재현
3. 관찰 가능성 부족 → 장애 원인 추적 난이도 폭증

---

성공 지표

• 배포 빈도 : 주 1회 → 하루 수십 회
• 평균 빌드 시간 : 20 분 → 5 분 이하
• 장애 전파 반경 : 전체 다운 → 단일 서비스 격리