긴 작업을 챗봇 한 창에 통째로 맡겨본 적이 있을 것이다. 처음 몇 단계는 그럴듯하다가, 후반으로 갈수록 앞에서 자기가 정한 규칙을 잊고, 없는 사실을 지어내고, 시켰던 항목 하나를 슬쩍 빠뜨린다. 더 답답한 건 그걸 스스로 의심하지 못한다는 점이다. “방금 쓴 5번 항목, 출처 확인했어?”라고 물으면 그제서야 멋쩍게 고친다.

이 답답함의 정체를 정확히 짚는 게 출발점이다. 결론부터 말하면, 이건 “프롬프트를 더 잘 쓰면” 풀리는 문제가 아니라 구조의 문제인 경우가 많다. 그리고 그 구조를 바꾸는 방법이 바로 여러 에이전트에게 역할을 나눠 일을 시키는 것 — 흔히 말하는 멀티 에이전트, 에이전트 팀이다.

다만 미리 못 박아두자. 모든 일에 팀이 필요한 건 아니다. 단순하거나 단발성이거나 응답이 빨라야 하는 작업이라면, 같은 비용을 한 에이전트에 몰아주는 게 더 싸고 빠르고 정확하다. 그래서 이 글은 “에이전트 팀이 최고다”가 아니라, 언제 팀이 이기고 언제는 과한지를 같이 다룬다.

단일 챗봇이 자꾸 무너지는 순간

단일 에이전트가 흔들리는 데에는 반복되는 패턴이 있다.

첫째, 긴 작업에서 맥락이 뒤섞인다. 컨텍스트 창에 리서치 자료, 초안, 수정 지시, 잡담이 한꺼번에 쌓이면 모델은 어떤 게 확정된 규칙이고 어떤 게 흘러간 시도인지 헷갈린다. 후반부 출력 품질이 떨어지는 건 모델이 멍청해서가 아니라 책상이 어질러져서다.

둘째, 스스로 한 말을 의심하지 못한다. 생성과 검증이 같은 머릿속에서 일어나면, 방금 만든 답을 비판적으로 다시 볼 동기가 약하다. 사람도 자기 글의 오타는 잘 못 잡는다. 같은 원리다.

셋째, 넓게 탐색해야 하는 일을 순차로 처리하다 지친다. “이 분야 주요 기업의 이사회 멤버를 전부 찾아줘” 같은 폭(breadth) 중심 과제를 한 줄기로만 파고들면, 중간에 컨텍스트가 차고 누락이 생긴다.

이 세 가지는 “더 좋은 프롬프트”로 어느 정도 완화되지만 근본적으로 사라지지는 않는다. 한 명에게 기획·조사·집필·검수를 동시에 시키는 구조 자체가 한계이기 때문이다. 사람 조직도 같은 이유로 역할을 나눈다.

에이전트 팀이란 무엇이고 단일과 무엇이 다른가

에이전트 팀은 거창한 게 아니다. 역할을 나눈 여러 에이전트 + 그들을 묶어 일을 분배하고 결과를 취합하는 오케스트레이션, 이게 전부다. 각 에이전트는 자기 직무에 맞는 프롬프트와 도구, 그리고 자기만의 깨끗한 컨텍스트 창을 갖는다.

팀이 단일을 이기는 지점은 의외로 명확하다. 막연히 “더 똑똑해서”가 아니라, 다음 네 가지 구조적 이점이 실제로 필요할 때다.

  • 긴 컨텍스트 분할: 한 창에 다 못 담을 정보를, 워커들이 각자 격리된 창에서 처리하고 압축된 결과만 돌려준다. 리드의 책상이 깨끗하게 유지된다.
  • 병렬 탐색: 서로 독립적인 여러 방향을 동시에 파고든다. 순차로는 실패하던 폭 중심 과제가 병렬 분해로 풀린다.
  • 독립 검증: 만드는 에이전트와 깨는 에이전트를 분리하면, 자기 답을 의심 못 하는 문제가 사라진다.
  • 역할 전문화: 도구·프롬프트·탐색 경로를 직무별로 분리(관심사의 분리)해 각자 잘하는 일에 집중시킨다.

