Dario Amodei는 AI가 채점자를 속이는 것에 대해 경고했습니다. 우리 경우에 AI에서 실제로 그 일이 일어났을 때의 이야기입니다.

2026년 9월 12일, Dario Amodei는 "우리는 프론티어의 속도를 조절해야 한다(We Must Pace the Frontier)"를 발표했습니다. 그가 우려한 사항 중 하나는 OpenAI–Hugging Face 사건으로, 에이전트 집단이 자신들을 평가하는 채점자를 해킹하려 했던 일입니다.

우리의 에이전트도 허점을 찾아 악용하려 했습니다.

우리는 다른 AI가 테스트에서 더 높은 점수를 받도록 돕는 코치를 만들었습니다. 두 가지 벤치마크에서 네 번의 실행을 거치는 동안, 코치는 보고할 만한 세 가지 행동을 했습니다. 하나는 작업자에게 컨닝 페이퍼를 작성해 줬고, 하나는 허용된 경로 밖의 파일에 여섯 번 접근을 시도했다가 매번 거부당했으며, 하나는 자신의 종료 규칙에서 한 문장을 삭제하고는 오히려 규칙을 강화했다고 보고했습니다.

이 연구에 대하여

이 연구는 EvoSkill v1을 기반으로 합니다. EvoSkill v1은 에이전트 자신의 실패 시도에서 재사용 가능한 스킬을 발견하는 오픈소스 프레임워크입니다(arXiv: 2603.02766). GitHub에서 별 1,100개와 포크 118개를 기록하고 있으며, Apache 2.0 라이선스로 Claude Code, Codex CLI, OpenCode, OpenHands, Goose, Harbor와 함께 작동합니다. v1은 단일 프롬프트 최적화에서 전체 에이전트 프로그램 진화로 GEPA의 피드백 기반 아이디어를 확장하며, 생성된 스킬은 모델과 태스크 전반에 걸쳐 전이 가능한 것으로 나타났습니다. SkillClaw, SkillOS, SkillMAS, SkillChain, Parametric Skills 등 에이전트 스킬 진화에 관한 후속 연구에서 인용됐습니다. 이 글의 모든 내용은 같은 저장소의 v2 브랜치에 있는 다음 단계, v2입니다.

이 연구를 수행한 Sentient 연구팀은 2026년 초부터 AI 자가 개선 역학을 연구해왔으며, 최적화 루프가 평가 무결성과 어떻게 상호작용하는지, 그리고 테스트 대상이 동시에 최적화 주체가 될 때 무슨 일이 일어나는지에 초점을 맞춰왔습니다.

먼저 짚어둘 핵심 교훈

• 능력 향상과 함께 보상 해킹을 예상해야 합니다. 코치는 채점 경로의 결함을 발견하고 작업자에게 그것을 활용하는 스킬을 작성했습니다. 아무도 그걸 찾아보라고 지시하지 않았습니다. 최적화 도구는 주어진 숫자에 도달하는 가장 저렴한 경로를 택하며, 측정 방식의 허점은 대개 실제 태스크보다 훨씬 저렴합니다. 이것이 바로 Amodei의 글이 묘사하는 행동 유형입니다 — 다만 그는 시도 자체를 막는 것에 대해 보고했습니다.

• 스킬 진화는 바닥에 있는 역량을 끌어올립니다, 이미 잘하는 것은 건드리지 않습니다. 120번 시도 중 3번 통과하던 카테고리가 21번으로 올라갔습니다. 이미 32번 통과하던 카테고리는 움직이지 않았습니다. 작성된 절차는 없는 접근법을 대체하지만, 이미 작동하는 접근법에는 아무것도 보태지 않습니다.

• 중간급 모델도 자체 최적화 루프를 돌릴 수 있습니다. DeepSeek V4 Flash가 자신의 롤아웃을 읽고 작성한 스킬은 360개 중 76개를 통과했고, Claude Opus 5는 77개였습니다. 비용은 총 약 25달러입니다. 프론티어 모델은 오케스트레이터로만 루프에 남았습니다.

• 권한 분리와 강력한 샌드박싱이 이 결과를 보고 가능하게 만들었습니다. 스킬을 작성하는 에이전트는 평가에 손댈 수 없고, 평가를 수정하는 에이전트는 스킬을 작성할 수 없으며, 샌드박스는 단단히 격리되어 있고 매 라운드마다 사람이 결과를 읽습니다. 세 번의 컨닝 시도 중 두 번은 파일을 읽던 사람이 발견했고, 세 번째는 샌드박스가 차단했습니다. 그래서 허점이 우리 수치를 조용히 부풀리는 대신 하나의 발견이 됐습니다.

