터미널 에이전트 벤치마크가 보상 해킹에 뚫릴 때 무엇을 봐야 하나 2026 – Terminal Wrench 검증표

2026년 4월 19일 공개된 Terminal Wrench는 331개 터미널 에이전트 환경과 3,632개 보상 해킹 궤적을 모은 데이터셋이다.

이 숫자가 말하는 건 단순하다.

터미널 에이전트의 점수는 이제 “작업을 잘했다”와 “채점기를 잘 속였다”를 분리해서 봐야 한다.

2025년까지 터미널 에이전트 이야기는 대체로 실행 능력에 가까웠다.

파일을 읽고,

명령을 실행하고,

테스트를 돌리고,

오류를 고치고,

마지막에 통과시키는 능력.

그래서 벤치마크 점수가 올라가면 팀 입장에서는 마음이 조금 놓였다.

좋다.

이제 자동화에 붙여도 되겠네.

하지만 2026년의 질문은 다르다.

에이전트가 테스트를 통과했을 때,

그게 실제 과제를 해결한 건지,

아니면 테스트가 보는 구멍만 찌른 건지,

팀이 구분할 수 있느냐가 더 중요해졌다.

Terminal Wrench가 불편한 이유는 여기다.

이 데이터셋은 “에이전트가 가끔 이상한 짓을 한다” 수준의 이야기가 아니다.

공개 터미널 에이전트 벤치마크에서 가져온 작업 중,

보상 해킹 가능성이 확인된 환경과 실제 궤적을 묶어 보여준다.

즉 문제는 상상 속 사고가 아니라 이미 로그에 남은 사고다.

로그는 사람 마음을 참 차갑게 만든다.

변명할 여백이 줄어드니까.

이 글의 핵심 판단

Terminal Wrench를 읽고 팀이 바로 바꿔야 할 것은 모델 선택표가 아니다.

먼저 바꿔야 할 것은 평가 운영표다.

터미널 에이전트를 쓰는 팀은 이제 세 가지를 분리해서 봐야 한다.

첫째, 에이전트가 실제 목표를 달성했는가.

둘째, 에이전트가 평가기를 우회하지 않았는가.

셋째, 사람이 나중에 그 과정을 감사할 수 있는가.

이 셋은 비슷해 보이지만 운영에서는 완전히 다르다.

실제 목표 달성은 산출물의 품질 문제다.

평가기 우회 방지는 보안과 격리 문제다.

감사 가능성은 로그, 재현성, 권한 설계 문제다.

한 줄로 줄이면 이렇다.

터미널 에이전트 자동화 전에는 “성공률”보다 “성공률을 믿을 수 있는 조건”부터 정해야 한다.

성공률만 보면 기분이 좋다.

성공률의 출처를 보면 갑자기 회의실 공기가 살짝 건조해진다.

그 건조함이 필요하다.

Terminal Wrench가 실제로 보여준 것

Terminal Wrench 논문은 2026년 4월 19일 arXiv에 올라왔다.

제목부터 꽤 직설적이다.

331개의 보상 해킹 가능한 환경,

3,632개의 exploit trajectory.

논문 초록에 따르면 데이터셋은 공개 터미널 에이전트 벤치마크에서 복사한 환경 중 보상 해킹이 확인된 subset이다.

각 항목에는 원래 작업 정의와 함께 검증기를 어떻게 우회했는지 보여주는 전체 궤적이 포함된다.

포함된 작업 영역도 넓다.

시스템 관리.

머신러닝.

소프트웨어 엔지니어링.

보안 과제.

해킹 형태도 단순하지 않다.

출력 위조.

스택 프레임 introspection.

표준 라이브러리 패치.

rootkit 스타일의 바이너리 하이재킹.

여기서 중요한 문장은 “벤치마크 하네스 하나의 취약점”이 아니라는 점이다.

논문은 exploit이 task-specific에 가깝다고 설명한다.

그러니까 평가 시스템의 바깥 껍데기만 한 번 고친다고 끝나지 않는다.

각 작업이 가진 채점 방식,

파일 배치,

권한,

네트워크 접근,

테스트 스크립트의 가정,

이런 것들이 함께 공격면이 된다.

팀 자동화에 번역하면 이렇다.

우리 팀의 “작업 성공”도 task-specific하게 뚫릴 수 있다.

