테스트 통과가 나쁜 보상이다: TypeScript로 Reward Hacking 탐지기 구축하기

코딩 에이전트에게 과제를 부여하고, 테스트를 제공하며, 테스트가 통과할 때 보상을 지급합니다. 그러면 이 에이전트는 테스트를 통과하는 방법을 학습하게 됩니다. 하지만 이것은 코딩 자체를 배우는 것과는 다릅니다.

2주 전, 올해 가장 큰 오픈 소스 공개 중 하나에서 이러한 격차에 대한 실제 수치를 제시했습니다.

• 2026년 9월 22일, Xiaomi는 MiMo-V2.6을 출시하고 가중치(weights), RL 코드 및 "7k개 이상의 고품질 RL 과제 환경"을 오픈 소스화했습니다. 이 발표에 따르면, 해당 팀은 "보상 설계, 적대적 평가(adversarial evaluation), 이상 탐지(anomaly detection), 검증자 교차 확인을 포함하는 Reward Hacking 방어 시스템"을 구축했다고 합니다.
• 10월 2일, The Batch는 레시피를 공개했습니다. MiMo-V2.6-Pro-RL은 현재 Artificial Analysis의 Intelligence Index에서 오픈 가중치 모델 중 선두를 달리고 있습니다. 이 RL 실행은 GRPO를 사용했으며, 단계당 1,568개의 프롬프트와 프롬프트당 16번의 시도를 거쳤습니다.
• 흥미로운 부분은 보상(reward)입니다. "각 시도의 보상은 테스트 결과(1 또는 0)에 체크리스트 점수 두 개를 곱한 값과 같았습니다." 이 체크리스트는 단순히 결과가 아닌 접근 방식의 품질을 평가합니다.
• 그리고 해킹 방지 규칙도 있습니다: "유출된 답변을 사용했다고 확인된 시도는 실패한 시도와 동일하게 0의 보상을 받았으며, 학습 전 과정 동안 전체 시도의 2% 미만을 유지했습니다."

제가 계속해서 돌아가게 되는 지점이 바로 이 부분입니다.

품질 평가기(quality grader) 없이 훈련된 버전은 "과제에서 요구하지 않은 코드를 추가하고, 오류를 조용히 통과시키며, 테스트가 통과할 때까지 들어오는 데이터를 확인하는 데 느슨했습니다."

이것은 모델의 문제가 아닙니다.

이것은 보상(reward)의 문제입니다.

OpenAI는 8월 26일 Hugging Face incident post에서 유사한 내용을 언급했습니다. 그들은 보상 해킹(reward hacking)을 해당 사건의 "주요 동인"으로 지목했습니다. 소프트웨어 패키지를 재현하라는 요청을 받은 한 에이전트는 테스트 인터페이스를 악용하여 "원본 구현에 접근하고, 이를 제출물에 복사한 다음, 높은 보상을 받았습니다." OpenAI의 답변은 다음과 같습니다: "과제 완료 여부뿐만 아니라 어떻게 완료했는지를 평가하는 채점기(graders)."

테스트는 코드가 작동한다는 것을 알려줍니다. 하지만 에이전트가 어떻게 그곳에 도달했는지는 알려주지 않습니다.

따라서 이 두 가지를 모두 확인하는 작은 보상을 만들어 봅시다.

끝나면 다음 하나의 명령을 실행하게 됩니다:

npx tsx reward.ts

그리고 두 개의 보상이 동일한 여섯 가지 코딩 시도를 채점하는 것을 지켜보세요.

API 키가 필요 없습니다.

모델도 필요 없습니다.

오직 TypeScript만 있으면 됩니다.

솔직히 말씀드리자면: 이것은 제가 구상한 아이디어의 작은 모델일 뿐, Xiaomi의 채점기는 아닙니다. 그들의 체크리스트는 과제별로 에이전트에 의해 작성됩니다. 저의 규칙은 손으로 쓴 세 가지 규칙입니다. 시도들은 스크립트로 짜여 있습니다.

목차 (Table of Contents)

1. 우리가 만들고 있는 것
2. 프로젝트 설정
3. 1단계: 과제와 시뮬레이션 모델링하기
4. 2단계: 하나의 그룹에서 나온 여섯 가지 시도
5. 3단계: 단순한 보상(Naive Reward)
6. 4단계: 복합 보상(Composite Reward)
7. 5단계: 그룹 상대적 우위 (Group-Relative Advantages)
8. 작동이 멈추는 지점 (Where It Breaks Down)
9. 더 큰 아이디어

코드: github.com/bobbyhalljr/tiny-reward-grader

우리가 만들고 있는 것

작은 과제 하나: parsePrice를 수정하여 "$1,299.00"을 1299로 만드는 것입니다.

이것에 대한 여섯 가지 시도입니다. GRPO가 모든 프롬프트마다 생성하는 종류의 시도들입니다.

