벌너포칼립스(vulnpocalypse)에 대한 이야기가 최근 많이 오갔는데, 나는 보안 쪽 사람은 아니라 딱히 덧붙일 말이 없다. 하지만 그와 밀접하게 관련된 — 솔직히 말하면 덜 심각한 — 문제인 벤치마크포칼립스(benchmarkpocalypse)에 대해서는 논의가 거의 없는 것 같아 글을 쓴다.

진짜 성능을 크게 끌어올리는 일이 그 어느 때보다 쉬워진 시대이지만, 벤치마크를 보상 해킹(reward hack)해서 가짜 성능 향상을 만들어내는 일 역시 그 어느 때보다 쉬워졌다. 전자는 여러 기업에서 조용히 일어나고 있을 테지만, 후자는 요즘 일주일에 한 번은 꼭 마주친다. 누군가 X를 최적화해 기존 소프트웨어 대비 엄청난 성능 향상을 달성했다고 주장하는데, 뜯어보면 벤치마크 점수만 올리고 실제 환경의 성능은 전혀 개선하지 않은 최적화를 해놓은 경우가 많다. 이는 흔히 “X를 Rust로 다시 썼습니다”¹류의 프로젝트나 투자 유치나 판매를 노리는 신생 스타트업에서 나타나곤 하지만, 다른 종류의 프로젝트에서도 마찬가지다.

물론 사람들은 예전부터 자신의 애정 프로젝트가 대단해 보이도록 대표성 없는 마이크로벤치마크를 요란하게 내세워 왔다. 대표성 없는 마이크로벤치마크를 조작하는 건 언제나 쉬웠고 앞으로도 그럴 것이다. 달라진 점은 예전에는 대규모 벤치마크 스위트를 공략하려면 엄청난 노력이 필요했지만, 이제는 LLM과 루프만 있으면 된다는 것이다. 이게 어려웠던 시절에도 대규모 벤치마크 스위트를 교묘하게 공략한 유명한 사례는 꽤 있다. 예를 들어 사람들이 워크스테이션 성능의 대리 지표로 SPECint / SPECfp를 중요하게 여기던 시절, CPU 벤더들은 벤치마크 안의 계산을 가속하는 컴파일러 “최적화”를 찾으려 혈안이었다. Sun이 SPECfp2000의 179.art를 SPECfp2000에서 12배나 빠르게 만든 것이 대표적이다. 숙련된 엔지니어들이 그런 벤치마크 해킹을 찾기 위해 많은 시간을 쏟았다. LLM은 이를 trivial하게 만들 뿐 아니라 기본값처럼 해버리니, 결과를 직접 감사하거나 감사한 사람을 신뢰하지 않는 한 예전에는 믿을 만했던 벤치마크조차 무의미해졌다.

남의 잘못된 주장을 굳이 지적하는 대신, 내가 에이전트에게 시켜 만든 정규식 엔진인 에이전트에게 시켜 만든 정규식 엔진인 FRE를 예로 들어보겠다. 이 엔진은 상당히 포괄적인 rebar 정규식 벤치마크 스위트에서 Rust regex 크레이트를 이기므로, 마음만 먹으면 세계에서 가장 빠른 정규식 엔진이라고 주장할 수도 있다. 하지만 이건 에이전트를 한 달 동안 루프에 넣어 벤치마크에 과적합하지 말라는 지시만 주고 별다른 감독 없이 만든 결과물이다. 대부분 LLM에게 좋은 벤치마크 점수를 뽑아내게 하는 건 꽤 쉽고, 이번 경우도 다르지 않았다. Rust regex 크레이트의 성능을 대략 따라잡는 데 2주 정도 걸렸고, rebar에서 1.4배 더 빠르게 만드는 데 다시 2주가 걸렸다². 하지만 에이전트는 과적합과 보상 해킹을 막는 강력한 가드레일을 걸어두지 않으면 그러기 마련인데, 이번 실험에서는 일부러 그렇게 하지 않았다.

