일타 강사 저스틴의 에이전트 구축 전략 강의: 멀티 에이전트 vs. 단일 에이전트, 무엇이 옳을까?

안녕하세요, 여러분! 일타 강사 저스틴입니다. 오늘은 2025년 6월 16일에 Prompt Engineering 채널에 올라온 “Context Engineering for Building Better Agents” 영상을 바탕으로, 에이전트 시스템 구축에 대한 뜨거운 논쟁, 즉 멀티 에이전트 시스템이 좋을지, 아니면 단일 에이전트 시스템이 좋을지에 대해 심도 있게 분석해보겠습니다. 최근 앤트로픽(Anthropic)과 코그니션 랩스(Cognition Labs)에서 이와 관련된 흥미로운 아티클을 발표했는데요, 두 회사의 상반된 주장을 중심으로 에이전트 구축 전략을 파헤쳐 보겠습니다.

강의의 핵심: 복잡한 작업을 수행하는 에이전트 시스템을 구축할 때, 멀티 에이전트 아키텍처와 단일 에이전트 아키텍처 각각의 장단점을 비교 분석하고, 상황에 맞는 최적의 접근 방식을 제시합니다.

1. 멀티 에이전트 시스템 vs. 단일 에이전트 시스템: 두 관점 [Basic]

일반적인 접근 방식 (멀티 에이전트): 복잡한 작업을 여러 개의 하위 작업으로 나누고, 각 하위 작업을 독립적인 작은 서브 에이전트에게 할당합니다. 그런 다음 오케스트레이터(Orchestrator)와 어그리게이터(Aggregator)를 통해 이들을 통합하는 방식입니다 [0:53].
코그니션 랩스의 주장 (단일 에이전트): 코그니션 랩스는 멀티 에이전트 시스템이 항상 최적의 접근 방식은 아닐 수 있다고 주장합니다 [1:14].

2. 멀티 에이전트 시스템의 과제 [Critical]

정보 공유의 부재: 각 에이전트가 독립적으로 작업을 수행하므로, 다른 에이전트가 무엇을 하고 있는지 알 수 없습니다 [1:43].
오해로 인한 문제: 한 에이전트가 작업을 잘못 이해하면, 어그리게이터가 결과를 통합할 때 부정적인 영향을 미칠 수 있습니다 [1:54].
- 예시: Flappy Bird 클론을 만드는 경우, 각 서브 작업이 모델의 주요 테마를 독립적으로 구현하면 일관성이 없어질 수 있습니다 [2:04].

3. 정보 공유 방식의 문제점 [Complex]

실시간 컨텍스트 공유: 에이전트 간에 컨텍스트를 공유하는 방법은 OpenAI의 Agent SDK에서도 제안되었지만, 장기 실행 작업의 경우 모든 대화와 액션을 추적하기 어렵다는 문제가 있습니다 [2:22].
독립적인 의사 결정: 에이전트들이 독립적으로 의사 결정을 내리기 때문에, Flappy Bird 예시처럼 시각적 스타일이 완전히 다른 결과물이 나올 수 있습니다 [3:15].

4. 코그니션 랩스의 제안: 순차적 실행 방식 [Moderate]

단일 에이전트, 서브 태스크 수행: 동일한 에이전트가 작업을 분할하고, 서브 태스크를 순차적으로 수행하며, 메모리를 업데이트하는 방식입니다 [3:39].
장점:
- 일관성 유지: 동일한 에이전트가 순차적으로 작업을 수행하므로, 이전 결정에 대한 메모리와 대화 기록을 유지할 수 있어 일관성을 유지할 수 있습니다 [3:56].
단점:
- 컨텍스트 오버플로우: 장기 실행 작업의 경우 컨텍스트 오버플로우가 발생할 수 있습니다 [4:18].
해결책:
- 압축 LLM: 컨텍스트와 채팅 기록, 메모리를 압축하는 압축 LLM을 병렬로 실행하여 에이전트에게 필요한 컨텍스트를 제공합니다 [4:25].
컨텍스트 엔지니어링: 프롬프트 엔지니어링의 확장 개념으로, 에이전트가 지금까지 수행한 모든 액션과 응답에 대한 컨텍스트를 확보하도록 합니다 [4:44].
결론: 대부분의 작업에서 단일 에이전트가 멀티 에이전트보다 더 적합한 솔루션일 수 있습니다 [5:04]. Cloud Code가 좋은 예시입니다 [5:17].

5. 앤트로픽의 주장: 멀티 에이전트 시스템의 가능성 [Moderate]

