분산 아키텍처에서 서비스와 이벤트 흐름을 설계하는 법

서비스 경계가 분산 시스템의 출발점이다

단일 모놀리식 구조는 비즈니스 요구사항의 변화와 트래픽 증가에 대응하기 어려워질 수 있다. 분산 아키텍처는 시스템을 독립적인 서비스 단위로 나누고, 각 컴포넌트가 자체적으로 확장·배포·변화할 수 있게 만드는 접근이다.

마이크로서비스, 이벤트 드리븐 아키텍처, CQRS는 이 구조에서 자주 함께 검토되는 패턴이다. 각각 서비스 경계, 서비스 간 통신, 읽기와 쓰기 모델이라는 서로 다른 문제를 다룬다.

도메인을 기준으로 분리하는 마이크로서비스

마이크로서비스는 애플리케이션을 비즈니스 도메인에 맞는 작은 서비스로 나눈다. 서비스는 독립적인 배포 단위로 동작하며, 외부 요청은 API Gateway를 통해 관리할 수 있다. 핵심은 서비스 사이의 느슨한 결합을 지키는 데 있다.

서비스 경계를 정할 때는 Domain-Driven Design(DDD)의 Bounded Context를 기준으로 삼고, 각 서비스가 단일 책임 원칙(Single Responsibility)을 따르게 한다. 데이터는 공유 데이터베이스에 묶기보다 서비스별 독립 저장소로 운영한다.

통신 방식은 요구사항에 따라 나뉜다. REST API와 gRPC는 직접 호출이 필요한 동기 통신에 쓸 수 있고, RabbitMQ나 Kafka 같은 메시지 큐는 비동기 연결에 적합하다. Consul, Eureka는 동적으로 바뀌는 엔드포인트를 찾는 서비스 디스커버리에 활용할 수 있다.

장애 전파도 별도로 다뤄야 한다. Circuit Breaker는 연쇄 장애를 막고, Bulkhead는 리소스를 분리한다. Retry와 Timeout 정책은 일시적인 실패를 처리하는 기준이 된다.

⤢✕

이벤트로 연결되는 서비스 간 처리

이벤트 드리븐 아키텍처에서는 이벤트를 만드는 Producer와 처리하는 Consumer가 비동기로 통신한다. Kafka나 RabbitMQ 같은 이벤트 브로커가 전달 경로를 맡으므로, 생산자와 소비자가 같은 시점에 동작해야 하는 시간적 결합도(Temporal Coupling)를 낮출 수 있다.

이 구조는 시스템 확장성과 유연성을 높이는 데 쓰인다. Publisher는 이벤트를 Topic에 발행하고, Subscriber는 필요한 Topic을 구독한다. 같은 이벤트를 여러 Subscriber가 처리할 수 있으며, Fanout 패턴으로 이벤트를 브로드캐스팅할 수 있다.

Event Sourcing은 상태 변경 자체를 이벤트로 기록하는 방식이다. 현재 상태는 이벤트 스트림을 재생해 복원하며, 감사 추적(Audit Trail)과 이력 관리에 유리하다. Event Store에는 불변(Immutable) 이벤트를 저장하고, Snapshot으로 재생 성능을 최적화한다. 이벤트 버전 관리는 스키마 진화에 대응하기 위한 요소다.

⤢✕

변경과 조회를 분리하는 CQRS

CQRS(Command Query Responsibility Segregation)는 데이터를 바꾸는 명령(Command)과 데이터를 읽는 조회(Query)를 별도 모델로 분리한다. Write Model은 데이터 변경과 비즈니스 로직을 담당하고, Read Model은 조회에 맞춘 비정규화된 뷰를 제공한다. 각 모델에는 목적에 적합한 데이터 저장소를 선택할 수 있다.

Command Side에서는 Aggregate Root가 도메인 로직을 수행하고, Command Handler가 비즈니스 규칙을 검증한다. 도메인 이벤트는 Event Store에 저장하며 트랜잭션 일관성을 보장한다.

Query Side에서는 Read Model Projector가 이벤트를 구독해 조회용 비정규화 데이터를 만든다. Redis, Memcached 같은 캐시를 적용해 조회 성능을 높일 수 있으며, 이 과정에서는 결과적 일관성(Eventual Consistency)을 허용한다.

CQRS와 Event Sourcing을 결합하면 변경 과정에서 생성된 이벤트를 조회 모델 생성에 재사용할 수 있다.

⤢✕

분산 트랜잭션의 일관성을 다루는 방식

분산 환경에서는 하나의 업무 흐름이 여러 서비스와 저장소를 지나갈 수 있다. Saga 패턴은 이때 트랜잭션 흐름과 실패 시 처리를 다룬다.

Choreography 방식에서는 각 서비스가 이벤트를 구독한 뒤 다음 작업을 수행한다. 중앙 조정자가 없으므로 서비스 간 결합도를 낮출 수 있다. Orchestration 방식은 Saga Orchestrator가 흐름을 제어하고, 보상 트랜잭션(Compensating Transaction)을 관리한다. 중앙 집중식 모니터링에도 적합하다.

일관성 모델은 요구사항에 따라 선택한다. 강한 일관성(Strong Consistency)은 분산 락과 2PC(Two-Phase Commit)를 사용한다. 이벤트 기반 동기화에는 결과적 일관성(Eventual Consistency)을 적용할 수 있고, 이벤트 순서 보장이 필요하면 인과 일관성(Causal Consistency)을 고려한다.

패턴이 필요한 조건을 먼저 확인한다

마이크로서비스는 대규모 개발팀이 독립적인 배포 주기를 가져야 하거나, 서비스마다 다른 기술 스택이 필요하고 수평 확장성과 고가용성이 중요한 경우에 적합하다.

이벤트 드리븐 아키텍처는 실시간 데이터 처리와 반응형 시스템이 필요할 때, 비동기 처리로 성능을 높여야 할 때, 시스템 간 느슨한 결합을 유지하려 할 때 검토할 수 있다.

CQRS는 읽기와 쓰기의 부하 양상이 크게 다르고, 복잡한 조회 요구사항에 맞춘 성능 최적화가 필요할 때 유효하다. 감사 추적과 이벤트 기반 분석이 요구되는 환경도 적용 대상이 된다.

운영 체계까지 포함해 설계한다

분산 구조에서는 요청이 여러 서비스를 넘나들기 때문에 Zipkin, Jaeger를 활용한 분산 추적(Distributed Tracing)이 필요하다. 로그는 ELK Stack(Elasticsearch, Logstash, Kibana)으로 집계하고, 메트릭은 Prometheus + Grafana로 수집할 수 있다.

배포에는 Blue-Green Deployment로 무중단 배포를 구성하고, Canary Release로 점진적인 롤아웃을 수행할 수 있다. Feature Toggle은 기능을 제어하는 수단이다.

보안 경계는 API Gateway에서 인증과 인가를 중앙화하는 방식으로 둘 수 있다. 서비스 간 통신에는 mTLS(Mutual TLS)를 적용하고, Secret은 Vault나 AWS Secrets Manager로 관리한다.