📊

평가 파이프라인 — 하네스 품질을 측정하는 법

감으로 판단하면 진다, 자동화된 평가 체계가 필수다

"프롬프트를 바꿨더니 체감상 좋아진 것 같다" — 이런 판단은 위험하다. 10개 케이스에서 좋아졌어도 다른 10개에서 나빠졌을 수 있다.

테스트 셋 — 입력-기대출력 쌍의 모음. 실제 사용 사례에서 추출하는 게 좋다. 합성 데이터만으로는 부족하다.

실행기 — 하네스를 통해 테스트 셋을 돌린다. 동일 조건에서 A/B 비교가 가능해야 한다.

채점기 — 출력의 품질을 수치화한다. 정답이 명확한 경우(코드 — 테스트 통과 여부)는 자동, 자연어 응답은 LLM-as-judge나 인간 평가를 쓴다.

추적 — 각 실행의 입력, 중간 과정, 출력, 점수를 전부 기록. 뭐가 좋아졌고 뭐가 나빠졌는지 원인을 추적할 수 있어야 한다.

코드 생성 하네스라면:

RAG 하네스라면:

"이 프롬프트가 더 좋은 것 같다"는 감이다. "pass@1이 52%에서 61%로 올랐고, 실패 케이스 분석 결과 에러 메시지 파싱 개선이 원인이다"가 데이터다.

하네스 엔지니어링은 감이 아닌 데이터로 의사결정하는 분야다.

동작 흐름

테스트 셋 구축 — 실제 사용 사례 기반 입력-기대출력 쌍 최소 50개 이상

자동 실행 + 채점 — 하네스 변경마다 전체 테스트 셋을 돌려서 점수 비교

실패 케이스 분석 — 점수가 떨어진 케이스를 분석해서 원인 파악

회귀 방지 — 새 기능 추가 시 기존 케이스가 깨지지 않는지 확인

SWE-bench — 실제 GitHub 이슈를 기반으로 코딩 에이전트의 하네스를 평가하는 벤치마크 RAG 평가 — 검색 정밀도, 응답 충실도, hallucination 비율로 RAG 하네스 품질 측정