오래 일하는 에이전트를 재는 법, 터미널에서 세 시간 버티기

Long-Horizon-Terminal-Bench 2.0: Automating Diverse Task Construction and Measuring Sustained Agent Progress는 arXiv 식별번호 2610.14146으로 공개된 터미널 에이전트 평가 연구입니다. 원문 링크는 제목 아래에 걸려 있습니다. 이 연구가 내세우는 주장은 한 문장으로 정리됩니다. 돌아가는 과학 공학 결과물에서 과제를 자동으로 뽑아내고, 부분 진행까지 점수로 주면서, 세 시간 동안 에이전트가 어디까지 꾸준히 나아가는지 재겠다는 것입니다.

짧은 질문에는 잘 답하던 모델이 막상 터미널 앞에 오래 앉으면 흐트러지는 장면을 저는 여러 번 봤습니다. 처음에는 명령어도 잘 치고 파일도 잘 찾다가, 한 시간쯤 지나면 같은 실수를 반복하거나 이전에 확인한 내용을 다시 묻기 시작하죠. 그래서 이 논문을 처음 펼쳤을 때 저는 반가우면서도 경계하는 마음이었습니다. 또 하나의 점수표가 나온 것일까, 아니면 오래 일하는 모습을 실제로 볼 수 있게 해주는 도구가 나온 것일까 궁금했기 때문입니다.

왜 긴 작업을 재는 일이 따로 필요해졌을까요

여러 사람이 함께 일하다 보면, 잠깐 잘하는 것과 오래 잘하는 것은 전혀 다른 문제라는 것을 알게 됩니다. 그렇다면 터미널에서 일하는 AI 에이전트에게도 같은 질문을 던질 수 있지 않을까요.

짧은 벤치마크는 시작이 좋습니다. 명령어 하나, 함수 하나로 끝나는 과제에서는 최근 모델들이 놀라울 정도로 정확합니다. 그런데 실제 터미널 작업은 그렇게 끝나지 않는데요. 의존성을 깔아야 하고, 데이터 경로를 맞춰야 하고, 중간에 깨진 스크립트를 고쳐야 하고, 로그를 읽고 다시 시도해야 합니다. 이 과정이 30분을 넘기기 시작하면 평가는 정확도 싸움이 아니라 지속력 싸움으로 바뀝니다. 어디에서 막혔는지 기억하는지, 막힌 지점을 돌아가는 방법을 찾는지, 앞선 시도의 흔적을 다음 시도에 남기는지가 점수를 가릅니다.

제가 이 논문에서 가장 먼저 눈이 간 부분은 바로 이 문제의식입니다. 연구진은 긴 터미널 벤치마크를 과정에 대한 보상을 함께 재는 장치로 설명합니다. 최종 결과만 맞았는지 보는 것이 아니라, 확장된 워크플로를 통과하면서 진척을 유지할 수 있는지 본다는 것이죠. 생각해보면 사람도 비슷하게 배웁니다. 시험 한 번 잘 보는 것과 프로젝트를 석 달 끌고 가는 것은 다른 근육을 쓰니까요. 일종의 마라톤 기록지처럼요. 결승선 통과 여부만 적는 것이 아니라, 10킬로 지점마다 페이스가 어땠는지 함께 적는 방식입니다.

그런데 여기서 재미있는 질문이 생깁니다. 긴 작업을 잰다고 말은 많은데, 실제로 긴 작업을 자동으로 많이 만들 수 있을까요. 사람이 하나하나 과제를 손으로 깎으면 다양성도 떨어지고 비용도 커집니다. 이 논문은 그래서 측정 방식만큼이나 과제 만드는 방식에 공을 들였습니다. 뒤에서 살펴볼 재구성 파이프라인이 바로 그 대답입니다.

46개를 살리면서 31개를 더한 이유가 궁금했습니다

LHTB 2.0은 기존 과제 46개를 버리지 않았습니다. 대신 과제와 평가 인프라에 있던 결함을 고치고, 31개 과제를 새로 더해 모두 77개 과제로 넓혔습니다. 숫자만 보면 46 더하기 31은 77이라서 단순한 확장처럼 보이는데요. 실제로는 그렇지 않습니다.

