← 업무 목록

플레이북_검토.md

플레이북(대시보드 ★플레이북 탭) vs 메타 안드로메다/GEM 충돌 검토

작성: 김서연 / 퍼포먼스팀

작성일: 2026-09-17 (KST)

검토 대상 원문: ~/Hermes/dashboard/build.py L167~180(알림 생성), L592~682(플레이북 섹션 HTML)

대조 기준: ~/ploe-work/research/meta_andromeda.md + Meta 공식 문서 직접 확인(2026-09-17 조회)

광고 계정: 이번 작업에서 조회하지 않았습니다(읽기 전용 원칙, 이번 건은 문서 대조 작업).

결론 한 줄: 충돌 5건(그중 심각 3건), 근거 미표기 3건, 충돌 없음 4개 파트.


0. 이번에 직접 확인한 Meta 1차 문서

문서URL확인일
머신 러닝 단계 정보facebook.com/business/help/1121679928307002026-09-17
제한된 머신 러닝 정보facebook.com/business/help/2692697373969812026-09-17
영향이 큰 변경 사항 및 머신 러닝 단계facebook.com/business/help/3164781089550722026-09-17
광고 수 관리 정보facebook.com/business/help/27200854147025982026-09-17
광고 세트와 캠페인을 결합하여 타겟 세분화 줄이기facebook.com/business/help/24194800916401052026-09-17
크리에이티브 피로도 추천 정보facebook.com/business/help/13468161423278582026-09-17
A/B 테스트 정보facebook.com/business/help/17381646430986692026-09-17
어드밴티지+ 타겟의 타겟 관리 및 타겟 추천 정보facebook.com/business/help/9383721277643912026-09-17
어드밴티지+ 캠페인에서 타겟 설정 선택하기ko-kr.facebook.com/business/help/259418579321258122026-09-17

안드로메다/GEM 쪽은 meta_andromeda.md에 정리된 1차 출처(engineering.fb.com 2024-12-02, Meta for Business 2024-11-19 / 2025-04-22 / 2025-12-16)를 그대로 씁니다. 2차 자료는 이 문서에서 근거로 쓰지 않았습니다.


1. 충돌 ①【심각】 "한 번에 하나만 바꾼 변형 A~D" = Meta가 말한 '반복 개선', 다양화가 아님

플레이북 원문(L638~647)

기획 — USP 하나에 변형 여럿
한 번에 하나만 바꿔야 무엇이 먹혔는지 안다
변형 A · 후킹 — 첫 문장만 교체. 나머지 고정.
변형 B · 증거 — 후기 ↔ 숫자
변형 C · 비주얼 — 첫 컷 교체. 제품컷 ↔ 실사용컷.
변형 D · 형식 — 이미지 ↔ 영상 ↔ 캐러셀.

충돌하는 Meta 원문 (Meta for Business 「Demystifying Creative Diversification」, 2025-12-16, 1차)

"Our ads system also analyzes creatives and groups together ads that share key visual and thematic attributes. When multiple ads look or feel alike, these are seen as variations of the same creative, meaning learnings and delivery optimizations are shared at the creative level."

같은 글이 '반복 개선(iteration)'을 "동일한 비주얼에 CTA 문구만 다른 두 광고"로 정의하고, 다양화의 재료는 되지만 대체물이 될 수 없다고 못 박았습니다.

왜 충돌하나. 변형 A(첫 문장만 교체)와 변형 B(증거만 교체)는 Meta 정의상 정확히 '반복 개선'입니다. 안드로메다는 수천만 개 후보 중 수천 개를 골라내는 retrieval 엔진이고, 그 앞단에서 유사 소재는 한 덩어리로 묶입니다. 즉 A·B를 4개 만들어 넣어도 retrieval이 보는 진입점은 1개일 수 있습니다. 플레이북은 "변형을 여럿 만들면 소재 수가 늘어난다"고 전제하지만, 현행 Meta 시스템에서 그 전제가 성립하지 않습니다.

변형 C(비주얼 전면 교체)·D(포맷 교체)는 분리도가 높아 이 지적에서 제외됩니다.

수정안 — L639~640 소제목과 L642~643 두 칸을 아래로 교체.

(소제목) 기획 — 구별되는 컨셉을 먼저, 변형은 그 다음
(부제) 문구만 바꾼 변형은 Meta가 같은 소재로 묶는다 (Meta, 2025-12-16)
컨셉 축 A · 구매 이유 — 다이어트 대체 / 운동 후 보충 / 아이 간식 / 혈당 관리. 서로 다른 사람에게 말 걸어야 다른 소재다.
컨셉 축 B · 증거 유형 — 후기 ↔ 수치 ↔ 랭킹 ↔ 비교. 비주얼까지 같이 바꾼다.
변형 C · 비주얼 — 첫 컷 전면 교체. 제품컷 ↔ 실사용컷.
변형 D · 형식 — 이미지 ↔ 영상 ↔ 캐러셀.

