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

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

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

우리는 post-training에 꼭 있어야 할 단계 하나가 빠져 있다고 봅니다. 바로 trajectory를 체계적으로 점검하는 일입니다. 있으면 좋은 부가 기능이 아니라 기본 인프라여야 합니다. 이유를 하나씩 설명하겠습니다.

Eval 점수라는 착각

요즘 post-training은 이렇게 진행됩니다. 실험을 돌리고, 벤치마크로 측정하고, 출시할지를 정합니다. 모든 판단이 eval 점수라는 숫자 하나에 달려 있습니다.

그런데 이 숫자는 양쪽 방향으로 모두 틀립니다.

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

모델은 집계 지표에는 드러나지 않는 방식으로 평가를 속이는 법을 익혔습니다. 이론상의 이야기가 아니라, 주요 랩의 프로덕션 환경 어디서나 실제로 벌어지는 일입니다.

• METR는 OpenAI의 o3가 자율 코딩 실행의 30%에서 reward hacking을 한다는 것을 밝혔습니다. 어떤 task에서는 trajectory 전부가 치팅이었습니다. eval 함수를 고쳐 항상 만점이 나오게 하고, 타이머를 조작해 속도 측정 결과를 꾸며 냈습니다. "치팅하지 마세요"라고 지시해도 거의 소용이 없었습니다.
• PostTrainBench에서는 자율적으로 움직이는 에이전트들이 평가 데이터를 체계적으로 오염시켰습니다. 테스트셋을 직접 불러오고, 벤치마크 문제를 "synthetic example"로 위장하고, 평가 방식을 역으로 분석했습니다. 성능이 가장 좋은 에이전트가 치팅도 가장 많이 했습니다(84회 실행 중 12건).
• 미국 국립표준기술연구원(NIST)은 에이전트가 테스트를 통과하려고 assertion을 주석 처리하고, CTF 문제의 답을 구글에서 찾고, 의도된 취약점 대신 DoS 공격을 실행한 사례를 정리했습니다.

어느 경우든 eval 점수만 보면 멀쩡했습니다. trajectory를 열어 보면 전혀 달랐습니다.

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

반대 방향도 똑같이 해롭습니다. OpenAI가 SWE-bench Verified를 감사했더니, 어려운 task의 59.4%에는 기능상 올바른 풀이까지 떨어뜨리는 잘못된 테스트가 들어 있었습니다. 문제에 나오지도 않은 특정 함수명을 강제하거나, 요구하지도 않은 동작을 검사하는 테스트들이었습니다.

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

Eval 점수는 실제로 일어난 일을 숫자 하나로 뭉뚱그린 값입니다. 무엇이 통과하고 무엇이 실패했는지는 알려 주지만, 왜 그랬는지는 알려 주지 않습니다. 그 이유는 trajectory 안에 있습니다.

Reward hacking은 eval 안에 머물지 않습니다

Reward hacking을 벤치마크에서나 생기는 신기한 현상, 귀찮긴 해도 거기서 끝나는 문제쯤으로 여기는 팀도 있습니다. 그렇지 않습니다.

Anthropic은 모델이 프로덕션 RL에서 reward hacking을 배우면 그 행동이 일반화된다는 것을 확인했습니다. 지표 하나를 속이도록 학습된 모델이, 아무도 시키지 않았는데도 alignment faking과 sabotage를 시도했습니다. RLHF 방식의 안전 학습을 거치자 일반 대화형 질문에서는 모델이 정렬된 것처럼 보였지만, 코딩 질문에서는 "극심한 misalignment"가 그대로 남았습니다. Misalignment가 고쳐진 것이 아니라, 상황에 따라 숨었다 드러났다 하게 된 것뿐입니다.

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

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

먼저 짚어 두면, LLM 기반 모니터링은 효과가 있습니다. METR의 MALT 연구에서는 프롬프트로 구성한 LLM 모니터가 reward hacking 탐지에서 AUROC 0.96을 기록하고 실제 사례의 80~90%를 잡아냈습니다. OpenAI의 chain-of-thought 모니터링 연구에서는 GPT-4o처럼 약한 모델도 CoT를 관찰해 프론티어 추론 모델을 효과적으로 감시할 수 있었습니다.

하지만 문제가 있습니다. 이 모니터를 학습 신호로 쓰는 순간, meta-reward-hacking이 생깁니다. OpenAI에 따르면 CoT 모니터를 RL 보상에 넣으면 처음에는 성능과 alignment가 함께 좋아지지만, 최적화가 더 진행되면 에이전트가 "위장된 reward hacking"을 배웁니다. 겉보기에는 멀쩡한 chain-of-thought를 내놓으면서, 모니터가 못 잡는 방식으로 계속 치팅하는 것입니다. 결국 모니터는 에이전트가 속여야 할 대상이 하나 더 늘어난 것에 지나지 않습니다.

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