이 그림을 뒷받침하는 사례도 있다. 여러 AI 연구팀이 리서치형 시스템을 공개하면서, 강한 리드 모델이 여러 워커 모델을 거느린 멀티 에이전트 구성이 동급의 단일 모델보다 폭 중심 리서치 과제에서 더 나은 결과를 냈다고 보고했다. 다만 여기엔 중요한 단서가 붙는다. 이런 우위는 병렬화 여지가 큰 리서치 과제 기준이며, 병렬로 쪼갤 거리가 적은 대부분의 코딩 작업에는 그대로 적용되지 않는다.

반대 방향의 논의도 정직하게 같이 보자. 일부 연구는 ‘생각하는 토큰’ 예산을 동일하게 맞추면 단일 에이전트가 멀티 에이전트를 맞먹거나 이긴다고 보고했다. 멀티 에이전트가 잘하는 이유의 상당 부분이 “구조가 우월해서”가 아니라 “그냥 연산을 더 많이 써서”일 수 있다는 것이다(특정 추론 과제에 한정된 결과다).

두 갈래를 합치면 결론은 이렇게 정리된다.

팀이 이기는 건 ‘더 똑똑해서’가 아니라 병렬·격리·검증이라는 구조적 이점이 실제로 필요할 때다. 그 이점이 필요 없는 과제라면, 같은 연산을 한 명에게 몰아주는 편이 낫다.

단일 vs 팀 — 한눈에 비교

항목 단일 에이전트 에이전트 팀
속도 단순 작업에 빠름 병렬 시 빠름, 조율 오버헤드 있음
정확도 자기 검증이 약함 독립 검증으로 향상 가능
비용(토큰) 낮음 역할 수만큼 배로 증가
디버깅 추적이 쉬움 실패 지점이 분산돼 어려움
적합 작업 단순·단발·저지연 길고 복잡, 병렬·검증 이득이 있는 일

비용 줄을 특히 기억해두자. 팀은 공짜가 아니다. 호출 수와 토큰이 역할 수만큼 늘어나므로, 그 값어치를 하는 고가치 과제에만 붙여야 한다.

실전에서 쓰는 핵심 협업 패턴 5+1

패턴은 무수히 많지만, 실무에서 반복적으로 꺼내 쓰는 건 결국 몇 개다. 각 패턴마다 “언제 쓰고 언제 과한지”를 같이 적어둔다.

1. 오케스트레이터-워커 (supervisor)

리드 에이전트가 큰 일을 잘게 쪼개 워커들에게 위임하고, 워커들의 결과를 다시 취합한다. 책임 추적점(리드)이 하나라 디버깅이 쉽고, 가장 무난한 기본값이다.

  • 언제 쓰나: 서브태스크를 설계 시점에 어느 정도 알고, 결과를 한 곳에서 모아야 할 때. 대부분의 프로덕션에서 첫 선택지로 무난하다.
  • 언제 과한가: 일이 한두 단계로 끝나는데 굳이 리드를 두면 오버헤드만 는다.

2. 병렬 팬아웃 → 취합 (fan-out / fan-in)

서로 독립적인 작업을 동시에 던지고(fan-out), reducer가 결과를 하나로 합친다(fan-in). 핵심은 모든 갈래가 끝날 때까지 기다리는 합류 지점(barrier)이다.

  • 언제 쓰나: 하위 작업이 서로 독립적이고, 지연(latency)을 줄이는 게 우선일 때. 예를 들어 비평가 여러 명에게 동시에 검토를 시키고 다 모은 뒤 다음 라운드로 넘어간다.
  • 언제 과한가: 작업끼리 의존성이 크면 병렬이 오히려 충돌을 만든다.

3. 파이프라인 (역할 릴레이)

기획 → 리서치 → 작성 → 편집처럼, 앞 단계의 출력이 다음 단계의 입력이 되는 선형 흐름이다. 콘텐츠 제작, ETL, CI/CD처럼 단계가 예측 가능할 때 강하다.

  • 언제 쓰나: 단계가 선형적이고 순서가 분명할 때. 어느 단계에서 깨졌는지 보이니 디버깅도 쉽다.
  • 언제 과한가: 전체 지연이 ‘각 단계 시간의 합’이 되므로, 빠른 응답이 필요한 일엔 부담이다.

