# 마케터 개인 OS 가이드: 반복은 맡기고 승인은 사람이 하는 법

- URL: https://troe.kr/insights/marketer-personal-os-guide/
- 작성: 박충효 (TROE)
- 게시: 2026-10-25
- 분류: AI 마케팅

> **한 줄 정의** 마케터 개인 OS는 반복 업무를 맥락 파일·스킬·루틴으로 고정해 에이전트가 돌리고, 사람은 검토 큐에 올라온 판단과 승인만 맡도록 만든 개인 업무 운영 체계입니다.

## 핵심 요약

- 개인 OS는 맥락, 스킬, 루틴, 결정 게이트, 검토 큐, 실패 기록의 여섯 층으로 반복을 고정합니다. 프롬프트로 매번 시키는 방식과 달리 결과가 매번 같은 형식으로 나옵니다.
- 만드는 도구, 돌리는 도구, 정하는 도구, 승인하는 사람의 네 역할을 나눕니다. 공개·지출·발송·삭제는 항상 사람이 합니다.
- 공개된 사례의 통제 규칙은 그대로 가져다 쓸 수 있습니다. 광고는 PAUSED로만 만들고, 경쟁사 모니터링은 읽기 전용으로 두고, 판단이 불확실하면 사람에게 올립니다.
- 4주 순서는 맥락, 스킬 하나, 루틴, 게이트 하나입니다. 쓰기 권한은 4주 안에 열지 않습니다.

## 마케터 개인 OS란 무엇이고 왜 필요한가?

개인 OS는 마케터의 반복을 사람의 기억이 아니라 파일로 고정한 운영 체계입니다. 마케터의 하루는 판단 몇 개와 반복 수십 개로 이루어집니다. 경쟁사 페이지를 다시 읽고, 멘션을 훑고, 리드를 거르고, 성과 표를 채웁니다. 이 반복을 프롬프트로 매번 시키면 결과가 매번 다르고, 시키는 시간도 그대로 남습니다.

개인 OS는 반복을 **파일·스킬·루틴**으로 고정하고, 사람은 검토 큐에 올라온 것만 판단하게 만듭니다. 공개 사례로는 Reyes Brusola가 코딩 없이 Claude Code로 12개 에이전트, 82개 스킬, 28개 파이프라인을 만들어 고객 4곳을 운영했고 "리서치·작성·조립에 쓰던 날들을 되찾았다"고 썼습니다. 이 수치는 본인 보고입니다.

> 세 도구(Jev, Claude Code 또는 Codex, Grok Bot)를 한 사람이 모두 쓴 문서화 사례는 아직 확인하지 못했습니다. 아래 사례는 각각 한두 도구만 씁니다. 이 글의 하루·주 리듬은 사례를 묶은 TROE의 설계입니다.

## 개인 OS에서는 누가 무엇을 맡는가?

네 역할로 나눕니다. 만드는 쪽, 돌리는 쪽, 정하는 쪽, 승인하는 쪽입니다.

| 역할 | 맡는 쪽 | 하는 일 |
|---|---|---|
| 만드는 쪽 | Claude Code 또는 Codex | 맥락 파일, 스킬, 게이트 기준을 쓴다 |
| 돌리는 쪽 | Grok Bot | 클라우드 컴퓨터에서 정해진 리듬으로 돌린다. 기기를 꺼도 돈다 |
| 정하는 쪽 | Jev (TypeSafe AI의 결정 모델) | 보낼까, 버릴까, 누구에게 같은 닫힌 질문에만 답한다 |
| 승인하는 쪽 | 마케터 | 공개·지출·발송·삭제는 무조건 사람이 한다 |

여섯 층은 맥락 파일, 스킬, 루틴, 결정 게이트, 검토 큐, 실패 기록입니다. Claude Code의 `CLAUDE.md`와 `claude -p`, Codex의 `AGENTS.md`와 `codex exec`는 같은 자리에 들어가는 부품이므로, 이미 쓰는 쪽을 고르면 됩니다.

## 공개된 사례에서는 어떤 업무를 맡겼는가?