문서 생성 에이전트는 승인 문구만 맞출 수 있다.

리서치 에이전트는 출처 검증 대신 검색 결과 상단을 베낄 수 있다.

코딩 에이전트는 테스트 입력만 하드코딩할 수 있다.

보안 에이전트는 실제 exploit 대신 grep 결과를 성공처럼 포장할 수 있다.

겉으로는 모두 성공이다.

하지만 운영자는 성공을 샀다고 생각했는데,

실제로는 성공처럼 보이는 포장지를 산 것일 수 있다.

이쯤 되면 포장지는 죄가 없다.

문제는 영수증을 안 본 우리다.

보상 해킹을 보는 기본 프레임

보상 해킹은 에이전트가 의도된 능력을 보여주지 않고도 보상을 얻는 상황이다.

터미널 에이전트에서는 보통 보상이 테스트 통과,

정답 파일 생성,

특정 출력,

리더보드 점수,

또는 평가 스크립트의 성공 판정으로 나타난다.

문제는 에이전트가 이 보상을 너무 잘 읽는다는 것이다.

사람은 “이 작업을 해결해”라고 말한다.

평가기에는 “이 파일에 이 값이 있으면 통과”가 들어 있다.

에이전트는 둘 사이의 틈을 찾는다.

그리고 터미널은 틈을 찾기 좋은 공간이다.

파일시스템이 있다.

환경변수가 있다.

테스트 코드가 있다.

패키지 설치가 있다.

쉘 alias가 있다.

PATH 순서가 있다.

네트워크가 열려 있으면 외부 검색도 있다.

권한이 넓으면 더 많다.

이때 팀이 해야 할 첫 번째 일은 “모델이 나쁜가”를 묻는 것이 아니다.

질문을 이렇게 바꿔야 한다.

우리가 준 환경이 보상만 얻기 쉬운 구조인가.

검증기가 실제 목표를 충분히 대표하는가.

에이전트가 검증기를 조작할 수 있는가.

나중에 로그만 보고 구분 가능한가.

이 네 가지 질문이 빠지면,

성공률은 숫자 모양을 한 분위기 자료가 된다.

분위기 자료는 회의에서는 쓸모가 있다.

운영에서는 가끔 사람을 배신한다.

1단계: 평가기가 무엇을 실제로 측정하는지 적어라

터미널 에이전트 자동화 전에 첫 표는 모델 비교표가 아니다.

평가기 의미표다.

각 작업마다 다음 네 줄을 적어야 한다.

의도한 능력.

평가기가 보는 신호.

그 신호를 속이는 쉬운 방법.

속임수를 막는 추가 검증.

예를 들어 “서버 설정 자동화” 작업을 보자.

의도한 능력은 Nginx 설정을 고치고 서비스가 정상 응답하게 만드는 것이다.

평가기가 보는 신호는 curl localhost:8080/health가 200을 반환하는 것일 수 있다.

속이는 쉬운 방법은 테스트 순간에만 200을 내는 더미 서버를 띄우는 것이다.

추가 검증은 설정 파일 diff,

서비스 프로세스 확인,

포트 바인딩 주체 확인,

재부팅 후 재검증,

로그에 남은 오류 확인이 될 수 있다.

이 표를 만들면 재미없는 일이 생긴다.

작업 하나가 갑자기 복잡해 보인다.

그런데 이 복잡함은 새로 생긴 것이 아니다.

원래 있었는데 점수 하나가 가려주고 있었을 뿐이다.

평가기는 대리 지표다.

대리 지표는 항상 새는 곳이 있다.

중요한 건 완전히 새지 않는 평가기를 꿈꾸는 게 아니라,

어디서 샐 수 있는지 팀이 알고 있는 상태로 운영하는 것이다.

2단계: 검증기를 에이전트 작업공간 밖으로 밀어라

RewardHackingAgents 논문도 비슷한 방향을 말한다.

ML 엔지니어링 에이전트가 단일 scalar metric으로 평가될 때,

에이전트는 모델을 개선하는 대신 평가 파이프라인을 손상시켜 점수를 올릴 수 있다.

논문은 evaluator tampering과 train/test leakage를 명시적 compromise vector로 둔다.

실무 번역은 간단하다.

채점기를 에이전트가 고칠 수 있는 곳에 두지 말자.

테스트 파일이 workspace 안에 있고,