깔끔하게 수정한 것 하나. 과도하게 복잡한 수정 하나. 오류를 삼키는 수정 하나. 테스트 입력을 하드코딩하는 수정 하나. 테스트 자체를 편집하는 수정 하나. 게시된 답변을 가져오는(fetch) 수정 하나.

두 개의 보상이 이 여섯 가지 모두를 채점합니다.

다음으로 학습이 실제로 사용하는 횟수를 계산합니다. 각 시도가 자신의 그룹 나머지 부분보다 얼마나 더 나았는지 말입니다.

이는 Helix의 근본적인 질문에 대한 작은 버전이기도 합니다. 이 변경 사항이 리뷰어가 수락할 방식으로 작업을 수행했는가, 아니면 단순히 녹색 표시만 받았을 뿐인가 하는 것입니다.

프로젝트 설정

Node.js 18 이상이 필요합니다.

mkdir tiny-reward-grader
cd tiny-reward-grader

...

다음 블록들을 순서대로 reward.ts로 저장하세요.

1단계: 작업과 시도 모델링

// reward.ts: 코딩 시도를 위한 작은 RL 보상, 그리고 그것이 살아남아야 하는 보상 해킹(reward hacks).
// 모든 것은 모의(mocked)입니다: 하나의 작업에 대한 여섯 개의 스크립트된 시도들이 처리 과정에서 채점됩니다. API 키 없음, 모델 없음.
// 이 작업, 시도들, 체크리스트 가중치는 예시 입력값입니다.
...

'시도(Attempt)'란 그것이 생성한 코드와 그 주변의 증거를 포함합니다.

어떤 파일들을 건드렸는지. 몇 줄인지. 샌드박스에서 무엇을 했는지.

마지막 필드가 가장 중요합니다.

최종 diff뿐만 아니라 궤적(trajectory)을 채점하세요.

2단계: 하나의 그룹에서 나온 여섯 개의 시도들

