CQRS 패턴, 읽기와 쓰기 분리로 애플리케이션 성능 극대화하기

CQRS란 무엇인가요? 현장 경험으로 설명드립니다

개발을 하다 보면 가장 자주 마주치는 고민이 하나 있습니다. “왜 우리 시스템은 사용자가 늘어날수록 점점 느려질까요?”

CQRS(Command and Query Responsibility Segregation)는 이런 고민에 대한 명쾌한 답 중 하나입니다. 복잡하게 들리지만, 핵심은 매우 단순합니다. 데이터를 “변경하는 일”과 “읽는 일”을 완전히 분리해서 각각 최적화하자는 것입니다.

마치 음식점에서 주방(요리 만들기)과 홀(서빙하기)을 분리하는 것과 같습니다. 각자의 역할에 집중할 수 있어 전체적인 효율이 크게 향상됩니다.

기존 방식의 근본적인 문제점

대부분의 개발팀이 처음에는 하나의 서비스로 모든 작업을 처리합니다. 이는 초기에는 매우 합리적인 선택입니다. 코드가 간단하고, 이해하기 쉽고, 빠르게 개발할 수 있기 때문입니다.

하지만 현실에서는 예상치 못한 일이 벌어집니다. 실제 서비스를 운영해보면 읽기와 쓰기의 비율이 극도로 불균형합니다. 쇼핑몰의 경우 상품을 보는 사람은 천 명인데, 실제 구매하는 사람은 열 명 정도입니다. 뉴스 사이트라면 더 극단적입니다. 기사를 읽는 사람은 수만 명인데, 기사를 작성하는 기자는 몇 명에 불과합니다.

데이터베이스의 딜레마

데이터베이스 관리자라면 누구나 경험하는 딜레마가 있습니다. 조회를 빠르게 하려면 인덱스를 많이 만들어야 하는데, 인덱스가 많을수록 데이터를 추가하거나 수정할 때 더 오래 걸립니다.

이는 마치 도서관에서 책을 빨리 찾기 위해 분류 체계를 복잡하게 만들수록, 새 책을 정리하는 데 더 많은 시간이 걸리는 것과 같습니다.

복잡성의 악순환

시간이 지나면서 하나의 서비스 안에 점점 더 많은 기능이 들어갑니다. 주문을 생성하는 로직, 주문을 수정하는 로직, 주문 목록을 보여주는 로직, 매출 통계를 계산하는 로직까지… 모든 것이 한 곳에 섞여있게 됩니다.

결국 새로운 기능을 추가하거나 기존 기능을 수정할 때마다 “혹시 다른 기능에 영향을 주지 않을까?”라는 걱정을 하게 됩니다. 이는 개발 속도를 크게 저하시키는 주요 원인이 됩니다.

CQRS가 문제를 해결하는 방법

1. 각자의 역할에 집중

CQRS에서는 명령(Command) 영역과 조회(Query) 영역이 각자의 전문 분야에만 집중합니다.

명령 영역의 특징:

• 비즈니스 규칙 검증에 집중
• 데이터 일관성 보장이 최우선
• 복잡한 계산과 로직 처리
• 처리 결과는 단순함 (성공/실패 여부)

조회 영역의 특징:

• 오직 데이터를 빠르게 가져오는 것에만 집중
• 복잡한 비즈니스 로직 없음
• 사용자 화면에 맞는 형태로 데이터 가공
• 다양한 형태의 리포트와 통계 제공

2. 데이터 구조의 최적화

가장 놀라운 변화는 데이터 저장 방식입니다.

쓰기용 데이터베이스: 정교한 비즈니스 규칙을 지키기 위해 정규화된 구조를 유지합니다. 데이터의 정확성과 일관성이 가장 중요하므로, 필요한 제약조건과 관계를 모두 설정합니다.

읽기용 데이터베이스: 사용자가 보는 화면에 최적화된 구조로 설계합니다. 고객 이름, 상품명, 총 금액 등 화면에서 필요한 모든 정보를 미리 계산해서 하나의 테이블에 저장해둡니다. 마치 미리 만들어둔 요약본을 읽는 것처럼 빠릅니다.

