LLM 에이전트 평가 파이프라인 — golden set 구축부터 LangSmith·Phoenix 운영까지

핵심 요약

LLM 에이전트는 매주 프롬프트·모델·도구가 바뀐다. 회귀 테스트 없이 운영하면 "어제는 됐는데 오늘은 안 된다"의 늪에 빠진다. 6개월간 사내 코드 리뷰 에이전트를 운영하며 정립한 평가 파이프라인을 정리한다.

• 골든셋: 손으로 만든 80~200개 케이스 + 운영 트래픽에서 자동 수집한 1,000개
• 채점: 정답 비교·LLM-as-judge·룰 기반의 3중 채점
• 회귀 감시: 매 PR마다 100케이스 실행, P50 정확도 -2%p면 머지 차단

1. 골든셋 설계 — 적은 수가 더 강하다

"많을수록 좋다"는 함정이다. 1,000개를 대충 만들면 80개를 잘 만든 것보다 못하다. 골든셋 조건:

• 실패한 운영 케이스가 70% 이상 차지 — 진짜로 어려운 케이스
• 각 케이스는 왜 어려운지 라벨링 (멀티홉 추론, 도구 선택, 모호한 지시 등)
• 3개월마다 30% 교체 — 모델이 학습해 쉬워진 케이스 정리

// golden-set.jsonl 한 줄 예시
{
  "id": "code-review-042",
  "tags": ["security", "auth"],
  "input": {
    "diff": "...",
    "instruction": "보안 이슈만 짚어라"
  },
  "expected": {
    "must_mention": ["jwt secret hardcoded", "SQL injection"],
    "must_not_mention": ["style preferences"]
  },
  "difficulty": "hard"
}

2. 3중 채점 — 어떤 평가자도 완벽하지 않다

3개 점수의 가중 평균이 최종 점수. 단일 채점자에 의존하면 그 채점자의 편향이 곧 시스템 편향이 된다.

3. LangSmith vs Phoenix — 무엇이 다른가

회사 정책상 트레이스가 외부로 못 나가는 곳은 Phoenix가 사실상 유일한 선택. 그 외엔 LangSmith의 UX가 압도적으로 좋다.

4. CI 통합 — PR마다 회귀 감시

# .github/workflows/eval.yml
name: agent-eval
on: pull_request
jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pnpm install
      - run: pnpm tsx scripts/run-eval.ts --suite=quick --max=100
      - uses: actions/upload-artifact@v4
        with: { name: eval-report, path: eval-report.json }
      - run: pnpm tsx scripts/eval-gate.ts eval-report.json

eval-gate.ts는 main 브랜치 베이스라인과 비교해 P50 정확도 -2%p, P95 응답시간 +30% 중 하나라도 위반하면 exit 1.

5. 운영 트래픽 자동 수집

실패 케이스가 진짜 골든셋이다. 운영 트래픽에서 자동 수집:

• 사용자가 "다시 답해줘" / 부정 피드백 누른 경우
• 도구 호출 5회 이상 (헤매는 신호)
• 응답 길이 P99 초과 (이상치)

if (feedback === 'thumbs_down' || toolCalls > 5) {
  await captureToGoldenCandidates({
    input: req.input,
    output: res.output,
    trace_id: trace.id,
    auto_label: 'failure_candidate',
  })
}

주 1회 사람이 검토 → 골든셋 편입 여부 결정.

6. LLM-as-judge 정밀도 올리기

판정 LLM도 평가해야 한다. 사람이 매긴 100개 케이스와 LLM 판정의 일치율을 측정.

판정엔 Sonnet 4.7이 ROI 최적. CoT(Chain of Thought) 강제하면 +2%p 가능하지만 비용 2배.

7. 흔한 함정

• 골든셋이 너무 쉽다: 정확도 95% 찍히고도 운영에서 무너진다. 진짜 어려운 케이스만 남겨라.
• 판정 LLM이 응답 LLM과 같다: 자기 답을 자기가 채점 → 점수 부풀림. 반드시 다른 계열로.
• 평가가 너무 느려 안 돌린다: 1,000케이스 30분 넘으면 아무도 안 돌린다. 빠른 100개 + 야간 풀.
• 점수만 보고 트레이스 안 본다: 점수가 같아도 추론 경로가 다르면 다른 시스템.

참고

• docs.smith.langchain.com — datasets & evaluators
• github.com/Arize-ai/phoenix — OTel-native evals
• Anthropic Cookbook evaluating-claude.ipynb