다중 에이전트 토론: 누가 옳은가?

Prompt Engineering 구독자 190,000명

요약

이 영상은 서로 상반된 두 연구, 즉 멀티에이전트 시스템 구축을 제안하는 Enthropic(엔트로픽)과 단일 에이전트를 선호하는 Cognition Labs(코그니션 랩스)의 주장을 비교·분석한다. 전자는 웹 검색 서비스에서 멀티에이전트가 단일 에이전트 대비 90% 높은 성능을 보였다는 실험을 공유하고, 후자는 에이전트 간 맥락 공유의 어려움과 일관성 문제로 인해 단일 에이전트의 순차적 태스크 분할 방식을 선호한다. 나아가 컨텍스트 엔지니어링, 압축 LLM 병렬 운용, 프롬프트 엔지니어링 등 실제 개발과 평가, 운영 단계에서 고려해야 할 실용적인 팁을 제시하며 에이전트 시스템의 현재 한계와 최적 설계 방향을 제시한다.

주요 키워드

멀티에이전트 시스템 단일 에이전트 오케스트레이터 (Orchestrator) 어그리게이터 (Aggregator) 컨텍스트 엔지니어링 프롬프트 엔지니어링 압축 LLM 출현적 행동 (Emergent Behavior) 평가 (Eval) 자율 개선 (Self-improvement)

하이라이트

🔑 멀티에이전트 병렬 실행의 문제: 서브 에이전트들이 서로의 작업을 볼 수 없어 일관된 결과를 내기 어렵다.
⚡️ 핸드오프 컨텍스트 공유: OpenAI SDK처럼 대화 내역을 넘기는 방식은 장기 과제에서 컨텍스트 오버플로우를 유발한다.
🌟 순차 실행 대안: 단일 에이전트가 태스크를 분할해 메모리로 기록하며 순차 처리하면 모든 결정과 맥락을 유지할 수 있다.
🚀 압축 LLM 활용: 긴 대화나 메모리를 압축하는 별도 모델을 병렬로 돌려 컨텍스트 용량 제한을 해소한다.
💡 토큰 사용량이 성능 변동의 80% 설명: 멀티에이전트는 토큰과 도구 호출, 모델 선택으로 대폭 성능 향상을 달성했다.
📌 적절한 도구 개수: 한 에이전트당 10~15개 도구가 최적이며, 전문 서브 에이전트를 두면 관리가 수월해진다.
🔥 출현적 행동(emergent behavior): 시스템 변경이 예측 불가능한 하위 에이전트 동작 변화를 일으키므로, 모든 구성 요소의 엔드투엔드 평가가 필수다.
✔️ 간단한 Eval 전략: 20개 실제 질의로 시작해, LLM 단일 호출로 0~1 스코어와 통과/실패 이진 평가가 사람 판단과 가장 일치한다.

용어 설명

멀티에이전트 시스템

여러 개의 서브 에이전트가 각기 독립적으로 작업을 수행하고 결과를 모아 최종 응답을 생성하는 구조

단일 에이전트

하나의 에이전트가 태스크를 순차적으로 분할·실행하며 컨텍스트와 결정을 일관되게 유지하는 방식

오케스트레이터 (Orchestrator)

전체 태스크를 받아 서브 에이전트에게 분할·할당하고 결과를 취합하도록 조율하는 중앙 제어 컴포넌트

어그리게이터 (Aggregator)

서브 에이전트들의 결과를 종합해 최종 응답을 생성하는 컴포넌트

컨텍스트 엔지니어링 (Context Engineering)

컨텍스트(대화 내역, 상태, 메모리)를 효율적으로 관리·공유하기 위한 프롬프트 엔지니어링 확장 기법

프롬프트 엔지니어링 (Prompt Engineering)

에이전트에게 명확한 지침과 태스크 설명을 제공해 정확한 동작을 유도하는 핵심 기술

압축 LLM (Compression LLM)

장기 과제 시 대화 내역을 요약·압축해 컨텍스트 오버플로우를 방지하는 별도 LLM 모델

출현적 행동 (Emergent Behavior)

시스템 구성 요소의 작은 변경이 예기치 않은 하위 에이전트 행동 변화를 일으키는 현상

Rainbow Deployment

에이전트 시스템을 단계별로 점진적 배포해 안정성을 유지하는 소프트웨어 배포 전략

최근 Enthropic의 멀티에이전트 시스템 구축 사례와 Cognition Labs의 단일 에이전트 옹호 주장 두 편을 간략히 소개하며, 에이전트 시스템 연구가 아직 초기 단계임을 강조한다.

[00:00] 지난주 에이전트 구축에 관한 두 가지 상반된 논문이 발표되었다. 하나는 멀티 에이전트 시스템 구축 방법을 제시하고, 다른 하나는 멀티 에이전트 시스템을 구축하지 말라고 제안한다.

[00:25] 첫 번째는 Anthropic의 '멀티 에이전트 연구 시스템 구축' 논문이고, 두 번째는 Devon을 만든 Cognition Labs의 '멀티 에이전트를 구축하지 말라' 논문이다.

사용자가 태스크를 요청하면 오케스트레이터가 이를 서브 에이전트로 분할하고, 각 에이전트는 독립 수행 후 어그리게이터가 결과를 취합한다. 이 방식은 에이전트 간 맥락 공유 부재와 태스크 오해 시 결합 오류가 발생한다.

[00:53] 현재 복잡한 작업을 위한 에이전트 시스템은 작업을 서브태스크로 나누고, 각각을 별도의 서브 에이전트가 수행한 후 오케스트레이터와 애그리게이터가 결합하는 방식으로 구축된다.

[01:40] 멀티 에이전트 시스템의 두 가지 주요 문제점이 있다. 첫째, 각 에이전트가 독립적으로 작업하여 서로의 활동을 알 수 없다. 둘째, 한 에이전트가 작업을 잘못 이해하면 전체 결과에 부정적 영향을 미친다.

OpenAI 핸드오프 원칙처럼 대화 이력과 제어권을 서브 에이전트에 전달해 맥락을 유지하려 하지만, 장기 과제에서는 대화 내역이 계속 커져 관리가 어렵다는 한계가 있다.

[02:20] 이 문제를 해결하기 위한 간단한 접근법은 에이전트들 간에 실행 중인 컨텍스트 공유 히스토리를 갖는 것이다. 오케스트레이터가 대화와 행동을 추적하여 서브 에이전트들과 공유한다.

[02:46] OpenAI의 Agent SDK에서 제안한 핸드오프 원리도 유사한 개념으로, 제어권과 대화 컨텍스트를 서브 에이전트에게 넘겨준다. 하지만 장기간 실행되는 작업의 경우 모든 것을 추적하기 어렵다는 문제가 있다.