과적합을 확인하기 위해 다소 자의적으로³ ripgrep 벤치마크 코퍼스를 홀드아웃 벤치마크로 사용했는데, 알고리즘이 폭발해 벤치마크가 끝나지 않는 경우를 제외하고도 10배나 느렸고, 아예 벤치가 끝날 때까지 기다리는 것 자체가 무의미할 정도로 오래 걸리는 경우도 있었다. 40% 더 빠르다는 말은 이렇게 무색해졌다!

Andrew Gallant(일명 BurntSushi)의 rebar 벤치마크 스위트는 벤치마크 스위트 중에서는 꽤 포괄적인 편이지만, 그 정도로 포괄적인 스위트조차 에이전트는 높은 점수를 받으면서도 일반 성능으로 이어지지 않는 방식으로 과적합하는 데 아무런 어려움이 없다.

다음 단계는 예전에 이야기했던 트릭을 쓰는 것이었다. LLM에게 단순히 속이지 말라고 하는 데 그치지 않고, 평가에 쓰일 홀드아웃 벤치마크 세트가 존재한다고 알려주는 방법이다. 그렇게 하자 LLM은 성능을 어느 정도 일반화해 홀드아웃에서 전체적으로 약 2.4배 느린 수준까지 개선됐다. 존재하는 가장 빠른 범용 정규식 엔진과 비교한다는 점을 감안하면 꽤 괜찮아 보인다. 하지만 이 벤치마크들은 코딩 에이전트가 만든 것이란 점을 기억해야 한다. 벤치마크가 무엇을 측정하는지 들여다보니, 적어도 동일한 가중치로 포함시킬 이유가 전혀 없는 항목들이 있었다. 중요해 보이는 벤치마크만 추려보면, FRE는 홀드아웃에서 4배 느리다⁰. “홀드아웃이 있다고 알려주는” 고전적인 트릭을 적용하기 전보다는 훨씬 나아졌지만, 여전히 40% 더 빠르다는 것과는 거리가 멀다.

여기서 흥미로웠던 점은 몇 가지다:

1. 에이전트에게 벤치마크에서 이기기 위해 보상 해킹이나 과적합을 하지 말라고 지시해도, 의미 없는 방식으로 nontrivial한 벤치마크에서 ‘우승’하는 것은 너무나 쉽다는 점
2. 또다시, LLM에게 일반화하라고 하거나 과적합·부정행위를 하지 말라고 하는 것보다 홀드아웃 세트가 있다고 알려주는 것이 더 효과적이었다는 점
3. FRE의 전체 성능은 그다지 좋지 않지만 특정 유스케이스에서는 실제로 더 좋은 성능을 낸다는 점. 일반적으로 특정 유스케이스를 위해 진지한 엔지니어링 경험을 요구하던 특화된 코드를 작성하는 비용이 크게 낮아졌다는 점

(1)에 대해 말하자면, 그래서 요즘 그토록 많은 허위 주장을 보는 것도 당연하다. 과거에 40% 속도 향상이란 허위 주장을 할 만큼 그럴듯하게 성능을 속이는 FRE 같은 것을 만들려면 상당한 전문 지식이 필요했다. 최소한 문자열 매칭 알고리즘과 정규식 엔진에 대한 깊은 이해, 그리고 일반적인 코드 최적화와 SIMD 최적화 실력이 있어야 했다. FRE에는 정규식을 머신 코드로 컴파일하는 모드도 있으니 컴파일러 전문 지식도 필요했을 것이다. 이제는 그런 벤치마크 속임수 — 원하든 원하지 않든 — 를 몇 분의 타이핑만으로 얻을 수 있다.

(2)에 대해서는, 이게 일반화되는지 궁금하지만 아직 충분히 많은 사례를 시험해보지 않아 알 수 없다.

(3)에 대해서는, 거의 인간의 노력이 들어가지 않은 바이브 코딩된 정규식 라이브러리를, 더 느린데다 견고하고 잘 테스트된 기존 라이브러리가 있는데 굳이 쓸 이유가 없으므로 FRE라는 결과물 자체는 흥미롭지 않다. 내가 흥미롭다고 생각하는 것은, 과거에는 희귀하고 전문적이며 비쌌던 지식을 LLM이 얼마나 대체할 수 있는가 하는 점이다.

