제브는 정말 놀라워요.00:00

최근에 출시되었고, System 1 모델이라고 불리는 AI 모델의 한 종류를 대중화시켰어요. 이 모델은 텍스트를 생성하는 대신00:02

결정을 내리는 데 특화되어 있어서, 클로드나 GPT 같은 LLM과는 완전히 달라요.00:09

그래서 지금 인터넷에서 모두가 공유하는 새로운 활용 사례들이 많이 생겨났어요.00:16

사람들은 제브를 활용한 정말 재미있고 멋진 사용 사례들을 많이 공유하고 있지만, 특히 저의 다이나미스00:22

커뮤니티에서 듣는 이야기는 그 사용 사례들이 재미있긴 하지만 항상 가장 실용적이지 않다는 거예요.00:29

지금 당장 AI 워크플로우에 통합해야겠다고 생각할 만한 것들이 많지 않아요.00:33

그래서 이 영상을 만들어서, 특히 AI 코딩을 위한 놀라운 제브 사용 사례들을 빠르게 보여드리고 싶어요.00:38

AI 코딩 워크플로우를 더 빠르고 토큰 효율적으로 만들어주는 것이 중요해요. 특히 현재 레이트 제한이 심각한 상황에서요.00:45

AI 최신 동향을 주시하고 계시다면, 제브에 대해 들어보셨을 가능성이 높고 아마 직접 사용해 보셨을 수도 있을 거예요.00:52

JEV는 이런 종류의 의사 결정 모델이 처음은 아니지만, 그것은 또 다른 영상에서 다룰 내용이에요.00:59

핵심은 JEV가 정말 강력하다는 거예요. 작동 방식은 특정 상황을 입력하는데, 그걸 상태라고 부르더라고요.01:04

그리고 나서 객관식 질문 목록도 함께 제공해야 해요.01:11

그리고 동시에 각 질문에 대한 확률을 답하는데, 기본적으로 그게 신뢰도 점수예요.01:14

사실 이미 LLM으로 이 작업을 할 수 있어요, 특히 구조화된 출력과 함께라면요.01:21

하지만 이후 워크플로우에서 활용할 수 있는 결정을 내리게 할 수 있죠.01:26

JEV가 정말 멋진 이유는 의사 결정 속도가 LLM보다 20배에서 200배 빠르기 때문이에요.01:30

그리고 비용도 40배에서 1,000배 저렴해요.01:37

물론 큰 범위는 JEV와 비교하기 위해 다양한 LLM을 사용할 수 있다는 점이에요.01:39

어떤 LLM을 사용하든,01:44

Jev는 어떤 종류의 결정을 내릴 때 더 정확하고 빠르고 저렴할 거예요.01:47

그래서 큰 틀에서 봤을 때, Jev를 결정권자로 생각하면 무한한 가능성이 있어요01:52

그걸 활용할 수 있는 방법이 정말 많아요. 그래서 여기서는 좀 더 구체적으로 보여드리고 다양한 아이디어를 드리고 싶어요01:58

매우 실용적인 방법으로 사용할 수 있어요. 지금 이 Jev 사용 사례 하나하나가 제가 통째로 비디오를 만들 만할 만큼 가치 있을 정도예요02:05

구축하고 통합하는 방법에 대해 자세히 다룰 수 있어요. 하지만 지금은 좀 더 큰 그림을 보여드리고 싶어요.02:12

이걸 짧고 굵게 유지하면서 영감을 드려서 여러분도 몇 개를 골라 직접 만들어볼 수 있도록 하고 싶어요.02:16

그리고 이번 주 금요일에 Dynamis 커뮤니티에서 이 사용 사례들을 더 깊이 있게 다루는 워크숍을 진행할 예정이에요.02:22

관심 있으시면 확인해보세요. 네, 말씀드린 것처럼 곧 더 많은 콘텐츠가 나올 예정이고, Jev에 대해 더 깊이 파고들 거예요. 왜냐하면 저에게는 정말 흥미로운 일이니까요.02:29

