여러 개의 에이전트 : 토큰 장사를 위한 걸수도 있다.
Agent의 숫자는 지능의 숫자가 아니다. | 요즘 AI 업계를 보면 이상할 정도로 “멀티에이전트”라는 말을 많이 쓴다. 기획 Agent가 있고, 분석 Agent가 있고, 개발 Agent가 있고, 검수 Agent가 있고, 또 그 Agent들을 관리하는 Manager Agent가 있다. 화면만 보면 마치 AI 직원 여러 명이 한 조직에서 협업하는 것처럼 보인다. 그런데 나는 이 구조의 상당 부분이
요즘 AI 업계를 보면 이상할 정도로 “멀티에이전트”라는 말을 많이 쓴다.
기획 Agent가 있고, 분석 Agent가 있고, 개발 Agent가 있고, 검수 Agent가 있고, 또 그 Agent들을 관리하는 Manager Agent가 있다.
화면만 보면 마치 AI 직원 여러 명이 한 조직에서 협업하는 것처럼 보인다.
그런데 나는 이 구조의 상당 부분이 기술 혁신이라기보다 AI 회사들의 장사 방식에 가깝다고 본다.
물론 멀티에이전트 자체가 쓸모없다는 이야기는 아니다.
서로 다른 권한을 가진 시스템이 필요하거나, 독립적인 탐색을 병렬로 수행해야 하거나, 한 모델의 결과를 다른 모델이 교차검증해야 하는 문제라면 여러 Agent를 두는 것이 합리적일 수 있다.
문제는 굳이 나눌 필요가 없는 일까지 전부 Agent로 쪼개는 경우다.
예를 들어 하나의 강한 모델이 충분한 컨텍스트를 가지고 자료를 읽고, 판단하고, 도구를 사용하고, 결과를 검증하면 끝나는 업무가 있다고 해보자.
그런데 이것을
기획 Agent 조사 Agent 분석 Agent 작성 Agent 검수 Agent
처럼 다섯 단계로 나눈다.
각 Agent가 완전히 다른 지능인 것도 아니다.
같은 LLM에 프롬프트 몇 줄을 다르게 넣고, 앞 Agent가 만든 결과물을 다음 Agent가 다시 읽는 구조인 경우도 많다.
그런데 사용자에게는 이것이 “다섯 명의 AI 전문가가 협업하는 시스템”처럼 표현된다.
나는 여기서 질문해야 한다고 생각한다.
왜 Agent를 여러 개로 나눴는가?
단일 Agent보다 정확도가 실제로 얼마나 올라갔는가?
실패율은 얼마나 낮아졌는가?
작업 시간은 줄었는가?
토큰 사용량과 API 비용까지 포함했을 때 경제성은 좋아졌는가?
긴 체인에서 앞 단계의 오류가 뒤 단계로 전파되는 문제는 어떻게 해결했는가?
그리고 무엇보다,
같은 문제를 하나의 잘 설계된 Agent로 풀었을 때보다 정말 더 좋은가?
이 질문에 수치로 답하지 못한다면 Agent의 개수는 기술력이 아니다.
오히려 시스템의 복잡성을 늘리고, 호출 횟수를 늘리고, 비용을 늘리고, 디버깅할 지점을 늘렸을 가능성도 있다.
AI 업계에서 자주 일어나는 착각이 있다.
복잡한 아키텍처가 더 지능적인 아키텍처라는 착각이다.
하지만 소프트웨어는 원래 반대다.
같은 문제를 더 적은 구성요소로, 더 낮은 비용으로, 더 안정적으로 해결할 수 있다면 그쪽이 더 좋은 시스템이다.
AI도 마찬가지다.
Agent가 10개 있다고 해서 지능이 10배가 되는 것이 아니다.
Agent 10개가 서로 같은 말을 전달하고 있다면 그것은 AI 조직이 아니라 긴 API 호출 체인일 뿐이다.
그래서 나는 앞으로 AI 제품을 볼 때 “Agent가 몇 개인가”보다 다른 것을 봐야 한다고 생각한다.
이 시스템이 실제 고객의 문제를 얼마나 적은 비용으로 정확하게 해결하는가.
결국 중요한 것은 그것뿐이다.
Agent가 하나든 열 개든 고객은 관심 없다.
고객이 원하는 것은 자신의 문제가 해결되는 것이다.
그런데 기술회사가 문제 해결 능력 대신 Agent의 숫자와 복잡한 조직도를 팔기 시작한다면, 그 순간 기술은 상품이 아니라 연출이 된다.
그래서 나는 요즘 유행하는 멀티에이전트 구조의 상당 부분을 보면서 이런 생각을 한다.
여러 개의 AI가 일하고 있는 것이 아니라, 하나의 AI를 여러 명처럼 보이게 만들어 팔고 있는 것은 아닌가.
멀티에이전트가 기술이 되려면 먼저 증명해야 한다.
더 정확한가.
더 빠른가.
더 싼가.
더 안정적인가.
그렇지 않다면 Agent의 숫자는 혁신의 숫자가 아니다.
그저 청구서에 찍히는 API 호출 횟수일 수도 있다.
실제로 많이 돌려봐서 하는 말이다.
실제로 매출을 내고 있어서 하는 말이다.
실제로 고객의 문제해결을 하고 있어서 하는 말이다.
실제로 고정비 월 40만원에 고객사 6개를 동시에 돌리고 있어서 하는 말이다.
요즘 멀티에이전트 열풍의 상당 부분이 기술적 필요보다 마케팅적 복잡성에 가깝다고 본다.
같은 모델을 여러 역할로 쪼개고, API 호출과 토큰을 더 사용한 뒤 성능이 좋아졌다고 말한다면 먼저 계산량을 동일하게 맞춰 비교해야 한다.
놀랍게도 최근 연구에서는 그렇게 비교했을 때 단일 에이전트가 멀티에이전트를 따라잡거나 오히려 이기는 결과가 나오고 있다.
Agent의 숫자는 지능의 숫자가 아니다.
내가 개발이 빠른 이유는 코드를 빨리 쳐서가 아니다.
필요 없는 구조를 처음부터 안 만들기 때문이다.
Agent 10개가 필요한지,
복잡한 파이프라인이 필요한지,
기능을 정말 따로 쪼개야 하는지 먼저 본다.
대부분은 생각보다 훨씬 단순하게 풀린다.
결국 개발 속도는
얼마나 빨리 만드는가보다,
무엇을 만들지 않을지 얼마나 빨리 판단하는가에서 갈린다.