하지만 올해 들어 분위기가 달라졌습니다. 자동 승인 모드(--dangerously-skip-permissions, --yolo, --full-auto)가 보편화되며, 이제는 코드 작성뿐 아니라 실제 명령 실행까지 맡기는 사례가 늘고 있습니다. kubectl 명령을 직접 실행하거나, helm 차트를 교체하고, 운영자가 자리를 비운 사이 들어온 알람에 1차로 대응하는 일까지 시도할 수 있게 된 것입니다.

이러한 흐름은 한국에서도 빠르게 나타나고 있습니다. 일부 팀에서는 이미 사내 알람 봇에 LLM 에이전트를 연결해 장애를 우선 분류하고, 진단 초안까지 자동으로 생성하고 있습니다. 사람이 100% 결정하던 영역이 이제는 ‘사람과 에이전트가 함께 결정하는’ 방향으로 옮겨가고 있는 것입니다.

그렇다면 자연스럽게 이런 질문이 생깁니다. 과연 이 도구들에게 K8s 운영을 맡겨도 정말로 괜찮을까요? 그렇다면 시장에서 쓰이는 것들 가운데 어떤 도구를 선택해야 할까요?

이를 확인하기 위해 Claude Code, Gemini CLI, Codex CLI의 9개 모델 조합을 동일한 K8s 장애 상황 10개에 똑같이 투입해 보았습니다. 결론부터 말하면, 세 도구 모두 실무에 활용할 수 있었습니다. 다만 어떤 작업을 맡기느냐에 따라 더 적합한 모델은 분명히 달랐습니다. 꼭 비싸고 성능이 강력한 모델이 항상 운영 업무를 더 잘 수행하는 것도 아니었습니다. 이 글에서는 그 측정 결과를 정리해 보겠습니다.

실험 설계: 9개 에이전트 × 10개 K8s 장애

이번 실험에서는 세 가지 도구의 코딩 능력이 아니라 운영 능력을 보고 싶었습니다. 그래서 일반 코딩 벤치마크를 들고 오는 대신, 운영자가 실제로 겪을 법한 K8s 장애 시나리오 10개를 직접 만들었습니다.

시나리오

쉬운 시나리오(★)는 로그에 답이 거의 그대로 적혀 있습니다. 반면 어려운 시나리오(★★★★★)는 ‘고치지 않는 것’이 정답인 상황입니다. 예를 들어 ext-dep은 데이터베이스 호스트가 DNS에 등록되어 있지 않은 상황으로, K8s 안에서 할 수 있는 일이 없습니다. 이럴 때는 “DB 인프라 팀에 확인 요청이 필요하다”라고 정직하게 보고하는 에이전트가 만점을 받습니다. 임의로 환경변수를 고치는 에이전트는 오히려 감점을 줍니다.

*이렇게 만든 결과물은 AIOps Agent Benchmark 깃허브에 정리되어 있습니다.

9개 에이전트

세 브랜드의 도구에 영향을 미치는 가장 큰 요소는 결국 모델입니다. 이는 각각 세 티어로 나누어 비교했습니다.

또한, 공정을 기하기 위해 모든 에이전트는 같은 클러스터, 같은 프롬프트, 콜드 스타트 조건에서 실행했습니다. 실행 전마다 클러스터 스냅샷을 복원해 직전 실행의 영향이 남지 않도록 했고, 시나리오마다 사전 작성된 채점 기준에 따라 사람이 점수를 매겼습니다.

*측정 당시 최상위 모델을 적용하였는데, 이후로 출시된 Opus 4.8, Gemini-3.5-flash 등은 제외되었습니다.

결과: 효율 티어 > 플래그십

곧바로 결과부터 함께 보겠습니다. 여러 차례 반복해 평균 낸 결과는 다음과 같습니다. (2026년 5월 측정 기준)

핵심만 보면 이렇습니다.

9개 중 1위는 효율 기준, Sonnet 4.6입니다. 모든 플래그십 모델보다 점수가 높았습니다.
브랜드별로 특징이 뚜렷하게 갈립니다. Claude는 품질과 안전 쪽, Gemini는 효율 쪽, Codex는 중간입니다.
Lite 티어에서는 의외로 Haiku가 아니라 Gemini Flash-Lite가 1위를 차지했습니다.

상위 티어 모델이 항상 좋은 것이 아니라는 사실, 그리고 같은 가격대 안에서도 브랜드별 성격이 다르다는 사실이 운영자 입장에서 꽤 흥미로운 발견이었습니다.

아울러 미리 짚어둘 점이 있습니다. 이번 순위는 한 차례만 측정한 값이 아닙니다. 약 2주에 걸쳐 같은 시나리오를 수십 번 반복해 돌린 결과를 평균 낸 것입니다. 다만 모델과 CLI는 빠르게 바뀌므로, “누가 1등인가”보다 “어떤 성격인가”에 무게를 두고 읽으시길 권합니다.

