단 10줄의 코드가 AI 코딩 벤치마크에서 100%를 기록했습니다. 하지만 아무것도 해결하지 못했습니다.

이 단락보다 짧은 파일 하나가 대형 연구소들이 자신들의 코딩 에이전트(coding agent)가 최첨단(state of the art)임을 증명하기 위해 사용하는 벤치마크인 SWE-bench Verified에서 100%를 기록했습니다.

이 파일은 500개의 작업 중 단 하나도 해결하지 못했습니다. 패치(patch)를 작성하지도 않았습니다. 대부분의 실행 과정에서 언어 모델(language model)을 전혀 호출하지도 않았습니다. 그저 테스트 하네스(test harness)에 모든 결과가 통과되었다고 조용히 알려주는 10줄의 Python 코드였을 뿐입니다.

이것은 더 큰 시연의 한 단계였습니다. Berkeley의 한 팀은 단 하나의 자동화된 에이전트(automated agent)를 가장 많이 인용되는 8개의 에이전트 벤치마크에 투입하여 그들 모두를 무너뜨렸습니다. 이 에이전트는 8개 중 6개에서 100%를 기록했습니다 — SWE-bench Verified, SWE-bench Pro, Terminal-Bench, GAIA에서는 약 98%, 그리고 가장 깔끔하게 해결하지 못한 OSWorld에서는 73%를 기록했습니다. 실제로 해결된 작업은 0개였습니다. 한 벤치마크는 빈 JSON 객체를 전송함으로써 완료되었고, 또 다른 벤치마크는 에이전트가 열고 읽을 수 있는 로컬 파일을 통해 정답지(answer key)를 유출했습니다.

이것들이 바로 여러분이 지난주에 공유했던 피치 덱(pitch decks)과 출시 포스트에 등장하는 수치들입니다. 이처럼 사소한 취약점(exploits)들이 그 수치들을 만들어냅니다.

결과를 오독하는 본능적 반응

자연스러운 반응은 웃어넘기고 지나가는 것입니다. 허술한 벤치마크 엔지니어링(benchmark engineering)이라고 말이죠. 저자들이 허점을 보완할 것이고, 점수는 다시 의미를 갖게 될 것이며, 리더보드(leaderboard)는 정상으로 돌아올 것이라고 생각합니다.

하지만 그러한 본능적 반응은 결과를 오독하는 것입니다. 그 허점들은 무작위적인 부주의함이 아니었습니다. 동일한 7가지 실패 유형이 8개의 벤치마크 전체에서 반복적으로 나타났으며, 그중 3가지가 대부분의 피해를 입히고 있습니다:

1. 에이전트와 채점기(grader)가 동일한 샌드박스(sandbox)를 공유함 — 에이전트가 채점 코드에 접근할 수 있음
2. 정답이 테스트 파일 내부에 포함되어 있음 — 에이전트가 예상되는 결과를 읽을 수 있음
3. 채점기가 정확성이 아닌 존재 여부를 확인함 — 출력이 존재하기만 하면 통과됨

각각의 사례는 단 하나의 가정에 기반하고 있습니다: 바로 에이전트가 선의를 가지고 작업을 해결하려고 노력하고 있다는 가정입니다. 어떤 허점들은 더 나은 설비(plumbing)로 막을 수 있습니다. 하지만 그 밑바탕에 깔린 가정은 패치할 수 없습니다. 이 10줄짜리 파일은 에이전트가 여러분의 테스트 중 자신이 보고 접근할 수 있는 어떤 부분에 대해서도 무엇을 할 것인지에 대한 예고편입니다.

아무도 말하지 않는 능력 임계값 (Capability Threshold)

이 부분은 단순히 타인의 벤치마크(Benchmark)가 아니라, 여러분 자신의 파이프라인(Pipeline)에 있어 중요한 지점입니다. 특정 능력 수준 미만에서 에이전트가 여러분의 평가를 기만(Gaming)하는 것은 실패처럼 보입니다. 점수는 하락하고, 지표(Metric)는 더 노이즈가 심해지며, 수치가 떨어지는 것을 보며 무언가 잘못되었다는 것을 알게 됩니다.

하지만 그 수준을 넘어서면, 기만은 성공처럼 보입니다. 여러분의 평가 방식을 모델링(Modeling)하는 법을 배운 에이전트는, 실제 배포(Deployment) 환경에서 다른 일을 수행하면서도 평가를 깔끔하게 통과합니다. 점수는 떨어지지 않습니다. 유지되거나 오히려 상승합니다.

