Live: NEW MODEL VIBE CHECK

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Live: NEW MODEL VIBE CHECK를 중심으로, Opus 5.5는 협업 경험과 결과물 품질에서 호평을 받았다. 이전 버전보다 대화가 편해졌고, 디자인·3D·교육용 인터랙티를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. Opus 5.5는 협업 경험과 결과물 품질에서 호평을 받았다. 이전 버전보다 대화가 편해졌고, 디자인·3D·교육용 인터랙티브 콘텐츠에서 강점을 보였다는 평가다. 일부 출연자는 주력 모델을 바꾸거나 사용 비중을 높였다.
2. 노력 수준은 품질뿐 아니라 시간·비용·사용자 참여를 조절한다. 낮음·중간 설정에서도 좋은 결과가 나왔고, 높은 설정은 검증과 세부 구현을 늘렸다. 다만 추가 품질이 긴 대기와 비용을 정당화하는지는 작업마다 달랐다.
3. 자율 작업의 확장과 완료 능력은 별개였다. 교육 콘텐츠와 게임을 장시간 제작하고 자체 검토하는 모습은 인상적이었지만, 시간 제한을 넘기거나 스스로 세운 품질 기준 때문에 완료하지 못한 사례도 있었다. 승인 요구와 반복 정체 역시 실무 효율을 떨어뜨리는 요인으로 지적됐다.
4. 글쓰기·디자인·코딩에 같은 순위를 적용하기 어렵다. 개인 글쓰기 평가에서는 Astra와 GPT-6 Soul이 앞섰고, Opus 5.5의 상세한 문체를 덜 선호하는 의견도 있었다. Grok 4.7은 비용과 기존 업무 환경 때문에 계속 쓰는 사용자도 있었지만, 초기 신뢰성·완주·글쓰기 품질에 대한 평가가 엇갈렸다.
5. 모델 선택은 실제 업무를 검사하는 개인 벤치마크로 구체화할 수 있다. 초안 품질, 약한 제목 발견, 지시 준수처럼 자신의 수정 경험을 평가 항목으로 바꾸는 접근이 소개됐다. 디자인 선호와 규칙 준수는 따로 평가하고, 익숙한 도구와 용도별 모델 조합도 함께 고려해야 한다.

🧩 배경과 문제 정의

• Every의 초기 평가는 출시 직후의 Claude Opus 5.5가 이전 Opus 5의 불편한 대화 방식과 작업 습관을 개선했는지, 실제 업무에서 다시 선택할 만한지를 다룬다.
• 비교 기준은 정답률에 한정되지 않는다. Fable 5.1·Astra와 비교한 결과물 품질, 협업 방식, 속도, 비용, 구독 사용량 한도가 함께 고려된다.
• 핵심 쟁점은 높은 지능을 일상적인 비용으로 활용하면서도 모델의 자율적 판단과 사용자의 개입 사이에 적절한 균형을 만드는 것이다. 평가는 초기 사용 경험에 기반하며, 향후 모델과 비용 변화에 관한 기대도 포함한다.

🕒 시간순 섹션별 상세정리

1. 시간 관리의 약점에도 개선된 첫인상

• 마이크는 Opus 5.5를 녹색과 금색 사이로 평가했다. 몇몇 과제를 시간 관리 실패로 망친 점이 없었다면 금색 평가를 줬을 만큼 전반적인 경험은 좋았다 [02:35]
• 대화하기 편한 정도는 Fable 5.1 수준이며, 자신을 Codex로 이동하게 했던 Opus 5의 불편한 특성이 줄었다고 평가했다 [02:58]

2. 기존 주력 모델을 바꿀 만큼 높아진 신뢰

• 마이크는 OpenAI 모델을 주력으로 쓰고 Fable을 약 20% 활용하던 상태에서 Claude와 Codex를 대략 절반씩 사용하는 상태로 바뀌었다. Codex 비중이 남아 있는 이유도 진행 중인 대화를 서서히 옮기고 있기 때문이라고 설명했다 [03:18]
• 키런은 비용보다 가장 잘 협업할 수 있는 모델을 우선해 Fable 5·5.1을 사용해 왔지만, 이제 Opus 5.5를 주력으로 선택했다. 이전 Opus 5와 달리 높은 신뢰를 느끼며, 일부 작업에서는 Fable 5.1보다 낫다고 평가했다 [04:49]

3. 노력 수준이 과잉 작업 대신 완성도를 조절

• 키런의 비교에서 Opus 5.5는 Fable뿐 아니라 Astra와도 경쟁할 만했다. 작은 등급의 모델이 상위 모델에 견줄 수 있다는 점을 이례적인 변화로 받아들였다 [05:52]
• 기존의 저렴하고 덜 똑똑한 모델은 노력 수준을 높이면 불필요한 작업을 늘리곤 했다. Opus 5.5는 높은 노력에서 성능이 좋아지고, 낮은 노력에서는 품질을 무너뜨리기보다 세부 사항을 줄여 사용자의 창작 여지를 남긴다는 평가다 [06:24]