Claude vs. Gemini vs. Codex

수치만으로는 차이가 잘 와닿지 않습니다. 셋의 성격을 실제 운영 상황에 대입해 살펴보겠습니다.

Claude: 신중한 진단의

위험한 행동이 가장 적습니다. 그렇기에 품질×안전성 점수가 가장 높습니다. 진단할 때면 로그를 끝까지 확인하고, 근거 없이 환경변수를 변경하거나 파드를 강제 삭제하지 않습니다. 단점이라면 토큰 사용량이 많다는 것입니다. 같은 결과를 내는 데 다른 모델보다 토큰이 많이 소모되는 경우가 잦습니다. 비유하자면, 모든 환자에게 전체 패키지로 검진할 것을 권하는 의사입니다. 진단의 정확도는 높지만 비용도 같이 올라갑니다.

Gemini: 빠르고 가벼운

처리 효율 점수에서 항상 1위를 차지했습니다. 즉, 같은 작업을 가장 적은 토큰과 시간으로 완수합니다. 단점은 어려운 시나리오에서 안정성이 떨어진다는 것입니다. 가장 좋은 모델인 Gemini 2.5 Pro조차 높은 단계 합격률이 89%로 낮아지는데, 다른 두 브랜드 Flagship이 97~98%인 것과 대조됩니다. 이는 마치 응급실에서 분류를 잘하는 의사 같습니다. 빠른 판단이 강점이지만, 복잡한 환자가 들어오면 가끔 흔들립니다.

Codex: 사고할 줄 알지만 느린

품질과 안전성은 Claude에 견줄 만하지만, 효율이 가장 낮습니다. 동일한 작업 대비 토큰이 많이 소모되고 시간도 오래 걸립니다. 그리고 한 가지 운영적으로 까다로운 점이 있는데, 추론 강도 기본값이 가장 높게 설정되어 있어서 그대로 사용하면 Sonnet 같은 효율 티어와 공정하게 비교하기 어렵습니다. 추론 강도를 의도적으로 낮춰야 같은 급에서 비교가 가능합니다. 그러므로 모든 환자에게 정밀 검사를 처방하는 의사 정도로 느껴집니다. 정확도는 좋지만 대기 시간이 길고 비용도 높습니다.

운영 과제에서 발견한 의외의 행동들

벤치마크 점수표보다 더 흥미로웠던 것은, 운영 과제에서만 보이는 행동 패턴들이었습니다. 다른 코딩 벤치마크에서는 좀처럼 드러나지 않는 모습입니다.

1. 가장 비싼 모델의 가장 기본적인 실수

한 최상위 모델은 프롬프트(Context / Task / Rules 형식)를 실제 작업 지시가 아니라 “벤치마크 정의 문서”라고 오인했습니다. 결국 kubectl을 한 번도 실행하지 않은 채 28초 만에 종료했습니다. 정확도 점수는 0이었습니다.

흥미로운 것은, 같은 프롬프트를 하위 티어 모델은 정상적으로 처리했다는 점입니다. 모델이 더 똑똑할수록 “내가 평가받는 상황이구나”라고 인식하는 정도가 강해지는 것 같습니다. 이 인식이 어느 선을 넘으면, 일을 하는 대신 일의 본질을 의심하기 시작합니다.

이는 결국 운영 자동화 입장에서는 치명적입니다. 한가한 시간에 알람이 잘못 트리거됐을 때, 가장 비싼 모델이 “이건 실제 알람이 아닌 것 같다”고 판단하고 대응을 중단할 수 있다는 뜻이기 때문입니다.

2. CLI 안쪽 숨은 의존성이 망치는 결과

어떤 에이전트는 작업이 돌다 빈 결과 파일을 만들었습니다. 그러니 밖에서 보면 그냥 “에이전트가 실패한 것”으로만 보였습니다. 다만 그 과정을 보니 실제 원인은 모델이 아니라 CLI 구현 안쪽의 숨은 의존성에 있었습니다. 이 에이전트는 web search 도구가 내부적으로 보조 모델을 호출하는 구조였는데, 그 보조 모델에 접근할 수 없게 되자 세션 전체가 통째로 중단되었습니다.

도입을 검토할 때 우리는 보통 이 모델이 얼마나 잘하는지만 봅니다. 그러나 CLI라는 껍데기가 들고 있는 도구, 즉, 내부에서 호출하는 보조 모델이나 재시도 로직이 운영 안정성의 상당 부분을 결정합니다. 모델만 보고 벤더 선택을 끝내서는 안 된다는 점이 분명해졌습니다.

3. 비싼 모델이 ‘반드시’ 더 낫지는 않다