과거에는 지식을 갖추고 있더라도 특정 워크로드에 최적화된 커스텀 정규식 엔진을 직접 작성하지는 않았을 것이다. 대규모 사용처 중에는 그런 수준의 커스터마이징을 하는 경우도 있었다. 예컨대 내가 Bing 인덱스 작업을 할 때, 코드에는 서로 다른 컴파일러가 여러 개 들어 있었다. 그걸 만든 사람이 최대 성능을 쥐어짜기 위해 그렇게 한 것이다. 검색 엔진에서는 컴파일 시간과 컴파일된 코드의 실행 성능이 모두 중요하고, 위치에 따라 트레이드오프가 다르므로, 일반적인 프로젝트라면 인터프리터를 쓰거나 “일반 코드”로 자료구조를 직접 순회할 만한 곳마다 커스텀 컴파일러를 작성하면 더 좋은 성능을 얻을 수 있다. 그 컴파일러들을 쓴 사람이라면 정규식 비슷한 코드를 다루면서 커스텀 정규식 엔진도 여러 개 만들었을 것이다. 하지만 그런 전문성과 의지를 동시에 갖추고, 더구나 업무 중에 그런 특화된 코드에 시간을 쏟을 자유까지 가진 사람은 극히 드물다. 당시 파트너급 엔지니어였고 검색 인덱스 작업으로 디스팅귀시드 엔지니어로 승진한 그 Bing 엔지니어의 인건비와 LLM을 루프에 돌리는 비용을 비교해보면, 이런 종류의 특화된 코드를 작성하는 비용은 수만 배 이상 떨어졌다.

아직도 AI는 가짜라고 생각하는 사람들은 앞부분만 읽고 “역시 AI는 가짜를 만들어내니 가짜 정규식 엔진을 만들어냈구나”라고 생각할 것이다. 하지만 결과를 보면, 홀드아웃에서 세계에서 가장 빠른 정규식 엔진보다 절반보다 약간 느린 정도이면서도 많은 실제 워크로드에서는 오히려 더 빠른 경우가 있으니 — 과적합의 대부분은 특정 벤치마크 패턴을 하드코딩한 것이 아니라, 대략 비슷한 형태의 것들에 대해서는 최적화가 되고 다른 형태에 대해서는 그렇지 않은 식이다 — 가짜 정규식 엔진과는 거리가 멀다. 게다가 컴파일 시간을 무시하고 반복 검색이나 매우 긴 검색을 실행하는 경우에는 네이티브 코드 컴파일 모드가 실제로 홀드아웃에서 Rust regex 크레이트를 이기기도 한다(많은 실제 유스케이스에서는 충분히 합리적인 가정이다). FRE의 목표가 몇 분의 인간 시간으로 만들 수 있는 정규식 엔진을 만드는 것이 아니라 빠른 정규식 엔진을 만드는 것이었다면, 다양한 홀드아웃 벤치마크에서 꽤 경쟁력이 있었을 것이고(물론 다양한 프로덕션 워크로드를 직접 돌려봐야 드러나는 빈틈은 있겠지만), 지금의 빠르고 허술한 버전조차도 일부 실제 워크로드에서는 매우 뛰어나다.

따라서 FRE 정규식 엔진 전체로 보면 Rust regex 크레이트보다 성능이 떨어지지만, 워크로드나 유스케이스에 특화했을 때 얻을 수 있는 이득을 생각하면 특정 지점에 자신만의 특화된 정규식 엔진을 넣는 것이 합리적인 경우가 있을 수 있고, 다른 종류의 로우레벨 소프트웨어에도 같은 말이 적용된다. AI 극대주의자가 아니더라도, 몇 년 안에 데이터베이스 같은 더 큰 소프트웨어에서도 이런 일이 일어나는 것을 보는 게 충분히 그럴듯하다고 생각할 수 있다.

Yossi Kreinin, Jamie Brandon, Peter Geoghegan, Luke Burton, John Spurling, Dennis Snell, Max Bittker에게 코멘트/수정/토론에 감사드립니다.

