AgentCrow + 261 tool call로 치과 블로그 이미지 파이프라인을 고도화한 기록

3개 세션, 454번 tool call. 기간은 2026-04-06부터 2026-04-14까지다. 가장 무거운 세션은 세션 2였다. 25시간짜리 세션에서 261번 tool call. 치과 블로그 이미지 파이프라인을 반복 고도화했다.

TL;DR 치과 블로그 24장 이미지를 자동 생성하는 파이프라인을 AgentCrow로 병렬화하고, “스킬 수정 → 재실행 → 스크린샷 피드백” 루프로 반복 개선했다. 스킬과 실제 코드를 동기화하지 않으면 다음 세션에서 처음부터 시작해야 한다는 걸 뼈저리게 배웠다.

”최악이야” — 그게 시작이었다

세션 2의 첫 피드백이 이거였다.

“최악이야 결과물, 이전에 스킬 고도화 한거 어디갔어?”

이전 세션에서 고도화한 내용이 SKILL.md에만 있고 pipeline.py에는 반영이 안 됐던 것. 스킬 문서와 실제 구현이 따로 놀고 있었다. 이게 이 세션의 핵심 패턴을 만들었다. 수정 → 재실행 → 스크린샷 확인 → 다시 수정. 이 루프를 수십 번 돌렸다.

AgentCrow 패턴: 3개 에이전트 동시 디스패치

분석/글쓰기/이미지 작업이 독립적으로 진행될 수 있어서 AgentCrow로 병렬화했다.

🐦 AgentCrow — dispatching 3 agents:
1. @skill-updater → SKILL.md 사진 카테고리 7종 반영
2. @blog-enhancer → 001 임플란트 블로그 글 전문성 고도화
3. @blog-reader → 002/003 블로그 구조 분석 (고도화 기준점)

002번 블로그(충치치료)를 S급 기준점으로 삼고, 001번(임플란트)을 거기 수준으로 올리는 게 목표였다. @blog-reader가 분석한 결과가 명확했다. 002번이 최적 구조(이미지-텍스트 균형, 심리적 훅, 전문성 시그널 모두 우수), 001번 문제는 텍스트 과잉에 이미지 8장뿐, 훅 없음, 실사 사진 전무. 이 분석 결과를 기반으로 001번을 이미지 24장짜리로 올렸다.

에이전트별 역할 분담이 명확할수록 결과가 좋다. 각자 스코프가 겹치지 않고, 서로의 결과물에 의존하지 않는 구조면 동시 디스패치가 의미있다.

스크린샷이 프롬프트다

이 세션에서 가장 효과적인 피드백 방법은 스크린샷을 직접 첨부하는 것이었다.