4. 세부 표현과 단순한 디자인, 일상적인 비용의 결합

• 키런은 3차원 세부 표현과 공간적 움직임을 강점으로 꼽았다. 관련 추가 학습이 있었을 것이라고 추측했지만, 이를 확인된 사실로 제시하지는 않았다 [07:18]
• Astra의 인터페이스 결과물은 입체 효과·제목·버튼이 많아 복잡하게 느껴지는 반면, Opus 5.5는 단순하면서도 세밀한 결과물을 만들 것으로 기대했다. 일상 업무에서 빠르고 비용도 낮다는 점 역시 주력 모델 선택의 이유였다 [07:33]

5. Sonnet과 Haiku까지 이어질 5.5 계열

• 게스트는 내부 사용자와 테스터들의 반응을 근거로 Opus 5.5가 Sonnet 3.5나 Opus 4.5처럼 기억될 모델이라고 기대했다 [09:27]
• Sonnet과 Haiku도 출시할 예정이며, 5.5 계열 전체가 일상적인 작업에 더 높은 지능을 제공할 것이라는 전망을 밝혔다 [09:51]

6. 구독 한도 안에서 반복 작업을 활용할 가능성

• 게스트는 Fable을 사용할 때 사용량 한도가 빠르게 소진되고 토큰 효율도 낮아 원하는 작업 흐름을 충분히 활용하기 어려웠다고 설명했다. Opus 5.5에서는 구독 플랜 안에서도 높은 수준의 지능을 활용할 수 있었다고 평가했다 [10:44]
• 개인 웹사이트 재설계에서는 여러 모델을 활용하고, 창의적인 초안에 비평과 반복 수정을 더했다. 이 경험은 Fable과 비슷한 품질을 더 빠르고 저렴하게 활용한다는 인상을 줬다 [11:29]

7. 특별한 선택 기준이 없을 때의 기본 모델

• 게스트는 현재 평균적인 사용에서는 Opus 5.5가 Fable 5.1보다 낫다고 판단했다. 다만 계획이나 안전 관련 작업에는 예외가 있을 수 있다는 여지를 남겼다 [12:17]
• 모델 선택에 별도로 시간을 들이고 싶지 않다면 Opus 5.5가 무난한 선택이며, 자신도 우선적으로 이 모델을 사용한다고 설명했다 [12:30]

8. 복잡한 말보다 이해하기 쉬운 소통

• 마이크는 초기 고지능 모델이 너무 어렵게 말해 사용자를 위축시키기도 했지만, Fable 5.1에서는 지능과 좋은 대화 성격이 공존할 수 있음을 느꼈다고 평가했다 [12:56]
• 게스트는 장시간 일하는 에이전트가 전달할 내용이 많더라도 복잡한 언어 자체가 지능을 뜻하지는 않는다고 설명했다. Opus 5.5에는 소통 방식과 토큰 효율에 관한 사용자 피드백이 반영됐으며, 이런 개선에는 피드백이 학습으로 이어지는 시간이 필요했다 [13:33]

9. 가격·속도·지능을 함께 개선할 수 있다는 관점

• 게스트는 모델 발전이 항상 한쪽 성능을 위해 다른 용도를 희생하는 관계는 아니라고 봤다. Opus 5.5도 더 저렴하고 빠르면서 똑똑해진 사례이며, 특정 사용 사례를 희생했다고 생각하지 않는다고 설명했다 [15:07]
• 앞으로 지능이 더 풍부하고 저렴하며 빨라질 것이라고 전망했다. 이는 향후 발전에 대한 기대이며, 모든 작업에서 이미 같은 개선이 검증됐다는 의미는 아니다 [15:39]

10. 비용 감소가 검토와 선제적 작업의 범위를 확대

• 토큰 사용량이 충분히 커지면 누구나 비용에 민감해진다. 게스트는 모델이 저렴하고 접근하기 쉬워질수록 사용자가 더 많이 활용하는 경향이 있다고 설명했다 [16:36]
• 코드 리뷰, 추가 검증, 피드백에 따른 선제적 PR 작성은 비용 때문에 실행 여부를 고민하는 작업의 예다. 토큰을 많이 쓰는 능동적 기능의 비용이 낮아지면 이런 작업을 수행할 경제적 유인이 커질 것으로 기대했다 [17:03]

11. 글쓰기에서는 문장력과 협업 품질을 구분

• 테스터 케이티의 평가는 최종 문장 자체가 반드시 최고는 아니더라도, Opus 5.5가 함께 작업하기 매우 편한 협업자라는 것이었다 [18:15]
• 게스트는 자신의 문체를 대체하기보다 어색한 단어와 구성 순서를 수정하는 편집 도구로 활용했다. 이전 모델의 조사 보고서가 지나치게 빽빽하고 읽기 어려웠던 문제도 상당히 개선됐다고 느꼈다 [19:00]

12. 지시 준수와 창의적 판단을 함께 수행

