Files
ECC/docs/ko-KR/rules/performance.md
fd1b11cfc7 docs: refresh model-selection guidance to the Claude 5 families (#2723)
Model-routing guidance across the rules, skills, and harness-steering docs
still recommends Sonnet 4.6 / Opus 4.5-4.6 by name. Readers on the current
generation have to map those onto Sonnet 5 / Opus 5 themselves, and the
recommendation reads as pinned to a superseded generation.

Renames the recommended models in guidance tables and updates two pinned
model IDs in code samples:

- rules/steering guidance: .cursor, .kiro, and the seven translated
  performance.md copies (ja-JP, zh-CN, zh-TW, ko-KR, pt-BR, es, tr)
- skills/prompt-optimizer complexity-routing table (+ zh-CN copy)
- skills/cost-aware-llm-pipeline MODEL_SONNET constant (+ zh-CN, ja-JP)
- docs/examples project-guidelines template, which pinned the invalid ID
  claude-sonnet-4-5-20250514 (+ zh-TW, ja-JP copies)

Deliberately left alone:

- The "Pricing Reference (2025-2026)" table in cost-aware-llm-pipeline.
  Renaming those rows while keeping the existing per-token figures would
  assert Claude 5 pricing this change has not verified.
- Executable model config (.opencode/opencode.json, agent.yaml). Those pins
  change real agent behavior and belong in their own reviewed change.
- Historical and illustrative references: the-shortform-guide session
  transcripts, the ECC-PRO roadmap log entry, gan-style-harness's
  "Opus 4.5-class"/"Opus 4.6-class" capability tiers, and
  strategic-compact's deliberately generic "400k Opus 4.x" example.
- docs/ATLAS-CLOUD-GUIDE.md, which lists a third-party provider's catalog.

Documentation wording only; no behavioral change.

Co-authored-by: Phumchai Tanonsi <274848436+phumchai1515-prog@users.noreply.github.com>
2026-08-11 19:36:48 -04:00

1.8 KiB

성능 최적화

모델 선택 전략

Haiku 4.5 (Sonnet 능력의 90%, 3배 비용 절감):

  • 자주 호출되는 경량 에이전트
  • 페어 프로그래밍과 코드 생성
  • 멀티 에이전트 시스템의 워커 에이전트

Sonnet 5 (최고의 코딩 모델):

  • 주요 개발 작업
  • 멀티 에이전트 워크플로우 오케스트레이션
  • 복잡한 코딩 작업

Opus 5 (가장 깊은 추론):

  • 복잡한 아키텍처 의사결정
  • 최대 추론 요구사항
  • 리서치 및 분석 작업

컨텍스트 윈도우 관리

컨텍스트 윈도우의 마지막 20%에서는 다음을 피하세요:

  • 대규모 리팩토링
  • 여러 파일에 걸친 기능 구현
  • 복잡한 상호작용 디버깅

컨텍스트 민감도가 낮은 작업:

  • 단일 파일 수정
  • 독립적인 유틸리티 생성
  • 문서 업데이트
  • 단순한 버그 수정

확장 사고 + 계획 모드

확장 사고는 기본적으로 활성화되어 있으며, 내부 추론을 위해 최대 31,999 토큰을 예약합니다.

확장 사고 제어 방법:

  • 전환: Option+T (macOS) / Alt+T (Windows/Linux)
  • 설정: ~/.claude/settings.json에서 alwaysThinkingEnabled 설정
  • 예산 제한: export MAX_THINKING_TOKENS=10000 (bash) 또는 $env:MAX_THINKING_TOKENS = "10000" (PowerShell)
  • 상세 모드: Ctrl+O로 사고 출력 확인

깊은 추론이 필요한 복잡한 작업:

  1. 확장 사고가 활성화되어 있는지 확인 (기본 활성)
  2. 구조적 접근을 위해 계획 모드 활성화
  3. 철저한 분석을 위해 여러 라운드의 비판 수행
  4. 다양한 관점을 위해 역할 분리 서브에이전트 사용

빌드 문제 해결

빌드 실패 시:

  1. build-error-resolver 에이전트 사용
  2. 에러 메시지 분석
  3. 점진적으로 수정
  4. 각 수정 후 검증