터미널벤치와 하버 정리: AI 에이전트 벤치마크가 빠르게 뚫리는 이유와 검증자 자동화 문제

핵심 메시지

• 터미널벤치2 점수는 개발 중 20~30%, 공개 시점 40~45%였다가 최근 제출에서 75%까지 올랐고 맞춤 하네스를 붙이면 80%에 이른다. 모든 과제가 최소 한 번은 풀린 적이 있어 이론적으로는 100%도 가능하다.
• 벤치마크가 업계 표준이 되려면 세 가지가 필요하다. 리워드 해킹이 어려운 높은 품질, 한 줄로 돌릴 수 있는 낮은 진입 장벽, 그리고 아직 아무도 재지 않는 능력을 골라낸 안목이다.
• 터미널이 좋은 추상인 이유는 UI 이전부터 컴퓨터를 다루던 방식이었고, 언어모델이 이미지보다 텍스트에 강하기 때문이다. 사람들이 터미널로 할 수 있는 일의 범위를 과소평가한다는 것이 제작자의 관점이다.
• 과제 품질의 병목은 생성이 아니라 검증이다. 전문가 기여자, 자기 점검용 루브릭과 LLM 심사, 그리고 마지막 QA 과정을 거쳐 취약하거나 해킹 가능한 과제를 걸러낸다.
• 다음 목표는 '에이전트가 검증자를 얼마나 잘 만드는가'를 재는 메타 벤치마크다. 검증자만 자동으로 만들 수 있으면 운영 로그에서 과제를 대량 생산하는 순환 구조가 열린다.

쉽게 이해하기

스노클 AI의 벤치토크 첫 회에 터미널벤치의 공동 제작자 알렉스 쇼가 출연했다. 넉 달 전 대화 이후 무엇이 가장 놀라웠느냐는 질문에 그는 두 가지를 꼽았다. 하나는 모델 개발사들이 점수를 끌어올린 속도다. 만드는 동안에는 20~30%대가 나왔고, 공개할 무렵 좋은 모델들이 40~45%를 기록했는데, 최근 제출에서는 75%가 나왔고 맞춤 하네스를 붙이면 80%까지 올라갔다. 다른 하나는 함께 내놓은 실행 프레임워크 하버가 예상보다 빠르게 채택된 일이다.

점수가 그렇게 빨리 올랐다는 사실을 그는 조심스럽게 해석한다. 터미널벤치2는 리워드 해킹이 비교적 어려운 벤치마크이므로 모델이 실제로 그 유형의 과제를 잘하게 된 것은 맞다고 본다. 그런데 정작 본인이 코딩 에이전트를 매일 쓰면서 느끼는 부족함은 여전하다. 80%를 받는 도구라면 모든 문제를 즉시 풀어야 할 것 같은데, 실제로는 복잡도를 잔뜩 끌어들이고 자기가 만든 결과물 위에 견고하게 쌓아 올리는 데 어려움을 겪는다는 것이다. 그가 내린 결론은 코딩이라는 영역이 지나치게 넓다는 것이다. 89개 과제로는 덮을 수 없으니 지금보다 천 배 많은 벤치마크가 필요하다고 말한다.

무엇이 이 벤치마크를 표준으로 만들었느냐는 질문에 그는 세 가지를 들었다. 첫째는 사람들이 실제로 신경 쓰는 과제로 구성되고 쉽게 뚫리지 않는 품질이다. 둘째는 채택의 편의성이다. 도커만 깔려 있으면 명령 한 줄로 돌아가게 만들려고 붙들고 있었다고 한다. 셋째는 통제하기 어려운 부분인데, 아직 아무도 측정하지 않지만 곧 중요해질 능력에 베팅하는 일이다. 이들에게는 그것이 터미널이었다. 코딩만이 아니라 컴퓨터로 하는 임의의 작업을 위한 강력한 도구로 본 것이다.