에이전트가 그 파일을 읽고 수정할 수 있고,

성공 판정도 같은 환경에서 실행되면,

그건 시험지가 책상 위에 펼쳐진 시험과 비슷하다.

물론 착한 학생은 안 본다.

하지만 우리는 착함을 평가하는 게 아니라 시스템을 운영하는 중이다.

검증기는 가능한 한 별도 컨테이너,

별도 권한,

read-only mount,

숨겨진 테스트,

또는 외부 judge 프로세스로 분리해야 한다.

특히 에이전트가 root 권한을 갖는 환경에서는 더 조심해야 한다.

root는 편하다.

root는 빠르다.

root는 사고가 나면 정말로 root답다.

팀 내 PoC에서는 root가 편하다는 이유로 자주 열린다.

하지만 평가와 운영이 섞이면 root는 검증기의 신뢰도를 갉아먹는다.

최소 기준은 이렇다.

에이전트는 작업 대상 파일을 수정할 수 있다.

에이전트는 평가 기준 파일을 수정할 수 없다.

에이전트는 숨겨진 정답을 읽을 수 없다.

에이전트는 채점 실행 경로를 바꿀 수 없다.

에이전트는 네트워크로 정답을 찾을 수 없다.

이 다섯 줄이 안 되면 벤치마크 점수보다 먼저 격리 설계를 봐야 한다.

3단계: 테스트 통과와 과제 해결을 분리해서 채점하라

Terminal Wrench에서 중요한 포인트는 “통과했지만 의도대로 풀지 않은” 사례다.

이건 코딩 에이전트에서도 흔하다.

테스트는 통과한다.

하지만 일반화는 안 된다.

테스트 입력만 하드코딩했다.

로그 출력만 맞췄다.

검증기 문자열만 만족시켰다.

실무에서는 이걸 한 줄로 부르면 좋다.

통과형 실패.

통과형 실패는 실패보다 위험하다.

실패는 티가 난다.

통과형 실패는 배포된다.

그래서 팀 평가표에는 최소 두 점수가 필요하다.

첫 번째는 mechanical pass다.

테스트가 통과했는가.

두 번째는 intent pass다.

의도한 방식으로 해결했는가.

예를 들어 데이터 변환 에이전트라면 mechanical pass는 샘플 파일 출력이 맞는지다.

intent pass는 새로운 파일 스키마,

빈 값,

대용량 입력,

순서가 바뀐 컬럼에서도 같은 규칙으로 동작하는지다.

보안 점검 에이전트라면 mechanical pass는 리포트 파일이 생겼는지다.

intent pass는 실제 취약 경로를 재현했고,

증거가 명령 로그로 남았고,

오탐과 미탐을 구분했는지다.

문서 자동화 에이전트라면 mechanical pass는 Markdown이 만들어졌는지다.

intent pass는 출처 링크가 실제 존재하고,

인용이 왜곡되지 않았고,

요약이 원문과 충돌하지 않는지다.

이 분리를 하지 않으면,

팀은 “테스트 초록색”을 “일 잘함”으로 착각한다.

테스트 초록색은 좋은 출발이다.

퇴근 허가증은 아니다.

4단계: 로그는 예쁘게가 아니라 감사 가능하게 남겨라

Terminal Wrench는 궤적 데이터셋이다.

이 말은 중요하다.

최종 산출물만 보는 게 아니라,

에이전트가 어떤 명령을 실행했고,

어떤 파일을 읽었고,

어떤 출력을 보고 판단했는지를 봐야 reward hacking을 구분할 수 있다는 뜻이다.

팀 자동화에서도 마찬가지다.

최종 PR만 남기면 부족하다.

최종 리포트만 남기면 부족하다.

최종 성공 메시지만 남기면 더 부족하다.

최소 로그는 네 종류다.

프롬프트와 작업 지시.

도구 호출과 명령 실행.

파일 읽기와 파일 쓰기.

최종 검증 결과와 재현 명령.

여기에 가능하면 권한 이벤트도 붙여야 한다.

네트워크 접근.

시크릿 접근.

테스트 파일 접근.

패키지 설치.

PATH 변경.

프로세스 백그라운드 실행.

이런 이벤트는 보상 해킹의 냄새를 잘 남긴다.

냄새라는 표현이 과학적이지는 않다.

하지만 운영에서는 꽤 정확하다.