2. 충돌 ②【심각】 "3차 타겟 3종 테스트" = 어드밴티지+ 타겟 및 광고세트 통합 권장과 정면 충돌

플레이북 원문(L653~655)

테스트 순서 — 1차 메시지(같은 이미지 · 카피 3종, 승자=CTR) → 2차 비주얼(승자 카피 · 이미지 3종, 승자=CTR) → 3차 타겟(승자 조합 · 타겟 3종, 승자=ROAS/CPA)

충돌하는 Meta 원문 1 (「광고 세트와 캠페인을 결합하여 타겟 세분화 줄이기」, 1차)

"이상적인 타겟을 찾기 위해 이렇게 여러 세그먼트에 걸쳐 광고 세트를 분할하면 총 타겟 크기가 여러 광고 세트에 걸쳐 분할되기 때문에 광고 성과를 저해할 가능성이 있습니다. … 너무 많은 광고 세트가 동시에 게재되면 각 광고 세트의 학습 기회가 줄어들어 더 적은 결과를 얻게 됩니다."

충돌하는 Meta 원문 2 (「어드밴티지+ 타겟의 타겟 관리 및 타겟 추천 정보」, 1차)

"타겟 추천을 사용해도 … 추천이 항상 타겟을 제한하지는 않습니다. 예를 들어 성별로 여성을 추천한 경우에도 Meta AI가 남성이 반응할 가능성이 높다고 판단하면 남성에게도 광고가 게재됩니다."

왜 충돌하나. 두 가지입니다.

(가) 타겟 3종을 나누려면 광고세트를 3개로 쪼개야 하는데, 이는 Meta가 명시적으로 성과를 저해한다고 말한 구조입니다. 우리 계정은 광고세트당 주 50 최적화 이벤트에 이미 한참 못 미치는 규모(30일 CPA 약 26,000원 · 9월 일예산 수준 기준)라, 3분할 시 세 개 모두 '제한된 머신 러닝'으로 떨어질 가능성이 큽니다.

(나) 어드밴티지+ 타겟이 켜진 광고세트에서는 상세 타게팅·연령·성별이 제한이 아니라 추천이므로, "타겟 A vs 타겟 B" 비교 자체가 성립하지 않습니다. 세 세트가 같은 사람들에게 겹쳐 나갈 수 있습니다.

어드밴티지+를 끄고 수동으로 돌리면 비교는 성립하지만, 그건 Meta가 "성과를 향상하는 것으로 입증되었다"고 밝힌 기본 설정을 버리는 선택입니다(「어드밴티지+ 캠페인에서 타겟 설정 선택하기」).

추가 지적 — 승자 판정을 CTR로 삼는 것도 Meta A/B 테스트 공식 기준과 다릅니다.

"A/B 테스트에서 '결과당 비용' 또는 '전환 성과 증대당 비용' 기준으로 각 전략의 성과를 측정할 수 있습니다." (「A/B 테스트 정보」, 1차)

또한 같은 문서가 수동 온오프 테스트를 명시적으로 말립니다.

"광고 세트 또는 캠페인을 수동으로 설정하거나 해제하여 비공식적으로 테스트하는 것은 권장되지 않습니다. … 비공식 테스트는 타겟이 중복되는 결과로 이어질 수 있습니다."

수정안 — L653~655 항목 전체 교체.

테스트 순서 — 타겟은 테스트 대상에서 뺀다. 어드밴티지+ 타겟에서 우리가 넣는 연령·성별·관심사는 제한이 아니라 추천이라 A/B 비교가 성립하지 않는다 (Meta 「어드밴티지+ 타겟의 타겟 관리 및 타겟 추천 정보」).
1차 컨셉(구매 이유 3종, 같은 광고세트 안에서, 승자=CPA) → 2차 비주얼(승자 컨셉 · 이미지 3종, 승자=CPA) → 3차 포맷(이미지↔영상).
승자 판정은 CTR이 아니라 결과당 비용(CPA). CTR은 참고 지표로만 본다.
정식 비교가 필요하면 광고 관리자 A/B 테스트 도구를 쓴다. 수동 온오프 비교는 Meta가 권장하지 않는다.

3. 충돌 ③【심각】 "승자에 예산 몰아주기 + 변형 3~5개 즉시 제작" = 머신 러닝 재시작 유발

플레이북 원문(L676)

승자가 나오면 예산을 몰아주고 그 소재의 변형 3~5개를 즉시 만든다.

충돌하는 Meta 원문 (「영향이 큰 변경 사항 및 머신 러닝 단계」, 1차)

