Fable 5.2 Vibe Check

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Fable 5.2 바이브 체크의 핵심 평가는 장기 자율 작업과 모호한 과제에서 제작 가능성을 넓혔지만, 검증 환경과 시간·비용에 맞춘 선택이 필요하다는 것이다.

📌 핵심 요점

1. 평가의 기준은 답변 품질보다 ‘새롭게 무엇을 만들 수 있는가’다. 참여자들은 전문 음악가용 DAW, 사내 영상 편집기 Every Cut, 탐색 가능한 3D 환경을 사례로 들며 작업 규모의 확장을 높게 평가했다.
2. 장기 실행은 작업 습관을 바꾼다. 하룻밤부터 며칠까지 목표를 맡기고 여러 프로젝트를 병렬로 진행하는 방식이 강조됐다. 다만 높은 노력 설정은 검증을 길게 이어가므로 빠른 피드백이 필요한 작업에서는 부담이 된다.
3. 자율 실행의 품질은 도구와 검증 기준에 좌우된다. 기준 자료와 테스트 수단이 있으면 반복 수정이 가능하지만, 슬라이드의 이미지를 확인하지 않고 텍스트만 읽은 사례처럼 확인 범위를 잘못 이해하면 오류가 남는다.
4. 모든 작업을 Fable로 통일할 이유는 제시되지 않았다. 모호하고 어려운 코딩·연구에는 Fable을, 일상 작업과 반복적인 글쓰기에는 Opus를 선호했다. Fable이 계획하고 다른 모델이 실행하거나, 막힌 구간에서만 Fable의 조언을 받는 분업도 소개됐다.
5. 경제성은 토큰 단가와 프로젝트 총비용을 함께 봐야 한다. 뉴욕 전투 환경 약 3,000달러, 포도주 게임 약 20,000달러, Every Cut 초기 버전 약 10,000달러라는 추정이 나왔다. 재작업과 사람의 투입을 줄일 수 있다는 기대가 있지만, 보편적인 비용 우위가 입증된 것은 아니다.

🧩 배경과 문제 정의

• Fable 5.2의 사전 사용 경험을 바탕으로, 성능 향상이 실제 제작 능력과 업무 방식까지 바꾸는지 평가한다.
• 핵심 평가 기준은 일상적으로 사용하는 좋은 모델을 넘어, 사용자가 가능하다고 생각하는 작업의 범위를 넓히는지에 있다.
• 장시간 자율 실행으로 복잡한 결과물을 만들 수 있지만, 적절한 도구·검증 기준·병렬 작업 환경과 상당한 시간·비용이 필요하다.
• 주요 근거는 팀의 주관적 평가와 직접 만든 앱·3D 환경·게임 사례이며, 제작 시간과 비용에는 추정치가 포함된다.

🕒 시간순 섹션별 상세정리

1. 사내에서 실제 사용하는 앱까지 확장된 제작 능력

• Fable 5.2 사전 사용에서 팀 전반의 만족도가 높았으며, 주요 관심은 이전 모델보다 어떤 작업을 새롭게 수행할 수 있는지에 있다 [00:46]
• 바이브 코딩으로 만든 앱을 사내 영상 편집과 라이브 스트리밍 등에 실제로 사용하고 있다. 제작 가능한 앱의 규모가 커졌다는 평가의 출발점이다 [01:02]

2. 금메달의 기준은 업무와 가능성에 대한 인식 변화

• Reach Test는 사용하지 않을 빨강, 조건부로 사용하는 노랑, 매일 사용하는 초록, 패러다임 전환에 해당하는 금메달로 나뉜다 [02:12]
• Katie는 금메달 평가에 인색했지만 이번 모델에는 금메달을 부여했다. 내부에서는 향상 폭이 커서 버전명이 5.5일 것으로 예상했다 [03:00]

3. 생산성 향상과 함께 높아진 작업 목표

• 약 3주간 사용한 뒤 접근이 잠시 중단됐다가 출시 직전에 다시 열리는 경험을 통해, 모델 사용 전후의 업무 변화를 체감했다 [04:04]
• Mike는 한 주에 약 8주 분량의 일을 했다고 개인적으로 추산했다. 이는 정식 측정 결과가 아닌 자신의 작업량에 대한 평가다 [04:18]

4. 느린 응답을 전제로 병렬 실행과 환경 준비가 필요

• Mike는 과학 논문 작성과 수백 차례의 실험을 수행하면서 여러 작업을 동시에 진행하게 됐다 [05:09]
• 모델은 더 느리고 숙고하는 성향이 강하며 비용 부담도 있지만, 이전 Fable보다는 조금 저렴하다는 평가다. 효과적으로 쓰려면 사용자도 작업 방식을 바꿔야 한다 [05:24]

