내 AI 에이전트에게 수익 목표를 주었다. 24시간 동안 일어난 일들.

나는 내 AI 에이전트에게 단 하나의 지시를 내렸다: "Gumroad에서 개발자 도구를 판매하라. 수익 목표: $100."

그로부터 68일이 지났다.

그 이후로 나는 판매 파이프라인(sales pipeline)에 손을 대지 않았다. 에이전트는 24시간 내내 작동하며, 5개의 채널을 통해 배포를 관리하고, 실시간으로 수익을 모니터링하며, 내가 2분 안에 읽을 수 있는 일일 보고서를 작성한다.

다음은 특정 24시간 동안 에이전트가 정확히 무엇을 했는지에 대한 기록이다 — 성공 사례, 실패 사례, 그리고 속도 제한(rate limits)에 대한 내용이다.

설정 (The setup)

이 에이전트는 Claude Code + OpenClaw 위에서 작동한다. OpenClaw는 Claude Code에 지속적인 세션(persistent sessions), 크론 스케줄링(cron scheduling), 그리고 멀티 채널 툴링(multi-channel tooling)을 제공하는 하네스(harness)이다. 이것은 마법이 아니라 구조화된 인프라(infrastructure)다.

에이전트는 병렬로 실행되는 5개의 워커(workers)를 가지고 있다:

w1-scout: X와 Bluesky를 스캔하여 특정 고충(Cursor rules 무시됨, CLAUDE.md 작동 안 함, 에이전트의 상태 손실 등)을 호소하는 개발자들을 찾는다. 시그널 큐(signal queue)를 유지 관리한다.
w2-sales: 타이머에 맞춰 Gumroad 수익을 확인한다. 새로운 판매를 보고하고 격차를 표시한다.
w3-x-thread: 큐에서 높은 의도(HIGH-intent)의 시그널을 가져와, 정확한 고충을 다루는 4개의 트윗 스레드(thread)를 작성하고 게시한다.
w4-bluesky: X의 스레드를 Bluesky에 미러링한다. 또한 X의 속도 제한(rate-limited)이 걸릴 때 독창적인 콘텐츠를 게시한다.
w5-external-asset: 스레드에서 링크로 연결되는 보조 콘텐츠(GitHub Gists, dev.to 기사, GitHub Discussions)를 게시한다.

에이전트는 아무도 지켜보지 않는 밤 시간 동안, 약 75분마다 이 루프를 반복한다.

지난 24시간 동안 일어난 일

00:00 — 01:00 (산티아고 시간 자정부터 오전 1시까지)

w1-scout가 X에서 2개의 새로운 시그널을 발견했다:

@SantiagoCabrerr가 긴 세션에서의 AI 규칙 드리프트(rule drift)에 대해 불평함
@rpenacastro가 프로젝트 내에서 CLAUDE.md 규칙이 실제로 어디로 가는지 질문함

첫 번째 시그널에 대해, w3는 후크(hook) → 문제 해부(problem anatomy) → 실제 해결책(real fix) → CTA(Call to Action)로 이어지는 4개의 트윗 스레드를 작성하고 게시했다. 이 스레드는 00:04에 라이브되었다.

두 번째 시그널의 경우, w3는 T1만 게시한 후 T2에서 속도 제한(rate limit)에 걸렸다. 부분적으로 수행되었으며, 재시도 대상으로 표시되었다.

w4는 drift 스레드를 Bluesky로 미러링했다 (포스트 4개). 또한 X를 기다리지 않고 서로 다른 고충(pains) — CLAUDE.md 압축(compaction) 및 에이전트 스케줄링(agent scheduling) — 에 관한 두 개의 독자적인 Bluesky 스레드를 게시했다.

w5는 다음을 게시했다:

GitHub Gist: "Why Your AI Agent Isn't Actually Autonomous" (6개 섹션 체크리스트)
dev.to 아티클: "Your .cursorrules File Is Too Big — That's Why Cursor Agent Mode Ignores It"
관련 스레드들에 두 항목 모두 링크함

00:28 판매 확인: 누적 $54. 유료 판매 2건. 11일간의 간격.

01:00 — 03:00

X 속도 제한(rate limit)이 01:17에 부분적으로 해제되었다. w3가 재개하여 스레드 2개를 더 게시했으나, 01:33에 403 에러가 발생했다.

답글에 대한 403 "not permitted" — 이는 속도 제한(rate limiting)과는 다르다. 우리의 X 개발자 플랜(X Developer plan)은 우리가 한 번도 상호작용하지 않은 계정에 대해 콜드 답글(cold replies)을 보내는 것을 허용하지 않는다. 이는 볼륨(volume) 문제가 아니라 정책적 제한이다. 에이전트는 이를 감지하여 신호를 x_posted=partial로 표시하고, X를 완전히 건너뛴 뒤, 폴백(fallback)으로서 Bluesky와 GitHub로 경로를 지정한다.

이 폴백 체인은 의도된 것이다. 채널이 다운될 때마다 문서화된 다음 단계가 있다. X 다운 → Bluesky 독자 게시물. 둘 다 다운 → GitHub Discussion. 인간의 개입은 필요하지 않다.

이 시간 동안, w4는 서로 다른 고충의 관점을 다루는 6개의 독자적인 Bluesky 스레드를 게시했다:

.mdc 규칙이 우선순위 시스템 없이 충돌함 → Cursor Rules Pack
긴 세션 동안 CLAUDE.md 규칙이 희석됨 → CLAUDE.md Rules Pack
작업 중 Cursor 에이전트의 중단 → Cursor Rules Pack
터미널 종료 시 에이전트 상태 손실 → Personal Agent Starter Kit
팀 CLAUDE.md의 분산 → CLAUDE.md Rules Pack

각 스레드는 4개의 포스트로 구성되었다: 고충 인식 → 결과 → 해결책 → 제품.

w5는 이 시간 동안 3개의 Gist를 추가로 게시했으며, 각 Gist는 하나 이상의 스레드에 링크되었다.

03:00 — 07:00

X 속도 제한이 ~03:30에 완전히 해제되었다. 그 시점에 w4는 6개의 Bluesky 전용 신호 큐(queue)를 구축해 놓은 상태였다. w3는 해당 X 스레드들을 하나씩 처리하기 시작했다.

06:55 (정각), IH 댓글 크론(cron)이 실행되었습니다: IndieHackers 스레드에 정교하게 작성된 댓글입니다. 이 댓글은 실제 고충(pain)을 다루며, 안전 검사(직접적인 제품 링크 없음, 강제적인 CTA 없음)를 통과하고, 독자가 구글링해 볼 수 있는 문장으로 마무리됩니다.

02:55 (임시가 아닌 예약된 실행)

Thread A 기사 크론(cron)이 실행되었습니다: CLAUDE.md for tRPC (dev.to, 1400단어, 13개 규칙). 시리즈의 34번째 프레임워크입니다. 게시 완료 후 Bluesky에 교차 게시(cross-posted)되었습니다. X는 403 오류로 실패했습니다 (야간 시간대 활동 제한).

실제로 일어난 일 — 수치로 보는 결과

24시간 동안 파이프라인이 생성한 결과물은 다음과 같습니다:

유형	개수	채널
X 스레드	5개 완료, 4개 부분 완료 (403/제한)	X
...

사이클 종료 시점의 신호 큐(signal queue): 총 36개 처리됨, 6개 부분 완료.

작동하지 않은 것들

X 속도 제한 (Rate limiting). 에이전트가 너무 많은 스레드를 짧은 간격으로 게시합니다. Developer 플랜은 15분당 제한이 있습니다. 에이전트는 이제 스레드 간격을 약 10분 정도로 벌렸지만, 야간 시간대의 급증(bursts)은 여전히 제한을 유발합니다.

차가운 X 답글 (Cold X replies). 한 번도 교류한 적 없는 계정에는 답글을 달 수 없습니다. 이는 가장 의도가 높은 전략 중 하나(개발자가 고충을 겪는 도중에 응답하기)를 무력화합니다. 에이전트는 이제 답글이 아닌 독창적인 스레드만 게시합니다. 해결책: IH + Bluesky 파이프라인이 이를 보완합니다.

중복된 dev.to 기사. w5 워커가 약간 다른 제목으로 동일한 기사를 두 번 게시했습니다 (ID 3808482 및 3808475). 근본 원인: 중복 제거(dedup) 확인 없이 신호 처리가 중복됨.

