▲

Claude Sonnet 4가 이제 1백만 토큰 컨텍스트를 지원

 (anthropic.com)
2P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Anthropic의 Claude Sonnet 4가 최대 1백만 토큰 컨텍스트를 제공하게 되어, 대규모 코드베이스나 다수의 문서를 한 번에 처리할 수 있음
  • 향상된 컨텍스트 지원으로 대규모 코드 분석, 방대한 문서 집합 처리 및 컨텍스트 유지형 에이전트 개발 등 다양한 활용이 가능해짐
  • 20만 토큰을 넘어가는 프롬프트의 경우 API 요금이 인상되며, 프롬프트 캐싱 및 배치 처리를 통해 비용 절감 가능함
  • 실제 고객사인 Bolt.new와 iGent AI는 이 기능으로 생산성 및 AI 기능을 크게 향상시킴
  • 현재 Sonnet 4의 롱 컨텍스트 지원은 Anthropic API와 Amazon Bedrock에서 베타로 제공 중이며, 곧 Google Cloud로도 출시될 예정임

1백만 토큰 컨텍스트 지원

  • Anthropic API를 이용하는 Claude Sonnet 4가 이제 최대 1백만 토큰의 컨텍스트를 지원
  • 이로써 한 번의 요청에 75,000줄이 넘는 코드 전체나 여러 연구 논문을 통합적으로 처리할 수 있는 기능을 제공
  • 1백만 토큰 컨텍스트 베타 기능은 현재 Anthropic API와 Amazon Bedrock에서 사용 가능하며, Google Cloud의 Vertex AI도 곧 지원될 예정

더 길어진 컨텍스트, 확장되는 활용 사례

  • 대규모 코드 분석: 전체 코드베이스(소스 파일·테스트·문서 포함)를 한 번에 불러와, 프로젝트 구조 이해·파일 간 연관성 파악·시스템 설계 기반 코드 개선 제안이 가능해짐
  • 문서 통합 요약: 수백 건에 달하는 법률 계약서, 논문, 기술 명세서를 일괄 분석하고 문서 사이의 관계를 유지한 상태에서 종합적 인사이트 도출 가능함
  • 컨텍스트 유지형 에이전트: 수백 번의 도구 호출, 멀티스텝 워크플로우 과정에서도 전체 API 문서·도구 정의·상호 작용 기록을 포함, 일관된 상태를 유지하는 대화형 에이전트 개발이 가능함

API 가격 정책

  • 20만 토큰 이하 프롬프트: 입력 $3/백만 토큰, 출력 $15/백만 토큰
  • 20만 토큰 초과 프롬프트: 입력 $6/백만 토큰, 출력 $22.5/백만 토큰
  • 프롬프트 캐싱을 적용하면 지연 시간과 비용을 줄일 수 있음
  • 1백만 토큰 컨텍스트와 배치 처리를 결합하면 최대 50% 추가 비용 절감 가능함

고객사 활용 사례

  • Bolt.new

    • Bolt.new는 Claude를 웹 기반 개발 플랫폼과 통합해 웹 개발의 혁신을 이루고 있음
    • "Sonnet 4의 1백만 컨텍스트 윈도우로 인해 개발자는 더 커진 프로젝트를 높은 정확성으로 다룰 수 있게 되었음"

  • iGent AI

    • 영국 런던 기반 iGent AI는 Maestro라는 AI 파트너를 통해 대화 내용을 실행 가능한 코드로 변환함
    • "이전엔 불가능하던 자율적인 소프트웨어 엔지니어링 기능이 Sonnet 4의 1백만 토큰 컨텍스트로 실현되어, 실제 코드베이스 상에서 며칠에 걸친 세션 운영이 가능해짐"

