📌 LLM 어플리케이션 10편: 멀티 에이전트 - AI들의 협업

BQ개발자입니다.

지난 편에서 에이전트가 스스로 생각하고 행동하는 방법을 배웠습니다.
그런데 실무에서는 더 복잡한 상황에 직면합니다.

📱LLM 어플리케이션 9편: 에이전트 - 생각하는 AI의 탄생


🤔 컨텍스트 희석 문제

"우리 회사 고객 중 최근 3개월간 구매가 줄어든 VIP 고객들에게 맞춤형 마케팅 전략을 수립해줘"

이 요청을 처리하려면 CRM 데이터 조회, 구매 패턴 분석, 마케팅 전략 수립, 개인화 메시지 작성이 모두 필요합니다.

단일 에이전트에게 이 모든 것을 시키면 프롬프트가 이렇게 됩니다:
"너는 CRM 전문가이면서 데이터 분석가이고 마케팅 전략가이며 카피라이터다. CRM 도구는 이렇게 쓰고, 분석은 이렇게 하고, 마케팅은..."

프롬프트가 길어질수록 각 역할의 지시사항이 희석됩니다.
LLM은 모든 역할을 동시에 수행하려다 어느 것도 제대로 못하게 되는거죠.


🤝 컨텍스트 분리를 통한 전문화

멀티 에이전트는 이 문제를 컨텍스트 분리로 해결하려는 방법론입니다.

CRM 전담 에이전트
- 프롬프트: "너는 Salesforce CRM 전문가다. API를 통해 고객 데이터를 조회하고..."
- 오직 CRM 관련 지시사항만 포함

분석 전담 에이전트
- 프롬프트: "너는 고객 행동 분석 전문가다. 구매 패턴을 분석하고..."
- 오직 분석 관련 지시사항만 포함

각 에이전트가 자신의 역할에만 집중하니 훨씬 정확한 결과가 나오는 것을 유도하는거죠.


📊 커맨더 패턴의 작동

중앙 조율 에이전트가 작업을 분배하는 구조를 살펴보겠습니다.

사용자 요청이 들어오면 커맨더 에이전트가 먼저 작업을 분해합니다.
"VIP 고객 데이터가 필요하다" → CRM 에이전트에게 전달
"구매 패턴 분석이 필요하다" → 분석 에이전트에게 전달

CRM 에이전트가 데이터를 추출하면, 그 결과를 분석 에이전트가 받아서 처리합니다.
분석 결과를 바탕으로 마케팅 에이전트가 전략을 수립하게 되구요.

커맨더는 이 모든 과정을 조율하고 최종 결과를 통합합니다.
작업의 순서와 의존성을 관리하는 것이 커맨더의 핵심 역할입니다.


📡 브로드캐스트 패턴의 병렬성

때로는 순차 처리보다 동시 처리가 효율적일때도 있습니다.

"신제품 출시 준비 상황을 점검해줘"

이 요청은 여러 부서의 독립적인 확인이 필요합니다.
모든 에이전트가 동시에 요청을 받고 각자의 영역을 점검합니다.

시장조사 에이전트는 타겟 시장을 분석하고,
가격 에이전트는 가격 전략을 검토하며,
운영 에이전트는 재고와 물류를 확인합니다.

각 에이전트의 답변이 모이면 통합 에이전트가 전체 그림을 그립니다.
순차적으로 처리했다면 30분 걸릴 작업이 5분 만에 완료됩니다.


💬 컨버세이셔널 패턴의 집단 지성

에이전트들이 서로 대화하면서 답을 찾아가는 과정도 있습니다.

코드 리뷰 상황을 생각해보죠.

코드분석 에이전트가 "23번 줄에 null 참조 가능성"을 지적합니다.
보안 에이전트가 "45번 줄의 SQL 인젝션이 더 심각한 문제"라고 반박합니다.
성능 에이전트가 "67번 줄의 루프 구조도 확인 필요"라고 추가합니다.

이때 코드분석 에이전트가 67번 줄을 재검토하고 "종료 조건이 있으니 문제없다"고 정정합니다.
최종 결정 에이전트가 우선순위를 정해 "SQL 인젝션부터 수정"이라고 결론 내립니다.

