어제, 앤트로픽에서 CloudCode Teams를 출시했는데, CloudCode 도구 세트에 혁신적인 변화를 가져다 줄 엄청난 기능입니다.00:00

오늘, 이 업데이트가 왜 이렇게 큰 의미를 가지는지 자세히 설명드리고, CloudCode Teams를 활용하여 이 새로운 기능을 최대한 활용하실 수 있는 방법을 보여드리겠습니다.00:08

말씀드린 것처럼, 이것은 Cloud Code 내 새로운 실험적인 기능입니다. 설정에서 활성화해야 하고, 이를 수행하는 방법에 대한 빠른 사용 설명서입니다.00:22

클라우드 코드 설정 파일의 settings.json 파일에 한 줄만 추가하면 됩니다. 이제 클라우드 코드에서 팀을 활성화했으니, 이 기능이 왜 이렇게 강력한지 알아보겠습니다.00:33

저도 여러 분들께서, 음, 팀즈를 계속 사용하시는 이유나 팀즈와 서브 에이전트의 차이점이 무엇인지 물어보시는 경우가 많았습니다.00:47

이 영상에서 조금 더 자세히 풀어 설명할 수 있기를 바랍니다. 팀은 팀원들로 구성되고, 클라우드코드 팀원들이죠?00:55

그래서 클라우드코드는 이 팀메이트 도구를 사용합니다. 제가 알기로는, 팀메이트를 생성하고 서브 에이전트 팀을 구성하기 위해 13개 정도의 도구가 있는 것 같습니다.01:03

기본적으로 이들은 하위 에이전트들의 팀이라고 생각할 수 있습니다. 하지만, 팀원은 하위 에이전트와 달리 매우 좁은 범위에 집중할 수 있다는 차이점이 있습니다.01:14

과거에는 서브 에이전트의 경우, Cloud Code 내에서 사용자 지정 서브 에이전트를 개발하거나, 작업 도구와 같은 범용 서브 에이전트를 활용하실 수 있었습니다.01:23

하지만 팀원들과 함께라면, 이제는 필요할 때마다 즉시 실행되도록 매우 좁게 특화된 하위 에이전트를 설정할 수 있습니다.01:35

이것은 무엇보다도, 특정 문제에 집중하여 귀하가 다루고 있는 문제점에 대한 좁고 세분화된 하위 에이전트를 활용할 수 있다는 의미입니다.01:43

실제로 적용해 보면 어떤 모습일지, 그리고 왜 이것이 Cloud Code의 큰 발전인지 설명드리자면, 팀원들과 함께 사용할 수 있는 다양한 패턴이 있다는 점입니다. 그렇죠?01:50

초기에 어떤 패턴이 있는데, 제가 여기 간단하게 그려봤습니다. 여기서 오케스트레이터, 즉 사용자가 대화하는 주 Cloud Code CLI 인스턴스가 개별 팀원을 생성하게 됩니다.01:59

그리고 제가 말씀드린 것처럼, 이 팀원들은 특정 문제에 집중하도록 좁게 설정되어 있습니다. 이제 왜 이것이 서브 에이전트보다 더 나은지, 그리고 어떻게 진정으로 활용할 수 있는지 말씀드리겠습니다. 그건 바로 그들에게 전문성을 부여함으로써 가능합니다.02:11

과거에 서브 에이전트에게 전문성을 부여하고 스스로 발전하는 서브 에이전트를 만드는 방법에 대해 말씀드린 적이 있습니다.02:22

이것은 매우 유사합니다. 이전의 문제들을 해결해 온 하위 에이전트들이 생성한 전문 지식을 활용하여 팀원들에게 제공할 수 있게 되었습니다.02:29

팀원분들은 지금 특정 분야에 집중하고 계시는군요, 맞죠? 특정 과제를 수행하고 계시지만, 코드 베이스나 하위 에이전트들의 더 넓은 범위의 전문 지식에도 접근하실 수 있습니다.02:41