연구 시스템: 앤트로픽은 멀티 에이전트 시스템이 효과적일 수 있다고 주장하며, 특히 검색 애플리케이션에 적합하다고 말합니다 [6:22].
웹 검색 구현: 앤트로픽의 멀티 에이전트 연구 시스템은 최고의 웹 검색 구현 중 하나입니다 [6:41].
아키텍처:
- 리드 연구원 (Lead Researcher): 사용자 쿼리를 기반으로 계획을 생성합니다 [7:11].
- 서브 에이전트 (Sub-agents): 계획을 실행하고, 다양한 도구에 액세스하여 독립적으로 작업을 수행합니다 [7:11].
- 오케스트레이터 (Orchestrator): 결과를 수집하고 통합하여 최종 응답을 생성합니다 [7:28].
성능 향상: 앤트로픽은 Cloud Opus 4를 리드 에이전트로, Cloud Solid 4를 서브 에이전트로 사용하는 멀티 에이전트 시스템이 단일 에이전트보다 성능이 90% 더 높았다고 밝혔습니다 [8:44].
토큰 사용량: 멀티 에이전트 시스템은 더 많은 토큰을 사용하지만, 성능 향상을 가져올 수 있습니다 [9:17].
제한 사항: 앤트로픽은 멀티 에이전트 시스템이 모든 애플리케이션에 적합한 것은 아니며, 특히 컨텍스트 공유가 중요하거나 에이전트 간 의존성이 높은 경우에는 적합하지 않다고 지적합니다 [10:16]. 코딩 작업은 검색보다 병렬화할 수 있는 작업이 적기 때문에 멀티 에이전트 시스템에 적합하지 않습니다 [10:32].

6. 실용적인 통찰력 및 권장 사항 [Complex]

프롬프트 엔지니어링: 에이전트에게 명확한 지침을 제공하는 것이 중요합니다 [11:54].
- 에이전트처럼 생각하기: 인간이 작업을 수행하는 방식을 단계별로 분석하고, 에이전트가 이를 복제하도록 지시합니다 [12:26].
- 오케스트레이터 교육: 오케스트레이터가 작업을 계획하고 위임하는 방법을 명확하게 전달합니다 [12:52].
- 작업 복잡도에 따른 노력: 작업의 복잡성에 따라 적절한 규모의 컴퓨팅 리소스를 할당합니다 [13:18].
도구 설계 및 선택: 도구의 복잡성을 고려하여 설계하고, 도구에 대한 명확한 설명을 제공합니다 [14:02]. 에이전트가 스스로 도구 설명을 변경하거나, 사용 가능한 도구를 수정할 수 있도록 합니다 [14:42].
검색: 넓게 시작하여 좁혀나가고, 사고 과정을 안내합니다 [15:08].
병렬 처리: 병렬 도구 실행 및 병렬 서브 에이전트를 사용하여 연구 시간을 단축할 수 있습니다 [15:50].

7. 평가 및 메트릭 [Critical]

평가의 중요성: 개선 사항을 측정하려면 좋은 평가 시스템이 필요합니다 [16:30].
멀티 에이전트 시스템 평가의 어려움: 멀티 에이전트 시스템은 비결정적 시스템이므로 평가가 더 복잡합니다 [16:43].
소규모 평가 데이터 세트: 실제 사용을 대표하는 20개의 쿼리로 시작하여 시스템을 평가합니다 [17:14].
LLM을 심판으로 활용: LLM을 사용하여 0에서 1 사이의 점수와 합격/불합격 등급을 출력하도록 하는 것이 가장 일관성 있고 인간의 판단과 일치합니다 [18:02].
인간의 참여: 자동화된 평가에서 놓치는 부분을 인간 평가자가 발견할 수 있습니다 [19:33].
시스템 변경 시 주의사항: 멀티 에이전트 시스템은 예측할 수 없는 동작이 발생할 수 있으므로, 한 부분을 변경하면 시스템 전체에 영향을 미칠 수 있습니다 [20:23].

8. 배포 및 실행 전략 [Moderate]

에이전트는 상태를 유지: 시스템의 한 부분을 변경하면 오류가 발생할 수 있으므로, 시스템을 추적하고 관찰할 수 있는 메트릭이 필요합니다 [21:06].
오류 발생 시 재시작 방지: 오류가 발생하면 처음부터 다시 시작하는 대신, 오류가 발생한 지점부터 다시 시작할 수 있는 시스템을 구축합니다 [21:33].
레인보우 배포 전략: 시스템 전체를 한 번에 배포하는 대신, 이전 시스템을 새로운 시스템으로 점진적으로 교체하는 방식으로 배포합니다 [22:33].
동기 실행: 리드 에이전트가 서브 에이전트가 완료될 때까지 동기적으로 기다린 후 다음 단계를 진행합니다 [22:47].

마무리

오늘은 앤트로픽과 코그니션 랩스의 아티클을 통해 멀티 에이전트 시스템과 단일 에이전트 시스템의 장단점을 비교 분석하고, 에이전트 구축 전략에 대해 논의했습니다. 어떤 아키텍처가 더 나은지는 애플리케이션의 특성과 작업의 복잡성에 따라 달라질 수 있습니다. 이번 강의를 통해 여러분은 에이전트 시스템을 구축할 때 다양한 요소를 고려하고, 상황에 맞는 최적의 전략을 선택할 수 있게 되셨을 겁니다.

[핵심]: 멀티 에이전트 시스템과 단일 에이전트 시스템 중 어느 것이 더 낫다고 단정 지을 수는 없습니다. 중요한 것은 각 시스템의 장단점을 이해하고, 구축하려는 에이전트의 목적과 작업의 특성에 맞춰 최적의 아키텍처를 선택하는 것입니다.