인터파크 티켓 클론코딩 프로젝트
목적
인터파크 티켓(NOL 티켓) 스타일의 예매 서비스를 뼈대로 삼아, 백엔드 성능 엔지니어링 학습용 프로젝트이다. 도메인을 완성도 있게 복제하는 것 자체가 목표가 아니라, 동시성 제어 / 실행계획 분석 / 결제 연동 / 소셜 로그인 / Redis 캐싱 / 트랜잭션 관리 / CI/CD / 부하테스트 / 스레드풀 튜닝 / 쿼리 개선을 실전처럼 다뤄보기 위한 그릇으로 도메인을 사용한다.
도메인 스코프
- 콘서트
- 스포츠 (야구, 축구)
- 전시/행사
학습 로드맵
| 주차 | 내용 |
|---|---|
| 1주 | 회원/인증(소셜로그인 포함), 도메인 조회 API(콘서트/야구/축구/전시행사), 기본 CRUD |
| 2주 | 좌석선점 |
| 3주 | 동시성 제어 여러 버전 구현 + 부하테스트 + 스레드풀/커넥션풀 튜닝 |
| 4주 | 쿼리 실행계획 분석/최적화, Redis 캐싱 적용, CI/CD 배포, 라이트 도메인에 엔진 연결 |
- 이메일 회원가입 / 로그인 (JWT 발급, Refresh Token 재발급)
- 소셜 로그인 (카카오 또는 구글)
- 내 정보 조회/수정
- 관리자(ADMIN) 계정 분리 및 권한 체크
- 서브 장르: 발라드, 락/메탈, 랩/힙합, 재즈/소울, 디너쇼, 포크/트로트, 내한공연, 페스티벌, 팬클럽/팬미팅, 인디, 토크/강연
- 목록 조회 (랭킹순 정렬), 상세 조회 (이미지, 일자, 장소, 출연진)
- 좌석 배치도 조회 (구역별 그리드, 좌석 상태 실시간 반영)
- 좌석 선택 → 임시 선점 → 결제 → 확정
- 예매 내역 조회 / 취소
- 팀 목록(10개 구단), 구장 목록
- 팀별 / 구장별 경기 일정 조회
- 좌석: 기본 동일 크기, 일부 구역만 special 좌석으로 가격 차등
- 좌석 선택 → 임시 선점 → 결제 → 확정 (콘서트와 동일 엔진, 가격 정책만 다름)
- 예매 내역 조회 / 취소
- 팀 목록, 경기장 목록
- 팀별 / 경기장별 경기 일정 조회
- 예매: 야구 예매 엔진 재사용
- 지정좌석 없이 기간 내 자유 관람권 형태로 가정
- 목록 조회 (최신순 / 할인율순 / 종료임박순), 상세 조회 (이미지, 전시 기간, 장소)
- 예매: 좌석선점 없이 수량 기반 예약 (인원수 선택 → 결제 → 확정), 결제 모듈만 재사용
- 결제 요청 생성 (PG 연동)
- 결제 승인 콜백/웹훅 처리
- 결제 실패 처리 → 좌석 선점 해제 / 수량 복구
- 결제 취소/환불
- 예매 오픈 시각 도달 시 대기열 진입 (토큰 발급)
- 순번 조회 (polling 또는 SSE)
- 순번 도달 시 예매 페이지 입장 허용
- 비관적 락 (
SELECT ... FOR UPDATE) — 락 대기, 데드락 - 낙관적 락 (
@Version) — 충돌 감지와 재시도 전략 - 분산 락 (Redisson
RLock) — 멀티 인스턴스 환경에서의 정합성 - 대기열 (Redis Sorted Set) — 트래픽 자체를 제한하는 접근
- 동일한 좌석 선점 API에 대해 네 가지 전략을 갈아끼우며 정합성/성능 비교
EXPLAIN ANALYZE로 실행계획 읽는 법 (Seq Scan vs Index Scan vs Bitmap Index Scan, 조인 전략 — Nested Loop/Hash Join/Merge Join)- N+1 문제와 fetch join / QueryDSL 활용
- 다중 조건 동적 쿼리에서 인덱스가 실제로 타는지 실행계획으로 검증
- 슬로우 쿼리 잡고 인덱스 추가 전/후 실행계획 비교
- PG 연동 흐름 (결제창 호출 → 웹훅 수신 → 상태 반영)
- 결제 실패/취소/환불 시 보상 처리 (좌석 선점 롤백, 수량 복구)
- 웹훅 중복 수신에 대한 멱등성 처리
- OAuth2 Authorization Code Flow 직접 구현 (Spring Security OAuth2 Client)
- 소셜 로그인 사용자와 자체 회원 시스템 연동 (최초 로그인 시 회원가입 처리)
- Access/Refresh Token 발급 및 재발급 흐름
- 목록/랭킹 조회 캐싱 전략 및 무효화 타이밍 설계
- 캐시 스탬피드(동시 캐시 만료 시 DB 몰림) 방지 방법
- 캐싱 적용 전/후 응답시간 비교
- 트랜잭션 전파(Propagation), 특히
REQUIRES_NEW로 선점 로그와 결제 트랜잭션 분리 - 트랜잭션 격리 수준과 동시 접근 시 발생 가능한 이상 현상
- AOP 기반 트랜잭션 프록시 동작 원리 (self-invocation 문제 등)
- GitHub Actions 파이프라인 구성
- Blue-Green 배포
- k6 스크립트 작성 (오픈런 시나리오 기반)
- TPS / 에러율 / p99 latency 측정 및 해석
- 동시성 전략별 부하테스트 결과 비교
- Tomcat 스레드 풀 크기 조정과 처리량 변화 관찰
- HikariCP 커넥션 풀 사이즈 조정과 부하테스트 결과 상관관계 분석
- 스레드 풀 vs 커넥션 풀 중 어느 쪽이 먼저 병목이 되는지 실험