[03:09] 멀티 에이전트 시스템의 주요 문제점들을 설명합니다. 서브 에이전트들이 서로의 대화와 행동을 추적하기 어렵고, 독립적인 결정으로 인해 일관성 없는 결과가 나올 수 있다는 점을 플래피 버드 예시로 설명합니다.

단일 에이전트가 동일한 메모리·대화 이력을 바탕으로 순차적으로 서브태스크를 수행하면 모든 결정과 맥락을 일관되게 추적할 수 있다. 맥락 엔지니어링 개념을 도입해 프롬프트 설계와 압축 LLM을 병렬 활용한다.

[03:38] 순차적 실행 접근법을 제안합니다. 여러 서브 에이전트 대신 단일 에이전트가 작업을 서브태스크로 나누고 순차적으로 수행하며, 대화 기록과 메모리를 유지하여 일관성을 보장하는 방법을 설명합니다.

[04:18] 장기 작업에서 발생하는 컨텍스트 오버플로우 문제와 해결책을 다룹니다. 병렬로 실행되는 압축 LLM을 통해 컨텍스트를 관리하고, 프롬프트 엔지니어링의 확장인 컨텍스트 엔지니어링 개념을 소개합니다.

[05:04] 단일 에이전트가 멀티 에이전트보다 더 적절한 솔루션이라는 주장을 뒷받침하는 실제 사례들을 제시합니다. 클로드 코드를 예시로 들며, 서브 에이전트 생성보다는 서브태스크 생성과 순차적 실행이 더 효과적임을 설명합니다.

Enthropic Cloud Code는 멀티 에이전트를 두지 않고, 하나의 에이전트가 순차적으로 서브태스크를 생성·완료하는 구조를 활용해 코드 편집 및 생성 작업에서 높은 일관성을 얻었다.

[06:24] Anthropic의 멀티 에이전트 시스템 구축 방법론을 소개하며, 이들이 개발한 클로드 내 연구 시스템이 최고 수준의 웹 검색 구현 중 하나라고 설명합니다.

웹 검색 분야에서 리드 연구자(Orchestrator)가 플랜을 생성하고, 여러 서브 에이전트를 통한 병렬 검색·의견 수집 후 어그리게이터가 결과를 통합하는 구조를 시연한다.

[06:53] 멀티 에이전트 시스템의 작동 방식을 구체적으로 설명합니다. 오케스트레이터가 사용자 쿼리를 받아 계획을 세우고, 여러 서브 에이전트들이 독립적으로 다양한 검색 작업을 수행한 후 결과를 집계하는 구조입니다.

[07:38] 단일 거대 에이전트 방식과 비교하여 멀티 에이전트 시스템의 장점을 설명합니다. 검색과 코드 생성의 특성이 다르기 때문에 멀티 에이전트 방식이 더 효과적이라고 주장합니다.

멀티에이전트 구조가 단일 에이전트 대비 90% 이상 높은 성능을 보인 이유로 토큰 사용량(80% 기여), 도구 호출 횟수, 모델 선택 이 세 가지 요인을 제시한다. 에이전트당 10~15개 도구가 최적이다.

[08:09] 멀티 에이전트 시스템의 아키텍처를 설명합니다. 사용자 인터페이스, 계획을 생성하는 리드 연구자, 그리고 메모리를 가진 서브 에이전트들로 구성된 구조를 소개합니다.

[08:25] Anthropic의 엔지니어링 블로그가 다른 회사들보다 더 자세한 정보를 제공한다고 평가하며, 시스템 설계의 중요성을 강조합니다.

[08:44] Anthropic의 실험 결과를 소개합니다. Claude Opus를 리드 에이전트로, Claude Sonnet을 서브 에이전트로 하는 멀티 에이전트 시스템이 단일 에이전트 Claude Opus보다 90% 뛰어난 성능을 보였다는 놀라운 결과를 발표했습니다.

검색처럼 탐색 공간이 넓을 때 멀티에이전트가 효과적이나, 복잡한 의존성이나 컨텍스트 공유가 중요한 코드 생성 등 분야에서는 단일 에이전트가 더 적합하다.

[09:12] 멀티 에이전트 시스템이 검색 애플리케이션에서 효과적인 이유를 설명합니다. 각 서브 에이전트가 서로 다른 연구 영역을 탐색할 수 있어, 더 많은 토큰을 사용하지만 그만큼 큰 성능 향상을 얻을 수 있다고 합니다.

[09:33] 성능 향상을 설명하는 세 가지 요인을 소개합니다. 토큰 사용량이 분산의 80%를 설명하며, 도구 호출 수와 모델 선택이 다른 설명 요인들입니다.

[09:51] 단일 에이전트에게 천 개의 도구를 제공하면 파악하기 어렵습니다. 실제로 10-15개 정도가 최적의 도구 수이며, 전문화된 서브 에이전트가 있으면 더 관리하기 쉬워집니다.

[10:13] 모든 애플리케이션에 멀티 에이전트 시스템을 사용할 수는 없습니다. 동일한 컨텍스트 공유나 에이전트 간 의존성이 많은 도메인에서는 적합하지 않습니다.

[10:36] 코딩 작업은 병렬화 가능한 작업이 적고, LLM 에이전트는 실시간 조정과 위임에 아직 뛰어나지 않습니다. Cognition Lab이 단일 에이전트에 집중하는 이유입니다.

에이전트가 인간처럼 단계별 작업 방식을 그대로 따라가게 하는 세부 지침 설계, 오케스트레이터의 위임 능력 강화, 태스크 복잡도에 따른 에이전트·도구 스케일링 기법을 소개한다.

[11:04] 더 실용적인 포인트들을 소개합니다. Google에서 에이전트 시스템 구축 강연을 했으며, 관심 있다면 해당 비디오 시청을 추천합니다.

[11:27] 두 가지 주요 집중 영역으로 나뉩니다: 프롬프트 엔지니어링과 연구 에이전트 평가. 거대한 평가 데이터 세트가 필요하지 않으며, 약 20개의 실제 사용 쿼리로 시작할 수 있습니다.

[12:02] LLM 기반 시스템의 가장 중요한 구성 요소인 프롬프트 엔지니어링에 대해 설명합니다. 에이전트에게 명확한 지시를 제공하는 것이 그 어느 때보다 중요합니다.

[12:21] 초기 에이전트들의 오류 사례를 소개합니다. 존재하지 않는 웹 링크를 검색하거나 여러 서브 에이전트를 불필요하게 생성하는 문제들이 있었습니다.

[12:43] 에이전트에게 명확한 지시를 제공하고 오케스트레이터에게 위임 방법을 가르치는 것의 중요성을 강조하며, 명확한 의사소통을 통해 하위 에이전트들이 중복 작업을 피하도록 해야 한다고 설명합니다.

[13:18] 작업 복잡성에 따른 확장 전략을 제시하며, 간단한 사실 확인은 하나의 에이전트로, 직접 비교는 2-4개 에이전트로, 복잡한 연구는 10개 이상의 하위 에이전트로 구성해야 한다고 구체적인 예시를 들어 설명합니다.

