네, 초대해 주셔서 감사합니다. 저는 아직 미국 서부 시간대라서, 지금 아침 7시쯤 하는 것 같아요. 네, 그렇지만 클라우드 에이전트 SDK에 대해 이야기하게 되어 기쁩니다.00:21

네, 오늘 저희가 이야기할 주요 내용의 개요가 될 것 같아요. 클라우드 에이전트 SDK가 무엇인지, 그리고 왜 사용해야 하는지, 그리고 다른 에이전트 프레임워크들이 정말 많잖아요, 그런 것들에 대해 이야기할 거예요.00:35

에이전트가 무엇인가요? 에이전트 프레임워크는 또 무엇인가요? 그리고 에이전트 SDK를 사용하거나 일반적으로 에이전트를 어떻게 설계하나요?00:48

그리고 나서 제가 라이브 코딩을 진행하거나, 아니면 클로드와 함께 에이전트 프로토타입을 만들면서 라이브 코딩을 진행할 예정입니다. 시작 코드는 준비되어 있습니다.00:58

네, 전체적인 목표는, 아시겠지만, 저희는 두 시간 정도가 있고, 최대한 협력하면서 질문도 드리고 할 예정입니다.01:07

이것도 너무 미리 준비된 시연처럼 느껴지지는 않을 것 같아요. 실시간으로 함께 고민하면서 진행할 예정이고, 제가 모든 답을 바로 알지는 못할 거예요. 아마 그런 점이 괜찮을 거라고 생각합니다.01:16

에이전트 루프 내에서 구축하는 방식은 제 생각에는 정말로 저에게는 일종의 예술이나 직관이라고 느껴지는 것 같아요. 음, 그런데 시작하기 전에 궁금한 게 있어서요.01:28

저기, 혹시 클라우드 에이전트 SDK에 대해 들어보신 분이 얼마나 되는지 손을 들어주시겠습니까? 좋습니다, 네, 멋지네요. 혹시 사용해보신 분이나 시도해보신 분 계신가요? 와, 굉장하네요. 꽤 괜찮은 반응이네요.01:39

네, 그럼 에이전트에 대한 개요 설명부터 시작하겠습니다.01:54

이런 일들이 예전에 접해본 적이 있을 거라고 생각하지만, 인공지능 기능들이 어떻게 진화하고 있는지 완전히 체득하는 데는 시간이 걸리는 것 같습니다.02:00

GPT-3가 처음 나왔을 때, 그때는 단일 LLM 기능에 대한 것이었다고 생각합니다.02:14

어, 있잖아요, 이거 분류해서, 예를 들어 이런 범주 중 하나로 응답을 돌려줄 수 있어요? 하고 물어보시는 거잖아요. 그리고 나서 좀 더 워크플로우 같은 기능들도 있죠?02:21

혹시 이 이메일을 만들어주고 라벨도 붙여주시겠어요? 아니면, 여기 제 코드 베이스가 있는데, RAG에 사용할 인덱싱도 해주시겠어요?02:30

다음 완성을 가져다 주시거나, 편집할 다음 파일을 주실 수 있나요? 바로 그거를 저희는 워크플로우라고 부릅니다. 아주 구조화되어 있는 방식이죠.02:37

음, 안녕하세요. 주어진 코드를 보고 코드를 다시 내놓으라고 할 때, 이제 에이전트에 대해서 이야기하고 있는데, 표준 에이전트는 '코드'라고 불린답니다.02:47

클라우드 코드는 저희가 무엇을 할 수 있는지 제한하지 않는 도구입니다. 사실, 텍스트로 소통하시면, 그에 맞춰 응답을 해줄 뿐입니다.03:00

다양한 행동들을 가능하게 하고, 따라서 에이전트들은 스스로 맥락을 결정하고, 자신의 경로를 스스로 설정하며, 매우, 매우 자율적으로 움직입니다.03:11

네, 그렇습니다. 앞으로 점점 더 많은 경제학자들이 에이전트로 활동할 거라고 생각합니다. 지금이 저희가 훌륭한 시점에 있다고 여겨집니다.03:21

이런 에이전트를 만들 수 있는 시기가 시작되었어요. 아직 완벽하지는 않지만, 분명히 시작하기에 좋은 시기인 것 같아요. 네, 클라우드 코드는 아마 많은 분들이03:34

사용해 보셨거나 사용하고 계실 거예요. 네, 제가 인공지능이 10분, 20분, 30분 동안 일하는 모습을 처음 봤던 첫 번째 진정한 에이전트라고 생각해요. 네.03:44

이것은 코딩 에이전트이며, 클라우드 에이전트 SDK는 실제로는 클라우드 코드를 기반으로 구축되었습니다. 그렇게 한 이유는 기본적으로 저희가 발견한 바로는…03:58

Anthropic에서 에이전트를 개발하면서, 같은 부분들을 계속해서 다시 만들고 또 다시 만들었습니다. 어떤 모습이었을지 감을 잡으실 수 있도록 말씀드리면, 우선 모델이 가장 기본이 되고요. 그리고 하니스(harness) 안에는 도구들이 있습니다.04:13

네, 맞습니다. 마치 첫 번째 분명한 단계처럼, 이 하니스에 몇 가지 도구를 추가해 보겠습니다. 나중에 처음부터 하니스를 직접 구축하는 예시와 그것이 어떻게 보이는지, 그리고 어떻게 하는지에 대해서도 보여드리겠습니다.04:28

어렵게 느껴질 수도 있지만, 도구들은 사용자 정의 도구들처럼 항상 같은 것은 아니고, 파일 시스템을 추적하는 도구일 수도 있습니다. 예를 들어, 플롯 코드를 사용했을 때, 볼륨이 증가했는지, 아니면 충분히 밀어 넣지 않았던 것인지 확인하는 것과 같은 상황이 있을 수 있습니다.04:41

음, 아무튼 도구들이 있습니다. 도구들은 루프 안에서 실행되고, 그런 다음에 프롬프트들이 있죠. 핵심 에이전트 프롬프트 같은 것들, 그리고 그런 것들을 위한 프롬프트들 말이죠.04:55

드디어 파일 시스템이 제대로 작동하는군요, 혹은 아닐 수도 있지만요. 어쨌든 파일 시스템은 컨텍스트 엔지니어링의 한 방법이고, 이에 대해서는 더 자세히 이야기하겠습니다.05:07

나중에 말씀드리겠습니다만, 저희가 클라우드 코드를 통해 얻은 핵심적인 통찰 중 하나는 프롬프트뿐만 아니라, 도구, 파일, 그리고 사용 가능한 스크립트들을 포함한 맥락 전체를 고려해야 한다는 점이었습니다.05:19

최근에 출시한 기능들에 대한 내용입니다. 혹시 기능에 대해 더 자세히 설명해 드릴까요? 관심 있으시면 언제든지 말씀해주세요. 그리고 구독 관련해서는...05:32

에이전트 웹 검색을 아시죠, 연구하고, 마치 기억을 압축하는 훅(hook) 같은 것들이 있습니다. 그리고 하니스 주변에도 여러 다른 것들이 존재하고, 결국에는…05:42

굉장히 많은 것들을 담아서 클라우드 에이전트 SDK가 패키지로 제공되고 있습니다. 사용하시기 편하도록 묶여 있습니다.05:55

네, 그리고 앱은 이미 준비되셨고요. 음, 혹시 클라우드 에이전트 SDK가 왜 이렇게 만들어졌는지, 대략적으로나마 설명드리기 위해서, 이렇게 말씀드리는 거예요.06:02

네, 음, 그런데, 네, 벌써 SDK를 이용해서 에이전트를 개발하시는 분들이 계십니다.06:21

알고 계신 소프트웨어 에이전트 같은 것들, 소프트웨어 신뢰성, 보안을 포함해서, 문제 분류, 버그 찾기, 그리고 웹사이트나 대시보드 제작 도구 같은 것들은 굉장히 인기가 많습니다.06:25

만약 사용하시고 계시다면, SDK를 꼭 사용하시는 것이 좋습니다. 그리고 사무실 담당자분들께서 사무 업무를 처리하신다면, 관련 예시가 정말 많이 준비되어 있습니다.06:36

법률, 금융, 의료 관련 자료들이 좀 있습니다.06:44

네, 그렇습니다. 정말 많은 분들이 그것을 기반으로 개발하고 계시고요. 좋습니다, 그럼 클라우드 에이전트 SDK는 왜 만들었냐는 질문에 답을 드리겠습니다. 왜 저희가 그걸 만들었는지 말씀드리죠.06:48

이렇게 보니 왜 클라우드 코드를 기반으로 구축했는지 알 것 같습니다. 저희가 클라우드 코드를 공개한 즉시 엔지니어들이 사용하기 시작했고, 이어서 재무팀 사람들과 데이터 과학자들도 사용하기 시작했습니다.07:00

그래서 그걸 사용하더니 마케팅 담당자들이 그걸 사용하기 시작했고, 네, 저희는 사람들이 클라우드 코드를 코딩 작업이 아닌 다른 용도로 사용하고 있다는 걸 알게 되었고, 저희도 코딩 작업을 하지 않고 에이전트를 구축하면서 그런 느낌을 받았습니다.07:12

계속해서 그 부분으로 돌아가게 되었습니다. 그리고 말씀드리지만, 왜 그런 방식이 효과적인지, 그리고 코딩이 아닌 작업에도 클라우드 코드를 사용할 수 있는지에 대해서는 좀 더 자세히 말씀드리겠습니다. 스포일러 경고입니다.07:27

이것은 bash 도구와 비슷한데, 네, 그렇죠. 저희가 시급하게 다뤄야 할 필요하다고 판단했던 패턴이었고, 저희 에이전트들을 그 기반 위에 구축했죠?07:39

그리고 이것은 우리가 클라우드 코드를 배포하면서 얻은 교훈들인데, 저희가 어느 정도 반영해 놓았습니다. 도구 사용 오류나 콤팩팅 같은 문제들도요.07:51

최적의 방법들을 찾기 위해서는 많은 시행착오와 규모를 키워야 하는데, 그걸 저희는 Cloud Agent SDK에 이미 반영해 놓았습니다. 그래서, 에이전트 구축하는 가장 좋은 방법에 대해 저희가 강력한 의견을 많이 가지고 있습니다.08:00

음, 클라우드 에이전트 SDK는 꽤 의견이 강하다고 생각해요. 제가 그 의견들 중 일부와 왜 그렇게 선택했는지 말씀드릴게요. 그런데 네, 큰 의견 중 하나는 Bash 툴, 가장 강력한 에이전트 툴이죠.08:13

그래서, 음, 제가 뭐라고 묘사할 수 있을지, 안트롭틱에서 에이전트를 만드는 방식이죠, 네? 이 방식으로 에이전트를 만들 수 있는 유일한 방법이라고 말하는 건 아니에요, 네?08:26

하지만 저희의 권장 스택을 에이전트 SDK에서 사용하신다면, 그게 어떤 건지에 대해 궁금하실 수 있겠죠?08:36

음, 대략적으로 bash나 파일 시스템과 같은 Unix 기본 기능들을 다루고, 클라우드 코드를 활용하여 에이전트를 프로토타이핑하는 것에 대해 말씀드리겠습니다. 제 목표는 정말…08:42

제가 그게 실제로 어떻게 보이는지 보여드릴게요. 예를 들어서, 왜 bash가 유용한지, 파일 시스템이 유용한지, 그냥 도구만 사용하지 않는 이유가 뭔지 설명드릴 수 있습니다. 물론 에이전트들도 워크플로우를 만들 수 있습니다. 나중에 좀 더 자세히 말씀드리겠습니다. 에이전트들은 스스로 구조를 만듭니다.08:53

문맥을 생각해보면, 코딩을 모르는 사람들을 위한 코드 생성도 가능할 것 같습니다. 현재도 코드를 활용해서 문서 생성이나 웹 검색, 데이터 분석, 비정형적인 작업 등을 수행하잖아요. 앞으로는 코딩을 못하는 사람들도 코드를 통해 이러한 작업을 할 수 있게 될 수 있겠네요.09:08

음, 많은 분들이 직관적으로 이해하기 어려워하실 수 있는 내용이 꽤 있습니다. 다시 한번 말씀드리지만, 프로토타입 세션에서 코딩이 불가능한 에이전트를 위해 코드 생성을 어떻게 활용하는지 설명해 드리겠습니다.09:21

네, 그리고 모든 에이전트는 컨테이너를 사용하거나 로컬에서 호스팅되는데, 왜냐하면 이것은 클라우드 코드이고 파일 시스템이 필요하고, bash가 필요하고, 그리고 그것을 조작할 수 있어야 하기 때문입니다. 그래서 매우 매우 다른 아키텍처입니다. 오늘 아키텍처에 대해 너무 자세히 말씀드리지는 않겠지만요.09:33

음, 결국 사람들의 관심사가 된다면 그렇게 할 수도 있습니다. 죄송하지만, 건축이라고 말씀드리는 것은 호스팅 아키텍처를 의미합니다. 즉, 에이전트를 어떻게 호스팅하는지에 대한 방식이죠.09:48

네, 거기에서 가장 좋은 방법은 무엇인가요? 그 부분은 마무리할 때 말씀해주셨죠, 네. 음, 잠시 멈추겠습니다. 이미 많은 내용을 다룬 것 같아서요.09:56

지금까지 에이전트 SDK나 에이전트에 대해 궁금한 점 있으세요? 네, 뭐 얻어갈 수 있는 것들에 대해서요.10:07

코딩을 못하는 사람들을 위한 코드 생성 기능이 정확히 무엇을 의미하는지 설명해 주실 수 있나요?10:14

네, 기본적으로 CloudCode에게 어떤 작업을 요청할 때와 비슷한 상황이라고 할 수 있습니다, 맞죠? 예를 들어, 어떤 작업을 요청한다고 해 봅시다.10:19

샌프란시스코 날씨를 알아봐 주시고, 어떤 옷을 입어야 할지 알려주시면 좋겠습니다.10:29

어쩌면 이 코드는 날씨 API를 가져오는 스크립트를 작성하기 시작할 수도 있고, 재사용 가능하도록 만들려고 할 수도 있습니다. 아마 자주 사용하려는 목적일 수도 있겠네요.10:38

네, 그러면 날씨 API를 호출해서, 혹시 IP 주소를 기반으로 현재 위치를 동적으로 알아내서, 날씨를 확인해 볼 수도 있겠네요.10:51

그리고 나서 아마 서브 에이전트에게 추천을 받으시는 식으로 전화를 해보시거나, 아니면 옷장이나 옷장에 대한 API가 있을 수도 있죠. 예를 들어, 그렇게 생각하시면 되는 것 같아요.11:05

개별적인 예시를 하나씩 살펴보면서 CodeGen을 어떻게 활용하실 수 있는지에 대해 이야기해 볼 수 있습니다.11:19

많은 부분이 API를 조합하는 방식으로, 높은 수준에서 하는 일이에요. 네.11:23

네, 네. 워크플로우와 에이전트, 예를 들어 반복적인 작업이나, 아시겠지만 항상 동일한 비즈니스 프로세스 같은 경우, 여전히 에이전트 구축을 워크플로우보다 선호하시나요?11:29

네, 그렇습니다. 음, 확실히 그렇습니다. 질문이 워크플로우와 에이전트의 차이에 대한 것이었는데, 여전히 클라우드 에이전트 SDK를 사용하시겠습니까?11:43

맞습니다, 그렇죠? 네, 그리고 제가 말씀드리고 싶은 건, 저희가 내부적으로 하는 일을 간단히 설명드리는 것입니다. 저희는 내부적으로, 저희가 수행하는 일들을 말씀드리고 있습니다.11:55

클라우드 에이전트 SDK를 기반으로 깃허브 자동화나 슬랙 자동화 같은 것들을 많이 만들었는데요. 이슈가 들어올 때 자동으로 분류하는 봇도 있고요. 꽤 괜찮은 워크플로우라고 생각합니다. 하지만 아직도... (문맥에 따라 뒷부분을 이어갈 수 있습니다.)12:07

문제 해결 우선순위를 정하기 위해 코드를 복제하고, 경우에 따라 도커 컨테이너를 실행해서 테스트하는 등의 작업이 필요합니다. 따라서 아직도 상당히 복잡한 과정을 거치게 되어서, 중간에 많은 단계들이 필요합니다.12:18

흐름이 꽤 자유로운 편이고, 마지막에는 구조화된 결과물을 제공하는 방식으로 진행되죠. 네, 좋습니다. 질문 하나 더 받고 계속 진행하겠습니다.12:31

네, 음, 파란색 부분에서요. 네, 혹시 보안 및 안전 장치에 대해 말씀해 주실 수 있을까요?12:40

음, 아시다시피, 클라우드 에이전트 SDK를 사용하고 있고, 또, 혹시 Bash를 일종의 만능 도구로 사용하시려는 경향이 있다면, 에이전트 빌더를 구축할 때, 음, 알아서 잘 해주셔야 하는 책임이 있는지 궁금합니다.12:44

일반적인 공격 경로에 대해 방어하고 계신가요, 아니면 모델이 그런 역할을 수행하는 건가요?12:57

네, 음, 제가 생각하기에는 이것이 마치 스위스 수장과 비슷한 것 같네요. 네, 알겠습니다. 질문은 bash 도구의 권한에 대한 것이었죠. 아니면, 권한과 안전장치에 대해 어떻게 생각하시는지, 그리고 에이전트에게 이 정도의 권한을 부여할 때 어떤 점을 고려해야 하는지에 대한 질문이었던 것 같습니다.13:03

알겠습니다, 컴퓨터의 논리 구조를 어떻게 하면 제대로 맞추는지에 대한 질문이시군요. 저희는 이 문제를 '스위스 치즈 방어'라고 부르며 생각합니다. 즉, 각 층마다 여러 가지 방어 장치가 마련되어 있는 방식입니다.13:18

함께 이렇게 하면 모든 것을 정렬하는 데 도움이 될 것이라고 생각합니다. 모델 계층에서 많은 정렬 작업을 수행하며, 저희는 최근에 매우13:32

