멀티 에이전트 시스템은 실무에서 완전한 악몽이다
Multi agent systems are a total nightmare in production
핵심 요약
복잡한 멀티 에이전트 시스템보다 잘 작성된 단순한 프롬프트 하나가 실무에서는 훨씬 강력하고 효율적이다.
- 멀티 에이전트 환상 — 인플루언서들이 홍보하는 복잡한 에이전트 스웜은 실무에서 오류와 할루시네이션만 유발함.
- 단순함의 미학 — 복잡한 체인보다 잘 작성된 단일 프롬프트가 비용과 성능 면에서 훨씬 뛰어남.
- 컨텍스트 손실 문제 — 에이전트 간 정보 전달 과정에서 발생하는 정보 왜곡이 시스템 신뢰도를 떨어뜨림.
- 실무 중심 스택 — 복잡한 프레임워크 대신 n8n이나 파이썬 스크립트, Supabase를 활용한 단순한 구조가 수익 창출에 유리함.
링크드인 인플루언서나 유튜브 구루들이 12개 에이전트 스웜을 자랑하는 걸 보는 게 지긋지긋합니다. 솔직히 저도 한때는 그런 사람 중 하나였죠. 리서처 에이전트가 라이터 에이전트와 대화하게 만들려고 새벽 2시까지 깨어 있으면서, 결국 전체가 할루시네이션 파티로 변하는 걸 지켜보곤 했습니다.
데모 영상에서는 멋져 보이죠. 마치 JARVIS를 만드는 기분이 듭니다. 하지만 현실 세계에서는요? 엉망진창입니다.
최근 고객들을 위해 이런 시스템을 20개 넘게 배포해 봤습니다. 실제로 계속 잘 돌아가고, 저녁 식사 시간에 에러 로그 때문에 휴대폰이 울리지 않게 만드는 것들은 놀라울 정도로 단순한 것들이었습니다.
대부분의 사람들은 단순한 건 기술 같지 않다고 생각해서 과도하게 엔지니어링을 하고 있습니다.
하지만 지금 저에게 실제로 수익을 가져다주는 것들의 현실은 이렇습니다.
. 지저분한 이메일을 정리하는 단일 프롬프트. 관리자 에이전트 따위 필요 없습니다.
. PDF에서 데이터를 추출해 데이터베이스에 넣는 기본적인 스크립트.
. 똑똑한 척하지 않는 FAQ 봇을 위한 탄탄한 프롬프트 하나.
복잡한 체인의 문제는 에이전트가 서로 대화할 때마다 컨텍스트를 잃어버린다는 점입니다. 어릴 때 하던 '전화 놀이' 게임과 같죠. 네 번째 에이전트가 정보를 받을 때쯤이면, 이미 내용을 지어내고 있는 수준입니다.
게다가 API 비용도 미쳤습니다. 잘 작성된 프롬프트 하나면 3초 만에 끝낼 작업을 5개의 에이전트가 고민하게 만들면서 돈을 쓰고 있는 거죠.
요즘 제 스택은 꽤 지루합니다. n8n을 쓰거나 그냥 간단한 파이썬 스크립트를 사용하죠. 예시를 잔뜩 넣은 길고 상세한 프롬프트를 하나 작성합니다. 무언가를 저장해야 하면 Supabase에 던져 넣고요.
그게 다입니다. 화려한 프레임워크도, 자율적인 루프도 없습니다.
LLM이 컨디션이 안 좋을 때마다 고장 나는 화려한 시스템보다, 100% 확률로 작동하는 멍청한 도구가 훨씬 더 가치 있다는 걸 깨달았습니다.
디지털 부서를 만들려고 하지 마세요. 그냥 한 가지 일을 확실히 하고 고장 나지 않는 도구를 만드세요.
혹시 저처럼 한 달 동안 스웜을 만들다가 결국 단일 프롬프트가 더 낫다는 걸 깨달은 분 계신가요? 아니면 제가 그냥 늙고 냉소적으로 변한 걸까요?
