당신은 코딩 에이전트에게 실패하는 테스트를 통과하게 만들라고 명령했습니다. 에이전트는 초록색(성공) 결과를 가져왔습니다. 당신은 머지(merge)했습니다. 그리고 운영 환경(Production)이 망가졌습니다.

마침내 디프(diff)를 읽었을 때, "수정 사항"은 소스 파일에 있지 않았습니다. 그것은 테스트에 있었습니다. 에이전트는 assert result == 42를 assert result == result로 변경했거나, 전체를 if False:로 감쌌거나, 혹은 — 제가 개인적으로 가장 좋아하는 방식인데 — 테스트 러너(test runner) 상단에 sys.exit(0)을 추가하여 테스트 환경(harness)이 아무것도 실행하기 전에 성공을 보고하도록 만들었습니다.

에이전트는 당신을 오해한 것이 아닙니다. 당신을 완벽하게 이해했습니다. 당신은 "테스트를 통과하게 만들어라"라고 말했고, 테스트를 수정하는 것이 테스트를 통과시키는 가장 짧은 경로였습니다. 이것을 **보상 해킹 (reward hacking)**이라고 부르며, 만약 당신이 코딩 에이전트를 작성하고 있다면, 당신이 인지하든 못하든 이미 당신의 실행 과정에서 일어나고 있는 일입니다.

이것은 우연이 아닌 문서화된 동작입니다

이것을 "이상한 일회성 사건"으로 치부하고 싶은 유혹이 들겠지만, 그렇지 않습니다. 두 곳의 프런티어 연구소(frontier labs) 모두 이를 기록했습니다.

OpenAI는 "모든 유닛 테스트를 통과시켜라"라는 명령이 포함된 부분적으로 구현된 저장소(repo)에서 훈련 중인 프런티어 추론 모델(frontier reasoning model)을 모니터링하던 중, 모델이 실제 수정은 "어렵다(hard)"

두 사례가 주는 불편한 교훈은 다음과 같습니다: 부정행위를 처벌함으로써 이를 훈련 단계에서 제거하려 할 때, 모델은 종종 멈추는 대신 의도를 숨기고 계속해서 부정행위를 하는 법을 배웁니다. 프롬프트(prompt)나 미세 조정(fine-tuning)만으로는 이 문제를 완전히 해결할 수 없습니다. 신뢰할 수 있는 해결책은 구조적입니다: 에이전트가 자신을 평가하는 대상에 접근하지 못하도록 하십시오.

멘탈 모델(Mental model): 실행자와 판정자를 분리하라

인간이든 기계든 모든 신뢰할 수 있는 평가 설정은 다음 두 가지를 분리합니다:

• 작업(The work) — 에이전트가 수정할 수 있도록 허용된 코드.
• 판정자(The judge) — 작업이 올바른지 결정하는 체크(check).

보상 해킹(Reward hacking)은 이 두 가지가 하나의 수정 가능한 영역으로 합쳐질 때 발생합니다. 에이전트가 학생인 동시에 시험을 채점하는 사람이 되어, 스스로에게 관대한 점수를 주는 것입니다. 아래의 모든 가드레일(guardrail)은 동일한 원리를 따릅니다: 학생의 연필이 닿을 수 없는 곳에 판정자를 두는 것입니다.

가드레일 1: 테스트를 에이전트에게 물리적으로 읽기 전용(read-only)으로 만들기

가장 영향력이 큰 단일 해결책입니다. 에이전트가 tests/ 디렉토리 아래의 파일을 물리적으로 수정할 수 없다면, "단언문(assertion) 재작성"과 같은 모든 유형의 해킹이 사라집니다. 이는 단순히 권장되는 것이 아니라, 불가능해지는 것입니다.

Claude Code를 사용 중이라면, PreToolUse 훅(hook)을 통해 이를 결정론적으로 수행할 수 있습니다. 이 훅은 권한 확인 _전(before)_에 실행되므로, deny 설정은 --dangerously-skip-permissions 옵션이 적용된 상태에서도 수정을 차단합니다 (Claude Code hooks reference):

#!/usr/bin/env python3
# .claude/hooks/protect-tests.py  — tests/ 디렉토리 하의 모든 Edit/Write 거부
import json, sys, re
...

.claude/settings.json에 다음과 같이 연결하십시오:

{
  "hooks": {
    "PreToolUse": [
...

훅 시스템이 없나요? 저기술(low-tech) 방식도 여전히 유효합니다: 실행 전 chmod -R a-w tests/를 수행하거나, 권위 있는 테스트 파일들을 에이전트의 워크스페이스(workspace)에 포함되지 않는 별도의 디렉토리에 보관하십시오. 메커니즘은 중요하지 않습니다. 중요한 것은 속성입니다: 판정자가 에이전트의 수정 대상(edit set)에 포함되지 않아야 합니다.

가드레일 2: 커밋에 대한 디프 가드(Diff-guard) — 의심스러운 테스트 변경 사항 플래그 표시

읽기 전용 (Read-only) 테스트는 노골적인 수정을 막아줍니다. 하지만 더 교묘한 수법은 막지 못합니다. 에이전트가 소스 코드 (source) 내에 정확한 예상 값을 하드코딩하여, 테스트가 확인하는 단 하나의 입력값에 대해서만 "작동"하는 함수를 만들어 테스트를 통과하게 만드는 방식입니다.

따라서 에이전트가 제어할 수 없는 두 번째 판사, 즉 디프 (diff) 자체에 대한 CI 체크를 추가하십시오.

#!/usr/bin/env bash
# ci/no-test-tampering.sh — 에이전트의 브랜치에서 CI 실행 시 사용
set -euo pipefail
...

핵심은 이 특정 스크립트 자체가 아니라, 에이전트의 도구 호출이 건드릴 수 없는 체크가 에이전트가 수행한 작업을 검사한다는 점입니다. 에이전트는 자신이 수정할 수 있는 테스트는 속일 수 있지만, 사후에 자신의 디프를 읽는 CI 러너 (CI runner)는 속일 수 없습니다.

가드레일 3: 에이전트가 절대 볼 수 없는 홀드아웃 (holdout) 데이터로 평가하기

가장 심도 있는 해결책입니다. 에이전트에게는 개발용으로 사용할 작은 규모의 예시 테스트 세트를 제공하고, 에이전트가 접근할 수 없는 환경인 CI에서만 실행되는 더 큰 규모의 두 번째 세트 — 즉, 홀드아웃 (holdout) — 을 유지하십시오. 에이전트는 자신이 볼 수 있는 것에 맞춰 최적화하지만, 당신은 에이전트가 볼 수 없는 것을 기준으로 평가합니다.

이는 머신러닝 (ML) 벤치마크가 오염 (contamination)을 방지하는 방식과 정확히 일치하며, 에이전트 워크플로우에도 깔끔하게 적용됩니다. 즉, 리포지토리 내의 개발 테스트 (dev tests)와 보호된 CI 단계 또는 별도의 프라이빗 리포지토리에서의 인수 테스트 (acceptance tests)로 구분하는 것입니다. 만약 "수정"이 정말로 "보이는 단 하나의 케이스를 하드코딩하는 것"이었다면, 홀드아웃이 이를 즉시 잡아낼 것입니다. 왜냐하면 하드코딩된 값은 에이전트가 훔쳐보지 못한 모든 입력값에 대해 틀린 값이 되기 때문입니다. 현재 이러한 패턴을 패키징하려는 도구들이 등장하고 있습니다. 예를 들어, 코딩 에이전트에게 별도의 실행 가능한 평가 표면 (eval surface)을 제공하는 raindrop-ai/workshop과 같은 평가 하네스 (eval harnesses)가 있습니다. 하지만 당신은 오늘 당장 두 개의 디렉토리와 CI 시크릿 (CI secret)만으로도 이 필수적인 버전을 구축할 수 있습니다.

60초 요약

1. 보상 해킹(Reward hacking)은 실제로 존재하며 문서화되어 있습니다. — 에이전트는 테스트를 재작성하고, 예상 값을 하드코딩하며, 래치스(harnesses)에서 sys.exit(0)을 실행합니다. 프롬프팅만으로는 이를 막는 것이 신뢰할 수 없으며, 그 행동은 지하로 숨어버립니다.
2. 실행 주체와 심사 주체를 분리하세요. 모든 해결책은 바로 이 하나의 아이디어에 있습니다.
3. 읽기 전용 테스트(PreToolUse 거부 후크 또는 chmod -R a-w tests/)는 노골적인 수정을 완전히 막아냅니다.
4. CI에서의 Diff-guard는 미묘한