이 영상은 Shaw Talebi가 Claude 코드의 서브 에이전트와 에이전트 팀 기능을 자세히 설명하고, 실제 작업에 이 두 접근 방식을 비교하는 실험 결과를 공유합니다. 영상은 Claude 코드의 기본 개념부터 시작하여 AI 에이전트가 직면하는 문맥 처리의 한계, 그리고 이를 극복하기 위한 서브 에이전트와 에이전트 팀의 역할을 명확히 설명합니다. 특히, 각 방식의 장단점을 실제 사례와 데이터를 통해 보여주어 시청자들이 두 기능을 이해하고 적절히 활용하는 데 도움을 줍니다.

1. Claude 코드와 문맥 처리의 중요성 ✨

Shaw는 먼저 Claude 코드가 무엇인지 설명하며 영상을 시작합니다. Claude 코드는 기본적으로 언어 모델인 Claude와 그 주변에 구축된 다양한 도구 및 소프트웨어의 결합이라고 할 수 있습니다. 이 도구들은 로컬 파일 접근, 웹 검색, 터미널 명령 실행, 이전 대화 압축, 그리고 '생각 모드'나 '채팅 모드' 같은 다양한 모드 전환 기능을 포함하고 있어요. 또한, 복잡한 작업을 위해 할 일 목록을 만들거나 사용자에게 질문하여 추가적인 문맥을 파악하기도 합니다. 이러한 기능들이 결합되어 Claude 코드는 복잡한 소프트웨어 엔지니어링 작업을 포함한 다양한 유형의 작업을 수행할 수 있는 강력한 AI 에이전트가 됩니다.

하지만 아무리 강력한 LLM이라도 복잡한 작업을 수행할 때 문맥(context)을 처리하는 데 있어 여러 도전 과제에 직면하게 됩니다. 😥

• 기술적 한계: LLM이 한 번에 처리할 수 있는 텍스트의 양에는 문맥 창(context window)이라는 기술적 제한이 있습니다. 예를 들어, Claude Sonnet은 20만 토큰의 문맥 창을 가지고 있는데, 이는 긴 교과서 한 권 분량의 텍스트와 비슷하죠. 이 문맥 창 안에는 시스템 메시지, 도구 접근 정보, 사용자 메시지, LLM의 추론 과정, 도구 호출 결과, 에이전트의 응답 등 모든 정보가 담겨야 합니다. 만약 정보의 양이 이 한계를 넘어서면 에이전트는 해당 정보에 접근할 수 없게 됩니다.

• 문맥 부패(Context Rot): 더 큰 문제는 설령 모든 정보가 문맥 창 안에 들어가더라도, 문맥 창이 꽉 찰수록 모델의 성능이 저하되는 현상인 문맥 부패가 발생한다는 점입니다. Shaw는 이를 그래프로 보여주며, 문맥 창이 50%, 60%, 70% 이상 채워질수록 모델의 성능이 관찰 가능한 수준으로 저하된다고 설명합니다.

이러한 문제들 때문에 문맥 관리(context management)는 매우 중요합니다. 즉, 필요한 정보만 적절한 시기에 문맥 창에 있도록 하는 것이 핵심이죠.

2. 서브 에이전트: 분업을 통한 문맥 관리 🛠️

Shaw는 문맥 관리를 위한 강력한 방법 중 하나로 서브 에이전트(Subagents)를 소개합니다. 서브 에이전트의 기본 개념은 간단합니다.

"새로운 전문화된 Claude 코드 인스턴스에 작업을 위임하는 아이디어입니다."

이는 사용자가 Claude 코드에 요청을 보내면, 메인 에이전트(사용자와 상호작용하는 Claude 인스턴스)가 작업을 직접 수행하는 대신, 일부 또는 전체 작업을 서브 에이전트에게 위임할 수 있다는 뜻입니다. 예를 들어, 메인 에이전트가 '오늘날 사용 가능한 코딩 에이전트 도구를 모두 조사해달라'고 요청받으면, 메인 에이전트는 이 작업을 직접 하는 대신, 조사를 전담할 서브 에이전트를 생성할 수 있습니다.

서브 에이전트의 작동 방식:

1. 메인 에이전트는 특정 목적을 가진 서브 에이전트를 생성합니다.
2. 서브 에이전트는 작업을 수행하고 결과를 생성합니다.
3. 서브 에이전트는 이 결과를 다시 메인 에이전트에게 보고합니다.
4. 메인 에이전트는 모든 결과를 종합하여 사용자에게 전달합니다.

하나의 서브 에이전트에만 국한되지 않습니다. Claude는 필요한 만큼 여러 서브 에이전트를 생성할 수 있어서, 특히 리서치 작업에 매우 유용합니다. 여러 서브 에이전트가 각기 다른 검색어나 도메인으로 동시에 조사를 수행하고, 그 결과를 메인 에이전트에게 보고하면 메인 에이전트가 이를 종합하는 방식이죠.

서브 에이전트의 핵심 구성 요소는 모델, 도구, 목적의 세 가지입니다. Claude 코드에는 몇 가지 내장 서브 에이전트가 있습니다.

• 탐색 에이전트(Explore Agent): 가장 작은 모델인 Haiku를 사용하며, 파일 검색, 코드 검색 등 코드 베이스 이해를 위한 읽기 전용 도구에 접근합니다.
• 계획 에이전트(Planning Subagent): 메인 에이전트와 동일한 모델을 사용하며, 읽기 전용 도구에 접근하여 코드 베이스를 연구하고 구현 계획을 세우는 데 사용됩니다.
• 범용 에이전트(General Purpose Agent): 메인 에이전트의 복사본으로, 메인 에이전트와 동일한 모델과 모든 도구에 접근하며 복잡한 연구나 다단계 작업에 유용합니다.

물론 사용자는 자신만의 커스텀 서브 에이전트를 만들 수도 있습니다. 예를 들어, 특정 방식으로 코드 리뷰를 수행하거나 특정 코딩 표준을 충족하는 에이전트를 만들 수 있어요. 서브 에이전트는 텍스트 파일로 정의되며, 여기에는 이름, 설명, 접근 가능한 도구, 사용할 모델 등의 메타데이터와 함께 서브 에이전트가 따를 지침(instructions)이 포함됩니다. 메인 에이전트는 이러한 서브 에이전트의 이름과 설명을 활용해 어떤 서브 에이전트가 현재 작업에 적합한지 자동으로 판단하고 호출할 수 있습니다. 또한, 사용자가 특정 서브 에이전트 사용을 명시적으로 지시할 수도 있습니다.

3. 서브 에이전트의 한계와 에이전트 팀의 등장 🚀

서브 에이전트 방식에는 여전히 몇 가지 한계가 있습니다. Shaw는 이 한계를 병목 현상으로 설명합니다.

"이 서브 에이전트들은 많은 작업을 할 수 있지만, 메인 에이전트에게 다시 보고된 정보만 보존됩니다."

주요 한계는 다음과 같습니다.

• 서브 에이전트 간 직접 소통 불가: 서브 에이전트들은 오직 메인 에이전트와만 소통할 수 있고, 서로 직접 소통할 수 없습니다. 만약 서브 에이전트 A가 프론트엔드를 구축하고 서브 에이전트 B가 백엔드를 구축하는데, 이 둘이 서로 의존적인 관계라면 직접 소통하는 것이 매우 유용할 것입니다. 하지만 서브 에이전트 방식에서는 각각의 결과물을 메인 에이전트에게 보고하고, 메인 에이전트가 이를 통합하며 문제가 발생하면 다시 서브 에이전트들에게 지시를 내려야 합니다.
• 메인 에이전트의 문맥 한계: 모든 정보가 메인 에이전트를 거쳐야 하기 때문에, 메인 에이전트가 여전히 문맥 창 제한과 문맥 부패 문제에 직면할 수 있습니다. 메인 에이전트가 너무 많은 정보를 처리해야 하면 성능이 저하될 위험이 있다는 거죠.

이러한 한계를 완화하기 위해 등장한 것이 바로 에이전트 팀(Agent Teams)입니다. 에이전트 팀은 기본적으로 서브 에이전트들이 서로 대화할 수 있도록 해줍니다. 🗣️

