AI 평가(evals)는 망가졌지만, 빌더들에게는 여전히 필요합니다

2026년 AI에 관한 불편한 진실은 데모(demo)는 점점 쉬워지는 반면, 측정(measurement)은 점점 어려워지고 있다는 점입니다. 모델이 세련된 벤치마크(benchmark)를 통과하고 아름다운 제품 영상을 만들어낼 수는 있지만, 정작 여러분의 팀이 매주 화요일 아침마다 실제로 필요로 하는 지루한 작업에서는 실패할 수 있습니다.

이것이 바로 현재 AI 평가(evals)를 둘러싼 논의가 중요한 이유입니다. 지난 48시간 동안 Hacker News에는 AI가 측정 문제(measurement problem)를 겪고 있다고 주장하는 직설적인 에세이가 떠올랐습니다. Google News 또한 평가(evals)가 망가졌지만 여전히 필수적이라는 새로운 논의를 보여주었으며, Hugging Face는 최근 세 가지 도메인에 걸쳐 121개의 도구 사용(tool-use) 시나리오를 포함한 EVA-Bench Data 2.0을 강조했습니다. 신호는 명확합니다. 빌더들은 리더보드(leaderboard) 점수만으로는 충분하지 않다는 것을 깨닫고 있습니다.

제 생각은 간단합니다. 평가(evals)는 마법 같은 진실 기계가 아닙니다. 그것은 안전벨트입니다. 평가(evals) 그 자체만으로는 여러분의 AI 시스템을 안전하거나 신뢰할 수 있거나 유용하게 만들 수는 없지만, 평가(evals) 없이 제품을 출시하는 것은 사용자들에게 여러분의 QA(품질 보증) 부서가 되어달라고 요구하는 것과 같습니다.

벤치마크 점수가 이제 덜 유용하게 느껴지는 이유

전통적인 벤치마크(benchmarks)는 질문이 주로 "어떤 모델이 알려진 작업에서 더 똑똑한가?"였을 때 유용했습니다. 그 질문은 여전히 중요하지만, 더 이상 게임의 전부가 아닙니다. 현대의 AI 제품은 결정의 사슬(chains of decisions)입니다. 적절한 컨텍스트(context)를 검색하고, 적절한 도구(tool)를 호출하며, 정책을 따르고, 출력을 작성하고, 실수로부터 회복하며, 언제 멈춰야 할지를 아는 과정입니다.

단일 모델 점수는 여러분의 고객 지원 봇이 정확한 환불 정책을 인용할지 알려주지 않습니다. 여러분의 코딩 어시스턴트가 복잡한 리포지토리(repo)에서 올바른 파일을 수정할지 알려주지 않습니다. 여러분의 내부 에이전트(agent)가 사용자가 단지 미리보기만을 원했을 때 파괴적인 도구(destructive tool)를 호출할지 알려주지 않습니다.

이 지점에서 많은 팀이 속습니다. 그들은 공개 리더보드(leaderboard)에서 두 모델을 비교하고, 승자를 프로덕션(production)에 교체 투입한 다음, 왜 고객 지원 티켓이 급증하는지 의아해합니다. 벤치마크(benchmark)가 가짜였던 것이 아닙니다. 단지 제품이 필요로 하는 것보다 더 좁은 질문에 답하고 있었을 뿐입니다.

실제 제품을 위한 유용한 평가(evals)의 모습

좋은 평가(evals)는 지루할 정도로 실제 작업과 밀접해야 합니다. 만약 교회 행정팀을 위한 AI 어시스턴트(AI assistant)를 구축하고 있다면, 실제 워크플로우(flows)를 테스트하세요: 회의 요약하기, 자원봉사자 메시지 초안 작성하기, 지저분한 공지사항에서 날짜 추출하기, 그리고 개인 구성원의 세부 정보를 노출하는 것을 거부하기 등입니다. 만약 개발자 도구(developer tool)를 구축하고 있다면, 실제 저장소(repositories), 실제 스타일 규칙(style rules), 실제 실패하는 테스트(failing tests), 그리고 실제 롤백(rollback) 동작을 테스트하세요.

실용적인 평가 스위트(eval suite)는 보통 세 가지 계층을 포함해야 합니다:

작업 성공 (Task success): 시스템이 사용자가 요청한 작업을 완료했는가?
제약 조건 준수 (Constraint following): 규칙, 권한, 톤(tone), 예산 및 도구 제한 사항을 준수했는가?
실패 동작 (Failure behavior): 불확실할 때 질문을 했는가, 중단했는가, 에스컬레이션(escalate)했는가, 아니면 답변을 지어냈는가?

