상상해 보세요: 지난주에 당신은 Opus 4.8을 사용하여 이름 변경 및 와이어업 (rename-and-wire-up) 작업을 맡겼습니다. 당연히 이 작업은 완벽하게 수행되었습니다. 하지만 당신은 필요한 것보다 대략 5배나 더 많은 비용을 지불했습니다. 당신의 기본 모델은 현재 사용 가능한 모델들에 비해 과도하게 강력합니다. 식료품을 사러 가는데 페라리를 타고 가는 격입니다.

6월 30일, Anthropic은 Opus 4.8만큼이나 뛰어나지만 훨씬 저렴한 Claude Sonnet 5를 출시했습니다. 그들은 또한 Claude Code의 Free 및 Pro 플랜에서 이를 기본 모델로 설정했습니다 (해당 플랜을 사용 중이라면 이 이슈는 당신에게 큰 의미가 없을 것입니다. 몇 분을 아끼기 위해 그냥 넘어가셔도 좋습니다).

만약 당신이 유료 API를 사용 중이거나, 정도는 덜하지만 Max 플랜을 사용 중이라면, 이 내용은 당신에게 흥미로울 것이며 아마 놓쳤을 수도 있습니다.

당신의 프롬프트가 호출할 모델을 선택하는 시스템이 필요합니다.

당신이 보지 못하는 사이에 실무형 계층이 성장했습니다

Anthropic의 자체 측정 결과에 따르면, Sonnet 5는 모든 면에서 Opus 4.8만큼이나 뛰어납니다:

벤치마크 (Benchmark)	Sonnet 5	Opus 4.8
에이전트 코딩 (Agentic coding) (SWE-bench Pro)	63.2%	69.2%
...
출처: Anthropic

단 하나의 중요한 지표를 제외하고는 말이죠: 바로 가격입니다. Sonnet 5는 Mtok당 $2/$10인 반면, Opus는 $5/$25입니다.

다시 말해, 당신이 추가로 지불하고 있는 격차가 매우 좁아졌습니다. 이제 Sonnet 5와 Opus 4.8 사이에는 큰 차이가 없습니다.

"그냥 가장 좋은 모델을 사용하라"는 말은 더 이상 합리적이지 않습니다

지금까지 당신은 이틀마다 모델을 벤치마킹하는 것은 비효율적이며, 하나의 모델을 선택하고 결과물에 집중함으로써 훨씬 더 빠르게 움직일 수 있다고 결정했을 것입니다. 그것은 어리석은 접근 방식은 아닙니다.

하지만 규모가 커지면 이 방식은 수백만 달러의 비용을 발생시킬 것입니다. 습관적으로 최첨단 모델 (frontier model)에 보내는 모든 작업은 이제 'Opus 세금'을 지불하고 있는 셈입니다.

이제 조금 더 선택적으로 접근해야 할 때입니다. HN consensus에 따르면, Opus 4.8은 여전히 높은 노력이 필요한 작업에서 승리합니다 (그 분야에서는 오히려 더 비용 효율적일 수도 있습니다). 모델 선택은 더 이상 사소한 결벽증의 문제가 아닙니다. 그것은 자원 할당 (resource allocation)의 문제입니다. 서버를 산정하듯 모델의 규모를 정해야 합니다.

인프라를 산정하듯 작업을 라우팅(Route)하세요

우리는 모델 선택을 위해 각 축이 1~3점을 부여하는 4축 휴리스틱 (four-axis heuristic)을 사용합니다:

축	기준 (1 / 2 / 3)
범위 (Scope)	단일 파일 / 다중 파일 / 교차 기능 (Cross-cutting)
...

이 점수를 바탕으로 작업을 분류하면 다음과 같습니다 (Claude Code 모델의 맥락에서):

점수	모델 계층 (Model tier)
4-6	Haiku
...

또한, 위험 (risk) 점수가 3점인 경우 자동으로 한 단계 높은 계층으로 격상됩니다.