이전까지 효과적이었던 방식과 관련하여 말씀드리면, 이 예시에서 보시는 것처럼 오케스트레이터가 특정 예제 문제를 처리하고 있는데, 동일한 전문 지식 영역에서 정보를 가져오는 두 명의 팀원을 생성해야 합니다.02:55

잠시 후에 좀 더 구체적인 예시를 보여드리겠지만, 여기에는 세 번째 팀원도 계시는데, 별도의 전문 지식을 활용하고 계십니다.03:09

음, 코드 DB 코드 베이스 내에서, 아시겠지만, 오픈 소스 프로젝트인데, 링크는 아래에 남겨드릴게요. 여기 .claw 디렉토리를 살펴보시면 됩니다.03:18

이것은 실제로 이 모든 것들이 작동하는 실제적인 예시를 보여줄 거예요. 하지만 코다DB 코드 베이스를 통해 좀 더 현실적인 예시를 보여드리기 위한 것입니다. 실제로 어떻게 생겼는지 보여드리기 위해서죠.03:27

그래서, 음, 이 do 팀 프롬프트를 이용해서 오케스트레이터를 가지고 계시다는 거죠. 잠시 후에 설명해 드릴게요. 이 오케스트레이터는 여러 개의 전문화된 서브 에이전트나 팀원을 생성하고, 그 서브 에이전트들은 이것에 의존하고 있습니다.03:39

제가 지난 몇 주 동안 설정하고 관리하며 스스로 개선해 온 전문 지식 파일들입니다.03:53

이제 저는 범용적인 기술보다는 데이터베이스 레이어에 대한 전문 지식을 갖추게 되었고, 데이터베이스 서브 에이전트를 활용할 수 있게 되었습니다. 마치 데이터베이스 스키마 팀원을 두고 일하는 것과 같은 느낌이랄까요?04:01

이것은 하위 에이전트보다 더욱 세부적인 내용에 집중할 수 있게끔 하는 기능인데, 코드를 보여드리기 전에 몇 가지 다양한 패턴이 있다는 점을 강조하고 싶습니다. 이 기능은 정말…04:14

하루 정도 밖에 없었는데요, 사실 하루도 안 된 것 같아요. 지금은 제가 이해하고 있고, 지난 하루 동안 효과가 있었던 점들을 처음으로 정리하고 있는 초반 단계라고 할 수 있겠네요. 여러 가지를 알아봤습니다.04:26

제가 지금까지 보여드린 내용과 관련하여, 이 오케스트레이터는 자체적으로 개별 팀원이나 전문가를 생성할 수 있습니다. 이는 일관된 방식입니다.04:39

오케스트레이터가 쉽게 팀원들을 생성하고, 팀원들이 직접 오케스트레이터에게 보고하는 방식이죠. 작은 작업에는 정말 강력한 기능이고, 빠르고 토큰 사용량도 적어서 아주 유용한 패턴이라고 할 수 있습니다.04:51

오푸스 4.6가 워낙 성능이 뛰어나서 대부분의 사용 사례에서는 잘 작동할 것 같습니다. 다만, 이 계층적 패턴을 보여주고 싶습니다. 이는 좀 더 위임적인 조정 방식입니다.05:05

보아하니 오케스트레이터가 리드 에이전트를 생성하는 것으로 보입니다.05:20

팀 도구와 함께 작업하기 시작하시면 Cloud Code가 이것을 하는 것을 보실 수 있을 거예요. 오케스트레이터로서 Cloud Code가 팀 리드 에이전트를 생성하는 것을 보실 수 있습니다.05:27

그리고 나서 해당 팀의 리더는 다른 팀원들에게 업무를 배분하게 됩니다.05:36

예시에서 보시는 것처럼, 이 오케스트레이터가 다시 리드 에이전트를 생성하고, 팀 리드는 CLI 에이전트, 훅스 워커, 그리고 테스팅 워커에 접근할 수 있습니다. 그리고 각각의 개별…05:41

