Spring Cloud: 모놀리틱 아키텍처와 MSA 아키텍처

이 글에서 모놀리틱 아키텍처(Monolithic Architecture)와 마이크로 서비스 아키텍처(MSA; Micro Service Architecture)가 무엇이고 어떠한 특징을 가지는지 정리했습니다.

모놀리틱(Monolithic): 모든 것이 한 곳에

모놀리틱 아키텍처(Monolithic Architecture) 는 하나의 코드베이스로 여러 비즈니스 기능을 수행하는 소프트웨어 개발 모델로, 단일 애플리케이션 안에는 웹 레이어, 비즈니스 로직, 데이터 액세스, 배치 작업까지 대부분의 기능이 모두 들어 있습니다.

모놀리틱 아키텍처는 개발·빌드·배포가 하나의 단위로 묶여 있어 새로운 기능을 빠르게 추가하고 MVP를 만들기 좋습니다.

다만 애플리케이션이 커질수록 모듈 간 의존성이 복잡해져 작은 수정에도 전체를 다시 빌드·배포해야 합니다. 또한 특정 기능에만 트래픽이 몰려도 애플리케이션 전체를 스케일 아웃해야 하므로 인프라 비용과 운영 복잡도가 함께 증가합니다.

모놀리틱: 규모가 커질수록 생기는 문제들

• ** 변경의 영향 범위를 예측하기 어렵다.**

  기능 간 결합도가 높아 한 모듈을 수정했을 뿐인데도, 예상치 못한 다른 부분에서 사이드 이펙트가 발생하기 쉽습니다.

• ** 배포 리스크가 크다.**

  하나의 거대한 배포 단위를 사용하기 때문에, 작은 기능 추가·버그 수정에도 전체 애플리케이션을 다시 빌드하고 배포해야 하며, 장애 발생 시 서비스 전체가 영향을 받을 수 있습니다.

• ** 필요한 부분만 골라 확장하기 어렵다.**

  특정 기능이나 도메인에만 트래픽이 몰리더라도 해당 부분만 따로 스케일 아웃할 수 없고, 애플리케이션을 통째로 여러 대 띄워야 해서 인프라 자원이 비효율적으로 쓰이고 비용도 함께 증가합니다.

• ** 팀별로 독립적인 개발·배포가 어렵다.**

  도메인별로 팀을 나누어도 같은 코드를 동시에 수정하게 되고, 팀별로 독립적인 배포 주기를 갖기 어렵습니다.

마이크로 서비스 아키텍처(MSA): 여러 개로 분리

마이크로 서비스 아키텍처(MSA; Micro Service Architecture)는 하나의 거대한 애플리케이션을 도메인 단위로 쪼개 여러 개의 독립적인 서비스로 나누어 개발·배포하는 방식입니다.

각 서비스는 자기만의 코드베이스를 가지고, 상품·주문·결제처럼 기능별로 나뉘어 필요에 따라 각각 따로 배포·확장할 수 있습니다. 덕분에 주문 서비스만 스케일 아웃하거나 결제 서비스만 롤백하는 식의 운영이 가능하지만, 그만큼 서비스 디스커버리·설정 관리·통신·장애 전파·관측 같은 분산 시스템 특유의 복잡도도 함께 늘어납니다.

MSA: 도입했을 때 얻는 이점

• ** 서비스 단위로 독립적인 배포·확장이 가능하다.**

  트래픽이 몰리는 주문·결제 같은 서비스만 스케일 아웃할 수 있고, 장애 발생 시 해당 서비스만 롤백해 전체 장애를 최소화할 수 있습니다.

• ** 서비스마다 도메인에 맞는 기술 스택을 선택하기 쉽다.**

  언어·프레임워크·데이터베이스 등을 서비스별로 다르게 가져갈 수 있어, 장기적으로 기술 부채를 줄이고 새로운 기술을 점진적으로 도입하기에 유리합니다.

• ** 팀별로 독립적인 개발·배포하기 쉽다.**

  서비스 단위로 팀이 나누어 여러 기능을 동시에 개발하기 더 쉽고, 다른 팀의 릴리스 일정에 얽매이지 않고 자기 속도대로 개발하고 배포할 수 있습니다.

MSA: 도입 시, 고려해야 할 비용

• ** 서비스가 늘어날수록 시스템이 복잡해진다.**

  서비스 간 통신, 서비스 디스커버리, 설정 관리, 로드 밸런싱, 장애 전파 제어, 분산 트랜잭션, 관측(로그·모니터링·트레이싱) 같은 분산 시스템 특유의 문제를 직접 다뤄야 합니다.

• ** 서비스 간 네트워크 통신으로 인한 비용·복잡도가 증가한다.**

  모든 통신이 네트워크를 거치기 때문에 모놀리틱에 비해 성능·지연 비용이 증가합니다.

• ** 운영 및 인프라 복잡도가 증가한다.**

  API 게이트웨이·설정 서버·서비스 레지스트리 같은 인프라 구성 요소가 늘어나면서 운영·배포 파이프라인을 설계하고 유지하는 일이 더 복잡해지고, 그만큼 운영·인프라 쪽에서 감수해야 할 부담도 커집니다.

모놀리틱 vs 마이크로 서비스 아키텍처

모놀리틱과 마이크로 서비스 아키텍처 중 어떠한 구조를 사용하는 것이 좋은지는 상황에 따라 다릅니다. 일반적으로는 모놀리틱 구조로 먼저 개발하고, 규모가 커지거나 병목 구간이 생길 때 MSA로의 전환을 고려해보는 것이 좋습니다.

주의할 점

1. MSA로 전환한다고 해서 모놀리틱의 문제가 자동으로 해결되지 않는다

도메인 경계가 명확하지 않은 상태에서 서비스를 나누면, 서비스 간 호출이 빈번해져 오히려 모놀리틱보다 성능과 유지보수가 나빠질 수 있습니다. 먼저 모놀리틱 내부에서 모듈 경계를 명확히 나눈 뒤 전환하는 것이 안전합니다.

2. 처음부터 MSA로 시작하면 초기 개발 속도가 크게 떨어진다

서비스 디스커버리, API Gateway, 분산 트랜잭션, 분산 추적 등 인프라 구축에 상당한 시간이 소요됩니다. 팀 규모가 작거나 도메인이 아직 확정되지 않은 초기 단계에서는 모놀리틱으로 빠르게 MVP를 만들고, 병목이 명확해진 후 점진적으로 분리하는 것이 효율적입니다.

3. 분산 시스템의 디버깅은 모놀리틱보다 훨씬 어렵다

모놀리틱에서는 하나의 로그 파일과 하나의 스택 트레이스로 문제를 추적할 수 있지만, MSA에서는 여러 서비스의 로그를 조합해야 합니다. 분산 추적(Micrometer Tracing), 중앙 로그 수집(ELK) 등의 관측 인프라 없이 MSA를 운영하면 장애 원인 파악에 몇 배의 시간이 걸립니다.