[14:02] 툴 설계와 선택의 중요성을 강조하며, 복잡성을 고려한 툴 설계와 명확한 툴 설명의 필요성을 언급합니다. 특히 에이전트가 적절한 툴을 선택할 수 있도록 명확한 입출력 설명이 필요하다고 강조합니다.

[14:42] 에이전트의 자기개선 능력에 대해 설명하며, 에이전트가 툴 설명을 수정하거나 MCP 서버를 통해 사용 가능한 툴을 변경할 수 있다는 흥미로운 아이디어를 제시합니다.

[15:08] 검색 전략으로 '넓게 시작해서 좁혀나가기' 접근법을 제안하며, 사고 과정 안내의 중요성을 강조합니다. 추론 모델의 사고 능력을 오케스트레이터뿐만 아니라 하위 에이전트에서도 활용할 수 있다고 설명합니다.

[15:31] RAG 애플리케이션에서의 실제 경험을 공유하며, 추론 모델이 재순위와 생성을 단일 단계에서 수행할 수 있는 흥미로운 가능성을 언급하고, 이를 로컬 GPT에 도입할 계획이라고 밝힙니다.

[15:56] 테스트에서 두 가지 병렬화 방식을 시도했는데, 리드 에이전트가 순차적이 아닌 병렬로 최대 5개의 서브 에이전트를 실행하고, 서브 에이전트들은 3개 이상의 도구를 병렬로 사용하는 방식입니다. 이는 연구 시간을 단축할 수 있지만 토큰 소모와 비용 증가가 단점입니다.

20개 실제 질의로 소규모 평가 세트를 구성하고, LLM을 단일 호출해 0~1 점수와 합격·불합격 이진 결과를 도출하는 간단한 Eval 프레임워크를 제안한다. 사람 검증도 병행해 리워드 해킹과 출현적 행동을 감시한다.

[16:29] 멀티 에이전트 시스템의 평가는 복잡한 문제입니다. 이들은 결정론적 시스템이 아니어서 같은 쿼리라도 매번 다른 결과를 낼 수 있으며, 도구나 에이전트의 실행 순서도 매번 달라집니다.

[17:12] 평가 접근법으로는 작게 시작할 것을 제안합니다. 실제 사용 사례를 나타내는 20개의 쿼리로 시작해서 점진적으로 테스트 케이스를 확장하는 방식이 효과적입니다.

[18:02] 대규모 평가를 위해 LLM을 심사위원으로 활용할 수 있습니다. 복잡한 지표보다는 0에서 1까지의 점수와 통과/실패 등급을 출력하는 단일 LLM 호출이 가장 일관성 있고 인간 판단과 일치한다는 것을 발견했습니다.

[18:55] RAG 시스템을 구축할 때 사람들은 진실성이나 정확성 같은 복잡한 평가 기준을 사용하지만, 실제로는 응답이 올바른지 틀렸는지 같은 단순한 이진적 결과가 더 의미 있을 수 있다.

[19:10] 인간 평가자에게 의미 있는 평가 방식을 고수하고, 현실에서 의미 없는 화려한 새로운 지표보다는 실용적인 평가를 LLM 시스템에 요청하는 것이 중요하다.

[19:35] 휴먼 인 더 루프가 필수적이며, 인간 평가가 자동 평가가 놓치는 부분을 잡아낸다. 인간 테스터들은 에이전트가 권위있는 소스보다 SEO 최적화된 콘텐츠를 선호하는 문제를 발견했다.

에이전트 시스템은 상태(stateful) 유지와 오류 누적 특성이 있어, 오류 발생 시 재시작 대신 중단 시점부터 재개하는 설계가 필요하다. 레인보우 배포, 동기식 실행, 추적·관찰 시스템도 필수적이다.

[20:00] 보상 해킹은 에이전트와 LLM 기반 시스템에서 실제로 발생하는 문제이며, 생성 부분과 LLM 판사 역할 모두에서 나타날 수 있어 인간의 검증이 반드시 필요하다.

[20:25] 멀티에이전트 시스템은 특정 프로그래밍 없이 창발적 행동을 보이며, 리드 에이전트의 작은 변화도 서브 에이전트들의 행동을 예측 불가능하게 바꿀 수 있다.

[20:40] 멀티에이전트 시스템에서 단일 컴포넌트를 변경할 때는 다른 부분에 다운스트림 효과를 미치므로, 한 부분을 변경하면 반드시 엔드 투 엔드 평가를 실행해야 한다.

[21:05] 프로덕션 환경에서 에이전트는 상태를 가지며 오류가 누적되는 특성이 있어, 시스템을 추적하고 관찰할 수 있는 지표와 시스템 구축이 중요하다.

[21:34] 오류 발생 시 처음부터 재시작하는 것은 비용이 많이 들고 사용자에게 좌절감을 주므로, 오류 발생 지점에서 재개할 수 있는 시스템을 구축하고 모델의 지능을 활용해 문제를 우아하게 처리하는 것이 효과적이다.

[21:59] 멀티 에이전트 시스템의 도구 실패 시 자기 적응 메커니즘이 놀랍도록 효과적으로 작동한다고 소개합니다.

[22:04] 멀티 에이전트 시스템의 배포 방식을 설명하며, 이들 시스템이 프롬프트, 도구, 실행 로직을 포함한 높은 상태 유지 웹으로 지속적으로 실행된다고 말합니다.

[22:21] 지속적으로 실행되는 시스템의 특성상 전체 업그레이드가 어려워 전통적인 소프트웨어 엔지니어링 원칙이 중요하며, 레인보우 배포 전략을 통해 점진적 교체를 수행한다고 설명합니다.

[22:47] 동기식 실행 방식을 강조하며, 리드 에이전트가 서브 에이전트들의 완료를 기다린 후 결과를 집계하는 방식으로 작동하지만, 비동기 실행은 아직 해결하지 못했다고 언급합니다.

[00:00] 지난주에 에이전트 구축에 관한

[00:02] 매우 흥미로운 두 개의 논문이 나왔습니다.

[00:04] 그 중 하나는 멀티 에이전트 시스템을

[00:06] 구축하는 방법을 보여주고 있습니다.

[00:08] 다른 하나는 멀티 에이전트 시스템을

[00:11] 전혀 구축하지 말라고 제안합니다.

[00:14] 언뜻 보기에 모순적이지만

[00:17] 둘 다 매우 중요한 내용이라고 생각합니다.

[00:19] 그리고 이것은 또한 우리가 얼마나

[00:21] 에이전트 시스템 구축 과정의

[00:24] 초기 단계에 있는지를 보여줍니다.

[00:25] 첫 번째 논문인 '우리가 멀티 에이전트

[00:28] 연구 시스템을 구축한 방법'은

[00:31] Anthropic에서 나온 것이고

