🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Sonnet 5는 벤치마크와 가격만 보면 매력적이지만, 실제 사용 테스트에서는 “i tried sonnet 5 and it sucks”라는 제목처럼 Opus 4.8을 대체할 만큼 압도적인 실전 신뢰성을 보여주지 못했다.

📌 핵심 요점

1. Sonnet 5는 입력 100만 토큰당 2달러, 출력 100만 토큰당 10달러로 Opus 4.8보다 저렴하고, 에이전트·코딩 벤치마크도 좋아 보이지만 실제 프로덕션 코드베이스에서의 안정성은 별도 검증이 필요했다.
2. 테스트는 Ship Space의 워크스페이스 이름 변경 버그 수정, HTML 요약 생성, Opus 4.8과 동일 프롬프트의 비폭력 1인칭 게임 생성, 간단한 상식 추론 질문 등으로 구성됐다.
3. Sonnet 5는 워크스페이스 rename 기능 수정에서는 실제 앱 개선에 성공했고, 게임 생성에서도 Opus 결과물보다 더 많은 기능과 상호작용 요소를 넣은 Wayfairer를 만들었다.
4. 그러나 HTML 요약은 강한 스트레스 테스트로 보기 어려웠고, “세차장이 50m 떨어져 있을 때 걸을지 운전할지”라는 질문에서는 차를 씻으려면 차를 가져가야 한다는 기본 조건을 놓치는 약점을 보였다.
5. 최종 평가는 “작은 작업에는 쓸 수 있지만 전체 워크플로를 Opus 4.8 중심에서 Sonnet 5 중심으로 바꿀 만큼 놀랍지는 않다”에 가깝고, 오픈웨이트·저가 API 모델의 부상까지 고려하면 프런티어 모델 구독 비용의 정당성도 다시 따져봐야 한다.

🧩 배경과 문제 정의

• 영상은 Sonnet 5가 벤치마크상 비용 효율과 에이전트 성능에서 좋아 보이지만, 실제 프로덕션 코드베이스에서 안정적으로 버그를 고치고 코드를 변경할 수 있는지는 별도 검증이 필요하다는 문제의식에서 출발한다.
• 기존 모델들도 높은 점수와 긍정적 초기 반응에도 불구하고 실제 작업에서는 코드베이스를 망가뜨리거나 버그 수정을 제대로 수행하지 못한 사례가 있었기 때문에, 단순 벤치마크만으로 운영 환경의 품질을 판단하기 어렵다는 관점이 깔려 있다.
• 핵심 검증 대상은 Sonnet 5가 더 저렴한 대안으로서 Opus 4.8 대비 실전 개발 작업, 병렬 에이전트 운영, 게임 생성 테스트에서 의미 있는 성능을 보여주는지다.
• 실험 환경으로 쓰이는 Ship Space는 여러 터미널, 에이전트, 브라우저, 메모리, 음성, 비전 기능을 하나의 캔버스에서 묶어 실제 빌더 워크플로를 빠르게 만들려는 작업 공간으로 소개된다.
• 검증 필요: Sonnet 5의 벤치마크, 비용 효율, Factory·Zapier 등의 공개 평가, 오픈웨이트 모델과의 비용 대비 가치 비교는 영상 내 언급과 진행자의 해석을 바탕으로 한 것이므로, 실제 도입 여부를 판단하려면 별도 벤치마크와 환경별 테스트가 필요하다.

🕒 시간순 섹션별 상세정리

1. 벤치마크와 실제 프로덕션 성능의 간극

• Sonnet 5는 출시 직후 벤치마크 수치가 좋아 보이지만, 실제 프로덕션 코드베이스에서는 버그 수정 실패나 코드 파괴 같은 리스크가 남아 있다는 문제의식이 제기된다 [01:08]
• 테스트 범위는 코드베이스 리뷰, 앱 리뷰, 실제 변경 수행, 게임 생성, Opus 4.8과의 비교로 설정되며, 단순 점수보다 실제 운영 사용성이 더 중요한 기준으로 잡힌다 [01:23]

2. Sonnet 5의 공개 평가와 첫 실전 과제 설정

