블로그 글을 에이전트 팀으로 나눠 쓰기 — 리서처·라이터·이미지메이커·어셈블러

Claude Code에 “이 주제로 블로그 글 하나 써줘”라고 시켜본 사람이면 익숙한 패턴이 있습니다. 첫 글은 꽤 괜찮습니다. 두세 번 고쳐 달라고 하면 더 좋아집니다. 그런데 열 번째 글쯤 되면 톤이 미묘하게 달라져 있고, 어느 순간부터는 앞에서 “이렇게 써 달라”고 했던 지시를 모델이 슬그머니 놓고 갑니다.

더 곤란한 건 무엇이 잘못됐는지 특정하기 어렵다는 점입니다. 문체가 문제인지, 인용한 자료가 부실한 건지, 제목·소제목 구조가 검색에 안 맞는 건지, 이미지가 본문과 따로 노는 건지. 한 대화 안에서 리서치와 집필과 SEO 판단과 이미지 제작이 전부 섞여 있으니 원인을 분리할 수가 없습니다. 그래서 매번 “전체적으로 좀 더 잘 써줘” 같은 두루뭉술한 재요청을 하게 되고, 결과도 두루뭉술하게 흔들립니다.

이 글은 그 문제를 역할을 파일로 쪼개서 푸는 방법을 정리한 것입니다. 근거는 데키랩 채널의 클로드로 블로그 에이전트 팀 구축 영상(33분, 유료강의 무료공개분)에서 제시된 구축 순서입니다. 미리 밝히면 저희가 이 팀을 실제로 구축해 장기간 운영해본 기록은 아직 없습니다. 아래 내용은 영상에서 소개된 절차와 각 도구의 공개된 동작을 기준으로 정리한 것이고, 저희 판단이 섞인 대목은 판단이라고 따로 표시했습니다.

왜 하나가 아니라 여럿으로 나누는가

핵심 이유는 맥락 오염입니다. 한 세션에서 리서치도 하고 글도 쓰고 이미지도 만들면, 앞에서 주고받은 대화가 전부 뒤 작업의 배경 맥락으로 남습니다. 리서치하다 나온 잡다한 정보, 중간에 폐기한 초안, “이 문장은 빼자”던 대화가 모델의 판단에 계속 영향을 줍니다. 그래서 같은 지시를 줘도 세션마다 결과가 다릅니다.

역할을 분리하면 세 가지가 달라집니다. 원 영상이 정리한 이점 그대로입니다.

1. 결과물 일관성 — 각 에이전트는 자기 지침 파일과 필요한 입력만 봅니다. 앞 단계의 대화 찌꺼기를 물려받지 않습니다.
2. 문제 지점만 골라 수정 — 문체가 이상하면 스타일 가이드만, 자료가 부실하면 리서처 지침만 고칩니다. 전체를 다시 튜닝하지 않아도 됩니다.
3. 규칙 변경이 한 파일에서 끝남 — 플랫폼 SEO 규칙이 바뀌면 seo-guide.md 하나만 갱신하면 이후 모든 글이 따라옵니다.

세 번째가 실무에서 가장 큽니다. 글 30편을 쓴 뒤에 “제목 규칙이 바뀌었다”는 상황이 오면, 프롬프트에 규칙이 흩어져 있는 방식에서는 손댈 곳을 찾는 것부터 일입니다.

팀 구성: 가이드 2장 + 에이전트 4명

전체 구조는 여섯 개 마크다운 파일입니다. 앞의 두 개는 규칙을 담은 참조 문서고, 뒤의 네 개가 실제로 일하는 역할입니다.

파일	역할	입력	출력
style-guide.md	문체 기준	기존 글 3편 분석	어투·문장 길이·구조 패턴
seo-guide.md	플랫폼 규칙	플랫폼 SEO 리서치	제목·본문 구조·키워드·이미지 수·해시태그·금지사항
researcher.md	자료 수집	주제 한 줄	출처 URL이 붙은 리서치 노트
writer.md	본문 집필	리서치 + 스타일 + SEO	이미지 자리 마커가 들어간 초안
image-maker.md	이미지 제작	본문의 이미지 마커	HTML/CSS로 만든 캡처 이미지
assembler.md	최종 조립	초안 + 이미지	발행용 md + HTML 미리보기

만드는 순서가 중요합니다. 가이드 → 테스트 → 에이전트 → CLAUDE.md 순으로 가야 하고, 특히 마지막 CLAUDE.md를 먼저 쓰면 고생합니다. 이유는 뒤에서 설명합니다.