[00:34] 두 번째인 '멀티 에이전트를 구축하지 말라'는

[00:37] Devon을 만든 Cognition Labs의 논문입니다.

[00:41] 두 논문 모두 읽어보시길

[00:43] 강력히 추천하지만, 이 영상에서는

[00:45] 에이전트 시스템 구축에 대해

[00:48] 이 논문들이 말하는 내용을

[00:50] 간단히 요약해드리려고 합니다.

[00:53] 현재 복잡한 작업을 위한

[00:55] 에이전트 시스템을 구축할 때

[00:57] 제안되는 접근법은 작업을

[01:00] 서브태스크로 나누고, 각 서브태스크를

[01:03] 별도의 작은 서브 에이전트가 수행하게 한 다음

[01:06] 이들을 결합하는 것입니다.

[01:07] 오케스트레이터와 애그리게이터가 있고

[01:10] 그 사이에 여러 에이전트들이

[01:12] 함께 작업하는 구조입니다.

[01:14] 하지만 Cognition Lab의 이 논문은

[01:18] 이것이 가장 최적의 접근법이 아닐 수도

[01:20] 있다고 말합니다.

[01:23] 일반적으로 흔한 접근법은

[01:25] 다음과 같습니다. 사용자로부터

[01:28] 작업을 받는 오케스트레이터가 있고

[01:30] 이것이 작업을 서브 에이전트들로 나눕니다.

[01:33] 각 서브 에이전트에게 작업을 할당하고

[01:36] 서브 에이전트들이 그 작업들을 수행한 다음

[01:38] 애그리게이터가 결과를 결합합니다.

[01:40] 여기에는 두 가지 주요 문제가 있습니다.

[01:43] 첫째는 각 에이전트가 다른 에이전트들과

[01:46] 독립적으로 작업을 수행한다는 것입니다.

[01:48] 따라서 서로 무엇을 하고 있는지

[01:50] 전혀 알 수 없습니다.

[01:52] 둘째는 에이전트 중 하나가

[01:54] 자신의 작업을

[01:56] 잘못 이해하면, 애그리게이터가

[01:58] 결과를 결합하려고 할 때

[02:01] 부정적인 영향을 미친다는 것입니다.

[02:04] 그들이 블로그 포스트에서 제시한

[02:06] 예시는 Flappy Bird 클론을 구축하는 것인데

[02:09] 서로 다른 서브태스크들이

[02:11] 모델의 주요 테마들을 서로 독립적으로

[02:15] 구현할 수 있고, 전체적인 일관성이

[02:17] 전혀 없을 수 있다는 것입니다.

[02:19]

[02:20] 이제 이런 문제를 해결하기 위한

[02:22] 더 간단한 접근법은

[02:24] 에이전트들이나 서브 에이전트들 간에

[02:27] 실행 중인 컨텍스트 공유 히스토리를

[02:29] 갖는 것입니다.

[02:31] 이것이 어떻게 보이는지 설명하면

[02:32] 오케스트레이터가 있고, 지금까지 일어난

[02:35] 대화와 지금까지 취해진 행동들을

[02:38] 추적하며, 이것들이

[02:40] 다른 서브 에이전트들 간에 공유됩니다.

[02:43]

[02:46] OpenAI가 그들의 OpenAI

[02:48] Agent SDK에서 제안한

[02:51] 핸드오프 원리는 매우 유사한 개념으로

[02:54] 제어권과 함께 지금까지 일어난

[02:56] 순수한 대화의 컨텍스트를

[02:58] 서브 에이전트에게 넘겨주는 것입니다.

[03:02] 이 접근법의 문제는

[03:03] 때때로 장기간 실행되는

[03:05] 작업들이 있다는 것입니다. 따라서 모든

[03:08] 것들을 추적하기가 매우 어려워집니다.

[03:09] 다양한 서브 에이전트들이 수행하는 대화와 행동들을

[03:12] 추적하는 것입니다. 그리고 두 번째는

[03:15] 독립적으로 내려지는 결정들입니다.

[03:17] 플래피 버드 예시로 돌아가서,

[03:19] 그들은 말합니다.

[03:21] 에이전트에게 동일한 플래피 버드

[03:24] 클론 작업을 주면, 이번에는

[03:26] 새와 배경이 완전히 다른

[03:28] 시각적 스타일로 나올 수 있습니다.

[03:31] 그 이유는 서브 에이전트 1과

[03:33] 서브 에이전트 2가 런타임에

[03:35] 자신들이 무엇을 하고 있는지 추적할 수 없기 때문입니다.

[03:38] 그래서 그들은 더 순차적인 접근법을 제안합니다.

[03:40] 같은 에이전트가 처음에 작업을 분해하고

[03:42] 그 다음 서브태스크를 담당합니다.

[03:46] 서브 에이전트가 아니라 동일한 에이전트에게

[03:48] 서브태스크를 주는 것입니다. 그 서브태스크를 수행하고

[03:51] 메모리를 업데이트한 다음

[03:54] 다른 서브태스크를 담당합니다.

[03:56] 이 경우 동일한 에이전트 내에서

[03:58] 순차적 실행을 하기 때문에

[04:00] 바뀌는 것은 서브태스크뿐입니다. 실제로는

[04:03] 대화 기록뿐만 아니라 지금까지

[04:06] 내린 모든 결정들의 메모리도 가지고 있습니다.

[04:09] 그래서 지금까지 일어난 모든 것을

[04:12] 추적할 수 있게 됩니다.

[04:14] 하지만 장기 작업이나 오래 실행되는 작업으로 돌아가면,

[04:18] 컨텍스트 오버플로우 문제에 부딪히게 됩니다.

[04:20] 이를 위해 그들은

[04:22] 병렬로 실행되는 압축 LLM을 제안합니다.

[04:25] 이것은 채팅 기록의 모든 컨텍스트와

[04:29] 에이전트가 지금까지 작업한 메모리를 압축하고

[04:30] 기본적으로 에이전트가 장기 작업을 수행할 때

[04:33] 그것을 컨텍스트로 제공합니다.

[04:40] 팀은 프롬프트 엔지니어링의 확장인

[04:44] 컨텍스트 엔지니어링이라는 개념을 제안했습니다.

[04:46] 하지만 이제는 에이전트나

[04:48] 서브 에이전트들이 지금까지 취한

[04:50] 모든 행동의 컨텍스트를 가지고 있는지 확실히 해야 합니다.

[04:54] 그리고 그들이 본 응답들도 마찬가지로요.

[04:58] 그들의 제안은 지금까지 본 대부분의 작업에서

[05:01] 단일 에이전트가 아마도

[05:04] 여러 서브 에이전트보다

[05:06] 더 적절한 솔루션일 것이라는 것입니다.

[05:09] 그리고 특별히 강조한 한 가지 예시는

[05:12] Anthropic의 놀라운 시스템인

[05:15] 클로드 코드였습니다.

