평가와 벤치마크로 하네스 개선하기

좋아졌다는 느낌은 품질 지표가 아니다

에이전트가 더 똑똑해진 것처럼 보일 때가 있다. 답변이 길어졌고, 말투가 자연스러워졌고, 몇 번의 데모도 성공했다. 그러나 이것만으로 하네스가 개선됐다고 말할 수는 없다.

하네스 엔지니어링에서 평가는 "좋아 보인다"를 "반복해서 측정된다"로 바꾸는 일이다. 같은 입력, 같은 조건, 같은 채점 기준에서 이전 버전보다 나아졌는지 확인해야 한다. 더 중요하게는 새 버전이 과거에 잘하던 일을 망가뜨리지 않았는지, 즉 회귀를 잡아내야 한다.

모델을 바꾸지 않아도 하네스 변경만으로 결과는 크게 달라진다. 프롬프트 문구, 컨텍스트 구성, 도구 스키마, 재시도 정책, 권한 규칙, 실패 복구 루프가 모두 에이전트의 행동을 바꾼다. 최근 연구들도 모델 자체가 아니라 하네스 코드와 실행 구조를 최적화해 성능과 비용을 개선할 수 있음을 보여준다.¹ 따라서 평가는 모델 평가가 아니라 시스템 평가여야 한다.

먼저 실패를 정의한다

평가 도구를 고르기 전에 먼저 물어야 한다.

"우리 하네스는 무엇을 잘해야 하는가?"

이 질문이 불명확하면 어떤 벤치마크를 돌려도 의미가 흐려진다. 코딩 에이전트라면 작업 성공률과 테스트 통과율이 중요하다. 고객 지원 에이전트라면 답변 정확도, 정책 준수율, 수동 상담 전환율이 중요하다. 데이터 분석 에이전트라면 올바른 쿼리 생성, 재현 가능한 결과, 민감 데이터 접근 차단이 중요하다.

운영 의사결정에 연결되는 지표를 먼저 정해야 한다. 예를 들면 다음과 같다.

• 작업 성공률: 사용자가 요청한 최종 목표를 달성했는가

• 테스트 통과율: 코드나 데이터 작업의 검증 스위트를 통과했는가

• 지시 준수율: 형식, 금지어, 길이, 정책 같은 명시적 지시를 지켰는가

• 재시도율: 같은 작업을 몇 번 반복해야 성공하는가

• 수동 개입률: 사람이 승인, 수정, 복구해야 한 비율은 얼마인가

• 평균 지연시간과 p95 지연시간: 사용자가 기다릴 수 있는 범위인가

• 토큰·API 비용: 개선이 비용 폭증을 숨기고 있지는 않은가

• 위험 액션 차단률: 삭제, 결제, 외부 전송 같은 행동을 올바르게 막았는가

좋은 지표는 숫자 자체보다 "어떤 회귀를 잡는지"가 분명하다. 예를 들어 지시 준수율은 프롬프트 변경으로 출력 형식이 깨지는 회귀를 잡는다. 재시도율은 도구 스키마가 모델에게 어려워졌는지 보여준다. 수동 개입률은 자동화가 실제로 운영 부담을 줄였는지 확인한다.

평가 세트는 실제 업무 분포에서 나온다

범용 벤치마크는 출발점일 뿐이다. MMLU, HellaSwag, HumanEval, IFEval 같은 벤치마크는 모델의 일반 능력을 비교하는 데 유용하다. lm-evaluation-harness는 여러 표준 벤치마크와 커스텀 태스크를 같은 방식으로 실행할 수 있게 해 주는 대표적인 평가 프레임워크다.²

하지만 높은 범용 점수가 곧 우리 에이전트의 품질을 보장하지는 않는다. 실제 사용자는 리더보드 문제처럼 질문하지 않는다. 사내 약어를 쓰고, 불완전한 요구사항을 던지고, 오래된 문서를 붙여 넣고, 권한이 필요한 액션을 요청한다. 그래서 하네스 평가는 반드시 업무별 평가 세트를 가져야 한다.

