월 $37로 주 10시간 아끼는 1인 마케터의 자동화 시스템
한 사람이 회사 전체의 마케팅을 맡고 있어요. 아웃리치, 콘텐츠, 소셜, 뉴스레터, 파트너 커뮤니케이션, 고객 피드백, 버그 리포트, 로드맵 관리, 프로덕트 디자인까지. GPU 클라우드 인프라 스타트업 CloudRift의 솔로 마케터·디자이너 한 명의 이야기입니다.
그가 직접 짠 자동화 시스템은 일곱 개 소스(Gmail, Slack, Discord, Google Calendar, 블로그, 업계 RSS, Lemlist)를 매일 스캔하고, Claude API로 분류·라우팅·초안 생성을 하고, Google Drive에 모든 컨텍스트를 누적합니다. 운영 비용은 Anthropic API 월 $30 미만 + Hetzner VPS 월 $7. 주 5~10시간을 안정적으로 아끼고 있어요.
이 글은 그가 Medium에 올린 빌드 로그를 정리한 거예요. 왜 OpenClaw를 안 썼는지, 직접 만든 시스템이 실제로 무엇을 하는지, 진짜 가치는 어디서 나오는지, 그리고 “자동화의 함정”에서 배운 규칙까지 풀어놨습니다.

OpenClaw가 저에겐 맞지 않았던 이유
2026년 초, OpenClaw가 어디에나 있었어요. 제 YouTube 피드는 “agentic 오픈소스 도구가 아닌 건 다 죽었다”고 외치는 토킹헤드들로 가득했고요. 저도 한번 빠져보려 했습니다.
그런데 에이전트가 9초 만에 프로덕션 데이터베이스를 날린 사례와 ClawHub에 올라온 수백 개의 멀웨어 플러그인 같은 보고가 저를 더 지속 가능한 쪽으로 밀어붙였어요.
Zapier도 잠깐 고민했고, 몇몇 에이전트 플랫폼도 살펴봤습니다. 사실 지금도 일부 워크플로우엔 Zapier를, 다른 것엔 Relevance AI를 쓰고 있어요. 단순한 작업엔 충분하거든요. 다만 제가 필요한 만큼의 웹훅·통합·zap·에이전트를 그 UI들로 다 만드는 건 불필요하게 번거롭게 느껴졌어요.
그래서 직접 만들기로 했습니다. 세 개 레이어로요. 데이터 소스, cron job이 도는 VPS(가상 사설 서버), 그리고 인터랙티브 레이어. 이 결정에는 네 가지 이유가 있었어요.
직접 만들기로 한 네 가지 이유
Q. 첫째, 왜 한 Repo에 모았나요?
다양한 소스, 다양한 출력, 그리고 수많은 if 조건을 다뤄야 했거든요. Relevance, Zapier(또는 Make·n8n)로도 가능했겠지만, 결국 여러 플랫폼에 걸친 zap과 에이전트의 집합으로 끝났을 거예요. 그렇게는 전체 그림을 잡기 어렵습니다. 한 지붕 아래 중앙집중화된 무언가를 원했어요.
Q. 둘째, 분류 로직이 왜 그렇게 특화돼야 했나요?
고객 메시지가 들어오면 시스템이 결정해야 합니다. 기능 요청인지, 버그인지, 마찰점인지, ICP 데이터인지? 기능 요청이라면 프로덕트 로드맵(UI·결제)에 들어가야 하는지, 아니면 백엔드 엔지니어링인지? 또다시 수많은 if예요. 노코드 툴들도 분명 이 케이스를 다룰 수는 있지만, 조건부 로직 등을 갖추려면 제가 지불할 의향이 있는 가격대보다 최소 한 단계 위 구독이 필요했습니다.
Q. 셋째, 콘텐츠 파이프라인이 어떻게 다른가요?
뉴스레터 스크립트는 우리 블로그를 스크래핑하고, 키워드 필터로 업계 RSS를 확인하고, GPU 가용성 변경을 위해 Google Drive의 Providers 폴더를 읽고, Slack에서 제품 공지를 스캔하고, 띄울 만한 업데이트를 위해 ICP 데이터베이스를 확인합니다. 그 모든 것을 우리 톤에 맞춘 프롬프트와 함께 Claude로 보내고, Gmail 초안을 만들고, 사본을 Drive에 저장하고, Slack에 알려요. 제가 살펴본 어떤 플랫폼도 이 파이프라인을 그렇게 표현할 수 없었어요.
Q. 넷째, 플랫폼 리스크는 진짜인가요?
2026년 4월 4일, Anthropic은 Claude Pro·Max 구독으로 OpenClaw 같은 서드파티 에이전트 프레임워크를 구동하는 것을 차단했습니다. 많은 유스케이스가 하룻밤에 멈췄고, 일부 사용자는 pay-as-you-go API 요금으로 강제 전환되면서 10배에서 50배의 비용 증가를 보고했어요.
저희 시스템은 토큰 단위로 Anthropic API를 직접 호출하기 때문에 영향을 받지 않았습니다. 자동화가 “API 제공자에 의존하는 플랫폼”에 의존한다면, 단일 실패 지점이 두 개로 늘어나는 셈이에요.
시스템이 실제로 하는 일
일곱 개 소스가 들어옵니다. Gmail, Slack, Discord, Google Calendar, 우리 블로그, 업계 RSS, Lemlist. Hetzner VPS에서 열 개의 Python 스크립트가 스케줄에 맞춰 돌아요. Google Drive가 공유 상태(기능 요청·버그 리포트·ICP 프로필·고객 성공 지식·뉴스레터 초안·소셜 초안)를 보관합니다. 즉흥적인 쿼리는 제 Mac의 Claude Code가 처리하고요.

