AI 에이전트 성능 평가를 위한 자체 호스팅 루프 구축 방법

AI 에이전트를 위한 자체 호스팅 평가(evals)란 무엇인가

AI 에이전트를 위한 자체 호스팅 평가는 사용자의 저장소에 직접 보관하는 네 가지 요소로 구성됩니다. 저장된 사례 파일, 에이전트를 실행하는 스크립트, 각 답변을 채점하는 검사 세트, 그리고 쿼리 가능한 결과 테이블입니다. 이 목록 중 벤더가 필요한 항목은 없습니다. 전체 루프는 수백 줄의 Python 코드와 하나의 SQLite 파일로 구현됩니다.

데모에서 에이전트가 잘 작동했던 이유는 사용자가 직접 5개의 입력을 선택했기 때문입니다. 2주 차에 에이전트가 고장 난 이유는 프롬프트 라인 변경, 모델 변경, 또는 도구 설명 변경 때문일 수 있으며, 이를 측정하는 지표가 없었기 때문입니다. 평가 루프를 도입하면 "왠지 성능이 떨어진 것 같다"는 막연한 느낌을 "커밋 4f1c9ab에서 통과율이 60개 중 58개에서 60개 중 51개로 하락했다"는 구체적인 수치로 바꿀 수 있습니다.

이 루프는 네 단계로 진행되며, 이 가이드는 각 단계를 한 섹션씩 다룹니다. 실제 트레이스를 수집하고, 흥미로운 사례를 선별하여 테스트 케이스로 승격시키고, 모든 변경 사항에 대해 각 사례를 채점한 뒤, 해당 결과를 생성한 커밋과 함께 통과율을 저장하는 방식입니다. 이 루프는 에이전트를 어떤 환경에서 실행하든 동일하게 작동하며, 사용할 가치가 있는 자체 호스팅 에이전트 프레임워크 간의 차이는 주로 트레이스 데이터를 얼마나 기본적으로 제공하느냐에 달려 있습니다.

에이전트가 2주 차에 오작동하는 이유

에이전트는 프롬프트, 모델, 도구 정의 세트, 그리고 실행 시점에 검색되는 컨텍스트로 구성됩니다. 이 네 가지 요소는 애플리케이션 코드를 변경하지 않아도 변할 수 있으므로, 일반적인 코드 리뷰에서는 문제를 발견할 수 없습니다.

가장 흔한 원인은 프롬프트 수정입니다. 무례한 답변을 막기 위해 문장 하나를 추가하면, 재테스트하지 않은 입력값에 대해서도 동작이 바뀝니다. 추적 로그를 보면 이는 명확히 드러납니다. 지난주 동일한 질문에 대한 추적에는 create_refund 도구 호출이 포함되어 있었으나, 이번 주 추적에는 호출이 전혀 없고 대신 정중한 사과 문구만 포함되어 있습니다. 오류가 발생하지 않았으므로 알림도 울리지 않습니다.

두 번째 원인은 모델입니다. 모든 실행 시점에 전송한 정확한 모델 문자열을 기록하십시오. 머릿속으로만 기억하는 약칭 대신 claude-haiku-4-5-20251001을 사용해야 합니다. 모델을 교체한 날 성공률이 떨어졌다면, 모델 정보가 데이터 행에 포함되어 있을 때만 원인을 진단할 수 있기 때문입니다.

세 번째 원인은 도구입니다. 도구 설명을 수정하면 모델이 해당 도구를 호출하기로 결정하는 시점이 바뀝니다. 만약 도구가 VPS에서 실행 중인 MCP 서버를 통해 전달된다면, 스키마는 다른 프로세스에 존재하므로 저장소의 diff 변경 없이도 예고 없이 바뀔 수 있습니다. 네 번째 원인은 검색입니다. 동일한 질문이 밤사이에 재구축된 인덱스에 도달하면, 답변은 새로운 문서를 따르게 됩니다.

수집된 트레이스에서 골든 셋 구축하기

평가 케이스를 임의로 만들지 마십시오. 실제 트래픽에서 추출해야 합니다. 이미 에이전트를 위한 자체 호스팅 Langfuse 트레이싱을 운영 중이라면, 모든 요청은 입력값, 도구 호출, 출력값과 함께 저장됩니다. 이것이 바로 평가 케이스에 필요한 원재료입니다.

