코딩은 잘하는데, 운영도 잘할까?
CLI 코딩 에이전트(Claude Code, Gemini CLI, Codex CLI)의 코딩 실력을 재는 벤치마크는 이미 많습니다. SWE-bench, HumanEval, LiveCodeBench 같은 것들이 그렇습니다. 그런데 운영 현장에서 자주 마주치는 일은 사실 코딩이 아니라 장애 진단입니다. CrashLoopBackOff 상태로 죽어 있는 파드 앞에서 로그를 읽고, OOMKill의 원인이 메모리 부족인지 limit 설정 실수인지를 가려내고, 때로는 “이건 클러스터 밖 문제입니다"라고 정직하게 보고하는 능력 말이지요.
이번 벤치마크는 그 질문에 답하기 위해 만들었습니다. 3개 에이전트와 3개 모델 티어를 곱한 9개 조합을 같은 Kubernetes 클러스터, 같은 프롬프트, 콜드 스타트 조건에서 10개 장애 시나리오에 돌렸습니다. 결과 수치와 재현 방법은 GitHub 저장소에 두었고, 이 글에서는 어떤 결정을 왜 내렸는지, 어떤 발견이 흥미로웠는지를 풀어봅니다.
한눈에 보는 결과
차트로 요약하면 이렇습니다.
- 효율 티어 Sonnet 4.6(Ops 0.733)이 9개 중 1위입니다. 모든 플래그십 모델보다 점수가 높았습니다.
- 브랜드마다 성격이 갈립니다. Claude는 품질과 안전, Gemini는 효율, Codex는 둘 다 어중간한 자리에 있습니다.
- Lite 티어에서는 Haiku가 아니라 Gemini Flash-Lite가 1위(0.661 대 0.647)였습니다. 차이는 근소하지만 의미는 작지 않습니다.
상세 표와 모든 수치는 README 결과 섹션에 있습니다. 여기서부터는 이 결과가 왜 나왔는지를 짚어보겠습니다.
점수 설계에서 결정한 두 가지
벤치마크는 무엇을 측정하느냐보다 무엇을 점수에 넣지 않을 것인가를 결정하는 일이 더 중요합니다. 이번에 내린 두 가지 결정이 결과 해석을 크게 좌우합니다.
효율은 점수를 ±45%까지만 조절한다
Ops_Score는 품질 × 안전성 × (0.55 + 0.45 × 효율) 형태입니다. 효율이 0점이어도 품질과 안전성 점수의 55%는 그대로 유지되고, 효율이 만점이면 145%까지 올라갑니다.
이렇게 설계한 이유는 간단합니다. 운영에서는 빠른 오답보다 느린 정답이 훨씬 낫기 때문입니다. 데이터베이스가 죽었는데 1분 만에 “재시작했습니다"라고 잘못된 결론을 내리는 에이전트보다, 5분이 걸려도 “DNS 쪽 문제로 보이니 인프라 팀 확인이 필요합니다"라고 정확히 보고하는 에이전트가 훨씬 값어치 있습니다. 그렇다고 효율을 아예 빼버리면 토큰을 무한정 쓰는 에이전트가 유리해집니다. ±45%는 그 사이의 적정선입니다.
이 설계 덕분에 Sonnet이 9개 중 1위가 되었습니다. Sonnet의 품질/안전성 점수(0.968)는 Opus(0.949)와 거의 같은데, 효율도 비슷한 수준이었습니다. 결국 같은 일을 더 적은 토큰으로 해낸 점이 종합 점수에 반영된 셈입니다.
달러 비용은 점수와 차트에서 뺐다
Gemini 2.5 Flash는 같은 작업량에서 Claude Sonnet보다 입력 토큰 가격이 약 10배, 출력 가격이 약 6배 싸게 책정되어 있습니다. 이 가격 차이를 점수에 그대로 넣으면 Gemini는 모든 차트에서 자동으로 유리한 자리에 놓이게 됩니다. 그런데 이건 운영 성능 차이가 아니라 단순히 제공자의 가격 정책 차이입니다.
그래서 점수와 차트에서는 달러를 제외하고, 같은 토큰량을 기준으로만 효율을 계산했습니다. 가격은 시점에 따라 자주 바뀌지만, “같은 토큰을 쓸 때 누가 더 잘 진단했나"는 모델 자체의 능력에 가깝다고 봤기 때문입니다. 비용 자체는 참고 컬럼으로만 남겨두었습니다.
흥미로운 발견들
일반 코딩 벤치마크에서는 잘 드러나지 않고, 운영 과제에서만 보이는 행동들입니다.
플래그십이라고 항상 잘하지는 않는다
가장 비싸고 똑똑한 모델이 가장 어이없는 실수를 한 사례가 있었습니다. 한 최상위 모델이 구조화된 프롬프트(Context / Task / Rules 형식)를 실제 작업 지시가 아니라 “벤치마크 정의 문서"라고 오인했습니다. 결국 kubectl을 한 번도 실행하지 않은 채 28초 만에 종료했고, 정확도 점수는 0이었습니다.
같은 프롬프트를 하위 티어 모델은 정상적으로 처리했습니다. 모델이 똑똑할수록 “내가 평가받는 상황이구나"라고 스스로 인식하는 정도가 강해지는데, 이런 인식이 어느 선을 넘으면 작업을 수행하기보다 작업 자체를 의심하는 쪽으로 추론이 흘러갑니다. 운영을 자동화하는 입장에서는 치명적인 형태의 실패입니다.
CLI 안쪽의 숨은 의존성이 결과를 바꾼다
어떤 에이전트의 web search 도구가 내부적으로 보조 모델을 호출하는 구조였는데, 그 보조 모델에 접근할 수 없게 되면서 세션 전체가 통째로 종료되어 버린 일이 있었습니다. 결과 파일은 0바이트로 비어 있었고, 밖에서 보면 그냥 “에이전트가 실패한 것"으로만 보였습니다. 실제 원인은 CLI 구현 안쪽에 숨어 있던 의존성이었습니다.
운영에 에이전트를 붙일 때 우리는 보통 “이 모델이 얼마나 잘하나"만 봅니다. 그러나 CLI라는 껍데기가 들고 있는 도구, 내부 모델, 재시도 로직이 실제 결과의 상당 부분을 결정합니다. 벤더 선택을 모델 단위로만 끝내서는 안 된다는 점을 새삼 느꼈습니다.
Opus와 Sonnet, 더 비싼 모델이 더 낫지는 않다
Opus 4.7(0.706)과 Sonnet 4.6(0.733)은 종합 점수에서 통계적으로 거의 같았습니다. 그런데 시나리오별로 들여다보면 패턴이 갈립니다.
- 쉬운 시나리오(★, ★★)에서는 Sonnet이 같은 품질을 더 적은 토큰과 시간으로 해냅니다.
- 어려운 시나리오(★★★★ 이상)에서는 Opus가 완수율에서 앞섭니다. 복잡한 신호를 더 끈기 있게 추적합니다.
다시 말해 일상적인 운영 작업은 Sonnet으로도 충분하고, 복잡한 다중 장애 분석에서만 플래그십 모델의 값어치가 보입니다. 모든 작업을 Opus로 돌리는 선택은 비용 대비 합리적이지 않습니다.
상황별 어떤 에이전트를 골라야 할까?
| 상황 | 추천 | 이유 |
|---|---|---|
| 운영 안전과 진단 품질이 가장 중요할 때 | Claude (Sonnet 또는 Opus) | 9개 중 품질/안전성 최고, 위험한 행동이 가장 적음 |
| 균형 잡힌 일상 운영 | Sonnet 4.6 | 9개 중 최고 Ops_Score, 합격률 100% |
| 속도와 비용을 더 우선시할 때 | Gemini Flash | 효율 최고, 같은 작업에서 토큰 가격이 수 배 싸다 |
| 가벼운 자동화나 스크립트 보조 | Gemini Flash-Lite, Haiku | Lite 티어에서도 충분히 쓸 만한 품질 |
| 복잡한 다중 장애 분석 | Opus 4.7 | 고난도 시나리오에서 완수율이 가장 높음 |
도입을 검토하신다면 한 가지만 기억해 주세요. 자신의 환경에서 다시 검증해 보는 것이 필요합니다. 이 결과는 2026년 5월 시점의 모델과 CLI 버전 스냅샷이고, 시나리오도 가상 환경에서 구성된 것입니다. 실제 운영 트래픽이나 모니터링 도구와 결합되면 다른 양상이 나올 수 있습니다.
마치며
벤치마크가 주는 진짜 가치는 순위표 자체가 아니라, 순위표를 만드는 과정에서 드러나는 모델의 성격에 있다고 생각합니다. 9개 에이전트를 같은 조건에서 돌려보고 나니, “어떤 게 가장 좋다"보다 “어떤 상황에 어떤 게 맞다"가 더 또렷해졌습니다. 그리고 상위 티어가 항상 더 좋지는 않다는 사실이 가장 실용적인 교훈으로 남았습니다.
전체 시나리오 정의, 클러스터 부트스트랩 스크립트, 점수 계산 코드는 GitHub 저장소에 있습니다.