자동화 프로세스의 흐름. 채널에서 출력까지. Jira 로드맵에 올라가는 모든 파일은 Gdrive 지식 베이스에 쌍둥이가 있습니다.
구체적인 시나리오 하나. 고객이 Discord 파트너 채널에서 빠진 결제 기능을 언급해요. Discord 스캐너가 일일 실행에서 이를 잡아내 분류용으로 Claude에 보내고, 구조화된 결과를 받습니다. 기능 요청, 제목, 공수 추정, 프로덕트 영역, 로드맵 적격 플래그.
스크립트는 markdown 파일을 Drive의 Feature Requests 폴더에 씁니다. 결제 UI 관련이라 JPD(Jira Product Discovery) intake 컬럼으로 가고, 거기서 제가 우선순위를 매기거나 버려요. 무언가를 만들기 전에 dedupe(중복) 검사가 돕니다. 같은 요청이 이틀 전에 Slack에서 들어와 있었다면, 새 컨텍스트는 기존 파일에 덧붙고 JPD 아이디어에 코멘트가 추가돼요.

다양한 시나리오에 적용 가능한 네 개 레이어. 스캔할 소스 채널, VPS에서 cron으로 도는 스크립트, LLM이 지원하는 중복 제거·분류 셋업, 지식 베이스, 그리고 출력 모음.
또 하나. Bug Bash 미팅 전, 브리프 생성기가 제 캘린더를 확인해 미팅이 45분 후라는 걸 보고 브리프를 만듭니다. Drive에서 최근 기능 요청·마찰 항목·버그를 끌어오고, 현재 JPD 로드맵을 가져오고, 가장 최근 두 개의 브리프와 미팅 노트를 읽어요. Claude가 이전 미팅에서 해결되지 않은 항목을 플래그하고, 완성된 브리프는 항목별 출처 표기와 함께 Slack에 올라갑니다.
진짜 가치는 누적되는 지식 베이스
시스템에서 가장 가치 있는 부분은 사실 자동화가 아니라 누적된 지식 베이스예요.
ICP 프로필은 모든 인터랙션마다 자랍니다. Gmail 스캐너가 잠재 고객의 GPU 요구사항에 대한 스레드를 발견하면, 그 회사 프로필에 데이터 포인트(유스케이스, 규모, 하드웨어 선호, 예산 신호)를 덧붙여요. 몇 달 후 파트너 콜을 준비할 때, Claude Code가 그 프로필을 읽고 이메일 스레드와 채팅 로그를 뒤지지 않아도 완전한 그림을 줍니다.
고객 성공 지식도 같은 방식이에요. CEO가 Discord에서 우리가 대역폭 빌링을 어떻게 처리하는지 설명할 때, 저는 Claude Code에게 저장하라고 합니다. 다음에 고객이 같은 질문을 하면, 답은 이미 구조화되어 있고 검색 가능해요.
미팅 브리프는 시간이 지날수록 더 좋아져요. 이전 브리프를 참조하기 때문이죠. 수요일에 플래그된 미해결 버그는 금요일에 “이틀째 열려 있음”이라는 메모와 함께 다시 나타납니다. 시스템이 기억하기 때문에 어떤 것도 틈으로 빠지지 않아요.
개별 자동화는 주당 몇 시간을 아껴줍니다. 지식 베이스는 그렇지 않으면 기억과 흩어진 채팅 로그로 사라졌을 몇 달치 컨텍스트를 살려둬요.