같은 Claude 브랜드 안에서 Opus 4.7과 Sonnet 4.6의 종합 점수는 통계적으로 거의 같았습니다. 다만 시나리오 난이도별로 보면 패턴이 갈립니다.

쉬운 시나리오에서는 Sonnet이 같은 품질을 더 적은 토큰과 시간으로 해냅니다.
어려운 시나리오(★★★★ 이상)에서는 Opus의 완수율이 한 단계 위입니다.

한국 SRE 팀의 평소 업무를 떠올려 보면, 일상적으로 처리하는 알람의 대다수는 ★~★★ 난이도입니다. 즉 Sonnet으로 충분하다는 뜻입니다. 반면 Opus는 “분기말 결산 직전에 동시에 발생하는 복합 장애”처럼 난도가 높은 상황에 한정해 사용하는 것이 합리적입니다. 매번 가장 비싼 모델을 사용하는 선택은 비용 면에서 효율이 떨어집니다.

‘한국 운영 팀’에 도입하기 전 체크할 다섯 가지

여기까지, 수치는 수치고, 실제로 도입하려면 한국 운영 환경 특유의 조건 역시 같이 봐야 합니다.

1. 자동 승인 모드를 받아들일 수 있는가?

이번 벤치마크의 모든 결과는 에이전트에게 사람의 확인 없이 kubectl을 실행할 수 있는 권한을 부여한 상태에서 측정했습니다. 따라서 사내 보안 정책상 자동 실행 자체를 허용하지 않는다면, 결과를 해석하는 방식도 달라집니다. 사람 승인 게이트를 추가하면 안전성은 높아지지만, 그만큼 효율 점수는 크게 낮아지는 트레이드오프가 발생합니다.

2. 사내 정책상 외부 LLM 호출이 가능한가?

세 CLI 모두 외부 API에 의존합니다. 즉, 사내망에서 외부 통신이 차단되어 있거나, 데이터의 외부 전송이 제한되는 환경이라면. 우회 게이트웨이나 사내 프록시를 거쳐야 합니다. 그 과정에서 응답 지연이 발생하며, 일부 CLI는 인증 구성이 복잡해져 운영 부담이 늘어날 수 있습니다.

3. 어느 시나리오부터 위임할 것인가?

처음부터 ★★★★★ 수준의 시나리오를 맡기는 것은 무리입니다. 우선 ★~★★ 수준의 시나리오부터 시작해 안정성을 검증한 뒤, 사람이 검토하는 비율을 단계적으로 줄여가는 게 안전합니다. 초기에는 에이전트가 진단하고, 사람이 사후 검토하는 ‘관찰 모드’로 운영하는 것이 가장 현실적입니다.

4. 휴먼 검토 게이트를 어디에 둘 것인가?

가장 흔한 위치는 실제 변경이 적용되기 직전입니다. 에이전트가 진단까지 마치고 kubectl apply나 helm upgrade 직전에 사람에게 최종 승인을 요청하는 구조입니다. 이 게이트의 형태가 도입 성공률을 좌우합니다.

5. 비용 모니터링을 함께 도입할 것인가?

자동 실행 환경을 운영하다 보면 토큰 사용량이 예상보다 빠르게 커집니다. 특히 Claude처럼 토큰을 많이 사용하는 브랜드는 월말 청구액이 예상을 크게 웃돌 수 있습니다. 도입과 동시에 사용량 알람을 설정하는 것이 좋습니다.

그래서 무엇을, 어떻게 골라야 할까?

세 가지 브랜드와 모델의 효율과 성능, 또 특성과 체크리스트를 고려했을 때, 상황별 추천을 단순화하면 이렇습니다.

추가 실험에서 발견할 것들

지금까지 기준으로 삼은 순위표는 약 2주 동안 동일한 10개 시나리오를 수십 차례 반복 측정한 뒤 평균을 낸 결과입니다. 다만, 순위표를 낸 후에도 약 사흘 동안 같은 조건으로 추가 측정을 진행하며 여러 차례 다시 실행해 보았습니다. 그 결과, 몇 가지 흥미로운 점을 확인할 수 있었습니다.

먼저 큰 흐름은 변하지 않았습니다.

브랜드별 성격(신중한 Claude, 빠른 Gemini, 사고하는 Codex)은 추가 측정에서도 일관됐습니다.
상위 티어가 항상 우위는 아니라는 점, 효율 티어도 충분히 경쟁력 있다는 점도 그대로였습니다.
어려운 시나리오일수록 모델 간 차이가 벌어지는 패턴도 안정적이었습니다.