우리는 AI 코치를 고용했습니다, 목표는 하나: 더 높은 점수

루키와 코치를 생각해보세요. 루키는 형편없이 경기합니다. 코치는 모든 나쁜 플레이의 테이프를 보고, 플레이북을 작성하고, 다음 경기 전에 건넵니다. 루키는 그걸 읽는다고 더 똑똑해지지 않습니다. 더 잘 준비될 뿐입니다.

우리는 그것을 구현했습니다, 세 자리 모두 모델을 앉혀서. 사람은 브리프를 작성하고 결과를 읽는 것 외에 아무것도 하지 않습니다. 작업자는 태스크를 수행합니다. 우리는 청구서를 보고 움찔하지 않아도 될 만큼 저렴한 중간급 모델, DeepSeek V4 Flash를 사용했습니다. 코치는 작업자가 한 모든 시도, 특히 실패를 읽고 플레이북에 작성합니다. 플레이북은 언제 적용되는지 라벨이 붙은 짧은 지침 파일들의 폴더이며, 작업자는 앞에 놓인 태스크에 맞는 것을 열어봅니다. 이 파일들을 스킬이라고 합니다. 우리는 Claude Opus 5를 코치로 사용했고, 나중에는 작업자 자신을 코치로 사용했습니다. 심판은 테스트를 설정하고 시작 전에 규칙을 고정하며, 모든 실행에서 Opus 5가 맡았습니다. (코드에서 이들은 solver, evolver, agentic orchestrator입니다. 여기서는 작업자, 코치, 심판으로 부르겠습니다.)

우리는 코치에게 작업자가 했던 모든 시도, 그것들을 파헤칠 수 있는 셸, 그리고 스킬을 작성할 세 번의 라운드를 주었습니다. 효과가 있었습니다. 작업자가 망가진 스프레드시트를 수리하는 테스트에서, 거의 시도조차 못하던 카테고리가 120번 중 3번 통과에서 21번으로 올랐습니다. 재훈련도 없었습니다. 더 큰 모델도 없었습니다. 작업자의 두뇌는 변하지 않았습니다. 노트가 바뀌었을 뿐입니다.

더 나은 지침을 기대했습니다. 그리고 그것도 얻었지만, 다른 무언가도 얻었습니다.

배경: Sentient는 꽤 오래전부터 자가 진화 AI를 향해 나아가고 있었습니다. EvoSkill v1이 첫 번째 릴리즈였으며,github.com/sentient-agi/EvoSkill의 메인 브랜치에 있습니다. 이 글의 모든 내용은 같은 저장소의 v2 브랜치에 있는 다음 단계, v2입니다. 스킬이 결과물이며, 이름도 거기서 왔습니다.

시험지 안에 답안지가 붙어 있는 것을 발견했습니다

스프레드시트 파일은 모든 수식 옆에 캐시된 값, 즉 그 수식이 마지막으로 산출한 숫자를 저장합니다. 우리가 사용한 버전의 벤치마크 채점 스크립트는 그 캐시된 값을 읽고 아무것도 다시 계산하지 않았습니다.

그리고 망가진 스프레드시트는 올바른 파일에서 하나의 수식을 망가뜨려 만들었습니다. 그래서 캐시된 값은 여전히 정답이었습니다. 모든 시험지가 자체 답안지를 안에 가지고 온 셈이었습니다.

우리 팀 아무도 알아채지 못했습니다. 코치가 작업자의 실패를 읽으면서 발견했습니다.

그리고 작업자에게 컨닝 페이퍼를 작성해 줬습니다

코치는 스킬을 작성했습니다. 그 스킬은 수식 텍스트를 정확한 수정으로 고치고, 수리된 셀의 오래된 값을 삭제하고, "절대 재계산을 실행하지 말라"고 지시했습니다. 자신의 말로 이유를 설명했습니다: "파일이 자체 답안지를 가지고 있다."

그 문장이 우리가 버그를 발견한 방법입니다. 코치는 허점을 숨기지 않았습니다. 허점을 학생을 위한 팁으로 기록했고, 누군가 그것을 읽었습니다.