[05:17] 실제로 우리는 멀티 에이전트 시스템을

[05:20] 옹호하는 Anthropic의 블로그 포스트를 볼 것입니다.

[05:23] 하지만 여기서 그들은

[05:24] 클로드 코드가 스스로를 위해

[05:27] 서브태스크를 생성하는 에이전트의 예라고 말합니다.

[05:29] 즉, 병렬로 작업을 수행하는

[05:33] 서브 에이전트를 생성하지 않습니다.

[05:36] 하지만 실제로는 단순히 서브태스크를 생성하고

[05:39] 순차적 실행 시스템입니다.

[05:42] 그 서브태스크들을 수행하고

[05:43] 다른 것으로 넘어갑니다.

[05:46] 코드 편집에서 사람들은

[05:48] 여러 다른 모델들을 사용했습니다.

[05:51] 더 작은 모델이나 큰 모델이

[05:52] 적용하려는 변경사항들을 제안하고

[05:55] 그 다음 더 작은 서브 에이전트 모델이

[05:57] 그 변경사항들을 적용했습니다.

[06:00] 하지만 그것은

[06:02] 좋은 접근법이 아닌 것으로 밝혀졌습니다.

[06:04] 그래서 그들은 오늘날 의사결정 과정과

[06:06] 적용이 한 번의 행동으로

[06:09] 단일 모델에 의해 수행되는 경우가 더 많다고 제안했습니다.

[06:12] 그들은 작업을 서브태스크로 나눌 수 있는

[06:14] 하나의 모델이 멀티 에이전트 시스템을 생성하는 것보다

[06:17] 훨씬 더 나은 접근법이라고 생각하는

[06:19] 몇 가지 예시를 제시합니다.

[06:22] Anthropic이 말하는 것을 살펴봅시다.

[06:24] 멀티 에이전트 시스템 구축에 관해

[06:26] 말하는 내용입니다. 두 번째

[06:29] 글은 Anthropic에서 나온 것으로

[06:31] 멀티 에이전트 시스템 구축에 대해 논합니다.

[06:33] 여기서 주목할 점은 그들이 구체적으로

[06:35] 클로드 내에서 사용 가능한

[06:37] 연구 시스템에 대해 이야기하고 있다는 것입니다.

[06:40] 이것은 아마도 제가 본 것 중

[06:42] 최고의 웹 검색 구현 중 하나일 겁니다.

[06:45] 예시를 보여드린 다음

[06:46] 글을 살펴보고 그들이

[06:48] 공유한 학습 내용도

[06:51] 살펴보겠습니다.

[06:53] 이것은 Anthropic 팀이 공유한 예시 쿼리입니다.

[06:56] 웹 검색을 활성화해보겠습니다.

[06:58] 이것을 실행하면 오케스트레이터가

[07:01] 사용자 쿼리를 받아서

[07:04] 사용자 쿼리를 기반으로 계획을 세웁니다.

[07:06] 여기 계획이 있습니다.

[07:09] 그리고 나서 여러 개의 서브 에이전트를

[07:13] 생성해서 다양한 검색 결과를 수행합니다.

[07:17] 각 서브 에이전트는

[07:19] 다양한 도구에 접근할 수 있습니다.

[07:21] MCP나 메모리 업데이트 같은 것들이죠.

[07:24] 그리고 이들은 독립적으로 작업을 수행합니다.

[07:26] 오케스트레이터는 마지막에

[07:29] 이러한 결과들을 수집하고 집계해서

[07:31] 사용자를 위한 최종 응답을 생성합니다.

[07:34] 만약 서브태스크를 생성하는

[07:38] 하나의 거대한 에이전트를 사용한다면

[07:41] 순차적 실행을 하게 되고

[07:44] 동일한 에이전트가

[07:46] 모든 웹 검색을 수행하게 됩니다.

[07:49] 하지만 그것은 Anthropic이

[07:51] 제안하는 구현 방식이 아닙니다.

[07:54] 생각해보면 그 이유는

[07:56] 이것이 매우 다른 애플리케이션이기 때문입니다.

[07:58] 검색의 성격과 코드 생성은

[08:01] 매우 다르고, 바로 여기서

[08:04] 이런 멀티 에이전트 시스템이

[08:06] 효과적일 수 있다고 생각합니다.

[08:09] 아키텍처는 다음과 같습니다.

[08:12] 사용자와 상호작용하는

[08:13] 시스템이 있습니다. 그 다음

[08:15] 계획을 생성하는 리드 연구자가 있고

[08:17] 메모리를 가진 서브 에이전트들이 있습니다.

[08:20] 이들은 오케스트레이터나

[08:22] 리드 연구자가 만든 계획을 실행합니다.

[08:25] 영상의 나머지 부분에서는

[08:27] Anthropic이 제공하는

[08:29] 인사이트들을 살펴보겠습니다.

[08:32] 개인적으로 그들의 엔지니어링 블로그가

[08:34] 매우 도움이 된다고 생각합니다.

[08:37] 다른 회사들에 비해 많은 세부사항을 공유합니다.

[08:39] 결국 시스템을 어떻게

[08:42] 설계하느냐에 달려있습니다.

[08:44] 그들은 Claude Opus를 리드 에이전트로 하고

[08:46] Claude Sonnet을 서브 에이전트로 하는

[08:48] 멀티 에이전트 시스템이

[08:51] 단일 에이전트 Claude Opus보다

[08:56] 내부 연구 평가에서 90% 더 뛰어난

[08:59] 성능을 보였다고 발견했습니다.

[09:01] 이는 정말 놀라운 수치입니다.

[09:04] Cognition이 제안했던

[09:06] 단일 모놀리식 에이전트에 비해

[09:09] 이런 멀티 에이전트 시스템으로 거의 두 배의 성능을 얻을 수 있습니다.

[09:12] 그들은 멀티 에이전트 시스템이

[09:14] 특히 검색 애플리케이션에서

[09:17] 잠재적으로 효과적일 수 있는 이유를 설명합니다.

[09:19] 핵심 아이디어 중 하나는

[09:22] 여러 다른 에이전트를 사용하므로

[09:24] 각 서브 에이전트가 다른

[09:27] 연구 영역을 탐색할 수 있다는 것입니다.

[09:30] 더 많은 토큰을 사용하게 되지만

[09:33] 그들은 구체적으로 세 가지 다양한 요인에 대해 이야기합니다

[09:35] 이것이 성능 향상을 설명하는 요인들이죠

[09:38] 그래서 그들이 발견한 것은

[09:40] 토큰 사용량 자체가

[09:42] 분산의 80%를 설명한다는 것입니다

[09:45] 도구 호출 수와 모델 선택이

[09:47] 다른 설명 요인들이라고 하네요

[09:51] 예를 들어 단일 에이전트에

[09:54] 천 개의 도구를 제공한다면

[09:56] 에이전트가 파악하기 정말 어려울 거예요