4. 적대적 검증 (생성가 vs 비평가)

한 에이전트는 만들고, 다른 에이전트는 일부러 결함을 찾는 ‘악마의 변호인(devil’s advocate)’ 역할을 한다. 단일 에이전트의 “자기 답을 못 의심하는” 약점을 정면으로 메운다.

  • 언제 쓰나: 정확도·신뢰성이 중요하고, 편향이나 맹점을 꼭 잡아야 할 때. 의료·법률·재무처럼 틀리면 비싼 도메인.
  • 언제 과한가: 가벼운 초안이나 브레인스토밍처럼 틀려도 괜찮은 작업엔 사치다.

5. 토너먼트 / 심사 패널 (LLM-as-judge)

여러 후보 답을 만들고, 판정가가 심사하거나 서로 토론시켜 베스트를 고른다.

  • 언제 쓰나: 정답이 여럿이고 그중 최선을 골라야 할 때(카피 여러 안, 설계 대안 비교 등).
  • 주의: 판정가 자체가 틀릴 수 있다. LLM 판정은 점수를 부풀리거나 특정 표현에 휘둘리기도 한다. 맹신하지 말고, 중요한 결정이라면 다수 판정으로 보완하자.

(+1) 루프-언틸-수렴 (reflection)

생성 → 비평 → 수정을 품질 임계치에 닿을 때까지 반복한다. 초안을 점진적으로 끌어올리는 데 좋다.

  • 반드시 지킬 것: 루프 상한(max iterations)을 둬라. 종료 조건이 없으면 무한 루프나 토큰 예산 소진으로 직행한다. 가장 흔하면서도 가장 고치기 쉬운 실패다.

성능 트레이드오프를 한 줄로 요약하면 이렇다. 적대적·반복형은 정확도, 병렬은 속도, 순차는 비용·확장성에서 유리하고, 계층형(오케스트레이터-워커)이 대부분의 프로덕션에 가장 무난한 기본값이다.

역할 설계 실전: 블로그 한 편을 팀으로 만들기

추상적인 패턴을 실제 워크플로우에 얹어보자. 블로그 글 한 편을 만드는 과정은 의외로 팀으로 쪼개기에 딱 좋은 예다. 파이프라인과 적대적 검증을 섞은 하이브리드로 돌아간다.

전략가(기획) → 리서처(팩트 수집·교차검증) → 작성자(초안) → 편집/검수자(비평·수정)
                                                  ↑__________________|
                                              (루프-언틸-수렴, 상한 N회)

각 역할이 실제로 하는 일은 이렇다.

  • 전략가: 주제·독자·각도·SEO 의도를 정의하고, 구조화된 개요를 다음 단계로 넘긴다. “무엇을 왜 쓰는가”를 못 박는 단계다.
  • 리서처: 웹을 교차검증하며 사실을 모으고, 확인 안 된 수치는 버린다. 출처가 붙은 팩트 노트를 반환한다.
  • 작성자: 그 노트를 받아 초안을 쓴다. 자기가 조사한 게 아니라 남이 검증해 넘긴 사실 위에서 쓴다는 점이 핵심이다.
  • 편집/검수자: 작성자와 분리된 독립된 시각으로 사실·논리·톤을 점검한다. “비평가를 따로 둔다”는 게 품질이 오르는 진짜 이유다.

여기서 중요한 감각 하나. 한 명에게 “조사하고 써줘”라고 하면 자기가 모은 자료를 검증 없이 그대로 믿고 쓴다. 리서처와 작성자, 검수자를 분리하면 각 단계가 앞 단계를 의심할 수 있는 위치에 놓인다. 이게 단순히 일을 나눈 것 이상의 효과를 낸다.

단계마다 무엇을 받고 무엇을 넘기는지 명시하는 것도 빼놓을 수 없다. 예를 들어 전략가가 작성자에게 넘기는 개요를 구조화하면 이렇게 된다.

