커맨드 마케팅은 AI에게 어떤 일을 어떤 기준으로 맡길지 정하는 운영 방식이고, 오케스트레이션 에이전트는 여러 에이전트와 도구를 어떤 순서와 규칙으로 연결할지 정하는 운영 방식입니다.
- 『AI AGENT를 지휘하는 마케터』의 지시서·위험도·승인 체계는 도구 중립입니다. 도구는 그 부품 하나씩을 채웁니다.
- 지시서(R-G-C-T-O-R)는 파일로 두고 git으로 버전을 관리하면 매번 다시 설명하지 않아도 됩니다.
- 고위험 신호 7종은 예/아니오 질문 7개가 됩니다. 하나라도 예이거나 판정이 실패하면 사람에게 올립니다. 이는 1차 거름망이지 심의가 아닙니다.
- 위험도 Level과 권한 구분(초안·추천·실행 확정)을 겹치면 도구별 권한표가 나옵니다.
- 도구는 업무를 먼저 정의한 뒤에 붙입니다. 책의 21일 훈련을 하고 그 뒤 2주에 도구를 붙이는 순서를 권합니다.
커맨드 마케팅과 오케스트레이션 에이전트는 어떻게 다른가?
커맨드 마케팅은 일을 맡기는 기준을 정하고, 오케스트레이션 에이전트는 여러 에이전트와 도구를 연결하는 규칙을 정합니다. 책은 두 개념을 이렇게 나눕니다.
| 구분 | 커맨드 마케팅 | 오케스트레이션 에이전트 |
|---|---|---|
| 중심 질문 | AI에게 어떤 일을 어떤 기준으로 맡길 것인가 | 여러 에이전트와 도구를 어떤 순서와 규칙으로 연결할 것인가 |
| 산출물 | 지시서, 검수 기준표, 프롬프트 카드, 업무 설계도 | 여기에 워크플로, 상태값, 도구 연결, 승인 게이트, 로그, 모니터링이 더해진다 |
책은 의도적으로 도구 중립으로 쓰였습니다. 아래 도구 대응은 책의 개념을 TROE가 해석해 짝지은 것입니다. 책이 커맨드 마케팅을 쓰고, 도구가 오케스트레이션 쪽 부품을 채웁니다.
| 책의 부품 | 맡는 도구 | 한 줄 |
|---|---|---|
| 지시서·검수 기준·프롬프트 카드를 쓰고 고치는 곳 | Claude Code 또는 Codex | R-G-C-T-O-R을 파일로 고정하고 버전을 관리한다 |
| 워크플로를 정해진 리듬으로 돌리는 곳 | Grok Bot | 리서치·모니터링·초안을 기기가 꺼져도 돌린다 |
| 검수 기준·상태값·위험도를 싸게 판단하는 곳 | Jev | 닫힌 질문만, 신뢰도와 함께 답한다 |
| 실행 확정과 최종 승인 | 마케터 | 실행 확정 권한은 원칙적으로 사람에게 둔다 |
책의 검수 기준과 에스컬레이션 신호표는 거의 그대로 Jev의 질문 목록이 됩니다. 사람에게 던지라고 한 예/아니오 질문을 하루 수백 번 먼저 던져 주는 것이 Jev의 자리입니다. 반대로 Jev가 확신 있는 오답을 낼 수 있다는 약점은 책이 이미 경고했습니다. AI를 1차 검수자로 쓰되 최종 검수자로 착각하지 않는 것입니다.
책의 개념은 어떤 도구에 대응되는가?
대응은 아래 표 한 장으로 정리됩니다. 도구를 바꿔도 책의 구조는 그대로입니다.
| 책 개념 | Claude Code / Codex | Grok Bot | Jev |
|---|---|---|---|
| R-G-C-T-O-R 지시서 | Context는 CLAUDE.md·AGENTS.md, 나머지 다섯 칸은 skill 파일 하나로 |
시연으로 만든 skill·루틴에 지시서를 붙인다 | Review 칸을 예/아니오 질문으로 쪼갠다 |
| 지시서 버전 관리 | git이 그대로 버전 관리 | 없음 | 판정 기준에도 버전을 붙인다 |
| 위험도 Level 1~4 | 위험도별로 skill을 나눈다 | 쓰기 권한은 Level 1~2만 | 위험도 판정 자체를 질문으로 |
| 상태값 8개 | 파일 front matter의 status |
브리프의 칸 | 다음 상태 판단을 질문으로 |
| 고위험 신호 7종 | 없음 | 없음 | 7종을 질문 7개로 |
| 로그 3종(입력·승인·성과) | 커밋 기록이 입력 로그 | 루틴 실행 기록. 루틴당 20건만 남으니 외부 저장 | 판정 로그를 파일로 남긴다 |
| 성숙도 6단계 | 5~6단계의 실체 | 3단계에 가깝다 | 4단계 이상에서 붙인다 |
| 월간 점검 4축 | 점검 지시서를 실행 | 없음 | 판정 불일치율이 학습성 지표 |
R-G-C-T-O-R 지시서는 도구에서 어떻게 파일이 되는가?
지시서는 "반복 가능한 실행 문서"이므로 채팅창에 매번 붙여 넣지 않고 파일로 둡니다.
| R-G-C-T-O-R | 파일 위치 | 바뀌는 주기 |
|---|---|---|
| Context | CLAUDE.md 또는 AGENTS.md (공용이면 .agents/product-marketing.md) |
분기 |
| Role · Goal · Tool · Output · Review | skills/{업무명}/SKILL.md 하나 |
캠페인마다 |
| 버전 기록 | skill 상단 + git 커밋 메시지 | 수정할 때마다 |
책의 지시서 버전 관리 표(지시서명, 버전, 수정일, 수정 이유, 적용 캠페인, 주요 변경, 다음 검토일)는 git 커밋 하나와 1대 1로 대응합니다. Claude Code와 Codex는 같은 파일을 읽을 수 있으므로 팀 안에서 도구가 섞여도 지시서는 하나로 유지됩니다.
고위험 신호 7종은 어떻게 Jev 질문이 되는가?
책의 에스컬레이션 표 일곱 줄이 각각 예/아니오 질문 하나가 됩니다.
| 고위험 신호 | Jev 질문 | 예일 때 |
|---|---|---|
| 개인정보 포함 가능성 | 고객 이름·연락처·구매 이력·상담 원문이 들어 있는가 | 개인정보·보안 담당 |
| 효능·성과 단정 표현 | 치료·수익·합격·강제·개선을 보장하는 표현이 있는가 | 법무·업종별 심의 |
| 저작권·상표권 유사성 | 특정 브랜드·캐릭터·작가 스타일을 흉내 낸 표현이 있는가 | 법무·브랜드 책임자 |
| 경쟁사 비교·비방 | 근거 없는 1위 주장이나 경쟁사보다 우월하다는 단정이 있는가 | 법무·마케팅 리드 |
| 고객 불안 자극 | 공포·결핍·외모·건강·경제 불안을 과도하게 자극하는가 | 브랜드 책임자 |
| 대규모 발송·집행 | 대량 이메일·고예산 광고·주요 런칭인가 | 캠페인 오너 |
| 외부 이슈 가능성 | 사회적 논란·민감한 시기·특정 집단 관련 표현이 있는가 | PR·브랜드·경영진 |
판정 규칙은 세 가지입니다.
- 하나라도 "예"이면 사람에게 올립니다. 신뢰도가 높아도 내리지 않습니다.
- 판정이 실패하거나 늦어도 올립니다. 막는 쪽으로 동작합니다(fail closed).
- "아니오"여도 표본은 사람이 봅니다. AI는 위험 후보를 넓게 찾고, 사람은 근거를 확인합니다.
표현 판정은 결정 모델이 가장 약한 영역일 수 있습니다. Jev 공식 문서가 문자 그대로 읽기(literal reading)와 적대적 입력(adversarial content)을 약점으로 꼽고, 한국어 광고의 미묘한 과장은 영어 중심으로 학습된 판정기가 놓칠 수 있습니다. 이 표는 1차 거름망이며, Level 3~4 산출물은 판정과 무관하게 사람이 승인합니다. 한국어 정확도는 도입 전에 작은 표본으로 먼저 검증하세요.
위험도와 권한 구분을 겹치면 도구 권한표는 어떻게 되는가?
위험도 4단계와 권한 3구분(초안, 추천, 실행 확정)을 겹치면 도구별 권한이 바로 나옵니다.
| 위험도 | 산출물 예 | Grok Bot | Claude Code / Codex | Jev | 사람 |
|---|---|---|---|---|---|
| Level 1 내부 참고용 | 회의 아이디어, 공개 자료 요약 | 생성·저장까지 자동 | 생성·저장까지 자동 | 신선도·관련성 판정 | 가끔 표본 |
| Level 2 내부 의사결정용 | 전략 초안, 성과 리포트, 경쟁사 분석 | 초안만 | 초안 + 1차 검수 | 위험 신호 판정 | 담당자 검토 후 팀 리드 확인 |
| Level 3 외부 공개용 | SNS·블로그·뉴스레터·랜딩 문구 | 초안만, 게시 금지 | 초안 + 1차 검수 | 7종 신호 + AI 티 검사 | 브랜드·사실성·권리 검수 후 승인 |
| Level 4 고위험 공개용 | 유료 광고, CRM 개인화, 의료·금융 | 초안만, 집행·발송 금지 | 광고는 PAUSED로만 생성 | 사람 확인 고정 | 다중 승인 + 법무·개인정보 |
상태값 8개는 모든 도구가 같은 필드로 씁니다. 사람은 "이거 확인됐나요"라고 묻지 않고 상태만 봅니다.
- Draft: 도구가 만든다
- AI Reviewed: Jev와 QA skill이 검수한다
- Human Review: 사람이 본다 (수정이 필요하면 Revision Needed를 거쳐 2번으로)
- Approval Pending, Approved: 사람만 바꾼다
- Published: 공개한다
- Reviewed: 성과를 보고, 결과가 다음 지시서 v+1로 돌아간다
성숙도 6단계에는 도구를 어디에 놓는가?
책은 하네스 엔지니어링을 마지막 단계에 가깝다고 보고, 대부분의 마케팅 팀은 13단계만으로도 큰 생산성 향상을 얻는다고 말합니다. 도구도 이 순서로 붙입니다. 이 6단계는 업무 자동화를 구현하는 방식의 단계이며, 조직이 AI를 얼마나 쓰는지 보는 [조직 성숙도 L1L5](/insights/builder-level/)와는 다른 축입니다.
| 단계 | 구현 방식 | 맞는 도구 | 들어가는 조건 |
|---|---|---|---|
| 1 | 프롬프트·템플릿 수동 운영 | ChatGPT·Claude 채팅 + 지시서 | 없음 |
| 2 | 문서·스프레드시트 반자동 | 지시서·검수표를 공유 폴더에, 버전 표기 | 지시서 3개 이상 |
| 3 | 노코드·로우코드 자동화 | Grok Bot 루틴, Codex 앱 Automations | 1주 QA(모든 출력 사람 검토) 통과 |
| 4 | API·사내 도구 연결 | MCP(광고·CRM 도구 연결) | 데이터 등급·권한 정리 완료 |
| 5 | Framework·Runtime 기반 에이전트 앱 | Claude Code 또는 Codex + skills + hooks | git·리뷰 습관 |
| 6 | Harness 기반 고자율 에이전트 | Claude Code/Codex 헤드리스 + Jev 게이트 + 상시 루틴 | 로그·킬 스위치·승인 체계 |
Grok Bot은 기술적으로 6단계처럼 보이지만 사용 방식 기준으로 3단계에 놓았습니다. 다만 공유 클라우드 컴퓨터와 자격증명 공유 위험은 4단계 이상의 수준이므로, 고객 데이터가 들어가는 순간 4단계 보안 기준을 적용합니다. Grok Bot 같은 일부 도구는 베타라 기능과 정책이 바뀔 수 있습니다(2026년 10월 기준).
1인 마케터와 팀은 에이전트를 어떻게 배치하는가?
책은 1인 마케터에게 5개 에이전트(주간 리서치, 콘텐츠, 광고 소재, 리포팅, QA)로 시작하라고 권합니다.
| 에이전트 | 사용 빈도 | 맡길 도구 | Jev가 판정할 것 | 사람이 볼 것 |
|---|---|---|---|---|
| 주간 리서치 | 주 1회 | Grok Bot 주간 루틴 | 관련성·신선도 | 출처와 해석 |
| 콘텐츠 | 주 2~3회 | Claude Code 또는 Codex skill | AI 티·금지 표현 | 브랜드 톤·사실관계 |
| 광고 소재 | 주 1회 | Codex(광고 MCP, PAUSED 생성) | 과장 표현·랜딩 연결성 | 과장·랜딩 연결 |
| 리포팅 | 주 1회 | Codex·Claude Code 예약 실행 | 이상치 여부 | 지표 정의·원인 가설 |
| QA | 공개 전마다 | Jev 게이트 + QA skill | 7종 위험 신호 | 최종 공개 승인 |
책의 요일 리듬(월 리서치, 화 콘텐츠, 수 광고 소재, 금 리포팅, 공개 전 QA)은 그대로 두고, 월요일 리서치가 일요일 밤에 이미 끝나 있게 한다는 점만 달라집니다. 3개월 뒤에는 CRM(리드 트리아지)과 실험 관리 에이전트를 더합니다.
어떤 순서로 도입하면 되는가?
책의 21일 훈련을 그대로 하고, 그 뒤 2주에 도구를 붙입니다. 순서는 바꾸지 않습니다.
| 기간 | 할 일 | 도구 | 산출물 |
|---|---|---|---|
| 1주차 (책) | 업무 관찰·분해, 에이전트 후보 5개 | Claude Code·Codex가 나를 인터뷰해 업무 로그 정리를 돕는다 | 업무 관찰 로그, 병목 지도, 후보 목록 |
| 2주차 (책) | 지시서 2개 작성, 산출물 생성 | 지시서를 skill 파일로 저장하고 git으로 버전 관리 | 지시서 v1, 수정 로그 |
| 3주차 (책) | 프롬프트 카드·입력 체크리스트·검수표 | 검수표의 예/아니오 항목을 따로 표시 | 프롬프트 라이브러리 v1, 월간 점검표 |
| 4주차 (추가) | Level 1~2 업무 하나를 주간 루틴으로 | Grok Bot, 첫 주는 모든 출력 사람 검토 | 루틴 1개 |
| 5주차 (추가) | 검수표 항목 하나를 Jev로 옮겨 shadow 1주 | Jev | 불일치 로그 |
5주 뒤 첫 월간 점검에서는 책의 4축에 도구 지표를 더합니다.
| 책의 축 | 도구로 재는 것 |
|---|---|
| 사용성 | 루틴 실행 횟수, skill 호출 횟수 |
| 품질 | 승인 통과율, 사람 수정 횟수 |
| 안전성 | 사람에게 올라간 비율, QA 지적 건수, "Could not read" 건수 |
| 학습성 | 지시서·판정 기준의 버전 업 횟수, shadow 불일치율 추이 |
일반 조직의 AX에는 어떻게 쓰는가?
위험도, 승인 상태, 에스컬레이션, 월간 점검은 마케팅에만 쓰는 장치가 아닙니다. 어떤 부서든 AI 업무에 "사람이 반드시 판단할 구간"과 "반복 부담이 큰 구간"이 있기 때문입니다. TROE는 부서 단위로 아래 순서를 권합니다.
- 업무 하나를 정의합니다. 반복되고, 기준이 명확하고, 사람이 검토할 수 있는 업무를 고릅니다.
- 위험도와 승인 상태를 표시합니다. 산출물이 내부용인지 외부 공개용인지에 따라 사람 승인 구간을 정합니다.
- 지시서와 검수표를 파일로 남깁니다. 담당자가 바뀌어도 업무가 멈추지 않습니다.
- 월간으로 점검합니다. 사용성, 품질, 안전성, 학습성을 같은 표로 봅니다.
이 구조는 AX WORKS의 Blueprint가 H(사람 필수)와 P(개선 대상)를 먼저 표시하는 방식과 같은 원리이고, Operate가 운영 기준·정기 점검·내부 이관을 맡는 단계와 이어집니다.
우리 팀에 적용하려면 어디서 시작하는가?
도구보다 업무를 먼저 정의하는 것이 출발점입니다. 3분 진단으로 현재 위치를 확인하세요. 이메일 없이 결과를 볼 수 있습니다. 첫 업무 하나를 정해 가동까지 가려면 Sprint 90을, 팀이 같은 언어로 지시서와 승인 체계를 쓰게 하려면 Academy를 참고하세요. 우리 조직에 맞춘 승인 체계와 도구 설계가 필요하면 문의를 남겨 주세요. 원리를 먼저 읽고 싶다면 『AI AGENT를 지휘하는 마케터』가 있습니다.
근거와 출처
- 『AI AGENT를 지휘하는 마케터』 — 박충효, 2026. 지시서, 위험도 4단계, 상태값, 성숙도 6단계, 승인 체계의 원 개념
- 커맨드 마케팅 × 에이전트 도구 매핑 리서치 — TROE, 2026. 책 개념과 도구의 짝짓기는 TROE의 해석. 2026년 10월 기준이며 일부 도구는 베타
자주 묻는 질문
커맨드 마케팅이란 무엇인가요?
AI에게 어떤 일을 어떤 기준으로 맡길지 정하는 방식입니다. 산출물은 지시서, 검수 기준표, 프롬프트 카드, 업무 설계도입니다.
도구를 먼저 도입하고 업무는 나중에 정의해도 되나요?
권하지 않습니다. 책의 원칙은 도구를 바꾸기 전에 업무를 먼저 정의하는 것입니다. 지시서 2개를 쓰고 검수표를 만든 뒤에 도구를 붙입니다.
결정 모델(Jev)이 위험을 판정해 주면 법무 검토를 줄여도 되나요?
아니요. 판정은 1차 거름망입니다. 외부 공개용(Level 3)과 고위험(Level 4) 산출물은 판정 결과와 무관하게 사람이 승인합니다.
Grok Bot은 6단계 고자율 자동화인가요?
기술적으로는 클라우드 컴퓨터를 쓰는 고자율 Bot이지만, 사용 방식(시연으로 루틴을 만들고 결과만 받는다)은 3단계 노코드에 가깝습니다. 고객 데이터가 들어가면 4단계 수준의 보안 기준을 적용합니다.