메타 시니어 엔지니어의 Fable 5.1 vs GPT-6 Astra 실전 비교

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

메타 시니어 엔지니어의 실전 비교에서 GPT-6 Astra는 UI 재설계·저장소 시각화, Fable 5.1은 성능 최적화에서 더 좋은 평가를 받았지만, 실험 조건이 달라 보편적인 우열을 단정할 수 없다.

📌 핵심 요점

1. 같은 프롬프트여도 실행 환경은 달랐다. 오토클릭에서 네 과제를 최대 추론 설정으로 비교했지만, Astra에는 패스트 모드를 적용했고 두 모델의 하네스도 달랐다. 결과는 모델과 실행 환경을 함께 평가한 사례다.
2. 영상 제작은 대체로 비슷했고 비용은 차이가 났다. Astra의 음성·자막 포함 온보딩 영상이 처음에는 더 좋은 인상을 줬지만, 최종 평가는 거의 비슷했다. 영상 제작 시간은 유사했고 Astra의 비용은 약 두 배였으나, 산출물 구성도 달랐다.
3. 최적화는 Fable이 더 개선했지만 자원을 더 사용했다. Astra는 약 1%, Fable은 시나리오별 2~3%, 최대 6%의 시간 단축을 보였다. Fable은 47달러·약 90분, Astra는 22달러·24분을 사용했으며, 둘 다 생성 시간 절반 단축 목표에는 미달했다.
4. UI와 저장소 3D 시각화에서는 Astra가 앞섰다는 평가다. Astra는 홈 화면·제작 흐름·프로젝트 검색을 재구성했고, 저장소 공간 탐색에 썸네일 생성 과정 설명을 연결했다. 네 과제의 총비용은 Fable 125달러, Astra 134달러로 비슷했다.
5. 모델 협업이 품질 향상을 보장하지 않았다. 단계별 상호 리뷰를 붙여도 영상·최적화 개선은 제한적이었다. 협업 UI에서는 프로젝트 검색창이 사라졌고, 평가자는 Astra 단독 결과를 더 선호했다.

🧩 배경과 문제 정의

• Fable 5.1과 GPT-6 Astra 출시 이후 성능·비용·안정성에 대한 사용자 평가가 크게 엇갈렸다. 작업 종류와 에이전트 구성, 사용 환경이 달라 리뷰만으로 우열을 판단하기 어려웠다.
• 실제 썸네일 생성 서비스인 오토클릭을 대상으로 영상 제작, 생성 시간 단축, UI 전면 재설계, 저장소 3D 시각화를 비교했다. 같은 프롬프트와 최대 추론 설정을 사용했지만 Astra에는 패스트 모드를 적용해 비용과 시간 해석에 주의가 필요하다.
• 단일 모델의 원샷 결과뿐 아니라 두 모델이 계획·구현·검증을 상호 리뷰하는 협업도 실험했다. 결과물의 완성도에는 개인 취향이 개입하며, 협업이 실제 개선으로 이어지는지도 검토 대상이었다.

🕒 시간순 섹션별 상세정리

1. 사용자 리뷰가 엇갈리는 이유는 작업 조건과 평가 기준의 차이다

• 커뮤니티와 개인 블로그 등에서 모은 113개 리뷰에는 상반된 평가가 공존했다. Fable 5.1의 토큰 소비가 늘었다는 경험과 이전 버전보다 줄었다는 경험, Astra로 회사의 주력 AI를 바꾼다는 평가와 매우 부정적인 평가가 함께 있었다. [02:02]
• 글쓰기 품질, 추론 수준에 따른 비용, Fable의 안정성도 의견이 갈렸다. Astra의 추론 수준을 높이면 비용이 줄었다는 경험이 있는 반면, 미디엄 설정에서도 두 턴 만에 주간 한도를 소진했다는 경험이 있었다. [02:51]

2. 최대 추론 설정과 같은 프롬프트로 실제 서비스를 비교한다

• Fable 5.1과 GPT-6 Astra의 추론 설정을 모두 맥스로 맞추고, 실제 서비스인 오토클릭을 공통 작업 대상으로 삼았다. [04:41]
• 메인 오케스트레이터가 두 작업 창을 띄워 각각 Astra와 Fable을 실행하고 같은 프롬프트를 주입하는 방식으로 비교했다. [05:20]

