에이전트 코딩의 새로운 패러다임에 들어서고 있습니다. 아주 강력하지만 위험하기도 한 말트봇이나 과거의 클로드봇처럼 그런 걸 말하는 게 아닙니다. 그것에 대해서는 나중에 더 이야기하겠습니다.00:00

엔지니어가 인공지능을 통합하고 관리할 수 있도록 새로운 도구를 논하고 있습니다.00:10

새로운 클로드코드 작업 시스템이 엄청난 규모로 주목받지 못하고 있네요. 아마도 클로드봇에 대한 관심이 너무 컸던 탓일 거예요. 하지만 이 기능은 엔지니어링 업무의 미래를 엿볼 수 있게 해줍니다.00:16

제가 보여드릴 두 가지 프롬프트가 있는데, 이 새로운 클라우드 코드 작업 시스템을 기반으로 에이전트를 활용하여 기능을 확장할 수 있습니다.00:26

이건 엔지니어링 워크플로우를 상당히 크게 바꿀 수 있는 변화인데, 솔직히 주목받지 못하고 있어요. 그래서 홍보에 치중하지 않고 이 부분에 집중하고 싶어요.00:35

에이전트와 함께 할 수 있는 능력을 한층 더 끌어올릴 수 있는 메타 프롬프트와 계획 하나를 공유해 드릴게요. 클라우드 코드 인스턴스 내에서 계획을 세우겠지만, 이건 평범한 계획과는 달라요.00:44

팀과 함께 계획을 세울 건데요, 사용자 프롬프트와 오케스트레이터 프롬프트가 있어요. 제가 이것들을 훑어보면서 채워 넣을 거고, 나중에 이게 어떻게 작동하는지 설명할게요. 필요하시면 동영상 일시정지를 하셔도 괜찮아요.00:54

이 프롬프트를 실행할 거고, 이 프롬프트는 이제 에이전트 팀을 안정적이고 일관성 있게 만들 수 있다는 것을 보여줄 거예요. 더 많은 에이전트, 더 많은 자율성, 그리고 더 많은 컴퓨팅이 항상 필요하지 않아요.01:04

더 나은 결과를 얻는다는 뜻인데, 저희가 원하는 건 함께 소통하며 공동의 목표를 향해 협력할 수 있도록 체계적으로 정리된 에이전트들이에요.01:16

만약 클라우드 코드 작업 시스템을 대규모로, 안정적이고 일관성 있게 활용하여 에이전트 팀을 만들고 싶으시다면, 계속 시청하시고 바로 시작해볼게요.01:25

팀으로 구성된 계획을 한번 살펴볼까요? 지금까지 보신 프롬프트들과는 좀 다릅니다. 이 프롬프트는 세 가지 강력한 구성 요소로 이루어져 있습니다.01:34

자기 검증, 에이전트 오케스트레이션, 그리고 템플릿팅입니다. 여기서 가장 먼저 눈치채실 부분은, 프론트 매터에 후킹이 있다는 점이에요.01:42

이 에이전트는 스스로 검증합니다. 사실, 자체 작업 검증에 사용되는 특화된 스크립트들이 있습니다. 여기에서 '새 파일 검증'과 '파일 내용 검증'과 같은 것을 확인할 수 있습니다. 이 에이전트가 멈추는 후크는 이와 관련이 있습니다.01:48

실행이 완료되면, 특정 유형의 파일을 특정 디렉토리에 생성되었는지 확인하고, 특정 내용을 포함하고 있는지 확인하게 됩니다. 굉장히 강력한 기능입니다.02:03

이제 이 계획이 실제로 생성되었고, 지금 바로 확인할 수 있다는 것을 확실히 알게 됐어요. 닫으면 계획이 생성되고 검증되었고, 다음 단계는 실제로 이것을 실행하는 것입니다. 그리고 에이전트가 뭔가 정말 흥미로운 일을 했어요.02:14

여기 팀 작업 목록이 있습니다. 모든 작업에 담당자가 지정되어 있죠. 그러니까 이건 평범한 하위 에이전트 프롬프트가 아니에요. 이 작업 목록에는 특정 팀 구성원이 특정 작업을 수행하고 있습니다.02:28

계속해서, 저희는 이제부터 자세히 설명드릴 두 가지 특정 유형의 에이전트를 사용하고 있습니다. 잠시만 기다려주시면 빌더 에이전트와 검증 에이전트로 나누어 설명드릴게요. 이제 프롬프트를 시작하고, 실제로 구축을 진행하면서 스펙을 살펴보겠습니다. 이건 두 번째 프롬프트입니다.02:42

자, 이제 살펴보고, 왜 이 메타 프롬프트에서 생성된 프롬프트가 이렇게 독특한지 이해해 보도록 하겠습니다. 바로 시작해서 배경에 건물을 생성해 볼게요. 슬래시 빌드 프롬프트를 사용할 겁니다. 자, 보세요, 새 건물이 올라가고 있습니다.02:55

작업 목록이 계속 쌓여서 새로운 작업 목록을 만들고 있습니다. 또한, 이 에이전트가 이 팀을 구성하기 위해 사용하는 도구들도 살펴보겠습니다. 결과를 전달하고...03:09

보시면, 아직 다섯 개가 더 대기 중입니다. 많은 작업들이 쌓여 있고, 이제 의존성 차단 문제도 발생하고 있습니다. 에이전트가 작업을 계획하고 있습니다.03:19

팀을 구성하는 것은 작업들을 설정하고, 작업들이 어떤 순서로 진행되어야 하는지 정하는 것과도 같습니다. 여기에서 볼 수 있듯이, 저희의 처음 다섯 개에서 여섯 개 작업들은 병렬로 실행될 수 있습니다. 새로운 훅들을 개발하는 과정이죠. 명확히 말씀드리자면, 제가 레포지토리 클라우드에 가지고 있는 코드 베이스를 활용하고 있습니다.03:29

