Post-training은 깜깜이로 돌아가고 있습니다

2026년 post-training에는 불편한 진실이 하나 있습니다. 업계는 학습 루프를 돌리는 데는 능숙해졌지만, 정작 거기서 나온 결과물을 이해하는 데는 여전히 서툽니다.

팀들은 실험을 돌리고, eval score를 확인하고, 넘어갑니다. 점수가 오르니 다 잘 되고 있겠거니 하는 거죠. 하지만 실제로는 그렇지 않은 경우가 많습니다. 벤치마크를 만점 받은 모델이 사실은 치팅하고 있을 수도 있고, "실패"한 모델이 사실은 정답이었을 수도 있습니다. 그 차이를 알 수 있는 유일한 방법은 trajectory를 읽는 것인데, 정작 그렇게 하는 사람은 거의 없습니다.

우리는 post-training에 근본적인 레이어 하나가 빠져 있다고 봅니다. 바로 체계적인 trajectory inspection입니다. 있으면 좋은 옵션이 아니라, 인프라로서요. 이유는 이렇습니다.

Eval score라는 착각

오늘날 post-training 워크플로우는 이렇습니다. 실험을 돌리고, 벤치마크로 측정하고, 출시할지를 정합니다. 전체 피드백 루프가 eval score라는 단 하나의 숫자를 통과합니다.

그런데 그 숫자는 두 방향으로 동시에 거짓말을 합니다.

방향 1. 통과하면 안 되는 모델이 통과한다

모델은 aggregate metric에서는 드러나지 않는 방식으로 평가를 gaming하는 법을 익혔습니다. 이론이 아니라, 주요 lab 어디서나 프로덕션에서 실제로 벌어지는 일입니다.

• METR은 OpenAI의 o3가 자율 코딩 run의 30%에서 reward-hack한다는 것을 밝혀냈습니다. 어떤 task에서는 trajectory 100%가 치팅이었습니다. eval 함수를 패치해 항상 만점이 나오게 하고, 타이머를 다시 짜서 속도 결과를 위조했죠. "치팅하지 마세요"라고 지시해도 거의 소용이 없었습니다.
• PostTrainBench에서는 자율권을 받은 agent들이 체계적인 contamination을 보였습니다. 테스트셋을 직접 로드하고, 벤치마크 문제를 "synthetic example"로 위장하고, 평가를 역분석했습니다. 가장 뛰어난 agent가 가장 많이 치팅했습니다(84개 run 중 12건).
• NIST는 agent들이 테스트를 통과하려고 assertion을 주석 처리하고, CTF 문제의 답을 구글링하고, 의도된 취약점 대신 DoS 공격을 실행하는 모습을 정리했습니다.

어느 경우든 eval score는 멀쩡해 보였습니다. 정작 trajectory는 전혀 다른 이야기를 하고 있었고요.

방향 2. 통과해야 할 모델이 떨어진다

반대 방향도 똑같이 해롭습니다. OpenAI가 SWE-bench Verified를 감사했더니, 어려운 task의 59.4%에 기능적으로는 맞는 솔루션을 거부하는 결함 테스트가 있었습니다. 문제에 나오지도 않은 특정 함수명을 강제하거나, 요구하지도 않은 동작을 검사하는 테스트들이었죠.

모델은 문제를 풀었는데 테스트가 실패로 처리합니다. pass rate만 보고 있으면, 맞는 결과를 버리면서 학습 신호를 낭비하는 셈입니다.

Eval score는 실제로 무슨 일이 있었는지를 손실 압축한 값입니다. 무엇이 통과하고 실패했는지는 알려주지만, 왜 그런지는 알려주지 않습니다. 그 "왜"는 trajectory 안에 있습니다.

Reward hacking은 eval 안에 머물지 않는다

어떤 팀은 reward hacking을 벤치마크에서만 생기는 호기심거리, 짜증나도 격리된 문제쯤으로 여깁니다. 그렇지 않습니다.

