프로젝트 배경
1) 문제점 - 총판 한 곳이 광고 캠페인을 50~100개씩 관리하는데 등록·승인이 수기로 이뤄져 누락과 지연이 발생 - 단가와 집행 한도를 개별 관리해 한도 초과 집행 위험이 상존 - 캠페인 성과를 확인하려면 매번 데이터를 수집·정리해야 해 운영 부담이 큼 - 총판·운영자·관리자의 권한 구분이 없어 접근 통제가 어려움 - 광고 집행 요청이 초당 약 1,700건 규모로 들어오는데, 초기 구성으로
프로젝트 성과
인프라 비용 62% 절감 (월 130만 원 → 45~50만 원)
Redis 캐싱으로 DB 부하를 걷어내고 SQS로 쓰기를 분산해 RDS 사이즈를 낮췄으며, 서버군 분리로 필요한 쪽에만 스케일링을 적용했습니다.
광고 실행 API 응답 시간 3~5ms 달성
유저 포인트·캠페인·미션 데이터를 ElastiCache에 올려 DB를 거치지 않도록 해, 초당 1,700건 요청을 3~5ms에 응답하게 만들었습니다.
동일 서버 구성에서 처리량 1.4배 향상
캐시·큐 도입과 부하 API 전수 쿼리 인덱스 최적화로 요청당 부하를 낮춰, 서버 증설 없이 같은 구성에서 처리량을 1.4배로 높였습니다.
핵심 기능
진행 단계
요구사항 정의 및 아키텍처 설계
2025.05
캠페인 운영 플로우를 정리하고 관리 서버와 실행 API를 분리하는 구조, 캐시·큐 계층을 포함한 아키텍처를 설계했습니다.
프로젝트 상세
[배경] 광고 총판이 스마트스토어·플레이스 광고를 대행 운영하려면 캠페인 등록·승인, 단가·집행 한도 관리, 성과 집계가 필요합니다. 총판 한 곳이 관리하는 캠페인이 50~100개에 이르는데 이를 수기로 처리하면 누락과 오집행 위험이 커집니다. 여기에 실제 광고 집행 요청은 분당 10만 건, 초당 약 1,700건 규모로 들어옵니다. 관리 업무와 대용량 실행 트래픽을 한 시스템에서 감당해야 하는 프로젝






