670 tool calls, 48시간: 치과 블로그 이미지 파이프라인을 4 라운드로 S급 만든 기록

48시간 30분, 670 tool calls. 단일 세션 기준 역대 최대다. 목표는 하나였다 — 치과 블로그 이미지 25장을 S급 수준으로 자동 생성하는 파이프라인을 만드는 것.

TL;DR: 서브에이전트 3개를 병렬 교차검증에 투입하고, Gemini Pro/Flash를 이미지 품질에 따라 분기했다. 4 라운드를 돌아야 AI 티 9점이 나왔다. 스킬 파일이 살아있는 문서가 돼야 파이프라인이 진화한다.

”spoonai” 한 단어 프롬프트가 만든 38분 세션

세션 1은 프롬프트 한 단어로 시작했다.

spoonai

Claude는 메모리에서 두 개의 관련 프로젝트를 찾고 뭘 원하는지 물었다. 이후 추가 지시가 들어왔다.

일단 디자인 고도화할 수 있는 부분이 있는지 확인해주고,
번역기능 완벽하게 되도록 수정해줘,
구글에서 검색 / AI가 검색하고 광고가 잘되도록 전략/기술 모두 적용해줘

한 번에 세 개 도메인(디자인, 번역, SEO)을 요청했다. Claude는 Explore 에이전트 3개를 병렬로 던져 현황을 파악했다. 결과가 돌아오자 핵심 버그를 발견했다.

lib/content.ts:133의 getPostSlugs()가 !f.includes("-en")으로 영어 파일을 전부 필터링하고 있었다. getAllPosts("en")이 빈 배열을 반환하니 /posts/..-en URL이 전부 404였다. 번역이 “제대로 안 되는” 진짜 원인은 UI가 아니라 콘텐츠 로딩 로직이었다.

38분, 133 tool calls. Edit 63회, Bash 37회, Read 27회. 수정된 파일만 22개.

670 tool calls의 48시간: 치과 블로그 파이프라인

두 번째 세션이 본편이다.

목표는 네이버 S급 치과 블로그 3편(임플란트 뼈이식, 잇몸질환, 소아치과)을 위한 자동 이미지 생성 파이프라인이었다. 각 포스트당 25장. 텍스트 카드 6장 + 3D 의료 일러스트 6장 + 실사진 활용 카드들.

멀티에이전트 교차검증 패턴

품질 검증은 항상 별도 컨텍스트에서 했다. 프롬프트는 반복적으로 이 패턴이었다.

별도의 컨텍스트 기준으로 평가하고
래퍼런스 s급들과의 비교해줘
3개 정도가 교차 검증해줘

라운드마다 3개 에이전트를 병렬로 투입했다. 역할은 고정이었다.

SEO/알고리즘 검증 에이전트
의료 정확성 + 퀄리티 검증 에이전트
S급 디자인/비주얼 기준 검증 에이전트

같은 파일을 다른 관점에서 동시에 보게 하면 메인 컨텍스트가 오염되지 않는다. 에이전트 결과는 점수표 형태로만 올라온다. “001 임플란트: SEO 7/10, 의료법 9/10, 비주얼 8/10” — 이 수준의 요약만 보면 된다.

Gemini Pro/Flash 라우팅

초기엔 단순히 Gemini로 이미지를 생성했다. 라운드 2에서 지시가 명확해졌다.

d로 하는데 pro랑 flash 필요한 그림 퀄리티에 따라 다르게 써줘

분기 기준은 이미지 타입이었다. 의료 일러스트(해부학, 치조골 단면, 임플란트 식립 과정) → Gemini 2.0 Pro. 텍스트 카드(히어로, FAQ, CTA, 면책고지) → Gemini 2.0 Flash. Pro는 품질이 높지만 느리고 비싸다. 카드형 이미지에 Pro를 쓰는 건 낭비다.

pipeline.py의 build_template_variables()에 이 분기 로직이 들어갔다. 파일명 패턴으로 타입을 판단하고 모델을 선택한다.

