MSA 아키텍처 구조와 Monolithic Architecture 비교

이전 글에서는 MSA(Micro Service Architecture)의 개념과 함께 Cloud Native, DevOps, Container, Service Discovery와 같은 핵심 개념들을 정리했다.

이번 글에서는 조금 더 구체적으로 들어가서 다음과 같은 내용을 정리해보려고 한다.

  • MSA 시스템의 전체적인 구조
  • 실제 요청이 처리되는 흐름
  • 기존 Monolithic Architecture와의 차이
  • 그리고 MSA가 가지는 단점

특히 Monolithic Architecture와 MSA의 차이는 시스템 설계를 이해하는 데 매우 중요한 부분이기 때문에 최대한 자세히 설명해 보려고 한다.

 

MSA 전체 아키텍처 구조

일반적으로 MSA 기반 시스템은 하나의 애플리케이션으로 구성되지 않는다.
대신 여러 개의 작은 서비스들이 서로 협력하면서 하나의 시스템을 구성하게 된다.

사용자의 요청이 들어오는 흐름을 단순화해서 표현하면 다음과 같은 구조를 가진다.

Client
→ API Gateway
→ Micro Services
→ Database

하지만 실제 MSA 시스템에서는 이보다 훨씬 많은 구성 요소들이 함께 사용된다.

예를 들어 다음과 같은 요소들이 함께 존재한다.

  • API Gateway
  • Service Discovery (Eureka)
  • Load Balancer
  • Container (Docker)
  • CI/CD 시스템
  • DevOps 환경

즉 MSA는 단순히 서비스를 여러 개로 나누는 구조가 아니라, 이러한 다양한 인프라 기술들이 함께 사용되는 하나의 아키텍처 패턴이라고 볼 수 있다.

 

MSA에서 요청이 처리되는 흐름

MSA에서 클라이언트의 요청이 실제 서비스까지 전달되는 과정은 다음과 같은 흐름을 가진다.

Client → API Gateway → Service Discovery → Micro Service

조금 더 구체적인 예를 들어 보자.

사용자가 회원 정보를 조회하는 요청을 보낸다고 가정해 보자.

  1. 사용자가 클라이언트에서 API 요청을 보낸다.
  2. 이 요청은 먼저 API Gateway로 전달된다.
  3. Gateway는 어떤 서비스가 이 요청을 처리해야 하는지 판단한다.
  4. Gateway는 Service Discovery(Eureka) 에 등록된 서비스 목록을 조회한다.
  5. member-service 중 하나를 선택하여 요청을 전달한다.
  6. 해당 서비스가 요청을 처리하고 응답을 반환한다.

여기서 중요한 점은 MSA 환경에서는 동일한 서비스가 여러 개 존재할 수 있다는 것이다.

예를 들어 member-service가 다음과 같이 3개의 인스턴스로 실행되고 있을 수 있다.

member-service-1
member-service-2
member-service-3

이처럼 동일한 서비스가 여러 개 존재할 때, 요청을 어느 서버로 보낼지 결정해 주는 역할을 하는 것이 Load Balancer이다.

Load Balancer는 트래픽이 특정 서버에 몰리지 않도록 적절히 분산시켜 주며, 특정 서버에 장애가 발생했을 경우 정상적으로 동작하는 서버로 요청을 전달하는 역할도 한다.

또한 주기적으로 서버의 상태를 확인하는 Health Check 기능도 수행한다.

 

Monolithic Architecture란?

MSA가 등장하기 전까지 대부분의 시스템은 Monolithic Architecture 구조를 사용했다.

Monolithic Architecture는 말 그대로 하나의 거대한 애플리케이션 구조를 의미한다.

예를 들어 쇼핑몰 서비스를 만든다고 가정해 보자.

이 경우 다음과 같은 기능들이 존재할 것이다.

  • 회원 관리
  • 상품 관리
  • 주문 기능
  • 결제 기능
  • 관리자 기능

Monolithic 구조에서는 이러한 모든 기능들이 하나의 프로젝트 안에 함께 존재한다.

즉 시스템 구조는 대략 다음과 같은 형태가 된다.