에이전트 팀의 작동 방식은 서브 에이전트와 유사하게 사용자가 메인 에이전트에게 요청을 보내는 것으로 시작합니다. 하지만 이제 메인 에이전트는 단순히 서브 에이전트를 생성하는 대신, 공유 작업 목록(shared task list)을 만들고 다양한 지시를 가진 완전한 에이전트 팀을 구성합니다.

• 공유 작업 목록과의 직접 상호작용: 서브 에이전트들은 메인 에이전트를 거치지 않고 이 공유 작업 목록과 직접 상호작용할 수 있습니다. 즉, 작업을 맡거나 완료 표시를 할 수 있어서 공유 문맥을 직접 업데이트합니다.
• 서브 에이전트 간 직접 소통: 가장 큰 특징은 서브 에이전트들이 서로 직접 대화할 수 있다는 점입니다. 프론트엔드를 담당하는 에이전트, 백엔드를 담당하는 에이전트, 그리고 검증 에이전트가 있다면, 이들은 서로 자유롭게 소통하며 피드백을 주고받고 작업을 조율할 수 있습니다.
• 메인 에이전트의 감독 역할: 각 에이전트는 독립적으로 작업을 수행하며 완료될 때까지 일합니다. 메인 에이전트는 모든 것을 감독하며 공유 작업 목록을 주시하고, 모든 작업이 완료되면 최종 검토를 거쳐 사용자에게 결과를 전달합니다.

2026년 현재, 에이전트 팀은 아직 실험적인 기능입니다. 사용하려면 수동으로 활성화해야 하는데요. 프로젝트 폴더 내에 .claude라는 숨겨진 폴더를 만들고, 그 안에 settings.json 파일을 생성하여 claude-code-experimental-agent-teams 변수 값을 1로 설정해야 합니다. 활성화 후에는 Claude에게 명시적으로 "X, Y, Z 작업을 수행할 에이전트 팀을 생성해달라"고 지시할 수 있으며, 팀에 포함될 에이전트의 역할(예: 프론트엔드, 백엔드, 검증 담당)도 지정할 수 있습니다.

4. 서브 에이전트 vs. 에이전트 팀: 비교 분석 ⚖️

Shaw는 서브 에이전트와 에이전트 팀의 유사점과 주요 차이점을 정리합니다.

✅ 유사점:

• 둘 다 Claude가 새로운 Claude 코드 인스턴스에 작업을 위임할 수 있도록 합니다.
• 이는 메인 에이전트의 문맥 창을 효과적으로 관리하는 강력한 방법입니다. 특히 토큰 소모가 많은 연구 작업에서 불필요한 정보를 걸러내어 문맥 창에 노이즈가 쌓이는 것을 방지하고 성능 저하를 막을 수 있습니다.

❌ 주요 차이점:

• 서브 에이전트: 서브 에이전트들은 서로 대화할 수 없습니다.
• 에이전트 팀: 서브 에이전트들이 서로 대화할 수 있습니다.

Shaw는 이 차이점을 멀티 에이전트 시스템 아키텍처와 연결하여 설명합니다.

• 서브 에이전트: 중앙 집중식(Centralized) 아키텍처에 해당합니다. 메인 에이전트가 오케스트레이터 역할을 하고, 서브 에이전트들은 워커 에이전트로서 메인 에이전트와만 상호작용하며 명확한 계층 구조를 가집니다.

  • 장점: 아키텍처가 더 단순하고 오류 허용 범위(fault tolerant)가 높습니다. 한 서브 에이전트가 실수를 저질러도 그 실수가 다른 모든 에이전트로 전파되지 않고, 메인 에이전트가 이를 검토하고 수정할 기회를 가집니다.
  • 최적의 사용 사례: 순차적인 작업(sequential tasks)에 적합합니다. 예를 들어, A 작업 후 B 작업, 그리고 C 작업을 수행해야 하는 경우, 단일 의식의 흐름을 유지하며 작업을 진행하는 데 좋습니다.

