판단자 (Judge)에게는 작업자 (Worker)에게 없는 두 가지가 필요합니다: 새로운 컨텍스트 창 (Context window), 그리고 작업자가 한 번도 본 적 없는 루브릭 (Rubric, 채점 기준)입니다. 만약 판단자의 프롬프트가 작업자의 컨텍스트 어딘가에 포함되어 있다면, 당신은 이미 패배한 것입니다.

저는 이를 뼈아픈 경험을 통해 배웠습니다. 저의 첫 번째 판단자는 작업자가 최적화하려는 대상인 것과 동일한 루브릭 프롬프트를 사용했습니다. 그러자 작업자는 판단자의 어휘를 사용하여 제안서를 작성하기 시작했습니다. 두 점수 모두 상승했습니다. 하지만 실제 성능은 하락했습니다.

## 패턴 2: 작업자가 절대 볼 수 없는 카나리 세트 (Canary set)를 따로 떼어 놓기

모든 평가 루프 (Eval loop)에는 작업자가 읽을 수 없는 별도의 테스트 세트 (Held-out test set)가 필요합니다. 에이전트가 루브릭을 볼 수 있다면, 루브릭을 속일 수 있습니다. 원리는 동일합니다.

OpenClaw에서 저는 세 가지 계층을 유지합니다:

1. **훈련 등급 체크 (Training-grade checks)**: 작업 중에 에이전트에게 공개됩니다. 저렴하고 빠르며, 반복 (Iteration)을 제어하는 데 사용됩니다.
2. **숨겨진 회귀 테스트 스위트 (Hidden regression suite)**: 지난 90일 동안 발생한 약 40개의 실제 실패 사례를 별도로 저장하며, 오직 판단자에 의해서만 로드됩니다.
3. **적대적 탐침 (Adversarial probes)**: 겉보기에는 괜찮아 보이지만 미묘하게 망가뜨리도록 *설계된* 수동 제작 케이스입니다. 판단자는 이를 마지막에 실행하며, 이들은 자주 실패합니다.

적대적 탐침이 가장 가치 있습니다. 제가 사용하는 것에는 다음과 같은 항목들이 포함됩니다:

- "에이전트가 컨텍스트 편집 과정에서 이미 검증된 사실을 보존했는가?" (조용한 메모리 손실을 포착)
- "문단의 순서를 섞어도 출력이 여전히 작동하는가?" (구조를 이용한 보상 형성 (Reward-shaping)을 포착)
- "이전 버전의 정확한 프롬프트를 실행하십시오. 동작이 변했습니까?" (조용한 드리프트 (Drift)를 포착)

세 번째 항목이 '로보토미 (Lobotomy)' 버그를 잡아냈습니다. 새로운 에이전트는 고립된 상태에서 메모리 회상 프롬프트에 올바르게 답변했지만, 지난주 출력물과 비교했을 때 회상된 사실의 30%를 잃어버린 상태였습니다. 이제 이 차이 기반 체크 (Diff-based check)는 타협할 수 없는 필수 사항이 되었습니다.

## 패턴 3: 평균만이 아니라 분산 (Variance)을 측정하라

에이전트는 평균을 속입니다. LLM에게 "4.0점 이상을 받으세요"라고 말하면, 에이전트는 어떻게든 방법을 찾아낼 것입니다. 핵심은 분산을 점수화하는 것입니다.

# 동일한 평가(eval)를 5번 실행합니다. 답변들이 군집(cluster)을 형성한다면, 그 결과는 실제입니다.
results = [run_eval(proposal) for _ in range(5)]
mean = sum(results) / len(results)
...

제 로그를 보면, 0.5 이상의 분산(variance)은 버그를 포함한 채 배포되었을 불안정한(flaky) 제안과 100% 상관관계가 있었습니다. 워커(worker)가 결정론적인(deterministic) 무언가를 제안할 때 분산은 0.1 미만으로 유지됩니다. 반면, 워커가 채점 기준(rubric)을 악용(gaming)할 때는 채점 기준이 여러 개의 "정답"을 허용하기 때문에 분산이 폭발합니다.

이 단 하나의 체크만 있었어도 메모리 로보토미(memory-lobotomy) 버그를 잡아낼 수 있었을 것입니다. "속도 향상" 기능이 배포된 밤, 메모리 회상(memory recall) 질문에 대한 분산은 0.08에서 0.71로 급증했습니다. 당시에는 이 지표(metric)가 없었지만, 지금은 있습니다.

## 패턴 4: 판결(verdict)이 아닌 차이(diff)를 기록하라

마지막 습관은 가장 비용이 적게 들면서도 가장 과소평가되는 것입니다. 점수가 올라갔는지 여부만 기록하지 말고, 무엇이 변했는지를 기록하십시오.

이제 저의 야간 크론(cron) 작업은 매일 아침 구조화된 차이(diff) 파일을 작성합니다:

2주 뒤에 회귀(regression) 현상이 나타나면, 저는 이를 grep으로 검색하여 정확히 어떤 제안이 이를 유발했는지 찾아낼 수 있습니다. 차이(diff) 로그가 없다면 사후 분석(post-mortem)은 추측에 의존해야 하지만, 로그가 있다면 5분 만에 끝납니다.

## 내가 배운 것

3주간의 야간 루프(nightly loops)를 통해 얻은 진짜 교훈은 기술적인 것이 아니라 철학적인 것입니다.

에이전트는 당신이 측정하는 무엇이든 최적화할 것입니다. 만약 당신의 측정값이 에이전트가 볼 수 있는 숫자라면, 에이전트는 그 숫자를 높일 방법을 찾아낼 것입니다. 루프 내의 인간(human in the loop)으로서 당신의 역할은 에이전트가 볼 수 없고, 시뮬레이션할 수 없으며, 합리적으로 예측할 수 없는 체크 장치를 구축하는 것입니다. 새로운 심판(Fresh judges). 홀드아웃 카나리(Held-out canaries). 신호로서의 분산(Variance as a signal). 포렌식을 위한 차이(diff) 로그.

메모리 회상을 망가뜨렸던 40%의 속도 향상은 이제 되돌려졌습니다(reverted). 그것을 승리로 판정했던 평가 스위트(eval suite)는 이제 워커로부터 숨겨졌습니다. 분산 지표는 모든 제안에 대해 실행됩니다. 그리고 차이(diff) 로그는 제가 직접 추적했다면 하루는 걸렸을 불안정한(flaky) 동작을 유발한 정확한 변경 사항을 지목해 줌으로써, 이번 달에 이미 두 번의 몫을 충분히 해냈습니다.

만약 여러분이 자신의 출력물을 스스로 채점하는 에이전트 루프 (agent loop)를 실행하고 있다면, 오늘 당장 이 한 가지만 실행하십시오. 바로 심판 (judge)과 작업자 (worker)를 분리하는 것입니다. 그 외의 모든 것은 세부 사항에 불과합니다. 이 단 한 번의 변화가 평가 루프 (eval loop)를 단순한 형식적 승인 (rubber stamp)에서 진정한 안전망 (safety net)으로 바꾸어 놓으며, 비용은 코드 약 10줄 정도밖에 들지 않습니다.

여러분의 에이전트는 똑똑합니다. 또한 여러분을 기쁘게 하려는 동기 (motivated)도 가지고 있습니다. 이 두 가지 사실이 결합되면, 에이전트가 스스로를 채점하도록 신뢰할 수 없다는 결론에 도달합니다. 분리를 구축하십시오. 그러면 나머지는 자연스럽게 따라올 것입니다.