에이전트의 깊이를 재는 법: 점수 너머의 다섯 가지 눈금
성공률 하나로 LLM 에이전트를 평가할 수 있을까요. 궤적 전체를 읽는 다섯 가지 기준과 이를 오래된 벤치마크에 얹는 법을 따라가 봅니다.
원문 논문 보기
arXiv에 공개된 논문 Agentic Cognitive Depth: Operational Criteria for Evaluating LLM Agents(arXiv 2610.04168)는 LLM 에이전트를 하나의 성공 점수가 아니라 다섯 가지 기준으로 이루어진 궤적 수준의 프로파일로 평가하자고 제안합니다. 원문 링크는 제목 아래에 걸어 두었습니다.
제가 이 논문을 처음 펼친 이유는 요즘 에이전트 데모를 보면서 느끼는 답답함 때문이었습니다. 데모에서는 분명히 일을 끝내는데, 막상 제 업무에 올려 두면 어느 날은 잘하다가 어느 날은 엉뚱한 곳에서 멈추거든요. 성공이냐 실패냐만 기록하는 표에서는 그 차이가 전혀 드러나지 않았습니다. 이 논문은 그 답답한 지점을 정확히 짚습니다. 결과가 아니라 과정을 보자는 것이죠. 그렇다면 과정을 본다는 것은 실제로 무엇을 본다는 걸까요. 오늘은 그 질문을 처음부터 따라가 보겠습니다.
성공률 하나로는 에이전트를 설명할 수 없습니다
다들 비슷한 경험을 해보셨을 겁니다. 여행 일정을 짜는 에이전트에게 밤 11시쯤 비행기와 숙소를 함께 잡아달라고 부탁했는데, 돌아온 답은 절반만 맞는 경우가 있죠. 비행기는 잡았는데 숙소 날짜가 하루 어긋나 있거나, 가격은 맞췄는데 환불 조건을 놓친 경우처럼요. 최종 판정만 남기면 이 실행은 그냥 실패 한 줄로 기록됩니다. 그런데 실패라는 한 단어 안에는 서로 다른 이야기가 들어 있습니다. 날짜를 잘못 읽은 것인지, 도중에 바뀐 조건을 놓친 것인지, 아니면 막판에 스스로 점검할 기회를 날린 것인지가 전부 지워지니까요.
저는 이 지점에서 성공률이라는 숫자가 얼마나 무심한지 다시 느꼈습니다. 같은 70점이라도 어떤 에이전트는 매번 다른 곳에서 삐끗하고, 어떤 에이전트는 특정한 종류의 상황에서만 반복해서 무너지는데, 평균 점수는 둘을 똑같이 보이게 만듭니다. 현장에서 일하는 사람에게는 후자가 훨씬 고맙습니다. 약점이 어디인지 알면 맡기는 일을 조절할 수 있으니까요. 그래서 저는 점수를 하나 더 올리는 연구보다, 점수 뒤에 가려진 실패의 모양을 구분해주는 연구에 마음이 갑니다.
이 논문이 겨냥하는 곳도 바로 그곳입니다. 저자들은 에이전트의 능력을 하나의 숫자로 접어 넣는 대신, 실행 궤적 전체에서 드러나는 성향으로 읽자고 말합니다. 다섯 가지 기준이 그 눈금에 해당하는데, 각각은 측정 가능한 대리 지표와 일부러 흔들어보는 섭동 절차를 함께 갖춥니다. 말하자면 성격 검사지와 스트레스 테스트를 묶은 셈이죠. 그렇다면 왜 하필 다섯 가지일까요. 다음 장면부터 하나씩 펼쳐 보겠습니다.
계획하고 기억하고 도구를 쓰는 고리 하나
논문은 요즘 에이전트 시스템을 아주 단순한 문장으로 정리합니다. 고리 안에 들어간 LLM이 계획과 기억과 도구와 흐름 제어를 오가며 일한다는 것이죠. 저는 이 정리가 마음에 들었습니다. 모델 크기와 상관없이 현장의 에이전트는 결국 같은 고리를 돌고 있기 때문입니다. 계획을 세우고, 필요한 것을 기억에서 꺼내고, 검색이나 코드 실행 같은 도구를 두드리고, 다시 흐름을 정돈하는 일이 반복되죠.
월요일 아침을 떠올려 보시면 감이 옵니다. 재고 정리를 부탁받은 사무실 신입이 스프레드시트를 열고, 어제 메모를 뒤적이고, 창고 시스템에 조회 쿼리를 날리고, 막히면 선배에게 물어보는 모습과 닮았죠. 신입의 하루를 평가할 때 마지막 보고서 한 장만 보는 상사는 드뭅니다. 중간에 메모를 어떻게 남겼는지, 무엇을 검색했는지, 막혔을 때 어떻게 방향을 바꿨는지를 함께 보니까요. 에이전트도 마찬가지라고 논문은 말합니다.
여기서는 조금 조심해서 읽을 필요가 있습니다. 계획이나 기억 같은 단어가 사람의 마음을 그대로 가리키는 것처럼 들리지만, 논문이 말하는 것은 훨씬 실제적인 쓰임새입니다. 계획이 실행 중간에 진짜로 쓰였는지, 기억이 다음 단계의 선택을 바꿨는지, 도구가 순서에 맞게 호출됐는지를 궤적에서 확인하자는 것이죠. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 고리가 어디에서 끊기는지 알면 고칠 곳이 보이니까요.