[09:57] 실제로 제가 본 것은

[10:00] 아마도 10개에서 15개 정도가

[10:02] 에이전트에게 줄 수 있는

[10:04] 최적의 도구 수입니다

[10:08] 그리고 전문화된 서브 에이전트가 있다면

[10:10] 훨씬 더 관리하기 쉬워집니다

[10:13] 하지만 그렇다고 해서

[10:15] 모든 애플리케이션에 멀티 에이전트 시스템을

[10:17] 사용할 수 있다는 의미는 아닙니다

[10:20] 실제로, 그들은 특별히 지적합니다

[10:23] 동일한 컨텍스트를 공유해야 하거나

[10:25] 에이전트 간에 많은 의존성이 있는

[10:28] 특정 도메인에서는

[10:31] 멀티 에이전트 시스템의 좋은 사용 사례가

[10:33] 아닐 수도 있다고 말입니다

[10:36] 예를 들어 그들이 말하는 것은 대부분의 코딩 작업이

[10:40] 실제로 병렬화 가능한 작업이 적다는 것입니다

[10:43] 검색보다는 말이죠. 그리고 LLM 에이전트는

[10:45] 아직 실시간으로 다른 에이전트와

[10:48] 조정하고 위임하는 데 뛰어나지 않습니다

[10:49] 따라서 Cognition Lab은

[10:52] 코딩 에이전트에 특별히 집중하고 있고

[10:55] 그래서 하나의 단일 에이전트가

[10:58] 그들에게 실제로 효과가 있는 것 같습니다

[11:00] 그리고 여기서 Anthropic도

[11:03] 정확히 같은 점을 암시하고 있습니다

[11:04] 이제 더 실용적인 포인트들을

[11:07] 안내해 드리겠습니다. 저는 이러한 것들의 대부분을

[11:10] 이전 비디오에서 다뤘습니다

[11:12] 그리고 특별히 Google에서 에이전트 시스템 구축에 대한

[11:15] 강연을 했습니다. 다음으로

[11:17] 그 비디오를 녹화했습니다

[11:20] 만약 이 주제에 대한

[11:22] 더 깊은 분석에 관심이 있다면

[11:24] 그 비디오를 시청하기를 강력히 추천합니다

[11:27] 그들은 두 가지 주요 집중 영역으로 나누었습니다

[11:30] 하나는 프롬프트 엔지니어링이고

[11:31] 두 번째는

[11:34] 연구 에이전트를 위한 평가입니다

[11:36] 그리고 평가 부분은

[11:38] 매우 흥미롭습니다

[11:41] 나중에 평가 부분을 살펴보겠지만

[11:43] 빠르게 강조하고 싶은 것이 있습니다

[11:46] 실제로는 거대한 평가 데이터 세트가

[11:48] 필요하지 않다는 것입니다

[11:52] 실제로, 그들은 약 20개의 쿼리로 시작했고

[11:54] 이것들은 실제 사용을 나타내는 것들입니다

[11:57] 따라서 에이전트를 평가하기 위해서는

[11:59] 상대적으로 작은 진화 데이터 세트가 필요합니다

[12:02] 좋습니다. 먼저 LLM 기반 시스템의

[12:05] 가장 중요한 구성 요소에 대해 이야기해봅시다

[12:08] 그것은 바로 프롬프트 엔지니어링입니다

[12:10] 이것은 지금 그 어느 때보다

[12:12] 중요합니다. 왜냐하면 에이전트에게

[12:16] 매우 명확한 지시를 제공하고 싶기 때문입니다

[12:17] 그들이 할당받은 작업을 수행할 수 있도록 말이죠

[12:21] 그들이 주는 예시는

[12:23] 초기 에이전트들이 오류를 범했고

[12:26] 여러 개의 서로 다른 서브 에이전트를

[12:29] 생성했다는 것입니다

[12:30] 작업을 실행하거나

[12:33] 전혀 존재하지 않는 웹 링크를

[12:36] 검색하기 위해서 말이죠

[12:40] 이제 그런 종류의 문제들을 어떻게 해결할까요?

[12:43] 에이전트에게 명확한 지시를 제공해야

[12:46] 사람이 하는 일을 그대로 복제할 수

[12:48] 있도록 해야 합니다. 두 번째는

[12:52] 오케스트레이터에게 위임하는 방법을

[12:54] 가르쳐야 합니다. 다시 말해, 이는

[12:56] 매우 명확한 의사소통으로 귀결됩니다.

[12:59] 따라서 세부적인 작업 설명을 제공하고

[13:02] 두 개의 하위 에이전트가 동일한

[13:05] 작업을 중복으로 수행하지 않도록

[13:08] 해야 하는데, 이는 오케스트레이터가

[13:11] 계획뿐만 아니라 작업 위임을

[13:14] 얼마나 잘하는지에 달려 있습니다.

[13:18] 다음은 쿼리 복잡성에 맞춰

[13:20] 노력을 확장하는 것입니다. 작업

[13:22] 복잡성이라고 말씀드리고 싶습니다.

[13:25] 작업의 성격에 따라 그만큼의

[13:28] 확장이나 컴퓨팅을 할당해야 합니다.

[13:30] 예를 들어, 간단한 사실 확인은

[13:33] 3~10개의 툴 호출로 하나의 에이전트만

[13:35] 필요합니다. 직접 비교는 2~4개의

[13:39] 하위 에이전트가 각각 5~15개의

[13:41] 호출이 필요할 수 있고, 복잡한 연구는

[13:45] 명확히 구분된 책임을 가진 10개

[13:47] 이상의 하위 에이전트를 사용할 수

[13:49] 있습니다. 따라서 에이전틱 시스템을

[13:51] 설계할 때는 작업을 어떻게 위임할지와

[13:54] 각 작업에 할당될 복잡성의 정도를

[13:57] 프롬프트에 충분한 정보로

[13:59] 제공해야 합니다. 다음 항목은

[14:02] 툴 설계와 선택이 중요하다는

[14:04] 것입니다. 제가 본 바로는 사람들이

[14:07] 복잡성을 염두에 두고 툴을

[14:09] 설계하지 않거나, 작업에 정말 좋은

[14:11] 툴을 가지고 있지만 툴 설명이나

[14:13] 입력 또는 출력 설명이

[14:15] 정말 형편없습니다. 에이전트가

[14:18] 특정 툴을 언제 사용해야 하는지

[14:21] 이해하지 못한다면 실수를

[14:23] 하게 됩니다. 따라서 에이전트에

[14:26] 들어가는 프롬프트가 정말

[14:27] 훌륭할 뿐만 아니라 툴의 설명도

[14:31] 정말 명확해야 에이전트가 특정 툴을

[14:34] 언제 사용해야 하는지 혼동하지

[14:38] 않습니다. 그리고 또 다른

[14:40] 흥미로운 아이디어는 에이전트가

[14:42] 스스로 개선하도록 하는 것입니다.