팀 리더가 생성한 팀원이 전문 지식 파일을 접근하고 있습니다. 해당 파일은 자체적으로 개선되도록 설정되어 있는데, 이제 팀 리더가 가지고 있습니다.05:57

이 모든 근로자들로부터 정보를 얻고, 또한 정보를 주고받고 있습니다.06:11

그리고 이 모든 작업자들이 작업을 완료하면, 팀도 작업을 완료하고 나서 오케스트레이터에게 보고합니다. 그래서 이건 굉장히 강력한 기능이에요. 즉, 여러분은 프로젝트 전체를 더 넓게 볼 수 있는 고수준 오케스트레이터를 가질 수 있다는 뜻입니다.06:17

이걸 이용해서 이론적으로 여러 문제를 해결할 수 있습니다. 동시에 하나의 오케스트레이터와 대화하면서, 전체적인 상황을 파악하고 있죠. 예를 들어, 백엔드 기능이 프론트엔드와 상호작용하는 새로운 기능을 개발한다고 가정해 봅시다.06:33

명백히 말씀드리면, 하나의 담당자가 두 가지 모두 처리하는 것은 적절하지 않은 것 같습니다.06:47

하지만 오케스트레이터가 팀 리더를 생성할 수 있고, 그 팀 리더가 백엔드를 담당해서 오케스트레이터에게 보고하며, 오케스트레이터가 또 다른 팀 리더를 통해 프론트엔드를 처리하도록 할 수 있다면, 이러한 구조가 얼마나 빠르게 강력해질 수 있는지 짐작하실 수 있을 겁니다.06:50

자, 이제 실제 코드, 이것이 어떻게 보이는지 자세히 살펴볼게요. 제가 이 비디오 초반에 보여드렸던 실행 과정입니다. GitHub 이슈를 가리키는 간단한 프롬프트가 있는 것을 볼 수 있습니다.07:04

물론이죠, 저는 위험하게 권한을 건너뛴 상태로 클로드(Claude)를 실행하고 있습니다. 그리고 시스템 프롬프트 파일은 이 do 팀즈(do teams) 파일인데, 지금 바로 자세히 살펴보겠습니다.07:18

하지만 빠르게, 이게 평탄한 패턴이라는 걸 알 수 있어요. 그래서 이건, 있잖아요, 오케스트레이터가 전문가들을 생성하고, 팀 리더는 관여하지 않아요.07:29

음, 이 문제가 어떻게 보이는지는, 아시다시피, 특정 데이터베이스 전문가의 영역이고, 이 문제는 의도적으로 여러 코드 섹션을 건드리고 있습니다.07:40

다양한 분야의 전문성이 필요합니다. 그래서 데이터베이스 전문가, API 전문가, 그리고 테스트 전문가가 있습니다.07:50

그리고 오케스트레이터가 이 모든 것들을 생성했습니다. 이 예시는 서브 에이전트와 크게 다르다고 보이지 않습니다.07:57

다만, 해당 에이전트에게 전달되는 프롬프트는 제가 말씀드린 것처럼 일반적인 서브 에이전트보다 훨씬 더 전문화되어 있다는 점은 참고해 주시면 좋겠습니다.08:05

만약 제가 이 작업을 위해 일반적인 서브 에이전트를 사용한다면, 예를 들어 Cloud Code 내의 작업 도구에서 결과가 일관되지 않을 거예요. 그리고 이건 Cloud Code에서 팀이라고 부르는 스웜이나 팀에게는 정말 중요한 부분입니다.08:15

에이, 확실히 에이전트 실행 간에 큰 차이가 없도록 하는 거죠. 그래서 이 에이전트들이 예측 가능하게 프롬프트되도록 하고, 동일한 정보를 제공하고, 동일한 전문 지식을 갖도록 하고 싶어요.08:27

파일들을 처리하는 동안, 좁게 집중된 작업을 수행하는 동안에도, 새로운 컨텍스트가 이 코드 베이스에 들어오지 않도록 보장할 수 있어요.08:41

