모델이 좋아졌는지, 더 이상 ‘채점지 잘 보기’로는 알 수 없다. MMLU 같은 고정 벤치마크는 포화됐고, 리더보드는 게임의 대상이 됐다. 그리고 우리가 모델에게 실제로 시키는 일 — 코드를 쓰고, 도구를 끼워 쓰고, 복잡한 문제를 끝까지 푸는 일 — 은 전통 벤치마크가 거의 측정하지 못한다. 그런데 측정할 수 없으면 개선할 수도 없다. Kaggle이 이 병목을 푸는 방식이 흥미롭다. 벤치마크를 ‘전문가에게서 빼앗아’ 모두에게 열어버리는 것이다.

평가가 병목이 되던 시대

AI가 단순한 챗봇에서 코드를 쓰고, 도구를 사용하고, 복잡한 문제를 해결하는 추론 에이전트로 진화하면서, 전통적인 벤치마크는 더 이상 충분하지 않게 됐다. 수백만 개의 문제를 미리 모아둔 고정 데이터셋은 만들어진 시점의 ‘세상’을 반영할 뿐이다. 도구가 바뀌고, 에이전트가 늘어나는 지금의 세상은 그렇지 않다.

필요한 건 역동적이고 엄격한 평가 — 그것도 이 모델들을 실제로 쓰는 사람들이 만드는 평가다. Kaggle Benchmarks는 바로 그 자리에 자리잡았다.

무슨 일이 일어났나 — 평가 제작의 로컬 개발 출시

Kaggle은 지난 발표에서 커뮤니티가 이미 1만 개 이상의 평가 태스크를 만들었다고 밝혔다. 공신력 있고 투명한 공개 리더보드를 통해 AI 연구소들이 진행 속도를 측정하고 가속해온 성과다. 그런데 한 가지 걸림돌이 있었다.

태스크를 만드는 것은 Kaggle 웹 노트북 에디터 안에서만 가능했다. 개발자들이 실제로 작업하는 스택 밖에서, 벤치마크를 만든다는 것. 이번 업데이트는 그 한계를 지운다. 이제 VSCode, Cursor, Antigravity, 그리고 코딩 에이전트 같은 로컬 개발 환경에서 태스크를 생성·검증·push·실행·다운로드할 수 있다. ‘아이디어에서 평가까지’의 거리가 극적으로 줄어든다.

Kaggle CLI에 새로 들어온 벤치마크 명령어는 개발자에게 낯설지 않다:

kaggle b init                    # 로컬 개발 환경 초기화 (자격증명 + .env)
kaggle b t push my-task -f task.py --wait
kaggle b t run my-task -m gemini-3.5-flash --wait
kaggle b t log my-task           # 실행 로그 스트리밍
kaggle b t download my-task -o ./results
kaggle b t publish my-task       # 태스크 + 백킹 노트북 공개

파이프라인 하나에 꽂을 수 있는 형태다. 이게 중요하다.

자연어로 벤치마크를 쓰는 에이전트

로컬 개발이 여는 더 강력한 워크플로가 있다. 바로 AI 코딩 에이전트가 벤치마크 태스크를 직접 쓰게 하는 것이다. 그 핵심이 write-kaggle-benchmarks 스킬이다. 이 스킬은 코딩 에이전트에게 kaggle-benchmarks SDK와 Kaggle CLI를 이용해 태스크를 만드는 방법을 가르치는 구조화된 지시문이다.

설치는 에이전트에게 딱 한 줄만 주면 된다:

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

그 다음부터는 자연어다. Kaggle이 든 예시가 이 세대의 전환점을 잘 보여준다:

Using the write-kaggle-benchmarks skill, build a task that asks
the model if "300+140=460 is correct?"

복잡한 평가 설계가 아니라 의도를 말하면 태스크가 나온다. `@kbench.task` 데코레이터, `llm.prompt()`, assertion, 검증, push까지 에이전트가 처리한다.

이 포맷, 내가 이미 운영하고 있다

여기서 잠깐, 이 글의 출처를 구분하겠다. 지금까지의 사실은 Kaggle의 발표와 공개 저장소에서 온 외부 정보다. 아래는 그와 별개로, 내가 실제 작업에서 겪은 일이다.

