이 장은 지능형 에이전트가 자신의 성능을 체계적으로 평가하고, 목표 달성 진행 상황을 모니터링하며, 운영상의 이상 징후를 감지할 수 있게 하는 방법론을 다룹니다.
먼저 앞선 장들과의 경계를 분명히 해둡니다.
11장에서는 목표 설정과 모니터링을, 17장에서는 추론 메커니즘을 다루는 데 비해, 이 장은 에이전트의 효과, 효율, 요구사항 준수 여부를 지속적으로 측정하는 데 초점을 맞추는데, 이는 대개 외부에서 이루어진다.
이 측정에는 지표를 정의하고, 피드백 순환 구조를 마련하며, 보고 체계를 구현해 운영 환경에서 에이전트 성능이 기대 수준에 부합하도록 하는 작업이 포함됩니다.
실제 적용 및 활용 사례
| 분야 | 무엇을 측정하는가 |
|---|---|
| 실 운영 시스템 성능 추적 | 프로덕션 환경에 배포된 에이전트의 정확도, 지연 시간, 자원 소모량을 지속 모니터링한다(예: 고객 서비스 챗봇의 문제 해결률, 응답 시간) |
| 에이전트 개선을 위한 A/B 테스팅 | 서로 다른 에이전트 버전이나 전략을 병렬로 체계적으로 비교하여 최적의 접근법을 찾는다(예: 물류 에이전트에 두 가지 계획 수립 알고리즘을 적용해 보는 경우) |
| 규정 준수 및 안전 감사 | 에이전트가 윤리 지침, 규제 요건, 안전 프로토콜을 시간이 지나도 얼마나 잘 준수하는지 추적하는 자동화된 감사 보고서를 생성한다. 사람(휴먼 인 더 루프)이나 다른 에이전트가 검증할 수 있으며, KPI를 산출하거나 문제 발견 시 알림을 보낼 수 있다 |
| 기업 시스템 | 기업 시스템에서 에이전틱 AI를 관리·통제하려면 새로운 제어 수단인 AI “계약(Contract)” 이 필요하다. 이 조정 가능한 계약은 AI에게 위임된 작업의 목표, 규칙, 통제 항목을 명문화한다 |
| 드리프트 탐지 | 시간이 지나도 에이전트의 출력이 적절하거나 정확한지 지속 모니터하고, 입력 데이터 분포의 변화(개념 드리프트, concept drift) 나 환경 변화로 인해 성능이 저하되는 시점을 감지한다 |
| 에이전트 행동의 이상 탐지 | 비정상적이거나 예상 밖의 동작을 식별한다. 이는 오류, 악의적 공격, 또는 의도치 않게 나타난 바람직하지 않은 행동의 신호일 수 있다 |
| 학습 진행도 평가 | 학습하도록 설계된 에이전트의 경우, 학습 곡선, 특정 기술의 향상 정도, 다양한 작업이나 데이터 세트에 대한 일반화 능력을 추적한다 |
책은 평가와 모니터링의 모범 사례를 5단계 피라미드로 정리합니다.
╱╲
╱01╲ 명확하고 측정 가능한 목표와 지표를 정의
╱────╲
╱ 02 ╲ 정량적 데이터와 정성적 데이터를 함께 활용
╱────────╲
╱ 03 ╲ 데이터를 정기적이고 일관되게 수집
╱────────────╲
╱ 04 ╲ 에이전트에게 보상과 인센티브를 제공
╱────────────────╲
╱ 05 ╲ 평가 및 모니터링을 위한 모범 사례
╱────────────────────╲
그림 19.1 평가와 모니터링 모범 사례
실습 코드 예제
시작하기 전에 책은 솔직하게 범위를 좁힙니다.
AI 에이전트를 위한 포괄적 평가 프레임워크를 만드는 일은, 복잡성만 놓고 보면 하나의 학문 분야나 대형 출판물에 맞먹을 만큼 까다롭다. 모델 성능, 사용자 상호작용, 윤리적 문제, 더 넓은 사회적 영향까지 고려해야 할 요소가 많기 때문이다.
그래서 실제 구현 단계에서 빼놓을 수 없는 핵심 사용 사례로 범위를 좁혀 살펴봅니다.
에이전트 응답 평가 — 그리고 단순 비교의 한계
에이전트가 주어진 입력에 대해 적절하고, 올바르며, 논리적이고, 편향이 없고, 정확한 정보를 제공하는지 판단하는 과정입니다. 평가 지표에는 사실 정확성, 유창성, 문법적 정밀도, 사용자 의도 부합도 등이 포함될 수 있습니다.
def evaluate_response_accuracy(agent_output: str, expected_output: str) -> float:
"""에이전트 응답의 단순 정확도 점수를 계산한다."""
# 아주 단순한 문자열 완전 일치 방식이며, 실제 환경에서는 더 정교한 지표를 사용해야 한다
return 1.0 if agent_output.strip().lower() == expected_output.strip().lower() else 0.0
# 사용 예시
agent_response = "The capital of France is Paris."
ground_truth = "Paris is the capital of France."
score = evaluate_response_accuracy(agent_response, ground_truth)
print(f"Response accuracy: {score}")
이 예시가 중요한 이유는 잘 작동해서가 아니라 실패하기 때문입니다.
공백을 제거하고 소문자로 변환하더라도 이 두 문자열은 동일하지 않다. 그 결과, 두 문장이 같은 의미를 전달하는데도 이 함수는 정확도 점수를 0.0으로 잘못 반환한다.
단순 비교 방식은 의미적 유사성을 평가하기에 역부족이며, 에이전트의 응답이 기대 출력과 정확히 일치할 때만 성공합니다. 더 효과적으로 평가하려면 문장 간 의미를 파악하는 고급 자연어 처리 기법이 필요합니다.
| 정교한 지표 | 무엇을 보는가 |
|---|---|
| 레벤슈타인 거리 / 자카드 유사도 | 문자열 유사도를 측정한다 |
| 키워드 분석 | 특정 키워드의 존재 여부를 분석한다 |
| 의미적 유사도 | 임베딩 모델을 활용한 코사인 유사도 기반으로 측정한다 |
| LLM 심사자 평가 | 미묘한 정확성과 유용성을 평가한다(뒤에서 자세히 다룸) |
| RAG 전용 지표 | 충실도(faithfulness)와 관련성(relevance) 같은 지표 |
지연 시간 모니터링
에이전트 동작의 지연 시간 모니터링은 AI 에이전트의 응답이나 동작 속도가 핵심인 애플리케이션에서 특히 중요합니다. 지연 시간이 길어지면 사용자 경험과 에이전트의 전반적 성능에 부정적인 영향을 미칠 수 있으며, 특히 실시간 또는 대화형 환경에서 그러합니다.
실무에서 중요한 단서가 하나 붙습니다.
실무에서는 지연 시간 데이터를 단순히 콘솔에 출력하는 것만으로는 충분하지 않다. 이 정보를 영구 저장 시스템에 기록하는 것이 바람직하다.
| 저장 방식 | 예시 |
|---|---|
| 구조화된 로그 파일 | JSON |
| 시계열 데이터베이스 | InfluxDB, Prometheus |
| 데이터 웨어하우스 | Snowflake, BigQuery, PostgreSQL |
| 관측 가능성 플랫폼 | Datadog, Splunk, Grafana Cloud |
LLM 상호작용의 토큰 사용량 추적
LLM 기반 에이전트의 경우, 비용 관리와 자원 배분 최적화를 위해 토큰 사용량 추적이 중요합니다. LLM 상호작용 과금은 처리한 토큰(입력 및 출력) 수에 따라 결정되는 경우가 많으므로, 토큰을 효율적으로 사용하면 운영 비용을 직접 줄일 수 있습니다. 또한 토큰 수를 모니터링하면 프롬프트 엔지니어링이나 응답 생성 과정에서 개선할 수 있는 영역을 파악하는 데 도움이 됩니다.
# 실제 토큰 수 계산은 LLM API에 따라 달라지므로, 이 클래스는 개념 설명용 구현이다
class LLMInteractionMonitor:
def __init__(self):
self.total_input_tokens = 0
self.total_output_tokens = 0
def record_interaction(self, prompt: str, response: str):
# 실제 시나리오에서는 LLM API의 토큰 카운터나 토크나이저를 사용한다
input_tokens = len(prompt.split()) # 임시 대체값
output_tokens = len(response.split()) # 임시 대체값
self.total_input_tokens += input_tokens
self.total_output_tokens += output_tokens
print(f"Recorded interaction: Input tokens={input_tokens}, Output tokens={output_tokens}")
def get_total_tokens(self):
return self.total_input_tokens, self.total_output_tokens
# 사용 예시
monitor = LLMInteractionMonitor()
monitor.record_interaction("What is the capital of France?", "The capital of France is Paris.")
monitor.record_interaction("Tell me a joke.", "Why don't scientists trust atoms? Because they make up everything!")
input_t, output_t = monitor.get_total_tokens()
print(f"Total input tokens: {input_t}, Total output tokens: {output_t}")
16장의 자원 최적화가 무엇을 줄일지의 문제였다면, 이 모니터는 줄인 것이 실제로 줄었는지를 확인하는 장치입니다.
LLM 심사자를 활용한 “유용성” 맞춤 지표
AI 에이전트의 “유용성(helpfulness)” 같은 주관적 품질을 평가하는 일은 표준 객관 지표만으로는 다루기 어렵습니다. 한 가지 유력한 프레임워크는 LLM을 평가자로 활용하는 방식입니다.
이 LLM 심사자 접근법은 사전에 정의된 “유용성” 기준에 따라 다른 AI 에이전트의 출력을 평가한다. LLM의 고급 언어 능력을 활용하면 단순 키워드 매칭이나 규칙 기반 평가를 넘어서는, 사람에 가까운 섬세한 평가가 가능하다. 아직 발전 중인 기법이지만, 정성적 평가를 자동화하고 확장하는 가능성을 보여 준다.
책의 예제는 법률 설문 문항의 품질을 평가합니다. 핵심은 상세한 평가 기준(Rubric) 입니다.
당신은 법률 설문 방법론 전문가이자 엄격한 법률 검토자입니다.
주어진 법률 설문 문항의 품질을 평가하는 것이 당신의 과제입니다.
전반적인 품질에 대해 1점에서 5점 사이의 점수를 부여하고,
상세한 근거와 구체적인 피드백을 함께 제시하십시오.
1. **명확성 및 정밀성 (1-5점):**
* 1점: 극히 모호하고, 중의적이거나 혼란스러움
* 3점: 어느 정도 명확하나 더 정밀하게 다듬을 여지가 있음
* 5점: 완벽히 명확하고, 중의적이지 않으며, 법률 용어(해당 시)와 의도가 정밀함
2. **중립성 및 편향 (1-5점):**
* 1점: 매우 편향적이거나 유도 질문의 성격이 강해, 응답자를 특정 답변으로 명백히 이끔
* 3점: 특정 답을 암시하거나 유도 질문으로 해석될 여지가 있음
* 5점: 완전히 중립적이고 객관적이며, 특정 답변을 유도하는 표현이나 편향된 용어가 전혀 없음
3. **관련성 및 초점 (1-5점):**
* 1점: 명시된 설문 주제와 무관하거나 범위를 벗어남
* 3점: 관련성은 있으나, 질문의 초점을 더 또렷하게 다듬을 여지가 있음
* 5점: 설문 목적에 긴밀하게 관련되어 있으며, 단일 개념에 분명하게 초점이 맞춰져 있음
4. **완결성 (1-5점):**
* 1점: 정확한 응답에 필요한 핵심 정보가 누락되었거나 맥락이 불충분함
* 3점: 대체로 완전하나 세부 사항이 일부 빠져 있음
* 5점: 응답자가 충실히 답변하는 데 필요한 모든 맥락과 정보를 제공함
5. **대상 독자 적합성 (1-5점):**
* 1점: 대상 독자가 이해하기 어려운 전문 용어를 사용하거나 전문가에게는 지나치게 단순함
* 3점: 대체로 적절하나 일부 용어가 어렵거나 지나치게 단순화되었을 수 있음
* 5점: 대상 설문 응답자의 법률 지식과 배경에 완벽히 맞춤화되어 있음
**출력 형식:**
응답은 반드시 다음 키를 포함하는 JSON 객체여야 합니다:
* `overall_score`: 1~5 사이의 정수
* `rationale`: 해당 점수를 부여한 이유를 주요 강점과 약점을 중심으로 간결하게 요약
* `detailed_feedback`: 각 기준에 대한 피드백을 글머리 기호로 상세히 기술. 구체적인 개선 방안을 제안할 것
* `concerns`: 법률적, 윤리적, 방법론적 우려 사항 목록
* `recommended_action`: 간략한 권장 조치(예: "중립성을 위해 수정 필요", "현재 상태로 승인", "범위 명확화 필요")
심사자 클래스는 이렇게 구성됩니다.
import google.generativeai as genai
import os, json, logging
from typing import Optional
class LLMJudgeForLegalSurvey:
"""생성형 AI 모델을 사용하여 법률 설문 문항의 품질을 평가하는 클래스."""
def __init__(self, model_name: str = 'gemini-1.5-flash-latest', temperature: float = 0.2):
"""
Args:
model_name (str): 사용할 제미나이 모델 이름.
'gemini-1.5-flash-latest'는 속도와 비용 면에서 권장된다.
'gemini-1.5-pro-latest'는 최고 품질을 제공한다.
temperature (float): 생성 temperature. 결정론적 평가를 위해 낮은 값이 적합하다.
"""
self.model = genai.GenerativeModel(model_name)
self.temperature = temperature
def _generate_prompt(self, survey_question: str) -> str:
"""LLM 심사자에게 전달할 전체 프롬프트를 생성한다."""
return f"{LEGAL_SURVEY_RUBRIC}\n\n---\n**평가 대상 법률 설문 문항:**\n{survey_question}\n---"
def judge_survey_question(self, survey_question: str) -> Optional[dict]:
"""LLM을 사용하여 단일 법률 설문 문항의 품질을 평가한다."""
full_prompt = self._generate_prompt(survey_question)
try:
logging.info(f"Sending request to '{self.model.model_name}' for judgment...")
response = self.model.generate_content(
full_prompt,
generation_config=genai.types.GenerationConfig(
temperature=self.temperature,
response_mime_type="application/json"
)
)
# 콘텐츠 조정 등의 이유로 빈 응답이 반환되었는지 확인한다.
if not response.parts:
safety_ratings = response.prompt_feedback.safety_ratings
logging.error(f"LLM response was empty or blocked. Safety Ratings: {safety_ratings}")
return None
return json.loads(response.text)
except json.JSONDecodeError:
logging.error(f"Failed to decode LLM response as JSON. Raw response: {response.text}")
return None
except Exception as e:
logging.error(f"An unexpected error occurred during LLM judgment: {e}")
return None
주목할 설정이 둘입니다. temperature=0.2 로 결정론적 평가에 가깝게 하고, response_mime_type="application/json" 으로 구조화된 응답을 강제합니다. 빈 응답(안전 필터에 의한 차단)과 JSON 디코딩 실패를 각각 구분해서 처리하는 점도 실무적입니다.
테스트 케이스는 세 종류입니다.
# --- 좋은 예시 ---
good_legal_survey_question = """
스위스의 현행 지식재산권법이 새롭게 등장하는 AI 생성 콘텐츠를 적절히 보호하고 있다는
의견에 어느 정도 동의하십니까? 단, 해당 콘텐츠가 연방대법원이 확립한 독창성 기준을
충족한다고 가정합니다.
(하나를 선택하십시오: 매우 동의하지 않음, 동의하지 않음, 중립, 동의함, 매우 동의함)
"""
# --- 편향된/부적절한 예시 ---
biased_legal_survey_question = """
FADP와 같이 지나치게 제한적인 개인정보 보호법이 스위스의 필수적인 기술 혁신과
경제 성장을 저해하고 있다는 데 동의하십니까?
(하나를 선택하십시오: 예, 아니오)
"""
# --- 모호한/불명확한 예시 ---
vague_legal_survey_question = """
리걸 테크(Legal Tech)에 대해 어떻게 생각하십니까?
"""
평가 방법의 장단점
| 평가 방법 | 장점 | 단점 |
|---|---|---|
| 인간 평가 | 미묘한 행동까지 포착할 수 있다 | 확장이 어렵고, 비용과 시간이 많이 들며, 주관적인 인적 요소를 고려해야 한다 |
| LLM 심사자 | 일관적이고 효율적이며 확장 가능하다 | 중간 단계가 간과될 수 있다. LLM 자체의 능력에 좌우된다 |
| 자동화 지표 | 확장 가능하고 효율적이며 객관적이다 | 전체 역량을 포착하는 데 한계가 있을 수 있다 |
LLM 심사자의 단점 — “중간 단계가 간과될 수 있다” — 가 바로 다음 절의 출발점입니다.
에이전트 활동 궤적
에이전트의 활동 궤적(trajectory) 은 꼭 평가해야 한다. 전통적인 소프트웨어 테스트만으로는 충분하지 않기 때문이다. 일반적인 코드는 예측 가능한 합격/불합격 결과를 내놓지만, 에이전트는 확률적으로 동작하므로 최종 출력뿐 아니라 에이전트의 활동 궤적 — 즉 해답에 도달하기까지 거치는 단계의 연쇄 — 에 대한 정성적 평가가 필요하다.
멀티 에이전트 시스템은 평가가 더욱 어렵습니다. 개별 성능을 넘어 의사소통과 협업의 효과를 측정하는 정교한 지표를 개발해야 하고, 환경 자체도 정적이지 않으므로 테스트 케이스를 포함한 평가 방법도 시간이 지남에 따라 적응해야 합니다.
정답 기준 궤적과 비교하기
예를 들어 고객의 제품 문의를 처리하는 에이전트라면 이상적인 궤적은 이렇습니다.
의도 파악 → 데이터베이스 검색 도구 사용 → 결과 검토 → 보고서 생성
에이전트의 실제 동작을 이 기대 경로, 즉 정답 기준(ground truth) 활동 궤적과 비교하여 오류와 비효율을 식별합니다. 비교 방법은 여섯 가지입니다.
| 비교 방법 | 기준 |
|---|---|
| 정확 일치(exact match) | 이상적 순서와 완전히 일치해야 한다 |
| 순서 일치(in-order match) | 올바른 동작이 순서대로 수행되기만 하면 되고, 추가 단계도 허용한다 |
| 순서 무관 일치(any-order match) | 올바른 동작이 어떤 순서로든 포함되면 된다 |
| 정밀도(precision) | 예측된 동작의 적절성을 측정한다 |
| 재현율(recall) | 필수 동작이 얼마나 포착되었는지를 측정한다 |
| 단일 도구 사용(single-tool use) | 특정 동작의 수행 여부를 확인한다 |
지표 선택은 에이전트의 구체적인 요구사항에 따라 달라지는데, 결과의 중요성이 크고 실수의 대가도 큰 시나리오에서는 정확 일치가 필요할 수 있고, 더 유연한 상황에서는 순서 일치나 순서 무관 일치를 사용할 수 있다.
테스트 파일과 평가 세트
AI 에이전트를 평가하는 방식은 크게 두 가지입니다.
① 테스트 파일 — JSON 형식으로 단일하고 단순한 에이전트-모델 상호작용(또는 세션) 을 나타냅니다. 개발이 한창 진행 중인 단계에서 단위 테스트에 쓰기 좋은데, 실행이 빠르고 세션 구조가 단순하기 때문입니다. 각 테스트 파일에는 여러 턴으로 구성된 단일 세션이 들어 있고, 턴이란 사용자의 질의, 기대 도구 사용 활동 궤적, 중간 에이전트 응답, 최종 응답을 포함하는 하나의 사용자-에이전트 상호작용을 말합니다.
예를 들어 "침실의 device_2를 끄세요" 라는 사용자 요청에 대해 에이전트가 location: Bedroom, device_id: device_2, status: OFF 등의 매개변수로 set_device_info 도구를 사용하는 것을 명시하고, "device_2의 상태를 끔으로 설정했습니다" 라는 기대 최종 응답을 정의할 수 있습니다. 테스트 파일은 폴더별로 정리할 수 있으며, 평가 기준을 정의하는 test_config.json 파일을 포함할 수도 있습니다.
② 평가 세트(evalset) 파일 — “evalset” 이라는 데이터 세트를 활용하여 상호작용을 평가하며, 복잡한 멀티 턴 대화를 시뮬레이션하고 통합 테스트에 적합한, 경우에 따라 길어질 수 있는 여러 세션을 포함합니다. 평가 세트 파일은 여러 개의 “eval”로 구성되고, 각 eval은 하나 이상의 “턴”을 가진 개별 세션을 나타냅니다.
예를 들어 사용자가 먼저 "무엇을 할 수 있나요?" 라고 묻고 이어서 "10면 주사위를 두 번 굴린 다음 9가 소수인지 확인해 주세요" 라고 말하는 세션을 포함하면서, 기대되는 roll_die 도구 호출과 check_prime 도구 호출, 그리고 주사위 결과와 소수 확인을 요약하는 최종 응답을 정의할 수 있습니다.
멀티 에이전트 — 팀 프로젝트를 평가하듯이
여러 에이전트로 구성된 복잡한 AI 시스템을 평가하는 일은 팀 프로젝트를 평가하는 것과 매우 비슷하다. 단계와 핸드오프가 많아 복잡하지만, 바로 그 점이 장점이 되기도 한다. 각 단계마다 작업 품질을 점검할 수 있기 때문이다.
개별 에이전트가 맡은 작업을 얼마나 잘 수행하는지뿐 아니라 시스템 전체가 얼마나 잘 작동하는지도 함께 평가해야 합니다. 7장의 멀티 에이전트 협업에 던져야 할 질문이 넷입니다.
① 에이전트들이 효과적으로 협력하고 있는가? ‘항공편 예약 에이전트’가 항공편을 확보한 뒤 올바른 날짜와 목적지를 ‘호텔 예약 에이전트’에게 제대로 전달하는가? 협력에 실패하면 잘못된 주에 호텔이 예약되는 상황이 발생할 수 있다.
② 계획을 잘 따랐는가? 항공편을 먼저 예약한 다음 호텔을 예약하는 것이 계획인데 ‘호텔 에이전트’가 항공편 확정 전에 객실을 예약하려 한다면 계획에서 벗어난 것이다. 또한 에이전트가 “완벽한” 렌터카를 끝없이 검색하며 다음 단계로 넘어가지 못하는 등 정체 상태에 빠지는지도 확인해야 한다.
③ 각 작업에 적합한 에이전트가 선택되고 있는가? 사용자가 여행지의 날씨를 물어보면 시스템은 실시간 데이터를 제공하는 전문 ‘날씨 에이전트’를 사용해야 한다. “여름에는 보통 덥습니다” 와 같은 일반적인 답변을 내놓는 ‘일반 지식 에이전트’를 대신 사용한다면, 해당 작업에 잘못된 도구를 선택한 것이다.
④ 에이전트를 추가하면 성능이 좋아지는가? 팀에 새로운 ‘레스토랑 예약 에이전트’를 추가했을 때 전체 여행 계획이 더 좋아지고 효율도 높아지는가? 아니면 충돌이 발생하고 시스템이 느려져 확장성 문제를 드러내는가?
에이전트에서 고도화된 계약자로
최근에는 단순 AI 에이전트를 고도화된 “계약자(contractor)” 로 발전시키는 방안이 제안되었습니다(Agent Companion, Gulli et al.).
확률적이고 신뢰하기 어려울 때가 많은 시스템에서 벗어나, 복잡하고 높은 리스크를 수반하는 환경에 맞게 설계된 보다 결정론적이고 책임 추적이 가능한 시스템으로 전환하자는 것이다.
문제 인식은 이렇습니다. 오늘날의 일반적인 AI 에이전트는 짧고 명세가 부족한 지시에 따라 동작하므로 간단한 시연에는 적합하지만, 모호함이 곧 실패로 이어지는 프로덕션 환경에서는 취약합니다. “계약자” 모델은 사용자와 AI 사이에 엄격하고 형식화된 관계를 수립하는데, 이는 인간 세계의 법적 서비스 계약과 흡사합니다.
첫 번째 기둥 — 형식화된 계약 (Formalized Contract)
작업의 단일 정보 원천(single source of truth) 역할을 하는 상세한 명세입니다. 단순한 프롬프트를 훨씬 넘어서는 개념입니다.
| 내용 | |
|---|---|
| 에이전트 프롬프트 | “지난 분기 매출을 분석하라” |
| 계약자 계약 | “2025년 1분기 유럽 시장 매출을 분석한 20페이지 분량의 PDF 보고서를 작성하되, 5개의 구체적인 데이터 시각화, 2024년 1분기 대비 비교 분석, 그리고 포함된 공급망 교란 데이터 세트에 기반한 위험 평가를 포함할 것” |
┌──────────────┐
│ 계약 제출됨 │
└───────┬──────┘
▼
┌──────────────────┐
│ 계약 평가 │
│ 실현 가능성, │
│ 비용 및 기간 평가 │
└───┬──────────┬───┘
계약 수정 요청됨 │ │ 계약 수락됨
▼ ▼
┌──────────────┐ ┌──────────────────┐
│ 계약 수정 │◀─┤ 계약 실행 │
│ 계약 수정 사항 │수정│ 계획 생성. 작업 실행│
│ 제안(모호성, │제안│ 하위 계약 생성. │
│ 비용 등) │ └────────┬─────▲───┘
└──────────────┘ │ │
▼ │
┌────────────────┴──┐
│ 작업 해결 │
│ 후보 생성. 후보 검토.│
│ 후보 점수 매기기. │
│ 후보 순위 매기기. │
│ 후보 진화. │
└─────────┬─────────┘
▼
┌──────────────┐
│ 계약 산출물 │
└──────────────┘
그림 19.2 에이전트 간 계약 실행 예시
두 번째 기둥 — 협상과 피드백의 동적 순환 과정 (Dynamic Lifecycle)
계약은 정적인 명령이 아니라 대화의 시작이다. 계약자 에이전트는 초기 조건을 분석하고 협상할 수 있다.
에이전트가 접근할 수 없는 특정 독점 데이터 소스를 사용하라는 계약 조건이 있다면, “지정된 XYZ 데이터베이스에 접근할 수 없습니다. 접속에 필요한 정보를 제공하거나, 데이터 세분화 수준이 다소 달라질 수 있는 대체 공개 데이터베이스의 사용을 승인해 주십시오” 라는 피드백을 반환할 수 있습니다. 이 협상 단계에서는 에이전트가 모호한 점이나 잠재적 위험을 지적할 수도 있으며, 이를 통해 실행 전에 오해를 해소하여 비용이 큰 실패를 방지하고 최종 결과물이 사용자의 실제 의도에 정확히 부합하도록 합니다.
세 번째 기둥 — 품질 중심 반복 실행 (Quality-Focused Iterative Execution)
저지연 응답에 최적화된 에이전트와 달리, 계약자는 정확성과 품질을 우선시합니다. 자체 검증과 교정의 원칙에 따라 동작합니다.
코드 생성 계약의 경우 에이전트가 단순히 코드를 작성하는 데 그치지 않습니다. 여러 알고리즘적 접근법을 생성한 뒤 계약 내에 정의된 단위 테스트 모음에 대해 컴파일하고 실행하며, 각 솔루션을 성능·보안·가독성 등의 지표로 점수를 매기고, 모든 검증 기준을 통과한 버전만 제출합니다.
계약 명세가 충족될 때까지 자신의 작업을 생성·검토·개선하는 이 내부 루프야말로 결과물에 대한 신뢰를 구축하는 핵심 요소라 할 수 있다.
네 번째 기둥 — 하위 계약을 통한 계층적 분해 (Hierarchical Decomposition via Subcontracts)
상당히 복잡한 작업의 경우, 주 계약자 에이전트가 프로젝트 관리자 역할을 맡아 주요 목표를 더 작고 관리 가능한 하위 작업으로 나눌 수 있습니다. 이를 위해 새로운 형식적 “하위 계약”을 생성합니다.
주 계약: "이커머스 모바일 애플리케이션 구축"
├─ 하위 계약: UI/UX 설계
├─ 하위 계약: 사용자 인증 모듈 개발
├─ 하위 계약: 제품 데이터베이스 스키마 생성
└─ 하위 계약: 결제 게이트웨이 통합
각 하위 계약은 자체 산출물과 명세를 갖춘 완전하고 독립적인 계약이며, 다른 전문 에이전트에게 할당할 수 있습니다. 이러한 구조적 분해를 통해 시스템은 방대하고 다면적인 프로젝트를 매우 체계적이고 확장 가능한 방식으로 수행할 수 있으며, 이는 AI가 단순한 도구에서 자율적이고 신뢰할 수 있는 문제 해결 엔진으로 전환되는 과정을 보여 줍니다.
구글 ADK
구글 ADK를 활용한 에이전트 평가는 세 가지 방법으로 수행할 수 있습니다.
| 방법 | 용도 |
|---|---|
웹 기반 UI (adk web) |
대화형 평가와 데이터 세트 생성. 대화형 세션을 만들고 기존 또는 새로운 평가 세트에 저장할 수 있게 해 주며, 평가 상태를 표시한다 |
| pytest 연동 | 테스트 파이프라인에 통합. AgentEvaluator.evaluate 를 호출하여 에이전트 모듈과 테스트 파일 경로를 지정하는 방식으로, 테스트 파일을 통합 테스트의 일부로 실행할 수 있게 한다 |
명령행 인터페이스 (adk eval) |
정기적인 빌드 생성 및 검증 프로세스에 적합한 자동화 평가. 에이전트 모듈 경로와 평가 세트 파일을 지정하며, 구성 파일을 지정하거나 상세 결과를 출력하는 옵션을 제공한다. 더 큰 평가 세트 안에서 특정 평가 항목만 선택해 실행하려면, 평가 세트 파일 이름 뒤에 쉼표로 구분하여 나열하면 된다 |
정리
평가와 모니터링이란 무엇인가
에이전틱 시스템과 LLM은 복잡하고 변화하는 환경에서 동작하며, 시간이 지남에 따라 성능이 저하될 수 있습니다. 확률적이고 비결정론적인 특성 때문에 전통적인 소프트웨어 테스트만으로는 신뢰성을 확보하기 어렵습니다. 상황이 유동적으로 바뀌는 멀티 에이전트 시스템을 평가하는 작업은 만만찮은 과제인데, 시스템과 환경이 끊임없이 변하므로 적응형 테스트 방법(에이전트와 환경의 변화에 맞춰 테스트 케이스와 평가 기준을 계속 갱신하는 방식)과, 개별 성능을 넘어 협업 성공을 측정할 수 있는 정교한 지표를 개발해야 하기 때문입니다. 실제로 배포 후 데이터 드리프트, 예기치 않은 상호작용, 도구 호출, 의도한 목표 이탈 등의 문제가 발생할 수 있습니다.
왜 사용하는가?
표준화된 평가·모니터링 프레임워크는 지능형 에이전트를 운영하는 중에도 계속 안정적인 성능을 유지하는지 체계적으로 평가하고 보장하는 방법을 제공합니다. 여기에는 정확도, 지연 시간, LLM 토큰 사용량 같은 자원 소모를 측정하는 명확한 지표 정의가 포함됩니다. 또한 추론 과정을 이해하기 위한 에이전트 활동 궤적 분석, 미묘한 정성적 평가를 위한 LLM 심사자 활용 등 고급 기법도 포함됩니다. 피드백 순환 구조와 보고 체계를 마련하면 지속적인 개선, A/B 테스팅, 이상 징후나 성능 드리프트 탐지가 가능해집니다.
언제 사용해야 하는가?
이 패턴은 실시간 성능과 신뢰성이 중요한 라이브 프로덕션 환경에 에이전트를 배포할 때 사용합니다. 또한 에이전트나 기저 모델의 서로 다른 버전을 체계적으로 비교하여 개선을 이끌어내야 할 때, 규정 준수·안전·윤리 감사가 요구되는 규제 대상이나 높은 리스크를 수반하는 영역에서 운영할 때도 적합합니다. 데이터나 환경 변화(드리프트)로 인해 성능이 시간이 지남에 따라 저하될 수 있는 경우나, 활동 궤적(동작의 연쇄)과 유용성 같은 주관적 출력 품질을 포함한 복잡한 에이전틱 행동을 평가해야 할 때에도 이 패턴을 활용합니다.
평가와 모니터링 패턴 개요도
┌───────────┐ ┌─────────────┐
│ 프롬프트 ├─────▶│ 에이전트 │◀──────────────┐
└─────▲─────┘ └──────┬──────┘ │
│ │ │
┌─────┴─────┐ ┌──────▼──────┐ ┌──────────┴──┐ ┌────────┐
│ 사용자 │◀─────┤ 출력 ├──▶│ 관측 지표 ├──▶│ 경보 │
└───────────┘ └─────────────┘ └─────────────┘ └────────┘
그림 19.4 평가와 모니터링 디자인 패턴
핵심은 관측 지표가 경보로 이어지고, 그 신호가 다시 에이전트로 되돌아가는 순환 구조입니다. 측정은 보고서로 끝나지 않고 개선으로 이어져야 합니다.
핵심 정리
- 지능형 에이전트의 평가는 전통적인 테스트를 넘어서, 실제 운영 환경에서 에이전트의 효과, 효율, 요구사항 준수 여부를 지속적으로 측정하는 것이다.
- 실무 적용 분야로는 실 운영 시스템 성능 추적, 개선을 위한 A/B 테스팅, 규정 준수 감사, 행동 드리프트나 이상 탐지가 있다.
- 기본적인 에이전트 평가는 응답 정확도 측정에서 출발하지만, 실제 시나리오에서는 지연 시간 모니터링이나 LLM 기반 에이전트의 토큰 사용량 추적과 같은 보다 정교한 지표가 요구된다.
- 에이전트가 거치는 단계의 연쇄인 활동 궤적은 평가에서 매우 중요한데, 이는 실제 동작을 이상적인 정답 기준 경로와 비교하여 오류와 비효율을 식별할 수 있기 때문이다.
- ADK는 단위 테스트를 위한 개별 테스트 파일과 통합 테스트를 위한 포괄적인 평가 세트 파일을 통해 구조화된 평가 방법을 제공하며, 두 방법 모두 에이전트가 보여야 할 행동을 정의한다.
- 에이전트 평가는 웹 기반 UI, CI/CD 통합을 위한 pytest 연동, 자동화된 워크플로를 위한 명령행 인터페이스를 통해 실행할 수 있다.
- 복잡하고 높은 리스크를 수반하는 작업에서 AI를 신뢰할 수 있게 만들려면, 단순한 프롬프트에서 벗어나 검증 가능한 산출물과 범위를 정확하게 정의하는 형식적 “계약”으로 전환해야 한다. 이러한 구조화된 합의를 통해 에이전트는 협상하고, 모호한 점을 해소하며, 자신의 작업을 반복 검증할 수 있어, 예측하기 어려운 도구에서 책임 추적이 가능하고 신뢰할 수 있는 시스템으로 탈바꿈한다.
마치며
AI 에이전트를 효과적으로 평가하려면 단순한 정확도 점검을 넘어 변화하는 환경에서 에이전트 성능을 지속적이고 다면적으로 평가해야 합니다. 여기에는 지연 시간이나 자원 소모 같은 지표의 실질적인 모니터링뿐 아니라, 에이전트의 활동 궤적을 통한 정교한 의사 결정 과정 분석도 포함됩니다.
유용성 같은 미묘한 품질을 평가하는 데는 LLM 심사자 같은 새로운 방법이 점차 중요해지고 있으며, 구글 ADK 같은 프레임워크는 단위 테스트와 통합 테스트를 위한 구조화된 도구를 제공합니다. 멀티 에이전트 시스템에서는 과제가 더 심화되는데, 평가의 초점이 협업 성공과 효과적인 협력 측정으로 이동하기 때문입니다.
미션 크리티컬 애플리케이션에서 신뢰성을 확보하기 위해, 단순한 프롬프트 기반 에이전트에서 형식적 합의에 따라 동작하는 고도화된 “계약자”로 패러다임이 전환되고 있습니다.
이 계약자 에이전트는 명시적이고 검증 가능한 조건에 따라 동작하여 협상하고, 작업을 분해하고, 엄격한 품질 기준을 충족하도록 자신의 작업을 자체 검증한다. 이러한 구조적 접근을 통해 에이전트는 예측하기 어려운 도구에서 복잡하고 높은 리스크를 수반하는 작업을 처리할 수 있는 책임 추적 가능한 시스템으로 전환된다. 결국 이 발전은 정교한 에이전틱 AI를 미션 크리티컬 영역에 배포하는 데 필요한 신뢰 형성에 핵심적인 역할을 한다.