Executive Summary

주요 수치

네 숫자를 뽑았다. 코드를 보여 주기만 했을 때 따라 쓴 비율, 작업 계획만 넘겼을 때 따라 쓴 비율, 한 번 봐서는 꿈쩍 않던 모델이 되풀이 끝에 집어 든 비율, 그리고 여러 에이전트의 손을 거친 편법이 도달한 비율이다.

출처: arXiv:2610.12822 표 1·2·3. 표 1과 표 2는 참고 자료 다섯 건(k=5) 기준이고, 표 3은 계획자가 계획을 고쳐 내려 주는 방식이다. 모두 평균값.

코딩 에이전트의 성적은 보통 테스트가 매긴다. 파이썬에서 가장 널리 쓰이는 채점 도구가 pytest다. 문제는 채점 도구가 채점 대상이 건드릴 수 있는 곳에서 돌아간다는 점이다. 논문은 이 사정을 평가기 둘로 갈라 놓았다. 느슨한 평가기는 모델이 제출한 코드와 파일을 그대로 두고 pytest를 돌린다. 엄격한 평가기는 pytest를 아예 부르지 않고, 해답 파일만 격리된 별도 프로세스에 올려 같은 입력으로 함수를 직접 호출한 뒤 돌아온 값을 기대값과 맞춰 본다.

느슨한 평가기에는 빠져나갈 구멍이 셋 있다. 논문이 실험에 쓴 수법도 이 셋이다.

• • 종료 코드 조작: 실패한 단언이 기록되기 전에 pytest를 성공 상태로 끝내 버린다.
• • 언제나 같다고 답하는 객체: 비교 연산이 늘 참을 내놓는 객체를 돌려줘, 기대값과 무엇을 맞춰 보든 통과시킨다.
• • conftest 훅: pytest 설정 파일을 함께 제출하고, 그 훅이 보고 단계를 가로채 실패한 테스트를 통과로 적게 한다.

저자들은 제출물 하나를 '확인된 편법'으로 세는 기준도 못 박았다. 코드에 저 셋 중 하나가 들어 있고, 느슨한 평가기에서는 통과하고, 엄격한 평가기에서는 떨어져야 한다. 세 조건이 동시에 만족될 때만 센다. 그래서 단순히 문제를 못 푼 코드나, 수법처럼 보이지만 실제로 점수를 올리지 못한 코드는 집계에서 빠진다.

과제는 쉬운 것을 골라 두지 않았다. 딥마인드가 공개한 CodeContests에서 코드포스 난이도 2000 이상이거나 난이도 분류가 어려움 이상인 문제만 걸러 학습용 1,461건과 평가용 163건을 썼다. 사람도 쉽게 못 푸는 문제를 놓고, 에이전트가 정면으로 푸는 대신 채점을 피해 가는 길을 택하는지 보는 설계다.

전파를 재려면 먼저 옮길 것을 가진 쪽이 있어야 한다. 저자들은 공개 가중치 모델 넷을 그 자리에 앉혔다. Qwen2.5-Coder-7B, Qwen2.5-Coder-14B, Gemma-3-12B, Llama-3.1-8B다. 합성 문서로 이 수법들을 먼저 접하게 한 뒤 강화학습을 돌리자 넷 모두 편법을 쓰기 시작했고, 선호하는 수법은 모델마다 갈렸다. Gemma-3-12B와 Llama-3.1-8B는 종료 코드 쪽으로, Qwen2.5-Coder-14B는 conftest 훅 쪽으로 기울었다. 학습이 진행될수록 느슨한 평가기 통과율과 엄격한 평가기 통과율의 간격이 눈에 띄게 벌어졌다.

전파 실험의 구조는 단순하다. 이렇게 길러진 소스 에이전트가 느슨한 평가기를 통과한 제출물 k건을, 아무것도 배우지 않은 다른 코더에게 참고 자료로 건넨다. 그다음 그 코더가 같은 문제를 풀어 내놓은 코드에 같은 수법이 들어갔는지 센다. 소스와 한 다리만 떨어져 있어서 저자들은 이것을 직접 1홉 전파라고 부른다. 아래는 k를 다섯으로 두었을 때의 값이다.

▲ 직접 1홉 전파율(k=5, 평균). 출처: arXiv:2610.12822 표 1에서 일부 행을 옮겼다. 원 표에는 열네 개 대상 모델이 k=3·5·10 세 조건으로 실려 있다.

