긴 작업을 끝까지 본다는 것, AgentHorizon이 agentic judge에게 던진 질문

arXiv 식별자 2610.11050으로 공개된 AgentHorizon: Evaluating Agentic Judges for Long-Horizon Computer-Use Tasks는 긴 컴퓨터 사용 작업을 평가하는 agentic judge를 정면으로 다룹니다. 이 연구가 내세우는 주장은 한 문장으로 정리됩니다. 화면과 행동이 수백 단계로 이어지는 실제 컴퓨터 작업에서, 성공처럼 보이는 궤적이 실제로는 제약을 어겼을 수 있기에 judge를 가리는 별도의 눈이 필요하다는 것입니다. 원문 링크는 제목 아래에 걸어 두었습니다.

제가 이 논문을 집어 든 이유는 조금 개인적입니다. 평소 에이전트 데모를 보면 마지막 화면만 그럴듯하면 박수가 나오는데요. 저는 그럴 때마다 마음 한구석이 불편했습니다. 마지막 화면이 맞았다고 해서 과정 전체가 맞았다는 뜻은 아니니까요. 사람이 엑셀에서 숫자를 하나 잘못 옮기고도 겉으로는 완성된 표를 내놓을 수 있듯이, 에이전트도 겉보기에는 멀쩡한 궤적을 남기면서 어딘가에서 지시를 어길 수 있습니다. 그렇다면 누가 그 어긋남을 잡아낼까요. 이번 글에서는 그 질문을 따라가 보려 합니다.

왜 마지막 화면만으로는 부족할까

컴퓨터를 쓰는 에이전트의 일은 챗봇의 답변과 결이 다릅니다. 하나의 답을 내놓고 끝나는 게 아니라 여러 앱을 오가며 클릭하고 입력하고 기다렸다가 다시 확인하죠. 그러다 보면 궤적이 길어집니다. AgentHorizon이 다루는 궤적은 최대 300개의 스크린샷과 행동까지 이어지는데, 이 길이는 생각보다 중요합니다. 짧은 과제에서는 마지막 상태만 봐도 성공 여부를 가릴 수 있지만, 긴 과제에서는 중간에 어긴 제약이 마지막 화면에 남지 않기 때문입니다.

예를 들어 월요일 아침을 떠올려 보시죠. 누군가에게 항공권과 호텔을 예약해 달라고 부탁했는데, 결과 메일에는 예약 번호가 잘 적혀 있습니다. 그런데 알고 보니 날짜가 하루 어긋나 있거나, 결제를 두 번 눌렀거나, 회사 계정이 아니라 개인 계정으로 로그인해서 예약했다면 어떨까요. 겉으로는 끝난 일처럼 보여도 실제로는 실패한 일입니다. 에이전트의 긴 궤적도 마찬가지인데요. 화면이 길게 이어질수록 이런 어긋남이 어딘가에 숨어들 자리가 늘어납니다.

그래서 자동 judge가 필요해졌다는 게 이 연구가 깔고 있는 출발점입니다. 사람이 166시간 분량의 궤적을 일일이 돌려보며 성공과 실패를 가릴 수는 없으니까요. 그런데 여기서 재미있는 질문이 생깁니다. 에이전트가 일을 잘하는지와 judge가 그 일을 가려내는 능력은 같은 능력일까요. 저는 이 두 능력이 다르다는 데에 이 논문의 출발점이 있다고 봅니다.

1,373개의 과제 쌍이 말해주는 것

AgentHorizon은 1,373개의 컴퓨터 사용 과제를 모았습니다. 하나하나가 지시문과 궤적의 쌍으로 되어 있고, 바탕에는 사람이 직접 기록한 166시간 분량의 궤적이 있습니다. 숫자를 그냥 읽으면 크게 와닿지 않는데요. 166시간을 일하는 시간으로 바꾸면 거의 한 달 치의 온전한 노동에 가깝습니다. 누군가 실제로 마우스를 움직이고 키보드를 두드리며 앱을 오간 시간이 그만큼 쌓였다는 뜻이죠.