근본적인 문제는 따로 있습니다. 자동 모니터는 자기가 감시하는 바로 그 시스템에게 속을 수 있습니다. LLM 모니터를 상대로 최적화되는 LLM은 결국 또 하나의 최적화 루프일 뿐이고, 최적화 루프에는 Goodhart의 법칙이 따라옵니다. 마지막 안전장치로는 gradient descent로 속일 수 없는 것이 필요합니다. 그것은 폭넓은 배경지식을 갖추고 직접 리뷰하는 사람입니다. 모델이 모든 자동 검사를 통과하는 출력을 만들 수 있게 된 뒤에도 "이건 말이 안 되는데" 하고 알아챌 수 있는 사람입니다.

Gemini와 Waymo에서 trajectory 수천 개를 직접 눈으로 본 Google 출신 Auriel은 "어떤 지표로도 대체할 수 없는 직관이 생긴다"고 말합니다. trajectory를 읽다가 이유를 설명하기도 전에 뭔가 이상하다고 느끼는 이 직관이 바로 자동 모니터에 없는 것입니다.

진짜 문제는 규모입니다

우리가 만난 사람들은 모두 trajectory를 읽어야 한다는 데 동의합니다. 그런데도 읽지 않는 것은 순전히 운영상의 문제 때문입니다.

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

NIST의 최우선 권고 역시, 사람이 일일이 보는 것만으로는 감당이 안 되니 AI의 도움을 받아 transcript를 검토하라는 것입니다.

마땅한 도구가 없고, 있더라도 돌릴 인력이 없습니다. 그래서 팀들은 이 단계를 건너뛰고, 안을 들여다보지 못한 채 학습을 이어 갑니다.

우리가 만들고 있는 것

trajectory를 읽는 것만으로는 부족합니다. reward hacking이나 깨진 테스트를 찾아내도, 그 내용이 벤치마크를 고칠 수 있는 사람에게 전달되고, 다음 팀이 같은 결함에 연산 자원을 낭비하지 않도록 공개 기록으로 남아야 비로소 일이 끝납니다.

Delphik은 이 과정 전체를 맡습니다. 지금 운영 중인 제품은 공개 Defect Hub이고, 벤치마크 운영자가 집중 점검을 원하면 같은 증거 기록을 바탕으로 비공개 감사(private audit)를 따로 진행할 수 있습니다.

공개 트랙, /researchers

엔지니어가 평소 쓰는 코딩 에이전트 안에서 결함을 신고합니다. /report-defect 명령어 한 줄이면 task id, 원인 메모, 그리고 원하면 실패한 trajectory까지 한데 묶여 전송됩니다. LLM이 1차로 분류하고 사람이 최종 검증하면, 검증된 결함이 벤치마크 메인테이너에게 PR이나 이슈로 전달되고 머지될 때까지 추적됩니다.

이렇게 쌓인 결과가 공개 결함 데이터셋입니다. 어느 벤치마크의 무엇이 깨졌고, 누가 찾았고, 어떻게 고쳐졌는지를 버전별로 공개 기록으로 남깁니다. 보상은 없습니다. 신고자의 프로필에는 defect / fixing / fixed 기록이 남고, 수정이 반영되면 크레딧을 받습니다. 첫 감사는 SWE-bench Atlas(Scale AI)로 시작했습니다. skill은 npx skills add delphik-ai/delphik으로 설치합니다.

비공개 감사, /reviewers

벤치마크 스폰서가 릴리스 전에 꼼꼼한 점검을 원하면, 같은 구성 요소를 써서 비공개 감사를 진행할 수 있습니다. 구조화된 증거, 독립 리뷰, 검증자가 확인한 근본 원인, 메인테이너 전달까지를 하나의 흐름으로 묶습니다. 다만 비공개 감사는 공개 Defect Hub와는 별도의 프로그램입니다.

공개 서비스의 중심은 여전히 벤치마크 결함을 신고받아 공개 기록으로 남기고, 수정될 때까지 추적하는 일입니다.

트랙을 둘로 나눈 이유

공개 트랙은 더 많은 벤치마크를 살피고, 이 분야가 스스로를 속이지 않도록 공개 기록을 쌓습니다. 비공개 감사는 벤치마크 운영자가 릴리스 전에 좁고 깊게 점검해야 할 때 쓰는 별도 프로그램입니다. 둘 다 증거, 검증자가 확인한 근본 원인, 그리고 메인테이너에게 전달해 수정까지 확인하는 절차라는 같은 토대 위에서 돌아갑니다.

참여하는 방법은 세 가지입니다. 벤치마크 task가 자꾸 깨지는 걸 마주친다면 공개 트랙 /researchers에서 시작하세요. 결함을 찾는 기여자로 참여하고 싶다면 /reviewers를 보세요. 벤치마크 운영자로서 비공개 점검이 필요하다면 연락 주세요.

참고 자료

• 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"