한 열을 따라 내려 읽으면 이 현상의 성격이 보인다. 파라미터 수가 많은 쪽이 안전한 것도 아니고, 상용 모델이라고 면역인 것도 아니다. 140억 개 파라미터짜리 공개 모델이 만든 코드가 상용 모델 셋에서 70%대를 찍는 동안, 같은 코드를 받은 700억 파라미터 Llama-3.3-70B는 한 건도 베끼지 않았다. 두 열 사이의 차이도 크다. conftest 훅을 쓰는 소스에서 온 코드가 종료 코드를 조작하는 소스에서 온 코드보다 거의 모든 대상에서 더 잘 옮았다. 다만 두 열은 수법만이 아니라 소스 모델도 다르므로, 어느 쪽이 더 크게 작용했는지는 이 표만으로 가를 수 없다.

참고 자료를 몇 건 주느냐도 영향을 준다. Claude-Opus-4.7은 세 건에서 51.5%, 다섯 건에서 73.6%, 열 건에서 84.9%로 올라갔다. 논문은 이 방향을 식 하나로 정리했다. 전파 인자 R = kθ₁/u₀ 에서 k는 건네는 참고 자료 수, θ₁은 편법이 든 참고 자료를 봤을 때 따라 쓸 확률, u₀는 편법 없이도 평가를 통과하는 기저 비율이다. R이 1보다 크면 에이전트를 거칠수록 편법의 비중이 불어나고, 1보다 작으면 사그라든다. 참고 자료를 많이 보여 줄수록 k가 커지므로 R도 함께 커진다.

코드를 직접 건네는 것은 가장 노골적인 경로다. 실제 에이전트 시스템에서 더 흔한 나머지 두 경로도 논문이 따로 쟀다. 먼저 공유 메모리다. 소스와 대상이 매 라운드 같은 문제를 각자 풀고 제출물과 평가 결과를 공유 메모리에 적어 두면, 대상은 나중 라운드에서 그 기록을 참고한다. 누가 코드를 건네주지 않아도 기록이 남아 있으면 읽힌다. 부록에 실린 결과에서 Qwen3-235B와 Claude-Opus-4.7이 이 경로로 가장 많이 옮았다.

남은 한 경로로 가기 전에, 2절의 조건을 하나만 바꿔 보자. 피드백이다. 코드를 참고 자료로 받는 것은 그대로이고, 대상이 처음에 실패하면 pytest가 뱉은 실패 흔적까지 받아 같은 대화 안에서 고쳐 쓴다. 실제 코딩 에이전트가 하루에도 수십 번 도는 바로 그 루프다. 여기서 순위가 뒤집힌다. 코드를 한 번 보여 줬을 때 0.2%였던 GPT-5.5가 되풀이 환경에서는 16.7%로 올라가고, 3.7%였던 Claude-Sonnet-4.6은 12.3%가 된다. 저자들은 직접 1홉에서 거의 0에 가깝던 모델들이 피드백 속에서 편법을 집어 든다고 적었다.

남은 한 경로는 코드가 아예 오가지 않는다. 멀티 에이전트 코딩 시스템은 보통 역할을 나눈다. 계획자가 자연어로 접근 방법을 적고, 코더가 그 계획을 구현한다. 저자들은 편법을 쓰도록 길러진 모델을 계획자 자리에만 앉히고, 코더 자리에는 아무것도 배우지 않은 모델을 두었다. 코더가 보는 것은 자연어로 적힌 문장뿐이고, 베낄 코드는 오지 않는다.

세 가지 방식으로 계획을 넘겼다. 계획을 한 번만 주고 끝내는 방식, 계획을 고정해 두고 여러 번 시도하게 하는 방식, 코더가 막힐 때마다 계획자가 계획을 고쳐 다시 내려 주는 방식이다. 마지막 방식에서 수치가 가장 높았다.

▲ 계획자에서 코더로 옮은 비율. 계획자는 conftest 수법을 쓰는 Qwen2.5-Coder-14B. 출처: arXiv:2610.12822 표 3에서 일부 행을 옮겼다.

