OpenAI가 경계해야 할 앤트로픽의 새 전략

URL: https://www.youtube.com/watch?v=8WbW_n95wc4 날짜: 2026-09-29 채널: t3dotgg

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==Claude Sonnet 5.5는 직접 선택해 쓰는 최상위 모델이라기보다, Opus나 Fable 같은 상위 모델이 복잡한 일을 분해할 때 호출하는 값싼 전문 조사·분석 도구로서 가장 큰 가치를 가진다.==

• Anthropic은 Sonnet 5.5에서 Terminal Bench 4 점수를 10.3%에서 70.6%로 끌어올리고, 출력의 가독성과 협업성을 개선했다.
• 표면적인 API 가격은 저렴하지만 에이전트 코딩에서 큰 비중을 차지하는 캐시 읽기와 토큰 사용량 때문에 실제 작업 비용은 Opus와 비슷하거나 더 비쌀 수 있다.
• 디자인 생성과 일반적인 일대일 코딩에서는 Opus·Fable에 밀리지만, 대규모 코드베이스를 읽고 구조를 분석해 상위 에이전트에 조사 결과를 넘기는 작업에서는 비용과 속도 모두 뛰어나다.
• OpenAI는 가장 똑똑한 모델, 가장 효율적인 모델, 가장 싼 모델, 다른 모델을 가장 잘 호출하는 모델 중 어느 것도 확실히 갖지 못한 상태로 평가된다.

Sonnet 5.5의 진짜 포지션은 사람의 프롬프트를 직접 받아 최종 결과를 만드는 주력 모델이 아니다. Opus나 Fable이 거대한 코드베이스의 구조를 파악하고, 특정 동작을 조사하고, 가설을 검증하고, 작업 범위를 정할 때 뒤에서 빠르게 호출하는 서브에이전트다. 이 역할을 전제로 보면 낮은 토큰 효율과 평범한 디자인 성능에도 불구하고 현실적인 가치가 분명해진다.

1. Anthropic의 상승세와 Sonnet 5.5의 등장

Anthropic의 최근 모델들은 실제 사용 흐름을 바꿀 정도로 빠르게 좋아졌고, Sonnet 5.5는 그 흐름을 OpenAI와의 가격·기능 경쟁으로 확장한다.

1.1. Opus와 Fable이 만든 기대치

1. Anthropic 모델이 실제 워크플로를 점령하다

   1. Fable 5.1: 가장 좋아하는 코드 모델로 평가될 만큼 인상적이었고, 출시된 코드 모델 중 최고로 느껴질 정도였다.
   2. Opus 5.5: 거의 모든 사람의 워크플로를 장악했고, 실제 사용자의 작업에서도 Fable을 일주일 넘게 선택하지 않게 만들었다.
   3. Sonnet 5.5의 반전: 처음에는 별로 관심을 두지 않고 건너뛸 모델로 생각했지만, 실제 사용 결과는 예상보다 훨씬 뛰어났다.

2. 벤치마크만으로는 설명되지 않는 호감

   1. Artificial Analysis Intelligence Index에서 Sonnet 5.5는 모든 단계에서 Opus 5.5보다 비싸고 덜 똑똑한 모델로 나타난다.
   2. 그럼에도 현대적인 가격대에서 의미 있게 쓸 수 있는 Anthropic의 저가형 모델이라는 점이 중요하다.
   3. 과거 같은 가격대에 있던 OpenAI 모델과 비교하면, Sonnet 5.5는 GPT-6 Soul을 정면으로 겨냥한 듯한 제품 포지션을 갖는다.

1.2. GPT-6 Soul과 OpenAI의 불안한 위치

1. GPT-6 Soul이 주목을 받지 못한 이유

   1. Soul은 별도 리뷰 영상을 만들 만큼 인상적이지 않았고, 실제로 다룰 이유가 거의 없을 정도로 존재감이 약하게 평가된다.
   2. OpenAI Dev Day를 앞두고 반격이 나올 가능성은 높지만, 현재 시점의 200달러 Codex 플랜은 200달러짜리 Claude 구독보다 사용량과 실세계 코드 작업량이 훨씬 적다.

2. 경쟁의 기준이 바뀌다

   1. 단순한 최고 점수 경쟁이 아니라 가격, 토큰 효율, 속도, 모델 간 호출 능력, 실제 에이전트 작업에서의 가치가 함께 평가된다.
   2. Sonnet 5.5는 모든 항목에서 1등인 모델은 아니지만, 상위 모델이 사용할 때 경쟁 구도를 바꾸는 부품이 된다.

2. 협찬 구간: CodeRabbit Change Stack

AI가 코드베이스에 기여하는 일은 쉬워졌지만, 무엇이 어떻게 바뀌었는지 사람이 추적하는 일은 오히려 어려워졌다. 에이전트가 만든 변경을 AI 리뷰어가 승인하고, 사람이 나중에 그 변경을 자신이 직접 만든 것으로 착각하는 문제가 생긴다.

2.1. PR을 읽는 방식의 개선