사실 이 말은 제가 Jev에 대한 첫 번째 비디오에서 했었어요. 꽤 오랫동안 처음 보는 AI 모델이에요02:36

진심으로 기대하고 있어요. 이 네 가지 사용 사례를 살펴보면 왜 그런지 알게 되실 거예요.02:41

자, 그럼 바로 시작해 볼까요.02:46

제 AI 코딩 워크플로우에서 지금 제가 가장 좋아하는 JEV 활용 사례는 보안이에요.02:48

왜냐하면 AI 코딩 어시스턴트가 해서는 안 될 일을 너무 쉽게 하려고 하거든요. 아마 여러분도 보셨을 거예요.02:54

예를 들어 환경 변수를 읽거나 폴더 전체를 삭제하는 것처럼요. 글로벌 규칙이나 스킬에 그렇게 하지 말라고 설정했더라도요.03:00

특히 대화 컨텍스트가 점점 커지거나, 우회적인 방법을 제시하는 프롬프트를 사용할 경우03:07

어떻게든 이런 일들을 수행할 방법을 찾아낼 거예요.03:14

그래서 에이전트가 파괴적인 행동을 하지 못하도록 가드레일이 필요해요.03:16

그리고 JEV는 바로 그 가드레일이 될 수 있어요.03:21

코딩 에이전트에게 이러한 가드레일을 구현하는 가장 인기 있고 효과적인 방법은 훅스를 사용하는 거예요.03:24

처음에는 Cloud Code에서 소개되었지만, 이제는 거의 모든 코딩 에이전트가 훅스라는 개념을 가지고 있어요.03:29

코딩 에이전트의 수명 주기에서 발생하는 다양한 이벤트에 자동화를 연결할 수 있는 곳이죠.03:35

가장 인기 있는 이벤트는 도구 사용 전이에요.03:41

에이전트가 파일을 읽거나 명령을 실행하는 등의 작업을 수행하기 전에 자동화를 실행할 수 있어요.03:44

기본적으로 해당 내용을 분석하여 에이전트의 작업을 차단하거나03:49

계속 진행하도록 허용할 수 있죠. 그래서 지금 어디로 가고 있는지 아시겠죠, 왜냐하면 가장 인기 있는 사용 사례 중 하나는03:54

도구 사용 전 훅을 사용하여 에이전트의 작업을 분석해 보는 것이거든요.03:58

`.env` 파일을 읽을지 판단하려고 하는 거죠?04:04

우리의 비밀이 코딩 에이전트의 컨텍스트에 노출되는 것을 원치 않아요.04:07

그래서 해당 작업을 차단하기 위해 오류 코드를 내보낼 수 있는 기회를 얻는 거죠.04:11

에이전트는 다른 무언가를 해야 해요. 예를 들어 `.env.example` 파일을 읽는 대신이죠.04:17

이제 이 후킹의 문제는04:22

제브까지는 매 콜을 LLM으로 분석해야 하거나, 혹은04:25

일종의 정형화된 프로세스와 정규 표현식을 사용해야 합니다. 어쨌든 비싸거나 정확하지 않을 거예요.04:32

자, 이제 LLM을 사용하는 아이디어를 버리죠. 에이전트가 하려는 모든 행동을 분석해야 한다면04:38

한 달에 수백 또는 수천 달러를 소비해서 가끔 발생하는 민감한 호출을 막아야 할 거예요.04:45

그래서 저는 제브까지 정규 표현식을 사용했어요.04:51

그래서 에이전트가 무엇을 하려고 하는지 파악하기 위해 패턴 매칭만 수행하는 훅을 가지고 있어요04:55

구글 자격 증명을 읽거나, .env 파일을 읽거나, 폴더를 삭제하는 것과 같은 일을 하려고 하는지04:59

무엇이든 간에 문제가 있습니다. 에이전트가 이러한 파괴적인 작업을 수행할 수 있는 방법이 너무 많기 때문입니다.05:04

파일을 직접 읽거나, 파이썬 스크립트를 작성하여 실행할 수 있기 때문입니다.05:10