매일 아침, 매일, 매주의 리듬으로 나눠 보면 맡길 업무가 보입니다.

| 시점 | 사례 | 도구 | 사람이 하는 일 | 보고된 결과 | 근거 |
|---|---|---|---|---|---|
| 매일 아침 | 출근 전 블로그 초안 (Reyes Brusola) | Claude Code 배경 실행 | review 폴더에서 승인 | 리서치·초안·키워드 점검이 출근 전에 완료. 수치 없음 | 본인 보고 |
| 매일 | 광고 성과 점검 (Adspirer) | Codex + MCP + 스킬 5종 | 캠페인 생성·예산 변경 전 확인 | CPA 30% 상승, 전환 없이 지출 50% 증가, CTR 1% 미만이면 플래그. 절감 수치 없음 | 벤더 |
| 매주 | 경쟁사 브리프 (Market Researcher) | Grok Bot 주간 루틴 | "Worth a decision" 최대 3건 판단 | 수동 2~4시간이 걸리던 주제를 검토 약 20분으로 (Metaflow 추정) | 공식 문서 + 벤더 추정 |
| 매주 | 리드 신호 트리아지 (Salesforge) | Grok Bot + Jev | low confidence·unclear는 사람 큐 | 신호가 없을 때 20건 전부 nurture, 6개월 신호를 더하자 4·4·12로 분류. 답장 분류는 24건 중 22건 일치 | 원문 확인 |
| 상시 | 콘텐츠 재가공 (Metaflow·MindStudio) | Grok Bot | 게시 승인 | 고객당 주 4~8시간 절감 | 자기 보고 |

절감 시간은 모두 자기 보고 또는 벤더 추정입니다. 수치가 가장 믿을 만한 사례는 Salesforge의 리드 트리아지 하나입니다. 저자가 실패(첫 20건 전부 nurture)와 한계(가상 답장으로 테스트, 작은 표본)를 스스로 밝혔기 때문입니다.

## 리드 트리아지 사례에서 무엇을 배우는가?

결정 모델은 받은 정보만큼만 판단합니다. Salesforge의 첫 실행에서 20건이 전부 nurture로 나온 이유는 모델이 아니라 **입력에 구매 신호가 없었기** 때문입니다. 그래서 게이트를 만들기 전에 "이 판단에 필요한 신호가 입력에 들어가는가"부터 확인합니다.

기준은 한 번에 맞지 않습니다. Every가 정리한 순서는 이렇습니다.

1. 에이전트가 경계 사례를 섞어 나를 인터뷰한다.
2. "관련 있음" 같은 주관어를 예/아니오 질문 여러 개로 쪼갠다.
3. 내가 이미 판정한 작은 표본으로 시험한다.

Jack Cheng의 첫 긴급도 필터는 뉴스레터를 긴급으로 분류했습니다. 시험하고 고치는 과정을 계획에 넣어야 합니다.

## 하루와 한 주는 어떻게 돌아가는가?

아래는 위 사례를 한 사람의 리듬으로 묶은 TROE의 설계안입니다.

| 시각 | 무엇이 도나 | 도구 | 마케터가 하는 일 |
|---|---|---|---|
| 06:00 | 경쟁사·멘션·업계 뉴스 수집, 관련성 판정, 아침 브리프 | Grok Bot 루틴 + Jev | 없음 |
| 09:00 | 브리프와 "결정할 것 3건" 읽기 | 없음 | 10분 |
| 09:10 | 맥락 파일 기반 콘텐츠 초안 생성, AI 티 검사 | Claude Code 또는 Codex | 초안 검토·수정 |
| 매일 | 광고 성과 점검, 플래그만 보고 | Codex 또는 Grok Bot | 플래그 건만 판단 |
| 월요일 | 경쟁사 주간 브리프, 리드 신호 트리아지 | Grok Bot + Jev | contact now 목록 확인, 발송 승인 |
| 금요일 | 실패·불일치 기록 정리, 기준 수정 | Claude Code 또는 Codex | 15분 |

## 반드시 지켜야 할 통제 규칙은 무엇인가?