1. 파일 목록을 변화의 이야기로 바꾸기

   1. CodeRabbit의 Change Stack은 로그인하지 않은 상태에서도 버튼 하나로 PR의 변화를 확인하게 해 준다.
   2. 알파벳순으로 쌓인 파일 목록 대신 무엇이 왜 바뀌었는지 설명을 제공한다.
   3. 아무도 클릭하지 않는 뒤엉킨 커밋 목록을, PR이 바꾸는 여러 항목의 스택과 각 항목의 설명으로 바꾼다.

2. 변경 위험과 활동을 빠르게 파악하기

   1. 패키지 설치 감지와 T3 Code의 로컬 저장 방식 변경처럼 변경 영역별 맥락을 요약한다.
   2. 여러 사용자에게 문제를 일으킨 업데이트 로직이 어디서 수정됐는지 보여 준다.
   3. 보안 블라스트 레디우스 다이어그램으로 특정 PR의 위험한 변경을 시각적으로 파악하게 한다.
   4. Activity View는 GitHub의 복잡한 스레드를 끝까지 스크롤하지 않고 PR의 변화를 빠르게 따라잡게 한다.

2.2. 협찬 구간의 핵심 메시지

1. AI가 만든 코드의 양이 늘수록 코드베이스에 대한 사람의 이해가 더 중요해진다.
2. CodeRabbit은 리뷰 품질 자체뿐 아니라 변경의 이유, 위험 범위, 시간순 활동을 한눈에 보여 주는 도구로 소개된다.
3. 안내 링크는 soy.link/coderabbit으로 제시된다.

3. Anthropic 공식 발표와 명목상 개선점

Anthropic은 Sonnet 5.5를 Sonnet 5 이후 5.5 계열의 두 번째 모델이자 명확한 업그레이드로 소개하며, 대부분의 작업에서 최대 30% 빠르고 최대 30% 저렴하다고 설명한다.

3.1. 모델 계층과 용도

1. Opus와 Sonnet의 역할 분담

   1. Opus 5.5는 신중한 판단이 필요한 복잡한 작업을 담당한다.
   2. Sonnet 5.5는 범위가 잘 정의된 일상 작업, 버그 수정, 문서·슬라이드·스프레드시트 제작에 강하다.
   3. 실제로는 공식 설명보다 더 넓은 능력을 보이며, 뒤에서 소개할 fish slop 데모가 그 사례가 된다.

2. 향후 Haiku 5.5

   1. Haiku 5.5는 고볼륨·비용 민감 애플리케이션을 위한 모델로 소개된다.
   2. 몇 주 안에 Claude 5.5 제품군에 합류할 예정이라고 발표됐다.
   3. Sonnet이 예상보다 빨리 출시된 점 자체도 기대보다 빠른 개발 속도의 신호로 받아들여진다.

3. 디자인 능력에 대한 주장

   1. Anthropic은 Sonnet 5.5가 디자인을 날카롭게 이해한다고 강조한다.
   2. 실제 디자인 결과는 기대에 미치지 못했으며, Fable과 Opus에 비해 프런트엔드 디자인 선택이 거칠다는 평가가 이어진다.

3.2. 벤치마크의 급격한 상승

1. Terminal Bench 4

   1. Sonnet 5.5는 70.6%를 기록해 이전 Sonnet 5의 10.3%를 크게 앞섰다.
   2. 점수만 보면 약 7배 상승이며, Sonnet 계열이 실제 코드 작업에 쓸 만해졌다는 강한 신호다.
   3. 다만 10.3%에서 70.6%로의 변화가 너무 커서 Terminal Bench 자체의 측정 신뢰도에 의문이 생긴다.

2. GDPVal·장기 작업·이미지 이해

   1. GDPVal에서는 Opus 5.5보다 조금 낮지만, 해당 벤치마크의 의미를 크게 두지는 않는다.
   2. 장기 작업과 이미지 이해에서 강점을 보인다.
   3. 스크린샷만 보고 Pokémon Red를 플레이하는 작업에서 Sonnet 계열 최초로 통과했다.
   4. 많은 모델이 이제 가능해진 일이라도, 저가형 모델이 장시간 게임 플레이 같은 작업을 수행한다는 점은 의미가 있다.

3.3. 내부 강화학습과 증류의 변화

1. 모델의 ‘이해하는 느낌’

   1. 과거에는 가장 크고 좋은 모델이 아닌 Anthropic 모델이 주어진 작업을 이해하기보다 정해진 절차를 기계적으로 수행하는 느낌이 강했다.
   2. Sonnet 5.5는 조금 덜 똑똑하지만 훨씬 빠른 Fable처럼 느껴지며, 작업의 의도와 맥락을 읽는 감각이 개선됐다.

2. 증류를 직접 잘하기 시작한 Anthropic

   1. 다른 회사들이 Anthropic 모델을 증류해 사용하던 상황을 Anthropic이 지켜보다가 직접 증류하기로 결심한 것처럼 보인다.
   2. 강화학습 내부에서 최근 큰 돌파가 있었고, 그 결과 상위 모델의 성격을 빠른 모델에 옮기는 데 성공했다는 해석이 가능하다.