보상 해킹에 관한 좋은 논문이 있는데, 정말 추천해 드립니다. 꼭 확인해 보시길 바랍니다. 음, 확실히 클로 모델은 저희가 매우, 매우 일치시키려고 노력하고 있습니다.13:42

네, 그렇습니다. 모델 정렬 동작이 있고, 또 하니스가 있죠. 그래서 권한 설정 및 프롬프트에 관한 사항들이 상당히 많습니다.13:51

우리가 bash 툴에 AST 경로 파서를 적용하는 것처럼, 예를 들어서, 실제로 bash 툴이 무엇을 하고 있는지 상당히 정확하게 파악할 수 있습니다. 그리고 절대 직접 만들고 싶지 않은 코드이기도 하고요. 마지막 레이어는요.14:04

샌드박싱을 이렇게 해두면, 예를 들어 악의적으로 에이전트를 탈취당했다고 가정했을 때, 실제로 어떤 일이 발생할 수 있을까요?14:18

파일 시스템 외부에서 네트워크 요청 및 파일 시스템 연산들을 테스트해 볼 수 있는 샌드박스를 포함했습니다.14:25

네, 그렇습니다. 결국 그들이 치명적인 '삼위일체'라고 부르는 건, 환경에서 코드를 실행하고, 파일 시스템을 변경하고, 코드를 유출할 수 있는 능력이라고 하는 거죠.14:35

제가 말씀드린 삼박자가 정확하지 않은 것 같습니다만, 기본적으로 말씀드리고 싶은 부분은 만약 그들이 정보를 빼낼 수 있다면, 여전히 정보를 추출할 수 있어야 한다는 점입니다. 그렇기에, 격리 환경을 구축한다면…14:48

네트워크를 활용하는 것은, 특히 Cloudflare, Modal, E2B, Daytona와 같은 샌드박스 컨테이너 환경에서 호스팅을 할 때 좋은 방법입니다. 이들 샌드박스 제공 업체들은 보안 측면에서도 어느 정도 수준의 조치를 취했습니다.15:01

개인 컴퓨터나 제품의 중요한 정보가 담긴 컴퓨터에 호스팅하는 것이 아니기 때문에 여러 보안 계층이 적용되어 있습니다. 네, 호스팅에 대해 좀 더 자세히 이야기할 수 있습니다. 네, 좋습니다. 그래서 제가…15:15

음, Bash is All You Need에 대해서 조금 이야기해 볼까 합니다. 아, 이런 건 제 트렌드라고 할 수 있죠. 저는 그냥… 그렇게 말씀드릴 것 같습니다.15:27

제가 말씀드리는 내용에 모두가 동의할 때까지 계속 이야기해야 할 것 같아요. 아니면 제가 여기 와서 발견한 것처럼 뭔가 있는 것 같아요.15:40

Bash가 Kotb를 정말 좋게 만들어주는 거죠?15:51

음, 여러분께서 아마 보셨을 텐데, 코드 모드나 프로그래밍 도구 같은 걸 사용해서 MCP를 구성하는 다양한 방식이 있죠. Cloudflare에서도 관련 블로그 게시물을 올렸었고, 저희도 그런 게시물을 올렸습니다.15:54

코딩 모드를 생각해보면, Bash이 처음 코딩 모드였던 것 같아요.16:08

음, bash 도구는 여러분이 결과를 파일에 저장하거나, 메모리를 동적으로 할당하여 스크립트를 생성하고 실행할 수 있도록 지원합니다. 또한 tail 그래프와 같은 기능들을 활용하여 FM peg와 같은 기존 소프트웨어를 사용할 수 있습니다.16:14

자, 리브레오피스는 굉장히 흥미롭고 강력한 기능들을 많이 가지고 있는데, bash 툴로 할 수 있는 것들이 정말 많습니다. 예를 들어, 클라우드 코드가 좋았던 점을 다시 한번 생각해 보면, 에이전트 하니스를 설계하신다면 아마 어떻게 하실지 궁금하네요.16:29

만약 검색 도구와 린트 도구, 그리고 실행 도구와 같은, 마치 모든 사용 사례를 떠올릴 때마다 새로운 도구를 필요로 하는 상황이 발생한다면, 클라우드는 이런 방식과는 다릅니다.16:41

자, 그래프를 오른쪽으로, 오른쪽으로 이동시키고, 여러분의 패키지 매니저를 이용해서, npm run 처럼, test.ts나 index.ts나 어떤 것이든 실행할 수 있습니다. 맞죠? 그리고 린트(lint)도 할 수 있고, 어떻게 린트하는지 알 수 있고, 린트 명령어를 실행할 수 있죠. 만약 린트가 없다면요.16:55

음, 제가 ESLint을 설치해 드릴까요? 그러면, 처음 말씀드렸듯이 프로그래밍 도구를 호출하는, 첫 번째 코드 모드처럼 될 수 있습니다.17:09

다양하고 매우 일반적인 여러 가지 행동들을 수행할 수 있습니다. 비코딩 에이전트의 맥락에서 조금 더 이야기를 풀어보자면, 예를 들어17:19

이메일 에이전트가 있어서, 사용자가 "이번 주에 차량 공유 서비스를 얼마나 사용했는지"와 같이 문의할 때, 그걸 확인하거나 일반적으로 관련 도구가 있습니다.17:32

이 기능은 이메일함에서 바로 검색이 가능하며, '유버(Uber)나 리프트(Lyft) 검색해줘' 와 같이 검색어를 입력하면, 유버나 리프트 관련 내용을 문제없이 찾아줍니다.17:44

음, 이메일이 백 개쯤 되는 것처럼 느껴지고, 이제는 그냥 그거에 대해 생각해야 할 것 같아요. 아시겠죠? 좋은 비유를 들자면, 마치 누군가가 엄청난 양의 서류 더미를 가져다주는 상황을 상상해 보세요.17:57

안녕하세요, 이번 주에 제가 차량 공유 서비스에 얼마를 썼는지 알 수 있을까요? 제 이메일들을 한번 살펴봐 주시면 감사하겠습니다. 물론, 그렇게 하려면 굉장히 높은 정확도와 재현율이 필요할 텐데, 어렵겠죠? 네, 정말 좋은 정밀도와 재현율이 필요합니다. 예를 들어, bash를 사용한다면…18:11

Gmail 검색 스크립트가 있죠. 쿼리 함수를 입력받아서 그 쿼리 함수를 파일에 저장하거나 파이프라인으로 연결해서 사용할 수도 있습니다. 가격 같은 걸 뽑아낼 때도요.18:24

가지고 있는 가격들을 더해서 확인할 수도 있죠. 예를 들어, '제 가격을 전부 가져와서, 그런 식으로 저장해 줘'라고 할 수 있습니다.18:35

파일의 줄 번호를 먼저 확인하고, 그 다음에 각 항목이 실제로 가격인지, 어떤 것과 연관되는지 확인할 수 있도록 할 수 있습니다. bash 도구를 사용하면 작업 결과를 검증하기 위해 훨씬 더 다양한 종류의 동적인 정보를 활용할 수 있습니다.18:45

간단한 예시를 보여드리려고 하는데, 이렇게 bash 스크립트의 조합 가능성을 조금이나마 보여주는 것이 목표입니다. 잠시 멈추겠습니다.18:59

바시(bash)에 대한 질문이 더 필요하신 건지, 바시(bash) 도구가 이해가 안 되시는지, 제가 좀 더 명확하게 설명해 드릴 부분이 있는지 모르겠습니다. 네올라 모드에서 말씀드리지만, 내부적으로는19:10

저희도 그렇게 하지는 않지만, 아마 저희가 좀 더 높은 보안 수준을 유지하는 것 같습니다. 네, 맞습니다.19:26

확실하지 않지만, 아마 그렇게 할 수 있을 것 같습니다. 혹시 bash에 대해 더 궁금한 점이 있으신가요? 네, 좋습니다. 좀 더 예시를 들어 드리자면, 예를 들어 이메일 API가 있다고 가정해 보겠습니다.19:33

음, 그리고 혹시 이 부분을 살펴보고 싶으시다면, 이번 주에 저에게 이메일을 보낸 분이 누구인지 알려주실 수 있을까요? 두 개의 API가 있습니다. 하나는 받은 편지함 API이고, 다른 하나는 연락처 API입니다.19:47

이걸 배치(bash)를 통해 할 수 있는 방법 중 하나예요. 코드 생성(code gen)을 통해서도 할 수 있죠. 배치(bash)가 어느 정도 코드 생성 도구라고 할 수 있을 정도예요.19:58

그리고 네, 예를 들어서, 영상 회의 에이전트가 있다고 해 볼게요, 그렇죠? 회의 녹화본에서 발표자가 분기별 실적이라고 말하는 모든 순간을 찾아달라고 요청하고 싶을 거예요, 그렇죠?20:08

이 비디오를 ffmpeg로 잘라서 작업하실 수 있고, 이후에 jq를 사용해서 정보를 분석하실 수도 있습니다. 네, 다양한 방식으로 활용하실 수 있습니다.20:20

네, 그렇습니다. Bash를 효과적으로 활용하는 방법에 대해 말씀드리겠습니다. 워크플로우와 에이전트도 가능합니다. 빌드 워크플로우를 활용하실 수 있습니다.20:30

에이전트들은 에이전트 SDK를 통해 구현되는데, 클라우드 코드와 유사합니다. 따라서 자연어(natural language)로 소통하며 유연하게 조치를 취하고 싶을 때 에이전트를 구축하시면 됩니다.20:41

비즈니스 데이터와 소통하며, 인사이트를 얻거나, 대시보드를 확인하거나, 질문에 답변하거나, 코드를 작성하는 등 다양한 작업을 수행할 수 있는 에이전트가 필요하신가요? 그런 에이전트는 맞는 표현이고, 워크플로우는 마치… 저희가 하는 것처럼 어떤…20:55

예를 들어 깃허브 액션 같은 경우, 입력과 출력을 아주 세밀하게 정의하잖아요. 예를 들어, 풀 리퀘스트를 받아서 코드 리뷰를 해달라고 요청하는 것과 같이, 이 모든 작업은 에이전트 SDK를 사용하여 빌드할 때 활용할 수 있습니다.21:08

저희가 방금 발표한 구조화된 출력 기능을 활용하여 워크플로우를 구축하실 수 있습니다. 네, 구글 에이전트 SDK의 구조화된 출력을 사용하실 수 있습니다. 네, 둘 다 가능합니다. 지금부터 보여드리겠습니다.21:21

지금은 에이전트에 대해 주로 이야기하고 있습니다. 여기서 배우는 대부분의 내용은 워크플로우에도 적용될 수 있습니다. 네, 계속해서 진행하겠습니다.21:32

손을 들어서 얼마나 많은 분들이 이전에 에이전트 루프를 설계해 보셨는지 확인해 볼까요? 좋습니다, 네, 좋습니다. 음, 네, 메타에서 가장 중요한 것은...21:44

디자인 에이전트 루프 학습 과정에서 제가 가장 중요하다고 생각하는 건, 스크립트를 계속 반복해서 읽는 거예요. 에이전트가 실행되는 모습을 볼 때마다 스크립트를 읽으면서, '아, 얘가 지금 뭘 하고 있고, 왜 이렇게 행동하는 거지?'라고 생각하며 이해하려고 노력하는 거죠.21:58

이것을 하면서 혹시 제가 좀 도와드릴 수 있을까요? 음, 나중에 조금 그렇게 할 예정이에요. 그렇죠, 네.22:09

에이전트 루프를 구축할 예정이지만, 에이전트 루프는 크게 세 부분으로 구성됩니다.22:17

먼저 상황을 파악하는 것이 첫 번째이고, 두 번째는 행동을 취하는 것이며, 세 번째는...22:25

정상적으로 작동하는지 확인하는 것은, 에이전트를 구축하는 유일한 방법은 아니지만, 제가 생각하기에는 꽤 좋은 방법이라고 봅니다. 문맥을 수집하는 것은, 음, 아시겠지만요...22:33

시계 코드에서 필요한 파일을 잡아서 찾고 있는데, 이메일 에이전트처럼 관련 이메일을 찾는 것과 비슷하다고 할 수 있겠네요.22:46

네, 예, 음, 제가 생각하기에는 문맥을 파악하는 것이 매우 중요하다고 생각하고, 많은 분들이 이 단계를 놓치시거나, 혹은 충분히 고려하지 않는 것 같아요.22:58

이것이 매우 매우 중요할 수 있으며, 이후 행동은 어떻게 작동을 하는지, 적절한 도구들을 가지고 일을 수행할 수 있는지, 코드 생성이나 Bash 스크립트처럼 좀 더 유연하게 행동할 수 있는 방식인지 고려해야 할 것 같습니다.23:09

검증은 또 매우 중요한 단계입니다. 그래서 지금 말씀드리자면, 에이전트 구축을 고려하신다면, 그 작업의 검증 가능성을 먼저 생각해보시는 것이 좋습니다. 작업 검증이 가능하다면, 굉장히 훌륭한 결과로 이어질 수 있습니다.23:22

에이전트 후보자를 평가할 때, 그 결과물을 검증할 수 없다면, 코딩이라면 린팅을 통해 검증할 수 있고, 적어도 컴파일이 되는지 확인할 수 있겠죠. 그런 점이 좋고요. 만약 심층적인 연구를 진행한다고 가정한다면, 실제로 검증하기가 훨씬 더 어렵습니다.23:37

귀하의 작업에 있어서 한 가지 방법은 출처를 인용하는 것입니다. 그러면 이것은 검증의 한 단계가 되겠지요. 하지만 연구는 분명히 코드만큼 검증하기 어려울 수 있습니다. 왜냐하면 코드는 특성상 검증 가능성이 더 높기 때문입니다.23:51

컴파일 단계에서 바로 실행해 보실 수도 있습니다. 그러면 결과물이 어떻게 나오는지 확인하실 수 있죠. 음, 생각해보면, 에이전트를 구축할 때, 특히 일반적인 에이전트에 가까운 것들은 검증 단계가 매우 강력한 것들인 것 같습니다.24:02

네, 질문 있으셨던 것 같습니다, 그러시죠?24:16

네, 말씀하신 질문이 언제 계획을 세우고 실행하시는지에 대한 것이었죠? 마치 클로스 코드처럼 항상 계획을 세우는 건 아니거든요.24:26

계획은 필요 없지만, 원하신다면 모임의 맥락과 행동 단계 사이에 삽입하실 수도 있습니다. 계획은 에이전트가 단계별로 생각하도록 돕지만, 어느 정도 지연이 발생하죠. 따라서 어느 정도의 균형을 맞추어야 할 것 같습니다.24:39

네, 그렇습니다. 에이전트 SDK는 계획을 세우는 데도 도움을 주어서요. 네, 네. 에이전트가 할 일 목록을 만들게 하거나, 확실히 그렇게 될 수 있도록 하는 거죠.24:54

혹시 할 일 목록을 만들어서 따르실 건가요?25:09

네, 질문하신 내용은 에이전트가 할 일 목록을 생성하는지에 대한 것이었죠. 그렇습니다. NSDK를 사용하신다면, 함께 제공되는 할 일 도구들이 있어서 목록을 관리하고 완료 항목을 표시할 수 있습니다. 이벤트 발생 상황을 실시간으로 표시하는 것도 가능합니다.25:12

혹시 지금 혹시 더 궁금하신 점 있으신가요? 네, 좋습니다. 잠시만, 이것들을 어떻게 하는지 간단하게 설명드리겠습니다.25:28

어떤 도구를 사용하시는지 궁금합니다. 일반적으로 세 가지 방법을 활용하실 수 있는데, bash나 코제너레이션 같은 도구들이 있죠. 그런데 많은 분들이 전통적으로는 도구에만 집중하시는 것 같습니다.25:38

기본적으로 주요 행동 촉구 중 하나는 좀 더 폭넓게 생각해서 이를 파악하는 것입니다. 도구들은 매우 체계적이고 신뢰성이 높죠. 어떤 식으로든 정렬하고 싶다면요.25:53

가능한 한 빠르게, 그리고 최소한의 오류와 재시도로 결과를 얻을 수 있으면 좋겠습니다. 도구들은 정말 유용하지만, 활용 시 높은 맥락 의존성이 있다는 단점이 있습니다. 혹시 50개나 100개의 도구를 활용하여 에이전트를 구축해 보신 분이 계시다면요.26:03

문맥이 굉장히 많이 필요하고, 모델이 약간 혼동되는 경향이 있습니다. 그리고 도구를 쉽게 발견하기 어렵고, 조합하기도 어렵습니다.26:16

현재 메시지나 Completion API를 사용하고 계시다면, 툴(Tools)은 마치 그런 방식으로 작동한다고 이해하시면 됩니다. 물론 코드 모드나 프로그래밍 툴 호출과 같은 기능도 포함되어 있습니다.26:27

이런 것들을 섞어서 활용할 수도 있지만, bash는 굉장히 조합하기 쉽습니다. 즉, 정적인 스크립트, 낮은 맥락에서의 사용에 적합하며, 약간의 탐색 시간이 필요할 수 있습니다.26:38

예를 들어, 혹시 플레이라이트 MCP 같은 도구나 아니면 플레이라이트 CLI, 즉 플레이라이트 bash 도구가 있다고 가정해 보겠습니다. 'playwright --help' 명령어를 사용하면 어떤 기능들을 사용할 수 있는지 확인할 수 있습니다.26:51

하지만 에이전트는 매번 그 작업을 수행해야 하잖아요. 그래서 스스로 할 수 있는 것을 찾아야 하는데, 그게 꽤 강력해서 고맥락 사용을 어느 정도 줄여주지만, 약간의 지연 시간이 발생할 수 있고, 콜률이 조금 낮아질 수도 있습니다.27:04

시간이 조금 더 필요해서 도구를 찾고 무엇을 할 수 있는지 확인해야 하지만, 분명히 시간이 지나면서 많이 개선될 거라고 생각합니다.27:18

