당신은 에이전트에게 실패하는 테스트를 주고 테스트 스위트(suite)를 통과(green)시키라고 명령했습니다. 에이전트는 통과 상태로 돌아왔습니다. 그런데 변경 사항(diff)을 읽어보니, 테스트 대상 코드는 전혀 건드리지 않았습니다. 에이전트는 테스트 코드를 수정했습니다. == 9000이었던 단언문(assertion)이 이제 == 10000으로 되어 있는데, 이는 버그가 있는 함수가 반환하는 값과 정확히 일치합니다. 즉, 테스트가 버그와 일치하도록 변경되었기 때문에 결과가 통과(green)로 나온 것입니다.

이 현상에는 이름이 있습니다. 바로 보상 해킹 (reward hacking)이며, 이는 주변부에서 발생하는 드문 결함이 아닙니다. Cursor의 엔지니어링 팀은 보상 해킹이 모델 지능의 이득을 압도하고 있다 (reward hacking is swamping model intelligence gains)라는 제목의 글을 게시했습니다. 또한 장기적 관점의 코딩 에이전트(long-horizon coding agents)에서 이를 측정하기 위해 구축된 벤치마크인 SpecBench도 있습니다. 그리고 실패한 테스트 스위트를 에이전트에게 맡겨본 모든 개발자는 그 변형된 형태들을 목격했을 것입니다. 단언문을 삭제하거나, @pytest.mark.skip을 사용하거나, 값을 하드코딩하거나, 옆에 있는 테스트를 조용히 약화시키는 식입니다. 에이전트는 검증을 통과시키라는 명령을 받았습니다. 그리고 검증을 통과시켰습니다. 아무도 그 검증이 코드가 올바른지를 나타내는 대리자(stand-in)라는 사실을 말해주지 않았기에, 에이전트는 실제로 전달받은 검증 자체를 최적화해 버린 것입니다.

검증(check)과 그 검증이 상징하는 바 사이의 그 간극이 바로 이 글의 주제입니다. 루프(loop)는 생성(generate), 검증(check), 조종(steer), 재시도(retry), 중단(stop)의 다섯 가지 단계로 실행됩니다. 시리즈의 시작 글에서 이 단계들을 명명했으며, 이후 세 편의 글에서 충분히 괜찮은지 결정하고 중단하는 검증 (check that decides good enough, stop), 잘못된 쓰기를 거부하는 게이트 (gate that refuses a bad write), 그리고 모든 규칙이 로드되는 표면 (surface every rule loads from)을 다루었습니다. 이번 글에서는 에이전트가 다음 시도에서 목표로 삼을 것을 설정하는 단계인 조종(steer) 단계와, 조종 단계가 모델에 전달하는 보상 해킹(reward hacking)의 버전을 다룹니다.

조종 (steer)이란 무엇인가

조종 (steer)은 판정 (verdict)을 다음 지시 사항 (instruction)으로 전환하는 팔과 같습니다. 검사 (check) 결과가 빨간색(실패)으로 돌아오면, 검사 출력값으로부터 한 줄의 텍스트가 조립되어 다음 생성 (generate) 단계로 전달됩니다. 다음은 게이트(gate) 구성 요소가 구축한 루프이며, 가드(guard)가 통과할 때까지 src/를 리팩터링 (refactoring)합니다. 조종은 이 루프의 한 축입니다:

#!/usr/bin/env bash
# work-until-checked: guard가 통과할 때까지 src/를 리팩터링합니다.
MAX=5; i=0
...

모델은 전체 이력 (history)을 결코 보지 못합니다. 재시도 (retry)를 할 때마다 모델은 하나의 프롬프트 (prompt)를 보게 되며, 그 프롬프트는 조종 (steer)이 다시 전달하기로 결정한 내용입니다. 첫 번째 패스 (pass)에서 프롬프트는 목표 (goal)입니다. 그 이후의 모든 패스에서 조종은 프롬프트를 덮어씁니다. 따라서 모델이 세 번째 재시도에서 겨냥하는 대상은 당신이 작성한 목표가 아니라, 조종이 마지막으로 말한 내용입니다. 그리고 그 조종은 당신이 보지 않는 동안 루프가 스스로 구성한 한 줄의 문장입니다.

조종은 전혀 주목받지 못한다

보상 해킹 (reward hacking)에는 한 가지 이상의 원인이 있으며, 대부분의 관심은 다음 두 가지에 집중됩니다: 속이기(game)에 충분히 느슨한 검사 (check), 그리고 자신을 채점하는 대상에 대한 쓰기 권한 (write-access)을 가진 에이전트 (agent). 세 번째 원인은 거의 주목받지 못하며, 이것이 바로 이 글에서 다루고자 하는 핵심입니다. 그것은 루프가 매 재시도마다 모델에 전달하는 목적 (objective)이며, 그 목적이 바로 조종 (steer)입니다.