• Factory와 Zapier는 Sonnet 5를 멀티스텝 소프트웨어 엔지니어링 작업의 실행 레이어로 긍정적으로 평가하지만, 출시 1시간 시점의 초기 반응이므로 과장 가능성도 남아 있다고 본다 [02:08]
• Sonnet 5는 의도적으로 사이버 보안 작업에 특화 학습되지 않았고, 소프트웨어 익스플로잇 개발 같은 위험한 사이버 평가에서는 Opus 4.8이나 Mythos 5보다 낮은 성능을 보인다고 드러난다 [02:23]

3. Ship Space의 목적과 병렬 에이전트 작업 환경

• Ship Space는 빌더가 워크스페이스를 정리하고, 노트를 남기고, 지속 메모리를 가진 에이전트를 활용하며, 음성 제어로 개발 속도를 높이기 위한 ADE 성격의 작업 환경으로 묶인다 [03:24]
• GPT Realtime과 음성 기능, Nvidia Parakeet 기반 로컬 음성 처리까지 함께 쓰이면서 클라우드 기반과 로컬 기반 워크플로를 모두 지원하는 구조가 드러난다 [03:53]

4. Sonnet 5와 Opus 4.8의 동일 프롬프트 게임 생성 비교

• Sonnet 5는 extra high effort로 설정되고, Opus 4.8과 함께 단순 버그 수정뿐 아니라 게임 생성 능력 비교 대상에 오른다 [05:12]
• 두 개의 추가 Cloud 에이전트가 열리고, 한쪽은 Opus 4.8 max effort, 다른 쪽은 Sonnet 5 max effort로 맞춰져 동일 프롬프트 조건이 만들어진다 [05:38]

5. OKF 기반 메모리 구조와 Ship Space의 상호운용성

• Ship Space는 MCP, 메모리, 음성, 비전, Google 프레임워크를 포함하며, 빌더는 제품 내부 구조를 이해해야 실제 워크플로 개선과 문제 해결을 더 잘할 수 있다고 드러난다 [07:03]
• Google의 OKF는 마크다운 파일과 YAML front matter를 이용해 에이전트 간 정보 전달을 더 구조화하고, 큐레이션 가능한 컨텍스트를 제공하는 최소한의 지식 번들 규격으로 드러난다 [07:19]

6. Canvas·Workbench·MCP 메모리가 결합된 실행 구조

• Ship Space의 캔버스는 터미널, 에이전트, 브라우저를 드래그·리사이즈 가능한 노드로 배치하고, Cloud Code·Codex·Hermes 같은 도구와 GPT Realtime 또는 로컬 Nvidia Parakeet을 연결할 수 있는 공간으로 드러난다 [09:29]
• Workbench는 backlog 카드마다 워커 에이전트를 하나씩 dispatch하고, 작업이 끝난 카드를 정리하면서 프로젝트별 작업 흐름을 지속적으로 관리하는 구조로 묶인다 [09:53]

7. Ship Space의 에이전트 인계와 워크스페이스 인식 구조

• handoff note를 남기면 다음 에이전트가 빈 상태에서 시작하지 않고 이전 작업 맥락을 이어받을 수 있어, 장기 작업에서 발생하는 컨텍스트 손실을 줄일 수 있다고 드러난다 [12:01]
• 음성 에이전트는 GPT real time을 쓰거나 로컬 Parakeet으로 대체할 수 있고, 전체 워크스페이스를 제어하는 입력 계층처럼 작동한다 [12:07]

8. HTML 요약, 버그 수정, 게임 생성 작업의 병렬 비교

• Sonnet 5가 만든 HTML 파일은 Ship Space의 맥락과 요약을 빠르게 담았지만, HTML 생성 자체는 Gemma 4 같은 모델도 할 수 있어 강한 스트레스 테스트로 보기 어렵다고 평가된다 [13:02]
• 한 에이전트는 워크스페이스 드롭다운 이름 관리 버그를 extra high effort로 처리 중이며, 단순한 rename 관리 기능도 실제 워크플로 개선 대상으로 남아 있다 [13:29]

9. 테마 커스터마이징과 Hermes·루프 통합 방향

