MSA
“큰 애플리케이션을 독립 배포 가능한 작은 서비스로 분해하는 아키텍처.”
MSA란 무엇인가
MSA(Microservice Architecture, 마이크로서비스 아키텍처)는 큰 애플리케이션을 독립적으로 배포 가능한 작은 서비스들로 분해하는 아키텍처다. 각 서비스는 하나의 업무 역량을 책임지고, 자체 데이터와 처리 로직을 갖춘 채 정해진 통신 규약으로 다른 서비스와 협력한다.
모든 기능이 하나의 실행 단위로 묶인 모놀리식 구조와 달리, MSA는 기능 경계를 따라 시스템을 여러 배포 단위로 쪼갠다. 그 결과 한 서비스의 변경이 다른 서비스의 빌드나 배포를 강제하지 않는다.
이 독립성이 MSA가 약속하는 가장 큰 가치다.
왜 쪼개는가
시스템이 커지면 모놀리식 구조는 작은 변경에도 전체를 다시 빌드·배포해야 하고, 한 부분의 장애가 전체로 번질 위험이 커진다. MSA는 서비스를 분리해, 자주 바뀌는 영역과 안정적인 영역을 따로 배포하고 부하가 몰리는 서비스만 선택적으로 확장하도록 돕는다.
또한 서비스별로 팀과 책임을 나누면, 여러 팀이 서로의 코드를 기다리지 않고 병렬로 개발·배포할 수 있다. 다만 이 이점은 시스템이 충분히 크고 변경이 잦을 때 비로소 비용을 상회한다.
작은 시스템을 성급히 쪼개면 얻는 것보다 잃는 것이 많다.
서비스 경계와 데이터
MSA 설계에서 가장 어려운 결정은 서비스를 어디서 나눌 것인가, 즉 경계를 긋는 일이다. 경계는 기술이 아니라 업무 역량을 따라 그어야 하며, 한 서비스가 하나의 일관된 책임을 갖도록 만드는 것이 원칙이다.
각 서비스가 자신의 데이터를 직접 소유하고 다른 서비스의 데이터베이스를 직접 건드리지 않을 때, 비로소 독립 배포가 가능해진다. 데이터를 공유하기 시작하면 서비스들이 한 데이터베이스에 묶여 사실상 다시 하나가 되어 버린다.
경계를 잘못 그으면 서비스 사이 호출이 폭증해 분산된 모놀리식이라는 최악의 상태에 이른다.
| 항목 | 모놀리식 | MSA |
|---|---|---|
| 배포 단위 | 전체 한 번에 | 서비스별 독립 |
| 확장 | 전체 확장 | 필요 서비스만 |
| 데이터 | 공유 DB | 서비스별 소유 |
| 복잡성 | 낮음 | 분산·운영 부담 |
분산이 만드는 복잡성
MSA는 공짜가 아니며, 단일 실행 단위에서는 없던 분산 환경의 복잡성을 대가로 치른다. 서비스 사이 통신은 네트워크를 거치므로 지연과 실패를 늘 가정해야 하고, 여러 서비스에 흩어진 데이터의 일관성을 한 번의 트랜잭션으로 보장하기 어렵다.
한 요청이 여러 서비스를 거치므로 장애가 어디서 시작됐는지 추적하려면 분산 로그와 모니터링 체계가 필수다. 서비스 수가 늘수록 배포·구성·버전 관리의 운영 부담도 함께 커진다.
이 복잡성을 감당할 자동화와 조직 역량 없이 MSA를 택하면 오히려 모놀리식보다 다루기 어려워진다.
DevOps 없이는 성립하지 않는다
MSA의 독립 배포라는 이상은 그것을 떠받치는 자동화 없이는 구호에 그친다. 수많은 서비스를 사람이 손으로 빌드하고 배포하는 것은 불가능에 가까우므로, 빌드·테스트·배포를 자동화하는 DevOps 체계가 전제 조건이 된다.
컨테이너로 실행 환경을 표준화하고, 배포 파이프라인으로 잦은 릴리스를 안전하게 반복하며, 모니터링으로 각 서비스의 상태를 실시간으로 관찰해야 한다. 즉 MSA는 아키텍처 결정인 동시에 조직과 운영 방식의 결정이다.
기술 구조만 쪼개고 일하는 방식과 자동화가 따라오지 않으면 분리의 이점은 운영 부담에 잠식된다.
언제 도입할 것인가
MSA는 모든 시스템의 정답이 아니라, 규모와 변경 빈도가 일정 수준을 넘어선 시스템을 위한 선택지다. 초기 제품이나 요구사항이 빠르게 흔들리는 단계에서는 경계가 자주 바뀌므로, 단순한 구조로 시작해 도메인이 안정된 뒤 점진적으로 분리하는 편이 안전하다.
디자인 패턴을 적용하듯 분해 자체를 목적으로 삼기보다, 어떤 문제를 풀기 위해 쪼개는지를 먼저 분명히 해야 한다. 무엇을 함께 두고 무엇을 떼어 낼지를 판단하는 감각이 곧 아키텍트의 역량이다.
결국 핵심은 쪼개는 기술이 아니라 경계를 옳게 긋는 판단에 있다.
관련 용어