이제 모델 평가는 점수가 아니라 개발 과정이다

📋 오늘의 3줄 요약

• Ai2가 AI 모델을 바꿀 때마다 성능이 정말 좋아졌는지 확인하는 무료 평가 도구를 공개했어요.
• 전체 점수만 보여주는 게 아니라, 어떤 질문은 좋아졌고 어떤 질문은 나빠졌는지 하나씩 비교해 줘요.
• 우리 제품도 모델을 바꾸기 전에 실제 고객 질문 30~50개로 먼저 시험해 보면 실패를 크게 줄일 수 있어요.

  안녕하세요. 오늘은 “어느 모델 점수가 더 높나”보다 더 현실적인 질문, “우리 제품이 어제보다 정말 좋아졌나”를 확인하는 방법을 이야기해 볼게요.

📌 오늘의 딥다이브 — Ai2가 공개한 반복형 모델 평가 워크벤치 `olmo-eval`

무슨 일이 있었나

Ai2가 대규모 언어 모델 개발 과정에 맞춘 오픈소스 평가 도구 `olmo-eval`을 공개했어요. 완성된 모델을 한 번 줄 세우는 벤치마크가 아니에요. 데이터, 아키텍처, 하이퍼파라미터, 체크포인트가 바뀔 때마다 같은 평가를 다시 돌리고 차이를 분석하는 일상적인 개발 루프를 겨냥했어요. 에이전트와 멀티턴 평가도 처음부터 주요 사용 사례로 다룹니다. 출처

그동안 왜 어려웠나

기존 평가 도구는 대체로 두 극단에 있었어요. 하나는 완성된 모델을 정해진 벤치마크로 비교하는 도구예요. 다른 하나는 격리된 샌드박스에서 도구를 쓰는 에이전트를 평가하는 무거운 시스템이죠. 계속 변하는 모델을 여러 체크포인트에 걸쳐 비교하고, 실제 제품 조건을 조금씩 바꿔 보는 개발 업무에는 빈틈이 있었어요.

Ai2는 2024년 OLMES(Open Language Model Evaluation Standard)를 내놓았어요. 같은 모델과 벤치마크라도 프롬프트 형식과 문제 구성 방식이 달라 점수가 재현되지 않는 문제를 줄이려는 표준이었죠. `olmo-eval`은 여기서 한 걸음 더 나갑니다. 최종 점수의 표준화뿐 아니라 평가를 만들고, 실행하고, 비교하고, 판단하는 전체 과정을 한 작업대로 묶었어요. 출처

디테일에서 봐야 할 것

핵심은 평가 문제와 실행 방식을 분리한 구조예요. `task`는 무엇을 평가할지 정의해요. `suite`는 여러 task를 묶어요. `harness`는 모델 제공자, 도구, 에이전트 실행 틀, 샌드박스, 보조 모델을 포함해 어떻게 실행할지 정합니다. 같은 문제를 일반 채팅 모델과 도구 사용 에이전트에 적용해도 평가 정의를 다시 만들 필요가 없는 거예요.

실행 비용도 구분해요. 단순 질의응답은 컨테이너 없이 가볍게 돌릴 수 있어요. 모델이 작성한 코드를 실행하는 평가처럼 격리가 필요할 때만 Docker나 Modal 방식의 샌드박스를 붙입니다. 모든 평가를 무조건 무거운 컨테이너에 넣지 않으니, 개발 중 자주 반복하기 쉬워져요. 출처

결과를 보는 방식도 중요해요. `olmo-eval`은 전체 평균과 함께 표준오차와 최소 검출 효과(minimum detectable effect, 우연한 흔들림과 구분할 수 있는 최소 차이)를 보여줘요. 두 체크포인트가 같은 질문에 어떻게 답했는지도 문항별로 나란히 비교합니다. 평균이 2.4%포인트 올랐더라도 일부 문제의 큰 상승 때문인지, 전체적인 개선인지, 통계적 잡음인지 따져볼 수 있는 거죠.

왜 중요한가

제품팀이 실패하는 지점은 모델 선택보다 변경 효과를 증명하는 과정인 경우가 많아요. 프롬프트를 고치고, 모델을 바꾸고, 검색 도구를 추가한 뒤 체감상 좋아졌다고 결론 내리기 쉽잖아요. 하지만 평균 점수 하나로는 검색이 좋아진 건지, 추론이 좋아진 건지, 실행 환경이 달라진 건지 알기 어려워요.