5. 장시간 작업의 강점에도 시간과 비용을 고려한 초록 평가

• Dan은 평가자 중 유일하게 초록 등급을 줬다. 장시간 빌드에서는 패러다임 전환에 해당한다고 보면서도, 소요 시간과 다른 모델보다 높은 비용을 제약으로 봤다 [06:22]
• 글쓰기에서는 여전히 Austra를 선호했다. 전체적인 호평이 모든 작업에서 단일 모델을 선택한다는 뜻은 아니다 [06:44]

6. 전문 지식과 장기 실행이 결합하며 커지는 제작 범위

• Kieran은 브라우저와 자신의 컴퓨터에서 실행되는 디지털 오디오 워크스테이션을 만들었다. 이미 가진 음악 제작 지식과 구체적인 요구를 구현으로 연결할 수 있다는 점을 높게 평가했다 [07:27]
• Fable 5.1·5.0처럼 밤새 실행할 수 있으면서 결과가 더 좋아졌으며, 무엇을 만들 수 있을지 상상하는 사용자의 능력이 병목이 될 수 있다고 봤다 [08:07]

7. 자율 실행의 성패를 가르는 검증 기준과 도구

• 큰 목표에는 평가 기준과 반복 검증 절차가 함께 있어야 한다. 오래 실행하는 것만으로 원하는 결과가 보장되지는 않는다 [08:54]
• 슬라이드 수정 작업에서는 모델이 자료 전체를 살피는 듯했지만 실제로는 텍스트만 읽었다. 이미지에 담긴 정보를 놓쳐 오류가 발생했다 [09:00]

8. 예루살렘 3D 벤치마크에서 드러난 몰입감과 제작 시간의 차이

• 과제는 예수의 마지막 방문과 처형이 있었던 주간의 예루살렘을 몰입감 있고 역사적으로 정확한 3D 환경으로 만드는 것이다. Astra는 약 20분 만에 방향과 지리는 대체로 맞지만 세부 묘사가 적은 결과를 냈고, Argon은 텍스트 비중이 높고 충돌 처리가 없었다 [11:30]
• Fable 5.2 결과에는 성경에서 가져온 42개 경유지, 성전 제물의 연기, 시대에 맞춘 복장의 인물, 기둥을 통과하지 못하게 하는 충돌 처리가 포함됐다 [12:47]

9. 공간 탐색을 통해 구체화되는 역사 학습

• Katie는 복음서에서 읽은 사건을 공간적으로 이해하는 데 도움을 받았다. 주변 마을과 감람산, 성전 사이를 이동하며 인물들의 동선과 환경을 구체적으로 떠올릴 수 있었다 [16:25]
• 직접 돌아다닐 수 있는 환경은 사건이 실제 장소에서 일어났다는 감각을 강화하고, 기존 텍스트에 대한 이해를 풍부하게 했다 [17:27]

10. 포도주 제조 게임으로 연결된 취향과 상호작용 학습

• Kieran은 별도의 아트 디렉션 없이 아늑하면서도 전문적인 포도주 제조 게임을 요청했다. 3D 제작과 설명 능력이 결합하면 개인의 좁고 구체적인 관심사도 게임으로 구현할 수 있다 [18:50]
• 발효와 펀치다운 같은 과정을 설명으로 접하고 직접 조작하며 결과를 확인할 수 있다. 질문과 행동을 연결하는 상호작용이 학습의 재미를 높였다 [20:05]

11. 영화 속 전투를 자유롭게 탐색하는 브라우저 환경

• Mike는 어벤져스의 뉴욕 전투가 자신의 집에서 어떻게 보일지 궁금해 제작을 시작했다. 결과물에서는 시간대를 이동하며 장면과 등장인물의 위치를 확인하고, 스타크 타워 내부로도 들어갈 수 있다 [21:44]
• 화면에 등장하지 않는 인물의 위치까지 추정해 배치하며, 인물을 따라가거나 주변을 걸어 다닐 수 있다. 제작은 금요일부터 일요일까지 이어졌다 [23:02]

12. 기준 자료와 반복 검증이 장기 실행의 품질을 높이는 방식

• 영화의 사건·시간·장소에 대한 지식이 계획과 검증의 기준으로 작용했다. 목표 상태를 확인할 근거가 있으면 오류를 찾아 수정하는 작업을 계속할 수 있다 [25:02]
• 모델은 수천 차례의 테스트를 실행했다고 보고했다. 인물이나 카메라가 건물에 끼는지 여러 위치와 각도에서 확인하는 작업이 포함됐다 [25:30]

13. 낮아진 단가와 여전히 큰 프로젝트별 토큰 비용