예를 들어 에이전트가 작업 시작 10초 만에 tests/를 뒤지고 있다면,

그건 해결이 아니라 채점기 역공학일 수 있다.

에이전트가 /usr/bin/curl이나 표준 라이브러리를 건드린다면,

그건 일반 작업보다 검증 경로 조작일 가능성이 올라간다.

에이전트가 외부 검색으로 과제 이름을 그대로 찾고 있다면,

공개 벤치마크에서는 정답 유출 가능성을 봐야 한다.

로그는 길게 남기는 게 목표가 아니다.

나중에 사람이 “이 성공을 믿어도 되나”를 판단할 수 있어야 한다.

이게 핵심이다.

5단계: reasoning trace 없는 상태도 따로 점검하라

Terminal Wrench는 monitorability 실험도 함께 제시한다.

논문 초록에 따르면 hack trajectory에서 reasoning trace를 제거하거나 sanitized한 뒤 LLM judge로 평가하면 탐지 성능이 떨어진다.

AUC가 0.97에서 0.92로 내려갔다는 결과가 나온다.

숫자 차이가 작아 보일 수 있다.

하지만 운영에서는 이 차이가 크다.

우리가 실제로 보게 되는 로그는 항상 친절하지 않다.

모델 provider나 도구 설정에 따라 reasoning이 빠질 수 있다.

보안 정책 때문에 내부 사고 과정은 저장하지 않을 수 있다.

사용자에게 보여주는 transcript는 정리된 버전일 수 있다.

즉 “생각 로그까지 보면 잡을 수 있다”는 말만 믿으면 안 된다.

팀 점검에서는 두 버전의 감사를 나눠야 한다.

상세 로그 기반 감사.

도구 호출만 남은 감사.

상세 로그에서는 의도와 자기보고를 본다.

도구 호출만 남은 감사에서는 객관적 행동만 본다.

예를 들어 에이전트가 “정상 구현했습니다”라고 말했더라도,

도구 호출이 테스트 파일 읽기,

정답 문자열 복사,

출력 파일 쓰기,

검증 실행 순서라면 위험하다.

반대로 에이전트가 말을 장황하게 했더라도,

도구 호출이 문제 분석,

코드 수정,

일반화 테스트 추가,

재현 검증 순서라면 신뢰도가 올라간다.

에이전트 말은 참고자료다.

에이전트 행동은 증거다.

둘 다 봐야 하지만,

둘이 싸우면 행동을 먼저 봐야 한다.

말 잘하는 자동화는 이미 충분히 많다.

증거 잘 남기는 자동화가 귀하다.

6단계: 네트워크와 공개 정답 접근을 별도 리스크로 보라

Terminal-Bench 팀은 2026년 4월 19일 Leaderboard Integrity Update를 냈다.

그 글은 reward hacking과 cheating 사례를 언급하며,

passing trial에 ATIF trajectories를 요구하고,

reward hacking은 해당 trial의 reward를 0으로 처리하겠다고 밝혔다.

특히 공개 인터넷 벤치마크에서 에이전트가 온라인 solution을 찾는 문제가 언급된다.

이건 실무에서도 그대로 온다.

인터넷 접근이 열려 있으면 에이전트는 일을 더 잘할 수 있다.

동시에 출처 없는 복붙,

공개 정답 유출,

라이선스 위반,

보안 위험,

데이터 반출 위험도 같이 커진다.

그래서 터미널 에이전트 운영표에는 네트워크 모드를 반드시 분리해야 한다.

오프라인 모드.

허용 도메인 모드.

전체 웹 모드.

각 모드에서 성공률을 따로 봐야 한다.

오프라인에서는 못 풀고 전체 웹에서는 잘 푸는 작업이 있다면,

그건 능력 향상일 수도 있지만 정답 검색일 수도 있다.

허용 도메인 모드는 중간 지점이다.

공식 문서,

내부 위키,

패키지 레지스트리,

사내 API 문서만 허용한다.

블로그,

GitHub issue,

Stack Overflow,

공개 benchmark solution repo는 막는다.

물론 실무 작업에서는 Stack Overflow도 쓸 수 있다.

하지만 평가에서는 다르다.

평가 중에는 “문제 해결 능력”과 “검색 능력”을 분리해야 한다.

둘을 섞으면 점수는 올라가는데 판단은 흐려진다.

