대부분의 AI 에이전트가 과하게 설계된 이유
AI 에이전트가 어디에나 있습니다.
에이전트 스웜(swarms), 자율 팀, 그리고 플래닝 에이전트를 볼 수 있습니다. 매주 새로운 프레임워크가 등장합니다. AI 워크플로우를 연구한 끝에, 저는 한 가지 결론에 도달했습니다.
대부분의 AI 에이전트는 과하게 설계되어 있습니다(overengineered).
에이전트가 쓸모없는 것은 아닙니다. 개발자들은 종종 단순한 워크플로우로 해결할 수 있는 문제를 에이전트로 해결하려 합니다.
업계는 복잡성을 좋아합니다
PDF를 읽고 질문에 답하는 시스템을 구축하고 싶다고 가정해 봅시다.
어떤 개발자들은 거대한 아키텍처를 만듭니다. 6개의 에이전트, 복잡한 상태 관리(state management), 그리고 메모리 동기화를 사용합니다. 이는 많은 골칫거리를 유발합니다.
종종 다음과 같은 단순한 시퀀스로 동일한 문제를 해결할 수 있습니다: • PDF • Chunk • Embed • Vector DB • LLM • Response
워크플로우만으로 충분합니다. 에이전트 군단은 필요하지 않습니다.
워크플로우가 대부분의 문제를 해결합니다
대부분의 AI 애플리케이션은 결정론적(deterministic)입니다. 정해진 시퀀스를 따릅니다.
예시는 다음과 같습니다: • Document Q&A • Customer support • Meeting summaries • Blog generation • Code review
이것들은 자율 시스템이 아니라 워크플로우입니다. 워크플로우는 디버깅, 확장, 유지보수가 더 쉽습니다. 복잡성은 그만한 가치가 있을 때만 도입해야 합니다.
에이전트는 숨겨진 비용을 발생시킵니다
에이전트가 추가될 때마다 다음과 같은 비용이 발생합니다: • 더 높은 토큰 비용 • 더 높은 지연 시간(latency) • 환각(hallucination) 발생 가능성 증가 • 더 어려운 디버깅 • 복잡한 인프라
단순한 애플리케이션이 순식간에 거대한 엔지니어링 프로젝트로 변해버립니다.
에이전트가 실제로 빛을 발하는 경우
저는 에이전트 반대론자가 아닙니다. 에이전트는 다음과 같은 경우에 잘 작동합니다: • 여러 웹사이트를 조사하는 것과 같이 작업 시간이 오래 걸리는 경우. • 논리에 기반한 의사결정이 필요한 경우. • Email, GitHub, Slack과 같이 여러 도구가 협업해야 하는 경우. • 인간의 개입이 루프의 일부인 경우(human-in-the-loop).
나의 원칙
개발자들은 종종 CrewAI나 LangGraph 같은 프레임워크로 즉시 뛰어듭니다. 그러기 전에 한 가지 질문을 던져보세요: "워크플로우로 해결할 수 있는가?"
만약 답이 "예"라면, 거기서부터 시작하세요. 복잡성이 요구될 때만 에이전트를 사용하세요. 유행(hype) 때문에 사용하지 마세요.
저는 이 원칙을 따릅니다:
- 워크플로우 우선.
- 에이전트 차선.
- 멀티 에이전트 마지막.
복잡성은 혁신이 아닙니다. 복잡성은 비용입니다. 사용자는 당신이 얼마나 많은 에이전트를 사용하는지 신경 쓰지 않습니다. 그들은 당신의 도구가 제대로 작동하는지에 관심이 있습니다.
단순함이 최고의 기능입니다.
Source: https://dev.to/jaideepparashar/why-i-think-most-ai-agents-are-overengineered-249o
Optional learning community: https://t.me/GyaanSetuAi