글로벌 이상 징후 탐색 자동화

문제

글로벌 마케팅, MD, 사업부 담당자에게는 범용 셀프 분석(BI) 도구만 있었고, 어떤 신호를 모아 어떤 행동으로 이을지 정한 구조가 없어 데이터 해석을 각자 떠안았습니다.

일본 고객군에서는 재구매까지 가는 속도가 느려지거나 신규 가입자의 첫 구매가 이상하게 떨어져도, 한 달이 지난 뒤에야 알 수 있었습니다.

그래서 문제를 “브랜드, 상품, 고객군에서 지표가 튄 곳(신호)을 찾아, 다음에 할 일(행동)까지 이어 주는 것”으로 정했습니다.

접근

• 먼저 2026년 4월 29일, 이상 진단 대시보드의 PRD, ADR, HLD, LLD를 하루에 써서 PoC를 끝냈습니다.
• 브랜드와 상품의 클릭률(CTR)과 구매 전환율(CVR) 신호를 잡는 파이프라인은 HLD 2개, LLD 3개, ADR 4개로 설계했습니다. 재고 정보는 1시간 단위 배치로 붙이고, 급등·급락을 가르는 임계값은 관리 API로 다루며, 캐시 값은 응답할 때 한 번에 묶어 읽게 했습니다.
• 신호를 어떻게 전할지는 서로 다른 방향의 5개 안을 영향과 노력을 7 대 3으로 가중한 결정표로 비교했습니다. 이유, 데이터, 할 일, 담당, 기한을 한 장에 담는 결정 카드가 1위였고, LLM 자동 요약은 함께 시험할 안으로 골랐습니다.
• 첫 단계 범위는 요구사항 후보 12개를 영향·노력 2×2 표에 나눴는데, 영향이 크고 노력이 작은 칸이 비어 있어 하나씩 내는 대신 서로 이어진 지표 5개(신규 고객 재구매 곡선, 카테고리별 90일 재구매율, 이상 신호 목록, 가입 후 7일 활성화 하락, 두 번째 구매 지연)를 한 번에 내기로 했고, 이 지표들은 뷰 3개와 이벤트 테이블 1개에 담았습니다. 나머지 7개는 2개를 다른 항목에 흡수하고, 3개는 기존 BI 도구에 맡기고, 2개는 미뤘습니다.
• 목표 전체 가운데 첫 단계에서 뺄 것 5가지(시간 단위 탐지, 티켓 자동 생성, 피드백 루프 등)를 기능 요약서에 따로 적었습니다.
• Prophet은 라이브러리 코드를 직접 읽어 적용할 수 있는지 판단한 뒤 도입했습니다.

결정

• 대시보드: 브랜드와 상품의 CTR·CVR이 급등하거나 급락한 곳과 고객군 지표의 이상 신호를 대시보드에서 보고, 신호별로 깊이 들어가 볼 수 있게 했습니다.
• 알림 시스템: 일본 고객군은 재구매 추세, 첫 구매에서 두 번째 구매까지 걸린 날짜, 가입 후 7일 활성화를 뷰 3개로 만들고, Prophet이 1년 주기 계절성을 분해해 이상을 판정합니다. 수치와 원인 후보는 급등·급락을 가르는 임계값 같은 휴리스틱 규칙으로 코드가 계산하고, LLM은 그 결과를 받아 원인 가설과 다음 할 일을 문장으로만 씁니다. 새로 저장하는 것은 이벤트 테이블 1개로 제한했습니다.
• 액션 아이템: 원인 가설과 다음 할 일을 담은 Slack 카드를 보내되, 국가와 고객군마다 주 1건까지만 보내 알림 피로를 막았습니다.

결과