공개 API를 통해 루트 관측값의 특정 기간 데이터를 내보내십시오. 이 API는 기본 인증(Basic Authentication)을 사용하며, 공개 키를 사용자 이름으로, 비밀 키를 비밀번호로 사용합니다.

export LF_HOST="https://langfuse.example.com"
curl -sS -u "$LF_PUBLIC_KEY:$LF_SECRET_KEY" \
  "$LF_HOST/api/public/v2/observations?limit=50&isRootObservation=true&fromStartTime=2026-07-01T00:00:00Z" \
  | jq '.data[0]'

파싱 코드를 작성하기 전에 레코드 하나를 먼저 읽어보십시오. 행은 data 아래로 반환되지만, 질문과 답변을 담고 있는 필드 이름은 에이전트가 스팬(span)을 어떻게 계측했느냐에 따라 달라집니다. 따라서 예상했던 구조가 아니라 실제로 확인되는 구조에 맞춰 매핑하십시오. 그 후 evals/cases.jsonl 형식에 맞춰 한 줄에 JSON 객체 하나씩 수동으로 케이스를 작성하십시오.

{"id": "refund-double-charge", "tags": ["smoke"], "input": "I was charged twice for order 41822.", "must_call": ["lookup_order", "create_refund"], "must_not_include": ["I cannot help"], "rubric": "The reply confirms exactly one refund for order 41822 and states the amount."}

다음 5가지 규칙을 지켜야 평가 셋의 가치가 유지됩니다.

• 40개에서 80개의 케이스면 시작하기에 충분합니다. 20개 미만일 경우, 불안정한 케이스 하나만으로도 통과율이 5포인트씩 변동하며, 이유 없이 수치가 널뛰는 결과는 무시하게 됩니다.
• 수정하는 모든 프로덕션 버그는 수정 당일에 케이스로 추가하십시오. 이러한 습관이 평가 셋을 올바른 방향으로 성장시킵니다.
• 케이스 하나당 하나의 동작만 검증하십시오. 환불 금액과 말투를 동시에 확인하는 케이스는 실패 시 원인을 파악할 수 없습니다.
• id는 절대 변경하지 마십시오. ID는 오늘 실행한 결과와 지난달 결과를 비교하는 기준이 되기 때문입니다.
• 커밋하기 전에 민감 정보를 삭제하십시오. 이 파일은 git에 저장되므로 고객 이름이나 본인 소유가 아닌 주문 번호는 모두 제거하십시오.

결정론적 검사를 먼저 수행하여 등급을 매기십시오. 비용이 들지 않기 때문입니다.

정답이 명확한 항목은 단순한 단언(assertion)을 사용합니다. 모델 호출이 필요 없으므로 비용이 발생하지 않으며 모호함도 없습니다. 결정론적 검사는 구조적 회귀를 잡아냅니다. 이러한 회귀는 에이전트 주변 시스템을 고장 내는 주원인입니다. 예를 들어 JSON 파싱 실패, 도구 호출 누락, 금지된 문구 포함, 출처 미표기 등이 이에 해당합니다.

단 하나의 함수만이 에이전트에 대해 알고 있어야 합니다. 테스트 환경의 나머지 부분은 모두 범용적이어야 합니다.

import json, os, urllib.request

def run_agent(case):
    req = urllib.request.Request(
        os.environ["AGENT_URL"],
        data=json.dumps({"input": case["input"]}).encode(),
        headers={"content-type": "application/json"},
    )
    with urllib.request.urlopen(req, timeout=120) as resp:
        return json.load(resp)


def deterministic(case, result):
    text = result.get("output", "")
    called = [c["name"] for c in result.get("tool_calls", [])]
    failures = []
    for tool in case.get("must_call", []):
        if tool not in called:
            failures.append(f"tool not called: {tool}")
    for phrase in case.get("must_not_include", []):
        if phrase.lower() in text.lower():
            failures.append(f"forbidden phrase: {phrase}")
    if len(called) > case.get("max_tool_calls", 12):
        failures.append(f"too many tool calls: {len(called)}")
    return failures

도구 사용 예산(tool budget)을 해당 목록에 유지하십시오. 오늘 3번의 호출로 문제를 해결하던 에이전트가 내일 11번의 호출을 한다면, 최종 정답이 맞더라도 이는 회귀입니다. 모든 호출마다 비용이 발생하기 때문입니다.

LLM을 판정자로 활용할 때 발생하는 4가지 오류