• Ship Space는 space dusk, prairie 같은 테마를 바꿀 수 있고, 개발 환경을 빈 터미널이 아니라 집중과 아이디어를 돕는 시각적 워크스페이스로 만들려는 방향을 갖는다 [15:30]
• 테마는 기본 제공 옵션뿐 아니라 사용자가 직접 만들 수 있으며, 작업자의 기분과 몰입 상태에 맞춘 환경 구성이 기능적 요소로 취급된다 [16:04]

10. Opus와 Sonnet의 게임 결과물 비교

• Opus가 만든 Lumen Run은 브라우저에서 실행되고, 떠 있는 섬을 달리고 미끄러지며 lumens와 beacons를 모으는 비전투형 게임으로 구성된다 [17:00]
• Opus 결과물은 약 20분 작업치고 기본적인 3D 블록, 수집 목표, 조명 비콘을 갖췄지만, 그래픽과 상호작용이 단순해 one-shot 게임의 한계도 드러난다 [17:20]

11. 상식 추론 실패와 워크스페이스 rename 수정 성공

• 새 Claude Code 터미널에서 “세차장이 50m 떨어져 있을 때 걸을지 운전할지”를 묻자 Sonnet 5 extra high effort는 걸으라고 답해, 차를 씻으려면 차를 가져가야 한다는 기본 조건을 놓친다 [20:40]
• Aspen은 차를 씻으려면 운전해야 한다는 점을 바로 잡고, 간단한 car wash test에서 Sonnet 5가 아직 실패한다는 결론이 드러난다 [21:04]

12. 오픈웨이트 모델과 프런티어 모델 비용 대비 가치

• GLM 5.2 같은 오픈웨이트 모델이 GPT 5.5, Opus, Sonnet 같은 프런티어 모델과 비교되면서, 월 200달러 Anthropic과 100달러 OpenAI 구독이 실제로 필요한지에 대한 의문이 제기된다 [21:54]
• GLM 5.2를 의미 있게 로컬 실행하려면 quantized 버전 기준 최소 4대 DGX Spark 수준의 무거운 하드웨어가 필요하지만, DeepSeek v4 flash는 더 낮은 하드웨어에서도 Sonnet 5와 비슷한 결과를 노릴 수 있다고 나온다 [22:20]

13. Sonnet 5 평가의 결론은 실전 코딩 효용성 부족에 가깝다

• Opus 쪽에서는 게임 결과물이 조금 더 흥미롭게 나왔지만, 진행자가 기대한 핵심 가치는 코딩 작업과 워크플로 설정, Ship Space 앱 개발을 직접 돕는 능력에 있었다 [24:04]
• 전체 반응은 크게 놀랄 수준까지 가지 않으며, Sonnet 5에 압도됐는지 또는 Fable 5가 더 그리운지에 대한 판단은 시청자 의견으로 열려 있다 [24:16]

14. Shipping School은 AI 빌더의 학습과 연결을 보완하는 공간이다

• Shipping School 안에 무료 커뮤니티 구간이 열렸고, 약 125명의 빌더가 AI로 무언가를 만들며 함께 활동할 수 있는 공간으로 묶인다 [24:23]
• 유료 업그레이드는 전체 강의 자료와 매주 4회의 라이브 콜 접근권을 포함하며, 현재 초점은 로컬 LLM, AI 추론, 컨텍스트 엔지니어링, 빌더가 배워야 할 프레임워크에 맞춰져 있다 [24:35]

🧾 결론

