Evals Are Broken, Use Them Anyway — Ara Khan (Cline)
📺 원본 영상: Evals Are Broken, Use Them Anyway — Ara Khan, Cline 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-06-07 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 강연은 AI 코딩 에이전트 플랫폼 Cline의 엔지니어 Ara Khan이 AI Engineer 컨퍼런스에서 발표한 세션으로, 제목 그대로 “Eval은 부서져 있지만, 그래도 사용해야 한다”는 역설적 메시지를 담고 있다. 강연자는 현재 AI 업계에서 eval(평가 지표)을 다루는 두 가지 극단적인 접근 방식 모두가 잘못되었음을 지적하면서, 실제로 에이전트 성능을 개선하기 위해 eval을 어떻게 설계하고 해석하며 활용해야 하는지를 Cline의 실전 경험을 통해 설명한다. 특히 단순 LLM 평가와 달리 에이전트 평가가 근본적으로 어려운 이유, 그리고 TerminalBench와 Harbor 같은 실전 인프라를 활용한 힐 클라이밍(hill climbing) 전략이 핵심 내용을 이룬다.
Eval에 대한 두 가지 함정
AI 개발 생태계에서 eval을 둘러싼 논쟁은 오래됐지만, Ara Khan은 이 논쟁이 대부분 두 가지 극단 중 하나에 치우쳐 있다고 진단한다. 첫 번째는 “객관적 지표 절대주의” 진영이다. 이 진영의 사람들은 벤치마크 리더보드를 보면서, 수치가 비슷하게 나오는 두 모델이 실질적으로 동등하다고 해석한다.
01:48 - 여러 AI 모델의 점수를 비교한 리더보드 대시보드 화면. 서로 다른 모델들이 유사한 수치를 나타내는 예시
실제로 써보면 느낌이 전혀 다른 모델들이 리더보드에서 비슷한 숫자를 내는 경우는 비일비재하다. 강연 당일 아침에도 Meta가 벤치마크 점수를 내세우며 자사 모델의 우수성을 홍보하는 트윗이 화제가 됐는데, 강연자는 이를 “전형적인 벤치마크 맥싱(benchmark maxing)“이라고 일갈한다. 다수의 모델을 직접 사용해보면 실세계의 검증을 견디지 못하는 경우가 많다는 것이 그의 주장이다.
두 번째 함정은 정반대 방향이다. “바이브(vibes) 절대주의” 진영, 즉 완전히 주관적인 감각에만 의존하는 사람들이다. 이 부류는 “왜 Claude Opus를 선호하나요?”라는 질문에 “그냥 그 모델이랑 대화하는 게 좋아요”라고 답하거나, 모델을 의인화하며 인상에 기반해 평가한다. 강연자는 이 역시 옳지 않다고 말한다. 진실은 그 사이 어딘가에 있다. Eval은 전부도 아니고 완전히 쓸모없는 것도 아니다. 핵심은 eval을 어떻게 올바르게 설계하고, 해석하고, 활용하느냐의 문제다.
Eval을 제대로 읽는 세 가지 휴리스틱
그렇다면 eval을 현명하게 활용하려면 어떻게 해야 할까? Ara Khan은 세 가지 실용적인 휴리스틱을 제시한다.
첫 번째 휴리스틱: 모델 회사의 eval 수치를 그대로 믿지 마라. 모델 회사들이 발표하는 벤치마크 결과는 어디까지나 근사치(approximation)에 불과하다. AI 연구자나 엔지니어들 사이에서는 이미 널리 알려진 사실이지만, 발표 수치를 그대로 받아들이는 문화가 여전히 만연하다. 강연자는 한 AI 연구자의 트윗을 인용하면서, 많은 AI 연구자와 엔지니어들이 eval 수치를 그다지 진지하게 받아들이지 않으며, 실제로 써보는 경험과 개인 선호도가 더 중요한 판단 근거가 된다고 말한다. 어느 정도는 사실에 가까운 지적이라고 강연자는 동의한다.
두 번째 휴리스틱: 최신 트렌드를 따르되, 얼리어답터가 될 필요는 없다.
04:38 - 지난 2년간 frontier 모델들의 벤치마크 집계 점수 변화 추이를 보여주는 차트(Epoch Index 혹은 유사한 모델 종합 지수)
지난 2년간 frontier 모델이 몇 달에 한 번씩 바뀌는 속도를 보면, 최전선의 모델을 항상 쫓는 것은 사실상 불가능하다. 강연자 본인도 수년간 이 일을 해오면서 모델 선호가 계속 바뀐다고 고백한다. 그가 권하는 전략은 간단하다. 새 모델이 나왔을 때 바로 달려들지 말고, 한두 주 정도 지켜보라는 것이다. 초반의 소란이 가라앉고도 해당 모델이 여전히 좋다는 평가가 이어진다면, 그때 마이그레이션을 검토해도 늦지 않는다. 항상 최신 모델을 써야 한다는 강박은 프로덕션 환경에서 오히려 불안정성을 초래할 수 있으며, 이를 직업으로 삼지 않는 이상 최첨단을 항상 쫓을 이유는 없다.
세 번째 휴리스틱: 새롭고 정밀한 eval을 찾아라. 이미 표준화된 eval 벤치마크들은 대부분 오래됐기 때문에 현재의 frontier 모델을 제대로 평가하지 못한다. 이에 대한 가장 명확한 사례가 SWE-bench Verified다.
05:43 - OpenAI 블로그 포스트 화면. SWE-bench Verified가 더 이상 frontier 코딩 능력을 측정하지 못한다고 명시한 내용
OpenAI가 공식적으로 “SWE-bench Verified는 더 이상 frontier 코딩 능력을 측정하지 못한다”고 선언했을 때, AI 연구 커뮤니티의 많은 이에게는 새삼스러운 일이 아니었다. 피보나치 수열 구현이나 행렬 곱셈 같은 문제가 실제 소프트웨어 엔지니어링 업무를 대표하지 못한다는 것은 이미 자명했기 때문이다. 따라서 좋은 eval을 찾으려면 최근에 만들어진 것이어야 하며, 동시에 실제 문제를 반영하는 정당한(legit) 것이어야 한다. 이 두 조건을 동시에 충족하는 eval을 가려내는 것은 경험에서 우러난 판별력(discernment)이 필요한 작업이다.
Cline의 Eval 도전기: 아무도 안 하면 우리가 한다
Cline은 오픈소스 코딩 에이전트 회사다. 약 1년 전, Cline 팀은 근본적인 문제에 직면했다. 당시 시장에 나와 있는 코딩 에이전트용 eval은 극히 드물었고, 있더라도 실제 프로그래밍 작업을 제대로 반영하지 못했다. Codex 팀을 비롯한 여러 팀들도 마찬가지 결론에 도달해 있었다. “표준화된 eval이 거의 없고, 있더라도 효과가 없다. 바이브로 충분하다. Eval은 시간 낭비다.” 그것이 당시 업계의 지배적인 분위기였다.
그러나 Cline 팀은 방향을 틀었다. 표준화된 eval이 없고 효과적이지도 않다면, 직접 만들면 된다는 결론에 이른 것이다. 이들은 사용자들이 동의하에 공유한 방대한 코딩 사용 데이터셋에서 출발했다. 사람들이 실제로 어떤 문제를 풀고 있는지를 파악하기 위해 데이터를 파싱하고, 정제하고, 노동 집약적인 수작업으로 클린업하는 과정을 거쳤다. 그 결과 Cline이나 다른 코딩 에이전트로 실제로 풀 수 있는 현실적인 프로그래밍 문제 세트를 구축했다. 이 과정은 단순히 데이터를 모으는 것이 아니라, “이 문제가 진짜 개발자의 일상과 얼마나 가까운가”를 끊임없이 검증하는 철학적 작업이기도 했다.
에이전트 평가의 본질적 어려움
eval을 구축하면서 Cline 팀이 맞닥뜨린 핵심 난관은 에이전트 평가가 단순 LLM 평가와 근본적으로 다르다는 점이었다. 단일 턴(single-turn) 평가는 비교적 간단하다. “고양이의 발가락은 몇 개인가?”라고 물으면 LLM이 답을 내고, 그 답이 맞는지 틀리는지를 확인하면 된다. 답의 공간이 제한되어 있고, 이진(binary) 판단이 가능하다.
에이전트는 완전히 다른 얘기다. 예를 들어 “내 MCP 서버가 동작하지 않는데 고쳐줘”라는 프롬프트를 에이전트에 던지면, 에이전트는 파일을 읽고, 문서를 검색하고, 환경을 설치하고, Python 스크립트를 실행하고, 테스트를 돌리는 등 수십 가지 작업을 순차적으로 수행한다. 강연자는 Claude Code나 다른 에이전트를 쓸 때 이런 방식으로 프롬프트를 입력하는 것이 일반적이라고 짚는다. 이 과정에서 판단해야 할 것은 단순히 “최종 결과물이 맞는가”가 아니다. 과정이 올바른가, 부수적으로 다른 것을 망가뜨리지는 않았는가, 비효율적인 경로를 택하지는 않았는가까지 따져야 한다. 에이전트 평가는 탐색 공간 자체가 거의 무한에 가깝기 때문에, 의미 있는 eval을 설계하는 것이 근본적으로 어려울 수밖에 없다.
TerminalBench와 Harbor: 실전 평가 인프라 구축
이러한 어려움을 해결하는 데 큰 도움이 된 것이 Stanford 연구자들이 개발한 TerminalBench다. TerminalBench는 89개의 실제 코딩 문제로 구성된 평가 스위트로, 레이스 컨디션(race condition), 데이터베이스 이슈, 인프라 문제 등 실제 로우레벨 프로그래밍 업무를 반영한 문제들로 구성된다. 중요한 것은 이 벤치마크가 CLI 기반 코딩 에이전트라면 어떤 것과도 호환 가능하도록 설계되었다는 점이다. 각 태스크는 완료에 30~40분이 걸리는 경우도 있는데, 강연자는 이것이 오히려 “진짜 문제”라는 신뢰할 수 있는 지표라고 말한다. 에이전트가 순환 논리에 빠지거나 여러 방향을 헤매는 것 자체가 테스트의 일부이기 때문이다.
10:19 - TerminalBench의 89개 실제 프로그래밍 문제 구성 및 평가 스위트 구조 설명 슬라이드
TerminalBench와 함께 사용되는 Harbor는 eval 실행 인프라 측면에서 핵심적인 역할을 담당한다. Harbor를 쓰지 않는다면 89개의 태스크를 순서대로 하나씩 실행해야 한다. 각 태스크마다 가상 환경을 설정하고, 에이전트를 설치하고, 문제를 실행한 다음 결과를 기록하는 과정이 반복된다. Harbor는 이 문제를 인프라 정의의 표준화로 해결한다. 각 태스크마다 적절한 Linux 머신, RAM, CPU를 갖춘 격리 환경을 정의해두면 89개의 태스크가 병렬로 동시에 실행된다. 이 경우 전체 실행 시간의 병목은 가장 느린 단일 태스크가 된다. Cline 팀은 이 인프라를 Modal(클라우드 컴퓨팅 플랫폼) 위에서 운영했으며, 대안으로 Daytona나 충분한 컴퓨팅 자원을 갖춘 자체 Docker 머신 등도 활용할 수 있다.
무엇을 평가하는가: 세 가지 레이어
eval 실행을 통해 얻은 점수를 해석하려면, 그 점수가 실제로 무엇을 측정하는지를 분리해서 이해해야 한다. 강연자는 eval이 실질적으로 세 가지를 동시에 테스트한다고 설명한다.
첫 번째는 모델 자체의 성능이다. 아무리 하네스(harness)가 허술해도, 모델이 충분히 강력하다면 좋은 점수를 낼 수 있다. 이는 반대로 말하면, 높은 점수가 반드시 잘 설계된 에이전트를 의미하지 않는다는 것이기도 하다.
두 번째는 하네스(harness)의 품질이다. 하네스란 에이전트가 모델을 활용하는 방식 전체, 즉 프롬프트 설계, 툴 구성, 컨텍스트 관리 등을 포괄한다. 강연자가 드는 흥미로운 사례가 있다. Anthropic의 모델이 Cursor나 다른 코딩 에이전트보다 Claude Code에서 훨씬 더 잘 작동하는 것처럼 보이는 경우가 있다. 이것은 모델 자체의 차이가 아니라, Claude Code의 하네스가 Anthropic 모델 패밀리의 특성을 더 잘 이끌어내도록 설계되어 있기 때문일 가능성이 높다. 하네스가 달라지면 같은 모델도 다른 결과를 낸다는 것, 이것이 에이전트 평가가 단순 모델 평가와 다른 핵심 이유 중 하나다.
세 번째는 **문제의 적절성(problem sanity)**이다. 형편없는 문제로 100% 점수를 받아봤자 아무 의미가 없다. eval이 실제로 의미 있는 작업을 반영하는지 지속적으로 검증해야 하며, 강연자는 TerminalBench가 이 기준을 상당히 잘 충족한다고 평가한다.
힐 클라이밍: 점수를 올리는 세 가지 구간
Cline 팀이 정립한 실전 전략의 핵심은 **힐 클라이밍(hill climbing)**이다. 에이전트를 eval에서 실행해 점수를 받고, 실패한 케이스를 분석하고, 그것을 개선하는 과정을 반복하는 것이다.
예를 들어 89개 태스크 중 50개가 실패했다고 하자. 이때 해야 할 일은 실패의 원인을 분류하는 것이다. 강연자는 이를 “포트폴리오 배분(portfolio allocation)“이라고 표현한다. 각 실패 케이스의 트레이스(trace)—에이전트가 수행한 모든 LLM 호출 기록을 담은 방대한 파일—를 별도의 에이전트로 분석하게 해서, “이 태스크는 테스트를 실행하지 않아서 실패했다”, “이 태스크는 파일 읽기 툴이 제대로 작동하지 않아서 실패했다” 등의 패턴을 파악한다. 실패의 원인이 분류되면, 개선해야 할 구체적인 레버(lever)가 명확해지고 어디서 가장 큰 개선 효과를 얻을 수 있는지가 보이기 시작한다.
13:16 - 89개 태스크 실행 후 실패 케이스를 포트폴리오 배분 방식으로 분류하는 방법론 설명 화면
15:02 - Cline의 초기 점수(43%)와 CPU·메모리·타임아웃·thinking 행동 개선 이후 점수를 비교한 내부 벤치마크 결과 슬라이드
Cline의 실제 사례에서 초기 점수는 약 43%였다. 이후 컨테이너의 CPU와 메모리 설정을 조정하고, 타임아웃을 늘리고, 모델의 사고(thinking) 행동을 개선했다. 흥미롭게도 모델에게 “더 많이 생각하도록” 지시하는 것이 항상 좋은 결과를 내지는 않는다. 때로는 2,000 토큰짜리 순환 논리에 빠져버리기도 하기 때문이다. 이처럼 미세한 조정 하나하나가 점수에 큰 영향을 미쳤다.
이 힐 클라이밍 과정에서 강연자는 세 가지 개선 구간을 구분한다. **구간 1: 명백한 결함(obvious flaws)**은 하네스를 아예 충돌시키거나 rate limiting에 걸리는 등 확실한 버그다. 이는 반드시 수정해야 하지만, 상대적으로 발견하기 쉽다. **구간 2: 미세 개선(nuance improvements)**이 가장 중요한 구간이다. 예를 들어 Anthropic 모델 패밀리에 효과적인 프롬프트 엔지니어링 기법이 Codex나 Gemini 모델 패밀리에는 전혀 통하지 않을 수 있다. “이 모델이 그렇게 좋다고 하는데 왜 내 에이전트에서는 안 될까?”라는 질문의 답이 바로 이 미세 조정의 영역에 숨어 있다. 에이전트 개발의 본질은 이 구간 2를 얼마나 잘 공략하느냐에 달려 있다고 해도 과언이 아니다. **구간 3: 위험 구간(danger zone)**은 eval 점수를 높이기 위해 사실상 치팅을 하는 단계다. 벤치마크에 과적합(overfitting)된 결과를 소셜 미디어에 올려 홍보하는 유혹이 있지만, 강연자는 이를 명백히 경계한다.
힐 클라이밍을 통해 Cline이 깨달은 또 다른 사실은 모델 지원 범위의 중요성이었다. 초기에는 Anthropic 모델 패밀리에 최적화되어 있었지만 Gemini나 다른 소형 모델 패밀리에서는 성능이 낮았다. 이 모델들을 제대로 지원하기 시작하자, 해당 모델을 애용하던 사용자층 전체를 흡수할 수 있었다. eval 기반 힐 클라이밍이 단순한 성능 개선이 아닌 제품의 적용 범위를 넓히는 데도 직접적으로 기여한 셈이다.
마무리: Eval은 엔지니어링이자 철학이다
Ara Khan의 강연이 남기는 핵심 메시지는 단순하면서도 깊다. Eval은 완벽하지 않다. 벤치마크는 부러져 있고(broken), 오래됐으며, 때로는 오해를 일으킨다. 그렇다고 바이브에만 의존하는 것은 더 나쁜 선택이다. 진정한 답은 eval을 엔지니어링 문제이자 철학 문제로 동시에 다루는 것이다. 에이전트가 실패하는 공간은 거의 무한하다. 그 공간을 완벽하게 커버하는 eval은 존재하지 않는다. 그러나 실제 사용자가 실제로 맞닥뜨리는 문제들을 최대한 잘 근사하는 eval을 만들고, 그 위에서 점수를 올리며 에이전트를 개선하는 힐 클라이밍 루프가 현실적으로 가장 효과적인 접근법이다.
Cline의 경험이 보여주듯, 표준 eval이 없을 때는 직접 만드는 것을 두려워하지 말아야 한다. 그리고 힐 클라이밍은 그저 점수를 높이는 기술적 작업이 아니다. 어디서 실패하는지를 이해하고, 그 실패를 분류하고, 레버를 찾는 과정이 에이전트의 실질적인 능력을 끌어올리는 핵심 루프다. 마지막으로 강연자는 두 가지를 모두 충족해야 한다고 강조한다. 숫자도 좋아야 하고, 실제로 써보는 경험도 좋아야 한다. 어느 한쪽만으로는 부족하다. 새로운 모델이 나왔을 때 올바른 판단을 내리기 위해서도, 이 두 가지 렌즈가 함께 필요하다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Evals Are Broken, Use Them Anyway — Ara Khan, Cline |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-06-07 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.