모놀리식의 한계와 마이크로서비스 아키텍처(MSA)의 등장 배경

서비스를 처음 만들 때는 대부분 하나의 프로젝트 안에 모든 것을 담습니다. 회원, 주문, 결제, 배송 — 모든 도메인이 하나의 코드베이스에 함께 있고, 하나의 프로세스로 실행되는 구조입니다. 초기에는 이게 오히려 자연스럽고 편합니다. 코드를 한 곳에서 전부 볼 수 있고, 배포도 한 번에 끝납니다.

그런데 서비스가 성장하면서 이 단순함이 조금씩 무거워지기 시작합니다.

"코드 한 줄 고쳤는데 왜 전체를 다시 배포해야 하지?"

오늘은 이 불편함에서 출발해서, 마이크로서비스 아키텍처(MSA)가 왜 등장했는지, 그리고 어떤 문제를 해결하려는 구조인지 살펴보겠습니다.

모놀리식 아키텍처의 한계

모든 도메인이 하나의 애플리케이션 안에 결합되어 있는 구조를 모놀리식(Monolithic) 아키텍처라고 합니다. 같은 메모리, 같은 커넥션 풀, 같은 데이터베이스를 공유하며 단일 프로세스 위에서 동작합니다.

트래픽이 적은 초기 단계에서는 오히려 장점이 많습니다. 구조가 단순해서 개발 속도가 빠르고, 디버깅도 한 곳에서 할 수 있습니다. 하지만 서비스가 커지면서 세 가지 구조적인 문제가 드러납니다.

단일 장애점 (SPOF)

모든 도메인이 같은 프로세스 안에서 동작하기 때문에, 한 곳에 문제가 생기면 전체가 영향을 받습니다. 이벤트 기간에 주문 트래픽이 폭주해서 스레드가 고갈되면, 전혀 관계없는 회원가입이나 상품 조회까지 함께 응답 불가 상태가 됩니다. 장애가 격리되지 않는다는 점이 가장 큰 문제입니다.

스케일 아웃의 비효율

결제 서비스에만 트래픽이 몰리더라도, 결제 부분만 따로 늘릴 수 없습니다. 전체 애플리케이션을 통째로 복제해야 하기 때문에, 사용하지 않는 회원·배송 로직까지 불필요하게 서버 자원을 차지하게 됩니다.

기술 스택의 종속

하나의 언어와 프레임워크에 전체가 묶여 있습니다. 특정 도메인에 더 적합한 기술이 생겨도 부분적으로 도입하는 게 사실상 어렵습니다. 프로젝트 전체에 영향을 미치는 변경이기 때문입니다.

마이크로서비스 아키텍처(MSA)란

이러한 모놀리식의 구조적 한계를 해결하기 위해 등장한 것이 마이크로서비스 아키텍처(MSA, Microservice Architecture)입니다.

MSA는 하나의 큰 애플리케이션을 비즈니스 경계에 따라 독립적으로 배포 가능한 여러 개의 작은 서비스로 분리하는 아키텍처입니다. 각 서비스는 자신만의 데이터베이스를 가지며, 다른 서비스의 DB에 직접 접근하지 않습니다. 서비스 간 통신은 HTTP/REST나 gRPC 같은 API 호출, 혹은 Kafka나 RabbitMQ 같은 메시지 브로커를 통해서만 이루어집니다.

이 구조가 주는 가장 큰 이점은 두 가지입니다.

장애 격리: 결제 서비스에 장애가 생기더라도 주문 조회나 상품 탐색은 정상적으로 동작합니다. 한 서비스의 문제가 전체로 번지지 않습니다.

독립적 스케일링: 트래픽이 몰리는 서비스만 컨테이너 단위로 늘릴 수 있습니다. 필요한 곳에만 자원을 투입할 수 있어 클라우드 인프라를 훨씬 효율적으로 활용할 수 있습니다.

MSA가 가져오는 복잡성

MSA는 확장성과 민첩성을 제공하지만, 동시에 분산 시스템 특유의 복잡성을 떠안게 됩니다. 이 부분을 솔직하게 짚어두는 것이 좋습니다.

단일 프로세스 안에서 일어나던 통신이 네트워크 호출로 바뀌면서 지연 시간(Latency)이 생깁니다. 네트워크가 끊기는 상황에 대비한 재시도(Retry), 타임아웃(Timeout), 서킷브레이커(Circuit Breaker) 같은 처리를 직접 설계해야 합니다.

데이터 정합성 문제도 새롭게 등장합니다. 단일 DB에서는 트랜잭션 하나로 해결되던 작업이, 여러 서비스에 걸쳐 분산되면서 Saga 패턴 같은 고도화된 설계가 필요해집니다.

운영 측면에서도 서비스 수만큼 모니터링, 배포, 로그 수집 파이프라인이 필요해지기 때문에 DevOps 인프라가 충분히 갖춰져 있지 않으면 오히려 유지 비용이 더 커질 수 있습니다.

MSA는 은탄환(Silver Bullet)이 아닙니다. 조직의 DevOps 성숙도가 충분한지, 도메인이 명확하게 분리 가능한 상태인지를 먼저 점검하는 것이 중요합니다.

모놀리식 vs MSA 비교

항목	모놀리식	MSA
배포 단위	전체 애플리케이션	서비스 단위
장애 범위	전체 영향	해당 서비스만
스케일링	전체 복제	서비스 단위
기술 스택	단일 스택 종속	서비스별 독립 선택 가능
초기 개발 속도	빠름	상대적으로 느림
운영 복잡도	낮음	높음

마무리

오늘은 모놀리식 아키텍처의 구조적 한계를 짚어보고, 이를 해결하기 위해 등장한 마이크로서비스 아키텍처(MSA)의 개념과 트레이드오프를 살펴보았습니다. MSA는 장애 격리와 독립적 스케일링이라는 강력한 장점을 제공하지만, 그만큼 분산 시스템의 복잡성도 함께 따라옵니다.

그런데 시스템이 여러 서비스로 나뉘어 독립적으로 실행되는 환경에서는 새로운 문제가 생깁니다. 컨테이너 환경에서는 서비스 인스턴스가 생성되고 사라질 때마다 IP 주소가 동적으로 바뀌는데, A 서비스는 B 서비스의 현재 주소를 어떻게 알 수 있을까요?

다음 시간에는 이 문제를 해결하는 MSA 인프라의 핵심 패턴인 서비스 디스커버리(Service Discovery)에 대해 다루어 보겠습니다.