“[Image #28] 이건 과하잖아.”

로고 크기가 너무 커서 스크린샷 찍어서 첨부했다. 그냥 “로고가 너무 커”보다 훨씬 정확하다. 이미지를 직접 보면 얼마나 축소할지 판단이 된다. 또 다른 피드백:

“[Image #29] 그림 무조건 한글 들어가게 해줘. 그리고 배경 제대로 다른 걸로 해줘 지금 이상해”

이 한 줄이 두 가지 수정으로 이어졌다. pipeline.py에 한글 라벨 강제 로직 추가, 배경색을 웜 베이지에서 순백(#ffffff)으로 변경. 텍스트 설명으로 전달하기 어려운 시각적 맥락을 스크린샷 한 장이 대신했다.

파이프라인 5번 연속 실패

Background command가 exit code 2로 5번 연속 터졌다. 원인은 매번 달랐다. 한글 폰트 경로 문제, Gemini 모델 버전 불일치, 캐시 덮어쓰기 로직 충돌. 캐시 삭제 + 재실행 패턴으로 최종 안정화했다. 매 수정 때마다 캐시를 날리고 파이프라인을 다시 돌리는 방식.

실패했을 때 에러 로그를 Claude에게 그대로 붙여주면 원인 파악이 빠르다. “파이프라인이 또 안 돼”보다 로그 전체를 던지는 게 낫다.

배경색 4번, 로고 3번

배경색만 4번 바꿨다.

기본 흰색 #ffffff
웜 베이지 #f5f0eb (전체 통일감 위해)
약한 하늘색 #f0f4ff (다른 느낌 시도)
다시 순백 #ffffff (최종)

로고 크기도 3번 바뀌었다. 처음엔 너무 컸다. “지금 사이즈의 반”으로 줄였더니 너무 작았다. “지금 사이즈의 2배”로 올렸다. 매번 SKILL.md에 반영했다. 스킬이 실제 코드와 동기화되지 않으면 다음 세션에서 다시 처음부터다. 이미 세션 시작에서 그 대가를 치렀으니까.

이미지 분할: 1단계 = 1장

6단계 임플란트 시술 과정을 2단계씩 묶어서 3장으로 만들었더니 피드백이 왔다.

“너무 한 장에 정보가 많아. 한 장에 합치지 말고 과정을 각각으로 나눠줘.”

결과: 3장 → 6장. 이미지당 정보량이 절반으로 줄었다. 스크롤할수록 다음 단계가 자연스럽게 보이는 구조가 됐다. 이 규칙을 SKILL.md에 박았다. “과정 이미지는 1단계 = 1장.”

수정 피드백이 생길 때마다 스킬에 규칙으로 고정하는 것이 핵심이다. 그렇지 않으면 같은 피드백을 다음 세션에서 또 받는다.

5개 에이전트 병렬 품질 평가

“전체적인 톤이 통일되지 않았다”는 피드백이 나왔다. 텍스트 톤, 디자인, SEO, 이미지 품질, 광고 효과 — 동시에 5개 관점이 필요한 상황이었다. 에이전트 5개를 병렬 디스패치했다.

Agent "블로그 톤/문체 평가"     → 어미 통일성 8/10, AI 클리셰 6건 발견
Agent "블로그 시각 디자인 평가" → 색상 통일성 6/10
Agent "블로그 콘텐츠/SEO 평가"  → 키워드 밀도, 구조 분석
Agent "블로그 이미지 품질 평가" → 종합 8.2/10
Agent "블로그 광고효과 평가"    → CTA 효과 8/10

색상 통일성이 6/10으로 가장 낮았다. 카드마다 배경색이 달랐다. 7개 템플릿 파일의 body background를 일괄 통일하고, pipeline.py에서 색상 팔레트를 하드코딩했다. 하나의 피드백이 동시에 여러 파일을 수정하는 작업으로 이어질 때, 병렬 평가 → 우선순위 결정 → 병렬 수정 패턴이 효율적이다.

세션 3: 288페이지를 스크립트 하나로

saju_global 프로젝트에서 SEO 궁합 랜딩 288페이지 구현. 프롬프트가 이거였다.

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

Writing Plans 스킬로 구현 계획 먼저 작성, Subagent-Driven Development 스킬로 실행했다. 288페이지를 하나씩 만들 수는 없다. generate-compat-content.ts 스크립트 하나로 전체를 생성하는 방식을 택했다. 실행은 백그라운드로 돌리고, 로그로 진행 상황을 확인했다.

태스크별 독립 에이전트를 디스패치하면서 git worktree를 별도로 만들어 main 브랜치를 건드리지 않고 작업했다. 182번 tool call 중 Bash가 111번이었다. 생성 스크립트 반복 실행과 로그 확인이 대부분이다.

세션 1: 2주간 멈춘 cron

spoonai 프로젝트. 마지막 성공 발송이 2026-03-28. 2주간 이메일이 발송 안 됐다. 원인은 CronCreate 세션 cron 만료였다. durable: true 없이 등록했던 것. crontab -l은 비어있고, launchd 플리스트도 없었다.

교훈은 명확하다. 스케줄러 등록할 때 durable: true 명시. Cowork로 돌아가는 태스크는 Cowork 대시보드에서 직접 상태 확인. 2주 후에야 발견된 건 모니터링 부재 때문이다.

세션별 통계

세션	날짜	시간	Tool calls
spoonai cron 디버깅	04-13	13h 43min	11
uddental 이미지 고도화	04-06	25h 5min	261
saju SEO 288페이지	04-09	105h 43min	182

도구별 합계: Bash(174), Read(138), Agent(41), Edit(35), Grep(20), 총 454.

세션 2의 Read 138회가 눈에 띈다. 에이전트들이 동일 파일을 반복 읽는 비용이다. 에이전트 스코프를 좁게 주고, 필요한 파일만 명시적으로 넘기면 이 수를 줄일 수 있다.