AI 에이전트 (AI agents)를 구축할 때, 무작위로 테스트하기 쉽습니다.

프롬프트 (prompt)를 변경합니다.
에이전트를 한 번 실행합니다.
답변이 더 좋아 보입니다.

그래서 시스템이 개선되었다고 생각합니다.

하지만 LLM 기반 시스템은 그렇게 단순하게 작동하지 않습니다.

하나의 사례를 개선하는 변경 사항이 다른 사례를 조용히 망가뜨릴 수 있습니다.
그것이 바로 에이전트 평가 (agent evaluation)에 구조가 필요한 이유입니다.

"이 출력 하나가 더 좋아 보이나요?"라고 묻는 대신,

더 나은 질문은 다음과 같습니다:
"이 변경 사항이 동일한 테스트 케이스 (test cases) 세트 전체에서 에이전트를 개선했는가?"
이것이 바로 평가 주도 개발 (evaluation-driven development)의 핵심 아이디어입니다.

간단한 평가 루프 (A simple evaluation loop)

기본적인 평가 루프는 다음과 같습니다:
데이터셋 (dataset) 큐레이션
→ 한 가지 변경 사항 적용
→ 실험 실행
→ 출력물 평가
→ 결과 비교
→ 회귀 (regressions) 수정

목표는 오직 느낌 (vibes)에만 의존하는 것을 멈추는 것입니다.
무엇이 변했는지, 무엇이 개선되었는지, 그리고 무엇이 망가졌는지 알고 싶어 합니다.

1단계: 데이터셋 큐레이션 (Curate a dataset)

작은 테스트 케이스 데이터셋으로 시작하세요.

거대할 필요는 없습니다.

시작 단계에서는 10개에서 25개의 강력한 사례만으로도 유용할 수 있습니다.
에이전트의 경우, 테스트 케이스에는 다음이 포함될 수 있습니다:

• 사용자 입력 (user input)
• 예상되는 도구 (expected tool)
• 예상되는 파라미터 (expected parameters)
• 예상되는 출력 (expected output)
• 엣지 케이스 (edge cases)
• 실패 사례 (failure cases)

예시:
입력:
"주문 번호 #1234의 상태를 확인할 수 있나요?"

예상되는 도구:
order_status_check

예상되는 파라미터:
order_number = 1234

이것은 안정적인 기준선 (baseline)을 제공합니다.
데이터셋이 없으면 모든 테스트는 주관적이 됩니다.

2단계: 각 변경 사항을 실험으로 추적하기 (Track each change as an experiment)

테스트 케이스를 확보했다면, 모든 변경 사항을 실험처럼 취급하세요.

다음과 같은 것들을 변경할 수 있습니다:
시스템 프롬프트 (system prompt)
라우터 프롬프트 (router prompt)
도구 설명 (tool descriptions)
모델 (model)
메모리 전략 (memory strategy)
검색 로직 (retrieval logic)
기술 구조 (skill structure)

그런 다음 동일한 데이터셋을 다시 실행합니다.

이는 다음 질문에 답하는 데 도움이 됩니다:
"이 변경 사항이 실제로 에이전트를 개선했는가?"

단순히 다음과 같은 질문이 아니라 말입니다:
"하나의 출력이 더 좋아 보였는가?"

Step 3: 적절한 평가자(Evaluator)를 사용하세요

에이전트의 각기 다른 부분에는 서로 다른 평가자가 필요합니다.
코드 기반 평가 (Code-based evals)

코드 기반 평가 (Code-based evals)는 규칙이 명확할 때 유용합니다.

예시:
JSON이 유효한가?
에이전트가 올바른 도구 (tool)를 호출했는가?
올바른 파라미터 (parameter)를 추출했는가?
SQL이 읽기 전용 (read-only) 상태를 유지했는가?
생성된 코드가 실행되었는가?
출력이 예상 값과 일치하는가?

이러한 방식은 더 결정론적 (deterministic)이기 때문에 좋습니다.

코드로 신뢰성 있게 확인할 수 있다면, 코드를 가장 먼저 사용하세요.

*LLM-as-a-judge (판단자로서의 LLM): *

LLM-as-a-judge는 출력물에 대한 품질 판단이 필요할 때 유용합니다.
예시:
요약이 명확한가?
답변이 근거에 기반하였는가 (grounded)?
응답에 환각 (hallucination)이 있는가?
실제 질문에 답변하였는가?
올바른 개체 (entity)를 식별하였는가?
최종 답변이 사용자에게 유용한가?

이는 단순한 규칙만으로는 충분하지 않을 때 도움이 됩니다.
하지만 LLM 판단자가 완벽한 것은 아닙니다. 그들 또한 틀릴 수 있습니다.

따라서 가능한 경우 명확한 라벨 (label)을 사용하세요:
정확함 (correct) / 부정확함 (incorrect)
근거 있음 (grounded) / 근거 없음 (not grounded)
유용함 (useful) / 유용하지 않음 (not useful)
안전함 (safe) / 안전하지 않음 (unsafe)

