Claude Code의 모델, 사용법 및 제한사항

이 가이드는 사용 중인 모델, 사용량 측정 방식, 그리고 긴 세션을 컨텍스트 및 사용량 제한 범위 내에서 유지하는 방법을 설명합니다.

로그인 방식에 따라 사용량이 측정됩니다. Claude Code의 다른 모든 기능은 이와 관계없이 동일하게 작동합니다.

Enterprise 시트로 로그인한 경우, 일반적으로 한도에 도달할 때까지 토큰에 대해 생각할 필요가 없습니다. API 키를 사용하는 경우, /cost 명령어는 현재 세션의 실행 비용을 표시합니다.

언제든지 /model을 실행하여 계정에서 사용 가능한 모델을 확인하고 모델 간에 전환할 수 있습니다. 대략적인 가이드는 다음과 같습니다:

세션 중간에 모델을 변경할 수 있으며 대화를 잃지 않습니다. 일반적인 패턴은 Opus로 계획하고 Sonnet으로 실행하는 것입니다.

매 턴마다 모델에 세 가지를 전송합니다:

이 중에서 첫 번째 항목이 가장 빠르게 증가합니다. Claude가 20개 파일을 읽고 15개의 diff를 생성한 긴 디버깅 세션은 이후의 모든 메시지에서 이 모든 것을 전달합니다. 이것이 비용과 컨텍스트 제한의 출처입니다.

컨텍스트 윈도우는 모델이 한 번에 고려할 수 있는 최대 텍스트 양입니다. Claude Code는 얼마나 찼는지 실시간 표시기를 보여줍니다. 가득 차면 Claude는 더 이상 대화의 가장 오래된 부분을 명확하게 볼 수 없으며 품질이 저하됩니다.

두 가지 명령어가 이를 제어합니다:

경험 법칙: 새 작업을 시작할 때는 /clear를 사용하고, 긴 작업을 계속할 때는 /compact를 사용하세요.

거의 모든 "점심시간까지 한도를 다 써버렸다"는 보고는 이 5가지 중 하나로 거슬러 올라갑니다.

모든 이전 메시지는 매 턴마다 다시 전송되므로, 3개의 관련 없는 문제를 거쳐온 세션은 각 새 메시지에서 3개 모두에 대해 비용을 지불합니다.

실제로: 로그인 리다이렉트 디버깅을 방금 완료했고 이제 데이터베이스 마이그레이션을 작성하려고 합니다. 먼저 /clear를 실행하세요. 간단한 테스트: 다음 프롬프트가 새로운 터미널에서 완벽하게 이해가 된다면, 전송하기 전에 정리하세요. CLAUDE.md와 프로젝트 파일은 그대로 유지되며, 채팅 기록만 삭제됩니다.

한 가지 경고: /clear는 실행 취소할 수 없습니다. 기록에서 뭔가 필요할 수도 있다면, 먼저 복사하거나 /compact를 대신 실행하세요. 이는 모든 것을 지우는 대신 요약을 보존합니다.

Opus는 턴당 Sonnet보다 몇 배 더 비싸고, Sonnet은 Haiku보다 더 비쌉니다. 일상적인 작업에 Opus를 사용하는 것은 일일 한도를 소진하는 가장 빠른 방법입니다.

합리적인 기본값: 대부분의 코딩(기능, 테스트, 알려진 버그, 리팩토링)에는 Sonnet; 정말 막혔거나 변경이 광범위할 때(어려운 디버깅, 교차 리팩토링, 아키텍처 결정)에는 Opus; 빠른 기계적 작업(이름 바꾸기, 로그 라인, 정규식 설명, 보일러플레이트)에는 Haiku.

붙여넣은 모든 것은 세션의 나머지 동안 컨텍스트에 전체적으로 남아 있습니다. 경로로 파일을 참조하면 Claude가 선택적으로 읽고 관심 있는 부분에 집중할 수 있습니다.

실제로: auth.ts를 붙여넣는 대신, src/auth.ts의 validateToken 함수를 살펴보세요라고 작성하세요 — 경로를 언급하면 Claude가 선택적으로 열고 읽을 수 있습니다. (@ 접두사는 전체 파일과 CLAUDE.md 트리를 컨텍스트에 주입하므로, 토큰을 절약하려고 할 때는 경로 없이 사용하세요.) 로그 및 스택 추적의 경우, 붙여넣기 전에 관련된 20~30줄로 자르세요. 큰 파일(lockfile, 빌드 로그, 데이터 덤프)의 경우, 디스크에 저장하고 경로를 참조하세요.

이 파일은 모든 턴에 앞에 붙습니다. 프롬프트 캐싱은 첫 번째 이후의 턴이 훨씬 저렴한 캐시 읽기 요금으로 청구되므로 달러 비용은 원시 라인 수보다 낮지만, 여전히 모든 메시지에서 컨텍스트 윈도우 공간을 차지합니다.

규칙: 2회 경고, 간결하게 유지하세요. 같은 것에 대해 Claude를 수정해야 하는 두 번째 경우에만 메모를 추가하세요(첫 번째 문제는 보통 일회성입니다). 파일을 대략 200줄 이하로 유지하세요. 새로운 것이 들어가야 하는데 공간이 없으면, 오래된 것이 나가야 합니다.

업데이트 시기: Claude를 같은 것에 대해 두 번 수정해야 했던 세션 직후입니다. 그때가 수정이 신선하고 작성하는 데 1분이 걸릴 때입니다. 몇 주마다 전체 파일을 읽고 더 이상 참이 아니거나 목적을 기억할 수 없는 것을 삭제하세요. 오래된 메모는 누락된 메모보다 나쁩니다. 왜냐하면 Claude를 적극적으로 잘못 인도하기 때문입니다.

계획은 몇 백 개의 토큰이 소요됩니다. 잘못된 400줄 diff를 되돌리고 다시 생성하는 데는 수천 개가 소요되며, 두 배로 더하기 무엇이 잘못되었는지 설명하는 데 소요되는 턴입니다. 실제로: 2~3개 이상의 파일을 건드리는 모든 것에 대해 Plan Mode로 전환하거나 단순히 다음을 요청하세요: "변경하기 전에 건드릴 파일과 각 파일에서 할 작업을 나열하세요." 목록을 읽고 일반 영어로 수정하세요("legacy/를 건너뛰고 아직 테스트를 건드리지 마세요"), 그 다음 실행하도록 하세요.

전문가 팁: Opus로 계획하고 Sonnet으로 실행하세요. Opus의 가장 높은 가치 사용은 계획 자체를 작성하는 것입니다. 여기서 더 깊은 추론이 실제로 효과를 발휘합니다. 좋은 계획이 존재하면, 실행은 대부분 기계적이며 Sonnet은 비용의 일부로 처리합니다. 이 패턴은 /model opusplan으로 내장되어 있으며, 계획할 때는 Opus를 사용하고 실행할 때는 Sonnet을 사용합니다. 모델을 전환해도 대화가 지워지지 않으므로 Sonnet은 여전히 Opus가 생성한 모든 것을 봅니다.