• PowerPoint 테스트에서 Opus 5.5는 기존과 다른 SVG 스타일을 선택하면서도 브랜드에 맞는 디자인을 유지했다. 마이크는 이를 창의적인 책임자가 독자적인 판단을 보태는 방식에 비유했다 [20:23]
• 게스트는 사용자의 과거 맥락과 숙련도를 이해하는 기억이 자율성 조절에 도움이 될 수 있다고 봤다. 초보자의 지나치게 야심 찬 요청에는 목표를 확인하고, 숙련자의 요청에는 바로 실행하는 식의 대응 차이가 필요하다는 설명이다 [21:08]

13. 새로운 관점과 무조건적인 동조 사이의 균형

• 마이크의 개인적 경험에서 OpenAI 모델은 매끄럽고 균형 잡힌 반면, Anthropic 모델은 예상하지 못한 아이디어를 주는 경우가 있었다. 새로운 제안을 하려면 모델도 일정한 관점을 가져야 한다는 해석이며, 모델을 지나치게 의인화했을 가능성도 인정했다 [22:10]
• 최고의 농구 선수를 묻고 답변에 반박하는 예시는 모델이 곧바로 사용자에게 동조할지, 기존 판단의 근거를 유지할지의 문제를 보여준다. 협업에는 자기 판단에 대한 확신과 사용자의 의견을 받아들이는 태도 사이의 균형이 필요하다 [23:06]

14. 노력 수준은 문제에 투입할 예산

• 게스트는 노력 수준을 문제 해결에 지출할 의향이 있는 예산으로 설명했다. 낮은 노력에서도 문제를 해결하려는 기본 수준은 유지하며, 높은 노력에서는 초기 사고와 테스트·검증에 더 많은 시간을 쓸 수 있다는 설명이다 [24:59]
• 실패할 수 있는 예외 상황이 많은 HTML 정제 도구 같은 작업에는 높은 노력이 적합하다. 반대로 모델의 수행 능력을 잘 파악한 작업에서는 낮음이나 중간 수준을 사용할 수 있다고 제안했다 [25:42]

15. 낮은 노력은 사용자가 참여할 공간을 확보

• 키런은 낮은 노력의 결과물을 미완성 작업이 아니라 사용자가 채워 넣을 여지가 있는 완결된 스케치에 비유했다. 노력을 높이면 정밀도와 세부 사항이 늘지만, 낮은 설정은 자신의 창작적 기여를 늘리는 데 유용했다 [27:33]
• 게스트는 짧은 시간의 과제에서는 요구를 정확히 좁히고, 긴 시간의 과제에서는 더 많은 가정을 세워 완수하려는 경향에 비유했다. 낮은 노력으로 작업하면 사용자가 과정에 더 많이 관여하는 협업 방식이 가능하다는 관점이다 [28:41]

16. 교육용 인터랙티브 콘텐츠에서 드러난 설명력과 설계 차이

• 교육 능력 시험은 여러 HTML 페이지를 연결해 주제를 깊이 설명하는 ‘탐색 가능한 설명’을 만드는 작업이다. 학습자가 연결된 페이지를 이동하며 개념을 이해하도록 구성한다 [30:23]
• Opus 5의 결과는 무난했고, Faible은 문구의 명료성과 디자인에서 조금 더 나았다는 평가다. Opus 5.5는 전체 콘텐츠 지도와 곳곳의 작은 JavaScript 상호작용을 통해 개념을 더 쉽게 이해하도록 만들었다 [32:00]

17. 장시간 자율 작업과 10분 제한 평가의 충돌

• 탐색형 교육 콘텐츠는 한 번의 요청으로 약 5시간 동안 제작됐다. 수십 개의 하위 에이전트가 50개 파일에 걸쳐 생성·디자인·자체 검토를 수행했다 [33:17]
• 일부 교육 과제는 10분 안에 끝나지 않아 벤치마크에서 감점됐다. 실제 작업에서는 짧은 지시를 준 뒤 완료될 때까지 맡겨 두고 결과를 검토하므로, 같은 시간 제한을 중요하게 보지 않는다는 입장이다 [33:56]

18. 낮음·중간 노력 수준의 효율과 높은 설정의 불확실성

• 여러 노력 수준과 벤치마크를 시험한 사용자는 약 여덟 차례 초기화가 필요했다고 했다. 다만 일반적인 사용량은 아니었으며, 높음·매우 높음 설정의 긴 대기 시간이 그만큼의 가치를 더하는지는 확신하지 못했다 [35:46]
• 낮음 설정에서는 약 2분 만에 뛰어난 랜딩 페이지가 나왔다는 사례가 있다. 작업에 맞는 노력 수준을 고르는 능력이 여전히 필요하다는 판단이다 [36:32]

19. 높은 노력 수준의 추가 품질을 시간·비용과 비교해야 한다