1. 스타일 가이드는 설명하지 말고 글을 첨부해서 뽑는다

첫 파일은 문체입니다. 여기서 흔히 하는 실수가 말로 설명하는 것입니다. “친근하지만 전문적인 톤으로”, “너무 딱딱하지 않게” 같은 표현은 사람에게도 모호한데 모델에게는 더 그렇습니다.

영상이 제시하는 방법은 기존에 내가 쓴 글 3편을 첨부해 분석시키는 것입니다. 형용사 대신 실제 샘플을 근거로 주는 방식입니다.

첨부한 글 3편은 제가 직접 쓴 블로그 글입니다.
이 글들에서 반복되는 제 문체 패턴을 분석해 style-guide.md로 정리해주세요.

분석에 포함할 것:
- 문장 길이와 어미 패턴 (실제 문장을 예시로 인용할 것)
- 단락 길이, 소제목을 쓰는 방식
- 자주 쓰는 표현 / 절대 안 쓰는 표현
- 독자를 부르는 방식, 존댓말 수준
- 도입부와 마무리의 전형적인 형태

조건: 다른 AI 에이전트가 이 파일 하나만 읽고도
같은 톤으로 글을 쓸 수 있을 만큼 구체적으로 작성할 것.
추상적인 형용사 대신 규칙과 예시 문장으로 쓸 것.

마지막 조건이 핵심입니다. 이 파일은 사람이 읽으려고 만드는 게 아니라 다른 에이전트가 실행 규칙으로 쓰기 위한 것이므로, “따뜻한 톤”이 아니라 “문장은 평균 40~60자, 단정 대신 ‘~라고 봅니다’로 끝냄” 수준까지 내려가야 재현이 됩니다.

2. SEO 가이드는 기준일을 박아서 리서치시킨다

두 번째 파일은 플랫폼 규칙입니다. 검색 노출 규칙은 자주 바뀌므로 모델의 학습 데이터에 의존하면 낡은 정보가 섞입니다. 그래서 기준일을 명시해 최신 자료를 찾게 합니다.

네이버 블로그 SEO 규칙을 2026년 7월 기준 최신 자료로 리서치해
seo-guide.md 가이드 문서로 만들어주세요.

포함할 항목:
- 제목 작성 규칙 (길이, 키워드 위치)
- 본문 구조 (소제목 개수, 문단 길이, 최소 글자 수)
- 키워드 배치 (밀도, 반복 위치)
- 이미지 최소 개수와 배치 원칙
- 해시태그 개수와 선정 기준
- 하면 안 되는 것 (저품질 판정 요인)

각 항목마다 근거 출처 URL을 함께 적어주세요.
확인되지 않은 항목은 "미확인"으로 표시하고 추측해서 채우지 마세요.

티스토리든 워드프레스든 플랫폼명만 바꾸면 같은 방식으로 뽑을 수 있습니다.

여기서 저희 판단을 하나 덧붙입니다. SEO 가이드는 리서치 결과물이지 사실 확정본이 아닙니다. 검색 알고리즘 규칙은 공식 문서보다 블로그 경험담이 많이 돌아다니는 영역이라, 모델이 찾아온 내용에 근거 없는 통념이 섞이기 쉽습니다. 위 프롬프트에서 출처 URL과 “미확인” 표기를 요구한 이유가 이것입니다. 출처가 개인 블로그뿐인 항목은 규칙이 아니라 참고로 취급하는 게 안전합니다.

3. 여기서 멈추고 테스트한다

가이드 두 개를 만든 다음 바로 에이전트를 만들지 않습니다. 이 두 파일만으로 테스트 글을 한 편 써보고, “내가 쓴 것 같을 때까지” 가이드를 고치는 반복을 먼저 끝냅니다.

이 단계를 건너뛰면 안 되는 이유는 명확합니다. 뒤에 만들 라이터·이미지메이커·어셈블러가 전부 이 두 파일 위에 쌓이기 때문입니다. 토대가 흔들리는 상태에서 위에 층을 올리면, 나중에 결과가 마음에 안 들 때 원인이 가이드인지 에이전트 지침인지 구분이 안 됩니다.

체감상 확정 신호는 단순합니다. 생성된 글을 읽었을 때 손볼 곳이 사실관계뿐이고 문장을 다시 쓰고 싶은 충동이 안 들면 그 가이드는 쓸 만한 상태입니다.

4. 리서처: “출처 없는 정보는 적지 말 것”