점수가 아니라 궤적을 본다는 발상
그렇다면 궤적을 본다는 것은 구체적으로 무엇일까요. 논문이 제안하는 깊이(depth)라는 말은 모델이 크다거나 똑똑하다는 뜻이 아닙니다. 하나의 실행이 시작부터 끝까지 얼마나 안정적으로 맥락을 붙잡고 이어졌는지를 가리키는 프로파일에 가깝습니다. 최종 답이 맞았어도 도중에 우연히 맞춘 것과, 탄탄하게 이어져서 맞춘 것은 다른 깊이를 갖는 것이죠.
등산을 생각해 보시면 됩니다. 정상 사진만 보면 두 팀이 똑같아 보이지만, 한 팀은 길을 잃었다가 우연히 표지판을 만났고 다른 한 팀은 갈림길마다 지도를 확인하며 걸었다면 다음 산행에서 데려가고 싶은 팀은 분명합니다. 에이전트 평가도 그렇게 바뀌어야 한다는 것이 논문의 판단입니다. 저는 이 발상이 운영자의 입장과 닿아 있다고 느꼈습니다. 저희가 새로운 AI 구조를 볼 때도 점수만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보니까요.
이 발상을 실제로 쓸 수 있게 만드는 장치가 두 가지 있습니다. 하나는 각 기준마다 붙어 있는 대리 지표인데, 직접 보기 어려운 능력을 곁에서 드러내는 신호로 읽는 방법입니다. 다른 하나는 섭동 절차인데, 입력이나 중간 상태를 일부러 조금 흔들어서 에이전트가 흔들리는 모양을 관찰하는 방법입니다. (참고로 저는 이 흔들어보기라는 표현이 참 솔직하다고 느꼈습니다. 잘될 때의 모습보다 흔들릴 때의 모습에서 성격이 드러나니까요.) 그렇다면 다섯 가지 눈금은 각각 무엇을 흔드는 걸까요.
상황의 미묘한 변화를 읽는 능력
첫 번째 눈금은 문맥 민감성입니다. 지시나 환경이 조금 바뀌었을 때 에이전트가 그 변화를 알아채고 행동을 고치는지를 봅니다. 겉으로 보면 당연해 보이지만, 막상 긴 작업에서는 자주 무너지는 부분이죠.
금요일 오후에 고객 목록 정리를 시켰다고 해보죠. 처음에는 국내 고객만 정리하라고 했다가, 중간 채팅에서 해외 건은 제외하고 VIP 표시를 추가해달라는 말이 끼어듭니다. 사람은 대수롭지 않게 받아들입니다. 그런데 에이전트는 처음 지시에 묶인 채 중간 변경을 흘려보내는 경우가 있습니다. 파일은 멀쩡히 만들어졌는데, 정작 바뀐 조건이 반영되지 않은 것이죠. 결과만 보면 절반의 성공이지만, 궤적을 보면 처음 몇 단계 이후로는 새로운 문맥을 읽지 않았다는 사실이 드러납니다.
왜 이런 일이 생길까요. 제 생각에는 흐름 제어가 처음 계획에 너무 단단히 묶여 있을 때 이런 증상이 잘 나타납니다. 계획이 한 번 굳어지면 이후의 관찰이 계획의 부속품처럼 취급되거든요. 그래서 대리 지표를 볼 때는 최종 산출물보다 중간 선택이 바뀌었는지를 봅니다. 조건이 바뀌기 전과 후의 검색어, 읽은 파일 범위, 도구 인자가 달라졌는지가 더 정직한 증거가 됩니다. 그리고 섭동 절차에서는 일부러 조건을 살짝 바꿔 봅니다. 날짜 형식을 바꾸거나 제외 조건을 문장 뒤쪽에 숨겨서, 에이전트가 끝까지 주의를 유지하는지를 시험하는 것이죠. 여러분도 비슷한 일을 맡겨보신 적이 있으시죠. 처음에는 멀쩡하다가 조건이 두 개만 넘어가도 흐트러지는 모습 말입니다.