서로 다른 관점이 충돌하고 조정되면서 더 정확한 답에 도달하는 것이죠.


🎯 프롬프트 충돌이 사라진 이유

단일 에이전트에서 "너는 보안 전문가이면서 성능 전문가"라고 하면,
보안을 위해 검증을 강화하라는 지시와 성능을 위해 검증을 줄이라는 지시가 충돌합니다.

멀티 에이전트에서는 보안 에이전트가 "모든 입력을 검증하라"고 하고,
성능 에이전트가 "캐싱으로 속도를 높여라"고 각자 제안합니다.
조율 에이전트가 "중요 데이터만 검증하고 나머지는 캐싱"이라는 균형점을 찾습니다.

역할이 분리되니 지시사항도 명확해지고, 충돌도 명시적으로 해결됩니다.


🔄 실제 성능 차이

동일한 작업을 수행했을 때의 차이를 보겠습니다.

"우리 회사 내년 사업 계획 수립" 요청에 대해:

단일 에이전트
- 프롬프트 길이: 5,000 토큰 (모든 지시사항 포함)
- 처리 시간: 45초
- 결과: 일반적이고 추상적인 계획

멀티 에이전트
- 각 프롬프트: 500-800 토큰 (역할별 특화)
- 병렬 처리 시간: 15초
- 결과: 부서별 구체적 실행 계획 포함

프롬프트가 짧아지니 각 에이전트가 자신의 역할을 더 잘 이해할 수 있겠죠?.
병렬 처리로 시간도 단축되고, 결과물의 구체성도 높아집니다.


💡 컨텍스트 분리가 만드는 전문성

멀티 에이전트의 본질은 "여러 AI를 쓰는 것"이 아니라고 생각합니다

각 에이전트의 컨텍스트를 분리해서,
하나의 역할에 완전히 집중하게 만드는 거죠.

이렇게 하면 프롬프트 충돌이 사라지고,
각 전문 영역에서 최고의 성능을 발휘한다고해요

결과적으로 전체 시스템의 정확도와 효율성이 모두 향상되구요

인간 조직도 전문가들이 협업할 때 최고의 성과를 내는 것처럼,
AI도 전문화와 협업을 통해 한 단계 높은 지능을 구현하고 있다고 하는데요

그런데 이런 복잡한 협업 과정을 어떻게 체계적으로 관리할 수 있을까요?
다음 편에서는 "오케스트레이션 - 복잡한 워크플로우 관리"를 알아보겠습니다.

---

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

#BQ개발자 #LLM애플리케이션 #멀티에이전트 #AIEngineering

📌 Claude Code가 조용히 느려지는 이유 2편: MCP를 많이 설치할수록 Claude가 할 수 있는 일이 줄어든다

BQ개발자입니다.

지난 편에서 context window가 70%를 넘으면 결과물이 나빠지기 시작한다는 점을 다뤘습니다.
이번에는 작업을 시작하기도 전에 이미 context가 채워져 버리는 원인, MCP에 대해 이야기해보려 합니다.

📱 Claude Code가 조용히 말을 안 듣기 시작할 때 — context 70%의 의미



🤔 도구가 많을수록 똑똑해질까?

파일 시스템, 웹 검색, DB 연결 등 MCP 서버를 많이 등록할수록 Claude의 능력이 확장된다고 생각하기 쉽습니다.
하지만 실제로는 MCP가 늘어날수록 Claude가 오히려 부정확해지는 현상이 발생합니다.


⚡ 도구 정의가 context를 점유하는 '고정 비용'

이유는 Claude Code의 작동 방식에 있습니다.

1. 초기 로딩: Claude Code가 실행되면 등록된 모든 MCP 서버의 '도구 정의(이름, 설명, 파라미터 등)'를 가져와 context에 올립니다.
2. 상시 점유: 도구를 실제로 사용하지 않아도 등록되어 있다는 이유만으로 context를 차지합니다.
3. 비용 누적: MCP 10개를 등록해 도구가 30~50개가 되면, 아무 작업도 안 했는데 이미 context의 30% 정도가 소모됩니다.

결국 지난 편에서 말한 '성능 저하 지점(70%)'까지 남은 여유 공간이 시작부터 줄어드는 구조입니다.