• 설계를 실제 데이터와 대조해 데이터 계약 8개 중 7개의 오류를 배포 전에 고쳤고, 1회 구매자 약 49만 명 오분류와 가입 후 7일 안 첫 구매율 82~88% 과대 계산이 사라졌습니다.
• 검증: LLD를 v0.1부터 v0.6까지 6번 고치며 버전마다 스모크 테스트를 돌렸고, 1차에서 4건(국가 코드 누락, 상태 필터 오류, 사용자 키 오류, 구매자 분류 규칙 오류), 2차에서 1건(7일 활성화 분모의 자기 선택 편향)을 코드 작성 전에 찾았습니다. 노트북 프로토타입을 v1부터 v5까지 운영 적재로 옮기는 동안 회귀는 0건이었습니다.
• 요구사항 후보 12개는 첫 단계 지표 5개로 좁혔고, 처음 설계한 테이블 8개는 그 지표를 담는 뷰 3개와 이벤트 테이블 1개로 줄었습니다.
• AI가 제기한 결함 후보 30건을 다시 검증해 11건을 확정하고 8건을 고쳤습니다.
• 2026년 6월 19일 출시를 마쳤습니다.

기록과 자동화

• 문서: 이상 진단 대시보드 PRD·ADR·HLD·LLD 4종(하루), 신호 탐지 파이프라인 HLD 2개·LLD 3개·ADR 4개, 가중 결정표 2건(전달 방식, 첫 단계 범위), 첫 단계 기능 요약서를 직접 썼습니다.
• 프로세스 자동화: 이상 판정부터 원인 계산, 문장 작성, Slack 카드 발송까지 자동으로 이어집니다.
• 누가 쓰나: 받는 대상은 글로벌 마케팅, MD, 사업부 담당자입니다.

배운 점

1. 설계를 고칠 때마다 실제 데이터로 다시 확인하는 것을 코드를 쓰기 전 첫 검증으로 둡니다.
   • 상황: LLD를 v0.1부터 v0.6까지 6번 고치는 동안 데이터 계약이 실제 데이터와 맞는지 확인해야 했습니다.
   • 한 일: 버전마다 실제 테이블 구조와 값을 대조하는 스모크 테스트를 돌렸습니다.
   • 결과: 데이터 계약 8개 중 7개의 오류를 배포 전에 고쳐, 약 49만 명 오분류와 82~88% 과대 계산이 사라졌습니다.
2. 지표가 0으로 나오면 실제 결과인지 데이터가 비어서인지부터 가립니다.
   • 상황: 일일 알림 카드에 활성화율이 0으로 표시됐습니다.
   • 한 일: 표면 숫자를 그대로 믿지 않고 데이터 경로를 거꾸로 따라가, 0이 계산 결과가 아니라 데이터 공백임을 밝히고 끊긴 과거 구간을 다시 채웠습니다.
   • 결과: 활성화율이 정상으로 돌아왔습니다.
3. 수치와 원인 후보는 휴리스틱 규칙으로 코드가 만들고 LLM에는 문장만 맡기며, AI가 낸 결과는 한 번 더 검증합니다.
   • 상황: 이상 신호 알림 문장을 LLM으로 만들었고, AI가 결함 후보 30건을 제기했습니다.
   • 한 일: Prophet 판정과 휴리스틱 규칙 계산 뒤에 LLM이 원인 가설과 다음 할 일 문장만 쓰게 나눴고, 결함 후보 30건을 다시 검증했습니다.
   • 결과: 30건 가운데 11건을 확정하고 8건을 고쳤습니다.
4. 첫 단계에서 만들 것과 뺄 것을 문서에 먼저 나눠 적어 범위를 좁힙니다.
   • 상황: 목표 전체에는 시간 단위 탐지, 티켓 자동 생성, 피드백 루프까지 들어 있었습니다.
   • 한 일: 뺄 것 5가지를 기능 요약서에 따로 적고, 요구사항 후보는 영향·노력 2×2 표로 정리했습니다.
   • 결과: 첫 단계는 뷰 3개와 이벤트 테이블 1개로 좁혀 2026년 6월 19일에 출시했습니다.