掘金2026년 10월 31일 23:16중국어 → 한국어

단일 에이전트에서 다중 에이전트까지 선택 기준 정리

대부분의 경우 다중 에이전트보다 워크플로를 먼저 권하고, 단일 에이전트 판단 기준과 다중 에이전트가 값을 내는 조건을 표와 코드로 제시했다.

중국어 원문을 AI로 번역했습니다. 고유명사와 수치는 원문 표기를 우선하며, 중요한 판단에는 아래 출처 원문을 함께 확인하세요.

핵심 결론: Agent 아키텍처 선정의 유일한 원칙은 workflow 우선, agent는 최후의 수단이다 — 95%의 상황에서는 먼저 "멀티 Agent가 필요한가"를 생각하지 말고, "이 프로세스를 고정할 수 있는가"를 물어야 한다. 고정할 수 있으면 workflow(fixed shape)를 쓰고, 고정할 수 없으면서 중간 의사결정이 필요할 때만 agent(runtime shape)를 쓴다. 멀티 Agent는 업그레이드가 아니라 값비싼 최후의 수단이다. Anthropic의 실측 결과 orchestrator-worker는 단일 Agent보다 약 90% 우수하지만, 약 15배의 토큰을 소모한다. 반면 동일한 컴퓨팅 예산에서는 멀티 Agent가 약 4%의 향상만 얻으면서 4배의 비용을 치른다.

1. 한 문장으로 정리: workflow 우선, agent는 최후의 수단

많은 사람이 처음부터 "단일 Agent냐 멀티 Agent냐"를 묻는데, 이는 거꾸로 물은 것이다. 진짜로 먼저 물어야 할 것은 이것이다. 이 작업을 workflow로 해결할 수 있는가?

Anthropic이 《Building Effective Agents》에서 제시한 조언은 매우 명확하다. 항상 workflow를 우선 구현하고, 정말 필요할 때만 agent로 resort하라는 것이다. 그 이유는 workflow가 프로덕션 애플리케이션에 대부분의 상황에서 필요한 reliability(신뢰성)와 predictability(예측 가능성)를 제공할 수 있는 반면, agent는 "요구사항을 예측할 수 없는" 상황에 flexibility(유연성)를 제공하기 때문이다.

비유하자면 🎭: workflow는 컨베이어 벨트처럼 작업대 순서가 미리 정해져 있어 매번 안정적으로 돌아간다. agent는 프리랜서처럼 목표와 도구 상자만 주면 현장에서 먼저 무엇을 할지 스스로 결정한다. 컨베이어 벨트는 똑똑할 필요 없이 안정적이기만 하면 되고, 프리랜서는 똑똑하지만 매번 surprise를 줄 수 있다.

판단 요령: 프로세스가 명확하고 반복 가능 → workflow; 프로세스가 입력에 따라 변하고 중간 의사결정이 필요 → agent 고려; 처음 시작한다면 → 먼저 workflow로 하고, 결과가 약하게 측정되면 agent로 교체.

2. 먼저 두 가지 근본 개념을 구분하자: 고정 형태 vs 런타임 형태

선정 전에 반드시 이 개념 쌍을 확립해야 한다. 그렇지 않으면 이후의 모든 계산이 엉킨다.

Workflow(고정 형태): 설계 단계에서 단계, 순서, 분기, fallback을 정의해 둔다. 시스템은 매번 같은 구조로 실행된다. 모델(있다면)은 컨베이어 벨트의 특정 슬롯에 텍스트를 채울 뿐이며, 컨베이어 벨트가 어떤 모습인지는 결정하지 않는다.

Agent(런타임 형태): goal과 일단의 tools를 주면 모델이 스스로 어떤 단계를 실행할지, 어떤 순서로 할지, 도구를 호출할지, 계속할지를 결정한다. 미리 하드코딩된 경로가 없다.

왜 이 구분이 선정의 초석인가? 의사결정의 난이도가 다르기 때문이다. workflow의 복잡성은 머릿속에서 한 번에 정리되지만, agent의 복잡성은 매 실행마다 다시 생각하도록 미뤄지는데, 후자는 더 높은 토큰 비용, 더 통제 불가능한 출력, 더 어려운 문제 진단을 의미한다.

Anthropic의 정의를 인용하자면, agent는 "LLM이 자신의 프로세스와 도구 사용을 동적으로 지휘하는 시스템"이고, workflow는 "미리 정의된 코드 경로"다. 둘은 workflow에서 agent로 이어지는 연속 스펙트럼이며, 흑백으로 나뉘는 것이 아니다.

3. 단일 Agent가 충분할 때: 3가지 판단 기준

