터미널벤치 개발팀이 밝힌 AI 에이전트 벤치마크의 설계와 하버 프레임워크의 지향점

핵심 메시지

• 화면을 보고 마우스를 움직이는 방식 대신, 언어모델이 가장 잘하는 텍스트와 코드로 컴퓨터를 다루게 하자는 발상에서 이 벤치마크가 출발했다.
• 평가 대상 에이전트를 컨테이너 안에 직접 설치하는 구조를 택해, 어떤 에이전트든 별도 배선 없이 그대로 돌려볼 수 있게 했다.
• 턴 수나 토큰 수 대신 과제별 제한 시간을 종료 조건으로 삼은 것은 임의의 에이전트를 지원하기 위해 감수한 타협이다.
• 2.0 버전은 과제 수를 채우기보다 품질 기준을 지키는 쪽을 택해, 기준에 못 미치는 과제를 걷어내고 89개만 남겼다.
• 평가와 강화학습, 프롬프트 최적화가 결국 같은 추상, 즉 컨테이너 위에서 롤아웃을 돌리고 보상을 돌려받는 구조를 공유한다는 발견이 후속 프레임워크로 이어졌다.

쉽게 이해하기

1년쯤 전만 해도 언어모델에게 컴퓨터를 맡기는 방법의 주류는 화면을 보고 커서를 움직여 버튼을 누르게 하는 것이었다. 시연 영상은 화려했지만 실제로 써보면 금세 무너졌다. 긴 사고 흐름을 유지하지 못했고, 화면 요소를 정확히 누르는 일조차 버거웠다. 개발팀은 시각적 추론이 약한 대신 코드 작성은 이미 수년째 잘해온 모델의 강점을 살려, 화면을 조작하는 대신 코드로 컴퓨터를 조작하게 하자는 쪽으로 방향을 틀었다.

설계의 뼈대는 앞선 코딩 벤치마크에서 배웠다. 특정 언어의 오픈소스 저장소와 풀 리퀘스트에 묶인 형식 대신, 지시문이 담긴 컨테이너와 채점용 테스트 스크립트라는 더 일반적인 틀을 잡았다. 컨테이너 자체가 사실상 가상의 컴퓨터이므로, 이 형식이면 컴퓨터에서 할 수 있는 거의 모든 과제를 담을 수 있다는 판단이었다. 팀은 터미널이 단순히 배시 명령을 실행하는 창구가 아니라 편집기 같은 대화형 프로그램까지 띄우는 환경이라는 점을 놓고 오래 고민했다고 밝혔다.

가장 큰 결정은 에이전트를 컨테이너 바깥에 두지 않고 안에 직접 설치한 것이다. 외부 환경과 에이전트를 연결하는 별도의 통신 배선이 필요 없어지면서, 이미 쓰고 있던 코드를 그대로 가져와 바로 점수를 받아볼 수 있게 됐다. 대신 대가도 있었다. 에이전트가 모델을 호출해야 하므로 컨테이너 안의 네트워크를 끊는 과제는 만들 수 없고, 환경도 특정 리눅스 계열을 전제해야 했다.

종료 조건에서도 같은 원칙이 작동했다. 턴 수를 제한하면 하드웨어 성능에 관계없이 공정하겠지만, 임의의 에이전트에서 턴 수를 꺼내올 방법이 마땅치 않고 무엇이 한 턴인지도 명확하지 않다. 하위 에이전트를 호출하면 그것을 한 턴으로 볼지부터 애매해진다. 토큰 수 제한도 에이전트마다 계측용 연결을 심어야 한다. 결국 팀은 과제마다 제한 시간을 붙이는 단순한 방식을 골랐고, 사용자가 추가 코드를 짜지 않아도 되게 했다.

2.0은 살아 있는 벤치마크라는 처음의 계획을 실행에 옮긴 결과다. 모델이 강해지면 난도도 함께 올려 점수가 포화되지 않도록 하고, 1.0에 남아 있던 문제들을 걷어냈다. 무작위성 때문에 실패가 갈리는 과제, 유튜브 정책 변화에 따라 어제는 되고 오늘은 안 되는 과제, 디버깅용으로 넣었던 지나치게 쉬운 과제가 정리 대상이었다. 두 사람이 모든 과제를 직접 점검하며 체크리스트를 돌린 끝에, 100개를 채우고 싶은 욕심을 접고 기준을 통과한 89개만 남겼다.

주요 인사이트

• 벤치마크의 성패를 가른 것은 과제의 개수가 아니라 채택 가능성이었다. 개발자들에게 물었더니 돌아온 답은 과제를 더 달라는 것이 아니라, 지금 쓰는 도구 그대로 어떻게 평가하냐는 질문이었다.
• 커뮤니티는 저절로 모이지 않았다. 초기에는 연구 참여를 문의해온 학생들과 하루에 두세 통씩 통화하며, 과제 세 개를 만들면 논문 공저자로 올린다는 식의 명확하고 병렬화 가능한 참여 방법을 제시한 것이 출발점이었다.
• 깃허브 별 1000개에 실제 활발한 기여자는 다섯 명이라는 수치는 오픈소스 참여 깔때기의 현실을 그대로 보여준다. 5퍼센트 미만만 남기 때문에, 임계량을 채우려면 입구 자체를 넓혀야 한다는 계산이 나온다.
• 기여자를 동료가 아니라 고객처럼 대한다는 관점이 인상적이다. 무엇이 기여를 어렵게 만드는 마찰인지 찾아 없애고, 병합까지 사람이 막아서는 지점을 줄이는 방향으로 운영했다는 설명이다.
• 평가와 강화학습과 프롬프트 최적화는 겉보기에 다른 용도지만, 컨테이너에서 롤아웃을 돌려 토큰과 보상을 받는다는 점에서 동일한 추상 위에 있다. 이 공통점을 잡아낸 것이 후속 프레임워크의 출발점이 됐다.

자주 묻는 질문

관련 AI 소식