우리는 스스로를 억제하지 못하는 것 같다. 멀티 에이전트 시스템에 대한 현재의 열풍은 유용한 패턴을 피할 수 없는 미래로 오해하는 위험을 안고 있다. 과거 마이크로서비스가 그랬던 것처럼. 기억하는가? 나름의 이유로 잘 작동하던 애플리케이션을 뜯어내 수많은 서비스로 쪼갠 뒤, 그렇게 만들어낸 복잡성을 관리하기 위해 서비스 메시, 트레이싱 스택, 플랫폼 팀을 구축했다. 마이크로서비스가 실질적인 장점을 제공한 것은 사실이다. 하지만 구글과 같은 문제를 안고 있지 않다면, 구글처럼 운영할 이유도 없다. (물론 그런 경우는 거의 없다.)

이제 AI 분야에서도 같은 실수가 반복되는 것 같다.

에이전트 데모마다 플래너 에이전트, 리서처 에이전트, 코더 에이전트, 리뷰어 에이전트가 등장한다. 심지어 아키텍처 다이어그램이 마음에 든다고 느끼는 것만이 역할인 에이전트까지 나온다. 멀티 에이전트 시스템이 나쁘다는 게 아니다. 마이크로서비스 때처럼, 현명하지 않을 정도로 광범위하게 처방되고 있다는 것이 문제다.

그렇다면 멀티 에이전트 방식을 언제 받아들여야 할까?

실질적인 패턴, 그러나 과대 포장된 비용

프런티어 모델을 개발하는 기업조차 개발자들에게 무분별한 사용을 자제해달라고 사실상 호소하고 있다. 앤트로픽은 2024년 에이전트 구축 가이드에서 “가능한 한 가장 단순한 솔루션”을 찾을 것을 명시적으로 권고하며, 경우에 따라서는 에이전트 시스템 자체를 구축하지 않는 것이 나을 수 있다고 밝혔다.

더 직접적으로, 앤트로픽은 많은 애플리케이션에서 검색 및 인컨텍스트 예제를 활용한 단일 대규모 언어 모델 호출 최적화만으로도 충분하다고 강조한다. 또한 프레임워크가 프롬프트와 응답을 가리는 추상화 계층을 만들고, 시스템 디버깅을 어렵게 하며, 더 단순한 구조로 충분한 상황에서도 개발자가 복잡성을 추가하도록 유혹할 수 있다고 경고한다. 기술 전문가 산티아고 발다라마는 같은 생각을 더 직설적으로 표현하며 “모든 것이 에이전트일 필요는 없고, 99%의 경우 필요한 것은 그냥 코드”라고 강조했다.

에이전트에 반대하는 것이 아니다. 엔지니어링 원칙의 문제다.

오픈AI도 비슷한 입장이다. 오픈AI의 실용 가이드는 단일 에이전트의 역량을 먼저 최대화할 것을 권고한다. 에이전트 하나에 도구를 더하는 방식이 복잡성, 평가, 유지보수 면에서 더 관리하기 쉽기 때문이다. 멀티 에이전트 프레임워크로 넘어가지 않고도 분기 복잡성을 흡수하는 방법으로 프롬프트 템플릿을 명시적으로 제안하기도 한다.

마이크로소프트도 단호하다. 보안이나 컴플라이언스 경계를 명확히 넘거나, 여러 팀이 관여하거나, 아키텍처적 분리가 필요한 경우가 아니라면 단일 에이전트 프로토타입부터 시작하라는 것이다. ‘플래너’, ‘리뷰어’, ‘실행자’ 역할이 자동으로 멀티 에이전트를 정당화하지는 않는다고도 경고한다. 페르소나 전환, 조건부 프롬프팅, 도구 권한 설정을 통해 단일 에이전트가 이런 역할을 충분히 수행할 수 있기 때문이다.

구글은 특히 유용한 관점을 제시한다. 서브 에이전트와 도구로 패키징된 에이전트 중 어느 쪽을 택하느냐에 따라 오버헤드가 크게 달라질 수 있다는 것이다. 결국 새로운 에이전트가 답이 아닐 수 있다. 역할과 범위가 명확히 정의된 함수 하나로 충분한 경우도 많다.

마이크로소프트는 한 가지를 더 강조한다. 겉으로 드러나는 많은 규모 문제는 아키텍처가 아니라 검색 설계에서 비롯된다는 점이다. 에이전트를 추가하기 전에 청킹, 인덱싱, 리랭킹, 프롬프트 구조, 컨텍스트 선택을 먼저 개선해야 한다. 소극적인 접근이 아니라 오히려 성숙한 판단이다. 마이크로소프트는 마이크로서비스 시대를 거치며 이 교훈을 뼈아프게 경험했다. 시스템을 분해해도 복잡성은 사라지지 않는다. 위치만 바뀔 뿐이다. 당시에는 네트워크로 이동했다. 이제는 핸드오프, 프롬프트, 중재, 에이전트 상태로 이동할 위협이 되고 있다.

분산 지능도 결국 분산 시스템이다

강력한 모델 호출 하나, 검색, 그리고 몇 가지 신중하게 설계된 도구로 충분했을 것이 에이전트 라우팅, 컨텍스트 핸드오프, 중재, 권한 설정, 확률적 컴포넌트 군집 전반의 관측 가능성으로 순식간에 불어날 수 있다. 문제가 진정으로 분산되어 있다면 그만한 가치가 있을 수 있다. 하지만 대부분은 그렇지 않다. 분산 지능도 분산 시스템이고, 분산 시스템은 구축과 유지보수 비용이 결코 싸지 않다.