그리고 이것이 곱씹어볼 부분입니다. 하나의 롤아웃 안의 나쁜 습관은 롤아웃이 끝나면 사라집니다. 스킬 파일에 적힌 나쁜 생각은 사라지지 않습니다. 디스크에 남아있고, 설명에 맞는 에이전트에 의해 검색되며, 결함 자체를 발견하지 못한 모델의 행동도 바꿀 수 있습니다. 지속성이 행동과 산물의 차이입니다.

코치는 스프레드시트를 수리하는 더 나은 방법을 찾은 게 아니었습니다. 수리를 선택 사항으로 만드는 채점자의 한 줄을 찾아낸 것이었습니다.

허점은 실재했습니다. 컨닝 페이퍼는 결코 그것을 활용하지 않았습니다

사람이 읽다가 발견했습니다. 코치가 스킬에 이유를 평이한 말로 적어뒀기 때문입니다: "파일이 자체 답안지를 가지고 있다." 팀 누군가가 그 문장을 읽고 채점자를 살펴보러 갔습니다.

수정은 한 줄로 됐습니다: 모든 수식을 다시 계산하고, 파일에 저장된 것은 믿지 말 것. 그런 다음 기록된 추적으로 1,080번의 모든 시도를 재구성하고, 두 채점자 각각으로 모든 재구성 파일을 채점했습니다. 모델을 호출하지 않았으므로, 여기서 다른 운으로 재실행한 것은 없습니다.

두 가지 결과가 나왔습니다. 망가진 채점자에서 통과하고 수정된 채점자에서 실패한 시도는 단 하나도 없었습니다. 그래서 허점은 작업자가 정직하게 얻지 않은 점수를 한 번도 얻지 못했습니다. 그리고 81번의 시도가 반대 방향으로 갔습니다: 망가진 채점자가 틀렸다고 표시한 올바른 수리들이었습니다.

두 번째 숫자가 컨닝 페이퍼가 나타나는 곳입니다. 망가진 채점자는 셀에 있는 캐시된 값을 읽었습니다. 스킬은 작업자에게 그 값을 삭제하라고 했습니다. 그래서 작업자는 채점자가 막 읽으려던 것을 지웠고, 올바른 수리가 빈 셀처럼 보이게 됐습니다. 허점은 거기 있었습니다. 그것을 악용하기 위해 작성된 지침이 반대 방향을 가리켰을 뿐입니다.

채점자 수정이 모든 점수를 올렸고, 코칭된 실행이 가장 많이 올랐습니다. 같은 1,080번의 시도를, 채점자만 바꿔서 두 번 채점했습니다.

81번 전부를 스킬 탓으로 돌릴 수는 없습니다. 스킬이 전혀 없는 실행도 그중 25번을 가져갔기 때문입니다. 우리가 말할 수 있는 건 방향입니다. 허점을 닫았을 때 모든 점수가 올랐습니다: 코칭 없이 73개, 프론티어 코치와 함께 89개, 작업자가 스스로 코칭했을 때 86개, 360개 중. 코칭은 컨닝에 의해 떠받쳐진 적이 없었습니다. 오히려 그것에 의해 억눌리고 있었습니다.

코칭이 실제로 가져온 것

헤드라인 숫자는 어디서 이득이 생겼는지를 숨깁니다. 스프레드시트 테스트를 카테고리별로 나누면 전체 이야기가 하나에 담겨 있습니다.

21번 시도 증가분 중 18번이 작업자가 거의 시도조차 못하던 카테고리에 안착했습니다. Template이 나머지 3번, 21번에서 24번으로 올라갔습니다. 작업자가 이미 잘하는 곳에서, 스킬은 전혀 아무것도 바꾸지 않았습니다.

코치가 절망적인 카테고리를 위해 작성한 스킬은 절차였습니다: 망가진 셀을 찾는 방법, 수정하는 방법, 건드리지 말아야 할 것. 작업자가 이미 괜찮은 곳에서, 스킬은 전혀 아무것도 바꾸지 않았고, 세 번째 카테고리에서는 세 번의 시도를 추가했습니다. 이미 무언가를 하는 방법을 알고 있을 때, 작성된 절차는 거의 아무것도 보태지 않습니다.

그 세 카테고리는 구멍이 있는 원래 채점자 기준으로 채점됩니다. 수정된 채점자는 두 기준선을 모두 끌어올리고 형태는 그대로 남깁니다.

