MSA vs 모놀리식 — 아키텍처 선택의 기준과 트레이드오프

새 프로젝트를 시작할 때 "마이크로서비스로 가야 하나, 모놀리식으로 가야 하나" 고민해본 적 있으신가요?

아키텍처 선택은 프로젝트의 성패를 좌우하는 결정입니다. 그런데 최근 업계 흐름을 보면, 한때 "무조건 MSA"라던 분위기가 많이 달라졌습니다. 이번 글에서 두 아키텍처의 핵심 차이와 현실적인 선택 기준을 정리해보겠습니다.

모놀리식 아키텍처란

하나의 코드베이스, 하나의 배포 단위로 전체 애플리케이션을 운영하는 방식입니다.

• 모든 기능이 하나의 프로세스에서 실행
• 공유 데이터베이스 사용
• 내부 함수 호출로 모듈 간 통신

장점:

• 개발/디버깅이 단순 — IDE 하나로 전체 흐름 추적 가능
• 배포가 간단 — JAR 하나 빌드해서 올리면 끝
• 트랜잭션 관리가 쉬움 — @Transactional 하나로 해결
• 인프라 비용이 낮음

** 단점:**

• 코드베이스가 커지면 빌드/배포 시간 증가
• 한 모듈의 장애가 전체에 영향
• 팀이 커지면 코드 충돌과 배포 대기 발생
• 기술 스택 변경이 어려움

마이크로서비스 아키텍처(MSA)란

기능별로 독립된 서비스를 나누어, 각각 독립적으로 개발/배포/확장하는 방식입니다.

• 서비스별 독립 프로세스 + 독립 데이터베이스
• 서비스 간 통신은 REST, gRPC, 메시지 큐 등 네트워크 호출
• 각 서비스를 독립적으로 스케일링 가능

** 장점:**

• 독립 배포 — 주문 서비스만 수정해서 바로 배포
• 장애 격리 — 결제 서비스 장애가 상품 조회에 영향 없음
• 기술 이종성 — 서비스별로 다른 언어/DB 사용 가능
• 팀 자율성 — 각 팀이 자기 서비스를 독립적으로 운영

** 단점:**

• 분산 시스템 고유의 복잡성 (네트워크 지연, 부분 장애)
• 분산 트랜잭션 처리가 어려움 (Saga 패턴 등 필요)
• 서비스 간 디버깅이 까다로움 (분산 추적 필수)
• 인프라/운영 비용 대폭 증가

MSA 회귀 현상 — 왜 다시 모놀리식으로?

공부하다 보니 최근 업계에서 흥미로운 움직임이 있었습니다. 2025 CNCF 서베이에 따르면 ** 마이크로서비스 도입 기업의 약 42%가 다시 통합 방향으로 움직이고 있습니다.**

Amazon Prime Video 사례

Amazon Prime Video 팀은 비디오 모니터링 서비스를 마이크로서비스에서 모놀리식으로 전환했습니다.

• 기존: Step Functions + Lambda 기반 분산 아키텍처
• 문제: 서비스 간 데이터 전달 비용이 폭발적으로 증가
• 결과: ** 인프라 비용 90% 절감**

핵심은 "모놀리식이 좋아서"가 아니라, ** 분산이 불필요한 곳에 분산을 적용한 것이 문제 **였다는 점입니다.

Twilio Segment 사례

Twilio Segment는 140개 이상의 마이크로서비스를 하나의 모놀리식으로 통합했습니다.

• 3명의 엔지니어가 대부분의 시간을 서비스 간 장애 대응에 소비
• 통합 후 개발 생산성이 극적으로 향상

비용 현실

마이크로서비스는 생각보다 비쌉니다:

• 인프라 비용: 모놀리식 대비 3.75x ~ 6x
• 플랫폼 엔지니어링 인건비: 연간 $140K ~ $360K 추가
• 서비스 메시, 모니터링, CI/CD 파이프라인 등 부대 비용

작은 팀이 MSA를 도입하면 "서비스 개발"보다 "인프라 운영"에 더 많은 시간을 쓰게 됩니다.

모듈러 모놀리식 — 두 세계의 장점을 취하다

2025-2026년 업계 컨센서스는 ** 모듈러 모놀리식 코어 + 필요한 2~5개 서비스만 추출하는 전략 **입니다.

모듈러 모놀리식은 단일 배포 단위를 유지하면서, 내부적으로 모듈 간 경계를 명확히 나누는 방식입니다.

// 모놀리식: 경계 없는 패키지 구조
com.example.app.service
com.example.app.repository
com.example.app.controller

// 모듈러 모놀리식: 도메인 단위로 분리
com.example.order       // 주문 모듈
com.example.payment     // 결제 모듈
com.example.product     // 상품 모듈

Spring Modulith

Spring 공식 프로젝트인 Spring Modulith는 모듈러 모놀리식을 코드 레벨에서 지원합니다.

// 모듈 간 의존성 검증 테스트
@Test
void verifyModuleStructure() {
    ApplicationModules modules = ApplicationModules.of(Application.class);
    modules.verify(); // 순환 의존성, 잘못된 접근 등을 검증
}

주요 기능:

• ** 모듈 경계 검증** — 모듈 간 불법적인 의존을 테스트 시점에 감지
• ** 이벤트 기반 통신** — 모듈 간 직접 호출 대신 이벤트로 느슨한 결합 유지
• ** 문서 자동 생성** — 모듈 구조를 자동으로 문서화

나중에 특정 모듈을 마이크로서비스로 추출해야 할 때, 이미 경계가 명확하니 전환 비용이 크게 줄어듭니다.

아키텍처 선택 기준

실무 전략: 모놀리식으로 시작하고 필요할 때 추출

1단계: 모듈러 모놀리식으로 시작
  ↓ (트래픽 증가, 팀 확대)
2단계: 병목이 되는 모듈만 서비스로 추출
  ↓ (필요한 경우에만)
3단계: 핵심 2~5개 서비스 + 모놀리식 코어

이 전략이 효과적인 이유:

• 초기에 불필요한 복잡성을 피할 수 있음
• 실제 병목 지점을 데이터 기반으로 파악한 뒤 분리
• 모듈 경계가 이미 있으니 추출 비용이 낮음

"MSA는 목표가 아니라 도구입니다. 문제가 없는데 MSA를 도입하면, MSA 자체가 문제가 됩니다."

정리

• 모놀리식은 단순함과 낮은 비용이 장점, MSA는 독립 배포와 확장성이 장점
• 최근 업계는 무분별한 MSA에서 모듈러 모놀리식으로 회귀하는 추세
• ** 모놀리식으로 시작 → 모듈 경계 유지 → 필요할 때 추출 **이 가장 현실적인 전략
• Spring Modulith로 모듈러 모놀리식을 체계적으로 구성할 수 있음
• 아키텍처 선택은 팀 규모, 도메인 복잡도, 트래픽 패턴을 기준으로 판단