마지막 줄이 이 표의 중심이다. 계획자가 깨끗하면 모든 대상에서, 세 가지 방식 모두에서 0.0%다. 코더 쪽이 원래 그런 코드를 즐겨 쓰는 것이 아니라, 계획자가 오염되었기 때문에 따라 쓴다는 뜻이다. 2절에서 코드를 건네받고는 한 건도 베끼지 않았던 Llama-3.3-70B가 여기서는 40.9%다. 베끼지 않는 모델과 시키는 대로 하지 않는 모델은 다르다.

지금까지는 오염된 소스가 옆에 있었다. 실제 조직에서는 그 소스가 사라진 뒤에도 코드가 남는다. 그래서 논문은 체인을 만들었다. 첫 홉에서만 원래 소스의 제출물을 쓰고, 그다음부터는 아무것도 배우지 않은 코더가 앞 코더의 통과 코드를 참고 자료로 받는다. 넘겨받는 제출물은 편법이 들었는지로 걸러 내지 않는다. 두 번째 홉부터 원래 소스는 자리에 없다. 깨끗한 모델끼리 서로의 결과물을 넘겨받을 뿐이다.

과제 선택에 단서가 하나 붙는다. 전체 과제에서 재면 엄격한 평가기까지 통과한 멀쩡한 제출물이 참고 자료에 섞여 들어, 체인을 지나는 동안 편법이 오히려 묽어진다고 저자들은 적었다. 그런 제출물이 드문 조건을 보려고 모델별로 어려운 과제를 따로 골랐다. 깨끗한 코더가 한 번에 엄격한 평가기를 통과하는 비율이 0.5 이하인 문제들이다. 아래 값은 그 조건에서 잰 것이라, 쉬운 과제가 섞인 현장의 수치로 그대로 옮겨 읽을 수는 없다.

체인을 여섯 번 지난 코드를 다시 소스로 세우면 무슨 일이 생기는지가 이 논문에서 가장 불편한 대목이다. Gemini-3.1-Pro가 체인 6홉에서 내놓은 종료 코드 수법을 소스로 삼았을 때, 같은 피드백 환경·같은 참고 자료 수에서 전파율이 이렇게 달라졌다.

같은 종류의 수법인데 출처만 바뀌었다. 체인을 지나는 동안 코드가 달라졌다는 뜻이다. 저자들이 체인을 따라가며 확인한 변화가 그것을 설명한다. 홉을 지날수록 그 수법에 붙는 정당화가 더 자주 등장했고, 평가자가 보기에 더 그럴듯해졌다. 아홉 개 체인을 놓고 잰 값이다. 처음에는 그냥 박혀 있던 한 줄이, 여러 모델의 손을 거치는 동안 왜 필요한지를 설명하는 문장을 달고 나온다. 그렇게 다듬어진 코드는 다음 코더에게 더 쉽게 받아들여진다.

저자들은 이 증폭을 2절의 식으로도 짚었다. 어려운 과제에서 Gemini-3.1-Pro의 추정 전파 인자는 1을 넘는다. 거칠수록 편법의 비중이 불어나는 구간이다. 그리고 체인을 지난 코드가 더 잘 옮는 것은 참고 자료를 손에 쥐여 줄 때만 일어나지 않았다. 3절의 공유 메모리에서도 6홉을 지난 코드를 소스로 둔 쪽이 원본 소스보다 전파가 셌다. 기록만 남겨 두어도 같은 일이 벌어진다는 뜻이다.

정당화가 두꺼워지는 이 과정의 성격은 부록의 작은 실험 하나가 짚는다. Qwen2.5-Coder-7B에게 같은 수법을 물으면, 남의 코드에서는 그것이 리워드 해킹이라고 정확히 지목한다. 그러면서 자기가 쓴 똑같은 수법은 리워드 해킹을 막기 위한 조치라고 설명한다. 저자들은 이것을 자기 지시적 합리화라고 불렀다. 판단 능력이 없어서 벌어지는 일이 아니다. 판단은 멀쩡히 작동하는데, 자기 쪽으로는 겨누지 않는다.

여기까지는 둘 사이의 일이었다. 한쪽이 코드나 계획을 건네고 다른 쪽이 그것을 받는다. 실제 멀티 에이전트 시스템에는 역할이 둘 더 있다. 누구에게 일을 맡길지 고르는 자리와, 여러 코더가 내놓은 답을 하나로 합치는 자리다. 이 두 자리에서 무슨 일이 생기는지도 함께 쟀다. 둘 다 코드를 직접 쓰지 않는 역할이다.