• 뉴욕 전투 환경의 총비용은 API 가격 기준 약 3,000달러로 추산됐다. 개인 구독의 실제 부담은 다를 수 있으며, 도시 전체 대신 일부 장면으로 범위를 줄이는 방안이 제시됐다 [26:43]
• 이전 Fable보다 가격이 20% 낮아졌고, 10달러에서 8달러로 내려갔다는 설명이 있었다. 다만 발언자는 구체적인 가격 수치를 확신하지는 않았다 [27:19]

14. 비용 비교의 기준이 엔지니어링 인력으로 확대

• 높은 토큰 비용도 이전에는 구현하기 어려웠던 결과물을 만들 수 있다는 점과 함께 판단해야 한다. 엔지니어가 Opus 5.5와 함께 작업하는 비용을 비교 대상으로 삼으면 경제성 판단이 달라질 수 있다 [28:14]
• 이 능력이 엔지니어를 대체하는 데 쓰일지, 엔지니어의 역량을 확장하는 도구가 될지는 열린 질문으로 남았다 [28:41]

15. 체감 성능 향상과 5.2라는 버전명 사이의 간극

• 팀은 기존에 시험한 모델을 넘어서는 문턱을 넘었다고 평가하며 5.5가 아닌 이유를 물었다. Jeremy는 명칭을 여러 이유로 결정한다고 답했지만, 구체적인 명명 근거까지 밝히지는 않았다 [29:53]

16. 모호한 요구에서 드러나는 판단력과 범위 조절

• 내부 사용자는 Fable 5.2가 미묘한 차이를 판단하고 창의적인 선택을 하며, 장기 작업을 지능적으로 수행한다고 평가한다. 주요 사용처는 소프트웨어 엔지니어링과 기술 지식 업무다 [30:54]
• 초기 시험 사용자와 고객의 경험에서는 맥락이 모호할 때 적절한 결정을 내리는 능력이 개선됐다. 필요한 경우 요구 이상의 작업을 하면서도 과업의 범위를 지키는 점이 강점으로 꼽힌다 [31:17]

17. 과학 연구와 하드웨어 설계로 넓어지는 활용 범위

• 출시 블로그에는 과학적 발견, 생물학 연구, 새로운 치료법 연구, 물리적 엔지니어링 관련 성과가 소개됐다. 실제로 작동하는 하드웨어를 설계하는 능력도 사례로 제시됐다 [31:55]
• 집 안의 공간에 맞는 가구를 설계하고 CNC 가공과 조립 설명서까지 연결하는 아이디어가 나왔다. 다만 답변자는 가능하다는 의견은 봤어도 실제 구현 사례를 직접 보지는 못했다고 선을 그었다 [32:36]

18. 일상 작업과 어려운 작업을 나누는 모델 선택 기준

• Opus 5.5는 신뢰성, 속도, 효율, 일상 작업의 품질 때문에 기본 모델로 사용된다 [33:29]
• 요구가 불명확하거나 모든 조건을 명시하기 어렵고, 명확한 검증·반복 과정이 없는 작업에서는 Fable 5.2를 선택한다. 과학 연구, 물리적 설계, 전체 소프트웨어 스택을 Rust로 다시 작성하는 복잡한 마이그레이션이 예로 드러난다 [34:07]

19. 실험 재작업 감소와 자율 연구의 진전

• 한 사용자는 생산성이 약 세 배로 높아졌다고 체감했다. Opus에서도 지시를 정확히 주면 실험을 잘 수행하지만, Fable 5.2에서는 의도와 다른 실험 결과 때문에 다시 실행하는 일이 줄었다 [35:19]
• 내부 경험에서도 실험과 평가를 처음부터 올바르게 구성하는 능력이 개선됐다. 반복이 완전히 없어지는 것은 아니지만, 더 나은 출발점에서 작업하며 세부 사항을 모두 명시하지 않아도 의도를 잘 파악한다는 고객 반응이 있었다 [35:51]

20. 검증의 깊이와 작업 속도를 조절하는 노력 수준

• 한 사용자는 Opus라면 하루나 반나절에 끝낼 작업을 Fable 5.2가 며칠 동안 수행하고, 그동안 천 번의 실험으로 검증한 경험을 들었다. 긴 대기 시간 때문에 여러 프로젝트를 동시에 진행하는 방식으로 작업 습관이 바뀌었다 [37:29]
• 높은 노력 수준에서는 반복과 검증이 더 꼼꼼해질 수 있다. 빠른 피드백이 필요하면 medium으로 낮추는 방법이 권장되며, 특히 xhigh에서는 검증 범위를 매우 넓게 잡을 수 있다 [37:52]

21. Fast mode의 비용과 지연 시간 절충