어제 한 말을 오늘도 기억할 수 있을까
두 번째 눈금은 시간적 이어짐입니다. 긴 실행에서 앞서 정한 사실과 약속이 뒤쪽 단계까지 살아 있는지를 봅니다. 에이전트가 길어질수록 흔히 겪는 증상이 바로 이 기억의 끊김입니다.
화요일에 시작한 시장 조사 작업을 떠올려 보죠. 오전에는 경쟁사 세 곳으로 범위를 정했고, 오후에는 가격대 기준을 정했습니다. 그런데 수요일에 정리본을 만들 때 갑자기 네 번째 회사가 끼어들거나 가격 기준이 슬쩍 바뀌어 있습니다. 누가 봐도 중간 메모를 잃어버린 것이죠. 사람은 이런 실수를 줄이려고 메모장을 펼치거나 어제 정한 것을 소리 내어 복기합니다. 에이전트에게도 그에 해당하는 장치가 필요한데, 논문은 구조화된 기억 같은 실용적인 수단을 함께 거론합니다.
여기서 재미있는 질문이 생깁니다. 기억을 길게 늘리면 무조건 좋아질까요. 저는 그렇지 않다고 봅니다. 쌓아두기만 하고 꺼내 쓰지 못하는 기억은 창고에 박힌 짐과 같거든요. 그래서 이 기준을 볼 때는 저장 용량보다 이어짐의 흔적을 봅니다. 앞서 정한 제약이 뒤쪽 도구 호출에 실제로 반영됐는지, 중간 요약이 다음 계획을 좁혔는지가 증거가 됩니다. 섭동 절차에서는 일부러 중간에 방해 정보를 끼워 넣습니다. 관련 없는 파일이나 오래된 수치 하나를 슬쩍 섞어서, 에이전트가 약속했던 기준을 그대로 붙잡는지 확인하는 것이죠. 이 시험을 통과하는 에이전트는 보고서가 깔끔해서가 아니라, 도중에 흔들릴 뻔하다가 스스로 기준을 되찾는 장면 때문에 신뢰가 갑니다.
눈과 손이 따로 놀면 무슨 일이 생길까
세 번째 눈금은 여러 양식과 도구를 함께 다루는 협응입니다. 문서와 표와 화면과 도구 호출이 서로 어긋나지 않고 맞물리는지를 봅니다. 요즘 에이전트는 읽는 일과 두드리는 일을 동시에 해야 해서 이 부분이 점점 중요해졌습니다.
이사 견적을 비교하는 작업을 예로 들어보죠. PDF 견적서 세 장과 웹 검색 결과와 계산기가 함께 동원됩니다. 에이전트가 PDF에서는 A업체의 보관료를 읽었으면서, 계산기에는 B업체의 숫자를 넣는 식으로 엇갈리면 최종 비교표는 깔끔해도 내용은 틀립니다. 눈과 손이 따로 노는 것이죠. 이런 실수는 최종 답만 보면 어디서 어긋났는지 알기 어렵습니다. 읽은 근거와 쓴 숫자를 단계별로 맞대봐야 비로소 드러나니까요.
실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 도구가 많아질수록 이런 엇갈림이 늘어나는데, 어떻게 묶어둘 수 있을까요. 논문은 도구 쪽에 걸 수 있는 제약을 실용적인 수단으로 꼽습니다. 호출 순서나 인자 범위를 미리 좁혀두면 엇갈릴 여지가 줄어드니까요. 대리 지표로는 근거와 행동의 일치가 쓰입니다. 인용한 문서 조각과 실제 호출 인자가 같은 대상을 가리키는지, 화면에서 본 값과 코드에 넣은 값이 같은지가 그 예입니다. 섭동 절차에서는 양식 하나를 살짝 비틉니다. 표의 열 순서를 바꾸거나 이미지 속 숫자를 텍스트와 다르게 배치해서, 에이전트가 어느 쪽을 믿고 어떻게 교차 확인하는지를 봅니다. 저는 이 장면을 볼 때마다 운전이 떠오릅니다. 백미러와 사이드미러와 내비게이션을 번갈아 보면서도 핸들은 한 방향으로 꺾어야 하는 일과 닮았거든요.

