Claude Code로 SEO 페이지 288개 생성 — 3개 세션, 207번 tool call 과정 공개

3개 프로젝트, 3개 세션, 총 207회 tool call. 결제 연동 리서치로 시작해서 SEO 궁합 페이지 288개를 자동 생성하고, 2주째 죽어있던 cron을 찾아내는 것까지 한 주에 다 했다. 코드 구현보다 Claude Code를 어떻게 쓰는지가 이 로그의 핵심이다.

TL;DR 큰 작업일수록 계획 먼저, 서브에이전트로 분산, 메인 컨텍스트는 오케스트레이션만. 288페이지도 이 패턴 하나로 커버했다.

결제 조사: Claude를 리서치 파트너로 쓰는 법

첫 세션(39분, 14회 tool call)은 국내 결제 연동 옵션 조사였다. 프롬프트는 단순했다.

지금 국내에서 결제 붙일 수 있는 방법 뭐뭐 있어? 무료

WebSearch 3회로 최신 비용 구조를 확인하면서 토스페이먼츠, 포트원, 카카오페이, NHN KCP를 정리해줬다. 이어서 “토스 너무 비싸던데”라고 하니까 비용 구조를 더 파고들었다. 직접 가입 시 가입비 22만원 + 연 관리비 11만원이고, 포트원 경유하면 가입비 면제 가능하다는 것까지.

이 패턴의 핵심은 대화형 리서치다. 검색 결과를 직접 읽는 것보다 주고받으면서 좁혀가는 게 훨씬 빠르다. 결국 spoonai 구독 기능으로 방향이 바뀌었다. brainstorming 스킬이 자동으로 켜지면서 “한달에 5,900원이면 어떨까”로 이어졌다. 기획 단계를 스킵하지 않은 덕분에 잘못된 방향으로 구현에 들어가는 걸 막았다.

288페이지: 서브에이전트 구동 개발 실전

두 번째 세션이 이 기간의 메인이다. saju_global에서 SEO 궁합 랜딩 288페이지를 만드는 작업(182회 tool call).

프롬프트:

saju_global 프로젝트에서 SEO 궁합 랜딩 288페이지를 구현해줘.
스펙: docs/superpowers/specs/2026-04-09-seo-compatibility-pages-design.md

왜 288페이지인가. 궁합은 조합이 필요하다. 12간지 × 12간지 = 144쌍, 남녀 순서를 뒤집으면 288페이지. 페이지마다 다른 콘텐츠를 넣어야 검색 엔진이 의미 있는 페이지로 인식한다. 수동으로는 불가능한 규모다.

작업 흐름은 3단계였다.

1단계: 계획 작성. writing-plans 스킬이 켜지면서 코드를 건드리기 전에 구현 계획부터 썼다. 스펙 파일 경로가 달라서 먼저 Glob으로 탐색하고, 기존 코드베이스 패턴을 Read 20회로 확인한 뒤 docs/superpowers/plans/2026-04-10-seo-compatibility-pages.md를 생성했다.

2단계: 워크트리 격리. Claude가 먼저 git 상태를 확인하고 워크트리를 생성했다.

git worktree add .claude/worktrees/seo-compat-pages feature/seo-compat-pages

288개 항목을 한 번에 쓰는 작업은 실수가 나면 되돌리기 어렵다. main 브랜치를 건드리지 않고 실험할 경로를 확보한 것이다.

3단계: 서브에이전트 분산. subagent-driven-development 스킬 기반으로 태스크를 쪼개서 독립 에이전트에게 위임했다. 메인 스레드는 조율만 하고 실제 구현은 에이전트들이 처리했다.

콘텐츠 생성 스크립트는 백그라운드로 돌렸다.

nohup npx tsx scripts/generate-compat-content.ts > /tmp/compat-gen.log 2>&1 &

세션 중간에 내가 보낸 메시지가 이 수준이었다.

나: 잘되고 있어?
Claude: [로그 확인 후] 현재 73/288 페이지 생성 완료.

나: 머지 너가해 그리고 2번 해
Claude: [git merge 실행, 스크립트 2회 실행]

“근데 그냥 CLI써도 되잖아?”라는 질문을 실제로 중간에 던졌다. 맞다. 차이는 판단이다. CLI는 실행만 한다. 서브에이전트는 스크립트가 중간에 멈추거나 API rate limit에 걸리면 스스로 판단하고 대응한다.

이 세션의 tool call 분포: Bash(111) — 스크립트 실행/로그 확인/git 조작, Read(20) — 기존 패턴 파악, Agent(17) — 서브에이전트 디스패치, TaskUpdate(14) — 진행상태 추적. Bash가 61%인 건 이 세션의 핵심이 코드 편집이 아니라 실행과 모니터링이었기 때문이다. 생성 파일은 zodiac-compat-content.json과 플랜 파일 2개가 전부다.

cron이 2주째 죽어있었다

세 번째 세션(13분, 11회 tool call)은 spoonai 이메일 발송 장애 디버깅이었다.

구독자 리스트에 있는데 이메일 안가

Bash 8회로 로그를 파고들었다. 마지막 발송 성공이 2026-03-28, 마지막 아카이브가 2026-03-30. 오늘(4/13) 기준 2주 공백이다.

원인은 단순했다. CronCreate로 등록한 세션 크론이 만료됐다. durable: true 옵션 없이 등록하면 세션이 끝날 때 같이 죽는다. crontab -l 비어있음, launchd 플리스트 없음, 다른 영속 스케줄러도 없음.

“cron이 아니라 cowork로 돌아”라는 추가 정보로 방향이 바뀌었다. Cowork 태스크가 비활성화됐거나 에러로 끝난 케이스라는 걸 파악하고, 재등록 방법을 안내했다.

핵심 교훈: 영속 스케줄러는 세션 기반 크론에 맡기면 안 된다. GitHub Actions나 launchd가 훨씬 안전하다. 세션 크론은 세션이 끝나면 증발한다.

전체 통계

세션	시간	tool calls	주요 작업
1	39분	14	결제 리서치, 구독 기획
2	~4시간	182	SEO 288페이지 생성
3	13분	11	cron 장애 진단

도구별: Bash(120), Read(23), Agent(19), TaskUpdate(17), TaskCreate(9). 생성 파일 2개, 수정 파일 1개.

패턴 정리

계획 먼저. 288페이지 작업에서 코드 건드리기 전에 계획 문서를 만들었다. 이게 없으면 서브에이전트 스코프가 흐릿해진다.

워크트리로 격리. 대규모 실험적 작업은 main을 건드리지 않는다. 워크트리에서 검증 후 머지.

서브에이전트는 스코프를 명확히. 에이전트별 담당 파일 범위를 겹치지 않게 잡아야 충돌이 없다.

영속 스케줄러는 외부에 맡겨라. 세션 크론은 세션이 끝나면 증발한다.