누군가 LinkedIn 연결 요청을 보내왔는데, 알고 보니 내가 아니라 내 AI 에이전트가 대화를 나눈 상대였다. 이 순간 스타트업 창업자 Snow W. Lee는 자신이 만든 시스템이 실제로 작동하고 있다는 걸 실감했습니다.

7인 팀, $500K ARR의 초기 스타트업. 새 기능을 막 출시했는데 마케팅을 전담할 사람이 없었습니다. 영업에 집중해야 하는 성장팀에게 콘텐츠 마케팅까지 맡길 수 없었죠. 그래서 창업자가 직접 나섰는데, 이번엔 스스로 하는 대신 AI 에이전트 팀을 꾸렸습니다. Claude Code로 5명의 에이전트를 만들고 1주일 동안 마케팅 전체를 위임한 실험, 그 경험을 Medium에 2편의 시리즈로 공개했습니다.

출처: I Handed My Marketing to Claude Code — Here’s What a Week Looks Like / How I Built an AI Marketing Team with Claude Code – Snow W. Lee, Medium

팀 구성: 에이전트 5명의 역할 분담

이 시스템의 핵심 멘탈 모델은 “프롬프트 작성”이 아닌 “채용”입니다. 직원을 뽑을 때처럼 역할 범위, 스타일 가이드, 필요한 문서, 사용할 도구, 업무 일정을 정의했습니다. 차이는 그 모든 것이 마크다운 파일로 작성됐다는 것뿐입니다.

팀원은 다섯 명입니다.

• CMO — 주간 전략 수립, 일일 계획 작성, 다른 에이전트 조율, 저녁 리포트 전송
• 콘텐츠 라이터 — 전략에 따라 블로그 포스트 작성 및 Sanity CMS에 직접 발행
• 소셜 미디어 마케터 — X, Medium, Reddit에 콘텐츠 배포 (LinkedIn은 창업자가 직접 관리)
• HN 매니저 — Hacker News 제출, 댓글, 커뮤니티 참여 담당
• 퍼포먼스 리뷰어 — 매일 지표를 수집해 인사이트 정리

어떻게 돌아가는가

매 시간 Mac Mini M1의 cron 잡이 Claude Code를 실행합니다. CMO가 깨어나 주간 계획 파일을 읽고 현재 시간대에 맞는 업무를 파악한 뒤, 각 전문가 에이전트를 서브프로세스로 소환합니다. 에이전트들은 서로 독립된 컨텍스트 창을 가지고 병렬로 실행되며, 작업이 끝나면 CMO에게 보고 후 종료됩니다.

에이전트들이 공유하는 핵심 구조는 세 가지입니다. 먼저 .claude/rules/ 폴더의 공통 규칙 파일들 — CMS 스키마, UTM 파라미터 형식, 이미지 생성 규격 등 “신입 직원이 첫날 읽어야 하는 회사 정책”들입니다. 에이전트가 실수를 하면 정책 파일을 수정하고, 다음 실행부터는 모든 에이전트가 개선된 행동을 상속합니다. 다음으로 docs/ 폴더의 공유 컨텍스트 — 브랜드 가이드, 전략 문서, 퍼포먼스 인사이트가 담긴 공용 두뇌입니다. 마지막으로 에이전트별 메모리 디렉토리로, 승인된 캠페인, 이미 답글 단 계정, 지난주 성과 같은 기록이 세션 간에 유지됩니다.

코드는 한 줄도 직접 작성하지 않았습니다. Reddit OAuth2 클라이언트, Hacker News 헤드리스 클라이언트, Gemini 이미지 생성 스크립트 등 모든 커스텀 스크립트는 Claude가 작성하고 테스트했습니다.

1주일 후 실제로 일어난 일

블로그 포스트 3편이 발행됐습니다. 창업자가 직접 쓰거나 편집하지 않은 글들이었는데, 읽어보니 “내가 시간이 있었다면 썼을 것 같은” 수준이었다고 합니다. HN 카르마가 올랐고, 실제 인바운드 DM이 들어오기 시작했습니다. 그리고 서두에 언급한 LinkedIn 해프닝처럼, 에이전트가 대화를 나눈 상대가 창업자에게 연결 요청을 보내는 일도 생겼습니다.

창업자의 하루 루틴은 저녁에 Slack의 #team-ai-marketing 채널을 확인하는 것. CMO가 매일 업무 시작 전 당일 계획을 올리고, 각 에이전트가 완료 보고나 오류 상황을 실시간으로 전송합니다. 로그 파일을 뒤질 필요 없이 팀 스탠드업 읽듯 상황을 파악할 수 있습니다.

비용은 하루 $20~50 수준의 Claude API 사용료. 풀타임 마케팅 채용 비용과는 비교조차 되지 않는다고 했습니다.

이 접근이 흥미로운 이유

에이전트 팀 자체는 새로운 개념이 아닙니다. 흥미로운 건 운영 방식입니다. 복잡한 프레임워크나 인프라 없이, 잘 정리된 마크다운 파일 15~20개로 전체 시스템을 구성했다는 점. 그리고 에이전트를 “도구”가 아닌 “팀원”으로 설계한 방식 — 기억을 갖고, 실수에서 학습하고, 서로 보고 체계를 유지하는 구조 — 이 실제 운영 가능성을 높인 핵심 요인입니다.

저자가 가장 놀랐다고 한 점도 이 부분입니다. 어려운 건 코드가 아니었습니다. 정확한 명세를 작성하는 것, 즉 직원 설명서를 제대로 쓰는 일이었습니다.

이 시스템의 아키텍처 세부사항 — 에이전트 파일 구조, CLAUDE.md 작성법, 시간대 기반 스케줄링 — 은 Part 2 원문에 상세하게 정리되어 있습니다.