• 에이전트 팀: 하이브리드(Hybrid) 아키텍처에 해당합니다. 리드 에이전트(메인 에이전트)와 서브 에이전트 사이에 명확한 계층 구조가 있지만, 서브 에이전트들이 서로 소통할 수 있다는 점에서 분산형(decentralized) 아키텍처의 특성도 가집니다. 즉, 중앙 집중식과 분산형 아키텍처를 혼합한 형태입니다.

  • 장점: 더 복잡한 아키텍처이며, 서브 에이전트들이 서로 소통할 수 있어서 병렬화 가능한 작업(parallelizable tasks)에 매우 유리합니다. 예를 들어, 복잡한 코드 베이스를 구축할 때 프론트엔드, 백엔드, 인증, 결제 통합 등 여러 구성 요소를 각각의 서브 에이전트가 동시에 작업하고 서로 조율하며 진행할 수 있습니다. 이를 통해 Claude 코드는 더 크고 정교한 애플리케이션을 구축하면서도 문맥 관리의 어려움을 피할 수 있습니다.
  • 단점: 오류 연쇄(error cascades)의 잠재성이 있습니다. 한 서브 에이전트의 치명적인 실수가 다른 서브 에이전트들에게 퍼져나가 전체적인 문제와 성능 저하를 초래할 수 있습니다.

5. 미니 실험: 서브 에이전트 vs. 에이전트 팀 실전 비교 🧪

Shaw는 서브 에이전트와 에이전트 팀을 실제 작업에 적용해 비교하는 미니 실험을 진행했습니다. 이 실험은 각 접근 방식이 세 가지 과제를 얼마나 잘 수행하는지 평가했어요.

실험 과제:

1. 리드 리스트 생성: 달라스-포트워스 지역의 중견 기술 기업에서 50명의 잠재 고객 연락처 목록(CSV 파일) 생성.
2. YouTube 강좌 생성기 앱 구축: YouTube 재생 목록을 입력받아 방해 없는 온라인 강좌로 변환하는 웹 앱 구축.
3. 랜딩 페이지 생성: 랜딩 페이지 디자인 및 설득력 있는 카피 작성.

Shaw의 초기 가설:

• 에이전트 팀: 리드 리스트 생성과 같이 병렬화 가능한 작업에 더 유리할 것이다.
• 서브 에이전트: YouTube 강좌 생성기 앱 구축과 같이 순차적인 작업에 더 유리할 것이다.
• 랜딩 페이지 생성: 순차적이고 병렬화 가능한 작업이 혼합되어 있어 결과를 예측하기 어려웠습니다.

실험 설정:

• 두 접근 방식에 동일한 프롬프트를 사용했습니다. (단, 에이전트 팀에게는 명시적으로 에이전트 팀을 사용하도록 지시하는 첫 줄이 추가됨.)
• 각 작업당 한 번만 실행하여 비용을 절감했습니다. (멀티 에이전트 시스템은 토큰 소모가 많기 때문)
• 총 실행 시간, 토큰 사용량, 결과물 품질을 평가 기준으로 삼았습니다.

5.1. 과제 1: 리드 리스트 생성 (병렬화 가능한 작업) 📊

• 목표: 달라스 지역 중견 기술 기업 50곳의 연락처 목록을 CSV 파일로 만듭니다.
• 예상: 에이전트 팀이 더 빠르고 효과적일 것입니다.

결과:

• 실행 시간: 예상대로 에이전트 팀이 훨씬 빨랐습니다. 여러 에이전트가 병렬로 실행되어 작업을 더 빠르게 완료했기 때문입니다.
• 토큰 사용량: 에이전트 팀이 더 많은 토큰을 사용했지만, Shaw의 예상만큼 (2-3배) 큰 차이는 아니었습니다.
• 결과 품질: 놀랍게도 서브 에이전트가 더 나은 품질을 보였습니다. 두 시스템 모두 50개의 연락처를 생성했지만, 에이전트 팀은 8개의 이메일만 제공한 반면, 서브 에이전트는 모든 연락처에 대해 이메일을 제공했습니다. Shaw는 에이전트 팀이 작업 완료에 있어서 덜 끈질겼던 것 같다고 평가했습니다.

5.2. 과제 2: YouTube 강좌 생성기 앱 구축 (순차적인 작업) 🖥️