단일 Agent(하나의 LLM이 여러 도구를 갖고 다단계 작업을 자율적으로 완수)는 대부분 상황의 기본 선택이다. 충분한지 판단하려면 이 3가지를 보라:

- 단계 수를 예측 가능 — 작업이 대략 3~5단계 내에 완결될 수 있다. 예를 들어 "날씨 조회 → 코디 추천"에는 ReAct(Rea soning + Action, 추론과 행동의 교대) 같은 단일 Agent 패턴이 자연스럽게 적합하다.

- 도구가 적고 관련성 있음 — 도구가 3~5개뿐이라 모델이 선택에서 헷갈리지 않는다. 도구가 많아지면 단일 Agent의 적중률이 급락한다.

- 병렬화 불필요 — 각 단계가 이전 단계 결과에 의존해 직렬로 진행하면 되고, 분리해 동시에 돌릴 하위 블록이 없다.

이 3가지를 만족하면 단일 Agent가 최적해다: 비용이 낮고, 통제 가능하며, 디버깅이 쉽다. 모델에 명확한 tool 목록과 좋은 system prompt 하나만 주면 된다.

반례에서 얻는 교훈: 작업에 도구가 8개 이상 필요하고, 단계가 10단계를 넘으며, 중간 단계에서 오류 수정이 발생한다면 단일 Agent는 느리고 비싸고 불안정해진다. 이때 비로소 멀티 Agent가 등판할 차례다.

4. 멀티 Agent가 정말 가치 있을 때: 단 두 가지 시나리오

멀티 Agent는 "더 고급"이 아니라, 특정 이득을 위해 높은 대가를 치르는 것이다. 멀티 Agent를 정말 도입할 가치가 있는 시나리오는 두 가지뿐이다.

시나리오 1: 진정한 병렬화(True Parallelism). 작업이 서로 독립적인 하위 블록으로 나뉘고, 병렬 실행이 직렬로 합치는 것보다 빠르다. 예를 들어 "동시에 10개 회사 조사", "동시에 20개 문서 분석" 같은 것이다. 연구에 따르면 병렬화 가능한 작업에서는 멀티 Agent가 뚜렷한 향상을 보이지만, 순차 추론 작업에서는 일반적으로 퇴화한다 — 멀티 Agent의 인계 과정에서 컨텍스트가 유실되기 때문이다.

시나리오 2: 생성 + 검증의 이중 역할(Generator-Critic). 한 Agent가 작성하고, 다른 Agent가 완전히 새로운 시각으로 심사한다. 이러한 "작성—심사" 구조는 향상이 가장 크고 대가는 상대적으로 가장 작다. LLM의 자기 오류 수정 능력이 약하기 때문에, 시각을 바꾼 비평자가 스스로 보지 못하는 많은 문제를 잡아낼 수 있다.

이 두 범주를 벗어나면 멀티 에이전트는 대체로 마이너스 수익이다. 특히 순차 체인(sequential chain)을 경계해야 한다. 에이전트를 하나 추가할 때마다 성공률은 곱셈으로 누적된다. 단일 단계 신뢰율이 95%라고 가정하면, 5단계 체인의 성공률은 77.4%로 떨어지고 10단계는 59.9%까지 추락한다. 단일 단계 신뢰율이 90%에 불과하다면(복잡하고 모호한 작업에서 흔히 그렇다), 10단계는 34.9%만 남는다. 이것이 바로 "단일 에이전트로 할 수 있는 일에는 멀티 에이전트를 쓰지 말라"는 말의 수학적 근거다.

5. 오케스트레이션 패턴 지도: ReAct / Planner-Executor / Orchestrator-Worker

에이전트가 정말 필요하다고 확인했다면, 다음은 오케스트레이션 패턴(orchestration pattern)을 고르는 것이다. 세 가지 주류 카드를 꺼내 비교해 보자.

ReAct(추론-행동 교차): 단일 모델 내부 루프 — 모델이 매 회차 "한 번 생각 → 도구 호출 → 결과 확인 → 다시 생각"한다. 간단한 질의응답, 리서치 어시스턴트, 3~5개 도구를 쓰는 단일 목적 에이전트에 적합하다. 복잡한 다단계 작업, 계획이 필요하거나 중간 복구가 필요한 오류 상황에는 적합하지 않다.

Planner-Executor(계획-실행 분리): 하나의 planner LLM이 미리 완전한 계획을 세우고, executor(더 작은 모델 또는 결정론적 runner)가 의존성 순서에 따라 실행하며, 선택적으로 replanning이 가능하다. 장점: 다단계 워크플로가 더 빠르고 저렴하다(대형 모델이 매 단계마다 호출될 필요가 없다). 단점: 계획이 0단계에서 고정되지만, 실제 작업은 도중에 새로운 정보가 드러나 계획을 바꿔야 하는 경우가 많다. 구조가 명확하고 예측 가능한 문서 파싱 파이프라인, 데이터 변환 작업에 적합하다. 개방형이고 경로 의존적 발견이 필요한 연구 작업에는 어려움을 겪는다.

Orchestrator-Worker(오케스트레이터-워커): 오케스트레이터 하나가 작업을 분해하고 여러 워커에게 분배한 뒤 결과를 집계한다. 폭 우선(breadth-first)이고 병렬화 가능한 작업에 적합하다. Anthropic의 리서치 어시스턴트가 바로 이 구조이며, 내부 평가에서 단일 에이전트보다 약 90% 우수했지만 약 15배의 토큰을 소모했다.

어떻게 고를까: 병렬이 필요하면 → Orchestrator-Worker; 시나리오 계획이 필요하고 작업이 예측 가능하면 → Planner-Executor; 작업이 단순하고 자율적이면 → ReAct. 이 셋은 대체 관계가 아니라 계층적으로 심화되는 복잡도다.

6. 비용과 신뢰성의 셈: 왜 멀티 에이전트는 돈을 태우는가

멀티 에이전트의 '비쌈'은 신비가 아니라 계산할 수 있는 셈이다.

- 토큰 소모: 멀티 에이전트의 실행 비용은 대략 단일 에이전트의 2~10배다. 출처로는 supervisor 오버헤드, 각 하위 에이전트가 저마다 system prompt를 로드하는 것, 핸드오프 시 context 직렬화 및 재정렬 등이 있다. 가벼운 병렬 fan-out은 저단에, 계층적 토론은 고단에 해당한다.

- Anthropic의 대조: 동일한 연산 예산에서 멀티 에이전트 설계는 약 4%의 향상만을 얻었지만 4배의 비용을 치렀다. 반면 orchestrator-worker는 평가에서 90% 더 우수했지만, 15배 토큰이라는 대가 때문에 많은 시나리오에서 이득이 없다.

- 성공률 감쇠: 멀티 에이전트 순차 체인에서는 각 핸드오프 지점마다 context를 잃거나 오류가 날 수 있다. 제4절에서 언급한 곱셈 누적 효과가 바로 reliability의 최대 킬러다.

결론 먼저: 멀티 에이전트의 가성비는 "돈으로 병렬도 또는 새로운 관점을 사는 것"이다. 작업이 병렬적이지 않고 생성-검증 이중 역할도 필요 없다면, 멀티 에이전트는 순수 손실이다.

7. 프레임워크 선택: LangGraph / CrewAI / AutoGen / Swarm

아키텍처를 정했다면 프레임워크 선택은 그저 도구일 뿐이다. 네 주요 선택지를 가로로 저울질해 보자(2026년 비교 참고).

판단 로직: 엄격한 실행 통제가 필요하면 → LangGraph; 빠른 구축 + 자연스러운 직관을 원하면 → CrewAI; 실시간 저지연이 필요하면 → Swarm(다만 실험적이다); AutoGen을 만나면 → 신규 프로젝트에는 쓰지 말라, 유지보수 모드로 이미 표시되어 있다.

8. 실행 가능한 선택 결정 코드: 하나의 Python 함수

아래는 그대로 복사해서 실행할 수 있는 선택 결정 함수다. 머릿속 판단을 4개의 질문으로 정규화해 권장 아키텍처를 출력한다. 실행에 외부 의존성은 전혀 필요 없다:

def recommend_agent_architecture ( steps_estimable: bool , # 단계 수를 예측할 수 있는가 tool_count: int , # 도구가 몇 개 필요한가 needs_parallel: bool , # 작업을 서로 독립적인 병렬 하위 블록으로 나눌 수 있는가 needs_critic: bool , # 「생성 + 검증」 두 역할이 필요한가 flow_fixed: bool , # 흐름을 설계 단계에서 고정할 수 있는가 ) -> str : """작업 특성에 따라 Agent 아키텍처를 추천한다. 파라미터: steps_estimable: 작업 단계를 미리 예측할 수 있는지 tool_count: 단일 Agent에 필요한 도구 수 needs_parallel: 병렬화가 가능한지 needs_critic: 생성/검증 두 역할이 필요한지 flow_fixed: 흐름을 설계 단계에서 고정할 수 있는지(고정 형태) 반환: 추천 아키텍처: workflow / single_agent / orchestrator_worker / generator_critic """ # 1) 흐름을 고정할 수 있으면 workflow 우선——Anthropic의 「workflow 우선」 원칙 if flow_fixed: return "workflow(고정 형태): 가장 안정적이고 가장 저렴, 먼저 결과부터 측정하라" # 2) 단계를 예측할 수 있고 도구가 적으면 단일 Agent의 ReAct로 충분 if steps_estimable and tool_count <= 5 : return "single_agent(ReAct): 단일 모델 루프, 비용 낮고 디버깅 쉬움" # 3) 병렬이 필요하면 Orchestrator-Worker로 속도를 바꿔라 if needs_parallel: return "orchestrator_worker(오케스트레이터-워커): 진짜 병렬일 때만 가치 있음, 토큰 비용 주의" # 4) 생성+검증이 필요하면 두 역할을 써라 if needs_critic: return "generator_critic(생성-검증 두 역할): 비용은 작고 향상은 큼" # 5) 모두 충족하지 않으면 보수적으로 단일 Agent 다중 도구 오케스트레이션으로 회귀 return "single_agent(다중 도구) + LangGraph: 도구가 많아지면 명시적 graph 제어가 필요" if __name__ == "__main__" : print (recommend_agent_architecture( steps_estimable= False , # 재무 보고서 내용은 예측 불가 tool_count= 6 , # 읽기, 파싱, 비교 등 여러 종류의 도구 필요 needs_parallel= True , # 20건을 병렬로 처리 가능 needs_critic= False , flow_fixed= False , )) # 출력: orchestrator_worker(오케스트레이터-워커): 진짜 병렬일 때만 가치 있음, 토큰 비용 주의

이 코드는 앞선 1~7장의 판단을 하나의 실행 가능한 의사결정 경로로 압축한 것으로, 복사하면 바로 실행된다.

9. 선정 대조표: 증상 → 원인 → 해법

증상 　 원인 　 해법

Agent가 한 번 호출에 자주 도구를 잘못 고름 　 도구가 너무 많아 단일 Agent의 의사결정 부담이 큼 　 도구를 <=5개로 줄이거나, LangGraph로 명시적 라우팅 도입

다중 Agent를 순차 실행했더니 결과가 오히려 더 나쁨 　 순차 추론에서 컨텍스트 손실(곱셈 누적 효과) 　 단일 Agent로 회귀하거나, 진짜 병렬일 때만 다중 Agent 사용

작업 단계는 예측 가능한데 매우 느리고 비쌈 　 매 단계마다 대형 모델이 다시 생각함 　 Planner-Executor로 전환, 한 번 계획하고 작은 모델로 실행

다중 Agent를 쓰고 싶은데 비용이 폭발 　 병렬성이 부족한데 단지 「고급」을 위해 도입 　 진짜 병렬인지 확인하고, 아니라면 단일 Agent로 토큰 2~10배 절약

새 프로젝트에 AutoGen을 쓰고 싶음 　 이미 유지보수 모드에 진입, 신규 기능 없음 　 신규 프로젝트는 Microsoft Agent Framework 또는 LangGraph로 전환

workflow를 다 작성했는데 결과가 늘 기준 미달 　 단계 사이에 모델의 판단이 필요 　 중간 판단 지점을 추출해 agent 자율화 또는 replanning으로 전환

10. 결론: 써야 할 때 / 쓰지 말아야 할 때의 판단 기준

언제 써야 하는가 : 흐름을 workflow로 고정할 수 있으면 agent를 건드리지 말 것; 반드시 자율적이어야 하지만 도구가 적고 단계를 예측할 수 있을 때는 단일 Agent ReAct를 사용; 작업이 진짜 병렬 가능하거나 생성-검증 두 역할이 필요할 때만 다중 Agent를 쓸 가치가 있다.

언제 쓰지 말아야 하는가 : 병렬화할 수 없고 새로운 관점도 필요 없을 때 다중 Agent는 순수하게 돈만 태우는 것(2~10배 토큰을 써서 ±4% 향상만 얻음); 순차 체인이 5~10단계를 넘으면 성공률 급락을 경계하고, 분기 분할 또는 단일 Agent로의 회귀를 우선 고려하라.

본 칼럼 《AI Agent 도구 칼럼》은 도구 호출, 메모리, Skill 라우팅부터 아키텍처 선정과 엔지니어링 방어선까지 죽 이야기하며, 매 편마다 실행 가능한 코드와 대조표 한 장을 함께 제공하고, 프로덕션 적용의 실제 트레이드오프에 초점을 맞춰 매주 한 편씩 업데이트한다. Agent 엔지니어링에서 시행착오를 줄이고 싶다면 칼럼 페이지에서 구독할 수 있다.

출처 원문