AI가 시험 문제에 익숙해졌을 때

같은 평가 문항에 맞춰 AI를 계속 고치면 점수는 무엇을 말해 줄까. LiveBench와 LiveCodeBench의 갱신·시간 구간 설계를 바탕으로 평가 오염과 반복 튜닝을 구분하고, 회귀 사례와 최종 시험을 나누는 방법을 살핀다.

표지는 익숙한 연습 자료와 따로 보관한 시험 자료를 표현한 AI 생성 개념 이미지다. 실제 벤치마크의 측정 결과를 그린 도표가 아니다.

팀이 고객 문의를 분류하는 AI를 만든다고 가정해 보자. 과거 문의를 모아 시험하고, 틀린 사례를 읽고, 프롬프트에 설명과 예시를 보탠다. 다시 시험하니 점수가 오른다. 같은 과정을 거듭한 끝에 준비한 문항을 거의 모두 맞힌다. 그런데 다음 주에 들어온 문의에서도 그만큼 잘할지는 아직 알 수 없다.

고친 사례를 다시 통과하는 것은 필요한 성과다. 문제는 그 사례가 이미 수정 방향을 정하는 데 쓰였는데도, 점수를 처음 보는 업무에 대한 실력처럼 읽을 때 생긴다. 모델의 가중치를 한 번도 바꾸지 않았어도 팀이 만드는 시스템은 시험 결과에 맞춰 달라질 수 있다.

앞선 작은 평가 사례집 글은 업무의 합격 기준을 구체적인 사례로 만드는 방법을 다뤘다. 그 사례집을 오래 운영하면 다른 질문이 생긴다. 개선에 사용한 자료와 개선의 효과를 판단할 자료를 어디에서 나눌 것인가.

시험 자료가 들어오는 경로를 구분한다

벤치마크의 시험 문항이나 정답이 모델의 학습 자료에 포함되는 일을 시험셋 오염이라고 한다. 이때 높은 점수에는 새로운 문제를 푸는 능력과 이미 접한 자료의 영향이 섞일 수 있다. LiveBench 논문은 이런 문항의 직접 노출과, 같은 종류의 과제를 학습한 뒤 새로운 문항을 푸는 일을 구분한다. 비슷한 분야를 배웠다는 사실만으로 평가가 무효가 되는 것은 아니다. LiveBench 논문의 오염 정의

팀 내부에서 생기는 다른 경로는 시험 결과에 맞춘 반복 선택이다. scikit-learn의 교차 검증 문서는 학습에 쓰지 않은 시험셋이라도 그 점수를 보며 설정을 계속 조정하면 시험셋에 과적합할 수 있다고 설명한다. 조정 과정에 쓰는 검증 자료와 최종 평가 자료를 구분하는 이유다. 교차 검증 문서

이 원칙을 LLM 업무에 적용하면 모델 선택뿐 아니라 프롬프트, 검색 방식, 예시, 도구 사용 규칙도 살펴야 한다. 시험에서 틀린 문의마다 전용 설명을 붙이고 그중 점수가 가장 높은 설정을 골랐다면, 해당 시험은 이미 개발에 쓰였다. 이것을 곧바로 기반 모델의 학습 자료 오염이라고 부를 수는 없다. 다만 같은 시험의 점수만으로 앞으로의 성능을 판단하기 어려워지는 문제는 남는다.

따라서 점수에 이상이 보이면 먼저 노출 경로를 기록하는 편이 유용하다. 문항이 학습 자료에 들어갔는가, 정답 예시가 실행 프롬프트에 들어갔는가, 개발자가 점수를 보고 설정을 골랐는가. 원인에 따라 고쳐야 할 대상이 달라진다. 점수가 높다는 이유만으로 오염을 단정하거나, 가중치를 고정했다는 이유만으로 평가가 독립적이라고 여겨서는 안 된다.

새 문제를 내는 벤치마크도 한계를 적는다

LiveBench는 최근 자료에 기반한 질문을 계속 추가하고, 확인 가능한 정답으로 자동 채점하는 방식을 제시한다. 고정된 문제 모음의 노출 시간을 줄이는 일과, 채점자의 취향이 점수에 들어오는 일을 함께 다루는 설계다. 공식 저장소는 릴리스별 질문을 선택하는 옵션도 제공한다. 여기서 참고할 것은 특정 모델의 현재 순위가 아니라 평가 자료를 갱신하고 판본을 지정하는 방식이다. 공식 저장소의 설명

그렇다고 새 문제라는 말이 오염 없음의 보증은 아니다. 2025년 4월 개정된 LiveBench 논문은 제목에 Contamination-Limited를 사용한다. 부록은 일부 오래된 코딩·수학 문항 때문에 제한된 분량의 오염 가능성이 남는다고 인정한다. 또 새 질문의 공개를 한 달 늦추는 정책을 설명한다. 문제를 계속 만들고 공개 시점을 관리해도 한계는 별도로 밝혀야 한다는 사례다. 개정 논문의 한계와 공개 정책