3. 온보딩 영상은 음성과 자막을 포함한 Astra 결과가 더 좋은 인상을 줬다

• 첫 번째 결과물은 썸네일 생성부터 편집·변형·학습까지 온보딩 과정을 여섯 단계로 구성한 45초 영상이었다. [05:59]
• 두 번째 결과물은 채널 연결, 시청자 분석, 아이디어 탐색, 콘셉트 비교, 수정과 다운로드 과정을 음성으로 안내했다. [06:31]

4. 홍보 영상의 차이는 작았고 영상 제작 비용은 Astra가 더 높았다

• 15초 홍보 영상은 두 모델의 결과가 대체로 비슷했다. 별도의 홍보 표현보다는 온보딩 영상을 짧게 줄인 듯한 인상이 있었다. [08:40]
• 공통 과제는 앱을 로컬에서 실행해 직접 사용한 뒤, 45초 온보딩 영상과 15초 홍보 영상을 코드로 만들고 MP4로 렌더링하는 것이었다. 제품을 실제로 사용하며 이해하는 능력도 비교 대상에 포함됐다. [08:57]

5. 생성 시간 단축에는 품질을 희생하지 않는다는 제약을 붙였다

• 썸네일 생성 시간을 절반으로 줄이되, 지켜야 할 조건은 유지하고 품질을 떨어뜨리는 변경이 있다면 보고서에 명시하도록 요구했다. [10:37]
• 속도라는 목표만 달성하려고 제품 품질을 낮추는 변경을 막는 것이 제약의 목적이었다. 시간 단축 수치만으로 최적화의 성공을 판단하지 않겠다는 기준이다. [10:58]

6. 최적화는 Fable이 더 개선했지만 시간과 비용도 더 들었다

• Astra의 평균 단축 폭은 약 1%, 시간으로는 약 10초로 체감 차이가 작다는 평가였다. Fable은 시나리오별로 2~3%, 최대 6%의 단축 수치를 보였고, 약 20~30초의 개선은 상대적으로 의미 있게 평가됐다. [11:32]
• 총 소요 시간의 P50·P90 등에서도 약 27~30초의 개선을 근거로 Fable 쪽에 더 높은 평가를 줬다. 다만 두 모델 모두 생성 시간을 절반으로 줄이지는 못했다. [12:18]

7. 원샷 비교만으로 같은 예산에서의 최종 성능을 판단할 수는 없다

• Astra에도 47달러 수준의 비용과 더 긴 실행 시간을 허용하면 Fable에 필적하거나 더 나은 최적화가 가능할지는 확인되지 않았다. [13:00]
• 이번 비교는 모두 원샷 프롬프트 결과다. 실제 작업처럼 에이전트와 대화하며 방향을 조정했을 때의 성과는 별도 검증이 필요하며, 후속 실험 대상으로 남았다. [13:18]

8. UI 재설계는 기능 유지와 자율적인 구조 개선을 함께 요구했다

• UI를 전면 재설계하되 기존 기능이 사라지지 않아야 하고, 변경 후 실제로 동작하는지 테스트하도록 요구했다. 사람과 에이전트 모두 사용하기 좋은 화면도 조건에 포함됐다. [14:07]
• 시간 제한을 두지 않고 중간 질문 없이 필요한 판단을 스스로 내려 끝까지 진행하도록 했다. 에이전트가 잘 사용할 수 있는 제품이 살아남을 것이라는 전망이 이 요구의 배경이었다. [14:25]

9. Fable의 UI는 입력 구조와 탐색을 다듬는 보수적인 개선에 머물렀다

• 첫 번째 결과물은 새 썸네일 입력 화면을 영상 설명, 헤드라인과 톤, 참고 자료의 세 영역으로 나눴다. 기존 입력 항목은 유지하면서 정보 구조를 정리한 변화였다. [15:19]
• 프로젝트와 시청자 분석 화면은 큰 차이가 없었다. 인사이트 화면에서는 규칙·가설·A/B 테스트 탐색을 상단에 배치해 이동하기 편해졌다. [16:08]

10. Astra는 홈 화면과 제작 흐름, 프로젝트 검색을 새로 구성했다