무엇을 알아내고 작업을 완료하려고 하는 거죠. 그러니까 제가 말씀드린 것처럼 좁게 집중하는 거예요. 좋아요, 그럼 이제 팀 프롬프트, 즉 제가 이전에 언급했던 시스템 프롬프트를 살펴볼까요?08:53

이 특정 에이전트 실행에 대해 시스템 프롬프트가 실행되고 있음을 알 수 있습니다. 여러분도 보셨듯이, 전문가들이 아주 훌륭하게 역할을 분담했지만, 실제로 에이전트가 받는 프롬프트는 꽤 큰 편입니다.09:05

약 4,000 토큰이 넘습니다. 그리고 이 기능은 기본적으로 오케스트레이터에게 일관성 있는 팀을 구성하도록 지시하는 역할을 합니다.09:19

다시 한번 말씀드리지만, 떼 그룹의 팀원 간 분산을 줄이는 것이 중요합니다.09:29

만약 그것을 어떻게 해야 하는지 알아낼 수 있다면, 다른 사람들보다 훨씬 앞서 나갈 거예요. 그래서 모든 사람들이 팀 도구를 사용하게 될 거고, '정말 좋네요'라고 말하게 될 거예요.09:38

하지만 이미 코드 베이스에 구축된 전문성을 활용하지 않거나 일관성이 없다면, 결국은 코드 베이스에 대한 맥락이 전혀 없는 여러 클라우드 코드 에이전트를 실행하는 것과 마찬가지입니다. 의미가 없겠죠.09:47

손상을 적절하게 처리하려면 일관성을 유지하는 것이 중요합니다. 이 프롬프트는 바로 그런 역할을 합니다. 오픈 소스이며 코드 DB 저장소에 있습니다. 자세한 내용은 해당 프롬프트를 확인해 보실 수 있습니다. 간단히 말해서...10:01

그냥 오케스트레이터 에이전트가 좋은 팀이 어떤 모습인지 이해하도록 안내하는 정도입니다. 이 코드베이스에서, 이전 영상에서도 말씀드린 적이 있지만, 저희는...10:14

에이전트 전문가들은 각자 이런 expertise.yaml 파일을 가지고 있습니다. 이 파일은 각 전문가들이 참조하는 파일인데, 이 파일 하나만 있으면 됩니다. 다만, 지금 보이는 것처럼 파일이 조금 복잡해 보이실 수 있습니다.10:26

에이전트가 특정 분야에서 업무를 수행할 때마다요.10:38

이런 잡 파일들은 어느 정도 무시해도 괜찮지만, expertise.yaml 파일은 정말 중요합니다. 제가 자가 개선 에이전트에 대해 설명했던 영상에서 말씀드린 것처럼, 에이전트가 작업을 완료한 후 이 파일을 업데이트하여 완료한 작업을 기록하는 바로 그 파일입니다.10:43

이것은 각 분야에 따른 지식이 계속 진화하는 형태라고 할 수 있습니다.10:58

여기 10개의 도메인이 있고, Do 팀 프롬프트, 팀 오케스트레이터, 즉 최고 수준의 에이전트가 그것을 인지하고 있습니다.11:04

이 모든 도메인이 존재하고, 각 도메인마다 특정 분야 전문 지식이 있습니다. 이거 정말 중요해요. 팀원을 생성할 때, 각 팀원에게 전문 지식을 전달하도록 하는 것이 중요하니까요.11:15

여기 떼를 이루는 각 에이전트, 그리고 여러분 팀의 각 에이전트입니다. 이것은 오케스트레이터가 팀원을 호출하는 방식에 대한 정확한, 정확히 알고 계시는, 틀이라고 할 수 있습니다.11:30

이 매우 구체적인 프롬프트를 통과하고 있습니다. 이건 단지 템플릿일 뿐이지만, 이 하위 에이전트, 이 팀원을 위한 맥락 안에서 확인하실 수 있습니다.11:40

죄송하지만, 용어가 너무 헷갈리니까 저를 따라오셔야 할 거예요.11:50