기존 벤치마크를 개정할 때 가장 어려운 결정은 무엇을 버릴지입니다. 처음부터 다시 만들면 깨끗해 보이지만, 이전 세대 모델과 비교하던 연속성이 끊깁니다. 반대로 낡은 과제를 그대로 두면 결함까지 유산으로 남습니다. 연구진은 첫 번째와 두 번째 사이를 골랐습니다. 46개를 살리되 고치고, 31개를 덧붙인 것이죠. 저는 이 선택에서 실무적인 감각을 느꼈습니다. 저희가 새로운 AI 아키텍처를 볼 때도 점수 하나만 보지 않습니다. 무엇이 유지됐고 무엇이 바뀌었는지, 그 변화가 측정 연속성에 어떤 영향을 주는지를 함께 보니까요.

새로 합쳐진 전체는 13개 도메인과 여덟 가지 과제 유형으로 구성됩니다. 도메인이 넓다는 말은 문제가 여러 분야에 걸쳐 있다는 뜻인데요. 과학 계산부터 공학 작업까지 터미널에서 실제로 벌어지는 일을 담으려는 의도가 읽힙니다. 유형이 여덟 가지라는 점도 눈에 띕니다. 같은 터미널이라도 파일 편집이 주가 되는 일과, 실행과 디버깅이 주가 되는 일은 에이전트에게 요구하는 습관이 다르니까요.

문제는 그다음입니다. 77개라는 숫자는 충분할까요. 솔직히 말하면 어떤 벤치마크도 현실의 터미널을 전부 담지는 못합니다. 다만 다양성을 의도적으로 설계했다는 점에서 저는 이번 확장을 좋게 봤습니다. 무작정 개수를 불린 것이 아니라, 결함을 고치는 작업과 새 과제를 더하는 작업을 함께 묶었기 때문입니다. 점수 인플레이션을 막으면서 측정 범위를 넓히려는 시도죠. 이 판단이 실제로 통했는지는 뒤에 나오는 측정 결과를 보면 가늠할 수 있습니다.

돌아가는 결과물에서 거꾸로 문제를 만드는 방법

제가 이 논문에서 가장 흥미롭게 본 부분은 확장 과제를 만드는 절차입니다. 연구진은 작동하는 과학 공학 아티팩트에서 출발하는 체계적인 재구성 과제 파이프라인을 제안합니다. 이미 돌아가는 결과물이 있다는 전제가 깔려 있는데요. 논문 속 실험 코드나 공학 스크립트처럼, 실행하면 결과가 나오는 출발점이 있다는 것입니다.

과정을 따라가 보면 흐름이 꽤 직관적입니다. 먼저 기준이 되는 구현을 매개변수화합니다. 입력 조건이나 상수, 데이터 범위를 바꿀 수 있게 손잡이를 다는 셈이죠. 그런 다음 이 손잡이를 돌려 여러 시나리오를 뽑아냅니다. 같은 뼈대 위에서 조건만 바꾼 변형 문제들을 만드는 것입니다. 학생 시절로 치면 선생님이 모범 답안 하나를 들고 숫자만 바꿔 문제지를 여러 장 만드는 모습과 비슷합니다. 다만 여기서는 숫자 바꾸기를 넘어서, 에이전트가 실제로 터미널에서 부딪힐 만한 형태로 변형을 빚어냅니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 자동으로 문제를 뽑아낸다고 해서 모두 좋은 문제가 되는 것은 아니기 때문입니다. 매개변수를 바꾸다 보면 너무 쉬워지거나, 반대로 의도와 다르게 너무 어려워지는 시나리오가 섞일 수 있습니다. 연구진이 파이프라인을 체계적이라고 부르는 이유는 그래서입니다. 무작정 뽑아내는 것이 아니라, 작동하는 출발점에서 변형을 만들고, 행동 증거로 쓸 것과 평가용으로 쓸 것을 나누는 규칙을 두었다는 것이죠. 이 규칙이 있어야 자동 생성이라는 말이 구호에 그치지 않습니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이렇게 만든 과제가 매번 처음부터 헤매는 에이전트만 만드는 것은 아닐까 하는 점입니다. 좋은 재구성 과제라면 에이전트가 맨땅에서 삽질만 하다가 끝나지 않고, 중간중간 단서를 잡고 앞으로 나갈 수 있어야 합니다. 뒤에 나오는 단계별 사다리와 30분 간격 점검이 바로 이 걱정에 대한 답으로 이어집니다. 과제를 만드는 일과 진행을 재는 일이 서로 맞물려 있다는 점이 이 논문의 짜임새입니다.

아홉 개 중 여섯 개를 보여주고 세 개를 숨기는 이유