그리고 나서 CodeGen은 고도로 조합 가능하고 동적인 스크립트를 사용하는데, 실행에 가장 오래 걸립니다. 따라서 LinkedIn과의 연동이나 컴파일 API 설계가 필요할 수 있습니다.27:28

여기서 굉장히 흥미로운 단계가 되는 것 같고, 에이전트에서의 API 디자인을 어떻게 생각해야 하는지에 대해 더 자세히 말씀드리겠습니다. 네, 그렇게 생각합니다.27:40

세 가지 도구를 활용하시는 방식이 저희가 선호하는 방식과 유사하다고 생각합니다. 네, 도구를 사용하다 보면 여전히 일부 도구가 필요할 수 있지만, 이 도구들을 순차적으로 실행해야 하는 원자적인 액션으로 생각하고, 제어할 수 있는 기능이 많이 필요하다고 봅니다.27:52

예를 들어 클라우드 코드를 사용한다면, 파일을 작성하기 위해 bash를 사용하지 않습니다.28:05

파일을 쓰는 도구가 있습니다. 사용자가 결과를 보고 승인할 수 있도록 하고 싶습니다. 파일 쓰기는 다른 것들과 함께 묶어서 사용하지 않습니다.28:09

매우 원자적인 동작입니다. 이메일을 보내는 것도 좋은 예시입니다. 어떤 종류의 파괴적이거나 되돌릴 수 없는 변경 사항은 거기에 적합한 곳이 될 수 있겠네요.28:19

이어서, bash를 예로 들면, 폴더 검색, GitHub 린팅, 코드 오류 및 메모리 검사 등과 같이 조립 가능한 액션들이 있습니다.28:34

네, 그렇습니다. 파일을 메모리에 쓰고, 그 메모리를 마치 bash처럼 활용할 수 있습니다. 예를 들어 bash를 메모리 시스템으로 사용할 수도 있죠. 그리고 마지막으로, 코드를 생성하는 기능도 있습니다. 혹시 매우 역동적인 방식으로 이 작업을 진행하려고 하신다면요.28:46

데이터 분석이나 심층 연구처럼 패턴을 재사용하면서 매우 유연한 로직을 API 형태로 구성하는 방식이죠. 잠시 후에 코드 생성에 대해서도 좀 더 자세히 이야기해 보겠습니다.28:58

혹시 SDK 루프나 도구, bash, 코드 생성 관련해서 질문 있으신 분 계신가요? 네, 제가 여쭤보려고 했는데, 오프로딩 도구 파일 결과를 처리할 수 있는 바로 사용할 수 있는 도구들을 제공하실 예정인가요?29:12

도구 파일 결과를 파일 시스템으로 옮기는 것과 같은, 아니면? 예를 들어 bash로 가서 컨텍스트가 폭발하면, 모든 것을 처리하는 명령어 같은 것들을 사용하는 걸까요? 아니면 단순히 긴 출력을 기록하는 것과 같은 방식일까요?29:27

네, 네, 네, 맞아요. 파일을 업로드하는 걸 기억하고 있어요. 네, 네, 그렇게 하는 게 일반적인 방법이라고 생각해요.29:41

저도 기억하는데, 클라우드 코드에서 아주 최근에 매우 긴 출력 처리에 대한 PR들이 논의된 것을 본 것 같습니다.29:48

저도 정확히 말씀드리기는 어렵지만, 앞으로는 더 많은 정보들이 파일 시스템에 저장되는 방향으로 나아갈 것 같습니다.29:59

네, 좋은 예시라고 할 수 있겠네요. 시간이 지남에 따라 긴 결과물을 저장하는 것 같아요. 일반적으로 에이전트에게 이런 작업을 시키는 것이 좋은 방법이라고 생각합니다. 아니면, 혹시… 제가 이제 항상 하는 일이 하나 있는데, 그건…30:11

제가 도구 호출을 할 때마다, 그 결과를 파일 시스템에 저장하여 검색 기능을 활용할 수 있도록 하고, 도구 호출 결과의 경로를 반환하도록 하고 있습니다.30:26

그렇게 하는 게 도움이 되는 이유는, 스스로 작업 결과를 다시 확인하게 할 수 있어서요. 네?30:37

네, 질문은 기술에 관한 것이었고, 배쉬를 더 잘 사용하기 위해 기술이 필요한지 묻는 질문이었습니다. 맞춤법이나 배경지식을 의미하는 기술, 기술, 기술에 대해 말씀하시는 것 같습니다.30:59

기본적으로 저희 에이전트가 좀 더 복잡한 작업을 수행하고, 문맥을 통해 정보를 불러올 수 있도록 하는 방법이라고 할 수 있습니다. 예를 들어, docx 파일 여러 개가 있는 경우도 있을 수 있습니다.31:12

기술들과 이러한 docx 기술들은 코드를 생성하여 이러한 파일들을 올바르게 만들 방법을 알려줍니다. 네, 전체적으로 봤을 때 기술들은 기본적으로 파일들의 모음이라고 할 수 있습니다. 또한, 매우 파일 중심적인 예시라고 할 수 있습니다.31:26

에이전트가 CD 명령을 통해 들어가서 파일을 읽을 수 있는, 마치 폴더와 같은 존재입니다. 그렇죠. 그래서, 필요한 정보를 제공하는 역할을 한다고 보시면 됩니다.31:41

저희가 발견한 바에 따르면, 정말 유용하게 활용할 수 있는 기술들은 상당한 전문성이 요구되는 반복적인 지시사항들을 처리하는 데 적합한 것 같습니다.31:54

예를 들어, 최근에 제가 정말 마음에 들었던 프론트엔드 디자인 기술을 출시했는데, 프론트엔드 디자인을 어떻게 하는지에 대한 굉장히 상세하고 유용한 가이드라인이라고 보시면 됩니다.32:02

하지만 저희 최고의 AI 프론트엔드 엔지니어분이 만들었거든요, 무슨 말씀인지 아시죠? 그리고 그분께서 정말 많은 고민과 반복적인 작업을 거쳐서 만드셨어요. 그래서 스킬을 사용하는 한 가지 방법입니다.32:14

네, 그렇습니다.32:28

그것입니다.32:46

질문은 skill.md와 claw.md를 어떻게 생각해야 하는지에 대한 내용이었습니다. 그리고 저는 이 개념들이 완전히 새로운 것이라고 말씀드리지는 않아요. 예를 들어 clock code조차도요.32:54

거의 8, 9개월 전에 출시했고, 스킬은 2주 전에 출시됐습니다. 제가 모든 최고의 것을 다 안다고는 칭찬할 수 없을 것 같습니다.33:07

음, 모든 일에 적용할 수 있는 방법이라고 생각하는데, 일반적으로 기술은 점진적인 맥락 공개의 한 형태라고 할 수 있을 것 같아요. 그런 패턴에 대해 이야기한 적이 있었던 것 같습니다.33:16

음, 마치 bash나 그런 도구들을 이용해서, 아시다시피, 일반적인 도구 호출 방식으로, 마치 그와 같은 방식으로 하는 방법이라고 할 수 있겠네요.33:26

에이전트가 "알겠습니다, 이걸 해야겠네요. 어떻게 해야 할지 찾아보고, skill.md 파일을 읽어봐야겠어요." 라고 말하는 것 같습니다. skill.md 파일에서 docx 파일을 만들도록 요청하면, 해당 파일을 디렉터리에 저장하는 것 같네요.33:36

어떻게 하는지 읽고 스크립트도 좀 쓰고 계속 진행하는데, 음, 네, 아직 어떤 것을 정확히 기술이라고 정의할지, 그리고 어떻게 나누어볼지 감을 익혀야 할 것 같아요.33:47

네, 그렇지만 아직 배워야 할 모범 사례가 많이 있을 것 같아요. 네?34:00

그래서 어제, 이걸 모델의 일부가 되는 거고, 간극을 메우는 방법이라고 생각하시는 건가요?34:08

네, 질문의 요지는 결국 기술이 모델의 일부가 되는지에 대한 것이었습니다.34:22

혹시 그런 연결고리 역할을 할 수 있을까요? 어제 배리와 메시의 강연을 못 들었지만, 네, 대략적으로 말씀드리면 모델이 다양한 작업들을 점점 더 잘 수행하게 될 것이라는 아이디어인 것 같습니다.34:26

기술이 분포 외적인 작업들을 처리하는 가장 좋은 방법이라고 할 수 있겠네요, 그렇죠?34:38

대략적으로 말씀드리자면, 정말, 정말 어렵다고 말씀드릴 수 있을 것 같습니다. 특히, 모델들이 어디로 향하고 있는지 정확히 파악하기 위해 연구실에 계신 분이 아니라면 더욱 그렇습니다.34:43

제 일반적인 경험에 따르면, 에이전트 코드를 대략 6개월마다 다시 생각하거나 다시 작성하려고 합니다. 왜냐하면 변화가 충분히 있었을 가능성이 높아서, 이미 반영되어 있을 수 있기 때문입니다.34:56

몇 가지 가정을 바탕으로 말씀드리는데, 저희 에이전트 SDK는 최대한의 기능 향상을 목표로 개발되고 있습니다. bash 도구도 계속해서 개선될 예정입니다.35:07

더 좋게는 클라우드 코드를 기반으로 구축하고 있기 때문에, 클라우드 코드가 발전함에 따라 처음부터 그 이점을 얻으실 수 있습니다. 하지만 동시에, 요즘 환경이 많이 달라졌죠.35:18

AI 엔지니어링 측면에서 작년보다 훨씬 더 빠르게 발전하고 있습니다. 그리고 제 생각에는 일반적인 모범 사례로서, 마치 '우리는 코드를 10배 빠르게 작성할 수 있습니다. 그럼 코드를 10배 빠르게 폐기해야 합니다.' 와 같이 생각하는 것이 좋다고 봅니다.35:30

음, 지금 미래가 어디에 있는지 좀 주저하면서 생각해보지만, 오늘 당장 효과적으로 할 수 있는 일이 무엇일까 고민하고 있어요. 좀 불확실하게 이야기했나요.35:44

오늘 시장 점유율을 확보해 봅시다. 스타트업이라면 나중에 코드를 수정하거나 버리는 것을 두려워하지 마세요. 아마도 이것이 경쟁사보다 훨씬 큰 장점일 겁니다. 좀 더 큰 회사들은 보통 6개월이나 되는 검토 기간을 거치는데, 저희는 훨씬 빠르게 움직일 수 있습니다.35:55

그래서 그분들은 항상 에이전트 기능과 관련된 과거에 갇혀 있는 그런 상태인 것 같아요. 그런데 고객님의 장점은 지금 당장 에이전트 기능이 있다는 점이고, 이걸 활용해서 무언가를 만들어볼 수 있다는 거죠.36:08

네, 지금 말씀드리는데 혹시 더 궁금하신 점 있으십니까? 저희가 이야기하고 있는 내용에 대해.36:20

네, 기술 관련 질문이 많은 것 같습니다. 그렇습니다.36:30

등 뒤에 누군가를 소리치셔야 할 수도 있고, 질문이 있으신가 봅니다.36:37

왜 기술을 API와 비교하는 것이 좋을까요? 좋은 질문이라고 생각합니다. 마치 에이전트가 점진적으로 정보를 파악할 수 있도록 하는 다양한 형태의 공개 방식과 같은 것이죠.36:49

그것이 무엇을 해야 하는지 설명드리겠습니다. 예를 들어, API를 직접 구현하거나 프로토타입 세션에서 사용하실 수 있습니다. 완전히 가능합니다.37:01

상황에 따라 다를 것 같아요. 제가 생각하기에는 일반적인 규칙은 딱히 없는 것 같아요. 그냥 대본을 읽어보시고 에이전트님이 원하시는 바를 파악하시면 될 것 같습니다. 만약 에이전트님이 항상 API 관련 정보를 원하신다면요.37:13

음, 더 좋은 방법은 api.ts 파일이나 api.py 파일처럼 하는 건데요. 그게 훌륭한 방법이라고 생각해요. 실력이라는 건, 마치 파일 시스템을 컨텍스트를 저장하는 방법으로 생각하는 것에 대한 소개와 같은 거라고 할 수 있겠네요.37:25

굉장히 추상화가 잘 되어있긴 하지만, 이 시스템을 사용하는 방법은 정말 다양합니다. 말씀드리고 싶은 건, 특정 기술들이 필요하다는 점입니다. 예를 들어 bash 도구가 필요하고, 가상 파일 시스템 같은 것들이 필요하죠. 그래서 에이전트 SDK는 마치…37:38

지금은 실력을 최대한 활용할 수 있는 유일한 방법이라고 생각합니다. 네, 그렇습니다. 맞습니다.37:51

질문하신 내용이 맞습니다. 기술에 대한 마켓플레이스를 기대할 수 있는지에 대한 질문이었죠. 네, Clock Code는 플러그인 마켓플레이스를 가지고 있으며, 에이전트 SDK와 함께 사용할 수도 있습니다. 저희는 시간이 지남에 따라 이 기능을 계속 발전시켜 나갈 예정입니다.38:03

음, 상당히 V0에 가깝고, 마켓플레이스라고 하면, 정확히 요금 부과를 할지는 잘 모르겠습니다. 더 나은 발견 시스템이라고 생각하는 것이 맞을 것 같습니다. 하지만 현재는 존재합니다. 클라우드 코드를 통해 슬래시 플러그인을 사용하고 찾을 수 있습니다.38:14

네, 그렇습니다. 음, SDK를 활용해서 문제를 해결하려고 할 때, 언제 사용하는 것이 좋을지 궁금합니다. 현재 어떤 생각을 가지고 계신가요?38:29

에이전트를 구축할 때 문제가 발생한다면 SDK를 활용하여 해결할 수 있습니다. 제 생각에는 어떤 에이전트든 bash 도구는 정말 많은 도움을 준다고 믿고 있습니다.38:39

파일 시스템의 강력함과 유연성을 활용하면 정말 많은 권한과 자유를 얻을 수 있고, 이를 통해 성능 향상도 꾸준히 얻을 수 있습니다. 그리고 네, 이번 발표의 프로토타입 부분에서 이를 자세히 살펴보겠습니다.38:53

도구만 사용한 예시와 파일 시스템에서 bash를 활용한 예시를 비교해서 말씀드리고 싶습니다. 제가 말씀드리는 bashful build는, 에이전트 SDK부터 시작하는 것을 의미합니다.39:06

엔트로픽에서 많은 분들이 그렇게 시작하신 것 같습니다. 물론, 에이전트 SDK가 때로는 네트워크 샌드박스 컨테이너 때문에 다소 불편할 때가 많다는 점 말씀드리고 싶습니다.39:20

음, 마치 제가 싫어하는 것처럼, 하고 싶지 않은 것처럼 아시죠? 제 브라우저에서 로컬로 실행하고 싶은 거죠. 네, 당연히 이해합니다. 성능에 대한 분명한 절충이 있는 것 같아요. 제가 생각하는 건 마치 리액트와 jQuery를 비교하는 것과 비슷하다고 생각합니다.39:32

음, 제가 어렸을 때 웹 개발에 푹 빠져 있었거든요. jQuery나 Backbone 같은 걸 사용하고 있었는데, 그러다가 React가 나왔죠. 페이스북에서 만들었고, JSX라는 걸 써야 한다고 하더라고요. 그냥 갑자기 만들었다고 하니까 신기했고, 이제는 번들러까지 사용해야 한다니, 정말…39:46

음, 좀 귀찮은 점도 있긴 하지만, 보통 모델 자체나 웹 애플리케이션을 좀 더 강력하게 만들어 주는 역할을 하는 것 같아요. 그리고 저희는 마치 반응형 에이전트 같은 존재라고 생각합니다.40:01

저에게 프레임워크는 저희가 그 위에 직접적으로 뭔가를 구축하는 것과 같아서, 그게 진짜라는 것을 알 수 있고, 불편한 부분들 역시 저희도 마찬가지로 불편하게 느꼈던 것들이거든요. 그래도 결국은 잘 작동하는 것 같아요. 마치 꼭 그래야만 하는 것처럼요.40:12

네, 그렇게 하는 것을 아시죠, 네 네, 알겠습니다. 이제 좀 더 실력 관련된 질문들인 것 같아요. 네, 맞습니다.40:25

네, 질문은 사용자 정의 에이전트와 bash 도구를 가지고 계신 경우, 에이전트가 이를 스스로 발견하도록 허용하셨는지 여부입니다.40:39

혹시 사용자 지정 Bash 도구를 말씀하시는 건가요? 네, 네, 네… 그렇게 파일 안에 넣으시는 거라고 생각합니다.40:48

시스템에 말씀드리는 건데, 마치 '이 스크립트가 있습니다'라고 알려주는 것처럼 생각하고 있습니다. 클라우드 에이전트 SDK의 맥락에서 파일 시스템과 bash 도구가 함께 연결되어 있는 것을 고려하고 있는데, 이와 유사한 개념입니다.40:59

가끔 제가 보게 되는 패턴인데, 사람들이 '우리는 bash 도구를 이 가상화된 공간에 호스팅할 거고, 다른 에이전트 루프 부분과는 상호작용하지 않을 거예요'라고 말하는 경우를 보게 됩니다. 그런 방식은… 그렇게 하는 것이 좋지 않다고 생각합니다.41:13

알겠습니다. 파일 저장을 하는 도구 결과라면, bash 도구가 읽어들일 수 없다는 말씀이시군요. 모든 것이 하나의 컨테이너 안에 있어야 한다는 뜻이신가요? 혹시 질문에 대한 답변이 되었는지 궁금합니다. 네, 맞습니다. 말씀하시는 것이…41:25

네, 시스템 프롬프트 내에 넣어주시면 됩니다. 마치, '이 기능에 접근할 수 있는지 확인하고, 제 CLI 스크립트들을 모두 --help 옵션을 갖도록 설계하고 싶습니다. 모델이 이를 호출하여 점진적으로 하위 명령어를 공개할 수 있게끔 하는 거죠.' 정도로요.41:39

그리고 스크립트 안에서요, 네. 네, 맥레리? 네. 제 질문은 언제 에이전트 SDK를 사용해야 할지 관련해서입니다.41:54

