FIELD NOTES / 2026.09.03
좋은 에이전트 태스크 하나는 어떻게 만들어질까?
어려운 문제를 쓰는 것으로 끝나지 않는다. 모델이 왜 실패했는지 설명할 수 있고, 정답과 편법을 정확히 가르는 작은 세계까지 만들어야 한다.
Terminal-Bench는 모델에게 터미널을 주고 실제 작업을 맡기는 벤치마크다. 태스크 작성자는 질문 하나가 아니라 시작 상태, 사용할 도구, 성공 조건, 채점기가 함께 들어 있는 작은 작업 세계를 만든다.
v3.0.0이 만들어지는 동안 공개 PR에 등장한 고유 task slug는 496개였다. 그중 82개가 병합됐고, 최종 릴리스에는 74개가 남았다. 공개 PR부터 릴리스까지 숫자를 잇으면 이렇다.
496개가 제안되고, 74개가 실제 릴리스에 들어갔다.
74개는 모두 앞의 496개에 포함된다. 14.9%는 공식 합격률이 아니라, 현재 복원 가능한 공개 PR 집단에서 계산한 릴리스 수록 비율이다.
01 / 태스크 하나의 조건
프롬프트는 시작일 뿐이다.
같은 지시문이라도 파일이 다르거나, 도구 권한이 다르거나, 채점 기준이 흔들리면 전혀 다른 문제가 된다. Terminal-Bench에서 태스크 하나는 다음 네 조각이 맞물릴 때 비로소 성립한다.
- 01
Instruction
에이전트가 끝내야 할 일을 설명한다. 정답 코드를 알려주는 대신 결과와 제약을 분명히 쓴다.
- 02
Environment
파일, 도구, 권한, 네트워크와 시작 상태를 고정한다. 매번 같은 조건으로 다시 시작할 수 있어야 한다.
- 03
Verifier
완성된 결과가 맞는지 별도 환경에서 검사한다. 정답뿐 아니라 그럴듯한 오답과 편법도 가려야 한다.
- 04
Reward
검사 결과를 점수로 바꾼다. rs-archive-clone은 모든 조건을 통과해야 1점, 하나라도 틀리면 0점이었다.
좋은 태스크는 “모델이 실패했다”에서 끝나지 않는다. 왜 실패했는지 믿을 수 있게 만든다.
02 / 왜 만들기 어려운가
어렵게 만드는 것과 불공정하게 만드는 것은 다르다.
작성자는 계속 세 가지를 확인해야 한다. 설명이 충분한가, 실제 능력을 요구하는가, 그리고 가짜 정답을 채점기가 잡아내는가. 숨겨진 파일명 하나 때문에 실패한다면 어려운 태스크가 아니라 모호한 태스크다. 반대로 한 줄짜리 힌트로 모든 모델이 풀어버린다면 난도의 중심이 약하다.
자동 리뷰가 가장 자주 멈춘 곳은 명세와 난도였다.
Proposal bot의 criterion 판단을 센 값이다. 사람이 101개를 거절했다는 뜻은 아니다.
병합된 실제 task-add PR 83개는 중앙값으로 15개 커밋, 40개 댓글, 35일을 거쳤다. 승인 버튼 한 번보다 그 전에 오간 질문, 수정, 재실행이 훨씬 많은 정보를 남긴다. 이 숫자 역시 작업시간이 아니라 공개된 반복 흔적이다.
PR #1127 ↗에서는 에이전트가 pytest의 TestReport를 바꿔 가짜 34/34를 만들었다. PR #1372 ↗에서는 공개하지 않은 geometry를 테스트가 요구해 정상 풀이를 떨어뜨렸다. 하나는 채점기가 너무 약했고, 다른 하나는 너무 불공정했다.
03 / CASE STUDY
rs-archive-clone은 문제를 만드는 과정 자체가 문제였다.
최종 과제는 실행 전용 archive 프로그램을 관찰한 뒤, 소스코드를 보지 않고 같은 프로그램을 다시 만드는 일이었다. 정상 입력뿐 아니라 손상 복구, 잘못된 입력, 출력 문구, 종료 코드와 생성되는 파일까지 같아야 했다.
에이전트가 실제로 맞춰야 했던 것
- 만들 결과
/app/archive-clone실행 파일 하나- 관찰 방법
- 제공된 reference binary에 입력을 넣어 동작 확인
- 호환 범위
- 8개 command · 3개 profile · 6개 transform · 오류와 filesystem 변화
- 성공 조건
- 57개 테스트 전체 통과 · binary reward 1
- 시간
- Agent 4시간 · verifier 20분 · expert estimate 16시간
- 01
처음에는 Reed–Solomon 알고리즘 문제였다.
Junha Park는 손상된 데이터를 복구하는 GF(2^16) Reed–Solomon list decoder를 제안했다. 자동 리뷰는 Accept를 냈고, 약 60시간 뒤 maintainer가 ‘Give it a shot’이라고 답했다.
- 02
너무 쉽게 풀리자, 실제 도구를 복제하는 문제로 바뀌었다.
원래 문제는 frontier model이 쉽게 풀었다. 제출자는 방향을 바꿔, 소스가 없는 archive 프로그램을 실행해 보면서 같은 동작을 다시 만드는 clean-room 과제로 만들었다. PR은 27번의 커밋과 57개 테스트를 거쳐 v3.0.0에 들어갔다.
- 03
정상 풀이보다 편법이 먼저 만점을 받았다.
후속 cheat trial에서 세 에이전트 중 두 개가 reference binary를 압축하거나 인코딩해 결과물 안에 숨긴 뒤 메모리에서 실행했다. 테스트를 190개로 늘리고 reference를 별도 sidecar로 옮겼지만, Harbor의 Modal 실행 문제가 막혀 저장소 정리 때 PR이 닫혔다.
- 04
보강안은 다시 제출됐지만 아직 끝나지 않았다.
같은 sidecar 보강안이 새 PR로 이어졌다. 2026년 9월 3일 기준으로 열려 있었고, 로컬에서는 Oracle 1·Nop 0이었지만 GitHub의 원격 Oracle job은 240분 뒤 실패했다. 따라서 이 설계를 production 해법이라고 부를 수는 없다.
정상 에이전트는 못 풀었지만, 편법 에이전트는 만점을 만들었다.
- 정상 trial
- 0 / 6완전 통과
- 가장 가까운 정상 풀이
- 45 / 57그래도 reward 0
- 후속 cheat trial
- 2 / 3reference wrapper로 reward 1
0점 여섯 개가 모두 같은 실패는 아니다. 한 run은 artifact 전달 실패였고, 다른 run들은 복구 알고리즘과 edge behavior에서 막혔다.
왜 “복사하지 마세요”라는 문구로는 막을 수 없었을까?
첫 버전에서는 reference binary가 에이전트와 같은 컨테이너 안에 있었다. 지시문은 복사를 금지했고 scanner는 큰 파일, ELF, base64 흔적을 찾았지만, root 권한을 가진 에이전트는 binary를 잘게 나누고 압축해 숨긴 뒤 메모리에서 다시 실행할 수 있었다.
후속 설계의 핵심은 scanner를 더 영리하게 만드는 것이 아니었다. reference 파일을 처음부터 에이전트가 있는 곳에 두지 않는 것이었다. 에이전트는 별도 sidecar에 제한된 probe 요청만 보내고, 제출물이 완성되면 sidecar가 없는 새 verifier 환경에서 검사한다.
같은 방에 둔 비밀은 숨기기 어렵다.
기존Agent + reference binary→root agent가 파일을 읽어 숨길 수 있음
제안Agent → 제한된 probe API → reference sidecar→agent filesystem에는 원본 파일이 없음
이 sidecar 보강안은 2026년 9월 3일 현재 아직 병합되지 않았다.
04 / 어떻게 검증하는가
PR 하나가 들어오면, 정답보다 먼저 실패의 원인을 검사한다.
공식 문서가 설명하는 흐름을 읽기 쉽게 묶으면 여섯 단계다. 자동화가 넓게 훑고, 강한 모델과 공격 모델이 실제로 부딪혀 보고, 마지막에는 사람이 그 실패가 의미 있는지 판단한다.
- 01
제안
실제 가치가 있고, 풀 수 있으며, 결과를 명확히 채점할 수 있는 문제인지 여섯 기준으로 본다.
- 02
파일 검사
Instruction, Docker 환경, solution과 tests가 형식과 보안 규칙을 지키는지 자동으로 확인한다.
- 03
Oracle · Nop
작성자의 정답은 통과하고, 아무것도 하지 않은 초기 상태는 실패하는지 확인한다.
- 04
정상 trial
강한 모델에게 실제로 풀게 한다. 실패했다면 난도 때문인지, 모호한 지시나 timeout 때문인지 다시 읽는다.
- 05
Cheat trial
채점기의 허점을 노리도록 지시한 에이전트가 가짜 만점을 만들 수 있는지 시험한다.
- 06
사람의 판단
실패가 흥미로운 능력 부족인지, 사소한 edge case나 인프라 사고인지 판단하고 수정 또는 병합을 결정한다.
이것은 문서가 권장하는 경로이지 모든 과거 PR이 똑같이 밟은 의무 절차는 아니다. Bot의 초록 체크는 특정 revision의 실행 결과이고, 최종 승인과도 다르다.
05 / CLOSED를 읽는 법
닫힌 PR을 모두 탈락으로 세면 이야기가 틀어진다.
2026년 9월 3일의 현재 new task 라벨 집단에는 closed-unmerged PR이 599개 있었다. 그러나 그 안에는 난도 부족뿐 아니라 중복, 후속 PR, 마감, 인프라 장애와 저장소 정리가 함께 들어 있다.
- #1272실제 난도 문제
Maintainer가 ‘너무 쉽고 난도를 조절할 뚜렷한 장치가 없다’고 판단했다.
원문 ↗ - #117새로움 부족
여러 trial을 거친 뒤에도 ‘TB3에 고유하지 않다’는 명시적인 이유로 닫혔다.
원문 ↗ - #1271저장소 정리
보이는 gate와 trial을 통과했지만 Git history cleanup 과정에서 자동으로 닫혔다.
원문 ↗ - #952후속 PR로 이동
실패로 끝난 것이 아니라 더 나은 제출물 #911로 작업이 넘어갔다.
원문 ↗ - #1500이유를 모름
Oracle 실패와 Nop skip은 보이지만 사람이 남긴 폐쇄 이유가 없어 unknown으로 남겨야 한다.
원문 ↗
우리가 자세히 분류한 31건은 전수나 무작위 표본이 아니다. 다양한 실패 모양을 보여주기 위해 고른 사례이므로, 그 비율을 전체 거절 사유로 일반화하지 않았다.
06 / 용어 사전
리뷰 댓글을 읽기 전에 알아둘 말들.
- Oracle
- 태스크 작성자가 만든 기준 정답이다. Oracle이 모든 테스트를 통과해야 한다. Oracle ✅만으로 태스크가 승인됐다는 뜻은 아니다.
- Nop
- 에이전트가 아무것도 하지 않은 상태다. Nop이 실패해야 채점기가 최소한 빈 답과 정답을 구분한다고 볼 수 있다.
- Verifier
- 에이전트가 만든 결과를 검사하는 프로그램이다. 테스트 코드와 예상 결과를 포함하며 에이전트 환경과 분리하는 것이 원칙이다.
- Reward
- Verifier 결과를 숫자로 바꾼 점수다. 0과 1만 쓰는 binary reward도 있고 부분 점수를 주는 방식도 있다.
- Normal trial
- 모델에게 정직하게 문제를 풀게 하는 실험이다. 성공률뿐 아니라 timeout, 거절, 근접 실패의 원인을 함께 본다.
- Cheat trial
- 모델에게 채점기를 속여 점수를 얻어보라고 지시하는 공격 실험이다.
- Sidecar
- 보호해야 할 reference를 agent와 다른 프로세스나 컨테이너에 두고, 허용한 요청만 받는 작은 서비스다.
- Difficulty lever
- 힌트, 입력 크기, 허용 도구처럼 난도를 실제로 바꾸는 장치다. 이 장치가 없으면 ‘어려움’이 우연일 수 있다.
07 / 남은 질문과 근거
Junha Park에게는 설계가 바뀐 순간을 묻고 싶다.
GitHub 프로필에서 확인되는 공식 이름은 Junha Park다. 한글 표기 ‘박준하’는 아직 본인이 확인한 표기가 아니다. 뻔한 인터뷰보다 공개 기록만으로 복원할 수 없는 결정들을 묻는 편이 낫다.
- 01
실제로 성공한 두 cheating trajectory 중 예상 밖이었던 행동은 무엇이었나요?
- 02
Scanner를 더 보강하지 않고 reference sidecar를 택한 결정적 이유는 무엇이었나요?
- 03
Modal·DinD 같은 인프라 제약이 최종 task design을 어떻게 바꿨나요?
- 04
어떤 edge case를 본질적인 난도로 보고, 어떤 것은 unfair한 grader trivia로 보았나요?
- 05
45/57 같은 near miss와 0/57 artifact failure를 서로 다른 신호로 분류한 내부 기준이 있었나요?
확인GitHub의 discussion, PR, comment, commit, v3.0.0 task tree에서 직접 본 사실
추론알고리즘 풀이보다 불완전한 관찰에서 시스템 동작을 복원하는 능력을 재려 했다는 해석
모름Discord와 비공개 대화, sidecar의 최종 채택 여부, 정확한 사람 작업시간
조사 방법과 1차 자료 보기
v3.0.0의 immutable commit 2b0442c3, 공개 Task Ideas 328개, 2026년 9월 3일 현재 new task 라벨 PR 765개와 각 PR의 파일·댓글·리뷰·보이는 gate를 대조했다. GitHub 라벨과 댓글은 바뀔 수 있고 sticky comment는 과거 상태를 덮어쓸 수 있다.