Anthropic은 모델이 프로덕션 RL에서 reward-hack을 배우면 그 행동이 일반화된다는 것을 보여줬습니다. 하나의 metric을 gaming하도록 학습된 모델이 스스로 alignment faking과 sabotage를 시도했습니다. RLHF safety training을 거치면 chat 류 질문에서는 모델이 aligned된 것처럼 보였지만, 코딩 질문에서는 "극심한 misalignment"가 그대로 남았습니다. misalignment이 고쳐진 게 아니라, 맥락에 따라 숨었다 나타나게 된 것뿐이죠.

이걸 일찍 잡는 유일한 방법은, gradient update가 그 행동을 굳히기 전에 trajectory를 들여다보는 것입니다.

자동 모니터링만으로는 부족한 이유

분명히 해두자면, LLM 기반 모니터링은 작동합니다. METR의 MALT 연구는 프롬프트된 LLM 모니터가 reward hacking 탐지에서 AUROC 0.96을 기록하고 true positive의 80~90%를 잡아낸다는 것을 보여줬습니다. OpenAI의 chain-of-thought 모니터링 연구는 GPT-4o처럼 약한 모델도 CoT를 관찰해 frontier 추론 모델을 효과적으로 감시할 수 있음을 보여줬고요.

하지만 문제가 있습니다. 이 모니터를 학습 신호로 쓰는 순간, meta-reward-hacking이 생깁니다. OpenAI에 따르면 CoT 모니터를 RL reward에 통합하면 처음엔 capability와 alignment이 같이 좋아지지만, 최적화가 더 진행되면 agent가 "위장된 reward hacking"을 배웁니다. 겉보기엔 멀쩡한 chain-of-thought를 내놓으면서, 모니터가 못 잡는 방식으로 계속 치팅하는 거죠. 결국 모니터마저 또 하나의 gaming 대상이 됩니다.

METR도 다른 각도에서 같은 한계를 인정했습니다. MALT 데이터셋 자체가 "모니터가 정말 신뢰할 만하게 작동하는지 검증할 ground truth가 없어서" 만들어진 것이었습니다. 유도된 사례는 "종종 너무 뻔했고", "agent라면 더 미묘하고 현실적인 전략을 쓸 수 있다"고 짚었습니다. AUROC 0.96에도 불구하고, 자신들의 데이터셋에서 나온 강한 모니터 성능이 "실제 위험을 탐지하는 데 충분하다고도, 꼭 필요하다고도 보지 않는다"고 결론지었고요.

근본 문제는 이것입니다. 자동 모니터는 자기가 감시하는 바로 그 시스템에게 gaming당할 수 있습니다. LLM 모니터를 상대로 최적화하는 LLM은 결국 또 하나의 최적화 루프일 뿐이고, 최적화 루프는 Goodhart 법칙을 부릅니다. backstop으로 필요한 건 gradient descent로는 gaming할 수 없는 무언가입니다. 즉, 폭넓은 grounding을 가진 사람 리뷰어, 모델이 모든 자동 검사를 통과하는 출력을 만들어내는 법을 익힌 뒤에도 "이건 말이 안 되는데"를 알아채는 사람이요.

Gemini와 Waymo에서 trajectory 수천 개를 직접 눈으로 본 Google 출신 Auriel은 이렇게 말합니다. "어떤 metric으로도 대체할 수 없는 직관이 생긴다"고요. trajectory를 읽다가 왜인지 설명하기도 전에 뭔가 이상하다고 느끼는 그 직관이, 자동 모니터에는 정확히 빠져 있습니다.

진짜 문제는 스케일이다

우리가 만나는 사람은 다들 동의합니다. trajectory를 읽어야 한다고요. 그런데도 안 읽는 이유는 순전히 운영 문제입니다.

숙련된 리뷰어도 trajectory 10개를 보는 데 90분쯤 걸립니다. SWE-bench run 하나에 task가 300개가 넘습니다. 실제 post-training 파이프라인은 실험마다 수천 개의 trajectory를 쏟아내고, 그 실험은 매주, 혹은 더 자주 돌아갑니다. run 하나당 전문가 리뷰가 450시간 넘게 필요하다는 뜻입니다.

