#Agent 평가의 핵심 기준 — Outcome과 Trajectory

← 전체 목차 · 이전: Agent가 20초 멈췄다면 — Trace와 Span으로 여는 관측성 · 다음: 답은 전부 맞는데 몰래 DB를 지웠다면 — 결과·경로 이중 평가

Agent가 대화창에서 "예약 성공"이라고 말하는 것과, 실제로 데이터베이스에 주문 한 건이 생성된 것은 완전히 다른 일이다.

평가는 혼동해서는 안 되는 두 차원으로 쪼개진다.

• Outcome(최종 결과) — 현실 세계의 상태가 바뀌었는지만 인정하는, 일도양단의 판정.
• Trajectory(궤적) — 모델 응답, 도구 호출, 에러와 재시도를 기록하며 "왜 성공했나" "왜 망했나"의 복기만 담당.

둘은 서로 보완하며 어느 쪽도 다른 쪽을 대체할 수 없다.

#Outcome: 현실 세계가 어떻게 바뀌었는가

위치는 일도양단이다 — 작업 완수 여부는 오직 이것이 결정한다.

#Trajectory: Agent가 지나온 궤적

1. 모델이 어떻게 응답했는가
2. 어떤 도구를 호출했는가
3. 중간에 에러가 났는가
4. 에러 후 스스로 어떻게 교정·재시도했는가

역할은 성패 판정이 아니라 복기다. Agent가 왜 성공했는지, 또는 왜 망쳤는지를 설명한다.

Outcome     → 「성공 여부」를 관장  → 판정용
Trajectory  → 「왜」를 관장         → 복기용
서로 보완하며 어느 쪽도 대체 불가

Outcome만 보면 실패한 건 알지만 어디를 고쳐야 할지 모르고, Trajectory만 보면 "그럴싸한" 가짜 궤적에 속아 넘어간다.

#가장 밟기 쉬운 함정: 같은 작업을 한 번만 테스트하는 것

같은 작업은 절대 한 번만 테스트해서는 안 되고, 여러 번(여러 Trial) 돌려야 한다. 대규모 모델에는 변동성이 있기 때문이다.

• 한 번에 성공 → 순전히 운이 좋았을 수 있다
• 한 번에 실패 → 능력 부족이 아니라 마침 네트워크가 막혔을 수 있다

#여러 번 돌린 뒤 통계 낼 네 지표

이 넷이 있어야 **"이번 모델 업그레이드, 프롬프트 수정이 진짜 안정적인 향상을 가져왔다"**고 당당히 말할 수 있다.

#채점 방식은 작업 유형에 따라 나눈다

일률적으로 처리하면 안 된다.

#1. 결과가 명확한 작업(정답이 있는 것) — 하드 규칙으로 자른다

판정 경로:
  바로 코드 테스트
  또는 DB를 조회해 데이터가 있는지 확인
  → 하드 규칙으로 자르면 된다

#2. 개방형 작업 — 평가 척도 + 대규모 모델 심판 + 사람 캘리브레이션

카피라이팅처럼 절대적 정답이 없는 유형은 3단계다.

0. 평가 척도(rubric)를 도입
1. 더 똑똑한 대규모 모델을 심판으로 세워 척도에 따라 채점
2. 사람이 정기적으로 표본 검사해 캘리브레이션 — 모델 심판의 헛소리 방지

2단계가 관건이다. 모델 심판도 헛소리를 하므로 사람의 표본 검사는 선택 사항이 아니라 상설 동작이다.

#과정 리스크: 밟으면 안 되는 레드라인 3종

이 셋은 모두 Outcome이 발견할 수 없다 — 작업은 여전히 "성공"일 수 있지만 과정에서 이미 사고가 났으므로 궤적에서만 조회할 수 있다.

#다만 리스크 방지 ≠ 빡빡한 통제: 레드라인만 지키고 우회는 허용한다

• Agent가 매번 당신이 규정한 것과 똑같은 단계로 가도록 요구하지 말 것
• 그것이 안전 레드라인을 밟지 않고, 최종적으로 일을 해냈다면
• 중간에 조금 돌아갔더라도 허용해야 한다

즉 제약의 대상은 레드라인과 결과이지 경로가 아니다.

#핵심 통찰

