김준형

개요

위탁자 유치 마케팅이 시작되며 접수량이 1.5배 증가, 미처리 재고 4주치 적체로 창고 한계 도달. 프롬프트 설계와 백엔드 파이프라인 구현을 단독 수행

문제

• 처음엔 인력 충원으로 접근했지만 효과가 비례하지 않아 검수 라인을 작업 단위로 분해. 병목은 물량 처리가 아니라 자사 카테고리, 소재, 색상, 스타일을 판별하는 해석 업무였고, 이 업무가 요구하는 암묵지 학습이 신규 인력 온보딩 장기화와 조기 이탈을 만들고 있었음. 문제를 인력 부족이 아닌 ‘해석 업무의 사람 숙련 의존도’로 재정의
• 현재 일 5,000건 처리량 기준으로 1~2년 재확장 없이 운영 가능하려면 최소 일 10,000건은 감당해야 함
• 검수~전시 2시간 SLA: 검수 시작과 완료 알림 간격이 짧을수록 위탁자 반응이 빨라져 전시가 당일 시작된다는 내부 통계 기반의 운영 규칙

해결

• Vision → Text 2단 파이프라인으로 시각 추출과 매핑 판단 분리, 정확도 88%. 키워드 전처리 기반 동적 few-shot으로 90%까지 끌어올림
• fan-out 동시 추론으로 7개 속성 순차 처리 시 상품당 p50 80초가 걸리던 것을 30초로 단축. 속성별 Kafka 토픽 분리도 검토했으나 토픽 수 증가와 Orchestrator 구현 복잡도로 보류
• 병렬 Consumer로 컨슈머 그룹 내부 처리량 확보. Kafka 파티션 증설은 한 번 늘리면 줄일 수 없는 비가역 변경이라, 현재 트래픽 대비 과투자로 판단해 보류
• 추론 실패 토픽 + 3회 재시도 후 DLQ로 처리 흐름 차단 방지. 속성별 추론 상태를 DB에 기록해 부분 실패 시 7개 속성 전체가 아닌 미완료 속성만 재호출, 상품당 최대 6회 LLM 호출 절감
• 주 LLM API 장애 시 Circuit Breaker가 감지하고 Fallback 모델로 호출 전환해 검수 흐름 중단 방지. 모델별 프롬프트로 정확도 편차 5%p 이내 유지

성과

• 1인당 검수 처리량 300개 → 1,500개, 검수 인력 11명 → 3명, 월 1,500만원 운영비 절감. 창고 확장 없이 접수량 2배 수용
• 검수~전시 SLA 달성률 55% → 95%
• LLM API 장애 상황 DLQ 유입률 0.01%

개요

첫 구매 전환 목적 선착순 쿠폰 프로모션을 한정 수량으로 진행

문제

• 동시 요청 시 발급 수 정합성을 보장해야 하나, 카운터 기반 차감은 단일 행 경합으로 동시성 병목
• 예상 동시 접속 200명 규모에서 초과 발급 0건이 요구사항

해결

• SKIP LOCKED 기반 lock-free 병렬 발급으로 lock contention 자체를 제거. 쿠폰 N개를 사전 발행해 두고 동시 요청 시 잠긴 행을 건너뛰며 다음 행에서 발급. 비관적 락이나 분산 락은 어떤 방식이든 락을 점유하므로 경합이 불가피하고, 메시지 큐는 예상 동시 접속 규모 대비 도입과 운영 비용이 과도해 기각
• Redis 매진 상태 캐싱으로 전량 발급 후 DB 도달 요청 자체를 제거. Redis 다운 시에도 DB 상태 컬럼이 정합성 보장

성과

• 첫 구매 전환 700명
• 동시 접속 200명 처리

회고

• 트래픽 증가 시 메시지 큐 기반 비동기 발급으로 다양한 요구사항에 유연하게 대응 가능
• 유저 중복 발급 가능 요구사항 추가 시 DB 제약조건 변경이 필요한 설계는 확장성 측면에서 아쉬움

개요

서비스 성장과 마케팅 캠페인으로 20시 피크 트래픽이 누적되며 상품 조회 API의 DB CPU가 90%까지 상승

문제

• p95 500ms 이상으로 SLO 미달. 매 요청마다 DB를 직접 조회하는 구조가 원인이며, 인덱스는 이미 적용된 상태라 DB 조회량 자체를 줄이는 접근이 필요

해결

• Redis Cache-Aside 분리 캐싱으로 DB 직접 조회 감소. 리스트 캐시는 TTL 5분 stale 허용, 상품 상세 캐시는 상태 변경 시 즉시 eviction. 리스트 miss 시 ID만 조회 후 개별 캐시 확인, miss인 상품만 batch fetch. Local Cache는 다중 서버 환경에서 상품 상태가 빈번히 변경될 때 일관성 보장이 어려워 미채택
• singleflight + TTL jitter로 cache stampede 방어. 프로세스 내 단일 실행으로 stampede 해소에 충분하고 관리 포인트가 적음. 분산 락은 멀티 인스턴스 단일 실행을 보장하나 TTL 관리와 Redis 의존이 부담. TTL jitter로 서로 다른 키가 동시 만료되지 않도록 방지

성과

• 상품 조회 API p95 500ms → 150ms, 피크 시 DB CPU 90% → 45%

개요

신규 가입자 확보 목표 하에 PLP 응답 속도 개선이 가입자 상품 상세 조회 CTR 상승으로 이어질 것이라는 가설을 바탕으로 조회 성능 개선 추진

문제

• PLP p99 10초로 상품 상세 진입 자체가 지연
• EXPLAIN ANALYZE 결과 인덱스가 이미 적용된 상태에서 좋아요 수를 매 요청마다 JOIN + COUNT로 집계하는 구조가 원인

해결

• 실시간 집계 테이블로 JOIN + COUNT 제거, 좋아요/취소 시 즉시 INCREMENT/DECREMENT. 조회 캐싱은 무거운 집계 반복 자체가 해소되지 않고, 배치 집계는 반영 지연과 규모 확대 시 복잡도 증가로 미채택

성과

• 상품 리스트 조회 API p99 10초 → 500ms
• 가입자 상품 상세 조회 CTR을 10%에서 22%로 향상

회고

• 좋아요/취소마다 DB 쓰기 발생 — 규모 확대 시 메시지 큐로 이벤트 적재 후 배치 처리하여 쓰기 부하 감소 가능