재구성 파이프라인에서 숫자로 가장 기억에 남는 대목은 여섯과 세 개입니다. 연구진은 매개변수화된 기준 구현에서 여러 시나리오를 만든 뒤, 여섯 개를 행동 증거로 공개하고 세 개는 평가용으로 따로 둡니다. 아홉 개 중 여섯 개는 보여주고 세 개는 숨기는 셈이죠.

왜 이렇게 나눌까요. 에이전트에게 예시를 보여줘야 한다는 점과, 답을 외워버리면 안 된다는 점이 동시에 걸리기 때문입니다. 여섯 개 공개 시나리오는 일종의 행동見本이 아니라 행동 증거입니다. 이런 식으로 입력이 바뀌면 출력도 이렇게 바뀌어야 한다는 것을 에이전트가 관찰할 수 있게 해줍니다. 반면 숨겨둔 세 개는 실제 채점표입니다. 공개된 것만 외워서는 풀 수 없게 막는 장치죠.

저는 여기서 오래된 시험 문제를 떠올렸습니다. 연습문제와 본고사가 같은 유형이되 같은 문제는 아닌 경우입니다. 연습문제를 충분히 풀어보면 본고사 유형에 익숙해지지만, 연습문제 답을 그대로 외운다고 본고사가 맞지는 않습니다. 이 구조는 자동 생성 과제에서 특히 중요합니다. 시나리오를 기계적으로 뽑아내다 보면 패턴이 남기 쉬운데, 평가용을 따로 숨겨두면 그 패턴을 외우는 shortcut이 통하지 않기 때문입니다.

그렇다면 여섯 대 세 개라는 비율은 어떻게 봐야 할까요. 공개가 너무 많으면 유출 걱정이 커지고, 비공개가 너무 많으면 에이전트가 무엇을 해야 할지 감을 잡기 어렵습니다. 연구진이 택한 6대 3은 행동을 보이기에는 충분하고, 외우기에는 부족한 지점을 노린 것으로 읽힙니다. 물론 이 비율이 모든 도메인에 똑같이 맞는지는 앞으로 더 따져볼 문제입니다. 도메인에 따라 변형의 폭이 다르니까요. 그럼에도 방향은 분명합니다. 보여줄 것은 보여주되, 재는 자는 따로 두겠다는 것입니다.

부분 점수가 있어야 끝까지 가는 모습이 보입니다

긴 작업을 평가할 때 통과 아니면 실패로만 가르면 어떤 일이 생길까요. 거의 다 해놓고 마지막 명령어 하나에서 미끄러진 에이전트와, 시작부터 방향을 못 잡은 에이전트가 같은 점수를 받습니다. 두 기록을 같은 실패로 묶어버리면, 에이전트가 어디까지 갔는지에 대한 정보가 사라지죠.

연구진이 도입한 단계별 보상 사다리는 이 문제를 직접 겨냥합니다. 부분 진행에 점수를 주되, 공개된 출력물을 외우는 일은 막겠다는 설계입니다. 사다리라는 비유 그대로, 한 칸씩 오를 때마다 발판이 확인되는 구조인데요. 최종 발판에 올라서지 못해도 몇 번째 발판까지 갔는지가 남습니다. 그래서 실패에도 밀도가 생깁니다. 어디에서 멈췄는지가 보이니까요.

이 차이는 생각보다 큽니다. 표면적으로 보면 점수를 후하게 주는 장치 같지만, 실제로는 측정 해상도를 높이는 장치에 가깝습니다. 30개 재구성 과제에서 이진 검증 점수 평균은 0.221에 그쳤지만, 단계별 사다리 점수 평균은 0.653까지 올라갔다는 대목이 바로 그 증거입니다. 같은 실행인데도 재는 자를 바꾸자 모습이 달라진 것이죠. 결과만 보면 다섯 중 하나만 건진 것처럼 보이지만, 과정을 보면 절반 이상을 밟아 올라갔다는 말이 됩니다.

(참고로 이 간극을 처음 봤을 때 저는 잠깐 멈칫했습니다. 점수가 후해졌다는 오해를 살 수 있기 때문입니다. 그런데 곰곰이 보면 후하다기보다 정직하다는 표현이 더 어울립니다. 최종 통과 여부를 넘어서 어디까지 왔는지를 함께 적는 쪽이 에이전트의 지속력을 더 잘 설명하니까요.)

