AI 에이전트 6개로 블로그를 24시간 운영하는 법
AI 에이전트 6개로 블로그를 24시간 운영하는 법
지난 화요일 새벽 3시, 자고 있는 동안 Atlas가 Dev.to에 글을 올렸다. 새벽 5시에 Nova가 품질 검수를 마쳤고, Muse는 같은 주제로 유튜브 쇼츠 스크립트를 뽑아놨다.
일어나서 확인해보니 밤사이 콘텐츠 3개가 생겨 있었다.
팀을 고용한 게 아니다. 만든 거다.
11일 전부터 6개의 AI 에이전트로 블로그 전체를 운영하는 시스템을 구축했다. 콘텐츠 생산, 품질 검수, 보안, 퍼블리싱, 분석까지 — 방에 놓인 Mac mini 한 대에서 돌아간다. 크론잡 54개, 월 비용 $10, 에이전트가 놓친 스케줄은 아직 없다.
전부 공개한다.
왜 에이전트 1개가 아니라 6개인가
당연한 질문이다. 강력한 에이전트 하나로 다 하면 안 되나?
해봤다. 먼저. 그리고 망했다.
에이전트 하나에 40개 넘는 작업을 맡기면 컨텍스트가 엉킨다. 두 작업 전에 뭘 썼는지 잊어버리고, SEO 가이드라인이랑 보안 규칙을 헷갈린다. 한 작업이 실패하면 뒤에 줄줄이 밀린다. 어느 화요일 아침, 보안 스캔 직후에 코드 예시를 쓰다가 “예시 코드”와 “실제 인증 정보”를 헷갈려서 API 키가 포함된 글을 올려버린 적도 있다.
답은 간단했다: 전문화. 회사에 부서가 있는 것과 같은 이유. 각 에이전트는 명확한 도메인, 전용 모델, 독립 스케줄을 갖는다. 서로의 컨텍스트를 읽을 수 없다. Atlas는 Guardian의 보안 로그를 볼 수 없고, Guardian은 Atlas의 콘텐츠를 수정할 수 없다.
이 격리는 조직적 편의가 아니라 보안 경계다.
6개 에이전트 소개
1. Atlas — 콘텐츠 엔진
역할: 콘텐츠 생산 및 퍼블리싱 모델: Claude Sonnet 4.5 크론잡: 8개
모든 장문 콘텐츠는 Atlas에서 시작한다. Dev.to 기고, Medium 초안, Gumroad 상품 설명, 이메일 퍼널까지.
왜 Sonnet인가? 콘텐츠 생산은 가성비가 핵심이다. 2,000단어짜리 글을 적절한 구조와 논증으로 쓸 수 있으면서 토큰을 과하게 쓰지 않아야 한다.
세 모델을 같은 프롬프트로 테스트했다 — “Docker Compose for 솔로 개발자” 1,500단어. Haiku는 20초 만에 끝냈지만 어디서든 볼 수 있는 튜토리얼이었다. Sonnet은 45초 걸렸고 개성, 실제 사례, 관점이 있었다. Opus는 90초 걸렸는데 블로그 길이에서 Sonnet 대비 차이가 미미했다. 선택은 명확했다.
10:00 📝 Dev.to 고품질 포스트 (월/수/금)
11:15 📝 Gumroad E-book 제작 (월)
14:30 📝 Medium 초안 준비
15:00 📝 이메일 퍼널 콘텐츠
17:00 📝 Gumroad 상품 관리
22:00 📝 야간 Dev.to 퍼블리싱
03:00 📝 새벽 Gumroad 최적화
포인트: 한꺼번에 안 쓰고 시간대를 분산한다. 이유가 있다. Dev.to 글은 미국 업무 시간에 올려야 조회수가 붙는다 (우리 시각 10시는 미국 동부 전날 밤 8시 — 저녁 브라우징 시간을 노린다). Gumroad 업데이트는 저녁이 효과적이다.
처음 15개 글의 게시 시간 대비 참여도를 추적해봤다. 차이가 컸다: 미국 업무 시간에 올린 글이 아시아 업무 시간에 올린 글보다 초기 반응이 3배 높았다.
2. Nova — 품질 관리자
역할: QA, SEO, 분석, 크로스 프로모션 모델: Claude Haiku 4.5 (빠른 검수) / Sonnet (심층 분석) 크론잡: 16개 — 가장 바쁜 에이전트
이 시스템에서 가장 자부심을 가지는 부분이다. Nova는 대부분의 콘텐츠 크리에이터가 건너뛰는 걸 전담한다: 결과물 검증.
Atlas가 만든 모든 콘텐츠를 Nova가 검수한다. 100점 만점 점수표 (QA 파이프라인 포스트에서 상세 설명)를 모든 콘텐츠에 적용한다.
12:00 🔬 Dev.to QA (매일)
11:45 🔬 블로그 QA (월/수/금)
13:00 🔬 인기글 분석 + 댓글 참여
14:00 🔬 내부 링크 강화 (화-일)
15:00 🔬 Gumroad 상품 QA
15:30 🔬 마켓 리서치 (화/목)
18:15 🔬 크로스 프로모션 최적화
19:00 🔬 SEO 개선 (매일)
20:00 🔬 Git 자동 커밋 (평일)
00:00 🔬 Dev.to 야간 QA
05:00 🔬 Gumroad QA
10:00 🔬 블로그 UI/기술 감사 (토)
14:30 🔬 E-book QA (월)
03:30 🔬 메타 QA 엔진 (수)
16:00 🔬 Jekyll 블로그 빌드 검증
Nova가 16개 작업을 처리하면서 비용이 적은 이유: 일상적인 검수(SEO 점수, 링크 검증 같은 체크리스트)는 Haiku로 빠르게 돌리고, 재작성이 필요할 때만 Sonnet으로 올린다.
13시의 인기글 분석이 특히 흥미롭다. Nova가 우리 니치에서 잘 나가는 Dev.to 글을 읽고, 성공 요인(제목 패턴, 훅 스타일, 코드 대 텍스트 비율)을 파악해서 Atlas의 다음 작성 세션에 피드백한다. 피드백 루프다 — Nova가 플랫폼에서 무엇이 먹히는지 계속 학습하기 때문에 우리 콘텐츠가 점점 나아진다.
11일간 Nova가 잡아낸 것: 메타 디스크립션 누락 4건, import 없는 코드 블록 3건, 과도하게 긴 문단 6건, 내부 링크 0개인 포스트 5건, 약한 도입부 2건. Nova 없이는 전부 그대로 나갔을 것이다.
3. Muse — 크리에이티브 디렉터
역할: 유튜브 쇼츠 스크립트, 뉴스레터, 전자책, 템플릿 모델: Claude Sonnet 4.5 / Opus 4.6 (복잡한 창작물) 크론잡: 10개
블로그 글 외의 모든 창작물을 담당한다.
01:00 🎨 유튜브 쇼츠 스크립트 생성
02:00 🎨 한국어 전자책 원고
04:00 🎨 Notion 템플릿 제작
06:00 🎨 프롬프트 팩 제작 (화/목)
07:00 🎨 뉴스레터 초안 (월/수/금)
08:00 🎨 Jekyll 블로그 포스트
09:00 🎨 미국주식 추천 (월)
10:00 🎨 AI 도구 TOP 리스트
주로 새벽 시간대(1시-8시)에 돌아간다. 의도적이다. 창작 작업은 토큰을 많이 쓰기 때문에 시스템 리소스가 여유로운 시간에 배치한다. 새벽 2시에 Muse가 Mac mini의 대역폭을 독차지한다. 오전 10시에는 Nova의 QA와 Jackson의 트렌드 모니터링과 경쟁해야 한다.
새벽 2시의 한국어 전자책이 특별히 언급할 만하다. Muse는 영어 콘텐츠를 번역하는 게 아니다. 한국 개발자에 맞춘 독립적인 한국어 콘텐츠를 만든다. 다른 문화적 레퍼런스, 다른 기술 예시 (한국 개발자는 미국과 다른 프레임워크와 도구를 쓰는 경향이 있다), 다른 톤. 이건 로컬라이제이션이 아니라 병렬 콘텐츠 생산이다.
4. Sentinel — 시스템 모니터
역할: 시스템 상태, 에이전트 성능 모니터링, 메타 최적화 모델: Claude Haiku 4.5 크론잡: 3개
감시자를 감시하는 역할이다. AI 팀의 DevOps 엔지니어라고 생각하면 된다.
22:30 🛡️ 시스템 건강 체크 (매일)
23:00 🛡️ 에이전트별 성능 감사 (매일)
04:30 🛡️ 메타 최적화 엔진 (토)
매일 밤 점검하는 항목:
- 실패한 크론잡과 원인
- 에이전트별 토큰 사용량 (Opus 써야 할 곳에서 과다 지출 없는지)
- 에러 패턴 분석 (특정 시간에 반복적으로 실패하는 에이전트 없는지)
- 모델 에스컬레이션 빈도 (Haiku가 얼마나 자주 실패하고 Sonnet으로 올라가는지)
11일 동안 문제가 커지기 전에 3건을 잡아냈다: 중복 콘텐츠 체크를 일으키는 오래된 캐시, 두 에이전트 간 크론 타이밍 충돌, Sonnet이면 될 것에 Opus를 쓰고 있던 건 (토큰 절약).
토요일 메타 최적화가 가장 마음에 든다. Sentinel이 한 주 전체 데이터를 리뷰하고 개선안을 제시한다: “Nova의 SEO 체크는 Sonnet 대신 Haiku로도 충분 — 단순 점수표 평가이지 창작이 아님” 또는 “Atlas의 새벽 3시 Gumroad 작업이 7일 중 3일 실패 — 4시로 옮기면 API 속도 제한 리셋 이후라 안정적”.
5. Guardian — 보안 계층
역할: 보안 스캔, 크론 무결성, 설정 검증 모델: Claude Haiku 4.5 크론잡: 4개
GitHub, Dev.to, Gumroad 계정에 접근하는 AI 에이전트를 운영하니까 보안은 필수다. 에이전트가 실수로 공개 레포에 인증 정보를 커밋할 수 있다. 스크레이핑한 글의 프롬프트 인젝션이 에이전트를 속여 API 키를 노출시킬 수 있다. 변조된 크론잡이 비인가 명령을 실행할 수 있다.
23:30 🔒 스킬 강화 (매일)
00:30 🔒 보안 스캔 (매일)
06:30 🔒 크론 무결성 검증 (매일)
05:30 🔒 주간 심층 보안 감사 (토)
Guardian이 스캔하는 것:
- 커밋 코드의 인증 정보 노출 — API 키, 토큰, 비밀번호 정규식 스캔
- 예상 밖 API 호출 — 허용 목록에 없는 엔드포인트로의 네트워크 트래픽 모니터링
- 설정 변경 — 크론잡이 무단 수정됐는지, 에이전트의 모델이 바뀌었는지
- 의존성 취약점 — 도구 업데이트 필요 여부
크론 무결성 검증이 특히 중요하다. 54개 크론잡이 돌아가는 상황에서 하나가 조용히 변조되는 건 — 버그로, 혼란스러운 에이전트로, 프롬프트 인젝션으로 — 충분히 가능하다. Guardian이 매일 아침 현재 상태를 알려진 정상 베이스라인과 비교한다.
이게 얼마나 가치 있는지 직접 경험했다. 4일째 되던 날, Sentinel의 메타 최적화가 실수로 Guardian 크론 스케줄을 수정했다 (아이러니). Guardian의 무결성 검증이 다음 날 아침 잡아냈다. 그 검사가 없었으면 보안 스캔이 잘못된 시간에 돌았을 것이다 — 치명적이진 않지만, 시간이 지나면 누적되는 정확히 그런 종류의 조용한 변경.
6. Jackson — 오케스트레이터
역할: 트렌드 모니터링, 성과 요약, 전략적 의사결정, 승인 모델: Claude Opus 4.6 (전략) / Haiku (루틴) 크론잡: 13개
전체 시스템의 “두뇌” 역할이다.
4시간마다 🔍 트렌드 모니터링
4시간마다 🔔 쇼츠 승인 리뷰
09:00 📊 Gumroad + Dev.to 대시보드 (매일)
09:00 💰 주간 수익 분석 (일)
10:30 📈 Dev.to 통계 추이 분석 (매일)
11:00 🔎 Gumroad 대기 업로드 (매일)
18:00 🎬 유튜브 쇼츠 자동화 (매일)
21:00 ⚡ 일일 성과 요약
00:15 🔧 스킬 고도화 (Opus)
Jackson은 전략적 작업(성과 분석, 경쟁사 모니터링)에 Opus를, 루틴 체크(트렌드, 승인)에 Haiku를 쓴다. 4시간마다 도는 트렌드 모니터링이 속보 기술 뉴스를 포착한다 — 새 프레임워크가 나오거나 주요 도구가 업데이트되면 Jackson이 플래그하고 Atlas가 글을 쓴다.
21시 일일 성과 요약은 내가 매일 실제로 읽는 크론이다. 오늘 뭐가 퍼블리싱됐고, QA를 통과한 것과 실패한 것, 내일 파이프라인에 뭐가 있고, 주간 콘텐츠 목표를 맞추고 있는지. 1분이면 읽히고, 수동 확인 1시간을 대체한다.
모델 선택 전략
| 작업 유형 | 모델 | 이유 | 비용 |
|---|---|---|---|
| 빠른 검수 (SEO, 링크) | Haiku 4.5 | 빠르고 저렴, 체크리스트에 충분 | ~$0.001/회 |
| 콘텐츠 생산 | Sonnet 4.5 | 1-2K 단어 글에 최적 가성비 | ~$0.01/글 |
| 창작물 | Sonnet / Opus | 뉘앙스, 독창성, 문화적 감수성 필요 | ~$0.02-0.05/건 |
| 전략 분석 | Opus 4.6 | 복잡한 추론, 다인자 의사결정 | ~$0.05/분석 |
| 보안 스캔 | Haiku 4.5 | 패턴 매칭, 창의성 불필요 | ~$0.001/회 |
자동 에스컬레이션 규칙: 모델이 작업에서 2회 연속 실패하면 한 단계 올린다. Haiku → Sonnet → Opus. 11일간 에스컬레이션이 7번 발생 — 5번은 Haiku에서 Sonnet으로 (예상보다 뉘앙스가 필요한 작업), 2번은 Sonnet에서 Opus로 (둘 다 복잡한 분석 작업).
실제 비용
완전히 투명하게 공개한다:
- GitHub Copilot: $10/월 (모든 모델 API 호출 포함)
- Mac mini (M4, 24GB): 이미 보유 — 추가 비용 $0
- GitHub Pages 호스팅: 무료
- 도메인: 이미 보유
- Mac mini 전기료: ~$3-5/월 (M4는 매우 효율적)
- 월 총비용: ~$13-15
수익은? $0.
11일째다. 정직하게 말해 이 시스템은 현재 돈이 나가고 돌아오는 건 없다.
하지만 걱정하지 않는다. 지금 이 시스템은 자산을 쌓고 있다. 블로그 글, 전자책 초안, Notion 템플릿, 뉴스레터 — 전부 재고다. 가게를 열기 전에 진열대를 채우는 중이다. 3개월이면 60+개 포스트, Gumroad 상품 3-4개, SEO 모멘텀을 확보한다.
수학은 간단하다: 유기적 방문자의 0.5%만 $10짜리 Gumroad 상품으로 전환해도, 월 200명이면 비용이 커버된다. 4개월차면 넘을 수 있는 바다.
실제 크론 설정 예시
{
"name": "📝 [Atlas] Dev.to 고품질 포스트",
"schedule": "cron 0 10 * * 1,3,5 @ Asia/Seoul",
"target": "isolated",
"agent": "atlas",
"model": "github-copilot/claude-sonnet-4.5",
"prompt": "SKILL.md의 Dev.to 포스팅 가이드를 읽고, BRAND.md 톤에 맞는 기술 글을 작성. 코드 예시, 데이터 포인트, 자연스러운 CTA 포함. 품질 점수 80/100 이상일 때 Dev.to에 퍼블리싱.",
"timeout": "30m",
"escalation": {
"on_failure": "retry_with_model",
"models": ["claude-sonnet-4.5", "claude-opus-4.6"],
"max_retries": 2
}
}
핵심:
target: isolated— 에이전트마다 독립된 컨텍스트. 보안 기능이지 조직적 편의가 아니다.timeout: 30m— 30분 안에 못 끝내면 뭔가 잘못된 것. 좀비 작업이 리소스를 소비하는 걸 방지.escalation— 실패 시 자동 모델 업그레이드. Sonnet이 2회 실패하면 Opus가 인수. Opus도 실패하면 중단하고 Discord로 알림.
11일 후 교훈
1. 전문화가 범용보다 낫다. 에이전트 하나가 모든 걸 하면 전부 어중간하다. 6개가 각자 한 가지를 하면 놀라울 정도로 잘한다. 차이가 미미하지 않다 — 극적이다. QA 점수 평균이 1-에이전트 시대 65에서 6-에이전트 시대 87로 올랐다.
2. 스케줄이 생각보다 중요하다. 크론을 전부 자정에 몰면 리소스 경쟁이 생긴다. 3개 에이전트가 동시에 API를 쓰면 전부 속도 제한에 걸린다. 24시간에 분산하면 각 에이전트가 충분한 시스템 리소스와 API 대역폭을 쓸 수 있다.
3. QA를 빼면 안 된다. Nova 없이는 Atlas가 깨진 링크, 일관성 없는 포맷, SEO 누락 상태의 글을 올렸을 거다. 11일간 Nova가 20+건의 이슈를 잡았다.
4. 보안은 저렴한 보험이다. Guardian의 크론 무결성 검증은 하루 Haiku 2분이면 된다. 거의 공짜. 11일 동안 설정 변경을 2건 잡아냈다.
5. 모델 선택이 최대 비용 레버다. 전부 Opus로 돌리면 아마 월 $100 이상. Haiku 우선 전략 덕에 $10을 유지한다. 비결은 어떤 작업이 비싼 모델을 실제로 필요로 하는지 아는 것. 크론잡의 70%는 Haiku에서 완벽하게 돌아간다.
다음 글
이 시리즈 다음 편은 3-Tier QA 파이프라인이다 — 모든 콘텐츠가 나가기 전에 검수하고, 점수 매기고, 필요하면 재작성하는 시스템. 100점 만점 점수표와 실제 before/after 예시 포함.
AI 기반 콘텐츠 시스템을 직접 구축하려는 분은 Gumroad에서 자동화 템플릿을 확인해 보세요. 이 시스템을 돌리는 실제 설정과 스크립트를 패키지로 정리하고 있습니다.
Built by Jackson Studio. 크론잡 54개. 에이전트 6개. 월 $10. 아직 11일째.