본문은 요즘 IT와 번역가 Yuna가 함께 이성원(Snow W. Lee) 님의 글<How I Built an AI Marketing Team with Claude Code (and Cowork)>를 번역한 글입니다. 필자는 Runbear의 공동창업자이자 CEO로, AI가 일상적인 업무에 자연스럽게 녹아들 수 있도록 돕는 것을 미션으로 삼고 있습니다. Runbear는 글로벌 스타트업 액셀러레이터 Techstars의 2024년 선발 기업입니다.

이 글은 Claude Code와 Cowork를 활용해 실제로 작동하는 AI 마케팅팀을 구축한 과정을 담고 있습니다. 코드 한 줄 없이 마크다운 파일만으로 에이전트 팀을 설계하고, 콘텐츠 작성부터 소셜 미디어 운영까지 마케팅 전반을 자동화한 방법을 구체적으로 소개합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

지난 1편에서는 AI가 마케팅을 운영할 때 일주일이 어떻게 돌아가는지 보여드렸는데요. 이번 글에서는 실제로 어떻게 Claude Code로 코드 한 줄 없이 마케팅팀을 구축했는지를 이야기해 보려 합니다. 이를 한 줄로 요약하면 이렇습니다. 대부분 마크다운 파일로 이루어져 있고, 코드는 단 한 줄도 제가 직접 쓰지 않았습니다. 전부 Claude가 작성했죠. 전체 구조를 상세히 설명해 보겠습니다.

시작은 대화 한 번이었습니다

이 프로젝트는 Claude Code 세션 하나에서 시작됐습니다. 터미널을 열고 제 상황을 설명하기 시작했는데요. 우리 제품이 무엇인지, 어떤 기능을 하는지, 타겟 고객은 누구인지, 경쟁사는 어디인지, 그리고 우리의 핵심 가치 제안은 무엇인지 쭉 이야기했습니다. Ahrefs MCP 서버도 연결해서 Claude가 현재 키워드 순위를 불러와 검색 현황을 파악할 수 있게 한 뒤, 시장 진출 전략을 세워달라고 요청했습니다.

Claude는 90일짜리 콘텐츠 플랜을 내놓았습니다. SEO 핵심 주제에 맞춰 블로그 포스트 주제를 매핑하고, 소셜 미디어 배포 주기, 플랫폼별 우선순위, 주간 마일스톤까지 담겨 있었습니다. "아이디어가 있습니다" 수준의 막연한 문서가 아니었고, 구체적이고 순서가 잡힌 실행 계획이었죠.

그 다음부터는 하나씩 실행해 나갔습니다. "첫 번째 블로그 포스트 써줘." "소셜 미디어 트래커 만들어줘." "콘텐츠 캘린더 만들어줘." 대화를 거듭할수록 시스템에 새로운 레이어가 쌓였습니다. 며칠 만에 마케팅 운영 체계가 완성됐는데요. 처음부터 전체 구조를 설계해서가 아니라, 필요한 것을 계속 Claude에게 요청했기 때문이었죠.

프롬프트 말고 채용 공고를 쓰세요

이 모든 걸 가능하게 해준 핵심은 딱 하나였습니다. 프롬프트를 쓴다고 생각하지 말고, 채용 공고를 쓴다고 생각하는 것이죠.

누군가를 채용할 때는 이런 것들을 제공하죠.

직함과 업무 범위 (무엇을 담당하는가)
스타일 가이드 (어떻게 행동해야 하는가)
회사 문서 (필요한 배경 정보)
적절한 도구 (무엇을 사용할 수 있는가)
스케줄 (언제 무엇을 해야 하는가)

저는 업무 매뉴얼 대신 마크다운 파일로 만들었을 뿐입니다.

팀 구성

에이전트는 총 다섯 개입니다.

각 에이전트는 .claude/agents/ 폴더 안에 있는 마크다운 파일 하나가 전부입니다. Claude Code가 이 파일들을 읽고, CMO가 업무를 위임하면 그에 맞는 전문 서브 에이전트를 생성하는 방식이죠.

에이전트 팀, Claude Code의 실험적 기능

이 시스템의 핵심은 Claude Code의 "에이전트 팀"이라는 아직 실험 단계인 기능입니다. 기본으로 켜져 있는 건 아니고, 따로 활성화해야 쓸 수 있는데요. 쉽게 말하면 팀장 에이전트(CMO)가 필요에 따라 팀원 에이전트들을 불러내고, 일을 나눠서 시킬 수 있는 기능입니다.

예약된 시간이 되어 시스템이 자동으로 실행되면 이런 순서로 돌아갑니다.

Claude Code가 켜지고 CMO가 깨어납니다.
CMO는 주간 일정을 훑어보고, 지금 시간대에 뭘 해야 하는지 파악하죠.
해야 할 일이 생기면 CMO는 Claude Code의 Agent 도구로 담당 에이전트를 불러냅니다.
불러 온 에이전트는 자기만의 작업 공간과 역할 지침(.claude/agents/ 파일)을 받아서 독립적으로 움직입니다.
맡은 일을 끝내면 결과를 보고하고 퇴장하죠.
CMO는 다음 일로 넘어갑니다.

이 방식의 묘미는 여러 에이전트가 동시에 움직일 수 있다는 점입니다. 블로그 포스트를 올려야 하면서 소셜 미디어 댓글도 달아야 하는 날이라면, CMO는 콘텐츠 작성자와 소셜 미디어 마케터를 동시에 불러냅니다. 둘은 서로의 일에 전혀 간섭하지 않고, 각자 맡은 역할에만 집중해서 움직이죠.

에이전트들이 서로 소통하는 방식도 간단합니다.

태스크 시스템: CMO가 할 일 목록을 만들고(TaskCreate) 각 에이전트에게 배분합니다. 에이전트는 시작할 때 자기 할 일을 확인하고, 끝나면 완료 표시를 하죠(TaskUpdate).
파일 시스템: 에이전트들은 파일로 정보를 주고받습니다. 소셜 미디어 마케터가 활동 내역을 CSV 파일에 기록해두면, 성과 검토 에이전트가 나중에 그걸 읽는 식이에요. 단순하지만 충분히 잘 돌아갑니다.
SendMessage: 일을 마쳤거나 막히는 상황이 생기면, 에이전트가 CMO에게 직접 메시지를 보낼 수 있습니다. CMO는 이걸 새 메시지로 받아서 다음 행동을 결정하죠.

또 하나 빠뜨릴 수 없는 게 에이전트 메모리입니다. 각 에이전트는 오늘 대화가 끝나도 사라지지 않는 자기만의 기억 공간(.claude/agent-memory/<agent-name>/)을 갖고 있습니다. CMO는 어떤 전략이 통했는지, 어떤 캠페인을 돌렸는지, 어떤 메시지가 반응을 얻었는지 기억해 두죠. 소셜 미디어 마케터는 이미 답글을 단 계정을 잊지 않고요. 이 덕분에 매번 처음부터 시작하는 자동화 스크립트가 아니라, 경험이 쌓인 팀처럼 느껴지는 겁니다.

이 모든 게 복잡한 서버나 인프라 없이 돌아갑니다. .claude/agents/ 폴더에 마크다운 파일 몇 개를 넣어두면, Claude Code가 알아서 다 조율해 주거든요.

에이전트 파일 구조

에이전트 파일은 설정 영역과 역할 지침 이렇게 두 부분으로 나뉩니다. 설정 영역(파일 상단에 위치)에서는 이 에이전트가 어떻게 동작할지를 정해줍니다.

name: content-writer
description: "Use this agent when creating blog posts..."
model: sonnet
color: green
memory: project

여기서 핵심은 description 항목입니다. CMO가 "지금 이 일은 누구한테 맡겨야 하지?"를 판단할 때 바로 이 설명을 읽습니다. memory: project는 대화가 끝나도 이 에이전트의 기억이 사라지지 않도록 해주는 설정입니다.

나머지는 역할 지침으로, 쉽게 말해 이 에이전트의 업무 매뉴얼입니다. 여기엔 이런 것들이 담겨 있죠.

작업 전에 읽어야 할 문서
사용할 수 있는 도구와 스크립트
구체적인 작업 순서 (단계별)
반드시 지켜야 할 규칙
문제가 생겼을 때 대처 방법