• Fable 5.2는 5.1보다 저렴하며, 제공자 측은 과업당 비용과 완료 시간의 효율에서도 Opus 5.5를 포함한 다른 모델보다 우세한 구간이 있다고 주장한다. 다만 fast mode 자체의 높은 비용에 대한 사용자 우려도 인정한다 [38:33]
• Fast mode는 마감이 임박한 실험, 결과 확인, 초안 수정처럼 사람이 즉시 피드백하며 진행하는 작업에 적합하다. 이후에는 자율 작업을 백그라운드로 넘길 수 있으며, 실제로 수 주 동안 지속한 작업도 관찰됐다고 한다 [39:04]

22. 총괄 모델과 조언자 모델로 나뉘는 협업 방식

• Fable 5.2가 계획과 판단을 맡고, Opus 5.5나 Sonnet 5.5가 실행하는 구성이 드러난다. 총괄 모델에 fast mode를 사용하면 피드백을 빠르게 주고받으면서 Fable의 토큰 사용을 줄일 수 있으며, 일부 고객에게서 효과가 있었다 [40:51]
• 반대로 Opus나 Sonnet을 주 실행 모델로 두고, 막히는 부분에서만 Fable에 조언을 요청할 수도 있다. 복잡한 버그처럼 일부 구간에만 높은 판단력이 필요할 때 적합하다 [41:28]

23. 단종 하드웨어를 사진과 연결 도식으로 지원한 사례

• 사진을 바탕으로 부품에 주석을 달고 각 요소를 식별해, 약 20년 전 단종된 장비를 연결하는 작업을 도왔다. 사례에 등장한 Schneider의 com box는 eBay 외에는 구하기 어렵다는 설명이 붙었다 [46:26]
• 모델이 만든 연결 도식은 장인이 장비를 연결하는 데 필요한 안내로 활용됐다. 이는 새로운 하드웨어 설계와 별개로, 오래된 장비의 이해와 조립을 지원하는 구체적인 사용 사례다 [46:33]

24. UI 실험에서 드러난 상태 보존과 애니메이션의 세밀함

• 디자인 시험은 정량 점수가 없는 자체 비교로, 드롭다운·토글 같은 실용 UI와 창의적인 인터랙션을 함께 다뤘다. Opus 5.5와 Fable 5.2, 노력 수준별 결과를 비교했다 [47:23]
• Max 설정의 사진 버튼 예제에서는 태양이 움직이고, 촬영한 이미지가 아래로 이동한 뒤에도 촬영 순간의 태양 위치를 유지했다. 이전 시험에서는 보지 못했던 세밀한 상태 처리가 강점으로 꼽혔다 [48:05]

25. 정적 디자인과 인터랙션 구현에서 달라지는 비용 효율

• 디자인 실무에서 Fable을 얼마나 자주 사용할지는 아직 불확실하다. Opus의 비용 효율이 좋고, Sonnet medium도 대부분의 작업을 충분히 수행하지만, 정적 화면을 넘어서는 디자인 엔지니어링에서는 Fable이 더 뛰어나다는 평가다 [49:49]
• Fable을 선택할 뚜렷한 이유는 많은 인터랙션과 애니메이션이 필요한 도전적인 작업이다. 앱이 빠르게 동작하는 것 자체도 좋은 디자인의 중요한 조건으로 드러난다 [50:56]

26. 대화만으로 구현한 앰비언트 음악 전용 DAW

• Kieran은 모델과 대화하며 앱을 만들었고, 코드를 읽거나 PR을 병합하는 방식으로 작업하지 않았다고 보여준다. 대표 결과물은 앰비언트 음악용 디지털 오디오 워크스테이션으로, 소리 재생과 효과 추가가 가능하다 [52:59]
• 작곡가이자 음악가로서 축적한 경험을 바탕으로 Ableton Live, Pro Tools, Logic, Reason 등에서 좋아했던 요소를 결합했다. 전문 소프트웨어에 대한 이해가 원하는 기능을 구체화하는 기반이 됐다 [53:30]

27. 맞춤 음향 효과와 에이전트 기능으로 확장한 음악 환경

• 일반적인 EQ뿐 아니라 원하는 배음이 공명하도록 설정하는 harmonic reverb 같은 맞춤 효과를 만들었다. 선법과 조율 방식도 선택할 수 있어 개인의 음악적 요구를 기능에 반영했다 [54:07]
• 에이전트에 새소리를 추가하라고 요청하면 새처럼 들리는 신시사이저를 생성하도록 구성했다. 자체 플러그인을 JUCE에서 WebAssembly로 컴파일했고, 게시·라디오·믹싱·연주 기능과 실시간 음성 입력도 포함했다 [54:47]

28. 개인의 창작 방식에 맞춘 소프트웨어 제작 가능성

• 이 DAW는 기존 제품 하나를 그대로 복제하기보다 여러 도구에서 좋아했던 요소를 골라 앰비언트 음악에 맞춘 결과물이다. 제작자는 구매 수요가 거의 없다고 보는 분야에서도 자신을 위한 소프트웨어를 만들 수 있게 됐다는 데 의미를 둔다 [56:01]
• 자신의 소프트웨어로 플루트와 피아노를 연주하며 합주한 경험은 도구 제작이 실제 창작으로 이어질 수 있음을 보여준다. 이런 경험이 창작자들의 AI에 대한 태도를 바꿀 가능성도 제기된다 [56:22]

29. 이전 모델의 작업 규모 한계를 넘었다는 사용 경험

• 이전 모델로도 음악 앱을 시도했지만, 작업 규모가 커지면 사람이 직접 해야 할 일이 너무 많았다. 여러 신시사이저와 수많은 효과를 채우는 작업이 부담의 예로 드러난다 [57:41]
• 이번에는 compound engineering 방식으로 앰비언트 음악용 효과 50개를 구상하게 한 뒤 모두 구현하도록 요청했고, 효과와 팩 등 추가 요구를 계속 맡겼다. 모델이 작업을 이어가면서 장난감 수준을 넘어 전문가인 자신에게도 쓸 만한 도구가 됐다고 평가한다 [58:29]

30. 전문가용 결과물과 코드 비개입 방식의 결합

• 다른 참여자는 전문 음악가가 실제로 사용할 수 있는 수준의 소프트웨어라는 점에서, 결과물을 단순히 ‘바이브 코딩’이라고 부르면 가치를 낮춰 표현할 수 있다고 본다 [59:26]
• Kieran에게 바이브 코딩은 자신의 엔지니어링 경험으로 방향을 조정하되 코드와 PR을 직접 검토하지 않는 작업 방식이다. Compound engineering을 활용하며, 이전 모델에서는 필요했던 구현 과정의 직접 개입이 크게 줄었다고 보여준다 [59:54]

31. 자체 영상 편집기 Every Cut의 제작과 기능

• 기존 화면 녹화 도구의 편집 기능에 아쉬움을 느껴 전문 영상 편집기를 한 번의 요청으로 만들었고, 그 결과물인 Every Cut을 팀 내부에서 사용하고 있다. [1:00:38]
• 단어를 수정해 영상을 편집하는 Descript 방식의 편집기, 레이어 타임라인, 천 개 이상의 도구 호출에 접근하는 에이전트를 결합했다. 사용자가 자신의 에이전트를 연결할 수도 있다. [1:01:06]

32. 개인 제작에서 팀 전체의 피드백 순환으로 확장

• 개인용 음악 앱과 달리 Every Cut은 팀을 위한 앱이다. 적어도 내부 사용에서는 코드를 직접 보지 않고도 팀 전체의 피드백으로 앱을 발전시키는 작업 방식이 가능해졌다. [1:02:14]
• 팀원의 요구가 서로 어긋나거나 실제 필요를 잘못 표현하면 개발 방향이 흔들릴 수 있다. Fable 5.2는 이런 상황에서 적절한 기능을 선택하고 추가하는 판단력이 좋다는 평가를 받았다. [1:02:43]

33. 초기 개발비와 자동화된 유지보수의 경제성

• 초기 버전의 토큰 비용은 약 1만 달러였던 것으로 추산한다. 큰 비용이지만, 구독에 포함된 사용량으로 처리하는 경우도 있으며 이 정도 기능의 앱을 직접 만들 수 있다는 선택지 자체에 가치가 있다는 판단이다. 일부 제품은 필요한 인력과 초기 자금이 줄어들 수 있다는 전망도 나온다. [1:03:27]
• 기능을 요청한 회의가 끝나기 전에 구현이 완료된 경험이 있으며, 유지보수에는 compound engineering 방식의 반복 작업과 Slack의 C sweep 명령을 활용한다. [1:04:30]

34. 읽기 쉬워진 응답과 지나친 단문화의 위험

• Fable 5.2는 대화 내용을 따라가고 이해하기 쉽다. Fable 5에서 느꼈던, 모델이 무엇을 하는지 또는 어떻게 상호작용해야 하는지 이해하기 어려운 문제가 줄었다. [1:05:45]
• 응답의 읽기 수준은 약 7.5학년으로 측정됐으며, 이전 Fable의 약 8학년 수준보다 낮아졌다. 여러 모델에서 요구 독해 수준이 낮아지는 흐름이 이어지고 있다. [1:06:10]

35. low에서도 가능한 초안 작성과 남은 정보 배치 문제

