같은 벤치마크를 다시 돌리면 같은 점수가 나올까요

오늘 다룰 글은 영국 AI 안전 연구소(UK AISI)와 EvalEval 팀이 Hugging Face 블로그에 공개한 How UK AISI and EvalEval Are Making Benchmark Results Reproducible입니다. 이 글은 벤치마크 점수가 매번 흔들리는 이유를 모델 실력이 아니라 평가 설정과 기록의 문제에서 찾고, 고정된 설정과 완전한 로그로 누구나 다시 돌려서 확인할 수 있게 만들자고 제안합니다. 원문 링크는 제목 아래에 걸려 있습니다.

저는 이 글을 읽으면서 얼마 전 겪었던 장면이 먼저 떠올랐습니다. 같은 모델을 같은 벤치마크로 돌렸는데 어제와 오늘 점수가 다르게 나온 날이 있었거든요. 코드는 손대지 않았고 데이터도 그대로였는데, 온도가 조금 달랐고 시스템 프롬프트에 한 줄이 추가돼 있었습니다. 그렇다면 우리가 leaderboard에서 보는 그 소수점 차이는 대체 무엇을 믿고 봐야 할까요. 오늘은 이 질문을 붙잡고 영국 안전 연구소의 평가 현장과 EvalEval이라는 도구의 선택을 하나씩 따라가 보겠습니다.

같은 점수표인데 왜 매번 숫자가 다를까요

벤치마크 점수를 처음 접하면 시험 점수처럼 느껴집니다. 같은 문제를 풀면 같은 점수가 나와야 하고, 점수가 높으면 실력이 좋은 거라고 생각하죠. 그런데 언어 모델 평가는 생각보다 훨씬 흔들립니다. 같은 데이터셋을 썼다고 해도 온도와 샘플링 방식이 다르면 답이 달라지고, 시스템 프롬프트에 들어간 문장 하나나 few-shot 예제의 순서만 바뀌어도 점수가 몇 점씩 움직이기 때문입니다. 여기에 평가를 돌리는 harness 코드가 조금만 달라도 결과는 또 달라집니다.

제가 이 대목에서 가장 흥미롭게 본 부분은, 차이가 사소해 보여도 결과가 사소하지 않다는 점입니다. 온도를 0에서 0.7로 올렸다거나, 예제를 다섯 개에서 세 개로 줄였다는 정도는 보고서에서 빠지기 쉽습니다. 하지만 생성형 평가에서는 이런 사소한 선택이 어떤 답을 뽑을지를 직접 바꾸는데, 점수표에는 최종 숫자만 남습니다. 그래서 겉으로는 같은 시험을 본 것처럼 보이지만, 실제로는 서로 다른 조건에서 본 시험이 됩니다.

생각해보면 사람 시험도 비슷합니다. 같은 수학 문제라도 계산기 사용이 가능한 반과 금지된 반의 평균은 다르게 나오죠. 그런데 우리는 모델 평가에서 이런 조건 차이를 자주 적어 두지 않습니다. 저는 그래서 이 글의 출발점이 마음에 들었습니다. 모델을 더 탓하기 전에, 점수를 만드는 과정을 먼저 의심하자는 것이니까요. 그렇다면 현장에서 점수를 가장 엄격하게 봐야 하는 사람들은 이 문제를 어떻게 다루고 있을까요.

배포 전에 미리 보는 시험이 따로 있습니다

영국 AI 안전 연구소는 frontier 모델이 세상에 나오기 전에 미리 살펴보는 평가를 맡고 있습니다. 일반 벤치마크가 수학이나 코딩, 상식 같은 넓은 능력을 재는 데 가깝다면, 이쪽은 안전과 직결된 능력을 봅니다. 사이버 공격에 악용될 수 있는 지식이나 생물학 관련 위험, 그리고 모델이 도구를 써서 스스로 여러 단계를 수행하는 agentic한 행동이 대표적인 예입니다. 배포 후에 문제가 터지면 되돌리기 어렵기 때문에, 나오기 전에 어디까지 할 수 있는지를 미리 확인하는 것이죠.

이런 평가는 정확히 한 번 잘 치르는 게 목표가 아닙니다. 같은 조건에서 다시 돌려도 같은 그림이 나오는지, 다른 사람이 같은 재료로 돌려도 같은 결론에 닿는지가 같이 중요합니다. 왜냐하면 안전 평가는 점수 경쟁이 아니라 판단의 근거가 되기 때문입니다. 예컨대 어떤 모델이 특정 사이버 작업에서 위험한 수준의 능력을 보였다는 결론이 나왔다고 해보죠. 이때 평가 조건이 어딘가에 적혀 있지 않으면, 그 결론은 나중에 누구도 되짚을 수 없는 한 줄짜리 주장으로 남습니다.

