왜 MSA인가?
코드팩토리 MSA의 요소6가지 영상을 보고 정리한 내용입니다 :)
MSA는 왜 등장했을까?
최근 마이크로서비스 아키텍처(MSA, Microservice Architecture)는 대규모 서비스를 운영하는 데 있어 중요한 선택지로 떠오르고 있다.
하지만 MSA는 단순히 서비스의 규모가 커졌기 때문에 등장한 것이 아니다.
그 배경에는 모놀리식 아키텍처의 한계, 서비스 분리 과정에서의 시행착오, 그리고 복잡도를 다루기 위한 기술과 도구의 진화가 있다.
이 글에서는 모놀리식에서 MSA로 넘어오게 된 과정과 그 흐름을 정리해보고자 한다.
1. 모놀리식 아키텍처의 한계
초기의 많은 서비스는 하나의 애플리케이션으로 구성된 모놀리식 아키텍처(monolithic architecture) 를 기반으로 개발되었다.
모놀리식 아키텍처란 모든 기능이 하나의 프로젝트 안에 있는 구조를 말한다. 하나의 프로젝트 안에 회원, 결제, 알림, 어드민 등의 모든 기능이 통합되어 있고, 하나의 데이터베이스를 공유한다.
이 구조는 다음과 같은 장점을 지닌다:
- 개발 및 배포 구조가 단순하다
- 소규모 팀에서는 빠르게 기능을 추가할 수 있다
하지만 서비스가 커지고 팀이 분화되면 다음과 같은 한계에 부딪히게 된다:
- 일부 기능 수정에도 전체 애플리케이션을 다시 배포해야 함
- 도메인 간 의존성이 강해 유지보수가 어려움
- 팀 간 작업 충돌이 발생하고 협업이 비효율적임
2. 서비스 단위 분리의 시작
서비스가 성장함에 따라 도메인을 기준으로 기능을 나누는 시도가 시작되었다.
예를 들어, 회원, 결제, 알림, 어드민 등의 서비스를 분리하여 각각의 책임을 명확히 하려 했다.
하지만 여전히 데이터베이스는 통합되어 있었고, 테이블 간 의존성은 남아 있었다.
그 결과, 다음과 같은 문제가 발생한다:
- 테이블 변경이 여러 서비스에 영향을 줌
- 데이터 정합성을 위한 간접적인 통신 발생
- 코드 분리는 했지만 실제 운영 환경에서는 여전히 커플링 상태
3. 독립적인 서비스로의 전환
진정한 의미의 분리는 각 서비스가 독립적인 데이터베이스와 persistence layer를 가지는 것에서부터 시작된다.
이로 인해 각 서비스는 다음과 같은 특성을 갖게 된다:
- 독립적인 배포 가능
- 장애 전파 최소화
- 책임과 소유권 명확화
하지만 이 구조에서는 서비스 간 통신이 필수가 되고, 이로 인해 새로운 문제가 발생한다.
4. 통신 구조의 변화: 동기 vs 비동기
처음에는 서비스 간 REST API, gRPC 등을 통한 동기 방식 통신이 주로 사용되었다.
하지만 이 방식은 다음과 같은 문제를 낳았다:
- 호출한 서비스가 응답하지 않으면 전체 흐름이 지연되거나 실패함
- 네트워크 지연, 장애 전파 가능성 존재
이를 해결하기 위해 비동기 방식의 통신, 특히 EDA(Event-Driven Architecture)가 도입되기 시작했다.
각 서비스는 이벤트를 발행하고, 필요한 서비스만 이를 구독하는 방식이다.
5. 데이터 정합성과 복잡성 대응
서비스마다 데이터베이스가 분리되면서, 트랜잭션 처리와 데이터 정합성 확보가 어려워졌다.
기존 모놀리식 아키텍처에서는 하나의 프로젝트에 모든 기능이 있기에 하나의 트랜잭션에서 실패가 되더라도 롤백하기 수월하였다.
하지만 서비스와 DB가 분리되고 트랜잭션 안에서의 실패처리 로직을 관리하기 어려워 졌다. 이를 해결하기 위해 아래와 같은 패턴이 등장하게 된다:
- SAGA 패턴: 각 서비스가 로컬 트랜잭션을 처리하고, 실패 시 보상 작업 수행
- CQRS: 명령(Command)과 조회(Query)를 분리하여 처리 성능과 구조의 명확성 확보
6. 서비스 수 증가에 따른 운영 복잡도
마이크로서비스가 많아지면 다음과 같은 운영 문제가 발생한다:
- 클라이언트가 직접 모든 서비스를 호출하기 어려움 → API Gateway
- 한 서비스의 장애가 전체에 영향을 줌 → 서킷 브레이커 패턴
- 수십~수백 개의 서비스를 관리하는 것은 매우 번거로움 → Kubernetes 등 오케스트레이션 도구
마무리하며
MSA는 단순한 유행이나 기술적 유희가 아니다.
모놀리식 구조의 현실적인 한계를 극복하기 위한 진화의 결과물이다.
각 단계마다 문제를 해결하려는 시도들이 있었고, 그 과정에서 수많은 아키텍처 패턴과 운영 도구들이 등장했다.
결과적으로 MSA는 더 높은 유연성과 독립성, 확장성을 제공하지만, 동시에 복잡성과 운영 난이도라는 숙제를 함께 안겨준다.
MSA가 항상 정답은 아니다.
하지만 서비스 규모가 커지고 팀이 분화될수록, 그 필요성은 점점 더 명확해진다.