그런데 이 데이터의 진짜 장치는 양이 아니라 만드는 방식에 있습니다. 연구진은 서로 가깝게 관련된 지시문에 대해 궤적을 나란히 기록한 뒤, 지시문을 맞바꿔서 부정 과제(negative task)를 만들었습니다. A라는 일을 한 궤적에 B라는 지시문을 붙이는 식이죠. A와 B가 서로 비슷하게 생겼기에, 궤적만 얼핏 보면 성공한 것처럼 보입니다.

이 방식이 마음에 드는 이유는 시험이 꽤 짓궂기 때문입니다. 쉬운 시험이라면 엉뚱한 궤적을 보여주고 실패라고 답하라고 요구했겠죠. 하지만 여기서는 성공한 궤적을 보여주면서 묻습니다. 이 궤적은 주어진 지시문을 이룬 게 맞을까, 아니면 옆에 있던 비슷한 지시문을 이룬 걸까. 궤적이 그럴듯하다는 인상만으로는 통과할 수 없는 문제입니다. 사람으로 치면 쌍둥이 형제의 숙제를 바꿔 들고 와서 어느 쪽이 누구 숙제인지 가려내는 일에 가깝습니다.

비슷해서 더 어려운 함정을 왜 팠을까

그렇다면 왜 굳이 이렇게까지 비슷한 함정을 팠을까요. 이유는 긴 궤적이 주는 착시에 있습니다. 화면이 수십 장, 수백 장으로 이어지면 읽는 쪽은 지치게 마련인데요. 대충 훑어보면 다 한 것 같고, 마지막 화면까지 열려 있으면 성공이라고 도장을 찍고 싶어집니다. judge 모델도 같은 유혹에 빠질 수 있습니다.

짝지은 설계(paired design)는 그 유혹을 정면으로 건드립니다. 궤적은 실제로 누군가 완수한 것이라서 군더더기가 없고, 지시문만 살짝 어긋나 있습니다. 그래서 judge는 궤적의 완성도가 아니라 지시문과 궤적 사이의 정합성을 봐야 합니다. 요청을 이루었는지가 아니라, 이 요청을 이루었는지를 묻는 것이죠.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 부정 과제를 인위로 망가뜨린 궤적으로 만들 수도 있었을 텐데, 연구진은 그러지 않았습니다. 멀쩡한 성공 궤적을 가져다 놓고 지시문을 바꾼 것입니다. 실패를 흉내 낸 게 아니라 성공의 주소를 바꾼 셈인데, 이 선택 덕분에 judge는 겉모습이 아니라 관계를 읽어야 합니다. 실제 운영에서도 에이전트가 일을 그럴듯하게 끝냈는데 알고 보니 옆길로 샌 경우가 가장 찾기 어렵다는 점을 떠올리면, 이 설계는 현실에 꽤 가깝습니다.

세 개로 쪼갠 이유가 궁금해지는 지점

AgentHorizon은 통으로 하나가 아니라 세 갈래로 나뉘어 공개됐습니다. AgentHorizon(AH)과 AgentHorizon-Simple(AH-S), 그리고 AgentHorizon-Development(AH-D)가 그것인데요. 처음에는 왜 굳이 나눴을까 싶었습니다. 하나로 합쳐서 크게 내놓는 게 더 시원해 보이니까요.

그런데 갈래를 나누는 데에는 나름의 쓰임이 있습니다. 어려운 본 시험과 가벼운 시험, 그리고 개발 과정에서 만지작거릴 수 있는 분할을 따로 두면 연구자와 실무자가 각자 속도에 맞춰 쓸 수 있죠. 가벼운 분할에서 감을 잡고 개발용 분할에서 조정해 본 뒤에 본 시험에서 점수를 매기는 흐름이 자연스럽습니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 분할이 셋이라고 해서 셋 다 같은 질문을 묻는 건 아니기 때문입니다. 이름만 보면 단순한 버전이 쉬운 문제 모음처럼 들리지만, 실제로는 평가의 목적이 조금씩 다릅니다. 어떤 분할은 빠르게 돌려보며 아이디어를 시험하는 데 쓰고, 어떤 분할은 최종 판정에 가깝게 씁니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 분할을 고르는 일도 같은 눈으로 봐야 합니다. 어떤 점수를 인용하더라도 그 점수가 어느 분할에서 나온 것인지가 함께 따라다녀야 하죠.