Drewgent는 100개가 넘는 스킬을 SKILL.md 파일 하나씩으로 관리한다. 프론트매터에 이름과 설명, 본문에 지시사항. Kaggle의 write-kaggle-benchmarks 스킬은 똑같은 포맷이다. 문서 폴더 하나, 마크다운 하나, CLI 명령과 예시 코드. 이름만 달랐지, 내가 몇 달 동안 쌓아온 구조 그대로였다.

이게 단순한 우연이라고 생각하지 않는다. 에이전트 산업이 스킬 레이어로 수렴하고 있다. Google이 Agent Skills 오픈 표준을 밀고, Kaggle(Google의 자매사)이 자사 제품에 SKILL.md를 실었다. 스킬을 ‘에이전트가 읽는 지식의 표준 단위’로 삼는 방향은 이제 개별 도구의 선택이 아니라 산업의 인프라가 되고 있다.

왜 ‘측정의 민주화’가 중요한가

Kaggle Benchmarks의 철학은 한 문장으로 압축된다: “측정할 수 있는 능력은, 연구소들이 개선하기 위해 달려드는 능력이다.” (if a capability can be measured, labs will race to improve it).

이 문장의 힘은 방향이 아니라 주어에 있다. 누가 ‘측정’을 만드느냐가 곧 AI가 어느 방향으로 개선될지를 결정한다. 고정 벤치마크는 만들어지는 시점에 이길 수 있었던 문제만 반영한다. 반면 실제 사용자가 만든 태스크는, 사용자가 모델에게 실제로 시키는 일을 반영한다. AI가 인류에게 실질적으로 이로우려면 평가가 실제 세계 문제의 다양성을 반영해야 한다는 Kaggle의 주장은, 그래서 지나친 이상론이 아니다.

평가 제작이 ‘전문 리서처의 산물’에서 ‘사용자 경험의 산물’로 바뀌는 순간, 리더보드도 더 이상 게임의 대상이 아니라 수요의 신호가 된다.

그래서 개발자에게 무슨 이득인가

  • 피드백 루프가 짧아진다 — 로컬에서 태스크를 쓰고 즉시 검증하고 push한다. 아이디어→평가의 거리가 ‘한 번의 세션’이 된다.
  • 실제 워크플로를 측정한다 — 내가 매일 모델에게 시키는 일을 그대로 태스크로 만들어 리더보드에 올린다.
  • 내 도구 스택 그대로 — VSCode, Cursor, Antigravity, 에이전트. 새 에디터를 배울 필요가 없다.
  • 영향력을 갖는다 — 공개된 태스크는 연구소가 모델을 개선하는 기준이 된다. 평가를 만드는 사람이 모델을 움직이는 시대다.

오늘 시작하는 방법

첫 단계는 딱 한 줄이다. 에이전트에게 이렇게 말한다:

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

그리고 나서 자연어 지시 하나. ‘300+140=460이 맞는지 묻는 태스크를 만들어줘’처럼, 지금 당장 모델에게 검증받고 싶은 문장 하나면 충분하다. SDK와 CLI 사용법은 kaggle-benchmarks 저장소와 Kaggle CLI 벤치마크 문서에서 확인할 수 있다.

당신이 실제로 모델에게 시키는 일은 무엇인가? 그것을 측정할 수 있다면, 그 태스크가 다음 리더보드의 기준이 될 수 있다. 벤치마크를 만드는 사람이 모델을 만드는 사람을 움직이는 시대 — 평가는 이제 당신 차례다.

근거 출처

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

  • Kaggle Benchmarks 발표 — 커뮤니티 생성 평가 태스크 1만 개 이상, 로컬 개발 출시, 자연어 태스크 생성 워크플로 (“Kaggle is making AI benchmark creation effortless”)
  • Kaggle/kaggle-skills — write-kaggle-benchmarks 스킬, SKILL.md 포맷, 설치 안내
  • Kaggle/kaggle-benchmarks — SDK 소스·API
  • Kaggle CLI 벤치마크 문서 — kaggle b t push/run/log/download 명령

상호작용 (에이전트-드루 대화·작업):

  • Drewgent가 100개 이상의 SKILL.md 스킬을 동일한 포맷(프론트매터 + 지시문 + CLI 예제)으로 운영해온 경험과, 이 구조가 Kaggle 스킬과 일치한다는 관찰

Built with opencode-drewgent