P.S. 여기에서의 논의에 따르면, LLM 덕분에 뭔가를 조금 만져보고 호기심을 충족시키는 데 걸리는 시간은 크게 줄어든 반면, 글로 정리해 블로그에 올릴 만큼 엄밀하게 만드는 데 걸리는 시간은 크게 달라지지 않았다(여러 이유로 오히려 늘었다고 생각한다). 그 결과 어느 때보다 많은 분석을 하고 있지만 그 결과를 몇몇 친구들과만 공유하고 공개하지는 않고 있다. 실험 삼아 이번에는 평소 블로그 글에 요구하는 정리·엄밀성 기준을 훨씬 낮춰, 아주 빠르게 글을 써보려 한다. 친구에게 가볍게 이야기하듯 쓰는 느낌이다. 이번 글의 목표는 작성에 30분 정도를 쓰는 것이었다고 하니, 점심시간에 후딱 해치울 수 있는 정도다. 이에 대해 의견이 있다면 알려달라!

물론 여기서의 모든 수치는 평소보다 틀릴 가능성이 높다는 점을 유의해야 한다. 한 벤치마크를 1~2분 정도 들여다봤더니 문제가 하나 있었고, 다른 벤치마크를 1분 정도 더 보니 또 문제가 있었다. 둘 다 고쳤지만, 이는 내가 아직 찾아내지 못한 다른 문제들이 더 있다는 뜻이다. 하지만 잘못된 벤치마크 수치라는 점에서 이는 매우 현실적이다! 벤치마크 수치를 들여다볼 때마다, 여기처럼, 혹은 여기처럼, 수치는 거의 항상 틀려 있다. 벤치마크포칼립스의 또 다른 측면은, 적어도 지금으로서는 LLM이 엉터리 벤치마킹을 잘한다는 것이다. 따라서 벤치마크 설정이 합리적인지 확인하는 데 상당한 주의를 기울이지 않았다면, LLM이 생성한 벤치마크 설정만으로는 뭔가 진짜 성능 향상이라 해도 일반적으로 알 수 없다.

부록: FRE 벤치마크 세부 사항

위 내용을 쓰고 발행을 앞두고 한 가지 더 발견한 것이 있다. LLM이 FRE가 rebar에서 Rust regex 크레이트보다 40% 빠르다고 주장한 것도 잘못되었다는 점이다. 틀렸다기보다는 적어도 오해의 소지가 있다는 것이 더 정확하다. 실제로는 rebar 벤치마크가 실행되는 방식과 같은 방식으로 벤치마크를 실행한 것이 아니었다. 벤치마크 결과를 1분 정도 확인하다 두 가지 문제를 발견한 뒤 이를 점검해보니, https://github.com/BurntSushi/rebar에서처럼 rebar 벤치마크를 실행하라는 지시에도 불구하고 LLM이 인터페이스를 바꿔 FRE가 성능을 높일 수 있는 최적화를 가능하게 했던 것이다. 이를 수정하자 rebar에서 FRE가 Rust보다 1.4배 빠르던 것이 오히려 1.5배 느려졌고(“단지” RE2보다는 2배 빠른 수준), 따라서 원래 결과는 이중으로 가짜였다. FRE가 rebar 벤치마크에 심하게 과적합되어 있었을 뿐만 아니라, 결과 자체에도 부정행위가 포함되어 있었던 셈이다.

하지만 긍정적으로 보면, 이는 rebar에서의 FRE 성능(Rust보다 1.5배 느림)과 홀드아웃 벤치마크에서의 성능(2.4배 느림) 차이가 이전에 보였던 것만큼 크지 않다는 뜻이므로, “LLM에게 홀드아웃이 있다고 말하는” 트릭이 이전에 보였던 것보다 훨씬 더 잘 먹혔다는 얘기가 된다.

그 뒤 LLM에게 몇 시간 동안 힐 클라이밍을 시켰더니 FRE가 1.28배 더 빠르다고 주장했는데, LLM 시간으로 몇 시간 만에 얻은 결과치고는 대단한 개선처럼 들리지만, 다시 1분 정도 부정행위를 찾아보니 여러 문제를 발견했다. 그중 하나는 (?s)^(.*)$에 대한 매치 개수를 세는 검색이 haystack(데이터)을 전혀 보지 않고 개수를 반환하는 경우였고, 또 다른 부정행위는 벤치마크가 라인 단위로 수행되어야 하는데 멀티라인 grep을 수행한 경우였다. 에이전트를 한 달 동안 엄격한 가드레일 없이 루프에 방치하면 이런 일이 생기는 것은 전혀 놀랍지 않다. 이것이 여기서의 주장을 더 강화하는지 아니면 약화하는지는 불분명하지만, 또 다른 문제들을 수정한 뒤 FRE는 다시 1.4배 느려졌다. 에이전트를 하룻밤 더 돌리자 FRE는 다시 1.5배 빠르다고 주장했다.