사용 방법 및 향후 계획

  • 롱 컨텍스트 기능은 Anthropic API의 Tier 4 및 커스텀 요금제 고객에게 베타로 제공 중이며, 몇 주 내로 더 넓은 사용자에게 확대 예정임
  • Amazon Bedrock에서도 지원 중이고, Google Cloud Vertex AI 지원도 곧 제공될 계획임
  • 다른 Claude 제품군에도 롱 컨텍스트를 도입할 계획임
  • 상세한 정보는 공식 문서와 가격 안내 페이지에서 확인 가능함
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 전문 소프트웨어 엔지니어링 업무에서 LLM이 정말로 뛰어난 컨텍스트 유지력을 갖추는 것이 절실한 필요임을 느낌, 새로운 모델이 조금 더 나아졌다는 발표는 실무에서는 별로 흥미롭지 않음, 하지만 가격이 가장 큰 결정 요소임, 내 코드베이스를 충분히 컨텍스트 윈도우에 넣게 해주는 것은 좋지만 가격이 크게 올랐으니 지금은 컨텍스트 관리를 더 잘하는 게 맞다고 생각함, 내가 컨텍스트 윈도우를 많이 사용하는 게 서비스 제공자에게는 이득이지만 실제로 Sonnet이 얼마나 효과적으로 초점을 유지하는지는 별도 평가가 필요하다고 느껴서 실제 가치를 확신하기 어려움

    • 컨텍스트는 레포에 있고, LLM이 항상 필요한 컨텍스트를 다 가질 수 없음을 인정해야 함, 특히 대형 레포는 한 머신에 다 안 들어감, 특정 작업을 완수하려면 집중을 위해 불필요한 정보를 제거해야 하는데, 모든 것을 다 넣으면 오히려 집중력이 떨어짐, 과거엔 윈도우 크기가 너무 작았고 아직도 작다고 생각하지만, 궁극적으로는 올바른 질문을 통해 레포를 이해하는 능력이 필요함

    • 컨텍스트를 너무 많이 넣으면 LLM이 자기 스스로 혼동할 위험이 커짐, 긴 컨텍스트 때문에 리셋 없이 진행하다 보면 집중력이 흐트러짐

    • 전체 코드베이스가 아니라 추상화된 정보만을 AI가 다루도록 훈련시키는 것이 필요하다고 생각함, 실제 인간도 전체 코드를 머릿속에 담고 일하지 않으므로 LLM도 그럴 필요는 없다는 입장임

    • 최근 Claude Code로 몇 주간 작업한 후, 에이전트형 AI의 실질적인 가치는 오히려 마이너스라는 결론에 도달함, 그래도 6-8개월 뒤에 다시 시도해볼 예정임

    • 사용 목적이 단순히 더 많은 코드를 한 번에 컨텍스트에 넣는 것만은 아니라고 생각함, 특정 작업에는 최소한 필요한 맥락이 있기도 하지만, 1M 컨텍스트 모델은 데이터를 어떻게 넣을지에 대한 새로운 방식을 요구함, 이 모델의 진짜 강점은 긴 호라이즌의 반복 탐색, 인컨텍스트 학습, 재구성 같은 딥 다이브 문제에 있음; 예를 들어 API 변경을 100개의 파일에 적용하는 너비 중심 작업도 있지만, 15가지 방법을 시도해보며 해결법을 찾는 깊이 중심 작업에도 강점을 가짐, Sonnet 1M은 특히 후자에 독보적인 능력을 보임

  • Claude Code와 토큰 사용량이 걱정되는 사용자들에게 몇 가지 팁을 제안함

    1. 작업에 필요한 컨텍스트를 모아 코드베이스를 많이 넣어둠
    2. 각 논리적 정지점마다 더블 이스케이프를 눌러 컨텍스트가 가득한 체크포인트로 돌아감 (이때 해당 토큰을 추가로 쓰지 않음)
    3. Claude에게 ‘개발자가 작업 X를 완료’했다고 알리고, 그것을 콘텍스트에 넣어 피드백을 받음(개발자 본인이 쓴 것보다 남이 쓴 코드에는 더 많은 문제를 지적함) 여러 채팅을 병렬로 사용하려면 /resume으로 같은 스레드를 불러 컨텍스트가 풍부한 시점으로 더블 이스케이프해 리셋할 수 있음

    • Claude에게 “다른 세션에서 네가 X 작업을 썼다”고 하고, 그 컨텍스트를 활용해 질문하거나 변경 요청을 하는 방법을 씀

    • 나도 자주 그렇게 하지만, 항상 잘 먹히지는 않음, 때로는 전체 대화 맥락을 가진 채로 Claude를 활용하는 게 더 도움 됨

    • 대기 시간이 크게 줄어듦, 새 Claude가 맥락 로딩을 처음부터 다시 하는 걸 기다릴 필요 없음

    • 이 과정이 프로그래머용 점성술(astrogy) 같다는 느낌이 듦, 말하지 않으면 에이전트가 코드베이스 작업을 하면서 어떤 일이 벌어질지 알 수 없음

    • 흥미로운 점은, 코드를 다른 개발자가 쓴 것처럼 말할 때 Claude가 문제를 더 많이 찾는 이유가 궁금함

  • 지금까지 Claude Code에서 가장 도움이 됐던 활용법은 "현재 diff에 버그가 있나?"라고 직접 묻는 것임, 그러면 챗봇이 변경 사항을 꼼꼼히 분석해 오랜 시간과 수많은 배포 과정이 필요한 미묘한 버그를 빠르게 잡아주고, 코드의 정확성을 높이기 위한 다양한 점을 조목조목 알려줌

    • ‘생각을 더 깊게 해달라’고 따로 주문하지 않아도 원하는 대로 잘 동작한다는 점이 신기함

    • 코딩이 아닌 작업에서도 사용한 경험상 창의성은 부족하지만 비평적이고 꼼꼼한 리더 능력은 뛰어남

    • 이 기능을 Claude Code의 hook으로 구체적으로 구현하면 좋겠다는 제안도 있음

    • 본인도 바로 내일부터 이 방식을 시도해보기로 함

  • 현재 도구에 대한 내 경험은 다음과 같음

    1. 새로운 언어나 프레임워크, 유틸리티, 또는 그린필드 프로젝트를 시작할 땐 큰 도움이 됨, 다만 그 후 코드 파싱하며 과연 믿어도 될지를 고민하지만 어차피 직접 해석하기 귀찮으니 그냥 ‘동작하니까’ 믿어보곤 함
    2. 이미 잘 아는 언어나 프레임워크에서는 오히려 생산성이 떨어짐, 프롬프트에 적합한 컨텍스트를 작성하는 데 드는 시간과 직접 작성하는 시간이 비슷하거나 더 소모됨, 특정 상황엔 동작하지만 뭔가 주니어가 짠 느낌의 애매한 코드가 나오기 쉬움, 경험 없는 이는 문제를 바로 발견하지 못할 수 있음 Typescript, Kotlin, Java, C++로 웹사이트, ESPHome 컴포넌트, 백엔드 API, 노드 스크립트 등 다양한 환경에 써봄, 결론은 취미, 스크립트, 프로토타입엔 좋지만 엔터프라이즈급 코드엔 아직 부족함

    • 나도 비슷했음 (Cline + Sonnet & Gemini 1년) 그러다 Claude Code를 만나고, 무엇보다도 ‘컨텍스트를 정말 깔끔하게 관리하는 법’을 익힌 후 진짜 돌파구를 느낌, AI를 코드 생성기가 아니라 아키텍트 및 구현자처럼 대하는 게 관건임, 최근엔 항상 먼저 CC에게 우리가 하려는 작업의 디자인 문서를 작성시키고, 그가 코드와 문서를 참고하도록 지시함, 내가 그걸 검토하면서 원하는 방향을 명확히 확인한 후, 작업 단계를 chunk로 나누고, 각 chunk도 세분화함, 초기 정의가 끝나면 문맥을 지우고, 단계별로 문서 읽게 한 뒤 구현하게 함, 필요하면 수정 방향을 잡거나, 문서를 고쳐서 그 단계만 다시 시작함, 각 단계별로 커밋, 문맥 클리어, 다음 단계로, 이런 식으로 하면 예전엔 2-3일 걸리던 기능을 하루 안에 만들 수 있음, 결과적으로 검증된 문서, 유닛 테스트, 스토리북, 접근성(arai 등) 등 잘 챙긴 결과물을 얻게 됨, 마지막엔 다른 모델로 코드리뷰도 받음, 비록 당장은 압도적 속도를 찍진 못해도 성장하는 툴에 대비해 실력의 미래 투자라고 생각함

    • 내 생각엔 이 툴은 예전 Ruby on Rails의 ‘rails new’ scaffolding과 비슷한 감각임, LLM은 도구의 공식 문서만 잘 파악하면 되는 영역, 즉 프로젝트 초기 뼈대 만들기엔 딱임, 반면 레거시 시스템이나 외부 요구사항 많은 프로젝트엔 덜 유용함, Databricks처럼 빠르게 변하는 툴에 대해선 거의 쓸모 없음, 트레이닝 데이터 이후 이름/문법/기능이 변했다면 실시간 문서를 프롬프트에 적극 활용해야만 겨우 가능성이라도 생김

    • 내 워크플로우는 Claude 데스크탑과 mcp 서버의 파일시스템을 함께 씀, 관련 파일 경로를 Claude에 알려주고, 태스크를 해결하라고 명령함, Claude가 직접 파일을 읽고 분석해서 필요한 수정/추가를 해줌, 보통 몇 가지 빌드 에러만 내가 붙여넣으면 다시 고쳐줌, 코드 스타일을 그대로 유지하면서 새 코드를 작성해주는 점도 인상적임, Typescript와 C#에서 써봄, 내 경험상 결과물이 취미용 수준에 그치지 않음

    • 나는 프로그래머가 아니지만 파이썬, bash 코드를 필요로 하는 일을 함, 개인 프로젝트와 웹사이트도 몇 개 운영 중임, Claude Code 덕분에 예전엔 능력 부족과 시간 탓에 못하던 작은 프로젝트를 구현하게 됐음, 이젠 emacs 환경도 직접 개선 가능함, lisp 함수도 척척 만들어줌, 이건 내게 완벽한 툴임, 이제 막혔던 일을 척척 해결해주고 삶이 편해짐

    • Typescript, Go, SQL, Rust에서 써봄, Rust는 너무 복잡해서 에러 투성이였고, 빨리 프로젝트 끝내고 싶음(하지만 프로젝트 자체가 워낙 어려움), Go는 언어가 너무 심플해서 굉장히 생산적임, 속도 2배, Typescript는 리액트 컴포넌트/애니메이션에 무난, SQL/PostgreSQL도 마찬가지, 저장함수의 보일러플레이트가 싫은데 LLM이 그걸 줄여줘서 손목 아픔을 덜 수 있음

  • 이렇게 옵션이 많아지는 건 확실히 좋지만, 동시에 많은 컨텍스트를 집어넣으면 LLM 결과 품질이 떨어질 수 있음, LLM이 산만해지기 쉬워지기 때문임, 사용자가 이 트레이드오프를 이해하지 못하고 자동모드에만 의존하면 Claude Code로 써낸 코드의 품질이 걱정됨

    • 참고할 만한 글 링크 몇 개를 제시함

    • 현재까지 긴 컨텍스트가 Claude Code에 통합되어 있진 않음, “다른 제품에도 긴 컨텍스트를 적용하는 방안을 검토 중”이라고 함, 이미 이걸 문제로 인식하고 해결 방법을 고민하고 있을 것이라 생각함, 이용자들이 비싼 요금제에서 추가 비용을 발생시키기 전에 솔루션을 내놓으려는 듯함

    • 대안으로 뭘 추천하는지 궁금하다고 질문함, Claude Code에 익숙해지고는 있지만 아직 베스트 프랙티스엔 서툼

    • Chroma 팀에서 이 문제를 연구 중이고 수치 자료가 나올 예정임

  • Opus가 더 낫지 않냐고 묻고, 토큰이 떨어져 Sonnet으로 강제 전환될 때 큰 차이를 느낌, 경력도 쌓였고, 아이디어는 넘치지만 코딩은 힘들었던 입장에서 Claude 등장 이후 아이디어 구현과 테스팅/버그 수정 모두 날아다니는 중이라고 함

    • 하지만 계속 Claude Code에만 의존하다 보면 실제 내 개발 실력이 퇴화할까 걱정하는 마음도 듦

  • 챗앱(ChatGPT, Claude.ai)의 큰 문제는 컨텍스트 윈도우 관련 이상 동작(갑작스런 잘림, 요약, ‘유령 스니펫’ 재삽입 등)임, 사용자가 계속 컨텍스트를 유지할지, 새 채팅을 시작할지 직접 선택하는 게 편할 것 같지만, 현실적으로 요금제와 컴퓨팅 제한 때문에 어쩔 수 없음, 실제로 개발자 도구(Google AI Studio)나 API랩핑한 챗앱을 써야 전 컨텍스트를 완전하게 보낼 수 있음, custom 챗앱을 만들면 메시지마다 타임스탬프를 삽입해서 “10분마다 Markdown 테이블의 새로운 행에 그 시간대 내용을 요약”하도록 LLM에 지시할 수도 있음

    • 시간 배열 대신 “메시지 단위”로, 예를 들면 “10번째 메시지마다 blah-blah.md로 요약”하는 게 낫지 않냐는 제안도 있음

  • 이번 요금제는 토큰 수가 늘어날수록 비용이 ‘제곱’처럼 뛴다는 점을 처음으로 인정한 케이스라고 생각함, LLM 공급자가 처음으로 비선형 요금 구조를 반영한 것으로 보임, 이 방식은 우리가 이미 아는 인퍼런스 스케일링 법칙을 닮아 있음

  • 관련 주제의 토론도 안내함

  • 이 기능은 멋지지만, 추론 속도를 개선할 방법이 무엇일지 궁금함, 개인적으로 200K 컨텍스트면 충분한데 응답 속도가 빨랐으면 좋겠음, 많은 이들이 컨텍스트 크기가 작더라도 에이전트가 훨씬 빠르게 작업한다면 만족할 것이라고 생각함(현재는 프롬프트당 2-3분 대기임)

답변달기