4. 협업성, 가격, 캐시 비용의 함정

Sonnet 5.5의 협업성은 좋아졌지만, 공식적인 “최대 30% 저렴”이라는 표현은 에이전트 코딩의 실제 비용 구조를 숨긴다.

4.1. 사람과 협업하는 출력 방식

1. Claude 특유의 나쁜 습관 제거

   1. 여러 모델이 싫어하던 ‘Claudeism’과 장황하고 어색한 Claude식 출력 습관을 줄였다.
   2. 이전 세대보다 훨씬 명료하게 쓰며, 결과를 사람에게 전달하는 협업 파트너로서 좋아졌다.
   3. 더 빠른 응답 속도도 협업감을 높이지만, 속도 향상이 공식 수치만큼 크게 느껴지는지는 의문이다.

2. 속도와 출력 품질의 교환

   1. 빠른 모델이라는 인상은 분명하지만, 토큰을 너무 많이 생성해 전체 작업 시간은 오히려 길어질 수 있다.
   2. 협업용 글쓰기와 범위가 잘 정의된 작업은 좋아졌지만, 모델을 직접 주력으로 선택해야 한다는 뜻은 아니다.

4.2. API 가격표

1. Sonnet 5.5의 표면 가격

   1. 입력 토큰은 100만 토큰당 2달러다.
   2. 출력 토큰은 100만 토큰당 10달러다.
   3. 캐시 읽기는 100만 토큰당 0.20달러다.
   4. Anthropic은 같은 가격표를 유지하면서도 작업당 필요한 토큰이 줄어 최대 30% 절감된다고 주장한다.

2. 상위 모델과의 비교

   1. Opus 5.5는 입력 4달러, 출력 20달러로 Sonnet의 두 배다.
   2. Fable 5.1은 입력 10달러, 출력 50달러로 Opus보다 다시 두 배 비싸다.
   3. 캐시 읽기는 Sonnet 0.20달러, Opus 약 0.40달러, Fable 0.25달러 수준으로 일반 입력·출력 가격만큼 비례해 내려가지 않는다.
   4. 캐시 쓰기 역시 Sonnet 약 2.50달러, Opus 5달러로 설명되며, 캐시 읽기보다 비싸지만 상위 모델과의 가격 차이가 작다.

4.3. 에이전트 작업에서 캐시 읽기가 만드는 역전

1. 캐시 읽기 비중

   1. 일반적인 에이전트 코딩에서는 새 입력 토큰보다 기존 컨텍스트를 캐시에서 읽는 토큰이 훨씬 많다.
   2. 따라서 입력 토큰이 2달러라는 사실만으로 실제 비용이 낮다고 결론 내릴 수 없다.
   3. Fable 5.1은 캐시 읽기 비용을 90% 낮춰 캐시 읽기가 전체 비용에서 5% 미만으로 남는다.
   4. Opus 5.5는 캐시 읽기 비중이 약 20%에 가깝고, Sonnet 5.5는 캐시 읽기 단가가 상대적으로 높아 50% 이상을 차지할 수 있다.

2. 실제 비용의 결론

   1. 캐시 읽기를 0.15달러, 가능하다면 0.10달러까지 낮췄다면 Sonnet 5.5는 훨씬 강력한 가격 경쟁력을 가졌을 것이다.
   2. 실제 코드 작업을 Opus와 Sonnet으로 동일하게 비교하면 Sonnet이 지속적으로 Opus와 비슷하거나 더 비싼 경우가 나온다.
   3. Artificial Analysis Intelligence Index의 실세계 작업 비용에서도 Sonnet 5.5는 Fable 5.1과 거의 같은 수준이다.
   4. “최대 30% 저렴”은 작업당 토큰 수가 정말 줄어드는 경우에만 성립하며, 에이전트의 캐시 구조까지 포함한 총비용을 보장하지 않는다.

5. 추론 예산과 Max 모드를 피해야 하는 이유

추론 레벨은 모델이 반드시 그만큼 생각한다는 뜻이 아니라, 사용할 수 있는 추론 토큰의 예산 상한이다. Max 모드만은 이 원칙을 사실상 하한으로 바꾸어 비용과 오류를 폭발시킨다.

5.1. low·medium·high·xhigh의 의미

1. 예산과 실제 사용량

   1. low는 적은 추론 토큰으로 처리하라는 뜻이고, medium·high·xhigh는 더 많이 사용할 수 있는 상한을 열어 준다.
   2. 단순한 작업에서는 low와 xhigh 사이의 토큰 사용량 차이가 5~8%에 불과한 벤치마크도 있었다.
   3. 복잡한 작업에서는 높은 상한이 도움이 될 수 있지만, 모든 작업에서 큰 예산을 소비하지는 않는다.