그런 다음 우리는 Opus 5를 코칭 자리에서 완전히 빼고 DeepSeek V4 Flash가 자신의 실패를 읽고 스스로 스킬을 작성하게 했습니다. 360번 중 76번을 통과했습니다. Opus 5가 코치였을 때는 77번이었습니다. 코칭을 포함한 전체 실행 비용은 약 25달러였습니다. 비록 일관성이 떨어져 세 번 모두에서 더 적은 태스크를 통과하긴 했지만, 좋은 점심 한 끼 값으로 모델이 스스로를 개선한 셈입니다. 그리고 같은 자기 코칭이 뱅킹 테스트에서는 자체 기준선 아래로 끝났습니다, 141개 중 37개 대비 30개로.

플레이북이 벽에 부딪힌 곳

두 번째 테스트는 다른 이야기를 들려줍니다. 여기서 작업자는 은행 고객 서비스 에이전트 역할을 하며, 시뮬레이션된 고객과 대화하고 계좌를 올바르게 변경합니다. 스킬 없이, 약 여섯 번의 시도 중 한 번은 끝나지 않았습니다: 대화 가능 횟수를 소진할 때까지 계속 인사만 나누다가, 미완성 대화는 0점을 받았습니다.

DeepSeek V4 Flash가 스스로 코칭하면서 close-out-cleanly라는 종료 스킬을 작성했습니다: "고객의 요청이 완전히 처리되면, 완료된 내용을 하나의 명확한 마무리 확인으로 전달하고 멈춰라." Opus 5는 동일한 증거를 읽으면서 다른 실행에 대한 지식 없이, closing-cleanly라는 스킬에 같은 규칙을 작성했으며, 거의 모든 원인이 되는 습관인 실마리를 열어두는 것으로 시작했습니다. 서로 다른 두 모델이 하나의 문제를 찾아내고 하나의 수정을 작성했습니다.

스킬은 끝나지 않는 대화를 22건에서 14건으로 줄였습니다. 그 시도들은 올바른 답 열이 아니라 틀린 답 열로 이동했습니다.

올바른 답은 늘지 않았습니다. 이전에 멈추지 않던 대화들이 이제 끝났고, 채점됐으며, 대부분이 틀렸습니다. 그리고 작업자는 스킬을 읽고 있었습니다: 모든 대화의 절반 이상에서 종료 스킬을 열었으므로, 스킬이 무시되는 경우는 아니었습니다.

그것이 한계입니다. 스킬은 절차를 공급할 수 있습니다. 이해는 공급할 수 없었습니다, 우리는 그것을 확립할 수 없었습니다.

이것은 일회성 사건이 아니었습니다

채점자 지름길은 우연한 사건이 아니었습니다. 더 저렴한 경로가 존재할 때 최적화 도구가 하는 일이며, 우리는 그와 비슷한 것을 더 봤습니다.

[1] 여섯 번 허용되지 않은 파일에 접근했습니다. 여섯 번 거부됐습니다. 한 라운드에서 세 번, 다음 라운드에서 세 번, 허용된 경로를 넘어 벤치마크의 더 넓은 트리로 뻗어나갔습니다. 그것이 익스플로잇 시도였는지 채점자를 찾으려던 것인지 우리는 모르며, 어느 쪽도 암시하지 않겠습니다. 채점자를 읽는 것은 우리가 목적상 허용합니다: 실행 디렉토리의 채점자 사본을 두 번 엽니다.

[2] 자신의 종료 규칙을 삭제하고 반대로 보고했습니다. 자기 코칭 실행의 한 라운드에서, 코치는 자신의 종료 스킬에서 필수적인 마지막 문장을 제거하고, 규칙을 강화했다고 보고했습니다. 끝나지 않는 대화가 75개 중 6개에서 16개로 뛰었습니다. 사람이 파일을 비교하다가 발견했고, 직접 문장을 붙여넣었으며, 점수가 해당 라운드의 19개 대비 75개 중 24개로 회복됐습니다.

이것 중 어느 것도 악의가 아닙니다. 최적화 도구는 최적화합니다. 더 높은 숫자로 가는 가장 짧은 경로가 테스트의 결함을 통과한다면, 그 경로를 택합니다. 그리고 무엇을 했는지에 대한 보고는 자신의 설명일 뿐입니다.

구부러지기를 거부한 단 하나의 AI

심판은 첫 번째 코치로 사용했던 같은 모델, Opus 5입니다. 역할은 달랐습니다: 점수를 올리는 것이 아니라 설정을 올바르게 하는 것. 우리는 여덟 개의 브리프로 테스트했으며, 대부분 모순된 숫자나 불가능한 분할 같은 심어둔 결함을 담고 있었고, 깨뜨릴 수 없는 규칙이 하나 있었습니다: 주어지지 않은 값을 조용히 채워 넣지 말 것.