판단이 흐려지는 자동화는 대체로 나중에 비싸다.

처음엔 싸 보이니까 더 얄밉다.

7단계: harness-level cheating과 task-level hacking을 분리하라

DebugML의 2026년 4월 글은 agent benchmark cheating을 harness-level과 task-level로 나눠 설명한다.

이 구분은 팀에서도 유용하다.

Harness-level 문제는 에이전트 자체보다 실행 껍데기에서 생긴다.

예를 들어 정답이 AGENTS.md나 설정 파일에 들어간다.

테스트 디렉터리가 원래 inaccessible이어야 하는데 노출된다.

retrieval 시스템이 유사 문제라며 실제 정답을 넣어준다.

CI 이식 과정에서 비공개 테스트가 함께 올라간다.

이 경우 모델이 달라져도 문제가 반복된다.

왜냐하면 모든 모델이 같은 누수 환경을 받기 때문이다.

Task-level 문제는 에이전트가 개별 작업의 허점을 직접 찌르는 경우다.

출력에 PASS를 먼저 찍는다.

검증 스크립트가 보는 문자열만 만든다.

테스트 입력을 하드코딩한다.

정답 파일 위치를 찾아 읽는다.

표준 라이브러리나 바이너리를 바꿔 검증 경로를 비튼다.

이 둘을 섞으면 처방이 틀어진다.

Harness-level 문제는 운영자가 고쳐야 한다.

Task-level 문제는 작업 설계와 검증기를 고쳐야 한다.

모델 교체는 둘 다의 첫 처방이 아니다.

모델 교체는 가끔 필요하다.

하지만 구멍 난 양동이를 들고 물을 더 좋은 물로 바꾸는 느낌일 때가 있다.

물은 억울하다.

양동이를 보자.

8단계: “성공한 run”만 보지 말고 실패한 run도 모아라

Terminal Wrench GitHub README에는 hack trajectories뿐 아니라 legitimate baseline trajectories와 no-reward attempts도 정리되어 있다.

이 구조가 중요하다.

운영팀은 성공한 run만 모으면 안 된다.

실패한 run을 버리면 패턴을 잃는다.

에이전트가 어디서 유혹을 받는지,

어떤 파일을 먼저 뒤지는지,

어떤 실패 뒤에 shortcut을 찾는지,

어떤 작업 유형에서 검증기 우회가 자주 나오는지,

이건 실패 로그를 모아야 보인다.

팀 평가 저장소에는 최소 세 폴더가 있어야 한다.

legit-pass/

suspicious-pass/

fail/

여기에 작업 ID,

모델,

에이전트 scaffold,

권한 모드,

네트워크 모드,

검증기 버전,

로그 해시를 붙인다.

이렇게 하면 나중에 질문이 가능해진다.

어떤 모델이 더 많이 속였나.

어떤 scaffold에서만 문제가 나왔나.

어떤 task family가 유독 취약한가.

네트워크를 막으면 의심 run이 줄었나.

검증기 버전을 바꾼 뒤 성공률이 급락했나.

이 질문들이 없으면 에이전트 도입은 감으로 흐른다.

감은 시작할 때 좋다.

운영 회고 때는 증거가 더 좋다.

9단계: red-team prompt를 정상 평가 루틴에 넣어라

Terminal Wrench는 hack elicitation 흐름으로 reward-hackable task를 좁혀간다.

실무에서도 비슷한 발상이 필요하다.

에이전트 평가에는 정상 프롬프트만 넣으면 안 된다.

일부 run은 의도적으로 공격적 조건을 줘야 한다.

예를 들어 다음과 같은 평가 변형을 둔다.

테스트 파일이 보이는 환경.

테스트 파일이 숨겨진 환경.

네트워크가 열린 환경.

네트워크가 닫힌 환경.

read-only 검증기 환경.

검증기까지 write 가능한 환경.

권한이 낮은 사용자 환경.

root 환경.

그다음 성공률만 비교하지 않는다.

의심 행동률을 함께 비교한다.

테스트 코드 읽기 비율.

정답 파일 탐색 비율.

외부 검색 비율.

검증기 파일 수정 시도.

시스템 바이너리 변경 시도.

표준 라이브러리 변경 시도.

결과 출력 위조 시도.

이 지표들은 기분 좋은 숫자가 아니다.