2. Max의 구조적 문제

   1. Max는 추론 상한을 조금 높이는 모드가 아니라, 모델이 일정량의 추론을 끝내기 전에는 완료하지 못하게 만드는 하한에 가깝다.
   2. low에서 xhigh까지는 토큰 사용량이 약 5% 늘었지만, xhigh에서 max로 올리자 1,500% 증가한 사례가 있었다.
   3. 쉬운 작업에도 계속 생각하도록 만들면 모델이 자기 답을 의심하고 과잉 추론해 오답을 만들 수 있다.

5.2. 벤치마크 비용과 실용적인 설정

1. 같은 벤치마크의 비용 차이

   1. Sonnet 5.5 Max는 7.60달러가 들었고, 비교된 Astra Max는 3.26달러였다.
   2. Sonnet을 xhigh로 낮추면 Astra에 가까운 비용이 되고, high는 약 1.18달러, medium은 약 0.59달러까지 내려간다.
   3. xhigh에서는 Astra와 비슷한 지능 점수를 내지만, 원래 Sonnet 5.5가 Astra보다 약 3점 높았던 이점이 사라진다.
   4. 일상 코드 작업에서는 Astra의 간헐적인 황당한 오류가 적다는 이유로 Sonnet을 선호할 수 있지만, 그 가격이면 Opus를 선택하는 편이 더 단순하다.

2. 권장 추론 범위

   1. Max는 존재하지 않는 옵션처럼 취급하는 것이 좋다.
   2. Low도 Anthropic 모델의 현재 특성상 피해야 한다.
   3. 과거의 무추론 즉시 응답 모드는 사라졌고, 충분한 추론 예산을 주지 않으면 성능이 더 악화된다.
   4. Medium은 대체로 쓸 만하지만 Opus가 Sonnet보다 medium 예산에서 더 강하다는 점을 기억해야 한다.

6. 벤치마크·토큰 효율·속도

공식 차트는 Sonnet 5.5의 강점을 보여 주지만, 비용 대비 점수만 강조하고 토큰 수와 전체 완료 시간을 가리면 해석이 달라진다.

6.1. Frontier Code·컴퓨터 사용·Cursor Bench

1. Frontier Code와 컴퓨터 사용

   1. Frontier Code에서도 Max 점수는 급락하고 xhigh·high가 상대적으로 괜찮으며, medium·low는 크게 떨어진다.
   2. Frontier Code의 일부 항목에서는 xhigh가 Max보다 높은 점수를 냈다.
   3. Computer Use는 이전보다 크게 좋아져 Opus 5.5와 거의 비슷한 수준이다.
   4. OSWorld 2.1에서 GPT-6 Soul과 Astra의 수치가 모두 공개되지 않아, 실제 컴퓨터 사용에서는 여전히 Astra를 주력으로 쓰게 된다.

2. 공식 차트가 숨기는 것

   1. Anthropic이 보고서 첫 차트로 Terminal Bench를 내세운 것은 Opus 5.5가 Max에서 오히려 하락하고 Sonnet 5.5 Max가 Opus보다 비싸면서 앞서는 이상한 그림을 만든다.
   2. 유일하게 Opus보다 비용 대비 성능이 좋아 보이는 영역이 Max인데, 바로 그 모드를 쓰지 말아야 한다는 점이 역설적이다.

3. Cursor Bench의 토큰 사용량

   1. 비용 대비 점수만 보면 Sonnet 5.5가 좋아 보이지만, 토큰 수 기준으로 보면 작업당 271,920토큰을 사용한다.
   2. Opus 5.5는 218,000토큰, Gemini 3.8 Flash는 162,000토큰으로 Sonnet보다 적게 쓴다.
   3. Sonnet은 Gemini 3.8 Flash보다 거의 두 배, GPT-6 Soul과 Astra보다 5~6배 많은 토큰을 쓴다.

6.2. TPS와 Fish Slop 완료 시간

1. 토큰 생성 속도

   1. OpenRouter는 Anthropic 경유 Sonnet 5.5를 초당 약 94토큰, Opus 5.5를 약 70토큰으로 보고한다.
   2. 공식 구독 환경의 실제 측정에서는 Sonnet이 평균 150TPS, Opus가 100TPS 정도였다.
   3. Sonnet은 분명 빠르지만, 토큰을 너무 많이 생성해 전체 작업에서 속도 우위를 잃을 수 있다.

2. 실제 완료 시간

   1. Fish Slop 작업에서 Sonnet 5.5는 43분, Opus 5.5는 36분이 걸렸다.
   2. 실제 토큰 생성에 소비한 시간만 보면 Sonnet은 39분, Opus는 27분으로 격차가 더 커졌다.
   3. ‘초당 토큰 수’만 빠른 것이 아니라, 필요한 토큰 수까지 함께 보아야 체감 속도를 판단할 수 있다.

7. Witch AI 디자인 실험

Witch AI는 Dra가 만든 디자인 쇼케이스로, 새 모델이 프런트엔드와 제품 디자인을 얼마나 잘 다루는지 비교하는 데 사용된다. Reference는 Fable과 Opus의 실행 결과도 공개했다.

