Claude 4 공개: Opus 4와 Sonnet 4

 (anthropic.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Anthropic이 Claude Opus 4와 Claude Sonnet 4를 공개하며, 코딩·고급 추론·AI 에이전트 작업을 차세대 Claude의 중심 성능 영역으로 내세움
  • 두 모델은 즉시 응답과 깊은 추론을 오가는 하이브리드 모델이며, 확장 사고 중 웹 검색 같은 도구 사용과 병렬 도구 실행을 지원함
  • Opus 4는 SWE-bench 72.5%, Terminal-bench 43.2% 를 기록했고, Sonnet 4는 SWE-bench 72.7% 로 Sonnet 3.7 대비 코딩·추론·지시 이행을 개선함
  • Claude Code는 정식 출시되어 터미널, VS Code, JetBrains, GitHub Actions, SDK로 확장되며 PR 리뷰 대응·CI 오류 수정·코드 변경까지 맡을 수 있음
  • API에는 코드 실행 도구, MCP connector, Files API, 최대 1시간 프롬프트 캐시가 추가되어 개발자가 더 강력한 AI 에이전트를 만들 수 있음

Claude 4 모델 공개

  • Anthropic은 Claude Opus 4와 Claude Sonnet 4를 Claude의 차세대 모델로 공개함
  • 두 모델의 핵심 초점은 코딩, 고급 추론, AI 에이전트 작업임
  • Claude Opus 4는 복잡하고 오래 실행되는 작업과 에이전트 워크플로에서 지속 성능을 내는 코딩 모델임
  • Claude Sonnet 4는 Claude Sonnet 3.7의 업그레이드로, 코딩·추론 성능과 지시 이행 정확도를 높임

제공 방식과 가격

  • Claude Opus 4와 Sonnet 4는 거의 즉각적인 응답과 더 깊은 추론을 위한 확장 사고 모드를 모두 제공함
  • Pro, Max, Team, Enterprise Claude 플랜에는 두 모델과 확장 사고가 포함됨
  • Sonnet 4는 무료 사용자도 사용할 수 있음
  • 두 모델은 Anthropic API, Amazon Bedrock, Google Cloud Vertex AI에서 제공됨
  • 가격은 이전 Opus·Sonnet 모델과 동일함
    • Opus 4: 입력/출력 100만 토큰당 $15/$75
    • Sonnet 4: 입력/출력 100만 토큰당 $3/$15

Opus 4의 코딩·장기 작업 성능

  • Claude Opus 4는 Anthropic의 가장 강력한 모델로, SWE-bench 72.5%, Terminal-bench 43.2% 를 기록함
  • 수천 단계의 집중 작업이 필요한 장기 작업에서 지속 성능을 내며, 몇 시간 동안 연속 작업할 수 있음
  • Cursor는 Opus 4를 코딩에서 최첨단 모델로 보고, 복잡한 코드베이스 이해에서 큰 진전이 있었다고 평가함
  • Replit은 여러 파일에 걸친 복잡한 변경에서 정밀도가 높아졌다고 밝힘
  • Block은 자사 에이전트 codename goose에서 Opus 4가 편집·디버깅 중 코드 품질을 높이면서 성능과 신뢰성을 유지한 첫 모델이라고 설명함
  • Rakuten은 까다로운 오픈소스 리팩터링 작업을 Opus 4가 7시간 독립 실행하며 지속 성능을 보였다고 검증함
  • Cognition은 Opus 4가 이전 모델이 놓친 중요한 작업과 다른 모델이 해결하지 못한 복잡한 과제에 강하다고 평가함

Sonnet 4의 위치

  • Claude Sonnet 4는 Sonnet 3.7 대비 개선된 모델이며, SWE-bench에서 72.7% 를 기록함
  • 내부·외부 사용 사례를 위한 성능과 효율의 균형을 목표로 하며, 구현 제어를 위한 조향성도 향상됨
  • 대부분의 영역에서 Opus 4와 같지는 않지만, 능력과 실용성의 조합을 제공함
  • GitHub는 Sonnet 4를 GitHub Copilot의 새 코딩 에이전트를 구동하는 모델로 도입할 예정임
  • Manus는 복잡한 지시 이행, 명확한 추론, 미적 결과물에서 개선을 강조함
  • iGent는 자율적인 다기능 앱 개발과 코드베이스 탐색이 개선됐고, 탐색 오류가 20%에서 거의 0으로 줄었다고 밝힘
  • Sourcegraph는 Sonnet 4가 더 오래 방향을 유지하고, 문제를 더 깊게 이해하며, 더 우아한 코드 품질을 제공한다고 평가함
  • Augment Code는 더 높은 성공률, 더 정밀한 코드 편집, 복잡한 작업에서의 신중함을 이유로 Sonnet 4를 기본 모델의 최우선 선택으로 삼음

모델 기능 개선

  • 두 모델은 확장 사고 중에도 도구를 사용할 수 있음
    • 예시로 web search를 사용할 수 있음
    • Claude는 추론과 도구 사용을 번갈아 수행해 응답을 개선할 수 있음
  • 병렬 도구 실행과 더 정확한 지시 이행도 지원함
  • 개발자가 로컬 파일 접근을 제공하면, 모델은 핵심 사실을 추출·저장해 연속성과 암묵 지식을 유지하는 메모리 기능을 보임
  • 지름길이나 허점을 이용해 작업을 끝내는 행동은 Sonnet 3.7 대비 줄어듦
    • 특히 지름길과 허점에 취약한 에이전트 작업에서 두 모델은 Sonnet 3.7보다 해당 행동을 할 가능성이 65% 낮음
  • Opus 4는 개발자가 로컬 파일 접근을 제공하는 애플리케이션에서 핵심 정보를 담는 memory files를 생성·유지하는 데 강함
    • 예시로 Pokémon을 플레이하는 동안 Navigation Guide를 생성함
    • 장기 작업 인식, 일관성, 에이전트 작업 성능을 개선함

사고 요약과 Developer Mode

  • Claude 4 모델에는 긴 사고 과정을 작은 모델로 압축하는 thinking summaries가 도입됨
  • 이 요약은 약 5% 의 경우에만 필요함
  • 대부분의 사고 과정은 전체를 표시하기에 충분히 짧음
  • 고급 프롬프트 엔지니어링을 위해 원시 사고 사슬이 필요한 사용자는 contact sales를 통해 새 Developer Mode를 문의할 수 있음

Claude Code 정식 출시

  • Claude Code는 정식 출시되어 Claude를 터미널, IDE, 백그라운드 실행 워크플로로 확장함
  • VS Code와 JetBrains용 새 베타 확장이 Claude Code를 IDE에 직접 통합함
    • Claude가 제안한 편집 내용은 파일 안에 인라인으로 표시됨
    • 사용자는 익숙한 에디터 안에서 리뷰와 변경 추적을 할 수 있음
    • IDE 터미널에서 Claude Code를 실행하면 설치됨
  • GitHub Actions를 통한 백그라운드 작업을 지원함
  • 확장 가능한 Claude Code SDK도 공개됨
    • 개발자는 Claude Code와 같은 핵심 에이전트를 사용해 자체 에이전트와 애플리케이션을 만들 수 있음
  • Claude Code on GitHub는 베타로 제공됨
    • PR에서 Claude Code를 태그해 리뷰어 피드백에 응답하고, CI 오류를 고치고, 코드를 수정할 수 있음
    • Claude Code 안에서 /install-github-app을 실행해 설치함

API와 안전성

  • Anthropic API에는 AI 에이전트 개발을 위한 네 가지 새 기능이 추가됨
    • 코드 실행 도구
    • MCP connector
    • Files API
    • 최대 1시간 프롬프트 캐시
  • Claude 4 모델은 전체 컨텍스트 유지, 긴 프로젝트에서의 집중 유지, 큰 영향을 내는 작업을 향한 단계로 자리 잡음
  • 모델에는 위험을 줄이고 안전성을 높이기 위한 광범위한 테스트와 평가가 적용됨
  • 더 높은 AI Safety Levels인 ASL-3를 위한 보호 조치가 포함됨
  • 사용자는 Claude, Claude Code, 또는 원하는 플랫폼에서 시작할 수 있음

벤치마크 보고 방식

  • Claude Opus 4와 Sonnet 4는 하이브리드 추론 모델이며, 공개된 벤치마크는 확장 사고 사용 여부와 관계없이 달성한 최고 점수를 표시함
  • 확장 사고를 사용하지 않은 결과는 다음 항목임
    • SWE-bench Verified
    • Terminal-bench
  • 확장 사고를 사용한 결과는 최대 64K 토큰까지 사용함
    • TAU-bench
    • GPQA Diamond
    • MMMLU
    • MMMU
    • AIME
  • 확장 사고 없이 측정한 일부 점수도 제공됨
    • GPQA Diamond: Opus 4 74.9%, Sonnet 4 70.0%
    • MMMLU: Opus 4 87.4%, Sonnet 4 85.4%
    • MMMU: Opus 4 73.7%, Sonnet 4 72.6%
    • AIME: Opus 4 33.9%, Sonnet 4 33.1%

TAU-bench와 SWE-bench 방법론

  • TAU-bench 점수는 Airline과 Retail Agent Policy에 프롬프트 부록을 추가해, Claude가 확장 사고와 도구 사용 중 추론 능력을 더 잘 활용하도록 한 설정에서 얻음
  • 모델은 문제 해결 중 일반 사고 모드와 구분되는 방식으로 생각을 적도록 유도됨
  • 추가 사고로 인해 단계 수가 늘어날 수 있어 최대 단계 수는 30에서 100으로 증가함
    • 대부분의 궤적은 30단계 미만에서 끝남
    • 50단계를 넘은 궤적은 하나뿐임
  • Claude 4 계열의 SWE-bench에서는 이전 릴리스와 같은 단순 스캐폴드를 계속 사용함
    • 도구는 bash 도구와 문자열 치환 방식 파일 편집 도구 두 가지뿐임
    • Claude 3.7 Sonnet에서 사용한 세 번째 planning tool은 더 이상 포함하지 않음
  • 모든 Claude 4 모델 점수는 전체 500개 문제 기준으로 보고됨
  • OpenAI 모델 점수는 477개 문제 부분집합 기준으로 보고됨
  • “high compute” 점수는 병렬 테스트 시점 계산과 추가 복잡도를 사용함
    • 여러 병렬 시도를 샘플링함
    • 저장소의 보이는 회귀 테스트를 깨는 패치를 버림
    • 숨겨진 테스트 정보는 사용하지 않음
    • 내부 채점 모델로 남은 시도 중 최선 후보를 선택함
  • 이 방식의 high compute 점수는 Opus 4 79.4%, Sonnet 4 80.2% 임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이번 발표에서 빠진 중요한 점은 Claude 4의 학습 컷오프가 2025년 3월이라는 것임. 최근 모델 중 가장 최신이고, Gemini 2.5는 2025년 1월 컷오프임
    https://docs.anthropic.com/en/docs/about-claude/models/overv...

    • 이제 주요 사용자용 LLM 제품에는 모두 웹 검색이 들어가 있고, 일부 API에도 제공되거나 가끔 의도치 않게 가능해서, 적어도 개인적으로는 정확한 컷오프 월이 점점 덜 중요해지는 느낌임
      자주 쓰는 모델들은 특정 주제에 새 정보가 필요하다는 걸 스스로 판단하고 가져올 만큼은 똑똑한 편임
    • 좋네. 이제 드디어 Svelte 5를 알고 있을지도 모름
    • Tailwind 4를 Claude가 몰라서 고생했던 적이 있어 Tailwind CSS에 대해 물어봤더니, 자신은 2025년 1월 컷오프 기준 최신 안정판인 Tailwind CSS 3.4까지 안다고 답함
    • 왜 지속적으로 학습시킬 수는 없는 걸까?
    • 그래도 무엇이 업데이트됐고 무엇이 안 됐는지는 모름. 업데이트 가능한 모든 것이 업데이트됐다고 가정할 수 있을까?

  • “GitHub says Claude Sonnet 4 soars in agentic scenarios and will introduce it as the base model for the new coding agent in GitHub Copilot.”
    이 모델이 “Assign to CoPilot”을 패키지 업그레이드 같은 대부분의 기계적인 일을 자동 처리하는 꿈에 더 가깝게 밀어줄 수도 있음. 유지보수 부담이 줄면 오래된 프로젝트의 부활로 이어질 가능성도 큼

    • 그럴 수도 있지만, 이전 모든 모델이 나올 때도 똑같은 기대를 받았음
    • 저렴한 코딩 에이전트가 오픈소스에 무엇을 해줄 수 있을지 정말 기대됨. 사실 CheepCode[0] 크레딧을 오픈소스 프로젝트에 나눠줘야겠다는 생각이 듦
      아직 공식 구조는 없지만 이 댓글을 보고 무료 코딩 에이전트 실행이 필요하면 이메일을 보내면 세팅해주겠음
      [0] 내 헤드리스 코딩 에이전트 제품으로, “assign to copilot”과 비슷하지만 Linear, Jira 같은 작업 보드에서 여러 작업을 병렬로 처리함. 지금까지 단순하고 반복적인 기능은 꽤 성공적이었고, 대체로 테스트가 좋을수록 결과 코드도 좋아짐. 물론 자체 테스트도 작성할 수 있고 실제로 작성함
    • 이런 모델이 유용한지 판단하는 내 기준이 딱 그 지점임. 다시 작동하게 하려면 대규모 리팩터링이 필요한 프로젝트가 있는데, 주로 패키지 업그레이드지만 작성 당시에는 없던 새 언어 의미론에 맞춰 코드도 고쳐야 함
      지금의 AI 모델들은 이 작업에서 사실상 진전을 전혀 못 냄. 가능해질 때까지 계속 시도해볼 생각임
    • 패키지 업그레이드와 기계적인 작업은 이미 봇으로 대부분 해결된 영역임
      여기서 AI가 도울 수 있는 부분은 변경사항, 충돌, 코드베이스 영향 요약과 가능하다면 보안 스캔 정도라고 봄
    • Copilot에 언제 적용될 계획인지 소식 본 사람 있음?

  • “Users requiring raw chains of thought for advanced prompt engineering can contact sales”
    이제 세 LLM 제공사가 모두 사고 과정(CoT) 을 숨기는 것처럼 보임. 아쉬운 일인 게, 잘못된 방향으로 가려는 순간을 볼 수 있어서 프롬프트를 빠르게 다듬는 데 도움이 됐음
    OpenAI뿐 아니라 Google도 최근 사고 과정을 요약으로 바꾸기 시작했는데, 개인적으로는 지나치게 단순화된 요약이라고 봄

    • 사고 과정을 제외하는 이유가 최근 Anthropic 논문 때문일 수도 있을까?
      https://assets.anthropic.com/m/71876fabef0f0ed4/original/rea...
      논문은 최신 추론 모델의 사고 과정 충실도를 6가지 추론 힌트로 평가했고, 대부분 설정과 모델에서 힌트를 사용한 사례 중 최소 1%는 사고 과정에 드러나지만 공개율은 대개 20% 미만이며, 결과 기반 강화학습은 처음에는 충실도를 올리지만 포화되지 않고 정체되며, 보상 해킹으로 힌트 사용 빈도가 늘어도 사고 과정에서 그것을 말로 표현하는 경향은 늘지 않는다고 함
      즉 사고 과정도 모델의 꾸며낸 설명일 수 있음. 그래서 Anthropic 내부 누군가가 고객을 오도하고 싶지 않은 것일 수도 있고, 이 문제가 해결되면 다시 돌아올지도 모름
    • 이건 연금술이고, 모두가 납을 금으로 바꾸는 데 자신만의 우위가 있다고 믿기 때문임
    • 기억하기로 RLHF는 위험한 응답을 하지 않도록 학습시키는 과정에서 모델 정확도를 필연적으로 일부 희생함
      사고 과정용 모델이 최종 사용자와 상호작용하는 모델과 다르게 학습됐다면 말이 됨. 예를 들어 MoE의 다른 전문가일 수도 있고, 사용자는 어차피 공개 모델로 필터링된 출력만 보게 되므로 사고 과정 모델은 RLHF 이전에 가까운 원본 모델에 더 가까워도 회사 평판 리스크가 적음
      이렇게 하면 원본 모델의 성능을 얻으면서도 실제 피해나 심각한 PR 사고를 막기 위한 필터링은 유지할 수 있음
    • DeepSeek가 다시 모두를 압도할 때까지 기다려야 할 듯
    • Zig를 배울 때는 사고 과정이 엄청나게 도움 됐음
      Zig와 구현에 대해 물어볼 때 모델의 사고 과정을 보면서 시야가 많이 넓어졌음

  • 이 버전이 이전보다 더 낫지 않고, LLM이 사실상 정체기에 들어섰으며, 새 릴리스의 “기능”은 대체로 눈속임에 가깝다고 생각하는 사람이 나뿐일 리 없음

    • 가장자리 부분에서만 좋아지는 것 같음. MCP, 도구 호출, 구조화 출력 같은 영역임. 확실히 지능이 늘어난 건 아니지만 부가가치는 늘었고, 그 가치가 학습 비용이나 회사 가치평가에 맞는지는 모르겠음
      현실적으로 이런 회사들이 어떻게 지속 가능할지 전혀 감이 안 옴. 클라우드 GPU에서 추론을 호스팅해봤는데, 무료 플랜을 조금이라도 붙이면 비용이 극도로 부담스러워 보였음
    • “LLM이 정체기에 도달했다”는 건 새로운 확률적 앵무새 밈처럼 들림. 몇 시간 전 메인에 올라온 글만 봐도, LLM 기반 에이전트가 이메일 검색 도구 3개와 “내 형제의 아이 이름을 찾아라”라는 단순 작업을 받고 체계적으로 문제를 풀고, 검색을 다듬고, “X가 좋아하는 음식”과 유튜브 링크만 있는 이메일에서 올바른 이름을 추론했음
      alphaevolve, 브라우저를 실행하며 기능을 탐색하고 Playwright 테스트를 작성하는 Microsoft의 Copilot 에이전트 테스트 데모, 코딩 분야의 발전은 말할 것도 없음
    • Claude Code를 많이 써봤고 동의함. 업데이트 이후 차이를 하나도 못 느꼈음. 요약은 조금 더 깔끔해진 것 같지만 능력 면에서 놀란 적은 없음
      TypeScript 코드베이스에서 3.7 때와 마찬가지로 계속 고쳐주고 다시 프롬프트해야 했음. 심지어 잘못된 파일을 편집하던 상황에서, 코드를 모두 삭제하고 우리가 보고 있던 대상이 전혀 바뀌지 않았다는 걸 보여주라고 강제하기 전까지 더 구체적으로 확인할 생각을 못 해서 꽤 충격이었음
    • 전반적으로 같은 느낌임. 요즘 벤치마크 승리는 튜닝에서 오는 것처럼 보이고, 대신 다른 영역에서 손실이 생김. o3, o4-mini도 SimpleQA, PersonQA에서 o1보다 환각이 더 많음
      합성 데이터는 환각률을 높이는 것 같고, 추론 모델은 각 추론 단계마다 환각이 모델을 빗나가게 할 위험이 있어 더 취약함
      범용 사용 관점의 LLM은 올해 초쯤 이미 끝났다고 봄. OpenAI도 GPT-5를 취소하고 나중에 “얻는 것 대비 너무 비싼” GPT-4.5를 출시했다가 곧 종료하기로 하면서 이걸 알게 됐음
      주식시장이 아직 이걸 반영했는지는 모르겠음. 여기서 벗어나려면 돌파구가 필요함
    • 많은 경우 벤치마크가 Claude 3.7과 매우 비슷해 보임
      그렇다고 정체기에 도달했다고 보기에는 전혀 충분하지 않음. 진행 속도가 엄청나게 빨랐으니, 그런 판단은 몇 달 더 기다려야 함
      기능들에 대해서는 오히려 반대로 생각함. 눈속임이 아니라, 핵심 AI 자체는 아니지만 AI를 실제로 활용하기 위해 필요한 중요한 도구화임. 대중적 사용 기준의 LLM 분야는 아직 초기 단계임. 모델이 더 좋아지지 않더라도, 상호작용 방식, 정보 공급, 도구 호출 같은 기능 쪽에는 사용성과 능력을 크게 끌어올릴 여지가 아주 많음

  • Claude 3.7을 정말 좋아하고 매일 쓰며 Gemini 모델보다 대체로 선호함. 그런데 Claude Code에서 Opus 4를 Go 코드베이스의 거의 신규 기능 작업에 써봤더니, 사고 과정은 좋지만 도구 호출의 70~80% 가 실패함
    “Write”, “Update” 같은 기본 도구도 잘못된 문법으로 실패함. 파일 작성 시도 5번이 모두 실패했고, “content 파라미터를 추가하는 걸 계속 까먹네요. 고쳐보겠습니다”라고 하며 계속 시도함
    뭔가 잘못됐음. 곧 해결되길 바라지만, 지금으로서는 적어도 Opus 4는 Claude Code에서 사용할 수 없음. 그래도 생성에 성공한 파일은 품질이 높았음

    • 원인을 찾은 것 같고, 명백한 버그로 보임: https://github.com/anthropics/claude-code/issues/1236#issuec...
      기본적으로 최대 출력 토큰 수에 걸려서, 새 파일 전체를 한 번에 쓰다가 응답이 멈추는 것 같음. “잘못된 도구 호출 파라미터” 오류는 헛다리였음

  • 이미 Opus 4와 Sonnet 4를 우리 SQL 생성 벤치마크에서 테스트했음: https://llm-benchmark.tinybird.live/
    Opus 4가 다른 모든 모델을 이겼고, 좋음

    • Opus 4가 원샷에서 최악이라는 게 이상함. 유효한 쿼리를 생성하는 데 평균 두 번의 시도가 필요함
      모델이 정말 그렇게 더 똑똑하다면 첫 시도 성능도 좋아야 하지 않나? 어쨌든 사전에 “생각”하긴 하니까
    • 흥미롭게도 Claude-3.7-Sonnet과 Claude-3.5-Sonnet이 Claude-Sonnet-4보다 순위가 높음
    • 이 벤치마크는 꽤 흥미로움. 다른 벤치마크에서 흔히 보던 모델 순위를 깨는 것처럼 보임
    • Claude Premium을 내고 있지만 실제로는 Grok도 꽤 많이 씀. “think” 기능이 원하는 결과에 더 자주 데려다주는 편임
      xAI 모델이 목록에 없는 게 이상함. Grok이라는 이름은 형편없지만 꽤 자주 놀라게 해줌. 아직 250달러짜리 ChatGPT 모델은 써보지 않았고, 요즘 OpenAI의 행태가 마음에 들지 않음
    • 궁금한데, 질문과 SQL이 LLM 학습 데이터에 없다는 걸 어떻게 알 수 있음? 벤치마크 질문과 SQL이 온라인에 있는 것처럼 보임: https://ghe.clickhouse.tech/

  • Claude 4의 컨텍스트 창 변경사항을 문서화한 곳이 있나? 잘 알지는 못하지만 Gemini 2.5가 유용했던 이유 중 하나가 5만~7만 줄 규모의 엄청난 컨텍스트를 처리할 수 있어서라고 이해하고 있었음

    • Sonnet의 컨텍스트 창은 그대로임. 입력 200k, 출력 64k: https://docs.anthropic.com/en/docs/about-claude/models/overv...
      실제로는 Gemini 2.5의 1M 컨텍스트가 그렇게 큰 차별점은 아님. 컨텍스트가 커질수록 뒤쪽 토큰을 잘 따르는 능력의 체감 수익이 줄어듦
    • 컨텍스트 창을 늘리거나 프롬프트가 너무 길어졌을 때 더 잘 처리해주면 좋겠음. 지금은 갑자기 “prompt is too long” 경고가 떠서 긴 대화나 글쓰기에서 다루기 답답한 모델이 됨
      다른 도구들은 이전 컨텍스트 일부를 버리거나 RAG를 쓰기도 하지만, 경고 없이 새 채팅을 시작하게 강제하지는 않음
    • 무슨 뜻인지 잘 모르겠음. 기사 제목에 Opus 4가 200k 컨텍스트라고 나와 있음
      Sonnet 3.7의 베타 헤더와 같음
    • 컨텍스트 창 크기는 굉장히 가짜 같은 지표임. 올바른 컨텍스트가 없으면 좋은 출력도 안 나옴

  • “Finally, we've introduced thinking summaries for Claude 4 models that use a smaller model to condense lengthy thought processes. This summarization is only needed about 5% of the time—most thought processes are short enough to display in full. Users requiring raw chains of thought for advanced prompt engineering can contact sales about our new Developer Mode to retain full access.”
    모델 추론의 “요약”을 보고 싶지 않음. 모델의 추론이 정확한지, 결과를 신뢰할 수 있는지 확인하려면 실제 추론을 봐야 함
    OpenAI에 이어 Anthropic까지 모델의 사고 과정을 숨기고, 사용자가 볼 수 없는 토큰에 과금하며, 실제로 무슨 일이 벌어지는지 알 수 없게 만드는 “요약”을 제공하는 방향으로 가는 게 매우 짜증남

    • 여러 논문이 “생각” 출력이 최종 출력과 별 관계가 없고, 점이나 일시정지 토큰으로 추가 처리 단계를 가능하게 해도 비슷한 개선이 나온다고 보고 있음
      여러 면에서 “생각”은 대부분 마케팅에 가까움
    • 너무 걱정할 필요는 없음. 생각이 출력과 자주 분리된다는 증거는 충분함
      사람들이 실제로 사고 과정을 거의 읽지 않는다는 점을 고려하면, 이건 사용자 경험 개선이라고 봄
    • 이게 자체 채팅 인터페이스를 말하는 건가? API는 여전히 thinking 토큰을 즉시 스트리밍함
    • Gemini 2.5 Pro도 이렇게 하는 것으로 알고 있음

  • Sonnet 4가 3.7처럼 도구 호출에 집착하지 않기를 정말 바람. 3.5는 처음으로 모델이 프로그래밍을 마스터할 것 같은 마법 같은 경험을 줬음. 그 이후로는 좀 내리막처럼 느껴짐

    • 3.7의 “온 김에 하나만 더 해볼게요” 식의 과도한 적극성이 나도 정말 별로였음. 3.5 수준의 지시 준수로 돌아오면 좋겠음
    • 이건 모델 문제라기보다 시스템 프롬프트 문제처럼 느껴짐

  • 90년대 CPU MHz 경쟁이 돌아온 것 같음. 이제는 CPU 아키텍처와 여러 벤치마크에서 애매한 가치의 결과를 놓고 떠드는 대신, LLM들 사이에서 같은 종류의 덕후 같은 이야기를 하고 있음
    역사는 스스로 운율을 맞춤

    • 돌아오긴 했지만, 2020년대 중반 기술 발전 속도로 돌아왔음. CPU MHz 경쟁은 훨씬 느렸던 기억이 나는데, 어릴 때 90년대의 시간 인식이 더 느렸던 건지도 모르겠음
      그래도 지금 AI 경쟁에서 몇 달마다 새 모델이 나오는 것처럼, 새 CPU “드롭”이 몇 달마다 있었던 건 아니라고 꽤 확신함
답변달기