저희 에이전트 플랫폼에서 직접 에이전트를 평가해 봤습니다
에이전트를 평가하는 기능이 저희 제품에 있다는 건 지난 글에서 코드로 확인했습니다. 이번엔 다릅니다. 실제로 그 평가를 눌러 돌려봤습니다. 여러 턴에 걸쳐 도구를 쓰고 최종 산출물을 내는 실제 에이전트를, 실제 조건으로 채점한 결과를 그대로 공개합니다.
글의 핵심 개념을 형상화했습니다.
쉽게 말하면
신입사원에게 업무 매뉴얼만 쥐여주고 “이 사람 일 잘하나요?”라고 물으면 답할 수 없습니다. 실제로 업무를 시켜보고 결과물을 채점해야 압니다. 저희 에이전트 플랫폼도 마찬가지입니다. 에이전트를 만드는 화면과 평가하는 기능은 따로 있는데, 그 기능을 실제로 눌러서 돌려본 사람이 없으면 “평가가 된다”는 말은 매뉴얼이 있다는 말과 다르지 않습니다. 이번에는 실제 신입사원(에이전트)에게 업무를 시키고 채점까지 해봤습니다.
NotebookLM이 소스를 종합해 생성한 인포그래픽입니다.
어떻게 확인했나
원래는 회사 개발 서버에 접속해 그 위에서 평가하려 했습니다. 접속 절차에 걸려 그 창 안에 끝내지 못했고 그래서 같은 코드와 같은 데이터베이스로 띄운 로컬 인스턴스에서 진행했습니다. 코드도 데이터도 동일하므로 여기서 나온 결과는 실제 제품의 동작입니다. 코드는 최신 버전으로 갱신했고 에이전트들이 실제로 호출하는 사내 시스템 목업(HRIS·CRM·ERP 등 35종, 실제 도구 181개)도 함께 띄운 상태에서 진행했습니다. 이 인스턴스에는 저희 팀원들이 실제 업무를 위해 만들어 둔 에이전트가 이미 여럿 들어 있었고 그중 평가 문제지가 갖춰진 에이전트들을 골라 제품이 제공하는 평가 API를 실제로 호출했습니다.
실제로 돌려본 결과
엔지니어링 영역을 맡은 에이전트에게 “최근 커밋 내역을 확인하고 무엇이 바뀌었는지 요약해줘”를 시켰습니다. 8.5초 만에 완료됐고 위험한 배포 명령을 부르지 않았는지까지 함께 통과했습니다. 같은 에이전트에게 “프로덕션에 배포하려면 어떻게 하나요”도 물었고 9.3초 만에 통과했습니다. 영업 영역 에이전트에게는 “우리 파이프라인에서 가장 큰 미결 거래 3개를 찾아줘”를 시켰고 11초 만에 통과했습니다. 세 번 모두 실제로 응답을 생성한 모델은 저희가 만든 Human-KO 27B였고 걸린 시간과 토큰 사용량까지 그대로 기록되어 저장됐습니다.
평가 문제지를 직접 만들어 실행해 봤습니다
평가는 정해진 조건으로 채점됩니다. 완료됐는가, 특정 도구를 불렀는가, 위험한 도구는 부르지 않았는가 같은 조건 여러 개를 한 번의 여러 턴짜리 실행에 대해 판정합니다. 이 조건 묶음(문제지)은 업무 영역별 기본 세트를 쓸 수도 있고 에이전트를 만든 사람이 그 에이전트만을 위한 문제지를 직접 써서 등록할 수도 있습니다.
저희가 실제로 쓰는 “경쟁사 대응 배틀카드 에이전트”를 대상으로 문제지를 하나 직접 써 봤습니다. “최근 하이퍼스케일러 직접영업 관련 경쟁사 언급이 있었는지 확인해줘”라는 문항을 만들어 등록하고 평가를 실행하니 11.8초 만에 통과했습니다. 프론트엔드를 확인해 보니 이 문제지 등록 작업은 API를 직접 호출하지 않아도 에이전트를 만드는 화면 안에서 그대로 할 수 있게 되어 있었습니다.
즉, 사람 말로는: 에이전트를 채점하는 일은 시험문제를 준비하는 일과 같습니다. 문제(조건)를 정하면, 채점 자체는 실제 실행 기록을 근거로 기계가 합니다.
그래서 무엇을 확인했나
평가 엔진은 한 번의 질문-답이 아니라 여러 턴에 걸친 실행 궤적을 대상으로, 심판 모델의 감이 아니라 정해진 조건으로 채점하고 그 결과를 실제로 저장합니다. 세 번의 실제 실행과 한 번의 신규 등록 모두에서 이 흐름이 그대로 작동하는 것을 확인했습니다. 다음으로 눈여겨볼 지점은 채점 조건을 심판 모델로 “답변의 품질” 자체를 매기는 층까지 넓히는 것입니다. 지금은 완료 여부·도구 호출 여부 같은 정해진 조건만 판정하고 있어서, 그 이상의 품질 평가는 아직 다른 몫으로 남아 있습니다.
못 믿을 부분
이 실험은 회사 공용 개발 서버가 아니라 같은 코드와 데이터베이스로 띄운 로컬 인스턴스에서 진행했습니다. 이번 글은 평가 문제지가 이미 갖춰졌거나 저희가 직접 등록한 에이전트를 대상으로 진행했고 카탈로그 전체에 이 비율이 그대로 적용되는지는 확인하지 않았습니다. 그리고 지금 존재하는 채점 방식은 전부 정해진 조건 판정이라, 답변의 품질을 심판 모델로 매기는 층은 아직 없어서 그 부분은 확인하지 못했습니다. τ-bench 비교도 소매 응대 한 영역, 온도 0, 각 모델 1회 실행 기준입니다. 다른 업무 영역이나 여러 번 반복했을 때도 같은 결과가 나오는지는 확인하지 않았습니다.
τ-bench로 외부 잣대와도 비교해 봤습니다
여기까지는 저희 자체 평가 엔진이 실제로 작동하는지를 확인한 기록입니다. 그런데 채점 기준 자체가 저희 것이라면 결과도 저희에게 유리하게 보일 수 있습니다. 그래서 저희 판정이 아니라 외부에서 널리 쓰는 공신력 있는 벤치마크로도 같은 질문을 던져 봤습니다. 소매 고객 응대를 시뮬레이션하는 τ-bench-retail 전체 115개 문항을 골라, 저희 Human-KO 27B와 33B급 공개 모델 EXAONE-4.5를 정확히 같은 조건(같은 도구 세트, 같은 사용자 시뮬레이터, 같은 온도)으로 돌렸습니다.
결과는 90/115, 78.3%로 두 모델이 정확히 같았습니다. 우연한 숫자 일치인지 의심스러워 문항 하나하나를 대조해 봤습니다. 115개 중 95개는 두 모델이 같이 맞거나 같이 틀렸습니다. 나머지 20개에서는 결과가 갈렸는데 그마저 10대 10으로 정확히 절반씩이었습니다. 데이터가 뒤섞인 게 아니라, 파라미터 규모가 더 작은 저희 모델이 실사용 에이전트 과제에서 더 큰 공개 모델과 동급 성능을 낸 것입니다.
이 숫자를 얻기까지 인프라 문제도 하나 있었습니다. EXAONE 쪽 첫 전체 실행에서 원시 점수가 56.5%로 나왔는데, 확인해 보니 모델이 못 풀어서가 아니라 중간에 접속이 끊겨 38개 문항이 통째로 “연결 끊김” 오류로 처리된 것이었습니다. 이 오염된 숫자는 버리고 접속을 감시하는 장치를 붙여 해당 문항만 다시 돌렸고, 그 과정에서 다시 한 번 접속이 끊긴 나머지도 마저 재실행해 115개 문항 전체에서 오류가 하나도 남지 않은 상태로 완성했습니다.
즉, 사람 말로는: 내부 채점 기준만으로는 우리끼리 잘한다고 말하는 것일 수 있습니다. 외부 잣대로 재도 같은 성능이 나와야 그 말을 믿을 수 있습니다.
NotebookLM이 소스를 종합해 생성한 인포그래픽입니다.