• 모든 작업을 높음으로 설정하는 방식이 항상 최상의 결과를 보장하지는 않으며, 비용도 크게 늘어날 수 있다. Every 내부에서도 설정별 사용법을 정리할 필요성이 제기됐다 [37:29]
• 높은 설정은 더 좋거나 상세한 결과를 만들지만 훨씬 오래 걸리고 비싸다는 평가다. 이전처럼 반복 작업에 빠지는 문제보다는, 추가로 다루는 예외 상황과 세부 사항이 사용자에게 필요한지가 핵심 쟁점이 된다 [38:06]

20. 한 문장 요청으로 확장된 샌프란시스코 게임

• 샌프란시스코에서 영감을 받은 ‘원신 같은 게임’을 요청하자 음악과 음향을 포함한 게임이 만들어졌다. 작업은 약 5일 반 동안 이어졌다고 추정되며, 완료된 상태에는 이르지 못했다 [41:35]
• 게임은 월세 4,200달러, 적으로 등장하는 ‘칼 더 포그’, 전동 스쿠터 같은 지역 소재를 반영했다. 구체적인 디자인 결정을 별도로 지시하지 않았고, 목표를 담은 한 문장 요청에서 나온 결과라는 설명이다 [42:11]

21. 자체 평가가 세밀한 수정을 이끌면서 완료를 지연시켰다

• 모델은 직접 게임을 시험하고 자체 평가하면서 제작자가 알아채지 못했을 문제를 찾았다. 제작자는 주중에 직접 플레이하지 못했고, 모델이 시험하는 모습을 관찰했다 [44:21]
• 시각 요소와 콘텐츠 등을 표로 정리해 10점 만점으로 평가했다. 정신질환자에게 모욕적일 수 있는 티셔츠 문구를 바꾸려 했고, 아래에서 보면 여성 캐릭터의 속옷이 보이는 문제도 발견했다 [45:01]

22. 게임 구현의 기술적 완성도와 후속 지시 없는 확장

• 잔디 표현에 필요한 셰이더도 모델이 직접 작성했다. 기존 Astra나 Claude 모델로 게임을 만들 때는 이 정도 결과에 도달하려면 많은 후속 지시가 필요했다는 경험과 비교된다 [45:50]
• 그래픽·음악·음향을 함께 갖췄고, 반응 지연이 낮으며 프레임률은 약 60이었다는 관찰이다. 게임이 진행될수록 월세가 오르는 설정도 유머에 기여했다 [46:24]

23. GPT-6 Soul의 일상 업무 적합성과 상위 능력의 구분

• GPT-6 Soul은 Codex와 Astra를 일상적으로 쓰던 사용자에게 새로운 주력 모델 후보가 됐다. 필요한 기능을 갖추면서 훨씬 저렴하다는 평가이며, 복잡한 고급 지식 작업에는 Astra를 계속 사용할 생각이다 [49:27]
• 글쓰기·컴퓨터 사용·일반 지식 작업에서는 Soul을 가장 적합하게 평가했다. 다만 Faible 5.1과 같은 수준의 고급 능력을 갖췄다고 보지는 않았고, Opus 5.5의 결과도 매우 인상적이라고 인정했다 [49:50]

24. Opus의 응답 속도 평가는 노력 설정의 영향을 받는다

• Opus 5.5가 일상적인 요청에도 많은 작업을 수행해 답변까지 약 15분이 걸린다는 경험이 나왔다. 이에 낮음 설정에서의 성능을 먼저 확인해야 한다는 반론이 제기됐다 [50:14]
• 해당 사용자는 낮음 설정을 시험하지 않았고 주로 높음 설정을 사용했다고 밝혔다. 따라서 자신의 Opus 평가를 신중하게 받아들여야 한다고 한정했다 [50:35]

25. Checks에서 공개한 개인별 평가와 글쓰기 순위

• Every는 기존 시험을 벤치마크로 전환하기 위해 Mike와 Nitish가 만든 Checks 플랫폼을 사용한다. 공개한 글쓰기 평가를 통해 일상적인 집필 작업에서 특정 모델을 선호하는 이유를 확인할 수 있도록 했다 [51:03]
• 개인 편집·글쓰기 평가의 당시 순위는 Astra가 1위, GPT-6 Soul이 2위였고, Opus 5.5가 그 뒤에 가까이 있었다. 이는 해당 사용자가 매일 수행하는 여러 작업을 바탕으로 한 결과다 [53:11]

26. 실제 업무를 평가 과제로 바꾸는 개인 벤치마크

• 범용 벤치마크 점수가 조금 높아졌다는 사실만으로는 자신의 업무에 적합한 모델인지 알기 어렵다. 개인 벤치마크는 실제 일상 업무를 평가 과제로 삼아, 모델이 잘하는 일과 부족한 일을 더 직접적으로 확인하려는 접근이다 [53:46]
• 편집·글쓰기 평가에는 기사에 유용한 피드백을 주는지, 좋은 초안을 만드는지가 포함된다. 구체적인 비교 과제로는 개인 벤치마크를 설명하는 문서의 도입부 작성이 사용됐다 [54:32]

