Claude 3.7 Sonnet의 확장 사고는 모든 질문에 켜는 기능이 아니라, 여러 조건을 비교하거나 코드 변경을 계획하는 복잡한 작업에 더 많은 사고 예산을 줄 때 선택하는 모드입니다.
이 글은 Claude 3.7 Sonnet과 Claude Code가 소개된 2025년 2월 당시 정보를 기준으로 합니다.
확장 사고를 오래 사용한다고 모든 질문이 더 정확해지는 것은 아닙니다. 문제 난도에 따라 사고 예산을 달리하고, 최종 답뿐 아니라 지연, token, 도구 실행 결과를 같은 업무 세트에서 비교해야 합니다.
Claude 3.7 Sonnet은 한 모델에서 빠른 표준 응답과 더 오래 추론하는 확장 사고를 선택하는 하이브리드 방식을 내세웠습니다. API 사용자는 사고에 쓸 토큰 예산을 조절해 속도와 작업 깊이 사이의 균형을 정할 수 있다고 소개됐습니다.
| 상황 | 먼저 선택할 모드 | 이유 |
|---|---|---|
| 문서 요약, 간단한 질의응답 | 표준 | 답의 조건이 적고 빠른 반복이 중요함 |
| 수학, 논리 문제 | 확장 사고 | 중간 조건과 검산 단계가 많음 |
| 여러 파일에 걸친 코드 변경 | 확장 사고 | 영향 범위와 테스트 계획을 함께 봐야 함 |
| 짧은 문구 수정 | 표준 | 긴 추론이 결과를 반드시 개선하지 않음 |
확장 사고는 오류를 없애는 스위치가 아닙니다. 시간이 더 필요한 작업에 계산 예산을 배분하는 선택이므로, 결과의 사실성과 코드 실행 여부는 모드와 별개로 확인해야 합니다.
Claude Code는 코드 검색과 편집, 테스트 실행, 터미널 명령, 저장소 작업을 수행하는 연구 프리뷰로 함께 공개됐습니다.
“로그인 기능을 추가해 줘”처럼 넓게 맡기면 요구사항 해석부터 여러 파일 수정까지 한꺼번에 진행될 수 있습니다. 실제 작업에서는 범위를 작게 쪼개고 다음 결과를 직접 보는 편이 안전합니다.
코드를 만들었다는 응답, 테스트를 통과했다는 설명, GitHub 작업을 완료했다는 문장은 실제 diff, 로그, 원격 상태를 대신하지 못합니다.
발표 당시 API 가격은 입력 100만 토큰당 3달러, 출력 100만 토큰당 15달러로 소개됐습니다. Claude.ai뿐 아니라 Anthropic API, Amazon Bedrock, Google Cloud Vertex AI를 통한 접근도 안내됐습니다. 가격과 제공 플랜은 바뀔 수 있으므로 이 숫자는 현재 견적이 아니라 당시 스냅샷으로 봐야 합니다.
또한 Python 딕셔너리에 프롬프트 해시와 응답을 저장하는 코드는 같은 프로세스에서 완전히 동일한 요청의 결과를 재사용하는 로컬 응답 캐시일 뿐, 모델 제공사의 프롬프트 캐싱 기능과 같지 않습니다. 프로세스가 끝나면 사라지고, 입력이 조금만 달라도 다시 요청하며, 최신 답이 필요한 질문에는 오래된 응답을 돌려줄 수 있습니다.
이 글에 있던 API 조각은 정확한 확장 사고 파라미터와 SDK 계약을 검증한 완전 실행 예제가 아니므로 그대로 실행법으로 제시하지 않습니다. Claude 3.7 Sonnet을 선택할 때는 “가장 똑똑한 모델”이라는 순위보다, 표준 모드로 충분한 일과 확장 사고가 필요한 일을 나누고 코드 작업의 변경 내역을 검수할 수 있는지가 더 중요한 기준입니다.
문서 형식 변환이나 명확한 코드 수정처럼 경로가 짧은 일은 일반 응답으로 먼저 시험합니다. 여러 file의 원인을 추적하거나 제약이 많은 설계 문제는 확장 사고가 도움이 될 수 있습니다. 모든 요청에 긴 사고를 켜면 쉬운 작업의 비용과 대기 시간만 늘 수 있으므로 난도 분류와 fallback 규칙이 필요합니다.
같은 문제를 두 모드에 주고 정답 여부, 첫 응답 시간, 총 token, 수정 후 test 통과율을 기록합니다. 답이 길어진 것과 해결 품질이 높아진 것을 구분해야 합니다. 확장 사고가 올바른 분석을 했어도 잘못된 tool을 실행하거나 file 범위를 넘겼다면 agent 작업은 실패입니다.
벤치마크 patch는 정해진 test로 채점되지만 자사 저장소에는 숨은 요구와 운영 규칙이 있습니다. 대표 issue를 bug fix, refactor, test 작성, 문서 변경으로 나누고 동일한 권한과 시간 제한에서 비교해야 합니다. test 통과뿐 아니라 변경 line 수, 불필요한 dependency, 기존 API 호환성을 review합니다.
도구 사용이 가능한 환경에서는 읽기, 수정, 명령 실행 권한을 구분합니다. 첫 시험은 sandbox branch와 읽기 전용 secret로 진행하고, network, 배포, 삭제는 허용하지 않습니다. 모델이 완료했다고 말해도 실제 working tree의 diff와 test log가 기준입니다.
이 글의 가격, 기능, 접근 범위는 발표 당시 snapshot일 수 있습니다. 선택 전에 현재 공식 안내에서 model ID, context, rate limit과 data 정책을 확인해야 합니다. 그러나 최신 정보가 달라져도 비교 원칙은 같습니다. 정확도와 지연, 총 token, tool 실패, 사람 검토 시간을 업무별로 재야 합니다.
Claude 3.7을 고르는 기준은 한 benchmark의 순위가 아니라 허용된 비용 안에서 복잡한 문제의 완료율이 실제로 높아지는지입니다. 확장 사고가 가치 있는 task와 일반 모드가 충분한 task를 분리하면 품질을 유지하면서 불필요한 비용을 줄일 수 있습니다.
확장 사고의 이득은 같은 문제를 표준 모드와 반복 실행해 정답률, 지연, 입력, 출력 비용을 함께 비교해야 보입니다. 쉬운 수정까지 항상 켜 두면 답은 달라지지 않은 채 응답 시간만 늘 수 있으므로 작업 유형별 사용 기준을 고정합니다.
초기 가정을 틀린 채 긴 분석을 이어 가거나, 같은 결론을 표현만 바꿔 반복하거나, tool 결과와 추론이 충돌해도 기존 계획을 고수할 수 있습니다. 따라서 중간 길이를 품질 신호로 쓰지 않고 각 tool 호출 뒤 관찰을 반영해 계획이 바뀌는지 확인합니다.
코딩 과제에서는 첫 patch 후 실패 test를 다시 읽고 수정하는 복구 loop가 중요합니다. 같은 명령을 반복하거나 test를 우회하면 중단하고 사람에게 넘깁니다. 문서, 분석 과제에서는 인용할 수 없는 주장을 제거하고 불확실성을 표시하게 해야 합니다.
비용 상한을 정할 때는 한 요청의 token뿐 아니라 재시도와 사람 review를 포함합니다. 확장 사고가 비싸도 복잡한 issue의 재작업을 줄인다면 가치가 있을 수 있고, 일반 모드와 완료율이 같다면 사용할 이유가 작습니다. 이 판단은 task 유형별 표로 남겨야 합니다.
팀 운영에서는 model이 만든 commit을 일반 개발자와 같은 review 규칙에 통과시킵니다. 작성 주체가 AI라는 이유로 더 느슨하거나 무조건 더 엄격한 기준을 쓰지 않고, 변경 위험도에 따라 reviewer와 test 범위를 정해야 결과를 공정하게 비교할 수 있습니다.
이 기록이 쌓여야 reasoning 예산을 경험이 아니라 실제 task 성과로 조정할 수 있습니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
