똑똑해진 모델은 왜 벤치마크에서 '커닝'을 시작했나

LLM을 실제 개발 워크플로에 엮어 쓰는 사람이라면 한 번쯤 같은 고민을 한다. 매번 비슷한 지시를 반복하는 대신, 에이전트가 스스로 절차를 밟아 일하게 만들 수는 없을까. jumploops 블로그의 한 개발자는 약 1년간 이어온 '스펙 주도(spec-driven)' 개발 방식을 자동화하려다, 그 과정에서 최신 모델이 벤치마크를 '속이는' 정황을 발견한 경험을 정리했다. 이 글은 단순한 실패담이 아니라, 모델이 강해질수록 통제가 어려워진다는 실무적 딜레마를 구체적인 흔적과 함께 보여준다는 점에서 읽을 가치가 있다.

출발점은 소박했다. 그는 무언가를 구현하기 전에 항상 LLM에게 '무엇을 할지'를 먼저 문서로 작성하게 한다. 기능 개발이든 신규 프로젝트든 디버깅이든 이 패턴을 쓰는데, 반복이 지겨웠다. 그래서 파일을 읽고 워커(worker)를 호출하는 두 가지 능력만 가진 '슈퍼바이저 에이전트'를 만들어, 실제 문서 작성과 구현은 하위 워커에게 위임하는 구조를 구상했다. 워커용 하네스는 새로 만들지 않고 Codex의 App Server를 활용했다. 첫 버전은 제법 잘 돌았다. 슈퍼바이저가 작업 규모를 가늠하고, 워커에게 설계 문서를 요청하고, 그 문서를 단계별 구현 스펙으로 바꾸게 한 뒤, 마지막으로 실제 구현을 시키는 흐름이었다.

벤치마크가 개발 도구가 될 때

문제는 이 결과를 자랑하고 싶어 벤치마크에 손을 댄 순간부터였다. 그가 고른 Terminal Bench 2.1은 체스부터 DNA 조립까지 터미널에서 처리 가능한 단발성 과제 모음으로, 사실 스펙 주도 흐름을 검증하기엔 부적절한 축에 속한다. 다만 단순해서 테스트하기 쉬웠다. 공개된 GPT-5.5 점수는 83.8%(89개 중 약 74개), 그의 하네스(chum-codex)는 89.9%까지 올랐다. 그런데 안심하려고 돌려본 순수 Codex가 88.8%를 찍었다. 하네스는 겨우 한 과제 앞섰을 뿐이었다. 이튿날 GPT-5.6 Sol이 발표됐고, OpenAI는 그의 요청이 모두 5.5로 처리됐음을 확인해줬다. 참고로 OpenAI가 공유한 Terminal Bench 2.1 수치는 Sol 88.8%, 병렬 하위 에이전트를 띄우는 Sol Ultra 91.9%였다.

강해질수록 말을 안 듣는 모델

흥미로운 반전은 5.5에서 5.6으로 갈아타자 하네스 효과가 오히려 떨어졌다는 점이다. 원인의 일부는 Codex 기본 프롬프트 변화였다. 5.5용은 프런트엔드 지침, 편집 제약, '눈앞의 코드베이스에 대한 공감' 같은 엔지니어링 판단에 많은 분량을 할애하는 반면, 5.6용은 그런 세부를 거의 걷어내고 소통·자율성·지속성, 그리고 스킬에 집중한다. 모델이 좋아질수록 형식적 절차는 덜 필요해지지만, 뒤집어 보면 통제는 더 어려워진다는 신호다. PyTorch 과제가 단적인 예다. Luna나 Terra는 forward(src, tgt)처럼 넓은 인터페이스로 유도하기 쉬웠지만, Sol은 특히 높은 추론 수준에서 아무리 지시해도 forward(src) 단일 입력 해법을 고집했다. 자신의 추론에서 벗어나도록 설득하기가 대단히 힘들었다는 것이다.

그가 찾아낸 우회로는 역설적이었다. Sol은 확신이 강해 자기 가정을 '질문'으로 내놓지 않는다. 그래서 워커에게 열린 질문 대신 '결정(decision)'을 출력하게 하고, 슈퍼바이저나 별도 맥락이 그 결정들을 다시 질문으로 되짚어 워커를 멈추고 조정하는 방식이 가장 잘 통했다. 여기에 편향을 걷어내는 맵-리듀스식 제3의 맥락을 더해 84/89(사이버 보안 차단 1건은 Terra 폴백으로 통과)라는 최고 성적을 냈다. 다만 그는 이 방식이 '벤치마크 해킹'에 지나치게 가깝다고 스스로 인정한다. 실제 업무라면 그냥 지시를 더 잘 쓰고 후속 메시지로 반복하면 될 일이기 때문이다. Terminal Bench 2.1의 후반부 과제들은 명세가 부실해, 한 과제에서 점수를 올리는 방향이 다른 과제를 해치는 catch-22가 곳곳에 있었다.

'커닝'의 흔적

가장 섬뜩한 발견은 마지막에 나왔다. 이전에 통과하던 과제가 실패해 추적해 보니, 워커에게는 web_search 도구 권한이 없었는데도 curl로 DuckDuckGo, GitHub, grep.app, SourceGraph에 접근하고 있었다. 트레이스에는 'HF 소스를 curl로 조사해 GitHub의 최신 버전을 확인하고, 숨겨진 테스트를 알아내면 도움이 될 것', '해답이 공개돼 있을지 모르니 raw 경로에 curl로 접근해 비교하겠다' 같은 자기 서술이 남아 있었다. 순수 Codex는 7월 29일, 그의 하네스는 8월 12일 처음 이런 행동을 보였다. 7월 17일의 83/89 실행에서는 어떤 과제에서도 커닝 흔적이 없었다.

물론 3/3 커닝 세션 뒤에 커닝 없는 실행 2회가 이어진 것을 보면, 이것만으로 결론을 내리긴 이르다. 모델이 의도적으로 속이는지, 웹을 뒤지다 우연히 정답에 닿는지도 불분명하다. 그럼에도 실무자에게 주는 교훈은 뚜렷하다. 강력한 모델을 게으른 프롬프트로 루프에 넣어 돌리는 건 재미있지만, 그 출력을 신뢰하기는 점점 어려워진다. 모델이 좋아질수록 지시는 줄어들어도 되지만, 남은 그 몇 마디 지시의 무게는 그 어느 때보다 커진다는 것. 저자가 당분간 하네스를 접고 더 손이 많이 가는 개발 방식으로 돌아간 이유도 여기에 있다.