버즈빌

Feature Flag evaluation API의 p95는 ~1ms였지만 p99가 3초 이상으로 튀어 일일 68만 건 호출이 다운스트림 지연을 유발했다.

AI 보조로 엔지니어 코드 생성이 51%, PR 생산량 98% 늘면서 "탐색-발산-수렴" 목업 중심 디자인 프로세스가 병목이 됐다.

100명 규모 버즈빌에서 홈페이지/기술블로그/SDK 문서/디자인 포털이 마케팅·개발·디자인 사이에서 소유권 공백 상태였다.

업계는 AI 가 디자인 시스템을 만들어줄 거라 기대하지만 실제로는 ‘AI 에이전트가 사용할 디자인 시스템’ 자체가 필요했다.

버즈빌의 DynamoDB RCU가 5월 1k에서 10월 130k/s까지 130배 폭증했고, 원인은 3월 배포된 코드가 Limit 없이 파티션 전체를 Strong Consistent로 스캔하던 패턴이었다.

Python 2.7 레거시 서버의 CI-Test 파이프라인이 약 13분 소요돼 긴급 배포 시 병목이 됐다. 실제 테스트는 2분이지만 패키지 설치·빌드 오버헤드가 11분을 차지했다.

AngularJS 기반 두 어드민의 기술 부채, Native SDK의 느린 배포 주기, 파트너사별 맞춤 UI 요구사항이 복잡하게 얽혀 있었다.

월 3.6억 원의 AWS 비용이 매출 대비 과도해 1년간 약 100개 과제를 통한 체계적 절감이 필요했다.

Airflow 데이터 파이프라인 CI 테스트가 7분대 이상 소요되어 개발 효율이 저하됐다.

수십 개 군·구를 좌표 데이터로 선택할 때 ElasticSearch 5의 1MB 패킷 제한을 초과했다. 양천구 하나만 197개 점으로 약 8KB였다.

MLFlow와 Sagemaker를 혼용하고 파이프라인 작성 방식이 통일되지 않아 권한 관리와 재현성이 부재했다.

GitHub-hosted 러너는 내부 네트워크 접근이 어렵고, 빌드 환경 제어와 비용 효율성이 부족했다.

RDS MySQL의 IOPS가 RPS 대비 비정상적으로 높았다. 버퍼풀 히트율이 98%였음에도 디스크 I/O가 지속됐다.

조직 성장으로 데이터 엔지니어에게 파이프라인 요청이 집중되어 인지 부하가 늘고, 각 팀도 데이터 조회를 엔지니어에 의존하는 병목이 생겼다.

광고 예산 제어 시스템이 큰 주기의 이진(on/off) 제어로 동작해 트래픽 급증 시 예산 초과 또는 방송 종료 후 10~15% 불필요한 노출이 발생했다.

광고 예산 제어 시스템이 모노리틱 구조에 묶여 있어 예산 제어 상태 갱신이 캠페인 레코드를 매 분마다 업데이트해 DB 부하를 유발하고, 알고리즘 변경 영향도를 즉시 파악하기 어려웠다.

7개 테이블 Join과 100개 이상 WHERE 조건이 필요한 복잡한 광고 타게팅 쿼리를 MySQL로 처리하면 수평 확장이 어렵고 성능이 떨어진다.

MidJourney·DALL-E 2 등 AI 이미지 생성 기술이 확산되면서 디자인 워크플로우와 광고 크리에이티브 최적화 방식이 근본적으로 바뀔 가능성이 제기된다.

서비스마다 Helm 차트와 Spinnaker 파이프라인을 개별 작성하면 중복 작업이 늘고, 배포 관련 설정 변경이 중앙 팀에 의존하는 병목이 생긴다.

60만 사용자·40만 상품 규모의 이커머스에서 Python으로 구현한 기본 Item-CF 알고리즘이 약 300일의 처리 시간이 필요해 실용적이지 않다.