스크립트
00:00:00Fable 5.1과 GPT-6 Astra가 불과 며칠 차이로 출시되었고, 둘 다 벤치마크에서 정말
00:00:05높은 점수를 기록했습니다. Astra는 기존에 어떤 모델도 근접하지 못했던 AGI 테스트에서 거의 100%를 기록했죠.
00:00:11따라서 이러한 수치를 보면 직접 업무를 맡겼을 때도 매우 훌륭한 성과를 낼 것이라 기대하게 됩니다.
00:00:16하지만 그런 테스트에서 좋은 성적을 거둔다고 해서 실제 실무를 얼마나 잘 처리할 수 있는지는 알 수 없기에,
00:00:20저희는 두 모델이 실제 우리 업무에서도 똑같이 잘 수행하는지 확인해보고 싶었습니다.
00:00:25저희는 소프트웨어 회사이므로 이미 테스트해 볼 프로젝트들이 있었고, 두 모델에게 해당 프로젝트의
00:00:30작업을 맡긴 뒤 완료된 결과물을 점검했습니다. 여러 프로젝트에 걸쳐 각 모델을 실행하고
00:00:35다양한 영역에서 얼마나 잘 수행했는지 평가했습니다. 결과 심사와 점수 산정에는 GPT-5.6을 활용했습니다.
00:00:41이 심사 모델은 어떤 결과물이 Fable에서 나왔고 어떤 결과물이 Astra에서 나왔는지 알지 못했습니다.
00:00:45한 모델은 100점 만점에 총점 86점을 받았고, 다른 모델은 84점을 받았습니다. 그리 큰 차이로 보이지 않을 수도 있지만,
00:00:52전체적으로 앞선 모델이 모든 테스트 부문에서 승리한 것은 아니며, 다른 모델도 특정 영역에서는
00:00:57놀라울 정도로 훌륭한 성과를 보여주었습니다. 따라서 각 모델이 테스트에서 어떻게 수행했는지,
00:01:02그리고 카테고리별로 어떤 모델이 우세했는지 자세히 살펴봄으로써 이러한 차이가 여러분의 실제
00:01:07업무에 어떤 영향을 미치는지 알아보겠습니다. 각 모델의 수행 결과로 넘어가기 전에 먼저 모델 자체에 대한
00:01:12간단한 개요를 짚어보겠습니다. 이 섹션은 모델에 대해 잘 모르는 분들을 위한 것이므로, 이미 세부
00:01:17내용을 알고 계신 분은 이 섹션을 건너뛰고 바로 다음 섹션으로 가셔도 됩니다. 앤스로픽은
00:01:229월 1일에 Fable 5.1을 출시했고, 앤스로픽이 출시의 열기를 온전히 즐기기도 전에
00:01:27오픈AI가 Fable 출시 직후 며칠 만에 GPT-6 Astra를 내놓았습니다. 사람들은 이 모델들로 정말
00:01:33흥미로운 제품들을 만들고 있으며, 모델의 능력 한계까지 밀어붙여 놀라운 결과를 얻어내고 있습니다.
00:01:37가격 면에서 두 모델은 실제로 입력 토큰 100만 개당 10달러, 출력 토큰 100만 개당 50달러로 동일합니다.
00:01:43하지만 Fable 5.1에는 한 가지 다른 점이 있는데, 앤스로픽이 캐시된 읽기(cached reads) 가격을 75% 인하했다는 것입니다.
00:01:49캐시된 읽기에 대해 잘 모르시는 분들을 위해 설명하자면, 모델이 이미 읽었던 대화의 일부는 재사용을 위해
00:01:54실제로 저장됩니다. 새로운 프롬프트를 보낼 때, 모델이 처음부터 다시 읽는 대신
00:02:00저장된 부분들을 재사용하게 되는데 이를 캐시된 읽기라고 부릅니다. 이러한 읽기 방식은 대화를 재사용하는 것을
00:02:05이미 더 저렴하게 만들어 주지만, 가격 인하 덕분에 훨씬 더 저렴해집니다.
00:02:10하지만 그렇다고 해서 Fable이 전반적으로 더 저렴한 모델이라는 뜻은 아닙니다. 총 비용은 다른 여러
00:02:14요인에도 좌우되기 때문이며, 이에 대해서는 곧 이야기해 보겠습니다. 자, Fable 모델들은 Claude Code에서
00:02:19잠깐 동안 사용되어 왔지만, Fable 5.1은 여전히 Claude Pro 플랜에 포함되어 있지 않습니다.
00:02:25따라서 Pro 플랜에서는 사용량 크레딧을 통해 별도로 비용을 지불해야 합니다. 맥스(Max) 플랜의 경우
00:02:30Fable 5.1이 포함되어 있지만, Fable 모델들은 다른 모델들에 비해 더 낮은 한도를 가집니다.
00:02:36반면에 오픈AI는 Astra를 그처럼 별도의 모델로 취급하지 않습니다. Astra는 ChatGPT+ 및 Pro의
00:02:41일반적인 코덱스(Codex) 한도에 포함되어 있으며, 사용량 전체를 Astra에 쏟아부을 수 있기 때문입니다.
00:02:47자, 이 모델들은 긴 작업을 처리하는 데 매우 능숙합니다. 즉, 거대한 기능을 만들어 달라고 요청하고
00:02:52스스로 단계를 거쳐 작업하도록 내버려 둘 수 있다는 뜻입니다. 하지만 이 모델들이 긴 작업을 처리하도록
00:02:57둘 때, 보유할 수 있는 컨텍스트의 양 역시 중요합니다. Fable은 Claude code에서 100만 토큰을 제공하는 반면,
00:03:02Astra의 코덱스 기본 컨텍스트 윈도우는 272,000토큰에 불과합니다. 비록 API를 통해서는 Fable의 100만 토큰보다도
00:03:09 훨씬 더 큰 윈도우를 가지고 있음에도 말이죠. 하지만 당장은 코덱스에서 그만큼을 얻지는 못할 것입니다.
00:03:14코덱스는 Astra에 대해서조차 기본 컨텍스트 윈도우를 272,000토큰으로 설정하기 때문입니다.
00:03:21자, 이 모델들은 고급 연구를 수행할 수 있는 수준에 도달했기 때문에 오픈AI와 앤스로픽 모두
00:03:26수행할 수 있는 일부 작업을 제한하는 안전 가드레일을 추가했습니다.
00:03:31하지만 그러한 제약들은 또한 각 모델이 요청이 허용되지 않는다고 판단했을 때 다르게 반응하기 때문에
00:03:36여러분 의 작업에도 여러 가지 방식으로 영향을 미칩니다. Astra가 규칙에 위배되는 작업 부분에 도달하면,
00:03:41해당 작업을 단호하게 거부하고 사용자에게 그 사실을 알립니다.
00:03:45반면에 Claude code는 요청이 규칙을 위반할 때 Fable에서 더 약한 모델로 전환합니다.
00:03:51그리고 많은 사람들이 Claude code가 자신들도 모르게 모델을 전환했다는 사실을 발견했습니다.
00:03:56따라서 전환 이후에도 Claude code가 계속 작동한다면, 여러분이 얻고 있는 결과물은 더 이상 Fable에서 온 것이 아닐 수 있습니다.
00:04:01자, 우리가 측정한 첫 번째 지표는 모델의 작업이 실제로 얼마나 훌륭한지를 살펴보는 품질(quality)입니다.
00:04:06이번 테스트에서는 여러 클라이언트 프로젝트를 사용했기 때문에 해당 프로젝트들의 세부 사항을 공개할 수는 없지만,
00:04:11우리가 어떻게 작업을 심사했고 모델 간에 어떤 차이가 있었는지는 설명해 드릴 수 있습니다.
00:04:16코드가 작성되고 조직된 완성도 측면에서, Fable은 앱의 서로 다른 부분에 대한 코드를 더 명확하게
00:04:22분리해 두었기 때문에 Astra의 78점에 비해 90점을 기록했습니다.
00:04:27이로 인해 나중에 변경 사항을 만들 때 모델이 앱을 더 쉽게 이해할 수 있으며, Fable은 우리가 테스트한 모든
00:04:32프로젝트에서 이 부분에 있어 Astra보다 앞서 있었습니다. 그리고 요청받은 작업 중 얼마나 완료했는지를 보면,
00:04:39Fable은 특별히 수정해 달라고 요청하지 않은 문제들까지 고쳐주었기 때문에 Astra의 84점에 비해 91점을 기록했습니다.
00:04:44하지만 완성된 기능들이 수정 요청 없이도 제대로 작동하는지 확인했을 때, 그 부문에서는 Astra가 87점으로 Fable의 85점보다 높았습니다.
00:04:50아스트라가 앞서간 부분 중 일부는 앱을 더 철저히 검토하고 알려진 문제들을 더 많이 해결했기 때문입니다.
00:04:55페이블은 앱을 테스트할 때 문제가 발생할 수 있는 일부 상황을 놓쳐서, 완성된 기능에
00:05:00앱 사용 경험 측면에서 보면, Astra는 페이지의 여러 요소를 더 찾기 쉽고 사용하기 편한 곳에 배치했기 때문에 Fable의 88점에 비해 89점을 기록했습니다.
00:05:08Astra는 페이지의 여러 요소를 더 찾기 쉽고 사용하기 편한 곳에 배치했기 때문에 Fable의 88점에 비해 89점을 기록했습니다.
00:05:13따라서 방금 언급한 모든 테스트를 바탕으로 볼 때, Fable의 전체 품질 점수는 88점인 반면 Astra는 84점을 기록했습니다.
00:05:19더 완성도 높은 기능을 구축했고 작업 내용을 나중에 수정하기 더 쉬웠기 때문입니다. 품질 측면에서는
00:05:25Fable이 명백한 승자입니다. 하지만 다음 테스트로 넘어가기 전에, 스폰서인
00:05:30Zapier의 메시지를 들어보겠습니다. 바이브 코딩(vibecode)으로 앱을 만들면 아주 잘 작동하지만, Gmail, Slack, Notion 같은
00:05:35도구들과 실제로 연동하고 싶어지는 순간, 모든 통합과 OAuth 흐름을 수동으로 연결해야 합니다.
00:05:41어느새 인증 코드 속에 파묻히게 되고, 순식간에 연동 작업이 프로젝트 전체가 되어버리죠.
00:05:46바로 그때 Zapier SDK가 필요합니다. 이것은 Claude code나 Cursor 안에서 프로젝트에 바로 집어넣을 수 있는 코드 라이브러리로,
00:05:52Zapier의 9,000개 이상의 앱 생태계에 프로그래밍 방식으로 접근할 수 있게 해줍니다. 따라서 각 통합을
00:05:58수동으로 구축하는 대신, 필요한 것들을 호출하기만 하고 계속 진행할 수 있습니다. 몇 줄의 코드만으로 우리 앱은
00:06:04복잡한 API 문서나 인증을 거칠 필요 없이 이메일을 보내고 Notion 페이지를 만들 수 있었습니다.
00:06:10그리고 사전에 구축된 작업이 없는 Notion의 사용자 정의 속성을 업데이트해야 할 때도, SDK를 통해 직접 호출했습니다.
00:06:15이 도구는 진정으로 여러분이 이미 일하고 있는 환경에 직접 찾아와 도움을 줍니다. 수동으로 연동 작업을 하느라 지치셨다면,
00:06:20Zapier SDK를 사용해 보세요. 링크는 아래 설명란에 있습니다. 우리가 측정한 다음 지표는 모델이
00:06:26장시간 실행되는 작업을 얼마나 잘 처리하는지였습니다. 이는 작업하는 동안 우리의 개입을 거의 받지 않고
00:06:31스스로 얼마나 많은 작업을 마쳤는지를 의미합니다. 또한 도중에 발생하는 문제를 얼마나 잘 해결하는지도 확인했습니다.
00:06:36이를 위해 각 모델에게 구축할 앱 아이디어를 제공하고, 최선의 작업 결과를 낼 수 있도록 각 모델의 프롬프트 가이드에 맞춰
00:06:42요청 문구를 작성했습니다. 구체적인 세부 사항은 언급하지 않고 앱이 해야 할 일만 설명했습니다.
00:06:47Astra는 약 32분 동안 작업했고 Fable은 약 44분 동안 작업했습니다. Astra는 앱을 구축하고 검사하는 동안
00:06:53오류에 부딪히기도 했지만, 우리가 모든 문제를 하나씩 안내해 줄 필요 없이 스스로 그것들을 해결하며 앱 수정을 이어갔습니다.
00:06:58Fable도 도중에 멈추거나 다음에 무엇을 해야 할지 묻지 않고 앱을 완성했으며, 자신이 구축한 것에 대해 검사를 실행했습니다.
00:07:03Fable도 도중에 멈추거나 다음에 무엇을 해야 할지 묻지 않고 앱을 완성했으며, 자신이 구축한 것에 대해 검사를 실행했습니다.
00:07:09따라서 두 모델 모두 작업을 끝까지 수행해 냈지만, 완성된 앱을 검토하여 어떤 결과물을 남겼는지도 살펴보았습니다.
00:07:13Astra의 앱은 별도의 랜딩 페이지 없이 바로 로그인 페이지로 열렸습니다. 일단 로그인하자마자,
00:07:18레이아웃이 잘 정돈되어 있고 앱도 잘 작동했습니다. 비록 많은 AI 생성 앱에 등장하는 친숙한 레이아웃이
00:07:24여전히 남아있긴 했지만요. 하지만 사이드 패널에 문제가 있었는데, 로그아웃 버튼에 닿을 만큼 충분히
00:07:30스크롤되지 않았습니다. 그 버튼에 도달하려면 화면을 축소해야 했는데, 이는 Astra 자신의 자체 검사에서도
00:07:35잡아내지 못한 부분이었습니다. Fable의 앱 역시 로그인 페이지로 바로 열렸지만, 디자인이 훨씬 더 진부하게 느껴졌습니다.
00:07:40기능들은 작동했지만 모든 것이 너무 촘촘하게 배치되어 있어서 앱을 사용하기 어려웠고,
00:07:45반복되는 그라데이션들이 그 친숙한 AI 생성 느낌을 더했습니다. 작은 화면에 맞게 조절되기는 했지만,
00:07:51비록 기능들은 심도 있게 구현되었음에도 여전히 사용하기 편한 레이아웃은 아니었습니다.
00:07:56우리는 모델들이 스스로 작업하도록 내버려 둔 채로 여러 다른 앱들과 거대한 기능들도 이와 같은 방식으로 기획하고 구축했습니다.
00:08:01따라서 장기 실행 작업의 경우, Astra는 Fable의 90점에 비해 100점 만점에 93점을 기록했습니다.
00:08:08Fable은 프롬프트에 시각적인 부분에도 집중하라고 구체적으로 명시하지 않는 한 기능 작동에 더 집중했습니다.
00:08:13Astra는 앱의 작동 방식과 시각적 외형 모두에 신경을 썼으므로, 장기 실행 작업에서는 Astra가 승리합니다.
00:08:18우리가 살펴본 다음 지표는 디자인과 앱의 사용 편의성이었습니다. 모델이 디자인에 점수를 매기도록 허용하긴 했지만,
00:08:23그 모델의 디자인 취향에만 의존하고 싶지는 않았습니다. 그래서 Fable의 결과물을 위한 뷰어와
00:08:28Astra의 결과물을 위한 뷰어를 각각 만들어 우리가 직접 디자인들을 살펴보며 사용하기에 어떤지 비교할 수 있게 했습니다.
00:08:33두 모델에게 글꼴을 판매하는 비즈니스를 위한 랜딩 페이지를 시작으로 동일한 디자인 과제를 주었습니다.
00:08:38Fable의 버전은 색상과 글꼴부터 레이아웃에 이르기까지 Opus가 만들어내는 것과 매우 유사해 보였습니다.
00:08:44최근 Opus 디자인에서 보아왔던 것처럼 페이지를 가로질러 움직이는 텍스트 줄무늬까지 포함되어 있었죠.
00:08:50하지만 Fable이 Opus와 다르게 한 가지 한 것은 디자인 전반에 훨씬 더 많은 인터랙티브 요소를 추가했다는 점이며,
00:08:55그 덕분에 앱을 사용하는 느낌이 더 좋아졌습니다. Astra의 버전은 더 여유로운 레이아웃을 갖추고 있었으며,
00:09:00아스트라 버전은 텍스트 크기와 색상의 대비가 더 명확해서 텍스트를 읽기가 더 쉬웠습니다.
00:09:05하지만 움직임이 훨씬 적었기 때문에 보기에는 더 편안했지만 페이블의 디자인 같은 경험은 주지 못했습니다.
00:09:10그래서 페이블이 상호작용 점수에서 94점을 기록한 반면, 아스트라는 85점을 기록했습니다.
00:09:14다음으로 각 모델에게 공포 게임 랜딩 페이지를 디자인하도록 했습니다.
00:09:20페이블의 디자인은 애니메이션 등대를 사용하여 분위기를 조성했습니다.
00:09:25코드로 그린 이미지인 SVG로 아트워크를 만들었지만, 페이블이 선택한 크기와 색상 때문에 어두운 배경에서 텍스트가 충분히 돋보이지 않았습니다.
00:09:31그리고 동일한 디자인 작업에서 아스트라는 코드로 아트워크를 만드는 대신 코덱스에 내장된 이미지 생성 모델을 사용하여 이미지를 생성했습니다.
00:09:36또한 요청하지도 않은 게임 티저를 만들기도 했습니다.
00:09:42그리고 아스트라가 앞선 부분은 폰트와 색상 선택이었는데, 덕분에 어두운 배경에서 텍스트가 더욱 돋보였습니다.
00:09:47음악 페스티벌 사이트의 경우, 페이블 버전은 오푸스가 만든 디자인에서 볼 수 있는 디자인 요소들을 많이 반복했습니다.
00:09:52하지만 그러한 친숙한 선택들에도 불구하고, 사이트만의 독창적인 스타일을 부여하기 위해 페이블이 더 많은 노력을 기울인 느낌이었습니다.
00:09:57Opus가 만든 디자인에서 흔히 볼 수 있는 요소들이 반복되었습니다. 하지만 그런 익숙한 선택들에도 불구하고,
00:10:03Fable이 사이트만의 고유한 스타일을 살리기 위해 더 많은 공을 들였다는 느낌을 주었습니다. Astra는 생성된 콘서트 사진을 사용했지만,
00:10:08후방 뷰 미러 덕분에 차를 어디로 움직여야 할지 더 정확하게 판단할 수 있었습니다.
00:10:13이 게임에는 두 개의 카메라 뷰가 있었지만 둘 다 문제가 있었습니다.
00:10:18하나는 주차 공간의 잘못된 쪽을 보여주었고, 다른 하나는 앞쪽 도로의 전체적인 뷰를 제공하는 대신 한쪽 페이지만 보여주었기 때문입니다.
00:10:23이로 인해 차량을 이동하는 위치를 확인하기가 더 어려워졌으며, 카메라 각도가 올바랐다면 게임이 더 현실감 있게 느껴졌을 것입니다.
00:10:27아스트라는 세 가지 고정 뷰를 제공하고 사이드 패널에 운전 팁을 추가하여 게임을 더 쉽게 플레이할 수 있도록 만들었습니다.
00:10:32카메라 뷰는 모두 페이블보다 훨씬 뛰어났습니다.
00:10:38원하는 디자인에 대한 세부 정보를 거의 제공하지 않은 일반적인 테스트였으므로, 여기서는 모델 자체의 취향을 확인할 수 있었습니다.
00:10:42두 모델 모두 다른 작업에서 보았던 디자인 선택을 반복했지만, 둘 다 좋은 결과를 만들어냈습니다.
00:10:48그리고 앱의 디자인과 사용성에 대해 조금 더 자세한 정보를 제공한다면, 두 모델 모두 훌륭한 디자인을 보여줄 것으로 기대됩니다.
00:10:53따라서 취향만 놓고 보면 시각과 사용성 측면에서는 아스트라가 승리했고, 애니메이션과 상호작용 측면에서는 페이블이 승리했습니다.
00:10:58하지만 비용과 속도 테스트로 넘어가기 전에, 채널을 구독하고 좋아요 버튼을 눌러주시면 정말 감사하겠습니다.
00:11:04이러한 작은 지지의 표명은 저희에게 큰 힘이 됩니다.
00:11:09다음으로 측정한 지표는 효율성이었는데, 이는 작업 비용, 소요 시간, 그리고 작업을 완료하기 위해 모델이 도구를 사용한 횟수를 다루었습니다.
00:11:15비용에 대해 알아야 할 한 가지는 API를 사용하지 않았으므로, 이는 사용된 토큰을 기반으로 API를 사용할 경우 작업에 소요될 비용의 추정치일 뿐이라는 점입니다.
00:11:20테스트는 평소 구독 플랜에서 실행했습니다.
00:11:25모든 테스트 실행을 통틀어 페이블의 총 예상 비용은 49.18달러였으며, 아스트라는 27.69달러로 아스트라의 총비용이 약 44% 더 낮았습니다.
00:11:31페이블은 아스트라에 비해 거의 3배에 달하는 출력 토큰을 생성했는데, 이는 페이블의 프롬프팅 가이드에서 다른 모델보다 더 많이 작성하는 경향이 있다고 언급된 것과 같습니다.
00:11:37두 모델 모두 해당 토큰에 대한 비용은 동일했으므로, 더 많이 작성한 것이 페이블의 비용을 증가시킨 원인이었습니다.
00:11:47또한 도구를 사용하는 것도 토큰 사용량을 증가시키는데, 모델이 사용할 도구를 결정한 후 작업을 계속하기 전에 결과를 읽기 때문입니다.
00:11:526번의 모든 실행에서 페이블의 메인 에이전트는 도구를 443회 사용한 반면 아스트라는 287회 사용하여, 이 역시 비용 증가의 원인이 되었습니다.
00:11:57비용 측면에서 아스트라는 100점 만점에 80점을 기록하여 66점을 받은 페이블보다 우수했습니다.
00:12:03속도의 경우에도 아스트라가 70점으로 페이블의 67점보다 앞섰습니다.
00:12:09장기 실행 작업은 아스트라가 총 약 62분이 소요된 반면, 페이블은 73분이 소요되었습니다.
00:12:17비용 부문에서 아스트라는 100점 만점에 80점을 기록하여 66점을 받은 페이블보다 우세했습니다. 속도 측면에서도 아스트라가
00:12:2367점인 페이블에 비해 70점으로 앞섰습니다. 장기 실행 작업의 경우 아스트라는 총 62분 정도 소요된 반면,
00:12:30프로젝트에서 페이블을 실행했을 때, 명시적인 지시에도 불구하고 초기에는 클로드(Claude)가 코드 작성을 도왔다는 공동 저자 메시지를 추가했습니다.
00:12:35또한 파일 생성 및 변경 허용 방식에 대한 규칙도 무시했습니다.
00:12:40클로드 자체의 파일 편집 도구를 사용하도록 지시하여 변경 사항이 추적되고 쉽게 취소될 수 있도록 하라고 했지만, 대신 명령어를 실행하여 두 개의 파일을 생성했습니다.
00:12:44지시사항 준수 측면에서 아스트라는 100점 만점에 96점을 기록하여 88점을 받은 페이블을 앞섰습니다.
00:12:49따라서 지시사항을 따르는 데 있어서는 이번 테스트에서 아스트라가 우위를 점했습니다.
00:12:53다음으로 측정한 지표는 검토 품질이었는데, 문제들이 포함된 프로젝트를 모델에게 제공하고 해당 문제를 찾도록 요청했습니다.
00:12:58먼저 두 모델에 동일한 코드를 검토하도록 제공했으며, 모델이 찾아야 하는 내용을 파악할 수 있도록 4개의 문제를 의도적으로 추가했습니다.
00:13:04페이블은 4개를 모두 찾아냈고, 우리가 추가하지 않은 5개의 추가 문제도 찾아내어 확인 및 검증을 거쳤습니다.
00:13:09아스트라는 100점 만점에 96점을 기록해, 88점을 받은 페이블보다 앞섰습니다. 지시사항 준수 측면에서 보면,
00:13:16또한 모델이 가짜 문제를 보고하는지 확인하기 위해 의심스러워 보이지만 실제로는 올바른 부분 3개를 포함시켰습니다.
00:13:21어느 모델도 이를 버그로 취급하지 않았으므로, 여기서의 차이는 얼마나 많이 찾아내느냐에 있었습니다.
00:13:27페이블이 더 철저한 검토를 제공했지만, 9개의 확인된 문제가 있는 더 큰 프로젝트에서 테스트했을 때는 아스트라가 5개를 수정한 반면 페이블은 4개만 찾아서 수정했습니다.
00:13:33따라서 아스트라가 더 많은 수정을 완료했지만, 두 모델 모두 여러 문제를 수정되지 않은 채로 남겨두었습니다.
00:13:37수정과 모델의 다른 작업 검토 방식을 포함한 검토 품질 측면에서 페이블은 84점을 기록하여 아스트라의 78점을 앞섰습니다.
00:13:42전반적인 검토 측면에서 페이블이 더 뛰어난 검토를 제공했기 때문에, 페이블이 전체 검토 점수에서 앞서게 되었습니다.
00:13:47따라서 이러한 결과를 바탕으로 볼 때, 아스트라는 테스트한 여러 카테고리 전반에서 명백한 승자입니다.
00:13:52하지만 그렇다고 해서 페이블이 나쁜 모델이라는 의미는 아닙니다. 작업 전반에 걸쳐 좋은 성능을 발휘했고 여러 항목에서 아스트라에 크게 뒤처지지 않았기 때문입니다.
00:13:57따라서 부여하려는 작업에 따라 적절한 모델을 선택하기만 하면 됩니다.
00:14:03이제 이 두 모델의 성능을 최대한 끌어내기 위해 따라야 할 특정 관행들이 있습니다.
00:14:08저희는 테스트 과정에서 그중 상당수를 활용했으며, 여러분도 이에 접근하고 싶다면 저희 커뮤니티인 AI 랩스 프로(AI Labs Pro)에서 확인하실 수 있습니다.
00:14:13저희의 활동에 가치를 느끼셨고 채널을 지원하고 싶으시다면 이것이 가장 좋은 방법입니다.
00:14:19전체적으로 더 꼼꼼한 검토를 제공했기 때문입니다. 따라서 이 결과를 바탕으로 볼 때, Astra는 테스트한 여러
00:14:25부문에서 명백한 승자입니다. 그렇다고 Fable이 성능이 나쁜 모델이라는 뜻은 아닙니다. 여러 작업에서
00:14:30채널을 지원하고 이와 같은 영상을 계속 만드는 데 도움을 주고 싶으시다면, 아래의 슈퍼 땡스(Super Thanks) 버튼을 통해 그렇게 하실 수 있습니다.
00:14:35늘 그렇듯 시청해 주셔서 감사하며 다음 영상에서 뵙겠습니다.
00:14:40반드시 지켜야 할 몇 가지 요령이 있습니다.
00:14:45저희 커뮤니티인 AI Labs Pro에서 확인하실 수 있습니다.
00:14:51저희 활동이 도움이 되셨고 채널을 후원하고 싶으시다면 가장 좋은 방법입니다. 링크는 설명란에 있습니다.
00:14:56이것으로 이번 영상도 마치겠습니다. 채널을 후원하고 앞으로도 이런 영상을
00:15:01채널을 지원하고 이와 같은 영상을 계속 만드는 데 도움을 주고 싶으시다면...
00:15:05시청해 주셔서 감사하며 다음 영상에서 뵙겠습니다.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기