Client
→ Web Server
→ Monolithic Application
→ Database

하나의 애플리케이션 안에

  • Controller
  • Service
  • Repository
  • Domain

등의 코드들이 모두 포함되어 있고, 이 애플리케이션 전체가 하나의 서버에서 실행된다.

초기 서비스에서는 이러한 구조가 오히려 매우 효율적이다.

 

Monolithic Architecture의 장점

Monolithic 구조는 생각보다 많은 장점을 가지고 있다.

우선 가장 큰 장점은 구조가 단순하다는 것이다.

모든 기능이 하나의 프로젝트 안에 존재하기 때문에 개발자가 시스템을 이해하기 쉽고, 새로운 기능을 개발하는 속도도 빠르다.

또한 서비스 간 통신이 필요하지 않다는 것도 큰 장점이다.

예를 들어 주문 서비스에서 회원 정보를 조회해야 한다고 가정해 보자.

Monolithic 구조에서는 단순히 다음과 같이 메서드 호출만 하면 된다.

memberService.getMember()

하지만 MSA 환경에서는 같은 작업을 하기 위해서 다음과 같은 과정이 필요하다.

  • HTTP API 호출
  • 네트워크 통신
  • 서비스 디스커버리 조회
  • 응답 처리

즉 Monolithic 구조에서는 내부 메서드 호출로 끝나는 작업이, MSA에서는 네트워크 통신이 되는 것이다.

또한 테스트와 디버깅도 비교적 쉽다.
모든 코드가 하나의 애플리케이션 안에 있기 때문에 로그를 추적하기도 수월하고 문제를 찾기도 쉽다.

 

Monolithic Architecture의 문제점

하지만 시스템 규모가 커질수록 Monolithic 구조는 여러 가지 문제를 발생시키기 시작한다.

가장 먼저 나타나는 문제는 코드 복잡도 증가이다.

서비스가 점점 커지면 하나의 프로젝트 안에

  • 수천 개의 클래스
  • 수십 개의 패키지
  • 매우 복잡한 의존 관계

가 생기게 된다.

이렇게 되면 새로운 개발자가 프로젝트에 참여했을 때 전체 구조를 이해하는 데 상당한 시간이 필요하게 된다.

또한 작은 기능 하나를 수정할 때도 다른 기능에 영향을 줄 가능성이 생긴다.

 

두 번째 문제는 배포 문제이다.

Monolithic 구조에서는 코드의 일부만 수정하더라도 전체 애플리케이션을 다시 빌드하고 배포해야 한다.

예를 들어 단순히 회원 기능의 버그를 수정했다고 해도 다음과 같은 과정이 필요하다.

  • 전체 애플리케이션 빌드
  • 전체 서비스 재배포
  • 서버 재시작

서비스 규모가 커질수록 이 과정은 매우 부담스러워진다.

 

세 번째 문제는 확장성 문제이다.

실제 서비스에서는 특정 기능에만 트래픽이 몰리는 경우가 많다.

예를 들어 쇼핑몰을 생각해 보면

  • 이벤트 기간에는 주문 기능 트래픽이 급증
  • 평소에는 조회 기능이 많음

이처럼 특정 기능만 확장이 필요할 수 있다.

하지만 Monolithic 구조에서는 기능 단위로 확장할 수 없기 때문에 전체 서버를 늘려야 한다.

즉 주문 기능 때문에 서버를 확장했지만
실제로는 상품 조회나 회원 기능까지 모두 확장되는 비효율적인 상황이 발생하게 된다.

 

마지막 문제는 장애 전파 문제이다.

Monolithic 시스템에서는 하나의 기능에서 문제가 발생하면 전체 시스템이 영향을 받을 수 있다.

예를 들어 결제 모듈에서 심각한 오류가 발생한다면

  • 결제 기능만 문제가 생기는 것이 아니라
  • 주문 기능
  • 상품 조회 기능

까지 영향을 받을 수 있다.

결국 하나의 장애가 전체 서비스 장애로 이어질 가능성이 존재한다.

 

Micro Service Architecture

이러한 문제들을 해결하기 위해 등장한 아키텍처가 바로 **MSA(Micro Service Architecture)**이다.

