대부분의 AI 에이전트가 과잉 설계되었다고 생각하는 이유

AI 에이전트(AI agents)가 어디에나 있습니다.

멀티 에이전트 시스템 (Multi-agent systems).

에이전트 스웜 (Agent swarms).

자율 팀 (Autonomous teams).

플래닝 에이전트 (Planning agents).

자기 개선 에이전트 (Self-improving agents).

매주 차세대 자율 AI 시스템을 구축할 수 있을 것처럼 유망해 보이는 새로운 프레임워크가 등장하는 것 같습니다.

AI 워크플로우 (AI workflows)를 연구하고 실험하며 상당한 시간을 보낸 후, 저는 단순한 결론에 도달했습니다:

대부분의 AI 에이전트는 과잉 설계(overengineered)되었다고 생각합니다.

이것이 에이전트가 쓸모없다는 뜻은 아닙니다.

전혀 아닙니다.

저는 단지 많은 개발자가 훨씬 더 간단한 것으로 해결할 수 있는 문제를 에이전트로 해결하려 한다고 믿을 뿐입니다.

업계는 복잡성을 좋아합니다

다음과 같은 시스템을 구축하고 싶다고 가정해 봅시다:

1. PDF 읽기.
2. 정보 추출.
3. 임베딩 (embeddings) 저장.
4. 질문에 답변.

저는 개발자들이 다음과 같은 아키텍처를 만드는 것을 보았습니다:

리서치 에이전트 (Research Agent)
↓
플래너 에이전트 (Planner Agent)
↓
리트리버 에이전트 (Retriever Agent)
↓
메모리 에이전트 (Memory Agent)
↓
답변 에이전트 (Answer Agent)
↓
리뷰어 에이전트 (Reviewer Agent)

6개의 에이전트.

여러 개의 프롬프트 (prompts).

복잡한 상태 관리 (state management).

재시도 (Retries).

메모리 동기화 (Memory synchronization).

그리고 수많은 골칫거리.

반면, 동일한 문제는 종종 다음과 같이 해결될 수 있습니다:

PDF → 청크 (Chunk) → 임베딩 (Embed) → 벡터 DB (Vector DB) → LLM → 응답 (Response)

때로는 워크플로우 (workflow)만으로 충분합니다.

모든 것에 에이전트 군단이 필요한 것은 아닙니다.

워크플로우가 대부분의 문제를 해결합니다

제 경험상, 대부분의 AI 애플리케이션은 결정론적 (deterministic)입니다.

그것들은 다음과 같은 순서를 따릅니다:

입력 (Input)
↓
변환 (Transform)
↓
검색 (Retrieve)
↓
생성 (Generate)
↓
출력 (Output)

예시로는 다음과 같은 것들이 있습니다:

• 문서 Q&A
• 고객 지원
• 회의 요약
• 블로그 생성
• 코드 리뷰
• 지식 어시스턴트

이것들은 워크플로우입니다.

자율 시스템이 아닙니다.

그리고 워크플로우는 다음과 같은 장점이 있습니다:

• 디버깅 (debug)이 더 쉬움
• 확장 (scale)이 더 쉬움
• 유지보수 (maintain)가 더 쉬움
• 설명하기가 더 쉬움

복잡성은 가정하는 것이 아니라, 정당성을 얻어야 하는 것입니다.

에이전트는 숨겨진 비용을 초래합니다

에이전트가 하나씩 추가될 때마다 다음과 같은 결과가 따릅니다:

더 많은 프롬프트

이는 더 많은 토큰 (tokens)을 의미합니다.

더 높은 지연 시간 (latency)

각 단계가 실행 시간을 추가합니다.

더 많은 환각 (hallucination) 기회

하나의 잘못된 출력이 하류(downstream)로 전파됩니다.

더 많은 디버깅 고통

실패 원인을 찾는 것이 어려워집니다.

더 많은 인프라 복잡성 (infrastructure complexity)

메모리 (Memory), 오케스트레이션 (orchestration), 재시도 (retries), 그리고 모니터링 (monitoring)이 필수적이 됩니다.

단순한 애플리케이션으로 시작했던 것이 갑자기 거대한 엔지니어링 프로젝트가 되어버립니다.

대부분의 빌더는 멀티 에이전트 시스템 (Multi-Agent Systems)이 필요하지 않습니다

비교해 봅시다.

단순 워크플로우 (Simple Workflow)
문서 (documents) → 임베딩 (embeddings) → Chroma → GPT → 답변 (answer)

단순합니다.

신뢰할 수 있습니다.

빠릅니다.

이제 이것과 비교해 보세요:

플래너 에이전트 (Planner Agent)
↓
리트리버 에이전트 (Retriever Agent)
↓
리서치 에이전트 (Research Agent)
↓
크리틱 에이전트 (Critic Agent)
↓
메모리 에이전트 (Memory Agent)
↓
최종 라이터 에이전트 (Final Writer Agent)

PDF에서 질문에 답하기 위해 정말로 6개의 에이전트가 필요할까요?

아마 아닐 것입니다.

에이전트가 실제로 빛을 발하는 지점

저는 에이전트 반대론자가 아닙니다.

저는 다음과 같은 상황에서 에이전트가 강력하다고 생각합니다:

장기 실행 작업 (Long-running tasks)이 존재하는 경우

예를 들어:

• 여러 웹사이트에 걸친 조사 (Researching)
• API 모니터링
• 작업 스케줄링
• 자율 코딩 루프 (Autonomous coding loops)

의사 결정 (Decision-making)이 필요한 경우

예를 들어:

if bug_found:
    fix_code()
elif tests_fail:
...

인간의 개입 (Human intervention)이 중요한 경우

Human-in-the-loop 시스템은 에이전트 아키텍처로부터 큰 이점을 얻습니다.

여러 도구의 협업이 필요한 경우

이메일 (Email).

GitHub.

Slack.

데이터베이스 (Databases).

웹 검색 (Web search).

이 지점이 바로 에이전트가 흥미로워지는 부분입니다.

저는 에이전트보다 워크플로우가 더 중요하다고 믿습니다

제가 배운 한 가지는 빌더들이 종종 에이전트 프레임워크 (agent frameworks)로 곧장 뛰어든다는 점입니다.

CrewAI.

LangGraph.

AutoGen.

그리고 그 외에도 아주 많습니다.

하지만 에이전트를 구축하기 전에, 우리는 먼저 다음과 같이 질문해야 한다고 생각합니다:

워크플로우로 이 문제를 해결할 수 있는가?

만약 답이 '예'라면, 거기서부터 시작하세요.

복잡성이 에이전트를 요구할 때만 에이전트를 도입하세요.

Twitter에서 에이전트가 미래라고 말하기 때문이 아니라 말입니다.

사실, 저는 최근에 제가 가장 좋아하는 리포지토리(repositories) 몇 개를 다음과 같이 공유했습니다:

["7 GitHub Repositories I Recommend to Every AI Builder">(https://dev.to/jaideepparashar/7-github-repositories-i-recommend-to-every-ai-builder-4hl4)]

그 도구 중 일부는 믿을 수 없을 정도로 강력하지만, 강력함이 항상 더 많은 복잡성을 의미하지는 않습니다.

때로는 가장 단순한 아키텍처가 최선의 아키텍처입니다.

소프트웨어 산업은 이미 이런 일을 경험한 적이 있습니다

마이크로서비스 (Microservices).

Kubernetes.

분산 시스템 (Distributed systems).

이벤트 기반 아키텍처 (Event-driven architectures).

많은 팀이 진정으로 필요하기 전에 이것들을 채택했습니다.

AI가 동일한 패턴을 반복하고 있을지도 모릅니다.

개발자들은 인상적인 데모를 보고 모든 프로젝트에 다음과 같은 요소가 필요하다고 가정합니다:

• 에이전트 메모리 (Agent memory)
• 멀티 에이전트 오케스트레이션 (Multi-agent orchestration)
• 계획 루프 (Planning loops)
• 성찰 에이전트 (Reflection agents)

하지만 복잡함은 혁신이 아닙니다.

복잡함은 비용입니다.

나의 원칙

나는 단순한 원칙을 따릅니다:

• 워크플로 (Workflow) 우선.
• 에이전트 (Agent) 차선.
• 멀티 에이전트 (Multi-agent) 마지막.

가능한 가장 단순한 아키텍처로 시작하세요.

하이프 (Hype)가 요구해서가 아니라, 현실이 요구할 때만 복잡성을 추가하세요.

마치며

AI 에이전트는 흥미롭습니다.

LangGraph나 CrewAI와 같은 프레임워크는 생태계를 앞으로 밀어붙이고 있습니다.

그리고 나는 자율 시스템 (Autonomous systems)이 미래에 중요한 역할을 할 것이라고 믿습니다.

하지만 오늘날, 나는 많은 AI 개발자가 솔루션을 과잉 설계 (Overengineering)하고 있다고 생각합니다.

대부분의 문제는 에이전트 팀을 필요로 하지 않습니다.

대부분의 문제는 명확한 워크플로를 필요로 합니다.

결국, 사용자는 당신의 애플리케이션에 12개의 에이전트가 있는지 여부에는 관심이 없기 때문입니다.

그들은 그것이 제대로 작동하는지에 관심이 있습니다.

그리고 엔지니어링에서 단순함은 종종 가장 과소평가되는 기능입니다.