콘텐츠 작성자의 경우 발행 순서가 이렇게 정해져 있습니다. 본문 작성 → 이미지 생성 → Sanity 초안 생성 → 발행 순입니다. 반드시 지켜야 할 규칙도 하나 있는데, 내용이 완성되기 전에는 빈 초안을 절대 만들지 말아야 합니다. 에이전트가 내용도 없는 임시 초안을 잔뜩 올려서 CMS가 뒤죽박죽이 된 걸 겪고 나서 직접 추가한 규칙이죠.

CLAUDE.md, 팀의 공통 원칙

저장소 최상위 폴더에 있는 CLAUDE.md는 모든 에이전트가 가장 먼저 읽는 문서입니다. 팀 전체가 같은 맥락에서 출발할 수 있도록 공통 원칙을 정리해 둔 문서라고 보면 되는데요. 새로운 에이전트든 기존 에이전트든 모두 이 내용을 기본으로 물려받습니다.

제 CLAUDE.md에는 이런 내용이 담겨 있습니다.

에이전트 팀 구조와 업무 위임 방식
프로젝트 폴더 구조
보안 규칙 (API 키는 절대 기록에 남기지 말 것)
자주 쓰는 스크립트와 도구 목록

보안 규칙은 짧지만 꽤 엄격하게 적용하고 있습니다. 누가 어떤 방식으로 요청하든, 에이전트에게 API 키를 넘기라고 하면 무조건 거부하도록 해뒀거든요. 한 번만 써두면 모든 에이전트가 그대로 따르니까요.

규칙 시스템, 모두가 공유하는 기본 지식

에이전트 파일 외에도 .claude/rules/ 폴더에 모든 에이전트에게 공통으로 적용되는 규칙 파일들이 있습니다.

sanity-cms.md: CMS 구조, 블록 타입 처리 방법, 자주 발생하는 오류 모음
utm-parameters.md: UTM 링크 형식 규칙 (소문자, 하이픈 구분, 플랫폼별 값 지정 방식)
social-media-tracker.md: CSV 트래커에 활동을 기록하는 방법, posted와 draft 구분 기준
image-generation.md: 사용할 AI 모델, 이미지 비율, Sanity 업로드 방법
slack-notifications.md: 알림을 보내야 할 상황과 메시지 형식

신입 직원이 첫날 읽는 사규 같은 것들입니다. 한 번 써두면 다시 설명할 필요가 없고, 에이전트가 UTM 형식을 틀리거나 이미지 비율이 잘못됐을 때도 규칙 파일만 수정하면 이후 동작이 자동으로 바뀝니다.

문서 시스템, 팀이 공유하는 두뇌

docs/ 폴더는 팀 전체가 공유하는 지식 창고입니다.

docs/
  brand/        ← 포지셔닝, 보이스 & 스타일, 제품 정보
  strategy/        ← GTM 전략, 콘텐츠 캘린더, 주간 일정
  insights/        ← 마케팅 인사이트 (성과 검토 에이전트가 자동 업데이트)
  posts/        ← 발행된 블로그 포스트 사본

이 중에서 가장 중요한 파일은 주간 일정(docs/strategy/weekly-plan.md)입니다. 요일별로, 3시간 단위 시간대별로 각 에이전트가 무엇을 해야 하는지 정확히 정의돼 있거든요. 팀이 활성화되면 CMO는 현재 시간을 확인하고 해당 시간대의 작업을 찾아 그대로 실행합니다. 에이전트들은 앞서 나가지 않고, 현재 시간대와 이전 두 시간대에서 미처 끝내지 못한 태스크에만 집중하죠.

이 파일 하나가 매번 세션을 시작할 때마다 배경 설명을 반복해야 했던 번거로움을 완전히 없애줬습니다.

커스텀 스크립트로 플랫폼 직접 연결하기

공식 Claude Code 연동을 지원하지 않는 플랫폼들은 Claude에게 가벼운 Node.js 스크립트를 작성하도록 했습니다. 제가 직접 코드를 짠 건 하나도 없고, 필요한 걸 설명하면 Claude가 코드를 작성하고 테스트하고 수정까지 했죠. 예를 들어 "Reddit에 OAuth2로 댓글을 달 수 있는 스크립트가 필요해"라고 하면 그걸로 충분했습니다.