이제 에이전트입니다. 첫 번째는 리서처고, 이 파이프라인에서 환각 차단이 걸리는 유일한 지점입니다.

이유는 구조에 있습니다. 라이터는 리서처가 넘긴 노트를 검증 대상이 아니라 이미 확인된 사실로 취급합니다. 리서처 단계에서 들어온 근거 없는 문장 하나가 다음 단계에서는 자연스러운 본문 문장이 되고, 그 뒤로는 아무도 의심하지 않습니다. 그래서 지침에 이 규칙을 못 박습니다.

# researcher.md

## 역할
주어진 주제에 대해 최신 자료를 수집하고 리서치 노트를 작성한다.

## 절대 규칙 (반드시 준수)
- 검색으로 확인한 내용만 기록한다.
- 모든 항목에 출처 URL을 반드시 붙인다.
- 출처를 댈 수 없는 정보는 적지 않는다. 추측으로 채우지 않는다.
- 수치·날짜·가격은 출처 페이지에 그대로 적힌 값만 옮긴다.
- 자료를 못 찾은 항목은 비워두고 "자료 없음"이라고 적는다.
  빈칸으로 두는 것이 잘못된 정보보다 낫다.

## 출력 형식
- 핵심 사실 목록 (각 줄 끝에 출처 URL)
- 인용할 만한 원문 문장 (출처 명시)
- 상충하는 주장이 있으면 양쪽 다 기록하고 상충한다고 표시
- 자료를 못 구한 항목 목록

마지막의 “빈칸으로 두는 것이 잘못된 정보보다 낫다”는 문장이 실제로 효과가 있습니다. 모델은 기본적으로 요청받은 형식을 채우려는 경향이 있어서, 빈칸을 허용한다고 명시하지 않으면 그럴듯한 값으로 메꿉니다.

저희 판단을 하나 더 붙이면, 출처 URL은 리서치 노트에만 남기지 말고 최종 본문에도 링크로 남기는 편이 낫습니다. 발행 후에 수치가 틀렸다는 지적을 받았을 때 어디서 온 값인지 되짚을 수 있어야 하고, 독자 입장에서도 검증 가능한 글이 더 신뢰를 받습니다.

5. 라이터: “반드시 준수”를 여러 번 쓴다

라이터는 입력이 세 개입니다. 리서치 노트, 스타일 가이드, SEO 가이드.

영상에서 강조하는 실무 포인트가 하나 있습니다. 참고 문서를 그냥 첨부하면 모델이 “참고사항” 정도로 취급하고 무시한다는 것입니다. 그래서 지침 안에서 “반드시 준수”를 여러 번 반복해 강제성을 명시합니다.

# writer.md

## 입력 (세 개 모두 반드시 읽을 것)
1. research/{주제}.md — 리서치 노트
2. style-guide.md — 문체 규칙 (반드시 준수)
3. seo-guide.md — SEO 규칙 (반드시 준수)

## 작성 규칙
- style-guide.md의 문체 규칙을 반드시 준수한다. 참고가 아니라 준수다.
- seo-guide.md의 구조·키워드·분량 규칙을 반드시 준수한다.
- 리서치 노트에 없는 사실은 쓰지 않는다.
  노트에 "자료 없음"인 항목은 본문에서도 다루지 않는다.
- 수치는 노트에 적힌 값을 그대로 쓴다. 반올림하거나 각색하지 않는다.

## 이미지 자리
본문에 이미지가 필요한 위치에 아래 형식의 마커를 남긴다.
[IMAGE: 타입 | 담을 내용 요약]
예: [IMAGE: 비교표 | A안과 B안의 비용·기간·난이도 비교]

이미지 마커를 라이터가 남긴다는 점이 설계상 중요합니다. 어떤 그림이 필요한지는 본문 맥락을 아는 쪽이 판단해야 하기 때문입니다. 이미지메이커에게 “알아서 어울리는 이미지를 만들어라”라고 하면 본문과 겉도는 장식이 나옵니다.

6. 이미지메이커: 외부 API 대신 HTML/CSS + 캡처

가장 응용 가치가 큰 부분입니다. 이미지 생성 API를 쓰지 않고 HTML/CSS로 코딩한 뒤 Playwright로 스크린샷을 찍는 방식을 씁니다.

# 예시 구조 — HTML을 렌더링해 PNG로 캡처
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page(viewport={"width": 800, "height": 600},
                            device_scale_factor=2)
    page.goto("file:///.../card.html")
    page.locator(".card").screenshot(path="out/card-01.png")
    browser.close()

