레슨 4: 협업 패턴: 파이프라인, 리뷰, 투표

학습 목표:

• 파이프라인, 프로듀서-리뷰어, 다관점 투표가 실제로 어떻게 동작하는지 구분하기
• 주어진 과제에 어떤 패턴이 맞는지 판단하고, 각각의 비용 프로파일을 짚기
• 핸드오프식 협업과 오케스트레이터-서브에이전트식 협업 사이에서 누가 제어권을 쥐는지의 핵심 차이를 이해하기

전제: 레슨 3을 마쳤고, 자기완결적이고 범위가 분명한 위임 프롬프트를 편하게 쓸 수 있다 | 이전: 레슨 3 << | 다음: 레슨 5 >>

지난 두 레슨의 오케스트레이터-서브에이전트 구조는 하나의 형태입니다. 중앙 노드가 과제를 쪼개고, 여러 서브에이전트가 병렬로 작업하며, 그 결과가 다시 병합됩니다. 하지만 여러 에이전트를 엮는 방법이 이것만 있는 것은 아닙니다. 이 레슨에서는 좀 더 구체적인 세 가지 협업 패턴 — 파이프라인, 프로듀서-리뷰어, 다관점 투표 — 을 다루며, 각각이 어디에 맞고 비용이 어디로 가는지 살펴본 다음, 오케스트레이터-서브에이전트와는 완전히 다른 아이디어로 돌아가는 네 번째 협업 방식, 즉 제어권을 아예 넘겨 버리는 방식을 다룹니다.

파이프라인: 한 단계 뒤에 또 한 단계, 각각 앞 단계를 먹고 자란다

파이프라인(프롬프트 체이닝): "Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one."¹ (프롬프트 체이닝은 과제를 여러 단계의 연속으로 분해하고, 각 LLM 호출이 이전 호출의 출력을 처리합니다.) 파이프라인과 오케스트레이터-서브에이전트의 가장 큰 차이는 이것입니다. 오케스트레이터-서브에이전트는 병렬 구조입니다 — "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results."¹ (중앙 LLM이 동적으로 과제를 분해해 워커 LLM에게 위임하고 그 결과를 종합합니다.) 파이프라인은 엄격하게 한 단계 뒤에 또 한 단계입니다 — 다음 단계는 이전 단계가 끝나기 전에는 시작할 수 없고, 그 이전 단계의 출력을 곧바로 자기 입력으로 받습니다.

제품 출시 블로그 글을 예로 들어 보겠습니다. 이것을 세 단계로 쪼갤 수 있습니다. 초안을 쓰고, 그 초안을 다른 언어로 번역하고, 번역본에서 용어가 일관성 없게 쓰인 곳이 없는지 점검하는 것입니다. 2단계의 입력은 1단계의 출력이고, 3단계의 입력은 2단계의 출력이며, 어느 것도 앞질러 혼자 시작할 수 없습니다. 이 형태는 자연스러운 순서를 지닌 과제, 즉 다음 단계가 정말로 이전 단계의 결과 없이는 진행될 수 없는 과제에 맞습니다. 세 회사의 가격을 조사하는 일이 정말로 독립적인 덩어리로 쪼개지는 것과 달리, 파이프라인의 모든 단계는 그 앞 단계에 의존합니다.

프로듀서-리뷰어: 하나가 쓰고, 하나가 뜯어보고, 반복한다

프로듀서-리뷰어(평가자-최적화자): "one LLM call generates a response while another provides evaluation and feedback in a loop."¹ (한 LLM 호출이 응답을 생성하고, 다른 하나가 루프 안에서 평가와 피드백을 제공합니다.) 파이프라인과의 핵심 차이는 그 루프입니다. 파이프라인은 정해진 단계들을 훑고 멈추지만, 프로듀서-리뷰어는 초안, 리뷰어의 피드백, 피드백에 맞춘 수정, 다시 리뷰로 돌아가며, 리뷰어가 만족할 때까지(또는 미리 정한 최대 라운드 수에 도달할 때까지) 멈추지 않습니다. 몇 라운드가 걸릴지는 보통 사전에 알 수 없습니다.

예를 들어, 한 에이전트에게 결제 로직을 다루는 코드를 쓰게 하고, 다른 에이전트는 그 코드가 엣지 케이스를 놓치지 않았는지 — 음수 금액, 동시성 상황에서의 중복 제출 — 만 확인하는 일을 맡깁니다. 리뷰어 에이전트가 문제를 발견하면 코드는 프로듀서 에이전트에게 돌아가 한 번 더 다듬어지고, 다시 리뷰어에게 돌아가며, 리뷰어가 뚜렷한 문제를 더는 보지 못할 때까지 이어집니다. 이 형태는 "일을 잘했는가"를 한 번에 정확히 판단할 수 없어, 수렴하기까지 반복적인 다듬기가 필요한 과제에 맞습니다. 첫 버전이 최종본인 경우는 드뭅니다. 리뷰 단계는 전달 전에 뚜렷한 문제를 잡아내고 프로듀서가 한 번 더 수정하도록 밀어붙이기 위해 존재합니다.