여기서 나의 원래 목표는 지금의 공개된 SOTA 에이전트(GPT-5.6 Sol)를 별다른 감독 없이 nontrivial한 코드 최적화 문제에 한 달 동안 루프에 넣어 돌리면 무슨 일이 일어나는지 보는 것이었으므로, 벤치마크를 더 공정하게 만들기 위해 시간을 더 쓰기보다는 여기서 멈추고 결과 그래프 몇 개만 올리려 한다.

전반적으로 Rust와 RE2 대비 FRE를 보면, FRE는 rebar 벤치마크에서 대체로 더 좋은 성능을 내는 경향이 있지만(위에서 언급했듯이 상당 부분은 과적합 때문이다), 모든 경우에 그런 것은 아니다(아래 그래프는 글 본문에서 언급한 수치와 반드시 일치하지 않는다. 에이전트가 끊임없이 변경을 가하고 있어 어느 시점의 스냅샷도 즉시 구식이 되기 때문이다):

특정 벤치마크나 특정 rebar 벤치마크 그룹에서의 성능이 궁금하다면 다음 표를 참고하면 된다(1보다 큰 비율은 FRE가 더 빠르다는 뜻이고, 1보다 작으면 FRE가 더 느리다는 뜻이다):

AOT 컴파일러 모드도 있는데, 정규식을 네이티브 코드로 컴파일하는 데 오래 걸린 뒤 실행한다. 모든 경우에 AOT를 지원하는 것은 아니지만, 지원되는 경우의 결과는 다음과 같다. 볼 수 있듯이 AOT 컴파일러는 매우 느리며(컴파일 시간 벤치마크에서 크게 진다), 컴파일에 꽤 많은 시간을 쓰는데도 결과가 표준 FRE 정규식 엔진보다 느린 경우가 많지만(물론 빠른 경우도 많다).

그리고 홀드아웃 벤치마크가 있다. 위에서 언급했듯이, AOT가 아닌 FRE 코드의 경우 홀드아웃에서의 성능은 rebar만큼 좋지 않다. 또한 위에서 언급했듯이, ripgrep 같은 워크로드를 고려하면 “hot search” 벤치마크 세트가 다른 것들보다 아마 더 중요하므로, FRE의 결과는 전체 점수가 보여주는 것보다 더 나빠 보인다.

여기서 주목할 점 하나는, 홀드아웃 벤치마크 중 컴파일 시간을 벤치마크에 포함하지 않고 검색을 반복 실행하는 경우, AOT FRE가 벤치마크에서 더 좋은 성능을 낸다는 것이다. 많은 유스케이스에서는 컴파일에 수 초가 걸리는 정규식을 원하지 않겠지만, 괜찮은 경우도 많다. 예컨대 ripgrep이나 Silver Searcher 같은 경우, 바로 매칭을 시작할 수 있는 정규식으로 실행을 시작하고 다른 스레드에서 컴파일을 진행한 뒤 컴파일이 끝나면 더 빠른 매처로 갈아타는 방식을 쓸 수 있다. 내 CPU 중 긴 ripgrep 검색에 쓰이는 비중을 생각하면, 그런 전략이 내가 개인적으로 하는 작업의 성능을 개선할 수 있을 것 같다. LLM 이전에는 최적화 정규식 컴파일러를 작성하는 데 노력을 들일 만한 가치가 없었겠지만, 이제는 몇 개 토큰으로 가능해졌다.