라운드 1→4: AI 티 9점까지

라운드 1의 가장 큰 문제는 3D CGI 스타일이었다. 파란 글로우, 과장된 광택, 로봇 같은 질감. AI 티 점수 평균 6~7점.

라운드 2에서 viewport 버그를 잡았다. HTML 템플릿의 body height: 860px 고정인데 hero 캡처 clip height=1075 → 히어로 이미지 하단 215px이 흰 배경. 텍스트 카드 로고 이중 노출 버그도 수정했다.

라운드 3에서 의료 일러스트 스타일을 Gray’s Anatomy 교과서 스타일로 전환했다. 3D CGI → 단순화된 해부학 일러스트. AI 티 점수가 8~9점으로 올라갔다.

라운드 4는 최종 튜닝이었다.

ai 티 9점이상이여야할 것 같아

에이전트 3개가 같은 25장을 독립적으로 채점했다. 점수가 수렴하면 통과. 점수가 벌어지면 가장 낮은 항목을 파악하고 수정. 최종 결과물: 25장 평균 AI 티 점수 9.1점.

스킬 파일이 살아있는 문서가 돼야 한다

이 세션에서 naver-dental-blog/SKILL.md와 dental-blog-image-pipeline/SKILL.md가 7번 업데이트됐다. 작업마다 배운 것을 즉시 스킬에 반영했다.

지금까지 작업 스킬 업데이트하고, 남은 작업 뭐야? 진행해

스킬 업데이트를 “나중에”로 미루면 다음 세션에서 처음부터 다시 학습한다. 세션 내에서 발견한 S급 기준, 실패한 프롬프트 패턴, 버그 수정 사항을 그 자리에서 스킬에 적어야 파이프라인이 누적된다.

라운드를 거치며 pipeline.py에 추가된 것들:

parse_image_tags() —  태그 파서
build_template_variables() — 파일명 기반 Pro/Flash 분기
CTA 카드 차별화 — 같은 CTA 템플릿이 반복 사용되지 않도록 파일명 기반 분기
viewport 고정 → HTML 템플릿 전체에 overflow: hidden 적용

삽질: 1차 2차 3차 왜 있어?

세션 중반에 이런 질문이 나왔다.

1차 2차 3차가 왜 있어?

파이프라인에 재시도 루프가 3개였던 건 초기 설계 실수였다. 이미지 생성 API가 가끔 실패하면 재시도하는 로직이 필요했지만, 코드가 항상 3번 돌게 돼 있었다. 성공해도 3번 실행, 실패해도 3번. 수정 후: 1회 성공하면 종료, 실패 시에만 재시도.

롤백: 직전 버전이 나을 때

라운드 5 근처에서 전면 리디자인이 들어갔다.

[Image #9] 이거는 바로 직전버전이 더 나은데? 롤백해

Claude는 git을 쓰지 않았다. 에이전트가 파일을 직접 수정했기 때문에 git history가 없었다. 백업을 만들지 않은 상태에서 전면 리디자인을 돌리면 이전 버전으로 돌아갈 수 없다.

이 세션의 가장 비싼 실수다. 파이프라인이 파일을 덮어쓰기 전에 .bak 백업을 만들거나, 각 라운드 결과를 별도 디렉토리에 저장하는 로직이 필요했다.

Edit 없이 670 tool calls

670 tool calls 중 Edit은 거의 없다. Bash로 Python 스크립트를 실행하고, Agent로 서브에이전트를 띄우고, Write로 파일을 통째로 교체했다. 코드 수정보다 파이프라인 실행과 검증이 대부분이었다.

에이전트를 쓸 때 중요한 건 스코프 지정이다. “3개 파일을 독립적으로 채점하라”는 지시에서 3개 에이전트는 같은 파일을 각자 읽고 평가한다. 파일 수정 범위가 겹치지 않으면 병렬 실행이 안전하다. 이 세션에서는 검증 에이전트들이 읽기만 했기 때문에 충돌이 없었다.