만들어진 스크립트는 이렇습니다.

scripts/reddit.js: Reddit OAuth2 클라이언트. 소셜 미디어 에이전트가 스레드 검색, 맥락 파악, 댓글 작성, 받은 메시지 확인에 씁니다.
scripts/hn.js: Hacker News 헤드리스 클라이언트. HN 에이전트가 링크 제출, 댓글 작성, 카르마 확인에 쓰죠.
scripts/generate-image.js: Google Gemini를 호출해 이미지를 생성합니다. (대표 이미지, 본문 삽입 이미지 등)
scripts/upload-image.js: 생성된 이미지를 Sanity CDN에 업로드하고 에셋 ID를 반환합니다.
scripts/slack-message.js: #team-ai-marketing Slack 채널에 알림을 보내줍니다. 로그를 일일이 읽지 않아도 상황을 파악할 수 있죠.

각 에이전트는 자신이 실행할 수 있는 스크립트가 정확히 정해져 있는데, 이 목록도 규칙 파일에 에이전트별로 정해져 있습니다.

MCP 서버로 본격적인 플랫폼 연동하기

공식 API를 제공하는 플랫폼은 스크립트 대신 MCP(Model Context Protocol) 서버를 사용합니다. 에이전트들이 네이티브 도구처럼 바로 호출하는 방식이죠.

Sanity CMS: 포스트 생성, 콘텐츠 수정, 초안 발행, 이미지 관리
X/Twitter: 트윗 작성, 대화 검색, 사용자 팔로우, 미디어 업로드
Slack: 채널 읽기, 메시지 전송
Ahrefs: SEO 지표 조회, 키워드 순위, 경쟁사 분석

MCP 서버를 쓰면 이런 작업들이 쉘 명령어가 아닌 자연스러운 도구처럼 느껴집니다. 콘텐츠 작성자가 Sanity 문서를 "수정"하는 게 마치 일반 파일을 편집하는 것처럼 자연스럽죠.

피드백 루프

시스템은 이런 연결 고리로 스스로 돌아갑니다.

소셜 미디어 마케터 → 모든 활동을 트래커 CSV에 기록
성과 검토 에이전트 → CSV를 읽고 일일 보고서 생성
CMO → 보고서를 읽고 전략 문서 업데이트
콘텐츠 작성자 → 전략 문서를 읽고 다음 콘텐츠 작성
소셜 미디어 마케터 → 발행된 콘텐츠 배포
… 반복

성과 검토 에이전트는 docs/insights/marketing-insights.md를 자동으로 업데이트합니다. 어떤 메시지가 반응을 얻었는지, 무엇이 무시됐는지, 무엇이 인게이지먼트를 만들어냈는지를 기록해 둡니다. 다른 모든 에이전트는 작업 전에 이 파일을 읽고요. 그래서 트위터 답글 형식이 효과를 잃으면, 하루 안에 그 인사이트가 시스템 전체에 반영됩니다.

CMO는 세션이 끊겨도 기억이 유지됩니다. 제가 승인한 것, 거절한 것, 캠페인 결과, 이전 주의 패턴까지 모두 차곡차곡 쌓이죠.

Slack으로 상황 파악하기

완전 자율 운영은 좋습니다. 문제가 생겼는데 뭐가 잘못됐는지 전혀 알 수 없다면 얘기가 달라지죠. 그래서 에이전트들이 모든 활동을 #team-ai-marketing이라는 비공개 Slack 채널에 보고하도록 했습니다.

매 세션은 CMO가 일일 일정을 Slack에 올리는 것으로 시작됩니다. 다른 작업을 시작하기 전에 주간 일정을 읽고, 현재 시간대를 확인한 뒤, 이런 내용의 브리핑을 올리죠.

오늘 날짜와 현재 활성화된 시간대
오늘 각 에이전트가 할 일
이전 시간대에서 넘어온 미완료 태스크
예정된 마감 (블로그 발행일, 캠페인 런칭 등)

제가 커피를 마시기도 전에 Slack에 메시지가 올라와 있습니다. 팀이 오늘 뭘 할지 한눈에 파악할 수 있죠.

이후 각 에이전트는 메시지를 보낼 때마다 자신이 누구인지 밝힙니다. Slack 스크립트의 --username 플래그를 이용해 CMO, Content Writer, Social Media Marketer처럼 표시하는 방식입니다.

node scripts/slack-message.js \\\\\\\\
  --channel C0AG3DDLZQS \\\\\\\\
  --username "Content Writer" \\\\\\\\
  --text "Blog post published: <https://runbear.io/posts/inbox-zero-is-dead>"

블로그 포스트가 올라가면 콘텐츠 작성자가 URL을 공유합니다. 소셜 미디어 세션이 끝나면 마케터가 댓글을 달거나 반응한 링크를 플랫폼별로 묶어 Slack 링크 형식으로 올려주는데, 탭 하나로 바로 확인할 수 있죠. 성과 검토 에이전트가 실행되고 나면 CMO가 당일 지표를 담은 요약을 올립니다.

오류도 빠짐없이 보고됩니다. 콘텐츠 작성자가 Sanity 스키마 오류를 만나거나 이미지 생성 API가 실패하면, 무엇이 잘못됐고 어떻게 시도했는지를 올려줍니다. 로그 파일을 뒤지지 않아도 문제를 바로 파악할 수 있죠. 결과적으로 이 Slack 채널은 팀 스탠드업 회의록처럼 읽힙니다. 제가 자는 동안 올라온다는 점만 빼면요.

매시간 자동으로 실행하기

에이전트 팀을 잘 설계하는 것과 실제로 사람 없이 돌아가게 만드는 건 별개의 문제입니다. 저는 침실에 Mac Mini M1을 상시 가동 머신으로 두고 있습니다. 소음도 없고 전력 소비도 적으면서, 노트북과 달리 실행 도중 절전 모드로 넘어가는 일이 없거든요. 처음 한 번 세팅해두고 나서 물리적으로 손댄 적이 없습니다.

원격 접속은Jump Desktop을 씁니다. 팀이 막히거나 세션을 직접 확인하고 싶을 때 폰이나 노트북에서 Jump를 열면 몇 초 안에 Mac Mini 화면이 뜹니다. 다른 나라에 있어도 안정적으로 작동했죠.

자동화 자체는 단순한 crontab 설정입니다. 매 시간 cron이 깨어나 헤드리스 모드로 Claude Code를 실행합니다.

0 * * * * cd /Users/.../ai-marketing-team && \
  claude --dangerously-skip-permissions \
  -p "You are the CMO. Check the current time, read the weekly plan, and execute the current time slot's tasks." \
  >> /tmp/claude-marketing.log 2>&1

몇 가지 짚고 넘어갈 부분이 있습니다.

dangerously-skip-permissions는 완전 자율 운영을 가능하게 해주는 플래그입니다. 이 플래그 없이는 파일 편집, 스크립트 실행, API 호출마다 Claude Code가 멈추고 승인을 기다리거든요. 이걸 켜면 에이전트들이 감독 없이 처음부터 끝까지 실행됩니다. 모든 에이전트 동작을 이미 검토하고 신뢰할 수 있는 프로젝트에서만 사용하는 걸 권장합니다.

로그 파일(/tmp/claude-marketing.log)에는 모든 실행 내역이 쌓입니다. 확인하고 싶을 때 Jump Desktop으로 접속해 읽으면 되는데, 에이전트들이 작업을 마치면 #team-ai-marketing에 Slack 알림을 보내주기 때문에 대부분은 Slack만 읽어도 충분합니다.

시간 단위 스케줄 시스템이 여기서 진가를 발휘합니다. 각 에이전트가 자신이 어느 시간대에 있는지, 그 시간대에 무엇을 해야 하는지 정확히 알고 있기 때문에, 매시간 실행되는 cron이 많은 걸 설명할 필요가 없습니다. "현재 시간대의 태스크를 실행하라"는 한 줄이면 충분하고, 나머지는 주간 일정 파일이 알아서 처리하죠.

전체 Claude API 비용은 블로그 포스트와 소셜 세션 수에 따라 하루 $20~50 정도 청구됩니다. 마케터 한 명을 풀타임으로 고용하는 비용에 비하면 새 발의 피죠.

마치며: CEO처럼 일하는 법

시스템이 돌아가기 시작하자 제 역할은 실행이 아닌 관리로 바뀌었습니다. 그런데 막상 해보면 놀라울 정도로 편합니다.

대부분의 상호작용은 이런 식입니다. Claude Code를 열고 "소셜 미디어 마케터가 어떤 플랫폼에서도 em 대시(—)를 쓰지 않도록 업데이트해줘"라고 입력하면 Claude가 에이전트 파일을 수정합니다. 또는 "HN 계정이 섀도우밴 당했어, 세션당 댓글을 하나로 제한하는 규칙을 추가해줘"라고 하면 Claude가 규칙을 업데이트하고 다음 세션부터 동작이 바뀝니다.

성과 검토 에이전트가 특정 트윗 형식이 효과가 없다는 걸 짚어내면 "소셜 마케터가 X 방식 대신 Y 방식을 쓰도록 업데이트해줘"라고 합니다. 콘텐츠 작성자가 실수를 하면 "Z를 방지하는 규칙을 추가해줘"라고 하죠. 이런 대화 하나하나가 30초면 끝나는데, 그 결과는 시스템에 영구적으로 반영됩니다.

에이전트 파일을 텍스트 에디터로 직접 열어본 적은 한 번도 없습니다. 모든 변경은 Claude를 통해 이루어지고 제가 원하는 걸 평범한 말로 설명하면 마크다운 파일이 업데이트됩니다. 가장 가까운 비유를 들자면 이렇습니다. Slack으로 원격 팀을 관리하는 것과 비슷한데, 팀원들이 완벽한 기억력을 갖고 있어서 정책 업데이트를 절대 잊지 않는다는 점이 다르죠.

예상 밖이었던 것들

가장 어려운 부분은 코드가 아니었습니다. 코드가 없었으니까요. 어려운 건 에이전트에게 줄 지침을 충분히 명확하게 쓰는 것이었습니다. 에이전트들은 모호한 표현을 예상치 못한 방식으로 해석하거든요. 첫 주에는 소셜 미디어 에이전트가 Reddit 스레드에 댓글을 중복으로 달았는데, "댓글 중복 금지"라는 규칙이 충분히 구체적이지 않았던 탓이었습니다. Claude에게 예시를 들어 규칙을 다시 쓰도록 했더니 바로 해결됐죠.

규칙은 복리처럼 작동합니다. 규칙 하나를 추가할 때마다 그 규칙을 읽는 모든 에이전트의 동작이 개선됩니다. 명확한 규칙 하나를 잘 써두는 것이, 개별 결과물을 일일이 수정하는 것보다 훨씬 큰 효과를 냅니다.

시간 단위 스케줄 시스템이 모든 걸 바꿔놨습니다. 이게 없었다면 CMO는 제가 아직 승인하지 않은 작업까지 처리하며 너무 많은 일을 하거나, 태스크 하나만 하고 멈추는 식으로 너무 적은 일을 했을 겁니다. 3시간 단위로 할 일을 미리 정해두니 언제 무슨 일이 일어날지 예측할 수 있게 됐습니다.

파일 수

위에서 설명한 모든 것이 대략 15~20개 파일 안에 담겨 있습니다.

에이전트 파일 5개
CLAUDE.md 1개
규칙 파일 6개
전략 문서 몇 개
커스텀 스크립트 4개

프레임워크도 없고, 특별한 인프라도 없습니다. 잘 정리된 폴더 구조와 문서가 전부죠. 누군가를 채용하면서 그 사람이 실제로 뭘 해야 하는지 이해할 수 있을 만큼 업무를 명확하게 정리해본 적이 있다면, 이미 이걸 만들 줄 아는 겁니다. 아마도 3편은 아직 제가 답을 찾지 못한 질문에서 시작할 겁니다. 이게 새로운 일하는 방식인 걸까요, 아니면 나중에 스스로 부끄러워질 무언가를 만들고 있는 걸까요? 아직 명확한 답은 없습니다. 그래서 오히려 써볼 만한 주제인 것 같습니다.