멀티 에이전트 시스템 (Multi-Agent Systems): 강력한 아이디어, 과하게 복잡해지기 쉬운 함정

다섯 명의 에이전트가 서로 대화하고, 작업을 할당하고, 계획을 토론하고, 코드를 작성하고, 코드를 리뷰하고, 버그를 수정하며, 승리를 선언하는 AI 데모를 본 적이 있나요?

그것은 미래지향적으로 보입니다. 하지만 동시에 관리자도 없고, 의제도 없으며, 모두가 동시에 자신 있게 말하는 회의처럼 수상해 보이기도 합니다.

**멀티 에이전트 시스템 (Multi-agent systems)**은 유용할 수 있습니다. 특화된 에이전트들이 업무를 분담하고, 서로를 점검하며, 복잡한 워크플로우 (workflow)를 처리할 수 있기 때문입니다. 하지만 이는 또한 매우 과하게 복잡해지기 쉽습니다. 에이전트가 더 많다고 해서 자동으로 지능이 높아지는 것은 아닙니다. 때로는 그저 혼란이 숨어들 곳이 더 많아질 뿐입니다.

하나의 유능한 에이전트가 혼란스러운 다섯 명의 에이전트보다 낫다

여러 에이전트를 추가하기 전에, 좋은 도구를 갖추고 지시를 잘 받은 하나의 에이전트가 문제를 해결할 수 있는지 자문해 보십시오.

많은 "멀티 에이전트" 워크플로우 (workflows)는 사실 코스튬을 입은 하나의 워크플로우일 뿐입니다. 플래너 에이전트 (Planner agent), 코더 에이전트 (coder agent), 리뷰어 에이전트 (reviewer agent), 테스터 에이전트 (tester agent), 매니저 에이전트 (manager agent) — 이름은 인상적이지만, 만약 그들이 모두 동일한 컨텍스트 (context)를 보고 검증되지 않은 텍스트를 생성한다면, 품질을 높이지 못한 채 지연 시간 (latency)만 추가했을 수도 있습니다.

이것은 토스트를 만들기 위해 레스토랑의 전체 직원을 고용하는 것과 같습니다. 기술적으로는 가능하지만, 반드시 똑똑한 방식은 아닙니다.

다음과 같은 경우에는 하나의 에이전트를 사용하십시오

1. 작업 범위가 좁을 때. 단일 버그 수정이나 작은 리팩토링 (refactor)에는 위원회가 필요하지 않습니다.
2. 도구가 단순할 때. 파일 읽기, 코드 편집, 테스트 실행 등은 종종 하나의 루프 (loop) 안에서 해결될 수 있습니다.
3. 컨텍스트 (context)가 공유될 때. 모든 역할이 동일한 정보를 필요로 한다면, 분리하는 것이 도움이 되지 않을 수 있습니다.
4. 리뷰가 사람에 의해 주도될 때. 사람이 최종 판단을 내릴 수 있다면 에이전트의 역할은 줄어듭니다.
5. 지연 시간 (latency)이 중요할 때. 에이전트가 많아질수록 일반적으로 호출 횟수가 늘어나고, 비용이 증가하며, 대기 시간이 길어집니다.

단순한 단일 에이전트 워크플로우 (single-agent workflow)만으로도 충분할 수 있습니다:

버그를 분석하고, 실패하는 테스트를 작성하며, 가장 작은 수정안을 제안하고, 승인된 검증 명령어를 실행한 뒤, 변경 사항(diff)을 요약합니다.

이것은 지루한 작업이 아닙니다. 효율적인 작업입니다.

멀티 에이전트가 실제로 도움이 되는 경우

멀티 에이전트 시스템 (Multi-agent systems)은 서로 다른 역할에 서로 다른 도구, 컨텍스트 (context), 또는 평가 기준이 필요할 때 유용해집니다.

예를 들어, 리서치 에이전트 (research agent)는 문서를 수집하고, 플래닝 에이전트 (planning agent)는 구현 단계를 생성하며, 코딩 에이전트 (coding agent)는 파일을 수정하고, 리뷰 에이전트 (review agent)는 보안 위험을 점검할 수 있습니다. 가치는 에이전트 연극 (agent theater)이 아니라 관심사의 분리 (separation of concerns)에서 나옵니다.