[14:45] 에이전트는 툴 설명을 변경하거나

[14:48] 다른 MCP 서버를 통해 사용 가능한

[14:51] 툴을 수정할 수도 있습니다.

[14:53] 이는 정말 흥미로운 아이디어라고

[14:55] 생각하는데, 에이전트가 특정한

[14:57] 실수를 하고 있다면 자신의

[14:59] 프롬프트뿐만 아니라 사용 가능한

[15:02] 툴도 수정하려고 시도할 수

[15:04] 있습니다. 검색과 관련해서는

[15:08] 넓게 시작해서 좁혀나가는 방식을

[15:10] 제안하는데, 이는 인간이 수행하는

[15:13] 방식과 매우 유사하며, 사고

[15:15] 과정을 안내하는 것입니다. 즉,

[15:18] 적용 가능한 곳에서는 이러한

[15:20] 사고나 추론 모델의 사고 능력을

[15:22] 활용하고 싶어합니다. 이제 이는

[15:24] 오케스트레이터와 애그리게이터에만

[15:27] 제한되지 않고 하위 에이전트도

[15:30] 이를 활용할 수 있으며, 실제로

[15:31] 제가 구축하고 있는 일부 RAG

[15:34] 애플리케이션에서 저는 실제로

[15:36] 이러한 추론 모델을 사용하기

[15:38] 시작했습니다. 동일한 추론 모델이

[15:41] 재순위뿐만 아니라 단일 단계에서

[15:43] 생성도 할 수 있다는 것은

[15:44] 제가 로컬 GPT에 도입할 예정인

[15:48] 매우 흥미로운 아이디어입니다.

[15:50] 그리고 프롬프팅에 대한 마지막

[15:53] 제안은 병렬 툴 실행과 병렬

[15:56] 테스트에서 그들이 시도한 것은

[15:58] 두 가지 다른 유형의

[15:59] 병렬화를 사용하는 것이었습니다. 하나는 리드

[16:02] 에이전트가 순차적이 아닌 병렬로

[16:04] 최대 5개의 서브 에이전트를

[16:06] 실행하는 것입니다. 이는 코그니션이

[16:08] 제안한 것과는 매우 다릅니다. 그리고 서브 에이전트들은

[16:11] 3개 이상의 도구를 병렬로 사용합니다. 이는

[16:15] 확실히 연구 시간을 단축할 수 있지만

[16:18] 멀티 에이전트 시스템을

[16:19] 여러 도구 호출과 함께 사용한다면

[16:21] 많은 토큰을 소모하게 될 것입니다.

[16:25] 그래서 비용이 상당히 증가할 것입니다.

[16:29] 자, 이제 아무도 좋아하지 않는 주제인

[16:31] 평가에 대해 이야기해 봅시다. 하지만

[16:33] 좋은 평가 체계가 없다면

[16:35] 실제로 개선 사항을

[16:37] 측정할 수 없습니다. 그저

[16:39] 개인적인 선호도나

[16:42] '괜찮아 보인다' 식의 지표에

[16:44] 의존하게 됩니다. 멀티 에이전트 시스템을 위한

[16:46] 평가를 만드는 것은 훨씬 복잡합니다

[16:48] 왜냐하면 이것들은 결정론적 시스템이

[16:50] 아니기 때문입니다. 같은 쿼리를

[16:52] 같은 시스템을 통해 여러 번 실행하면

[16:54] 매번 완전히 다른 계획을

[16:56] 세울 수 있고, 심지어 도구나

[16:59] 에이전트의 실행 순서도

[17:01] 매우 다를 것입니다. 그래서

[17:02] 이것이 매우 복잡하게 만듭니다. 하지만

[17:06] 이러한 서브 에이전트들을 평가하는 데

[17:09] 사용할 수 있는 매우 간단한 아이디어가 있습니다.

[17:12] 하지만 그 전에 그들은

[17:14] 작게 시작할 것을 제안했습니다. 실제로

[17:16] 이 멀티 에이전트 연구 도구를 만들 때

[17:19] 그들은 실제 사용 사례를 나타내는

[17:22] 20개의 쿼리 세트로 시작했습니다

[17:24] 이는 매우 흥미로운데, 많은 사람들이

[17:26] 이런 것들을 테스트에 투입하기 전에

[17:30] 많은 데이터를 수집하는 데

[17:32] 시간을 보내기 때문입니다. 목표는

[17:34] 모든 엣지 케이스와

[17:36] 테스트 케이스를 다룰 수 있는

[17:39] 거대한 평가 세트를 갖는 것입니다

[17:41] 하지만 그들은 매우 적은 수의

[17:44] 예제로 시작할 것을 제안했고, 이는

[17:47] 시스템이 얼마나 좋은지에 대한

[17:49] 초기 지표를 제공할 것이고, 그다음에

[17:52] 더 복잡한 상황이나 엣지 케이스를

[17:55] 접하게 되면서 더 많은

[17:58] 테스트 케이스를 추가할 수 있습니다. 작게 시작하되 일찍 시작하세요.

[18:02] 이제 질문은 어떻게

[18:04] 정확히 이러한 평가를 대규모로 수행할지입니다

[18:06] 그래서 특정 평가를 위해

[18:09] LLM을 심사위원으로 사용할 수 있습니다

[18:11] LLM을 심사위원으로 사용하는 것의

[18:14] 효과성과 어떤 유형의 지표를 사용할지에 대한

[18:18] 많은 논의가 있습니다. 그들은

[18:20] 매우 간단한 기준을 가지고 있고

[18:23] 저는 이것을 정말 좋아합니다. 그들은

[18:25] 이러한 멀티 에이전트 시스템이 매우 복잡하다고

[18:27] 말합니다. 왜냐하면 동시에

[18:29] 여러 가지 다른 것들을

[18:30] 추적해야 하기 때문입니다. 하지만 그들은

[18:33] 0에서 1까지의 점수와

[18:35] 통과/실패 등급을 출력하는 단일 프롬프트로

[18:39] 단일 LLM 호출이 가장

[18:41] 일관성 있고 인간의 판단과

[18:43] 일치한다는 것을 발견했습니다. LLM 기반

[18:46] 시스템을 보면, 사람들은 성능을

[18:49] 측정하기 위해 매우 새로운 지표들을

[18:52] 내놓고 있습니다. 하지만 실제로는

[18:54] 실제로 아무것도 측정하지 못하고 있습니다.

[18:55] RAG 시스템을 구축할 때, 사람들은 진실성이나

[18:58] 정확성과 같은 평가 기준을 사용합니다.

[19:00] 하지만 인간으로서는 응답이

[19:04] 올바른지 아닌지에 관심이 있죠.

[19:06] 그래서 단순한 리콜, 이진적 결과일 수 있습니다.

[19:09] 따라서 인간 평가자로서

[19:12] 당신에게 의미 있는 것들을 고수하고