어설션(assertion)을 통과한 결과물은 읽을 수 있는 평가자가 필요합니다. LLM 판정자는 두 번째 모델 호출을 의미합니다. 질문, 에이전트의 답변, 그리고 하나의 기준을 입력받아 판결을 내립니다. "답변이 사용자의 질문에 부합하는가"를 평가할 수 있는 유일한 실용적인 방법입니다.

판정자를 유용하게 만드는 4가지 규칙은 다음과 같습니다.

• 1점에서 10점 사이의 점수가 아닌 이진 판정(Binary verdict)을 사용합니다. 점수 척도는 거의 모든 항목에 7점이나 8점을 부여하므로 수치 변화가 없어 아무것도 배울 수 없습니다.
• 호출당 하나의 기준만 적용합니다. 환불 금액에 대해 묻거나 어조에 대해 물어야 하며, 두 가지를 동시에 묻지 마십시오.
• 정답이 있는 경우에는 판정자에게 기대 답변을 제공합니다. 추상적으로 평가하는 것보다 참조 답변을 기준으로 평가하는 것이 훨씬 쉽습니다.
• 출력 형식을 강제하고 엄격하게 파싱합니다.

from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment


def judge_prompt(case, output):
    return (
        "You grade one answer against one criterion.\n"
        "Reply with JSON only, in this exact shape:\n"
        '{"verdict": "pass", "confidence": "high", "reason": "one short sentence"}\n'
        f"Criterion: {case['rubric']}\n"
        f"Question: {case['input']}\n"
        f"Answer: {output}\n"
        "Length is not a criterion. Judge only the criterion above."
    )


def judge(case, output, model):
    msg = client.messages.create(
        model=model,
        max_tokens=200,
        messages=[{"role": "user", "content": judge_prompt(case, output)}],
    )
    return json.loads(msg.content[0].text)

이제 실패 유형을 살펴봅니다. 각 유형은 오늘 오후에 바로 실행해 볼 수 있는 테스트가 있습니다. 검증되지 않은 판정자는 정밀해 보이지만 실제로는 아무 의미 없는 수치를 생성하므로, 이러한 테스트를 수행하는 것은 중요합니다.

길이 편향(Length bias). 답변이 길수록 통과할 확률이 높습니다. 테스트 방법은 다음과 같습니다. 판정자가 실패 처리한 답변 10개를 골라, 새로운 사실은 없지만 자신감 넘치는 문단 2개를 덧붙여 다시 평가하게 합니다. 통과로 결과가 바뀌는 판정은 길이 편향 때문이며, 이 경우 루브릭(rubric)을 수정해야 합니다.

자기 선호(Self-preference). 판정자는 종종 다른 모델 계열의 출력물보다 자신이 속한 모델 계열의 출력물을 더 관대하게 평가합니다. 테스트 방법은 다음과 같습니다. 동일한 답변 30개를 서로 다른 두 모델 계열의 판정자로 평가하고 사례별로 결과를 비교합니다. 의견이 갈리는 사례는 직접 확인하십시오.

위치 편향(Position bias). 판정자를 사용하여 두 답변 A와 B를 비교할 경우, 순서를 바꾸어 다시 실행합니다. 순서를 바꿨을 때 판결이 뒤집힌다면 해당 루브릭으로는 쌍대 비교(pairwise comparison)를 안전하게 수행할 수 없다는 의미입니다.

루브릭 드리프트(Rubric drift). 모호한 기준은 판정자를 무조건 동의하게 만듭니다. "답변이 도움이 되는가"라는 기준은 거의 모든 것을 통과시킵니다. "답변이 환불 금액을 달러로 명시했는가"라는 기준은 의도한 내용만 통과시킵니다. 확인하려는 사실을 명확히 지칭할 때까지 모든 기준을 다시 작성하십시오.

이 4가지 오류를 모두 방지하는 방법이 하나 있습니다. 직접 라벨링한 30개의 사례를 유지하고, 판정자 모델이나 프롬프트를 변경할 때마다 해당 라벨과 비교하여 판정자의 점수를 매기십시오. 10개 사례 중 1개 이상에서 의견이 일치하지 않는다면, 판정자가 내놓는 통과율을 신뢰하기 전에 루브릭을 수정해야 합니다. 판정자는 코드이므로, 코드처럼 버전을 관리하고 검토해야 합니다.

저렴한 모델로 평가하고, 필요하면 최상위 모델로 격상하기