품질을 어떻게 유지했는지에 대한 답은 실무적이다. 처음에는 둘이서 과제를 만들다가 각자 열 개쯤에서 아이디어가 바닥났고, 그래서 크라우드소싱으로 전환했다. 핵심은 자기 경력에서 실제로 풀어낸 어려운 문제를 재현할 수 있는 전문가 기여자였다. 여기에 기여자가 스스로 점검할 수 있도록 루브릭을 만들고 LLM이 명세의 빠진 부분을 짚어주게 했으며, 마지막으로 과제가 취약한지 리워드 해킹이 가능한지 확인하는 QA 단계를 뒀다. 리더보드 무결성 문제도 같은 방식으로 다룬다. 제출을 공개해 두니 커뮤니티의 다른 기여자가 정답 경로를 에이전트 바이너리에 끼워 넣은 항목을 찾아냈다. 다만 모델이 정답으로 파인튜닝됐는지는 검증할 방법이 없으므로, 결국 해법은 새 벤치마크를 빠르게 찍어내는 것이라고 그는 말한다.

하버는 여기서 나온 발상이다. 벤치마크를 하나씩 만드는 대신 다른 사람들이 자기 벤치마크를 만들 수 있는 공장을 짓겠다는 것이다. 이미 40~50개 벤치마크가 편입됐고, 에이전트가 온라인 게임을 하게 만든 것 같은 실험적 사례도 등장했다. 최근 집중하는 방향은 코딩을 넘어 금융이나 법률처럼 다른 영역의 과제까지 담는 것이다. 그가 참고한 기준은 웹 프레임워크 수준의 개발자 경험이었다. 복잡도의 90%를 감추면서도 필요한 유연성의 90%를 남기는 인터페이스가 강력하다는 것이다.

앞으로 무엇이 변하지 않을 것 같으냐는 질문에 그는 오프라인 학습의 중요성을 들었다. 지속 학습이 풀리기를 바라지만, 당분간은 실제 운영에서 벌어지는 작업을 과제와 환경으로 옮겨 담아 오프라인 개발에 쓰는 방식이 핵심으로 남으리라는 예측이다. 그가 가장 보고 싶어 하는 벤치마크는 에이전트가 검증자를 얼마나 잘 만드는지를 재는 메타 벤치마크다. 환경과 지시문은 여러 방식으로 만들어낼 수 있지만 검증자는 그렇지 않고, 과제 제작에서 가장 어려운 부분이 늘 검증자이기 때문이다. 이 조각이 풀리면 운영 트레이스에서 과제를 뽑고, 그 과제로 에이전트를 훈련하고, 다시 운영 트레이스가 쌓이는 순환이 돌기 시작한다는 것이 그가 말한 북극성이다.

주요 인사이트

• 벤치마크를 성적표가 아니라 제품 명세로 보는 관점이 이 대화의 핵심이다. 과제는 '우리가 중요하게 여기는 능력이 무엇인가'를 적어둔 문서이고, 프런티어 연구소들이 그 위에서 점수를 올리는 이상 과제 목록이 곧 업계의 로드맵이 된다.
• 벤치마크 점수와 체감 성능의 괴리를 데이터 문제로 환원하는 대신 과제 집합의 좁음으로 설명하는 것이 설득력 있다. 넓은 영역을 89개 과제로 대표하려는 시도 자체가 무리라는 것이다.
• 오버피팅을 막는 방법으로 '더 촘촘한 검증'이 아니라 '더 빠른 교체'를 택한 점이 눈에 띈다. 파인튜닝 여부를 검증할 수단이 없다는 현실을 인정한 데서 나온 선택이다.
• 과제를 만드는 일은 예상보다 재미있고 남의 과제를 리뷰하는 일은 예상보다 고통스럽다는 고백이 확장의 진짜 병목을 보여준다. 검증자 자동화가 중요한 이유도 여기 있다.
• 데이터가 여러 손을 거쳐 이동하는 상황에서 공통 형식과 프레임워크가 조율 문제를 푼다는 지적은, 평가 인프라가 왜 개별 기업의 내부 도구로 남지 않는지를 설명한다.

자주 묻는 질문

관련 AI 소식