[19:15] LLM 시스템이나

[19:17] 에이전트 시스템이 그런 평가를 출력하도록 요청하는 것이

[19:21] 현실에서 전혀 의미가 없는

[19:24] 화려하고 새로운 지표를 만들어내는 것보다

[19:27] 낫습니다

[19:30] 하지만 이는 또한

[19:33] 휴먼 인 더 루프가 필요하다는 뜻입니다.

[19:35] 그들은 인간 평가가

[19:37] 자동 평가가 놓치는 부분을 잡아낸다고 말합니다.

[19:40] 흥미로운 예로, 그들의 경우

[19:42] 인간 테스터들이 초기

[19:44] 에이전트들이 일관되게

[19:46] 권위 있지만 순위가 낮은

[19:49] SEO 최적화된 콘텐츠 형식을 선택한다는 것을 발견했습니다.

[19:52] 학술 PDF 파일이나

[19:55] 개인 블로그와 같은 소스들보다 말이죠.

[19:57] 그리고 보상 해킹은

[20:00] 이런 에이전트나

[20:01] LLM 기반 시스템에서 실제로 발생하는 문제이며

[20:04] 생성 부분이나 LLM을

[20:07] 판사로 사용할 때 모두 발생할 수 있습니다.

[20:09] 따라서 평가자들을 확인하고

[20:12] LLM 판사가 생성하는 결과가

[20:16] 실제로 의미가 있는지 확인할

[20:19] 인간이 반드시 필요합니다. 그리고

[20:21] 이를 철저히 해야 하는데, 왜냐하면

[20:23] 그들이 강조하듯 멀티에이전트 시스템은

[20:25] 특정 프로그래밍 없이 발생하는

[20:28] 창발적 행동을 가지기 때문입니다.

[20:30] 예를 들어, 리드 에이전트의

[20:32] 작은 변화가 서브 에이전트들이

[20:35] 어떻게 행동하는지 예측 불가능하게 바꿀 수 있습니다.

[20:38] 이는 매우 중요한 점입니다.

[20:40] 만약 멀티에이전트 시스템을 구축한다면

[20:42] 단일 컴포넌트를 변경할 때, 예를 들어

[20:45] 오케스트레이터를 변경하면

[20:46] 다른 것은 건드리지 않았다고 가정하고

[20:49] 그 단순한 컴포넌트에 대해서만

[20:51] 평가를 실행할 수는 없습니다.

[20:52] 시스템의 나머지 부분에도 다운스트림 효과를 가질 것이기 때문입니다.

[20:57] 그래서 한 부분을 변경하면

[20:59] 엔드 투 엔드 평가를 실행해야 합니다.

[21:01] 이제 이런 것들을 프로덕션에

[21:03] 적용하는 몇 가지 권장사항이나 아이디어입니다.

[21:05] 하나는 에이전트들이 상태를 가지며

[21:07] 오류가 누적된다는 것입니다.

[21:10] 다시 말해, 시스템의 한 부분에

[21:12] 변경을 가하면 다운스트림으로 갈수록

[21:15] 누적될 오류를 생성하기 시작합니다.

[21:17] 따라서 시스템을 추적하고

[21:20] 관찰할 수 있는 지표나

[21:23] 시스템을 구축하는 것이 중요하며

[21:26] 이는 고유한 도전을 가져옵니다.

[21:30] 전체 에이전트 시스템을

[21:32] 단순히 재생성할 수는 없고

[21:34] 그들이 제안하는 방법은 오류가 발생했을 때

[21:36] 처음부터 재시작할 수 없다는 것입니다.

[21:37] 재시작은 비용이 많이 들고

[21:39] 사용자에게 좌절감을 줍니다.

[21:42] 그래서 그들은 오류가 발생했을 때

[21:44] 에이전트가 있던 곳에서

[21:46] 재개할 수 있는 시스템을 구축했습니다.

[21:48] 그리고 그들은 모델의

[21:50] 지능을 사용해 문제를

[21:51] 우아하게 처리한다고 말합니다.

[21:53] 이는 자기 개선으로 이어집니다.

[21:54] 예를 들어, 도구가 실패할 때

[21:57] 에이전트가 이를 알고 적응할 수 있도록 하는 것입니다.

[21:59] 작업에 적응하는 것이 놀랍도록 잘 작동하는 것 같습니다.

[22:02] 또 다른 매우

[22:04] 흥미로웠던 점은 이들이 어떻게

[22:07] 멀티 에이전트 시스템을 배포하는지였습니다.

[22:09] 에이전트 시스템은 높은 수준의 상태 유지 웹이라고 말합니다.

[22:12] 프롬프트, 도구, 실행 로직이

[22:15] 거의 지속적으로 실행됩니다. 예를 들어

[22:17] 시스템을 배포하면 계속

[22:19] 실행됩니다. 따라서 실제로는

[22:21] 시스템 전체를 업그레이드할 수 없습니다. 그리고 이런

[22:24] 방식으로 전통적인 소프트웨어

[22:26] 엔지니어링 원칙이 매우 중요하다고 생각합니다

[22:29] 이런 것들로 구축하더라도

[22:30] 멀티 에이전트 시스템으로 말이죠. 배포할 때

[22:33] 그들은 레인보우

[22:35] 배포 전략을 사용하고 아이디어는

[22:37] 이전 업데이트나 이전 시스템을 점진적으로

[22:39] 새로운 시스템으로 교체하는 것입니다

[22:41] 모든 것을 한 번에 배포하는 대신

[22:44] 말이죠. 그들이 강조하는 또 다른 점은

[22:47] 동기식 실행입니다.

[22:49] 현재 그들은 말합니다.

[22:51] 우리의 리드 에이전트가 서브 에이전트를 동기적으로 실행하여

[22:53] 각 서브 에이전트 세트가 완료될 때까지 기다린 후

[22:56] 진행하며 그 이유는

[22:57] 모든

[22:59] 에이전트의 결과를 집계해야 하기 때문입니다.

[23:01] 따라서 이런 시스템을

[23:04] 비동기적으로 실행하고 싶은 경우가 있을 수 있지만

[23:06] 그들의 특정 사용 사례에서는

[23:08] 아직 그 방법을 찾지 못한 것 같습니다.

[23:11] 어쨌든, 이것은 매우 흥미로운 읽을거리였습니다.

[23:14] 링크는

[23:16] 영상 설명에 있을 것입니다.

[23:18] 또한 구글과 OpenAI가 어떻게

[23:20] 에이전틱 시스템을 구축하려고 하는지에 대한 영상도 만들었습니다.

[23:24] 관심이 있으시다면

[23:26] 여기에 링크되어 있을 것입니다.

[23:28] 어쨌든, 이 영상이 유용했기를 바랍니다.

[23:31] 시청해 주셔서 감사하고

[23:33] 늘 그렇듯이, 다음 영상에서 뵙겠습니다.