The Race to Done: Fable 5.1 vs GPT-6 Astra. Who Wins?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Fable 5.1과 GPT-6 Astra의 이번 앱 제작 대결에서는 빠른 반복 개선으로 실사용에 도달한 Astra가 앞섰지만, 발표자는 작업별 강점을 살려 두 모델을 함께 쓰는 편을 권한다.

📌 핵심 요점

1. 같은 Mac 클립보드 관리자 요청에서 Fable은 오른쪽의 좁은 목록형 Ledge를, Astra는 하단의 넓은 카드형 Shelf를 만들었다. 두 앱 모두 작동했으며, 서로 다른 설계가 사용자의 선호를 구체화했다.
2. 발표자에 따르면 Astra는 더 적은 토큰으로 약 한 시간을 절약했다. Fable이 1.0을 만드는 동안 Astra는 1.1·1.2까지 개선해, 속도가 실제 사용과 피드백 기회를 늘렸다.
3. 실용성을 가른 것은 단축키, 카드 정렬, 패널 이동, 복사 성공 표시 같은 세부 경험이었다. Shelf는 키를 놓은 뒤 이전 앱으로 포커스를 돌려보내도록 수정해 단축키의 부작용도 줄였다.
4. 비교에는 모델뿐 아니라 Claude Co-work와 Codex라는 사용 환경, 개인 취향, 서로 다른 후속 피드백이 포함됐다. 따라서 이번 결과를 보편적인 지능 순위나 모든 작업의 승패로 확대하기 어렵다.
5. 발표자는 문제 탐색과 설계에는 Fable, 빠른 구현과 구조화에는 Astra를 활용하는 작업 분담을 제안했다. 이번 작은 앱은 멀티에이전트 없이 만들었으며, 복잡한 협업은 별도의 확장 사례로 설명했다.

🧩 배경과 문제 정의

발표자는 최근에 복사한 항목만 사용할 수 있는 불편을 줄이기 위해, 텍스트·이미지·링크를 기억하고 단축키로 다시 꺼내는 네이티브 Mac 클립보드 관리자를 요청했다. Fable 5.1과 GPT-6 Astra에 같은 초기 과제와 시간 예산을 제공했지만 결과는 서로 다른 형태의 앱이었다.

영상의 핵심 질문은 첫 프롬프트가 만든 시제품을 어떻게 실사용 가능한 완성품으로 발전시키느냐다. 발표자는 직접 써본 뒤 발생하는 두 번째·세 번째 요청, 수정 속도, 설치와 전달 경험을 중심으로 비교한다. 이후 자신의 다른 작업 경험과 멀티에이전트 역할 분담 제안으로 논의를 넓힌다.

🕒 시간순 섹션별 상세정리

1. 같은 요청에서 나온 두 앱과 비교 기준

• Fable은 오른쪽에서 나오는 좁은 목록형 Ledge를, Astra는 하단에 큰 카드와 미리보기를 배치한 Shelf를 만들었다. 같은 요청과 시간 안에 두 앱 모두 작동했다. [00:24]
• 발표자는 첫 생성 결과를 넘어, 직접 사용한 뒤 추가 요청으로 완성에 도달하는 과정이 이번 비교의 핵심이라고 보여준다. [00:47]

2. 클립보드 문제와 첫 실사용 결과

• 요청은 복사한 텍스트·이미지·링크를 저장하고 키보드 단축키로 다시 불러오는 네이티브 Mac 앱이었다. [01:21]
• 발표자는 Astra가 더 적은 토큰을 사용하고 약 한 시간을 절약해 더 많은 개선을 시도할 수 있었다고 드러낸다. Fable의 디자인도 좋았지만 단축키 같은 세부 요소에서 사용성이 덜 맞았다고 평가한다. [01:46]
• 복사한 항목을 다시 찾아 원래 작업으로 돌아가는 흐름을 일상적으로 쓰게 됐는지가 실질적인 성공 기준이었다. [02:08]

3. 서로 다른 디자인과 사용 환경

• Ledge는 색상 견본과 코드 표현이 돋보였고, Shelf는 큰 카드·필터·넓은 미리보기를 제공했다. 두 결과를 보면서 발표자는 자신이 원하는 형태를 더 명확히 알게 됐다. [03:06]
• Fable은 배치할 화면 가장자리 등을 질문했고 Astra는 하단 배치를 스스로 선택했다. 사용 환경도 각각 Claude Co-work와 Codex여서 모델뿐 아니라 도구와 설정 경험이 비교에 포함됐다. [03:39]
• 발표자는 설계 차이를 지능의 우열로 보지 않고, 해결 방법을 탐색하는 서로 다른 관점으로 해석한다. [04:05]

