모델을 고르는 일보다, 무엇을 측정할지 정하는 일이 먼저다

새 모델이 나올 때마다 리더보드 순위를 확인하지만, 막상 내 업무에 투입하면 같은 실수를 반복한다. 코드베이스를 엉뚱하게 수정하고, 도구 호출 순서를 놓치고, 그럴듯한 오답을 길게 설명한다. 공개 벤치마크의 점수와 실제 워크플로의 신뢰성 사이에 틈이 있는 이유다.

이 틈을 줄이는 가장 현실적인 방법은 거대한 평가 세트를 기다리는 것이 아니다. 내가 모델에게 실제로 시키는 일을 작은 평가 태스크로 만들고, 여러 모델에 반복해서 실행하는 것이다. Kaggle이 2026년 6월 발표한 Kaggle Benchmarks의 로컬 개발 지원은 바로 이 과정을 개발자가 쓰던 도구 안으로 가져온다.

로컬 컴퓨터와 웹 기반 평가 환경을 연결하는 Kaggle Benchmarks 개념도
로컬 개발 환경에서 Kaggle Benchmarks를 만들고 실행하는 흐름. 이미지: Google Blog/Kaggle

왜 지금 벤치마크를 직접 만들어야 하나

Google과 Kaggle은 AI 모델이 단순한 대화형 챗봇에서 코드를 작성하고, 도구를 사용하고, 복잡한 문제를 해결하는 추론 에이전트로 이동하면서 전통적인 벤치마크만으로는 부족하다고 설명한다. 객관식 정답률이 높아도, 긴 작업을 끝까지 수행하는지와 실패했을 때 복구하는지는 별개의 능력이다.

더 중요한 문제는 평가의 속도다. 고정된 데이터셋은 만들어진 시점의 능력을 측정한다. 하지만 프레임워크, 도구, 프롬프트, 에이전트의 역할은 계속 바뀐다. 평가를 만드는 데 몇 주가 걸리면 제품의 변화 속도를 따라가지 못한다. 실제 사용자에게 필요한 것은 한 번의 권위 있는 점수보다, 새 작업이 생길 때마다 다시 돌릴 수 있는 작은 회귀 테스트에 가깝다.

외부 발표에 따르면 Kaggle Benchmarks 커뮤니티는 이미 1만 개 이상의 평가 태스크를 만들었다. 이번 로컬 개발 업데이트는 그 제작 장소를 Kaggle 웹 노트북에만 묶어두지 않고 VS Code, Cursor, Antigravity, 코딩 에이전트 같은 환경으로 확장했다. 생성, 검증, 업로드, 실행, 결과 다운로드를 로컬 개발 흐름에서 이어갈 수 있게 된 것이다.

핵심 변화는 ‘벤치마크 서비스’가 아니라 제작 루프다

Kaggle Benchmarks를 단순히 모델 순위를 보는 웹사이트로 이해하면 이번 업데이트의 가치를 놓친다. 핵심은 아이디어 → 태스크 코드 → 로컬 검증 → 모델 실행 → 결과 비교라는 루프를 짧게 만드는 데 있다.

kaggle b init
kaggle b t push my-task -f task.py --wait
kaggle b t run my-task -m gemini-3.5-flash -m claude-sonnet-4 --wait
kaggle b t log my-task
kaggle b t download my-task -o ./results

공식 CLI 문서의 흐름은 익숙한 개발 도구의 흐름과 닮았다. init으로 로컬 환경을 만들고, push로 태스크를 올리고, 여러 모델을 대상으로 run한 뒤 로그와 결과를 내려받는다. 결과가 마음에 들 때만 공개 단계인 publish로 넘어간다. 웹 편집기에서 셀을 오가며 확인하던 작업이 소스 파일과 명령어 중심의 반복 가능한 작업으로 바뀐다.

자연어 한 문장이 평가 코드가 되는 이유