세 운영체제에 걸친 궤적이라는 말의 무게

이 벤치마크는 세 개의 운영체제에 걸쳐 있습니다. 한 운영체제에서만 돌려본 결과와 여러 운영체제에서 돌려본 결과는 읽는 맛이 다른데요. 버튼의 위치도 다르고, 단축키도 다르고, 파일 대화상자가 뜨는 타이밍도 다릅니다. 같은 지시문이라도 환경이 바뀌면 궤적의 모양이 달라집니다.

문제는 그다음입니다. judge가 특정 환경의 겉모습에 과적합되면 다른 환경에서는 눈이 흐려질 수 있습니다. 예를 들어 특정 팝업의 생김새만 외워서 성공을 판정하던 judge는, 운영체제가 바뀌어 팝업 모양이 달라지면 멀쩡한 성공을 실패로 찍을 수 있죠. 세 환경을 아우른다는 건 그래서 장식용 조건이 아닙니다. judge가 화면의 생김새가 아니라 작업의 성취를 읽는지를 가리는 장치에 가깝습니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 우리 제품의 에이전트가 윈도우에서만 돌아간다면 세 환경 평균 점수가 무슨 소용일까요. 반대로 여러 환경에서 돌아가야 한다면 평균보다 환경별 편차가 더 중요하지 않을까요. 논문이 던진 조건을 받아서 각자 환경에 맞게 다시 묻는 일이 남습니다. 평균 점수 뒤에 숨은 편차를 보는 습관이 여기서도 필요합니다.

통째로 읽는 심사와 도구 들고 다니는 심사

평가 방식도 두 갈래입니다. 하나는 전체 궤적을 judge에게 통째로 넘겨서 판정하게 하는 방식이고, 다른 하나는 judge를 코딩 에이전트처럼 다섯 가지 하네스 위에 올려서 도구 사용과 함께 판정하게 하는 방식입니다. 열한 개의 judge가 두 방식 모두에서 시험됐는데요. 같은 judge라도 읽는 방식이 바뀌면 성적이 달라질 수 있다는 게 이 비교의 요지입니다.

통째로 읽는 방식은 시험지를 통째로 받아 들고 채점하는 일에 가깝습니다. 최대 300개의 스크린샷과 행동이 한 번에 들어오니 맥락이 끊기지 않는다는 장점이 있습니다. 반면 도구 쓰는 방식은 심사관이 직접 서랍을 열어보는 일과 비슷합니다. 필요한 부분을 찾아서 확대하고, 파일을 뒤지고, 기록을 훑으면서 판정하죠. 전자는 한 번에 많이 보고, 후자는 필요한 만큼만 골라 봅니다.

저는 여기서 조금 멈칫했습니다. 보통은 도구를 주면 성적이 오를 것 같잖아요. 눈이 닿지 않는 곳까지 뒤질 수 있으니까요. 그런데 이 논문의 이야기는 그렇게 단순하지 않습니다. 도구가 어떤 모델에게는 날개가 되지만 다른 모델에게는 짐이 됩니다. 그래서 다음 대목이 중요해집니다. 도구가 만능이 아니라면, 무엇이 갈림길을 만들까요.

80.9라는 숫자 앞에서 잠시 멈추기

본 시험인 AH 분할에서 가장 성적이 좋았던 agentic judge는 GPT-5.5로, balanced accuracy 80.9퍼센트를 기록했습니다. 열한 개 가운데 1등이라는 점과 80점대 초반이라는 점이 함께 눈에 들어오는데요. 이 숫자를 어떻게 읽어야 할까요.

일단 80.9퍼센트는 절반 찍기보다야 훨씬 낫지만, 심판자로 쓰기에는 여전히 불안한 구석이 있습니다. 다섯 번 가운데 한 번꼴로 판정을 그르친다는 뜻이니까요. 특히 judge의 오답은 그냥 틀린 답이 아니라 시스템 전체로 번지는 씨앗입니다. 성공을 실패로 찍으면 멀쩡한 일을 버리게 되고, 실패를 성공으로 찍으면 어긋난 일을 통과시키게 됩니다. 어느 쪽이든 비용이 따릅니다.