그러다 보면 bash 명령어도 있고, 정말 다양한 방법이 백만 가지가 넘어요.05:15

그래서 엄청나게 긴 목록이 있는데, 이걸로도 모든 걸 잡아내지는 못해요.05:18

거짓 긍정 결과도 많고요. 그래서 저는 이 사전 도구 사용 후킹을 가져와서 이걸 대체했어요.05:22

제브가드로 교체했고, 조금 있다가 통계도 보여드릴게요.05:27

매우 비용 효율적이고 신뢰성도 높아요. 시스템 원 모델의 경우에도 다시 한번 상태와 객관식 질문 목록을 제공해요.05:31

객관식 질문들을 통해 에이전트의 행동으로 인해 발생할 수 있는 모든 문제에 대해 '이렇게 되는 건가?'라고 물어봐요. 예를 들어, 비밀 정보를 노출시키고 있나요?05:37

정답은 참 또는 거짓이라고 답하게 되고요. 추가적인 맥락을 위한 지침도 제공해요.05:44

이건 상태의 일부이고, 그리고 데이터를 파괴하고 있나요?05:48

예를 들어 폴더 전체를 삭제하거나, 프롬프트 인젝션 공격을 통해 민감한 데이터를 외부로 유출하고 있나요?05:51

또 다른 멋진 기능은 에이전트가 원래 목표에서 벗어나는지 분석할 수 있다는 거예요.05:58

그래서 이 사전 도구 사용 후킹을 더 많이 활용할 수 있어요.06:03

단순히 보안뿐만 아니라 일반적으로 다른 모델을 심판으로 두어 우리가06:06

목표대로 진행하고 있는지 확인하는 데 사용할 수 있어요. 그리고 상태에 대해서는,06:11

제브의 주요 입력인 상황인데, 도구 이름과 효과를 제공하고,06:15

도구에 대한 입력이나 인수와 현재 작업 디렉터리도 알려주어서06:19

전체적인 그림을 보여주고, 그래서 제가 제브를 사용할 때는 오픈 루터06:24

새로운 의사 결정 엔드포인트를 통해 사용하고, 이 상태와 제가 위에서 보여드렸던 모든 질문을 함께 제공해요.06:29

제공하고 있어요. 제브가 막 출시되었기 때문에 이 후킹을 조금밖에 사용하지 않았지만, 초기 결과는 정말 놀라워요.06:34

이전 버전의 후킹은 정규식을 사용하여 위험한 호출을 많이 차단하지 못했다는 것을 알 수 있어요.06:41

물론 '위험'은 주관적이에요. 전반적으로 이 후킹에 만족하고 있지만, 제가 겪었던 주요 문제는06:47

가짜 양성 반응이 문제가 되었어요. 차단해서는 안 될 것들을 차단하는 경우도 있는데, 예를 들어06:54

.env 파일을 마크다운 문서에 쓰는 것처럼요. 그리고 LLM을 사용하는 경우에는 정말06:58

잘 작동해요. 가짜 양성 반응이 많지 않고 위험한 호출 대부분을 차단하지만, Haiku처럼 빠르고 저렴한 것을 사용하더라도07:04

1초가 넘게 걸려요.07:08

분석당 약 1센트 정도밖에 안 들지만, 에이전트가 매일 수천 번의 호출을 할 경우에는 그 금액이 눈덩이처럼 불어납니다.07:12

매일 수천 건의 호출을 하는 경우입니다. 그리고 Jev를 사용하면 거의 모든 위험한 호출을 차단하고07:17

거의 가짜 양성 반응이 없어요. 분석당 0.25초밖에 걸리지 않고07:23

분석 비용도 아주 적게 들기 때문에 비용 효율적이고 빠릅니다.07:29

본질적으로07:33

이런 종류의 결정에 필요한 LLM의 추론 능력을 제공하지만, 무료처럼 느껴져요.07:35

물론 완전히 무료는 아니지만, 아무런 부담도 주지 않아요.07:40