혹시 에이전트 SDK를 활용하여 일반적인 채팅 에이전트를 구축하셨거나, 아니면 추천하시는지 궁금합니다. 저는 입력값을 받아서 에이전트가 특정 작업을 수행하도록 만들고 있는데, SDK를 사용하는 것이 다른 방식에 비해 어떤 장점이 있을까요?42:02

마지막으로 제가 궁금한 건 결과물에 대한 신경 쓰시는 정도입니다. 예를 들어, 어떤 분들은 에이전트를 활용해서 에이전트 SDK를 구축하거나, Claude the app처럼 어플리케이션을 만들 용도로 활용하실 수도 있을 텐데요. 혹시 그런 계획을 가지고 계신가요?42:16

네, 질문이 있는데요, 에이전트 SDK를 언제 사용하는 것이 좋을까요? 그렇습니다.42:29

에이전트 SDK를 이용해서 Claude.ai를 구축할 수 있을까요? Claude code보다는 좀 더 전통적인 챗봇이라고 생각하는데요.42:36

음, 저는 클로드 코드가 기존의 챗봇 인터페이스와는 조금 다른 방식인 것 같아요. 입력과 출력이 정말 자유롭고, 코드를 넣으면 코드를 보호받으면서 텍스트 결과도 얻을 수 있고, 다양한 행동을 취할 수 있거든요.42:46

클라우드 AI에 문서 생성 기능을 출시했던 것처럼, 혹시 보셨을 수도 있는데, 이제 파일 시스템을 생성하고 활용할 수 있는 기능이 추가되었습니다.43:00

스프레드시트나 파워포인트 파일 같은 것들을 코드를 생성해서 다루고 있고, 현재 저희는 에이전트 루프들을 합치는 과정에 있습니다.43:14

음, 그런 것들이 있고, 전체적으로 보면, 네, cloud.ai 가 점점 더, 실력이나 기억 저장 도구 같은 것들을 보면 알 수 있듯이, 더 많은 파일 시스템 기능을 포함하게 되는 것 같습니다, 그렇죠?43:24

네, 저희는 그것이 광범위하게 일반적으로 활용될 수 있는 개념이라고 생각하며, 예시를 통해 자세히 설명드릴 수 있습니다.43:35

네, 질문 하나만 더 드리겠습니다. 그 다음에 살펴보겠습니다, 네. 제가 아직 도구를 만들지 사용할지, 아니면 스크립트로 감싸거나 에이전트가 bash에서 자유롭게 실행하도록 할지, 언제 그런 결정을 내려야 하는지에 대한 경험 법칙을 이해하려고 노력하고 있습니다.43:43

예를 들어, 제가 가끔 데이터베이스에 접근해야 한다고 가정해 보겠습니다. MCP를 사용할 수 있고, 스크립트로 감싸서 에이전트가 그 스크립트에서 직접 엔드포인트를 호출하도록 할 수 있습니다.43:57

네, 좋은 질문입니다. 좋은 질문이시네요. 아직은 도구를 언제 사용해야 할지 이해하려고 노력하고 있는 단계입니다. 예를 들어, bash를 이용해서 어떤 코젠을 처리해야 하는데, 데이터베이스에 접근할 수 있도록 에이전트가 활용할 수 있는 방법을 제시하셨습니다.44:12

어떤 방식을 택해야 할까요? 데이터베이스를 쿼리하는 도구를 만들어야 할까요? 아니면 bash를 사용해야 할까요, 아니면 cogen을 사용해야 할까요? 이 세 가지 방법 모두 괜찮다고 생각합니다. 어떤 방법을 선택하셔도 괜찮을 것 같습니다.44:24

음, 일부는 제가 생각하기에는 안타깝게도 딱 하나에 가장 좋은 방법이라고 할 수는 없을 것 같습니다. 시스템 설계 문제의 일종이라고 할 수 있겠네요. 하지만 만약 여러분이 bash나 데이터베이스에 접근하고자 한다면, 그렇게 하실 수 있습니다.44:38

데이터베이스는 굉장히 체계적으로 구성되어 있어서, 접근할 때 매우 신중해야 합니다. 특히 사용자의 민감한 정보를 다루는 경우에는, 예를 들어 '이 입력값만 받아들여야 하고, 필요에 따라…' 와 같이 제한을 두고 접근해야 합니다.44:52

이 결과를 보여드리고, 다른 데이터베이스 정보는 에이전트에게 숨겨야 할 겁니다. 물론, 이것은 에이전트가 할 수 있는 일에 다소 제한을 두게 되겠네요.45:06

완전히 복잡한 시퀀스 쿼리를 작성해야 할 때에는 마스터 코칭을 사용하는 것을 적극적으로 추천합니다. 모델이 시퀀스 쿼리를 생성할 때 실수를 할 수 있는데, 그럴 때 마스터 코칭의 피드백을 통해 오류를 수정하는 데 매우 유용하기 때문입니다.45:16

오류를 수정하면서 반복하는 방식으로, 파일에서 오류를 찾아내는 것과 같이 린팅하거나 결과를 살펴보는 것이 가장 좋습니다. 그렇죠, 그리고45:30

오늘 에이전트를 만든다면, 제가 데이터베이스에 최대한 많은 접근 권한을 주고, 그런 다음 안전 장치를 마련하는 것 같아요.45:41

아마 접근 권한을 다양한 방식으로 제한하고 있을 거예요. 하지만 제가 할 일은 아마 접근 권한을 주고 특정 규칙을 적용하는 것일 거예요.45:51

그리고 시도해도 할 수 없는 일을 하면 피드백을 주는 거죠. 아시겠죠? 이런 문제가 해결해야 할 문제라고 생각해요. 왜냐하면 우리는 bash tool parser를 만들었거든요.46:03

그리고 그건 정말 답답한 문제이지만, 에이전트가 일반적으로 작동할 수 있도록 해결해야 합니다. 데이터베이스도 마찬가지입니다. 쿼리가 무엇을 하는지 이해하기가 상당히 어렵지만, 만약 그것을 해결한다면요.46:16

에이전트가 시간이 지남에 따라 보다 일반적으로 작업할 수 있도록 하는 것이 중요하며, 가능한 한 유연하게 접근하고, 매우 세분화된 작업 단위로 유지하는 것이 필요합니다. 이러한 세분화된 작업은 많은 보장을 필요로 합니다.46:30

어떻게 주변을 말씀하시는 건가요?46:44

질문은 역할 기반 접근 제어가 제대로 이루어지는지 확인하는 방법인데, 보통은 API 키나 백엔드 서비스를 프로비저닝하는 과정에서 처리되는 경우가 많습니다.46:55

아니면 뭐 그런 식으로요, 음, 제가 생각하기로는 아마 제가 하는 방식은 일종의 임시 API 키를 만들거나 하는 것 같아요. 가끔은 사람들이 API 키를 삽입하기 위해 중간에 프록시를 만들기도 하고요. 혹시…47:04

음, 혹시 데이터 유출이 걱정되시는군요. 그렇다면 에이전트들에게 특정 범위로 제한된 API 키를 생성하는 것을 고려해 보시는 건 어떨까요? 그렇게 하면 백엔드에서 에이전트가 무엇을 하려고 하는지 어느 정도 파악할 수 있고, 에이전트에게 필요한 권한을 부여할 수 있을 것입니다.47:16

네, 다양한 피드백이 있었네요. 질문이 하나 있는데요, 혹시 메모리 툴에 대해 좀 더 자세히 설명해주실 수 있을까요? 제가 특별히 굳이 알아두려고 하는 건 아니고요.47:31

제가 정확히 알지는 못하지만, 코드를 읽어보지는 않았지만, 파일 시스템을 기반으로 작동하는 것 같아요. 기어와 관련이 있을까요, 아니면 이미 관련이 있는 걸까요?47:46

음, 제가 말씀드리면, 이 질문은 여러 번 있었던 것 같은데, 클라우드 에이전트 SDK에서 파일 시스템을 사용해서 '메모리즈' 폴더나 이와 비슷한 폴더를 만들어서 거기에 메모리즈를 저장하도록 하는 방법이 있을 것 같습니다. 정확히 어떻게 되는지는 잘 모르겠습니다.47:58

메모리 툴의 정확한 구현 방식은 아니지만, 파일 시스템을 그렇게 활용하고 계시는군요. 네, 네, 좋습니다. 네, 마지막 질문 있으신가요? 어떻게 지내시는지요?48:10

코드 관리 방식이 최적화되어 재사용성을 고려하고 있는지 확인해야 합니다. 같은 에이전트가 수백 명의 사용자에게 동일한 코드를 매번 사용하도록 관리될 경우를 가정해 볼 때, 코드를 효율적으로 관리하는 것이 중요합니다.48:20

생성하는 과정은 반복적으로 실행되는데, 그렇다면 재사용성을 어떻게 활용할 수 있을까요? 네, 정말 좋은 질문입니다. 네, 예를 들어 두 명의 에이전트가 상호작용한다고 가정해 보겠습니다. 서로 다른 두 사람이 만나는 경우와 비슷하다고 할 수 있겠네요.48:31

에이전트 간의 재사용성 문제는 어떻게 생각하시나요, 아니면 에이전트들이 어떻게 소통하는지에 대한 질문인데요. 저는 이 부분이 발견해야 할 부분이라고 생각합니다.48:44

웹 앱의 전통적인 방식으로는 보통 한 앱을 백만 명에게 제공하잖아요. 그래서 최적의 방법과 시스템 설계가 많이 필요하다고 생각합니다.48:56

에이전트, 예를 들어 클라우드 코드와 같이 사용할 때, 컨테이너 하나하나를 마치 여러분의 컨테이너처럼 제공해 드린다고 말씀드릴 수 있습니다. 클라우드 코드를 웹에서 사용하시면, 마치 여러분만의 컨테이너를 사용하는 것과 같은 형태가 되죠. 그리고 컨테이너 간의 통신이 많지 않고, 매우…49:06

정말 다른 패러다임이네요. 제가 그 최적의 시스템 설계를 정확히 알고 있다고 말씀드릴 수는 없고요. 그러한 시스템을 구축하기 위한 여러 최적의 방법들이 있을 거라고 생각합니다. 특히 에이전트 재사용과 같은, 여러 좋은 사례들이 있는 것 같습니다.49:21

어떻게 하면 이 작업을 일반 스크립트처럼 결합하여 그들이 해낸 일을 공유할 수 있을까요? 저는 일반적으로 이런 방식으로 하는 것이 좋다고 생각합니다.49:30

음, 약간 딴 이야기일 수도 있지만, 에이전트 통신 프레임워크에 대해서는 개인적으로 그렇게 생각합니다. 아마도 전체적으로 새로 만들 필요는 없을 것 같아요. 제가 생각하기에는, 그렇게 해야 할 필요가 없을 것 같습니다.49:42

새로운 커뮤니케이션 시스템이 있는데, 에이전트들이 HTTP 요청, Bash 도구, API 키, 명명된 파이프 등 저희가 가지고 있는 것들을 능숙하게 활용하는 것 같습니다. 아마 에이전트들이 HTTP를 활용하여…49:56

서로 HTTP 서버를 이용해서 요청을 주고받는 방식이 있잖아요. 거기에는 정말 흥미로운 작업들이 많이 있습니다. 제가 봤을 때 사람들은 가상 포럼 같은 것을 만들기도 하더라고요.50:10

에이전트 분들께서 소통하시기에 좋고, 게시물 주제도 흥미롭고, 댓글도 좋고, 그런 다양한 기능들이 많다고 생각합니다. 탐색해볼 만한 것들이 정말 많을 것 같습니다.50:20

네, 알겠습니다. 계속 진행해 보겠습니다. 혹시 시간 괜찮으신가요? 한 시간 정도 남은 것 같네요. 네, 좋습니다. 디자인의 예를 들어볼까요?50:30

에이전트님, 네, 그렇죠. 프로토타입 세션은 아니지만, 이 부분이 좋은 시작이 될 수 있을 것 같아요. 마치… 저희가 어떤 것을 만들 때와 같은 방식으로 들어가는 것이라고 할까요.50:44

스프레드시트 에이전트가 스프레드시트를 검색하는 가장 좋은 방법은 무엇인가요? 코드를 실행하는 가장 좋은 방법은 무엇이며, 스프레드시트에서 작업을 수행하는 가장 좋은 방법은 무엇인가요? 스프레드시트에 링크하는 가장 좋은 방법은 무엇인가요? 이러한 것들이 모두 궁금하신가요?50:55

정말 흥미로운 것들을 할 수 있는데, 무화과 광산에 가볼까 하는데, 혹시 누군가 물을 가져다줄 수 있다면 정말 감사하겠습니다. 저도 정말 필요한데.51:07

네, 알겠습니다. 감사합니다. 그럼, 저희가 한번 살펴볼까요? 아니면, 잠시 시간을 내셔서 직접 생각해보시는 건 어떠세요?51:17

이 질문에 관하여, 스프레드시트 에이전트를 활용하고 싶으신데, 검색 기능을 갖추고 맥락을 파악하고, 작업을 수행하며, 결과를 검증할 수 있도록 만들고 싶으시다고요. 어떻게 접근해야 할까요? 잠시 시간을 내어 고민해 보시고, 메모라도 적어 보시는 게 좋겠습니다.51:31

네, 혹시 이 문제에 대해 생각해 보실 시간이 조금 있으셨나요? 혹시 더 시간을 원하시는 분이 계신가요, 아니면 바로 시작해도 괜찮을까요? 음, 에이전트가 스프레드시트에서 검색을 할 때 가장 좋은 방법은 무엇일까요?52:57

이제 한 손으로만 타이핑을 해야 할 것 같습니다.53:10

나중에 타이핑해야 하니까 이거 어떻게 해야 할지 알아내야겠어요. 좋아요, 좋아요, 스프레드시트 검색하는 거요. 혹시 아이디어 있으세요? 스프레드시트는 어떻게 검색해야 할까요? 뭘 해야 할까요?53:15

CSP요. CSP가 있네요, 알겠습니다. 이제 에이전트가 CSP를 검색하고 싶어해요. 이게 뭘 하는 건가요?53:26

그리프 스테이지에요. 좋아요, 그리프는 어떻게 생겼나요?53:34

헤더들을 한번 살펴봐 주실 수 있나요? 헤더를 확인해 주세요, 네.53:38

모든 시트의 헤더입니다. 좋아요, 네.53:41

그리고 제가 2024년의 수익을 찾고 있다고 가정해 보겠습니다.53:45

이제 헤더도 갖추었으니, 스프레드시트를 불러올게요.53:51

수익 데이터가 들어왔다고 가정해 보겠습니다. 수익 항목이 있고, 마치 그런 식으로... 네, 한번 살펴보겠습니다.53:57

네, 그렇습니다. 음, 예를 들어 이렇게 되는 경우를 말씀드리겠습니다. 2026년에 어떻게 수익을 창출할 수 있는지, 질문이신 거죠? 이런 문제가 흔히 있는 문제이기도 합니다. 여기 수익이라는 단어가 있고, 여기에는 2026이라는 연도가 적혀 있으니, 이런 식이죠.54:22

음, 다차원 스텝 오른쪽으로 보시면 헤더를 확인할 수 있습니다. 그러면 아마 100, 200, 300처럼 값을 얻을 수 있을 거예요. 약간 조절이 필요할 것 같습니다.54:37

다른 아이디어도 있고, 다른 방법들도 있을 거예요. 네, bash 도구로 awk를 사용할 수도 있죠. 네, 그리고요.54:48

awk로 무엇을 할 수 있을까요? 네, 네, 그게 질문이죠. 사용자가 무엇을 찾고 있는지 알아야 하잖아요. 아마 이런 종류의 걸 찾고 있을 거예요.54:59

2026년의 수익과 관련된 API를 활용하여 구글 도구들과 모든 숫자를 함께 처리하는 것이 아이디어입니다. 즉, 구글 API를 활용하는 것입니다.55:09

네, 찾아보시는 건 정말 좋네요. 하지만 혹시 저희가 로컬 환경에서 작업한다고 가정했을 때, API를 설계해야 할 수도 있습니다. SQLite 같은 걸 사용할 수도 있겠죠.55:23

아, 정말 흥미롭네요. 네, 몰랐어요. 아주 좋네요. 네, CSV 파일을 쿼리하기 위해 SQLite를 사용하시는군요. 정말 창의적인 방법이네요.55:33

API 인터페이스에 대해 생각하고 있는데, 에이전트가 아주 잘 이해할 수 있는 인터페이스로 번역할 수 있다면 정말 좋을 것 같습니다. 그렇죠? 그리고, 음….55:43

데이터 소스가 있으시다면, 이를 시퀀엘 쿼리로 변환할 수 있다면, 에이전트가 시퀀엘을 검색하는 방법을 정말 잘 알고 있다는 뜻입니다. 이러한 변환 과정을 생각해보는 것은 매우 흥미롭습니다. 설계하는 방식에 도움이 될 수 있는 훌륭한 방법이라고 생각합니다.55:53

에이전트 검색 인터페이스입니다, 네, 네.56:05

클로드 같은 게 적절한 도구를 적절한 일에 사용하도록 순위를 매길 만큼 똑똑할까요? 바로 그게 우리가 이야기하고 있는 내용이거든요, 적절한 도구를 적절한 일에 사용하는 거죠. 클로드 같은 게 적절한 도구를 적절한 일에 사용하도록 순위를 매길 만큼 똑똑할까요?56:14

네, 프롬프트하면 가능해요. 아마 이런 것들은 우리가 '음, 잘 모르겠네, 한번 해보자'라고 하는 것들 중 하나일 거예요. 한번 기록을 읽어볼까요? 만약 아니라면, 어떻게 도와드릴 수 있을까요?56:24

네, 마치 이 모든 것들이 직관과 같다고 생각해요, 아시죠? 말 타는 것과 비슷한 느낌이에요. 물론 제가 말을 탄 적은 없지만요.56:34

네, 마치 말을 탄 것처럼 신호를 보내거나 진정시키는 것 같아요. 어떻게 더 빠르게 밀어붙일까요?56:46