4. 단축키와 피드백이 결정한 사용성

• Shelf의 Control+Shift+Space가 Ledge의 Command+Shift+V보다 기억하고 쓰기 편했다고 평가한다. 카드와 미리보기 선호 역시 개인 취향임을 인정한다. [05:10]
• 실제 사용 중 카드 정렬, 패널 이동, 숫자 단축키 충돌, 복사 성공 표시 부재를 발견했다. 성공 여부가 불분명하면 반복 조작과 확인 때문에 정신적 부담이 생긴다고 보여준다. [05:44]
• 스크린샷과 충돌하는 키 조합을 전달하고 복사 성공을 알고 싶다고 설명하자, Astra가 구체적인 수정 방식을 마련했다. [06:04]

5. 반복 개선과 검사로 완성도 높이기

• Fable이 1.0을 만드는 동안 Astra는 1.0·1.1·1.2를 진행했다. 발표자는 같은 시간에 더 많은 개선을 수행하는 능력을 속도 비교의 일부로 봤다. [06:25]
• Shelf에 패널 위치 기억과 드래그 이동, 복사 완료 표시가 추가됐다. 빠른 복사 키를 조정하고 키를 놓은 뒤 포커스를 돌려보내도록 해 다른 앱에 같은 입력이 전달되는 문제를 다뤘다. [06:49]
• 설치된 빌드는 Astra가 만든 65개 이상의 검사를 통과했다고 보여준다. 클립보드 복원·저장 이력·키보드 동작 검사와 실제 상호작용 테스트가 포함됐다. [07:09]

6. 다른 사람에게 전달하고 속도의 의미 재평가

• 다른 사용자가 앱을 바로 설치해 쓰기 시작한 일을 유용성의 중요한 증거로 제시한다. Mac용 DMG 설치 파일을 만들고 서명과 승인 절차를 거쳤다고 보여준다. [07:49]
• 첫 결과가 빨리 나오면 프로젝트에 집중하고 있는 동안 문제를 발견하고 수정 효과까지 확인할 수 있다. 이 반복 속도가 최종 품질과 다음 요청의 구체성에 영향을 줬다. [08:32]
• 이번 제작에서는 Astra가 더 빠르고 토큰 사용도 적었지만, 모든 작업에서 같은 결과가 나오거나 항상 Astra의 결과물을 고르지는 않을 것이라고 선을 긋는다. [09:00]

7. 우승자 선정에서 작업별 역할 배정으로

• 발표자는 모델 비교를 각 모델의 직무 적합성을 보여주는 경험 자료로 보여준다. 사람의 역할은 모델이 잘할 수 있는 작업과 자리를 찾아주는 것이다. [10:11]
• 글쓰기에서는 Fable로 문제를 충분히 탐색한 뒤 Astra로 구조와 작성 계획을 구체화한다고 드러낸다. 초기 사고에는 깊이를, 이후 전개에는 속도를 중시한다. [11:04]
• Astra의 앱 화면 설계와 공동 집필 경험을 통해 기존의 모델별 역할에 대한 자신의 인식도 달라졌다고 보여준다. [11:29]

8. 스프레드시트·발표자료·컴퓨터 사용의 분담

• 복잡한 스프레드시트는 Astra로 초안·수식 검증·초기 분석을 진행하고 Fable로 디자인을 다듬는 구성을 선호한다고 드러낸다. [11:58]
• 발표자료는 방향이 잡혀 있을 때 Astra로 이야기 구조를 계획한 뒤 Fable로 구체화하며, Astra를 조사 파트너로도 활용한다고 보여준다. [12:18]
• Mac의 다른 도구와 연동하는 컴퓨터 사용에서는 Astra의 속도를 높게 평가하고 Claude 쪽의 개선 필요성을 언급한다. 이는 발표자의 사용 경험에 근거한 평가다. [12:56]

9. 단일 에이전트의 성과와 협업 확장 예시

• 이번 앱 제작에는 멀티에이전트를 사용하지 않았다. 짧은 초기 요청과 단일 에이전트로도 실제 소프트웨어를 만들 수 있었다는 점을 강조한다. [13:39]
• 개방형 협업의 예로 Ringer를 언급하고, 참여 도구가 저장소와 메시지 보드에 접근하며 역할을 공유하는 방식을 보여준다. [14:09]
• Fable이 조정과 설계를 맡고 Astra가 검토한 뒤 더 저렴한 Luna에 실행을 맡기는 구성을 제안한다. 이번 앱에서 실행한 구성은 아니다. [14:38]