🎯 선택 기준: "무엇을 하는가"보다 "얼마나 가벼운가"

이제 MCP를 고를 때는 기능뿐만 아니라 context 효율성을 따져야 합니다.

예를 들어 exa.ai가 고평가받는 이유는 응답 데이터의 양 때문입니다. 일반 크롤러는 불필요한 HTML 태그까지 다 가져와 context를 낭비하지만, exa.ai는 AI가 읽기 좋은 핵심 텍스트만 추출해서 돌려줍니다. 도구 정의 비용은 같아도, 실행 시 발생하는 데이터 비용이 훨씬 적은 것이죠.


🚀 실전 MCP 관리 팁

1. 현재 작업과 무관한 MCP는 꺼두기
• 코딩 중이라면 부동산이나 날씨 MCP는 비활성화하는 게 좋습니다. 켜져 있는 것만으로도 비용입니다.

2. 응답이 간결한 도구를 선택하기
• 같은 기능을 제공한다면 응답 데이터가 더 정제되어 돌아오는 MCP가 장기 세션에 유리합니다.

MCP는 강력한 확장이지만, 결국 '유한한 context'를 나눠 쓰는 자원입니다. "항상 켜져 있는 비용"이라는 관점에서 관리해 보시는거 추천!!

다음 편에서는 "Agent Teams를 켰는데 왜 더 느려졌을까"에 대해 다뤄보겠습니다.

---

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

#BQ개발자 #LLM애플리케이션 #MCP #AIEngineering

📌 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를 켜기 전, 에이전트별 역할부터 명확히 나누세요.
역할 경계가 분명해야 병렬화가 실제 속도로 이어집니다.

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

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

#BQ개발자 #LLM애플리케이션 #AgentTeams #AIEngineering

📌 Claude Code 1편: Claude Code에 앱 스토어가 생겼다

BQ개발자입니다.

같은 Claude Code를 쓰는데 어떤 팀은 코드를 바로 짜고,
어떤 팀은 "엣지 케이스는 어떻게 할까요?"라고 먼저 묻게 되는데요,
이런 방식의 차이는 보통 모델 차이가 아니라 Plugins 때문입니다.

🤔 "플러그인 = 기능 추가"라는 착각

예를 들어서 Clarify 스킬을 설치하면 Claude가 코드 짜기 전에 요구사항을 먼저 묻기 시작합니다.
단순히 꼼꼼해진 게 아니라, Claude의 동작 방식 자체가 바뀐 거거든요.

⚡ SKILL.md: 판단 기준의 주입

이런게 왜그런지를 설명해보면, 플러그인을 설치했을때 컨텍스트에 SKILL.md 파일이 추가되기 때문입니다.
여기에는 "코딩 전 요구사항을 먼저 확인해라" 같은 방법론이 적혀 있고, Claude는 이걸 읽고 이후 모든 요청에 알아서 적용합니다.
기본 상태에선 수단까지 지정해줘야 하는 도구인데, SKILL.md가 들어오면 목표만 줘도 수단을 스스로 선택하는 에이전트가 됩니다.

🎯 /plugins로 시작하는 에이전틱 코딩
Claude Code에서 /plugins를 입력하면 팀어텐션(TeamAttention)이 구축한 생태계에 연결됩니다.
여기서는 팀만의 SKILL.md를 직접 정의할 수 있어서, 설계 검토 기준이나 PR 체크리스트 같은 팀 컨벤션을 Claude의 판단 기준으로 만들 수 있구요

💡 팀이 Claude에게 매번 반복하는 규칙이 있다면, 그게 SKILL.md 후보입니다.

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

#BQ개발자 #ClaudeCode #LLM애플리케이션 #AgenticCoding #AIEngineering

📌 LLM 어플리케이션 2편: 세션이 끝나도 Claude는 기억한다 — 단, 당신이 설계할때만

BQ개발자입니다.

지난 편에서 Skills와 Plugins가 Claude의 "기능"을 추가하는 게 아니라 Claude의 "판단 기준"을 바꾼다고 했는데요,
오늘은 그 판단이 세션이 끝나면 어떻게 되는가라는 질문을 다뤄보겠습니다.