코드 훅스 숙달 관련 마지막 업데이트는 5~6개월 전이었으니, 이제 문서도 업데이트하고 코드도 약간 수정할게요. 이건 흔히 사용하는 엔지니어링 워크플로우인데, 에이전트들을 활용해서 개선하고, 기존 코드를 업데이트하는 방식이죠.03:43

변경 사항과 새로운 문서를 반영하기 위해 지금 이렇게 진행하고 있습니다. 여러 에이전트를 동시에 실행하기 시작했고, dan a4ec608은 게시 도구에 실패 훅을 추가했습니다.03:57

에러 처리 기능이 이제는 부드럽게 작동합니다. a249b56 버전에서 세션 및 훅 구현이 완료되었고, 바로 사용 준비가 되었어요. 자, 지금은 저희 서브 에이전트의 텍스트 음성 변환 응답을 듣고 계십니다.04:07

계속해서 이런 것들이 들어올 거예요. 그래서 조금 귀찮을 수도 있죠. 우리를 방해하기도 하겠지만, 완료된 각 서브 에이전트는 자신의 작업을 요약해서 알려줄 거예요.04:17

그래서 이거 서브 에이전트 스톱 훅에 내장해놨어요. A356. 세팅 훅 구현도 완료됐습니다.04:28

hook setup.py 파일이 준비됐어요. 그리고 댄, A1FA9A7이 권한 관련해서 작업해서 준비됐고, 인증 처리도 할 수 있네요. 멋지네요. 이 작업은 계속해서 들어올 겁니다.04:34

다음 중요한 부분은 물론 에이전트 오케스트레이션입니다. 여기 있는 모든 것을 합치면, 전형적인 에이전트 프롬프트 형식을 볼 수 있습니다. 목적이 있고, 변수 목록도 있습니다.04:44

프롬프트 형식과 오케스트레이션 프롬프트를 확인할 수 있습니다. 저희의 지시사항이 있습니다. 여기서 정말 흥미로운 일이 시작됩니다. 지시사항 안에 새로운 팀 오케스트레이션 블록이 추가되었습니다.04:53

자, 이제 새로운 작업 관리 도구에 대한 세부 사항을 설명하기 시작할 건데요, 작업 생성, 목록 업데이트, 그리고 이게 바로 작업 시스템이 작동하는 방식이고, 저희 주요 에이전트가 필요로 하는 모든 것이 여기에 포함되어 있습니다.05:04

이 작업을 통해 하위 에이전트 간의 통신이 작업 목록을 통해 이루어지도록 제어하고 모든 하위 에이전트를 조율하게 됩니다. 이는 임의적인 하위 에이전트를 호출하는 것에서 매우 큰 진전입니다.05:15

특정 임무는 다른 임무에 의존하지 않고, 각 에이전트에게 작업 완료 여부를 알릴 방법도 없어요. 저희는 몇 가지 세부 사항을 설명하고 있지만, 정말 중요한 건 그게 아니에요.05:27

우리 워크플로우에서, 특히 에이전트 프롬프트 형식으로 계획 수립을 위해 팀 프롬프트를 설정하는 단계를 자세히 살펴보면, 정말 흥미로운 점을 발견할 수 있습니다. 그 단계에서요.05:38

네, 4번과 5번에서는 두 가지 중요한 일을 하고 있습니다. 오케스트레이션 프롬프트를 활용하여 팀원을 정의하고, 단계별 작업들을 정의하여 계획에 팀 오케스트레이션을 적용합니다.05:47

이렇게 계획을 실제로 생성하는 주된 에이전트는 팀을 구성하고 각 팀원에게 단계별로 작업을 할당하게 됩니다. 알겠습니다, 그렇죠?06:01

이 부분이, 음, 특별한 점은 이전에는 저희가 계획을 세우고 코드를 조사하기 위해 사용했던 계획 프롬프트들이 있었는데, 그럴 때마다 어떤 에이전트가 실행될지, 어떻게 전문화할지를 정확히 지정해야 했습니다.06:10

그런 워크플로우에서 위에서부터 아래로 엄격하게 정리해야 하는 형식으로 실행되었죠. 이제 팀과 작업 목록을 통해 저희의 주요 에이전트가 어떻게06:22

개별 팀원들을 포함하는 계획을 세우는 것도 중요하고, 마지막으로 매우 중요한 부분은 이 프롬프트가 템플릿이라는 점입니다. 즉, 이 메타 프롬프트 자체가 템플릿 메타 프롬프트라는 거죠.06:33

전술적 에이전트 코딩에서 우리가 이야기하는 큰 아이디어는 에이전트가 구축하는 방법을 가르치는 것입니다. 마치 여러분에게 보여주는 것처럼요. 여기에서 계획 형식을 볼 수 있는데, 이 형식에는 실제로 포함되어 있습니다.06:45

안에 프롬프트가 들어가고, 그 안에 있는 중첩된 내용은 실제 요청으로 대체됩니다. 그래서 저희의 계획은 태스크 이름이 나오고, 생성된 계획을 바로 옆에서 확인할 수 있습니다. 스펙을 열어보면 팀 업데이트 훅이 있다는 것을 볼 수 있습니다.06:56

바로 옆에서 보면 이 템플릿이 어떻게 적용되고 있는지 정확히 알 수 있습니다.07:09

이곳이 플랜 이름이고, 여기에 작업 설명이 있습니다. 그리고 저희 에이전트가 작업 설명을 채워 넣도록 하고 있죠.07:13

