아키텍처 패턴(2) - CQRS, 이벤트 소싱, 서버리스란 무엇인가?

안녕하세요. 좋은 밤입니다. 오늘은 쉬려고 했으나 블로그라도 쓰자라는 생각으로 늦게라도 돌아왔습니다. 그럼 바로 시작하겠습니다.

---

CQRS

CQRS(Command Query Responsbility Segregation)는 명령과 조회의 책임을 분리하는 패턴입니다. 여기서 Command는 데이터를 생성, 수정, 삭제하는 작업을 의미하고, Query는 데이터를 조회하는 작업을 의미합니다.

 

일반적인 CRUD 구조에서는 하나의 모델이나 서비스에서 생성, 수정, 삭제, 조회를 함께 처리하는 경우가 많습니다. 하지만 서비스가 커지면 쓰기 작업과 읽기 작업의 요구사항이 달라질 수 있습니다. 예를 들어 주문 생성은 데이터 정합성이 중요하고, 주문 조회는 빠른 응답 속도와 다양한 조회 조건이 중요할 수 있습니다.

 

CQRS가 필요한 상황

CQRS는 읽기와 쓰기의 요구사항이 크게 다를 때 유용할 수 있습니다.

상황	설명
조회가 매우 많을 때	읽기 전용 모델을 따로 두어 조회 성능을 최적화할 수 있음
쓰기 로직이 복잡할 때	Command 쪽에서 검증과 도메인 규칙을 명확히 관리할 수 있음
조회 화면이 다양할 때	Query 모델을 화면에 맞게 구성할 수 있음
데이터 변경 이력이 중요할 때	이벤트 소싱과 함께 사용할 수 있음

하지만 CQRS는 구조가 단순하지 않습니다. Command와 Query를 분리하면 코드와 데이터 흐름이 늘어나기에 작은 서비스에서는 오히려 복잡도가 커질 수 있습니다.

 

이벤트 소싱이란?

이벤트 소싱은 현재 상태만 저장하는 것이 아닌 상태가 변경된 이력을 이벤트로 저장하는 방식입니다. 즉, 데이터의 최종 상태가 아닌 그 상태가 만들어진 변경 과정을 기록한다고 볼 수 있습니다.

 

예를 들어 장바구니 기능에서는 장바구니 생성, 상품 추가, 상품 제거, 배송 정보 입력과 같은 이벤트를 순서대로 저장할 수 있습니다. 이후 이 이벤트들을 다시 적용하면 현재 장바구니 상태를 재구성할 수 있습니다. 

 

CQRS와 이벤트 소싱의 관계

CQRS와 이벤트 소싱은 서로 다른 개념이지만 함께 사용되는 경우가 많습니다.

CQRS는 읽기와 쓰기 책임을 분리하는 패턴이고, 이벤트 소싱은 상태 변경 이력을 이벤트로 저장하는 방식입니다.

구분	역할
CQRS	Command와 Query 분리
이벤트 소싱	상태 변경 이력을 이벤트로 저장
함께 사용할 때	Command와 이벤트를 저장하고, Query 모델은 이벤트를 기반으로 조회용 데이터를 구성

 

아래 그림은 이벤트 소싱이 CQRS와 함께 사용되는 구조 예시입니다. Command 측에서 발생한 이벤트를 저장하고, 이를 기반으로 조회용 저장소나 외부 시스템을 갱신하는 흐름을 보여줍니다.

https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

 

서버리스

서버리스는 개발자가 직접 서버를 관리하지 않고 클라우드 제공자가 실행 환경을 관리해주는 방식입니다. 서버가 없다는 의미가 아닌 서버의 생성, 확장, 운영을 개발자가 직접 관리하지 않아도 된다는 의미에 가깝습니다.

 

대표적으로 AWS Lambda 같은 서비스를 생각할 수 있습니다. 개발자는 특정 이벤트가 발생했을 때 실행될 함수 코드를 작성하고, 서버 프로비저닝이나 확장 관리는 클라우드 플랫폼에 맡길 수 있습니다.

 

예를 들어 이미지가 업로드되면 썸네일을 생성하고, 결제가 완료되면 알림을 발송하며, 정해진 시간마다 데이터를 정리하는 작업을 실행할 수 있습니다.

 

서버리스의 장점과 한계

서버리스는 짧고 독립적인 작업을 처리할 때 유용합니다. 하지만 모든 백엔드 애플리케이션을 서버리스로 만드는 것이 항상 좋은 선택은 아닙니다. 실시간 연결이 오래 유지되어야 하거나, 복잡한 상태 관리가 필요한 경우에는 전통적인 서버 구조가 더 적합할 수 있습니다.

 

장점

1. 서버 관리 부담 감소
2. 사용한 만큼 비용 지불 가능
3. 트래픽에 따라 자동 확장 가능

단점

1. 콜드 스타트가 발생할 수 있음
2. 클라우드 제공자에 대한 의존성이 생길 수 있음
3. 복잡한 장기 실행 작업에는 적합하지 않을 수 있음 

 

CQRS, 이벤트 소싱, 서버리스 비교

구분	핵심 개념	적합한 상황	주의할 점
CORS	읽기와 쓰기 분리	조회와 변경 요구사항이 크게 다를 때	구조가 복잡해질 수 있음
이벤트 소싱	상태 변경 이력을 이벤트로 저장	이력 추적과 감사 로그가 중요할 때	이벤트 설계와 복구 로직이 어려움
서버리스	서버 관리를 클라우드에 위임	이벤트 기반의 짧은 작업 처리	클라우드 의존성과 콜드 스타트 고려 필요

 

모든 프로젝트에 필요한 구조는 아니다

CQRS, 이벤트 소싱, 서버리스는 모두 유용한 아키텍처 방식이지만 모든 프로젝트에 필요한 것은 아닙니다.

개인 프로젝트나 초기 서비스에서는 일반적인 CRUD 구조와 모놀리식 애플리케이션만으로도 충분한 경우가 많습니다. 오히려 처음부터 복잡한 구조를 도입하면 개발 속도가 느려지고 문제를 해결하기보다 구조 자체를 관리하는 데 더 많은 시간이 들어갈 수 있습니다.

---

이번편을 마무리로 아키텍처 패턴을 마치도록 하겠습니다.

이제 정말 백엔드 로드맵에 해당하는 부분이 얼마 남지 않았네요. 8챕터 정도 남은 것 같습니다. 다음 시간에는 검색 엔진과 함께 돌아오도록 하겠습니다. 수고하셨습니다.