Hybrid Multi-Agent System, 설계 원리와 적용
LLM 기반 에이전트를 파이프라인의 모든 단계에 균일하게 배치하면 두 가지 문제가 동시에 발생한다. 판단이 필요 없는 반복적·결정론적 작업까지 매번 추론을 거치므로 토큰 비용과 지연 시간이 불필요하게 늘어나고, 같은 입력에 대해서도 매번 다른 경로로 추론이 진행될 수 있어 재현성이 떨어진다. 반대로 파이프라인 전체를 결정론적 규칙과 학습된 함수로만 구성하면 사전에 열거할 수 없는 예외 상황이나 열린 판단이 필요한 구간을 처리할 수 없다.
Hybrid Multi-Agent System은 이 두 문제를 동시에 풀기 위해 파이프라인의 각 단계를 그 단계가 실제로 요구하는 에이전트 클래스에 맞춰 배치하는 설계 방식이다. 판단과 재관찰이 필요한 구간에는 추론 기반 에이전트를 배치하고 입력과 출력이 고정적으로 대응하는 구간에는 결정론적 함수를 배치해, 자율성이 필요한 곳에서는 자율성을 확보하고 자원 효율이 필요한 곳에서는 효율을 확보한다.
이 글에서는 Hybrid Multi-Agent System을 학계와 산업계의 논의를 통합적으로 검토해서 정의를 명확하게 하고 이를 구성하는 에이전트 클래스와 배치 기준을 살펴 본다. 이를 바탕으로 정형화된 기술 스펙을 입력으로 받는 표준 웹 애플리케이션 자동 개발 파이프라인을 대표 사례로 살펴본다.
Hybrid Multi-Agent System의 정의
멀티에이전트 시스템(Multi-Agent System, MAS)은 여러 자율적인 에이전트가 상호작용하며 하나의 문제를 해결하는 계산 시스템을 가리키는 분산 AI 분야의 오랜 표준 용어다. 각 에이전트는 부분적인 자율성을 가지고 시스템 전체에 대한 완전한 정보 없이 국소적인 관점에서 동작하며, 단일 에이전트가 전체 행동을 통제하지 않는 탈중앙화된 구조를 특징으로 한다.
여기서 혼동하기 쉬운 용어 하나를 먼저 살펴 보면, "Hybrid Agent(Architecture)"는 하나의 에이전트 내부에서 즉각적인 반응을 처리하는 반응형(reactive) 계층과 계획을 수립하는 숙고형(deliberative) 계층을 결합한 아키텍처를 가리키는 오래전부터 이어진 별개의 개념이다. 이는 단일 에이전트의 내부 구조에 관한 논의이지 여러 에이전트로 구성된 팀에 관한 논의가 아니라는 것에 주목할 필요가 있다. 반면 이 글에서 다루는 Hybrid Multi-Agent System은 팀을 구성하는 에이전트 자체가 서로 다른 클래스로 섞여 있다는 뜻이며, 두 용어는 서로 다른 층위를 가리키므로 혼용하면 안 된다.
추론 기반 에이전트와 결정론적 함수를 하나의 시스템 안에 섞어 쓰는 접근 자체는 2024년 버클리 AI 연구진이 제시한 컴파운드 AI 시스템(Compound AI System) 개념과 맞닿아 있다. 이 개념은 AI 과제를 모델 호출, 검색기, 외부 도구 등 여러 상호작용하는 컴포넌트의 조합으로 처리하는 시스템을 가리킨다. 실제로 LLM 기반 멀티에이전트 시스템에 관한 최근 연구에서도 생성형 에이전트를 규칙 기반 에이전트로 대체해 효율을 높인 사례가 보고된 바 있다. 다만 이런 조합을 "Hybrid Multi-Agent System"이라는 하나의 이름으로 체계화해 다루는 표준 분류 체계는 아직 확립되어 있지 않다. 이 글에서 쓰는 이 명칭은 각 에이전트를 그 역할에 맞는 클래스로 명시적으로 구분하고 배치하는 실무적 설계 패턴을 가리키는 용어로 이해하는 것이 정확하다.
에이전트 클래스: ReAct Agent와 Functional Agent
Hybrid Multi-Agent System을 구성하는 에이전트는 크게 두 클래스로 나뉜다.
| 클래스 | 정의 | 실행 형태 |
|---|---|---|
| ReAct Agent | 관찰 이력에 따라 다음 행동이 매번 달라지는 과정(process). 고정된 함수가 아니며 유일하게 AI 에이전트라 부를 수 있는 클래스다 | 관찰(Observation) → 가설(Hypothesis) → 행동(Action) → 재관찰의 반복 |
| Functional Agent — Rule-based | 사람이 명시적으로 작성한 결정론적 함수. 같은 입력에 항상 같은 출력을 낸다 | 입출력 검증 후 즉시 반환하며 변경은 코드 리뷰로 관리한다 |
| Functional Agent — Learned | 데이터에서 통계적으로 도출된 고정 함수(classical ML). 내부 상태나 실행 이력에 의존하지 않는다 | 입출력 검증 후 즉시 반환하며 데이터 드리프트 감지·재학습·버전 관리가 필요하다 |
Hybrid Multi-Agent System을 구성하는 에이전트 클래스
세 클래스 모두 세션 상태를 유지할 필요가 없고 재시도만으로 충분하다는 점에서 실행 형태는 비슷해 보이지만, ReAct Agent는 매 호출마다 관찰 이력에 따라 경로가 달라지는 반면 두 Functional Agent는 같은 입력에 대해 항상 같은 경로를 재현한다는 점에서 근본적으로 다르다. Functional Agent가 대표적으로 수행하는 역할은 네 가지로 정리된다. 스키마 입력을 고정 템플릿 산출물로 매핑하는 것(Rule-based), 유사도를 기준으로 대량 항목을 압축해 후속 처리 대상을 줄이는 것(Learned), 학습된 패턴으로 리스크를 점수화해 처리 순서를 정하는 것(Learned), 사전 정의된 조건의 불리언 판정으로 통과·실패를 확정하는 것(Rule-based)이다.
어디에 ReAct Agent를 배치할 것인가
ReAct Agent는 비용과 지연 시간이 크고 재현성도 상대적으로 낮으므로 파이프라인의 모든 구간에 배치할 이유가 없다. 다음 세 조건이 모두 충족되는 지점에만 배치하고 하나라도 조건에 맞지 않는 것이 있다면 Functional Agent나 결정론과 학습된 함수의 조합으로 대체하는 것을 우선 검토해야 한다.
첫째는 후보 공간의 유한성이다. 원인이나 선택지의 후보를 열거할 수 있어야 한다. 컴파일 에러의 원인이 될 수 있는 코드 경로는 정적으로 유한하게 열거할 수 있는 대표적인 예다.
둘째는 액션의 차별적 정보력이다. 액션은 실행되기 전에는 없던 새로운 정보를 만들어내야 한다. 같은 데이터를 다시 확인하는 절차는 액션이라 볼 수 없다.
셋째는 반증 가능한 판단 기준이다. 세운 가설이 참인지 거짓인지를 판정할 명확한 기준이 있어야 한다. 이 기준이 없으면 에이전트가 그럴듯한 사후 서사를 구성하는 확증편향에 빠질 위험이 있다.
대표 사례: 스펙 기반 표준 웹 애플리케이션 자동 개발 파이프라인
Hybrid Multi-Agent System이 실제로 어떻게 작동하는지는 정형화된 기술 스펙을 입력으로 받아 표준 스택(가령 프런트엔드·백엔드·데이터베이스로 구성된 전형적인 웹 애플리케이션)을 구현부터 테스트, 검증까지 자동화하는 파이프라인에서 잘 드러난다. 입력은 엔티티, API 계약, 화면 구성 등을 구조화한 스펙 문서이고, 스펙이 충분히 잘 작성되어 있다는 것을 전제로 아래에 정리한 흐름으로 파이프라인을 구성할 수 있다.
스펙 기반 웹 애플리케이션 파이프라인의 단계별 에이전트 배치 — 점선 상자는 소진까지 반복되는 순환 구간이다. 코드·diff 변경마다 상시 동작하며 이 순환 구간의 재실행 범위를 좁혀 주는 회귀영향분석(Learned)은 흐름도 밖에서 항상 함께 작동한다.
전체 테스트 실행 단계는 스캐폴딩·최종 게이트와 마찬가지로 결정론적이지만 에이전트로 분류하지 않는다. 입력 내용에 따라 출력이 달라지는 변환을 수행하지 않고 코드나 테스트 내용과 무관하게 항상 동일한 절차만 실행하는 인프라이기 때문이다. 실패 트리아지와 디버깅 루프는 순환 구조를 이룬다. 전체 테스트 실행에서 실패가 나오면 Learned Functional Agent가 실패를 그룹핑해서 압축하고, 그룹별 대표 실패를 ReAct Agent가 넘겨받아 원인을 역추적해 수정한 뒤 전체 테스트 실행을 반복한다. 그리고 이 순환 루프는 그룹핑한 대상들이 완전 소진될 때까지 유지된다.
클래스 경계를 지키는 설계 원칙
이 파이프라인이 실제로 자율적이면서도 자원 효율적으로 작동하려면 에이전트 클래스 사이의 경계를 명시적으로 지키는 몇 가지 원칙이 필요하다.
스펙 단일 소스 원칙이 첫째다. 스캐폴딩과 표준 테스트 생성은 반드시 같은 스펙 파서를 공유해야 한다. 두 단계를 별도의 LLM 호출로 각각 생성하면 동일한 오독을 두 산출물이 함께 공유하게 되어 서로가 서로의 오류를 잡아내지 못하는 위험이 생긴다.
ReAct 스코프 제한이 둘째다. 커스텀 로직 구현과 엣지케이스 테스트, 디버깅 루프는 "표준 스캐폴딩으로 해결되지 않는 부분"으로 범위를 명시적으로 좁혀야 한다. 이 범위가 모호해지면 재현성 저하와 비용 증가, 보안 취약점 확산이라는 위험이 다시 나타난다.
ML은 판정이 아니라 그룹화와 우선순위화만 수행한다는 원칙이 셋째다. 실패 트리아지와 회귀영향분석의 산출물은 "이것이 정답이다"가 아니라 "이것을 먼저 보라"는 우선순위 정보에 그친다. 실제 원인 확정과 수정 여부 판단은 반증 가능한 기준을 갖춘 ReAct Agent의 디버깅 루프가 담당한다.
최종 게이트는 항상 Rule-based로 고정한다는 원칙이 넷째다. 파이프라인의 마지막 통과·실패 판정에 LLM의 주관적 판단이 개입하면 검증 자체의 신뢰성이 흔들린다. 최종 판정은 언제나 기계적으로 재현 가능해야 한다.
에이전트 클래스 사이의 인터페이스를 강타입 스키마로 정의한다는 원칙이 다섯째다. ReAct Agent와 Functional Agent 사이의 경계는 자유 텍스트가 아니라 구조화된 태스크 스키마로 연결하고 실행 전에 파라미터 검증 게이트를 둔다. 이는 LLM의 할루시네이션이 검증 없이 결정론적 파이프라인으로 그대로 전파되는 것을 막기 위한 장치다.
이 다섯 원칙이 함께 작동하면 파이프라인은 두 가지를 동시에 확보한다. 판단과 재관찰이 실제로 필요한 구간(커스텀 로직 구현, 엣지케이스 해석, 디버깅)에는 ReAct Agent가 배치되어 사람의 개입 없이 자율적으로 문제를 풀어나가고, 입력과 출력이 고정적으로 대응하는 나머지 구간(스캐폴딩, 표준 테스트 생성, 그룹화, 우선순위화, 최종 판정)은 토큰 비용이 들지 않는 결정론적 함수나 경량 ML 모델이 처리한다. 파이프라인 전체를 ReAct Agent만으로 구성했을 때보다 LLM 호출 횟수와 토큰 비용이 크게 줄고, 결정론적 함수가 담당하는 구간은 항상 같은 입력에 같은 출력을 내므로 재현성도 함께 확보된다.
정리 및 요약
Hybrid Multi-Agent System은 하나의 팀 안에 서로 다른 클래스의 에이전트를 의도적으로 섞어 배치하는 설계 방식이다. 관찰 이력에 따라 매번 다른 경로로 판단하는 ReAct Agent와 같은 입력에 항상 같은 출력을 내는 Functional Agent를 나누는 기준은 후보 공간이 유한한지, 액션이 새로운 정보를 만들어내는지, 가설을 반증할 명확한 기준이 있는지 이 세 가지다. 이 세 조건을 모두 충족하는 구간에만 ReAct Agent를 두고 나머지는 결정론적 함수나 학습된 함수로 처리하는 것이 이 설계의 핵심 판단 규칙이다.
스펙 기반 웹 애플리케이션 자동 개발 파이프라인은 이 판단 규칙이 실제로 적용된 대표적인 유즈 케이스다. 커스텀 로직 구현과 엣지케이스 해석, 디버깅처럼 판단과 재관찰이 필요한 구간에는 ReAct Agent를 두고, 스캐폴딩과 표준 테스트 생성, 그룹화, 최종 판정처럼 입력과 출력이 고정적으로 대응하는 구간은 Functional Agent가 맡는 구성이다. 이 구성의 결과로 파이프라인은 판단이 필요한 구간에서는 사람의 개입 없이 자율적으로 문제를 해결하고, 판단이 필요 없는 구간에서는 LLM 호출 자체를 생략해 토큰 비용과 지연 시간을 함께 줄인다. 아울러 결정론적 구간의 산출물은 매번 동일한 경로로 재현되므로 파이프라인 전체의 신뢰성도 함께 높아진다. 자율성과 자원 효율, 재현성을 동시에 확보하는 이 결과가 곧 Hybrid Multi-Agent System을 적용해 얻는 실질적인 효과다.