Update Technology Post "AWS EC2 기반 부하 테스트를 진행하며 시스템 아키텍처 및 성능 개선하기"

Author: devFancy

_posts/2025-12-30-spring-boot-coupon-system-performance-improvement.md

@@ -41,6 +41,51 @@ AWS EC2 기반으로 구축하고 최소 사양부터 시작해서 부하 테스
 
 이러한 기능적 요구사항과 비기능적 요구사항을 모두 충족하는 쿠폰 발급 시스템을 점진적으로 개선해보고자 합니다.
 
+## 소프트웨어 설계
+
+대규모 트래픽을 처리하기에 앞서, 복잡한 비즈니스 로직을 명확히 정의하고 시스템의 확장성을 확보하기 위해 도메인 주도 설계와 멀티 모듈 아키텍처를 적용했습니다.
+
+### 전략적 설계를 통한 비즈니스 경계 설정
+
+협업 시 용어의 혼선을 방지하고 비즈니스 로직의 응집도를 높이기 위해 전략적 설계를 진행했습니다.
+용어 사전을 통해 도메인 내 개념을 일관되게 정의하고, 시스템이 책임지는 논리적 경계인 바운디드 컨텍스트(Bounded Context)를 다음과 같이 정의했습니다.
+(자세한 내용은 [해당 링크](https://github.com/devFancy/springboot-coupon-system/blob/main/docs/coupon-domain-modeling.md)를 참고해 주시면 감사하겠습니다.)
+
+- `Auth`: 로그인 및 토큰 발급을 통한 사용자 식별
+
+- `User`: 회원가입 및 사용자 관리
+
+- `Coupon`: 쿠폰 생성, 수량 및 유효기간 관리
+
+- `IssuedCoupon`: 사용자에게 발급된 쿠폰 관리(중복 방지 및 사용 처리)
+
+![](/assets/img/technology/kudadak/kudadak-coupon-issue-system-ddd-strategy-design.png)
+
+### 역할과 책임을 분리한 멀티 모듈 아키텍처
+
+각 모듈의 역할과 책임을 명확히 분리하기 위해 멀티 모듈 구조를 도입했습니다.
+특히 애플리케이션의 핵심인 비즈니스 로직(Domain)이 기술적인 세부 구현에 오염되지 않도록 설계하는 데 집중했습니다.
+
+도메인 계층에는 순수한 인터페이스만 두고, 실제 데이터베이스에 접근하는 구현체(JPA 등)는 인프라 모듈로 격리했습니다. 
+이를 통해 향후 기술 스택이 변경되더라도 핵심 도메인 로직은 안정적으로 보호될 수 있는 구조로 설계했습니다.
+
+또한 애플리케이션의 핵심인 API 서버와 Consumer 서버가 필요한 공통 로직을 효율적으로 공유하면서도, 독립적인 확장 및 배포가 가능하도록 설계했습니다.
+특히 로깅이나 모니터링처럼 여러 모듈에서 공통으로 필요한 기술적 기능들을 별도의 `support` 모듈로 분리하여 코드 재사용성을 높였습니다.
+
+- `coupon-api`: 쿠폰 발급 요청 접수 및 검증 (Producer 역할)
+
+- `coupon-consumer`: Kafka 메시지 소비 및 데이터 저장 (Consumer 역할)
+
+- `coupon-domain`: 외부 환경에 의존하지 않는 순수한 비즈니스 로직과 엔티티를 포함
+
+- `coupon-infra`: 외부 시스템 연동 및 인프라 설정 (JPA, Redis, Kafka)
+
+- `support-logging`: 서비스 전반의 로그 표준화 및 추적 시스템을 제공
+
+- `support-monitoring`: Prometheus, Grafana, Sentry 등 시스템 가용성을 실시간으로 관측하기 위한 지표 수집 라이브러리를 포함
+
+![](/assets/img/technology/kudadak/kudadak-coupon-issue-system-multi-module.png)
+
 ## 쿠폰 발급 프로세스
 
 초기 프로젝트는 아래 사진과 같이 단일 서버 내의 API 서버와 MySQL 연동만 하는 상황이었습니다.
@@ -556,7 +601,7 @@ Kafka 프로듀서 및 컨슈머의 Config 튜닝을 통해 대량 유입 상황
 
 현재 시스템의 최대 한계는 API 서버의 CPU 자원 고갈임이 확인되었으나, 컨슈머와 DB 서버는 여전히 여유 자원을 보유하고 있어 API 서버 확장 시 선형적인 성능 향상이 가능할 것으로 판단됩니다.
 
-## 향후에 개선 방안
+## 향후 개선 방안
 
 현재 CPU 점유율 100%에 도달한 API 서버를 증설하여 부하를 분산하고, p95 응답 시간을 목표치인 3초 이내로 단축할 계획입니다.