1. 들어가며
최근 백엔드 시스템 아키텍처를 이야기할 때 빠지지 않고 등장하는 키워드가 있다. 바로 MSA(Microservice Architecture)다.
하지만 단순히 "서비스를 나눈다"는 말로는 MSA를 정확히 이해하기 어렵다. MSA는 기술적인 설계인 동시에, 조직 구조와 운영 방식까지 영향을 주는 아키텍처 패러다임이다.
오늘날 많은 기업과 개발팀이 모놀리식 아키텍처에서 마이크로서비스 아키텍처로 전환하고 있지만, 단순히 트렌드라는 이유만으로 선택하기엔 그 변화가 가지는 의미와 복잡도가 꽤 크다. (특히 조금 경험해보니 비용이 만만치않다)
앞선 글들에서는 spring cloud를 정리하면서 MSA에 필요한 기술들을 정리해왔었는데, 이 글에서는 기존의 모놀리식 아키텍처와 비교하며, MSA의 개념, 특징, 장단점 등을 하나씩 짚어보려고 한다.
2. 모놀리식 아키텍처 vs 마이크로서비스 아키텍처
(monolithic architecture vs microservice architecture)
2.1 모놀리식 아키텍처란?
모놀리식(monolithic) 아키텍처는 말 그대로 하나의 커다란 단일 애플리케이션이다.
웹, 서비스, DB 접근, 인증 등 모든 기능이 하나의 통합된 프로젝트 안에서 개발되고 배포되는 구조를 말한다.
장점은 단순한 구조와 빠른 개발 초기 속도에 있다. 프로젝트 구조가 비교적 단순하고 익숙해서 빠르게 개발을 시작할 수 있고, 하나의 JAR 파일만 관리하면 되기 때문에 배포가 쉽다. 또한 전 기능이 한 코드베이스에 있어 디버깅과 추적이 편리하다.
하지만 서비스가 커질수록 여러 가지 문제가 발생한다. 기능이 많아질수록 코드베이스가 비대해져 특정 기능 하나 수정하려 해도 전체 빌드가 필요하고, 사이드 이펙트도 크다. 또한 하나의 기능 변경으로 전체를 재배포해야 하고, 다른 팀의 기능에 영향을 줄 수 있다. 또한 모든 기능이 한 프로세스에 묶여 있어, 개별 서비스 단위로 스케일 업/아웃이 불가능하다.
2.2 마이크로서비스 아키텍처란?
MSA는 하나의 애플리케이션을 독립적인 여러 개의 작은 서비스로 분리해서 구성하는 아키텍처 패턴이다.
각 서비스는 자체적인 비지니스 책임을 가지며, 독립적으로 배포되고, 자체 데이터 저장소를 가질 수도 있다.
이러한 분리는 개발, 테스트, 배포, 운영 등 전반에 걸쳐 유연성과 독립성을 확보할 수 있게 해준다.
분리된 서비스들 끼리는 HTTP/REST, 메시지 큐, gRPC 등을 통해 통신한다.
2.2.1 MSA의 장점
- 독립적인 개발 및 배포 가능
→ 팀 간 간섭 없이 각자의 서비스만 빠르게 개발/배포 가능 - 기능별 유연한 스케일링
→ 트래픽이 몰리는 서비스만 수평 확장하여 자원 효율 증가 - 기술 스택 다양성 허용
→ 서비스별로 언어나 프레임워크를 다르게 선택할 수 있음 (예: Kotlin + Spring, Node.js 등) - 장애 격리
→ 하나의 서비스가 장애가 나도 전체 시스템이 다운되지 않음
2.2.2 MSA의 단점
- 초기 설계 및 인프라 복잡도 증가
→ 서비스 간 통신, 인증, 트레이싱, 로깅 등 공통 기반 시스템 필요 - 운영 및 배포 자동화 필요
→ 수십 개 이상의 서비스가 존재하기 때문에 CI/CD 파이프라인, 모니터링 시스템이 필수 - 트랜잭션 관리 어려움
→ DB가 분리되면서 분산 트랜잭션 처리 또는 eventual consistency 이슈 발생 - 서비스 간 통신 비용
→ 네트워크 지연, 장애 가능성을 고려한 설계 필요
3. MSA로의 전환, 어떤 상황에서 고려해야할까?
모놀리식이 나쁘다는게 아니다. 스타트업, MVP, 초기 제품 단계에서는 오히려 모놀리식이 빠른 결과를 만들기에 적합하다. 하지만 시스템이 커지고, 여러 팀이 동시에 개발해야 하는 상황이 잦아지고, 서비스마다 요구 성능과 배포 주기가 달라지고, 기능별로 장애 영향도를 낮추고 싶어질 때, MSA로의 전환은 자연스러운 선택지가 된다.
실제로 많은 기업은 초기엔 모놀리식으로 시작했다가, 비지니스 확장과 함께 점진적으로 MSA로 전환하는 과정을 겪게된다고 한다.
4. MSA 생태계의 도구들
MSA는 단지 구조의 변화만이 아니라, 서비스 간 통신, 설정 관리, 모니터링, 장애 대응을 위한 기술 스택도 함께 구성되어야 한다.
| 구성 요소 | 도구 예시 |
| 서비스 디스커버리 | Spring Cloud Eureka, Consul |
| 설정 중앙화 | Spring Cloud Config |
| 메시징 브로커 | Kafka, RabbitMQ |
| API Gateway | Spring Cloud Gateway |
| 트레이싱 | Zipkin, Sleuth |
| 모니터링 | Prometheus, Grafana |
| 보안 | Oauth2, JWT, Spring Security |
5. 마무리
모놀리식과 MSA는 정답과 오답의 관계가 아니라, 문제와 상황에 따른 선택지다. 강사님께서 MSA를 가르치실때 자주 하시던 말씀이다.
시스템이 작고, 한 팀이 전부 관리하는 상황에서는 모놀리식이 효율적이고, 시스템이 커지고 팀과 기능이 많아질수록 MSA가 가지는 확장성과 유연성은 분명한 강점이 된다.
단, MSA라는 복잡도라는 대가를 반드시 요구하므로, 아키텍처 전환은 충분한 인프라 준비, 개발 문화, 자동화 체계와 함께 논의되어야 한다. 또한 AWS 환경에서는 그만큼 인스턴스도 늘어나므로 Auto Scaling와 서비스 별 RDS 까지 고려하게 된다면 비용또한 만만치 않다.
경험을 해보며 장점도 확실히 느꼈지만, 아직까지는 대용량 트래픽의 실무 경험이 없다보니 와닿지 않아서인가 단점이 내겐 더 크게 느껴지는 것 같다.