자, 다음 사용 사례는 게임 플레이 테스트이고, 이는 실시간으로 반응하거나 즉각적인 결정을 내려야 하는 모든 유형의 애플리케이션에 적용돼요.07:45

모델이 즉흥적으로 결정하거나 실시간으로 반응해야 하는 경우를 말이죠. 저는 단순히07:50

비디오 게임을 예로 들기만 하는데, Jev가 게임하는 모습을 보는 건 정말 멋있고, 실제로 제가 만들고 있는 것이기도 하고요.07:56

제가 실제로 만들고 있어요. 그래서 게임과 같이 어떤 경우든 60 프레임08:01

초당 또는 30프레임 초당, 대규모 언어 모델은 너무 느려서 어떤 것에든 반응하기에는08:06

장면을 분석하여 결정을 내릴 때쯤이면 장면이 이미 지나갔겠죠?08:12

예를 들어 캐릭터는 게임에서 죽게 될 거예요. 하지만 Jev는 따라갈 수 있죠.08:16

보는 건 정말 놀랍습니다. 그리고 이것은 저희가 항상 AI 코딩 워크플로우에서 그08:20

검증 단계를 갖고 싶어하기 때문에 매우 실용적입니다. 그래서 비디오 게임의 경우, 다음을 만들고 나면08:26

기능을 만들 때마다 모델이 실제 사용자가 게임을 하는 것처럼 플레이할 수 있기를 원해요.08:31

제브가 나오기 전까지는 정말 현실적이지 않았어요. 자, 한번 보세요. 제가 지금 만들고 있는 게임 중 하나를 제브가 플레이하는 실시간 예시가 있어요.08:35

지금 개념 증명용으로 만들고 있는 게임 중 하나를 플레이하고 있는데, 제가 직접 플레이하는 것처럼 보여요.08:41

캐릭터가 공격하고, 피하고, 맵을 돌아다니고 있어요. 제브가 내리는 결정들을 볼 수 있죠.08:46

여기 왼쪽에 제브가 내리는 결정들이 있는데, 저희가 제공하는 모든 가능한 행동에 대한 확률이 표시되어 있어요. 다시 한번 말씀드리지만, 상태에 관한 것이에요.08:50

게임 내 모든 사람의 위치를 나타내는 상태이고, 그다음은 어떤 움직임을 할지 결정하는 것이죠?08:57

키보드를 놔도 지금 제가 직접 플레이하는 것처럼 보여요.09:02

정말 멋져요. 제브가 결정을 내리고 게임 상태를 처리하는 동안, 전반적으로 상황이 어떻게 진행되고 있는지 분석할 수도 있죠.09:06

그에 맞춰 조치를 취할 수 있겠죠?09:13

게임하면서 실제로 버그를 발견할 수도 있죠. LLM이 절대 할 수 없는 일이에요.09:15

단독으로 유닛 테스트를 실행하는 것만으로도 가능하고, 게임에 새로운 기능을 추가하면서 실제로 이것을 사용해 왔어요.09:20

LLM이 게임을 플레이할 수 없기 때문에, LLM 자체로는 잡지 못했던 버그를 실제로 잡아냈어요.09:27

물론 다른 테스트나 제가 만든 하니스를 실행할 수도 있지만, 그것은 좀 더 결정적인 방식이고09:33

playing the game as a user actually would. And so the important thing is we still have to use a09:39

LLM을 이용해서 JEV를 위한 테스트 환경을 구축해야 하잖아요.09:43

게임 상태를 JEV의 입력으로 어떻게 변환할지 알아내야 하잖아요.09:47

어떤 옵션을 제공해야 다양한 움직임을 수행할 수 있을까요? LLM으로 미리 구축하지만, 이후 모든 테스트는09:52

JEV를 사용하게 돼요. 그래서 정말 빠르고 안정적이며 비용 효율적이에요.09:59

비디오 게임에서 시도해 봤던 또 다른 방법은 LLM이 게임 속도를 늦추도록 하는 거예요.10:03

그러면 프레임별로 게임을 플레이할 수 있어요.10:09