마지막 계층은 과소평가되어 있습니다. 크게 실패하며 안전하게 작동하는 모델이, 워크플로우(workflow)를 조용히 망가뜨리면서 자신감 있게 들리는 모델보다 훨씬 더 유용할 때가 많습니다.

평가를 보여주기식 행위로 만들지 마세요

위험 요소는 평가(evals)가 하나의 의식(ritual)이 될 수 있다는 점입니다. 팀이 몇 개의 골든 프롬프트(golden prompts)를 추가하고, 초록색 체크 표시를 받은 뒤, 그것을 증거처럼 취급하는 것입니다. 그것은 측정(measurement)이 아닙니다. 그것은 장식(decoration)일 뿐입니다.

만약 평가 세트(eval set)가 전혀 변하지 않는다면, 시스템은 결국 그것에 과적합(overfit)될 것입니다. 만약 평가자(judges)가 모호하다면, 점수는 표류(drift)할 것입니다. 만약 해피 패스(happy paths)만을 테스트한다면, 당신의 제품은 사용자가 가장 스트레스를 받는 바로 그 지점에서 무너질 것입니다. 목표는 평가 대시보드(eval dashboard)를 갖는 것이 아닙니다. 목표는 고객이 발견하기 전에 추한 실패를 찾아내는 것입니다.

유용한 습관 중 하나는 매주 프로덕션(production) 환경의 사례를 추가하는 것입니다. 혼란스러운 사용자 프롬프트, 잘못된 모델 응답, 도구 호출(tool-call) 실수, 그리고 고객 지원 에스컬레이션(support escalations) 사례를 가져와서 회귀 테스트(regression tests)로 만드세요. 시간이 흐름에 따라, 당신의 평가 스위트(eval suite)는 당신의 제품이 고생하며 배운 것들에 대한 기억이 됩니다.

빌더들이 이번 주에 해야 할 일

아직 평가(evals) 체계가 없다면, 작게 시작하세요. 실제 사용자의 의도(user intent)에서 20개의 예시를 선정하세요. 쉬운 프롬프트, 일반적인 프롬프트, 엣지 케이스(edge-case), 그리고 악의적인(malicious) 프롬프트를 골고루 포함하세요. 모델을 실행하기 전에 무엇이 좋은 답변인지 미리 적어두세요. 그런 다음 현재 모델의 출력값과 대안 모델의 출력값을 비교하세요.

완벽한 점수를 쫓지 마세요. 신뢰를 잃게 만들 실패 사례들을 찾아내야 합니다. 잘못된 인용(wrong citations), 사실 왜곡(invented facts), 안전하지 않은 도구 사용(unsafe tool use), 지시사항 무시(ignored instructions), 잘못된 개인정보 판단(bad privacy judgment), 또는 듣기에는 좋지만 실제 작업은 건너뛰는 응답 등이 이에 해당합니다.

이미 평가 체계를 갖추고 있다면, 그것이 여전히 제품과 일치하는지 점검하세요. 많은 평가 스위트(eval suites)가 프로토타입 제작 주간에 만들어진 후 잊혀지곤 합니다. 당신의 제품이 변했습니다. 당신의 사용자가 변했습니다. 당신의 모델이 변했습니다. 당신의 평가 체계도 변해야 합니다.

실질적인 결론

AI 평가(evals)는 지도가 불완전한 것과 같은 방식으로 망가져 있습니다. 지도는 무언가를 누락하고, 시대에 뒤처지며, 잘못된 자신감을 줄 수 있습니다. 하지만 그 해결책이 눈을 감고 운전하는 것은 아닙니다. 해결책은 더 나은 지도를 사용하고, 자주 업데이트하며, 여전히 도로에 시선을 고정하는 것입니다.

개발자들에게 승리하는 패턴은 "벤치마크(benchmark)를 신뢰하라"도, "벤치마크를 무시하라"도 아닙니다. 그것은 다음과 같습니다: 첫 번째 필터로 공개 벤치마크를 사용하고, 실제 의사결정에는 제품 특화 평가(product-specific evals)를 사용하며, 실패가 치명적인 지점 근처에는 항상 인간의 검토(human review)를 유지하는 것입니다.

다음 세대의 AI 제품은 단순히 가장 최신 모델을 먼저 연결하는 팀이 승리하지 않을 것입니다. 모델이 실제로 도움이 되고 있는지를 측정할 수 있는 팀이 승리할 것입니다.

참고 문헌

원문은 https://blog.jenuel.dev/blog/ai-evals-are-broken-but-builders-still-need-them에 게시되었습니다.