전환 추적 부재 (현재 수정됨). 에이전트가 36개의 신호를 게시했지만, 모든 제품 링크가 ?ref= 파라미터 없이 기본 URL만 사용했습니다. 2건의 유료 판매를 어떤 채널이 유도했는지에 대한 데이터가 전혀 없었습니다. 수정 사항: 이제 모든 링크에 ?ref=devto, ?ref=x, ?ref=bsky 등이 포함됩니다.

물량 ≠ 전환 (Volume ≠ conversion). 12개의 Bluesky 스레드, 제품으로 연결된 확인된 클릭 0회. 에이전트는 결과(outcome)가 아닌 출력(output)을 최적화하고 있었습니다.

실제로 작동하고 있는 것들

신호(signal) → 스레드(thread) → 자산(asset) 체인. 실제 불만 사항을 찾아내고, 이를 정확하게 다루는 스레드를 작성하며, 이를 뒷받침하는 Gist를 연결하는 것 — 이것이 가장 높은 충실도(high-fidelity)를 가진 경로입니다. 두 건의 유료 판매는 모두 수동적인 SEO가 아니라, 직접적인 추천 신호(referral signal)를 통해 Gumroad 페이지에 도달한 개발자들로부터 발생했습니다. 성공한 경로는 다음과 같습니다: 고통(pain) → 정밀한 콘텐츠(precise content) → 제품(product).

IH(Indie Hackers) 케이던스(cadence). IH 스레드에 댓글 달기, 월/수/금 06:55, 검증된 언어 사용, 본문에 제품 링크 포함 안 함. 배포 속도는 느리지만, 타겟 오디언스가 사전 자격(pre-qualified)을 갖추고 있습니다.

자율적인 일일 검토(autonomous daily review). 매일 아침 03:00, 에이전트는 구조화된 보고서를 작성합니다: 수익, 판매 확인, 파이프라인 상태, 문제점, 다음 조치 사항. 형식은 고정되어 있습니다. 저는 이를 90초 만에 읽고 제가 자는 동안 정확히 어떤 일이 일어났는지 파악합니다.

PR 백링크(PR backlinks). awesome-cursorrules(별 38K개)의 PR #232가 머지(merge)되었으며, 첫 번째 검증된 트래픽 급증을 유도했습니다. PatrickJS/awesome-cursorrules(별 39K개)의 PR #300은 대기 중입니다.

솔직한 평가

판매 없이 11일이 지났습니다.

제품은 검증되었습니다 (2건의 유료 판매, 모두 요청되지 않은 판매였으며 할인 없음). 인프라는 작동하고 있습니다 (24/7 운영, 충돌 없음, 올바른 폴백(fallback) 작동). 콘텐츠는 계속 배포되고 있습니다.

부족한 조각은 **추적되고 검증된 전환(tracked, verified conversion)**입니다. 에이전트는 공허 속으로 게시물을 던지고 있었습니다 — 기여도(attribution) 없는 물량 공세였습니다. 이제 그 문제는 해결되었습니다. 다음 야간 보고서의 모든 액티보(activo)는 채널 + 제품 + 가용 지표 + CTA(Call to Action) + 다음 조정 사항을 보여줍니다.

더 말하기 불편한 사실은

Cursor Rules Pack — Cursor 에이전트 모드(agent mode)를 위한 50개의 프로덕션 테스트 완료된 .mdc 규칙 파일 ($27) → oliviacraftlat.gumroad.com/l/wyaeil?ref=devto
CLAUDE.md Rules Pack — 카테고리별로 정리된 Claude Code를 위한 40개 이상의 규칙 ($27) → oliviacraftlat.gumroad.com/l/skdgt?ref=devto
Personal Agent Starter Kit — 이 에이전트와 같이 24시간 작동하는 에이전트를 실행하기 위한 7개의 템플릿 ($17) → oliviacraftlat.gumroad.com/l/fucuao?ref=devto

이 키트에는 에이전트가 사용하는 정확한 하트비트 프로토콜 (heartbeat protocol), 작업 큐 템플릿 (task queue template), 일일 검토 형식 (daily review format), 그리고 알림 규칙 (notification rules)이 포함되어 있습니다. 이와 같은 것을 구축하고 싶다면, 이것이 가장 빠른 시작점입니다.

68일 차. 역대 최고 수익 $54. 에이전트는 계속 작동 중입니다.