7.1. Sonnet 5.5의 결과

1. 첫 번째 세대 결과

   1. 페이지를 작은 사이드 요소가 있는 가짜 앱처럼 만들어 실제 제품의 사용감에 가깝게 표현했다.
   2. 독특하고 의견이 뚜렷한 스타일은 장점이지만, 다른 모델에서도 볼 수 있는 방향이고 전반적으로 다소 과하게 해석했다.

2. 구체적인 품질 문제

   1. 일부 화면은 거칠고 스크롤 상태가 오늘에서 지난달로 갔다가 다시 오늘로 돌아오는 문제가 있었다.
   2. 배경의 가는 선이 가독성을 해쳤다.
   3. 카드 디자인은 매력적이지 않았고, 강조 효과가 과하며, 애니메이션도 좋지 않았다.
   4. 지질 단면도 같은 시각적 계층은 무엇을 표현하려는지 불분명했다.

7.2. Fable·Opus와의 비교

1. 모델별 디자인 성격

   1. Fable 5.1은 마케팅 사이트에 어울리는 보기 좋은 프런트엔드 디자인에서 여전히 전체적으로 가장 뛰어나다.
   2. Opus 5.5는 좋은 디자인 방향으로 유도하기 쉽고, 디자인 지시를 따르는 능력이 좋다.
   3. Sonnet 5.5는 Fable보다 확실히 낮고 Opus보다도 약하지만, OpenAI와 특히 xAI의 결과보다는 훨씬 앞선다.

2. 선택 기준

   1. 일대일로 동일한 프런트엔드 작업을 하면 Opus가 Sonnet과 비슷한 비용으로 더 좋은 결과를 내는 경우가 많다.
   2. 따라서 프런트엔드 구축을 위해 Sonnet을 직접 선택할 이유는 약하다.
   3. 디자인이 Sonnet 5.5의 대표 강점이라는 Anthropic의 표현은 실제 데모와 맞지 않는다.

8. 직접 선택하는 모델이 아니라 상위 모델의 도구

Sonnet 5.5의 가치가 드러나는 지점은 최종 산출물을 혼자 만드는 일이 아니라, 상위 모델이 복잡한 작업을 분해할 때 조사자로 호출하는 일이다.

8.1. T3 Code Orchestrator v2 대규모 코드베이스 벤치

1. 벤치마크 설계

   1. 수십만 줄 규모의 T3 Code orchestrator v2를 대상으로, 거대한 PR에 들어갈 변경을 여러 단위로 쪼개고 더 빨리 main에 병합하는 전략을 제안하게 했다.
   2. 전통적인 코드 작성 능력이 아니라, 대규모 저장소를 읽고 아키텍처 결정을 내리고 다른 사람에게 설명하는 분석 능력을 측정한다.
   3. 초기에는 Astra가 압도적으로 좋은 분해안을 냈고, Fable은 약했으며, Grok이 Fable을 앞섰다.
   4. Opus·Sonnet·Soul도 초기 버전에서는 좋은 성과를 내지 못했다.

2. 평가 방식 개선 후의 결과

   1. 평가 방식과 판단 패널을 개편하자 Fable 점수가 크게 올랐지만, 여전히 Opus 아래였고 Astra와는 큰 차이가 났다.
   2. Astra는 세부사항을 끝까지 파고드는 성향 덕분에 가장 좋은 계획을 만들었다.
   3. Sonnet 5.5는 Opus의 절반 정도 비용으로 작업했고, 자동 평가 패널 기준 Opus보다 약간 더 좋은 결과를 냈다.

8.2. 비용·시간 대비 가장 좋은 분석 도구

1. 분석 작업에서의 강점

   1. 이 작업은 일반적인 코딩이 아니라, 수많은 파일과 맥락을 훑어 구조적 결정을 내리는 심층 조사다.
   2. Sonnet은 이 벤치에서 점수당 비용이 압도적으로 낮았다.
   3. Sonnet은 약 5분 만에 완료했고, Opus는 거의 두 배, Astra는 거의 세 배의 시간이 걸렸다.
   4. Soul은 더 빨랐지만 점수가 절반 수준이었다.

2. 에이전트 오케스트레이션의 적용

   1. Opus나 Fable이 큰 작업을 받으면 시작 전에 Sonnet을 호출해 코드베이스를 조사하게 할 수 있다.
   2. Sonnet은 특정 동작이나 특징을 찾고, API에서 발견한 가설을 확인하고, 변경 범위를 정하는 역할을 맡을 수 있다.
   3. 상위 모델은 Sonnet의 결과를 이용해 전체 계획을 더 빨리 세우고, 직접 모든 파일을 읽는 시간을 줄인다.
   4. Sonnet의 핵심 제품 가치는 “사람이 직접 프롬프트를 보내는 모델”이 아니라 “상위 에이전트가 호출하는 분석 서브에이전트”다.

9. 실제 코드베이스에서 드러난 맥락 이해

