당신의 AI SRE는 하나의 모델이 필요하지 않습니다 — 각 작업에 맞는 올바른 모델이 필요합니다
Source: Dev.to
소개
우리는 단일 모델인 Opus for everything— 사고 트리아지, Kubernetes 디버깅, IAM 정책 검토, 비용 이상 탐지— 로 첫 AI SRE 통합을 구축했습니다. 가장 좋은 모델을 사용하고 과도하게 고민하지 않는 것이 목표였습니다.
3개월이 지나면서 비용이 현실이 되었습니다. 솔직히 말해서, 대부분의 작업은 Opus 수준의 추론을 필요로 하지 않았습니다. CrashLoopBackOff 상태에 있는 파드를 확인하는 일은 복잡한 교차 계정 IAM 정책 신뢰 관계를 파싱하는 것과 같은 인지 부하를 요구하지 않습니다.
Rootly가 이번 주에 벤치마크 결과를 발표했으며, 이는 우리 대부분이 가지고 있던 직감에 실제 수치를 부여했습니다. AI SRE 도구를 구축하고 있든, 곧 구축하려고 하든, 이 결과는 충분히 검토할 가치가 있습니다.
What the Benchmarks Found
Rootly ran Claude Sonnet 4.6 and Opus across four infrastructure task types:
| 작업 유형 | 테스트된 모델 |
|---|---|
| Kubernetes 디버깅 | Sonnet 4.6, Opus |
| 컴퓨트 이상 감지 | Sonnet 4.6, Opus |
| IAM / S3 정책 검토 | Sonnet 4.6, Opus |
| 일반 인프라 작업 | Sonnet 4.6, Opus |
핵심 요점: Sonnet 4.6은 Kubernetes와 컴퓨트 작업에서 Opus와 비슷한 성능을 보입니다. 복잡한 IAM 및 정책 추론에서는 차이가 벌어지며, 이 부분에서 Opus가 눈에 띄게 앞서 있습니다.
왜 이런 결과가 나왔는가
- K8s 디버깅은 주로 패턴 매칭과 로그 해석(
OOMKilled,CrashLoopBackOff등)으로 이루어집니다. 모델은 알려진 패턴을 인식하고 알려진 해결책을 제시하면 되므로, 작고 빠른 모델이 충분히 잘 처리합니다. - IAM은 다릅니다. 계정 간 신뢰 정책, 조건 키, 권한 경계와 상호 작용하는 SCP, AssumeRole 체인 등은 깊은 의존성 추론을 필요로 합니다. 한 번의 잘못된 추론이 전체 계정의 보안 태세를 바꿀 수 있기 때문에, 더 높은 추론 능력이 중요합니다.
Source: …
실제 모델 라우팅 예시
멋진 프레임워크가 없어도 시작할 수 있습니다. 가장 간단한 형태는 작업 유형 → 모델을 매핑하는 라우팅 함수이며, 이는 진입점에서 수행됩니다:
# Mapping of task types to the model that should handle them
TASK_MODEL_MAP = {
"k8s_debug": "claude-sonnet-4-6",
"compute_anomaly": "claude-sonnet-4-6",
"cost_analysis": "claude-sonnet-4-6",
"iam_policy_review": "claude-opus-4-6",
"security_audit": "claude-opus-4-6",
"incident_triage": "claude-sonnet-4-6", # fast first pass
"incident_rca": "claude-opus-4-6", # deep analysis on escalation
}
def route_task(task_type: str, payload: dict) -> str:
"""
Choose the appropriate model based on task_type and invoke the LLM.
"""
model = TASK_MODEL_MAP.get(task_type, "claude-sonnet-4-6")
return call_llm(model, payload)작업 유형은 알림 메타데이터, PagerDuty 서비스 이름, 혹은 가벼운 사전 라우팅 호출을 통해 진입점에서 분류하고, 그에 맞게 라우팅합니다.
사고에 대한 2단계 라우팅
- 빠른 1차 트리아지 (Sonnet): “P1인가? 가능한 원인은 무엇인가?”
- 깊이 있는 RCA (Opus): 사고가 15분을 초과하거나 초기 평가가 불확실할 경우 트리거됩니다.
대부분의 사고는 두 번째 단계를 거치지 않으므로 비용을 절감하면서도 필요할 때는 깊이 있는 분석을 제공할 수 있습니다.
비용 계산
Anthropic의 현재 가격 기준으로 Opus는 출력 토큰당 Sonnet보다 대략 3–5× 비용이 듭니다.
- 시나리오: 모든 작업을 Opus로 처리하는 200건/일 알림.
- **70 %**를 Sonnet으로 라우팅(예측 가능한 K8s 및 컴퓨팅 작업)하면 월간 LLM 지출의 **60–70 %**를 품질을 희생하지 않고 절감할 수 있습니다.
규모가 커질수록 — 20개의 서비스에서 하루 500건 이상의 알림을 처리하는 플랫폼 팀 — 의미 있는 감소 효과가 있습니다. 이 원칙은 고전적인 FinOps와 동일하게 워크로드에 맞게 자원을 최적화하는 것입니다.
팀이 이것을 시작할 때 흔히 저지르는 실수
| 함정 | 왜 중요한가 | 빠른 해결책 |
|---|---|---|
| 라우팅 신뢰도 | 보안 관련 작업을 잘못 분류하면 비용이 크게 발생할 수 있습니다. | 분류기가 확신이 없을 때는 Opus를 기본으로 사용하세요. |
| 캐시 생략 | 저렴한 모델을 사용하더라도 반복되는 컨텍스트가 토큰 사용량을 늘립니다. | 시스템 프롬프트와 안정적인 사용자 메시지 부분을 캐시하면 → 40–60 % 토큰 절감. |
| 관측성 부족 | 모델별·작업별 메트릭이 없으면 비용 급증 원인을 파악할 수 없습니다. | Prometheus 카운터 추가: llm_requests_total{model="claude-sonnet-4-6", task_type="k8s_debug"} llm_requests_total{model="claude-opus-4-6", task_type="iam_policy_review"} |
몇 분 정도의 계측 작업으로 청구서가 도착했을 때의 혼란을 몇 시간 단축할 수 있습니다.
내가 다르게 할 일
- Day 0부터 작업 유형과 모델을 기록 — 라우팅 로직을 만들기 전에도.
- 한 달 동안 단일 모델을 실행, 모든 요청에 작업 유형을 태그.
- 월말까지 작업 분포에 대한 실제 데이터를 얻게 됩니다 (예: % K8s 디버깅 vs. IAM 작업).
- 긴 꼬리 추론 작업이 실제로 어디에 나타나는지 알 수 있습니다.
- 직관이 아니라 데이터로 라우터를 구축.
우리는 새로운 알림 유형이 등장함에 따라 분류 작업을 계속 반복하고 있으며, 라우팅이 완벽하다고 주장하지도 않습니다. 하지만 처음부터 가시성을 확보하면 개선이 훨씬 쉬워집니다.
스니펫과 아이디어를 자신의 스택에 맞게 자유롭게 적용하세요. 핵심은 간단합니다: 올바른 모델을 올바른 작업에 매칭하면 신뢰성을 손상시키지 않으면서 비용을 절감할 수 있습니다.
어디에 적용되는가
이는 LLMOps가 실제 분야로 자리 잡기 시작한 단계입니다. 현재 대부분의 팀은 “모델을 골라서 어디든 사용한다”는 상황에 있으며—실험에는 괜찮고, 솔직히 소규모라면 괜찮습니다. 하지만 AI SRE가 파일럿 단계에서 프로덕션 단계로 넘어가면서 운영상의 고민이 나타납니다: 비용, 신뢰성, 지연 시간, 작업 유형별 품질 등.
LLM 인프라를 컴퓨팅 인프라처럼 다루는 팀—비용 가시성, 적정 규모 조정, 가시성 확보—은 아직도 포드 재시작을 분류하기 위해 Opus 요금을 내는 팀보다 의미 있는 경쟁 우위를 가질 것입니다.
Rootly의 벤치마크는 하나의 데이터 포인트일 뿐입니다. 여러분의 프로덕션 데이터가 더 좋은 데이터입니다. 데이터 수집을 시작하세요.
AI SRE 도구를 구축하면서 모델 라우팅이나 작업 분류에서 흥미로운 엣지 케이스를 발견한다면, 연락 주세요—다른 팀이 어떤 패턴을 찾고 있는지 정말 궁금합니다.