그래서 이 에이전트는 우리처럼 정말로 구축하고 있는 겁니다.07:18

에이전트가 당신처럼 빌드하도록 가르치는 게 중요하죠, 그렇죠? 이게 에이전트 엔지니어링과 그냥 대충 코딩하는 것, 엉성하게 코딩하는 것과 가장 큰 차이점이에요.07:21

프롬프트를 클로데봇 같은 무작위 도구나, 아니면 어떤 도구나 에이전트에 던져서, 어떤 에이전트가 뭘 할지, 어떻게 일을 처리할지 모를 때 결과는 천차만별일 수 있습니다.07:30

원하는 대로 딱 나오지 않고, 상태도 좋지 않아서 전혀 안 되는 경우도 있어요. 모델이 발전하고 더 능숙해지면 물론 덜 노력하고 쉽게 프롬프트를 만들 수 있겠죠. 하지만 실제 엔지니어링 작업을 한다면 반대로 가고 싶어요. 결과가 어떻게 나올지 알고 싶으니까요.07:41

당신이 에이전트가 당신을 위해 생성하는 것을 확인할 수 있고, 템플릿 프롬프트를 통해 그렇게 할 수 있습니다. 특히 템플릿 메타 프롬프트인데, 이는 매우 구체적이고 일관성 있는 형식을 갖춘 새로운 프롬프트를 생성하는 프롬프트입니다.07:55

그래서 우리는 계속 진행할 수 있습니다. 양쪽에 객관적인 내용을 확인할 수 있습니다. 문제 설명이 있는 곳에는 솔루션 접근 방식이 있습니다.08:06

그래서 계속 그렇게 진행되지만 흥미로운 부분은 여기부터입니다. 팀 조정이 있다는 것이죠. 이걸 검색하면 제가 확실히 팀 조정이 생성된 프롬프트 안에 있을 거라고 장담할 수 있습니다. 왜냐하면...08:15

여기서 위로 스크롤하면 이 정지 훅이 자체 검증을 실행했고, 이걸 확인해보세요. validate file contains를 실행해서 사양 디렉터리에 들어가 있는지 확인하고 있습니다.08:28

물론 여기 있잖아요. 마크다운 파일이고, 이 하위 항목들을 포함하고 있어요. 생성된 파일에 정확한 섹션이 있는지 확실하게 확인하고 있죠. 만약 아니라면 이 스크립트가08:38

여기 'validate file contains'는 이 플래너 에이전트를 위한 지시사항을 다시 출력할 거예요. 굉장히 강력하죠. 이전 영상에서 다뤘던 전문적인 자체 검증과 이 새로운 팀 오케스트레이션을 결합하는 방식입니다.08:49

강력한 템플릿 기능을 이용해서요, 네? 그리고 템플릿은 액티브 에이전틱 코딩에서 길게 다루는 내용인데, 에이전트가 여러분이 하는 것처럼 만들 수 있도록 가르쳐 줄 수 있기 때문이에요.09:03

하지만 이 팀 오케스트레이션 부분은 정말, 정말 강력합니다.09:14

자, 한번 살펴봅시다. 여기 보시면 이건 템플릿의 일부인데, 그냥 원본 텍스트거든요.09:17

그래서 우리 에이전트가 지시사항에 따라 그대로 복사했는데, 여기부터 에이전트가 팀원들을 만들기 시작합니다.09:23

그리고, 아시겠지만, 여기서 정말 명확하게 말씀드리기 위해, 다시 한번 말씀드리자면, 왼쪽에 템플릿 메타 프롬프트가 있고, 오른쪽에 저희 에이전트가 실행하고 아마 지금쯤 완료했을, 생성된 계획 파일이 있습니다.09:29

자, 벌써 끝났어요, 그렇죠? 두 분의 작업 시간이에요. 덕분에 병렬 설정이 완료되어서, 모든 게 이미 끝났네요. 훅이 설정 완료됐고, README 파일에 완벽한 설명서가 작성됐어요. 이걸 분해해서 강력한 프롬프트를 분석하고 나면 확인해 볼까요?09:40

팀원들, 보시면 빌더, 검증사, 빌더, 검증사, 빌더, 검증사... 계속 반복되는 거, 그렇죠?09:51

이 워크플로우에서 저는 두 가지 특정 에이전트를 사용하고 있는데, 이것이 여러분이 갖춰야 할 가장 기본적인, 최소한의 구성이라고 생각합니다. 빌더와 검증자입니다.09:56

작업을 수행하는 에이전트와 작업을 확인하는 에이전트가 있습니다. 모든 작업에 대해 컴퓨팅 자원을 두 배로 늘려서 빌드하고 검증합니다. 저희는 이걸 더 발전시켰습니다.10:07

잠시 후에 에이전트를 보여드리겠지만, 여기 프롬프트 템플릿에서 빌더를 지정하고 이름을 지정하는 것을 볼 수 있습니다.10:17

변수 채우고, 이 작업을 실행할 팀에 대한 사양을 정의하는 것, 그렇죠?10:28

그리고 단계별 작업도 있는데, 실제 워크플로우를 자세하게 설명합니다.10:35

이 부분이 바로 단계별로 진행하면서 에이전트들이 수행해야 할 작업을 처리하는 계획의 부분이에요. 그래서 이건 우리가 만들고 있는 작업 목록이에요. 명확하게 하자면, 이게 우리가 단계별로 작업하면서 만들어가는 작업 목록입니다.10:39

그리고 또 다시, 저희는 이걸 반복적으로 사용할 수 있는 프롬프트로 만들었어요. 터미널을 열어서 바로 프롬프팅하는 것보다 훨씬 더 나은 결과를 얻을 수 있잖아요.10:52

