데일리 광고 에이전트 구축 — 네이버 AI 브리핑 베타를 24시간 내 캐치한 방법

네이버 AI 브리핑 광고 베타가 2026-05-07 시작됐다. 이걸 발표 다음날인 2026-05-08에 알았다. 클라이언트 브리핑 전에. 우연이 아니라 데일리 에이전트를 돌렸기 때문이다.

TL;DR medical_dental_ads_daily_goal.md로 정의한 데일리 리서치 에이전트에 공식 소스 URL을 직접 지정해두면, 일반 WebSearch보다 빠르고 정확하게 공식 변화를 잡는다. 6세션 102 tool calls, 파일 8개 생성.

데일리 에이전트의 핵심: URL 명시

치과 광고 관련 네이버 알고리즘 모니터링을 에이전트에게 맡길 때 가장 흔한 실수는 “알아서 찾아라”다. WebSearch에 키워드를 던지면 모델은 블로그 포스트, 커뮤니티 글, SEO 에이전트 마케팅 글을 먼저 가져온다. 공식 공지를 보려면 URL을 직접 명시해야 한다.

medical_dental_ads_daily_goal.md에 박아둔 확인 대상 목록:

- 네이버 광고 공지 https://ads.naver.com/notice?categoryId=147
- 네이버 광고 도움말 https://ads.naver.com/help
- 네이버 서치어드바이저 https://searchadvisor.naver.com/
- 스마트플레이스 고객센터 (해당 섹션 URL)
- 대한치과의사협회 의료광고심의 https://www.dentalad.or.kr

이 목록이 있으면 에이전트가 WebFetch로 각 URL을 직접 요청한다. 없으면 WebSearch가 퍼져나가고 소스 신뢰도가 무너진다. 세션 6에서 WebSearch(9) + WebFetch(6) 조합이 나온 이유가 여기 있다—키워드 탐색과 공식 URL 직접 접근을 둘 다 했다.

결과: 2026-05-07 네이버 AI 브리핑 광고 베타 시작, 1차 적용 범위(쇼핑검색광고/ADVoost 연동, AI 답변 하단 노출), 헬스케어 버티컬 연내 로드맵을 당일 캐치. 의료 키워드 직접 적용 여부만 [확인 필요]로 남겼다.

4-agent 병렬이 필요한 이유

단일 에이전트에 “네이버 광고 알고리즘 변화를 조사해라”라고 던지면 한 방향으로만 파고든다. 공식 공지를 잘 찾는 에이전트가 업계 커뮤니티 관찰도 잘 찾는다는 보장이 없다.

세션 1에서 research 스킬로 4개 각도를 분리했다:

Agent 1: 공식 공지·서치어드바이저 원문 추출
Agent 2: 자연검색·플레이스 랭킹 변화 (커뮤니티 + 업계 관찰)
Agent 3: ADVoost 매칭 로직 변화 분석
Agent 4: 치과/의료 광고 실무 적용 각도

단일 메시지에서 Agent 호출 4개를 동시에 보낸다. 각 에이전트 프롬프트에 “출처 URL 필수, 자매 에이전트와 중복 영역을 플래그하라”를 명시했다. 21분 만에 4개 독립 리서치 파일이 떨어졌다.

순차 실행이었다면 80분 이상 걸렸을 작업이다. 병렬 디스패치는 속도 이상의 이점이 있다—4개 에이전트가 독립적으로 판단했기 때문에 한 에이전트의 편향이 전체 결과를 오염시키지 않는다.

Evidence Grading이 없으면 보고서가 위험하다

4개 에이전트 결과를 합치는 순간 문제가 드러났다. 첫 초안에 “2026-05 플레이스광고 적용 공지”가 사실처럼 들어가 있었다. naver_ads_notice_extracts.json 15건 어디에도 없는 내용이었다.

의료광고 분야에서 공식 확인 없는 “알고리즘 변화” 표현은 컴플라이언스 리스크다. 세션 2에서 claude_synthesis_review.md를 별도로 만들고 5단계 증거 등급을 강제했다:

공식 확인   → 광고 공지에 명시된 것만
도움말 해석 → 공식 도움말에서 추론 가능한 것
업계 관찰   → 공지 없이 커뮤니티·실무에서 관찰된 것
합리적 유추 → 공식 자료 기반 추론
확인 필요   → 출처 부재 또는 미확인 주장

자연검색·플레이스 일반 랭킹은 네이버 비공개 정책상 “업계 관찰” 이상으로 올릴 수 없었다. 이 단계를 별도 세션으로 뺀 게 결과적으로 보고서 품질을 실질적으로 바꿨다.

세션 2 소요: 5분, Read(4), Bash(4), Write(2), Grep(1).

API Overload에서 손실 없이 복구한 이유

세션 3에서 HTML 보고서를 처음 만들려다 API Error: Overloaded가 터졌다. Opus 4.7 + 병렬 에이전트 조합이 요청을 과하게 날렸다.

손실이 없었던 이유는 단순하다. research-minutes.md와 claude_naver_research_report.md가 이미 저장돼 있었기 때문에 세션 4에서 바로 이어받을 수 있었다. 에이전트가 중간 결과를 파일로 떨어뜨리도록 설계해두면 세션이 끊겨도 컨텍스트를 잃지 않는다.

세션 4에서 만든 첫 번째 HTML 보고서는 40.9KB, 429줄. Bash를 15번 쓴 이유는 Write 후에 태그 쌍 균형, DOCTYPE, viewport, 섹션 존재 여부를 스크립트로 직접 검증했기 때문이다.

보고서를 3번 만든 건 실패가 아니다

HTML 보고서가 세 버전으로 만들어졌다:

naver_algorithm_ad_agency_prediction_report_2026-05-08.html — 알고리즘 변화 전반 + 대행사 예측
(같은 날 세션 5) 최근 6개월 압축 버전 — “최근 6개월, 핵심만”으로 요구사항이 바뀌었다
2026-05-08-daily-update.md + 데일리 HTML — 당일 모니터링 결과

세 번 만든 건 요구사항 발전이었다. 첫 버전이 “변화 전반”이었다면 두 번째는 “대행사 관점 예측”, 세 번째는 “최근 6개월 압축”. 이전 결과물을 덮어쓰지 않고 새 파일로 만들었다—Codex 교차검증에서 비교 기준을 남겨두기 위해서다.

전체 통계

6세션, 총 102 tool calls:

도구	호출 수
Bash	29
Read	28
Write	9
WebSearch	9
Agent	8
WebFetch	6
Grep	5
TodoWrite	3

생성 파일 8개, 수정 파일 0개. 데일리 에이전트 시스템 + 파일 기반 상태 관리 + Evidence Grading 조합이 이번 작업의 핵심이었다. 어느 하나만 빠져도 보고서 신뢰도나 복구 가능성이 달라졌을 것이다.