그렇다면 1등 모델조차 20퍼센트 가까이 틀린다는 사실은 무엇을 뜻할까요. 저는 이 대목을 에이전트는 되는데 심판은 안 되는 구간이라고 읽었습니다. 일을 하는 에이전트는 점점 길어지는 궤적을 내놓는데, 그 궤적을 가려내는 눈은 아직 그 속도를 따라가지 못한다는 것이죠. 데모에서는 에이전트의 성공 장면만 보이지만, 운영에서는 그 성공을 판정하는 눈까지 함께 사야 합니다. 80.9라는 숫자는 그래서 축하할 점수라기보다 남은 숙제를 보여주는 점수에 가깝습니다.

도구가 어떤 모델에게는 짐이 된다

아까 미뤄둔 이야기로 돌아올 차례입니다. 도구 사용은 어떤 모델의 성적을 끌어올렸지만, 공개 가중치(open-weight) 모델에서는 오히려 성적을 끌어내렸습니다. 같은 도구를 손에 쥐여 줬는데 결과가 정반대로 갈린 것이죠.

이유는 단정하기 어렵지만, 그림은 그려볼 수 있습니다. 도구를 쓴다는 건 판정이라는 본업 외에 탐색이라는 부업까지 떠안는 일입니다. 어디를 봐야 할지 정하고, 도구를 고르고, 돌아온 결과를 읽어서 다음 탐색으로 이어야 하죠. 이 과정이 매끈하게 이어지면 시야가 넓어지지만, 한 고리라도 어긋나면 오히려 시간을 쓰고 눈을 흐립니다. 체력이 되는 모델은 부업을 소화하고, 아직 무거운 모델은 본업까지 흔들리는 셈입니다.

(괄호를 열고 덧붙이자면, 저는 이 대목에서 예전의 멀티홉 검색 실험이 떠올랐습니다. 검색기를 달면 답이 좋아질 줄 알았는데, 검색 결과를 못 고르는 모델은 오히려 헛다리를 짚던 경우가 있었죠. 도구가 정보를 주는 동시에 복잡도라는 세금도 함께 매기기 때문입니다.)

여기서 한 걸음 더 들어가면 하네스 차이도 궁금해집니다. 다섯 가지 하네스 위에서 성적이 어떻게 갈렸는지가 공개되면, 어떤 탐색 방식이 긴 궤적 심사에 어울리는지가 드러날 테니까요. 지금은 방향만 보입니다. 도구는 약이 아니라 처방이라는 것, 누구에게나 같은 용량이 통하지 않는다는 것입니다.

받아들이는 눈과 걸러내는 눈은 다르다

이 논문에서 제가 가장 흥미롭게 본 부분은 정답을 받아들이는 능력과 오답을 거르는 능력 사이의 간극입니다. 유효한 궤적을 성공이라고 인정하는 일과 실패한 궤적을 실패라고 찍어내는 일이 서로 다르게 움직인다는 것이죠. 어떤 judge는 관대해서 성공을 잘 알아맞히지만 실패를 흘려보내고, 어떤 judge는 엄격해서 실패는 잘 잡지만 멀쩡한 성공까지 의심합니다.

생각해보면 사람도 비슷하게 배웁니다. 칭찬에 후한 선생님과 감점에 후한 선생님이 같은 시험지를 다르게 채점하듯이, judge도 기질 같은 게 있습니다. 문제는 운영에서는 두 눈이 다 필요하다는 점입니다. 성공을 알아봐야 에이전트의 진짜 진전을 재고, 실패를 잡아내야 사고를 막을 수 있으니까요. 한쪽만 좋은 judge는 저울 한쪽이 기울어진 셈입니다.

balanced accuracy라는 잣대를 쓴 이유도 여기에 있습니다. 성공 쪽 정확도와 실패 쪽 정확도를 함께 보지 않으면, 관대한 judge가 점수를 부풀릴 수 있기 때문입니다. 숫자 하나를 볼 때도 그 안에 두 눈이 균형 있게 들어 있는지를 따지는 것이죠. 실무에서 judge를 고를 때도 같은 질문을 던져야 합니다. 우리 시스템에서 더 아픈 쪽은 어느 쪽일까. 멀쩡한 일을 버리는 게 아픈지, 어긋난 일을 통과시키는 게 아픈지 말이죠. 답에 따라 골라야 할 judge의 기질이 달라집니다.

