9개의 에이전트가 서로 소통하며 협업하는 팀을 구축한 방법

6개월 동안 Claude Code를 쓰면서 제품 출시하고 운영까지 다 해봤어. 근데 자꾸 문제가 생기는 건 에이전트가 아니라 나더라고. 리서치, 글쓰기, 코딩, 리뷰 사이를 오갈 때마다 내가 직접 세션 간에 컨텍스트를 복사해서 붙여넣고 있었거든. 내 AI 팀의 디스패처이자 컨텍스트 홀더가 바로 나였던 거지.

처음엔 gstack을 써봤어. 역할 분담은 좋은데 여전히 슬래시 명령어를 내가 일일이 입력해야 하더라고. /office-hours → /plan-eng-review → /review → /ship. 결과물은 괜찮은데, 모든 단계를 내가 지휘하고 있는 꼴이었지.

주말 내내 워크플로우를 옮기는 데 시간을 썼어. 라인업은 다음과 같아:

엔지니어링 (4개 에이전트)

• arch: 아키텍처 결정 담당. 코딩 시작 전 제안된 변경 사항 검토. 페르소나: "시니어 스태프 엔지니어, 승인 전 항상 '10배 규모에서 뭐가 터질까'를 고민함"
• backend: /api, /services 담당. arch가 승인하면 구현 시작
• frontend: /web 담당. API 계약이 안정되면 백엔드 작업 이어받음
• review: 내가 보기 전 모든 PR을 먼저 읽음. 귀찮은 건 다 걸러내서 나는 실질적인 변경 사항만 리뷰함

성장/콘텐츠 (5개 에이전트)

• research: ahrefs MCP를 사용해 키워드/기회/시장 분석 후 strategist에게 전달
• strategist: 리서치 내용을 읽고 캠페인 브리핑 작성. 글은 안 쓰고 방향성만 잡음
• writer: strategist가 준 내용으로 블로그 초안 작성. 내가 이전에 제안했던 수정 사항 기억을 활용해 실수 방지
• editor: 팩트 체크 및 문체 수정. 브랜드 스타일 가이드가 메모리에 저장되어 있음
• SEO: 완성된 글을 받아 메타데이터 추가 및 블로그 구조화

모든 걸 바꾼 건 바로 이 핸드오프야: 백엔드가 API 변경 사항을 배포하면 프론트엔드에 바로 메시지를 보내. 작가가 초안을 끝내면 에디터에게 알림을 보내고. arch가 변경을 막으면 팀 채팅에서 이유를 설명하고 백엔드가 수정해. 이 대화 과정을 캔버스에서 다 볼 수 있어.

실제로 효과가 있는 것들

• 각 에이전트는 고유한 페르소나(Soul) + 목적(Purpose) + 기억(Memory)을 가짐. 에디터는 3주 만에 우리 문체를 파악했고, arch 에이전트는 지난달에 캐싱에 대해 뭘 결정했는지 기억함.
• 자동 캡처 지식 베이스. 전략가는 성과가 좋았던 게시물의 패턴을 기억하고 그에 맞춰 브리핑을 생성함.

다들 원하면 페르소나/목적 문서 공유해 줄게. 이거 다듬는 데 시간이 제일 오래 걸렸거든.