모델이 업데이트된다는 공지가 올라올 때마다 우리는 같은 실수를 반복한다. “확실히 좋아졌네”라고 체감하고, 일주일 뒤 지난주에 잘 돌던 프롬프트가 이상한 답을 주는 걸 발견하고, “아 그 버전이 문제였나?” 하고 뒤적거린다. 체감은 통계가 아니다. 그런데 우리는 오랫동안 그 체감 하나로 모델을 판단해왔다. 그 모델이 우리 업무의 절반을 담당하고 있으면서.

그래서 이 글은 Kaggle의 기능 발표 소개가 아니라, 하나의 주장을 하려고 쓴다: 벤치마크는 더 이상 ‘AI 연구소가 리더보드에 올리려고 만드는 것’이 아니라, 당신이 매일 의존하는 모델에 대한 회귀 테스트다. 그리고 벤치마크 제작이 자연어 한 줄이 된 지금, 그것을 안 만들 이유가 사라졌다.

측정할 수 없으면, 개선할 수도 없다

AI가 단순한 챗봇에서 코드를 쓰고, 도구를 조작하고, 복잡한 문제를 끝까지 푸는 추론 에이전트로 진화하면서 전통적인 벤치마크는 힘을 잃었다. 미리 모아둔 고정 데이터셋은 만들어진 시점의 세상만 반영한다. 도구가 매주 바뀌고, 에이전트가 늘어나는 지금의 세상은 그렇지 않다. 리더보드는 정답을 많이 맞힌 모델 순서대로 줄을 세우지만, 정작 우리가 모델에게 시키는 일은 그 정답 목록 밖에 있다.

Kaggle Benchmarks는 바로 그 지점을 겨냥했다. “측정할 수 있는 능력은, 연구소들이 개선하기 위해 달려드는 능력이다” — Kaggle이 이 서비스를 시작하며 내세운 문장이다. 출시 이후 커뮤니티가 만든 평가 태스크는 1만 개 이상에 이른다. 공개 리더보드라는 투명한 신호를 통해 AI 연구소들이 모델 개선의 방향을 맞추는 구조다. 평가가 많아질수록, 실제 사용자가 원하는 방향으로 모델이 움직인다는 논리다.

외부 정보 — 벤치마크 제작이 ‘개발자의 스택’으로 들어왔다

여기까지가 Kaggle의 발표에서 온 외부 정보다. 핵심 변화는 두 가지로 요약된다.

첫째, 로컬 개발 지원. 그동안 평가 태스크는 Kaggle의 웹 노트북 에디터 안에서만 만들 수 있었다. 개발자들이 실제로 일하는 환경이 아니다. 이번 업데이트로 VSCode, Cursor, Antigravity, 그리고 코딩 에이전트 같은 로컬 개발 환경에서 태스크를 생성·검증·push·실행·다운로드할 수 있게 됐다. ‘아이디어에서 평가까지’의 거리가 한 번의 개발 세션으로 줄어든다.

둘째, 자연어로 태스크를 쓰는 에이전트. write-kaggle-benchmarks라는 스킬이 Kaggle CLI와 SDK를 이용해 벤치마크 태스크를 만드는 방법을 코딩 에이전트에게 가르친다. 에이전트에 한 줄만 던지면 설치된다:

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?"

평가 설계서를 쓰는 게 아니라 의도를 말하면 태스크가 나온다. 채점 로직, assertion, 검증, push까지 에이전트가 처리한다. 벤치마크 제작의 진입장벽이 ‘AI 평가 전문가 수준’에서 ‘말할 줄 아는 개발자 수준’으로 내려간 것이다.

상호작용 — 벤치마크가 진짜 결함을 잡는 순간을 본 적이 있는가

지금부터는 Kaggle과 무관한, 내가 운영하는 시스템에서 겪은 상호작용이다. 왜 벤치마크를 ‘남의 리더보드용’이 아니라 ‘내 워크플로의 안전망’으로 봐야 하는지, 그 이유를 여기서 확신하게 됐다.

내가 만든 에이전트 시스템은 수만 개의 관찰 기록을 SQLite에 저장하고 검색한다. 한 번은 검색 성능을 개선하는 작업이 있었다. 두 검색 엔진을 같은 데이터로 비교하는 벤치마크 스크립트를 돌렸다. 기준 엔진의 재현율(recall@1)은 0.628이었고, 하이브리드 검색을 얹은 엔진이 그것을 넘어서는지가 관전 포인트였다.

벤치마크가 잡아낸 것은 그 비교 결과가 아니었다. 데이터를 마이그레이션한 뒤 스크립트가 “아카이브에 엔티티 5개가 있는데 이식된 것은 0개”라고 보고했다. 조용한 데이터 유실이었다. 에러도, 경고도 없었다. 그냥 아무도 물어보지 않으면 발견되지 않았을 5개의 사라진 엔티티. 벤치마크는 비교가 아니라, 그 숫자를 보여줬기 때문에 문제를 드러냈다.