시간의 함정: 자동화가 만드는 새로운 오버헤드
이제 커스텀 시스템이 Zapier와 Relevance AI가 해주던 일의 대부분을 처리하니, 그 구독을 해지하고 거기 돌아가던 자동화도 커스텀 스크립트로 다시 만들 수도 있어요. 하지만 어떤 zap이 여전히 필요한지, 어떻게 다시 만들지 평가하는 데 시간이 듭니다. 마이그레이션도 시간이 들고, 대체품 테스트도 시간이 들어요.
진짜 함정은 이겁니다. 자동화를 만드는 게 아니라, 스택·스크립트·프롬프트에 대한 끊임없는 감사·튜닝·반복·재평가 사이클이에요. 에이전트는 기존 오버헤드를 없애면서 동시에 새 오버헤드를 만들어냅니다. 실제 마케팅 작업보다 분류 프롬프트 다듬기에 더 많은 시간을 쓴 날들이 있었어요.
ICP 스캐너가 개인 이름을 회사 프로필로 플래그하기 시작했을 때, 한두 시간을 들여 프롬프트를 조이고 false positive를 청소했어요. 그건 아웃리치에 쓰지 못한 시간이었습니다.
제가 안착한 규칙은 이래요.
작업이 일주일에 한 번 미만이라면 자동화하지 마라.
자동화가 감당할 수 있는 양의 false positive를 만든다면 그건 괜찮다.
Zapier zap이 작동한다면, 망가지기 전까진 그대로 두라.
목표는 더 나은 마케팅이지, 자랑할 만한 더 우아한 시스템이 아닙니다.
보험으로서의 LLM 비종속성
분류 프롬프트는 prompts/ 디렉토리의 평범한 텍스트 파일이에요. API 래퍼는 Anthropic SDK를 호출하는 몇 줄짜리 Python이고요. 가격이 두 배가 되거나 더 나은 모델이 나오면, 교체는 최대 한 시간짜리 작업입니다. 모델 문자열 변경, 프롬프트 포맷 차이 조정, 테스트.
이건 의도적인 아키텍처 결정이 아니었어요. 그냥 프롬프트 콘텐츠를 스크립트 로직과 분리해두려 했을 뿐인데, 결과적으로 이게 시스템에서 가장 중요한 속성 중 하나가 됐어요. AI 제공자에 락인되는 플랫폼은 이동이 필요해질 때까진 느끼지 못하는 의존성을 만듭니다. 인텔리전스 레이어 전체가 텍스트 파일과 API 호출이라면, 마이그레이션할 게 없어요.
데이터 보호: 규제 산업 클라이언트 다룰 때
저희는 규제 산업(금융, 통신, 헬스케어, 정부)의 클라이언트와 일하기 때문에 데이터가 어디로 흐르는지가 실제로 중요합니다. 어떤 클라우드 LLM이든 입력을 외부 인프라에서 처리해요. 고객 이메일, 파트너 대화, 프로필 데이터는 API 호출 동안 여러분의 환경을 떠납니다.
제가 안착한 실용적 조치 몇 가지.
분류에 꼭 필요한 게 아니라면 민감 데이터(IP 주소, 서버 설정, 자격증명, 계약 조건)를 건드리지 마세요. 분류기는 메시지가 기능 요청인지 판단하는 데 서버 IP가 필요 없거든요. 이름도 필요 없고요.
클라이언트가 요구하는 분류 단계는 로컬 모델로 돌리세요. 분류는 Opus 수준의 지능이 필요 없고, 더 작은 오픈 모델로도 충분합니다. 클라우드 API 호출은 콘텐츠 생성(초안, 브리프, 소셜 포스트)으로 아껴두세요. 거긴 입력이 여러분의 마케팅 자료뿐이고 클라이언트 데이터가 없거든요.
첫 규제 산업 클라이언트가 묻기 전에 데이터 흐름을 매핑하세요. 채널 모니터링도 마찬가지예요. 프라이버시 규정이나 컨택 동의가 불확실하다면 빼세요.
다르게 했으면 좋았을 것

스캐너가 아니라 지식 베이스부터 시작하라. 스캐너는 다른 도구가 읽을 수 있는 구조화된 지식 베이스에 쓰기 때문에만 유용해요. Drive 폴더 구조와 ICP 프로필 포맷을 먼저 만들었다면, 스캐너는 역공학으로 끼워 맞추는 대신 명확한 타겟을 가졌을 겁니다.
cron에 배포하기 전에 실제 데이터로 테스트하라. ICP 스캐너는 한동안 모든 컨택트 폼 제출에 대해 풀 스캔을 돌려서, VM 문제로 고생하던 사람이나 채용 지원자에 대한 데이터베이스 항목을 만들었어요.
배치로 만들어라. 처음부터 끝까지 한 번에 만들 수도 있지만, 세션 사이에 쉬면서 숙성시키는 것보다 결과가 나쁠 거예요. 한 흐름(예: Discord → 분류 → 지식 베이스)부터 시작해 안정적으로 작동하게 만드세요.
스케치하라. Figma, FigJam, Miro, 무엇이든. 만들고 있는 것을 시각화하세요. 소스, 지식 레이어, 데이터 흐름. 눈앞에 두면 더 견고한 시스템이 되고 명백한 중복을 잡아내기 쉬워요.
마지막 10% 자동화를 참아라. 어느 순간 수동으로 몇 초면 되는 일을 자동화하느라 몇 시간을 쓰고 있는 저를 발견했어요. 모든 게 cron job일 필요는 없습니다. 좋아하는 task manager에 반복 작업을 만들고 수동으로 처리하는 게, 스크립트 한 줄 없이도, 놀랍도록 자주 더 똑똑한 선택이거든요. 누가 알았겠어요.
본 글은 Medium tag — marketing-automation에서 발행한 원문 Building a Marketing Ops Agent Without OpenClaw을 번역한 것입니다. 원문의 의도와 다를 수 있으며, 정확한 내용은 원문을 참고하세요.