재사용 가능한 프롬프트를 만들고, 재사용 가능한 기술을 만드세요. 이 분야의 많은 엔지니어들은 이미 이것을 기본적인 개념으로 이해하고 있을 거라고 생각하지만, 더 발전시킬 수 있습니다.11:05

기억하세요, 이 메타 프롬프트는 세 가지 강력한 구성 요소를 가지고 있습니다.11:13

이건 스스로 검증하고, 팀을 구축하는 방법을 구체적으로 제시합니다. 그리고 오케스트레이션 프롬프트를 제공하면, 우리가 전달한 그 오케스트레이션 프롬프트가 플래너가 팀을 어떻게 구축할지 안내하는 데 도움을 줄 겁니다, 그렇죠?11:16

그래서 거기서 그걸 해결하는 거예요. 그리고 템플릿을 사용하기도 해요. 이건 템플릿 메타 프롬프트거든요. 굉장히 멋있어 보이는 용어일 수도 있지만, 사실 그렇게 복잡하지 않아요. 프롬프트의 핵심이 되는 프롬프트인데, 특정한 형식으로 되어 있는 거죠. 사실은 꽤 간단하지만, 정말 정말 강력해요.11:30

이건 상당히 발전된 에이전트 기반 프롬프트 엔지니어링 기술입니다. 하지만 이걸 한 번 보면, 또 이걸 활용해서 만들어보기 시작하면 자연스러워져요. 성공을 위한 재사용 가능한 공식들을 만드는 게 아주 쉬워지죠.11:44

엔지니어링 작업하면서 보시다시피, 우리를 위해 여기 지어졌고, 굉장히 큰 프롬프트입니다. 아시다시피, 아래에 검증 명령어들이 모두 있고, 여기에는 노트도 있습니다. 다시 말씀드리지만 이건 전형적인 메타 프롬프트이고, 큰 차이점은 바로 우리가 지시를 내리고 있다는 점입니다.11:55

우리가 계속 반복해서 사용하게 될 메타 프롬프트인데, 새로운 클라우드 코드 작업 시스템을 활용해서 팀을 구축하도록 지시하고 있습니다. 자, 새로운 클라우드 코드 작업 시스템은 어떻게 생겼나요? 그리고 이것이 왜 특별한 걸까요? 언급했듯이,12:09

사실 우리는 작업 목록과 개별 작업을 처리할 전담 팀을 구축하고 있습니다. 이것은 이전 세대의 할 일 목록 및 이전 세대 서브 에이전트에 비해 훨씬 더 우수합니다.12:23

작업 도구를 통해 호출하는데, 특정 순서로 실행되고 다른 작업 완료를 기다리는 작업을 설정할 수 있습니다. 그리고 그뿐만 아니라, 이는 대규모 작업 관리를 가능하게 해줍니다.12:36

주요 에이전트가 방대한 작업 목록을 관리하고 시작할 수 있기 때문에, 하위 에이전트들이 완료되면 특정 이벤트를 받아 더 긴 작업 흐름을 유지할 수 있습니다.12:47

작업이 완료되면, 작업 결과 알림을 주요 에이전트로 다시 보내고, 주요 에이전트는 실시간으로 이에 반응할 수 있습니다. 더 이상 bash sleep 루프를 사용할 필요가 없어요.12:58

이제 작업 시스템에 대해 이야기해보면, 작업 시스템의 주요 기능은 무엇일까요? 주요 기능들을 한번 살펴보겠습니다. 작업 생성 기능이 있고,13:10

우리가 해야 할 작업은 작업 목록을 가지고, 작업 업데이트를 하는 것입니다. 작업 업데이트가 당연히 가장 중요한 부분이죠. 작업을 생성한 다음에 추가적인 세부사항으로 업데이트할 수 있는데, 이게 아주 강력한 기능입니다.13:19

귀하의 주요 에이전트와 하위 에이전트들은 이 도구들을 사용하여 서로 소통할 수 있습니다. 지금 이 네 가지 도구를 통해 무슨 일이 일어나고 있는지 보여주는 것입니다. 주요 업데이트는 이 작업이 가장 큰 부분이기 때문입니다.13:31

이렇게 하면 하위 에이전트와 주 에이전트가 업무 내용을 공유할 수 있게 되며, 이를 통해 강력한 워크플로우가 가능해집니다. 이제는 여러 명의 주 에이전트를 포함하는 멀티 에이전트 팀을 구성할 수도 있습니다.13:41

아시죠, 워크플로우가 보통 그렇죠? 큰 계획이나 작업 세트를 시작하면, 담당자들이 작업을 시작해서 완료하고, 막혀있던 작업들이 풀리면, 그 작업들을 하나씩 처리하면서 계속 진행하는 거죠.13:52

작업 목록이 완료되면 완료 메시지를 보내고, 주요 작업이 완료됨에 따라 주 담당자들이 알림을 받게 됩니다. 원하는 만큼 에이전트를 실행할 수 있습니다. 그리고 이 모습이 2주 전에 이야기했던 에이전트 스레드와 상당히 유사해 보이는 것을 주목해 주세요.14:06

스레드 기반 엔지니어링은 업무가 어떻게 완료되는지를 생각하는 강력한 사고방식입니다.14:20

그리고 여기에서 여러 에이전트 작업 시스템을 통해 그 점을 확인하고 있습니다. 다시 한번 말씀드리지만, 에이전트에 프롬프트를 전달하면 에이전트는 큰 작업 목록을 생성하고, 에이전트 팀이나 하위 에이전트들이 작업을 완료합니다.14:25

주문하고, 검토하고, 서로의 업무를 확인하는 거죠. 적절한 검토 에이전트를 설정하면, 다음 작업을 풀어주고, 이런 식으로 계속 진행됩니다.14:37

