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

마이크로서비스 아키텍처(Microservices Architecture, MSA)는 하나의 애플리케이션을 비즈니스 기능 단위의 작은 서비스 여러 개로 나누고, 각 서비스를 독립적으로 개발, 배포, 확장하는 설계 방식이다. 마이크로서비스 아키텍처에서 각 서비스는 자신만의 데이터 저장소를 가지며 잘 정의된 API로만 서로 통신한다. 대규모 조직이 배포 속도와 확장성을 확보하기 위해 채택하지만, 분산 시스템의 복잡성이라는 비용이 따르므로 도입에는 신중한 판단이 필요하다.

모놀리식에서 마이크로서비스로

모놀리식 아키텍처(Monolithic Architecture)는 전체 애플리케이션이 하나의 배포 단위로 묶인 구조다. 초기에는 개발과 배포가 단순하고 함수 호출만으로 모든 기능에 접근할 수 있어 효율적이다. 문제는 규모가 커지면서 나타난다. 작은 수정에도 전체를 다시 빌드하고 배포해야 하며, 한 모듈의 결함이 전체 프로세스를 죽일 수 있고, 특정 기능만 트래픽이 몰려도 전체를 복제해 확장해야 한다. 수십 개 팀이 하나의 코드베이스와 배포 일정을 공유하면 서로가 서로의 병목이 된다. 한 팀의 배포가 다른 팀의 회귀 테스트를 기다리고, 배포 열차를 놓친 기능은 다음 주기까지 밀리는 식이다. 아마존과 넷플릭스 같은 대규모 서비스 기업들이 이 문제를 해결하는 과정에서 마이크로서비스라는 접근이 정립되었다.

마이크로서비스는 이 결합을 배포 단위 수준에서 끊는다. 주문, 결제, 회원, 상품 같은 비즈니스 능력을 기준으로 서비스를 나누면 각 팀이 자기 서비스를 독립적으로 배포할 수 있고, 트래픽이 몰리는 서비스만 골라 수평 확장할 수 있다. 서비스 경계를 어디에 긋느냐가 성패를 좌우하는데, 보통 도메인 주도 설계(Domain-Driven Design, DDD)의 바운디드 컨텍스트(Bounded Context)를 기준으로 삼는다. 조직 구조가 시스템 구조를 닮아간다는 콘웨이의 법칙(Conway's Law)도 중요한 배경이다. 서비스 단위와 팀 단위를 일치시켜야 아키텍처가 유지된다.

핵심 특징

• 독립 배포: 각 서비스는 자체 파이프라인으로 배포된다. 다른 서비스의 일정에 묶이지 않는다.
• 서비스별 데이터 저장소: 서비스가 자신의 데이터베이스를 소유하고 다른 서비스는 API를 통해서만 접근한다. 저장소를 공유하면 사실상 분산된 모놀리식이 된다.
• 기술 이질성: 서비스마다 적합한 언어와 저장소를 선택할 수 있다. 다만 운영 부담 때문에 실무에서는 표준 스택을 정해 두는 경우가 많다.
• 장애 격리: 한 서비스의 장애가 전체 중단으로 번지지 않도록 설계한다. 이를 위한 방어 패턴이 함께 필요하다.

서비스 간 통신과 데이터 일관성

프로세스 안의 함수 호출이 네트워크 호출로 바뀌는 것이 MSA의 본질적 비용이다. 동기 통신으로는 REST API나 성능이 중요한 내부 통신에 쓰는 gRPC가 있고, 비동기 통신으로는 카프카(Kafka) 같은 메시지 브로커를 통한 이벤트 발행과 구독이 있다. 동기 호출은 직관적이지만 호출 체인이 길어지면 지연과 장애가 전파되고, 비동기 이벤트는 결합도를 낮추지만 흐름 추적이 어려워지고 메시지 중복이나 순서 문제를 다뤄야 한다. 두 방식은 배타적이지 않아서 조회처럼 즉답이 필요한 곳은 동기로, 상태 변경의 후속 처리는 이벤트로 처리하는 혼용이 일반적이다.

데이터베이스가 분리되면 여러 서비스에 걸친 작업을 하나의 트랜잭션으로 묶을 수 없다. 이때 사가 패턴(Saga Pattern)을 사용해 전체 작업을 서비스별 로컬 트랜잭션의 연쇄로 나누고, 중간에 실패하면 이미 수행된 단계를 되돌리는 보상 트랜잭션(Compensating Transaction)을 실행한다. 그 결과 시스템은 항상 즉시 일치하는 대신 최종 일관성(Eventual Consistency)을 가지게 되며, 이를 비즈니스가 수용할 수 있는지가 설계의 관건이다. 장애 전파를 막기 위해서는 실패가 반복되는 호출을 일시 차단하는 서킷 브레이커(Circuit Breaker), 타임아웃과 재시도, 격벽(Bulkhead) 패턴을 적용한다. 클라이언트와 서비스 사이에는 인증과 라우팅을 담당하는 API 게이트웨이(API Gateway)를 두고, 서비스 위치는 서비스 디스커버리(Service Discovery)로 찾는다. 최근에는 이런 통신 관심사를 애플리케이션 밖으로 빼낸 서비스 메시(Service Mesh)도 널리 쓰인다.

운영 관점에서는 관측 가능성이 필수 조건이 된다. 하나의 사용자 요청이 여러 서비스를 거치므로, 요청마다 고유 식별자를 부여해 전체 경로를 추적하는 분산 추적(Distributed Tracing)과 서비스 전체의 로그를 한곳에 모으는 중앙화된 로깅 없이는 장애 원인을 찾기 어렵다. 읽기와 쓰기 모델을 분리하는 CQRS(Command Query Responsibility Segregation)나 상태 대신 이벤트의 기록을 저장하는 이벤트 소싱(Event Sourcing) 같은 패턴도 MSA와 자주 함께 언급되지만, 복잡도가 높아 필요한 곳에만 제한적으로 적용하는 것이 일반적이다.