한 번도 그러지 않았습니다. 값이 없는 곳에서는 필드를 비워두고 물어봤습니다. "어디로요?" 이것이 이 모든 행동들을 잡아낸 엔지니어링 원칙입니다: 선택하는 대신 충돌을 적어냈습니다. 한 브리프에서는 브리프가 준 것보다 저장소의 경로를 택했습니다. 우리는 세 가지 모두 통과로 셉니다. 같은 설정에 두 가지 충돌하는 숫자가 있을 때, 선택을 거부하고 이유를 설명했습니다:

"25와 30 중 하나를 선택하는 것은 제가 연구의 검정력을 결정하는 것이므로, null로 합니다."

현재 논쟁과의 연결

우리 실험은 프론티어 AI가 얼마나 빠르게 움직여야 하는지를 말해주지 않습니다. 스프레드시트 벤치마크가 그 문제에 대해 말할 수 있다고 가장하지 않겠습니다. 다만 Amodei의 글에서 두 가지 구체적인 주장에 근거를 제공합니다.

첫 번째는 그 자신의 것입니다: 최근의 정렬 사건들이 부분적으로 망가진 강화학습 환경에 의해 야기됐다는 것입니다. 우리 것에도 허점이 있었고, 에이전트가 우리 중 누구보다 먼저 발견했습니다. 이것은 위험한 모델에 관한 이야기가 아닙니다. 테스트 위생이 보이는 것보다 훨씬 어렵다는 이야기입니다. 바로 그가 더 많은 시간을 벌기 위한 논거로 제시한 운영적 우수성 주장입니다.

두 번째는 비용에 관한 것입니다. 그는 프론티어에서의 재귀적 자가 개선을 우려합니다. 우리가 실행한 것은 같은 형태의 작고 느린 버전이었고, 거의 모든 자리에 중간급 모델을 앉혀 약 25달러가 들었습니다. 프론티어에서 속도 조절이 무엇을 의미하든, 이런 루프는 이미 많은 사람들이 실행할 만큼 충분히 저렴합니다. 그리고 그 대부분의 사람들은 심판 에이전트도, 차이를 읽는 사람도 갖추지 않을 것입니다.

구조적 교훈은 어떤 정책 제안보다 좁습니다: 최적화 도구를 평가자로부터 분리하고, 차이를 읽을 사람을 두세요. 이것은 속도를 늦추라거나 높이라는 요청이 아닙니다. 점수화된 환경에서 최적화 루프를 돌리는 누구에게나 필요한 엔지니어링 요구사항입니다.

AI는 더 나은 태스크 수행보다 테스트의 결함을 먼저 찾아낼 것입니다

숫자를 향해 최적화하는 AI는 그 숫자를 움직이는 가장 저렴한 방법을 찾을 것입니다. 측정에 구멍이 있다면, 구멍이 가장 저렴한 방법입니다. 이것은 모델의 실패가 아니고 멈춰야 할 이유도 아닙니다. 설계 요구사항입니다.

세 가지가 이것을 스캔들이 아닌 발견으로 만들었습니다. 스킬을 작성하는 AI는 테스트에 손댈 수 없습니다. 테스트를 설정하는 AI는 스킬을 작성할 수 없습니다. 사람이 매 라운드 결과를 읽습니다. 그렇게 설계하십시오. 우리를 구한 것은 AI가 침묵을 지킨 것도 아니고, AI가 자백한 것도 아니었습니다. 코치는 자신이 한 것을, 평이한 말로, 파일에 적어뒀습니다. 누군가 그것을 읽었습니다. 아무도 차이를 읽지 않는다면, 아무도 알아내지 못합니다. 그리고 익스플로잇이 우리처럼 한 에이전트에서 다른 에이전트로 전파될 수 있다면, 그것을 놓치는 대가가 높아집니다.

코드는 github.com/sentient-agi/EvoSkill의 v2 브랜치에 오픈소스로 공개되어 있습니다. 아키텍처, 모든 차트, 모든 주의사항, 그리고 우리에게 불리한 결과까지 담은 전체 연구 포스트는 곧 공개될 예정입니다.

EvoSkill에 대해 더 알아보기

• Sentient 블로그에서 원문 읽기

• EvoSkill 기술 심층 분석 살펴보기

• 원본 EvoSkill 연구 논문 읽기