맞아요. 작업이 완료되면 에이전트끼리 소통하고, 작업 목록 시스템이 에이전트에게 다시 알려주고, 에이전트가 작업 완료 후 여러분께 응답하게 됩니다. 이게 강력한 작업 목록 시스템의 핵심입니다.14:44

시스템이 되고, 이걸 배포하고 재사용 가능한 프롬프트로 만들어서 계속 반복해서 사용할 수 있게 되면 훨씬 더 강력해지죠. 자, 우리 에이전트는 대체 뭘 해줬냐면, 추가하고 업데이트를 해줬습니다.14:54

이 코드베이스의 문서를 한번 살펴봅시다. 터미널을 열어서 GS를 실행하면 변경된 파일들을 확인할 수 있습니다.15:05

새로운 상태 메시지들이 많이 추가된 것을 볼 수 있습니다. 전에 없었던 새로운 훅들이 추가되었고, README 파일도 업데이트되었고, 새로운 스펙도 있고, 새로운 JSON 파일도 있습니다.15:12

자, 이 부분만 비교해 보면 새로운 훅들이 보이는데, 세션 종료, 권한 요청, 서브 에이전트 시작, 설정, 그리고 여러 개의 새로운 훅들이 있고, 각각의 훅마다 별도의 로그 파일이 있어야 합니다.15:21

그러니까 이 프롬프트를 열어서, 두 에이전트가 어떻게 함께 작동하는지 이해하는 데 집중해 주세요.15:31

우리가 계획 담당 에이전트에게 팀을 만들게 했어요, 알겠죠? 그리고 왜 이게 다르고 강력한가요? 왜냐하면, 하나의 일을 정말 훌륭하게 해내는 특화된 에이전트들을 만들 수 있기 때문이죠.15:37

자, 여기 팀원들을 보면, 그 메모는 어디 있었지, 에이전트 슬래시, 아, 여기 있네.15:48

팀원들은요, 여기 변수가 있는데, 워크플로우 안에 자세히 적어두는 겁니다.15:53

그리고 네 번째 단계에서, 이렇게 정확하게 말합니다. 오케스트레이션 프롬프트를 사용하여 팀 구성을 안내하고, .cloud, 에이전트, 팀, 마크다운에서 식별합니다.15:59

그래서 특정 디렉터리에 있는 에이전트만 보고 있거나, 일반적인 용도의 에이전트를 사용하고 있는 거죠.16:08

그래서 이 디렉터리, `.cloud`, `agents`, `team`을 열어보면, 두 명의 팀원이 있네요, 그렇죠?16:13

이 코드 베이스에서 접근할 수 있는 두 가지 특정 유형의 에이전트가 있습니다. 빌더와 검증 에이전트가 있습니다. 빌더의 목적은 단 하나의 작업에 집중해서 그것을 만들고 작업 결과를 보고하는 것입니다.16:20

하지만 저희 빌더는 좀 더 나아갑니다. 이전 영상에서 이 점을 다뤘었는데, 계속 언급하는 게 중요해요. 이제 여러분의 모든 에이전트에 특화된 자체 검증 기능을 넣을 수 있습니다.16:31

여기서 제 빌더 에이전트가 실행된 후의 모습을 볼 수 있습니다. 도구 사용 후에, 바로 확인해서 파이썬 파일에서 실행되고 있는지 확인합니다.16:42

그리고 러프앤타이를 실행합니다. 기본적으로 자체 코드 체커를 실행하는 거죠.16:49

이러한 검증은 원하시는 어떤 종류의 코딩 검증이라도 될 수 있습니다.16:55

여기서 중요한 건, 빌더 자체적으로 마이크로 스텝의 검증 단계를 내장해 놓았다는 점이에요. 그리고 그 위에 더 높은 수준의 검증 에이전트가 있어서, 작업이 제대로 완료되었는지 확인하는 역할을 하죠.16:59

작업자가 실제로 작업을 완료했는지 확인하기 위해 코드가 완전하게 작성되었는지, 그리고 필요한 검증을 모두 수행할 수 있는지 확인하세요.17:10

음, 저는 이런 두 에이전트 페어링 방식이 정말 마음에 들어요. 기본적으로 컴퓨팅 자원을 늘려서 작업이 제대로 수행되었는지 신뢰도를 높이는 거죠.17:18

특정 유형의 검증이 있다면, 빌더가 작업을 제대로 수행했는지 확인할 수 있는 특화된 도구들을 만들어서 제공할 수도 있을 겁니다. 아마 이 정도 조합이 가장 간단하게 만들 수 있는 팀 구성이 아닐까요?17:25

물론 다른 것도 있죠, 예를 들어 QA 테스터 에이전트, 검수 에이전트, 배포 에이전트, 로그 모니터링 에이전트 같은 것들요. 다양한 종류의 에이전트 팀을 만들 수 있어요.17:37

하지만, 이게 가장 기본적인 두 가지라고 생각해요. 한 에이전트가 무언가를 만들고, 다른 에이전트가 그걸 검증하는 거죠. 아주 강력하죠. 템플릿 메타프롬프트로 계획 작업을 하던 주요 에이전트가 실제로 팀을 구성할 때 이걸 사용했어요.17:45

아시죠, 정말 명확하게 말씀드리면, 여기 팀 오케스트레이션 검색을 해보면 우리 팀 멤버들을 확인할 수 있습니다. 그런데 보시다시피, 이 에이전트들 모두가 고유했습니다. 그래서 이 세션과 훅을 위한 세션 빌더를 만들었고, 그에 대응하는 검증기도 만들었어요.17:59