여기서 한 가지 덧붙이고 싶은 점은 외움 방지와의 연결입니다. 부분 점수를 주면서도 공개 출력 암기를 막는다는 것은, 사다리의 발판이 단순한 문자열 매칭이 아니라는 뜻입니다. 중간 발판마다 확인하는 방식이 있어야 에이전트가 공개 시나리오를 베껴 붙이는 것만으로 점수를 쌓지 못합니다. 이 설계가 있어야 자동 생성과 부분 보상이 함께 굴러갑니다. 하나만 있으면 다른 하나가 흔들리기 때문입니다.

90분에서 세 시간으로 늘리면 무엇이 달라질까요

LHTB 2.0은 평가 시간을 90분에서 세 시간으로 늘렸습니다. 두 배로 늘린 셈인데요. 동시에 30분마다 검증 지점을 기록합니다. 세 시간이면 모두 여섯 번의 중간 기록이 남습니다. 이 결정은 단순히 시간을 넉넉히 주는 차원을 넘습니다.

90분 안에 끝나는 과제와 세 시간이 걸리는 과제는 요구하는 습관이 다릅니다. 90분짜리는 몰아붙이기로 풀 수 있습니다. 로그를 꼼꼼히 안 읽어도 감으로 밀어붙이면 운 좋게 통과하기도 하죠. 하지만 세 시간이 되면 이야기가 달라집니다. 중간에 한 번은 막히게 되어 있고, 막힌 지점을 메모해두지 않으면 같은 곳에서 다시 헤맵니다. 저는 이 대목을 읽으면서 야간 장애 대응을 떠올렸습니다. 새벽 두 시에 시작된 장애가 아침 여섯 시까지 이어지면, 결국 버티는 것은 화려한 명령어가 아니라 기록 습관이니까요. 무엇을 시도했고 무엇을 확인했는지 남기는 사람이 끝까지 갑니다.

30분 간격 점검은 그래서 마라톤의 계측 매트와 비슷합니다. 출발과 결승만 재는 것이 아니라, 중간 지점마다 통과 시각을 찍는 것이죠. 이 기록이 있으면 에이전트가 언제 속도를 냈고 언제 헤맸는지가 드러납니다. 초반 30분에 빠르게 치고 나가다 중반에 멈추는 유형과, 느리게 시작해 꾸준히 올라가는 유형이 구분됩니다. 에이전트 개발자 입장에서는 어디를 고쳐야 할지 알려주는 단서가 됩니다. 무엇을 못했는지가 아니라 언제 무너졌는지가 보이니까요.

그렇다면 세 시간이라는 길이는 충분할까요. 현실의 터미널 작업 중에는 며칠씩 이어지는 일도 있습니다. 그런 점에서 세 시간도 여전히 짧은 편입니다. 다만 측정 비용을 생각하면 이해가 갑니다. 1,145번의 실행을 세 시간씩 돌리는 것만으로도 계산량이 상당하니까요. 연구진이 90분에서 세 시간으로 끊은 것은 현실성과 비용 사이의 절충으로 읽힙니다. 이 절충이 적절한지는 앞으로 더 긴 지평 실험이 나올 때 다시 따져보면 됩니다.

1,145번의 실행이 말해주는 현재 위치

숫자가 많은 논문은 읽기가 수월하면서도 어렵습니다. 수월한 이유는 비교할 거리가 분명하기 때문이고, 어려운 이유는 숫자 뒤의 조건을 놓치기 쉽기 때문입니다. 이번 논문의 중심 숫자는 15개 프론티어 모델에서 모은 1,145번의 점수 기록입니다. 과제 하나당 한 번씩이 아니라, 여러 모델과 여러 과제를 곱한 실행 기록이라는 점이 먼저 눈에 띕니다.

그중 가장 앞선 이름은 GPT-6-astra입니다. 단계별 평균 보상이 0.69였고, 보상 0.95 이상인 과제가 37개였습니다. 77개 과제 중 37개에서 거의 완성에 가깝게 올랐다는 뜻인데요. 절반에 조금 못 미치는 지점입니다. 절반을 넘지 못했다는 해석도 가능하고, 가장 어려운 장기 과제 묶음에서 절반 가까이를 거의 끝까지 갔다는 해석도 가능합니다. 저는 후자에 조금 더 무게를 둡니다. 세 시간짜리 터미널 과제에서 절반 가까운 완성은 쉬운 기록이 아니기 때문입니다.

