Communitygithub.com

arome3/증거-기반-카피라이팅

모든 주장이 가져온 출처로 추적되고, 레이블이 지정되며, 게시 전 적대적 검증을 거치는 마케팅 카피 작성 기술입니다. FTC 실질증명 수준의 규율을 실무 파이프라인으로 구현합니다.

증거-기반-카피라이팅란 무엇인가요?

이 스킬은 AI 에이전트(Claude Code, Cursor 등)가 마케팅 카피를 작성할 때 모든 주장이 명확하게 검증된 출처에 기반하도록 강제하는 워크플로우를 제공합니다. 바닥 다지기(Ground) → 리서치(Research) → 작성(Write) → 검증(Verify) → 출시(Ship)의 5단계 파이프라인으로 구성되며, 각 주장은 반드시 프로젝트 문서나 직접 가져온(fetch) 외부 소스에 연결되어야 합니다. 이 스킬은 근거 없는 통계 인용, 기능/용어 조작, 검증되지 않은 출처 사용 등 카피라이팅에서 흔히 발생하는 두 가지 미묘한 실패를 방지하는 데 중점을 둡니다. 자동화된 결정론적 검사(스크립트 실행)와 사람(또는 다른 에이전트)의 적대적 검토를 모두 요구하며, 최종 결과물에는 감사 추적(audit trail)로서 사실 베이스(fact base), 섹션별 주석, 배제된 증거 목록, 오픈 결정 사항이 포함됩니다. FTC 및 Lanham Act 같은 미국 광고 규제를 준수하도록 설계되었지만, 법률 자문은 아닙니다.

지원 대상✓Claude Code~Codex CLI~Cursor
npx skills add arome3/evidence-based-copywriting

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

증거 기반 카피라이팅

개요

가져온 출처나 프로젝트 자체 문서로 추적할 수 없는 주장은 출시되지 않습니다. 이 단일 규칙은 미국 광고주에 대한 법률이기도 합니다. FTC는 객관적 주장에 대해 이의 제기 이후가 아니라 유포되기 전에 "합리적인 근거"를 요구합니다(references/evidence-standards.md 참조). 이 스킬은 그 기준을 실제 작동하는 파이프라인으로 전환합니다: 바닥 다지기 → 리서치 → 작성 → 검증 → 출시.

결과물은 단순한 카피가 아닙니다. 카피에 감사 추적(audit trail)이 더해집니다: 사실 베이스(fact base), 출처 레이블이 있는 섹션별 주석, 플래그가 지정된 미결정 사항, 검토자가 반증할 수 있는 체크리스트.

이 스킬이 막고자 하는 두 가지 실패

기준 테스트에 따르면 능숙한 작성자(사람과 모델 모두)는 더 이상 로고나 사용 후기를 거의 조작하지 않습니다. 그들은 두 가지 더 미묘한 방식으로 실패합니다:

  1. 검증 없는 인용. 그럴듯한 URL과 함께 실제처럼 들리는 통계를 기억에서 작성하고, 가져오지(fetch) 않은 채로 — 때로는 "출시 전에 검증하세요"라는 메모와 함께 출시합니다. 통계는 구식이 되거나, 대체되거나, 그런 적이 없습니다. TODO는 실질증명이 아닙니다.
  2. 기능 및 용어 조작. 발명된 제품 메커니즘("에이전트리스 센서", "읽기 전용 커넥터", "시스템콜 베이스라이닝"), 상업적 조건("평생 금리 고정", "소스코드 에스크로"), 그리고 어떤 문서도 입증하지 않는 아키텍처 세부 사항. 이것들은 마치 카피라이팅의 재량 범위처럼 느껴집니다. 그러나 이들은 입증되지 않은 주장입니다 — FTC 법리는 묵시적 주장까지 포함하며, 발명된 용어는 계약 분쟁이 됩니다.

자신이 이 중 하나를 하고 있음을 알아차리면 즉시 중단하고 해당 항목을 공개 질문으로 사실 베이스(fact base)에 라우팅하세요.

워크플로우

이 체크리스트를 작업 노트에 복사하고 완료 시 항목을 체크하세요:

증거 기반 카피 파이프라인
[ ] 1. GROUND(바닥 다지기)    — 프로젝트 문서로부터 사실 베이스 구축; 공개 질문 목록화
[ ] 2. RESEARCH(리서치)  — 외부 증거 가져오기(fetch) + 검증; 경쟁사 매핑; 구매자 언어 샘플링
[ ] 3. WRITE(작성)     — 템플릿에서 결과물 초안 작성, 주장 인라인 레이블 지정
[ ] 4. VERIFY(검증)    — 적대적 검토 통과; 결정론적 검사 통과
[ ] 5. SHIP(출시)      — 체크리스트 정직하게 표시; 미결정 사항 소유자에게 플래그

1. 바닥 다지기(Ground)

프로젝트 자체 문서(전략 문서, 사양서, 가격표, 창업자 답변)를 사용하여 templates/fact-base-template.md를 작성하세요. 어떤 글을 쓰기 전에 프로젝트가 제공하는 모든 문서를 읽으십시오.

  • 카피가 제품에 대해 할 모든 주장은 출처가 있는 사실 베이스 행으로 추적 가능해야 합니다. 여기에는 헤드라인 기능뿐만 아니라 메커니즘, 아키텍처, 통합, 성능, 팀 자격 증명, 상업적 조건이 포함됩니다.
  • 카피에 필요한 사항 중 어떤 문서도 답하지 않는 것은 "소유자를 위한 공개 질문(Open questions for the owner)" 에 들어갑니다. 이는 해당 카피를 차단하거나, 결과물의 주석에 명시적인 [소유자를 위한 공개 결정(Open decision for the owner)] 플래그로 출시됩니다. 그럴듯한 내용을 써서 미지의 것을 해결하지 마십시오.
  • 소유자의 지시가 서로 충돌할 때(명시된 대상 vs. 요청된 어조, 요구된 증거 vs. 실제 단계), 문서화된 사실에 맞게 작성하고 충돌을 공개 결정으로 플래그 지정하십시오 — 조용히 편을 들지 말고, 더 큰 소리의 지시가 문서화된 사실을 덮어쓰도록 두지 마십시오.
  • 단계 정직성(stage honesty) 섹션을 충실히 기록하십시오: 고객 수, 실제로 보유한 인증, 이 단계에서 금지된 주장. 회사에 고객이 0명이라면 카피는 그렇게 말할 것입니다 — references/copy-craft.md의 단계 정직성 플레이북을 참조하십시오.

2. 리서치(Research)

세 가지 병행 트랙(가능하면 하위 에이전트 파견; 그렇지 않으면 순차적으로 실행). 전체 프로토콜: references/evidence-standards.md.

  • 시장 증거. 문제 서사를 뒷받침하는 외부 통계를 찾으십시오. 엄격한 규칙: 이 작업 중에 해당 출처 URL을 가져와서(fetch) 해당 주장이 거기에 명시된 대로 나타나는지 확인한 경우에만 주장을 사용할 수 있습니다. 1차 발행자를 선호하십시오. 모든 것을 날짜 스탬프 처리하십시오. 발행자가 숫자를 대체했는지 확인하십시오. 유리한 해석을 선택하는 대신 충돌을 기록하십시오.
  • 경쟁사 매핑. 카피가 차별화해야 하는 경쟁사 페이지를 가져오십시오(fetch). 그들의 포지셔닝, 주장, 가격, CTA, 반복 문구를 그대로 기록하십시오 — 이는 차별화를 위해서도, 4단계의 유사성 검사에서 카피가 그들을 반영하지 않음을 증명하기 위해서도 필요합니다. 경쟁사에 관한 비교 주장은 법적 노출을 수반합니다(Lanham Act — references/evidence-standards.md 참조). 정확히 인용하고 날짜 스탬프를 찍으십시오.
  • 구매자 언어. 공개 출처(채용 공고, 커뮤니티 팟캐스트/블로그, 공개 포럼)에서 구매자의 어휘를 샘플링하십시오. 비공개 커뮤니티에 대한 접근을 조작하지 마십시오. 한계를 명확히 밝히십시오.

네트워크 미작동 시 폴백: 가져올 수 없으면(fetch) 검증할 수 없습니다. 모든 외부 주장을 [검증되지 않음 — 가져올 때까지 게시 금지(UNVERIFIED — do not publish until fetched)]로 표시하고, 결과물 상단에 출처 검증이 실행되지 않았음을 명시하며, 최종 체크리스트 항목 중 출처 검증에 대한 항목을 표시하지 마십시오.