실제 사례를 들어보겠습니다. 이번 주 Temrel에서 우리는 Maitris 백엔드에 관리자 전용 새 양식을 추가하는 작업을 맡았습니다. 비교적 간단한 작업이었습니다. 우리의 결정은 다음과 같았습니다:

축	점수	근거
범위 (Scope)	2	교차 기능 없음
...

여기서 격상 규칙(bump rule)은 발동되지 않았음에 주목하십시오. 만약 동일한 양식이 운영 데이터에 대한 파괴적인 마이그레이션 (destructive migration)을 필요로 했다면, 위험 (Risk) 점수가 3점이 되어 총점과 상관없이 전체 작업이 한 단계 격상되었을 것입니다.

'과하게 생각한다'는 불만은 위장된 컨텍스트 교훈입니다

Sonnet 5는 작은 작업에 대해 과하게 생각합니다 (over-thinks). 더 오래 생각하고, 더 많은 토큰 (tokens)을 사용하며, 일반적으로 요청되었거나 필요한 것보다 더 많은 작업을 수행합니다. 이를 총체적으로 보면, 생산성과 비용 효율성을 크게 갉아먹게 될 것입니다.

교훈은 우리가 모델을 체계적으로 더 선택적으로 사용해야 한다는 것입니다. 프롬프트 실행 전에 작업의 범위를 정하는 것 (Scoping tasks)은 비용 제어의 일부이며, 따라서 컨텍스트 엔지니어링 (context engineering)의 일부입니다.

이제 노력 (Effort)은 언어로 설정되는 하나의 파라미터 (parameter)입니다.

temrel-agentic-toolkit: 스스로를 감사(audit)하세요

이번 주의 무료 Temrel 도구는 model-router입니다. 위에서 언급한 4축 휴리스틱 (four-axis heuristic)을 Claude Code 스킬로 구현하였으며, 로컬 Claude Code 트랜스크립트 (transcript)를 분석하여 모델별 실제 작업당 비용 (cost-per-task)을 보고하는 CLI (Command Line Interface)를 제공합니다.

감사 (audit) 기능은 Sonnet의 프로필로 충분히 처리 가능한 작업에 Opus 가격을 지불한 지점을 찾아내고, 총 초과 지출액을 추정합니다. 본인의 기기에서 실행하여 지난 30일간의 데이터를 확인해 보세요.

주의 사항: 정확한 달러 금액은 사용자가 직접 확인해야 하는 가격 파일 (pricing file)에 따라 달라지며, Claude Code의 30일 이동 트랜스크립트 창 (30-day rolling transcript window)으로 인해 확인할 수 있는 과거 기간에 제한이 있습니다.

오늘 바로 실행해 보세요

1. 모델을 선택하기 전에 다음 세 가지 작업에 대해 4개 축을 기준으로 점수를 매기세요.
2. 7~9점 사이의 점수가 나온 작업은 Sonnet 5로 보내고, 결과물을 블라인드 테스트 (blind test) 하세요.
3. model-router를 설치하고 model-router audit --since 30을 실행하세요. 초과 지출 금액을 확인하세요.
4. 다음 프롬프트에 작업 범위 설정 (task scoping) 문구(예: "이것은 작은 단일 파일 변경 사항입니다")를 한 문장 추가하고 토큰 (token) 수를 관찰하세요.

이것이 중요한 이유

모델 라우팅 (Model routing)은 인스턴스 크기 조정 (instance sizing)과 마찬가지로 기본적이고 필수적인 기술이 될 것입니다. 에이전트 (agents)가 늘어남에 따라, 작업당 할당 (per-task allocation)은 속도와 비용 모두에서 빠르게 복리로 작용합니다.

에이전틱 엔지니어 (agentic engineer)로서 당신의 직무 기술서에는 한 줄이 더 추가되었습니다. 이제 자원 할당 (resource allocation) 또한 기술의 일부입니다.