“멀티 에이전트 (Multi-agent)”라는 용어는 종종 하나의 아키텍처를 설명하는 것처럼 사용되곤 합니다. 하지만 그렇지 않습니다.

코딩 워크플로우의 경우, 대화의 소유권을 전문가에게 이전하는 것, 전문가를 호출하여 결과를 돌려받는 것, 그리고 애플리케이션이 다음 단계를 제어하는 고정된 파이프라인을 실행하는 것 사이에는 큰 차이가 있습니다.

이러한 선택은 컨텍스트 가시성 (context visibility), 테스트, 재시도 (retries), 승인 경계 (approval boundaries), 그리고 잘못된 실행을 설명하기가 얼마나 쉬운지에 영향을 미칩니다.

이 글은 세 가지 접근 방식에 대한 문서 기반 비교입니다: handoffs와 agents-as-tools를 사용하는 OpenAI Agents SDK, 부모/하위 에이전트 이전 (parent/sub-agent transfer) 및 워크플로우 에이전트를 사용하는 Google ADK, 그리고 서브그래프 (subgraphs) 및 명시적 상태 (explicit state)를 사용하는 LangGraph입니다.

저는 다섯 가지 기준을 바탕으로 이들을 평가했습니다: 다음 응답의 소유권이 누구에게 있는지, 상태 (state)가 어떻게 전달되는지, 라우팅 (routing)이 모델에 의해 제어되는지 또는 애플리케이션에 의해 제어되는지, 병렬 또는 반복 가능한 작업에 대한 적합성, 그리고 개발자가 실패 후 무엇을 조사할 수 있는지입니다. 공통 벤치마크를 실행하지 않았으므로, 이 글은 특정 프레임워크가 더 빠르거나 더 신뢰할 수 있다는 주장이 아닙니다.

핵심 차이점: 이전인가, 반환인가?

코딩 작업으로 시작해 보겠습니다: “이 풀 리퀘스트 (pull request)를 검토하고, 테스트를 실행한 뒤, 패치 (patch)를 제안하세요.”

**Handoff (이전)**는 전문가가 업무를 인계받아야 할 때 적절합니다. 원래의 에이전트는 더 이상 다음 응답의 소유자가 아닙니다. OpenAI Agents SDK에서 handoffs는 모델에 transfer tools로 노출되며, 수신된 에이전트가 실행을 계속합니다. 이 SDK는 또한 타입이 지정된 handoff 입력과 히스토리 필터 (history filters)를 지원합니다.

**Subagent call (하위 에이전트 호출)**은 관리자가 통제권을 유지해야 할 때 적절합니다. 전문가는 제한된 작업을 수행하고 결과를 반환하며, 관리자는 다음에 무엇을 할지 결정합니다. 이는 플래너 (planner)가 하나의 답변을 생성하기 전에 여러 개의 독립적인 검토를 결합해야 할 때 더 안전한 기본 방식입니다.

**워크플로 그래프 (workflow graph)**는 애플리케이션의 제어 흐름 (control flow)을 명확하게 보여주어야 할 때 적합합니다. 그래프를 사용하면 모델에게 런타임 (runtime) 중에 구조를 직접 만들어내라고 요청하지 않고도, "보안 검토와 테스트 검토를 병렬로 실행한 다음, 합성기 (synthesizer)를 거치도록 한다"와 같이 정의할 수 있습니다.

실제적인 실수는 이들을 서로 교체 가능한 함수 호출 (function calls)로 취급하는 것입니다. 이들은 서로 다른 소유권 모델 (ownership models)입니다.

한눈에 보는 비교

OpenAI Agents SDK: 소유권 모델을 의도적으로 선택하기

OpenAI의 오케스트레이션 (orchestration) 가이드는 **도구로서의 에이전트 (agents as tools)**와 **핸드오프 (handoffs)**를 구분합니다.

매니저가 제어권을 유지해야 할 때는 에이전트를 도구로 사용하십시오. 예를 들어, 코드 리뷰 매니저는 보안 전문가, 테스트 전문가, 문서화 전문가를 호출한 다음 그들의 결과물을 조정할 수 있습니다. 매니저가 최종 답변에 대한 소유권을 가지며 공통된 출력 규약 (output contract)을 강제할 수 있습니다.

전문가가 다음 응답에 대한 소유권을 가져야 할 때는 핸드오프를 사용하십시오. 분류 (triage) 에이전트는 저장소 작업을 마이그레이션 전문가에게 전달할 수 있으며, 전문가는 이후 사용자에게 누락된 버전 세부 정보를 요청하거나 자체 도구를 사용하여 작업을 계속할 수 있습니다.

