유저 수가 늘어나면서 쇼핑몰 수백 곳의 상품 카탈로그와 수만 건의 리뷰를 동시에 수집하다 보면 반드시 마주치는 거대한 벽이 있다. 바로 웹 요청 타임아웃(HTTP 504 Gateway Timeout)과 서버 메모리 고갈이다.
수만 개의 데이터를 한 번의 웹 요청 안에서 동기식(Sync)으로 전부 긁어오려고 하면 브라우저는 멈추고 서버는 뻗어버린다. 고객에게는 “작업이 접수되었습니다”라는 응답을 0.1초 만에 돌려주고, 실제 무거운 수집·정제 작업은 뒤편의 작업 대기열(Queue)에서 차례대로 쪼개어 처리하는 ‘비동기 백그라운드 큐 시스템’을 구축해야 대규모 트래픽 앞에서도 서버가 터지지 않는다.
오늘은 고가의 전용 서버 없이 서버리스 환경(Redis 기반 메시지 큐)을 활용해, 수만 건의 대규모 동기화 요청을 안정적으로 소화하는 분산 처리 파이프라인을 정리했다.
⏳ 동기식 처리의 한계와 비동기 큐(Job Queue) 전환 흐름
사용자의 화면과 백엔드의 무거운 작업을 물리적으로 분리하는 것이 핵심이다.
Plaintext
[백그라운드 큐 기반 비동기 처리 파이프라인]1. [유저 요청 접수 (0.1초)] - 유저가 "스마트스토어 상품 5,000개 일괄 분석" 버튼 클릭 - 백엔드는 즉시 작업 고유 ID(Job ID)를 발급하고 대기열(Redis Queue)에 집어넣은 뒤 202 Accepted 응답 반환2. [작업 분할 및 대기열 적재 (Chunking)] - 거대한 5,000개 작업을 50개 단위의 작은 100개 마이크로 태스크로 잘게 쪼개어 큐에 분산 적재3. [백그라운드 워커 풀(Worker Pool) 분산 실행] - 대기 중인 여러 대의 독립된 서버리스 워커가 큐에서 태스크를 하나씩 가져와 크롤링 및 LLM 분석 수행 - 특정 쇼핑몰 차단이나 에러 발생 시 해당 50개 조각만 자동 재시도(Retry)4. [작업 완료 및 실시간 상태 알림 (SSE / Webhook)] - 전체 청크 처리가 완료되면 데이터베이스 상태를 '완료'로 변경하고 유저 화면에 실시간 완료 알림 전송
🛡️ 대규모 분산 작업 시 시스템 다운을 막는 3대 안전장치
작업량이 갑자기 폭증해도 전체 시스템이 마비되지 않도록 완충 장치를 걸어야 한다.
- 지수 백오프(Exponential Backoff) 기반 자동 재시도:
- 대상 쇼핑몰에서
429 Too Many Requests차단이 들어오면 워커가 즉시 작업을 포기하지 않고 1초, 2초, 4초, 8초 간격을 점진적으로 늘려가며 최대 3회까지 안전하게 재시도.
- 대상 쇼핑몰에서
- 동시성 제어(Concurrency Rate Limiting):
- 한 번에 수백 개의 워커가 특정 쇼핑몰 사이트를 동시에 긁으면 IP가 영구 차단된다. 도메인별로 초당 동시 실행 워커 수를 엄격히 제한(예: 네이버는 초당 최대 5건, 쿠팡은 초당 최대 3건).
- 데드 레터 큐(Dead Letter Queue, DLQ) 격리:
- 데이터 포맷 오류나 삭제된 상품 링크로 인해 3회 이상 실패한 작업은 무한 루프를 돌지 않도록 별도의 ‘실패 대기열(DLQ)’로 격리하고 원인 로그만 적재.
📊 대기열 진행 상태(Progress)를 유저에게 보여주는 UX 설계
비동기 작업의 단점은 유저가 “내 작업이 지금 잘 돌아가고 있는지” 불안해한다는 점이다. 체감 대기 시간을 줄이는 시각적 피드백이 필수적이다.
- 실시간 퍼센트 진행률 바(Progress Bar):
- 전체 100개 조각 중 45개가 완료되면 화면에
45% 수집 완료 (현재 2,250 / 5,000건)를 실시간 업데이트.
- 전체 100개 조각 중 45개가 완료되면 화면에
- 백그라운드 처리 유예 안내:
- “창을 닫으셔도 작업은 백그라운드에서 계속 진행됩니다. 완료 시 이메일과 슬랙으로 리포트를 보내드릴게요”라는 안내 문구를 노출하여 유저가 브라우저를 켜둔 채 멍하니 기다리지 않게 유도.
💡 백그라운드 큐 운영 시 주의해야 할 점
- 작업의 멱등성(Idempotency) 보장:
- 네트워크 순단으로 인해 동일한 크롤링 작업이 큐에서 두 번 실행되더라도, 데이터베이스에 중복 레코드가 쌓이지 않고 덮어쓰기(Upsert)되도록 설계해야 데이터 정합성이 깨지지 않는다.
- 큐 메모리 누수 방지:
- 완료된 작업 기록이나 성공 로그를 큐 저장소에 무한정 남겨두면 Redis 메모리가 가득 차서 터진다. 완료된 작업은 24시간 뒤 자동 만료(TTL)되도록 설정한다.
- 인사이트 요약: 트래픽이 커져도 무너지지 않는 탄탄한 시스템의 본질은 무거운 연산을 사용자의 시야 밖으로 우아하게 밀어내는 데 있다. 비동기 백그라운드 큐와 정밀한 분산 제어를 구축함으로써, 수만 건의 대규모 데이터 동기화 요청도 지연이나 서버 다운 없이 묵묵히 소화하는 강력한 데이터 파이프라인을 완성했다.
- 차기 분석 테스크: 리스트 059번 “고객 유지와 업셀을 부르는 B2B 이메일 주간 다이제스트(Weekly Digest) 자동 리포팅 시스템” 정리.
🚀 지금 바로 1인 AI SaaS 창업을 시작하세요!
이 글에서 다룬 모든 아키텍처와 운영 전략이 담긴 마스터북 + 풀스택 보일러플레이트 코드를 지금 확인해보세요.
$0에서 $10k MRR까지의 완벽한 로드맵. 7일 내 환불 보증.
댓글 남기기