평가 세트는 다음 원천에서 만든다.

1. 실제 사용자 요청 로그

2. 실패한 운영 사례

3. 자주 반복되는 내부 업무

4. 보안·권한상 위험한 요청

5. 제품팀과 운영팀이 중요하다고 보는 대표 시나리오

그다음 평가 세트를 층화한다. 층화란 한 덩어리로 섞지 않고 기준별로 나누어 관리하는 것이다.

• 난이도: 쉬움, 보통, 어려움

• 도메인: 결제, 계정, 코드베이스, 법무, 데이터 분석

• 도구 사용 여부: 단일 답변, 검색 필요, DB 조회 필요, 코드 실행 필요

• 위험도: 읽기 전용, 변경 가능, 외부 전송, 삭제·결제

• 대화 길이: 단일 턴, 다중 턴, 장시간 작업

이렇게 나누어야 평균 점수의 착시를 줄일 수 있다. 전체 성공률이 85%여도 위험 액션이 포함된 작업에서 50%라면 배포하면 안 된다. 반대로 쉬운 질문에서 점수가 조금 떨어져도 고위험 작업 차단률이 크게 좋아졌다면 운영상 더 나은 하네스일 수 있다.

벤치마크 점수를 읽을 때도 조심해야 한다. 데이터 오염, 프롬프트 템플릿 차이, few-shot 예시 수 차이, 채점 기준 차이가 있으면 점수는 신호가 아니라 잡음이 된다. 같은 데이터셋도 구현 방식에 따라 결과가 달라질 수 있다. 그러므로 평가 설정에는 모델 버전, 프롬프트 버전, few-shot 수, 샘플링 파라미터, 도구 버전, 데이터셋 버전을 함께 고정해야 한다.

평가 파이프라인은 재현 가능해야 한다

lm-evaluation-harness 같은 프레임워크에서 배울 핵심은 특정 도구 이름이 아니다. 핵심은 평가를 구성요소로 분리해 재현 가능한 파이프라인으로 관리한다는 점이다.

평가 파이프라인은 보통 다음 요소로 구성된다.

• 데이터셋: 입력, 기대 출력, 메타데이터

• 프롬프트 템플릿: 모델에게 문제를 제시하는 형식

• few-shot 예시: 문제 풀이 전에 보여주는 예시

• 실행기: 모델 또는 에이전트를 호출하는 코드

• 채점기: 답변, 도구 호출, 실행 결과를 점수화하는 로직

• 메트릭 집계기: 성공률, 비용, 지연시간, 실패 유형을 계산하는 부분

• 결과 저장소: 버전별 결과와 샘플 로그를 남기는 곳

이 구조가 있어야 하네스 변경을 실험할 수 있다. 예를 들어 도구 설명을 바꿨다면 같은 평가 세트를 다시 실행한다. 성공률이 올랐는지, 지연시간이 늘었는지, 위험 액션 시도가 줄었는지 비교한다. 결과가 좋으면 배포 후보가 된다. 나쁘면 되돌린다.

평가 설정은 코드처럼 버전 관리해야 한다. evals/customer_support_v3.yaml, datasets/payment_risk_2026_05.jsonl, rubrics/planning_quality_v2.md처럼 파일로 남기면 팀이 같은 기준으로 토론할 수 있다. 평가가 문서가 아니라 실행 가능한 자산이 되는 것이다.

최종 답만 보면 중요한 실패를 놓친다

에이전트 평가는 단일 답변 평가보다 넓다. 특히 도구를 쓰는 에이전트는 최종 답이 맞더라도 과정이 위험할 수 있다.