저는 여기서 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 배포 전 평가는 대개 최신 모델을 대상으로 한 번에 진행되는데, 시간이 지나서 모델 버전이 바뀌거나 평가 코드가 조금 바뀌면 그때의 결론을 어떻게 믿을 수 있을까요. 그래서 안전 연구소처럼 무거운 판단을 내려야 하는 조직일수록 재현 가능성이 절실해집니다. 점수 자체보다 점수가 나온 과정을 남기는 일이 먼저인 셈이죠. 그런데 과정을 남긴다는 말은 구체적으로 무엇을 뜻할까요.

온도가 0.1만 달라져도 순위가 바뀝니다

이 글에서 반복해서 나오는 지적은, 공개되지 않은 작은 차이가 점수를 몇 점씩 움직인다는 사실입니다. 온도와 top-p 같은 샘플링 설정, 시스템 프롬프트의 문구, few-shot 예제의 개수와 순서, 그리고 점수를 매기는 harness 구현이 모두 여기에 들어갑니다. 하나하나는 별것 아닌 것처럼 보이지만, 합쳐지면 leaderboard의 순서가 뒤집힐 정도의 차이가 됩니다.

왜 이렇게 민감할까요. 언어 모델의 답은 확률 분포에서 뽑히는데, 온도가 낮으면 가장 그럴듯한 답에 몰리고 온도가 높으면 다양한 답이 섞여 나오기 때문입니다. 수학 풀이처럼 정답이 하나로 정해지는 문제에서는 이 차이가 통과율에 직접 반영됩니다. 시스템 프롬프트도 마찬가지입니다. 정중하게 단계별로 풀라고 덧붙였는지, 아니면 답만 내놓으라고 했는지에 따라 모델의 행동이 달라지는데, 이런 문구는 논문이나 블로그에서 자주 생략됩니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 점수 차이는 실력 차이가 아니라 조건 차이일 수 있다는 것이죠.

여기서 재미있는 질문이 생깁니다. 그렇다면 83.2점과 84.7점의 차이를 보고 이 모델이 더 똑똑해졌다고 말할 수 있을까요. 조건이 고정되지 않았다면 그 1.5점은 발전이 아니라 흔들림일 수 있습니다. 연구실에서는 이런 흔들림을 노이즈라고 부르는데, 노이즈가 클수록 작은 개선은 묻혀 버립니다. 그래서 재현 가능성은 꼼꼼한 성격의 문제 같지만, 실제로는 무엇을 발전이라고 부를지를 정하는 문제에 가깝습니다. 문제는 그다음입니다. 흔들림을 줄이려면 무엇을 고정해야 할까요.

다시 돌릴 수 있다는 말의 실제 뜻은

EvalEval이 내세우는 답은 단순합니다. 평가를 다시 돌릴 수 있게 만들자는 것입니다. 이때 다시 돌린다는 말은 같은 코드를 한 번 더 실행한다는 뜻이 아니라, 다른 사람도 같은 조건을 갖춰서 같은 결과를 얻을 수 있다는 뜻에 가깝습니다. 그래서 EvalEval은 오픈소스 도구로 평가 설정을 고정하고, 실행 과정을 빠짐없이 기록하는 방식을 택합니다.

고정된 설정이란 온도와 샘플링, 프롬프트, 예제 구성, 채점 방식 같은 선택을 파일로 적어 두고 바꾸지 않는다는 뜻입니다. 사람의 손으로 매번 입력하는 게 아니라 설정 파일이 평가를 지배하게 만드는 것이죠. 완전한 로그란 어떤 모델을 어떤 데이터에 어떤 조건으로 돌렸고, 각 샘플에서 무슨 답이 나왔는지를 남긴다는 뜻입니다. 합산 점수만 남기는 게 아니라 샘플별 출력까지 남기니, 나중에 누군가 이상한 점수를 발견해도 어디서 어긋났는지 되짚을 수 있습니다.

저는 여기서 멈칫했습니다. 로그를 남긴다는 말이 너무 당연하게 들리기 때문입니다. 그런데 막상 내 주변을 돌아보면 점수만 있고 로그는 없는 경우가 훨씬 많습니다. 엊그제 돌린 평가의 시스템 프롬프트가 정확히 어떤 문장이었는지, 예제를 어떤 순서로 넣었는지 물으면 바로 답하기 어렵죠. 일종의 요리 기록과 비슷합니다. 맛있다는 말만 남기고 레시피와 불 조절을 적어 두지 않으면, 다음 사람은 같은 맛을 낼 수 없습니다. 그렇다면 레시피에 해당하는 재료 목록에는 무엇이 들어가야 할까요.