권한 요청 빌더와 권한 요청 검증기도 마찬가지예요. 좋습니다. 여기서 정말 강력해지는 거죠. 단계별 작업으로 이 부분을 보면 빌드 워크플로우가 있다는 것을 확인할 수 있습니다.18:12

그래서 계속 만들고, 만들고, 만들고, 만들고, 만들었어요. 그리고 여섯 번째 이후에는 어떻게 될까요? 검증러들이 나타납니다. 코드를 컴파일해서 제대로 되는지 확인하는 거죠.18:22

그리고 여기 아래에 추가적인 검증 단계를 거치게 됩니다. 돌이켜보면, 이 부분에서 놓친 기회가 있었네요.18:30

제가 claw-p를 검색하면, 모든 검증 에이전트가 그 프롬프트를 실행시켜 올바른 반응을 유도하는 명령을 바로 실행할 수 있는 큰 기회가 생깁니다.18:37

여기서 볼 수 있듯이, 로그들이 logs 슬래시 안에 모두 생성되었는지 확인해야 합니다. 에이전트들이 이 로그 파일을 검증하는 더 촘촘한 폐쇄 루프를 만들 수도 있었죠. 저희는 이 새로운 방법들 각각에 대한 모든 로그를 가지고 있습니다.18:47

자, 새로 추가된 것 중에 '세션 종료'를 검색하면, 여기 세션 종료 파일이 나타날 거예요.19:01

네, 세션 종료입니다. 그리고 이제 이전에는 없었던 새로운 로그 파일들이 생겼네요, 그렇죠? 권한 요청 관련 로그도 있고, 제가 아직 많이 사용해 보지 못한 새로운 로그 중에는 '도구 사용 실패' 관련 로그도 있습니다.19:06

거기 로그 파일이 보이시는 것 같네요. 아주 좋네요. 그리고 나서 여기 15단계, 16단계에서 README 파일을 업데이트할 거예요. 물론 간단한 검증은 여기에서 빠르게 확인할 수 있죠. 열어서 한번 검색해볼 수도 있고.19:17

이전에 기록되지 않았던 이런 도구들을 검색하면, 예를 들어 'post tool'을 검색하면, 기존 문서를 모두 편집했다는 걸 확인할 수 있습니다. 파일 경로를 얻기 위해 gdf(get diff)를 사용하면 더욱 빠르게 전체 변경 사항을 확인할 수 있습니다.19:28

새로운 상태 메시지들이 많이 추가되었고, 파일 참조도 업데이트되었고, 이 훅에 대한 새로운 문서도 준비되었습니다.19:42

정말 멋지네요. GDF 설정 파일도 업데이트되었고요. 새로운 훅들이 추가된 걸 볼 수 있습니다. 엄청 새롭거나 그런 건 아니네요.19:49

오푸스는 여러 에이전트에 분산되어 각 작업에 하나씩 집중하여 처리할 수 있어서, 특히 이 작업은 비교적 간단하게 해결할 수 있었습니다.19:58

이 시스템의 또 다른 엄청난 가치 제안입니다. 여러분의 모든 에이전트가 하나의 작업을 매우 뛰어난 성능으로 처리할 수 있도록 집중된 컨텍스트 창을 가지고 있습니다. 이것은 저희가 에이전트 기반 코딩에서 끊임없이 이야기하는 내용입니다.20:09

이것은 여섯 번째 전술 레슨입니다. 관심 있으시면 확인해 보세요. 설명란에 링크가 있습니다. 기본적으로, 집중된 컨텍스트 창으로 한 가지 특정 작업을 수행하는 에이전트가 많을수록 좋습니다.20:19

그리고 이 멀티 에이전트 태스크 시스템은 바로 그거에 딱 맞아요. 최상위 플래너인 오케스트레이터 에이전트가 계획을 세우죠. 그 다음에는 문맥을 리프레시하고, 계획 안에 있던 작업을 수행하기 위해 새로운 에이전트로 시작하면 돼요.20:29

한번 그렇게 되면, 다중 에이전트 시스템의 작업 목록과 개별 에이전트 팀에 업무를 할당하는 것들은, 어느 정도 자동으로 해결되는 경향이 있어요.20:40

그래서, 언제 이 작업 시스템을 사용해야 할지 질문으로 이어지네요. 기본적으로 항상 사용해도 괜찮습니다. 클로드, 코드, 그리고 오퍼스 같은 모델은 큰 프롬프트를 작성하면 이러한 도구에 접근할 수 있다는 것을 알고 있습니다.20:49

그 자체만 해도 괜찮은 편이에요. 좀 더 가치 있는, 아시죠? 그런데 만약 여러분이 정말로 확장하고, 에이전트를 통해 할 수 있는 일을 크게 늘리려고 한다면, 이런 메타 프롬프트를 구축하고 싶을 거예요.21:00

프롬프트가 또 다른 프롬프트를 만들어요. 특히 에이전트 코딩의 경우, 계획하고 검토하는 두 가지 주요 제약 조건이 있어요. 만약 진정한 에이전트 엔지니어링을 한다면, 대부분의 시간을 계획하거나 검토하는 데 쓰고 있을 거예요.21:10

자, 이 프롬프트, 이 새로운 도구 세트는 계획 단계에서 정말 우리에게 도움이 됩니다. 저희는 다시 한번, 스스로 검증하는 전문 에이전트를 만들 수 있습니다.21:23

각 에이전트들이 스스로 작업 결과를 검토하고 있어요. 이거 정말 중요합니다. 제가 이전에 에이전트들이 특정 작업을 검증하도록 임베디드된 훅을 만드는 방법에 대한 영상을 채널에 링크해 놓았으니 참고해주세요.21:33