아시죠? 정말 유기적인, 자연스러운 느낌이랄까요? 네, 저희는 모델이 설계되는 게 아니라 성장한다고 말하는 걸 좋아해요. 네, 네, 모델의 역량을 이해하는 과정이죠.56:58

네, 그래서요.57:12

또 다른 좋은 패턴은, 예를 들어 스프레드시트에 메타데이터를 추가할 수 있는지, 이런 질문들을 생각해 보시는 게 좋겠습니다.57:20

음, 예를 들어 검색에 대해 생각할 때, 검색을 더 좋게 만들기 위해 어떤 전처리를 할 수 있을까 하는 질문이 나올 수 있겠죠. 하나의 예시로, 내용을 시퀀스 형태로 변환하거나, 혹은 어떤 방식으로든 활용할 수 있을 겁니다.57:33

네, 바로 쿼리해서 질문할 수 있습니다. 마치 번역 단계를 거치는 것처럼요. 또 다른 단계는, 혹시 도구를 사용하거나 전처리 단계를 통해 다른 에이전트가 스프레드시트를 주석 처리하고 정보를 추가하는 과정이 있을 수도 있습니다.57:45

그러면 그 정보를 더 잘 검색할 수 있겠죠. 네, 또 다른 방법이 뭐 있는지 생각해 보면, 제안하신 거처럼 에이전트가 그냥 그걸 할 수 있다면 좋겠네요.58:00

헤더를 읽고 날짜를 가져오는 건 사소한 일이 아니겠어요. 그렇죠, 읽어 텍스트라면 그렇게 할 수 있을 거예요.58:12

코드로 만들었지만, 사실 스프레드시트 에이전트를 정말 많이 만들었어요. 기본적으로 하는 게 좀 어렵죠, 네. 그래서 제가 생각하는 건…58:22

음, 그러니까, 세안 씨, 혹시 어떻게 이야기해야 할지 조언이 있으신가요?58:34

동시에 코딩을 하고 있지만, 있습니다.58:40

등면에 있는 마이크 버튼이 있네요.58:50

그런 거는 믿지 마세요, 정말 안 돼요. 저희는 AI 연구실에서 작업하고 있는지 확인해야 해요.59:00

알겠습니다, 음, 한번 살펴볼게요, 잠깐만요, 잠깐만요. 하는 방법 중 하나는 이런 식으로요.59:09

스프레드시트에서 보시는 것처럼, 예를 들어 여기에서 수식을 디자인하실 수 있습니다. B3, 2와 같이요. 이 것과 같은 식으로요.59:25

에이전트가 주로 사용하는 B3에서 B5 정도의 구문 방식이죠, 맞습니까?59:41

그리고 에이전트 검색 인터페이스를 디자인할 수도 있어요, 그렇죠? B3, B5 같은 식으로요, 그렇죠? 그러니까 에이전트 검색 인터페이스가 범위를 입력받을 수 있어요, 그렇죠?59:45

범위 문자열을 입력받을 수도 있어요, 그렇죠? 에이전트가 잘 아는 것들이기도 하고요, 그렇죠? SQL 쿼리를 사용할 수도 있죠?59:56

에이전트는 SQL 쿼리를 잘 알고 있죠, 그렇죠?01:00:05

그리고 이처럼 XML도 가능합니다. 죄송하지만 글씨가 너무 작네요. 네, XML도 가능합니다.01:00:10

혹시 아실 수도 있는데, XLX 파일은 내부적으로 XML 형식으로 되어 있고, XML은 굉장히 구조화되어 있어서 XML 검색 쿼리를 사용하거나, 이를 처리할 수 있는 다양한 라이브러리도 존재합니다.01:00:24

네, 그게 하나의 예시가 될 수 있죠. 예를 들어, 어떻게 맥락을 찾고 수집하느냐 하는 질문과 관련이 있습니다. 이 설명이 맥락을 수집하는 것이 얼마나 창의적인 작업인지 이해하는 데 도움이 되었으면 좋겠습니다. 그리고 여러 번의 반복 과정을 거치게 되죠.01:00:36

만약 한 번만 시도해보셨다면, 아마 충분하지 않으실 겁니다. 그렇죠? 생각해보시면, 가능한 한 다양한 방법으로 시도해보셔야 합니다. 예를 들어, 시퀀스나, 서버를 시도해보시고, grep과 ock 같은 다양한 기능들을 사용해보시는 것이 좋습니다.01:00:48

여러 가지 시도를 해보고 에이전트가 무엇을 좋아하고 무엇을 싫어하는지 살펴보는 테스트들을 몇 개 가지고 계시는 거 같아요. 에이전트라고 말씀하실 때는, 어떤 것을 말씀하시는 건가요?01:01:00

그리고 이미 가지고 있는, 그런 방식으로 어떻게 하는지에 대한 기존 지식을 활용하고 계시는 거고요. 누가 그걸 모델링하고 있나요? 네, 왜냐하면 질문은 누가, 그 지식은 어디에서 오는 걸까요?01:01:18

혹시 모델 말씀하시는 건가요? 제가 에이전트라고 말씀드리는 게, 어떤 의미인지 궁금하신 건가요? 네, 일반적으로 말씀하시는 건, 문제가 있을 때 에이전트가 최대한 분포를 갖도록 만들어야 한다는 거겠죠?01:01:30

그래서 그 요원은 다양한 분야에 대해 많은 것을 알고 있습니다. 예를 들어 금융 분야에 대해서도 잘 알고 있죠.01:01:41

그래서 DCF 모델을 만들라고 하면, DCF가 뭔지 알죠, 그렇죠? 그리고 더 많은 정보를 제공하고 싶다면, 스킬을 만들 수도 있죠?01:01:46

DCF가 무엇인지, 시퀄이 무엇인지 알고 계시죠? 혹시 그 두 가지를 함께 연결할 수 있을까요?01:01:56

그래서 이상적으로는 문제 해결 과정에서 데이터가 기존 분포에서 벗어나는 경우가 발생할 수 있습니다. 예를 들어, 인터넷에 없는 정보나, 본인만이 가지고 있는 정보가 관련된 경우가 있을 수 있습니다.01:02:01

아니면 그것 자체가 좀 특별한 의미를 가지는데, 최대한 널리 보편화될 수 있도록 다듬어 보려는 시도이시겠죠. 음, 네, 매우 창의적이시다고 생각합니다. 아시다시피, 이건…01:02:13

음, 과학이라기보다는 예술에 좀 더 가까운 것 같아요. 네, 좋아요. 그래서 저희는…01:02:25

맥락을 파악하고 조치를 취하는 방식으로 시도해 봤는데, 여기서 이전에 했던 것과 비슷한 많은 작업을 수행할 수 있을 것 같습니다. 예를 들어 2D를 삽입하는 것과 같은 작업도요.01:02:35

만약 속편 인터페이스가 있다면, 속편 쿼리를 실행하거나 XML을 수정할 수 있습니다. 이 부분들은 종종 매우 유사한 경우가 많습니다.01:02:48

액션과 문맥 파악이 필요하고, 아마도 유사한 API를 양방향으로 주고받아야 할 것입니다. 그리고 마지막으로, 작업 결과를 검증하는 것도 중요합니다. 혹시, 어떻게 생각하시는지, 어떻게 생각하시는지, 널 포인터 확인도 하셔야 할 것 같습니다.01:03:02

그것은 방법 중 하나이고, 다른 검증 아이디어가 있을까요?01:03:17

네, 네, 마치 다른 SDK를 사용할 때처럼 아시아 지역을 개발할 때, 제가 문맥을 어떻게 수집해야 하는지 알려줄 필요는 없습니다. 그냥 문맥을 제공하고 설명해주면 됩니다.01:03:25

이게 대체로 무슨 뜻인지, 쉽게 풀어서 설명해 주시면 감사하겠습니다. 제가 의도한 바를 말씀드리고, 혹시 제가 잘못 이해하고 있는 부분이 있는지 확인하고 싶습니다.01:03:37

QA를 위한 별도의 에이전트를 만들어 검증하도록 해야 하는데, 스스로 검증할 수 있다는 에이전트를 완전히 신뢰하지는 못하겠습니다. 다만, 그 수준이 어느 정도인지 조금 혼란스럽습니다.01:03:47

네, 알겠습니다. 예시에서 설명해야 할 세부 사항은 바로 그 질문에 대한 건데요, 에이전트에 맥락을 제공하는 것과 에이전트 스스로 맥락을 파악하도록 하는 것의 차이점에 대한 내용입니다. 말씀하신 내용이 맞습니다.01:04:01

가끔씩 Q&A 에이전트를 사용하시는데, 혹시 어떤 분야의 에이전트를 구축하고 계신지 여쭤봐도 될까요? 혹시 사이버 보안 분야인가요? 네, 물론입니다. 음, 생각하신다면 말씀해주시면 감사하겠습니다.01:04:12

좀 더 구체적으로 살펴봐야 할 것 같아요. 클라우드 에이전트 SDK는 사이버 보안에 아주 유용하고, 일반적으로는 에이전트가 최대한 많은 컨텍스트를 수집하도록 권장하는 편입니다. 아시죠?01:04:27

가능하면 스스로 일을 찾도록 내버려 두는 것이 좋다고 생각합니다. 저희는 그 일이 스스로 찾을 수 있도록 도구를 제공하려고 노력하고 있죠. 제가 생각하는 방식은, 마치 누군가 여러분을 방에 가두고, 스스로 할 일을 해내도록 돕겠다고 말씀하시는 것과 비슷하다고 할 수 있습니다.01:04:39

알고 계시는 업무처럼, 마치 신사분처럼 하셨던 업무가 그랬던 걸로 알고 있습니다.01:04:52

음, 마치 그런 상황이랄까요? 만약 이 방에 6개월 동안 머무신다면 달러 1달당 5그램 정도를 얻을 수 있다면, 누군가에게 어떤 메시지를 전달하려는 것일 겁니다. 그 메시지를 전달하기 위해 어떤 도구들이 필요할까요? 그냥 간단한 도구만 원하실 건가요?01:04:56

논문 목록이나, 계산기, 아니면 컴퓨터 같은 걸 원하시겠습니까? 아마 저는 컴퓨터를 원할 것 같아요. 구글도 필요하고, 이런 것들 모두 필요할 것 같고요. 그러니까 저는 그 사람이 저에게 이런 것들을 보내주는 건 원하지 않아요.01:05:10

문서 더미를 보고 있으면, 마치 '이것이 아마 필요한 모든 정보일 겁니다.'라고 말하는 것 같네요. 저는 오히려 '그냥 컴퓨터를 주세요. 문제를 던져주세요. 제가 검색해서 알아낼게요.'라고 말하고 싶습니다. 에이전트에 대해서도 그렇게 생각하고 있습니다.01:05:23

아마 지금 뭔가 갇혀 있는 상황인 것 같아요. 제가 그들에게 필요한 도구를 제공해야 해서, 혹시 슬라이드를 다시 보여주실 수 있을까요? 그래프로 넘어가 주시면 감사하겠습니다.01:05:34

이 그래프처럼 말씀하시는 거죠, 네, 네, 그렇습니다. 제가 마치... 음, 어쩌면...01:05:44

코드 생성 API인데, 혹시 SQL 도구를 제공할 수도 있고, bash를 제공할 수도 있습니다.01:05:56

이것 모두 예시죠? 네, 맞아요. 혹시 더 질문 있으세요? 질문 있는데요, 제가 언급하는 에이전트들이 모두 같은 컨텍스트 윈도우를 공유하나요? 그리고 그 크기는 어느 정도인가요?01:06:00

흥미롭네요. 네, 에이전트들이 컨텍스트 윈도우를 공유하나요? 전체적인 컨텍스트 관리에 대한 정말 흥미로운 질문인 것 같아요.01:06:14

아직 이 부분에 대해 자세히 말씀드리지 않았지만, 서브 에이전트가 컨텍스트를 관리하는 매우 중요한 방법이라고 생각해요. 음, 생각합니다.01:06:20

클라우드 코드를 사용할수록 점점 더 많은 하위 에이전트를 활용하고 있는데, 하위 에이전트를 아주 일반적으로 다루는 것을 고려해 볼 수 있을 것 같습니다. 예를 들어 스프레드시트 에이전트의 경우, 어쩌면 다음과 같은 방식으로 접근할 수 있을 것입니다.01:06:30

검색 서브 에이전트를 활용하는 방법이 있습니다. 서브 에이전트는 많은 작업을 수행하고 결과를 메인 에이전트에 전달해야 할 때 매우 유용합니다. 검색의 경우, 예를 들어 질문이 '어떻게 하면...'과 같은 경우에 활용할 수 있습니다.01:06:42

2026년의 수익을 찾아봐야 할 것 같아요. 아마 여러 결과를 분석해야 할 수도 있고, 인터넷 검색이나 스프레드시트 같은 자료를 찾아봐야 할 수도 있을 거예요. 하지만 메인 에이전트와 관련 없는 여러 세부 사항은 고려할 필요가 없어요. 메인 에이전트는 그것들을 볼 필요가 없답니다.01:06:53

네, 결과가 좋네요. 정말 훌륭한 하위 에이전트 작업입니다. 제가 하위 에이전트 전용 공간은 따로 마련해두지 않았지만, 굉장히 유용하고, 정말 좋은 방법이라고 생각합니다.01:07:07

음, 좀 더 생각해보자고 하셨는데, 그 질문에 대해서 좀 더 발전시켜보면, 실제로 검증을 위해서 예를 들어 숙련된 에이전트나 서브 에이전트를 활용해서 할 수 있을 겁니다. 심지어 보안 예시처럼 적대적인 에이전트를 활용하는 것도 고려해 볼 수 있겠습니다.01:07:18

정말 멋진 결과물을 원하신다면, 기존 작업에 대한 애착 없이 과감하게 수정하셔야 할 수도 있습니다. 물론 스펙트럼이라는 말씀이시겠지만, 혹시 부제를 활용하시는 것을 제안하시는 건가요?01:07:31

기술을 활용한다면 어떻게 생각하시겠어요? 네, 물론이죠. 질문이 있는데요, 혹시 서브 에이전트 사용하시나요? 네, 물론입니다. 감사합니다. 네, 가능하실까요?01:07:43

네, 검증을 위한 대행자들이 있다는 점은 이해가 됩니다. 패턴으로 보입니다. 이상적으로는 규칙 기반의 검증 방식이 가장 좋을 것 같습니다. 혹시, 그 점이 맞으신가요?01:07:57

널 포인터 같은 쉬운 검증이 필요하거든요. 린트나 컴파일처럼 최대한 많은 규칙을 넣으려고 노력하고, 창의적으로 접근하는 거죠.01:08:08

예를 들어 클라우드 코드에서 에이전트가 읽지 않은 파일에 쓰려고 한다면, 저희는 그걸 읽기 캐시에 아직 없다고 판단해서 에러를 던지는 방식이에요.01:08:19

이 내용을 전달할 때, 음, 아직 이 파일을 읽지 않으셨다면 먼저 읽어보시는 게 좋겠습니다. 그리고 이것은 저희가 검증 단계에 삽입하는, 일종의 결정적인 도구의 예시입니다. 그리고, 흠...01:08:31

가능한 한, 생각나는 즉시, 검증 없이 처음에 할 수 있는 일이 무엇인지 결정적으로, 어떤 일들이 가능한지, 예를 들어, 어떤 출력을 낼 수 있는지 등을 생각해보시는 겁니다. 그리고 또 그때마다…01:08:42

어떤 에이전트 8가지 유형을 선택하느냐에 따라, 더 결정적인 규칙을 가진 에이전트가 더 낫겠죠. 당연히 말이 되는 것 같아요. 음,01:08:54

물론 모델이 점점 더 좋아지면, 하위 에이전트가 메인 에이전트의 작업을 검토할 수 있습니다. 중요한 것은 컨텍스트 오염을 피하는 것이니까요. 컨텍스트를 포크하는 것은 아마 원치 않으실 거예요.01:09:05

새로운 컨텍스트 세션을 시작하고, 마치 이렇게 말하는 것처럼 해보고 싶어요. '아, 네, 경쟁적으로 확인해볼게요. 이 결과물은 맥킨지 주니어 애널리스트가 만들었습니다.'01:09:19

아니면 졸업한 학교라든지, 아니면 성적 같은, 아시죠, 이런 종류의 정보들을 쭉 넣어서 평가하게 하는 거죠. 그게 바로 서브 에이전트의 도구 중 하나고요. 네.01:09:29

모델들이 점점 더 좋아짐에 따라 선호도가 높아지는 경향이 있고, 그런 검증 방식 또한 더욱 정교해질 것입니다. 하지만, 그것을 결정적으로 수행하는 것은 마치…01:09:44

아, 좋은 시작이네요. 혹시 확인하는 기능에 대해서 질문이 있습니다. 네, 만약에...01:09:53

포인터를 찾지 못했는데요, 아마 그냥 '괜찮습니다, 수정하겠습니다'라고 말하는 것이 쉬울 수도 있지만, 혹시라도 배포 과정에서 예상치 못한 문제로 인해 시스템에 영향을 미치는 상황이 발생할 수도 있습니다.01:10:03

전체 스프레드시트가 삭제되었고, 그래서 어느 단계에서 되돌리기 기능을 포함해야 할지 고민이네요. 예를 들어, QA 담당자가 만약…01:10:16

그분들의 스프레드시트가 비어있는 상황을 고려했을 때, 이전 상태로 되돌리기 어려울 수도 있다는 점에 대해서는 뭐라고 조언하셨나요?01:10:28

네, 질문은 마치 국가와, 그리고 되돌리기와 다시 하기, 즉, 오류를 수정할 수 있는 기능에 대해 어떻게 생각하시느냐 하는 것이죠, 맞습니까?01:10:37

이 질문이 정말 좋은 질문이라고 생각합니다. 솔직히 말씀드리면, 에이전트가 무엇을 잘하는지에 대해 생각해보는 것과 비슷한 맥락이라고 할까요?01:10:45

