장애 진단을 자동화하려는 시도는 대개 대형 언어모델(LLM) 에이전트가 명령을 실행하고 가설을 세우며 보고서를 쓰는 방식으로 설계된다. SREGym 진영이 공개한 이번 실험은 그 구조를 뒤집는다. LLM 에이전트를 아예 배제하고, 선택지 중에서 답을 고르는 가벼운 판단 모델 'Jev'를 중심에 둔 진단 파이프라인을 만든 것이다. 결과는 105건의 진단 중 80건 통과, 즉 76.2%의 성공률이었고 진단 한 건의 중앙값 소요 시간은 14.6초였다. 속도와 비용을 감안하면 눈여겨볼 만한 수치다.
수집기가 일하고, Jev는 고른다
이 파이프라인의 핵심은 역할 분담이다. Jev는 스스로 명령을 만들거나 최종 보고서를 작성하지 않는다. 대신 '프로그래밍 방식의 수집기(collector)'가 쿠버네티스 오브젝트와 이벤트, 최근 파드 로그, 리소스 사용량을 읽어 Deployment 같은 구성요소 단위로 묶고 장애 징후를 요약한다. Jev는 이 요약을 보고 들여다볼 만한 지점을 고른 뒤, 수집기가 더 자세히 모아 번호를 매긴 증거 항목 중에서 해당 구성요소가 원인인지, 피해를 입은 하류인지, 무관한지를 판단하고 가설을 뒷받침할 증거를 선택한다. 가설이 증거로 뒷받침되지 않으면 다른 후보로 넘어간다. 즉 Jev의 판단력만큼이나 수집기가 '무엇을, 얼마나 자세히 보여줄지' 결정하는 설계가 성패를 좌우한다.
이 구조가 어떻게 작동하는지는 소셜 네트워크 애플리케이션의 웹훅 장애 사례에서 잘 드러난다. nginx-thrift 파드가 계속 메모리 부족으로 죽었는데, Deployment 템플릿에는 256Mi 제한이 명시돼 있었지만 실제 생성된 파드에는 16Mi만 할당됐다. 파드 생성 시점에 뮤테이팅 어드미션 웹훅이 제한값을 다시 쓰고 있었던 것이 원인이었다. 문제는 웹훅 구성이 네 개나 더 있어 이름만으로는 범인을 특정할 수 없었다는 점이다. 수집기는 social-network의 27개 Deployment를 각각 요약하면서 nginx-thrift에서 파드와 템플릿의 차이를 찾아내고 일치하는 웹훅까지 짚어냈다. Jev는 영향받은 구성요소와 제출할 증거를 골랐고, 다섯 번의 시도가 모두 진단 기준을 통과했다. 실제 진단 노동의 상당 부분을 수집기가 떠맡았음을 보여주는 대목이다.
성능과 일관성, 그리고 비용
평가는 9월 4일자 SREGym-Lite 코호트의 21개 장애 시나리오를 jev-1.13.0으로 다섯 번씩 돌리고, gpt-6-astra가 높은 추론 수준에서 9개 질문 루브릭과 0.70 통과 기준으로 채점하는 방식으로 진행됐다. 눈에 띄는 것은 결과의 일관성이다. 모든 장애에서 다섯 번의 시도가 전부 통과하거나 전부 실패했고, 21개 중 18개는 점수까지 동일했다. 같은 점수를 받았다고 매번 같은 경로를 밟았다는 뜻은 아니지만, 이 안정성은 결국 '파이프라인이 클러스터 상태를 어느 정도 세밀하게 Jev에게 보여주느냐'가 관건이라는 설계 질문으로 이어진다. 요약이 너무 거칠면 원인을 설명할 디테일이 사라지고, YAML을 통째로 던지면 유용한 신호가 묻힌다.
비교 지점도 분명하다. Jev의 76.2%는 GPT-5.6 Sol(중간 설정)의 77.8%에 근접하면서도 약 7배 빠르고 진단당 비용은 약 200배 저렴했다. 유연성은 LLM 에이전트보다 떨어진다. 파이프라인이 제공한 증거와 선택지에 진단이 종속되기 때문이다. 그러나 이 속도와 비용은 Jev를 1차 진단 도구로 쓰고, 더 폭넓은 조사가 필요한 사례만 LLM 에이전트에 넘기는 역할 분담을 매력적으로 만든다.
실패가 드러낸 두 가지 한계
실패한 실행들은 두 가지 뚜렷한 유형을 보였다. 첫째는 Jev가 엉뚱한 단서를 고른 경우다. 애스트로노미 숍의 CPU 포화 장애에서는 조작된 WAF 요청이 frontend-proxy의 값비싼 정규식을 건드려 CPU를 포화시켰는데, 수집기는 정규식 변경과 새로 추가된 100m CPU 제한을 모두 증거로 제시했다. Jev는 다섯 번 모두 CPU 제한을 지목했고, 채점자는 위치와 영향 범위는 인정했지만 설명이 틀렸다고 보아 0.67점을 매겼다.
둘째는 결정적 증거 자체가 빠져 있던 경우다. 호텔 예약 서비스의 재시도 붕괴 장애에서는 짧은 트래픽 폭증이 rate 서비스의 큐를 채웠고, search가 타임아웃된 호출을 재시도하면서 트래픽이 정상으로 돌아온 뒤에도 과부하가 유지됐다. Jev는 rate와 20-QPS 백엔드 제한에만 집중해 큐·데드라인·재시도가 만든 루프를 놓쳤다. 넓은 스냅샷은 search의 재시도 설정을 언급했을 뿐 그 값을 보여주지 않았고, 파이프라인은 search를 자세히 들여다보지도 않았다. 게다가 단일 원인 구성요소 하나를 고르라고 요구했는데, 이 장애는 두 서비스의 상호작용 속에 있었다. 측정값 누락과 좁은 선택지가 정답을 가로막은 셈이다.
이 한계들은 다음 과제도 규정한다. 연구진은 원인이 여러 서비스에 걸치거나 시간에 따라 변하는 장애로 파이프라인을 확장하려 한다. 요청 단위 신호와 변화하는 지표를 수집해 구성요소 간에 연결하고, 둘 이상의 서비스가 얽힌 설명도 Jev가 고려하게 만드는 방향이다. 여기서 GPT-6 Luna 같은 작고 특화된 모델이 구조화된 텔레메트리를 Jev가 소화하기 쉬운 자연어로 바꾸는 역할을 맡을 수 있다는 구상도 함께 제시됐다. 빠르고 값싼 판단(System One)과 깊은 추론(System Two)을 결합하려는 실무적 밑그림으로 읽히는 대목이다.