RCAtlas에서 조사 자유를 준 단순 LLM 하네스가 수작업 RCA 에이전트를 이긴다

무엇인가

이 논문은 마이크로서비스 장애의 근본 원인 분석(RCA)에서 LLM 에이전트를 얼마나 수작업으로 설계해야 하는지를 직접 겨냥한다. 웹 서비스 뒤의 마이크로서비스가 실패하면 여러 컴포넌트로 연쇄되고, 운영자는 수백 개 서비스·파드·노드의 메트릭, 트레이스, 로그, 이벤트에서 원인을 찾아야 한다. 기존 LLM RCA 에이전트는 표준 운영 절차(SOP), 고정 단계, 역할별 서브에이전트와 투표로 조사 과정을 프로그램에 고정하는 경우가 많다. 하지만 각자 자기 데이터와 소수 베이스라인에서만 평가돼, 모델이 스스로 조사하게 두는 단순 하네스보다 나은지 알 수 없었다는 것이 논문의 출발점이다.

어떻게 동작하나

비교를 위해 저자들은 RCAtlas를 만든다. 8개 공개 RCA 데이터셋(RE1–3을 따로 세면 10개 스위트)을 하나의 사례 형식으로 모으고, 2,359개 공개 사례 중 542개를 검토해 8개 제외 규칙을 통과한 348개에서 90개 핵심 사례를 뽑았다. 핵심 세트는 23개 시나리오, 10개 장애 클래스를 아우르며 근본 원인은 서비스 59개, 파드 20개, 노드 11개다. 사례당 텔레메트리는 3.7만 행에서 560만 행에 이르고, 무작위 추측의 정확한 적중률은 0.25%에서 16.7%(중앙값 3.45%)다. 채점은 응답 엔티티를 데이터셋 라벨 수준까지 상향 매핑한 뒤 처음 5개를 비교하며, PR@1과 RR을 보고한다.

무엇과 다른가

방법군은 세 갈래다. 단순 하네스는 모델 호출을 프로그램이 지정하지 않는다. 원샷은 시스템 인벤토리, 움직인 메트릭 원시 샘플, 분당 트레이스 통계, 로그 템플릿, 이벤트를 한 번의 호출로 넣는다. SQL 에이전트는 DuckDB로 원시 파일을 직접 조회하는 ReAct 루프이며 최대 100회 호출한다. Codex는 사례 폴더에서 Codex CLI를 실행해 모델이 셸과 파이썬을 직접 작성하게 하고, 폴더 밖 읽기 금지·네트워크/설치 금지·데이터 수정 금지·원본 데이터셋 식별 시도 금지·최종 보고서 작성·최대 1시간 같은 여섯 규칙만 준다. 비교 대상은 발표된 LLM RCA 에이전트 5종(RCA-Agent, mABC, FoA, RCAgent, DecompRCA)과 비LLM 통계·인과 기법(NSigma, BARO, CIRCA, RCD, TORAI, FaultInsight, SimpleRCA), 무작위 랭킹이다. 실험은 6개 모델과 3개 추론 노력 설정에서 진행됐고, 저자들은 데이터에 맞지 않아 실행되지 않거나 구현 오류인 부분만 고치고 능력은 추가하지 않았다고 밝힌다.

어떻게 쓰나

핵심 결과는 단순 하네스의 우세다. 중간급 모델 3종(GPT-6 Luna, DeepSeek V4.1 Flash, Claude Haiku 5.5)에서 단순 하네스는 PR@1 65–77%, 발표된 LLM 에이전트는 16–53%, 비LLM 기법은 6–39%였고 무작위는 5.5%였다. Codex가 전체 최고였고, 가장 약한 단순 하네스인 원샷도 가장 좋은 발표 에이전트 FoA보다 12포인트 앞섰다. Luna·Haiku·Flash 각각에서 모든 단순 하네스가 모든 발표 에이전트보다 앞섰으며, Luna에서 원샷의 5.9포인트 우위만 통계적으로 유의하지 않았다. 모델군을 넓히면 단순 하네스는 Luna·Haiku에서 60–71%, Flash·Sol·Astra에서 74–87%로 두 계층을 보였다. MiMo는 AA 지수가 상위 계층(46.3)이어도 58–74%로 하위 계층에 가까웠고, 90개 중 69–86개만 완료했다. 파드·노드 수준 근본 원인은 서비스 수준보다 어려웠고, 서비스에서 파드로 갈 때 Codex는 9포인트 떨어졌지만 FoA와 RCAgent는 31–38포인트 떨어졌다. NSigma는 파드에서 55.0%로 서비스 33.9%보다 오히려 높았는데, 자원 장애가 원인 자신의 메트릭에 나타나기 때문이다. 네 가지 데이터 종류가 모두 있는 17개 사례는 단순 하네스에 가장 어려웠고(52–71%), 이 열에서만 FoA가 70.6%로 Codex와 맞먹었다. 메트릭만 있는 10개 사례는 SQL 에이전트가 95.6%로 가장 쉬웠다.

전제와 한계