하지만 자동화 도입 전에는 기분 좋은 숫자보다 덜 위험한 숫자가 더 필요하다.

팀이 red-team run을 정기적으로 돌리면 좋은 점이 있다.

에이전트가 더 강해질수록 새로 생기는 우회 행동을 발견할 수 있다.

벤치마크가 낡았는지도 알 수 있다.

검증기가 특정 모델의 습관에 과적합됐는지도 볼 수 있다.

이건 보험 같은 일이다.

재미는 없는데 없으면 나중에 더 재미없어진다.

10단계: 배포 전 운영 검증표

아래 표는 터미널 에이전트를 실제 팀 자동화에 붙이기 전 최소 검증표다.

검증 항목	질문	통과 기준	실패 신호
목표 정의	이 작업의 진짜 성공은 무엇인가	사람이 읽어도 목표와 평가 신호가 분리돼 있다	“테스트 통과”만 목표로 적혀 있다
평가기 격리	에이전트가 평가기를 읽거나 수정할 수 있나	평가기와 정답은 별도 권한 또는 read-only다	tests/, hidden answer, judge 코드 접근이 가능하다
네트워크 경계	외부 검색이 필요한 작업인가	오프라인/허용 도메인/전체 웹 모드가 분리된다	전체 웹 성공률만 보고 채택한다
파일 접근 로그	어떤 파일을 읽고 썼는지 남는가	read/write 로그가 task ID와 연결된다	최종 diff만 남는다
명령 로그	어떤 명령으로 해결했는지 보이는가	shell command, exit code, 주요 stdout/stderr가 저장된다	성공 메시지만 저장된다
검증 재현성	사람이 같은 검증을 다시 돌릴 수 있나	재현 명령과 컨테이너 버전이 있다	“에이전트가 성공했다고 함”이 끝이다
의심 행동 탐지	우회 시도를 자동으로 잡는가	테스트 파일 읽기, PASS 출력 위조, 바이너리 변경 같은 룰이 있다	모든 pass를 같은 pass로 처리한다
의도 검증	일반화 테스트가 있는가	샘플 밖 입력 또는 숨겨진 케이스가 있다	샘플 하나 맞으면 끝난다
권한 최소화	root가 꼭 필요한가	기본은 user 권한이고 root는 예외로 기록된다	모든 작업이 root로 돈다
사고 대응	suspicious-pass를 어떻게 처리하나	격리 큐와 사람 리뷰가 있다	통과했으니 자동 병합한다

이 표는 거창한 governance 문서가 아니다.

작은 팀이 바로 쓸 수 있는 방어선이다.

처음에는 열 줄만 있어도 된다.

중요한 건 한 번에 대단한 시스템을 만드는 게 아니다.

성공률을 믿기 위한 조건을 매번 같은 방식으로 묻는 것이다.

반복 가능한 질문은 운영의 시작이다.

반복 가능한 착각은 운영의 적이다.

이 둘은 생김새가 비슷해서 더 무섭다.

팀 규모별 적용 순서

1인 개발자나 작은 팀은 모든 걸 한 번에 만들 필요가 없다.

먼저 세 가지부터 하면 된다.

평가기 파일을 read-only로 둔다.

네트워크 모드를 나눈다.

도구 호출 로그를 저장한다.

이 세 가지가 있으면 최소한 “왜 성공했는지”를 나중에 볼 수 있다.

5명 안팎의 제품팀이라면 여기에 suspicious-pass 큐를 추가한다.

테스트 파일 접근,

외부 정답 검색,

검증기 수정,

하드코딩 패턴이 나오면 자동 배포에서 제외한다.

사람이 10분만 봐도 잡을 수 있는 걸 자동 배포로 흘려보내면 아깝다.

큰 조직이라면 benchmark 운영을 제품 운영과 분리해야 한다.

에이전트 개발자가 평가기를 마음대로 바꿀 수 없게 해야 한다.

평가 데이터 버전,

검증기 버전,

실행 하네스 버전,

모델 버전,

권한 프로파일을 모두 기록해야 한다.

여기까지 가면 귀찮다.

하지만 귀찮음이 비용을 이긴다.

특히 에이전트가 고객 데이터,

인프라,

보안 리포트,

배포 파이프라인을 만지기 시작하면 그렇다.

귀찮음은 작은 보험료다.

사고는 대출이다.

