Claude를 활용한 멀티 에이전트 워크플로우 구축: 1인 스튜디오 플레이북
요약
Claude를 활용해 여러 에이전트를 병렬로 실행하고 결과물을 병합하는 멀티 에이전트 워크플로우를 소개합니다. 단일 에이전트의 선형적 한계를 극복하고 작업 시간을 6시간에서 90분으로 단축하는 실전 전략을 다룹니다.
핵심 포인트
- 에이전트를 완성된 제품이 아닌 가공되지 않은 재료로 취급
- 병렬 처리를 통해 아이디어 공간의 다양한 관점 확보
- 단순 병렬 실행보다 출력물을 통합하는 병합(Merge) 전략이 핵심
- 서로 다른 제약 조건을 부여하여 에이전트 간 분산(Variance) 유도
-
동시에 초안을 작성하는 3개의 병렬 작가 에이전트 덕분에 블로그 작업 시간이 6시간에서 90분으로 단축되었습니다.
-
리서치 에이전트(Research agents)는 병렬로 실행된 후, 중복되는 내용의 40%를 제거하는 중복 제거(dedup) 단계를 거쳐 병합됩니다.
-
이미지 사양(Image-spec) 에이전트는 하나를 써보고 운에 맡기는 대신, 제가 순위를 매길 수 있는 12개의 프롬프트 변형(prompt variants)을 생성합니다.
-
병렬 처리(Parallelism)보다 병합(Merge) 전략이 더 중요합니다. 잘못된 병합은 모든 에이전트의 출력물을 낭비하게 만듭니다.
저는 크리에이티브 스튜디오를 혼자 운영합니다. 팀도, 계약직도 없습니다. 오직 저와 팀처럼 행동하는 Claude 에이전트 스택뿐입니다. 지난달 저는 22개의 블로그 포스트, 60개의 이미지 컨셉, 그리고 단 한 명의 작가라면 감당하지 못했을 방대한 리서치 백로그(backlog)를 완료했습니다. 비결은 더 빨리 일하는 것이 아니었습니다. 에이전트들을 병렬로 실행하고 그들의 출력물을 잘 병합하는 것이었습니다.
1인 운영자에게 병렬 처리가 순차 처리보다 나은 이유
단일 에이전트가 블로그 포스트를 작성하는 것은 병목 현상(bottleneck)을 일으킵니다. 에이전트는 선형적(linearly)으로 생각합니다. 초기에 하나의 관점에 몰두하며, 좀처럼 생각을 바꾸지 않습니다. 한 에이전트에게 1,800단어 분량의 기사를 써달라고 요청했을 때, 저는 일관성은 있지만 평이한 결과물을 얻었습니다. 구조는 항상 똑같았고, 예시들은 항상 안전한 것들뿐이었습니다.
그래서 저는 한 명의 에이전트에게 모든 일을 맡기는 것을 그만두었습니다. 대신 세 명의 작가 에이전트를 동시에 가동합니다. 각 에이전트에게는 동일한 브리프(brief)를 주되 서로 다른 제약 조건을 부여합니다. 에이전트 A는 회의론자들을 위해 글을 씁니다. 에이전트 B는 초보자들을 위해 글을 씁니다. 에이전트 C는 데이터 우선 방식으로, 모든 문단에 숫자를 포함하여 글을 씁니다. 이들은 동시에 실행됩니다. 저는 예전에 하나를 만드는 데 걸리던 시간 동안 세 개의 완전한 초안을 얻습니다.
수치가 이를 증명합니다. 저의 편집과 재작성을 포함하여 하나의 순차적 초안(sequential draft)을 만드는 데는 약 6시간이 걸렸습니다. 세 개의 병렬 초안(parallel drafts)에 병합 단계(merge pass)를 더하면 90분이 걸립니다. 이것은 작은 이득이 아닙니다. 일주일에 포스트 2개를 발행하느냐, 8개를 발행하느냐의 차이입니다.
병렬 처리 (Parallelism)가 효과적인 이유는 분산 (Variance) 때문입니다. 각 에이전트는 아이디어 공간 (Idea space)의 서로 다른 영역을 탐색합니다. 세 가지 초안을 모두 읽을 때, 저는 어떤 프레이밍 (Framing)이 실제로 효과적인지 파악할 수 있습니다. 초안 B는 최고의 도입부를 가질 수 있고, 초안 C는 남겨둘 가치가 있는 유일한 예시를 포함할 수도 있습니다. 초안 A는 제가 통째로 가져다 쓸 만한 구조를 가지고 있을 수도 있습니다. 저는 더 이상 단 하나의 에이전트가 완벽하게 해내기를 바라지 않습니다. 대신 펼쳐진 결과물들 중에서 가장 좋은 부분들을 골라냅니다.
이 방식은 에이전트를 완성된 제품이 아닌 가공되지 않은 재료 (Raw material)로 취급할 때만 작동합니다. 세 가지 초안 중 그 어느 것도 있는 그대로 발행되지 않습니다. 병렬 에이전트들의 출력물 (Output)은 병합 (Merge) 단계의 입력물 (Input)이 되며, 그 병합 단계에서 실제 기사가 탄생합니다.
제가 실행하는 전체 설정을 알고 싶다면, Claude Blueprint에서 제가 매일 사용하는 에이전트 구성 (Agent configuration)을 단계별로 확인할 수 있습니다. 요약하자면 이렇습니다. 브리프 (Brief)를 한 번 정의하고, 이를 세 갈래로 나누어(Fork), 동시에 실행하며, 단일 에이전트의 첫 번째 직관이 최종 답변이 되도록 내버려 두지 마십시오.
작가 에이전트 패턴과 브리핑 방법
세 명의 작가가 동시에 돌아간다는 것은 혼란스럽게 들릴 수 있습니다. 하지만 그렇지 않습니다. 브리프 (Brief)가 그 역할을 수행하기 때문입니다. 저는 주제, 단어 수, 규칙, 그리고 독자를 포함한 하나의 마스터 브리프 (Master brief)를 작성합니다. 그런 다음 에이전트마다 달라지는 단 한 줄을 추가합니다. 그 한 줄이 모든 차이를 만듭니다.
실제 사례는 다음과 같습니다. 작가 A에게는 "가장 강력한 반론을 먼저 제시하고 이를 해체하라"라는 지침을 줍니다. 작가 B에게는 "독자가 이 일을 한 번도 해본 적이 없다고 가정하고, 모든 용어를 설명하라"라고 합니다. 작가 C에게는 "모든 주장에는 숫자나 구체적인 예시가 필요하며, 추상적인 문장은 배제하라"라고 지시합니다. 주제는 같지만, 완전히 다른 세 개의 기사가 나옵니다.
브리프의 나머지 요소들은 모두 공유됩니다. 톤 (Tone) 규칙, 금지어, 구조, 길이 등입니다. 저는 이 요소들을 하나의 파일에 보관하여 한 곳에서 업데이트할 수 있도록 합니다. 규칙을 변경하면 다음 실행 시 세 명의 작가 모두가 변경된 규칙을 상속받습니다. 이는 영리한 관점(Angle)을 설정하는 것보다 더 중요합니다. 에이전트 간의 일관성 (Consistency)이 있어야만 병합 (Merge)이 가능해집니다. 만약 세 에이전트가 톤 (Tone)에 대해 서로 의견이 다르다면, 병합 과정은 결국 재작성 (Rewrite)이 되어버립니다.
또한 저는 각 작가(Writer)에게 결과물을 반환하기 전에 반드시 통과해야 하는 품질 게이트(Quality gate)를 부여합니다. 단어 수가 범위 내에 있는지, 금지된 문구는 없는지, 네 개의 섹션과 맺음말이 포함되었는지 등을 확인합니다. 만약 에이전트의 초안이 이 게이트를 통과하지 못하면, 결과물을 넘겨주기 전에 스스로 수정(Self-corrects)합니다. 덕분에 저는 망가진 초안 세 개를 읽어야 하는 수고를 덜 수 있습니다. 저는 Claude Blueprint에서 이 자기 점검 루프(Self-checking loop) 아이디어를 다룬 적이 있는데, 이는 제가 올해 수행한 작업 중 신뢰성(Reliability) 측면에서 가장 큰 업그레이드였습니다.
출력물 순위 선정은 수동으로 빠르게 진행합니다. 저는 약 4분 만에 세 가지 초안을 모두 훑어봅니다. 가장 좋은 도입부, 가장 좋은 세 가지 사례, 가장 좋은 구조, 그리고 가장 좋은 맺음말에 태그를 답니다. 가끔은 한 에이전트가 모든 면에서 승리할 때도 있는데, 드물지만 아주 기분 좋은 일입니다. 보통은 혼합된 형태입니다. 작가 C의 수치, 작가 A의 프레이밍(Framing), 작가 B의 어려운 부분에 대한 설명과 같은 식입니다.
한 가지 주의사항이 있습니다. 동일한 브리프(Brief)에 대해 3~4개 이상의 작가를 실행하지 마세요. 한 번은 8개를 시도해 본 적이 있습니다. 추가된 초안들은 처음 세 개가 이미 다루고 있는 내용 외에 아무것도 더해주지 못했고, 저는 변동성(Variance)의 가치보다 읽는 데 더 많은 시간을 소비했습니다. 관점의 다양성에는 수확 체감(Diminishing returns)이 존재합니다. 세 개의 날카로운 제약 조건이 여덟 개의 모호한 조건보다 언제나 더 낫습니다.
병렬 조사 에이전트와 중복 제거 문제 (The Dedup Problem)
조사(Research) 단계는 병렬 처리(Parallelism)가 복잡해지는 지점입니다. 동일한 질문에 대해 세 명의 조사 에이전트를 보내면, 이들은 엄청난 중복을 가지고 돌아옵니다. 그중 두 명은 동일한 출처를 인용하고, 세 명 모두 똑같이 뻔한 점을 언급합니다. 만약 제가 단순히 그들의 출력물을 쌓아 놓기만 한다면, 똑같은 사실을 세 번 읽게 되고 문서의 길이는 이득 없이 세 배로 늘어납니다.
따라서 조사 패턴에는 작가 패턴에는 필요 없는 중복 제거(Dedup) 단계가 필요합니다. 저는 의도적으로 서로 다른 범위(Scope)를 설정하여 조사 에이전트를 실행합니다. 한 명은 넓게 접근하여 주제 전체를 조사합니다. 한 명은 제가 중요하다고 표시한 단일 하위 주제를 깊게 파고듭니다. 또 한 명은 구체적으로 반례(Counterexamples)와 예외 사례(Edge cases)를 찾아냅니다. 범위를 분할하면 중복이 발생하기 전에 이를 줄일 수 있습니다.
범위가 지정된 에이전트(Scoped agents)를 사용하더라도 중복은 실제로 발생합니다. 그래서 세 번째 에이전트가 반환한 후, 오직 중복 제거(Dedup)와 병합(Merge)만을 수행하는 네 번째 에이전트를 실행합니다. 이 에이전트는 세 가지 연구 결과물(Research dumps)을 모두 가져와 하나의 깔끔한 문서를 생성합니다. 이 에이전트의 지침은 매우 직설적입니다. 두 번 이상 언급된 사실은 모두 제거할 것. 두 에이전트의 의견이 다를 경우, 둘 다 유지하고 충돌(Conflict)을 표시할 것. 발견 사항을 어떤 에이전트가 찾았느냐가 아니라 주제별로 그룹화할 것. 각 주장에는 가장 강력한 출처를 인용하고, 더 약한 중복 인용은 삭제할 것.
해당 중복 제거 에이전트는 일반적으로 결합된 연구 분량을 약 40% 정도 줄여줍니다. 각각 약 2,000단어 정도인 세 개의 결과물이 6,000단어의 반복 문구가 되는 대신, 3,600단어의 단일 참조 문서가 됩니다. 더 중요한 것은, 충돌 사항이 묻히는 대신 표면 위로 드러난다는 점입니다. 두 에이전트가 사실에 대해 의견이 다를 때, 그 불일치는 제가 확인해야 할 신호이지, 평균을 내어 없애버려야 할 소음이 아닙니다.
'충돌 표시(Flag-conflicts)' 규칙은 사람들이 건너뛰는 부분이자 가장 중요한 부분입니다. 단순한 병합(Naive merge)은 조용히 한 가지 버전만을 선택하며, 이로 인해 두 출처가 서로 달랐다는 사실을 영영 모르게 됩니다. 저의 병합 방식은 두 가지를 모두 유지하고 표시를 남깁니다. 그런 다음 제가 인간으로서 최종 결정을 내립니다. 그것은 제가 위임하기를 거부하는 단 하나의 판단입니다. 왜냐하면 발행된 기사 속의 자신 있게 틀린 사실은, 쉽게 다시 쌓을 수 없는 신뢰를 앗아가기 때문입니다.
저는 모든 병합된 연구 문서를 저장하여, 나중에 작가 에이전트(Writer agents)들이 이를 가져다 쓸 수 있도록 합니다. 이렇게 된 연구는 여러 기사에 걸쳐 재사용이 가능합니다. 한 주제에 대한 양질의 병합 과정 한 번이 향후 세 개 또는 네 개의 포스트로 이어집니다. 배경 지식: Claude Blueprint에서는 에이전트들이 사실을 지어내는 대신 실제 발견 사항을 참조할 수 있도록, 연구 저장소(Research store)를 작가 브리프(Writer briefs)에 어떻게 연결하는지 다룹니다.
이미지 사양 에이전트(Image-Spec Agents) 및 시각적 출력 병합
이미지는 제가 병렬 에이전트(Parallel agents)를 마지막으로 추가한 분야이며, 이는 시각적 작업에 대한 제 사고방식을 완전히 바꾸어 놓았습니다. 예전에는 이미지 프롬프트를 하나 쓰고, 생성하고, 마음에 들지 않으면 다시 쓰는 방식을 반복했습니다. 느리고 좌절스러운 과정이었죠. 이제 저는 한 번의 실행으로 12개의 프롬프트 변형(Prompt variants)을 생성하는 이미지 사양 에이전트(Image-spec agents)를 실행하며, 추측하는 대신 순위를 매깁니다.
사양 에이전트(Spec agents)는 이미지를 생성하지 않습니다. 대신 상세한 프롬프트(Prompts)를 생성합니다. 각 에이전트는 기사의 주제를 가져와 서로 다른 시각적 접근 방식을 가진 네 가지 프롬프트 변형(Prompt variants)을 만들어냅니다. 하나는 추상적(Abstract)이고, 하나는 사실적(Literal)이며, 하나는 에디토리얼(Editorial) 스타일이고, 마지막 하나는 미니멀(Minimal) 스타일입니다. 세 명의 에이전트가 각각 네 개의 변형을 생성하면, 총 12개의 프롬프트가 테이블 위에 놓이게 됩니다. 저는 이들을 읽고 가장 강력한 세 개를 선택한 다음, 실제 렌더링(Render)과 업스케일(Upscale)을 위해 Magnific로 보냅니다.
생성하기 전에 프롬프트의 순위를 매기는 것이 이 과정의 핵심입니다. 생성(Generation)은 시간과 인내심이 많이 드는 비용이 큰 단계입니다. 12개의 프롬프트를 읽는 데는 2분이 걸리지만, 12개의 이미지를 생성하고 이를 판단하는 데는 40분이 걸립니다. 따라서 저는 판단의 시점을 비용이 저렴한 텍스트 단계로 앞당기고, 이미 확신이 있는 세 개의 프롬프트에만 생성 노력을 투입합니다.
여기서의 병합(Merge) 문제는 연구 분야와는 다릅니다. 프롬프트의 경우 저는 사실 관계의 중복을 제거하는 것이 아니라, 시각적 유사성(Visual sameness)을 피하는 것입니다. 만약 12개의 프롬프트가 모두 다른 단어를 사용하면서 동일한 구도를 설명한다면, 얻은 것이 아무것도 없습니다. 그래서 저는 사양 에이전트들에게 강력하게 분기(Diverge)하도록 지시합니다. 서로 다른 카메라 각도, 서로 다른 색상 이야기(Color stories), 서로 다른 추상화 수준을 갖도록 말이죠. 브리프(Brief)에는 다른 변형들과의 차이점을 명시적으로 보상하도록 설정되어 있습니다.
저는 실제로 사용된 이미지를 생성해낸 프롬프트 구조들을 계속 파일로 기록해 둡니다. 60개 이상의 이미지 컨셉을 거치며, 제 브랜드의 경우 사실적인(Literal) 변형보다 에디토리얼(Editorial) 및 미니멀(Minimal) 변형이 훨씬 더 자주 채택된다는 것을 배웠습니다. 그래서 이제는 에이전트들이 이 두 가지 방향으로 가중치를 두도록 설정합니다. 이러한 병렬 패턴은 피드백 루프(Feedback loop)를 형성합니다. 모델이 바뀌어서가 아니라, 제가 무엇이 효과적이었는지 추적하기 때문에 에이전트들이 더 나아지는 것입니다.
이는 이미지 너머에도 적용됩니다. '실행 전 순위 매기기(Rank-before-execute)' 로직은 비용이 많이 드는 모든 후속 단계에 적용될 수 있습니다. 만약 결과물인 그래픽을 여러 채널에 예약 게시한다면, 저는 Buffer를 사용하여 고정된 주간 그리드에 맞춰 게시함으로써 병렬적인 프런트엔드(Front end) 작업이 백엔드(Back end)의 게시 병목 현상을 일으키지 않도록 합니다. 저렴하게 생성하고, 빠르게 순위를 매기며, 승자에게만 실행하십시오.
핵심 요약 (Bottom Line)
병렬 처리 (Parallelism)는 어려운 부분이 아닙니다. 세 명의 에이전트를 가동하는 것은 명령어 하나면 충분합니다. 진짜 어려운 부분은 병합 (Merge)이며, 이 병합 단계에서 1인 스튜디오가 규모를 확장하느냐 아니면 침몰하느냐가 결정됩니다. 잘못된 병합은 모든 에이전트의 결과물을 낭비하게 만들고, 당신이 똑같은 소음만 세 번 읽게 만듭니다. 반면 훌륭한 병합은 세 개의 거친 초안을 하나의 날카로운 기사로, 6페이지의 조사 자료를 하나의 깔끔한 참조 자료로, 그리고 12개의 프롬프트를 실제로 렌더링할 수 있는 3개의 프롬프트로 탈바꿈시킵니다.
이 패턴은 글쓰기, 조사, 이미지 생성 모두에서 동일하게 적용됩니다. 하나의 브리프 (Brief)를 몇 개의 날카롭게 다른 제약 조건으로 분기(Fork)시키십시오. 그것들을 동시에 실행하십시오. 그런 다음 병합에 당신의 진짜 주의력을 집중하십시오: 중복 제거 (Dedup), 순위 매기기 (Rank), 충돌 표시 (Flag conflicts), 그리고 가장 좋은 부분 선택하기입니다. 에이전트는 원재료를 만들고, 당신은 결정을 내립니다.
이 모든 과정의 뒤에 숨겨진 구성을 알고 싶다면, Claude Blueprint에서 제가 매주 사용하는 브리프, 게이트 (Gates), 그리고 병합 단계를 설명해 두었습니다. 다음 포스팅부터 세 명의 작가 에이전트로 시작해 보십시오. 그 단 한 번의 변화가 기사당 4시간 반을 아껴주었으며, 가장 쉽게 시작할 수 있는 지점입니다.
이 기사에는 제휴 링크가 포함되어 있습니다. 이 링크를 통해 가입하시면, 귀하에게 추가 비용 부담 없이 저에게 소정의 수수료가 지급될 수 있습니다. (광고)
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기