모든 커밋마다 가장 비싼 모델로 평가를 수행하면 평가 비용이 테스트 대상인 에이전트 개발 비용보다 커지게 됩니다. 평가 모델을 가격순으로 배치하고, 결과가 명확해지는 즉시 평가를 중단하십시오.

[
  {
    "label": "Haiku 4.5, Batch API",
    "usd_per_1000_judge_calls": "0.90"
  },
  {
    "label": "Haiku 4.5",
    "usd_per_1000_judge_calls": "1.80"
  },
  {
    "label": "Sonnet 5",
    "usd_per_1000_judge_calls": "3.60"
  },
  {
    "label": "Opus 5",
    "usd_per_1000_judge_calls": "9.00"
  }
]

이 수치는 평가 호출 1회당 입력 토큰 약 1,200개, 출력 토큰 120개를 기준으로 합니다. 이는 질문 1개, 답변 1개, 평가 기준 1개에 대한 현실적인 크기입니다. 1,000건을 평가할 때 Claude Haiku 4.5는 1.80 달러, Claude Opus 5는 9.00 달러가 소요됩니다. 이 차이는 작아 보이지만, 곱셈을 해보면 다릅니다. 60건의 케이스를 매 커밋마다 평가하고 주당 40회 커밋이 발생한다면, 야간 작업(nightly job)을 실행하기도 전에 주당 2,400회의 평가 호출이 발생합니다.

평가 작업에는 두 가지 할인이 적용되며, 중복 적용이 가능합니다. 평가 실행은 대화형이 아니므로 Batch API를 사용하면 비동기 처리를 대가로 입력 및 출력 가격이 절반으로 줄어듭니다(표의 첫 번째 행). 루브릭과 지침은 모든 호출에서 바이트 단위까지 동일하므로 프롬프트 캐싱(prompt caching)이 적합합니다. 캐시 읽기 비용은 기본 입력 가격의 10분의 1이며, 5분 캐시 쓰기는 기본 입력의 1.25배이므로 단 한 번의 히트만으로도 캐시 비용을 회수할 수 있습니다. 위 가격은 2026년 8월 기준 Anthropic 정가이며, Sonnet 5는 2026년 8월 31일까지 도입 가격이 적용되므로 해당 날짜 이후에는 세 번째 막대의 비용이 상승합니다.

평가 단계는 다음과 같습니다:

• 모든 케이스에 대해 결정론적(deterministic) 검사를 수행합니다. API 비용이 전혀 들지 않습니다.
• 해당 검사를 통과한 케이스에 대해서만 소형 모델로 평가합니다.
• 소형 모델이 실패로 판정하거나 낮은 신뢰도로 통과 판정을 내린 경우에만 최상위 모델로 평가합니다.
• 주 1회 소규모 샘플에 대해 사람이 직접 검토합니다.

CHEAP = "claude-haiku-4-5-20251001"
STRICT = "claude-opus-5"


def grade(case, result):
    hard = deterministic(case, result)
    if hard:
        return False, "deterministic", "; ".join(hard)
    first = judge(case, result["output"], CHEAP)
    if first["verdict"] == "pass" and first["confidence"] == "high":
        return True, CHEAP, first["reason"]
    second = judge(case, result["output"], STRICT)
    return second["verdict"] == "pass", STRICT, second["reason"]

이 방식은 평가 정확도를 일부 희생하여 비용을 절감하므로, 막연히 추측하지 말고 그 차이를 측정해야 합니다. 한 달에 한 번씩 전체 케이스를 엄격한 모델로 평가하여 두 결과를 비교하십시오. 만약 소수 이상의 케이스에서 결과가 엇갈린다면, 루브릭이 소형 모델에게 너무 모호한 것이므로 루브릭을 수정해야 합니다. 에이전트 자체의 비용을 제어하는 작업은 별개의 영역이며, VPS에서 AI 에이전트 비용 제어하기에서 다룹니다.

운영 중인 시스템의 통과율을 시간에 따라 추적하기

커밋과 연결할 수 없는 통과율은 단순한 느낌일 뿐입니다. 실행 단위별로 케이스당 한 행씩, 커밋과 모델 정보를 포함하여 저장하십시오.

CREATE TABLE IF NOT EXISTS results (
  run_id      TEXT NOT NULL,
  ran_at      TEXT NOT NULL,
  git_sha     TEXT NOT NULL,
  agent_model TEXT NOT NULL,
  case_id     TEXT NOT NULL,
  passed      INTEGER NOT NULL,
  graded_by   TEXT NOT NULL,
  reason      TEXT
);