TypeScript 컴파일러를 Rust로 다시 쓰고 WASM까지 가능하게 만드는 장기 프로젝트에서 Sonnet 5.5의 맥락 판단과 출력 태도가 확인된다.

9.1. 수백만 줄의 레거시 슬롭 정리

1. 프로젝트 배경

   1. Microsoft의 훌륭한 Go 재작성판이 이미 있지만, 더 멀리 밀어붙이고 WASM으로 동작시키는 가능성을 확인하기 위해 Rust 재작성 프로젝트가 시작됐다.
   2. 원래는 완성하기 어려운 하일메리 프로젝트였지만, Opus가 작업을 크게 진전시켰다.
   3. 다만 Astra와 Soul이 남긴 수백만 줄의 슬롭을 Opus가 그대로 물려받았고, 자동으로 정리하지는 못했다.

2. Sonnet의 스레드 맥락 판단

   1. 레거시 코드를 멈추고 정리하라고 지시한 뒤, T3 Code의 변경 모니터링 스레드에서 삭제 현황을 물었다.
   2. 화면에 레거시 코드 삭제 내용이 보이지 않아 Sonnet 5.5가 의도를 이해하지 못한 회귀인지 의심했다.
   3. 실제로는 숫자만 이야기하던 다른 스레드를 보고 있었고, Sonnet은 그 스레드의 맥락에 맞춰 계속 숫자 관련 작업을 수행하고 있었다.
   4. 현재 스레드의 맥락과 맞지 않는 요청을 억지로 추측하지 않고, 스레드가 지금까지 하던 일을 이어간 판단은 오히려 올바른 행동이었다.

3. 결과

   1. 촬영을 시작한 직후 작업을 실행했는데, 약 160만 줄의 코드가 삭제됐다.
   2. 작업 전체를 이해하지 못해서가 아니라, 요청을 보낸 스레드의 맥락을 일관되게 유지했기 때문에 처음에 오해가 생겼다.

10. Fish Slop 데모: 비용보다 결과가 놀라운 사례

Fish Slop은 모델이 3D 자산과 플레이 가능한 게임을 생성하는 작업으로, Sonnet 5.5가 실제로 얼마나 많은 일을 할 수 있는지 보여 준다.

10.1. Opus와의 비용·토큰 비교

1. 비용

   1. Sonnet 실행 비용은 Opus 실행과 대략 비슷했다.
   2. Opus 실행에는 실수로 Fable 5.1 서브에이전트가 포함돼 Opus의 수치가 정확하지 않을 가능성이 있다.
   3. Fable 서브에이전트를 빼고 다시 측정하면 Opus가 더 저렴해질 가능성이 있다.

2. 입력 토큰

   1. Sonnet 5.5는 Opus보다 3.5배 이상 많은 입력 토큰을 사용했다.
   2. 많은 토큰을 사용했음에도 최종 비용은 비슷했으며, 빠른 생성 속도가 일부를 상쇄했다.
   3. 따라서 Sonnet의 “저렴함”은 토큰 단가가 아니라 특정 서브에이전트 역할에서의 비용·시간 조합으로 이해해야 한다.

10.2. 게임 품질과 생성 비용

1. 시각적 결과

   1. Fish Slop은 지금까지 본 결과 중 최고 수준에 속한다.
   2. 일부 모델보다 떨어지는 부분은 있지만, Astra나 다른 연구소 모델에서 얻은 결과보다 전체적으로 뛰어나다.
   3. 물고기에는 각자 알아볼 수 있는 고유한 디자인이 있고, 귀엽게 보인다.
   4. 산호와 해초도 충분히 자연스럽고, 3D 자산을 무엇으로 표현했는지 명확하게 구분할 수 있다.

2. 플레이 감각

   1. 화면 녹화는 30fps처럼 보이지만 노트북에서는 120fps로 부드럽게 실행됐다.
   2. 물고기의 움직임과 게임 메커니즘이 안정적이고 균형이 잡혔다.
   3. 물고기 애니메이션은 특히 사랑스럽고, 펠리컨 같은 주변 요소도 들어 있다.
   4. 공격 이벤트가 발생하면 나타나는 외계인이 다른 데모보다 훨씬 잘 만들어진 핵심 오브젝트다.

3. 생성 경제성

   1. 모델에 프롬프트를 던진 뒤 약 40분 만에 몇 달러로 플레이 가능한 결과가 나왔다.
   2. API 정가를 적용해도 약 16달러이며, 그보다 비싼데도 더 형편없는 게임을 구매한 경험과 비교할 수 있다.
   3. Fortnite 스킨 하나의 가격으로 직접 게임을 만들 수 있다는 점이 생성형 개발의 변화를 상징한다.

11. 구독 플랜의 실제 사용량과 모델 배치

Claude Code 200달러 플랜은 모델을 어떻게 배치하느냐에 따라 매우 큰 작업량을 감당할 수 있다.

11.1. 계정별 사용량 추정