그게 제가 게임을 사용자처럼 플레이하게 하려는 방법이었는데, 상상하셨겠지만 매우 느리고 비쌌어요.10:13

엄청나게 느리고 비쌌습니다. 이제 저희가 이 사용 사례들을 살펴보면서 패턴이 나타나는 것을 보실 수 있기를 바라요.10:18

이러한 사용 사례를 살펴보고 있는데, 저희는 절대 JEV만 사용할 일이 없을 거예요.10:24

정말 강력해요10:28

LLM과 함께 사용하면 좋거든요. 왜냐하면 JEV는 의사 결정을 내리는 데 정말 뛰어나지만,10:30

처음부터 결정을 구성하거나 실제로 실행할 수는 없어요.10:36

그래서 JEV를 사용하는 가장 좋은 방법은 일반적으로 대규모 언어 모델에 대한 호출 사이에 넣어두는 거예요.10:40

예를 들어 게임 플레이 테스트의 경우, LLM이 하니스를 구축하고 Jev가 게임을 플레이하면서 발견한 버그에 대해 조치해요.10:46

게임에서 버그를 발견할 때요. 아니면 보안의 경우, 코딩 에이전트가 다양한10:52

액션을 수행하고, Jev는 액션을 분석하고, 차단되면 에이전트, 즉 LLM은 다른 방법을 찾아야 해요.10:57

다른 것을 해야 하는 거죠? Jev은 저희 워크플로우의 끝이 아니에요.11:02

항상 저희 워크플로우의 일부를 더 빠르고 효율적으로 만들어주죠.11:07

이제 또 다른 좋은 예시가 브라우저 테스트라는 세 번째 사용 사례로 이어집니다.11:11

AI 코딩 워크플로우의 검증 단계에서 모델을 사용하여 웹페이지를 사용자처럼 탐색하고 조작합니다.11:16

게임 플레이 테스트와 매우 유사하지만, 일반적으로 대규모 언어 모델은 이 부분에서 어느 정도 괜찮은 성능을 보여왔습니다.11:23

비디오 게임과 달리 웹사이트의 이벤트에 대해 실시간으로 응답할 필요가 없기 때문입니다.11:29

그래서 시간을 내어 페이지를 분석하고 다음 작업을 선택할 수 있습니다.11:34

하지만 예상하셨겠지만, Jev에 비해 LLM을 사용하는 것은 여전히 느리고 비용이 많이 듭니다.11:41

그리고 Jev는 이와 같은 브라우저 자동화에서 더욱 안정적입니다.11:47

아마도 Playwright MCP나 Vercel의 에이전트 브라우저 CLI와 같은 도구를 사용하여 LLM으로 브라우저 테스트를 수행하실 겁니다.11:51

이제 많은 오픈 소스 도구들이 나오고 있는데, 같은 종류의 방식으로 LLM 대신 Jev를 사용하고 있어요.11:58

굉장히 잘 작동합니다. 다양한 웹사이트에서 Jev가 클릭하는 모습을 보여주는 멋진 예시들이 많아요.12:04

기억해야 할 가장 중요한 점은 항상12:10

Jev를 모든 것에 사용할 수 있는 기회가 없다는 거예요. 왜냐하면 Jev는 LLM처럼 텍스트를 생성할 수 없으니까요.12:14

따라서 웹사이트에 자유 형식의 텍스트 입력을 요구하는 작업이 있다면, 일반적으로 워크플로우의 일부로 대규모 언어 모델이 필요해요.12:20

가능한 한 많이, 무엇에 집중해야 할지 또는 어떤 버튼을 클릭해야 할지와 같은 결정을 내릴 때 Jev를 사용하는 것이 좋아요.12:27

그러므로 이제 브라우저 자동화 워크플로우의 대부분은 Jev에 의해 처리되어야 해요.12:34

설명란에 이 GitHub 저장소 링크를 첨부할게요. 제가 지금까지 본 최고의 오픈 소스 프로젝트예요.12:39

Jev 브라우저 사용을 위한 것이지만, 네, 많이 있어요. 직접 만들 수도 있고요.12:44

