💡 오늘 학습 키워드
- MSA
- Spring Cloud
🎯 학습 내용 정리
1. MSA
최근 대부분의 대규모 서비스는 MSA를 기반으로 개발되고 있다. Netflix, Amazon, Uber와 같은 글로벌 서비스뿐만 아니라 국내 다양한 IT 기업들도 MSA를 도입하여 서비스를 운영하고 있다. 하지만 MSA를 처음 접하면 "서비스를 여러 개로 나누는 것" 정도로만 이해하는 경우가 많다. 실제로 MSA는 단순히 프로젝트를 분리하는 것이 아니라 서비스의 개발 방식, 배포 방식, 운영 방식까지 모두 바꾸는 아키텍처이다.
MSA는 Microservices Architecture의 약자로 하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발하고 운영하는 소프트웨어 아키텍처 스타일이다.
각 서비스는 하나의 비즈니스 기능만 담당하며 독립적으로 개발, 배포, 확장이 가능하다.
예를 들어 쇼핑몰 서비스라면 하나의 프로젝트에서 모든 기능을 구현하는 것이 아니라 다음과 같이 여러 서비스로 분리할 수 있다.
- User Service
- Product Service
- Order Service
- Payment Service
- Review Service
각 서비스는 자신의 데이터베이스와 비즈니스 로직을 가지며 서로 HTTP, gRPC, 메시지 브로커(Kafka, RabbitMQ) 등을 통해 통신한다.
즉, 하나의 거대한 애플리케이션이 아니라 여러 개의 작은 애플리케이션이 하나의 서비스를 구성하는 방식이라고 이해하면 된다.
왜 MSA가 등장했을까?
초기의 대부분 서비스는 모놀리틱(Monolithic) 아키텍처를 사용했다. 서비스 규모가 작을 때는 하나의 프로젝트에서 모든 기능을 개발하는 것이 가장 단순하고 효율적이었다.
하지만 서비스가 성장하면서 다음과 같은 문제가 발생하기 시작했다.
- 프로젝트 규모가 지나치게 커진다.
- 하나의 기능 수정이 전체 서비스에 영향을 줄 수 있다.
- 작은 수정도 전체 애플리케이션을 다시 배포해야 한다.
- 일부 기능만 확장하고 싶어도 전체 서버를 증설해야 한다.
- 여러 팀이 동시에 개발하기 어려워진다.
이러한 한계를 해결하기 위해 등장한 아키텍처가 MSA이다.
모놀리틱(Monolithic) 아키텍처는 하나의 프로젝트 안에 모든 기능이 포함된 구조이다.
예를 들어 쇼핑몰 서비스라면
- 회원
- 주문
- 상품
- 결제
- 리뷰
기능이 모두 하나의 프로젝트 안에 존재한다.
배포도 하나의 애플리케이션으로 이루어진다.
장점은 다음과 같다.
- 프로젝트 구성이 단순하다.
- 개발 초기 생산성이 높다.
- 배포 과정이 비교적 간단하다.
- 하나의 데이터베이스를 사용하여 데이터 일관성을 유지하기 쉽다.
반면 서비스 규모가 커질수록 단점도 커진다.
- 전체 프로젝트의 복잡도가 증가한다.
- 작은 수정도 전체 배포가 필요하다.
- 특정 기능만 확장하기 어렵다.
- 코드 간 결합도가 높아진다.
- 장애가 전체 시스템으로 확산될 가능성이 높다.
MSA와 모놀리틱은 각각 장단점이 존재한다.
모놀리틱은 작은 프로젝트나 빠른 프로토타입 개발에 적합하다. 반면 MSA는 서비스 규모가 커지고 개발 조직이 커질수록 강력한 장점을 가진다.
| 항목 | 모놀로틱 | MSA |
| 프로젝트 | 하나의 프로젝트 | 여러 개의 서비스 |
| 배포 | 전체 배포 | 서비스별 독립 배포 |
| 확장 | 전체 서버 확장 | 서비스별 확장 |
| 장애 영향 | 전체 서비스 영향 | 해당 서비스만 영향 |
| 기술 선택 | 하나의 기술 스택 | 서비스별 선택 가능 |
| 운영 난이도 | 낮음 | 높음 |
즉, 모놀리틱은 개발이 쉽지만 확장성이 부족하고, MSA는 운영이 복잡하지만 대규모 서비스에 적합하다.
MSA의 장점에 대해서 자세히 알아보자.
1. 독립적인 배포
서비스별로 독립적으로 배포할 수 있다.
예를 들어 주문 서비스만 수정했다면 주문 서비스만 다시 배포하면 된다.
회원 서비스나 상품 서비스는 영향을 받지 않는다.
2. 뛰어난 확장성
트래픽이 주문 서비스에만 집중된다면 주문 서비스 인스턴스만 추가하면 된다.
전체 애플리케이션을 확장할 필요가 없기 때문에 서버 자원을 효율적으로 사용할 수 있다.
3. 기술 스택의 다양성
서비스마다 적절한 기술을 선택할 수 있다.
예를 들어
- 주문 서비스는 Java
- AI 서비스는 Python
- 실시간 채팅은 Node.js
처럼 목적에 맞는 언어와 프레임워크를 사용할 수 있다.
4. 작은 팀 단위 개발
서비스별로 팀을 나누어 독립적으로 개발할 수 있다.
각 팀이 서로 간섭하지 않고 개발과 배포를 진행할 수 있으므로 개발 속도가 향상된다.
MSA는 장점만 있는 아키텍처는 아니다. 오히려 운영 난이도는 모놀리틱보다 훨씬 높다.
대표적인 단점은 다음과 같다.
1. 서비스 간 통신
서비스가 분리되면서 HTTP, FeignClient, Kafka 등을 이용한 통신이 필요하다.
네트워크 장애와 응답 지연도 고려해야 한다.
2. 데이터 일관성 관리
서비스마다 데이터베이스가 분리되는 경우가 많다.
하나의 트랜잭션으로 처리하기 어렵기 때문에 Saga Pattern과 같은 분산 트랜잭션 기법을 고려해야 한다.
3. 운영 비용 증가
서비스마다 로그, 모니터링, 배포, 장애 대응이 필요하다.
서비스 수가 증가할수록 운영해야 할 시스템도 함께 증가한다.
4. 복잡한 인프라
MSA에서는 다음과 같은 다양한 인프라가 필요하다.
- API Gateway
- Service Discovery
- Config Server
- Circuit Breaker
- Distributed Tracing
- Message Broker
이처럼 서비스 외에도 관리해야 할 컴포넌트가 많아진다.
2. Spring Cloud
Spring Cloud는 Spring 기반으로 MSA를 쉽게 구축할 수 있도록 다양한 기능을 제공하는 프레임워크이다.
MSA를 직접 구현하려면 서비스 검색, 로드 밸런싱, 설정 관리, 장애 대응 등을 모두 개발해야 한다. Spring Cloud는 이러한 기능을 이미 제공하므로 개발자는 비즈니스 로직에 집중할 수 있다.
대표적으로 다음과 같은 기능을 제공한다.
- Service Discovery(Eureka)
- API Gateway
- Load Balancer
- Circuit Breaker
- Config Server
- Distributed Tracing
- Messaging
즉, Spring Cloud는 MSA 운영에 필요한 다양한 인프라를 하나의 생태계로 제공하는 프로젝트라고 볼 수 있다.
그렇다면, Spring Cloud가 필요한 이유는 무엇일까?
예를 들어 Order Service가 Product Service를 호출한다고 가정해 보자.
서비스가 여러 대 실행되고 있다면 어떤 서버를 호출해야 하는지 직접 관리해야 한다. 또한 서비스가 종료되거나 새로운 인스턴스가 생성되면 주소도 계속 변경된다.
Spring Cloud는 이러한 문제를 해결하기 위해 다음과 같은 기능을 제공한다.
- 서비스 등록
- 서비스 검색
- 자동 로드 밸런싱
- 장애 대응
개발자는 서비스 이름만 알고 있으면 실제 주소를 몰라도 통신할 수 있다.
MSA를 이야기할 때 가장 많이 등장하는 기업이 Netflix이다.
Netflix는 초기에 모놀리틱 구조를 사용했다.
하지만 사용자 수가 급격하게 증가하면서 다양한 문제가 발생했다.
- 데이터베이스 장애
- 대규모 트래픽 증가
- 잦은 배포 실패
- 시스템 전체 장애
하나의 기능 장애가 전체 서비스 장애로 이어지는 경우도 많았다.
이를 해결하기 위해 Netflix는 MSA로 전환을 시작했다.
Netflix는 단순히 프로젝트를 나눈 것이 아니라 운영 방식 전체를 변경했다.
먼저 거대한 모놀리틱 애플리케이션을 여러 개의 서비스로 분리하였다. 이후 CI/CD 파이프라인을 구축하여 자동 배포 환경을 만들었다. 서비스 간 통신을 위해 Eureka, Ribbon, Hystrix와 같은 다양한 도구를 직접 개발하였다. 또한 AWS 클라우드 환경을 적극 활용하여 수평 확장이 가능한 인프라를 구축하였다.
현재는 수천 개 이상의 마이크로서비스를 운영하며 전 세계 사용자에게 안정적인 서비스를 제공하고 있다.
최근에는 MSA가 많이 사용되고 있지만 많은 사람들이 MSA를 반드시 적용해야 한다고 생각한다. 하지만 모든 프로젝트가 반드시 MSA를 선택해야 하는 것은 아니다.
서비스 규모가 작거나 빠른 개발이 필요한 경우에는 모놀리틱이 더 적합할 수 있다. 실제로 많은 기업은 초기에는 모놀리틱으로 서비스를 개발한 후 서비스 규모가 커질 때 점진적으로 MSA로 전환한다.
중요한 것은 최신 기술을 사용하는 것이 아니라 서비스의 규모와 조직에 맞는 아키텍처를 선택하는 것이다.
📚 한줄 정리
1. MSA는 서비스를 독립적으로 개발·배포·확장하기 위한 아키텍처
2. Spring Cloud는 이러한 MSA를 효율적으로 구축하고 운영할 수 있도록 지원하는 핵심 프레임워크이다.
3. 모든 프로젝트에 반드시 MSA를 적용해야할 필요는 없으며, 규모와 조직에 맞는 아키텍처를 선택하는 것이 중요하다.
'Bootcamp > Fundamentals' 카테고리의 다른 글
| Circuit Breaker와 Resilience4j (0) | 2026.07.02 |
|---|---|
| Service Discovery와 Spring Cloud LoadBalancer (0) | 2026.07.01 |
| MSA 요약 (0) | 2026.06.29 |
| Spring 심화 (0) | 2026.06.26 |
| Spring 숙련 - 2 (0) | 2026.06.25 |