💬 채용 공고나 기술 블로그를 보면 MSA(Microservices Architecture)가 마치 현대 개발의 표준인 것처럼 느껴질 때가 있다.
반면 Monolithic Architecture는 왠지 낡고 피해야 할 레거시처럼 취급받기도 한다.
과연 MSA는 무조건적인 정답일까?
두 아키텍처의 특징을 명확히 비교해 보고, 현업 개발자로서 우리가 가져야 할 아키텍처 선택의 기준에 대해 정리해 보려고 한다.
1. Monolithic Architecture
모놀리식 아키텍처는 소프트웨어의 모든 구성 요소가 한 프로젝트, 한 패키지 안에 통합되어 있는 형태
특징: 강한 결합과 통합
모든 모듈이 하나의 Application 안에서 강한 결합을 가지며,
데이터베이스 또한 하나의 DB에 모든 도메인(주문, 회원, 결제 등)의 테이블이 모여 있는 것이 특징이다.
마치 거대하고 견고한 성과 같다.
장점
- 단순함: 개발 초기 설정이 쉽고, 배포 파이프라인이 하나라 관리가 편하다.
- 트랜잭션 관리: 모든 로직이 하나의 DB 트랜잭션 안에서 처리되므로, 데이터의 일관성(ACID)을 보장하기가 매우 쉽다.
- 디버깅: IDE 하나에서 전체 흐름을 추적할 수 있어 문제 원인을 찾기 수월하다.
단점
- 높은 결합도: 코드 간 결합도가 높아, 작은 모듈의 에러가 전체 시스템의 장애로 번질 수 있다.
- 빌드/배포의 비효율: 코드 한 줄만 수정해도 애플리케이션 전체를 다시 빌드하고 배포해야 한다.
- 확장성 제약: 특정 기능(예: 주문)에만 트래픽이 몰려도, 전체 서버를 통째로 Scale-out 해야 하므로 자원 효율이 떨어진다.
2. Microservices Architecture (MSA)
애플리케이션을 개별적으로 개발 및 배포가 가능한 작은 서비스 단위 로 나누어 구성하는 방식
특징: 독립성과 연결
MSA는 API Gateway를 통해 연결된 독립적인 서비스들의 집합이다.
마치 여러 건물이 유기적으로 연결된 도시와 같다.
- API Gateway: 클라이언트의 요청을 받아 적절한 서비스로 라우팅하고, 인증/인가 등 공통 로직을 처리하는 단일 진입점 역할을 한다.
- Database-per-Service: 각 서비스는 자신만의 데이터베이스를 가질 수 있다. 이를 통해 서비스 간의 결합도를 낮추고, 각 기능에 최적화된 DB(RDBMS, NoSQL 등)를 선택할 수 있다.
장점
- 장애 격리: 특정 서비스(예: 결제)가 죽어도 다른 서비스(예: 상품 조회)는 정상적으로 동작하여 전체 시스템 셧다운을 방지한다.
- 유연한 확장: 트래픽이 폭주하는 특정 서비스(예: 주문)만 서버를 늘리는 효율적인 Scale-out이 가능하다.
- 기술적 자유: 서비스별로 Java, Python, Node.js 등 가장 적합한 기술을 자유롭게 선택할 수 있다.
단점
- 복잡도의 이동: 비즈니스 로직의 복잡도가 인프라와 운영의 복잡도로 옮겨간다.
- 데이터 정합성: 분산된 데이터베이스 간의 트랜잭션 처리가 매우 까다롭다. (Saga 패턴 등 고난도 기술 필요)
- 네트워크 비용: 서비스 간 통신(HTTP/gRPC)이 필수적이므로 네트워크 지연(Latency)과 오버헤드가 발생한다.
3. 비교
| 특징 | Monolithic | MSA |
| 구조 | 단일 통합 패키지 | 분산된 서비스 집합 |
| 배포 | 전체 배포 (느림) | 서비스별 독립 배포 (빠름) |
| 복잡도 | 낮음 (코드 의존성 관리 필요) | 매우 높음 (네트워크, 운영 복잡도) |
| 트랜잭션 | 쉬움 (DB 트랜잭션) | 어려움 (최종적 일관성 지향) |
| 적합한 조직 | 소규모 팀, 스타트업 초기 | 대규모 팀, 도메인이 명확히 분리된 조직 |
4. 결론
MSA는 분명 강력한 장점을 가지지만, 애플리케이션 내부의 복잡도를 인프라와 운영의 복잡도로 맞교환하는 것이나 다름없다. 무조건적인 MSA 도입은 정답이 아니다.
트래픽이 예측이 가능하고 팀 규모가 작다면 Monolithic이 생산성과 유지보수 측면에서 오히려 최고의 선택으로 보인다. 우리 팀의 상황과 비용을 고려하여 맞는 아키텍처를 가져가는 게 좋아보인다.
초기에는 잘 설계된 Monolithic으로 시작해 기틀을 다지고, 서비스가 성장함에 따라 점진적으로 MSA로 전환하는 전략도 생각해 볼 수 있다.
5. 참고
'아키텍처' 카테고리의 다른 글
| [아키텍처] DDD를 이해하기 (1) | 2025.12.05 |
|---|---|
| [아키텍처] MSA 데이터 일관성 문제, SAGA 패턴으로 해결하기 (0) | 2025.11.23 |