테스트하면서 Jev를 활용해 제가 직접 브라우저 자동화를 만들어봤어요.12:48

여기 이 앱처럼, 지금 운영 중인 DynaChat입니다.12:52

chat.dynamist.ai로 가서 이 에이전트와 대화할 수 있습니다. 기본적으로 제 유튜브 콘텐츠 전체를 검색할 수 있어요.12:55

그리고 Dynamis 커뮤니티에서 사용하는 동일한 이메일로 로그인하면 제 워크숍과 강좌 콘텐츠도 가져와요.13:01

정말 멋진 앱이에요. 다양한 기능을 구축하고 Jev가 사용자와 똑같이 처리하는지 테스트해 봤습니다.13:08

지루하게 설명하지 않겠습니다. 지금 전체 테스트 실행을 보여드리겠지만, 이 사이트에서 Jev가 작동하는 모습을 빠르게 보여드리고 싶어요.13:14

입력으로 보이는 모든 텍스트는 LLM에서 미리 생성된 것이지만, 나머지는 실시간으로 결정하고 있어요.13:20

채팅 상자에 클릭하고, 로그인 버튼을 누르는 것과 같은 모든 행동은 LLM에 의해 분석될 수 있어요.13:25

LLM이 이후에 버그가 있는지 확인하고 반복할 필요가 있는지 판단해요.13:33

좋아요, 여기 JEV의 네 가지 사용 사례 중 마지막은 워크플로우 분류입니다.13:36

이것은 시간이 지날수록 점점 더 중요해지고 있어요.13:41

저는 워크플로우가 동적이었으면 좋겠어요. 예를 들어, 항상 같은 LLM을 사용하고 싶지는 않아요.13:44

작업 난이도에 따라 달라지죠. 그래서 토큰 효율성을 위해 시작 부분에13:51

어떤 모델 레벨을 사용해야 하는지 분류하는 것이 필요해요.13:57

또 다른 좋은 예는 때때로 들어오는 작업 유형에 따라14:01

다른 기술이나 단계를 사용해야 할 때가 있어요. 그래서 아주 명확한 예는 GitHub 이슈를 작업하고 싶을 때에요.14:06

버그를 조사하고 수정해야 할 수도 있고, 기능을 계획하고 구축해야 할 수도 있죠.14:13

그래서 제가 직접 그 결정을 내리고 싶지는 않아요. 제 AI 코딩 워크플로우와 함께 확장되지 않을 거예요.14:19

그것을 분류하고 워크플로우를 처음부터 안내할 무언가가 필요해요.14:24

그래서 Jev가 필요한 거예요. 그리고 제가 설명하는 이 정확한 워크플로우는 다양한 분류 단계를 포함하고14:28

아콘 워크플로우로 만들었어요. 그래서 제 채널에서 아콘에 대해 많이 다뤘어요.14:34

이건 제가 만든 오픈 소스 하니스 빌더인데, 다양한 작업들을 훨씬 쉽게 더 큰 규모의 AI 코딩 워크플로우를 만들 수 있게 해줘요.14:38

이 영상에서 다루었던 다양한 작업들을 포함하고 있고, 물론 제 Archon 워크플로우에 Jev를 통합해 왔어요.14:45

여기서 보고 계시는 건 그래프 시각화인데, GitHub 이슈를 입력받아요.14:49

그리고 Jev를 이용해서 두 가지를 분류하는데, 이 작업을 완료하는 데 어떤 수준의 모델이 필요한가요?14:55

아마 아주 간단한 작업일 수도 있고, Sonnet 5 같은 걸 그냥 사용할 수 없을 수도 있으니까요.15:00

그리고 라우팅을 결정하기도 해요. 제가 앞서 말씀드린 것처럼 이건 버그라서 조사하고 수정해야 하나요?15:04

아니면 계획하고15:10

구현해야 하는 기능인가요? 그래서 이건 Archon 워크플로우 전체를 구성하는 YAML 파일이고, 각15:12