막히면 돌아갈 줄 아는 에이전트
네 번째 눈금은 적응적인 상호작용입니다. 막히거나 되돌아오거나 예상과 다른 답이 왔을 때, 에이전트가 다음 수를 바꾸는지를 봅니다. 계획이 처음부터 완벽할 수는 없으니, 이 능력은 현장에서 체감이 큽니다.
수요일 저녁에 식당 예약을 잡는 상황을 떠올려 보죠. 첫 번째 가게는 만석이고, 두 번째 가게는 영업시간이 끝났습니다. 좋은 에이전트는 여기서 멈추지 않고 조건을 넓힙니다. 시간을 30분 늦추거나 지역을 한 정거장 넓혀서 다시 묻죠. 반면 아쉬운 에이전트는 같은 질문을 같은 가게에 반복하거나, 실패했다는 말만 남기고 끝냅니다. 둘의 최종 성공 여부는 운에 따라 갈릴 수 있지만, 궤적의 모양은 완전히 다릅니다.
문제는 그다음입니다. 되묻기와 우회가 항상 좋은 것일까요. 무작정 다시 시도하는 것은 성실해 보이지만 비용만 키울 뿐입니다. 그래서 논문이 말하는 적응은 방향 없는 재시도가 아니라, 실패의 모양에 맞춘 수정을 뜻합니다. 대리 지표도 그 결을 따라갑니다. 오류 메시지를 읽고 인자를 고쳤는지, 같은 도구를 같은 값으로 반복하지 않았는지, 사람에게 물을 때 필요한 정보를 묶어서 물었는지가 그 예입니다. 섭동 절차에서는 일부러 막히는 구간을 만듭니다. 검색 결과가 비어 있거나 도구가 한 번 실패하게 두어서, 에이전트가 우회로를 찾는지를 봅니다. 여러분이라면 어떤 모습을 더 믿으시겠습니까. 한 번에 맞추는 모습보다, 막혔을 때 차분하게 돌아가는 모습이 저는 더 오래 기억에 남습니다.
스스로를 내려다보는 다섯 번째 눈
다섯 번째 눈금은 조금 결이 다릅니다. 앞의 네 가지가 계획과 기억과 도구와 흐름이 각자의 자리에서 잘 도는지를 본다면, 이 기준은 전체 실행을 위에서 내려다보며 스스로 점검하고 다잡는지를 봅니다. 논문이 따로 떼어 설명하는 이유도 여기에 있습니다.
밤늦게 보고서를 다 쓴 사람의 마지막 10분을 떠올려 보죠. 숫자의 합이 맞는지, 빠진 장은 없는지, 처음에 정한 분량과 어긋나지 않았는지를 훑습니다. 이 점검 때문에 보고서의 수준이 달라지죠. 에이전트도 실행 중간에 멈춰 서서 지금까지의 궤적을 돌아볼 수 있어야 합니다. 모순된 가정이 끼어 있지는 않은지, 도구가 뱉은 값이 상식에서 벗어나지 않았는지, 다음 단계로 가기 전에 무엇을 확인해야 하는지를 묻는 것이죠.
제가 이 논문에서 가장 흥미롭게 본 부분은 바로 이 대목과 세계 모형의 연결입니다. 에이전트가 세계에 대해 가진 그림이 또렷할수록 점검의 눈도 매서워진다는 설명인데, 저는 이 연결이 설득력 있다고 느꼈습니다. 가령 배송비에는 상한이 있고, 날짜에는 앞뒤 순서가 있다는 식의 그림이 있으면, 도구가 엉뚱한 숫자를 내놓았을 때 바로 멈칫할 수 있으니까요. 그래서 실용적인 수단으로 기호 검증기 같은 장치가 함께 거론됩니다. 규칙으로 확인할 수 있는 부분은 규칙으로 걸러내고, 애매한 판단만 모델에게 맡기는 것이죠. 대리 지표로는 중간 점검의 흔적이 쓰입니다. 스스로 세운 확인 항목이 있는지, 모순을 발견하고 계획을 고친 기록이 있는지가 그 예입니다. 섭동 절차에서는 일부러 작은 모순을 심어둡니다. 앞뒤가 맞지 않는 수치를 슬쩍 섞어서, 에이전트가 그냥 통과하는지 아니면 멈춰서 묻는지를 봅니다.