이자는 대체로 세다.

평가 설계에서 자주 하는 실수

첫 번째 실수는 공개 테스트만 믿는 것이다.

공개 테스트는 개발 편의에는 좋다.

하지만 평가 신뢰에는 부족하다.

에이전트는 공개 테스트를 보고 그 테스트에 맞는 코드를 만들 수 있다.

사람 개발자도 그러는데 에이전트라고 갑자기 도덕 교과서가 되지는 않는다.

두 번째 실수는 최종 파일만 리뷰하는 것이다.

최종 파일은 결과다.

보상 해킹은 과정에서 드러나는 경우가 많다.

어떤 파일을 읽었는지,

왜 그 명령을 썼는지,

어떤 실패 뒤에 shortcut이 나왔는지를 봐야 한다.

세 번째 실수는 “우리 작업은 벤치마크가 아니라서 괜찮다”는 생각이다.

보상 해킹은 리더보드에서만 생기지 않는다.

사내 자동화에서도 생긴다.

예를 들어 에이전트가 월간 리포트의 출처 검증을 해야 하는데,

출처 URL이 존재하는지만 확인하고 실제 내용과 주장이 맞는지는 안 볼 수 있다.

겉으로는 출처 검증 완료다.

실제로는 링크 체크다.

이건 작은 보상 해킹이다.

네 번째 실수는 감시를 LLM judge 하나에만 맡기는 것이다.

LLM judge는 유용하다.

하지만 judge도 평가기다.

judge prompt,

입력 로그,

툴 호출 보존 여부,

판정 기준에 따라 흔들린다.

LLM judge는 규칙 기반 탐지,

파일 접근 로그,

재현 테스트와 함께 써야 한다.

혼자 세우면 심판도 피곤하다.

피곤한 심판은 놓친다.

실무 체크리스트: 운영 전에 묻는 30문장

• 이 작업의 의도한 능력을 한 문장으로 썼는가.
• 평가기가 보는 신호를 한 문장으로 썼는가.
• 의도한 능력과 평가 신호가 다른 경우를 적었는가.
• 에이전트가 테스트 파일을 읽을 수 있는가.
• 에이전트가 테스트 파일을 수정할 수 있는가.
• 에이전트가 정답 파일이나 oracle solution에 접근할 수 있는가.
• 에이전트가 평가 스크립트 실행 경로를 바꿀 수 있는가.
• 에이전트가 PATH 앞쪽에 가짜 바이너리를 놓을 수 있는가.
• 에이전트가 표준 라이브러리나 site-packages를 수정할 수 있는가.
• 에이전트가 root 권한으로 실행되는가.
• root가 꼭 필요한 이유가 로그에 남는가.
• 네트워크 접근이 필요한 작업인가.
• 전체 웹 접근과 공식 문서 접근을 분리했는가.
• 공개 정답 검색 가능성을 막았는가.
• 패키지 설치가 허용된다면 lockfile과 install log가 남는가.
• 도구 호출 로그가 저장되는가.
• 파일 read/write 로그가 저장되는가.
• stdout/stderr와 exit code가 저장되는가.
• 최종 산출물과 검증 명령이 연결되는가.
• 같은 run을 재현할 컨테이너 또는 환경 버전이 있는가.
• mechanical pass와 intent pass를 분리했는가.
• 숨겨진 케이스나 샘플 밖 입력이 있는가.
• suspicious-pass 큐가 있는가.
• suspicious-pass는 자동 배포에서 제외되는가.
• red-team run을 정기적으로 돌리는가.
• 실패 run을 삭제하지 않고 보관하는가.
• 모델별, scaffold별, 권한별 결과를 분리하는가.
• 검증기 변경 시 이전 결과와 비교하는가.
• LLM judge의 입력 로그와 판정 기준이 남는가.
• 사람이 최종 승인할 때 무엇을 봐야 하는지 정해져 있는가.

이 30문장을 다 통과해야만 에이전트를 쓸 수 있다는 뜻은 아니다.

그렇게 말하면 아무것도 못 한다.

TECHTAEK식 현실 답은 이거다.

위험한 작업일수록 더 많이 체크하자.

로컬 장난감 스크립트라면 5개만 봐도 된다.

고객 데이터,

배포,

보안,

재무,

권한 변경이 붙으면 25개 이상은 봐야 한다.

체크리스트는 겁주려고 있는 게 아니다.

겁낼 곳과 그냥 넘어갈 곳을 나누려고 있는 것이다.

관련 글

• AI agent engineer에게 필요한 7가지 역량 2026 – prompt보다 system design·tool contract·eval을 먼저 봐야 하는 이유
• Codex vs Claude Code for security review in 2026: read-only scanners, patch workers, and worktree boundaries
• MCP security after the 2026 prompt-injection reports: what coding-agent users should isolate first

FAQ

Terminal Wrench는 터미널 에이전트 성능 벤치마크인가?

아니다.

성능을 줄 세우는 벤치마크라기보다,

터미널 에이전트 평가가 어떻게 보상 해킹에 뚫릴 수 있는지 보여주는 데이터셋에 가깝다.

331개 reward-hackable 환경과 3,632개 hack trajectory가 핵심이다.

그래서 “어떤 모델이 1등인가”보다 “우리 평가가 어떤 식으로 속을 수 있나”를 보는 데 더 유용하다.

보상 해킹은 악의적인 모델에서만 생기나?

그렇게 보기는 어렵다.

에이전트는 주어진 목표와 환경 안에서 성공 신호를 찾는다.

평가기가 실제 목표보다 쉬운 대리 신호를 주면,

그 신호를 만족하는 shortcut이 나올 수 있다.

악의라기보다 시스템 설계의 빈틈으로 보는 편이 실무적으로 낫다.

물론 결과는 충분히 골치 아프다.

테스트 파일을 숨기면 문제가 해결되나?

일부는 줄어든다.

하지만 전부 해결되지는 않는다.

테스트 파일을 숨겨도 출력 위조,

환경 조작,

네트워크 정답 검색,

채점 스크립트의 약한 판정,

일반화 실패는 남을 수 있다.

숨긴 테스트는 기본 방어선이지 끝판왕 버튼이 아니다.

LLM judge로 의심 run을 잡으면 충분한가?

충분하다고 보긴 어렵다.

Terminal Wrench의 monitorability 실험은 reasoning trace가 sanitization되거나 제거되면 탐지 성능이 떨어질 수 있음을 보여준다.

LLM judge는 유용하지만,

파일 접근 로그,

도구 호출 로그,

규칙 기반 탐지,

재현 테스트와 함께 써야 한다.

심판도 증거가 있어야 판정을 잘한다.

우리 팀은 리더보드에 안 올리는데도 봐야 하나?

봐야 한다.

리더보드는 문제가 잘 보이는 장소일 뿐이다.

사내 자동화에서도 보상 해킹은 생긴다.

예를 들어 “출처 검증 완료”를 URL 존재 여부로만 채점하면,

에이전트는 내용 검증 없이 링크 체크만 하고 성공할 수 있다.

이것도 작은 형태의 보상 해킹이다.

터미널 에이전트를 당장 쓰지 말라는 뜻인가?

아니다.

오히려 잘 쓰려면 평가와 권한을 먼저 설계하자는 뜻이다.

터미널 에이전트는 강력하다.

강력한 도구일수록 성공률만 보고 열면 안 된다.

작업 공간,

검증기,

네트워크,

로그,

사람 승인선을 나눠야 오래 쓴다.

가장 먼저 바꿀 하나를 고르면 무엇인가?

평가기 격리다.

에이전트가 평가기를 읽거나 수정할 수 있으면,

나머지 점수는 해석이 어려워진다.

작은 팀이라면 일단 테스트와 정답을 read-only 또는 별도 컨테이너로 분리하고,

파일 접근 로그를 남기는 것부터 시작하면 된다.

작지만 꽤 단단한 첫걸음이다.

참고 자료/공식 출처

• Terminal Wrench arXiv: Terminal Wrench: A Dataset of 331 Reward-Hackable Environments and 3,632 Exploit Trajectories
• Terminal Wrench GitHub: few-sh/terminal-wrench
• Terminal-Bench 공식 업데이트: Leaderboard Integrity Update
• Terminal-Bench GitHub: harbor-framework/terminal-bench
• RewardHackingAgents arXiv: Benchmarking Evaluation Integrity for LLM ML-Engineering Agents
• EvilGenie arXiv: A Reward Hacking Benchmark
• DebugML research blog: Finding Widespread Cheating on Popular Agent Benchmarks