지금 어디까지 왔고,
다음에 무엇을 하면 좋을까
wisebirds-ax 저장소 전수구성 현황 진단 → 구조로 본 강점과 여백 → 먼저 할 것 2건 + 후속 2건
목차
01현황 — 만드는 단계는 이미 지났다
읽히는 신호
- 마케터가 직접 만들고 직접 배포하는 흐름이 자리 잡았다. 저장소 84개 중 51개가 표준 파이프라인(
argocd-managed)을 타고*.wisebirds.ai로 서비스된다 - 개인 도구 수준을 넘어 광고주에게 링크를 공유하는 실서비스가 여럿이다 — 헤일리온, LX ZIN, 클리오, 랄프 로렌, 직방, LG전자 정산
- 효과도 숫자로 남아 있다: 경쟁사 모니터링 40분 → 5분, 정산 대사 며칠 → 몇 분, 주간 코멘트 30~60분 → 10분
같이 봐야 할 것
- 쇼케이스의 "운영중"은 자기 신고다. 실제 데이터가 최근까지 도는 것으로 확인된 건 15건 — 나머지를 부정할 근거는 없지만, "무엇이 실제로 쓰이는가"를 아직 사람이 화면을 열어 판단한다
- 도메인 60개 중 정상 응답 44개. 응답이 없는 것들이 언제부터인지 아무도 모르고 있었다
- 즉 만드는 힘은 충분하고, 만든 것을 유지·관측하는 층이 얇다
02잘 되고 있는 것 — 여기는 손대지 않는다
아래 세 영역은 이미 충분히 갖춰져 있다. 새로 만들자는 제안은 중복이 된다.
리포트 자동화
30건이 돌고 있다. RAW 업로드 → 자동 집계 → 코멘트 초안 → 공유가 하나의 관행으로 정착했다.
- 코멘트 자동 생성만 8건 (사실/추정 구분 표기까지)
- 판단 자동화도 5건 — 입찰·예산 상향/유지/하향, 소재 수명주기, 주간 액션 P0~P2
- 헤이딜러도 데일리·주간·폐차 리포트가 이미 가동 중
소재 자동화
디자인랩 14건 + 조직 저장소 8개. 생성부터 검수·등록·아카이브까지 한 바퀴가 돈다.
- 카피 생성, PSD 마스터 → 8매체 36규격 변환
- 브랜드 가이드 자동 검수, 소재 대량 등록
- 소재 수명주기 판단(3단계 트리거)까지 구현
배포 표준
저장소 하나 만들면 주소가 나오는 구조가 완성돼 있다.
- push → 빌드 → ArgoCD →
<이름>.wisebirds.ai ax-starter-kit에 템플릿과 스킬 3종(ax-new-project·ax-deploy·ax-guide-aligner)- 시크릿 주입·인증 옵션이 차트에 내장
03구조로 보면 — 가운데만 두껍다
데이터가 마케터에게 닿기까지는 공급 → 가공 → 전달 세 층을 지난다. 지금은 가운데 층만 두껍고 양옆이 얇다.
이 구조가 만드는 일
- 담당자가 자리를 비우면 대시보드가 함께 멈춘다
- 수치가 이상해져도 누군가 열어보기 전까지 아무도 모른다
- 대시보드는 늘어나는데 하루에 열어보는 화면 수도 같이 늘어난다
그래서 방향은
가운데를 더 만들지 말고, 양옆을 붙인다.
- 공급: 사람이 하던 다운로드를 자동으로 — 대시보드 코드는 그대로
- 전달: 먼저 알려주고, 물어보면 답하는 창구 하나
03-2현장에서 실제로 일어난 일
아래는 지난 두 달 문의 기록에서 확인된 실제 사건이다. 공통점은 "멈춘 걸 한참 뒤에 알았다"는 것이다.
멈춘 것을 늦게 알았다
- 자동 리포트가 하루 실행되지 않았는데, 담당자가 이틀 뒤에 발견했다
- 데이터 적재가 멈춘 것을 하루 넘게 아무도 몰랐고, 지원 담당자가 뒤늦게 알렸다
- 서비스가 중단된 것을 지원 담당자가 먼저 발견해 고쳐두자, 사용자가 "마침 연락드리려던 참이었다"고 답했다
실패가 성공으로 기록됐다
- 외부 저장소가 3분간 응답하지 않아 그날 데이터가 기록되지 않았는데, 프로그램은 정상 종료로 남겼다
- 다른 대시보드는 데이터를 못 읽자 기존 값을 빈 결과로 덮어썼다. 사용자가 3분 동안 53번 새로고침했지만 52번은 그 빈 값을 다시 받았다
- 화면 문구도 "공유 설정을 확인하세요"라고 나와, 원인을 엉뚱한 곳에서 찾게 만들었다
그래서 지금은
- 장애를 아는 경로가 ①사용자가 이상하다고 느껴 문의 ②지원 담당자가 눈으로 확인 두 가지뿐이다
- 대시보드가 늘어날수록 이 방식은 유지되기 어렵다
흥미로운 사실
두 달치 문의를 통틀어 "알림을 붙여달라"는 요청은 한 건도 없었다. 알림 이야기는 언제나 지원 담당자 쪽에서 먼저 나왔다.
사용자는 대신 이렇게 말했다 — "1~2시간 지나면 저절로 낫긴 하는데, 바로 확인이 필요할 때 불편합니다."
요청이 없다는 것이 필요가 없다는 뜻은 아니다. 겪고는 있지만 해결 가능한 문제로 인식되지 않은 상태에 가깝다. 제안 2가 여기에 대응한다.
04추천 — 이 두 가지를 먼저 하시길 권합니다
진단을 그대로 따르면 손댈 곳은 공급층과 전달층이다. 그중 지금 시작해서 효과가 가장 빨리 보이는 두 가지를 먼저 권한다. 판단 기준은 셋이다 — 이미 있는 것과 겹치지 않는가 · 기존 자산을 그대로 쓰는가 · 마케터가 매일 체감하는가.
매체 데이터 자동 수집
사람이 하던 다운로드만 대신한다. 대시보드도 시트도 그대로 두고, 채우는 주체만 바꾼다.
이걸 먼저 권하는 이유
- 매체 수집기가 이미 만들어져 있다 — 새 개발이 아니라 연결에 가깝다
- 대시보드 코드를 한 줄도 고치지 않는다. 실패해도 원래대로 돌아갈 뿐이다
- 매일 반복되는 시간이 줄어든다 — 담당자당 10~30분 × 12명 이상 ≈ 하루 3~5시간
- 담당자가 자리를 비워도 대시보드가 멈추지 않는다
슬랙 알림과 질의
이상을 먼저 알려주는 창구를 하나 만든다. 감지 로직은 이미 여러 대시보드 안에 있다.
이걸 같이 권하는 이유
- 감지는 이미 있고 통보만 없다 — 붙이는 비용이 작다
- 앞의 자동 수집이 잘 돌고 있는지도 같은 창구로 확인된다. 둘이 서로를 받쳐 준다
- 1·2단계(알림·브리핑)는 LLM 없이 된다. 사내 원칙과도 맞다
- 지금은 멈춘 걸 사람이 발견해야 안다 — 그 구조를 바꾸는 가장 짧은 길이다
모니터링 한 곳으로
순위·경쟁사 모니터링은 8곳에서 이미 잘 돌고 있다. 새로 만들 이유가 없으니, 새 프로젝트부터 수집만 공용으로 쓰게 하는 정도가 적당하다. 급하지 않다.
AI 검색 노출 측정
사내에 아직 사례가 없는 영역이다. 광고주 한 곳으로 1회 진단 리포트를 만들어 반응을 보는 정도로 가볍게 시작하기를 권한다.
1매체 데이터 자동 수집
사람이 하던 다운로드만 대신한다. 수집기가 매체 API에서 RAW를 받아 지금 쓰는 구글시트를 그대로 채운다. 대시보드 코드는 한 줄도 고치지 않는다 — 채우는 주체만 사람에서 자동으로 바뀐다.
지금 상태
- 매일 매체 콘솔에 들어가 CSV를 내려받아 시트에 올리는 일이 12개 이상의 대시보드를 떠받치고 있다
- 담당자 휴가·이동이 그대로 대시보드 정지로 이어진다
- 구글시트가 사실상 사내 표준 저장소다(12개 저장소가 원본으로 사용)
이미 있는 자산을 쓴다
marketing-support-backend에 매체 20여 개 수집기가 만들어져 있다 — Meta, Google Ads, DV360, GA4, TikTok, 네이버 SA/GFA, 카카오, Criteo, AppsFlyer 등- 일부 프로젝트는 이미 자동 적재를 하고 있다(BigQuery 일일 적재, GitHub 수집, 폴더 감시)
- 즉 새로 개발이 아니라 연결에 가깝다
난이도는 매체마다 다르다. Meta·TikTok은 앱 심사가, 네이버 SA/GFA는 로그인 기반 수집이 변수다. 한 매체·한 광고주로 시작해 검증한 뒤 넓히는 방식을 권한다.
기대 효과: 담당자당 하루 10~30분 × 12명 이상 ≈ 하루 3~5시간. 담당자 부재와 무관하게 데이터가 유지된다.
필요한 것
사내 규칙상 GitHub Actions 스케줄은 쓰지 않고 파드 내 스케줄러를 쓴다(지연·중복 실행 사례가 있었다).
2슬랙 알림과 질의
"보러 가는 데이터"를 "찾아오는 데이터"로. 대시보드는 사람이 열어야 작동한다. 광고주를 여러 곳 맡으면 모든 화면을 매일 같은 밀도로 볼 수 없고, 이상은 대개 덜 보던 계정에서 생긴다.
세 단계로 나눠 붙인다
- 알림 — 예산 소진 속도 이탈, CPA 급등, 소진 0원, 전환 0(추적 끊김). 기존 Z-score·임계값 로직을 그대로 쓴다
- 브리핑 — 매일 아침 광고주별 어제 성과와 특이사항 요약
- 질의 — "이번 주 헤이딜러 내차팔기 CPA 왜 올랐어?"를 슬랙에서 바로
1·2단계는 LLM 없이 성립한다. 문장을 다듬는 구간에만 모델을 쓴다 — 사내 원칙("규칙 기반을 LLM으로 교체하지 않는다")과도 맞다.
지금 상태와 필요한 것
- 슬랙 연동은 2건, 둘 다 리포트를 보내는 용도다. 물어보면 답하는 창구는 아직 없다
- 이미 만들어 둔 이상 감지 로직(CTR 급락·CPC 급등·Z-score)이 여러 대시보드 안에 있다 — 감지는 있고 통보가 없는 상태
3모니터링을 한 곳으로
순위·경쟁사 모니터링은 8곳 이상에서 각자 만들어져 잘 돌고 있다. 새로 만들 이유는 없다. 수집만 공용으로 묶고 화면은 그대로 둔다.
지금 있는 것
- 브랜드 키워드 노출순위 조회, 파워링크 키워드 침해 감지(메일 통보 포함)
- 경쟁사 광고 자동 캡처·주차 아카이빙 — 40분 → 5분
- 증권·부동산·패션 등 업종별 경쟁사 대시보드
- 앱 지표는 모바일인덱스 연동이 사실상 사내 표준으로 자리 잡았다
묶으면 좋아지는 것
- 수집 방식(프록시·차단 회피·광고/오가닉 판별)을 매번 다시 푸는 일이 없어진다
- 한 곳이 막혔을 때 다른 프로젝트가 같이 배우게 된다
- 개인 PC에서 도는 수집기를 서버로 옮길 수 있다
기존 화면과 저장소는 그대로 둔다. 사내 원칙상 강제 이관은 하지 않는다 — 새로 만드는 프로젝트부터 공용 수집을 쓰게 하는 방식이 현실적이다.
여기에 하나 더 얹을 수 있는 것
순위를 이미 재고 있고 입찰가도 갖고 있으므로, 둘을 교차하면 예산 재배분 근거가 나온다. 아직 사내에 없는 각도다.
| 키워드 | 입찰가 | 오가닉 | 판정 |
|---|---|---|---|
| 내차팔기 | 15,000 | 1위 | 재배분 검토 |
| 중고차 시세조회 | 8,200 | 3위 | 관찰 |
| 중고차 판매 절차 | 6,900 | 미노출 | 유지 |
| 내차 시세 | 4,100 | 2위 | 재배분 검토 |
| 중고차 매입 견적 | 11,300 | 미노출 | 유지 · 증액 |
"광고비를 줄이자"가 아니라 "같은 예산을 더 필요한 쪽으로 옮기자"로 제시하는 편이 광고주와의 대화에 맞는다.
4AI 검색 노출 측정
"우리 브랜드가 AI에게 물어봤을 때 어떻게 나오나요?" — 광고주가 곧 물어볼 질문이다. 사내 저장소·쇼케이스 전체에서 관련 사례가 아직 확인되지 않는다. 검색 관련 프로젝트는 모두 검색광고 순위·쿼리·검색량 쪽이다.
측정 항목
- 인용 여부 — 주요 질문에서 브랜드가 답변에 등장하는지, 어떤 맥락으로 언급되는지
- 유입 — 분석 도구에서 AI 경유 유입을 분리해 추이로
- 기술 진단 — 페이지 구조·구조화 데이터·AI용 요약 파일 등 인용되기 좋은 형태인지
- 개선 목록 — 광고주 개발팀에 그대로 넘길 수 있는 형태로
왜 지금인가
- 검색의 일부가 대화형으로 옮겨가는 중이고, 아직 표준 측정법이 없는 영역이다
- 먼저 자리를 잡으면 기존 광고주에게 새로 제안할 항목이 하나 생긴다
- 측정 자체는 무겁지 않다 — 월 1회 진단 리포트로 시작할 수 있다
Gemini 미인용 → 서비스 소개 페이지·구조화 데이터 보강 제안으로 연결
시작하는 방법
광고주 한 곳으로 1회 진단 리포트를 만들어 반응을 본다. 반응이 있으면 월간 정기 항목으로, 없으면 거기서 멈춘다. 초기 투입이 작아 실패해도 비용이 크지 않다.
09운영 기반 — 오래 가게 만드는 세 가지
앞의 네 가지를 얹기 전에, 지금 만들어진 것들이 계속 살아 있게 하는 받침이 필요하다. 셋 다 크지 않다.
데이터 신선도
도메인 60개 중 정상 응답이 44개다. 언제부터 멈췄는지를 알 방법이 지금은 없다.
- 각 서비스가 "마지막 데이터 시각"을 한 줄로 알려주는 규칙만 정하면 된다
- 그러면 멈춘 것을 자동으로 알 수 있다 — 제안 2의 알림에 그대로 얹힌다
모델 사용 가시화
LLM을 실제로 호출하는 프로젝트가 15개인데, 사용량을 집계하는 곳은 1개다.
- 어느 프로젝트가 얼마나 쓰는지 보이면 예산 대화가 쉬워진다
- 모델명이 코드에 흩어져 있어, 모델을 바꿀 때 전수 수정이 필요하다
접근 정리
표준 배포 49개 중 로그인이 걸린 것은 5개다. 주소 규칙이 단순해 추측이 가능하다.
- 광고주 실데이터가 보이는 화면부터 순차적으로 로그인을 켜면 된다
- 차트에 옵션이 이미 있어 설정 한 줄로 켜진다
10요약
현황
- 저장소 84개, 표준 배포 51개, 쇼케이스 69건 — 만드는 단계는 지났다
- 리포트·소재·대시보드는 이미 충분하다
- 얇은 곳은 데이터가 들어오는 층과 사람에게 닿는 층이다
추천
- 먼저 — 매체 데이터 자동 수집 — 사람이 하던 다운로드만 대신, 대시보드는 그대로
- 같이 — 슬랙 알림과 질의 — 감지는 이미 있고 통보가 없다
- 그다음 — 모니터링 통합 — 새로 만들지 않고 수집만 공용으로
- 여유가 되면 — AI 검색 노출 측정 — 아직 사례가 없는 영역, 1회 진단으로 시작
하지 않을 것
리포트·소재 자동화를 새로 만드는 제안 · 기존 도구를 하나로 강제 이관하는 제안 · 잘 도는 규칙 기반 로직을 LLM으로 바꾸는 제안. 이미 잘 되고 있는 것을 건드리지 않는다는 것이 이 문서의 전제다.
wisebirds-ax 저장소 전수 · juyoungoh-wisebirds/ax-solution