3. 작성(Write)

templates/deliverable-template.md에 초안을 작성하십시오. 제작 규칙 — 어조, 금지 어휘, 히어로 스펙, 섹션 아키텍처, 회사 단계별 증명 전략, 메타데이터 진실 — 은 references/copy-craft.md에 있습니다. 양보할 수 없는 사항:

  • 모든 사실 문장은 해당 등급(register)을 가집니다: 검증된 사실(링크 포함), 내부 제품 주장(문서 경로 포함), 예측/설계 목표(레이블 지정), 전략적 권장 사항, 또는 카피라이팅 판단. 각 섹션 후 주석이 이를 나열합니다.
  • 최상급(superlative)은 인용된 출처 자체가 사용하는 경우에만 사용합니다. 의역은 출처의 단위, 모집단, 날짜를 보존합니다.
  • 인용문은 그대로입니다. 저자의 요약을 설문 응답자에게 귀속시키는 것은 인용 표류(quote drift)이며, 인용 표류는 조작입니다.
  • 예측, 설계 목표, 로드맵 의도는 처음뿐만 아니라 모든 발생 지점에서 그렇게 레이블을 지정합니다.
  • 의도적으로 제외한 사항(검증에 실패한 통계, 대체된 숫자)은 주석에 들어갑니다. 제외 목록은 표준의 일부입니다.

4. 검증(Verify)

두 계층, 모두 필수:

  • 결정론적(Deterministic). 실행: python3 scripts/check_copy.py DELIVERABLE.md (금지 어휘 + 포함된 단어/문자 제한; 실패 시 0이 아닌 코드로 종료). 그런 다음 python3 scripts/check_copy.py DELIVERABLE.md --urls를 실행하여 사실 확인 패스에 대한 인용 워크시트를 생성합니다. --lexicon FILE로 프로젝트별 금지 용어를 추가합니다. 실행 불가 폴백: 이 환경에서 스크립트를 실행할 수 없는 경우, 금지 어휘와 템플릿의 check: 예산을 수동으로 적용하고 체크리스트에 결정론적 패스가 스크립트가 아닌 수동으로 수행되었음을 기록합니다.
  • 적대적(Adversarial). references/verification.md에 따른 독립 검토 패스: (a) 인용된 모든 URL을 다시 가져오고(re-fetch) 카피의 정확한 표현을 테스트하는 웹 사실 확인, (b) 사실 베이스에 대한 내부 충실도 검사, (c) 제약/준수 검사, (d) 회의적인 구매자 페르소나 읽기, (e) 경쟁사 유사성 검사. 모든 차단 요소를 수정하십시오. 수정 후 결정론적 검사를 다시 실행하십시오.

5. 출시(Ship)

결과물의 자체 검토 체크리스트를 정직하게 표시하십시오 — 검토자가 반증할 수 있는 체크리스트 항목은 그것이 숨기는 결함보다 더 큰 피해를 줍니다. 인계 요약에서 모든 [소유자를 위한 공개 결정(Open decision for the owner)] 항목을 표면화하십시오. 프로젝트에 청구 레지스트리나 공식 검토 게이트(법무, 브랜드, MLR 스타일)가 있는 경우, 주석과 인용 워크시트를 첨부하십시오 — 이들은 검토를 위해 구축되었습니다(references/enterprise-integration.md 참조).

철칙