하지만 팀원이나 에이전트처럼 특정 목적을 위해 만들어진 여러분의 자원들을 활용해서, 독특한 워크플로우를 구축할 수 있는 가능성이 정말 큽니다. 즉, 실행을 고려했을 때 조합을 생각해볼 수 있다는 거죠.21:45

여러 에이전트들이 함께 작동하여 단일 에이전트보다 뛰어난 성능을 보입니다. 그래서 저희는 끊임없이 개발하고 테스트하며, 검토하고 있습니다. 문서화만을 담당하는 에이전트도 있죠.21:55

이걸 통해 또 다른 방향으로 진행할 수 있다는 걸 알 수 있습니다. 여기 보시면, 저희 검증 도구는 단순히 올바르게 만들어졌는지 확인해주는 역할을 합니다. 제대로 만들어졌으면 성공이라고 보고하고, 그렇지 않으면 실패라고 보고합니다.22:05

실패했고 괜찮습니다. 아주 강력하고 헌신적인 에이전트를 이용해서 작업을 검증하는 건데, 언급했듯이, 이 검증을 좀 더 나위 좋게 할 수도 있었을 거예요. 클라우드 대시 피를 도입했어야 했습니다.22:15

개별 검증 에이전트에 대한 메시지 대신, 그냥 각 스크립트를 파이썬으로 컴파일했어. 오푸스 정도면 충분할 것 같고. 파일을 하나라도 열어보면 로그도 있는데, 기본적으로 이전 포맷을 그대로 반영하고 복사하는 방식이야.22:26

우리가 실행하고 있는 다른 모든 훅 스크립트들로부터.22:40

네, 잠깐만 봐도 이거 맞아요. 서브 에이전트 알림도 받았고요. 다 괜찮아 보이는데, 아시겠지만 저희는 검증 부분을 좀 더 개선할 수도 있었을 거예요.22:43

그리고 이 부분이 바로 오케스트레이터 프롬프트가 훨씬 더 중요해지는 지점이에요. 팀을 세워서 계획을 진행한다면, 우리가 전달하는 프롬프트는 두 개가 있어요. 만들고 싶은 것과 실제 오케스트레이션 프롬프트, 이렇게 두 가지죠.22:52

그리고 그거 여기서 바로 가져올 수 있어요. 그냥 복사 붙여넣기 한 거고, 미리 준비해둔 거고요.23:03

그러니까 정확히 어떻게 생겼는지 보실 수 있을 거예요. 각 훅마다 에이전트 그룹을 만들고, 빌더랑 검증 담당 한 명씩 두는 거죠.23:07

좋아요, 그럼 이건 저희의 오케스트레이션 프롬프트입니다. 이 프롬프트는 저희의 메타 프롬프트 덕분에 저수준 프롬프트로 쪼개집니다.23:13

그런 다음 오케스트레이터 프롬프트에서는 에이전트가 실제로 작업을 수행하는 팀을 구성하는 방법을 안내하도록 돕고 있습니다.23:20

새롭게 떠오르는 다중 에이전트 오케스트레이션의 새로운 패러다임입니다. 이걸 반복적이고 일관성 있게, 그리고 신뢰성 있게 사용할 수 있는 방법 중 하나입니다.23:26

그리고 오케스트레이션 프롬프트를 전달할 수 있는 약간의 유연성도 제공합니다. 여기에서 다루는 핵심 아이디어는 자체 검증과 다중 에이전트 오케스트레이션입니다.23:35

다시 한번 말씀드리지만, 이건 저희가 재사용 가능한 프롬프트에 통합하고 있습니다. 많은 엔지니어들이 이 부분을 놓칠 거예요. 부디 그중에 포함되지 않으셨으면 좋겠습니다.23:45

팀 오케스트레이션을 재사용 가능한 프롬프트에 통합할 수 있습니다. 그러면 매번 그 가치를 얻게 되죠. 훌륭한 프롬프트를 구축하는 데는 한 번만 투자하면 됩니다, 그렇죠?23:51

초기 투자에 집중하는 것이 정말 중요하며, 시간을 그쪽에 더 많이 써야 합니다. 앞서 언급했듯이, 에이전트 기반 디코딩에서처럼, 코드 베이스의 에이전트 레이어를 구축해야 합니다.24:01

이제 애플리케이션 자체를 개발하지 마세요. 애플리케이션을 만들어주는 에이전트에 집중하세요.24:11

좋아요. 아주 큰, 큰, 큰 아이디어네요. 거기에 많은 가치가 담겨 있어요. 지금 우리가 보는 것들, 예를 들어 랄프 위컴 기법이나, 여러 에이전트 오케스트레이션과 관련된 모든 것들... 클라우드코 팀은 이 부분과는 거리가 멀죠.24:16

정말 꼼꼼하게 기록하고 있어서 좋긴 한데, 이 부분에 대한 설명서를 좀 더 자세하게 만들어주면 좋겠네요.24:28

이 태스크 기능은 멀티 에이전트 오케스트레이션 쪽으로 밀어주고 있어요. 처음에는 베이스 에이전트가 있고, 컨텍스트 엔지니어링과 프롬프트 엔지니어링을 통해 그걸 더 잘 활용하는 방법을 배우게 되죠.24:31

그리고 에이전트를 더 추가합니다. 정말 강력합니다. 더 많은 에이전트를 추가한 후에는 에이전트를 사용자 정의합니다. 마지막으로, 모든 에이전트를 관리하는 오케스트레이터 에이전트를 추가합니다.24:42

그리고 저희가 주요 에이전트를 바로 그런 형태로 바꾸고 있는 겁니다. 이 점을 명확히 말씀드릴게요. 고객님의 주요 에이전트는 이 작업 목록과 에이전트 팀을 활용할 때, 마치 지휘자처럼 전체를 조율하게 됩니다.24:52