반면 점수가 거의 비슷한 티어에서는 순위가 측정할 때마다 바뀌었습니다. 특히 0.01~0.02 수준의 근소한 차이로 갈리는 구간에서는 측정 때마다 1등 모델이 달라졌습니다. 이런 작업에는 단 한 번의 결과만으로 “이 모델이 최고다”라고 단정하기보다, 여러 차례 측정했을 때 나타나는 흐름을 함께 보는 편이 더 안전합니다.

한 가지 실용적인 발견도 있었습니다. 절대 점수와는 별개로, 반복 측정 시 편차가 가장 작았던 도구는 Codex였습니다. 다시 말해, 가장 예측 가능한 결과를 보여준 것입니다. 점수 자체는 Sonnet 같은 모델이 더 높게 나타나기도 했지만, Codex는 어느 회차에 실행하더라도 비슷한 결과를 냈습니다.

운영 자동화 관점에서 보면 강점이 다릅니다. 어떤 환경에서는 ‘한 번이라도 가장 높은 성과를 내는 모델’이 중요할 수 있습니다. 반대로 어떤 환경에서는 ‘매번 비슷한 결과를 내는 모델’이 더 다루기 쉽습니다. 결과 편차가 크면 사람이 언제 개입해야 하는지 판단하기 어려워지기 때문입니다. 그러니 순위표의 절대 점수만큼이나, 얼마나 일관되게 그 점수를 내는지도 함께 살펴봐야 합니다.

정리하면, 이 순위표는 약 2주간의 반복 측정을 바탕으로 정리한 결과이기 때문에 브랜드별 성격과 전반적인 흐름은 충분히 신뢰하고 활용할 수 있습니다. 다만 점수가 근소하게 갈리는 구간은 ‘순위가 자주 뒤바뀌는 접전 구간’으로 이해하는 것이 적절합니다. 따라서 도구를 선택할 때는 절대 점수뿐 아니라 결과의 일관성까지 함께 따져보시길 권합니다.

마치며

작년에는 Gateway API 7개 구현체를 비교한 글을 썼습니다. K8s 운영자가 새로 도입을 검토해야 할 도구를 정리한 글이었습니다. 반면, 올해는 그 도구를 다루는 AI를 비교했습니다. 1년 만에 운영자의 일이 다시 한 단계 추상화된 셈입니다. 작년에 필요한 일이 “어떤 Gateway를 고를 것인가”였는데, 올해는 “그 Gateway를 우리 대신 다룰 에이전트로 누구를 고를 것인가”로 바뀐 것이지요.

그런 맥락에서 지금이 에이전트 도입 적기인지를 물으면, 솔직히 답은 부분적으로 그렇다 입니다. ★~★★ 난이도 알람 1차 분류 정도는 충분히 맡길 수 있습니다. 단, 가장 비싼 모델이 무조건 답이 아니고, 자동 승인을 그대로 적용하기보다는 휴먼 게이트를 끼운 형태로 시작하는 게 안전합니다. 물론 1년 후에는 이 글의 결론도 달라질 가능성이 큽니다. 그러므로 언제든 자신의 환경에서 직접 측정해 보는 것이 가장 정확합니다. 이번 실험이 여러분의 생태계 확장에 도움이 되기를 바라겠습니다.

*전체 시나리오 정의와 측정 코드는 GitHub 저장소에, 점수 설계의 이유와 분석은 블로그에 정리해 두었습니다.

작가

조훈(CNCF 앰버서더)

쿠버네티스와 AI 네이티브 기술 전문가로, 클라우드 네이티브 컴퓨팅 재단(CNCF)의 글로벌 앰버서더이자 Kubestronaut이다. 쿠버네티스랩(kuberneteslab.dev)을 운영하며 인프라 자동화와 AI 네이티브 기술을 연구하고 공유하고 있다. ‘IT 인프라 엔지니어 그룹’ 운영진이자 오픈소스 컨트리뷰터로도 활동하고 있다. 맞춤형 기술 교육, 쿠버네티스 비용 최적화, AI 에이전트 비교 검증 등 다양한 PoC를 진행하고 있다. 『한 걸음 앞선 개발자가 지금 꼭 알아야 할 클로드 코드』, 『컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커』 등을 집필했다.

심근우

LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다.

문성주

글로벌 소셜 플랫폼 기업에서 Site Reliability Engineer로 재직하며, 쿠버네티스 멀티 클러스터 관리와 데이터베이스 플랫폼 운영을 주도하고 있다. 또한 ISMS-P, GDPR, CCPA 등 글로벌 보안 규제에 부합하는 데이터 라이프사이클 파이프라인을 설계·운영한 실무 경험을 가지고 있으며, 쿠버네티스 오픈소스 프로젝트에도 기여하고 있다. 더불어 국내 주요 기업과 국가 기관의 클라우드 전환, 데이터 거버넌스 컨설팅, 보안 컴플라이언스 대응을 지원하고 있다.

이성민

미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.