"세션이 끝나면 Claude는 다 잊는 건데, 그걸 어떻게 기억하게 해?"

🤔 환각의 원인에 대한 오해

Claude가 틀린 답을 낼 때, 가장 흔한 설명은 이겁니다.

"LLM이 원래 그래요. 모델 한계예요."

근데 실제로 해보면 패턴이 있습니다. 세션 초반엔 정확한데, 세션이 길어질수록 틀리는 빈도가 늘어나거든요.
이미 결정한 설계를 재발명하거나, 없는 파일 경로를 있는 것처럼 응답하는 일이 생깁니다.

저는 이게 모델이 멍청해서가 아니라고 생각합니다.

Claude Code의 컨텍스트 윈도우가 일정 한도에 도달하면 자동 압축(compaction)이 트리거됩니다.
이 압축이 세션 초기의 정밀한 정보들 — 특정 변수명, 에러 메시지 원문, 설계 결정의 이유 — 을 요약으로 뭉개버리거든요.


⚡ 환각은 의존 구조의 문제다

Claude가 정보를 가져오는 경로는 두 가지입니다.

하나는 컨텍스트에 올라온 텍스트를 읽는 것이고, 다른 하나는 모델 내부의 추론으로 "그럴 것 같은" 것을 생성하는 거예요.

컨텍스트에 정확한 정보가 있으면 Claude는 그걸 읽습니다. 없으면 추론에 의존하고요. 압축이 바로 컨텍스트에서 정확한 정보를 지워버리는 과정이에요. 압축 이후 Claude가 초기 설계 결정을 재발명하는 건, "기억이 나빠서"가 아니라 정확한 정보 소스가 컨텍스트에서 사라졌기 때문에 추론이 그 자리를 채우는 상황인 것 같아요.

그러면 해결책이 보이죠. 모델을 교체하거나 파인튜닝하는 게 아니라, 다음 세션이 시작될 때 정확한 정보를 컨텍스트에 올려놓으면 됩니다. 이게 Session Wrap의 설계 원리예요.


🎯 Session Wrap이 하는 일

제가 개인적으로 많이 활용하는 스킬인데요,
/wrap 명령을 실행하면 멀티에이전트 파이프라인이 돌아갑니다.

Sonnet 모델 4개가 병렬로 세션에서 추출해야 할 것들을 각자 담당해요
문서 업데이트 내용, 자동화 가능한 반복 패턴, 오늘의 발견과 실수,
다음 세션 우선순위. 이 결과가 CLAUDE.md와 context.md 외부 파일에 저장됩니다.

다음 세션이 시작되면 Claude는 그 파일을 읽어요.
이전 세션의 결정 사항들이 "정확한 텍스트"로 컨텍스트에 올라오는 거죠. 모델이 내부 추론에 의존할 이유가 없어집니다.

핵심은 의존 구조를 교체했다는 거예요. 불확실한 내부 기억 의존 → 명확한 외부 파일 참조. 모델을 바꾸지 않았는데 환각이 줄어드는 이유가 여기 있는 것 같습니다.


🚀 작업 이력이 지식 자산이 되는 구조

Session Wrap에는 automation-scout라는 구성요소가 있습니다.
세션마다 반복 패턴을 발견해서 새 Skill 후보로 제안하는 역할이에요.

1회 세션에서 발견한 패턴이 Skill로 만들어지면, 2회 세션에서 그게 자동 트리거됩니다.
3회엔 이미 내재화된 방법론이 되고요. 작업할수록 Claude의 판단 기준이 업그레이드되는 복리 구조인 거죠.

1편에서 얘기한 "방법론의 코드화"가 Session Wrap으로 자동화되는 겁니다.

💡 팁: /wrap을 세션 종료 루틴으로 만들어두면 CLAUDE.md가 스스로 업데이트되는 시스템이 됩니다. 처음엔 빈 파일이지만 쌓일수록 달라져요.

하지만 이 구조를 팀 단위로 확장하려면 새로운 문제가 생깁니다.
한 팀원이 만든 Skill을 다른 팀원은 어떻게 공유하고, 권한은 어떻게 관리할까요? (다음편에서 다뤄볼게요)

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

BQ개발자 #LLM애플리케이션 #SessionWrap #AIEngineering