SELECT run_id, git_sha, agent_model,
       count(*) AS cases,
       round(100.0 * sum(passed) / count(*), 1) AS pass_pct
FROM results
GROUP BY run_id
ORDER BY ran_at DESC
LIMIT 10;

sqlite3 evals/results.db < evals/schema.sql를 사용하여 스키마를 로드한 다음, sqlite3 -box evals/results.db < evals/passrate.sql으로 추세를 확인하십시오. 60개의 케이스를 매일 1년간 실행하면 약 22,000개의 행이 생성되므로, 저장소 자체가 별도의 프로젝트가 될 일은 없습니다. VPS에서 SQLite를 운영 환경으로 실행하기에서는 이 파일을 여러 머신에서 공유할 때 중요해지는 설정들을 다룹니다.

러너는 사람을 위해 동일한 정보를 출력합니다:

run 2026-08-05T09:14:22Z  sha 4f1c9ab  model claude-sonnet-5  58/60 pass (96.7%)
FAIL refund-double-charge  deterministic: tool not called: create_refund
FAIL pto-policy-question   judge(opus): reply gives no dollar amount

에이전트를 손상시킬 수 있는 변경 사항에 대해 테스트 스위트를 실행하십시오. 이는 저장소의 모든 커밋이 아니라 프롬프트 수정, 모델 변경, 도구 변경을 의미합니다. pre-push 훅은 빠른 하위 집합을 처리합니다:

cat > .git/hooks/pre-push <<'EOF'
#!/bin/sh
python3 evals/run.py --set smoke || exit 1
EOF
chmod +x .git/hooks/pre-push

전체 실행은 시간이 더 걸리므로 일정에 따라 수행해야 합니다. 매일 밤 실행되는 VPS의 systemd 서비스 및 타이머는 배포된 프롬프트를 대상으로 전체 세트를 실행합니다. 이는 호스팅된 도구의 동작 변경과 같이 저장소 외부에서 발생하는 변화를 포착하는 방법입니다.

전수 조사가 아닌 표본 기반의 사람에 의한 검토

판정 모델은 사람이 매긴 라벨을 기준으로 보정되므로, 누군가는 반드시 라벨을 생성해야 합니다. 매주 표본을 읽어 보십시오. 판정 모델이 실패한 모든 사례와 무작위로 선택한 10개의 통과 사례를 포함합니다. 무작위 통과 사례는 매우 중요합니다. 판정 모델이 잘못된 답변을 조용히 통과시키기 시작하면, 모델 자신의 판정 결과를 기반으로 구축된 대시보드에서는 완벽하게 보이기 때문입니다.

사례 15개를 건당 3분씩 검토하면 주당 45분이 소요됩니다. 이 과정에서 귀하와 판정 모델의 의견이 일치하지 않는 부분에 대한 루브릭 수정 사항이 도출되며, 아무도 예상하지 못한 유형의 실패 사례도 새로 발견할 수 있습니다. 사람의 판정 결과를 graded_by을 human로 설정한 동일한 테이블에 기록하십시오. 이렇게 하면 판정 모델과 사람 간의 일치 여부를 기억에 의존하지 않고 쿼리로 확인할 수 있습니다.

평가 도구 자체에서 발생하는 문제

anthropic.RateLimitError 첫 번째 전체 실행 시 발생. 60개의 사례를 한꺼번에 처리하면 현재 티어의 요청 또는 토큰 제한을 초과합니다. 동시성(concurrency)을 4개의 워커로 제한하고, 야간 실행은 Batch API로 옮기십시오.

json.JSONDecodeError: Expecting value: line 1 column 1 (char 0) 판정기(judge)에서 발생. 모델이 산문으로 답변하거나 JSON을 코드 블록으로 감쌌습니다. 한 번 재시도한 뒤, 실패로 기록하십시오. 구문 분석 실패를 통과로 처리해서는 안 됩니다. 오류를 통과로 바꾸는 테스트 스위트는 에이전트의 성능이 저하되는데도 성공률은 100%를 향해 올라가기 때문입니다.