음, 좋아요, 아니면 도메인에 어떤 문제가 있는지 궁금하신가요? 에이전트는 어떻게 작동하며, 작업은 얼마나 되돌릴 수 있는 걸까요? 직관적으로 정말 좋은 점이죠. 코드는 되돌릴 수 있습니다. 그냥 이전으로 돌아갈 수 있고, Git 기록을 되돌릴 수도 있습니다. 아시겠지만요.01:10:57

처음부터 원자 단위 작업이 바로 이루어지도록, 클라우드 코드를 통해 저는 Git을 계속 사용하고 있습니다. 이제는 키 명령어를 직접 입력하지 않죠. 굉장히 좋은 예시라고 할 수 있습니다. 반대로, 컴퓨터 사용을 나쁜 예시로 들 수 있겠네요. 왜냐하면…01:11:10

사용하는 것은 상태에서 되돌릴 수 없습니다. 예를 들어, 도어대쉬(Doordash) 같은 곳에 접속하셨다고 가정해 보겠습니다. 사용자가 콜라를 주문해 달라고 요청하시면, 주문을 추가하는 식으로 진행되죠.01:11:23

펩시를 지금 주문하세요. 코크를 다시 선택할 수 있는 것처럼 되돌릴 수 있는 게 아니니까요. 장바구니로 가서 펩시를 제거해야 합니다. 그래야 실수를 바로잡을 수 있습니다. 아시겠지만, 이런 상태 관리, 상태 머신과 같은 거죠.01:11:34

상황이 더 복잡해지면서, 되돌리거나 다시 할 수 없는 매우 복잡한 상태 머신을 다룰 때 어려움이 따르는 경우가 많습니다. 엔지니어로서 고민해야 할 질문 중 하나가 바로 그것입니다.01:11:48

제가 말씀드린 것처럼, 되돌릴 수 있는 상태 머신 형태로 변환할 수 있을까요? 체크포인트 사이에 상태를 저장해서, 혹시 사용자가 '제 스프레드시트가 지금 망가졌어요'라고 말씀하실 때 이전 체크포인트로 되돌릴 수 있도록 하는 거죠.01:12:00

네, 모델이 이전 체크포인트로 되돌아갈 수도 있을 것 같습니다. 누군가가 시간 여행 도구와 비슷한 것을 코딩 에이전트에게 제공했는데, 꽤 멋있었습니다. 마치 특정 시점으로 돌아가는 시간 여행을 하는 것과 같았습니다.01:12:11

이 일이 있기 전에는, 아시겠지만, 꽤 웃기네요. 마치 이러한 도구들 중 일부는 아직 완벽하게 작동하지 않는 것 같기도 하고요. 하지만, 결국에는 다 잘 될 거예요. 네, 생각해보니 상태에 대해서도요.01:12:26

네, 맞습니다. 검증하는 것은 매우 유용하죠. 네, 맞아요. 뒤에 질문 있으신 분 계신가요? 네.01:12:37

규모가 얼마나 커질 수 있을지 궁금하네요. 만약 스프레드시트가 수백만 개의 도로처럼, 아니면 수십억 개의 행과 수천만 개의 열로 이루어진다면 어떨까요?01:12:47

그 상황에서 데이터베이스를 검색한다면, 문맥의 제약이 있을 때 어떻게 접근해야 할까요? 아, 네, 좋습니다. 코딩 예시로 스프레드시트 예제를 보여줬어야 했나 싶네요.01:12:57

예시로 말씀드리면, 제 코딩 에이전트는 포켓몬 에이전트입니다. 아마 스프레드시트가 더 나았을 거예요. 질문은, 스프레드시트가 엄청 크다면 어떻게 해야 할까요?01:13:10

백만 개의 행이 있다면, 어떻게 생각하시겠어요? 백 개의 열이 있고, 또는 백만 개의 열이 있거나, 어떤 것이든, 어떻게 생각해야 할까요, 그렇죠?01:13:23

데이터베이스도 엄청 크다면, 그걸 어떻게 처리해야 할까요? 이런 모든 경우에 있어서, 데이터가 점점 커질수록, 문제가 더 어려워지는 건 당연합니다. 그냥, 정말로 그렇습니다.01:13:31

정확도가 떨어지겠죠, 그렇죠? 클라우드 코드는 더 큰 코드베이스에서는 작은 코드베이스만큼 좋지 않죠? 모델이 더 좋아지면, 이 모든 것들을 더 잘 처리할 수 있겠죠. 이런 것들을 해결하려면 어떻게 해야 할지 생각해야 할 것 같아요.01:13:44

만약에 백만 개의 열과 백만 개의 행을 가진 스프레드시트가 있다면, 어떻게 해야 할까요? 저는 그걸 찾기 시작해야 할 것 같아요. 예를 들어, 수익을 찾는다면, Ctrl+F를 사용해서 검색할 것 같습니다.01:13:57

수익을 확인한 다음에는 이러한 결과들을 하나하나 꼼꼼히 검토하면서 이게 맞나 하고 생각하고, 혹시 여기 숫자가 있나 살펴보고, 아마 새로운 용지나 스크래치 패드에 적으면서 저 같을 때는 이렇게 계산하면 되겠구나 하는 식으로 정리할 것 같습니다.01:14:09

알고 계시다시피, 매출은 이런 식으로 산출되는 것이고, 매장에서는 이 레퍼런스를 참고해서 계속 진행해야 합니다. 제가 생각하기에 좋은 방법은 모델이 스프레드시트 전체를 맥락에 맞게 한 번에 읽어들여서는 안 된다는 것입니다.01:14:23

음, 너무 많은 권리를 주장하시는 것처럼, 마치 처음부터 컨텍스트 양을 부여하시는 것 같고, 또 그렇게 업무를 처리하시는 거죠. 예를 들어, 스프레드시트를 열어보셨을 때, 행들이 보이시죠? 맨 처음 10행 정도 보이시는 거죠?01:14:36

네, 아시다시피 30개 정도의 열이 보일 겁니다. 그게 보이시는 거죠. 처음부터 전부 컨텍스트에 로드하는 게 아니라, '이걸 좀 더 컨텍스트에 로드해야겠네' 하는 감이 오실 거예요. 그렇죠.01:14:49

아, 네, 이 다른 시트로 이동해야겠네요. 이 다른 시트에는 더 많은 데이터가 들어있죠. 그런데 어느 정도는 스스로 맥락을 파악해야 하고, 그래야 에이전트가 동일하게 작동할 수 있습니다. 예를 들어, 이 시트들로 이동하는 것처럼요.01:15:01

네, 읽으시면서 스크랩 노트에 메모하시면서 계속 진행하시면 되는 것 같아요. 그렇게 생각하고 있습니다. 네, 뒤쪽에서 질문 있으신가요? 제 질문은 컨텍스트 오염을 관리하는 것에 대한 건데요, 사실은 이전 질문과도 관련이 있습니다.01:15:16

혹시 컨텍스트 윈도우의 어느 정도 비율을 사용해야 점차 효율이 떨어지거나 효과가 감소하는지, 그런 기준이 있으신가요, 아시는지요?01:15:30

네, 질문은요, 네, 컨텍스트 관리에 대한 질문인데요. 컨텍스트 윈도우를 얼마나 사용해야 효과가 줄어들기 시작하는지에 대한 경험 법칙 같은 게 있으신가요? 음, 이건 지금 당장 상당히 흥미로운 문제라고 생각합니다.01:15:39

클라우드 코드를 사용하시는 분들과 대화할 때, 종종 '이것이 제 다섯 번째 컴팩트인가요'라고 말씀하시는 분들이 계십니다. 저는 깜짝 놀라면서 '무슨 말씀이신지?'라고 되묻곤 합니다. 거의 컴팩트를 사용해 본 적이 없는 것처럼 테스트를 꼼꼼하게 해봐야 할 때가 많거든요, 아시겠죠?01:15:54

제가 스스로를 억지로 압축하게 되는 경우가 종종 있습니다. 특히 클라우드 코드를 사용할 때 문맥 창을 자주 정리하는 편이라 그런 것 같습니다.01:16:08

음, 제 경우에는 적어도 코드 자체의 상태가 코드 베이스 파일에 저장되어 있잖아요. 그러니까 제가 변경 사항을 만들었을 때, 클라우드 코드는 제 깃 디프를 보고 바로 알 수 있는 거죠.01:16:17

안녕하세요, 변경 사항이 이것들입니다. 이전 대화 기록 전체를 알 필요는 없고, 새로운 작업을 이어가기 위해서죠. 클라우드 코드를 사용하는 저는 맥락을 매우 자주 초기화하고, 마치 이렇게 말합니다. '저의 아직 적용되지 않은 Git 변경 사항들을 보세요, 저는 이 작업들을 하고 있습니다.'01:16:30

네, 그렇게 확장해 볼 수 있을 것 같습니다. 마치 그런 방식으로 생각하는 거죠. 그리고 사용자님께서 직접 에이전트를 구축하실 때, 예를 들어 스프레드시트 에이전트를 만든다고 할 때, 사용자님의 요구사항이 좀 더 복잡해질 수 있습니다.01:16:45

기술적인 권한도 없으시고, 컨텍스트 윈도우(context window)가 무엇인지도 모르시는 분들이 계시죠. 음, 저는 이게 상당히 어려운 문제라고 생각합니다. 아마도 사용자 경험(UX) 디자인적인 측면에서, 대화 단계를 재설정할 수 있는지, 아니면 매번 대화를 시작할 때마다01:16:57

사용자께서 새로운 질문을 주셨는데, 혹시 자체적으로 좀 더 간결하게 정리하거나 내용을 요약해 주실 수 있나요? 상태 정보가 대부분 스프레드시트에 포함되어 있어서, 별도로 정보를 알 필요는 없을 것 같습니다.01:17:12

전체적인 맥락에서 사용자 선호도를 기억하며, 마치 예술 작품처럼 다양한 관점과 방식으로 접근할 수 있도록 할 수 있을까요? 여러 가지 요소를 고려해야 하는 부분이 많습니다.01:17:25

네, 음, 맞아요. 맥락 사용을 줄이려고 노력하시는 거죠. 아마도 소네트 밀리언만큼 많은 맥락이 필요하지 않으실 거예요, 아시죠? 그냥 맥락 관리를 잘 하시면 되는 것 같아요.01:17:39

네, 님. 긍정적으로 말씀드리자면, 하위 대행들은 핵심 대행의 업무를 보호하기 위해 만들어졌다고 말씀하셨습니다. 맞습니다. 하위 대행들은 핵심 대행 업무를 보호할 수 있도록 고안되었습니다.01:17:49

여러 하위 에이전트를 활용하여, 스프레드시트가 매우 큰 경우를 대비하여 덩어리별로 나누어 각 에이전트들이 서로 평행하게 처리할 수 있도록 프로세스를 구축해 보려고 합니다.01:18:02

네, 네, 그러니까 음, 네, 그래서요. 클락코드(ClockCode)에서 제가 좋아 하는 것 중 하나는 저희가 특히 bash를 사용하는 서브에이전트(sub-agent)를 활용할 때 최상의 경험을 제공한다고 생각한다는 점입니다. 정말, 정말01:18:10

음, 좋네요. 사실 제가 그 고통을 완전히 깨닫지 못했다는 걸 알게 됐어요. 혹시 Qcon에 참석하시는 분들이 계시다면, 아담 울프 님이 Qcon에서 저희가 배쉬 툴을 어떻게 만들었는지에 대한 강연을 하시더라고요. 아담 님은 정말 전설이세요. 그리고…01:18:23

배쉬 도구는 훌륭하지만, 동시에 여러 개의 하위 에이전트를 실행할 때는 매우 복잡해질 수 있습니다. 레이스 컨디션과 같은 문제가 많이 발생할 수도 있습니다.01:18:35

거기서 저희가 해결했던 많은 작업들이 있었죠. 그래서 제가 클라우드 코드를 좋아하는 것 중 하나는, 그냥 이렇게 세 개의 하위 에이전트를 띄워서 이 작업을 처리할 수 있다는 점이에요. 그렇게 할 수 있습니다.01:18:46

그리고 에이전트 SDK에서도 그렇게 하도록 요청할 수 있습니다. 우선, 서브 에이전트는 에이전트 SDK에서 훌륭한 기본 요소이며, 아직 그렇게 구현하신 분은 보지 못했습니다. 그래서 큰 이유 중 하나입니다.01:18:56

네, 일반적으로 사용하려면, 하위 에이전트들이 문맥을 보존하도록 해야 합니다. 예를 들어, 스프레드시트가 있다면 여러 개의 읽기 하위 에이전트들이 동시에 실행될 수 있겠죠. 아마도 메인 에이전트는 이렇게 말할 겁니다. ‘이 에이전트가 읽고 요약할 수 있나요?’01:19:06

이 시트 하나를 에이전트가 읽고, 시트 둘을 요약하고, 시트 셋을 요약한 뒤 결과를 반환합니다. 그런 다음 에이전트는 또 다른 하위 에이전트를 생성할 수도 있습니다, 그렇죠? 이것은 또 다른 조절 장치입니다.01:19:21

제가 말씀드리고 싶었던 건, 다양한 창의적인 방법들을 활용하는 것에 대해 너무 많이 이야기했다는 점이에요. 문제를 해결할 때 이 수준에서 생각하셔야 합니다.01:19:35

제 생각에는, 프로세스를 분리해서 부분 에이전트를 만들거나, 시스템 엔지니어링 같은 것을 어떻게 하는지, 또는 컴팩트와 같은 무엇이 필요한지에 대해 너무 고민하실 필요는 없으실 것 같습니다. 저희가 이 모든 부분을 처리해 드릴 테니까요.01:19:49

그러니 하네스 안에서 마치 '어떤 하위 에이전트들을 분리해야 할까?' '에이전트 검색 인터페이스는 어떻게 만들지?' '그리고 그 결과물이 제대로 작동하는지 어떻게 검증해야 할까?' 와 같은 점들을 생각하며, 이러한 문제들이 정말 핵심적이고 어려운 문제라는 것을 인지해야 합니다.01:20:04

이 문제들을 해결해야 하는데, 만약 이 문제들을 해결하지 않고 좀 더 하위 수준의 문제들을 해결하는 데 시간을 소비한다면, 아마도 고객에게 가치를 제공하지 못하고 있을 겁니다.01:20:17

알고 계신 사용자분들과 관련해서, 네, 에이전트 SDK를 서브 에이전트들이 굉장히 좋아합니다. 네, 맞아요. 저희는 이 액션과 검증 작업이 있습니다, 네.01:20:25

정확히 저희가 필요한 방식은, 예를 들어 설명하자면, SQL 쿼리가 생성된 후에 제가 그 쿼리가 맞는지 확인할 수 있는 경로가 하나 있습니다. 두 번째 부분은 마치…01:20:40

질의를 직접 실행하고, 결과를 받으면 검증을 진행할 예정입니다. 그리고 에이전트가 어떤 경로가 올바른 경로인지 동적으로 선택하는 방식은 어떻게 되나요? 질문은 어디에서 진행되는 건가요?01:20:52

확인 과정은 끝부분에서만 진행하시는 것이 아니라 중간중간에도 하시는 것이죠, 그렇죠? 제 생각에는, 어디든 지속적으로 확인하시면 좋을 것 같습니다. 말씀하신 것처럼, 저희도 클라우드 코드의 읽기 단계에서 일부 확인 작업을 진행하고 있습니다.01:21:06

네, 좋은 예시가 바로 그거네요. 끝부분에서 하시는 게 좋고, 정말 그렇게 하셔야 합니다. 하지만 그 외의 시점에서는 규칙이나 휴리스틱이 특히 필요할 때, 예를 들어서요...01:21:19

음, 제 규칙 중 하나는 검색해야 하는 열의 총 개수가 1만 개 이하이거나 천 개 정도여야 한다는 거예요. 그런 방식으로 하는 게 좋다고 생각하는 거죠, 그렇죠? 여기도 마찬가지인데요, 너무 큰 데이터는 삽입하지 않는 게 좋을 것 같아요.01:21:30

음, 마치 행렬의 값을 전달하는 것처럼 모델에게 피드백을 제공하면, 마치 '이 부분을 좀 나누어줘'라고 말하는 것과 같아요. 에러가 발생하고 피드백을 받는 거죠. 그런데, 이 모델의 좋은 점은 피드백을 잘 듣는다는 거예요. 에러 메시지를 읽고 계속 진행하는 거죠. 네, 검증은 확실히 중요한 것 같아요.01:21:45

이런 식으로 일종의 루프 안에 넣어서 가지고 있습니다만, 사실은 검증이 어디든 발생할 수 있어야 하고, 어디든 발생해야 한다고 생각합니다. 마치...01:22:00

네, 가능한 한 많은 곳에서 시작해야 할 프로토타입 작업이 필요하지만, 한 번 더 질문을 받겠습니다. 여기, 네, 잠시만요.01:22:12

네, 시스템 프롬프트처럼 시계 코드를 사용하는 경우, 그냥 그렇게 전달하면 됩니다.01:22:26

그리고 bash 툴을 사용해서, 마치 "어, 음, 맥락을 파악하고, 여러분의 파일을 읽고, 그런 일을 하죠. 예를 들어 링크드인 같은 걸 실행하는 것처럼요. 아시겠죠? 네, 다시 말씀드리지만 에이전트를 사용하실 때, 이걸 반드시 강제할 필요는 없습니다. 말씀드리고 싶은 건, '이런, 이런'이라고 일일이 알려줄 필요가 없다는 말씀입니다.01:22:40

이걸 하셔야 하는 이유는, 가끔은 필요하지 않을 수도 있기 때문입니다. 예를 들어, 스프레드시트에 대해 읽기 전용 질문을 받는 경우, 그러실 필요는 없죠.01:22:53

혹시 컴파일러에서 오류가 없는지, 그리고 혹시 아직 쓰기 오류나 작업 같은 게 없으신지 확인해 주셔야 할 것 같습니다.01:23:03

에이전트가 똑똑하게, 그리고 여러분이 일하실 때 누리는 자유와 똑같은 방식으로 자유롭게 할 수 있도록 해 주시는 거죠? 마치 여러분이 이 상자 안에 갇혀있는 것처럼요, 그렇죠?01:23:13