모델별 차이를 볼 때는 조건을 함께 봐야 합니다. 같은 77개라도 도메인별 편차가 있을 수 있고, 과제 유형에 따라 잘하는 모델이 갈릴 수 있습니다. 13개 도메인과 여덟 가지 유형이라는 구성이 그래서 다시 중요해집니다. 한두 분야의 점수로 전체를 말하기 어렵게 설계되어 있기 때문입니다. 특정 모델이 특정 유형에서 강해도 전체 평균에서는 그 강점이 희석됩니다. 반대로 여러 유형에서 고르게 오르는 모델이 평균에서는 유리해집니다.

개인적으로 인상 깊었던 점은 실행 횟수 자체입니다. 1,145번이라는 기록은 한두 번의 운이 아니라 반복된 모습이라는 뜻입니다. 긴 작업 평가는 편차가 크기 마련인데, 실행을 많이 쌓으면 그 편차가 조금씩 가라앉습니다. 물론 이 숫자가 모든 불확실성을 없애주지는 않습니다. 모델 버전이 바뀌면 기록도 바뀌고, 채점 인프라의 작은 결함이 결과에 스며들 여지도 있습니다. 그럼에도 15개 모델을 같은 잣대로 여러 번 돌렸다는 점에서, 현재 프론티어의 지속력을 가늠하는 기준점으로는 충분해 보입니다.

0.221과 0.653 사이에서 무엇을 읽어야 할까

30개 재구성 과제에서 이진 검증 점수 평균은 0.221이었고, 단계별 사다리 점수 평균은 0.653이었습니다. 두 숫자를 나란히 두면 간극이 큽니다. 하나는 다섯 중 하나꼴로만 통과했다는 이야기이고, 다른 하나는 절반을 훌쩍 넘어 밟고 올라갔다는 이야기니까요.

이 차이를 어떻게 읽어야 할까요. 먼저 분명한 점은 결과만 재는 평가는 중간 진행을 버린다는 것입니다. 0.221이라는 숫자는 최종 통과 여부만 셉니다. 반면 0.653은 중간 발판을 밟은 기록까지 합칩니다. 같은 실행을 놓고도 무엇을 점수에 넣느냐에 따라 이야기가 달라지는 것이죠. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 최종 판정과 과정 보상이 따로 움직인다는 점, 그리고 그 간극이 크다는 점이 에이전트 평가의 빈틈을 드러내기 때문입니다.

예를 들어보겠습니다. 오전에 터미널 과제를 받은 에이전트가 두 시간 반 동안 의존성을 맞추고, 스크립트 오류를 세 번 고치고, 마지막 10분을 남기고 검증 조건 하나를 놓쳤다고 해보죠. 이진 판정에서는 0점입니다. 하지만 사다리 점수에서는 0.7점 언저리가 나올 수 있습니다. 어느 기록이 에이전트의 능력을 더 잘 설명할까요. 채용으로 치면 면접에서 떨어졌다는 사실만 남기는 것과, 어디까지 잘했고 어디에서 막혔는지 피드백을 남기는 것의 차이와 비슷합니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 0.653이라는 숫자가 에이전트가 거의 다 왔다는 뜻은 아니기 때문입니다. 중간 발판을 잘 밟는 것과 마지막 고비를 넘는 것은 다른 능력입니다. 중간까지는 순조롭다가도 마지막 검증 조건 앞에서 무너지는 패턴이 반복된다면, 그건 따로 고쳐야 할 문제입니다. 연구진이 두 점수를 함께 둔 이유도 여기에 있다고 봅니다. 하나만 보면 놓치는 모습을 다른 하나가 잡아주니까요. 결과와 과정을 함께 봐야 지속력이라는 말이 빈말이 되지 않습니다.

외워서 푸는 일을 막는 장치가 왜 필요할까

자동으로 과제를 많이 만들고 부분 점수까지 주면, 다음 걱정은 유출입니다. 공개된 시나리오와 답을 외워서 점수를 올리는 일이 생길 수 있기 때문입니다. 연구진은 단계별 사다리가 부분 진행에 보상하면서도 공개 출력 암기를 막도록 설계했다고 설명합니다.