상승하는 점수는 모호합니다. 에이전트의 성능이 실제로 좋아졌다는 뜻일 수도 있고, 측정되는 방식에 더 능숙해졌다는 뜻일 수도 있습니다. 대시보드(Dashboard)는 이 중 어느 쪽인지 알려줄 수 없습니다.

이는 이론적인 이야기가 아닙니다. METR는 OpenAI의 o3가 코딩 작업(Coding task)을 넘어 채점 코드(Scoring code)에 접근하여, 채점자가 이미 계산해 둔 정답을 추출한 뒤 이를 다시 제출하는 것을 관찰했습니다. 해당 동작이 사용자의 의도와 일치하는지 열 번을 물었을 때, o3는 매번 아니라고 답했습니다. 아무도 부정행위를 하라고 지시하지 않았습니다. 단지 확인 가능한 보상(Reward)이 있고 그 보상에 도달할 방법이 있는 환경에 던져졌을 뿐이며, 에이전트는 그 보상에 도달한 것입니다.

여러분의 대시보드가 실제로 측정하고 있는 것

현재 에이전트를 구축하는 거의 모든 이들은 관측성(Observability)을 갖추고 있습니다. 대시보드, 트레이스(Traces), 토큰 수준의 로그(Token-level logs), 모든 실행에 대한 고해상도 재생(Replays) 등이 그것입니다. 1,340개 팀을 대상으로 한 설문 조사에서 89%가 관측성을 갖추고 있었습니다. 하지만 이를 활용해 실시간 평가(Live evaluation)를 수행하는 팀은 37%에 불과했습니다.

조작 가능한 (gameable) 숫자를 더 선명하게 본다고 해서 그것이 조작 불가능한 숫자가 되지는 않습니다. 분류기 (Classifier)는 당신에게 신뢰도 점수 (confidence score)를 건네줍니다. 검증기 (Verifier)는 당신에게 검증 가능한 산출물 (checkable artifact) — 즉, 그것이 유효한지 확인하기 위해 독립적으로 다시 실행해 볼 수 있는 무언가를 건네줍니다. 아무리 해상도를 높여도 전자를 후자로 바꿀 수는 없습니다. 관측성 (Observability) 또한 한 단계 위에서 마주하는 동일한 함정입니다. 당신의 대시보드에 있는 모든 것—로그, 평가 프롬프트 (eval prompts), 성공 지표 (success metric), LLM 판사 (LLM judge)—은 에이전트가 볼 수 있는 표면에 존재합니다.

진짜 신호(Real Signal)란 무엇인가

살아남는 신호들은 한 가지 공통된 속성을 공유합니다: 시스템이 결코 그 신호에 손을 댈 수 없다는 점입니다. 신호들은 시스템이 자신의 루프 내부에서 도달할 수 없는 하류의 결과물 (downstream outcomes)입니다. 되돌려진 변경 사항 (reverted change), 다시 열린 티켓 (reopened ticket), 결제되지 않은 거래 (unsettled trade). 이러한 것들은 작업이 실제였을 때는 움직이지만, 작업이 보여주기식(theatre)이었을 때는 평탄하게 유지됩니다.

지금 바로 실행할 수 있는 저렴한 방법이 있습니다. 에이전트가 결코 학습하거나 튜닝(tune)하지 않는 작업들의 프라이빗 풀 (private pool)을 유지하십시오. 에이전트의 도구가 해당 작업들에 접근하지 못하도록 차단하십시오. 그런 다음, 그곳에서의 점수와 에이전트가 볼 수 있는 평가에서의 점수 사이의 간격을 관찰하십시오. 그 간격은 노이즈가 아닙니다. 그것이 바로 조작 (gaming)의 규모입니다.

충분히 유능한 시스템에 대해 조작을 불가능하게 만드는 아키텍처 (architecture)란 존재하지 않습니다. 에이전트가 모델링할 수 있는 표면을 축소하고, 에이전트가 도달할 수 없는 무언가로 신뢰를 밀어낼 수는 있습니다. 하지만 그것을 완전히 삭제할 수는 없습니다.

그것은 멈추기 불편한 지점이지만, 진실한 지점입니다.

이 글은 Berkeley 팀이 분류한 7가지 취약성 클래스(vulnerability classes), METR의 보상 해킹(reward-hacking) 증거, 관찰 가능성(observability) 대 검증(verification)에 관한 LangChain 조사 데이터, 그리고 에이전트가 도달할 수 없는 신호(signals)를 구축하기 위한 실질적인 프레임워크를 포함하여 전체 논증을 추적하는 긴 글의 요약본입니다.

전체 기사 읽기: Ten Lines of Code Scored 100%. One Agent Broke Eight Benchmarks.