이 방식의 장점은 결정적(deterministic)이라는 것입니다. 생성형 이미지 모델은 같은 프롬프트로도 매번 다른 그림을 내놓지만, CSS는 같은 코드에서 항상 같은 결과가 나옵니다. 블로그처럼 글이 계속 쌓이는 매체에서는 이 일관성이 품질보다 중요할 때가 많습니다.

두 가지 제약을 지침에 넣습니다.

• 템플릿을 4종으로 제한 — 비교표, 단계 다이어그램, 포인트 카드, 인용 박스. 자유롭게 만들게 두면 글마다 스타일이 달라집니다. 라이터가 남긴 마커의 타입이 이 넷 중 하나로 매핑됩니다.
• 자체 검수·재생성 루프 — 캡처한 이미지를 스스로 확인해 텍스트가 박스 밖으로 넘쳤는지, 여백이 무너졌는지 점검하고 문제가 있으면 CSS를 고쳐 다시 찍게 합니다.

# image-maker.md 중 검수 규칙 발췌

캡처 후 반드시 이미지를 열어 확인한다.
- 텍스트가 잘리거나 박스를 넘쳤는가
- 좌우 여백이 비대칭인가
- 글자가 너무 작아 읽기 어려운가
하나라도 해당하면 CSS를 수정해 다시 캡처한다. 최대 3회 반복.
그래도 해결되지 않으면 해당 이미지를 건너뛰고 사유를 기록한다.

이 패턴은 블로그 밖에서도 그대로 쓰입니다. 카드뉴스, 상세페이지 배너, 썸네일처럼 같은 틀에 내용만 바뀌는 이미지는 전부 같은 구조로 찍어낼 수 있습니다.

7. 어셈블러와 발행

어셈블러는 초안과 이미지를 합쳐 최종 마크다운을 만들고, 여기에 발행 플랫폼 레이아웃과 비슷한 HTML 미리보기를 함께 생성합니다. 발행 전에 실제로 어떻게 보일지 확인하기 위한 용도입니다.

네이버 블로그의 경우 외부에서 글을 자동 발행하는 경로가 막혀 있어, 마지막 발행은 복사·붙여넣기로 사람이 합니다. 파이프라인이 초안까지만 책임지는 구조라는 뜻입니다.

8. CLAUDE.md는 맨 마지막에, 짧게

프로젝트 지침 파일인 CLAUDE.md는 모든 에이전트를 확정한 다음 맨 마지막에 씁니다. 분량도 세 줄 수준이면 충분합니다.

# 블로그 에이전트 팀

목적: 주제 한 줄을 받아 리서치 → 집필 → 이미지 → 조립까지 처리한다.
폴더: agents/(역할 지침) guides/(스타일·SEO) research/ drafts/ images/ output/
메인 세션은 분배만 한다. 직접 리서치하거나 글을 쓰지 않는다.

순서를 지켜야 하는 이유는 단순합니다. 에이전트 구성이 아직 흔들리는 상태에서 CLAUDE.md를 먼저 자세히 써두면, 역할을 하나 조정할 때마다 이 파일도 같이 고쳐야 합니다. 폴더 이름 하나 바꿨을 뿐인데 지침이 어긋나 있는 상황이 반복되면 수정 부담만 커집니다.

마지막 줄의 “메인 세션은 분배만 한다”도 실질적인 규칙입니다. 이걸 안 적어두면 메인 세션이 답답함을 못 이기고 직접 리서치를 시작하는데, 그 순간 맥락 분리라는 설계 전체가 무의미해집니다.

9. 통합 테스트와 병렬 운영

전부 만들었으면 새 세션을 열어 주제 한 줄만 던져 끝까지 굴러가는지 봅니다. 기존 세션에서 테스트하면 구축 과정의 대화가 맥락에 남아 있어서, 지침 파일 덕분에 잘 된 건지 대화 덕분에 잘 된 건지 구분이 안 됩니다.

여러 편을 동시에 쓸 때는 세션을 병렬로 띄웁니다. 파일 기반이라 각 세션이 같은 지침을 읽고 각자의 산출물 폴더에 쓰는 구조면 충돌 없이 굴러갑니다.

점수: 8.3

특정 도구가 아니라 이 구축 방식 자체에 대한 점수입니다. 저희가 이 팀을 구축해 실제로 글을 양산해본 것은 아니고, 영상에서 제시된 절차와 각 도구의 공개된 동작을 기준으로 매긴 점수입니다.

좋은 점