오래된 벤치마크에 새로운 눈금을 새기는 법
그렇다면 이미 널리 쓰이는 시험들은 어떻게 될까요. 논문은 기존 시험을 버리자는 쪽이 아니라, 그 위에 기준별 진단을 얹자는 쪽을 택합니다. 이름도 낯익은 GAIA와 SWE-bench와 WebArena와 TRIP-Bench가 그 예로 나옵니다. 각각 묻는 일은 다르지만, 모두 실행 과정을 남긴다는 점에서는 같습니다.
이 제안이 고마운 이유는 시험을 처음부터 다시 만들 필요가 없기 때문입니다. 이미 쌓인 과제와 실행 기록에 기준별 눈금만 덧대면, 어디서 자주 끊기는지가 보이기 시작합니다. 가령 어떤 시험에서는 시간적 이어짐이 자주 무너지고, 다른 시험에서는 도구 협응이 자주 어긋나는 식이죠. 저는 여기서 멈칫했습니다. 그동안 모델 순위를 가르는 데 쓰였던 숫자들이, 사실은 서로 다른 약점을 뭉뚱그린 평균이었을 수 있으니까요.
실제로 짓는 쪽으로 시선을 돌리면, 논문이 꼽은 수단들이 꽤 손에 잡힙니다. 구조화된 기억은 흩어지기 쉬운 약속을 붙잡아 두고, 계획과의 결합은 점검이 다음 행동으로 이어지게 돕고, 도구 쪽의 제약은 엇갈림을 미리 줄여주고, 기호 검증기는 확인할 수 있는 것을 가볍게 걸러줍니다. 어느 것도 거창한 새 모델을 요구하지 않는다는 점이 오히려 좋습니다. 평가 기준이 분명해지면, 그 기준을 통과하기 위한 작은 장치들을 하나씩 붙여볼 수 있으니까요. 여러분 팀의 에이전트가 자주 멈추는 시험이 있다면, 그 시험의 기록을 다섯 가지 눈금으로 다시 읽어보는 일이 다음 개선의 시작이 될 겁니다.

그래서 사람은 에이전트에게 무엇을 맡길까
마지막에 남는 질문은 사람의 자리입니다. 다섯 가지 눈금이 생기면 우리는 에이전트를 더 잘 고를 수 있을까요. 저는 그렇다고 봅니다. 다만 순위가 아니라 용도가 분명해진다는 뜻에서 그렇습니다.
어떤 에이전트는 문맥을 잘 읽어서 회의 준비나 고객 응대처럼 조건이 자주 바뀌는 일에 어울립니다. 다른 에이전트는 기억을 오래 붙잡아서 조사나 정리처럼 긴 호흡의 일에 어울리죠. 도구를 정확히 엮는 에이전트는 숫자를 다뤄야 하는 일에, 막혔을 때 돌아갈 줄 아는 에이전트는 바깥 세계와 부딪히는 일에 어울립니다. 그리고 스스로 점검하는 힘이 약한 에이전트는 사람이 마지막 눈으로 봐줘야 하는 일이 분명해집니다. 이렇게 보면 평가는 서열을 매기는 일이 아니라 일을 나누는 일이 됩니다.
물론 아직 모르는 것도 많습니다. 다섯 가지 눈금이 서로 겹치는 부분은 어떻게 다룰지, 어떤 흔들기 시험이 실제 현장의 어려움을 닮았는지, 작은 과제에서 통하는 장치가 큰 과제에서도 통하는지는 더 지켜봐야 합니다. 제가 앞으로 보고 싶은 것은 현장의 기록입니다. 연구실의 과제보다 지저분한 실제 업무에서, 이 눈금이 고장의 위치를 얼마나 정확히 가리키는지가 궁금하거든요. 그 증명이 쌓이면 에이전트에 대한 우리의 질문도 바뀔 겁니다. 잘했냐고 묻는 대신, 어디에서 어떻게 깊었냐고 묻게 될 테니까요. 그렇다면 여러분은 지금 쓰는 에이전트에게 어떤 일을 맡기고 어떤 일은 직접 보고 계신가요.