네, 좋아요, 멋지네요. 이제 이 홀더가 준비되었으니 프로토타입을 해볼 수 있는지 확인해보고 싶어요. 네, 실행 랜딩. 저희는 질문 답변도 많이 했어요, 네.01:23:24

프로토타입 제작은 괜찮을까요? 음, 에이전트를 구축하고 싶다고 가정해 보겠습니다. 이 대화에서 나가신 후, ‘좋아, 아이디어가 엄청나게 많아. 어떻게 시작해야 할까?’ 라고 생각하실 수 있을 겁니다. 저는 전체적으로 말씀드리면, 에이전트 구축이라는 관점에서…01:23:38

시작하기는 매우 간단하지만, 단순함과 쉬움은 같은 의미가 아니죠. 이해하기 쉽도록 아주 간결하게 설명해 드리겠습니다.01:23:53

그냥 클로그 코드에 가서 클로그 코드에 몇 가지 스크립트와 라이브러리, 그리고 사용자 정의 클로그 아이덴티티를 제공하고, 그걸 제대로 해달라고 요청하면 됩니다. 바로 그렇게 할 겁니다.01:24:02

네, 음, 그거 네, 엄청 쉬울 것 같은데, 마치 이런 식으로요. 제가 API를 말씀드리고, 이 API 키를 드릴 수 있는데, 혹시 확인해 주실 수 있을까요?01:24:12

고객 지원 티켓을 검색해서 우선순위별로 정리하거나, 뭐 그런 일을 해 보세요. 그리고 클라우드 코드가 뭘 하는지 살펴보고 개선해 보세요.01:24:21

그리고 이것은 바로 가지고 계신 전문 분야의 어려운 문제로 바로 건너뛸 수 있는 아주 좋은 방법입니다.01:24:32

그러니까 데이터 정리, 자연 검색, 데이터베이스에 대한 안전장치 마련 등 여러 분야의 문제점들이 있으신 거군요.01:24:40

이것은 바로 클라우드 코드로 시작해서 풀 수 있는 질문들입니다. 클라우드 코드로 무언가를 구축해보시고, 사용하기에 꽤 괜찮다고 느껴질 정도로 만들어보세요. 일반적으로 제가 보기에 그렇게 하실 수 있습니다.01:24:47

처음부터 클라우드 코드를 로컬에서 바로 사용하면 정말 좋은 결과를 얻을 수 있을 거예요. 그리고 그걸 통해 확신을 얻게 되실 겁니다. 네, 그렇게 생각합니다.01:24:59

이 정보는 제가 깜빡하고 있었어요. 제 AI 엔지니어가 설명하는 영상을 보세요. 저희 내부적으로 사용하던 자료 데크입니다. 네, 이제 삽입하겠습니다. 네.01:25:11

고객들에게 보여주는 것들을 보시는군요. 네, 네, 네. 클라우드 코드를 다시 사용하세요. 간단하지만 간단한 게 쉬운 건 아니죠. 양이 많아서요.01:25:23

에이전트 코드 자체가 너무 크거나 복잡할 필요는 없어요. 단지 우아해야 하고, 모델이 원하는 바를 충족해야 해요.01:25:37

흥미로운 통찰력을 얻고 싶다면 모델을 SQL 쿼리로 변환해 보세요. 스프레드시트도 SQL 쿼리로 변환해서 시작할 수도 있겠죠. 그렇게 생각하시면 돼요. 클라우드 코드는 그런 작업을 하기에 아주 좋은 방법이에요. 좋아요, 그럼 포켓몬 에이전트를 만들어 볼까요? 이건요.01:25:49

우리가 할 일인데요, 포켓몬은 정보가 굉장히 많은 게임이에요. 포켓몬은 천 마리 이상 있고, 각 포켓몬마다 엄청나게 많은 기술들이 있답니다.01:26:03

꽤 일반적인 것을 원하고, 실제로 포켓몬 API가 있습니다. 포켓몬을 선택한 이유는 여러분도 자체 API를 가지고 있기 때문입니다, 그렇죠?01:26:12

그리고 다들 굉장히 독특하다고 하잖아요, 그렇죠? 그래서 저는 제가 이전에 해보지 않았던, 다소 복잡한 API를 가진 무언가를 선택해보고 싶었습니다.01:26:21

그래서 포켓몬 API 같은 게 있잖아요, 예를 들어 딧토 같은 포켓몬을 검색할 수도 있고, 아이템이나 그런 것도 검색할 수 있고요.01:26:29

그래서 커스텀 API가 있고, 게임 내에 모든 것이 다 있잖아요, 그렇죠? 그래서 사용자 분들이 포켓몬 팀을 만들고 싶어하는 질문이 있을 수도 있을 거예요, 그렇죠?01:26:38

포켓몬을 정말 좋아하는데, 경쟁적인 플레이를 위한 재미있는 포켓몬 팀을 만드는 것에 대해서는 잘 모르는 것 같아요.01:26:53

혹시 제 에이전트가 그 부분에 대해 도움을 주실 수 있을까요? 그렇게 해주시면 정말 좋을 것 같습니다. 제 목표는 포켓몬에 대해 이야기할 수 있는 에이전트를 만드는 것이고, 그다음에 저희가 무엇을 할 수 있는지 알아볼 생각입니다.01:26:59

그리고 얼마나 진행되었는지, 이미 일부 작업을 완료했습니다. 지금 열어서 보여드리겠습니다. 첫 번째 단계와 프롬프트는 다음과 같습니다.01:27:10

가장 먼저, 저는 주로 코드 생성 작업을 진행할 예정입니다.01:27:24

혹시 GitHub에 올라갈 예정인가요? 네, 실제로 그렇습니다. 제 개인 GitHub에 있습니다. 아, 네, 이 모든 걸 커밋하려고 했던 기억이 납니다. 네.01:27:32

네, 네, 제 개인 깃허브는 음, 어디 보자, 괜찮은 것 같습니다.01:27:44

저희 깃허브가 안전한 곳인지, 아니면 악성코드가 있는지 궁금합니다. 저희는 AI 엔지니어들이잖아요. 오웬을 구하는 게 가능하다면, 그거는 여러분의 책임이에요.01:27:51

네, 네, 혹시 이 코드를 복제하고 싶으시다면 그렇게 하셔도 괜찮습니다. 제가 마지막 변경 사항을 푸쉬해야 해서요. 음, 혹시 이걸 보실 수 있으신가요? 다크 모드로 바꾸는 게 좋을까요, 아니면 괜찮으신가요? 음...01:28:02

다크 모드입니다. 다크 모드인가요? 네.01:28:18

좋아요, 이게 더 나은가요? 네, 아니에요? 다른 다크 모드를 원하세요?01:28:28

좋아요, 이것이 어떻게 작동하나요? 잘 들리시나요?01:28:45

네, 그래서 예를 들어볼게요. 제가 제시한 프롬프트는, 음, '이걸 검색해 줘' 정도였습니다.01:28:50

포키 API를 활용해서 API를 만들고, TypeScript 라이브러리를 제작했는데요. 이 모든 것이 바이브(Vibe) 코드로 작성되었고, 여기 보시면 포켓몬(Pokemon) 인터페이스를 이렇게 만들어 놓은 것을 볼 수 있습니다.01:29:00

네, 그래서 이렇게 만들어졌어요. 포켓몬 API를 이용해서, 이름을 불러서 정보를 얻을 수 있고, 목록을 볼 수도 있고, 모든 포켓몬을 가져올 수도 있고, 종족 정보나 능력치 같은 것도 확인할 수 있어요. 이렇게 제가 입력한 프롬프트에요, 네.01:29:11

이걸 타입스크립트 API 형태로 생성했고, 움직임에 대해서도 동일하게 처리했습니다. 그리고 제가 사용할 수 있는 API를 생성했습니다. POKI API를 가져다 사용합니다.01:29:25

네, POKI API SDK에서 가져왔고, 보시면 어떻게 설정되어 있는지 대략적으로 알 수 있어요. 그리고 지금은 대비되는 부분이 있네요. 이건 cloud.nb 입니다.01:29:38

이것은 POKI API를 위한 TypeScript SDK이고, 여기에는 POKI API의 모듈들이 들어있어요. 주요 기능은 다음과 같습니다.01:29:51

예제 디렉터리에 스크립트를 작성하도록 요청하고, 그런 다음 스크립트를 실행해서 제 질문에 대한 도움을 받게 되는 거죠? 그리고 제가 몇 가지 예제 스크립트를 제공하는 거군요.01:30:01

항상 이 모든 정보가 필요한 건 아니죠? 예를 들어, 포켓몬을 불러오거나, 자원을 나열하거나, 데이터를 가져오는 것처럼요.01:30:12

이것은 제 에이전트라고 할 수 있을 것 같습니다. 제가 TypeScript 라이브러리를 생성하도록 지시한 프롬프트와 Claw.md를 만들고, 클라우드 코드 내에서 대화할 수 있습니다. 관련 버전을 보여드리기도 할 겁니다.01:30:19

이것은 그냥 도구일 뿐인데, 여기서는 메시지 완성 API를 사용하고 있습니다. 그리고 API에서 제공하는 여러 도구를 입력했는데, 예를 들어 포켓몬을 가져오고 포켓몬 종을 가져오는 것과 같은 기능입니다.01:30:31

포켓몬의 능력이나 타입을 얻고, 움직임을 정의하는 등, 다양한 도구를 사용하도록 만들었습니다. 프롬프트를 통해 제가 직접 도구를 생성하도록 지시했는데, 백 도개가 넘게 만들려고 하지는 않거든요.01:30:43

연기가 너무 많이 나네요, 아니면 포키 API 데이터 말씀하시는 건가요? 하지만 아시다시피, 그 정도까지는 어쩔 수 없죠.01:30:56

매우 많은 파라미터를 사용할 수 있어요, 그래서 지금 이렇게 도구 호출 기능이 있고, 제가 작은 채팅 인터페이스를 만들었어요, 그렇죠? 이제 여기 와서 이렇게 말씀드릴 수 있죠, 이게 제 도구 호출 기능이에요.01:31:05

정말 훌륭하네요.01:31:21

네, 그래서 여기 chat.ts 파일이 있습니다. 저는 프로토타입 작업을 할 때 Bun을 사용하는데, 컴파일하는 번거로움을 피하고 싶어서 그렇습니다.01:31:31

타입스크립트에서 자바스크립트로 변환하는 것과 다시 버튼을 누르는 것은 마치 린팅 기능이 내장된 것과 같습니다. 에이전트가 컴파일하는 것을 기억할 필요 없이 단순화하는 방법입니다. 하지만 타입스크립트는 타입 정보가 있기 때문에 생성에 더 적합합니다.01:31:41

좋아요, 이 버튼 채팅을 시작하고, 음… 2세대 물 포켓몬이 뭐였지… 한번 찾아볼게요. 검색이 시작되는 것 같네요. 로그인을 하고 있습니다.01:31:55

여기서 모든 도구 호출은 매우 매우 중요합니다. 왜냐하면 도구 호출을 수행해야 하기 때문입니다. 보시면, 여러 포켓몬을 검색하는 것을 알 수 있습니다. 그리고 저에게 2세대 물 포켓몬 목록이 여기 있습니다, 라고 알려주었습니다.01:32:11

토토다일, 크로키노프, 혹은 악어 같은 것들이 있습니다. 단계별로 이전 단계를 생각하는 방식이 어떻게 보이는지 알 수 있죠?01:32:25

자, 클로드 코드를 사용해서 해보려고 할 때, 이 예제를 삭제해야 할 것 같아요.01:32:36

마리 씨? 아, 네. 혹시, 도구 호출 기록은 어떻게 하시는지 여쭤봐도 될까요? 인자(argument) 하나로 처리하는 건가요?01:32:47

네, 맞아요. 일반적인 API처럼, 모델이 로그인할 때마다 이 함수를 호출하고 있습니다.01:32:56

이것은 일반적인 Anthropic API와 같은 방식입니다. SDK에서는 SDK로 다시 돌아가서 로그를 확인하는데, 어시스턴트 메시지를 전부 기록하는 것과 같은 방식으로 진행됩니다.01:33:06

솔직히 콘솔에서 그냥 해보는 것인데요, 그게 혹시 이해가 되시나요? 네, 괜찮습니다. 보여주시는 채팅 인터페이스는 그냥 일반적인 API를 사용하시는 거고, 맞죠? 에이전트 SDK가 아니라 일반 API를 사용하시는 거죠. 네, 네. 그럼 제가 뭘 할 건데요...01:33:18

여기 있습니다. 스크립트를 삭제하려고 합니다. 속임수를 쓰고 싶지는 않지만, 괜찮습니다. 아시다시피 저는 그냥 클록 코드를 열고 제가 만든 파일들을 많이 생성했습니다.01:33:32

네, 제가 말씀드리자면 물에 대한 모든 세대를 알려달라고 요청하고 나서, 그 기능이 어떻게 나타나는지 살펴보려고 합니다. 스크립트를 작성하도록 프롬프트를 제공해야 할지는 모르겠지만, 아마 괜찮을 것 같아요. 결과를 확인해 보겠습니다.01:33:47

혹시 코어 SDK 파일로 가서 연락처 획득, 액션, 그리고 검증 과정을 보여주실 수 있을까요? 코드에서 어떻게 구현되어 있는지, 그리고 툴 설명을 어떻게 설정하는지 알려주시면 감사하겠습니다.01:34:01

네, 아직 SDK 부분은 진행하지 못했습니다.01:34:13

지금까지는 클라우드 코드에 API를 몇 개 넣어봤어요. 네, 네, 네, 맞아요. 제가 그걸 놓쳤다고 생각했어요. 아니, 아니, 아니, 네, 네, 그럼요, 알겠습니다.01:34:17

네, 그러니까 여기 보시면 좀 더 많은 정보를 주네요, 그렇죠? 그리고, 네,01:34:28

훨씬 많이 줬어요. 그러니까, 21마리의 포켓몬이 있다고 말하는 거죠? 음, 대략적으로 이 정도면 맞는 것 같아요. 제가... 생각해보니까...01:34:40

무슨 일이 있었죠? 아, 그냥 알고 있는 것 같아요. 네.01:34:49

아니, 그거 재미있네요. 뭐, 제가 이것저것 해본 적은 있어요. 아무튼, 음,01:34:56

네, 포켓몬은 현재 유통되는 상황인 것 같아서, 음, 좋다고 생각합니다.01:35:07

네, 그러니까, 결국 이 프로그램이 하려는 일은, 마치 대본을 써내듯이 진행하려고 하는 건데요. 너무 많은 생각을 하지 않도록 돕기 위해서죠. 그래서 이렇게 생각해요. ‘제가 할 일은… 음, Gen 2를 한번 살펴볼까요?’01:35:14

네, 여기 보시면 세대의 시작을 알고, API를 통해 이걸 가져오는 것을 알 수 있습니다.01:35:31

이전 API는 여기서는 안 쓰는 걸로 결정했네요. 그리고 나서 실행되죠, 그렇죠?01:35:43

클론 mb를 좀 더 개선해야 할 것 같아요.01:35:51

어쨌든, 200 플러스 포켓몬을 확인하고, 타입을 확인해서 정보를 가져오는 것도 할 수 있다는 걸 보실 수 있을 거예요.01:35:55

자, 이건 코젠을 사용하는 방법과 클라우드 코드를 이용해서 어떻게 하는지 간단하게 보여주는 예시입니다. 이 스크립트를 실행하고, 계속 진행해 보겠습니다.01:36:06

오른쪽으로 진행할게요. 그러면 결과를 보여드릴 수 있을 것 같습니다. 네, 지금 남은 시간이 대략 15분 정도 되는 것 같은데, 맞나요?01:36:19

네, 포켓몬을 플레이해요. 실은 제가 고려하고 있는 데모 중 하나인데, 클라우드 코드가 포켓몬을 플레이하는 거에요. 예를 들어 클라우드의 에이전트 버전으로 만들고 싶다고 해 볼게요.01:36:34

포켓몬을 플레이한다고 했을 때, 어떻게 할 것 같으세요? 음, 어떻게 할 것인지 생각해보자면, 아마도 내부 메모리에 접근할 수 있게 해주는 것 같아요. 음, 잘못된 거죠. 그리고 만약에 무언가를 찾고 싶다면요.01:36:44

파티였고, 메모리에서 그걸 검색할 수 있었어요. 포켓몬 레드 같은 경우는 굉장히 잘 배포되었고 리버스 엔지니어링이 된 게임이죠. 그래서 메모리에서 검색해서 마치 '이것이 포켓몬이다', '이렇게 되어 있다' 같은 정보를 찾을 수 있었던 것 같아요.01:36:58

지도 위치를 파악해야 합니다. 제가 이렇게 찾아가는 방식이죠. 독자님께서 직접 시도해보고 싶으시다면, 아마도 노드.js 기반의 GBA 에뮬레이터일 겁니다. 말씀드리지만, 구매하시는 것이 필요합니다.01:37:12

포켓몬 레드 버전을 해보시고, 네, 음, 좋은 예시네요. 하여튼, 모든 포켓몬을 만졌고, 타입들도 모두 나열되어 있습니다. 네, 가능합니다.01:37:26

이렇게 코드를 활용하여 생성하는 방식이 맞는지 확인해 보겠습니다. 간단한 예시를 통해 Clock Code를 사용하여 프로토타입을 만드는 것을 보여드릴게요. 좀 더 흥미로운 방식으로도 만들 수 있을 겁니다.01:37:38

데이터가 있어서, 시간을 좀 내고 싶습니다. 죄송하지만, 질문을 위한 시간을 확보하기 위해 간단한 예시를 보여드리려고 합니다. 예를 들어, 경쟁적인 포켓몬을 만들고 싶다고 해 봅시다. 경쟁적인 포켓몬은 많은...01:37:48

다양한 변수와 데이터를 가지고 있는데, 이건 마치 온라인 라이브러리에서 가져온 텍스트 파일과 같아요. 기본적으로 포켓몬과 그들의 기술 정보들을 모두 저장해두는 곳이죠.01:38:02