점수가 아니라 꾸러미를 공개해야 합니다

이 글이 말하는 재현 가능성은 점수 공개가 아니라 꾸러미 공개에 가깝습니다. 데이터셋 해시와 모델 버전, 코드 커밋, 컨테이너 이미지, 그리고 샘플별 출력이 한 묶음으로 있어야 한다는 것이죠. 각각의 역할은 분명합니다. 데이터셋 해시는 내가 본 문제와 남이 보는 문제가 같은 문제임을 보증하고, 모델 버전은 같은 이름을 썼더라도 가중치가 바뀌지 않았음을 확인해 줍니다. 코드 커밋은 채점 로직이 중간에 살짝 바뀌는 일을 막아주고, 컨테이너 이미지는 라이브러리 버전 차이로 생기는 미묘한 어긋남을 줄여줍니다.

이 목록을 처음 보면 과하다고 느낄 수도 있습니다. 점수 하나에 이렇게까지 해야 하냐는 반응이 나올 만하죠. 하지만 분산된 환경에서 일해 본 분들은 바로 감이 올 겁니다. 제 컴퓨터에서는 되는데 동료 컴퓨터에서는 안 되는 문제는 대개 환경 차이에서 오니까요. 평가도 마찬가지입니다. 같은 데이터와 같은 모델이라도 실행 환경이 다르면 토큰화나 배치 처리, 심지어 난수 생성 방식에서 차이가 생길 수 있습니다. 컨테이너까지 고정하자는 제안은 그래서 연구실의 까다로움이 아니라 운영의 경험에 가깝습니다.

저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 평가도 같은 눈으로 봐야 합니다. 숫자가 좋아졌다는 말과 함께, 그 숫자를 만든 꾸러미가 그대로 있는지가 같이 와야 하는 것이죠. 그런데 꾸러미를 다 공개하면 새로운 걱정이 생깁니다. 시험 문제를 통째로 내놓는 셈인데, 그래도 괜찮을까요.

한 번 돌린 최고 점수는 믿음이 안 갑니다

점수가 흔들린다는 사실을 받아들이면 보고 방식도 달라져야 합니다. 이 글이 권하는 방향은 한 번 돌려서 나온 최고 점수가 아니라 여러 시드로 돌린 평균과 신뢰구간을 보는 것입니다. 같은 조건에서도 샘플링의 무작위성 때문에 점수는 조금씩 달라지는데, 한 번의 실행은 그 분포에서 우연히 뽑힌 하나의 값에 불과하기 때문입니다.

신뢰구간이라는 말을 들으면 통계 수업이 떠올라서 거리감이 느껴질 수도 있습니다. 하지만 아이디어 자체는 소박합니다. 줄자로 키를 잴 때 한 번만 재지 않고 몇 번 재서 대략 어느 범위에 들어가는지를 보는 것과 비슷합니다. 84점이라는 숫자 하나보다 82점에서 85점 사이에 들어간다는 범위가 더 정직한 표현이죠. 특히 1점이나 2점 차이로 우열을 가리는 leaderboard에서는 이 범위가 겹치는지를 보는 게 중요합니다. 범위가 크게 겹치는데도 순위가 갈렸다고 말한다면, 그건 실력 차이가 아니라 우연을 순위처럼 포장한 셈이니까요.

여기서는 조금 조심해서 읽을 필요가 있습니다. 여러 번 돌리면 비용이 몇 배로 늘어납니다. 큰 모델을 큰 벤치마크에 여러 시드로 돌리는 건 시간도 돈도 듭니다. 그럼에도 이 글의 제안이 설득력을 갖는 이유는, 한 번의 점수로 잘못된 판단을 내리는 비용이 더 크기 때문입니다. 배포 여부를 가르는 안전 평가라면 더 그렇죠. 저는 그래서 최고 점수 하나를 내세우는 보고서보다 분포를 보여주는 보고서를 더 신뢰합니다. 분포를 본다는 건 작성자가 흔들림을 숨기지 않았다는 뜻이니까요. 그렇다면 이렇게 다 공개하면 풀리는 문제일까요. 아쉽게도 현실은 조금 더 복잡합니다.

문제를 공개하면 답이 새고 숨기면 검증이 안 됩니다

