문제 상황
한 도메인에 많은 API를 구현하다 보니 Service 클래스의 코드가 지나치게 길어졌다.
기능별로 코드를 찾기 어렵고, 가독성이 크게 떨어졌다.
해결 방안 — CQRS 패턴 적용
CQRS (Command Query Responsibility Segregation) 란, 명령(Command) 과 조회(Query) 의 책임을 분리하는 패턴이다.
적용 내용
ProductService 를 아래 두 클래스로 분리하였다.
| 클래스 | 역할 | 주요 작업 |
|---|---|---|
ProductCommandService | 명령 (Command) | 생성, 수정, 삭제 등 데이터 변경 |
ProductQueryService | 조회 (Query) | 단건/목록 조회 등 데이터 읽기 |
확장 가능성 (고급 적용)
서비스 레이어 분리에서 나아가, DB 모델까지 분리하는 풀(Full) CQRS로 확장할 수도 있다.
- 쓰기 모델 → 데이터 일관성에 집중한 정규화된 DB 설계
- 읽기 모델 → 빠른 조회를 위한 비정규화된 뷰(View) 또는 별도 DB 사용
⚠️ 단, 이 단계는 MSA나 대규모 트래픽 환경에서 주로 적용되며, 현재는 서비스 레이어 분리만 적용하였다. CQRS의 장단점
✅ 장점
- 단일 책임 원칙(SRP) 준수 — 각 서비스가 하나의 역할만 담당
- 유지보수 용이 — 명령/조회 로직이 분리되어 복잡한 비즈니스 로직 관리가 쉬워짐
- 성능 최적화 가능 — 읽기/쓰기를 독립적으로 최적화할 수 있음
- 보안 강화 — 조회와 변경 권한을 별도로 제어 가능
❌ 단점
- 데이터 일관성 문제 — DB를 분리할 경우, 데이터 생성/변경과 조회 사이에 시간차 발생 가능
- 시스템 복잡도 증가 — 클래스 수가 늘어나고, 구조를 처음 접하는 팀원에게 러닝커브 존재
단점이 있음에도 채택한 이유
현재 적용한 방식은 DB 분리 없이 서비스 레이어만 분리하는 경량(Lightweight) CQRS 이다.
따라서 위 단점들이 대부분 상쇄된다.
- 데이터 일관성 문제 → DB를 분리하지 않았으므로 해당 없음
- 복잡도 증가 → 거대한 단일 서비스가 더 복잡했던 상황이므로 오히려 복잡도 감소
- 풀 CQRS는 MSA/대규모 트래픽 환경에 적합하며, 현재 목적(가독성·유지보수 개선)에는 경량 적용이 최적의 선택이었다.
개발공부 처음해보는 사람