MSA에서는 하나의 애플리케이션을 여러 개의 작은 서비스로 나눈다.

예를 들어 쇼핑몰 시스템을 다음과 같이 나눌 수 있다.

Member Service
Order Service
Payment Service
Product Service

각 서비스는 독립적으로 실행되며 서로 API 통신을 통해 협력한다.

또한 서비스마다 독립적인 데이터베이스를 사용할 수도 있다.

이렇게 서비스를 분리하면 다음과 같은 장점이 생긴다.

특정 서비스만 수정하여 독립적으로 배포할 수 있고, 트래픽이 많은 서비스만 선택적으로 확장할 수도 있다.

또한 하나의 서비스에서 장애가 발생하더라도 전체 시스템이 영향을 받을 가능성이 줄어든다.

 

Monolithic vs MSA 비교

정리해 보면 Monolithic Architecture와 MSA는 여러 측면에서 큰 차이가 존재한다.

먼저 배포 방식이 다르다.

Monolithic에서는 코드 일부만 수정해도 전체 애플리케이션을 다시 배포해야 한다.
반면 MSA에서는 특정 서비스만 수정하여 해당 서비스만 재배포할 수 있다.

두 번째는 확장 방식이다.

Monolithic 구조에서는 특정 기능에 트래픽이 몰려도 전체 서버를 확장해야 한다.
하지만 MSA에서는 필요한 서비스만 확장할 수 있다.

예를 들어 주문 트래픽이 많다면

order-service 서버만 여러 개로 늘릴 수 있다.

세 번째는 장애 격리이다.

Monolithic 시스템에서는 하나의 기능에서 발생한 장애가 전체 서비스에 영향을 줄 수 있다.
하지만 MSA에서는 서비스가 분리되어 있기 때문에 장애가 다른 서비스로 전파될 가능성이 줄어든다.

마지막으로 팀 구조도 달라질 수 있다.

Monolithic 구조에서는 하나의 팀이 전체 시스템을 관리하는 경우가 많다.

반면 MSA에서는 서비스 단위로 팀을 나눌 수 있다.

예를 들어

회원 서비스 팀
주문 서비스 팀
결제 서비스 팀

처럼 각각의 팀이 독립적으로 개발과 배포를 진행할 수 있다.

 

MSA의 단점

MSA가 많은 장점을 가지고 있지만, 항상 좋은 선택은 아니다.

MSA를 도입하면 시스템의 복잡도가 크게 증가한다.

단순한 Monolithic 시스템에서는 필요하지 않았던 다음과 같은 기술들이 필요해진다.

  • API Gateway
  • Service Discovery
  • Load Balancer
  • Container
  • Monitoring
  • CI/CD

또한 서비스 간 통신이 네트워크 기반으로 이루어지기 때문에

  • 네트워크 지연
  • 통신 장애

같은 문제도 발생할 수 있다.

그리고 MSA에서 가장 어려운 문제 중 하나는 데이터 관리이다.

서비스마다 데이터베이스가 분리되는 경우가 많기 때문에
여러 서비스에 걸쳐 있는 트랜잭션을 처리하기가 쉽지 않다.

이 문제를 해결하기 위해

  • Saga Pattern
  • Event Driven Architecture

같은 방식이 사용되기도 한다.

 

정리

MSA는 대규모 서비스를 효율적으로 운영하기 위해 등장한 아키텍처이다.

특히 다음과 같은 상황에서 큰 장점을 가진다.

  • 서비스 규모가 매우 큰 경우
  • 팀 규모가 큰 경우
  • 빠른 배포가 필요한 경우
  • 트래픽 변동이 큰 경우

하지만 작은 프로젝트에서는 오히려 Monolithic 구조가 더 효율적일 수 있다.

따라서 시스템 규모와 팀 구조를 고려하여 적절한 아키텍처를 선택하는 것이 중요하다.

'BackEnd > Spring' 카테고리의 다른 글

ACL 패턴  (0) 2026.04.05
벡터 데이터(Vector Data)와 벡터 데이터베이스(Vector DB)  (0) 2026.03.13
MSA [1편]  (0) 2026.03.13

티스토리툴바