앞 장에서 우리는 큰 목표를 검증 가능한 작은 작업으로 나눴다. 이제 다음 질문이 남는다. 그렇게 나눈 작업이 실제로 잘 작동하는지는 어떻게 알 것인가?
여기서부터는 감이 아니라 측정의 영역이다. 에이전트가 "대체로 괜찮아 보인다"는 말만으로는 제품을 운영할 수 없다. 어떤 작업에서 성공하는지, 어디서 자주 틀리는지, 바꾼 프롬프트가 정말 나아졌는지, 모델을 교체했더니 왜 비용은 늘고 성공률은 떨어졌는지를 숫자와 기록으로 봐야 한다.
핵심은 단순하다. 측정할 수 없는 에이전트는 개선할 수 없고, 개선할 수 없으면 운영할 수 없다.1
왜 에이전트 평가는 보통 소프트웨어 테스트보다 더 어렵나
일반적인 소프트웨어 테스트는 비교적 단정하다. 입력이 같으면 출력도 같기를 기대한다. 그래서 "이 함수는 7을 반환해야 한다" 같은 식의 단언이 잘 통한다.
하지만 에이전트는 다르다. 같은 요청을 받아도 매번 약간 다른 경로로 문제를 풀 수 있다. 어떤 날은 검색을 한 번 하고 끝내고, 어떤 날은 두 번 검색한 뒤 요약을 만들며, 또 어떤 날은 같은 정답에 도달했더라도 불필요한 도구를 더 많이 쓸 수 있다. 게다가 외부 문서, 검색 결과, API 응답처럼 실행 시점마다 달라지는 데이터까지 끼어든다. 그래서 에이전트 평가는 최종 답만 보는 순간 급격히 부정확해진다.2
이 말은 곧, 에이전트를 평가할 때는 두 가지를 함께 봐야 한다는 뜻이다. 하나는 결과가 맞았는가이고, 다른 하나는 그 결과에 도달하는 과정이 괜찮았는가다. 최종 답이 맞아도 금지된 도구를 썼다면 실패다. 반대로 답이 조금 서툴러도 근거를 정확히 찾고 안전 규칙을 지켰다면 개선 가능한 실패다.
좋은 평가 하네스는 이 둘을 분리해서 본다. 결과와 과정이 섞이면, 어디를 손봐야 할지 알 수 없기 때문이다.
평가 하네스는 테스트 몇 개가 아니라 반복 가능한 실험실이다
평가 하네스를 단순한 테스트 묶음으로 생각하면 금방 한계에 부딪힌다. 진짜 평가 하네스는 다음 요소가 함께 있어야 한다.
고정된 시나리오 집합
동일한 실행 조건
점수 규칙과 판정 기준
기준선과의 비교
결과 저장과 회고
이 다섯 가지가 함께 있어야 "이번 변경이 실제 개선인지, 그냥 운이 좋았던 것인지"를 구분할 수 있다. 예를 들어 프롬프트를 조금 바꿨는데 성공률이 올라갔다고 하자. 이때 테스트 케이스가 매번 바뀌고, 도구 응답도 제각각이고, 평가 규칙도 그때그때 다르면 아무 의미가 없다. 그런 평가는 측정이 아니라 기분에 가깝다.
그래서 평가 하네스는 일종의 실험실이어야 한다. 같은 시나리오를, 같은 조건에서, 같은 채점 규칙으로 반복 실행하고, 이전 버전과 비교해야 한다. 이때 비로소 "좋아졌다"는 말이 제품 언어가 된다.3
먼저 정의해야 할 것: 무엇을 성공이라고 부를 것인가
평가 도구를 고르기 전에 더 먼저 해야 할 일이 있다. 성공의 정의를 쓰는 일이다. 이것이 없으면 테스트를 많이 돌려도 결국 흐릿한 숫자만 쌓인다.
에이전트 평가에서 성공은 보통 네 층으로 나뉜다.
작업 성공: 사용자의 목표를 실제로 달성했는가
과정 성공: 올바른 도구와 절차를 따라갔는가
운영 성공: 시간, 비용, 호출 수가 허용 범위 안에 있는가
안전 성공: 정책, 권한, 금지 규칙을 지켰는가
이 구분이 중요한 이유는, 에이전트가 겉보기 성공을 자주 만들기 때문이다. 예를 들어 고객 문의를 해결했다고 답했지만 실제 CRM에는 아무것도 기록하지 않았을 수 있다. 또는 정답은 맞았지만 권한이 없는 파일을 읽었을 수 있다. 혹은 보고서는 괜찮았지만 도구 호출을 열다섯 번이나 반복해 비용이 세 배가 됐을 수 있다.
제품 관점에서 이런 것은 모두 실패다. 그러니 성공률 하나만 보면 안 된다. 성공을 여러 층으로 쪼개야 어디가 무너졌는지 보인다.
에이전트 평가의 기본 단위: 작업, 시행, 채점기, 트레이스
평가를 설계할 때 유용한 기본 단어 몇 개를 정리해 두자. 하나의 작업은 하나의 테스트 문제다. "이 영수증에서 총액을 추출하라", "이 버그를 재현하고 수정하라", "이 회의 내용을 요약하고 액션 아이템을 뽑아라" 같은 것이 작업이다.
그 작업을 한 번 실행한 것이 시행이다. 같은 작업이라도 에이전트는 매번 조금 다르게 움직일 수 있으므로, 중요한 평가는 여러 번 시행해 보는 편이 좋다. Anthropic도 에이전트 평가에서 작업, 시행, 채점기, 트레이스, 결과 상태를 분리해서 다루는 것이 중요하다고 설명한다.1
여기서 채점기는 점수를 매기는 규칙이다. JSON 형식이 맞는지 검사하는 코드도 채점기이고, "이 답이 사용자의 의도를 잘 해결했는가"를 판단하는 LLM도 채점기다. 마지막으로 트레이스는 에이전트가 무엇을 보고, 어떤 도구를 부르고, 어떤 중간 판단을 거쳤는지 남긴 실행 기록이다.
이 네 가지가 분리되어야 평가가 디버깅 도구가 된다. 실패했다는 사실만 알아서는 부족하다. 어떤 작업에서, 몇 번째 시행에서, 어떤 채점기 기준으로, 어떤 트레이스를 남기며 실패했는지를 알아야 고칠 수 있다.
단위 테스트: 에이전트를 똑똑함이 아니라 기계적 정확성으로 먼저 본다
많은 팀이 에이전트를 평가할 때 너무 빨리 종합 시나리오로 들어간다. 하지만 가장 먼저 해야 할 일은 훨씬 소박하다. 개별 부품이 기계적으로 맞게 움직이는지 확인하는 것이다.
단위 테스트는 주로 이런 질문을 다룬다. 이 요청에서 올바른 도구를 선택했는가? 도구 인자를 스키마에 맞게 만들었는가? 상태 전이가 허용된 순서대로 일어났는가? 출력 포맷이 계약을 지켰는가?
예를 들어 환불 문의 자동화 에이전트가 있다고 해 보자. 사용자가 "환불 상태를 확인해줘"라고 말했는데, 에이전트가 send_email 도구를 먼저 고르면 그 순간 이미 단위 테스트에서 잡혀야 한다. 아직 고객 경험 전체를 보기 전이다. 그냥 기초 체력이 부족한 것이다.
단위 테스트의 좋은 점은 빠르고 싸고 분명하다는 데 있다. 여기서는 실제 LLM 호출보다 모의 응답, 고정 입력, 스키마 검증 같은 결정적 검사 방식을 우선하는 편이 좋다. 이 단계에서 흔들리면 상위 평가로 올라갈수록 실패 원인이 안개처럼 퍼진다.4
즉, 단위 테스트는 에이전트의 "지능"을 시험하는 것이 아니다. 하네스의 기계적 연결 상태를 시험하는 것이다.
통합 테스트: 여러 단계를 묶었을 때도 이야기가 이어지는가
단위 테스트를 통과했다고 안심하면 안 된다. 에이전트의 진짜 문제는 부품 하나가 아니라 부품 사이의 연결에서 자주 생긴다. 계획 단계는 멀쩡했는데 실행 단계로 넘어가며 컨텍스트가 빠질 수 있고, 올바른 도구를 골랐지만 이전 단계에서 만든 인자를 잘못 넘겨 줄 수도 있다.
그래서 통합 테스트는 여러 단계를 엮어 본다. 검색 → 선별 → 요약, 또는 계획 → 도구 호출 → 결과 해석 → 후속 행동처럼 실제 작업 흐름을 작게 재현한다. 여기서 보는 것은 단순 정답 여부가 아니다. 컨텍스트가 유지되는지, 중간 상태가 깨지지 않는지, 실패가 났을 때 적절히 재시도하거나 멈추는지다.2
통합 테스트가 필요한 이유를 아주 쉬운 비유로 말해 보자. 단위 테스트는 각 악기가 소리를 내는지 확인하는 일이고, 통합 테스트는 합주를 해 봤을 때 곡이 되는지 확인하는 일이다. 바이올린도 멀쩡하고 피아노도 멀쩡한데, 함께 연주하니 박자가 어긋날 수 있다. 에이전트도 똑같다.
특히 도구를 여러 개 쓰는 에이전트라면 통합 테스트는 선택이 아니라 필수다. 에이전트의 실패는 종종 3단계에서 보이지만, 원인은 1단계에서 잘못 만든 입력인 경우가 많기 때문이다.2
종단간 평가: 최종 산출물만이 아니라 최종 상태를 본다
종단간 평가는 사용자 요청부터 최종 결과까지 전체 경로를 실제에 가깝게 돌려 보는 것이다. 그런데 여기서 자주 생기는 착각이 하나 있다. 에이전트가 마지막에 "완료했습니다"라고 말하면 정말 완료된 것으로 취급하는 것이다.
에이전트 세계에서는 말과 상태가 다를 수 있다. Anthropic이 강조하듯, 평가 대상은 대화 마지막 문장이 아니라 환경의 최종 상태여야 할 때가 많다.1 항공 예약 에이전트가 "예약이 끝났습니다"라고 답해도 데이터베이스에 예약이 없으면 실패다. 코딩 에이전트가 "버그를 수정했습니다"라고 말해도 테스트가 여전히 깨져 있으면 실패다.
그래서 종단간 평가는 가능하면 결과 문장보다 결과 상태를 확인해야 한다. 실제 파일이 수정되었는가, 실제 레코드가 생성되었는가, 실제 테스트가 통과했는가, 실제 승인 요청이 저장되었는가를 보아야 한다. 이 관점이 들어오면 에이전트 평가는 훨씬 현실적이 된다.
회귀 테스트: 좋아진 것 같지만 사실은 망가졌다는 착시를 막는다
에이전트 개발에서 가장 흔한 사고 중 하나는 한 영역을 고치다가 다른 영역을 망가뜨리는 일이다. 프롬프트를 더 자세히 썼더니 도구 선택은 좋아졌지만 응답 속도가 크게 느려질 수 있다. 모델을 바꿨더니 요약 품질은 올라갔지만 JSON 형식 준수율은 떨어질 수 있다.
회귀 테스트는 바로 이런 착시를 막는 장치다. 핵심은 새 버전을 절대 점수만으로 보지 않고, 기준선과의 차이로 본다는 데 있다.3
예를 들어 현재 운영 버전이 있고, 후보 버전이 있다고 하자. 두 버전을 같은 데이터셋, 같은 도구 모의 환경, 같은 채점 규칙으로 돌린다. 그리고 비교한다. 성공률이 올랐는가? 실패 유형이 바뀌었는가? 평균 단계 수가 늘었는가? 비용 대비 성공률은 좋아졌는가? 특정 케이스만 유난히 나빠졌는가?
이 비교가 없으면 팀은 쉽게 속는다. 눈에 띄는 데모 몇 개가 더 좋아 보이면 전체적으로 좋아졌다고 착각한다. 하지만 제품은 데모의 합이 아니다. 반복되는 실제 시나리오들의 분포다. 회귀 테스트는 그 분포의 변화를 보는 습관이다.
평가 데이터셋은 테스트 케이스 모음이 아니라 팀의 기억이다
좋은 평가 하네스의 중심에는 결국 데이터셋이 있다. 여기서 말하는 데이터셋은 벤치마크라는 거창한 이름보다, 실무적으로는 반복해서 돌리는 시나리오 묶음에 가깝다.
처음부터 완벽한 데이터셋을 만들 필요는 없다. 오히려 다음 세 묶음부터 시작하는 편이 좋다.
꼭 성공해야 하는 대표 시나리오
자주 헷갈리는 경계 사례
실제로 사고가 났던 실패 사례
이 중에서 특히 중요한 것은 마지막이다. 운영 중 한 번이라도 사람을 당황하게 만든 케이스는 곧바로 데이터셋에 들어가야 한다. 그 순간부터 그 실패는 불운이 아니라 자산이 된다. 다음 릴리스에서 같은 사고가 되풀이되는지 자동으로 확인할 수 있기 때문이다.2
평가 데이터셋을 잘 만드는 팀은 시간이 지날수록 더 강해진다. 그 이유는 모델이 좋아져서가 아니라, 팀이 잊지 않기 때문이다. 데이터셋은 팀의 집단 기억이다.
데이터셋을 어떻게 구성해야 하나: 골든 세트와 살아 있는 세트
실무에서는 데이터셋을 두 층으로 나누면 편하다. 하나는 골든 세트다. 평가 기준이 비교적 분명하고, 릴리스 게이트에 걸어 둘 핵심 시나리오들이다. 다른 하나는 살아 있는 세트다. 최근 장애, 새로 추가된 기능, 정책 변화, 고객 피드백에서 나온 사례처럼 계속 갱신되는 시나리오들이다.
골든 세트는 자주 바꾸지 않는 것이 좋다. 그래야 장기 비교가 가능하다. 반면 살아 있는 세트는 계속 바뀌어야 한다. 그래야 현재 위험을 반영한다. 이 둘을 섞어버리면 장기 추세도 흐려지고, 최신 위험도 놓치기 쉽다.
데이터셋의 각 항목에는 최소한 이런 정보가 있으면 좋다. 작업 ID, 입력, 기대 행동, 금지 행동, 필요한 도구, 채점 방식, 중요도, 관련 장애 이력. 이 메타데이터가 있으면 실패 보고서가 훨씬 읽기 쉬워진다. "전체 성공률 87%"보다 "고객 환불 경계 사례 12개 중 정책 위반 3건"이 훨씬 행동 가능한 정보이기 때문이다.
LLM-as-a-Judge: 정답 한 줄로 못 재는 것을 재는 방법
에이전트 평가에는 아주 답답한 영역이 있다. 정답을 한 줄로 써 두기 어려운 경우다. 보고서가 충분히 설득력 있는지, 고객 응답이 공감적이면서도 정책을 지켰는지, 조사 결과가 질문 의도를 제대로 해결했는지 같은 문제는 단순 문자열 비교로 평가하기 어렵다.
이럴 때 쓰는 방법이 LLM-as-a-Judge다. 말 그대로 다른 모델을 심판으로 세우는 방식이다. 채점용 프롬프트와 기준표를 주고, 결과물의 유용성, 관련성, 정확성, 정책 준수 여부를 점수와 이유로 평가하게 한다.5
이 방식의 장점은 명확하다. 사람이 일일이 보지 않아도 대규모로 평가할 수 있고, 단순 키워드 매칭보다 훨씬 문맥을 이해한다. 특히 개방형 출력, 다단계 응답, 대화형 결과물 평가에 강하다.5
하지만 여기서 조심해야 할 점도 크다. LLM 심판은 편리하지만 절대 심판은 아니다. 사람 평가를 완전히 대체하는 것이 아니라, 사람이 하던 대규모 점검을 자동화한 근사치에 가깝다.
LLM-as-a-Judge를 쓸 때 꼭 알아야 할 한계
Microsoft의 분석이 보여 주듯, LLM 심판도 안정적이지 않을 수 있다. 심지어 temperature를 0으로 둬도 같은 입력에 점수가 조금씩 달라질 수 있고, 심판으로 쓰는 모델이 바뀌면 판정도 달라질 수 있다.6
이 말은 곧, LLM-as-a-Judge를 한 번 돌린 점수 하나에 과하게 의미를 부여하면 위험하다는 뜻이다. 실무에서는 보통 이런 보완이 필요하다.
평가 기준을 아주 구체적인 루브릭으로 쓴다
가능하면 구조화된 점수와 사유를 함께 받는다
중요한 평가는 여러 번 돌려 평균이나 분포를 본다
사람 샘플 검수를 통해 심판 모델을 주기적으로 보정한다
서로 다른 심판 모델 간 차이를 관찰한다
쉽게 말해, LLM 심판도 감독받아야 한다. 심판을 세웠다고 경기가 저절로 공정해지지는 않는다.
결정적 채점기와 모델 채점기를 섞어 써야 한다
좋은 평가 하네스는 LLM-as-a-Judge만 믿지 않는다. 오히려 가장 강한 구조는 결정적 채점기와 모델 채점기를 섞는 것이다.1
예를 들어 고객 이메일 초안을 평가한다고 해 보자. JSON 구조가 맞는지는 코드로 검사한다. 금지 문구가 있는지도 코드로 잡는다. 개인정보가 들어갔는지도 규칙 기반 검사로 본다. 반면 어조가 적절한지, 질문 의도를 충분히 해결했는지는 LLM 심판으로 본다.
이렇게 나누면 장점이 크다. 코드가 잘하는 영역은 빠르고 싸고 일관되게 처리하고, 모델이 필요한 영역에만 모델을 쓴다. 비용도 줄고, 디버깅도 쉬워진다. 무엇보다 실패 원인을 설명하기 좋다. "형식은 맞았는데 의도 해결 점수가 낮다"는 문장은 개선 방향을 바로 떠올리게 만든다.
경로 평가: 답만 맞으면 된다는 생각에서 벗어나기
에이전트는 종종 "정답은 맞지만 과정이 수상한" 방식으로 성공한다. 예를 들어 우연히 맞는 도구를 골랐지만 논리가 틀렸거나, 같은 API를 네 번 불러서 결국 답을 만들었거나, 금지된 지름길을 써서 문제를 해결할 수 있다.
그래서 평가 하네스는 최종 답뿐 아니라 경로 자체의 타당성을 봐야 한다. Braintrust가 제안하듯, 도구 선택 정확도, 인자 정확도, 실행 경로의 유효성, 불필요한 반복 여부 같은 지표를 따로 보는 것이 좋다.3
경로 평가가 중요한 이유는 아주 현실적이다. 오늘은 맞았지만 내일은 틀릴 수 있는 성공을 걸러내기 위해서다. 우연한 성공은 제품 품질이 아니다. 재현 가능한 성공만이 품질이다.
이 지점에서 트레이스 저장이 필수가 된다. 어떤 프롬프트로 어떤 도구를 호출했고, 어떤 응답을 받아 다음 행동을 골랐는지가 남아 있어야 경로를 채점할 수 있다. 트레이스가 없으면 평가는 다시 입력-출력 맞추기 놀이로 퇴행한다.
다회 실행과 분산 보기: 한 번의 통과를 믿지 말자
에이전트 평가는 본질적으로 확률적이다. 그래서 중요한 시나리오는 한 번만 돌려서는 안 된다. 같은 작업을 여러 번 실행해 보고, 성공률뿐 아니라 점수 분산도 보는 편이 좋다.16
예를 들어 어떤 시나리오가 1회 실행에서는 통과했지만 5회 실행하면 2번만 통과한다면, 그 기능은 사실상 불안정하다. 반대로 모든 실행에서 거의 비슷한 품질을 보인다면 훨씬 운영 친화적이다.
이 방식은 특히 모델 교체나 프롬프트 변경 시 중요하다. 평균 점수는 비슷한데 분산이 커지는 경우가 있기 때문이다. 사용자는 평균을 경험하지 않는다. 매번 한 번의 실행을 경험한다. 그러니 분산이 큰 시스템은 현장에서 더 불안하게 느껴진다.
데이터 품질이 나쁘면 에이전트 평가도 거짓말을 한다
평가를 아무리 열심히 해도 밑바닥 데이터가 흔들리면 결과를 믿기 어렵다. 검색 인덱스가 오래되었거나, 핵심 테이블의 스키마가 바뀌었거나, 조인 키 결측이 심하면 에이전트가 잘못 답해도 그 원인이 모델인지 데이터인지 구분하기 힘들다. 일부 실무 가이드는 그래서 아예 평가의 0번 레이어로 데이터 검증을 둔다.4
이 관점은 특히 RAG나 사내 데이터 에이전트에서 중요하다. 검색 품질이 낮아서 엉뚱한 문서를 가져왔는데, 이를 생성 모델의 환각으로 오해하면 엉뚱한 곳만 계속 고치게 된다. 그러니 평가 하네스에는 최소한 데이터 신선도, 검색 정확도, 스키마 일치 여부 같은 기초 점검이 포함되는 편이 좋다.
에이전트 평가는 결국 모델만의 시험이 아니다. 모델이 일하는 작업장 전체의 시험이다.
CI/CD에 평가를 넣어야 비로소 하네스가 된다
평가를 사람이 시간이 날 때만 돌리면, 그것은 참고 자료일 뿐 안전장치가 아니다. 진짜 하네스가 되려면 배포 파이프라인에 연결되어야 한다. 프롬프트가 바뀌든, 도구 설명이 바뀌든, 모델이 바뀌든, 검색 설정이 바뀌든, 행동에 영향을 줄 수 있는 변경이라면 자동으로 평가가 돌아야 한다.3
보통은 이렇게 층을 나눈다. 빠른 단위 테스트는 모든 PR에서 돌리고, 주요 통합 테스트는 병합 전후에 돌리며, 무거운 종단간 평가는 야간 배치나 릴리스 후보에서 돌린다. 여기에 회귀 기준선을 붙여서 특정 지표가 임계값 아래로 떨어지면 배포를 막는다.
이때 중요한 것은 "모든 지표를 완벽히 맞춰야 통과" 같은 과도한 문턱을 세우지 않는 것이다. 대신 제품에 치명적인 지표, 예를 들면 정책 위반률, 필수 작업 성공률, 구조화 출력 파싱률처럼 정말 중요한 것들에 우선 게이트를 두는 편이 현실적이다.
좋은 CI 평가는 팀을 느리게 하지 않는다. 오히려 사용자가 먼저 버그를 발견하는 일을 줄여 준다.
운영 중 평가는 개발용 평가와 달라야 한다
개발 단계의 평가는 고정 데이터셋과 반복 가능한 환경이 중요하다. 반면 운영 단계에서는 실시간 변화를 더 빨리 감지해야 한다. 그래서 운영 평가는 보통 트레이스 샘플링, 온라인 judge, 실패 유형 집계, 비용 이상 탐지처럼 모니터링 성격이 강해진다.5
여기서 유용한 지표는 생각보다 단순하다. 성공률, 재시도율, 평균 단계 수, 사람 에스컬레이션 비율, 작업당 비용, 작업당 시간, 정책 위반 비율. 이런 숫자를 주 단위로만 봐도 에이전트의 건강 상태가 꽤 잘 보인다.
특히 "비용 대비 성공"을 보는 습관이 중요하다. 성공률은 그대로인데 비용이 두 배가 됐다면, 그것도 퇴보다. 에이전트는 똑똑한 것만으로는 부족하다. 지속 가능한 방식으로 똑똑해야 한다.
사람이 꼭 남아 있어야 하는 평가 지점
자동 평가를 강조한다고 해서 사람이 필요 없어지는 것은 아니다. 오히려 잘 설계된 평가 하네스일수록 사람의 시간을 더 값비싼 판단에 집중시킨다.
사람이 특히 필요한 지점은 세 가지다. 첫째, 루브릭을 설계할 때다. 무엇이 좋은 답인지, 무엇이 위험한 행동인지, 어떤 실패가 치명적인지를 정하는 일은 제품과 도메인을 아는 사람이 해야 한다. 둘째, LLM 심판을 보정할 때다. 자동 평가와 사람 판단이 얼마나 맞는지 계속 비교해야 한다. 셋째, 새롭고 이상한 실패를 해석할 때다. 자동 평가는 반복되는 것을 잘 보지만, 완전히 새로운 유형의 사고를 의미 있게 이름 붙이는 일은 아직 사람이 더 잘한다.6
결국 자동 평가는 사람을 대체하기보다, 사람이 매번 처음부터 보지 않아도 되게 해 주는 장치다.
작은 팀이 처음 평가 하네스를 만들 때의 현실적인 순서
처음부터 거대한 평가 플랫폼을 만들 필요는 없다. 작은 팀이라면 다음 순서면 충분하다.
먼저 가장 중요한 작업 20개를 모은다. 그중 절반은 정상 시나리오, 절반은 실제로 헷갈렸던 실패 사례로 채운다. 다음으로 결정적으로 채점 가능한 항목부터 붙인다. JSON 파싱, 필수 필드, 금지 행동, 도구 선택 같은 것들이다. 그다음 최종 품질을 보는 간단한 LLM judge를 하나 붙인다. 그리고 기준선 버전을 저장한 뒤, 변경이 있을 때마다 같은 세트를 다시 돌린다.
여기까지만 해도 팀은 이미 훨씬 덜 불안해진다. 적어도 "이번 수정이 대형 사고를 낼까?"라는 질문에 전보다 훨씬 근거 있게 답할 수 있기 때문이다.
평가 하네스는 처음부터 화려할 필요가 없다. 대신 반복 가능하고, 비교 가능하고, 실패를 기억해야 한다. 그 세 가지가 먼저다.
평가가 자리 잡은 팀은 무엇이 달라지는가
평가 하네스가 없는 팀은 변경할 때마다 늘 비슷한 감정에 휩싸인다. 왠지 좋아진 것 같고, 또 왠지 불안하다. 그래서 릴리스는 종종 낙관과 긴장의 혼합물이 된다.
반면 평가 하네스가 자리 잡은 팀은 대화 방식이 달라진다. "이번 프롬프트가 더 자연스러워 보여요" 대신 "경계 사례 성공률이 8% 올랐지만, 단계 수가 늘어 비용이 12% 증가했습니다"라고 말한다. "이 모델이 더 똑똑한 것 같아요" 대신 "리서치 작업 품질은 개선됐지만 도구 인자 오류가 늘었습니다"라고 말한다.
이 변화는 단순히 더 과학적이어서 좋은 것이 아니다. 제품 팀이 같은 그림을 보게 되기 때문에 좋다. 개발자, PM, 보안 담당자, 운영 담당자가 같은 테스트 결과와 같은 실패 사례를 두고 이야기할 수 있다. 그때 비로소 에이전트는 데모가 아니라 운영 대상이 된다.
측정 가능한 에이전트만이 커질 수 있다
에이전트 하네스 설계에서 테스트와 평가는 마지막 단계가 아니다. 오히려 시스템이 제품으로 넘어가는 문턱이다. 작업을 잘게 나누는 것만으로는 충분하지 않다. 그 작업들이 실제로 잘 수행되는지, 바뀐 환경에서도 유지되는지, 더 나아졌는지 나빠졌는지 확인할 수 있어야 한다.
단위 테스트는 부품의 기초 체력을 본다. 통합 테스트는 연결 상태를 본다. 종단간 평가는 실제 결과 상태를 본다. 회귀 테스트는 좋아진 척하는 퇴보를 막는다. LLM-as-a-Judge는 정답을 한 줄로 쓰기 어려운 품질을 측정 가능하게 만든다. 평가 데이터셋은 팀이 겪은 실패를 잊지 않게 해 준다.
결국 좋은 평가 하네스는 에이전트를 비판하기 위한 장치가 아니다. 에이전트를 계속 개선할 수 있게 만드는 장치다. 측정이 가능해지면 실패가 구체화되고, 실패가 구체화되면 수정이 가능해진다. 그리고 그때부터 에이전트는 "가끔 놀라운 것"이 아니라 "꾸준히 믿을 수 있는 것"이 된다.
다음 장에서는 이렇게 측정된 결과를 다시 시스템 개선으로 연결하는 구조, 즉 피드백 루프와 자기 수정 구조를 살펴본다. 테스트와 평가가 진단이라면, 피드백 루프는 치료에 가깝다.
참고
1Demystifying evals for AI agents
2How to Test Your AI Agent Harness
3AI agent evaluation: A practical framework for testing multi-step agents
4Agent Harness Engineering Guide [2026]: Evaluating AI Agents in Production
5LLM-as-a-Judge for LLM and Agent Evaluation
6Evaluating AI Agents: Can LLM‑as‑a‑Judge Evaluators Be Trusted?
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.