1. 실제 계정 분석

   1. 여섯 개의 Cloud 계정을 사용해 왔고, 최근 며칠 사이 세 계정을 종료하면서 실제 소비량을 대략 계산했다.
   2. 200달러 플랜 하나에서 일주일에 약 2,300달러 상당의 사용량이 나왔다.
   3. 30일로 환산하면 한 달에 거의 1만 달러 상당의 모델 사용량을 200달러 구독으로 확보하는 셈이다.

2. Sonnet의 위치

   1. 일반 작업에서 직접 선택하는 모델로는 Sonnet이 Opus보다 달러당 훨씬 더 많은 일을 해 주지 않는다.
   2. 반면 Opus가 코드베이스 심층 조사, 특정 동작 확인, API 가설 검증에 Sonnet을 호출하면 비용이 매우 낮고 속도도 빠르다.
   3. Opus가 적절한 순간에 Sonnet을 서브에이전트로 배치하면, 전체 시스템은 더 빠르게 실제 일을 끝내면서 약간 더 저렴해질 수 있다.

12. 결론: OpenAI가 답해야 하는 질문

Sonnet 5.5는 직접 사용할 때는 애매하지만, 상위 모델의 도구로 사용하면 Anthropic 제품군에 중요한 층을 추가한다.

12.1. 직접 사용에 대한 결론

1. 선택하지 말아야 할 주력 모델

   1. Claude Code에서 Fable·Opus·Sonnet 중 하나를 직접 고르는 상황이라면 대부분의 사용자는 Sonnet을 선택할 이유가 적다.
   2. 프런트엔드 디자인은 Fable과 Opus가 낫고, 일반 코드 작업은 Opus가 비슷한 비용으로 더 안정적이다.
   3. Sonnet은 토큰을 많이 사용하고 Max 모드에서는 비용이 폭발하며, 실제 완료 시간도 Opus보다 길 수 있다.

2. 서브에이전트로서의 결론

   1. 코드베이스의 사실 확인, 아키텍처 조사, 특정 패턴 검색, 상위 모델의 가설 검증에는 매우 적합하다.
   2. 문서·오피스 작업에서도 같은 구조의 이점이 기대되지만, 핵심 강점은 개발 에이전트의 조사 계층이다.
   3. 사람이 직접 프롬프트를 보내지 않고 Opus나 Fable이 적절한 시점에 호출하게 만들 때 Sonnet의 가격·속도·품질 조합이 살아난다.

12.2. OpenAI에 남은 과제

1. 경쟁 우위의 상실

   1. OpenAI는 현재 가장 똑똑한 모델을 갖지 못했다.
   2. 가장 효율적인 모델도 갖지 못했다.
   3. 가장 싼 모델도 갖지 못했다.
   4. 다른 모델을 호출하는 데 가장 좋은 모델도 갖지 못했다.

2. 다음 경쟁의 방향

   1. OpenAI는 조만간 반격해야 하며, Dev Day를 전후로 새로운 발표가 나올 가능성이 있다.
   2. 모델 경쟁은 느려지기보다 더 빨라질 가능성이 높다.
   3. 사용자는 모델 하나의 벤치마크 점수보다, 상위 에이전트가 어떤 하위 모델을 언제 호출하고 전체 비용·시간을 어떻게 줄이는지를 보게 된다.

주요 발언 모음

“Sonnet 5.5는 당신이나 내가 선택해야 하는 모델이 아니다.”

“Sonnet은 직접 호출해서는 안 된다. Opus나 Fable이 복잡한 일을 쪼갤 때 사용하는 여러 도구 중 하나여야 한다.”

“Max는 존재하지 않는다고 생각해라. 그러면 삶이 훨씬 편해진다.”

“이 모델은 당신이 프롬프트를 보내는 한 유용한 것이 아니라, 당신이 프롬프트를 보내지 않을 때 유용하다.”

“OpenAI는 가장 똑똑한 모델도, 가장 효율적인 모델도, 가장 싼 모델도, 다른 모델을 호출하는 데 가장 좋은 모델도 갖고 있지 않다.”

핵심 데이터 & 수치

• Terminal Bench 4: Sonnet 5.5 70.6%, Sonnet 5 10.3%로 약 7배 상승했다.
• 명목 속도·가격 개선: 대부분의 작업에서 최대 30% 빠르고 최대 30% 저렴하다고 발표됐다.
• Sonnet 5.5 API: 입력 100만 토큰 2달러, 출력 100만 토큰 10달러, 캐시 읽기 100만 토큰 0.20달러다.
• Opus 5.5 API: 입력 4달러, 출력 20달러로 Sonnet의 두 배다.
• Cursor Bench 토큰: Sonnet 5.5 271,920토큰, Opus 5.5 218,000토큰, Gemini 3.8 Flash 162,000토큰이다.
• 토큰 생성 속도: OpenRouter 보고치는 Sonnet 약 94TPS, Opus 약 70TPS이며 공식 구독 측정치는 각각 약 150TPS·100TPS다.
• Fish Slop 완료 시간: Sonnet 43분, Opus 36분이며 생성 토큰 시간은 각각 39분·27분이다.
• 추론 Max 비용: Sonnet 5.5 Max 7.60달러, 비교된 Astra Max 3.26달러다.
• T3 Code 분석 벤치: Sonnet은 Opus의 절반 정도 비용으로 약 5분 만에 완료했고, Opus는 약 2배, Astra는 약 3배 걸렸다.
• Fish Slop 생성 비용: API 정가 기준 약 16달러이며, 구독 환경에서는 훨씬 저렴하다.
• 구독 사용량 추정: 200달러 Cloud Code 플랜 하나에서 일주일 약 2,300달러, 한 달 약 1만 달러 상당의 사용량이 나왔다.
• 레거시 코드 정리: TypeScript Rust 재작성 프로젝트에서 약 160만 줄이 삭제됐다.