• 두 번째 결과물은 홈 화면을 추가해 영상 아이디어 입력, 새 썸네일 제작 진입, 기존 프로젝트 이어가기, 채널 인텔리전스를 연결했다. 새 썸네일 화면도 이야기·표현 방식·소재와 참조·생성 전 확인의 네 단계로 구성했다. [17:26]
• 프로젝트에는 제목이나 콘셉트로 찾는 검색과 상태 확인 기능이 생겼다. 기존 화면에서 여러 페이지를 넘기며 작업물을 찾아야 했던 불편을 줄이는 변화였다. [19:28]

11. 저장소를 걸어 다니는 3D 공간으로 바꿔 코드 이해를 돕는다

• 복잡한 오토클릭 저장소에 새로 합류하면서 코드베이스를 이해하기 어려웠던 경험이 3D 시각화 실험의 배경이었다. 기능 개선보다는 저장소를 공간으로 표현하는 능력을 살펴보는 과제였다. [21:37]
• 첫 번째 결과물은 이동·달리기·점프가 가능한 게임 형태였다. 앱과 공유 라이브러리 등을 구역으로 나누고, 리액트 컴포넌트나 API·서버 액션 같은 코드 유형을 건물 색으로 구분했다. [22:17]

12. Astra의 3D 저장소는 공간 구조와 썸네일 생성 과정을 함께 설명했다

• 두 번째 결과물은 서비스를 여덟 공간으로 구조화하고 파일·구역 검색을 제공했다. 건물 하나를 파일 하나에 대응시키고 코드 줄 수를 높이로 표현했으며, 조감도와 직접 걷기를 모두 지원했다. [23:24]
• ‘썸네일의 여정’은 생성 요청에서 API 인증·프로젝트 확인, 작업 전달, 파이프라인 실행, 내용 이해와 콘셉트 평가, 이미지 생성·확인, 결과 저장까지의 흐름을 코드베이스와 연결했다. 편집과 평가 이후의 학습이 다음 생성의 맥락으로 이어지는 구조도 포함했다. [24:34]

13. 네 과제의 합계 비용은 비슷했지만 강점은 달랐다

• 네 데모의 총비용은 Fable 125달러, Astra 134달러였고 전체 소요 시간은 Fable이 더 길었다. [26:16]
• UI 재설계와 저장소 3D 시각화는 Astra가 크게 앞섰고, 성능 최적화는 Fable이 조금 더 좋았다는 종합 평가였다. 온보딩은 최종적으로 거의 비슷하게 평가했으며, 최적화를 제외한 작업 시간도 비슷했다. [26:24]

14. 단계별 상호 리뷰를 붙여도 영상과 최적화의 개선 폭은 작았다

• 협업에서는 두 에이전트가 의도 파악·계획·구현·검증·보고 단계마다 서로 리뷰하도록 했다. 의도는 사람이 한 번 확인하고, 이후 계획과 구현 결과, 검증 내용을 상호 검토하는 구조였다. [26:43]
• 협업으로 만든 홍보·온보딩 영상은 기존 결과와 대체로 비슷했다. 음악을 추가한 버전도 있었지만 협업 자체가 극적인 차이를 만들지는 못했다. [27:44]

15. 협업 UI는 두 모델의 구조를 섞으며 일부 장점을 잃었다

• 협업 UI는 색과 톤, 홈 화면에서 Astra의 방향을 따랐다. ‘나의 크리에이티브 작업실’이라는 구성은 Fable도 더 낫다고 판단해 채택한 방향이었다. [28:43]
• 최근 프로젝트와 인텔리전스를 담은 홈은 Astra의 접근을 따랐지만, 다른 부분에는 Fable의 구조를 사용했다. 두 결과를 섞은 협업안보다 Astra가 혼자 만든 UI가 더 낫다는 개인적 평가였다. [29:12]

16. 협업 비용과 실험 조건이 모델 우열 판단을 제한한다