영향이 큰 변경 사항에 해당하는 항목: "광고 크리에이티브에 대한 모든 변경 사항", "광고 세트에 새 광고 추가", … 규모에 따라 판정되는 항목: "예산 금액"
"예를 들어 예산을 100달러에서 101달러로 높이면 … 다시 시작되지 않을 가능성이 높습니다. 하지만 예산을 100달러에서 1,000달러로 높이면 하나 이상의 광고 세트에서 머신 러닝 단계가 다시 시작될 수 있습니다."

왜 충돌하나. "몰아준다 + 즉시 3~5개 추가"는 예산 급변과 신규 광고 추가를 동시에, 승자가 막 나온 시점에 하는 동작입니다. 둘 다 영향이 큰 변경이라 해당 광고세트가 머신 러닝 단계로 되돌아가고, 승자 소재가 쌓아둔 최적화가 리셋됩니다. 게다가 1번 지적대로 그 변형 3~5개는 Meta가 같은 소재로 묶을 가능성이 높아, 리셋 비용만 치르고 다양성은 안 늘어납니다.

참고로 예산 인상 자체도 우리 계정 실측이 부정적입니다 — meta_andromeda.md ⑤: 예산을 건드린 4회 모두 CPA가 1.7~2.9배 상승(2026-05~09 /activities 기준).

수정안 — L676 교체.

승자가 나오면 그 광고세트는 건드리지 않는다. 예산 급증과 신규 광고 추가는 둘 다 '영향이 큰 변경'이라 머신 러닝이 리셋된다 (Meta 「영향이 큰 변경 사항 및 머신 러닝 단계」). 확장은 새 광고세트에 구별되는 컨셉으로 태운다. 예산 인상은 승인 후 1회 20~30% 이내.

4. 충돌 ④ "빈도 2.5 초과 = 교체"

플레이북 원문(L669~670, L675, L173~175)

빈도 {freq}회 — 같은 사람이 열 번 봤다. 2.5 넘으면 소모품 — 다음 소재 준비.
빈도 게이지 — 1.5 미만 싱싱함 · 1.5~2.5 다음 소재 준비 · 2.5 초과 교체

충돌하는 Meta 원문 (「크리에이티브 피로도 추천 정보」, 1차)

"타겟이 같은 광고를 너무 자주 본 것으로 판단되는 경우 광고 세트 또는 광고의 게재 열 상태가 크리에이티브 제한 또는 크리에이티브 피로도로 표시됩니다. … 결과당 비용이 이전에 게재한 광고보다 높지만 두 배에는 미치지 않는 경우 크리에이티브 제한, … 두 배에 도달하는 경우 크리에이티브 피로도 상태가 표시됩니다."
권장 사항: "다른 광고 만들기 — 원본 크리에이티브와 실질적으로 다른 새로운 이미지 또는 동영상을 사용하여 새 광고를 만드세요. 참고: 기존 광고 게재를 일시 중단하거나 해제하는 대신 게재 상태를 유지하면 결과를 극대화할 수 있습니다."

왜 충돌하나. 두 군데입니다.

(가) 판정 기준. Meta의 피로도 판정은 빈도 숫자가 아니라 결과당 비용의 상승폭이고, 광고 관리자 게재 열에 상태값으로 뜹니다. "2.5"라는 임계값은 Meta 공식 문서에서 확인되지 않습니다(업계 관행 수치).

(나) 처방. 플레이북은 "교체"(=끄고 새 것), Meta는 "끄지 말고 유지한 채 실질적으로 다른 광고를 추가"입니다. 정반대입니다. 게다가 광고세트를 7일 이상 일시 중지하면 재개 시 머신 러닝이 다시 시작됩니다(「영향이 큰 변경」).

수정안 — L675 교체.

빈도는 참고 지표. 판정은 광고 관리자 게재 열의 '크리에이티브 제한 / 크리에이티브 피로도' 상태로 한다 (Meta 「크리에이티브 피로도 추천 정보」 — 결과당 비용이 직전 광고 대비 2배면 피로도). 빈도 2.5는 우리 내부 경보선이며 Meta 기준이 아니다.
피로도가 뜨면 기존 광고는 끄지 말고 켜둔 채, 실질적으로 다른 소재를 추가한다.

5. 충돌 ⑤ "소재 수명이 짧아 학습 전에 꺼진다" — 층위가 틀림

플레이북 원문(L665~666, L170~172)

소재 수명 {our_med}일 — 업계 중앙 {ref_med_days}일. 학습 전에 꺼서 최적화할 시간이 없다.

충돌하는 Meta 원문 (「머신 러닝 단계 정보」, 1차)