• 목표: YouTube 재생 목록을 입력받아 방해 없는 온라인 강좌로 변환하는 웹 앱을 구축합니다.
• 예상: 서브 에이전트가 더 나은 성능을 보일 것입니다.

결과:

• 실행 시간: 에이전트 팀이 약간 더 빨랐지만, 큰 차이는 아니었습니다. Shaw는 이 작업이 병렬화 가능성이 낮아서 에이전트 팀이 에이전트를 생성했음에도 불구하고 작업이 사실상 순차적으로 진행되었기 때문이라고 설명했습니다.
• 토큰 사용량: 서브 에이전트가 더 적은 토큰을 사용했습니다.
• 결과 품질: 서브 에이전트가 확실히 우세했습니다. 서브 에이전트가 만든 앱은 더 나은 디자인과 진행률 표시줄을 가지고 있었던 반면, 에이전트 팀이 만든 앱은 디자인이 더 나빴고 진행률 표시줄도 없었습니다. Shaw는 단일 페이지 웹 앱과 같이 응집력이 필요한 작업에서는 단일 에이전트(서브 에이전트 방식)가 전체 문맥을 유지하며 작업을 수행하는 것이 유리하다고 평가했습니다.

5.3. 과제 3: 랜딩 페이지 생성 (혼합형 작업) 🌐

• 목표: 랜딩 페이지를 디자인하고 설득력 있는 카피를 작성합니다.
• 예상: 예측하기 어려움 (순차적+병렬화 가능 작업 혼합).

결과:

• 실행 시간: 놀랍게도 서브 에이전트가 더 빨랐습니다. 에이전트 팀은 Shaw의 배경, 카피라이팅, 랜딩 페이지 모범 사례 등에 대한 광범위한 리서치에 많은 시간을 할애했기 때문이라고 설명했습니다.
• 토큰 사용량: 역시 서브 에이전트가 훨씬 적은 토큰을 사용했습니다.
• 결과 품질: 명확한 승자가 없었습니다. 서브 에이전트가 만든 랜딩 페이지는 더 나은 디자인과 FAQ 섹션을 가졌지만, 에이전트 팀이 만든 랜딩 페이지는 더 좋은 카피를 제공했고, "누구를 위한 것인지"와 "누구를 위한 것이 아닌지"를 명확히 구분하는 등 더 설득력 있는 내용을 담았습니다. 두 구현 모두 ConvertKit 계정과의 웨이팅 리스트 가입 필드 통합은 성공적으로 작동했습니다.

6. 핵심 요약 및 결론 💡

Shaw의 미니 실험 결과는 예상과 다소 달랐지만, 몇 가지 중요한 통찰을 제공합니다.

1. 속도: 에이전트 팀이 일반적으로 작업을 더 빠르게 처리했습니다. 이는 병렬 처리 능력 덕분입니다.
2. 토큰 사용량: 에이전트 팀이 모든 작업에서 더 많은 토큰을 생성했지만, Shaw의 예상만큼 압도적으로 많지는 않았습니다.
3. 결과물 품질: 서브 에이전트가 전반적으로 더 나은 결과물 품질을 꾸준히 보여주었습니다.

Shaw는 이러한 결과가 에이전트 팀 기능이 아직 실험 단계에 있고, 그 '초기 스캐폴딩(scaffolding)'이 미성숙하기 때문일 수 있다고 추측합니다. 즉, 에이전트 팀 아키텍처 자체의 한계라기보다는 구현의 문제일 가능성이 있다는 것이죠. 그는 Anthropic이 더 많은 피드백을 받아 기능을 개선할 것이라고 기대합니다.

"하지만 이 시점에서 저는 아마도 실제 작업을 할 때는 서브 에이전트를 고수할 것 같습니다."

Shaw는 현재로서는 실제 작업 수행에는 서브 에이전트가 더 안정적이며, 에이전트 팀은 추가 실험을 통해 가능성을 탐색하는 데 사용할 것이라고 결론 내립니다. 그는 시청자들에게도 에이전트 팀이나 특수 서브 에이전트를 사용해본 경험이 있다면 댓글로 공유해달라고 요청하며, 이러한 정보가 자신과 다른 시청자들에게 큰 도움이 될 것이라고 강조합니다.