나는 최근 LLM 기반의 에이전트를 활용해 복잡한 워크플로우를 자동화하려다 큰 벽에 부딪혔다. 단순히 프롬프트를 잘 짜거나 에이전트 몇 명을 붙여놓는 것만으로는, 단계가 많아질수록 전체 맥락이 꼬이고 결과물이 산으로 가는 ‘컨텍스트 붕괴’ 현상이 일어났기 때문이다. 그러다 우연히 AgentOrchestra라는 계층적 멀티 에이전트 프레임워크에 관한 논문과 기술 패턴들을 접하게 되었고, 이것이 내가 겪던 혼란을 해결할 실마리가 될 수 있겠다는 확신이 들었다.
단순한 협업을 넘어 ‘지휘’가 필요한 이유
처음에는 그저 여러 개의 전문 에이전트를 만들고 서로 대화하게 하면 될 줄 알았다. 예를 들어 ‘리서치 에이전트’가 자료를 찾고 ‘작성 에이전트’가 글을 쓰는 식이다. 하지만 실제 구현해 보니 에이전트들끼리 서로의 말을 반복하거나, 원래 목표와 상관없는 세부 사항에 매몰되는 경우가 허다했다. 이는 중앙에서 전체 흐름을 제어하는 ‘컨덕터(Conductor)’의 부재 때문이었다.
계층적 멀티 에이전트 협업(Hierarchical Multi-Agent Coordination)의 핵심은 바로 이 지휘 체계에 있다. AgentOrchestra 같은 프레임워크는 중앙의 플래닝 에이전트가 상위 수준의 목표를 설정하고, 이를 실행 가능한 작은 단위의 하위 작업으로 분해(Decomposition)하여 적절한 전문 에이전트에게 할당한다. 마치 오케스트라 지휘자가 각 악기 연주자에게 언제 어떤 파트를 연주할지 지시하는 것과 같다.
이런 구조를 도입하면 각 하위 에이전트는 전체 그림을 다 알 필요 없이 자신에게 주어진 구체적인 태스크에만 집중하면 된다. 이는 LLM의 토큰 제한 문제를 완화할 뿐만 아니라, 각 단계의 출력값을 검증하고 수정하는 루프를 만들 수 있어 최종 결과물의 품질을 비약적으로 높여준다.
AgentOrchestra 스타일의 계층 구조 설계하기
실제로 이런 시스템을 구축하려면 먼저 중앙 플래너(Central Planner)와 전문가 에이전트(Specialist Agents)의 역할을 명확히 구분해야 한다. 플래너는 문제를 분석하고 ‘계획서’를 작성하는 역할이며, 전문가들은 그 계획서의 각 항목을 수행하는 도구(Tool)로서 동작한다. 최근의 기술 패턴들을 보면, 단순한 텍스트 전달이 아니라 구조화된 프로토콜을 통해 상태를 공유하는 방식이 주를 이룬다.
내가 시도해 본 구조는 다음과 같다. 먼저 플래너가 사용자의 요청을 받으면 이를 JSON 형태의 태스크 리스트로 변환한다. 이후 각 태스크에 최적화된 에이전트(예: Python 코드 실행 에이전트, 웹 검색 에이전트, 문서 요약 에이전트)를 호출하고, 그 결과물을 다시 취합해 최종 응답을 생성하는 방식이다. 이때 중요한 것은 하위 에이전트가 실패했을 때 플래너가 이를 감지하고 계획을 수정하는 ‘재계획(Replanning)’ 메커니즘을 넣는 것이다.
만약 이런 계층 구조 없이 모든 에이전트가 동등한 권한을 가지고 대화하는 ‘피어 투 피어(Peer-to-Peer)’ 방식을 썼다면, 아마 에이전트들끼리 서로의 의견에 동조하며 잘못된 방향으로 합의해버리는 ‘집단 사고’ 오류에 빠졌을 가능성이 크다. 계층 구조는 이러한 무질서를 막아주는 강력한 가드레일이 된다.
실전 구현: 간단한 계층적 에이전트 환경 구축
이론만으로는 부족하기에, 나는 오픈소스 라이브러리를 활용해 간단한 계층적 구조의 프로토타입을 만들어 보았다. 아래는 가상의 AgentOrchestra 스타일 프레임워크를 설정하고 실행하는 과정이다. 실제 구현 시에는 LangGraph나 CrewAI 같은 도구를 활용해 상태 머신을 설계하는 것이 효율적이다.
먼저 필요한 환경을 설정하고 에이전트들을 정의하는 과정은 다음과 같다.
- 가상 환경을 생성하고 필요한 LLM 오케스트레이션 라이브러리를 설치한다.
- 중앙 플래너 에이전트의 시스템 프롬프트에 ‘작업 분해 및 할당’ 규칙을 정의한다.
- 각 전문 에이전트에게 사용할 수 있는 도구(API, DB 접근 권한 등)를 매핑한다.
- 플래너가 생성한 태스크 큐를 순차적으로 실행하는 루프를 구현한다.
# 계층적 에이전트 실행 예시 (Python pseudo-code)
import agent_orchestra as ao
# 1. 전문 에이전트 정의
researcher = ao.Specialist(role="Researcher", tools=["web_search", "arxiv_api"])
coder = ao.Specialist(role="Coder", tools=["python_repl", "git_api"])
# 2. 중앙 플래너(Conductor) 설정
conductor = ao.Conductor(
llm="gpt-4o",
specialists=[researcher, coder],
planning_strategy="hierarchical_decomposition"
)
# 3. 복잡한 문제 투입
task = "최신 LLM 양자화 기법을 조사하고, 간단한 PyTorch 예제 코드를 작성해줘."
result = conductor.run(task)
print(f"최종 결과: {result}")처음 실행했을 때, 플래너가 코더 에이전트에게 리서치 단계 없이 바로 코드를 짜라고 지시하는 에러가 발생했다. 이를 해결하기 위해 플래너의 프롬프트에 "반드시 리서치 에이전트의 결과물을 확인한 후 코딩 단계로 진입하라"는 의존성 제약 조건을 추가했다. 설정 파일의 planning_strategy 옵션을 "sequential"에서 "hierarchical_decomposition"로 변경하자, 플래너가 스스로 [조사 → 검증 → 구현]이라는 단계적 로드맵을 그리기 시작했다.
더 정교한 조율을 위한 기술적 팁
시스템을 운영하며 느낀 점은, 계층 구조가 깊어질수록 정보 손실이 발생한다는 것이다. 상위 플래너가 하위 에이전트에게 지시를 내릴 때 너무 요약된 정보만 전달하면, 하위 에이전트가 맥락을 잘못 짚어 엉뚱한 결과물을 내놓는다. 이를 방지하기 위해 나는 ‘공유 메모리(Shared Memory)’ 개념을 도입했다.
모든 에이전트가 접근할 수 있는 공통의 상태 저장소(예: Redis 또는 단순한 JSON 파일)를 두고, 각 에이전트가 작업 결과뿐만 아니라 ‘왜 이런 결론에 도달했는지’에 대한 추론 과정(Reasoning Path)을 함께 기록하게 했다. 이렇게 하면 플래너가 하위 에이전트의 결과물을 검토할 때 훨씬 정교한 피드백을 줄 수 있다.
또한, HS-MARL(Hierarchical Symbolic Multi-Agent Reinforcement Learning) 같은 접근법에서 힌트를 얻어, 상징적인 지식 체계를 결합하는 시도도 해볼 만하다. 모든 것을 LLM의 확률적 생성에 맡기지 않고, 도메인 지식이 담긴 규칙 기반의 워크플로우를 계층 구조의 뼈대로 사용하면 시스템의 안정성이 비약적으로 향상된다.
마치며: 다음 단계로의 확장
이번에 계층적 멀티 에이전트 구조를 직접 설계하고 구현해 보며 배운 가장 큰 교훈은, AI 시스템의 성능은 개별 모델의 체급보다 ‘어떻게 협업 구조를 설계하느냐’에 달려 있다는 점이다. 아무리 똑똑한 모델이라도 명확한 지휘 체계와 역할 분담이 없다면 복잡한 문제 앞에서는 무너지기 마련이다.
앞으로는 단순히 텍스트 기반의 조율을 넘어, 에이전트들이 실시간으로 서로의 상태를 모니터링하고 동적으로 역할을 교대하는 ‘적응형 계층 구조’를 실험해 보고 싶다. 예를 들어, 특정 작업에서 리서치 에이전트의 성능이 떨어지면 플래너가 즉시 다른 보조 에이전트를 투입하는 방식이다.
혹시 여러분도 여러 개의 에이전트를 연결해 보았지만, 결과물이 일관되지 않아 고민한 적이 있으신가요? 그렇다면 단순한 연결이 아니라, 명확한 ‘지휘자’를 세우는 계층적 설계를 도입해 보시는 건 어떨까요?