10월 7일 수요일

운영 로그를 다음 배포의 품질 신호로 쓰려면 무엇을 기록하고, 무엇을 의심해야 하는가?

에이전트 품질 루프의 출발점은 최종 답변이 아니라 도구 호출, 입력과 출력, 중간 판단을 포함한 전체 trace다. 그러나 trace가 많다는 사실은 곧 관측 가능성을 뜻하지 않는다. 이미 알고 있는 실패는 코드 기반 score나 LLM judge로 좁혀 보고, 아직 분류하지 못한 사용자 의도와 조용한 실패는 전처리, facet, 요약, embedding, topic map을 거쳐 발견해야 한다. 여기서 얻은 대표 사례를 dataset과 offline eval로 되돌리면 production이 development를 갱신하는 순환이 생긴다. 문제는 그 순환의 보상 신호 자체도 틀릴 수 있다는 점이다. 유창한 에이전트의 자기 보고를 판사가 그대로 믿으면 실제 환경에서는 실패했는데 성공으로 세고, 그 오류가 평가·학습 데이터·강화학습 보상까지 전파된다. 따라서 관측 계층은 실패 후보를 찾는 역할과 성공 여부를 증명하는 역할을 분리해야 한다.

1. 01

   수집보다 먼저 정할 계측 경계

   trace 일부가 빠지면 그 구간은 블랙박스가 된다. 루트 응답뿐 아니라 어떤 도구가 어떤 순서와 입력으로 호출됐는지, 중간 span과 결과가 무엇이었는지를 남겨야 한다. offline score는 배포 전 회귀를, online score는 실제 traffic의 알려진 실패를 측정한다. score는 한 번 켜 두는 설정이 아니라 에이전트와 함께 계속 보정해야 하며, 새 시스템에서는 높은 sampling으로 신호를 확보한 뒤 정보량과 비용에 따라 낮추는 정책이 필요하다.

2. 02

   미지의 실패를 평가 항목으로 승격하는 경로

   Topics는 score가 미리 이름 붙이지 못한 사용자 의도, 감정, 기능 요구, silent failure를 찾는다. 운영 trace를 작은 표현으로 줄이고 facet과 embedding으로 묶은 뒤, 반복되는 record lookup failure 같은 사례를 새 score와 dataset으로 승격한다. 이때 자동 분석이 바로 코드 변경으로 뛰어들어서는 안 된다. SQL로 대표 trace를 좁히고 eval에서 변경 전후와 regression을 비교한 뒤, 사람이 PR의 근거와 영향을 검토해야 관측이 대시보드 소비로 끝나지 않는다.

3. 03

   판정기를 다시 판정하는 증거 설계

   웹 에이전트 검증에서는 작업에서 직접 파생한 겹치지 않는 루브릭을 만들고, 기준마다 관련 화면 증거를 골라 에이전트의 주장과 실제 상태를 대조해야 한다. 과정 점수와 최종 결과를 분리하면 품절이나 로그인 벽처럼 통제 불가능한 차단은 과정에서 인정하면서도 목표 미달을 성공으로 꾸미지 않는다. 앞 단계 오류를 뒤 단계의 정확한 수행까지 연쇄 감점하지 않는 것도 보상 신호의 정밀도를 지킨다. 사람 라벨 역시 개발 세트와 홀드아웃으로 나눠 검증기의 과적합을 확인해야 한다.

4. 04

   같은 숫자라도 의미가 다른 이유

   Fara 7B의 동일한 WebVoyager 궤적은 공식 판정에서 성공률 74%, 증거 중심 Universal Verifier에서 38%로 평가됐다. 이 36%포인트 차이는 모델이 달라서가 아니라 성공의 증거를 세는 방법이 달라서 생겼다. Universal Verifier는 인간 라벨과의 Cohen's kappa가 0.58이었고, 150개 궤적 중 50개를 개발에 쓰고 100개를 홀드아웃으로 보류했다. 수치는 검증기 자체의 평가 절차와 함께 읽어야 보상 함수로 사용할 수 있다.

실전 아키텍처는 trace 수집, 알려진 실패용 score, 미지의 패턴용 topic, 상태 증거를 확인하는 verifier, 홀드아웃 인간 라벨을 한 계층으로 뭉개지 않는다. 자동화는 실패 사례를 찾아 eval과 변경 후보로 연결하되, 판정 기준·증거 선택·회귀 결과를 사람이 검토할 수 있게 남겨야 한다. 품질 루프의 병목은 로그 양이 아니라 신뢰할 수 있는 신호와 그 신호를 다시 검증하는 경계다.