필요하지 않은 경우 모호한 점수 (score)는 피하세요.

인간 평가 (Human evaluation)

다음과 같은 작업의 경우 인간 평가가 여전히 중요합니다:
중요도가 높은 (high-stakes)
주관적인 (subjective)
도메인 특화적인 (domain-specific)
안전에 민감한 (safety-sensitive)
사용자 신뢰와 직결된 (tied to user trust)

때로는 인간 검토자나 사용자 피드백이 여전히 최고의 신호일 수 있습니다.
인간이 매긴 라벨은 향후 평가 데이터셋 (eval dataset)의 일부가 될 수도 있습니다.

Step 4: 퇴보 (Regressions)를 확인하세요

평가가 잡아낼 수 있는 가장 유용한 것 중 하나는 퇴보 (regression)입니다.
퇴보란 이전에 잘 작동하던 것이 이제는 고장 난 것을 의미합니다.

예시:
최종 응답 스타일을 개선했습니다.
하지만 이제 라우터 (router)가 잘못된 도구를 더 자주 선택합니다.

평가가 없다면, 당신은 더 나아진 글쓰기만을 알아차릴 수도 있습니다.
평가가 있다면, 다음과 같이 말할 수 있습니다:
응답 품질은 향상되었습니다.
3개의 테스트 케이스에서 라우터 정확도가 하락했습니다.

그것은 유용합니다.
다음에 무엇을 수정해야 할지 알려주기 때문입니다.

5단계: 평가자(Evaluator) 또한 평가하세요

이 부분은 놓치기 쉽습니다.

여러분의 평가자 또한 평가가 필요합니다.

예를 들어, 라우터(Router)가 올바른 도구(Tool)를 선택했는지 확인하기 위해 LLM-as-a-judge를 사용한다고 가정해 봅시다.

만약 올바른 도구에 대한 정답(Ground truth)을 이미 가지고 있다면, LLM 판사(LLM judge)를 그것과 비교할 수 있습니다.

이는 다음 질문에 답하는 데 도움이 됩니다:
내 LLM 판사가 실제로 신뢰할 수 있는가?

명확한 사례의 경우, 코드 기반 평가(Code-based evals)가 기준점 역할을 할 수 있습니다.
그다음 LLM 판사가 이에 동의하는지 확인할 수 있습니다.
LLM-as-a-judge가 유용하긴 하지만 100% 정확하지는 않기 때문에 이 과정은 중요합니다.

좋은 실험이 보여주어야 하는 것

좋은 평가(Eval) 결과는 하나 이상의 점수를 보여주어야 합니다.

다음 사항들을 보여주어야 합니다:
무엇이 변했는가
어떤 데이터셋(Dataset)이 사용되었는가
어떤 평가자(Evaluator)가 사용되었는가
어떤 테스트 케이스(Test cases)가 통과했는가
어떤 테스트 케이스(Test cases)가 실패했는가
어디에서 회귀(Regressions)가 발생했는가
다음에 무엇을 수정해야 하는가

예시:
실험:
라우터 프롬프트(Router prompt) 업데이트

결과:
도구 선택(Tool choice)이 70%에서 85%로 향상됨

회귀(Regression):
기존 3개 사례에서 파라미터 추출(Parameter extraction) 실패

이는 다음과 같이 말하는 것보다 훨씬 낫습니다:
에이전트(Agent)의 느낌이 더 좋아졌다.

이것이 중요한 이유

에이전트는 작고 다양한 방식으로 실패할 수 있습니다.
프롬프트 업데이트가 답변 품질은 향상시킬 수 있지만 도구 선택(Tool choice)을 망가뜨릴 수 있습니다.
모델 변경이 추론(Reasoning)은 개선할 수 있지만 지연 시간(Latency)을 증가시킬 수 있습니다.

새로운 도구 설명(Tool description)이 환각(Hallucination)을 줄일 수 있지만 파라미터 추출(Parameter extraction)을 악화시킬 수 있습니다.

구조화된 실험 없이는 이러한 변화를 추적하기 어렵습니다.
구조화된 평가(Structured evals)가 있다면 실패 원인을 더 명확하게 이해할 수 있습니다.

테스트 케이스를 만드세요.
한 번에 하나의 변경 사항만 적용하세요.
동일한 데이터셋을 실행하세요.
적절한 평가자 (Evaluator)를 사용하세요.
결과를 비교하세요.
퇴보 (Regressions)를 포착하세요.
그다음 증거를 바탕으로 개선하세요.
다음 에이전트 변경을 시도하기 전에 이렇게 해보세요:
10개의 테스트 프롬프트를 저장하세요.
변경 전과 후에 이를 실행하세요.
도구 선택 (Tool choice), 최종 답변 품질, 단계 수 (Step count), 그리고 실패 사례를 추적하세요.

느낌 (Vibes)에 의존하는 것보다 작은 평가 세트 (Eval sets)를 갖는 것이 더 낫습니다.