{
  "audience": "1인 개발 창업가",
  "angle": "만능 1명보다 역할분담+검증이 낫다",
  "outline": [
    {"h2": "도입", "key_points": ["맥락 붕괴", "구조의 문제"]},
    {"h2": "패턴 5+1", "key_points": ["supervisor", "fan-out"]}
  ],
  "must_include": ["비용은 역할 수만큼 증가", "우위는 리서치형 과제 한정"],
  "tone": "동료에게 알려주듯, 과장 금지"
}

이렇게 출력 형식을 못 박아두면, 작성자는 빈칸을 채우듯 작업하고, 검수자는 must_include 항목이 본문에 실제로 들어갔는지 기계적으로 확인할 수 있다.

실전 체크리스트: 팀을 무너뜨리지 않으려면

팀은 잘못 설계하면 단일보다 더 엉망이 된다. 굴려보며 체득한 다섯 가지를 정리한다.

1. 역할·입출력 계약을 명시하라. 각 에이전트에 ‘직무기술서’를 줘라. 자기완결적인 과제 설명, 출력 포맷, 그리고 깨끗한 새 컨텍스트 창. “알아서 잘해줘”는 사람한테도 안 통한다. 워커마다 명확한 과제 명세를 부여하는 게 기본이다.

2. 구조화 출력(JSON 스키마)으로 기계 검증하라. 에이전트의 출력과 그걸 받는 다음 소비자 사이마다 스키마 검증 레이어를 둬라. 형식이 깨진 출력이나 환각이 하류로 흘러가기 전에 차단된다. 회복탄력성 측면에서 가성비가 가장 높은 패턴 중 하나다.

# 작성자 출력 → 검수자 입력 사이의 검증 레이어 (개념)
def validate(draft: dict) -> dict:
    assert draft["word_count"] >= 3000, "분량 미달"
    for fact in REQUIRED_FACTS:
        assert fact in draft["body"], f"누락된 필수 사실: {fact}"
    assert draft["h2_count"] >= 5, "H2 부족"
    return draft  # 통과해야만 다음 에이전트로

3. 컨텍스트를 격리하라. 모두에게 전부 주지 마라. 워커는 자기 일에 필요한 것만 받고, 전체 맥락이 아니라 압축된 최종 결과만 리드에 돌려준다. 컨텍스트 오염과 토큰 폭발을 동시에 막는 방법이다.

4. 비용·토큰을 관리하라. 길목마다 가장 비싼 프론티어 모델을 부르는 건 낭비다. 리드는 강한 모델, 단순 워커는 저렴한 모델로 섞어라. 비용이 역할 수만큼 배로 는다는 사실을 늘 머릿속에 두고, “이 과제가 그 값을 하는가”를 물어라.

5. 병렬과 파이프라인을 구분해 쓰라. 하위 작업이 독립적이면 병렬 팬아웃(모든 갈래를 barrier로 모은 뒤 다음 라운드), 단계가 선형 종속이면 파이프라인. 현실의 프로덕션은 대개 이 둘을 섞은 계층형 하이브리드다.

흔한 실패 모드도 미리 알아두면 절반은 막는다. 한 에이전트의 오류가 하류로 “신뢰된 입력”인 양 번지는 환각 전파, 전달 중 맥락이 빠지는 정보 유실, 종료 조건 실패로 인한 무한 루프, 라운드를 거듭하며 원 목표에서 벗어나는 목표 표류. 처방은 위 체크리스트와 그대로 겹친다 — 스키마 검증, 입출력 계약, 루프 상한, 검수자의 원 사양 재확인.

솔직한 한계: 언제 팀을 쓰지 말아야 하나

여기가 다른 글이 잘 안 다루는 부분이고, 사실 가장 중요한 부분이다.

비용이 곱으로 는다. 호출 수와 토큰이 역할 수만큼 늘어난다. 단순 작업에 멀티 에이전트를 쓰는 건 명백한 오버킬이다.