• 문제의 원인을 특정할 수 있게 됩니다. 문체가 이상하면 스타일 가이드, 사실이 틀렸으면 리서처 지침으로 바로 갑니다. “전체적으로 더 잘 써줘”라는 재요청이 사라집니다.
• 규칙 변경이 한 파일에서 끝납니다. SEO 규칙이 바뀌어도 seo-guide.md만 고치면 이후 글 전체가 따라옵니다.
• 스타일 가이드를 글 3편 첨부로 뽑는 방법이 특히 실용적입니다. 문체를 말로 설명하려는 시도보다 정확하고, 만드는 데 몇 분 안 걸립니다.
• 이미지를 HTML/CSS로 만드는 선택이 일관성 면에서 유리합니다. 생성형 이미지의 매번 달라지는 결과와 달리 같은 코드가 같은 결과를 냅니다. 이 부분만 떼어 카드뉴스·썸네일 양산에 옮겨도 값을 합니다.
• 고객사별로 팀을 복제하기 쉬운 구조입니다. 스타일 가이드와 SEO 가이드만 갈아끼우면 나머지는 그대로 재사용됩니다.

아쉬운 점

• 초기 구축 비용이 작지 않습니다. 파일 여섯 개에 중간 테스트 반복까지 하면 몇 시간 단위입니다. 글 몇 편 쓰고 말 거면 그냥 한 세션에서 쓰는 게 빠릅니다.
• 환각이 줄지 없어지지는 않습니다. 리서처의 출처 규칙은 입력 단계를 막아줄 뿐이고, 라이터가 노트를 재해석하며 뉘앙스를 바꾸는 것까지는 못 막습니다. 최종 사실 확인은 결국 사람 몫입니다.
• 파이프라인이 길어 실패 지점 추적에 신경 써야 합니다. 중간 산출물(리서치 노트·초안·이미지)을 전부 파일로 남기지 않으면 어느 단계에서 틀어졌는지 못 찾습니다.
• 이미지 템플릿 4종 제한은 일관성과 다양성을 맞바꾸는 선택입니다. 시각적 임팩트가 중요한 콘텐츠에는 부족할 수 있습니다.
• 마지막 발행 구간이 수작업으로 남습니다. 네이버는 자동 발행 경로가 막혀 있어 복붙이 필요하고, 편수가 늘면 이 구간이 병목이 됩니다.
• SEO 가이드의 신뢰도가 리서치 품질에 종속됩니다. 검색 규칙은 공식 문서보다 경험담이 많이 도는 영역이라 검증 없이 규칙으로 굳히면 위험합니다.

이럴 때 쓰세요: 같은 톤으로 글을 꾸준히 쌓아야 하는 블로그를 운영하거나, 여러 고객의 블로그를 대행해 톤만 바꿔 복제할 구조가 필요할 때. 반대로 한 편 한 편이 다 다른 성격의 글이거나 총 분량이 열 편 안쪽이면 구축 비용을 회수하기 어렵습니다.

주의사항 — 양산 자체가 목적이 되면 안 됩니다

마지막은 저희 판단입니다. 이런 파이프라인을 만들면 “하루에 몇 편 뽑을 수 있나”로 목표가 옮겨가기 쉽습니다. 그 방향으로 가면 검색엔진과 광고 플랫폼 양쪽에서 문제가 생깁니다. 독자에게 실질적 가치가 없는 대량 생성 콘텐츠는 검색 정책상 저품질로 분류되는 대상이고, 애드센스 심사 기준에서도 마찬가지입니다.

그래서 이 구조는 초안 속도를 올리는 장치로 쓰는 게 맞습니다. 리서치·구조·이미지처럼 시간을 잡아먹는 반복 작업을 파이프라인이 처리하고, 사람은 확보한 시간을 사실 확인과 자기 경험 추가에 씁니다. 실제로 써보고 알게 된 것, 실패한 사례, 남들이 안 쓰는 숫자는 어떤 에이전트도 만들어내지 못합니다. 그 부분이 빠진 글은 아무리 빨리 뽑아도 남지 않습니다.

발행 전 최소 점검 항목만 정리하면 이렇습니다.

• 본문의 모든 수치·날짜에 출처가 있고, 그 출처를 직접 열어 확인했는가
• 리서치 노트에서 “자료 없음”이던 항목이 본문에 슬쩍 채워져 있지 않은가
• 이미지의 텍스트가 잘리거나 넘치지 않았는가
• 이 글에만 있는 내용(직접 해본 것, 실패담, 판단)이 최소 한 단락은 있는가