이 문제는 데이터 레이크 질의응답 에이전트를 분석한 SANA 연구와도 맞닿아 있어요. 이 연구는 검색, 계획, 데이터 분석, 행동 정책을 따로 제거해 보며 실패 원인을 나눴어요. 두 벤치마크에서 데이터 분석은 일관된 병목이었고, 큰 데이터 레이크에서는 검색도 주요 한계였어요. 에이전트의 최종 정답률만 보면 어느 부품을 고쳐야 할지 놓친다는 뜻이에요. 출처

다음에 볼 것

앞으로 평가 도구의 경쟁은 지원 벤치마크 수보다 제품 개발 루프에 얼마나 자연스럽게 들어가느냐로 옮겨갈 가능성이 커요. `olmo-eval`은 평가 정의, 실행 정책, 샌드박스, 결과 저장 형식을 분리했어요. 덕분에 모델만 바꾸거나 도구만 바꾸면서 나머지 조건을 고정할 수 있습니다.

다만 도구가 좋은 평가셋을 대신 만들어주지는 않아요. 고객이 실제로 묻는 질문과 실패 사례가 빠져 있으면 정교한 통계도 엉뚱한 개선을 증명할 뿐이에요. 다음 단계는 분명합니다. 공개 벤치마크를 더 붙이는 것보다, 실제 제품 로그에서 대표 업무와 치명적인 실패를 고정 평가셋으로 만드는 일이다.

⚡ 빠른 소식

• OpenAI, 기업 도입 파트너에 1억5천만달러 투자 — OpenAI가 글로벌 기업의 AI 도입과 배포를 지원하는 Partner Network를 출범했어요. 출처
• OpenAI, Ona 인수로 Codex의 장기 실행 환경 강화 — 보안이 적용된 영속적 클라우드 환경을 Codex에 더해 기업 워크플로에서 오래 실행되는 에이전트를 지원할 계획이에요. 출처
• Google DeepMind, 멀티에이전트 안전 연구에 최대 1천만달러 지원 — 샌드박스, 에이전트 네트워크, 신원·평판 인프라, 대규모 감독 기술을 우선 연구 분야로 제시했어요. 출처
• Vercel AI SDK 7, Codex·Claude Code·Pi를 같은 API로 실행 — 실험적 `HarnessAgent`가 에이전트 실행 틀의 세션, 샌드박스, 권한, 하위 에이전트를 통합 인터페이스로 다뤄요. 출처
• Kimi K2.7 Code, Vercel AI Gateway에 추가 — 텍스트와 이미지를 받고 항상 thinking 모드로 작동하는 장기 코딩 작업용 모델을 통합 API에서 호출할 수 있어요. 출처
• 부산역에 13개 언어 AI 통역 안내 도입 — 코난테크놀로지의 `링고엑스`가 자체 LLM과 음성인식 엔진으로 도시철도 이용법, 환승 경로, 관광 정보를 안내해요. 출처

🇰🇷 빌더 포인트 — 그래서 오늘 뭘 해야 하나

1. 이번 주 고객 업무 30~50개를 고정하세요. 성공 사례만 고르지 말고 환각, 도구 오작동, 한국어 존댓말 실패처럼 실제로 비용을 만든 사례를 절반 이상 넣으세요. 입력, 기대 결과, 채점 기준을 한 파일에 버전으로 남겨야 해요.
2. 모델과 실행 환경을 따로 비교하세요. 먼저 프롬프트·도구·샌드박스를 고정하고 모델만 바꾸세요. 다음에는 모델을 고정하고 검색기나 에이전트 실행 틀만 바꾸세요. 두 변수를 동시에 바꾸면 개선 원인을 찾을 수 없어요.
3. 평균 점수만 보고 배포하지 마세요. 변경 전후 결과를 문항별로 나란히 보고, 치명적 실패가 새로 생기지 않았는지 확인하세요. 차이가 작다면 표준오차나 최소 검출 효과를 확인하고, 우연한 상승이면 기존 버전을 유지하세요.

오늘의 한 줄: 좋은 모델을 고르는 팀보다 개선을 반복해서 증명하는 팀이 더 빨리 간다.

—
Korean AI Builder Brief · 매일 아침 한국 AI 빌더에게