다관점 투표: 하나의 대상에 대한 여러 독립 판단

다관점 투표: 여러 에이전트가 릴레이로 단계를 밟아 처리하는 것이 아니라, 각자 같은 내용을 독립적으로 판단합니다. 공식 예시는 코드 보안 리뷰입니다. "Reviewing a piece of code for vulnerabilities, where several different prompts review and flag the code if they find a problem."¹ (한 코드의 취약점을 리뷰하는데, 여러 다른 프롬프트가 코드를 검토하고 문제를 발견하면 표시합니다.) 여기서 "여러 다른 프롬프트"는 각자 같은 코드를 독립적으로 보며, 어느 것도 다른 것의 판단에 의존하지 않습니다. 한 프롬프트라도 문제를 표시하면 코드는 표시되고 좀 더 자세히 볼 가치가 생깁니다.

이 패턴은 프로듀서-리뷰어와 다릅니다. 투표는 초안-후-수정 루프가 아니라, 이미 존재하는 하나의 내용을 여러 에이전트가 병렬로 독립적으로 판단하는 것입니다. 목표는 여러 다른 각도에서 점검해 놓칠 확률을 낮추는 것이지, 반복적인 편집으로 내용을 더 낫게 만드는 것이 아닙니다. 이 방식은 문제를 흘려보내느니 몇 번의 호출을 더 쓰는 편이 나은 상황에 맞습니다 — 보안 리뷰와 컴플라이언스 점검에서는 진짜 문제를 놓치는 비용이 보통 토큰 몇 개보다 훨씬 큽니다.

셋 중 고르기, 그리고 비용이 어디로 가는가

세 패턴은 비용 구조가 다르므로, 실제 상황에 대고 계산해 보며 고르세요.

• 파이프라인: 총비용은 대략 각 단계에 걸친 호출들의 합입니다. 단계 수는 고정적이고 예측 가능하지만, 실행이 엄격하게 순차적이라 총 지연은 모든 단계의 시간을 더한 것이므로 빠르지는 않습니다. 단계 간 의존이 분명하고 각 단계의 범위가 꽤 작은 과제에 좋습니다.
• 프로듀서-리뷰어: 비용은 수렴하기까지 몇 라운드가 걸리는지에 달려 있고, 그 라운드 수는 불확실합니다. 프로듀서와 리뷰어가 한 번 주고받기에 빠지면 비용이 예상을 크게 넘어설 수 있습니다 — 그래서 이 패턴은 보통 루프에 최대 라운드 상한이 필요하며, 끝없이 도는 것을 막습니다. 첫 버전이 아마 충분치 않아 반복적인 다듬기가 필요한 과제에 좋습니다.
• 다관점 투표: 비용은 대략 단일 리뷰 비용에 투표하는 에이전트 수를 곱한 것입니다 — 곧이곧대로의 곱셈이므로 에이전트 N개면 비용도 N배입니다. 놓치는 대가가 크고 더 넓은 커버리지를 위해 더 많이 지불할 의향이 있는 과제에 좋고, 내용 자체가 그리 위험하지 않은 비용 민감 상황에는 맞지 않습니다.

고르려면 과제 자체의 형태로 돌아오세요. 단계의 자연스러운 순서가 있는가? 그렇다면 파이프라인을 고려하세요. 출력 품질이 충분해지기까지 반복적인 다듬기가 필요한가? 그렇다면 프로듀서-리뷰어를 고려하세요. 문제를 놓치는 대가가 여러 각도에서 점검할 만큼 큰가? 그렇다면 다관점 투표를 고려하세요. 이 셋은 상호 배타적인 것도 아닙니다 — 하나의 전체 워크플로가 고정된 파이프라인을 훑으면서 그중 한 단계 안에 프로듀서-리뷰어 루프를 중첩할 수 있습니다. 레슨 6에서 바로 이런 조합을 직접 만들어 봅니다.

또 다른 협업 방식: 제어권을 아예 넘겨 버리기

지금까지의 패턴들은 한 가지를 공유합니다. 오케스트레이터(또는 파이프라인의 연결 노드)가 전체를 계속 책임지고, 서브에이전트는 끝나면 결과를 돌려줄 뿐 핸들을 쥐고 다음에 무엇이 올지 지시하지 않습니다. 하지만 협업에는 완전히 다른 아이디어가 있습니다 — 핸드오프: "Handoffs: Peer agents hand off control to a specialized agent that takes over the conversation. This is decentralized."² (핸드오프: 동료 에이전트들이 대화를 넘겨받는 전문 에이전트에게 제어권을 넘깁니다. 이것은 탈중앙적입니다.)

