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는 기본 인증을 사용하며, 공개 키를 사용자 이름으로, 비밀 키를 비밀번호로 사용합니다.

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 아래로 반환되지만, 질문과 답변이 담긴 필드 이름은 에이전트가 스팬을 어떻게 계측했는지에 따라 달라집니다. 따라서 예상했던 구조가 아니라 실제로 확인되는 구조에 맞춰 매핑하십시오. 그 후 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."}

골든 셋의 가치를 유지하기 위한 다섯 가지 규칙입니다.

• 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 비용이 전혀 발생하지 않습니다.
• 검사를 통과한 사례에 대해서만 소형 모델로 평가합니다.
• 소형 모델이 실패로 판단하거나 낮은 신뢰도로 통과시킨 경우에만 고성능 모델(frontier judge)을 사용합니다.
• 주 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개의 케이스를 동시에 실행하면 사용 중인 티어의 요청 또는 토큰 제한을 초과하게 됩니다. 동시성을 4개의 워커로 제한하고, 야간 실행은 Batch API로 전환하십시오.

json.JSONDecodeError: Expecting value: line 1 column 1 (char 0) 평가자(judge)로부터 발생. 모델이 산문으로 응답하거나 JSON을 코드 블록으로 감싸는 경우입니다. 한 번 재시도한 뒤, 그래도 실패하면 해당 케이스를 오류로 기록하십시오. 구문 분석 실패를 통과로 처리해서는 안 됩니다. 오류를 통과로 간주하는 테스트 스위트는 에이전트의 성능이 저하되더라도 통과율이 100%에 수렴하게 만들기 때문입니다.

불안정한(Flaky) 케이스. 에이전트가 출력을 샘플링하기 때문에 동일한 입력이 실행마다 통과하거나 실패할 수 있습니다. 케이스를 삭제하는 대신 3번 실행하여 성공 비율을 기록하십시오. 3번 중 2번 통과하는 케이스는 실제 견고성 버그이며, 고객이 이를 발견하게 될 것입니다.

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

절대 실패하지 않는 스위트. 통과율이 한 달 동안 100%에 머물러 있다면, 해당 테스트 셋이 더 이상 제품의 변화를 추적하지 못하고 있다는 의미입니다. 최근의 트레이스 10개를 추출하여 에이전트가 제대로 처리하지 못한 사례를 찾아 테스트 셋에 추가하십시오.

FAQ

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

40개에서 80개 사이로 시작하여 실제 실패 사례를 바탕으로 세트를 확장하십시오. 20개 미만의 사례에서는 불안정한 결과 하나가 통과율을 5포인트나 변동시키므로, 수치가 정보로서의 가치를 잃습니다. 수백 개를 넘어가면 모든 실행에 실제 비용과 시간이 소요되지만, 추가되는 사례가 제공하는 커버리지는 미미합니다. 중요한 것은 사례의 개수가 아니라, 알려진 운영 환경의 실패 유형 중 몇 퍼센트가 평가 세트에 최소 한 번 이상 포함되어 있는가입니다.

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

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

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

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

평가가 운영 모니터링을 대체하는가?

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