자, 들어봐. 이건 단계가 있는 일이야. 에이전틱 호라이즌 안에서 우리 스스로 멀티 에이전트 오케스트레이션 시스템을 구축했어. 더 자세한 내용은 설명에 링크해 놓을 테니, 에이전틱 엔지니어링을 더 깊이 파고 싶으면 참고해. (혹은: 더 발전시켜 보고 싶으면 말이야.)25:01

이 프롬프트를 클라우드 코드 훅스 마스터리 코드 베이스에 남겨둘게요. 확인하고 싶거나, 엔지니어링을 인코딩하는 템플릿 메타 프롬프트를 어떻게 만들 수 있는지 이해하고 싶다면 아주 강력합니다. 현재 기술 업계에서 많은 과장이 있긴 하지만요.25:14

음, 많은 사람들이 엉터리 같은 방식으로 툴을 사용하고, 그냥 막 느낌대로 하는 경우가 많아요. 특히, 너무나 고차원적이고 추상적인 도구들, 예를 들면 몰트봇 같은 것들을 무턱대고 사용하는 경향이 있는데, 저는 이 도구 자체를 싫어하는 건 아니에요. 이해는 해요.25:28

왜 사람들이 너에게 그렇게 관심을 보이는지 알잖아, 정말 강력한 힘이 있는 현상이야. 이 건이 엄청나게 바이럴이 되었는데, 내가 걱정되는 건 이런 도구에만 너무 의존하면서 그 작동 원리를 제대로 이해하지 못하는 거야.25:41

지금 생각해보면, 에이전트 기반 엔지니어라면, 즉, 에이전트를 활용하고 스스로 작동하는 능숙한 시스템을 구축하는 데 익숙한 엔지니어라면요.25:51

이런 도구들 마음껏 활용해 봐. 이게 어떻게 돌아가는지 넌 알고 있잖아. 내가 걱정하는 건 다른 사람들일 뿐이지, 그렇지?26:03

진짜 무슨 일이 속에서 벌어지는지 전혀 모르겠지만, 에이전트로 빌드하는 방법을 배우려고 한다면, 핵심적인 네 가지 요소, 즉 컨텍스트, 모델, 프롬프트, 그리고 도구를 이해하는 게 전부예요.26:09

그리고 에이전트 코딩의 기본적인 원리를 활용하고, 에이전트 구축의 핵심 요소를 이해하는 것에 관한 내용입니다.26:19

그건 결국 재사용 가능한 프롬프트, 맞춤형 에이전트 구축, 그리고 AI 개발 워크플로우, 저희가 기술 업계에서 ADW라고 부르는 것들을 의미합니다. 핵심은 무엇을 해야 하는지 정확히 알고 에이전트에게 어떻게 해야 하는지 가르치는 거죠.26:26

엔지니어들 사이에 큰 차이가 생길 거예요. 뇌를 끄고 일하는 엔지니어들과 지속적으로 배우고 에이전트 구축에 필요한 기술, 패턴, 도구를 계속 쌓아가는 엔지니어들 사이의 차이가 클 겁니다.26:40

에이전트 사용하지 말라는 뜻은 아니에요. 이 도구도 그렇고, 이와 같은 다른 도구들도 정말 굉장하다고 생각해요. 제가 말하려는 건, 에이전틱 코딩의 기본 요소들과 레버리지를 어떻게 활용하는지 알아야 한다는 거죠.26:53

모든 것을 구성하는 기본 요소들이죠. 왜냐하면 저를 포함해서, 이 채널을 시청하는 많은 분들이 그랬듯이, 그걸 해내면 도구에서 도구로, 기능에서 기능으로 자유롭게 이동할 수 있게 될 테니까요.27:03

그리고 이 도구는 아주 좋은 예시죠. 클라우드 코드 팀에서 만든 이 시스템 말이에요. 새로운 건 아니고요, 오픈 소스 도구에서 이미 이런 기능이 있었어요. 하지만 여기서 중요한 건, 이 팀이 표준화하고 접근성을 높였다는 점입니다.27:14

가장 주목할 만한 에이전트 코딩 도구, 배우 가치가 있는 도구들을 말씀드릴 텐데요. 이 모든 기능 세트는 결국 도구와 프롬프트에 불과합니다. 따라서 클라우드 코드를 떠나서, 필요하다면 다른 도구에 통합할 수도 있습니다.27:25

다행히 우리에게는 그럴 필요가 없네요. 왜냐하면 이 시스템은 '클로' 코드로 만들어졌거든요. 이 시스템을 사용해서 특화된 에이전트 팀을 구성할 수 있어요. 강력한 메타 프롬프트와 결합하면, 프롬프트를 생성하는 것과 같은 기능도 할 수 있습니다.27:40

프롬프트를 템플릿으로 만들고, 자체 검증 기능을 에이전트 시스템에 추가하면, 이런 강력한 트렌드가 쌓이고 있습니다. 채널을 좋아하고 댓글을 달아 알고리즘에게 실제 실습 에이전트 엔지니어링에 관심이 있다는 것을 알려주세요. 제가 원해요.27:51

이것에 대해 조금 반박하고 싶지만, 지금 진행 중인 엄청난 AI 과장 광고와는 가깝게 유지하면서, 기본적인 내용에 집중해 봅시다. 에이전트의 기본을 이루는 것에 집중해 봅시다.28:05

레벨을 올리면서 우리가 이걸로 할 수 있는 것을 늘리는 거죠.28:17

좋아요. 이번 건 여기까지입니다. 매주 월요일에 어디서든 저를 찾아보세요. 집중하고 계속 발전시키세요.28:20