3. 성능 개선의 실제 효과

조회 성능 혁신: 복잡한 JOIN 쿼리가 사라지면서 응답 시간이 극적으로 개선됩니다. 실제 프로젝트에서 500ms 걸리던 주문 상세 조회가 50ms로 단축되는 것을 여러 번 경험했습니다. 이는 단순히 10배 빠른 것이 아니라, 사용자 경험 자체를 바꾸는 수준의 개선입니다.

쓰기 성능 안정화: 읽기를 위한 복잡한 인덱스에서 해방되면서, 데이터 생성과 수정 작업이 안정적이고 예측 가능해집니다. 트래픽이 급증하는 상황에서도 핵심 비즈니스 로직은 영향받지 않고 정상 동작합니다.

확장성의 혁명: 읽기 서버와 쓰기 서버를 독립적으로 관리할 수 있다는 것은 엄청난 장점입니다. 블랙프라이데이처럼 조회 트래픽이 급증하는 상황에서는 읽기 서버만 추가로 띄우면 됩니다. 반대로 대량의 데이터 처리가 필요한 배치 작업 시에는 쓰기 서버의 성능만 강화하면 됩니다.

실무에서 검증된 폴더 구조

src/main/java/com/example/ecommerce/
├── controller/
│   ├── OrderCommandController.java    # 쓰기 API
│   └── OrderQueryController.java      # 읽기 API
├── service/
│   ├── command/
│   │   └── OrderCommandService.java
│   └── query/
│       └── OrderQueryService.java
├── repository/
│   ├── command/
│   │   └── OrderRepository.java
│   └── query/
│       └── OrderQueryRepository.java
├── dto/
│   ├── command/
│   │   └── CreateOrderRequest.java
│   └── query/
│       └── OrderSummaryDto.java
└── event/
    └── OrderCreatedEvent.java

핵심 구현 포인트

// 명령 서비스: 비즈니스 로직에 집중
@Service
public class OrderCommandService {
    public void createOrder(CreateOrderRequest request) {
        // 1. 비즈니스 규칙 검증
        // 2. 데이터 저장
        // 3. 이벤트 발행 (조회 모델 동기화용)
    }
}

// 조회 서비스: 빠른 데이터 제공에 집중
@Service
public class OrderQueryService {
    public OrderSummaryDto getOrderSummary(Long orderId) {
        // JOIN 없는 단순 조회로 최고 성능 달성
        return orderQueryRepository.findSummaryById(orderId);
    }
}

언제 CQRS를 도입해야 할까요?

실무에서의 경험을 바탕으로 말씀드리면, CQRS는 다음과 같은 상황에서 빛을 발합니다:

즉시 적용을 고려해야 하는 경우: 읽기 작업이 쓰기 작업보다 10배 이상 많은 시스템, 복잡한 리포팅과 대시보드가 필요한 시스템, 사용자 수가 급격히 증가하고 있는 시스템입니다.

신중하게 판단해야 하는 경우: 팀 규모가 5명 이하로 작거나, 시스템이 아직 단순한 CRUD 수준이거나, 읽기와 쓰기 비율이 비슷한 시스템에서는 섣불리 도입하지 않는 것이 좋습니다.

마무리: 선택이 아닌 필수가 되는 순간

CQRS는 복잡성을 추가하는 패턴입니다. 하지만 적절한 시점에 도입하면, 그 복잡성을 상쇄하고도 남을 만큼 큰 가치를 제공합니다.

시스템이 성장하면서 성능 문제와 복잡성 문제에 직면하고 있다면, CQRS는 선택이 아닌 필수가 될 수 있습니다. 다만, 팀의 역량과 시스템의 특성을 신중히 고려하여 도입 시점을 결정하시기 바랍니다.

기술은 문제를 해결하는 도구입니다. CQRS라는 도구가 여러분의 문제 해결에 적합한지 충분히 검토해보시고, 필요하다면 과감하게 도전해보시기 바랍니다.