핸드오프와 오케스트레이터-서브에이전트의 핵심 차이는 누가 제어권을 쥐는가만이 아닙니다 — 넘겨받는 에이전트가 보는 정보의 양이 완전히 다르다는 점도 있습니다. 문서는 명시적입니다. "When a handoff occurs, it's as though the new agent takes over the conversation, and gets to see the entire previous conversation history."³ (핸드오프가 일어나면 새 에이전트가 대화를 넘겨받는 것과 같으며, 이전 대화 이력 전체를 보게 됩니다.) 그것이 기본 동작이고, 새 에이전트가 이력을 얼마나 볼지 바꾸는 입력 필터 같은 설정 옵션이 있습니다. 이것은 레슨 2와 3의 서브에이전트 메커니즘과 정반대입니다. 서브에이전트는 신선하고 격리된 컨텍스트에서 시작해 이전 대화를 보지 못하지만⁴, 핸드오프의 수신 에이전트는 기본적으로 이력 전체를 봅니다. 왜냐하면 하나의 격리된 과제를 하고 결과를 돌려주도록 파견되는 것이 아니라, 진짜로 대화를 넘겨받아 그 지점부터 사용자나 다음 단계와 이어 가기 때문입니다.

이 차이가 각 방식이 어떤 상황에 맞는지 결정합니다. 오케스트레이터-서브에이전트는 독립적인 서브태스크 한 묶음을 갈라내어 각자 결론을 돌려주고 중앙 노드가 전체를 계속 책임지는 데 맞습니다. 핸드오프는 대화가 진행되면서 더 전문화된 에이전트가 여기서부터 맡아야겠다고 깨닫고, 대화 전체를 온전히 넘겨주는 경우에 맞습니다 — 예컨대 고객 지원에서 일반 지원 에이전트가 사용자의 문제가 환불과 관련된다고 판단해 대화 전체를 환불 전문 에이전트에게 넘기면, 사용자는 문제를 처음부터 다시 설명하지 않아도 됩니다. 다만 이 제어권 이전은 여전히 하나의 실행 안에서 일어납니다. "Handoffs stay within a single run."³ (핸드오프는 하나의 실행 안에 머뭅니다.)

정리

• 파이프라인은 과제를 순서에 의존하는 고정 단계들의 사슬로 쪼개어 각 단계가 이전 단계의 출력을 처리한다¹. 자연스러운 순서가 있고 일을 되돌려 보낼 필요가 없는 과제에 좋다.
• 프로듀서-리뷰어는 초안 쓰기, 피드백 받기, 수정, 다시 리뷰의 루프로 수렴할 때까지 돈다¹. 출력 품질에 반복적인 다듬기가 필요한 과제에 좋고, 비용이 라운드 수에 좌우되므로 보통 최대 라운드 상한이 필요하다.
• 다관점 투표는 여러 에이전트가 같은 내용을 병렬로 독립적으로 판단하고, 어느 한 각도라도 문제를 찾는 즉시 표시한다¹. 놓치는 대가가 크고 넓은 커버리지를 위해 몇 배의 비용을 지불하는 상황에 좋으며, 비용은 대략 단일 실행 비용에 판단하는 에이전트 수를 곱한 것이다.
• 셋 중 고르려면 과제의 형태를 보라. 단계의 자연스러운 순서가 있는가, 반복적인 다듬기가 필요한가, 놓치는 대가가 큰가 — 세 질문이 각각 파이프라인, 프로듀서-리뷰어, 다관점 투표를 가리킨다.
• 핸드오프는 다른 협업 아이디어다. 에이전트들이 제어권을 아예 서로 넘기고, 넘겨받는 에이전트가 대화를 이어받아 기본적으로 이전 대화 이력 전체를 본다³. 서브에이전트가 신선하고 격리된 컨텍스트에서 시작해 결론만 돌려주는 오케스트레이터-서브에이전트의 메커니즘과 정반대이며⁴, 핸드오프는 하나의 실행 안에 머물고 더 전문화된 에이전트가 여기서부터 대화를 맡아야 하는 경우에 맞는다².

>> 레슨 5: 실패와 조율

Footnotes

1. Building effective agents (Anthropic Engineering) — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. Agents (OpenAI Agents SDK) — https://openai.github.io/openai-agents-python/agents/ ↩ ↩²

3. Handoffs (OpenAI Agents SDK) — https://openai.github.io/openai-agents-python/handoffs/ ↩ ↩² ↩³

4. Create custom subagents (Claude Code Docs) — https://code.claude.com/docs/en/sub-agents ↩ ↩²