불안정한 사례(Flaky cases). 에이전트가 출력을 샘플링하기 때문에 동일한 입력이 한 번은 통과하고 다음번에는 실패할 수 있습니다. 사례를 삭제하지 말고 세 번 실행하여 통과 비율을 기록하십시오. 세 번 중 두 번 통과하는 사례는 실제 견고성 버그이며, 고객이 이를 발견하게 될 것입니다.

골든 셋(Golden set)의 노후화. 누군가 테스트 스위트를 통과시키기 위해 예상 답변을 수정합니다. evals/cases.jsonl에 대한 변경 사항은 에이전트 코드 변경만큼이나 신중하게 검토해야 합니다. 해당 파일은 귀하가 정의한 올바른 결과의 기준이기 때문입니다.

절대 실패하지 않는 스위트. 한 달 동안 성공률이 100%에 머물러 있다면, 해당 테스트 셋이 제품의 변화를 더 이상 추적하지 못하고 있다는 의미입니다. 최근의 추적(trace) 10개를 가져와 에이전트가 제대로 처리하지 못한 사례를 찾아 추가하십시오. 그런 다음 의도적으로 무언가를 고장 내어 실행 결과가 빨간색(실패)으로 변하는지 확인하십시오. 이것이 뮤테이션 테스트가 테스트 스위트에 적용되는 방식이며, 테스트 셋이 여전히 유효한지 확인할 수 있는 유일한 방법입니다.

FAQ

AI 에이전트 평가 세트에는 몇 개의 사례가 필요한가?

40개에서 80개 사이로 시작하여 실제 실패 사례를 바탕으로 점진적으로 늘려가야 합니다. 사례가 20개 미만이면 불안정한 결과 하나만으로도 통과율이 5%포인트씩 변동하므로 데이터로서의 의미를 잃습니다. 수백 개를 넘어가면 실행할 때마다 비용과 시간이 소모되는 반면, 추가되는 사례가 커버리지에 기여하는 정도는 미미합니다. 중요한 것은 사례의 개수가 아니라, 알려진 운영 환경의 실패 유형이 평가 세트에 최소 한 번 이상 포함되어 있는지 여부입니다.

LLM 판정자가 에이전트를 평가하도록 신뢰할 수 있는가?

직접 작성한 라벨과 비교하여 측정한 후에만 신뢰할 수 있습니다. 직접 평가한 30개의 사례를 유지하고, 판정자 모델이나 프롬프트를 변경할 때마다 해당 사례로 판정자의 점수를 매겨야 합니다. 판정자는 답변이 길수록 더 자주 통과시키는 '길이 편향'과, 같은 모델 계열의 출력을 더 관대하게 평가하는 '자기 선호' 현상을 보입니다. 두 가지 모두 테스트가 가능합니다. 실패한 답변에 내용을 덧붙여 다시 판정하게 하거나, 다른 계열의 모델을 판정자로 사용하여 동일한 답변을 평가해 보십시오. 판정자가 10개 사례 중 1개 이상에서 본인의 라벨과 다른 결과를 낸다면, 평가 기준이 너무 모호한 것입니다.

어떤 모델로 평가를 수행해야 하는가?

저렴한 모델로 먼저 평가하고 필요시 상위 모델로 넘어가야 합니다. 결정론적 단언(deterministic assertion)은 비용이 들지 않으므로 모든 사례에 대해 가장 먼저 실행합니다. 명확한 통과 사례는 작은 모델로 처리합니다. 실패했거나 신뢰도가 낮은 판정 결과만 최상위 모델로 보냅니다. 2026년 8월 정가 기준으로 1,000개의 사례를 평가하는 데 Claude Haiku 4.5는 약 1.80 달러, Claude Opus 5는 약 9.00 달러가 소요됩니다. 평가 실행은 비동기적으로 이루어지므로 Batch API를 사용하면 비용을 절반으로 줄일 수 있습니다.

평가가 운영 모니터링을 대체할 수 있는가?

아니요, 두 가지는 서로 다른 질문에 답하기 때문입니다. 평가 세트는 배포하려는 변경 사항이 고정된 사례 세트에 대해 성능을 개선하는지 혹은 악화시키는지를 알려줍니다. 추적(tracing)과 모니터링은 실제 사용자가 현재 무엇을 겪고 있는지, 즉 어떤 사례에도 포함되지 않은 입력값까지 포함하여 알려줍니다. 이 둘은 상호 보완적입니다. 추적 데이터는 새로운 사례를 제공하고, 평가 세트는 수정 사항이 실제로 효과가 있었는지 판단합니다.