• 온보딩 45초·홍보 15초 영상 작업에서는 아스트라를 메인으로, 페이블을 리뷰용으로 사용했다. 비용 수치로 108달러, 62달러, 142달러가 나왔지만 구독으로 사용했으므로 해당 금액이 그대로 청구된 것은 아니다. 메인 역할인 아스트라에 시간과 비용이 더 많이 들었다 [30:40]
• 이번 비교는 모델과 하네스를 결합한 두 환경의 비교다. 페이블에는 클로드 코드, 아스트라에는 코덱스를 사용했으므로 차이의 원인을 모델에만 돌릴 수 없다. 모델 자체를 비교하려면 오픈 코드 같은 동일한 하네스에서 모델만 바꿔 실행해야 한다 [31:36]

17. 사람의 검증과 작업에 맞는 설정이 결과를 좌우한다

• 좋은 원샷 프롬프트와 장시간 실행하는 에이전트에도 한계가 있다는 판단이다. 사람이 의도를 명확히 하고 방향을 조정하며, 계획을 점검하고 중간 결과를 검증할 때 원하는 품질의 결과물을 얻기 쉽다 [32:52]
• 사람과 하네스의 역할은 모델 성능이 좋아져도 여전히 중요하다는 견해다. 아스트라의 미디엄 또는 하이 설정이 최대 설정보다 비용을 적게 쓰면서 더 좋은 결과를 낸 실험이 있었던 것으로 기억하지만, 정확한 설정과 사례는 확실하게 단정하지 않는다 [33:29]

🧾 결론

• 이번 결과는 작업별 강점을 보여 주지만, 단일 실행·단일 코드베이스·개인 평가에 근거하므로 일반적인 모델 순위로 확장하기 어렵다.
• 비용과 시간을 더 쓴 결과가 더 좋았다는 사실만으로 같은 예산에서도 우세하다고 판단할 수는 없다.
• 사람의 의도 명확화, 계획 점검, 중간 결과 검증이 중요하며, 최대 추론 설정이나 복수 모델 사용 자체가 최선의 결과를 보장하지 않는다.

📈 투자·시사 포인트

• AI 도입에서는 모델 평판보다 실제 업무의 품질·완료 시간·비용을 함께 비교하는 평가 체계가 중요하다.
• 하네스와 검증 방식이 결과에 영향을 주므로, 모델 선택과 함께 작업 환경 구성에도 주의를 기울일 필요가 있다.
• 사람과 에이전트 모두 사용하기 쉬운 제품 설계가 중요해질 수 있다는 관점이 제시됐다. 이번 실험에서는 탐색 흐름과 프로젝트 검색이 구체적인 평가 요소였다.
• 복수 모델 운영의 경제성은 추가 리뷰가 실제로 개선한 품질과 보존한 기능으로 판단해야 한다. 이번 사례에서는 협업의 뚜렷한 추가 효과가 확인되지 않았다.

⚠️ 불확실하거나 확인이 필요한 부분

• Fable은 클로드 코드, Astra는 코덱스를 사용했고 Astra에만 패스트 모드가 적용됐다. 모델 자체의 차이와 하네스·실행 설정의 영향을 분리하기 어렵다.
• 각 실험은 한 번씩만 수행했다. 반복 실행에 따른 변동과 다른 코드베이스에서의 재현성은 확인되지 않았다.
• UI·영상의 완성도에는 개인 취향이 반영됐다. 영상은 음성·자막·음악 포함 여부도 달라 비용을 동일 산출물 기준으로 비교하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 자신의 실제 업무에서 대표 과제를 선정하고, 같은 프롬프트·하네스·추론 설정·실행 모드로 비교한다.
• 같은 비용 또는 시간 예산을 부여한 실험을 추가하고, 반복 실행의 중앙값과 평균을 기록한다.
• 최적화 평가에 처리 시간뿐 아니라 품질 유지 조건과 기존 기능의 정상 동작 여부를 포함한다.
• 협업 결과를 단독 실행과 비교하며, 프로젝트 검색처럼 유용한 기능이 사라지지 않았는지 검증한다.

❓ 열린 질문

• Astra에 Fable과 같은 최적화 예산과 실행 시간을 주면 개선 폭의 차이가 유지될까?
• 동일한 하네스에서 모델만 바꾸고 반복 실행해도 UI·시각화 평가가 재현될까?
• 원샷 대신 사람이 방향을 조정하는 작업에서는 두 모델의 비용 대비 성과가 어떻게 달라질까?