로컬 개발의 진짜 레버리지는 AI 코딩 에이전트와 결합할 때 생긴다. Kaggle은 write-kaggle-benchmarks라는 스킬을 공개했다. 이 스킬은 에이전트가 kaggle-benchmarks SDK와 Kaggle CLI를 사용해 평가 태스크를 작성하도록 구조화된 지시를 제공한다.

에이전트에 다음과 같이 요청할 수 있다.

Install the write-kaggle-benchmarks skill:
https://github.com/Kaggle/kaggle-skills

그 다음에는 평가하고 싶은 행동을 자연어로 설명한다. Kaggle이 제시한 예시는 “모델에게 300+140=460이 맞는지 묻는 태스크를 만들어라”는 식이다. 물론 실제 업무에서는 “이 저장소의 변경사항을 요약하고 위험한 API 변경을 세 가지 찾게 하라”거나 “검색 도구를 사용해 근거 링크를 남겼는지 검사하라”처럼 더 구체적인 요청을 넣게 된다.

SDK의 기본 단위는 태스크 함수다. @kbench.task로 평가 단위를 정의하고, 모델에 프롬프트를 보내고, assertion으로 통과 조건을 적고, .run()으로 실행한다. 중요한 것은 에이전트가 코드를 대신 써준다는 사실이 아니다. 사람이 모호하게 알고 있던 “잘한다”를 입력·행동·통과 조건으로 바꾸게 된다는 점이다.

import kaggle_benchmarks as kbench

@kbench.task(name="check-factual-answer")
def check_factual_answer(llm):
    response = llm.prompt("300+140=460이 맞는지 설명하라.")
    kbench.assertions.assert_contains_regex(
        r"(?i)(아니|틀리|440)",
        response,
        expectation="잘못된 산술식을 바로잡아야 한다.",
    )

check_factual_answer.run(kbench.llm)

실제 워크플로에 넣는 네 단계

  1. 실패 장면 하나를 고른다. “추론 능력을 평가한다”처럼 크게 시작하지 말고, 실제로 반복되는 실패를 한 문장으로 적는다. 예를 들어 “도구로 조회한 결과와 답변의 숫자가 일치해야 한다”처럼 관찰 가능한 행동이어야 한다.
  2. 통과 조건을 먼저 쓴다. 정답 문자열 하나만 검사할지, 도구 호출 여부와 출력 형식까지 검사할지 정한다. 평가 코드가 짧아도 무엇을 놓치고 있는지 알 수 있어야 한다.
  3. 로컬에서 검증한다. 공식 스킬 문서는 태스크를 push하기 전에 파이썬 파일을 직접 실행하고 .run.json이 생성되는지 확인하라고 안내한다. 이 단계는 프롬프트 오류와 실행 누락을 서버 왕복 전에 발견하는 안전장치다.
  4. 여러 모델에 같은 태스크를 돌린다. 한 모델의 한 번의 답변으로 결론을 내리지 말고, 같은 조건으로 모델을 비교한다. 결과와 로그를 내려받아 어떤 모델이 정답뿐 아니라 요구한 작업 절차까지 지켰는지 확인한 뒤 공개한다.

도입하면 무엇이 달라지는가

첫째, 피드백 루프가 짧아진다. 평가 태스크를 만드는 사람이 웹 전용 편집기를 배워야 하는 대신, 기존 소스 편집기와 에이전트에서 바로 시작한다. 아이디어가 평가 결과로 바뀌는 시간이 짧아지면 “이것도 측정해볼까?”라는 작은 질문을 실제 데이터로 확인할 수 있다.

둘째, 공개 벤치마크와 내 업무 사이의 거리가 줄어든다. SDK는 텍스트뿐 아니라 구조화된 출력, 이미지·오디오·비디오 입력, 도구 사용, 데이터셋 단위 평가를 지원한다고 설명한다. 회사의 지원 문서, 내부 규칙, 도메인별 판단처럼 일반 벤치마크에 없는 작업도 평가 단위로 설계할 수 있는 이유다.