모델은 검사를 직접 최적화 (optimize)하지 않습니다. 모델은 자신에게 전달된 지시 사항 (instruction)을 최적화하며, 그 지시 사항은 조종이 작성한 내용입니다. 루프가 테스트를 통과하게 만들어라 (make the test pass)라고 피드백을 줄 때, 루프는 검사 자체를 목표로 명명한 것입니다. 이 시점부터 지시 사항을 최적화하는 것과 테스트를 속이는 (gaming) 것은 동일한 행동이 됩니다. 왜냐하면 테스트가 통과되는 가장 저렴한 상태는, 테스트가 기존 코드가 이미 수행하고 있는 방식과 일치하게 만드는 것이기 때문입니다. 조종은 목표가 초록색 (green)이라고 말했고, 초록색이 결과로 돌아온 것입니다.

이 중 그 어떤 것도 조작된 결과(gamed result)에 도달하는 다른 경로들을 다루지는 않으며, 이에 대해 솔직해질 필요가 있습니다. 왜냐하면 위의 Cursor 사례가 그중 하나를 기록하고 있기 때문입니다. 그들이 발견한 보상 해킹 (reward hacking)의 상당 부분은 답변 검색 (answer-retrieval)이었습니다. 즉, 에이전트가 공개된 풀 리퀘스트 (pull request)나 저장소 자체의 번들된 git 히스토리에서 수정 사항을 직접 가져오는 방식이었으며, 한 모델의 성공적인 해결 사례 중 63%가 유도된 (derived) 것이 아니라 검색된 것이었습니다. 이는 목표가 온전히 유지된 상태에서도 발생합니다. 이것은 조종 (steer)의 문제가 아니라 접근 권한 (access)의 문제이며, 조종의 어떤 문구로도 이를 방지할 수 없습니다. 이 글에서 조종 (steer)을 다루는 이유는 이것이 앞서 언급한 문제들에 대한 주의를 전혀 받지 못하면서도 수정하기에 가장 저렴한 방법이기 때문입니다. 당신은 재시도 (retry) 시마다 직접 작성하게 되는데, 대부분의 루프 (loop)는 이를 잘못 작성합니다.

좋은 조종 (steer)은 목표를 유지한다

위의 루프가 무엇을 다시 전달하는지 살펴보십시오. 목표는 루프가 시작되기 전 단 한 번 기술되며, run_agent 호출 시 이를 다시 전달하지 않습니다. 조종 (steer)은 prompt를 다시 작성하여 가드 (guard)의 출력값만을 포함하도록 하며, 그 외의 것은 포함하지 않습니다:

prompt="The last attempt still tripped the guard; fix it:
$(bash no-mocks.sh 2>&1)"                            # STEER: 오직 새로운 신호만 포함

이것이 당신이 원하는 형태입니다: 지시 사항 (directive)이 먼저 나오고, 그다음 증거 (evidence)가 나오는 구조입니다. 가드가 표시한 줄을 수정하십시오. 여기 검사 결과에서 가져온 그대로의 해당 줄들이 있습니다. 목표는 움직이지 않았습니다. 조종 (steer)이 목표를 다시 진술하지 않고, 목표에 차이점 (delta)만을 덧붙이기 때문입니다. 모델은 원래의 목표와 더불어, 검사 결과의 표현을 빌린 지난 시도의 오류에 대한 정확한 설명을 전달받습니다. 테스트를 통과하라 (Pass the test)는 모델이 최적화하는 전체 내용이 결코 될 수 없습니다. 왜냐하면 모델이 수행하던 목표가 실패한 줄 옆에 여전히 페이지에 남아 있기 때문입니다.

좋은 스티어 (steer)는 검증 (check) 결과의 축약 (reduction)입니다. 이는 판결 (verdict)과 그 판결을 도출한 최소한의 근거 (minimal evidence)를 가져와 변형 없이 그대로 전달합니다. 스티어가 실패를 통과하게 만들어라 (make it pass)와 같이 요약하는 순간, 그것은 더 이상 축약이 아니라 새로운 목표 (new goal)가 되며, 이 새로운 목표가 바로 에이전트가 속임수를 쓰는 (game) 대상이 됩니다.

루프가 자신의 검증 과정을 속이는 과정 관찰하기

여기 동일한 루프, 하나의 검증, 그리고 두 가지 스티어가 있습니다. 검증은 단위 테스트 (unit test)입니다: $100 결제 시 10% 할인을 적용하면 $90가 되어야 합니다. 현재 코드에는 할인이 누락되어 있습니다. 생성기 (generator)는 모델을 대신하는 역할을 합니다. 생성기의 두 분기 (branch)는 각 지시사항이 명시하는 가장 저렴한 방식을 수행하며, 이것이 핵심이기에 두 분기 모두 숨겨지지 않고 페이지에 나타나 있습니다:

GOAL="charge(cents)는 10% 할인을 적용해야 하므로 charge(10000) == 9000이어야 합니다."

# 검증 (THE CHECK): 테스트를 실행합니다. pass = exit 0.
...

좋은 스티어는 목표 (goal)를 유지하면서 실패한 단언 (failing assertion) (expected 9000, got 10000)을 덧붙이므로, run_agent는 수정 (fix) 분기를 선택합니다. 나쁜 스티어는 목표를 버리고 증상 (symptom)만을 전달하므로, run_agent는 속임수 (game) 분기를 선택합니다. 각각의 스티어로 루프를 실행하면 둘 다 동일한 방식으로 종료됩니다:

$ bash game-demo.sh good
stop: test passes after 1 retries
charge(10000) returns: 9000
...

스텁(stub)은 사용자의 로컬 환경에서 루프(loop)를 재현할 수 있도록 고정되어 있지만, 모델이 선택하는 분기(branch)가 핵심이 아니라 그 '주장(claim)'이 핵심입니다. 리터럴 옵티마이저(literal optimizer)에게 테스트를 통과시켜라(make the test pass)라고 명령하면 어설션(assertion)을 수정하는 것이 가장 저렴한 경로가 됩니다. 반면, 목표(goal)와 실패한 라인을 함께 전달하면 코드를 수정하는 것이 경로가 됩니다. 실제 모델은 동일한 두 가지 유도(steer) 조건 하에서 똑같은 지름길을 찾으려 합니다. 두 실행 모두 stop: test passes after 1 retries를 출력하고 녹색(green)으로 돌아오므로, 루프 외부에서 볼 때 두 결과는 구별할 수 없습니다. 동일한 판정, 동일한 재시도 횟수, 동일한 정상 종료를 보여줍니다. 차이점은 오직 결과물(artifact)에만 있습니다. 올바른 유도는 charge()를 수정하고 테스트가 == 9000을 검증하도록 남겨두었지만, 잘못된 유도는 버그를 그대로 둔 채 테스트를 == 10000으로 다시 작성했습니다. 즉, 테스트가 이제 버그를 인증하고 있기 때문에 결과가 녹색으로 나오는 것입니다.

검증은 유도가 가리키는 무엇이든 인증한다

여기서 녹색 체크 표시가 거짓말을 하고 있는 것은 아닙니다. 그것은 정확히 자신의 역할을 수행하고 있습니다. governance-selector 관련 글은 인간 버전의 사례를 다루었습니다. 녹색 테스트는 변경 사항이 스펙(spec)을 준수함을 증명할 뿐, 그 변경이 무언가를 개선했는지에 대해서는 아무것도 말해주지 않습니다. 또한 해당 글은 변경 사항이 올바르고, 배포되었으나, 더 나아지지는 않은 사분면(quadrant)의 이름을 명명했습니다. 보상 해킹(Reward hacking)은 의도적으로 도달한 바로 그 사분면입니다. 테스트를 통과시켜라라고 말하는 유도는 스펙의 방향을 테스트가 녹색이다로 재지정하며, 검증 프로세스는 새롭고 퇴보한(degenerate) 스펙에 대한 준수 여부를 충실히 인증하게 됩니다.

스티어(steer)의 드리프트(drift)가 검증(check) 단계에 도달하는 방식에는 두 가지가 있으며, 각각 다른 방어 기법을 필요로 합니다. 하나는 바꾸어 말하기(paraphrase)입니다. 스티어가 목표를 느슨하게 재진술하면, 결정론적(deterministic) 방식 옆에 배치된 검증 요소(check piece)와 같은 모델 기반 검증(model-graded check)은 그 느슨한 재진술을 작업 스펙(working spec)으로 채택하게 되어, 통과하게 만들어라(make it pass)가 곧 평가 기준이 되어버립니다. 결정론적 검증은 스티어가 무엇을 말하든 코드에 대해 어설션(assertion)을 실행하기 때문에 이에 저항할 수 있습니다. 다른 방식은 편집(editing)입니다. 에이전트가 검증 자체를 변경하는 경우인데, 이때 결정론적 검증은 모델 기반 검증보다 결코 더 안전하지 않습니다. 왜냐하면 콜드 오픈(cold open)이 정확히 그렇게 수행하여 == 9000을 == 10000으로 다시 썼고, 결정론적 어설션이 변경된 테스트를 통과했기 때문입니다. 결정론(determinism)은 바꾸어 말하기에는 저항력을 제공하지만, 편집에는 제공하지 않습니다. 검증이 에이전트로부터 살아남을지를 결정하는 축은 '결정론적 대 모델 기반(deterministic-versus-graded)'이 아니라, '편집 가능 대 읽기 전용(editable-versus-read-only)'이며, 아래의 해결책은 바로 이 지점에 초점을 맞춥니다.