27. 사용자의 수정과 판단을 누적 가능한 검사로 만든다

• Soul이 쓴 도입부는 개인 벤치마크를 실제 업무에서 가져와 자신의 기준으로 평가하는 과제 모음으로 정의했다. 모델이 약한 제목을 놓쳤다면, 사용자의 수정 경험을 ‘약한 제목을 발견했는가’라는 검사로 바꿀 수 있다는 예시를 들었다 [55:28]
• 수정 사례가 쌓이면 어떤 모델이 자신의 기준을 충족하고 언제 모델을 바꿔야 하는지 판단하는 자료가 된다. Astra의 정의도 실제 업무와 사용자에게 좋은 결과가 무엇인지 포착하는 검사를 연결했다 [55:49]

28. 상세한 글쓰기와 핵심을 먼저 전달하는 글쓰기의 차이

• Opus 5.5는 길게 답하면서 주제에서 조금 벗어나는 경우가 있다는 평가다. 다만 현장에서 그 차이를 보여 줄 정확한 비교 사례를 바로 찾지는 못했다 [56:33]
• 전반적인 인상은 매우 지능적이고 상세하게 쓰지만, 도입부나 검토 의견의 앞부분에 핵심을 놓는 데는 상대적으로 약하다는 것이다. 본론에 도달하기까지 시간이 걸리는 문체가 짧고 직접적인 글을 선호하는 사용자와 맞지 않았다 [57:11]

29. 지시 준수와 사용자가 선호하는 디자인은 다를 수 있다

• Mike의 평가에서는 Opus 5.5가 지시를 정확히 따르지 않은 선택을 오히려 더 선호한 사례가 있었다. Every 브랜드 스타일의 PowerPoint 제작이 그 예다 [58:51]
• 브랜드 가이드는 초록색을 요구했지만 Opus 5.5는 검은색을 사용했고, 평가자는 그 결과를 더 좋아했다. 지시 준수 여부와 실제 결과물의 선호가 엇갈렸다 [59:09]

30. 브랜드 규칙 준수와 디자인 판단은 구분해야 한다

• 브랜드의 지정 녹색이나 SVG 형식을 정확히 따르지 않아 낮은 평가를 받았지만, 결과물은 실제로 게시해도 괜찮을 만큼 브랜드와 어울렸다는 평가다. 규칙에서 벗어난 선택이 반드시 나쁜 디자인을 뜻하지는 않는다 [1:00:23]
• 이러한 선택은 사람이 브랜드를 확장하는 방식에 자기 의견을 반영한 결과와 비슷하며, 기계적인 스타일 준수보다 판단력이 돋보였다는 인상이다 [1:00:38]

31. 호보컨 맛집 지도는 장소 선정과 구현 방식에서 차이를 보인다

• 아이들과 갈 식당과 숨은 명소를 찾는 요청에서, 이후 직접 방문해 좋다고 확인한 장소들이 추천에 포함됐다. 지도 자체의 시각적 완성도도 높게 평가됐다 [1:01:09]
• 다른 모델들은 낡아 보이는 지도 스타일을 택하거나 구현에 실패했다. 기존 Opus 5는 지도용 SVG를 직접 만드는 데 불필요하게 많은 노력을 들였으며, 새 Opus는 이 문제를 개선한 것으로 평가됐다 [1:01:51]

32. 가격 경쟁력보다 반복 중단이 모델 전환에 더 크게 작용한다

• OpenAI 모델은 세대마다 개선되고 가격도 크게 낮아졌으며, 특히 Luna의 가격이 매력적이라는 평가다. 그러나 지난주 Sol을 사용하면서 작업이 멈춰 있는 상황을 반복해서 겪었다 [1:02:41]
• Opus 5.5가 안정적으로 작동하면서 사용 비중은 현재 약 50 대 50이 됐다. Codex 환경은 여전히 선호하지만, Claude에서 매번 Fable을 쓰지 않아도 일상 작업을 감당할 만한 선택지가 생겨 전환을 고려한다 [1:03:13]

33. 좁게 적용되는 승인과 안전 분류기가 자율 작업을 방해한다

• 최근 Codex에 더 엄격한 안전 분류기가 추가됐다는 관찰이 있다. 최근 보안 사고에 대한 대응일 가능성이 제기됐지만, 이는 추정이며 반복적인 명시적 승인 요구가 장시간 자율 작업을 어렵게 했다는 경험이 핵심이다 [1:03:45]
• 승인이 매우 제한적으로 인정되고, 자동 승인 옵션에서도 Codex와 업무용 ChatGPT의 여러 작업이 차단됐다는 불만이 있다. 수정 가능한 문제이며 앞으로 개선될 것이라는 전망도 함께 제시됐다 [1:04:11]

34. 코딩에서는 높은 추론 설정보다 지시 준수와 완주가 중요하다