오픈AI의 평가 가이드가 경고하듯, 멀티 에이전트 시스템에서 트리아지와 핸드오프는 새로운 비결정성의 원천이 된다. 오픈AI의 코덱스(Codex) 문서에 따르면 서브 에이전트는 자동으로 작동하지 않으며, 병렬 에이전트 작업을 명시적으로 요청할 때만 사용해야 한다. 각 서브 에이전트가 자체적으로 모델 및 도구 작업을 수행하기 때문에 단일 에이전트 실행보다 더 많은 토큰을 소비하기 때문이다. 마이크로소프트도 기업용 언어로 같은 지적을 한다. 모든 에이전트 상호작용에는 프로토콜 설계, 오류 처리, 상태 동기화, 별도의 프롬프트 엔지니어링, 모니터링, 디버깅, 더 넓은 보안 범위가 요구된다.

모듈성은 좋다. 하지만 모듈성이 공짜라는 착각은 금물이다.

대다수 팀이 멀티 에이전트가 필요하다고 생각할 때 실제로는 다른 문제를 안고 있다고 보는 이유가 여기에 있다. 도구가 모호하고, 검색이 허술하고, 권한이 지나치게 넓고, 저장소 문서화가 부실한 것이다. 에이전트를 더 추가해도 이런 문제는 해결되지 않는다. 오히려 악화된다. 앤트로픽이 설명하듯, 가장 성공적인 구현 사례는 복잡한 프레임워크보다 단순하고 조합 가능한 패턴을 활용하는 경향이 있다.

AI가 복잡성을 손쉽게 키운다는 점에서 이 문제는 더욱 중요하다. 마이크로서비스 시대에는 잘못된 아키텍처 아이디어도 구현에 필요한 노력이 자연스러운 제동 역할을 했다. 에이전트 시대에는 새로운 오케스트레이션 계층, 특화된 페르소나, 핸드오프, 글루 코드를 추가하는 비용이 빠르게 하락하고 있다. 당장은 자유로워진 것 같지만, 시스템을 장기적으로 유지하고 관리하는 능력을 갉아먹는다. 생산 비용 하락이 자동으로 생산성 향상으로 이어지지는 않는다. 오히려 규모 있는 취약성을 더 쉽게 양산하게 될 뿐이다.

추가 구성요소는 정당하게 얻어내야 한다

하이퍼스케일러 아키텍처에 대해 수년간 강조해온 지점으로 다시 돌아온다. 구글, 아마존, 앤트로픽, 오픈AI가 어떤 방식을 취한다고 해서 그대로 따라야 하는 것은 아니다. 같은 문제를 안고 있지 않기 때문이다. 앤트로픽의 리서치 시스템이 인상적인 이유는 어렵고 열린 결말의 광범위한 리서치 문제를 다루기 때문이다. 앤트로픽도 그 비용을 솔직하게 인정한다.

자체 데이터에 따르면 에이전트는 채팅 상호작용보다 약 4배 많은 토큰을 소비하고, 멀티 에이전트 시스템은 약 15배 더 많이 사용한다. 대다수 코딩 작업은 진정으로 병렬화 가능한 하위 작업이 적고 에이전트들이 실시간으로 서로 조율하는 능력이 아직 충분하지 않아 멀티 에이전트 시스템에 특별히 적합하지 않다는 점도 언급한다.

다시 말해, 멀티 에이전트 성공 사례로 손꼽히는 공개 사례에조차 경고 문구가 붙어 있다. “여기 들어오는 자, 모든 희망을 버려라”는 아니지만, “우리처럼 해라”는 더더욱 아니다.

더 나은 질문은 이것이다. “이 작업에 필요한 최소한의 자율성은 무엇인가?” 강력한 모델 호출부터 시작하라. 충분하지 않으면 검색을 추가하라. 그래도 부족하면 더 나은 도구를 추가하라. 반복이 필요하다면 그 도구들을 단일 에이전트 루프로 감싸라. 컨텍스트 오염이 실제로 발생하거나, 독립적인 작업을 진정으로 병렬로 실행할 수 있거나, 특화가 도구 선택을 실질적으로 개선하는 경우에만 두 번째 에이전트를 “정당하게 얻어내라”. 세 가지 문제 중 어느 것을 해결하고 싶은지 말할 수 없다면, 에이전트를 추가할 필요가 없을 가능성이 높다. 믿기 어렵다면, 앤트로픽, 오픈AI, 마이크로소프트, 구글 등 에이전트 도구 시장을 이끄는 기업들이 한목소리로 같은 결론을 내리고 있다는 사실을 떠올려라.

멀티 에이전트는 마이크로서비스의 새로운 판박이다. 칭찬이자 경고다. 마이크로서비스는 분산할 만한 문제가 있을 때 강력했다. 멀티 에이전트 시스템은 분해할 만한 문제가 있을 때 강력하다. 대다수 기업 팀은 적어도 아직은 그런 상황에 처해 있지 않다. 상당수는 앞으로도 그런 상황을 맞닥뜨리지 않을 것이다.

대신 대다수의 경우에 필요한 것은 잘 계측된 에이전트 하나, 엄격한 권한, 강력한 평가, 단순한 도구, 명확한 종료 조건이다. 에이전트 AI에서 성과를 내는 팀은 가장 화려한 구조를 먼저 택하는 팀이 아니다. 추가 구성 요소 하나하나를 정당하게 도입할 만큼 원칙을 지키고, 가능한 한 오랫동안 구조를 단순하게 유지하려 노력하는 팀이다. 기업 환경에서는 여전히 단순함이 확장성의 핵심이다.
dl-itworldkorea@foundryco.com