병원을 생각해보세요. 다섯 명의 무작위 의사가 소리를 지르는 것을 원치 않을 것입니다. 여러분이 원하는 것은 명확한 전문의들이며, 각자가 역할, 차트 접근 권한, 그리고 에스컬레이션 규칙 (escalation rules)을 갖추고 있는 상태입니다.

좋은 멀티 에이전트 활용 사례

1. 리서치 및 구현. 한 에이전트가 컨텍스트를 수집하는 동안, 다른 에이전트는 승인된 조사 결과로부터 코드를 작성합니다.
2. 생성기 및 비평가 (Generator plus critic). 한 에이전트가 제안하면, 다른 에이전트가 규칙이나 테스트에 따라 검증합니다.
3. 보안 리뷰. 특화된 리뷰어가 인증 (auth), 인젝션 (injection), 비밀 정보 (secrets), 그리고 데이터 노출을 점검합니다.
4. 대규모 문서 워크플로우. 추출 (extraction), 정규화 (normalization), 검증 (validation), 그리고 요약 (summarization)을 분리할 수 있습니다.
5. 운영 (Ops) 워크플로우. 한 에이전트가 로그를 조사하는 동안, 다른 에이전트는 승인을 위한 복구 계획 초안을 작성합니다.

중요한 점은 모든 에이전트가 동일한 권한을 가져서는 안 된다는 것입니다. 어떤 에이전트는 제안할 수 있고, 어떤 에이전트는 검증할 수 있습니다. 코드를 작성할 수 있는 에이전트는 적어야 하며, 배포 (deploy)를 할 수 있는 에이전트는 거의 없어야 합니다.

혼돈의 문제

멀티 에이전트 시스템은 흥미로운 방식으로 실패합니다.

에이전트들이 서로의 말을 반복하거나, 서로 모순되거나, 잘못된 가정을 하위 단계로 전달하거나, 생산적인 것처럼 느껴지지만 신뢰할 수 있는 결과물 (artifact)을 만들어내지 못하는 긴 대화를 생성할 수 있습니다. 또한 어떤 에이전트가 잘못된 결정을 내렸는지 아무도 알 수 없기 때문에 시스템을 디버깅 (debug)하기 어려워질 수도 있습니다.

관측 가능성 (observability)이 없는 멀티 에이전트 워크플로우는 누군가 운영 환경 (production)을 변경했지만 모두가 그저 "우리가 그것에 대해 논의했다"라고만 기억하는 단체 채팅방과 같습니다.

일반적인 멀티 에이전트 문제 (Common Multi-Agent Problems)

1. 역할 중복 (Role overlap). 두 에이전트가 동일한 작업을 수행하고 서로 충돌하는 결과물을 생성합니다.
2. 컨텍스트 드리프트 (Context drift). 각 에이전트가 서로 약간씩 다른 이해를 바탕으로 작업합니다.
3. 권한 모델 부재 (No authority model). 시스템이 누구의 답변이 최종적으로 승인되어야 하는지 알지 못합니다.
4. 무한 루프 (Unbounded loops). 에이전트들이 서로에게 계속해서 수정을 요청하며 반복합니다.
5. 취약한 검증 (Weak verification). 최종 답변이 검토된 것처럼 들리지만, 실제로 테스트된 적은 없습니다.

이것이 바로 결정론적 가드레일 (deterministic guardrails)이 중요한 이유입니다. 모델 외부에서 테스트, 스키마 (schemas), 승인 (approvals), 예산 (budgets), 타임아웃 (timeouts), 그리고 권한 경계 (permission boundaries)와 같은 엄격한 규칙이 필요합니다.

인터페이스처럼 역할 설계하기 (Design Roles Like Interfaces)

좋은 에이전트 역할은 소프트웨어 인터페이스 (interface)만큼 명확해야 합니다.

입력 (Inputs), 출력 (outputs), 도구 (tools), 권한 (permissions), 그리고 성공 기준 (success criteria)이 명시적이어야 합니다. 만약 에이전트가 무엇을 할 수 있는지 설명할 수 없다면, 그것은 아마도 너무 모호한 상태일 것입니다.