디버깅이 어렵다. 다단계 구성에서 어느 에이전트가 어디서 멈췄는지 추적하는 건 고통스럽다. 관측·트레이싱 도구 없이 멀티 에이전트를 운영하면, 문제가 터졌을 때 손쓸 방법이 마땅치 않다.

실시간 조율은 아직 약하다. 서로 발을 맞춰가며 진행해야 하는 작업에서 LLM 에이전트들은 종종 엇나가고 책임이 흩어진다.

경험적으로 멀티 에이전트가 잘 안 맞는 케이스는 대략 이렇다.

  • 모든 에이전트가 동일한 컨텍스트를 공유해야 하는 작업
  • 에이전트 간 상호 의존성이 큰 도메인
  • 대부분의 코딩 작업 (리서치보다 병렬화할 여지가 적다)
  • 저지연이 생명인 작업 — 인터랙티브 UX, 실시간 고객 응대 (사용자가 기다리는데 비평가 라운드를 돌릴 수는 없다)

판단 기준을 한 줄로 줄이면 이렇다. “팀이냐 단일이냐”가 아니라 “이 과제가 병렬화·검증으로 이득을 보는가”를 먼저 물어라. 답이 ‘아니오’면 단일이 더 싸고 빠르고 정확하다.

도구 생태계 지도 — 프레임워크부터 고르지 마라

마지막으로 도구 이야기. 다만 “어떤 프레임워크가 1등이다” 같은 단정은 출처마다 의견이 갈리니 피하고, 각자 무엇을 지향하는지만 짚는다.

  • Claude Code 서브에이전트 / Claude Agent SDK — 오케스트레이터-워커 지향. 리드가 워커를 병렬로 띄우고, 각 워커는 격리된 세션에서 일한 뒤 최종 출력만 부모에 반환한다.
  • OpenAI Agents SDK — 핸드오프(handoff) 중심. 에이전트가 명시적으로 제어권을 다음 에이전트에 넘긴다. 핸드오프, 가드레일(입출력 검증), 트레이싱(관측)을 주요 축으로 둔다.
  • LangGraph — 그래프 기반 상태머신. 에이전트를 공유 상태를 가진 유향 그래프의 노드로 모델링한다. 체크포인팅, 내구성 있는 실행, 휴먼 인 더 루프, 관측에 강점이 있고 제어 흐름이 명시적이다.
  • CrewAI — 역할 기반 팀. 역할과 위임이 직관적이라 비즈니스 워크플로 프로토타이핑이 빠르다.
  • AutoGen — 대화형 멀티 에이전트. 그룹 토론, 합의 형성, 순차 대화에 어울린다.

핵심 조언은 “프레임워크부터 고르지 말 것”이다. 패턴이 먼저고 도구는 나중이다. 자기 워크플로우에 필요한 게 파이프라인인지 병렬 팬아웃인지 적대적 검증인지를 먼저 정하면, 어떤 도구든 그 패턴을 표현할 수 있다. 반대로 도구부터 고르면, 그 도구가 잘하는 패턴에 억지로 일을 끼워 맞추게 된다.

마무리: 오늘 할 수 있는 첫걸음

정리하면, 팀의 이점은 ‘더 똑똑한 두뇌’가 아니라 병렬·격리·독립 검증이라는 구조에서 나온다. 그 구조가 필요한 길고 복잡한 일이라면 역할 분담과 검증이 품질을 분명히 끌어올린다. 반대로 그 구조가 필요 없는 단순·저지연·고의존 작업이라면, 같은 토큰을 한 에이전트에 몰아주는 편이 더 싸고 빠르고 정확하다.

거창하게 시작할 필요는 없다. 지금 굴리고 있는 워크플로우 하나를 골라, 역할 2~3개로 쪼개고 검증 1개를 붙여보라. 예를 들어 “조사하고 써줘”를 “리서처가 출처 붙여 모은다 → 작성자가 그걸로 쓴다 → 검수자가 그 둘을 의심한다”로 바꿔보는 것. 딱 이 정도가 첫걸음으로 충분하다.

그 한 번이 돌아가는 걸 보고 나면, 어디에 팀이 값을 하고 어디서는 과한지 — 그 감각이 비로소 손에 잡힌다.