업무 평가에서도 최근에 작성한 문서인지와 독립적인 시험인지가 같은 뜻은 아니다. 어제 만든 합성 문의라도 이미 조정에 쓴 문의의 이름만 바꿨다면, 새로운 실패 조건을 충분히 담지 못할 수 있다. 반대로 오래된 업무 유형이라도 개발 과정에 노출하지 않은 실제 사례는 별도의 확인 기회를 줄 수 있다. 자료의 생성일과 노출 이력을 함께 관리해야 하는 이유다.

점수를 비교할 때 문제의 날짜도 고정한다

LiveCodeBench는 코딩 대회의 새 문제를 시간에 따라 수집하고, 데이터셋 판본과 날짜 구간을 지정해 평가하도록 설계돼 있다. 공식 README는 --release_version으로 데이터 판본을 선택하고, 점수 계산 때 시작일과 종료일을 지정하는 방법을 설명한다. 모델이 출시된 날짜만 적는 것으로는 어떤 문제를 시험했는지 충분히 설명되지 않는다는 점을 보여준다. 공식 평가 안내

2026년 10월 21일 확인한 기본 브랜치 main의 고정 버전도 이 구분을 구현한다. 점수 계산 코드는 저장된 결과의 대회 날짜를 읽고, --start_date와 --end_date로 해당 구간을 고른 뒤 점수를 계산한다. 문제를 푼 날과 문제 자체가 공개된 시점은 서로 다른 정보다. 날짜 구간을 적용하는 코드

이 방식을 사내 업무에 옮길 때는 점수 옆에 평가 묶음의 버전, 사례를 수집한 기간, 시스템 버전, 채점 기준을 함께 적을 수 있다. 지난달에는 쉬운 문의를 많이 넣고 이번 달에는 예외 문의를 많이 넣었다면, 평균 점수의 하락을 곧바로 모델의 퇴보로 해석하기 어렵다. 이 경우에는 같은 문제 묶음에서 두 시스템을 비교한 결과와, 새 업무 묶음에서 얻은 결과를 따로 보여 주는 편이 낫다.

시간으로 나누는 것만으로 모든 노출을 검출할 수도 없다. 기반 모델의 학습 범위가 불분명하거나 평가 중 외부 검색을 허용했다면, 날짜 기록만으로 문항을 처음 봤다고 입증할 수는 없다. 사용할 수 있는 도구와 자료까지 평가 조건에 포함해야 한다. 이 글은 두 벤치마크를 재실행해 성능을 비교한 결과가 아니라, 공개된 평가 설계와 구현을 업무 운영에 적용해 보는 논의다.

고친 문제는 남기고, 판단할 문제는 따로 둔다

팀에서는 평가 자료의 역할을 나눠 운영해 볼 수 있다. 실패한 사례를 감추거나 버릴 필요는 없다. 수정에 활용한 사례는 같은 오류가 되살아나는지 확인하는 데 계속 쓸 수 있다. 다만 그 결과와 개발 중 열어 보지 않은 사례의 결과가 답하는 질문을 구분한다.

이 표는 특정 벤치마크의 필수 절차를 옮긴 것이 아니라 팀을 위한 운영 제안이다. 최종 시험에서 실패한 사례를 읽고 수정했다면, 이후에는 그 사례가 개발에 노출됐다는 이력을 남긴다. 수정이 제대로 됐는지 다시 확인하되, 같은 사례의 향상만으로 새로운 업무에 대한 성능까지 입증했다고 보고하지 않는다.

자료를 나눌 때는 원문과 파생본의 관계도 살펴야 한다. 같은 고객 문의의 요약본, 표현을 바꾼 문항, 그 문의에서 만든 정답 예시를 서로 다른 묶음에 흩어 놓으면 형식적인 분리만 남을 수 있다. 같은 출처에서 나온 자료를 함께 관리하고, 개발용 예시가 최종 시험 쪽으로 들어가지 않았는지 확인하는 방법을 생각해 볼 수 있다.

최종 시험을 통과해도 적용 가능한 업무 범위와 남은 불확실성은 기록해야 한다. 작은 묶음의 좋은 결과를 모든 고객·언어·예외 상황에 대한 보장으로 늘려 읽을 수는 없다. 운영에서 새로 발견한 실패를 다음 개발 사례로 편입하고, 다음 판단에 쓸 자료를 다시 확보하는 순환이 필요하다.

오래 쓰는 평가 사례집의 가치는 사라지지 않는다. 다만 그 사례집으로 무엇을 증명하려는지 계속 확인해야 한다. 익숙한 문제를 안정적으로 처리하는 능력과 아직 조정에 쓰지 않은 문제로 넘어가는 능력을 함께 볼 때, 점수의 상승이 실제 업무 개선으로 이어졌는지 더 분명하게 말할 수 있다.