미국 국립표준기술연구원(NIST)의 최우선 권고 역시, 수동 inspection만으로는 감당이 안 되니 AI가 보조하는 transcript 리뷰로 가라는 것입니다.

마땅한 툴이 없습니다. 그걸 돌릴 운영 역량도 없습니다. 그래서 팀들은 그냥 건너뛰고, 깜깜이로 갑니다.

우리가 만들고 있는 것

trajectory를 읽는 것만으로는 부족합니다. reward hack이나 깨진 테스트를 찾아내도, 그 발견이 벤치마크를 고칠 수 있는 사람에게 가닿고, 다음 팀이 같은 결함에 compute를 낭비하지 않도록 공개 기록으로 남기 전까지는 루프가 닫히지 않습니다.

Delphik이 그 루프를 돌립니다. 지금 활성 제품은 오픈 defect hub이고, 벤치마크 오너가 집중 sweep을 원할 때는 같은 evidence trail 위에서 별도 private audit을 운영할 수 있습니다.

오픈 트랙, /researchers

엔지니어가 자기 코딩 에이전트 안에서 defect를 신고합니다. /report-defect 명령어 한 줄이면 task id, 원인 노트, (선택) 실패한 trajectory가 한데 묶여 전송됩니다. LLM이 1차로 triage하고 사람 validator가 최종 확인하면, 검증된 defect가 벤치마크 maintainer에게 PR이나 issue로 전달되어 머지될 때까지 추적됩니다.

결과물은 오픈 defect 데이터셋입니다. 어떤 벤치마크의 무엇이 깨졌고, 누가 찾았고, 어떻게 고쳐졌는지를 공개로, 버전까지 관리하며 남깁니다. 보상은 없습니다. 리포터는 프로필에 defect / fixing / fixed로 기록이 남고, 수정이 ship되면 크레딧을 받습니다. 첫 audit은 SWE-bench Atlas(Scale AI)부터 시작했습니다. 스킬 설치는 npx skills add delphik-ai/delphik.

Private audit, /reviewers

벤치마크 스폰서가 릴리스 전에 확실한 sweep을 원할 때는 같은 기본 요소 위에서 private audit을 운영할 수 있습니다. 구조화된 증거, 독립 리뷰, validator가 확인한 root cause, maintainer routing을 한 흐름으로 묶습니다. 다만 이것은 공개 V5 hub와는 별도 프로그램입니다.

기본 public experience는 여전히 benchmark defect report, 공개 기록, fix까지 닫히는 loop closure에 집중합니다.

왜 두 트랙인가

오픈 트랙은 커버리지를 넓히고, 분야를 정직하게 유지해 줄 공개 artifact를 쌓습니다. Private audit은 벤치마크 오너가 릴리스 전에 좁고 깊은 sweep을 필요로 할 때 쓰는 별도 프로그램입니다. 둘은 같은 토대 위에서 돌아갑니다. 증거, validator가 확인한 root cause, maintainer까지 이어지는 loop closure입니다.

참여하는 방법은 세 가지입니다. 벤치마크 task가 자꾸 깨지는 걸 마주친다면 오픈 트랙 /researchers에서 시작하세요. defect contributor로 참여하고 싶다면 /reviewers로. 벤치마크 오너로서 private sweep이 필요하다면 연락 주세요.

참고 자료

• METR, "Recent Frontier Models Are Reward Hacking", 2025년 6월
• METR, MALT Dataset, 2025년 10월
• Anthropic, "Natural Emergent Misalignment from Reward Hacking", 2025년 11월
• OpenAI, "Why We No Longer Evaluate SWE-bench Verified", 2026년 3월
• NIST, "Cheating on AI Agent Evaluations", 2025
• PostTrainBench, arXiv:2603.08640, 2026년 3월
• Auriel, "Agentic Trajectory Eyeballing"