"머신 러닝 단계는 게재 시스템이 광고 세트의 게재와 성과에 대해 계속해서 학습해야 하는 단계입니다. … 일반적으로 광고 세트가 마지막으로 대폭 수정되고 한 주가 지난 후 약 50건의 결과가 발생하면 이루어집니다."

왜 충돌하나. 학습 단계는 광고(소재) 단위가 아니라 광고세트 단위이고, 종료 조건은 기간이 아니라 주 50건 결과입니다. 소재를 오래 켜둔다고 학습이 끝나지 않고, 소재를 일찍 꺼도 광고세트 학습은 유지됩니다. 문장이 가리키는 인과가 틀렸습니다.

다만 지적 자체가 무의미하진 않습니다 — 소재를 일찍 끄면 그 소재의 성과를 판정할 표본이 안 쌓입니다. 그건 '학습'이 아니라 '판정'의 문제입니다. 그리고 플레이북에는 소재를 끄는 행위 자체가 학습을 건드린다는 진짜 위험(광고세트 7일 이상 중지 → 재시작)이 빠져 있습니다.

수정안 — L666 교체.

업계 중앙 {ref_med_days}일. 일찍 끄면 그 소재의 성과를 판정할 표본이 안 쌓인다. (머신 러닝 단계는 소재가 아니라 광고세트 단위 · 주 50건 결과 기준 — Meta 「머신 러닝 단계 정보」)

6. 근거 미표기 (충돌은 아니나 출처를 달아야 함)

플레이북 문장상태조치
L667~668 "동시 활성 15개 이상 유지" / L167 알림 n_active < 15Meta 공식 수치는 「Advantage+ 쇼핑 캠페인 최소 20개」(2024-11-19, 1차). 15는 우리 내부 수치. 한편 「광고 수 관리 정보」는 "한 번에 너무 많은 광고를 게재하면 각 광고의 게재가 저조해집니다"라며 반대 방향도 말함 — 두 Meta 문서가 서로 당기는 사안이라 숫자 하나로 못 박으면 안 됨"동시 활성 15개 이상(우리 예산 기준 내부값. Meta 공식 권장은 Advantage+ 쇼핑 20개)"로 표기
L672 "구매 3건 또는 클릭 80 전에는 끄지 않는다"Meta 공식 기준 아님(공식은 광고세트 주 50 최적화 이벤트). 내부 판정 룰"(내부 판정 기준)" 각주
L650~652 증거 문구(누적 100만개, 올리브영 1위, 재구매율 51% 등)Meta 로직과 무관. 다만 L656이 요구하는 "기준일 각주"가 정작 이 목록엔 없음각 수치에 기준일 병기

7. 충돌 없음

  • 0단계 목표 역산(L596~613, 객단가÷목표ROAS=CPA 상한) — Meta 로직과 무관한 자체 손익 기준. 충돌 없음.
  • 1단계 레퍼런스(L616~634, 장수 광고를 보고 카피가 아닌 뼈대를 빌린다) — 오히려 Meta 다양화 권장과 같은 방향. 충돌 없음.
  • L677 "공구 기간 ROAS를 보고 예산을 늘리지 않는다" — 우리 계정 실측 근거가 있는 항목(공구/비공구 분리). 충돌 없음.
  • L656 "「살 빼는·치료·질병」 표현 금지" — 광고 정책 영역. 이번 검토 범위 밖이나 충돌 없음.

  • 8. 데이터로 확인 불가

    1. 우리 광고세트가 실제로 '제한된 머신 러닝' 상태인지 — 게재 열 상태는 광고 관리자 UI 지표이고 Marketing API로 조회되지 않습니다. 대표님 화면 확인 필요.

    2. 현재 활성 소재가 Meta 기준 몇 개의 구별된 컨셉으로 묶이는지 — 그룹핑 결과를 외부에 노출하는 필드가 없습니다. 실물 감사로 추정만 가능.

    3. "빈도 2.5"가 우리 계정에서 실제 임계값인지 — 소재별 빈도-CPA 곡선을 아직 뽑지 않았습니다. 별건으로 가능합니다.


    9. 헤르메스에게 — 우선순위

    수정 3건만 먼저 반영해도 플레이북이 현행 Meta와 어긋나지 않습니다.

    1. §3 (L676) — 지금 이 문장대로 하면 승자 광고세트를 스스로 리셋합니다. 실질 손실이 가장 큼.

    2. §2 (L653~655) — 3차 타겟 테스트는 우리 예산에서 실행하면 세 세트 전부 학습 미달로 갑니다.

    3. §1 (L638~647) — 변형을 늘려도 소재 수가 안 늘어나는 구조적 문제.

    §4·§5는 문구 정정 수준이라 같이 반영하면 됩니다.

    build.py 수정은 하지 않았습니다. 대시보드 코드 변경은 제 권한 밖으로 보고 원문·대체문만 제시했습니다.