10. 두 모델의 장점을 결합하고 다음 비교로

• 향후 Shelf 개선에는 Fable의 디자인 탐색과 세부 표현에서 얻은 교훈을 가져오고 싶다고 드러낸다. 두 모델 모두 두 시간 이내에 맞춤형 소프트웨어를 만들었다는 점도 강조한다. [15:17]
• 서로 다른 해결 관점을 경험할 수 있으므로 두 모델을 함께 활용하라고 권한다. 이번 속도 차이를 한 모델만 고집해야 한다는 결론으로 연결하지 않는다. [15:34]
• 상세 시나리오는 Substack 가이드를 안내하고, Shelf 사용과 피드백을 권한다. 앞으로도 작은 도구 제작을 모델 비교에 활용하며 후속 비교를 공유하겠다고 마무리한다. [16:15]

🧾 결론

• 이번 사례의 승부 기준은 첫 결과물의 인상보다 실제로 설치하고 반복해서 쓰며 다른 사람에게 전달할 수 있는 상태에 도달했는지였다.
• 빠른 첫 구현은 사용 중 발견한 문제를 다음 요청에 반영할 시간을 확보해 최종 품질에 영향을 줬다.
• Ledge의 표현 방식과 세부 설계에도 가치가 있었으며, 발표자는 그 장점을 향후 Shelf 개선에 반영하고 싶다고 밝혔다.
• 모델 선택은 고정된 우승자를 정하는 일보다 작업과 단계에 맞는 역할을 배정하는 일에 가깝다.

📈 투자·시사 포인트

• AI 도구의 생산성은 생성 속도만으로 판단하기 어렵다. 설정 부담, 수정 왕복, 설치와 전달까지 포함한 완료 시간을 함께 봐야 한다.
• 토큰 사용 감소와 반복 개선 증가는 비용 효율을 평가할 단서다. 다만 영상에는 정확한 토큰 수와 요금이 없어 금전적 절감액은 계산할 수 없다.
• 발표자가 보여준 서로 다른 설계 결과는 복수 모델을 활용한 제품 탐색의 가치를 시사한다. 한 모델의 결과를 다른 모델의 개선 재료로 활용할 수 있다.
• 작은 맞춤형 도구를 짧은 요청에서 출발해 배포 가능한 형태로 발전시킨 경험은 개인용 소프트웨어 제작의 접근성이 높아졌다는 사례다. 특정 기업의 실적이나 투자수익을 판단할 자료는 제시되지 않았다.

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

• 단일 앱 제작 경험이며 반복 실험, 정확한 소요 시간 기록, 모델별 토큰 집계가 제시되지 않았다. 약 한 시간 절약과 낮은 토큰 사용은 발표자의 보고다.
• 출발 요청과 시간 예산은 같았지만 후속 피드백 횟수와 사용 환경은 달랐다. 동일 시간 내 완성도 비교로는 의미가 있어도 모델 자체의 능력을 분리한 실험은 아니다.
• 65개가 넘는 검사 통과는 Astra가 구성한 검사에 대한 설명이다. 검사 목록과 독립 검증 결과가 없어 전체 신뢰성이나 장기 안정성까지 확정할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 실제로 반복하는 작은 작업 하나를 정하고, 같은 초기 요청과 시간 예산으로 두 모델의 결과를 비교한다.
• 첫 실행까지 걸린 시간, 후속 수정 횟수, 토큰 사용량, 최종 전달 가능 여부를 함께 기록한다.
• 복사·검색·재사용 흐름을 직접 수행하며 단축키 충돌, 성공 표시, 포커스 복귀, 패널 위치 유지 여부를 확인한다.
• 스크린샷과 재현 가능한 불편 사례를 후속 요청으로 전달하고, 수정 후 같은 동작을 다시 검증한다.

❓ 열린 질문

• Fable에도 동일한 후속 피드백과 개선 횟수를 제공하면 두 앱의 사용성 차이는 얼마나 남을까?
• 텍스트 위주 사용자와 이미지·링크를 자주 확인하는 사용자는 Ledge와 Shelf를 다르게 평가할까?
• 같은 환경에서 여러 종류의 앱을 반복 제작해도 Astra의 시간·토큰 이점이 유지될까?