이러한 구분은 코딩 에이전트에게 매우 유용합니다. 왜냐하면 "이 diff를 검토하라"와 "이 마이그레이션을 계속하라"는 서로 다른 작업이기 때문입니다. 전자는 종종 제한된 결과 (bounded result)를 얻는 것이 유리합니다. 후자는 전문가가 다회차 상호작용 (multi-turn interaction)을 넘겨받아야 할 수도 있습니다.

문서에서 도출할 수 있는 프로덕션 가드레일 (production guardrail)은 다음과 같습니다: 핸드오프 체인 (handoff chain) 내의 모든 에이전트가 입출력 가드레일로 자동으로 둘러싸여 있다고 가정하지 마십시오. 모든 부수 효과 (side effect)를 검토해야 하는 경우에는 도구 또는 워크플로 경계에 체크 로직을 배치하십시오.

Google ADK: 위임(delegation)을 위한 계층 구조, 파이프라인을 위한 워크플로 에이전트

Google ADK는 서로 관련되어 있지만 다른 두 가지 개념을 제공합니다.

부모 에이전트(parent agent)는 하위 에이전트(sub-agent)가 다음 상호작용을 처리해야 할 때 해당 에이전트로 권한을 넘길 수 있습니다. 이는 핸드오프(handoff)와 유사하며, 제어권이 계층 구조를 따라 아래로 이동합니다.

자동화된 다단계 작업을 위해, ADK는 워크플로 에이전트(workflow agents)를 제공합니다:

• SequentialAgent: 정의된 순서에 따라 자식 에이전트들을 실행합니다.
• ParallelAgent: 독립적인 자식 에이전트들을 동시에 실행합니다.
• LoopAgent: 종료 조건이나 제한에 도달할 때까지 자식 에이전트들을 반복 실행합니다.

이러한 특징 덕분에 ADK는 코딩 파이프라인(coding pipeline)에 자연스럽게 적합합니다. 즉, 저장소 컨텍스트(repository context)를 수집하고, 정적 분석(static analysis)과 테스트를 병렬로 실행하며, 결과를 합성(synthesize)한 다음, 엄격한 반복 제한을 두고 '수정 및 검증(repair-and-verify)' 과정을 루프(loop)로 돌릴 수 있습니다.

중요한 선택 사항은 사용자 대면 전문가(user-facing specialist)가 업무를 인계받아야 하는지, 아니면 애플리케이션이 예측 가능한 파이프라인을 완료해야 하는지 여부입니다. 후자의 경우, 모델이 선택한 제약 없는 전송(unconstrained chain of model-selected transfers)보다 워크플로 에이전트를 사용하는 것이 추론하기에 더 쉽습니다.

LangGraph: 상태와 제어 흐름을 명시적으로 만들기

LangGraph는 워크플로를 그래프(graph)로 취급합니다. 노드(node)는 에이전트, 도구(tool), 또는 일반 애플리케이션 코드를 호출할 수 있습니다. 조건부 엣지(conditional edges)는 다음에 무엇을 실행할지 결정하며, 서브그래프(subgraphs)는 전문가의 내부 워크플로를 캡슐화합니다.

멀티 에이전트 코딩 시스템에서 가장 유용한 차별점은 상태 범위(state scope)입니다. 서브그래프는 부모의 메시지 상태(message state)를 공유하거나, 다른 스키마(schema)를 사용하여 별도의 비공개 히스토리(private history)를 유지할 수 있습니다. 문서에서는 독립적인 하위 에이전트 작업의 경우 호출당 지속성(per-invocation persistence)을 일반적인 선택으로 설명하며, 전문가가 턴(turn) 간에 메모리가 필요한 경우에는 스레드당 지속성(per-thread persistence)을 사용합니다.

이는 기본적인 핸드오프(handoff)보다는 설정(configuration)에 가깝지만, 프로덕션 환경에서 중요한 질문들에 답을 제시합니다:

• 보안 검토자(security reviewer)가 이전 요청을 기억하는가?
• 어떤 상태(state)가 경계를 넘어가는 것이 허용되는가?
• 실패한 브랜치(branch)를 조사하고 재개할 수 있는가?
• 두 번째 호출은 새로운 검토인가, 아니면 연속된 과정인가?

승인(approvals), 내구성 있는 상태(durable state), 또는 다중 브랜치를 사용하는 코딩 에이전트에게 이러한 요소들은 워크플로 계약(workflow contract)의 일부입니다.

개발자를 위한 의사결정 규칙

실패 모드(failure modes)를 가시화할 수 있는 가장 작은 제어 모델을 선택하세요:

• 핸드오프 (handoff) 사용: 한 명의 전문가가 다음 사용자 대면 턴(user-facing turn)을 소유해야 할 때.
• 도구로서의 에이전트 (agent-as-tool) 또는 제한된 서브에이전트 (bounded subagent) 사용: 매니저가 타입이 지정된 결과(typed result)를 필요로 하며 제어권을 유지해야 할 때.
• 순차적 워크플로 (sequential workflow) 사용: 순서가 고정되어 있고 각 단계가 이전 출력에 의존할 때.
• 병렬 브랜치 (parallel branches) 사용: 검토(reviews)가 독립적이며 나중에 조정(reconcile)될 수 있을 때.
• 루프 (loop) 사용: 명시적인 종료 조건(exit condition), 반복 횟수 제한(iteration cap), 그리고 검증 단계(verification step)가 있을 때만 사용.
• 그래프 (graph) 또는 내구적 워크플로 (durable workflow) 사용: 승인(approvals), 재시작(restarts), 감사 가능성(auditability), 또는 상태 범위(state scope)가 핵심 요구사항일 때.

질문해 보세요: "만약 이 전문가가 위험한 제안을 생성한다면, 그것이 실행(action)으로 이어질지 결정할 책임은 여전히 누구에게 있는가?" 만약 답변이 불분명하다면, 경계(boundary)가 너무 암시적(implicit)일 가능성이 높습니다.

지금 해야 할 일

1. 모든 전문가에 대한 소유권 경계(ownership boundary)를 그리세요: 인계(takes over) 또는 결과 반환(returns a result).
2. 각 전문가에게 발견 사항(findings), 근거(evidence), 신뢰도(confidence), 권장 조치(recommended action)를 포함하는 좁은 출력 계약(output contract)을 부여하세요.
3. 부수 효과(side-effecting)를 일으키는 도구들은 승인 또는 정책 경계 뒤에 두세요. 검토자(reviewer)가 조용히 실행자(executor)가 되도록 방치하지 마세요.
4. 각 브랜치에 대해 하나의 실패 테스트를 추가하세요: 타임아웃(timeout), 잘못된 형식의 출력(malformed output), 오래된 리포지토리 상태(stale repository state), 그리고 거부된 승인(rejected approval).
5. 각 경계를 통과하는 상태(state)를 기록하세요. 모호한 "멀티 에이전트 (multi-agent)"라는 라벨보다 짧은 트레이스(trace)가 더 유용합니다.

시스템을 측정하고 있다면, 브랜치 선택 정확도(branch-selection accuracy), 유용한 결과율(useful-result rate), 검토 대비 실행율(review-to-action rate), 도구 실패(tool failures), 승인 개입(approval interventions), 그리고 완료된 리포지토리 작업당 비용(cost per completed repository task)을 추적하세요. 프레임워크 선택만으로는 워크플로가 제대로 작동하는지 알 수 없습니다.

솔직한 한계점

이 비교는 2026년 7월 21일에 사용 가능한 공식 문서를 반영합니다. API와 권장 패턴은 빠르게 변경될 수 있습니다. 각 프레임워크는 동일한 추상화 (abstractions)를 노출하지 않으므로, 행 단위의 직접적인 비교는 근사치에 불과합니다. 저는 세 가지 프레임워크 모두에서 동일한 리포지토리 작업 (repository task)을 실행하거나, 지연 시간 (latency)을 측정하거나, 모델 품질을 비교하지 않았습니다. 실제 결과는 모델, 프롬프트 (prompts), 도구 (tools), 상태 저장소 (state store), 동시성 제한 (concurrency limits), 그리고 평가 품질 (evaluation quality)에 따라 달라집니다.

이것이 기본적으로 다중 에이전트 (multiple agents)를 사용해야 한다는 주장은 아닙니다. 명시적인 도구와 검증 (verification) 기능을 갖춘, 범위가 잘 정의된 단일 코딩 에이전트 (coding agent)가 에이전트 팀보다 테스트하기 쉬운 경우가 많습니다.

Sources

• OpenAI Agents SDK: orchestration and handoffs
• OpenAI Agents SDK: handoffs
• Google ADK: workflow agents
• Google Codelab: build multi-agent systems with ADK
• LangGraph: subgraphs and persistence

다음 단계의 프로덕션 세부 사항을 확인하려면, Zira의 문맥 압축 비교 (context compaction comparison), 도구 오류 처리 비교 (tool-error handling comparison), 그리고 코딩 에이전트 점수 가이드 (coding-agent score guide)를 참조하세요.

Discussion: 여러분의 코딩 에이전트 워크플로 (coding-agent workflows)에서는 전문가가 대화를 인계받는 방식을 선호하시나요, 아니면 매니저에게 제한된 결과값을 반환하는 방식을 선호하시나요? 그리고 어떤 실패 경험이 여러분을 해당 설계로 이끌었나요?