MSA(Microservice Architecture)
큰 애플리케이션을 여러 개의 작은 서비스로 나누어, 독립적으로 개발·배포·운영할 수 있게 만드는 아키텍처 스타일
각 서비스는 고유한 기능을 담당하며, 서로 API로 통신하면서 전체 시스템을 구성한다.
주요 장점은 다음과 같다.
- 서비스별 독립 배포
- 필요한 서비스만 선택적 확장
- 장애 발생 시 영향 범위 최소화
- 팀/기능 단위로 분리 개발 가능
1. MSA vs Monolithic 한눈에 비교
1-1. 핵심 개념 비교
| 구분 | Monolithic | MSA |
|---|---|---|
| 구조 | 하나의 큰 애플리케이션 | 여러 개의 독립적인 작은 서비스 |
| 코드베이스 | 단일 코드베이스 | 서비스별 분리된 코드베이스 |
| 통신 방식 | 내부 메서드 호출 | 네트워크 기반 API 호출(HTTP, 메시지 등) |
2. 관점별 상세 비교
2-1. 아키텍처 구조
-
모놀리식
- UI, 비즈니스 로직, 데이터 액세스 로직이 하나의 애플리케이션에 모두 포함
- 하나의 WAR/JAR, 하나의 배포 단위
-
MSA
- 기능별로 잘게 나눈 독립 서비스들로 구성
- 각 서비스는 별도 프로세스, 별도 배포 단위
- 서비스 간 통신은 대부분 HTTP/메시지 기반 API
2-2. 개발 및 배포
-
모놀리식
- 일부 기능만 바꿔도 전체 애플리케이션 빌드/배포
- 작은 변경도 전체 재시작이 필요할 수 있음
- 특정 부분 버그가 전체 서비스에 영향을 줄 가능성 있음
-
MSA
- 수정된 서비스만 개별 배포 가능
- 팀/기능 단위로 독립적인 배포 파이프라인 구성 용이
- 빠른 반복 배포와 실험에 유리
2-3. 기술 스택과 유연성
-
모놀리식
- 주로 단일 기술 스택에 묶이기 쉬움
(예: Spring + JPA + MySQL 하나로 통일) - 새로운 기술 도입 시 전체 시스템에 영향
- 주로 단일 기술 스택에 묶이기 쉬움
-
MSA
-
서비스별로 다른 기술 스택 선택 가능
- 예: 주문 서비스는 Java, 결제 서비스는 Node.js 등
-
특정 기능에 적합한 기술을 선택하기 쉬움
-
2-4. 확장성과 성능
-
모놀리식
-
전체 애플리케이션을 통째로 확장해야 함
- 주문 기능만 트래픽이 많아도 애플리케이션 전체를 scale-out
-
자원 낭비 발생 가능
-
-
MSA
-
트래픽이 많은 서비스만 선택적 확장 가능
- 예: 상품 조회 API 서버만 여러 대 띄우기
-
인프라 자원을 보다 효율적으로 사용 가능
-
2-5. 장애 격리 및 회복성
-
모놀리식
- 하나의 모듈 장애가 전체 프로세스를 죽일 수 있음
- 잘못된 코드/쿼리 하나가 전체 서비스 장애로 이어질 수 있음
-
MSA
-
서비스 단위로 장애 격리 가능
- 예: 결제 서비스 장애 시, 조회 서비스는 정상 동작
-
각 서비스는 독립적으로 회복/재배포 가능
-
2-6. 운영·관리와 모니터링
-
모놀리식
- 프로세스가 하나라서 로그/모니터링 포인트가 단순함
- APM 연동이나 시스템 모니터링 구성이 상대적으로 쉬움
-
MSA
- 서비스 수만큼 로그/트레이싱/모니터링 포인트가 늘어남
- 분산 트레이싱, 중앙 로그 수집, 서비스 헬스 체크 등 운영 인프라가 필수
- 운영 복잡도가 단순히 N배가 아니라 “분산 시스템 수준”으로 올라감
3. “MSA가 항상 정답은 아니다”
작은 팀, 초기 서비스, 단순한 요구사항이라면 모놀리식이 오히려 더 효율적일 수 있다.
3-1. 모놀리식이 유리한 경우
- 서비스 초기 단계, 기능이 많지 않을 때
- 팀 인원이 적고, 역할 분리가 크지 않을 때
- 빠르게 프로토타입/초기 버전을 만들고 검증해야 할 때
- 운영/인프라를 전문적으로 관리할 인력이 부족할 때
장점:
- 프로젝트 구조가 단순하다.
- 배포/운영 플로우가 이해하기 쉽다.
- 코드 레벨 디버깅이 상대적으로 편하다.
- 초기 인프라/운영 비용이 낮다.
3-2. MSA가 유리해지는 시점
- 기능이 계속 추가되면서 코드베이스가 거대해지고 빌드/배포 시간이 과도하게 증가할 때
- 팀이 늘어나고, 도메인별로 완전히 독립적인 개발/배포가 필요할 때
- 일부 도메인만 트래픽이 폭증해 선택적 확장이 반드시 필요한 상황일 때
- 여러 기술 스택을 섞어서 써야 하는 요구가 커질 때
- 장애 격리·고가용성·전 세계 여러 리전에 걸친 배포가 사업적으로 중요한 경우
이럴 때는 아래처럼 접근하는 것이 현실적이다.
- 처음에는 모놀리식으로 시작
- 도메인이 커지고 복잡해지면 경계가 명확한 도메인부터 서비스 분리
- 점진적으로 MSA로 전환 (Strangler 패턴 등)
4. 정리
-
MSA는 확장성·독립 배포·장애 격리 측면에서 큰 장점을 가지지만,
-
그만큼 분산 시스템에 대한 이해, 인프라 구성, 운영 복잡도가 크게 증가한다.
-
따라서,
- 초기/소규모·단순한 서비스 → 모놀리식
- 성장/복잡·대규모 트래픽 → MSA 전환 고려
-
중요한 것은 “요즘 트렌드니까 MSA”가 아니라,
현재 팀 규모·서비스 상태·운영 능력에 맞는 아키텍처를 선택하고, 필요해질 때 점진적으로 나눠 가는 것이다.
개발자 희망자