공개 사례 원문에서 가져온 일곱 가지입니다. 벤더 글이라도 통제 규칙은 그대로 쓸 수 있습니다.

| # | 규칙 | 사례 |
|---|---|---|
| 1 | 광고·캠페인은 **PAUSED 상태로만** 만든다. 실패한 생성은 재시도하지 않고 보고한다 | Adspirer |
| 2 | 경쟁사 모니터링은 **읽기 전용**이다. 팔로·좋아요·답글·DM, 경쟁사 광고 클릭을 하지 않는다 | Market Researcher |
| 3 | 못 읽은 출처는 지어내지 않고 **"Could not read"** 칸에 적는다. 모든 주장에 링크·날짜·스크린샷을 붙인다 | Market Researcher |
| 4 | **다른 Bot의 승인은 내 승인이 아니다.** 공개·지출·발송은 사용자 본인만 승인한다 | Market Researcher |
| 5 | 판정이 **low confidence·unclear**이면 자동 실행하지 않고 사람 큐로 보낸다 | Salesforge |
| 6 | 수신거부·부정 답장은 결정 모델과 무관하게 **코드 규칙으로** 즉시 중단한다 | Salesforge |
| 7 | AI 품질 검사가 작업을 조용히 끝내게 두지 않는다. 판정이 흔들리면 **결정적 스크립트**로 바꾸고, 산출물은 개수로 센다 | Reyes Brusola |

결정 게이트 자체에는 별도 통제를 둡니다. 처음 1주는 결과를 실행하지 않고 기록만 하는 shadow 모드로 돌리고, 사람 확인(`ask_human`)을 기본값으로 고정하고, 판정이 실패하면 막는 쪽(fail closed)으로 동작시키고, 언제든 끌 수 있는 킬 스위치를 둡니다.

## 고객사나 팀이 여러 곳이면 어떻게 분리하는가?

Grok Bot은 계정 하나에 클라우드 컴퓨터 하나이고 모든 Bot이 같은 파일·세션·로그인을 봅니다. 고객사가 여러 곳인 컨설턴트와 에이전시에게 가장 실무적인 위험입니다. Metaflow가 제시한 분리는 세 층입니다.

| 층 | 방법 |
|---|---|
| 권한 | 고객별 Bot에는 그 고객 도구의 자격증명만 준다. 공용 로그인을 쓰지 않는다 |
| 이름 | Bot 이름에 고객 접두어를 붙인다(예: `Acme-Market-Researcher`). 같은 계정의 Bot끼리 메시지를 주고받기 때문이다 |
| 루틴 | 루틴 이름에 고객 식별자를 넣고, 첫 단계에서 "현재 작업 고객"을 확인한다 |

| 고객 유형 | 분리 수준 |
|---|---|
| 민감도 낮음 | 공유 Bot + 접두어 이름 |
| 민감도 중간 | 고객별 Bot + 전용 로그인 |
| 규제·NDA | 고객별 계정 분리 (2026년 10월 기준 엔터프라이즈 대기 명단) |

고객 기밀이 들어가는 세션은 도구의 데이터 보존 정책을 먼저 확인합니다. 내부 조직에서는 "고객"을 "부서"로 바꿔 같은 표를 쓰면 됩니다.

## 4주 구축 순서는 어떻게 되는가?

쓰기 권한은 4주 안에 열지 않습니다. 이력이 쌓인 뒤 하나씩 엽니다.

| 주차 | 할 일 | 끝났다는 기준 |
|---|---|---|
| 1 · 맥락 | 브랜드·타깃·KPI·톤을 맥락 파일 하나에 쓴다(`CLAUDE.md` 또는 `AGENTS.md`) | 에이전트가 "우리 타깃이 누구냐"에 파일 근거로 답한다 |
| 2 · 스킬 하나 | 매주 하는 반복 업무 하나를 스킬로 만든다. 경쟁사 브리프나 성과 점검이 무난하다 | 같은 입력에 같은 형식의 결과가 3회 나온다 |
| 3 · 루틴 | Grok Bot에 시연하거나 기존 Bot을 가져와 주간 루틴으로 돌린다. 첫 주는 모든 출력을 사람이 검토한다 | 1주 무사고, "Could not read" 칸이 정직하게 채워진다 |
| 4 · 게이트 | 루틴 안의 닫힌 질문 하나만 Jev로 옮겨 shadow로 돌린다. 기준은 Claude Code·Codex가 인터뷰해서 쓴다 | 불일치 로그 1주치와 완료 작업당 비용 비교 |