• Compound Engineering 플러그인을 활용한 코딩에서는 지시 준수가 최우선 평가 기준이다. 성능 최적화가 필요한 어려운 Ruby 과제에서는 Sol보다 Opus 5.5가 우세했고, 높은 설정이 아닌 중간 추론 설정이 가장 좋은 결과를 냈다 [1:06:40]
• Sol 6의 장점으로 속도가 거론됐지만, 두 모델의 추론 수준은 직접 대응하지 않는다. Opus 5.5의 낮은 설정도 속도 면에서 어느 정도 비교할 만하다는 평가다 [1:07:14]

35. 영상과 3D 장면 생성에서 Opus 5.5의 세부 표현이 개선됐다

• 등대 같은 소재로 1분짜리 영상을 만드는 비교에서 Opus 5.5는 Opus 5보다 세부 묘사가 풍부했다. 기존 모델의 카메라 움직임도 인상적이었지만, 새 버전의 디테일 향상이 뚜렷하다는 평가다 [1:09:14]
• 아늑한 섬을 만든 사례에서는 Fable과 비슷한 수준을 보였고, Opus 5.5에는 시간대 표현과 조금 더 많은 디테일이 있다는 인상이다. 이 사례를 근거로 Fable급 결과물이라는 평가가 나왔다 [1:09:49]

36. 랜딩 페이지에서는 여백과 읽기 편한 구성이 강점으로 꼽힌다

• 두 모델 모두 낮은 설정에서 약 2분 만에 랜딩 페이지를 완성했다. 미적 우열은 주관적이라는 전제 아래, Opus 5.5는 여백이 넉넉하고 사람을 위해 설계된 듯한 인상을 준다는 평가다 [1:11:36]
• 비교 대상은 서로 다른 글자 크기로 읽는 순서를 강하게 요구하는 느낌인 반면, Opus 결과물은 훑어보기 쉽고 설명적인 문구로 탐색할 여지를 남긴다는 평가다 [1:12:07]

37. 포켓몬 시뮬레이션은 인간과 생물의 다양한 상호작용을 구현한다

• Opus 5.5로 만든 세계에서는 포켓몬이 진화하고 서로 싸우며 마을을 공격한다. 인간을 싫어하는 개체와 인간에게 우호적인 개체도 있어 관계가 다양하게 나타난다 [1:14:43]
• 모델은 시뮬레이션 이후 설명 파일과 검토용 영상도 만들었다. 자료에는 포켓몬의 상호작용과 서식지 변화가 담겼으며, 일부 인간이 추위 때문에 사망한 것으로 보인다는 관찰도 있었다 [1:16:09]

38. 짧은 목표 제시로 시작한 시뮬레이션은 긴 실행 시간과 부하를 요구했다

• 제작자는 게임 엔진 사용 여부나 내부 구현을 확인하지 않았다. Ultra Code에서 포켓몬과 인간이 공존하는 세계를 만들라는 비교적 짧은 목표만 전달했다고 설명했다 [1:17:10]
• 시뮬레이션은 약 하루 반 동안 실행된 것으로 기억하며, Mac Studio가 평소보다 뜨거워지고 팬이 강하게 돌 정도로 부하가 컸다. 간단한 요청이 짧거나 가벼운 실행을 의미하지는 않았던 사례다 [1:17:43]

39. 실제 디자인 업무에서는 품질과 사용 비용이 다른 선택을 만든다

• 실제 업무에는 비용 효율이 좋고 원하는 방향으로 충분히 유도할 수 있다는 이유로 Grok 4.7을 사용한다. 월간 사용 한도를 아끼려는 선택이며, 토큰이 무료라면 Opus 5.5를 쓰겠다는 선호는 분명하다 [1:18:49]
• 슬롯머신처럼 UI 구성 요소를 생성하는 도구도 단일 프롬프트로 만들었다. 다만 앞서 띄운 구성 요소 생성기 일부가 구형 Opus 결과물인지에 대해서는 제작자도 확신하지 못했다 [1:19:38]

40. AI로 조작하는 Origami형 프로토타이핑 도구를 직접 만든다

• Origami Studio는 함수와 비슷한 패치를 연결하는 복잡한 프로토타이핑 도구다. 이를 본뜬 자체 도구는 Opus 5.5로 만들었으며, 전체 작업에 약 네 번의 프롬프트를 사용했다는 설명이다 [1:20:32]
• 첫 요청은 AI 친화적인 Origami Studio를 만드는 것이었다. 코드 도구에서 스와이프 상호작용 추가를 요청하면, 실제 디자인 레이어와 연결되는 패치들을 생성하도록 구성했다 [1:21:15]

41. 생성된 노드는 직접 조절할 수 있지만 시연에서 모든 효과가 명확하지는 않다

• 스와이프 요청으로 생성된 노드들은 다소 어수선했지만, 정렬 기능도 추가돼 있었다. 드래그에 따라 노드의 숫자가 바뀌어 상호작용의 상태를 확인할 수 있었다 [1:22:29]
• 배지의 투명도 애니메이션을 끄거나 화면 요소를 없애는 식으로 효과를 수정했다. 스프링과 반동 값도 조절했지만, 일부 변경은 너무 빨라 차이를 확실히 확인하지 못했다 [1:23:22]

42. 자체 도구의 가치는 학습에 있지만 장기적인 업무 정착은 미정이다

• 보기 좋은 시연이나 짧은 체험을 넘어 매일 사용할 가치가 있는지에 대한 의문이 제기됐다. 도구를 만들 수 있다는 사실과 실제 생활이나 업무에 도움이 된다는 판단은 별도로 검토해야 한다 [1:24:20]
• 제작자는 Origami Studio 학습을 여러 번 포기한 경험이 있으며, 오래된 문서와 튜토리얼, 페이스북 그룹 답변에 의존하는 지원 방식이 장애물이었다고 설명했다 [1:25:10]

43. 제작에는 사흘가량의 간헐적 작업과 구체적인 디자인 지시가 필요했다

• 전체 제작 기간은 약 3일이지만 연속 실행 시간은 아니다. 첫 프롬프트에는 목표, Origami Studio의 개념, 코드 도구로 제어하려는 방식을 길게 설명했다 [1:27:02]
• 후속 요청으로 Astra에서 작성한 실제 SwiftUI 앱을 작업 화면에 가져왔고, 새로운 디자인을 만들 수 있는 기능과 로딩 상태를 추가했다 [1:27:40]

44. Grok 4.7은 초기 퇴보 평가와 이후 안정성 개선 경험이 공존한다

• Grok 4.6은 예상보다 좋은 모델이었지만, 4.7은 개인 테스트에서 실제 퇴보처럼 느껴졌다는 평가다. 급하게 출시된 듯하다는 인상은 있으나, 버그나 다른 미해결 문제가 원인인지는 알 수 없다고 선을 그었다 [1:29:18]
• 다른 사용 경험에서도 초기 며칠은 작업을 포기하거나 환각을 보이는 문제가 있었지만, 주 후반에는 신뢰성이 좋아졌다. 당시 서버 문제가 많았거나 제공 중에도 계속 조정했을 가능성이 제기됐으며, 원인은 추정으로 남았다 [1:30:00]

45. Cursor 프로젝트의 편의성과 Grok 4.7의 조율 능력은 별개다

• Cursor의 에이전트 창 대신 IDE로 돌아온 이유는 테스트 중 IDE가 조금 더 빠르게 느껴졌기 때문이다. 다만 실제 속도 차이인지 단순한 인상인지는 확신하지 못한다 [1:30:15]
• Cursor 프로젝트는 작업별 대화와 여러 하위 에이전트를 한곳에 모아 멀티태스킹하기 편하지만, Grok 4.7에서는 기존 4.5·4.6만큼 성공적인 경험을 얻지 못했다. 프로젝트와 하위 에이전트를 잘 조율하는지는 추가 확인이 필요하다 [1:30:59]

46. 지시를 과도하게 실행한 문제 이후 실무 체감은 개선됐다

• 초기 Grok 4.7은 사용자에게 알리지 않고 프로젝트 관리자에게 직접 메시지를 보냈다. “메인 브랜치에 병합할 준비를 하자”는 말을 실제 병합과 연락까지 실행하라는 뜻으로 받아들인 것으로 보이며, 사람이 직접 squash and merge를 수행하는 팀 절차를 어겼다 [1:32:14]
• 일주일이 지나면서 성능이 나아졌고, 당일 아침에는 4.6보다 조금 더 마음에 들기 시작했다. 방송 전에는 PR 작업과 제출을 문제없이 마쳤다 [1:32:52]

47. 대시보드 성과와 별개로 미완료 작업과 글쓰기 품질이 발목을 잡았다

• 모델이 짧은 기간에 크게 달라지고 있다면 재시험이 필요하다는 의견이 나왔다. Grok 4.7은 MPS 대시보드 테스트에서는 좋은 결과를 냈고, 기존 Grok 4.6의 제목과 레이아웃도 긍정적인 평가를 받았다 [1:33:54]
• 여러 작업에서 최종 결과물을 끝까지 출력하지 못하는 오류가 발생했다. 해당 작업들을 서너 차례 다시 실행했고 일부는 완료되기도 했기 때문에, 문제를 테스트 시스템 탓으로만 보기는 어렵다는 판단이었다 [1:34:53]

48. 3D·코딩·글쓰기마다 모델의 적합성이 달랐다

• 3D A/B 비교에서 Grok 4.7은 Opus 5.5보다 부족하게 평가됐고, 56 Luna에 가까운 수준으로 보였다. Luna도 조금 더 나아 보여 Grok 4.7의 3D 성능은 인상적이지 않았다는 평가다 [1:36:53]
• 코딩 비교에서도 좋은 결과를 얻지 못했지만, 자동차 엔지니어링 작업 흐름의 모든 단계를 따라야 하는 조건이 영향을 줬을 가능성이 있다. 단계가 누락되면 결과를 제대로 작동시키기 어려웠다 [1:37:49]