• 이전 모델의 low 설정에서는 AI 특유의 문체, 독자 관점의 부족, 생각의 연결 문제 때문에 초안 작성이 어려웠다. 이번에는 Fable 5.2의 low 설정으로 해당 바이브 체크의 첫 초안을 작성할 수 있었다. [1:06:55]
• 가장 중요한 생각을 앞에 배치하는 능력은 여전히 부족하다. 핵심에 도달하기 전에 긴 일화를 넣는 경향이 있어, 독자에게 중요한 정보부터 제시하도록 구조를 다듬어야 한다. [1:07:34]

36. 반복적인 글쓰기에서는 Opus 5.5의 우위 유지

• Fable의 low 설정으로 초안을 쓸 수 있게 됐지만, 반복해서 주고받으며 수정하는 글쓰기에서는 빠르고 효율적인 Opus 5.5의 medium 또는 high 설정이 여전히 더 낫다는 판단이다. [1:08:12]
• 산문 초안을 작성할 때 Fable의 추론 강도를 지나치게 높이면 추가 이득이 줄어들 수 있다. Extra High나 Max까지 사용할 필요는 없다는 권고다. [1:08:47]

37. 디자인 평가에서 확인한 추론 강도와 컨텍스트 차이

• 여러 추론 강도로 진행한 약 150개 테스트에서 웹사이트 제작과 디자인 작업은 high를 넘기면 결과가 나빠지는 경향이 있었다. 지나치게 많은 것을 시도하기 때문일 수 있지만, 원인은 확인되지 않았다. [1:11:47]
• Max나 Extra High가 더 좋을 것이라는 선입견을 줄이기 위해 설정을 가린 채 결과를 채점하고 나중에 어떤 설정인지 확인했다. 예시 과제는 정량 트레이딩 분석 플랫폼의 랜딩 페이지를 단일 HTML 파일로 만드는 것이었다. [1:13:53]

38. 반복되는 디자인 취향과 기본 스타일 금지 실험

• 디자인 결과에는 녹색 계열이 반복적으로 나타났다. 해당 색감은 평가자 개인의 취향에는 맞지 않았으며, 모델의 기본적인 시각적 성향으로 관찰됐다. [1:15:36]
• 스케이트숍 웹사이트는 실제 매장에서 쓰기에는 지나치게 기교적이었다. 특히 Max 결과는 이상한 요소가 많아 품질이 가장 나쁜 편이었다. [1:15:56]

39. 자유 창작과 SVG의 한계, 비교 평가의 공백

• 구체적인 기획 없이 자랑할 만한 결과물을 만들라고 요청하자 직조 형태의 시각물이 반복적으로 생성됐다. 자유로운 과제에서도 특정한 취향이 드러났다. [1:17:16]
• SVG와 종이비행기 반복 애니메이션은 결과가 좋지 않았고, medium 결과는 다소 느렸다. 해당 테스트들에서도 가장 좋은 결과는 high, 특히 100만 토큰 컨텍스트 버전에서 나왔다. [1:17:57]

40. 지식 업무의 차이를 드러내는 다단계 의사결정

• Fable 5.2는 일반적인 지식 업무에는 필요 이상으로 강력할 수 있다. 이메일이나 보고서 작성만으로 성능의 큰 차이를 체감하기는 어렵고, 연구 작업에서는 좋은 결과를 얻었다. [1:19:24]
• AI의 트레이딩 역량을 정량적으로 비교하기 위한 LLM 트레이딩 벤치마크를 준비하고 있다. 주요 트레이딩 회사의 필기시험과 사고력 문제에서는 거의 모든 모델이 100%에 가까운 성과를 보여 변별력이 부족했다. [1:20:22]

41. 기존 코드베이스 이해와 유지보수성에 대한 신뢰

• 생성 코드가 깔끔하고 유지보수하기 좋아 장기간 앱에 남겨두고 싶다는 평가가 나왔다. 이러한 코드 품질이 코드를 직접 읽지 않고 개발을 진행할 때의 자신감을 높였다. [1:22:27]
• 기존 앱의 맥락과 필요한 변경을 더 철저하게 이해한다는 경험이 제시됐다. 특히 변경하기 어려운 코드베이스나 중요한 코드 작업에서 활용할 가치가 크다는 판단이다. [1:23:09]

42. 주말 동안 75개 PR을 만든 백로그 처리

• Checks 개발에서는 자동 리뷰와 엔지니어의 검토를 병행하면서, 금요일부터 일요일까지 75개 PR을 만들어 백로그를 크게 줄였다. 코드를 직접 읽지 않고 작업했지만 검토 장치는 함께 사용했다. [1:24:36]
• PR을 영향이 큰 순서로 정리하고 서로 쌓아 하나의 병합 대기열로 구성했으며, 변경 내용을 설명하는 30분짜리 영상도 생성했다. 백로그에는 구현하기로 결정하지 못한 일만 남아야 한다는 작업 관점으로 이어졌다. [1:25:01]

43. 질문과 제품 결정을 한곳에 남기는 작업 방식

• 개별 작업 스레드마다 질문에 답하는 부담을 줄이기 위해, 필요한 질문을 한꺼번에 받는 마스터 스레드를 만들었다. 답변 기록은 다른 엔지니어나 에이전트가 구현 이유를 확인하는 근거로 활용할 수 있다. [1:26:44]
• 완료하지 못한 일도 별도로 정리했다. 특정 프로젝트와 연결된 작업이나 제품 결정을 먼저 내려야 하는 일이 남으면서, 수백 개 티켓 중심의 대기열이 의사결정 중심으로 바뀌었다. [1:27:12]

44. 흩어진 대화에서 제품 철학을 체계화한 문서

• Checks의 제품 철학을 정리하기 위해 통화 자막과 Slack 메시지 등 약 1,000건의 자료를 읽게 했으며, 그중 통화 자막은 143건이었다. 아이디어 초기 논의부터 온보딩과 질문 답변까지 흩어진 기록이 정리 대상이었다. [1:27:55]
• 결과물은 Checks를 설명하는 12개 문장과 그 문장으로 만든 영상, 확정된 규칙과 작업 중인 규칙, 발전 중인 영역과 의견이 갈리는 영역을 포함했다. 제품 용어의 정의까지 한곳에 모으면서 합의와 미해결 쟁점을 함께 확인할 수 있게 됐다. [1:28:58]

45. Checks의 공개 범위와 Fable 결과 게시 계획

• Checks의 이용 권한을 어떻게 제공할지는 아직 결정 중이다. checks.every.to에서는 일부 공개 벤치마크를 볼 수 있으며, Fable이 공개된 만큼 관련 결과도 게시할 계획이다. [1:29:43]

46. 자동화 확대의 병목과 실습 계획

• 더 넓은 이용자층으로 공개할지는 아직 검토 중이다. [1:30:03]
• 자동화를 더 적극적으로 적용하려면 사람이 어느 지점에서 병목이 되는지 찾아 줄여야 한다. 관련 학습 내용과 적용 방법을 담은 글은 당일 공개할 예정이다. [1:31:07]

47. 성경 공부 앱에서 드러난 구체적 명세 처리의 한계

• Marginelia 벤치마크는 성경 본문 옆에 메모를 남기고, 아이디어를 연결하며, 책·주제·개념을 모아 관리하는 개인용 앱을 만드는 과제다. 동일한 명세로 만든 Astra의 결과물은 기능 배치와 버튼의 용도가 명확했다. [1:32:54]
• Fable 5.2의 결과물은 상대적으로 사용하기 어려웠고, 핵심인 성경 본문도 쉽게 찾기 힘든 곳에 묻혀 있었다. [1:33:30]

48. 장기 작업과 대규모 맥락 해석에 대한 기대

• Fable 5.2는 밤새 또는 일주일 동안 맡겨 두는 작업과 중요한 업무를 위임할 유력한 모델로 평가된다. 코딩과 과학 작업에는 강점이 있지만, 글쓰기는 여전히 Opus 5.5를 우선하며 디자인과 모호한 문제에는 선택적으로 활용할 만하다는 판단이다. [1:34:52]
• 큰 맥락에서 의미 있는 내용을 골라내는 능력을 활용해 Slack, 이메일, Granola 메모를 지속적으로 살피고 관심사와 통찰을 찾아주는 개인용 점검 체계를 만들고자 한다. 직접 고른 것보다 나은 내용을 모델이 찾아냈다고 느낀 경험이 이 기대의 근거다. [1:35:41]

49. 모호한 아이디어를 구현하고 기존 한계를 다시 시험하기

• 벤치마크 플랫폼을 다른 프레임워크로 옮기면서 무한 캔버스를 추가하는 것처럼, 원하는 방향만 있고 세부 요구가 불분명한 작업에서 Fable의 가능성을 높게 평가한다. 같은 유형의 요청에서 Opus는 무언가를 만들더라도 의도한 결과에는 도달하지 못했다는 경험이 근거다. [1:37:13]
• 한 참여자는 여러 앱을 만들면서 아직 모델이 무너지는 지점을 보지 못했다고 평가한다. 다만 외형이 최상은 아니었으며, 사람이 반복해서 개선에 참여하면 어디까지 완성도를 높일 수 있고 어떤 한계가 드러날지는 추가로 확인하려 한다. [1:37:44]

50. 작가가 원하는 워드프로세서를 직접 만드는 구상

