점수표 너머, 모델들의 습관이 보이기 시작했다
ICML 2026. ProgramBench trajectory 로그에서 발견한 모델별 습관 — 2부.
이 글은 ICML 2026에서 들은 발표를 발표자 1인칭 시점으로 재구성한 것입니다.
벤치마크를 만들고 나면 숫자만 보고 끝날 거라 생각했다. 몇 퍼센트를 풀었는지, 어떤 모델이 앞섰는지. 그런데 ProgramBench의 trajectory 로그를 하나씩 들여다보기 시작하면서 전혀 다른 종류의 재미를 발견했다. 같은 문제를 받아 들고도 모델마다 일하는 방식이 이렇게까지 다를 수 있다는 걸, 로그를 행동 유형별로 색칠해보고 나서야 실감했다.
관찰하는 모델과, 일단 쓰고 보는 모델
에이전트의 매 턴을 읽기(reading), 쓰기(writing), 찔러보기(probing) 세 가지 행동 타입으로 나눠 색깔로 시각화해봤다. 그랬더니 모델별로 뚜렷한 성향이 드러났다. GPT 계열 모델들은 초반 몇 턴 동안 문서를 읽고 프로그램을 probe하는 데 시간을 쓴 다음, 어느 순간 스위치를 켠 듯이 곧장 구현으로 넘어가서 그대로 끝까지 밀어붙였다. 반면 Sonnet은, 그리고 Opus도 어느 정도는, probing과 writing을 계속 섞어가며 진행할 때 결과가 더 좋았다. 한 번 찔러보고 조금 짜고, 다시 찔러보고 또 조금 짜는 식으로 관찰과 구현을 촘촘하게 반복하는 리듬이었다.
이 차이는 코드베이스가 시간에 따라 얼마나 커지는지를 봐도 그대로 드러났다. Opus 4.6과 Gemini 3.1 Pro는 구현량을 턴마다 꾸준히 쌓아 올리는 반면, GPT-5.4는 한 턴에 최대한 많은 코드를 한꺼번에 뽑아내려는 경향을 보였다. 결국 ProgramBench가 알려준 건 “누가 더 잘 풀었나”라는 단일한 축만이 아니었다. 코드베이스를 처음부터 쌓아 올리게 만드는 이 구조는, 모델이 문제를 대하는 방식에 대한 행동 신호(behavioral signal)까지 함께 드러내고 있었다.
언어를 억지로 바꿨더니, 오히려 점수가 올랐다
여기서부터는 조금 더 반직관적인 결과들이다. 정답 코드베이스와 다른 언어로 구현하도록 강제했을 때 점수가 일괄적으로 떨어질 거라 예상했다. 그런데 실제로는 그렇지 않았다. 오히려 GPT 계열 모델들은 점수가 올라갔다. 이건 모델들이 어떤 문제에 어떤 언어가 가장 적합한지를 스스로 신뢰할 만큼 파악하고 있지 않다는 뜻으로 읽힌다. 익숙한 선택지를 강제로 빼앗고 다른 언어를 쓰게 만드는 쪽이 오히려 벤치마크 성능을 끌어올리기도 한다는, 다소 의외의 결론이었다.
또 하나 눈여겨볼 결과는 인터넷 접근 여부였다. 인터넷이 켜진 상태로 벤치마크를 돌려보니, 모델들이 답을 찾기 위해 할 수 있는 모든 방법을 동원해 인터넷에서 결과를 검색해오는, 치팅에 가까운 행동이 두드러지게 나타났다. 그래서 처음부터 인터넷 접근을 차단하는 쪽으로 벤치마크를 설계했고, 여기에 더해 LLM을 심판으로 세운 치팅 탐지 로직까지 추가로 마련해 뒀다.
12시간 만에 시작된 반응
벤치마크를 공개하고 나서 가장 먼저 놀란 건 반응 속도였다. 공개한 지 채 12시간도 지나지 않아 누군가 이미 ProgramBench로 여러 코딩 하네스(harness)를 비교한 결과를 트위터에 올려놓았다. 그 뒤로 여러 모델 카드에도 ProgramBench가 인용되기 시작했다. Opus 4.8 모델 카드에서는 싱글 에이전트 모델들의 능력 차이를 보여주는 지표로 쓰였고, 같은 4.8 모델 카드에서 Anthropic이 멀티 에이전트 세팅의 토큰 효율 개선을 보여줄 때도 ProgramBench의 초기 신호가 쓰였다. 처음부터 코드베이스를 다시 짓는 능력을 재려던 벤치마크가, 어느새 싱글 에이전트를 넘어 멀티 에이전트 설계까지 들여다보는 창이 된 셈이다.
최근에는 리더보드도 열어 외부 제출을 받기 시작했다. 어떤 팀이 어떤 방식으로 이 문제를 풀어올지, 어떤 에이전트 설계가 튀어나올지 궁금해하며 지켜보고 있다. 벤치마크 하나를 만들었을 뿐인데, 그 안에서 모델들이 저마다 다르게 일하는 방식을 들여다보는 일이 이렇게 흥미로울 줄은 몰랐다.