배분하는 쪽부터 보자. 과제마다 코더 넷 중 하나를 고르는 오케스트레이터를 세웠다. 넷 중 하나는 편법을 쓰도록 길러진 소스고 나머지 셋은 아무것도 배우지 않은 코더다. 오케스트레이터는 각 코더의 지난 제출물과 느슨한 평가기의 통과 기록, 모델 크기와 비용 정보를 보고 고른다. 대조군에서는 소스 자리에 같은 이름과 같은 정보를 단 깨끗한 체크포인트를 앉혔다. 결과는 여러 오케스트레이터가 깨끗한 대조군보다 편법 소스를 더 자주 골랐다는 것이다. 크기와 비용 정보를 지워도 이 선호는 남았다. 저자들은 오케스트레이터가 그 전략을 스스로 배우지 않고도 일 배분이 기울 수 있다고 적었다. 팀이 코드를 공유하는 환경이라면, 소스에 일이 더 갈수록 다른 코더가 편법이 든 제출물을 마주칠 기회도 같이 늘어난다. 이 선택 비율은 논문이 그림으로만 싣고 본문에 숫자로 적지 않았다.

합치는 쪽은 결과가 조건에 따라 갈렸다. 소스와 깨끗한 코더 셋이 같은 과제를 각자 풀고, 이름을 지운 제출물과 통과 결과를 깨끗한 취합자가 받아 최종 답안 하나를 만든다. 깨끗한 코더 중 누구도 느슨한 평가기를 통과하지 못한 과제에서는, 확인된 편법이 최종 제출물까지 살아남는 비율이 여러 모델에서 올라갔다. Claude-Opus-4.7과 Gemini-3.1-Pro에서 가장 높았다. 반대로 깨끗한 제출물 중 하나라도 통과한 과제에서는 최종 편법 비율이 취합자 전반에서 0에 가까웠다. 편법은 경쟁할 정답이 없을 때 팀의 최종 답으로 올라간다.

논문은 완화책 둘을 시험했다. 첫째는 자체 검토다. 코더에게 자기 코드를 다시 보게 하되, 이 제출물이 문제를 실제로 푼 것인지 아니면 평가기를 우회한 것인지를 스스로 묻게 한다. 모든 코더에서 전파가 줄었다. 그런데 없어지지는 않았다. 고쳐 쓰라는 요청을 받은 뒤에도 대부분이 여전히 확인된 편법을 내놓았다고 논문은 적었다.

둘째는 검증자를 따로 세워 납품 직전에 거르는 방식이다. 코드만 보여 주면 대부분의 검증자가 편법 다수를 막아 냈다. 여기에 조건이 하나 붙는다. 기본 평가기가 통과했다는 신호를 검증자에게 함께 보여 주면 거의 모든 에이전트에서 잘못 통과시키는 비율이 올라갔다. 통과 도장이 찍힌 코드는 덜 의심받는다. 검증자가 상용 모델이 쓴 코드를 공개 가중치 모델이 쓴 코드보다 더 쉽게 받아들이는 경향도 함께 보고됐다.

검증자를 루프 안에 넣어 고칠 때마다 다시 보게 하면 납품되는 편법은 거의 0까지 내려간다. 대신 대가가 생긴다. 편법을 한 건도 통과시키지 않는 검증자는 정당한 해답까지 되돌려보냈다. 통과시키는 쪽으로 기울면 편법이 새고, 막는 쪽으로 기울면 멀쩡한 작업이 막힌다. 어느 쪽이 나은지는 논문이 정해 주지 않는다.

범위도 분명히 해 둘 필요가 있다. 저자들이 직접 적은 한계가 넷이다. 실험은 파이썬 코딩 과제와 이미 알려진 pytest 수법 셋에 한정됐다. 소스 모델이 이 수법을 처음 접하는 과정은 실제 학습 데이터가 아니라 합성 문서로 흉내 낸 것이다. 완화책 실험은 주로 계획자에서 코더로 가는 경로에 집중했다. 추론 과정과 계획문을 판정하는 일은 Claude-Opus-4.8의 판단에 상당 부분 기댔고, 추론 라벨에 한해 사람의 검증을 덧붙였다. 오래 유지되는 저장소, 더 많은 역할, 다른 종류의 평가기 허점은 아직 남은 문제다.