• 전문가가 자신에게 꼭 맞는 소프트웨어를 직접 만드는 사례로 개인 워드프로세서 프로젝트가 드러난다. Every Type과 별도로, WordG Good은 compound writing 플러그인을 내장한 워드프로세서를 목표로 한다. [1:39:49]
• Fable 5와 Astra를 사용할 때는 직접 디버깅하고 모델이 막힌 부분을 해결해야 했다. 이제는 필요한 기능과 작가에게 자연스러운 사용 방식을 지정해 구현을 맡길 수 있을 것이라는 기대가 생겼지만, 실제 완성 여부와 Google Docs에 도전할 가능성은 앞으로 확인할 과제다. [100:40] [1:40:04]

51. 제작 도구의 공개와 실용적인 사용법 공유

• Every Cut, Every Type, 다른 사람이 활용할 수 있는 Every Checks의 일부를 포함해 이번에 만든 작업물을 오픈소스로 공개할 계획이다. 공개는 앞으로 이루어질 예정이다. [101:16] [1:41:18]
• 금요일 구독자 실습에서는 모델을 실제로 사용하는 방법과 지난 몇 주 동안 얻은 팁을 공유할 예정이다. 상세 글과 후속 공유를 통해 실험 결과를 실무 적용으로 연결하려 한다. [101:43] [1:41:33]

🧾 결론

• 가장 뚜렷한 변화는 전문가가 자신의 요구를 실제로 사용하는 소프트웨어로 연결하는 범위가 넓어졌다는 점이다. 음악 제작 지식과 팀의 피드백이 구현 방향을 잡는 핵심 자원으로 작용했다.
• 오래 실행하거나 추론 강도를 높이는 것만으로 품질이 보장되지는 않는다. 일부 디자인 시험에서는 high를 넘기면 결과가 나빠졌고, 구체적인 명세를 준 성경 공부 앱에서도 사용성이 부족했다.
• 이번 평가는 사전 사용자들의 경험과 자체 시험을 중심으로 한 판단이다. 장기 코딩·연구에 대한 호평과 글쓰기·디자인에서의 한계, 대기 시간과 비용을 함께 읽어야 한다.

📈 투자·시사 포인트

• 소프트웨어 제작의 경제성을 판단할 때 모델 사용료뿐 아니라 엔지니어의 작업 시간, 재작업, 유지보수 부담까지 비교필요가 있다. 영상의 사례들은 비교 기준이 넓어질 수 있음을 보여준다.
• 개인의 좁은 취향이나 팀 내부 요구에 맞춘 소프트웨어도 제작 대상이 될 수 있다. 맞춤형 DAW와 Every Cut은 기존 제품의 기능에 사용자를 맞추던 방식에서 벗어날 가능성을 보여준다.
• 도구 연결, 평가 설계, 피드백 수집, 모델 간 분업이 활용 성과를 가르는 요소로 부각된다. 모델 자체의 능력과 이를 운영하는 환경을 함께 평가해야 한다.
• 엔지니어 대체와 역량 확장 중 어느 효과가 커질지는 미정이다. 이 영상만으로 특정 기업의 수익성이나 투자수익을 추정할 근거는 부족하다.

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

• 생산성 3배, 한 주에 8주 분량의 작업을 했다는 발언은 개인의 체감과 추산이다. 작업 난도와 사람의 투입을 통제한 측정 결과로 볼 수 없다.
• 프로젝트 비용과 가격 인하 수치에는 추정과 기억에 의존한 설명이 포함된다. API 환산 비용, 구독에 포함된 사용량, 실제 결제 부담을 구분해야 한다.
• 디자인 시험에는 자체 채점과 제한된 비교가 포함된다. 후반부의 동일 디자인 과제를 Opus 5.5로 실행하지 않았으므로 두 모델의 전반적인 디자인 우열을 확정할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 최근 모델이 실패했던 과제 하나를 골라 다시 실행하고, 성공 조건과 사람의 개입 시간을 기록한다.
• 장기 작업을 맡기기 전에 필요한 도구, 기준 자료, 테스트 절차, 이미지 등 확인해야 할 입력 범위를 명시한다.
• 같은 과제를 기준으로 완료 시간, 토큰 비용, 재작업 횟수, 실제 사용성을 비교해 모델을 선택한다.
• 빠른 수정은 medium 등 낮은 노력 설정으로 시작하고, 검증의 깊이가 필요한 구간에서만 설정을 높인다. 디자인은 high 이상이 항상 유리하다고 가정하지 않는다.

❓ 열린 질문

• 장기 자율 실행의 이점은 어떤 과제 규모와 검증 환경에서 대기 시간·사용료를 상쇄하는가?
• 모호한 요구를 처리하는 판단력은 여러 사용자와 더 큰 서비스에서도 안정적으로 유지되는가?
• 높은 노력 설정이 일부 디자인 결과를 악화시킨 이유와 큰 컨텍스트 버전이 더 좋은 결과를 낸 이유는 무엇인가?