발표에서 확인된 핵심 사실

가상 심판(LLM-as-a-Judge)을 골든 데이터셋으로 보정해 인간과의 일치도를 높이는 작업만으로는 비결정적 출력과 도구 호출의 연쇄 실패를 완전히 통제할 수 없다. 이러한 제약을 해결하기 위해 평가를 사후 검증이 아닌 핵심 엔지니어링 규율로 격상시킨 평가 주도 개발(EDD, Evaluation-Driven Development)을 도입했다. 평가 기준을 먼저 세우고 그에 맞춰 시스템을 개선하는 방식으로 개발 공정을 재편해 성능의 예측 가능성을 높인다.

EDD는 실제 운영 중 발견된 오류를 다시 평가 기준으로 전환해 지속적으로 검사하는 체계다. 출시 목표와 통과 게이트를 먼저 정의하고, 최종 단계에 인간 의사결정자를 두어 품질을 확정하는 구조를 갖춘다. 검색과 추론 과정에서 발생하는 복잡한 실패 사례를 평가 항목으로 정교화해 개발 단계에서 미리 걸러낸다.

프로덕션 환경에서는 매일 비식별화된 실사용 트래픽의 5%를 표본 추출해 프로그램 검사와 가상 심판을 실행한다. 문제가 표시된 출력은 즉시 인간 검토로 보내며, PM(Product Manager, 제품 관리자)이 매주 결과를 검토한다. 여기서 발굴한 새로운 실패 유형을 다시 평가 항목에 반영해 시스템 개선으로 연결하는 루프를 가동하며 평가 데이터셋을 실시간으로 확장한다.

로봇 학습 데이터 병목을 겨냥한 해법

50~100개의 골든 데이터셋은 가상 심판의 신뢰도를 결정하는 기준점이 된다. 특히 의도적으로 포함한 나쁜 사례들을 통해 가상 심판이 인간 평가자와 80% 후반에서 90%대까지 일치하도록 보정한다. 불일치 정도는 Cohen’s kappa(두 평가자 간 일치도를 측정하는 지표)나 Krippendorff’s alpha(다양한 데이터 유형의 일치도를 측정하는 지표)로 산출한다. 목표 수치에 도달할 때까지 프롬프트와 퓨샷 예제를 반복해서 수정하며 평가 기준을 정교화한다. 인간의 판단 로직을 가상 심판에게 이식해 대규모 데이터 평가의 객관성을 확보하는 단계다.

최종 답변의 정답 여부만으로는 에이전트 시스템의 내부 결함을 완전히 찾아낼 수 없다. 잘못된 추론 경로가 정답이라는 결과 뒤에 숨겨질 때 시스템의 신뢰도는 낮아진다. 정답을 맞혔더라도 추론 경로가 틀렸거나 도구 매개변수가 부정확해 우연히 정답에 도달한 경우가 발생하기 때문이다. 이를 위해 실행 추적(trace, 전체 실행 과정의 기록)과 스팬(span, 특정 작업 단위의 구간)을 재구성해 중간 과정을 전수 검사한다. 하위 에이전트 호출 시점과 도구 선택, 매개변수 및 중간 상태를 트리 순회 방식으로 추적해 비효율적인 실행 경로를 식별한다. 결과값이 아닌 과정의 무결성을 검증해 시스템의 안정성을 높인다.

결정론적 검사, LLM 심판(LLM-as-a-Judge)

명백한 실패를 걸러내는 코드 기반 검사와 미묘한 품질을 측정하는 모델 기반 평가 중 무엇을 우선할지는 검증 대상의 성격에 따라 갈린다. Airbnb는 프로그램 검사와 휴리스틱을 첫 번째 필터로 배치해 명백한 실패 사례를 먼저 제거한다. 이후 LLM 심판(LLM-as-a-Judge, 거대언어모델이 다른 모델의 출력을 평가하는 방식)이 어조나 일관성 같은 미묘한 품질을 검사한다. 인간은 정답 데이터를 구축하거나 고위험 영역의 기준을 세우고, 자동 평가기 간의 불일치를 해결하는 최종 심판 역할을 수행한다.

출력의 비결정성과 판단의 주관성 때문에 전통적인 소프트웨어 테스트 방식은 그대로 적용되지 않는다. 검색, 추론, 도구 호출, 생성으로 이어지는 각 단계가 독립적으로 실패할 수 있는 구조적 특성 때문이다. 평가 모델 자체의 실패 가능성까지 고려해야 하는 복합적인 검증 환경이 형성된다.

모델 교체나 프롬프트 수정 시에는 한 번에 하나의 변수만 변경하고, 50~100개의 골든 데이터셋을 구축해 Cohen’s kappa(코헨의 카파, 두 평가자 간 일치도를 측정하는 지표) 또는 Krippendorff’s alpha(크리펜도르프 알파, 다수 평가자의 신뢰도를 측정하는 지표)로 일치도를 측정하며 가상 심판을 보정한다.