이 경험이 내 판단을 바꿨다. “잘 작동하는 것처럼 보이는 시스템”과 “검증된 시스템”의 차이는 측정의 유무다. 측정을 쌓아두지 않으면, 나는 그 데이터 유실을 “어디선가 조용히 벌어진 무언가”로 평생 넘겼을 것이다. 그리고 이건 AI 평가에서도 똑같다. 모델이 업데이트되고, 프롬프트가 조금 바뀌고, 라이브러리가 버전업되면 — 나는 매번 그 유실 같은 회귀(regression)를 체감으로만 흘려보내 왔다.

그래서 무엇이 달라지는가 — 평가가 ‘산출물’에서 ‘습관’이 된다

벤치마크 제작이 자연어 한 줄이 되면서 생기는 변화는 단순한 편의가 아니다. 평가의 단위 비용이 회귀 테스트 하나 쓰는 수준으로 떨어지면, 평가는 ‘연구소의 산출물’에서 ‘개발자의 습관’으로 격이 바뀐다.

유닛 테스트가 “코드는 이래야 한다”는 계약을 코드로 박아두는 것처럼, 벤치마크 태스크는 “내 워크플로의 이 일은 모델이 이렇게 해야 한다”는 계약을 박아둘 수 있다. 지금 당장 나에게 유용한 건 Kaggle의 공개 리더보드가 아니라, 이 두 가지다:

  • 내가 매일 시키는 일의 회귀 테스트 — “요약은 반드시 한국어로”, “표는 깨지지 않게”, “출처는 언제나 남기고”. 모델이 바뀔 때마다 태스크를 다시 돌리면, ‘체감’이 아니라 숫자로 ‘나아졌다/나빠졌다’를 안다.
  • 두 모델을 내 기준으로 비교하는 방법 — 벤치마크 스크립트가 두 검색 엔진을 같은 데이터로 줄 세웠듯, 내 업무 데이터로 두 모델을 줄 세우면 리더보드 순위는 더 이상 정보가 아니다. 내 데이터에서의 순위만이 정보가 된다.

Kaggle의 문장 — “AI가 인류에게 실질적으로 이로우려면 평가가 실제 세계 문제의 다양성을 반영해야 한다” — 는 사실 개발자 개인에게 그대로 내려쓸 수 있다. 당신이 모델에게 시키는 일이 평가로 반영되지 않으면, 그 일이 개선될 이유가 없다. 측정은 방향을 만들고, 방향은 개선을 만든다. 이건 AI 연구소만의 원리가 아니라, 당신의 워크플로에도 그대로 작동하는 원리다.

오늘 시작하는 두 줄

첫 단계는 에이전트에 한 줄을 던지는 것이다:

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

그 다음, “지금 내가 매일 모델에게 시키는 일 중 가장 자주 하는 것 하나”를 자연어로 태스크로 만들면 된다. 검증이 필요한 문장 하나면 충분하다. ‘300+140=460이 맞는지 묻는 태스크’ 같은 수준에서 시작해도, 모델이 업데이트될 때마다 그 태스크는 당신의 안전망으로 작동한다.

벤치마크는 남이 만든 시험지가 아니라, 내가 의존하는 것에 대한 계약서다. 그리고 그 계약서를 쓰는 비용이 자연어 한 줄로 내려온 지금, “안 만들 이유”가 없어졌다. 당신이 매일 모델에게 시키는 일 하나 — 그것부터 태스크로 만들어보는 걸 권한다. 측정해본 순간, 당신은 이제까지 그 일을 ‘체감’으로만 관리하고 있었다는 걸 알게 될 것이다.

근거 출처

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

  • Kaggle Benchmarks 발표 — 커뮤니티 생성 평가 태스크 1만 개 이상, 로컬 개발 출시(Antigravity·VSCode·Cursor·코딩 에이전트에서 생성·검증·push·실행·다운로드), 자연어 태스크 생성 워크플로, “측정할 수 있는 능력은 연구소들이 개선하기 위해 달려드는 능력” 인용, 평가가 실제 세계 문제의 다양성을 반영해야 한다는 주장 (“Kaggle is making AI benchmark creation effortless”)
  • Kaggle/kaggle-skills — write-kaggle-benchmarks 스킬 설치 안내, 자연어 태스크 생성 예시

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

  • Drewgent drew.db 검색 벤치마크 — 기준 엔진 recall@1 0.628, 하이브리드 검색 비교
  • 데이터 마이그레이션 후 벤치마크가 “아카이브 엔티티 5개, 이식 0개”를 감지 — 무증상 데이터 유실을 벤치마크가 발견한 경험
  • 동일 데이터로 두 검색 엔진을 비교하는 evaluation harness 운영 — 숫자로 논쟁을 종결한 경험

Built with opencode-drewgent