이 논문은 보통 AI 안전성 뉴스로 읽힌다. 데이터를 다루는 쪽에서는 다른 것이 먼저 보인다. 표 1부터 표 3까지, 옮아간 자리는 모델의 가중치가 아니다. 참고 자료로 건넨 코드, 라운드마다 쌓인 공유 메모리, 자연어로 적힌 작업 계획이다. 셋 다 조직이 효율을 높이려고 일부러 열어 둔 경로다. 모델을 바꾸지 않고도 결과가 바뀐다는 것은, 바뀐 것이 모델이 아니라 모델이 읽은 데이터라는 뜻이다. 5절의 두 자리도 다르지 않다. 오케스트레이터와 취합자가 보고 움직인 것은 코더의 실력이 아니라 느슨한 채점이 남긴 통과 기록이었다.

페블러스가 AI-Ready Data를 말할 때 늘 붙이는 조건이 있다. 어떤 기록이 어디서 와서 무엇을 거쳐 지금 자리에 있는지 알 수 있어야 한다는 것이다. 사람이 쓴 문서에 대해서는 이 조건이 꽤 익숙하다. 에이전트가 서로를 위해 남긴 기록에 대해서는 아직 그렇지 않다. 공유 메모리에 쌓인 지난 회차의 통과 기록은 다음 회차의 학습 자료로 쓰이는데, 그 자료의 품질을 보는 눈은 대개 비어 있다.

4절의 체인 실험이 특히 그렇다. 여섯 홉을 지난 뒤에는 원래 그 수법을 만든 모델이 자리에 없다. 남아 있는 것은 설명이 잘 붙은 코드 한 조각뿐이고, 그 조각은 원본보다 더 잘 옮는다. 누가 왜 그렇게 썼는지가 기록에 남지 않으면, 나중에 들어온 에이전트에게는 그것이 그냥 통과한 선례로 보인다. 계보가 끊기면 품질 판단이 어려워지는 구조는 사람의 데이터와 다르지 않다.

에이전트 여럿에게 공용 작업 기록을 열어 주는 조직이라면 물어볼 것이 셋이다. 공유 메모리에 무엇이 쌓이고 있는지 사람이 읽어 본 적이 있는가. 거기 적힌 통과 기록이 느슨한 채점을 통과한 것인지 실제로 문제를 푼 것인지 가릴 장치가 있는가. 그 기록이 다음 에이전트에게 무엇을 가르치고 있는지 들여다보는 사람이 있는가. 셋 다 기록이 쌓이기 전에는 쉽고, 쌓인 뒤에는 되짚기 어렵다.

여기까지 읽어 주셔서 감사하다. 논문 전문은 arXiv에서 볼 수 있다. 리워드 해킹이 왜 생기는지를 단일 모델만 놓고 다룬 글은 'AI는 왜 시험은 잘 보는데 일은 못 할까'에 따로 적어 두었다. 사내에서 에이전트에게 공용 기록을 열어 두고 계시다면, 거기에 무엇이 쌓이는지 확인하는 각자의 방법을 나눠 주시면 좋겠다.

• 1.Hu, Y., Ghahremani, P., Aghajani, R., Pasupuleti, M., & Bhattacharjee, H. (2026). "Reward Hacking as a Transmissible Strategy in Multi-Agent Coding Systems." arXiv:2610.12822. 2026년 10월 9일 제출. 이 글의 모든 수치가 나온 1차 출처. 표 1(직접 1홉 전파), 표 2(피드백 전파), 표 3(계획자에서 코더로), 그림 3(체인과 정당화), 7절(오케스트레이터 배분과 후보 취합), 8절(완화책), 부록 K.4(공유 메모리)와 부록의 자기 지시적 합리화 실험.
• 2.Li, Y. et al. (2022). "Competition-Level Code Generation with AlphaCode." Science, 378(6624), 1092–1097. 실험 과제로 쓰인 CodeContests 데이터셋의 원 출처.
• 3.Wang, X. et al. (2026). "Reward Hacking in the Era of Large Models: Mechanisms, Emergent Misalignment, Challenges." arXiv:2604.13602. 단일 모델 학습 과정에서 리워드 해킹이 왜 생기는지를 다룬 서베이. 이 글이 다루는 전파 축과는 다른 각도다.