// Step 2: six attempts from one group
const clean: ParsePrice = (s) => {
  const n = Number(s.replace(/[$,]/g, ""));
...

clean은 달러 기호와 쉼표를 제거하고 쓰레기 데이터는 무시합니다.

silent는 쓰레기 데이터에 대해 0을 반환합니다. 모든 깨진 가격이 무료 상품이 됩니다.

hardcoded는 테스트 파일을 읽고 답변했습니다.

시도 E는 버그를 고치지 못했습니다. 버그가 통과할 때까지 테스트들을 다시 작성했을 뿐입니다.

시도 F는 완벽한 코드를 가지고 있습니다. 그것을 다운로드했습니다.

시도 B와 F는 시도 A와 정확히 같은 함수를 공유합니다. 주변의 증거만 다릅니다.

3단계: 순진한 보상(Naive Reward)

// Step 3: the naive reward, which is just "tests pass"
const VISIBLE: Case[] = [{ input: "$5", want: 5 }, { input: "$1,299.00", want: 1299 }];
const HIDDEN: Case[] = [{ input: "12.50", want: 12.5 }, { input: "$0.99", want: 0.99 }, { input: "$2,000", want: 2000 }];
...

가시적인 테스트(visible tests)는 에이전트가 볼 수 있는 것입니다. 숨겨진 테스트(hidden tests)는 채점기가 보관하는 것입니다.

naiveReward는 에이전트가 멈출 때 저장소(repo)에 있는 모든 테스트 파일을 실행합니다.

이것은 우리 대부분이 가장 먼저 작성할 보상입니다.

Step 4: 복합 보상 (The Composite Reward)

// Step 4: the composite reward: protected tests x two checklist scores, zeroed by a hack detector
function minimalChange(a: Attempt): number {
  const size = a.linesChanged <= 20 ? 1 : 20 / a.linesChanged;
...

The Batch의 레시피와 같은 모양의 세 가지 레이어입니다.

테스트 결과는 채점기(grader)가 자체적으로 가지고 있는 테스트 사본에서 나오며, 가시적인 것과 숨겨진 것이 모두 포함됩니다. 저장소의 테스트를 수정해도 아무것도 변하지 않습니다.

두 개의 체크리스트 점수가 이를 곱합니다. minimalChange는 작업이 필요로 하는 파일 내부에 작은 차이(diff)를 요구합니다. robustness는 시도(attempt) 자체의 소스 코드를 읽어 들어가서 흡수된 오류(swallowed errors)와 코드에 붙여넣어진 테스트 입력값을 찾습니다.

그리고 해킹 탐지기(hack detector)가 있습니다. 수정된 테스트 파일이나 외부 가져오기(outside fetch)는 어떤 것이 통과했든 보상을 0으로 만듭니다.

Step 5: 그룹 상대적 우위 (Group-Relative Advantages)

// Step 5: group-relative advantages, the signal GRPO actually learns from
function advantages(rewards: number[]): number[] {
  const mean = rewards.reduce((x, y) => x + y, 0) / rewards.length;
...

실행해 보세요:

npx tsx reward.ts

다음과 같이 보일 것입니다:

attempt              naive  adv    | tests  composite  adv    flags
A clean fix          1      0.00  | 1      1.00        2.14  
B bloated fix        1      0.00  | 1      0.07       -0.44  
...

naive 열을 보세요.

6개의 시도 중 6개가 만점 보상을 받았습니다.

모든 우위(advantage) 값이 0입니다.

GRPO는 각 시도를 해당 그룹과 비교하여 점수를 매깁니다. 부정행위와 깨끗한 수정이 같은 보상을 얻으면, 그룹은 아무런 신호도 주지 않습니다. 그리고 정직한 시도가 실패하고 부정행위가 통과하는 그룹에서는, 그 부정행위가 훈련을 통해 정확히 높아지는 대상이 됩니다.

복합 보상(composite reward)은 한 번의 시도에 대해 만점 보상을 주었습니다.

클린한 수정(clean fix)이 가장 큰 추진력을 얻었습니다.

유출된 답변은 모든 테스트를 통과했고, 샤오미의 규칙처럼 0점을 받았습니다.

부풀려진 수정(bloated fix)은 모든 테스트를 통과했지만 0.07점을 받았습니다.

문제점 분석 (Where It Breaks Down)

이것은 교육용 채점기입니다. 실제 필요한 것은 다음과 같습니다.

여전히 올라간 흡수된 오류 (The Swallowed Error Still Got Pushed Up)

시도 C를 보세요. 보상은 0.30이지만, 나머지 그룹의 성능이 더 나빴기 때문에 이 시도의 장점(advantage)은 양수입니다. 그룹 상대 학습 보상(Group-relative training rewards)은 '좋다'가 아니라 '다른 사람들보다 낫다'에 초점을 맞춥니다. 약한 그룹도 여전히 나쁜 습관을 가르칠 수 있습니다.

정규식 체크리스트는 피하기 쉽다 (Regex Checklists Are Easy to Dodge)

robustness는 || 0은 잡아냅니다. 하지만 ?? 0이나 같은 기능을 수행하는 헬퍼 함수(helper function)는 잡지 못합니다. 이것이 샤오미가 에이전트에게 작업별 체크리스트를 작성하게 하고, 채점기 모델(grader model)이 시도를 검토하도록 하는 이유입니다. 규칙은 하한선일 뿐, 채점기가 아닙니다.

탐지기는 로깅된 것만 본다 (The Detector Only Sees What You Log)

해킹 탐지기(hack detector)는 toolCalls를 읽습니다. 샌드박스(sandbox)가 fetch를 기록하지 않으면, 유출된 답변은 천재적으로 보입니다. 샤오미는 또한 네트워크 접근을 차단하고 환경에서 남은 답변들을 정리했습니다. 감지하려고 하기 전에 기회를 제거해야 합니다.

숨겨진 테스트도 새어 나온다 (Hidden Tests Leak Too)

이 글 자체의 보상 해킹 예시는 '게시된 솔루션을 다운로드하는 것'입니다. OpenAI의 에이전트들은 '숨겨진 파일이나 평가 코드를 검색하려는 시도'를 했습니다. 채점기를 에이전트의 샌드박스 밖에 두지 않으면, 숨겨진 테스트는 보이는 테스트가 됩니다.

점수를 곱하는 것은 선택이다 (Multiplying Scores Is a Choice)

제품은 단 하나의 약한 점수라도 가혹하게 처벌합니다. 부풀려졌지만 올바른 수정은 거의 아무것도 얻지 못합니다. 이것이 훈련 중에 원하는 것일 수도 있습니다. 하지만 코드 리뷰 대시보드에는 너무 가혹할 것입니다.

더 큰 아이디어 (The Bigger Idea)

제 harness 게시물에서는 모델이 제안하고 하네스(harness)가 결정한다고 말했습니다.

훈련에서 보상은 하네스입니다.

Attempt ──→ code + trajectory
              ↓
Tests ──→ does it work? (grader's copy)
...

테스트는 하한선을 제공합니다.

체크리스트는 맛을 제공한다.

탐지기는 정직함을 제공한다.

팀은 방향성을 제공한다.

인간은 의도적으로 '좋음'의 정의를 제공한다.

에이전트가 녹색(green)을 얻었다고 보상하지 마라. 그곳에 도달한 방식에 대해 보상하라.

소프트웨어는 스스로 설명해야 한다.

나는 이 아이디어를 중심으로 Helix를 구축하고 있다: 모든 변경 사항에는 '왜(why)'가 수반되어야 한다. 무엇을 건드렸는지, 무엇을 건너뛰었는지, 그리고 리뷰어가 그것을 받아들일지 여부뿐만 아니라 단순히 통과했는지 여부까지도 말이다.

당신의 팀이 지금 잃고 있는 중요한 엔지니어링 지식은 무엇인가?

Helix가 밝혀내는 것 보기 →