해당 글은 0909 프로젝트 세미까지 과정에 대한 회고글입니다.
1. 프로젝트 개요
0909(공구공구)는 여러 사용자가 함께 구매에 참여하여 목표 인원 달성 시 할인된 가격으로 상품을 구매할 수 있는 공동구매 이커머스 서비스입니다.
본 프로젝트는 Spring Cloud 기반 마이크로서비스 아키텍처(MSA)로 구성되었으며,
서비스 간 결합도를 낮추기 위해 Kafka 중심의 이벤트 기반(Event-Driven) 아키텍처를 적용했습니다.
프로젝트 목표
- 마이크로서비스 환경에서 확장 가능한 구조 설계
- 이벤트 기반 비동기 처리로 서비스 간 느슨한 결합
- 공동구매 특성상 발생할 수 있는 동시성 문제 해결
- 일·월 단위 정산 배치 시스템 구축
2. 프로젝트 정보
- 기간: 2025.12.01 ~ 2025.12.17 (약 2~3주)
- 팀 구성: Backend Developer 5명
- 개발 방식: GitHub PR 기반 코드 리뷰
제가 담당한 역할
- 상품 / 공동구매 도메인 설계 및 구현
- 공동구매 참여 동시성 제어 (Optimistic Lock)
- 일별 / 월별 정산 Batch 설계 및 구현
- 정산 결과 Kafka 이벤트 발행 및 후속 처리 분리
3. 기술 스택
(1) Backend
- Java 17
- Spring Boot 3
- Spring Cloud (Gateway, Eureka, OpenFeign)
- Spring Batch
- Spring Retry
(2) Data & Search
- PostgreSQL 15 (서비스별 스키마 분리)
- Elasticsearch 8.x
(3) Messaging
(4) Security
- JWT (Access / Refresh Token)
- HTTP-only Cookie 기반 인증
(5) Infra & DevOps
- Docker / Docker Compose
- Gradle (멀티 모듈)
- Jib (Docker 이미지 빌드)
4. 아키텍처 설계
(1) 전체 구조
- Gateway → 각 비즈니스 서비스로 라우팅
- 인증/인가 및 사용자 컨텍스트는 Gateway에서 처리
- 비즈니스 서비스 간 상태 변화는 Kafka 이벤트로 전달
REST API는 “즉시 응답이 필요한 경우”에만 사용하고,
검색·알림 등은 이벤트 기반으로 분리
(2) 서비스 구성
Infrastructure
- Gateway Service
- JWT 검증 및 사용자 컨텍스트 헤더 주입
- WebFlux 기반 → 인증/라우팅 책임만 담당
- Discovery Service
Business
- Product Service
- 상품 / 공동구매 관리
- 공동구매 참여 시 동시성 제어
- 상품/공동구매 이벤트 발행
- Order Service
- 주문 생성 및 상태 관리
- 일·월별 정산 Batch 수행
- 정산 완료/실패 이벤트 발행
- Point Service
- Toss Payments 연동 포인트 충전
- 포인트 결제/환불
- 포인트 변경 이벤트 발행
- Notification Service
- Kafka 이벤트 기반 알림 생성
- 주문/포인트/정산 알림 처리
- Search Service
- Kafka 이벤트 기반 Elasticsearch 인덱싱
- 상품/공동구매 실시간 검색
5. 핵심 설계 및 구현 포인트
(1) 공동구매 동시성 제어
문제
- 여러 사용자가 동시에 공동구매에 참여할 경우
- 목표 인원 초과 참여 가능성 발생
해결
- JPA Optimistic Locking 적용
@Version
private Long version;
선택 이유
- 공동구매 참여는 짧은 트랜잭션
- 비관적 락 사용 시 DB 락 경합 우려
- 충돌 시 재시도가 더 적합하다고 판단
결과
- 참여 인원 초과 문제 해결
- 충돌 발생 시 재시도 로직으로 사용자 경험 유지
(2) 정산 Batch + 이벤트 기반 후속 처리
설계 포인트
- 정산 로직과 후속 처리(알림, 상태 변경)를 분리
- Batch 성공/실패 결과를 Kafka 이벤트로 발행
정산 흐름
- Spring Batch로 일·월별 정산 수행
- 정산 결과 이벤트 발행
- settlement.daily.completed
- settlement.daily.failed
- Notification (다른 서비스모듈) 에서 이벤트 소비
효과
- 정산 로직과 알림 로직 분리
- 정산 실패 시 재처리 및 확장 용이
(3) 이벤트 기반 아키텍처 적용 이유
- 서비스 간 동기 호출 증가로 인한 결합도 문제
- 장애 발생 시 전체 흐름 중단 방지 필요
설계 결정
- 메시지 키 = 엔티티 ID
- Consumer Group 기반 확장
- @RetryableTopic으로 소비 실패 재시도
6. 결과 및 성과
(1) 기술적 성과
- Spring Cloud 기반 마이크로서비스 아키텍처 구축
- Kafka 중심 이벤트 기반 시스템 설계
- 공동구매 동시성 문제 해결
- 일·월별 자동 정산 Batch 구축
- Elasticsearch 기반 실시간 검색 구현
(2) 학습 성과
- MSA 환경에서의 데이터 일관성 문제 이해
- 이벤트 기반 시스템의 장단점 체감
- 동시성 제어 전략 비교 및 적용
- Batch + 이벤트 아키텍처 연계 경험
7. 프로젝트를 통해 느낀 점
- 마이크로서비스는 설계 비용이 크지만, 책임 분리가 명확해짐
- 이벤트 기반 구조는 확장성과 장애 격리 측면에서 효과적
- 동시성 문제는 이론보다 실제 구현에서 더 중요
- “왜 이 기술을 선택했는지”를 설명할 수 있어야 설계가 된다
8. 마무리
0909 세미 프로젝트는 17일이라는 제한된 기간 동안 기획부터 개발까지의 과정을 경험한 프로젝트였습니다.
짧은 일정으로 인해 장애 시나리오 기반 테스트와 운영 환경을 가정한 검증을 충분히 진행하지 못한 점은 아쉬움으로 남습니다.
그럼에도 불구하고,
그동안 Spring Batch 기반 정산 처리, DB 락을 활용한 동시성 제어,
Kafka를 활용한 이벤트 처리, OpenFeign을 통한 서비스 간 통신 등을
실제 요구사항에 맞춰 적용하며 기능을 완성하고 설계에 대해 깊이 고민할 수 있었던 의미 있는 경험이었습니다.
이번 프로젝트를 기반으로, 이후에는
- 모니터링(Metrics, Tracing)
- 장애 시나리오 기반 테스트
를 단계적으로 추가하여, 개발 단계에 머무르지 않고 운영 관점까지 고려한 서비스로 확장해보고자 합니다.
프로젝트 관련
Repository:
link: https://0982.vercel.app/