Jev를 호출하고 싶은 단계마다 인자를 전달하는 이 파이썬 스크립트가 있어요.15:18

결정을 내고 Jev에게 질문을 던지고, 그러면 워크플로우의 나머지 부분이 Jev의 출력에 따라 작동할 거예요.15:23

Jev에 대해서, 파이썬 스크립트를 빠르게 보여드릴게요. 어떤 질문들을 보내고 있는지 확인할 수 있거든요.15:28

Jev에 보내는 질문들이 맨 위에 있어서, Jev가 엄청난 양의 질문을 병렬적으로 처리할 수 있다는 점이 정말 강력해요.15:32

저렴한 비용으로 답변해 줘요. 예를 들어, 이 GitHub 이슈는 어떤 작업을 요구하나요?15:38

버그인지 기능인지 판단해서 나머지 워크플로우에서 사용할 기술을 결정하는 건가요?15:43

워크플로우인가요? 작업 난이도에 따라 어떤 모델 티어를 사용할지 결정해야겠죠?15:47

빠른 모델을 사용해야 할까요? 예를 들어, GPT-6 Terra나 표준 모델인 Sonnet 5 또는 GPT-6 Soul 같은 것들이 있죠.15:52

아니면 강력한 모델인 Opus 5.5나 GPT-6 Astra를 사용할 수도 있겠죠.15:58

이해하셨죠? Jev가 그런 판단을 내리고 있고, 제 테스트 결과 전반적으로 아주 잘 수행하는 것 같아요.16:02

작업의 난이도와 작업 유형을 이해하고 있거든요.16:08

그래서 이 특정 실행으로 돌아가서, 분류 결과 버그이며 조사해야 한다는 결론을 내렸어요.16:11

그리고 티어 선택 부분에서는 로그를 빠르게 확인해 볼게요.16:17

알아보기 힘들 수도 있지만, 다음 단계가 실행되었을 때 표준을 조사했고, 즉 이 모델의 중간 티어를 사용하고 있었어요.16:21

모델의 중간 티어였어요. 제가 선택한 건 Sonnet 5 같은 거죠.16:27

물론 제가 여기서 진행한 모든 Jev 테스트에 대해 직접 판단을 내렸습니다.16:32

그래서 이 Archon 워크플로우를 12번 실행했는데, 매번 Jev가 내린 결정에 완전히 동의했어요.16:36

처음에 분류한 내용들이요. 풀 리퀘스트 검토를 위한 별도의 Archon 워크플로우도 있어요.16:41

풀 리퀘스트를 검토하기 위해 분류를 먼저 사용해서 어떤 종류의 리뷰가 필요한지 알아내는 거죠?16:46

이게 전체 아키텍처 검토가 필요한 큰 문제인지, 아니면 빠르게 검증할 수 있는 간단한 작업인지 판단하는 거죠?16:51

빠르게 검증해야 하는 간단한 작업인지요. 완벽하진 않았지만, 16번 중 15번이나 정확했어요.16:55

꽤 괜찮은 결과이고, 여기 비용을 보면 LLM에서 일반적으로 드는 비용보다 훨씬 적어요.17:00

그리고 다시 말씀드리지만 풀 리퀘스트당 32센트인데, 특히 아콘과 같은 프로젝트에서는17:05

아콘처럼 매주 수십에서 수백 개의 풀 리퀘스트와 이슈를 처리하는 경우에는요.17:10

이것으로 끝입니다. 제이V를 AI 코딩 워크플로우에 사용하는 제가 가장 좋아하는 네 가지 사용 사례예요.17:15

이 중에서 특정 주제에 대한 전용 영상을 만들고 싶다면 댓글로 알려주세요,17:21

이것들을 워크플로우에 통합하는 데 더 자세히 도와드릴 수도 있고요. 그리고 이 영상이 좋았다면,17:25

제이V와 AI 코딩에 대한 더 많은 콘텐츠를 기대하고 계시다면 좋아요와 구독을 부탁드려요.17:31

그럼 다음 영상에서 만나요.17:36