누구와 잘 어울리는지, 누구와 안 어울리는지, 그리고 어떤 포켓몬에게 약점을 보이는지 등등 이런 정보들이 있겠죠? 그래서 데이터가 정말 많아요, 그렇죠? 그리고 이 모든 정보가 텍스트 클라우드에 있는데, 클라우드 코드에는 실제로 이게 괜찮은 편이죠?01:38:17

데이터를 조금 더 넣을 수 있죠, 음, 보통은 데이터 검토 폴더에 넣거든요.01:38:31

혹시, 제가 덩쿠리(Venusaur)를 중심으로 팀을 구성하고 싶어요. 혹시 스모곤 데이터(Smogon data)를 기반으로 몇 가지 제안을 해 주실 수 있을까요?01:38:39

음, 그냥 이 온라인 API를 이용해서 진행해 보려고 하는데, 지금은 정확히 뭘 할지 잘 모르겠습니다. 이 쿼리는 처음 해보는 거라서요. 하지만, 한번 해보면 재미있을 것 같아요.01:38:53

네, 하지만 제가 하고 싶었던 것은 이 데이터를 꼼꼼히 살펴보면서, 처음 원리로부터 시작해서 이 데이터를 처음 보는 상태에서 어떻게 질문에 답할 수 있을지 생각해 보려고 했습니다.01:39:14

네, 질문 있으시면 편하게 말씀해주세요. 혹시 질문 있으신가요? 이 내용은…01:39:25

클라우드 코드를 정말 잘 활용하고 계신 것 같은데, 혹시 이 고객용 기본적인 기능 배포를 하지 않는다면, 클라우드 코드를 스웜 형태로 계속 실행해야 할까요?01:39:36

혹시 봇과 에이전트 SDK를 바로 사용할 수 있는 방법이 있을까요?01:39:48

네, 보여드리겠습니다. 아주 빠르게 에이전트 SDK를 사용하는 모습이 어떤지 말씀드릴게요. 저는 이미 파일 시스템 부분을 처리했습니다.01:39:55

다시 한번 파일 시스템을 컨텍스트 엔지니어링을 올바르게 수행하는 방법으로 생각해보시길 바랍니다. 제 실제 에이전트 파일은 50줄 정도 되는데, 대부분이 무작위적인 내용으로 채워져 있습니다.01:40:06

음, 접시 쪽은 아마 괜찮을 것 같아요. 이제부터는 다시 사용자 지정 스크립트 디렉터리 밖에서 스크립트를 작성하지 않기로 결정했습니다. 완전히 백엔드 코딩으로 되돌렸으니, 네, 그렇게 하려고요.01:40:20

음, 마치 그냥 이 쿼리를 실행하고, 작업 디렉터리를 받아, 그리고 반복적으로 실행하는 것 같은데요. 아마 이 부분을 어떻게 변환해야 할지 고민해 봐야 할 것 같습니다.01:40:31

여기서 사용할 수 있는 도구들은 당연히 있지만, 매우 간단해서 만약 이 기능을 실제 서비스에 적용한다면, 제가 가장 먼저 할 일은 '구름 환경에서 테스트를 해봤습니다' 라고 말하는 것일 겁니다.01:40:43

클라우드, 클라우드, 코드... 이렇게 하는 것 같네요. 제가 이 파일을 작성하고 거기에 넣으면, 두 가지 방법이 있습니다. 하나는 로컬 앱이...01:40:54

인공지능으로 다시 돌아온 이유는, 운영하는 데에 상당히 많은 부담이 있다고 생각하기 때문입니다. 예를 들어, 클라우드 코드는 프론트엔드 앱이죠. 사용자의 컴퓨터에서 작동하는 방식이고요. 제가 이 앱을 포켓몬 앱 형태로 배포한다면, '설치하면 앱을 사용할 수 있습니다' 이런 식으로 제공하는 것이겠네요.01:41:05

로컬 컴퓨터에서 작동하고 스크립트를 작성하는 것 같은데, 한 가지 방법이라고 생각합니다. 음, 다른 방법은 샌드박스에 호스팅하는 것입니다. 그리고 다시 한번 말씀드리지만, 여러 가지 방법이 있습니다.01:41:19

클라우드플레어처럼 사용하기 정말 편리한 다양한 샌드박스 제공업체가 있습니다. 에이전트 SDK를 사용하는 좋은 예시를 보여주고 있고, 샌드박스.스타트(sandbox.start)처럼 간단하게 시작할 수 있습니다.01:41:30

음, 번(like) 에이전트 도트 TS 같은 것들인데, 그거면 거의 다 되는 것 같아요. 예를 들어, 많은 부분을 추상화해 놓았으니, 샌드박스 같은 걸 실행하면 되는 거죠.01:41:40

그것과 소통하면서, 네, 저는 아주 흥미로운 내용들이 좀 있는 것 같고, 제가 시간을 내서 다 다루지 못했을 수도 있지만, 흥미로운 것들이 좀 있다고 생각합니다.01:41:50

질문이 있는데요, 네, 예를 들어서 이 서비스를 어떻게 이용하는지 궁금합니다. 사용자마다 샌드박스라고 하는, 일종의 환경을 구축하는 건데요. 제 생각에는 여러 가지 측면에서 최고라고 말씀드리고 싶습니다.01:42:02

여기서 해결해야 할 방법들에 대해 말씀드리겠는데, UI를 가진 에이전트를 만드실 때 한 가지 염두에 두셨으면 하는 점이 있습니다. 예를 들어, 제가…01:42:12

저와 포켓몬 에이전트는 사용자에 따라 유연하게 적용될 수 있는 사용자 인터페이스를 갖고 싶었습니다. 어떤 사용자들은 팀을 구성하고, 어떤 사용자들은 게임 플레이를 돕고, 또 다른 사용자들은 포켓몬 그림을 보고 싶어할 수도 있기 때문입니다.01:42:25

제 사용자에 실시간으로 적응하는 에이전트를 어떻게 만들 수 있을까요?01:42:36

제가 할 방식은 샌드박스에서 개발 서버를 두는 거예요, 그렇죠? 그리고 개발 서버는 포트를 노출할 거예요. 번들이나 노드 같은 걸로 실행될 수도 있겠죠.01:42:41

포트가 노출될 수 있고, 에이전트가 코드를 수정할 수 있으며, 지속적으로 새로 고쳐질 것입니다.01:42:51

사용자분께서 웹사이트와 상호작용하게 될 텐데요. 러블러블과 같은 많은 웹사이트 빌더들이 그렇게 작동하는 방식입니다. 샌드박스를 사용하고, 기본적으로는 개발 서버를 활용하는 거죠. 이러한 점을 고려하면…01:42:56

사용자분들을 위해 맞춤형 인터페이스를 원하신다면, 이 방법이 좋은 방법이 될 수 있습니다. 네, 한번 살펴볼까요? 한번 해볼게요. 네.01:43:08

네, 알겠습니다. 이 스크립트에서 기본적인 통계 정보와 제안 사항을 보여주시면 감사하겠습니다.01:43:24

이동 방식이나 팀원, 그리고 어떤 영향을 미쳤는지 확인할 수 있는 것 같습니다.01:43:33

네, 여기서 보시면, 얘가 시작하자마자 덩굴초를 찾기 시작하고, 그런 타입의 포켓몬이나 언급된 포켓몬들을 찾기 시작합니다. 그렇게 찾으면서 다른 포켓몬들도 함께 가져오는 것을 볼 수 있습니다.01:43:50

비너피츄가 팀원들과 상대 포켓몬들을 고려하고, 또 흥미로운 포켓몬들을 찾아보면서 같이 어울릴 만한 포켓몬이 있을지 조사해봤어요. 이런 식으로 여러 번 검색을 해봤고, 그걸 바탕으로…01:44:03

이 프로필에서 가장 흔하게 함께하는 팀원들을 찾아내고, 이를 분석하는 스크립트를 작성했습니다. 물론 텍스트 파일 기반으로 진행되었고, 텍스트 파일을 조금 더 전처리할 수도 있었겠지만, 지금은 거의 완료된 상태입니다.01:44:15

저에게도 흥미로운 분석이네요. 앞으로도 깃허브 저장소에 코드를 더 올리고 트위터에도 관련 내용을 올리려고 합니다. 저는 트위터 아이디가 trq212이고, 자주 트윗하는 편입니다.01:44:30

네, 확실히 에이전트 SDK 관련 내용이 대부분이었고, 네, 저희는 남은 시간이 대략 8분 정도 남았네요. 남은 시간은 질문에 답하는 데 사용하고 싶습니다. 어떤 질문이든 편하게 해주세요. 더 많은 프로토타입을 보여드리지 못해서 죄송합니다만.01:44:43

클로드 연극과 관련해서 말씀드리자면, 에이전트의 Z(선택 기준)를 활용하여 팀 구성 시 좀 더 신중하게 캐릭터를 고려해 볼 수 있을까요?01:44:58

네, 클로드에게 포켓몬처럼 행동하도록 시켜보겠습니다. 클로드 코딩이 포켓몬처럼 작동하게 하고 싶어요. 재미있을 것 같아요. 클로드에게 포켓몬처럼 행동하게 하는 것은, 최대한 순수한 추론 과제로 유지하는 것이 좋다고 생각합니다.01:45:06

다른 질문 있으시면 네, 네, 말씀해주세요.01:45:17

네, 전 전체적으로 봤을 때, 특히 지금 시점에서는 그렇게 생각합니다.01:45:30

아시다시피 모델들이 이제야 어느 정도 자율성을 갖추기 시작하면서, 저희는 가장 지능적인 모델을 확보하는 데 집중하고 있는데, 그게 조금 가격이 있는 편입니다.01:45:42

일반적으로 뵙고 좋아하게 되면, 이런 종류의 빠른 비즈니스 소프트웨어는 높은 가격을 정하여, 정말로 어려운 문제를 겪고 있는 소수의 고객에게 서비스를 제공하는 것이 더 좋다고 생각합니다. 그래서 저는 아직도 괜찮다고 생각하며, 아마도 그렇게 되리라고 예상합니다.01:45:52

알아야 할 어려운 사용 사례들이 있을 거라고 생각하지만, 가장 중요한 첫 번째 단계는 사람들이 돈을 지불할 의향이 있는 문제를 해결하는 것입니다. 그 다음으로, 네, 그렇게 하면 괜찮을 것 같습니다.01:46:05

구독 방식이든 토큰 기반 방식이든, 결국 사용자들이 제품을 얼마나 자주 사용할 것인지에 따라 결정될 것 같아요. 클라우드 코드는 워낙 사용량이 많은 반면, 다른 서비스들은 가끔씩 사용하는 경향이 있을 테니까요.01:46:19

저희는, 저희가 제한된 요청 횟수를 드리고, 그걸 초과하시면 사용량에 따른 요금을 부과하는 방식으로 운영하고 있습니다.01:46:32

저도 그렇게 생각합니다만, 사용자 기반에 따라 상당히 달라질 수 있고, 사용자들이 어떻게 반응할지에 따라서도 영향을 많이 받을 것 같습니다. 다만, 수익화는 초기 단계부터 고려하고 설계에 반영하시는 것이 좋다고 말씀드리고 싶습니다.01:46:39

아시겠지만, 요원 주변에 있어서 약속을 돌려받기가 쉽지 않습니다. 네, 뒤에 있어서요. 네.01:46:52

음, 이야기가 정말 많네요. 사람들은 정말 좋고, 배송도 진행하고 있습니다. 훅(hooks)은 특히나, 특정 맥락에서 결정적인 검증을 수행하는 방법입니다.01:47:06

음, 아시다시피 저희는 이 훅들을 이벤트로 발생시키고, 에이전트 SDK에서 이 훅들을 등록할 수 있습니다. 등록하는 방법에 대한 가이드와 예시들이 있습니다. 훅을 활용할 수 있는 몇 가지 예시가 있습니다.01:47:17

예를 들어 음, 네, 스프레드시트처럼 매번 확인할 수도 있고요. 또는, 제가 에이전트와 함께 일하고 있는데 에이전트가 스프레드시트 작업을 수행하는 경우라고 말할 수도 있겠습니다.01:47:27

사용자께서 스프레드시트도 변경하셨네요. 훅을 사용할 만한 흥미로운 지점이 될 것 같아요. 사용자가 변경한 내용을 각 툴 호출 후에 삽입하는 방식으로 구현할 수 있을 것 같습니다.01:47:39

그래서 실시간으로 상황 변화를 흥미로운 방식으로 적용하고 계시는군요.01:47:50

네, 그러니까 훅에 대한 설명이 문서에 더 자세히 나와있을 거예요. 그리고 나서도 언제든지 관련해서 이야기할 수 있습니다.01:47:56

네, 더 질문 있어요. 네, 네.01:48:07

네, 알겠습니다. 네.01:48:22

네, 그렇습니다. 음, 예를 들어서 이 프로토타입 작업을 마치셨다고 가정해 봅시다. 작동하는 것을 발견하셨다면, 저는 아마 클라우드.md 같은 곳에 저장할 것 같습니다. 물론, 한 번 이 작업을 시도했을 때 제 API를 직접 사용하지 않고 자바스크립트를 작성했었어요.01:48:38

제가 cloud.md 파일을 좀 더 구체적으로 작성해서, 예를 들어 '이걸 사용해보세요' 또는 '이런 점을 고려해보시는 게 좋을 것 같아요'와 같이 표현하는 건 어떨까요? 그리고 cloud.md 파일에 그 이유를 명확하게 설명하는 것도 필요할 것 같습니다.01:48:52

필요한 보조 스크립트들을 준비하신 후, agent.ts 스크립트와 같이 SDK를 실행할 수 있도록 작성하시면 됩니다. 그렇죠? 더 궁금한 점 있으십니까?01:49:05

그런데 두 번이나 시도하더니, 마침내 비교표를 보여주네요. 하지만 단순히 배포 상태 때문인 것 같아요.01:49:26

그 문제에 대해 조언을 드릴 말씀이 있을까요? 네, 좋은 질문이라고 생각합니다. 음, 솔직히 말씀드리면 다소 복잡한 부분이 있는 것 같습니다.01:49:31

음, 제 생각에는, 혹시 에이전트가 답을 알고 있는데, 마치 그걸, 그러니까, 반박하고 싶을 때, 이런 식으로 말이죠. 예를 들어, '아니요, 지금은 9세대이고, 금성 지구의 능력치(stats)가 바뀌었습니다.' 라고요.01:49:37

그리고 새로운, 음, 캐릭터 유형 같은 게 있는데, 이건 좀 어렵네요, 정말 그렇게 생각해요.01:49:49

하나의 방법은 훅(Hook)을 사용하는 것입니다. 예를 들어, '혹시 스크립트를 작성하지 않고 응답을 반환했는데, 확인해 볼 수 있습니다.'라고 말씀드릴 수 있겠습니다.01:49:55

음, 스크립트 작성하도록 피드백을 줄 수도 있고요. 데이터는 꼭 읽어야 한다, 그렇죠? 그런 피드백을 줄 때 후크를 사용할 수도 있어요.01:50:07

클라우드 코드에서와 마찬가지로, 이런 규칙들이 있습니다. 파일을 쓰기 전에 반드시 읽어야 한다는 규칙이죠.01:50:14

음, 조금 더 결정론적인 요소를 추가하는 건 어떨까요? 제가 말씀드린 것처럼, 결국에는 예술적인 부분이라고 생각합니다. 아시죠, 때로는 그래야 할 때가 있고, 마치 말 타는 것처럼요, 아마도 그렇겠죠. 그리고 회색빛도 있구요. 혹시 큰 코페이스를 어떻게 처리하고 계신가요?01:50:20

음, 방금 말씀하신 것처럼 5천만 라인 이상의 코드베이스를 다루고 있어서, 일반적인 도구로는 효과를 보기 어려워요. 그래서 제가 직접 의미론적 인덱싱 같은 것을 구축해서 도움을 받으려고 합니다. 혹시 엔트로픽이나 비슷한 접근 방식이 있을까요?01:50:35

그것이 제품에 좀 더 자연스럽게 녹아들 수 있는 방법에 대해 어떻게 생각하시는지, 예를 들어, 제가 쓰고 있는 내용이 사라질 수도 있거나, 여러분은 어떻게 생각하시는지, 마지막으로 질문입니다.01:50:49

몇 달 후에 떠나실 생각처럼, 대체로 그렇습니다. 네, 그렇게 생각합니다.01:50:58

시맨틱 검색은 클라우드 기반으로 코딩된 질문이며, 질문의 성격은 다소 까다롭지만 답변해 드리겠습니다. 시맨틱 검색의 단점이라고 하면, 좀 더 취약하다는 점이라고 생각합니다. 저희 같은 경우, 그와 같은 트레이드오프를 고려해야 합니다.01:51:08

인덱싱 및 검색 기능이 있는데, 꼭 필요한 건 아니지만 모델이 시맨틱 검색에 대해 훈련되지 않았기 때문에 문제가 될 수 있다고 생각합니다. 그래프 기반 모델은 쉽게 구현할 수 있지만, 시맨틱 검색은 그렇지 않다고 생각합니다.01:51:18

검색을 구현하실 때, 특히 매우 큰 코드 베이스에서 사용자 정의 쿼리를 사용하시는 경우가 많으신 것 같습니다. 저희는 많은 고객분들이 큰 코드 베이스에서 작업하고 계신다는 것을 알고 있습니다. 제가 보기에는, 보통은 그냥 체계적으로 접근하시는 것 같습니다.01:51:30

시작하실 때, 말씀하신 디렉토리가 제대로 설정되었는지 확인하는 절차나 연결, 후킹 등의 과정을 거쳐서 진행해야 합니다. 저희는, 사용자 맞춤 설정 같은 건 따로 제공하지 않습니다.01:51:44

네, 강아지 사료 복제 코드 맞아요. 네, 네, 마지막 질문이네요. 안타깝게도 마무리해야 할 것 같습니다. 그럼 타릭에게 박수 부탁드립니다, 여러분.01:51:57