1. "성공했다고 말하는 것"과 "성공인 것" 사이에는 현실 세계 조회 한 번이 놓여 있다 — Agent의 출력은 자연어이므로 실패를 성공으로 포장하는 능력을 천연으로 갖고 있고, 능숙한 상담원처럼 포장할수록 더 위험하다. 응답을 읽는 데서 멈추는 평가는 피시험자에게 자기 답안을 채점하게 하는 것과 같다. 판정권은 Agent가 바꿀 수 없는 곳 — 데이터베이스, 파일 시스템, 프로세스 종료 코드 — 에 있어야 한다.
2. 평가는 "판정"과 "설명" 두 층으로 쪼개야 하고 합쳐서는 안 된다 — 궤적을 판정으로 쓰면 "그럴싸함"에 속고, 판정만 남기고 궤적을 버리면 실패해도 어디를 고칠지 모른다.
3. 한 번의 결과는 하나의 관측이 아니라 한 번의 표본 추출이다 — 성공은 우연일 수 있고 실패는 네트워크 지연일 수 있다. 단일 결과를 결론으로 삼는 것은 표본 수 1의 실험으로 판단을 내리는 것이다.
4. "향상"은 사건이 아니라 통계량이다 — 모델 업그레이드와 프롬프트 수정의 효과는 반복 실행으로 얻은 평균 성공률, Token 비용, 평균 인터랙션 라운드 수, 오류 분포에서만 드러난다. 엔지니어링 신뢰도의 출처는 직관이 아니라 통계다.
5. 채점 방법은 작업의 "판정 가능성"을 따라가야 한다 — 정답이 있는 작업에는 하드 규칙이 가장 싸고 믿을 만하며, 모델 심판을 쓰는 것은 낭비이자 노이즈 유입이다. 절대적 정답이 없는 작업은 하드 규칙을 아예 쓸 수 없어야 척도와 모델 심판 차례가 온다. 방법을 잘못 고르는 것이 방법이 없는 것보다 나쁘다.
6. 모델 심판 자체도 평가받아야 하는 컴포넌트다 — 사람의 정기 표본 검사가 필요하다는 것은 평가 시스템도 드리프트하며 캘리브레이션 루프가 필요하다는 뜻이다.
7. 과정 리스크는 Outcome의 사각지대이므로 별도 판정 기준을 세워야 한다 — 금지 도구 호출, 데이터 월권, 비용 폭주 상황에서 작업은 여전히 "완수"되고 Outcome은 초록불이다. 안전과 비용은 결과 지표 아래에 매달 수 없고 궤적에서 독립적으로 조회해야 한다.
8. 경로를 제약하는 것과 레드라인을 제약하는 것은 완전히 다른 관리 방식이다 — Agent가 고정 단계를 따르게 요구하면 그것을 하드코딩된 스크립트로 강등시키는 것이고, Agent를 쓰는 이유 자체를 포기하는 것이다. 올바른 방법은 안전 레드라인을 긋고 그 안에서는 돌아가는 것을 허용하되 최종적으로 일을 해내게 하는 것이다.

#엔지니어링 실전 Tips

• 판정 근거는 Agent가 손댈 수 없는 곳에 둘 것: Outcome 검사를 설계할 때 먼저 물을 것 — 이 증거를 Agent가 스스로 위조할 수 있는가?
• 궤적에는 "에러가 났는지"만이 아니라 "에러 후 어떻게 했는지"를 기록할 것: 자가 치유 과정은 "운이 좋았던 것"과 "진짜 능력이 있는 것"을 구분하는 핵심 증거이며, 에러 코드만 기록해서는 보이지 않는다.
• 정답이 있는 문제에 모델 심판을 쓰지 말 것: 하드 규칙으로 자를 수 있으면 하드 규칙으로 자를 것. 모델 심판은 비싸고 헛소리도 하며, 개방형 작업에서만 존재 가치가 있다.
• 평가 척도가 심판보다 먼저 존재해야 한다: 척도 없는 모델 채점은 주관적 인상 점수이며 버전 간 비교가 불가능하다.
• 사람의 표본 검사는 일회성이 아니라 주기적으로: 출시 전에 한 번 하는 것이 아니라 리듬 안에 편성할 것.
• 비용을 통계 지표만이 아니라 레드라인 지표로도 쓸 것: Token 비용은 네 통계량 중 하나이면서 동시에 과정 리스크의 레드라인(9,900원 커피 vs 100만 원 예산)이기도 하다. 전자는 추세를 보고 후자는 일표 부결이므로 두 용도를 섞지 말 것.
• "하면 안 되는 것"과 "요구할 필요 없는 것"을 구분할 것: 안전 레드라인은 하드 제약이고 실행 단계는 소프트하다. 단계까지 하드 제약으로 쓰는 것이 이런 시스템에서 가장 흔한 과잉 설계다.