재현 가능성을 끝까지 밀어붙이면 피할 수 없는 긴장이 있습니다. 검증을 위해 재료를 다 내놓을수록 시험 문제가 바깥으로 새기 쉽고, 그렇게 새어나간 문제는 다음번 평가의 정직함을 해치기 때문입니다. 모델이 이미 본 문제를 다시 맞히는 오염(contamination)이 생기면 점수는 올라가지만 실력은 그대로인데, 겉으로는 구분이 안 됩니다.

이 딜레마는 생각보다 뿌리가 깊습니다. 문제를 비공개로 두면 오염은 막을 수 있지만, 바깥에서는 평가가 제대로 이뤄졌는지 확인할 길이 없습니다. 반대로 문제와 정답, 채점 코드를 다 공개하면 누구나 다시 돌릴 수 있지만, 그 순간부터 그 문제는 연습 문제처럼 쓰일 수 있습니다. 다음 모델이 그 문제를 외워서 오는지 이해해서 푸는지를 가리기가 어려워지는 것이죠.

연구 현장에서는 이 사이를 걷는 여러 절충안이 나옵니다. 문제의 일부만 공개하고 나머지는 비공개로 돌리거나, 해시값으로 동일성만 확인하게 하고 원문은 따로 보관하거나, 신뢰할 수 있는 제3자가 대신 다시 돌려주는 방식이 그렇습니다. 저는 이 대목을 읽으면서 시험 출제자와 수험생의 오래된 줄다리기가 떠올랐습니다. 기출문제를 다 공개하면 학생은 대비하기 쉽지만, 다음 시험의 변별력은 떨어지죠. 평가도 같은 고민을 안고 있습니다. 어디까지 보여주고 어디부터 감출지를 정하는 일이 기술 못지않게 중요한 셈입니다. 그리고 이 고민은 위험한 시험일수록 더 날카로워집니다.

위험한 시험일수록 공개가 어려워집니다

안전 평가 가운데 일부는 그 자체가 민감합니다. 사이버 공격에 활용될 수 있는 절차나 생물학적 위험과 연결된 지식을 묻는 평가는, 문제와 답을 자세히 공개하는 것만으로도 악용의 문을 열어줄 수 있기 때문입니다. agentic한 능력을 보는 평가도 비슷합니다. 모델이 도구를 엮어서 목표를 이루는 과정을 상세히 풀어놓으면, 그 기록이 그대로 우회 매뉴얼처럼 읽힐 수 있습니다.

그래서 이런 평가를 둘러싸고는 얼마나 자세히 밝혀야 하는지를 두고 논쟁이 이어집니다. 다 보여주면 검증은 쉬워지지만 위험도 커지고, 감추면 안전은 지키지만 바깥에서는 믿고 맡기기 어렵습니다. 어느 쪽도 공짜가 아닙니다. 저는 이 지점에서 평가를 기술 문제로만 보면 놓치는 게 있다고 봅니다. 공개의 수준을 정하는 일은 결국 누구와 무엇을 공유할지를 정하는 거버넌스의 문제이기 때문입니다.

현실적인 해법은 공개를 한 덩어리로 보지 않는 것입니다. 설정과 절차, 집계 방식은 넓게 공유하되, 민감한 문제 자체와 위험한 출력의 전문은 제한된 통로로 다루는 식이죠. 검증 가능한 요약과 감사 가능한 로그를 남기되, 열람 권한을 나누는 방법이 여기에 들어갑니다. 완벽한 답은 아니지만, 검증도 안전도 놓치지 않겠다는 태도는 분명합니다. 그렇다면 이런 고민을 뚫고 재현 가능성을 챙기는 일은 결국 무엇을 남길까요.

재현 가능성은 점수를 위한 일이 아닙니다

겉으로 보면 재현 가능성은 점수를 깔끔하게 만드는 작업처럼 보입니다. 하지만 조금 길게 보면 판단의 문화를 바꾸는 일에 가깝습니다. 점수 하나를 믿고 마는 대신, 그 점수가 어떤 조건에서 나왔고 얼마나 흔들리며 어디서 다시 확인할 수 있는지를 함께 묻는 습관이 생기기 때문입니다. 저는 이 변화를 오답 노트에 비유하고 싶습니다. 틀린 문제를 고치는 것도 중요하지만, 왜 틀렸는지를 적어 두면 다음 시험이 달라지듯이, 평가의 조건과 흔들림을 적어 두면 다음 모델 비교가 달라집니다.