하지만 이 전문성 파일을 전달하고 있답니다.11:55

네, 제가 사용하는 환경에 코딩되어 있어서, 그거는 제가 수정할 예정입니다. 하지만 전문 지식 파일은 제대로 전달되고 있는 것 같습니다.12:00

이것은, 음, 예를 들어, 데이터베이스 에이전트가 제 에이전트 전문가 디렉터리의 데이터베이스 섹션으로 간다고 말씀드릴 수 있겠습니다.12:08

그리고 작업을 시작하기 전에 이 전문 지식 파일을 읽어야 합니다. 계획을 세우든, 무언가를 구축하든, 작업하는 동안 해당 도메인 전문 지식을 활용하게 되는데, 이것이 중요한 포인트입니다.12:18

다른 패턴들도 몇 가지 있습니다. 예를 들어, 저는 리서치나 읽기 전용 작업에 더 적합한 '카운셀' 패턴을 사용하고 있습니다. 하지만 다시 한번 말씀드리지만, 제가 정의하는 이 스키마들은 모든 팀원을 전문 지식 파일로 연결하고 있습니다.12:30

정말, 정말 중요한 내용들이 여기 있습니다. 제가 말씀드린 것처럼, 전체 도 팀 프롬프트를 읽어보실 수 있습니다. 이용 가능합니다. 원하신다면, 레포지토리를 포크해서 직접 사용해 보셔도 좋습니다.12:45

에이전트 팀에 대해 제가 생각하는 방식은 이렇습니다. 제가 말씀드린 것처럼, 아마 제가 지금까지 본 가장 중요한 클라우드 코드 업데이트일지도 모르겠습니다.12:55

음, 확실히 올해 안에 나올 것 같습니다. 굉장히 강력한 내용들이 준비되어 있습니다. 핵심적으로 기억해야 할 부분은...13:04

이것에서 중요한 점은 팀원들의 분산을 줄이고 싶다는 것입니다. 이전에 '스웜(swarm)'이라고 불렸던 에이전트 팀은 훨씬 더 많은 하위 그룹을 포함함을 의미합니다.13:13

에이전트라고 부르시든지, 아니면 팀원이라고 부르시든지 간에, 용어 자체가 조금 헷갈릴 수 있지만, 팀에 있는 모든 에이전트가 프로젝트 표준에 맞춰서 업무를 진행하고 있는지 확인하는 것이 중요합니다.13:28

코드 베이스 내에 이미 축적된 전문 지식을 바탕으로 하시는 것이 중요합니다. 또한 오케스트레이터 에이전트의 역할 분담도 적절하게 처리하시는 것을 고려해야 합니다. 말씀드린 것처럼 오케스트레이터를 구현하는 방법은 여러 가지가 있습니다.13:40

업무를 위임하는 것은 매우 중요하며, 이는 귀하의 업무 흐름에 크게 좌우됩니다.13:54

다시 말씀드리지만, 제가 모든 영상에서 말씀드리는 것처럼, 더 좋은 방법이 있을 수도 있습니다. 만약 오케스트레이터가 리드 에이전트에게 작업을 위임하는 더 효율적인 방법을 찾으셨다면, 어떤 패턴이든 발견하셨다면 댓글로 알려주세요.13:58

저도 이것이 너무 궁금해서요. 에이전트 엔지니어링 분야에서 엄청난 잠재력이 아직 개척되지 않은 영역이라고 생각합니다. 시청해 주셔서 감사합니다. 팀 에이전트를 사용해 보시고, 마음껏 활용해 보세요.14:13

이번 달 토큰을 모두 사용하시면서, 정말 강력한 내용이라는 것을 인지하시는 것이 중요합니다. 이것은 단순한 서브 에이전트나 팀을 지칭하는 용어가 아니라는 점을 분명히 말씀드리고 싶습니다. 팀은 서브 에이전트가 아닙니다.14:26

아시겠지만, 그려보면 아주 비슷해 보여요. 하지만 기존의 하위 에이전트와는 분명히 다릅니다.14:39