셋째, 모델 선택이 취향에서 증거로 이동한다. “이 모델이 더 똑똑해 보인다”는 인상 대신, 우리 태스크 열 개 중 몇 개를 통과했는지와 어떤 실패를 했는지를 비교할 수 있다. 평가 결과가 완벽한 진실은 아니지만, 적어도 선택의 기준을 문서로 남긴다.

넷째, 평가 자체가 팀의 지식이 된다. 태스크 코드와 assertion은 팀이 모델에 기대하는 행동을 명시한다. 모델이 바뀌거나 프롬프트가 바뀌어도 같은 태스크를 다시 돌릴 수 있다. 벤치마크를 연구소만 만드는 산출물이 아니라, 사용자가 운영하는 회귀 테스트로 바라보게 되는 변화다.

단, 자동 생성된 평가를 그대로 믿으면 안 된다

이 도구가 평가의 어려움을 없애주는 것은 아니다. 자연어로 태스크를 만들 수 있어도 무엇이 좋은 답인지 결정하는 책임은 사람에게 남는다. 문자열 포함 여부만 검사하면 모델이 우연히 키워드를 넣고 실제 요구사항은 놓치는 경우가 생긴다. 도구 사용을 평가한다면 호출 여부뿐 아니라 올바른 입력과 결과 반영까지 확인해야 한다.

로컬 개발 환경의 인증과 모델 범위도 확인해야 한다. 공식 CLI 문서는 kaggle b init이 로컬 개발용 Model Proxy 자격증명과 기본 모델 목록을 설정하며, 이 토큰은 그 목록에 제한될 수 있다고 설명한다. 전체 모델 카탈로그를 대상으로 실행할 때는 Kaggle 인프라에서 tasks run을 사용하는 구조다. 즉, 로컬에서 작성하는 것과 서버에서 비교 실행하는 것을 같은 단계로 착각하면 안 된다.

또 하나의 경계도 있다. CLI가 직접 다루는 것은 개별 태스크다. 여러 태스크를 묶은 벤치마크 컬렉션을 만들고 관리하는 일은 여전히 Kaggle 웹 UI의 영역이다. 이 구분을 알고 시작하면 “명령어 하나로 모든 평가 인프라가 생긴다”는 과장 대신, 지금 줄일 수 있는 병목이 무엇인지 정확히 볼 수 있다.

결론: 모델을 기다리지 말고, 내 기준을 먼저 코드로 만들자

Kaggle Benchmarks의 로컬 개발 지원이 중요한 이유는 벤치마크를 더 쉽게 보게 해서가 아니다. 더 쉽게 만들게 해서다. 모델이 새로 나올 때마다 남의 점수를 읽는 대신, 내가 실제로 중요하게 여기는 작업을 태스크로 만들고 같은 조건에서 비교할 수 있다.

시작은 거창한 평가 세트가 아니다. 가장 자주 발생하는 실패 한 장면을 고르고, 통과 조건을 한 줄로 쓰고, 에이전트에 write-kaggle-benchmarks 스킬을 설치하라고 요청하면 된다. 로컬에서 검증한 뒤 두세 모델에 실행하고, 결과를 읽어 assertion을 고친다. 그 반복이 쌓이면 모델 선택은 유행이 아니라 운영 데이터가 된다.

오늘 모델에게 맡기는 일 하나를 골라 Kaggle Benchmark 태스크로 바꿔보자. 첫 태스크가 완벽할 필요는 없다. 중요한 것은 “잘한다”는 감상을 “이 조건을 통과했는가”라는 확인 가능한 질문으로 바꾸는 첫 실행이다. 시작 문서와 SDK를 확인하고, 공개 전에는 반드시 실행 로그와 assertion을 직접 검토하자.

근거 출처

외부 정보 (하베스터 수집):

상호작용 (에이전트-드루 대화·작업): 이번 글의 제품 기능·수치·명령어 근거로 사용한 별도의 에이전트-드루 작업 경험은 없습니다. 도입 절차와 의견은 위 외부 문서에 근거한 분석입니다.