저희 팀에서 모델을 고를 때도 비슷한 경험을 합니다. 데모에서는 매끈해 보이던 모델이 막상 운영 조건에서 온도와 프롬프트를 고정하고 다시 재보면 미묘하게 흔들리는 경우가 있거든요. 이때 점수표의 숫자보다 도움이 되는 건 분포와 로그입니다. 어디서 자주 틀리고, 어떤 조건에서 무너지는지를 알면 도입 여부를 훨씬 빨리 정할 수 있습니다. 영국 안전 연구소의 평가가 재현 가능성을 강조하는 이유도 같은 결에 있습니다. 한 번의 판정이 아니라 누적되는 판정의 신뢰를 쌓아야 하기 때문이죠.

여기서 한 가지 오해를 바로잡고 싶습니다. 재현 가능하다는 말이 모델을 통제한다는 뜻은 아닙니다. 같은 조건에서 같은 결과가 나온다는 건 측정 도구가 안정됐다는 뜻이지, 모델의 행동이 전부 예측된다는 뜻이 아닙니다. 줄자가 정확해졌다고 키가 자라지 않는 것과 비슷합니다. 측정이 안정돼야 비로소 무엇이 자랐는지를 말할 수 있는 것이죠. 그렇다면 실제로 벤치마크를 보는 독자로서 우리는 무엇을 달리해야 할까요.

다음에 벤치마크를 볼 때 제가 확인할 세 가지

제가 앞으로 보고 싶은 것은 거창한 구호가 아니라 보고서의 작은 칸 세 개입니다. 첫째는 조건이 적혀 있는지입니다. 온도와 샘플링, 시스템 프롬프트, few-shot 구성, harness 버전이 같이 있는지부터 봅니다. 이 칸이 비어 있으면 점수는 아직 반쪽짜리 주장에 가깝습니다. 둘째는 한 번의 숫자가 아니라 분포가 있는지입니다. 시드 개수와 평균, 신뢰구간이 보이면 적어도 작성자가 흔들림을 감추려 하지 않았다는 신호로 읽을 수 있습니다. 셋째는 다시 돌릴 재료가 있는지입니다. 데이터셋 해시와 모델 버전, 코드 커밋, 컨테이너 정보, 샘플별 출력 가운데 무엇이 열려 있고 무엇이 왜 닫혀 있는지가 적혀 있으면, 그 보고서는 대화를 이어갈 준비가 된 것입니다.

이 세 가지를 확인하는 습관은 리더보드를 보는 눈도 바꿔줍니다. 1점 차이의 역전을 예전처럼 승패로 읽지 않고, 구간이 겹치는지를 먼저 보게 됩니다. 새로운 1등이 나왔다는 소식에도 바로 흥분하지 않고, 조건이 같은지를 먼저 묻게 됩니다. 작은 차이처럼 보이지만, 이런 읽기가 쌓이면 연구실과 제품팀 사이의 대화도 달라집니다. 숫자 하나로 밀어붙이는 대신, 어떤 조건에서 어디까지 믿을 수 있는지를 함께 말하게 되니까요.

물론 모든 평가에 같은 잣대를 들이댈 수는 없습니다. 민감한 안전 평가에서는 다 열 수 없고, 비용이 큰 대형 평가에서는 시드를 많이 늘리기 어렵습니다. 중요한 건 완벽한 공개가 아니라 정직한 기록이라고 봅니다. 무엇을 고정했고 무엇을 고정하지 못했으며, 그로 인해 결론의 어디까지가 흔들릴 수 있는지를 적는 것만으로도 보고서는 훨씬 단단해집니다. 저는 그래서 EvalEval의 선택을 도구의 문제가 아니라 태도의 문제로 읽었습니다. 다시 돌릴 수 있게 남긴다는 건, 남의 검증을 환영한다는 뜻이니까요.

돌아보면 벤치마크는 처음부터 약속이었습니다. 같은 문제를 같은 방식으로 풀면 실력을 비교할 수 있다는 약속이죠. 영국 안전 연구소와 EvalEval이 하려는 일은 그 약속을 다시 유효하게 만드는 과정에 가깝습니다. 조건을 고정하고, 로그를 남기고, 분포로 말하고, 열 수 있는 것과 닫아야 하는 것을 구분하는 일이 쌓이면 점수는 다시 비교의 도구가 됩니다. 다음에 여러분이 leaderboard에서 2점 오른 숫자를 보게 된다면, 저와 같이 한 번만 더 물어봐 주시면 좋겠습니다. 그 2점은 같은 조건에서 다시 나와줄까요.