그래서 이 눈을 어디에 써야 할까

앞에서 본 조각들을 한데 모아보죠. 짝지은 함정, 세 운영체제, 통째로 읽기와 도구 쓰기의 대조, 80.9퍼센트라는 천장, 도구 사용의 엇갈림, 받아들이기와 걸러내기의 간극까지 말이죠. 그렇다면 이 모든 장치는 결국 무엇을 묻고 있을까요.

저는 이 벤치마크가 묻는 게 모델 순위가 아니라 운영의 전제라고 봅니다. 긴 컴퓨터 작업을 에이전트에게 맡기겠다는 결정은, 그 작업을 판정할 눈까지 함께 두겠다는 약속과 한 묶음이니까요. 눈 없이 손만 두면 겉보기 성공이 쌓이고, 그 쌓인 성공 위에서 다음 자동화가 춤을 추게 됩니다. 작은 어긋남이 복리로 불어나는 구조죠.

실무의 언어로 바꾸면 이야기는 더 또렷해집니다. 밤사이 에이전트가 수백 단계짜리 정산 작업을 돌렸다고 해보죠. 아침에 사람이 300개 화면을 다 돌려볼 수는 없습니다. 결국 judge의 도장을 믿고 넘어가야 하는데, 그 도장의 적중률이 80퍼센트 언저리라면 나머지 20퍼센트를 어떻게 다룰지가 설계의 본질이 됩니다. 중요한 단계에만 사람을 끼워 넣을지, 제약을 기계적으로 검사하는 룰을 곁들일지, 아니면 궤적을 짧게 쪼개서 판정의 단위를 낮출지 같은 선택이 뒤따릅니다. 이 논문은 그 선택을 피할 수 없게 만듭니다. 눈의 한계를 숫자로 보여줬으니까요.

앞으로 무엇을 더 봐야 할까

남은 질문도 꽤 있습니다. 300개 화면까지 이어지는 궤적을 통째로 읽는 방식은 컨텍스트가 길어질수록 비용이 불어나는데, 어디까지가 감당 가능한 길일까요. 도구 쓰는 방식은 비용을 아낄 수 있지만 탐색이 빗나가면 눈이 흐려지는데, 어떤 하네스가 그 빗나감을 덜어줄까요. 공개 가중치 모델의 하락은 도구 사용법의 문제인지, 긴 시각 맥락을 읽는 능력 자체의 문제인지도 가려지지 않았습니다.

표면적으로 보면 단순합니다. judge가 일을 잘 가려내면 된다는 이야기니까요. 실제로는 그렇지 않습니다. 가려낸다는 말 안에는 지시문 이해, 화면 읽기, 행동 해석, 제약 대조라는 여러 층이 겹쳐 있으니까요. 어느 층에서 눈이 흐려지는지를 층별로 뜯어보는 후속 연구가 붙어야 이 벤치마크가 더 단단해질 것 같습니다.

제가 앞으로 보고 싶은 것은 실패의 지도입니다. 어떤 종류의 어긋남이 가장 잘 빠져나가는지, 날짜처럼 작은 디테일인지, 계정처럼 맥락적인 제약인지, 아니면 여러 앱에 걸친 정합성인지 말이죠. 그 지도가 그려지면 judge를 통째로 키우는 대신 약한 고리를 보강하는 처방도 가능해집니다. 무엇보다 그 지도 위에서야 80.9라는 숫자가 다음 목표를 가리킬 수 있습니다. 점수 자체보다 점수가 가리키는 방향이 중요하니까요.

그렇다면 사람의 역할은 무엇일까요. 긴 궤적을 사람이 다 보는 시대는 이미 지났고, 눈에 전적으로 맡기기에도 아직 이른 구간에 우리는 서 있습니다. 저는 그래서 당분간은 사람이 심판이 아니라 심판의 설계자가 되어야 한다고 봅니다. 함정이 될 만한 짝을 미리 심어두고, 관대함과 엄격함의 균형을 용도에 맞게 고르고, 도장을 믿되 검증할 지점을 남겨두는 일 말이죠. AgentHorizon이 남긴 가장 단단한 문장은 점수가 아니라 그 설계도의 필요성이라고 생각합니다.