10월 19일 월요일

비결정적인 에이전트가 실제 작업을 끝냈고 변경 뒤에도 품질을 유지한다고 무엇으로 증명할 것인가?

검증의 출발점은 에이전트가 ‘완료했다’고 말한 문장이 아니라 실제 제품 상태다. 앱별 CLI나 브라우저 계측으로 사용자 경로를 실행하고 저장 상태·네트워크·부작용을 검사한 뒤, 결과를 코드 리비전에 묶은 영수증으로 남긴다. 하지만 영수증은 정의된 조건만 증명한다. 그래서 실행 전체를 보여주는 트레이스와 출력 품질을 판단하는 평가가 필요하다. 값의 일치나 필수 필드는 코드로 검사하고, 의미·근거·행동 가능성은 좁은 질문의 LLM 심판으로 보완하며, 도메인 전문가는 골든 라벨과 새 실패 모드를 제공한다. 이렇게 모은 능력 평가를 동일 입력 실험과 회귀 테스트, CI 게이트, 프로덕션 감시로 이어야 변경의 효과와 한계를 설명할 수 있다.

1. 01

   리비전에 묶인 완료 영수증

   검증 함수는 사용자 경로를 실제로 실행하고 PASS, FAIL, 판단 불가를 구분해야 한다. 판단 불가는 통과가 아니다. 실패 응답에는 원인과 다음 행동을 구조화해 에이전트가 수정 루프를 돌 수 있게 한다. 결과 영수증에는 검사한 조건과 대상 리비전을 기록하고 코드가 바뀌면 폐기한다. 스크린샷도 어떤 경로와 상태에서 만들어졌는지 연결되지 않으면 증거가 약하다. 기능 지도에 검증 범위를 명시하면 한 번도 검사하지 않은 영역까지 신뢰를 과장하는 일을 줄일 수 있다.

2. 02

   트레이스는 경로를, 평가는 기준 충족을 본다

   에이전트는 초기 도구 선택의 작은 오류가 뒤 단계로 전파된다. 트레이스에는 입력, 모델 호출, 도구와 인자, 검색 결과, 출력, 비용과 지연을 연결해 어느 단계가 원인인지 남긴다. 그 위에 평가는 결과와 각 span의 행동을 나눠 본다. 형식과 티커 일치처럼 결정적인 조건은 값싼 코드 평가가 적합하고, 충실성이나 행동 가능성처럼 문맥이 필요한 항목은 각각 별도의 LLM 심판으로 다룬다. 하나의 거대한 점수는 실패 원인을 숨기므로 운영 조치와 연결되는 작은 지표가 낫다.

3. 03

   평가자도 골든 데이터에서 시험한다

   LLM 심판의 숫자는 정답표가 아니다. 사람과 심판에게 같은 기준을 적용하고, 전문가가 판정한 대표 사례를 개발용과 테스트용으로 나눠 일치뿐 아니라 편향과 경계 사례를 확인한다. 자료의 16개 표본에서 일부 심판은 최신 자료를 확인할 수 없다는 이유로 모든 결과를 부정확하다고 판정했고, 이는 평가 설명과 원본 트레이스를 함께 읽어야 하는 이유다. 운영 초기에 적은 표본으로 방향을 잡을 수 있지만, 릴리스 결정을 위해서는 입력 분포와 위험을 반영한 더 넓은 데이터가 필요하다.

4. 04

   한 변수씩 바꾸고 CI에서 회귀를 차단한다

   프롬프트, 모델, 컨텍스트, 도구를 동시에 바꾸면 점수 변화의 원인을 알 수 없다. 대표 데이터셋을 고정한 뒤 한 변수를 바꾸고 같은 평가를 반복한다. 안정된 능력은 회귀 평가로 승격하고 최소 임계값을 CI에 둔다. 비결정적 실행에서는 여러 번 중 한 번 성공하는 기준과 매번 성공해야 하는 기준을 위험에 맞게 구분한다. 배포 뒤에는 실제 트래픽에서 새 실패를 찾아 데이터셋에 되돌린다. 규제 업무라면 정책 위반, 개인정보 처리, 실제 도구 실행 여부 같은 하드 리밋을 별도 가드레일로 둔다.

신뢰할 수 있는 에이전트 배포는 단일 테스트 도구의 선택이 아니다. 앱이 제공하는 관측 레버, 재현 가능한 영수증, 실행 트레이스, 서로 다른 평가기, 전문가 판정, CI와 운영 피드백이 하나의 루프를 이뤄야 한다. 각 층은 자신이 검사하지 않은 것을 증명한다고 주장해서는 안 된다. 완료 증거가 특정 리비전과 데이터셋, 평가 기준에 연결되어 있을 때 사람은 코드 전체를 다시 읽지 않고도 변경을 승인하거나 중단할 근거를 얻는다.