나는 최근 복잡한 프로젝트 관리 자동화를 위해 여러 개의 LLM 에이전트를 연결해 보다가 한계에 부딪혔다. 단순히 에이전트 여러 개를 한 방에 몰아넣고 “서로 협력해서 해결해”라고 명령했더니, 서로의 말을 반복하거나 책임 소재가 불분명해 결국 엉뚱한 결론으로 빠지는 이른바 ‘대화의 늪’에 빠진 것이다. 마치 명확한 팀장 없이 모인 전문가들이 회의실에서 끝없는 토론만 하다가 시간을 다 쓰는 모습과 비슷했다.
이 경험을 통해 내가 깨달은 것은, 에이전트의 숫자를 늘리는 것보다 더 중요한 것이 바로 ‘구조(Structure)’라는 점이었다. 무질서한 수평적 구조가 아니라, 명확한 위계와 역할 분담이 존재하는 계층적 구조(Hierarchical Structure)가 도입되어야만 비로소 복잡한 문제 해결이 가능하다는 사실을 알게 되었다.
수평적 협업의 한계와 계층적 구조의 필요성
처음에는 단순히 ‘멀티 에이전트(Multi-Agent)’라는 개념에 매몰되어, 각 분야의 전문가 에이전트를 많이 배치하면 성능이 올라갈 것이라 믿었다. 예를 들어 기획자 에이전트, 개발자 에이전트, 검수자 에이전트를 만들어 놓고 이들이 자유롭게 의견을 주고받게 했다. 하지만 실제 결과물은 처참했다. 기획자가 수정한 내용을 개발자가 반영하는 사이, 검수자가 이전 버전의 기획안을 기준으로 피드백을 주는 식의 동기화 오류가 빈번하게 발생했다.
이런 현상은 정보의 과부하와 책임의 분산 때문에 일어난다. 모든 에이전트가 모든 메시지를 수신하는 ‘브로드캐스트’ 방식은 에이전트 수가 늘어날수록 토큰 소모량을 기하급수적으로 늘릴 뿐 아니라, 모델이 집중해야 할 핵심 맥락을 흐리게 만든다. 결국 우리에게 필요한 것은 단순한 협업이 아니라, 상위 수준에서 목표를 설정하고 하위 수준에서 이를 실행하는 오케스트레이션(Orchestration)이었다.
오케스트레이터: 지휘자의 등장
계층적 멀티 에이전트 모델의 핵심은 바로 ‘매니저’ 혹은 ‘오케스트레이터’ 역할을 하는 상위 에이전트를 두는 것이다. 이 상위 에이전트는 직접 문제를 풀지 않는다. 대신 사용자의 모호한 요청을 분석하여 작은 단위의 태스크(Sub-tasks)로 쪼개고, 이를 수행하기에 가장 적합한 하위 에이전트에게 할당하는 역할에 집중한다.
내가 설계해 본 구조에서는 오케스트레이터가 일종의 ‘라우터’ 역할을 수행했다. 예를 들어 “새로운 서비스의 시장 조사 보고서를 작성해 줘”라는 요청이 들어오면, 오케스트레이터는 이를 다음과 같이 분해한다. 첫째, 최신 트렌드 검색, 둘째, 경쟁사 분석, 셋째, SWOT 분석 도출. 그리고 각각의 태스크를 검색 전문 에이전트와 분석 전문 에이전트에게 순차적으로 혹은 병렬적으로 배분한다.
여기서 중요한 점은 하위 에이전트들이 서로의 존재를 알 필요가 없게 만드는 것이다. 하위 에이전트는 오직 상위 매니저가 준 지시사항에만 집중하고, 결과물을 다시 매니저에게 보고한다. 이렇게 하면 개별 에이전트가 처리해야 할 컨텍스트 윈도우가 획기적으로 줄어들어, 훨씬 더 정교하고 정확한 답변을 얻을 수 있게 된다.
피드백 루프와 품질 관리의 체계화
계층적 구조의 진정한 위력은 ‘검토 및 수정(Review & Refine)’ 단계에서 나타난다. 수평적 구조에서는 누군가 틀린 말을 해도 다른 에이전트가 이를 지적하지 않고 그대로 수용해버리는 ‘집단 사고’의 오류가 잦다. 하지만 계층적 구조에서는 오케스트레이터가 최종 결과물을 검수하는 ‘게이트키퍼’ 역할을 수행한다.
나는 이를 위해 ‘비판자(Critic)’ 에이전트를 계층 구조의 중간 단계에 배치해 보았다. 하위 에이전트가 제출한 결과물을 비판자 에이전트가 먼저 검토하고, 기준에 미달하면 다시 하위 에이전트에게 반려(Reject)하는 루프를 만든 것이다. 오케스트레이터는 이 루프가 적절히 돌아가는지 감독하며, 최종적으로 승인된 결과물만을 취합해 사용자에게 전달한다.
이 과정에서 발생하는 흥미로운 지점은, 상위 에이전트가 하위 에이전트의 성능을 평가하며 스스로 프롬프트를 최적화하기 시작한다는 점이다. “A 에이전트는 요약 능력이 부족하니, 이번에는 지시사항을 더 구체적으로 전달해야겠다”라는 식의 메타 인지가 시스템 전체의 효율성을 높이는 동력이 된다.
복잡성을 다루는 태도와 앞으로의 고민
결국 계층적 멀티 에이전트 협업은 소프트웨어 공학의 ‘모듈화’ 원칙을 AI 에이전트 세계에 적용한 것과 같다. 거대한 하나의 지능에 의존하는 것이 아니라, 작고 날카로운 지능들을 체계적으로 배치하고 이를 관리하는 상위 논리를 구축하는 것이 핵심이다. 이를 통해 우리는 단일 모델이 가질 수 없는 확장성과 안정성을 확보할 수 있다.
물론 완벽한 것은 아니다. 계층이 깊어질수록 응답 속도가 느려지는 레이턴시 문제가 발생하고, 상위 에이전트가 잘못된 판단을 내렸을 때 하위 에이전트 전체가 엉뚱한 방향으로 질주하는 ‘단일 실패 지점(Single Point of Failure)’의 위험도 존재한다. 이를 어떻게 보완할 것인가가 다음 단계의 과제가 될 것 같다.
이번 실험을 통해 나는 AI를 다루는 능력이 단순히 ‘프롬프트를 잘 쓰는 것’에서 ‘시스템을 잘 설계하는 것’으로 옮겨가고 있음을 느꼈다. 이제는 개별 모델의 성능보다, 그 모델들을 어떻게 엮어 하나의 유기적인 조직처럼 움직이게 할 것인지가 더 중요한 시대가 아닐까 싶다. 여러분의 워크플로우에서도 단순히 챗봇과 대화하는 것을 넘어, 자신만의 작은 ‘AI 조직’을 설계해 본 적이 있는지 궁금하다.