• Sonnet 5는 실패작이라고 단정하기보다, 벤치마크 기대치에 비해 실전 효용이 애매한 모델로 정리할 수 있다.
• 실제 앱 기능 수정에서는 쓸 만한 결과를 냈지만, 상식 추론 실패와 제한적인 스트레스 테스트 결과 때문에 프로덕션 코드베이스의 핵심 작업을 맡기기에는 신중함이 필요하다.
• 게임 생성 비교에서는 Sonnet 5가 Opus 4.8보다 풍부한 요소를 만든 장면도 있었지만, 이것만으로 코딩 모델 전반의 우위를 입증하기는 어렵다.
• 발표 직후의 긍정적 평가와 벤치마크 수치는 참고 지표일 뿐이며, 실제 운영 환경에서는 버그 수정 성공률, 코드 파괴 위험, 반복 작업 비용, 검수 부담을 함께 봐야 한다.
• 검증 필요 내용: GLM 5.2, DeepSeek v4 flash 같은 대안 모델이 Sonnet 5와 비슷하거나 더 나은 비용 대비 결과를 낼 수 있다는 평가는 영상 내 논의 기준이며, 실제 성능은 사용 환경과 과제별 추가 테스트가 필요하다.

📈 투자·시사 포인트

• AI 모델 선택에서는 “최신 모델인가”보다 “실제 워크플로에서 비용 대비 오류를 얼마나 줄이는가”가 더 중요한 판단 기준이 된다.
• 월 200달러 수준의 Anthropic 구독이나 월 100달러 수준의 OpenAI 구독은, Sonnet 5 같은 신규 모델이 큰 도약을 보여주지 못할 경우 더 엄격한 ROI 검토 대상이 된다.
• 프런티어 모델의 업그레이드가 점점 작은 성능 개선과 벤치마크 향상 중심으로 보인다면, 기업과 개인 빌더는 모델 락인보다 Opus, Sonnet, GPT 계열, 오픈웨이트·저가 API 모델을 과제별로 나눠 쓰는 전략이 유리할 수 있다.
• Ship Space처럼 여러 에이전트, 터미널, 브라우저, 메모리, 음성 입력을 한 작업 공간에 묶는 환경은 모델 자체 성능만큼이나 생산성의 핵심 변수가 될 수 있다.
• 검증 필요 내용: 오픈웨이트 모델을 로컬로 돌리는 비용은 하드웨어 요구사항에 크게 좌우되므로, 단순히 모델 사용료만 비교하지 말고 장비 비용, 운영 난이도, 속도, 유지보수 부담까지 함께 계산해야 한다.

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

• 영상에서 언급된 Sonnet 5의 가격, 입력 100만 토큰당 2달러·출력 100만 토큰당 10달러, 그리고 Swebench Pro 63.2점 수치는 공식 가격표와 벤치마크 원문으로 별도 확인이 필요하다.
• Factory와 Zapier의 긍정적 평가는 영상 내에서는 출시 직후 반응으로 다뤄지므로, 장기간 실사용 결과나 독립적인 재현 평가로 보기에는 아직 불확실하다.
• Sonnet 5가 Opus 4.8보다 게임 생성 결과에서 더 나아 보였다는 평가는 단일 프롬프트·단일 실행 사례에 기반하므로, 일반적인 모델 성능 우위로 단정하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Sonnet 5, Opus 4.8, GPT 5.5를 동일한 실제 코드베이스 버그 수정 과제에 투입하고 테스트 통과율, 수정 범위, 회귀 발생 여부를 비교한다.
• 모델별 입력·출력 토큰, 세션 사용량, 작업 완료 시간, 재시도 횟수를 기록해 비용 대비 실전 효율을 정량화한다.
• 영상에서 언급된 가격, Swebench Pro 점수, 사이버 평가 관련 내용, 오픈웨이트 모델 비교 수치를 공식 문서나 독립 벤치마크로 검증한다.
• Sonnet 5는 당분간 HTML 요약, 작은 UI 수정, 제한된 버그 수정처럼 범위가 좁은 작업에 우선 사용하고, 큰 코드 변경은 Opus 또는 다른 모델의 리뷰를 붙인다.

❓ 열린 질문

• Sonnet 5는 작은 단발성 작업이 아니라 여러 파일을 건드리는 장기 에이전트 작업에서도 안정적으로 코드베이스를 유지할 수 있는가?
• Opus 4.8 대비 Sonnet 5가 실제로 우위에 있는 작업 유형은 게임 프로토타입, 간단한 UI 수정, 요약 HTML 생성 중 어디까지인가?
• Sonnet 5의 낮은 비용이 재시도, 검수, 회귀 수정 비용까지 포함해도 Opus 4.8보다 유리한가?