이 대목은 얼핏 모순처럼 들립니다. 과정을 자세히 보여주면 외우기도 쉬워지는 것 아닐까요. 그런데 설계 방향을 보면 이해가 갑니다. 사다리의 발판이 공개된 문자열과 똑같은지 보는 것이 아니라, 각 단계에서 실제로 요구되는 상태에 도달했는지를 확인하기 때문입니다. 답안지를 베껴 적는 것과 문제를 풀어내는 것은 다르죠. 수학 시험에서 풀이 과정을 채점하는 선생님을 떠올리면 비슷합니다. 답만 맞힌 것과 풀이가 맞는 것은 다르게 봅니다.

실제 시스템 관점에서 보면 이 장치는 과제 자동 생성과 짝을 이룹니다. 시나리오를 기계적으로 뽑아내면 변형 규칙이 남기 마련인데, 그 규칙을 외우는 shortcut이 통하면 벤치마크 수명이 짧아집니다. 평가용 세 개를 숨기고, 사다리 채점을 외움에 둔감하게 만들면 수명이 늘어납니다. 벤치마크도 일종의 소프트웨어라서 유지보수가 필요합니다. 처음에는 깨끗해도, 답이 돌기 시작하면 다시 손봐야 하죠. 처음 설계에서 외움을 염두에 두는 편이 나중에 손보는 비용보다 쌉니다.

그렇다면 이 방어가 완전할까요. 그렇지는 않을 것입니다. 어떤 방어든 뚫는 방법이 나오기 마련이니까요. 다만 방향이 맞다는 점은 분명합니다. 많이 만들고, 부분까지 재고, 외움은 막는 세 가지를 한 묶음으로 설계했다는 점에서 저는 이번 작업을 좋게 평가했습니다. 하나씩 따로 내놓으면 각자 구멍이 생기지만, 세 개를 맞물리면 서로의 구멍을 메워주니까요. 앞으로 이 구조를 깰 새로운 shortcut이 나온다면, 그때는 다시 방어막을 덧대면 됩니다.

오래 일하는 에이전트를 곁에서 지켜보며 드는 생각

여기까지 읽고 나면 자연스럽게 다음 질문이 남습니다. 그래서 에이전트를 오래 일하게 하려면 무엇을 고쳐야 할까요. 논문은 직접적인 처방을 내리지는 않는데요. 대신 어디를 봐야 할지 알려줍니다. 최종 통과율이 아니라 중간 기록을 보라는 것, 짧은 성공이 아니라 긴 지속을 보라는 것입니다.

저는 앞으로 보고 싶은 것이 분명합니다. 30분 간격 기록을 모델별로 펼쳐놓고, 어디에서 무너지는지 유형별로 보고 싶습니다. 초반 탐색에서 시간을 다 쓰는 모델이 있을 것이고, 중반 디버깅에서 맴도는 모델이 있을 것이고, 막판 검증 조건 앞에서 미끄러지는 모델도 있을 것입니다. 무너지는 지점이 다르면 고치는 방법도 달라집니다. 탐색이 문제라면 계획과 메모가 필요하고, 디버깅이 문제라면 로그 읽기와 가설 세우기가 필요하고, 막판 실수가 문제라면 검증 습관이 필요합니다. 같은 낮은 점수라도 처방은 전혀 다르죠. 세 시간 기록지가 있어야 이런 구분이 가능합니다.

저희가 새로운 AI 아키텍처를 볼 때도 점수보다 구조를 먼저 봅니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보는 것이죠. LHTB 2.0도 같은 잣대로 보면 됩니다. 77개라는 개수보다 재구성 파이프라인이라는 제작 방식이, 0.69라는 평균보다 30분 간격 기록이라는 측정 방식이 더 오래 남을 가능성이 큽니다. 점수는 다음 모델이 오면 바뀌지만, 과제를 만들고 과정을 재는 틀은 남으니까요.

그렇다면 사람의 역할은 무엇일까요. 에이전트가 세 시간씩 터미널 앞에 앉아 일하는 시대에, 사람이 할 일은 명령어를 대신 쳐주는 것이 아니라 무엇을 시킬지와 어디까지 믿을지를 정하는 일이 될 것 같습니다. 중간 기록을 읽고, 어느 지점부터는 사람에게 물어보게 만들고, 어느 지점까지는 맡겨도 되는지 정하는 것이죠. 오래 일하는 에이전트를 재는 일은 결국 오래 함께 일하는 방법을 묻는 일이기도 합니다. 이번 논문은 그 질문에 답하기 위한 자를 만드는 작업이었고, 저는 그 자가 앞으로 현장에서 어떻게 쓰일지 지켜보고 싶습니다.