블로그 글 하나 발행하는 데 필요한 작업을 세어봤다. PayloadCMS에 글 올리고, ComfyUI로 대표 이미지 만들고, Postiz로 SNS 4개 플랫폼에 맞게 가공하고, 때에 따라 n8n 워크플로우를 건드리거나 K8s 배포를 확인해야 한다. 5개 서비스, 5개 프로젝트 디렉토리를 왔다 갔다 하는 셈이다.
이걸 하나의 대화에서 처리할 수 없을까? Claude Code의 Agent Teams 기능으로 팀 리더 에이전트가 5개 전담 에이전트를 조율하는 구조를 만들어봤다.
팀 리더가 중앙에서 5개 에이전트를 관리한다. 각 에이전트는 자기 프로젝트 디렉토리에서만 동작하고, 팀 리더가 결과를 모아서 다음 에이전트에 넘긴다.
콘텐츠 생성 쪽 에이전트(museck, comfy, postiz)는 opus 모델을 쓴다. 글 품질이나 이미지 프롬프트 작성처럼 창의성이 필요한 작업이라서다. 반면 인프라 에이전트(n8n, homelab)는 sonnet으로 충분하다. 명령 실행이 주 업무니까 비용 대비 효율이 좋다.
각 에이전트는 .claude/agents/ 디렉토리에 YAML 파일로 정의한다. museck-agent를 예로 보면 이렇다.
---
name: museck-agent
description: museck-public 블로그 콘텐츠 생성과 PayloadCMS 발행 담당
tools: Read, Write, Grep, Glob
model: opus
mcpServers:
payloadcms:
command: npx
args: ["-y", "mcp-remote", "https://museck.com/api/mcp",
"--header", "Authorization: Bearer ${PAYLOAD_MCP_API_KEY}"]
---핵심은 mcpServers 설정이다. museck-agent는 PayloadCMS MCP 서버에 직접 연결해서 글을 생성하고 발행 상태를 바꿀 수 있다. 다른 에이전트도 비슷한 구조로 각자 담당 서비스의 API나 MCP에 연결된다.
자동화의 함정은 '전부 자동'에 있다. 블로그 글에 오타가 있거나 이미지가 엉뚱하게 나오면 그대로 발행되는 거다. 그래서 사람이 개입하는 지점을 두 군데 잡았다.
첫 번째 확인 지점은 블로그 draft 단계다. museck-agent가 글을 쓰고 comfy-agent가 이미지를 만든 뒤 관리자 패널에서 미리보기한다. 수정이 필요하면 다시 museck-agent에 요청한다. 두 번째는 SNS 배포 직전이다. postiz-agent가 블로그를 트위터, 링크드인 등 플랫폼별 포맷으로 가공하면 한 번 더 확인하고 배포를 승인한다.
완전 자동 파이프라인보다 느리지만 품질을 보장할 수 있다. 나중에 신뢰도가 쌓이면 확인 단계를 줄여나갈 수도 있고.
comfy-agent가 이미지를 생성할 때만 GPU를 사용한다. RTX 5090 한 장이라 ComfyUI가 점유하면 다른 GPU 작업이 전부 막힌다. 그래서 온디맨드 패턴을 적용했다.
# 1. GPU 상태 확인
uv run comfyui_ctl.py status
# 2. GPU idle이면 ComfyUI 시작
uv run comfyui_ctl.py start
# 3. ComfyUI API로 이미지 생성
curl -X POST http://localhost:8188/prompt -d '{...}'
# 4. 완료 후 GPU 반환
uv run comfyui_ctl.py stopcomfyui_ctl.py가 GPU idle 체크부터 health check까지 전부 처리한다. 에이전트 정의 파일에 "이미지 생성 후 반드시 stop할 것"이라고 명시해두지 않으면 GPU를 물고 놓지 않는 일이 생긴다. 에이전트에게 규칙을 적어주는 게 생각보다 중요하다.
처음에는 모든 에이전트를 opus로 돌렸다. 파이프라인 한 번 실행하는 데 비용이 장난이 아니었다. n8n-agent가 하는 일은 워크플로우 트리거 한 번인데 opus를 쓸 이유가 없었다. 콘텐츠 품질이 직접적으로 영향받는 에이전트만 opus로 두고 나머지는 sonnet으로 바꿨더니 비용이 확 줄었다.
각 에이전트가 독립된 프로젝트 디렉토리에서 동작하기 때문에 서로 직접 소통이 안 된다. museck-agent가 만든 post ID를 comfy-agent에 넘겨야 하고, comfy-agent가 생성한 이미지 경로를 다시 museck-agent에 전달해야 한다. 이 중간 결과를 팀 리더가 수집하고 분배하는 허브 역할을 한다. 사실상 에이전트 간의 메시지 큐 같은 존재다.
"이미지 생성 후 GPU를 반환하세요" 같은 모호한 지시보다 "comfyui_ctl.py stop 명령을 실행하세요"가 훨씬 낫다. 에이전트 정의 파일에 구체적인 명령어와 실행 조건을 적어두니까 실수가 확 줄었다. 사람한테 업무 인수인계하는 것과 비슷하다. 문서가 구체적일수록 좋다.
멀티 에이전트 시스템 설계에서 가장 중요한 건 세 가지였다.
에이전트가 5개나 돌아간다고 해서 복잡한 게 아니다. 오히려 역할이 명확하니까 문제가 생겨도 어떤 에이전트에서 터졌는지 바로 알 수 있다. 마이크로서비스 아키텍처의 장점이 에이전트 시스템에서도 그대로 적용된다.