📌 LLM 어플리케이션 3편: Agent Teams — 더 많은 에이전트가 더 빠른 게 아니다

BQ개발자입니다

지난 편에서 MCP를 많이 등록할수록 context를 소비해 Claude의 성능이 떨어지는 역설을 다뤘습니다.

이번에는 Agent Teams를 살펴봅니다. "AI가 여러 명이면 당연히 빠를 것"이라는 기대와 달리, 왜 때로는 더 느려지는지 이유를 짚어보겠습니다.

🤔 Agent Teams를 켰는데 왜 더 느려졌을까?

단일 에이전트가 복잡한 작업을 순차 처리하면 코드 리뷰,
보안 감사 등 모든 과정이 하나의 context에 쌓입니다.
결과적으로 정보가 너무 많아져 1편에서 언급한 'attention 희석'이 발생하죠.

이를 해결하기 위해 에이전트를 나누는 Agent Teams를 도입하지만, 구조를 이해하지 못하면 오히려 성능이 저하됩니다.

⚡ Agent Teams의 실제 메커니즘

Agent Teams의 핵심은 단순 협업이 아니라 context window를 분할하는 것입니다.

팀원이 3명이면 각자 독립된 context를 갖습니다. 코드 리뷰 에이전트는 리뷰 데이터만,
문서 작성 에이전트는 깨끗한 context에서 시작하는 식이죠. 이 구조가 효율적으로 작동하려면 반드시 지켜야 할 순서가 있습니다.

🧠 순서를 틀리면 생기는 함정

역할 분리(Specialized Agents) 없이 병렬화만 하면 문제가 생깁니다.
역할이 모호하면 에이전트들이 같은 작업을 중복 수행하게 되고, 오케스트레이터는 이를 조율하는 메시지로 메인 context를 빠르게 소진합니다.
작업 효율은 낮은데 관리 비용만 치솟는 '이중 오버헤드' 상태가 되는 거죠.

따라서 Specialized Agents 설계가 우선되어야 합니다. 누가 어떤 역할을 맡고, 어떤 파일을 다룰지 경계가 명확해야 병렬화의 이득을 볼 수 있습니다.

🎯 3~4명 권고가 자의적 숫자가 아닌 이유

Claude Code 공식 문서에서 권장하는 팀 규모 3~4명은 '비용과 조율의 균형점'입니다.

팀원이 늘면 context 비용도 배로 늘고, 오케스트레이터의 조율 부담도 커집니다.
4명을 초과하면 병렬화로 얻는 이득보다 조율 오버헤드가 더 커지기 시작한다고 보는 것이 합리적입니다.

💡 팁: Agent Teams를 켜기 전, 에이전트별 역할부터 명확히 나누세요.
역할 경계가 분명해야 병렬화가 실제 속도로 이어집니다.

에이전트 역할을 잘 나눴다면, 이제 각 에이전트가 도구를 얼마나 잘 쓰는지도 중요합니다. 다음 편에서는 제가 자주 사용하는 플러그인들에 대해서 좀 다뤄볼게요!!

---

여러분의 좋아요와 공유는 사랑입니다 🥰