예를 들어 사용자가 "지난달 매출 요약을 만들어줘"라고 요청했다. 에이전트가 최종적으로 맞는 요약을 냈다고 하자. 하지만 실행 로그를 보면 필요 없는 고객 개인정보 테이블을 조회했고, 같은 쿼리를 다섯 번 반복했고, 중간에 삭제 API를 호출하려다 차단됐을 수 있다. 최종 답만 채점하면 이런 문제는 보이지 않는다.

따라서 평가는 네 단계로 나누어야 한다.

첫째, 단일 호출 평가다. 모델이 한 번의 입력에 대해 올바른 형식과 내용을 생성하는지 본다. 분류, 요약, JSON 출력, 간단한 코드 생성에 적합하다.

둘째, 도구 호출 포함 전체 실행 평가다. 에이전트가 올바른 도구를 선택하고, 파라미터를 정확히 채우고, 실패 응답을 처리하는지 본다.

셋째, 다중 턴 대화 평가다. 사용자가 조건을 바꾸거나 이전 답변을 수정하라고 할 때 맥락을 유지하는지 확인한다.

넷째, 트레이스 기반 평가다. 트레이스는 에이전트가 거친 실행 흔적이다. 프롬프트, 검색 결과, 도구 호출, 오류, 재시도, 최종 답을 모두 포함한다. 트레이스를 보면 잘못된 검색, 불필요한 반복, 위험한 액션 시도, 컨텍스트 누락을 검출할 수 있다.

하네스 품질은 결과와 과정의 합이다. 정답에 도달했는지뿐 아니라 안전하고 경제적인 경로로 도달했는지를 함께 봐야 한다.

자동 채점과 사람 평가는 역할이 다르다

모든 작업을 같은 방식으로 채점할 수는 없다.

정답이 명확한 작업은 자동 채점을 우선한다. 코딩 작업은 단위 테스트, 타입 체크, 린트, 실행 결과로 평가한다. 데이터 작업은 정확도, 재현율, 쿼리 결과 일치, 파일 생성 여부로 본다. 이런 영역에서는 LLM 판정보다 결정론적 검증이 강하다. 테스트가 통과하면 통과이고, 실패하면 실패다.

반면 문서 작성, 기획, 디자인, 전략 제안은 정답이 하나가 아니다. 이때는 루브릭 기반 평가가 필요하다. 루브릭은 평가 기준표다. 예를 들어 기획 문서라면 다음 기준을 둘 수 있다.

• 요구사항을 빠짐없이 반영했는가

• 의사결정에 필요한 근거가 있는가

• 모호한 부분을 가정으로 표시했는가

• 실행 가능한 다음 단계가 있는가

• 금지된 정책이나 표현을 위반하지 않았는가

이런 작업에는 LLM-as-judge를 사용할 수 있다. 더 강한 모델에게 루브릭을 주고 답변을 채점하게 하는 방식이다. 다만 LLM 평가자도 완벽하지 않다. 그래서 중요한 평가는 사람 평가와 함께 써야 한다. 특히 주관적 평가에서는 블라인드 비교, 쌍대 비교, 평가자 간 합의도를 포함해야 한다. 어느 버전이 만든 결과인지 숨기고 비교하면 선입견을 줄일 수 있다.

IFEval처럼 검증 가능한 지시 준수 벤치마크는 좋은 참고 사례다. 이 유형의 평가는 "모든 지시를 지켰는가"와 "개별 지시를 얼마나 지켰는가"를 나누어 볼 수 있다.³ 하네스에서도 같은 관점을 적용할 수 있다. 최종 산출물이 좋아 보여도, "JSON만 출력하라", "개인정보를 포함하지 말라", "근거 문서 ID를 포함하라" 같은 개별 지시를 어겼다면 실패로 기록해야 한다.

하네스 변경은 A/B 테스트로 검증한다

평가의 목적은 순위를 매기는 것이 아니라 개선 결정을 내리는 것이다. 그래서 하네스 변경은 실험으로 다뤄야 한다.

예를 들어 다음 변경을 했다고 하자.