왜 이런 차이가 나는지를 저자들은 규정 호출 비율(prescribed-call ratio)로 분석한다. 프로그램이 모델 판단과 무관하게 고정 지점에서 발생시키는 모델 호출의 비중이다. 단순 하네스 세 개는 0이고, mABC는 최소 0.10, RCA-Agent 0.29, RCAgent 0.35, FoA 0.51, DecompRCA 1.00이었다. 이 비율이 정확도를 순서대로 설명하지는 않지만, 아무것도 규정하지 않는 하네스와 무언가를 규정하는 에이전트 사이의 경계가 뚜렷하다. 사례 연구 rca100-main-0104에서는 inventory 서비스가 파드를 선택하지 못해 cart의 호출이 거부되고, inventory 요청 수가 1,450에서 109로, 다시 0으로 무너지는 동안 cart 오류율이 올라간다. 원샷은 cart 파드의 거부 로그 템플릿을 보고 inventory를 1위로 올렸고, SQL 에이전트는 31개 쿼리로 거부 로그 1,291줄과 요청 수 붕괴를 확인해 inventory를 제출했다. Codex는 7개 명령으로 넓게 비교한 뒤 onset 전후 로그를 읽고 inventory를 지목했다. 반면 FoA는 선택된 일반 SOP에 로그 단계가 없어 cart에서 멈췄고, mABC는 호출 체인을 따라가다 cart에서 멈췄다. NSigma는 상승한 메트릭만 높게 점수화해, 요청 수가 급감한 inventory의 큰 음의 z-score를 373개 컬럼 중 뒤에서 두 번째로 낮게 평가했다.

모델 역량과 추론 예산의 효과는 분리된다. Luna에서 Sol로 가면 Codex와 SQL 에이전트 모두 호출 수와 조회 엔티티 수가 줄었는데(Codex 16%→12%, SQL 21%→12%), 근본 원인을 더 많은 사례에서 찾고 PR@1이 14–18포인트 올랐다. 반대로 추론 노력을 높이면 호출과 조회가 늘지만 PR@1은 2–4포인트만 오르고, 대조 실험에서 벽시계 시간이 1.5–4배로 늘었다. 논문 전체로는 추론 노력 확대가 최대 7배 시간을 쓰면서 정확도는 몇 포인트 바뀌는 수준이라고 요약한다. 큰 예산은 탐색을, 강한 모델은 방향을 산다는 것이 저자들의 해석이다. 안정성 실험에서 Luna에서 Sol로 가면 세 번 중 최소 한 번 해결한 비율 A는 2–7포인트만 오르지만, 패스마다 결과가 갈리는 비율 U는 32–36%에서 7–8%로 떨어졌다. 멀티턴 하네스는 Luna에서 원샷보다 최소 한 번 해결한 사례를 10–11포인트 더 풀었고 U는 30–36%로 비슷했다. 원샷은 어떤 패스에서도 26%의 사례를 전혀 풀지 못했지만 두 에이전트는 14–16%만 그랬다. 약한 모델의 단일 패스는 흔들려서 Luna의 Codex 세 패스가 62%, 69%, 76%, SQL 에이전트가 66–71%였고, Sol에서는 패스 간 차이가 최대 4.5포인트였다.

비용·시간 관점에서도 결론은 단순 하네스 쪽이다. 최고 비LLM 기법 NSigma의 38.9%보다 정확한 실행만 사용 가능으로 두면 발표 에이전트 7개 실행이 43–63%로 문턱을 넘었지만, 비용 또는 시간 기준 파레토 최적 실행은 모두 단순 하네스를 썼다. 비용이 중요하면 Luna+Codex가 사례당 1센트 미만으로 68.9%, 달러당 정확도가 중요하면 Flash+Codex가 약 5센트로 85.6%, 빠른 답이 필요하면 Sol+SQL 에이전트가 45초에 85.6%를 냈다. 가장 정확한 Sol xhigh+Codex는 88.9%였지만 사례당 약 26센트와 277초가 들어, 마지막 몇 포인트가 가장 싼 강한 구성보다 약 5배 비쌌다. 개발자 입장에서는 RCA 에이전트를 SOP와 고정 단계로 먼저 복잡하게 만들기보다, 검증된 공유 사례에서 단순 하네스를 강한 베이스라인으로 두고 모델·하네스 조합을 비용과 지연까지 함께 비교해야 한다. 특히 파드·노드 수준 장애, 하락 신호, 단일 패스의 변동성을 확인해야 한다.

저자들이 밝힌 한계도 분명하다. 일반 코딩 하네스는 Codex만 시험했고 Claude Code 등은 다를 수 있다. 모든 모델이 2026년 모델이라, 수작업 워크플로가 설계되던 더 약한 모델에서도 순서가 유지되는지는 말할 수 없다. 예산 때문에 Fable, Opus, Argon 같은 최신 프런티어 모델은 포함하지 못했다. 데이터 변환과 재구현이 원본과 다를 수 있고, 사례 연구는 한 건만 따른다. 규정 호출 비율은 조사가 얼마나 고정됐는지를 측정할 뿐 그것이 낮은 정확도의 원인이라고 인과적으로 증명하지는 않으며, 한 에이전트에서 규정을 제거하는 ablation이 필요하다고 인정한다. 결론은 도메인 지식이 쓸모없다는 것이 아니라, 절차가 사례에 맞지 않을 때 통제 흐름에 고정하는 것이 해롭고, 절차를 선택적 안내로 제공하는 쪽이 자연스러운 다음 단계라는 것이다.