여기서 또 하나 주목할 점은, 이 비교가 ARM Graviton 머신에서 SVE/SVE2를 사용해 실행되었고 FRE에는 SVE/SVE2 최적화가 들어가 있어 다소 불공정할 수 있다는 것이다. LLM 이전에는 존재하는 모든 SIMD 명령어 조합에 대해 정규식을 최적화하는 것이 그만한 가치가 없었을지 모르지만, LLM을 이용하면 그런대로 괜찮은 SIMD 최적화를 꽤 쉽게 생성할 수 있다. 인간 전문가가 여기서는 일반적으로 LLM보다 더 잘한다는 것을 알고 있다. 예컨대 Jay Stelly는 LLM에게 SIMD 코드를 생성시키려 했을 때 원하는 수준의 코드를 얻기까지 20번 이상의 반복이 필요했다고 말했다. 하지만 반대로 LLM은 주어진 시간 안에 인간이 시도할 수 있는 것보다 훨씬 많은 최적화를 시도할 수 있으므로, 특정 최적화 하나하나가 인간 전문가가 만든 것만큼 좋지 않더라도 전체적으로는 여전히 꽤 잘할 수 있다.

과적합 문제도 있다. 맥락에 따라 이 문제는 매우 쉽게 해결되는 경우부터 다소 어렵게 해결되는 경우까지 있다. 나는 여기서 일부러 문제를 해결하려고 크게 노력하지 않고 어떤 일이 일어나는지 보려 했지만, Azul AI를 작업할 때처럼 큰 노력 없이도 문제를 해결한 적이 있다. 하지만 이런 대규모 벤치마크 주장 중 상당수는 사람들이 과적합을 피하려고 거의 또는 전혀 노력하지 않거나, 심지어 마이너스 노력을 들일 때 나온다. LLM 이전 시대에도 사람들은 자신의 애정 프로젝트가 얼마나 훌륭한지 보여주기 위해 극도로 대표성 없는 마이크로벤치마크를 고르곤 했는데, 이는 적어도 무의식적인 수준에서는 벤치마크에 과적합하지 않으려는 마이너스 노력에 해당한다. 인간의 본성상 사람들이 오해의 소지가 있는 주장을 멈출 것 같지 않고, 오해의 소지가 있는 주장을 만드는 것이 그 어느 때보다 쉬워졌으므로, 당연히 그런 주장을 더 많이 보게 된다.

이 글에서는 AI가 아닌 소프트웨어에 대해 논했지만, 여기서 말한 모든 것은 AI 소프트웨어에는 두 배로 적용된다. 예컨대 Kimi K2가 Fable(5) 수준이라는 코멘트를 많이 봤다. 하지만 내가 아는 모든 사용자는 GPT-5.6 Sol이나 Fable보다 훨씬 못하다고 느꼈다. 인상적인 엔지니어링 성과가 아니라는 말은 아니지만, 다양한 실제 작업에서의 성능은 벤치마크에서만큼의 수준이 아니다. 이는 각종 평가(evaluation) 성격의 문제에도 적용된다. 예컨대 친구가 ICFP 2026 대회 문제에 서로 다른 코딩 에이전트를 시험해봤을 때도 그랬다. 보안 이슈에도 적용되는데, 이는 AI 랩들이 분명히 자신들의 평가에 넣고 있을 것이다. 예컨대 내 동료가 Kimi K3를 이용해 우리 소프트웨어의 취약점을 스캔해보니 GPT-5.6 Sol이 찾은 취약점의 약 4분의 1만 찾았고, GPT-5.6 Sol이 찾지 못한 취약점은 하나도 찾지 못했으며, 비용 외에는 어떤 차원에서도 이점이 없었다. 실제 보안 이슈를 찾기 위해 더 저렴한 모델을 쓰고 있는 내가 아는 사람들은 벤치마크에서는 더 낮은 성능을 보이지만 실제에서는 더 잘하는 GLM-5.2 같은 다른 모델을 쓰고 있다.

다시 FRE 이야기로 돌아오면, 한 가지 더 언급할 점은 홀드아웃 벤치마크가 에이전트가 알 수 없는 이유로 선택한 ripgrep 벤치마크 설정의 임의의 하위 집합이라는 것이다. 에이전트에게 전체 벤치마크 스위트를 가져오라고 했지만, 이 글을 쓰는 시점까지 끝나지 않아 전체가 완료되면 결과가 어떻게 될지는 아직 모른다.