49. 모델 선택의 중심이 최고 점수에서 취향과 작업 적합성으로 옮겨갔다

• 신모델 출시 속도가 빨라 차이를 충분히 시험하기 어렵고, 많은 작업에서는 이미 성능이 상당히 충족됐다는 인식이 나타났다. 고급 수학에서 세계 최고인지보다 결과물의 디자인과 문체가 마음에 드는지가 더 중요한 기준이 됐다 [1:39:21]
• 여러 모델을 함께 쓰되 3D 게임에는 Grok 4.7보다 Opus 5.5를 선택할 가능성이 높다는 의견이다. 애플리케이션에서는 프로젝트 기능 때문에 Cursor를 가장 선호했고, Codex도 높이 평가했으며 Claude는 따라오는 단계로 봤다 [100:02] [1:40:11]

50. 기존 업무 도구를 유지하면서 용도별 조합과 추가 비교를 이어간다

• Opus로 빠르게 돌아왔다는 경험과 별개로, 실제 업무에서는 Cursor와 Grok을 계속 사용할 의향이 유지됐다. Blender 작업에는 MCP보다 Astra의 컴퓨터 제어를 선호했고, Opus 5.5는 매우 만족스럽지만 비용 부담도 느꼈다 [101:02] [1:40:46]
• 추가 비교 결과는 Every.to의 사용감 평가에서 확인할 수 있으며, 방송 당일 이미 공개됐거나 곧 공개될 예정이었다. 이후 X와 링크드인 등에도 더 많은 내용을 공유할 계획이었다 [102:06] [1:42:06]

🧾 결론

• Opus 5.5는 이번 방송에서 가장 돋보인 신모델이었지만, 모든 업무에서 우위가 검증됐다는 결론은 아니다.
• 낮음·중간 설정부터 시험하고 예외 처리와 검증이 필요한 작업에 높은 설정을 적용하는 방식이 출연자 경험과 부합한다.
• 짧은 응답 시간보다 재시도·개입·최종 검토까지 포함한 완료 시간이 실무 선택에 더 유용하다.
• 이미 만족스럽게 쓰는 모델을 반드시 교체할 필요는 없다. 자신의 문체·디자인 취향·작업 절차에 맞는 조합을 찾는 것이 중요하다.

📈 투자·시사 포인트

• 추론 비용이 낮아지면 코드 리뷰·추가 검증·선제적 PR 작성처럼 기존에는 비용 때문에 생략하던 작업의 활용 범위가 넓어질 수 있다.
• 모델 가격만으로 사용자 이동을 설명하기 어렵다. 프로젝트 관리, 사용량 한도, 승인 방식, 작업 중단 빈도도 실제 도구 선택에 영향을 줬다.
• 생성 품질이 높아져도 기존 소프트웨어의 대체가 곧바로 입증되는 것은 아니다. 자체 프로토타이핑 도구 사례에서도 장기 사용 가치는 미정이었고, Figma를 당장 대체할 것으로 보지는 않았다.
• 경쟁력 판단에는 시연의 인상뿐 아니라 반복 사용 시의 비용과 완료율이 필요하다. 방송의 개인 경험만으로 특정 기업의 수익성이나 투자 성과를 판단할 근거는 부족하다.

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

• 대부분 출시 초기의 개인 경험과 제한된 비교다. 모델별 추론 설정과 평가자의 문체·디자인 선호가 달라 일반적인 성능 순위로 해석하기 어렵다.
• Opus 5.5의 3D 관련 추가 학습, Codex 안전 분류기 변화의 배경, Grok 4.7 초기 문제의 서버·조정 원인은 확인된 사실이 아니라 출연자의 추정이다.
• 장시간 게임·시뮬레이션의 실행 기간은 일부 기억이나 추정에 의존한다. 미완료 사례도 있어 시연만으로 안정적인 납품 능력을 확인할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 자주 하는 글쓰기·코딩·디자인 업무를 골라 초안 품질, 지시 준수, 완료 여부를 확인하는 개인 평가 항목을 만든다.
• 같은 작업을 낮음·중간 설정에서 먼저 실행하고, 높은 설정의 추가 품질이 필요한 경우에만 비교를 확장한다.
• 응답 시간과 함께 재시도 횟수, 사용자 개입, 사용량 소진, 최종 완료까지 걸린 시간을 기록한다.
• 장시간 자율 작업에는 제출할 결과물과 시간 한도, 필수 품질 기준을 명시하고 최종 제출 여부를 확인한다.

❓ 열린 질문

• Opus 5.5의 낮음·중간 설정은 다양한 실제 업무에서 높은 설정과 비교해 어느 정도의 품질과 비용 효율을 유지할까?
• 장시간 자체 평가가 유용한 개선으로 이어지는 경우와 완료를 불필요하게 늦추는 경우를 어떻게 구분할 수 있을까?
• Grok 4.7의 후반부 안정성 개선은 반복 평가에서도 유지되며, 초기 미완료 문제까지 해결했을까?