간단한 역할 계약 (A Simple Role Contract)

agents/reviewer.yaml

name: security_reviewer
input:
  - git_diff
...

이것은 지루한 설정처럼 보일 수 있지만, 매우 중요합니다. 이는 에이전트를 단순히 "이름만 있는 느낌적인 느낌"에서 통제 가능한 컴포넌트 (component)로 탈바꿈시킵니다.

코딩 에이전트는 쓰기 권한 (write access)을 가질 수 있습니다. 하지만 리뷰어 에이전트는 아마도 권한이 없어야 할 것입니다. 리서치 에이전트는 문서에는 접근할 수 있지만 자격 증명 (credentials)에는 접근할 수 없을 것입니다. 이러한 경계가 곧 시스템입니다.

검증은 결정론적이어야 합니다 (Verification Should Be Deterministic)

에이전트들이 서로를 검토할 수는 있지만, 중요한 관문 (gates)은 여전히 결정론적 체크 (deterministic checks)가 결정해야 합니다.

테스트 (Tests), 린터 (linters), 정적 분석 (static analysis), 타입 체크 (type checks), 스키마 검증 (schema validation), 보안 스캐너 (security scanners), 그리고 인간의 승인 (human approval)은 구식 장애물이 아닙니다. 이것들은 에이전트 워크플로 (agent workflows)를 현실에 기반하게 유지하는 방법입니다.

AI는 변경 사항이 좋아 보인다고 말해줄 수 있습니다. 하지만 테스트는 특정 동작이 여전히 작동함을 증명할 수 있습니다. 둘 다 유용하지만, 동일한 것은 아닙니다.

전문가 팁 (Pro Tips)

1. 에이전트를 하나로 시작하세요. 특정 역할이 존재해야 할 명확한 이유가 있을 때만 에이전트를 추가하세요.
2. 소유권(Ownership)을 정의하세요. 각 에이전트는 구체적인 작업과 출력물을 가져야 합니다.
3. 도구(Tools)를 제한하세요. 모든 에이전트에게 모든 권한을 부여하지 마세요.
4. 스키마(Schemas)를 사용하세요. 구조화된 출력(Structured outputs)은 검증(Validate)하고 라우팅(Route)하기가 더 쉽습니다.
5. 타임아웃(Timeouts)과 예산(Budgets)을 추가하세요. 에이전트가 무한 루프에 빠지는 것을 방지하세요.
6. 위험도가 높은 작업에는 인간의 승인을 유지하세요. 특히 배포(Deploys), 삭제(Deletes), 마이그레이션(Migrations), 그리고 보안에 민감한 변경 사항이 이에 해당합니다.

워크플로 게이트(Workflow gate)는 다음과 같이 간단할 수도 있습니다:

scripts/agent-gate.sh

#!/usr/bin/env bash
set -euo pipefail

...

해당 스크립트는 설득력 있는 설명에 감명받지 않습니다. 스크립트는 통과하거나 실패할 뿐입니다. 때로는 그것이 정확히 당신에게 필요한 것입니다.

마지막 팁 (Final Tips)

저는 각 에이전트가 지루할 정도로 명확한 업무를 수행할 때 멀티 에이전트 시스템(Multi-agent systems)을 선호합니다. 아키텍처 다이어그램에 실제 제약 조건(Constraints)보다 더 많은 에이전트가 그려져 있을 때 저는 불안함을 느낍니다. 그것은 대개 증거가 나타나기도 전에 복잡성부터 도착했다는 것을 의미하기 때문입니다.

제 의견은 이렇습니다. 최고의 멀티 에이전트 시스템은 자율적인 위원회(Autonomous committees)처럼 느껴지기보다는, 특정 단계 내에 AI가 포함된 정교하게 설계된 워크플로(Workflows)처럼 느껴질 것입니다.

멀티 에이전트를 사용하는 것은 데모를 더 멋지게 만들기 위해서가 아니라, 혼란을 줄여줄 때여야 합니다. 로봇들을 잘 조직화하시길 바랍니다 👊

원문은 nazarboyko.com에 게시되었습니다.