SSG.COM

SSG.COM 의 장보기 지원금 소멸 알림 배치가 수십만 건을 병렬 발송하다 간헐적으로 "Connection is not available, request timed out"으로 실패한 문제를, Spring Batch 의 DB 커넥션 점유 구조를 손봐 해결한 사례를 다룬다. 발송 API 가 느린 게 아니라, 발송 응답을 기다리는 동안 DB 커넥션을 계속 붙잡는 chunk 구조가 진짜 원인이었다.

SSG.COM 검색은 노출 30%·클릭 35%를 책임지지만 기존 오타보정은 재검색 로그 기반이라 커버리지가 낮고 사후 대응에 머물렀다.

SSG.COM의 MSA 환경에서 노출 누락·데이터 이상 문의가 들어올 때마다 DB, 로그, 소스를 수동으로 오가야 해 운영 대응이 비효율적이었다.

표 형식 데이터 분석은 오랫동안 XGBoost·LightGBM 같은 모델에 의존해 왔는데, 데이터가 적거나 튜닝 시간이 길고 데이터셋마다 새로 학습해야 하는 부담이 있었다.

SSG7CLUB 가입 배포 직후 동일 입력이 때로는 성공·때로는 실패하는 랜덤 오류가 발생했고, 단일 WAS인 테스트 환경에서는 재현되지 않았다.

SSG.COM이 30여 개 제휴 채널 상품을 FCFS 방식으로 연동하다 보니 행사 상품이나 BEST 상품이 단순 수정 시각 기준으로 밀려, 일 수십 건의 지연 문의가 발생했다.

신규 매장이나 서비스마다 페이지 구성요소를 새로 만들면 개발·운영 비용이 급증하고, 기획자와 개발자 사이의 소통도 점점 어려워졌다.

2025년 상반기 특정 센터에서 품절이 급증했다. 기존 ML 모델(XGBoost, LGBM)이 할인행사 시 출하량 급증에 즉각 반응하지 못했다.

Confluence 내부 위키의 키워드 기반 검색이 용어 차이로 연관 문서를 누락해 업무 효율이 저하됨.