00:00:00Anthropic에서 내놓은 업그레이드가 Opus 4.6뿐이었을까요?
00:00:03각 에이전트가 개별 엔티티로서 고유한 컨텍스트 창을 가지고
00:00:07작동하는 하위 에이전트에 대해서는 이미 알고 계실 겁니다.
00:00:09하지만 이 하위 에이전트들은 상호 간의 협업이 필요한 작업에서는 한계를 보였습니다.
00:00:13그런 경우, 오케스트레이터가 개입하여 한 에이전트의 응답을 받아
00:00:17다른 에이전트에게 전달하거나, 에이전트들이 프로젝트 폴더의 메모에 의존해야 했습니다.
00:00:21이러한 소통의 공백 때문에 단순한 작업조차 지나치게 복잡해지곤 했죠.
00:00:25이를 해결하기 위해 Anthropic은 하위 에이전트의 새로운 업그레이드 버전인 '에이전트 팀(Agent-Teams)'을 출시했습니다.
00:00:30이 기능은 Opus 4.6과 함께 공개되었습니다.
00:00:33아직 실험적인 기능임에도 불구하고 저희는 이를 여러 워크플로우에 적용해 보았는데,
00:00:37가장 큰 개선점은 작업 소요 시간이 획기적으로 단축되었다는 것이었습니다.
00:00:41물론 실험적 기능인 만큼 보완해야 할 부분도 있었지만,
00:00:44저희는 그러한 문제들에 대한 해결책도 찾아냈습니다.
00:00:47에이전트 팀은 여러 개의 Claude Code 인스턴스가 함께 협업하는 개념입니다.
00:00:51팀의 각 구성원은 독립된 작업을 수행하며, 한 에이전트가 제어하는
00:00:55중앙 집중식 관리를 받습니다.
00:00:56기존 Claude 하위 에이전트도 병렬로 실행되고 작업을 분담하기에 비슷하다고 생각하실 수 있지만,
00:01:00엄밀히 말하면 다릅니다.
00:01:03에이전트 팀은 하위 에이전트 프레임워크가 가진 결정적인 문제 하나를 해결했기 때문입니다.
00:01:08하위 에이전트들은 서로 소통할 수 없어서 오케스트레이터 에이전트가
00:01:12중간에서 통신 매체 역할을 해줘야만 했습니다.
00:01:15반면, 팀 구성원들은 서로 직접 소통할 수 있습니다.
00:01:18에이전트 팀의 핵심 아이디어는 여러 Claude Code 세션이 함께 작동하는 것입니다.
00:01:22한 세션은 팀 리더로서 작업을 조율하고 할당하며 결과를 종합하고,
00:01:27팀원들은 각자의 컨텍스트 창에서 독립적으로 작업합니다.
00:01:31하위 에이전트는 고유한 컨텍스트 창을 갖고 그 결과를 호출자에게 보고하지만,
00:01:34팀 방식은 작동 원리가 다릅니다.
00:01:36에이전트 팀의 각 구성원은 완전히 독립된 터미널 세션입니다.
00:01:40이들은 단순히 작업을 나누기만 하는 오케스트레이터에 의해 제한되거나 조정되지 않습니다.
00:01:43대신, 이 터미널 세션들은 메인 팀 리더에 의해 열리고 닫힙니다.
00:01:47이들은 소통 능력을 바탕으로 에이전트 간의
00:01:52토론과 협업이 필요한 작업을 수행할 수 있습니다.
00:01:54따라서 에이전트 팀은 본질적으로 팀 리더와 팀원들로 구성됩니다.
00:01:57팀 리더는 팀을 생성하고 작업을 조율하는 메인 에이전트입니다.
00:02:01팀원들은 실제로 작업을 수행하는 작업자들입니다.
00:02:03각 팀원은 공유된 항목 리스트인 작업 리스트를 받습니다.
00:02:07각 구성원은 이 리스트에서 자신이 해야 할 일을 식별하고 실행합니다.
00:02:10또한 소통을 위해 서로 메시지를 주고받을 수 있는 공유 사함함을 가집니다.
00:02:15여기서 질문은, 각 팀원이 독립적이라면 이것이 실제로 어떻게 작동하느냐는 것입니다.
00:02:19다른 멤버가 무엇을 하고 있는지 어떻게 알 수 있을까요?
00:02:21이것이 가능한 이유는 팀, 구성원, 그리고 각 구성원이 작업 중인 작업에 대한
00:02:26모든 정보가 '.claude' 폴더에 로컬로 저장되고 작업 이름으로 식별되기 때문입니다.
00:02:30이 기능은 아직 실험 단계이며 기본적으로 비활성화되어 있어, 이 과정에서
00:02:34팀원 처리와 관련된 일부 버그가 발생할 수 있습니다.
00:02:36이 기능을 사용해 보려면 수동으로 활성화해야 했습니다.
00:02:38저희는 Claude Code CLI 플래그에서 'experimental agent teams' 설정을 1로 지정했습니다.
00:02:43이 CLI 플래그를 활성화하면 이후 세션부터 에이전트 팀을 사용할 수 있게 됩니다.
00:02:47플래그 활성화 후 Claude Code의 팀 기능에 접근할 수 있었습니다.
00:02:51실험적 기능이므로 Claude에게 특정 작업에
00:02:55에이전트 팀을 사용하고 싶다는 구체적인 문구를 사용해야 했습니다.
00:02:58저희 팀은 코드 문제를 식별함과 동시에 수정할 수 있도록
00:03:02코드 리뷰를 병렬화하는 데 이 기능을 사용하기 시작했습니다.
00:03:04이를 위해 한 팀원은 코드베이스에서 문제를 찾고,
00:03:08다른 팀원은 첫 번째 팀원이 찾은 문제를 수정하도록 Claude에게 요청했습니다.
00:03:11올바른 방향으로 진행되도록 프롬프트를 매우 상세하게 작성해야 했습니다.
00:03:15만약 하위 에이전트가 이 작업을 처리했다면, 다른 에이전트에게 수정할 내용을 알리기 위해
00:03:19어떤 물리적 파일에 보고서를 작성하고 있었을 것입니다.
00:03:21하지만 저희는 로컬 파일에 쓰는 오버헤드 없이 이 과정이 진행되도록 하여
00:03:26리뷰 프로세스의 속도를 높이고자 했습니다.
00:03:27Claude Code에 프롬프트를 입력하자 팀 리더가 제어하는
00:03:31팀원 에이전트들이 생성되었습니다.
00:03:32리더 에이전트는 각 에이전트에게 프롬프트를 전달하여 수행할 작업을 알려주었습니다.
00:03:36먼저 코드 리뷰어 에이전트가 작업을 시작했고, 분석을 마친 뒤
00:03:40코드 수정자 에이전트에게 버그별로 메시지를 공유했습니다.
00:03:42리뷰어 에이전트는 중대한 보안 문제를 우선시했고, 코드 수정자는
00:03:47메시지를 받는 즉시 수정을 시작했으며, 그동안 리뷰어는
00:03:51계속해서 다른 문제들을 찾아 나갔습니다.
00:03:53이런 식으로 두 에이전트는 계속 소통하며 구현된 변경 사항을 보고했습니다.
00:03:57중대한 문제들이 해결되자 두 에이전트는
00:04:01중간 우선순위의 문제들을 수정하기 시작했습니다.
00:04:02코드 리뷰와 수정이 동시에 이루어져 시간을 크게 절약할 수 있었습니다.
00:04:06이 기능의 장점은 팀원에게 어떤 작업이든 할당하거나 수정할 수 있다는 것입니다.
00:04:10이를 통해 특정 팀원의 작업 방향을 직접 조정할 수 있습니다.
00:04:14에이전트들의 작업이 끝나면 제어권은 다시 메인 에이전트에게 돌아가며,
00:04:18메인 에이전트는 변경 사항이 올바르게 반영되었는지 확인하고
00:04:22나중에 오류가 발생하지 않도록 에이전트들을 정상적으로 종료시킵니다.
00:04:26저희 영상에서 무언가를 만드는 모습을 자주 보셨을 겁니다.
00:04:28모든 프롬프트, 코드, 템플릿 등 화면을 멈추고 일일이
00:04:32복사해야 했던 자료들을 저희 커뮤니티에 모두 올려두었습니다.
00:04:36이번 영상뿐만 아니라 이전 영상 자료들도 있습니다.
00:04:37링크는 설명란을 확인해 주세요.
00:04:38문제를 찾아 고치는 것도 좋지만, 원인을 도저히
00:04:43파악할 수 없는 경우도 종종 발생합니다.
00:04:45그럴 때 에이전트 팀을 활용해 앱의 여러 측면을 테스트하며
00:04:49점진적으로 버그를 추적해 나갈 수 있습니다.
00:04:51팀원들이 각자의 발견 사항을 공유하며 함께 나아갈 수 있기 때문입니다.
00:04:55저희는 Claude에게 여러 팀원을 사용하여 코드베이스의 버그를 찾으라고 요청했고,
00:04:59문제를 다양한 관점에서 접근하도록 했습니다.
00:05:02그러자 동일한 앱의 서로 다른 측면에 집중하는 4개의 하위 에이전트가 생성되었습니다.
00:05:06이들은 팀 리더로부터 유사한 프롬프트를 받아 각자의 담당 영역에서 오류를 조사했고,
00:05:09메인 리더는 이들이 끝나기를 기다렸다가
00:05:14조사 결과들을 분석했습니다.
00:05:16팀 기능이 없었다면 단일 스레드로 작업하여 훨씬 오래 걸렸을 것입니다.
00:05:19하지만 에이전트 팀을 활용하니 프로세스가 훨씬 빨라졌습니다.
00:05:22조사는 신속하게 완료되었으며, 에이전트들의 모든 연구는 약 2~3분 만에 끝났습니다.
00:05:27이는 5~10분 정도 걸렸을 선형적인 확인 방식에 비해
00:05:31상당한 개선입니다.
00:05:33한 가지 주의할 점은 각 에이전트가 고유한 컨텍스트 창을 사용하기 때문에
00:05:37토큰 소모가 많다는 점이며, 이 부분을 유의해야 합니다.
00:05:40에이전트들이 결과를 반환하고 종료되자, 팀 리더는
00:05:45직접 검토하여 결과를 검증했습니다.
00:05:464명의 에이전트 모두 동일한 버그를 찾아냈고,
00:05:50useEffect의 stale closure 문제를 정확히 지적했습니다.
00:05:524명의 에이전트 모두 정확히 이 부분을 짚어냈습니다.
00:05:54또한 저희 콘텐츠가 마음에 드신다면 'Hype' 버튼을 눌러주세요.
00:05:59더 좋은 콘텐츠를 만들고 더 많은 분께 다가가는 데 큰 힘이 됩니다.
00:06:02이 에이전트 프레임워크는 장기적인 작업을 수행하는 방식을 바꾸어 놓았습니다.
00:06:07에이전트들이 단순히 진행 상황을 기록하는 데 의존할 필요가 없기 때문입니다.
00:06:10에이전트 팀을 통해 앱의 다양한 측면을 병렬로 처리하고,
00:06:14조사 및 연구 전담 팀원을 둘 수도 있습니다.
00:06:16Claude에게 프롬프트를 주었더니 6명의 에이전트가 생성되었습니다.
00:06:192명은 조사와 기초 토대 마련을 담당했고, 나머지는
00:06:23페이지 구축을 맡았습니다.
00:06:24빌더 에이전트들은 기초 담당 에이전트의 작업이 끝날 때까지 대기해야 했습니다.
00:06:28필요한 패키지를 설치하고 모든 의존성이 갖춰진 환경을 준비해야 했기 때문입니다.
00:06:32각 에이전트는 역할을 정의하는 구체적인 프롬프트를 받았습니다.
00:06:35대기 중인 에이전트들은 팀 리더의 차단 해제 신호를 계속 기다렸습니다.
00:06:38조사와 기초 작업이 완료되자 나머지 에이전트들의 차단이 해제되어
00:06:43각자의 애플리케이션 파트를 동시에 구현하기 시작했습니다.
00:06:46이들은 각 컴포넌트 간의 일관성을 위해 서로 계속 소통했습니다.
00:06:49팀 리더는 에이전트들을 계속 조율했고, 작업이 끝난 에이전트에게는
00:06:53종료 메시지를 보내 안전하게 종료시켰습니다.
00:06:57이 전체 과정에서 약 17만 개의 컨텍스트 창 토큰이 소모되었지만, 결국
00:07:02단 한 번의 프롬프트로 우리가 원하던 앱을 정확히 만들어냈습니다.
00:07:05앞서 말씀드린 것처럼 저희 팀이 이를 테스트하면서
00:07:09에이전트 팀을 더 잘 활용할 수 있는 여러 방법을 찾아냈습니다.
00:07:13이러한 베스트 프랙티스는 AI Labs Pro에서 확인하고 직접 따라 해 보실 수 있습니다.
00:07:16첫 번째 권장 사항은 에이전트 팀뿐만 아니라
00:07:20모든 에이전트에게 일반적으로 적용되는 내용입니다.
00:07:21에이전트가 작업해야 할 범위를 명시적으로 지정해야 한다는 점입니다.
00:07:25프롬프트에 정의하거나 작업을 위해 확인해야 할 파일을 지정할 수도 있고,
00:07:29저희 워크플로우처럼 개별 작업이 포함된 문서를 프로젝트에 생성할 수도 있습니다.
00:07:33저희는 각 할당량에 맞춰 적절한 작업 문서를 준비하여
00:07:38에이전트가 올바른 범위 내에서 독립적으로 일할 수 있게 했습니다.
00:07:41또 한 가지 유의할 점은 각 에이전트가 서로 독립적인
00:07:45작업을 수행해야 한다는 것입니다. 여러 에이전트가 동시에 같은 파일을 편집하면
00:07:49충돌이 발생하여 내용이 덮어써질 위험이 있기 때문입니다.
00:07:52이 외에도, 팀원이 작업을 완료하는 데 시간이 걸리면 메인 에이전트가
00:07:56조급해져서 팀원이 끝내기를 기다리지 않고
00:08:00직접 작업을 시작해 버리는 경우가 가끔 있었습니다. 따라서 팀 리더에게
00:08:04팀원이 완료할 때까지 기다리라고 상기시키는 것이 중요합니다.
00:08:06작업 규모를 적절히 조절하는 것도 필요합니다.
00:08:08작업을 너무 잘게 나누면 조율 오버헤드가 발생합니다.
00:08:11반대로 너무 크게 잡으면 노력 낭비의 위험이 커지므로,
00:08:16작업은 균형 잡히고 독립적인 형태여야 합니다.
00:08:17마지막으로, 에이전트의 작업을 모니터링해야 합니다.
00:08:19어떤 에이전트가 기대한 대로 작동하지 않는다면 실행을 중단하고
00:08:23수행해야 할 작업에 대해 새로운 지침을 줄 수 있습니다.
00:08:25이러한 실천 사항들을 따르면 이 실험적 기능을 훨씬 효과적으로 사용할 수 있습니다.
00:08:29이제 영상의 끝부분에 다다랐네요.
00:08:31저희 채널을 후원하고 이런 영상을 계속 제작할 수 있도록 돕고 싶으시다면
00:08:35아래의 'Super Thanks' 버튼을 이용해 주세요.
00:08:38언제나 시청해 주셔서 감사드리며, 다음 영상에서 뵙겠습니다.