• 시스템 프롬프트를 짧게 줄였다

• 검색 결과를 10개에서 5개만 넣도록 바꿨다

• 도구 스키마의 파라미터 이름을 더 명확하게 바꿨다

• 실패 시 재시도 횟수를 3회에서 1회로 줄였다

• 고위험 액션에는 승인 단계를 추가했다

이 변경이 좋은지 알려면 이전 버전과 새 버전을 같은 평가 세트에서 비교해야 한다. 가능하면 A/B 테스트를 한다. 일부 트래픽이나 샘플을 기존 하네스에, 일부를 새 하네스에 보내고 결과를 비교한다.

보고서는 평균 성공률만 보여주면 안 된다. 다음을 함께 봐야 한다.

• 어떤 유형의 문제가 좋아졌는가

• 어떤 유형에서 회귀가 생겼는가

• 비용은 얼마나 변했는가

• 지연시간은 악화됐는가

• 위험 액션 시도와 차단은 어떻게 변했는가

• 사람이 개입해야 하는 비율은 줄었는가

특히 비용과 지연시간은 품질과 함께 봐야 한다. 성공률이 2% 올랐지만 비용이 3배가 되고 응답 시간이 두 배가 됐다면 운영상 나쁜 변경일 수 있다. 반대로 성공률은 그대로지만 수동 개입률이 크게 줄었다면 좋은 하네스 개선일 수 있다.

실패 로그는 다음 평가 세트가 된다

평가 세트는 한 번 만들고 끝나는 문서가 아니다. 운영 중 실패가 발생하면 그 사례를 정리해 평가 세트에 추가해야 한다.

좋은 루프는 단순하다.

1. 운영 로그에서 실패를 수집한다.

2. 실패 원인을 분류한다.

3. 재현 가능한 테스트 케이스로 만든다.

4. 프롬프트, 컨텍스트, 도구, 정책, 테스트 중 어디를 고칠지 정한다.

5. 수정 후 전체 평가 세트를 다시 실행한다.

6. 회귀가 없으면 배포한다.

이 루프가 쌓이면 하네스는 점점 단단해진다. 과거의 실패가 미래의 안전장치가 되기 때문이다. 연구 영역에서도 실행 트레이스와 이전 후보의 결과를 활용해 하네스 자체를 자동 개선하려는 시도가 늘고 있다.⁴ 방향은 분명하다. 하네스는 감으로 고치는 프롬프트 묶음이 아니라, 평가와 로그를 먹고 진화하는 시스템이다.

평가 체계가 하네스를 엔지니어링으로 만든다

하네스 엔지니어링은 모델을 믿는 일이 아니다. 모델이 실수해도 시스템이 감지하고, 차단하고, 복구하고, 다시 배우게 만드는 일이다. 그 중심에 평가가 있다.

평가가 없으면 모든 개선은 의견 싸움이 된다. 평가가 있으면 토론은 데이터 위에서 진행된다. "이 프롬프트가 더 좋아 보인다"가 아니라 "고위험 요청 차단률은 8% 올랐고, 비용은 12% 늘었으며, 다중 턴 작업에서 3개 회귀가 생겼다"라고 말할 수 있다.

좋은 하네스 팀은 벤치마크 점수를 맹신하지 않는다. 대신 자기 업무의 실패 정의를 만들고, 실제 로그에서 평가 세트를 만들고, 도구 호출과 트레이스를 채점하고, 하네스 변경을 반복 실험한다.

결국 하네스의 성숙도는 평가 세트의 성숙도와 함께 자란다. 에이전트 품질을 감각이 아니라 반복 가능한 측정으로 다룰 때, 하네스는 비로소 운영 가능한 엔지니어링 자산이 된다.

참고

¹Meta-Harness: End-to-End Optimization of Model Harnesses

²EleutherAI lm-evaluation-harness

³주간 LLM: LLM Evaluation (1) - IFEval

⁴Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses