실패의 마지막 장면이 아니라 흩어진 단서를 찾는 일

오늘 다룰 논문은 arXiv에 공개된 Root-Cause Attribution Is a Search Problem: Continual Search for Long-Horizon Agent Failures로, 식별 번호 2609.13463을 달고 있습니다. 이 논문이 내세우는 주장은 한 문장으로 정리됩니다. 에이전트 실패의 원인 찾기는 한 번의 판단이 아니라 흩어진 증거를 계속 찾아내는 탐색 문제로 다뤄야 한다는 것이죠. 그래서 전체 논증은 제목 아래에 걸린 원문 링크에서 확인할 수 있습니다.

제가 이 논문을 집어 든 이유는 실패 이야기가 자꾸 마지막 장면으로만 귀결되는 모습이 마음에 걸렸기 때문입니다. 에이전트가 도구를 수백 번 호출하다가 마지막에 넘어지면 우리는 자연스럽게 마지막 호출을 의심합니다. 하지만 실제 운영에서 일어난 일을 복기해보면 진짜 문제는 한참 앞에 있는 경우가 많았기 때문이죠. 그래서 이 논문이 말하는 탐색이라는 단어가 눈에 들어왔습니다.

저는 실패 보고서가 아니라 탐정 이야기를 기대했는데요

여러분도 비슷한 경험을 해보셨을지 모르겠습니다. 저는 예전에 동료와 함께 밤늦게 장애를 들여다본 적이 있습니다. 처음에는 마지막 배포가 문제라고 믿어서 배포 기록만 뒤지다가 시간을 꽤 썼죠. 그런데 나중에 알고 보니 몇 시간 전의 설정 변경이 조용히 쌓여서 마지막 단계에서 터진 것이었습니다. 그렇다면 에이전트의 실패도 이렇게 봐야 하지 않을까요?

이 논문이 다루는 장면은 바로 그 지점입니다. 긴 작업을 수행하는 에이전트는 엄청난 분량의 실행 로그를 남깁니다. 사람이 처음부터 끝까지 읽기에는 현실적으로 벅찬 양이죠. 그래서 자동화된 근본 원인 분석, 즉 RCA가 필요하다는 이야기가 나옵니다. 여기서 RCA는 성공과 실패라는 결과 신호를 실제로 고칠 수 있는 개입으로 바꾸는 작업을 뜻합니다.

제가 이 논문에서 가장 흥미롭게 본 부분은 진단을 추론 능력이 아니라 탐색 끈기의 문제로 다시 쓴 대목입니다. 모델이 똑똑하지 않아서 틀리는 것이 아니라 끝까지 찾아보지 않아서 틀린다는 설명이라서, 이 관점이 바뀌면 평가와 설계가 함께 바뀌게 됩니다. 그래서 다음 이야기부터는 이 관점을 따라가 보려 합니다.

밤새 일한 에이전트의 로그를 누가 다 읽을까요

긴 작업이라는 말이 생각보다 실감이 잘 안 날 수도 있습니다. 에이전트가 브라우저를 열고 파일을 읽고 코드를 고치고 테스트를 돌리고 다시 검색하는 과정을 떠올리면 감이 오죠. 이런 과정이 몇 시간 이어지면 로그는 수천 줄로 불어납니다. 사람이 그걸 다 읽으려면 커피를 몇 잔 마셔야 할지 모릅니다.

문제는 분량만이 아니라서, 실패와 직접 관련된 증거가 아주 드물게 서로 멀리 떨어진 행동들 사이에 흩어져 있기 때문입니다. 그래서 눈에 보이는 실패 장면과 실제 원인이 이어지지 않는 경우도 많은데, 예를 들어 마지막에 파일 쓰기가 실패했어도 진짜 이유는 한참 전에 잘못 고른 검색어나 잘못 읽은 문서에 있을 수 있습니다.

이런 상황에서 사람 리뷰가 어렵다는 말은 단순한 엄살이 아닙니다. 규모가 커질수록 검토 비용이 선형으로만 늘지 않고 집중력도 함께 떨어지기 때문이죠. 그래서 자동화된 RCA가 필요하다는 논문의 출발점에는 저는 동의하는 편입니다. 다만 자동화가 정말 사람을 대신하려면 사람이 놓치는 바로 그 흩어짐을 처리할 수 있어야 합니다.

결과지를 수리 설명서로 바꾸는 일

RCA라는 용어가 조금 딱딱하게 들릴 수 있어서, 저는 이걸 성적표와 처방전의 차이로 이해했습니다. 성적표는 잘했는지 못했는지만 알려주지만 처방전은 어디를 어떻게 고쳐야 하는지 알려줍니다. 논문이 말하는 RCA는 후자에 가깝죠. 결과 신호를 운영에 쓸 수 있는 개입으로 바꾸는 일이니까요.

그렇다면 좋은 RCA는 어떤 모습일까요? 실패한 단계만 가리키는 것이 아니라 왜 그 단계가 실패할 수밖에 없었는지를 앞선 선택들에서 찾아내야 합니다. 어떤 도구를 잘못 불렀는지, 어떤 정보를 놓쳤는지, 어떤 가정이 조용히 어긋났는지를 짚어내면, 수정은 훨씬 구체적이 됩니다. 프롬프트를 고칠지, 도구 설명을 바꿀지, 재시도 로직을 넣을지를 정할 수 있으니까요.

여기서 재미있는 질문이 생깁니다. 진단은 모델이 한 번 읽고 답을 내놓는 시험 문제와 같은 걸까요, 아니면 현장을 여러 번 뒤지는 일과 같은 걸까요? 논문은 후자라고 말하고, 이 선택이 이후의 모든 설계를 이끕니다.

그럴듯한 답에 너무 일찍 멈추는 판단

기존의 LLM 기반 RCA 방식이 왜 낮은 진단 정확도를 보이는지, 논문은 그 이유를 실행 흔적이 길어질수록 더 또렷해지는 현상에서 찾습니다. 흔적이 길어지면 모델은 그럴듯해 보이는 진단을 일찍 내놓고 거기서 멈추기 때문이죠. 저는 이 대목에서 무릎을 쳤습니다. 사람도 피곤하면 비슷한 실수를 하니까요.

생각해보면 사람도 비슷하게 행동합니다. 밤늦게 로그를 보다가 그럴듯한 원인을 찾으면 그 뒤의 기록은 대충 훑게 됩니다. 한 번의 판단으로 끝내는 one-shot 방식에서는 이런 경향이 더 강해지죠. 검토하지 않은 증거가 남아 있음에도 이미 답을 정해버리는 셈이니까요.

문제는 그다음입니다. 남겨진 증거 중에 진짜 원인이 들어 있을 수 있습니다. 판단이 일찍 닫히면 그 증거는 영원히 검토되지 않죠. 그래서 정확도가 떨어지는 것은 모델이 멍청해서가 아니라 구조가 서두르게 만들기 때문입니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 구조가 탐색을 멈추게 하면 더 큰 모델을 가져와도 같은 벽에 부딪힐 수 있으니까요.

원인이 아니라 증거를 찾는 문제로 보면 어떨까요

논문의 표현을 빌리면, 근본 원인 분석은 거대한 탐색 문제로 축소됩니다. 이 문장을 저는 이렇게 읽었습니다. 원인을 맞히는 게임이 아니라 아직 설명되지 않은 증거를 계속 찾아내는 게임이라는 뜻으로 말이죠. 원인은 증거가 모이면 따라오는 것이니까요.

이런 관점 전환이 도움이 되는 이유는 흩어짐을 정면으로 다루기 때문입니다. 관련 증거가 드물고 멀리 떨어져 있다면 답을 먼저 정하는 방식은 불리합니다. 대신 아직 풀리지 않은 단서가 무엇인지 목록으로 만들고 그 단서를 하나씩 해소하는 방식이 어울리죠. 일종의 오답 노트처럼요. 틀린 답을 지우는 것이 아니라 아직 확인하지 않은 페이지를 줄여나가는 셈이니까요.

그렇다면 탐색을 잘한다는 것은 무엇을 뜻할까요? 단순히 오래 보는 것이 아니라 어디를 봤고 어디를 아직 안 봤는지를 기억하면서 보는 것입니다. 이미 본 구간을 또 보는 것이 아니라 설명되지 않은 구간으로 시선을 옮겨야 해서, 이 차이는 생각보다 중요합니다. 같은 시간을 써도 어디에 쓰는지에 따라 결과가 달라지니까요.

끝나려는 판단을 계속 붙잡고 다시 묻는 방법

논문이 제안하는 Continual Search는 이름 그대로 계속 이어지는 탐색으로, 판단자 모델에게 여러 턴에 걸쳐 아직 해결되지 않은 진단 증거를 계속 찾도록 유도하는 반복 프레임워크입니다. 저는 여기서 조금 의심했습니다. 그냥 여러 번 물어보면 되는 것 아닌가 싶었죠.

그런데 조금 더 들여다보면 단순한 반복이 아닙니다. 매 턴마다 아직 설명되지 않은 부분을 의식하게 만든다는 점이 다르기 때문입니다. 처음에 그럴듯한 답이 나와도 거기서 끝내지 않고 혹시 보지 않은 단서가 있는지 다시 묻게 됩니다. 마치 옆에서 경험 많은 동료가 어깨너머로 아직 안 본 로그가 남았다고 일러주는 모습과 비슷하죠.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이렇게 여러 번 묻는 데 드는 비용은 감당할 만한가요? 논문의 답은 진단 정확도의 상승에서 비용의 근거를 찾습니다. 틀린 진단을 믿고 엉뚱한 곳을 고치는 비용을 생각하면 진단을 위해 몇 번 더 탐색하는 비용은 오히려 쌀 수 있기 때문입니다. 저희가 새로운 AI 아키텍처를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 운영에서 어떤 비용 구조를 만드는지를 함께 보기 때문이죠. 이 경우에도 같은 잣대를 들이대야 합니다.

길고 지저분한 실패 50개를 따로 모은 이유

평가 이야기를 하기 전에, 저는 이 논문이 MegaRCA-Mix라는 평가 모음을 새로 만든 선택을 먼저 보고 싶습니다. 실행이 많은 긴 작업에 걸친 실패 사례 50개를 사람이 직접 주석을 달아 모은 것인데, 왜 하필 이런 모음이 필요했을까요?

이유는 기존 평가가 긴 흔적의 어려움을 제대로 담지 못했기 때문입니다. 짧고 깔끔한 실패만 모아두면 한 번 훑어보는 방식으로도 점수가 잘 나오지만, 실제 실패는 길고 지저분하기 때문입니다. 중간에 쓸데없는 재시도도 있고 우회로도 있고, 나중에 알고 보면 상관없는 소음도 많습니다. 그런 실패 50개를 따로 모았다는 것은 쉬운 문제로 점수를 부풀리지 않겠다는 선언과 비슷합니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 50개라는 숫자는 크지 않아서 통계적으로 넓은 일반화를 하기에 넉넉한 규모는 아니기 때문입니다. 그럼에도 이 모음이 의미가 있는 이유는 난이도의 방향이 분명하기 때문이며, 길고 실행이 많은 실패에 초점을 맞췄다는 점에서 기존 방식이 왜 무너지는지를 드러내기에는 충분합니다. 저는 그래서 이 선택을 점수용 데이터가 아니라 문제 정의용 데이터로 읽었습니다.

0.349에서 0.498로 오른 점수가 가리키는 방향

이제 숫자를 prose 안에 넣어보겠습니다. MegaRCA-Mix에서 GPT-5.5의 F1 점수는 Continual Search를 적용한 뒤 0.349에서 0.498로 올랐습니다. 40%를 훌쩍 넘는 상승이죠. 같은 계열 안에서 하위 모델이 상위 모델을 앞지르는 장면도 나타났다고 합니다.

이 숫자는 그대로 믿기 전에 조건을 봐야 합니다. F1이라는 지표는 원인을 얼마나 정확하고 빠짐없이 짚었는지를 함께 보는 것이라서 단순 정확도보다 진단 작업에 어울리기 때문입니다. 그리고 상승 폭이 크다는 것은 기존 방식이 남긴 여백이 그만큼 컸다는 뜻이기도 해서, 다시 말하면 한 번의 판단이 놓치고 있던 증거가 꽤 많았다는 이야기입니다.

개인적으로 인상 깊었던 점은 하위 모델이 상위를 앞질렀다는 대목입니다. 보통은 모델을 키우면 점수가 오르죠. 여기서는 탐색 방식을 바꾸는 것만으로 순위가 뒤집혔습니다. 이는 모델 크기보다 탐색 구조가 병목이었다는 방증으로 읽히지만, 물론 이 결과를 모든 작업에 일반화하기에는 데이터가 부족합니다. 50개 사례에서의 결과이기도 하고 다른 모델 계열에서는 양상이 다를 수도 있으니까요. 그럼에도 방향은 분명해서, 더 큰 판단자를 사기 전에 판단을 계속 일하게 만드는 구조를 먼저 의심해볼 수 있게 됐습니다.