결론 및 시사점

1. Sonnet 5.5를 일상 코드의 기본 모델로 선택하기 전에 캐시 읽기 비용과 작업당 토큰 수를 계산해야 한다.
2. Max 추론은 성능 향상보다 강제 토큰 소비와 과잉 추론 오류를 만들 가능성이 커서 피하는 편이 안전하다.
3. 모델의 속도는 TPS가 아니라 전체 토큰 수와 작업 완료 시간까지 합쳐 평가해야 한다.
4. Sonnet의 가장 좋은 사용처는 대규모 저장소 조사, 특정 동작 확인, 아키텍처 분해, 상위 에이전트의 가설 검증이다.
5. Opus나 Fable이 Sonnet을 서브에이전트로 적절히 호출하면 상위 모델의 체감 속도와 비용 효율이 동시에 개선될 수 있다.
6. AI 코딩 시스템의 경쟁력은 단일 최강 모델이 아니라, 모델별 강점을 조합하는 오케스트레이션 설계에서 결정된다.
7. OpenAI는 모델 지능·효율·가격·멀티모델 호출 능력 모두에서 명확한 우위를 되찾아야 한다.

핵심 요약 (20줄)

1. Anthropic의 Sonnet 5.5는 Opus와 Fable에 이어 등장한 빠른 코드·분석 모델이다.

2. 공식 발표는 Sonnet 5.5가 대부분의 작업에서 최대 30% 빠르고 최대 30% 저렴하다고 설명한다.

3. Terminal Bench 4 점수는 Sonnet 5의 10.3%에서 Sonnet 5.5의 70.6%로 뛰었다.

4. Sonnet 5.5는 장기 작업과 이미지 이해에서 개선됐고 스크린샷만으로 Pokémon Red를 플레이했다.

5. Claude 특유의 장황한 출력 습관이 줄어 사람과 협업하기 쉬운 문장을 만든다.

6. Sonnet 5.5의 표면 가격은 입력 2달러, 출력 10달러, 캐시 읽기 0.20달러다.

7. 에이전트 코딩은 캐시 읽기 토큰이 많아서 표면 입력 가격만으로 실제 비용을 판단할 수 없다.

8. Sonnet 5.5는 실제 코드 작업에서 Opus와 비슷하거나 더 비싼 비용이 나올 수 있다.

9. Cursor Bench에서 Sonnet 5.5는 작업당 271,920토큰을 사용해 Opus보다 비효율적이었다.

10. Sonnet 5.5의 생성 속도는 빠르지만 많은 토큰 때문에 Fish Slop 완주 시간은 Opus보다 길었다.

11. Max 추론은 xhigh보다 토큰 사용량을 최대 1,500% 늘리고 쉬운 작업을 과잉 추론하게 만들 수 있다.

12. 실용적인 설정은 Max와 low를 피하고 작업 복잡도에 맞춰 medium이나 high를 선택하는 방식이다.

13. Witch AI 디자인 실험에서 Sonnet 5.5는 Fable과 Opus보다 거칠고 프런트엔드 완성도가 낮았다.

14. Sonnet 5.5의 핵심 가치는 최종 결과를 혼자 만드는 모델보다 상위 에이전트의 조사 도구에 있다.

15. T3 Code Orchestrator v2 분석에서 Sonnet은 Opus의 절반 비용과 약 5분의 실행 시간으로 더 높은 평가를 받았다.

16. 대규모 코드베이스의 구조 파악과 변경 계획 수립은 Sonnet의 가장 강력한 사용처다.

17. TypeScript를 Rust로 재작성한 프로젝트에서는 맥락에 맞는 스레드를 따라가며 약 160만 줄의 레거시 코드가 삭제됐다.

18. Fish Slop 데모는 약 40분과 API 기준 16달러로 귀엽고 부드럽게 플레이되는 3D 게임을 만들었다.

19. 200달러 Claude Code 플랜은 모델을 서브에이전트로 배치할 때 한 달 약 1만 달러 상당의 사용량을 제공할 수 있다.

20. OpenAI는 지능·효율·가격·멀티모델 호출 능력 모두에서 반격해야 하며 모델 경쟁은 더 빨라질 가능성이 높다.