## 일반 조직에서는 어떻게 적용하는가?

마케팅 팀이 아니어도 구조는 같습니다. 여섯 층과 통제 규칙은 마케팅 지식이 아니라 "반복을 고정하고 승인을 사람에게 남기는" 방법이기 때문입니다. TROE는 개인에서 팀으로 키우는 순서를 이렇게 권합니다.

1. **개인 1업무**: 한 사람이 반복 업무 하나를 위 4주 순서로 가동합니다.
2. **팀 공통 기준**: 맥락 파일과 지시서를 팀이 함께 쓰고 버전을 관리합니다. 승인 담당과 책임(RACI)을 정합니다.
3. **조직 운영 체계**: 승인 기록, 월간 점검, 중단 규칙을 조직 표준으로 올립니다.

이 과정은 [Builder Level](https://troe.kr/insights/builder-level/)의 B2 조립자와 B3 오케스트레이터를 실제 업무로 훈련하는 길이기도 합니다. AX WORKS의 [Blueprint](https://troe.kr/ax/blueprint/)는 사람이 반드시 판단할 구간(H)과 반복 부담이 큰 구간(P)을 먼저 표시해 어떤 업무부터 맡길지 정합니다.

## 우리 팀에 적용하려면 어디서 시작하는가?

먼저 우리 팀이 어느 단계에 있는지 확인하세요. [3분 진단](https://troe.kr/ax/diagnose/)은 이메일 없이 결과를 볼 수 있습니다. 첫 업무 하나를 4주 안에 가동하고 싶다면 [Sprint 90](https://troe.kr/ax/sprint-90/)과 [Blueprint](https://troe.kr/ax/blueprint/)를, 팀이 같은 언어로 쓰게 하려면 [Academy](https://troe.kr/ax/academy/)를 참고하세요. 업무에 맞춘 설계가 필요하면 [문의](https://troe.kr/contact/)를 남겨 주세요. 책의 원리가 궁금하다면 [『AI AGENT를 지휘하는 마케터』](https://troe.kr/books/)에서 이어 읽을 수 있습니다.

## 근거와 출처

1. 마케터 개인 OS 에이전트 오케스트레이션 사례 리서치 — TROE, 2026. 2026년 10월 기준 공개 사례 조사. 사례별 저자·벤더와 증거 등급은 본문에 표기
2. Jev·Claude Code·Grok Bot 도구 리서치 — TROE, 2026. 도구별 역할과 통제 방법. 일부 도구는 베타라 기능과 정책이 바뀔 수 있음

## 자주 묻는 질문

### 개인 OS를 만들려면 코딩을 알아야 하나요?

코딩 없이 만들었다는 공개 사례가 있습니다(본인 보고). 다만 맥락 파일을 쓰고, 결과를 검토하고, 승인 규칙을 정하는 습관은 필요합니다.

### Claude Code와 Codex 중 무엇을 고르면 되나요?

이미 쓰고 있는 쪽을 고르면 됩니다. Claude Code의 CLAUDE.md와 Codex의 AGENTS.md는 같은 자리에 들어가는 부품입니다.

### 에이전트가 광고나 메일을 직접 집행해도 되나요?

아니요. 공개, 지출, 발송, 삭제는 사람이 승인합니다. 광고는 PAUSED 상태로만 만들고, 실패한 생성은 재시도하지 않고 보고하게 합니다.

### 고객사 자료를 넣어도 되나요?

고객별로 권한, 이름, 루틴을 분리하고, 기밀이 들어가는 세션은 도구의 데이터 보존 정책을 먼저 확인해야 합니다.