운영 회의에서 이 논문을 꺼내면 생기는 질문들

이 논문이 운영 현실에 던지는 질문은 꽤 구체적입니다. 에이전트를 오래 돌리는 팀이라면 누구나 한 번쯤 겪는 장면이 있습니다. 아침에 출근해보니 밤새 돌린 작업이 실패해 있고 로그는 산더미처럼 쌓여 있는데 어디부터 봐야 할지 막막한 장면 말입니다. 그때 필요한 것은 실패한 줄 번호가 아니라 어떤 앞선 선택이 연쇄를 만들었는지에 대한 설명입니다.

Continual Search의 관점을 빌리면 대시보드의 생김새도 달라질 수 있습니다. 최종 판단 하나만 보여주는 대신 어떤 증거는 해소됐고 어떤 증거는 아직 남았는지를 함께 보여줄 수 있기 때문입니다. 아직 풀리지 않은 단서가 몇 개 남았다는 표시만 있어도 엔지니어는 다음 행동을 정하기가 쉬워집니다. 로그 전체를 다시 읽을지 특정 구간의 도구를 뜯어볼지를 말이죠.

반면 비용과 지연에 대한 질문도 따라옵니다. 매번 여러 턴을 돌리면 추론 비용이 늘고 진단이 늦어질 수 있기 때문입니다. 그래서 모든 실패에 같은 강도의 탐색을 쓸 필요는 없습니다. 짧은 작업의 분명한 실패에는 가벼운 진단을, 길고 애매한 실패에는 깊은 탐색을 쓰는 식으로 단계를 나누는 편이 자연스럽습니다. 좋은 건 알겠는데, 이걸 실제로 어떻게 서빙할까요? 이 질문에 답하는 과정이 다음 제품화의 갈림길이 될 것 같습니다.

다음에는 어디까지 물어볼 수 있을까요

그렇다면 이 흐름은 어디까지 이어질 수 있을까요? 논문이 남긴 빈칸을 저는 세 가지로 읽었습니다. 첫째는 언제 멈출지에 대한 기준입니다. 계속 묻는 방식은 멈춤 규칙이 없으면 비용이 무한히 늘어날 수 있어서, 아직 해소되지 않은 증거가 없다는 것을 판단자 스스로 믿을 수 있을지가 관건이기 때문입니다.

둘째는 증거의 우선순위를 정하는 방법입니다. 모든 구간을 똑같이 뒤지는 것은 비효율적이어서, 실패와 멀리 떨어져 보이지만 실제로는 연결된 구간을 먼저 찾는 감각이 필요합니다. 사람이 탐정처럼 냄새를 맡는 지점이 있다면 그 감각을 구조로 옮기는 일이 남습니다. 참고로 저는 이 부분을 단순한 프롬프트 문제가 아니라 흔적의 구조를 읽는 별도의 설계 문제로 봅니다.

셋째는 진단과 수정 사이의 간격입니다. 원인을 정확히 짚어도 수정이 따라오지 않으면 운영 지표는 움직이지 않습니다. 이번 논문은 진단에 초점을 맞췄지만 다음 단계에서는 진단 결과를 어떤 개입으로 바꿨을 때 실제로 실패율이 떨어지는지를 보여줘야 합니다. 제가 앞으로 보고 싶은 것은 바로 그 연결로, 점수가 아니라 밤샘 작업의 성공률이 바뀌는 장면 말입니다.

이 논문이 남긴 한 문장을 다시 곱씹게 됩니다. 실패의 원인은 마지막에 있지 않을 때가 많고, 그래서 판단은 한 번으로 끝나서는 안 된다는 것입니다. 에이전트가 더 오래 일하고 더 많은 도구를 만질수록 진단은 답 맞히기가 아니라 현장을 지키는 일이 됩니다. 다음에 긴 로그 앞에서 멈칫하게 된다면 저는 이 논문의 질문부터 떠올릴 것 같습니다. 아직 보지 않은 증거가 남아 있지 않은지 말입니다.