개별적으로 인용 가능하며, 검토 시 번호로 인용하십시오.

  1. 추적 또는 삭제(Trace or cut). 제품 주장은 사실 베이스로 추적됩니다. 외부 주장은 이 작업에서 가져온 URL로 추적됩니다.
  2. 인용하기 전에 가져오기(Fetch before you cite). 기억에서 가져온 URL은 인용 모양을 한 검증되지 않은 주장입니다.
  3. 메커니즘은 주장입니다(Mechanism is a claim). 작동 방식 카피, 아키텍처, 통합, 성능 및 상업적 조건은 통계와 마찬가지로 출처가 필요합니다.
  4. 등급을 레이블 지정하십시오(Label the register). 검증된 사실 / 내부 주장 / 예측 / 권장 사항 / 판단 — 주석에 표시됩니다.
  5. 출처가 상한선을 설정합니다(The source sets the ceiling). 최상급 업그레이드, 단위 변경, 모집단 교체, 날짜 없는 "최근 연구"는 없습니다.
  6. 조작된 증거는 절대 출시되지 않습니다(Invented proof never ships). 고객, 사용 후기, 로고, 사례 연구, 인증, 파트너십, 메트릭, 결과. 미국에서는 가짜 사용 후기와 리뷰도 불법입니다(16 CFR Part 255 및 465).
  7. 단계 정직성은 전략입니다(Stage honesty is strategy). 아직 존재하지 않는 증거를 명확히 밝히십시오. 공개는 빌린 신뢰성보다 회의적인 구매자와의 전환율이 더 높습니다 — 그리고 실사를 견딜 수 있는 유일한 자세입니다.
  8. 미지의 것은 플래그를 지정하고 채우지 않습니다(Unknowns are flagged, not filled). 확립되지 않은 사실은 그럴듯한 카피가 아닌 소유자를 위한 공개 질문이 됩니다.

합리화 — 모두 중지를 의미합니다

변명현실
"출시 전에 확인하라는 메모를 추가하겠습니다"검증은 초안 작성보다 선행합니다. TODO는 실질증명이 아닙니다.
"유명한 보고서에서 이 통계를 기억합니다"기억은 출처가 아닙니다. 가져오거나(fetch) 삭제하십시오.
"제품이 분명히 어떻게 작동하는지 설명하는 것은 주장이 아닙니다"메커니즘 설명은 기능 주장이며, 묵시적 주장도 포함됩니다.
"구체적인 용어가 제안을 현실감 있게 만듭니다"발명된 용어는 계약이 됩니다. 공개 결정으로 플래그를 지정하십시오.
"그냥 임시 카피입니다"임시 문구는 출시됩니다. 명확하게 표시하거나 작성하지 마십시오.
"솔직함 섹션이 우리가 정직하다는 것을 증명합니다"고객에 대한 정직함이 다른 곳에서의 발명을 허가하지 않습니다.
"통계가 대략적으로 맞습니다"대략적인 방향은 주장이 아닙니다. 단위, 모집단, 날짜가 주장입니다.
"출처가 차단되었지만 2차 보도가 일치합니다"1차 출처로 제시하는 것을 중단하십시오. references/evidence-standards.md의 차단된 출처 프로토콜에 따라 재라우팅하십시오 — 검증된-2차(verified-secondary)로 재레이블하고 차단을 명시한 경우에만 사용 가능합니다.

위험 신호 — 중단하고 재기반화하십시오

  • 이번 작업에서 직접 가져오지 않은 초안의 통계
  • 사실 베이스에서 가리킬 수 없는 제품 세부 사항
  • 인용된 출처에 없는 최상급("최대", "최초", "유일한", "#1")
  • 소유자가 명시한 적 없는 상업적 용어(락인, 할인, 보장, SLA)
  • 조이거나, 병합하거나, 재귀속시킨 인용문
  • 검토자가 반증할 수 있다고 생각하면서 막 표시하려는 체크리스트 항목

참조 라우팅

읽을 문서시기
references/evidence-standards.md리서치 전; 출처 판단 시; 법적 최소 기준과 증거 함정 카탈로그 확인용
references/copy-craft.md작성 전; 어조, 금지 어휘, 히어로, 섹션 아키텍처, 단계 정직성 증명, 메타데이터 확인용
references/verification.md검증 단계 전; 적대적 검토 패널 및 수정 프로토콜 정의
references/enterprise-integration.md클라이언트에 클레임 검토, 브랜드 거버넌스 또는 규제 산업 요구사항이 있을 때

템플릿: templates/fact-base-template.md (먼저 작성), templates/deliverable-template.md (작성 대상). 스크립트: scripts/check_copy.py 실행 (컨텍스트로 읽지 마십시오. --help와 출력은 자명합니다).

이 스킬은 주장과 증거를 규율합니다. 의도적으로 회사의 브랜드 보이스 가이드를 대체하지 않습니다 — 그 아래에 계층화됩니다(references/enterprise-integration.md 참조). 그 어떤 것도 법률 자문이 아닙니다. 규제 산업은 최종 카피를 법무팀을 통해 라우팅합니다.

관련 스킬