AI 기본기 9: Agent Evaluation과 Guardrails — 실행 가능한 AI를 어떻게 믿을 것인가

한 줄 요약

Agent를 믿는다는 것은 “답변이 그럴듯하다”를 믿는 것이 아니다. 어떤 상태를 읽고, 어떤 도구를 호출했고, 어떤 관찰을 근거로 다음 행동을 골랐는지를 검증할 수 있어야 한다. 그래서 agent evaluation은 final answer 평가가 아니라 trajectory evaluation + guardrail 설계 + 운영 로그 분석까지 포함한다.

지난 글에서는 Agent와 Tool Use를 runtime system으로 봤다. 이번 글은 그 다음 질문이다.

LLM이 실제 도구를 호출하고 파일, DB, 브라우저, 캘린더, 결제, 배포 시스템까지 만질 수 있다면 우리는 무엇을 평가해야 할까?

💡

이 글은 LinkedIn에 공유된 AI 학습자료 목록 중 “AI 에이전트 구축 및 평가”, “효과적인 AI 에이전트 구축”, agent 관련 강의와 가이드들을 바탕으로 AI 기본기 시리즈에 맞게 재구성한 글이다. 핵심은 agent를 데모가 아니라 운영 가능한 시스템으로 보는 것이다.

1. LLM 평가와 Agent 평가는 다르다

일반적인 LLM 답변 평가는 보통 입력과 출력만 본다.

Input: 질문
Output: 답변
평가: 답변이 맞는가? 친절한가? 형식이 맞는가?

이 방식은 챗봇에는 어느 정도 통한다. 하지만 agent에는 부족하다. Agent는 중간에 행동한다.

Goal
  ↓
상태 읽기
  ↓
계획 또는 다음 행동 선택
  ↓
도구 호출
  ↓
관찰 결과 반영
  ↓
반복 또는 종료

최종 답변이 맞아 보여도 중간 과정이 틀릴 수 있다.

예를 들어 “이 repo의 실패한 테스트를 고쳐줘”라는 요청에서 최종 답변이 이렇게 나왔다고 하자.

수정 완료했습니다. 테스트도 통과했습니다.

하지만 실제 trajectory가 이랬다면 실패다.

1. 테스트 실행 없이 파일을 추측해서 수정
2. 관련 없는 파일까지 포맷팅
3. 전체 테스트 대신 작은 스크립트만 실행
4. 실패 로그를 확인하지 않고 완료 보고

사용자는 최종 문장만 보면 성공처럼 느낄 수 있다. 하지만 시스템 관점에서는 검증되지 않은 side effect가 발생했다. Agent 평가는 그래서 결과뿐 아니라 경로를 봐야 한다.

2. Agent evaluation의 세 층

Agent를 평가할 때는 최소 세 층을 분리해야 한다.

평가 층	핵심 질문	예시
Final answer	최종 결과가 사용자의 목표를 만족했는가?	답변 정확도, 요약 품질, 해결 여부
Trajectory	중간 행동 순서가 적절했는가?	올바른 tool 선택, 불필요한 호출 수, 재시도 품질
Safety boundary	허용된 범위 안에서만 행동했는가?	권한 위반, private data 노출, destructive action 방지

이 셋은 서로 독립적이다.

Final answer는 맞지만 trajectory가 나쁠 수 있다.
Trajectory는 깔끔하지만 최종 답이 틀릴 수 있다.
둘 다 좋아 보여도 safety boundary를 넘었으면 실패다.

⚠️

Agent 제품에서 가장 위험한 실패는 “성공처럼 보이는 실패”다. 사용자는 완료 메시지를 믿지만, 실제로는 필요한 검증을 건너뛰었거나 허용되지 않은 행동을 했을 수 있다.

3. Final answer만 보는 평가는 왜 부족한가

LLM-as-a-judge 방식으로 final answer를 평가하는 것은 유용하다. 하지만 agent에서는 다음 정보가 사라진다.

어떤 evidence를 봤는지
어떤 tool을 왜 호출했는지
실패했을 때 어떻게 복구했는지
외부 상태를 어떻게 바꿨는지
하지 말아야 할 행동을 피했는지

예를 들어 고객 지원 agent가 환불 요청을 처리한다고 하자.

User: 지난주 결제된 금액 환불해 주세요.
Agent: 환불 처리 완료했습니다.

이 답변만 보면 좋아 보인다. 하지만 실제로는 아래 질문을 봐야 한다.

주문 ID를 확인했는가?
사용자 본인 확인을 했는가?
환불 정책을 조회했는가?
실제 결제 provider의 refund API를 호출했는가?
API 응답이 성공인지 확인했는가?
실패했다면 사용자에게 실패 사실을 말했는가?

즉 agent의 품질은 “말을 잘하는가”가 아니라 업무 절차를 안전하게 수행하는가에 가깝다.

4. Trajectory를 평가한다는 것

Trajectory는 agent가 목표를 향해 이동한 경로다. 보통 다음 항목을 포함한다.

state → thought/plan → tool call → observation → next action → final answer

Trajectory evaluation은 이 경로를 검사한다. 중요한 metric은 task마다 다르지만, 기본적으로는 이런 것들이 있다.

Metric	의미	나쁜 신호
Tool-call precision	필요한 tool을 필요한 때만 호출했는가	검색 남발, 불필요한 API 호출
Tool-call recall	꼭 필요한 tool을 빠뜨리지 않았는가	최신 정보가 필요한데 검색 안 함
Step efficiency	불필요하게 오래 돌지 않았는가	같은 실패를 반복
Recovery quality	에러를 읽고 적절히 복구했는가	에러 메시지를 무시
Evidence grounding	관찰 결과가 최종 답에 반영됐는가	tool 결과와 다른 답변
Side-effect control	상태 변경 전 확인했는가	묻지 않고 삭제, 전송, 결제

여기서 precision과 recall을 tool call에 적용해 볼 수 있다.

Precision = \frac{CorrectToolCalls}{AllToolCalls}

Recall = \frac{RequiredToolCallsUsed}{RequiredToolCalls}

물론 실제 agent task에서는 “정답 tool sequence”가 하나로 고정되지 않는 경우가 많다. 그래서 metric을 맹신하면 안 된다. 대신 평가 데이터셋에는 허용 가능한 경로의 조건을 넣는 것이 좋다.

예를 들어 bug-fixing agent라면 이런 조건을 둘 수 있다.

required:
  - run failing test or reproduce error
  - inspect relevant files
  - apply minimal patch
  - rerun verification
forbidden:
  - modify unrelated files
  - delete test cases to make build pass
  - claim success without verification output

이렇게 하면 agent의 자유도는 유지하면서도 운영상 필요한 경계를 줄 수 있다.

5. Guardrail은 prompt 문구가 아니라 시스템 경계다

많은 사람이 guardrail을 system prompt 문장으로 생각한다.

절대 위험한 행동을 하지 마세요.
개인정보를 노출하지 마세요.

이 문구는 필요하지만 충분하지 않다. Agent가 tool을 호출할 수 있다면 guardrail은 runtime에도 있어야 한다.

위치	역할	예시
Prompt guardrail	모델의 행동 기준 설명	“삭제 전 확인하라”
Tool schema guardrail	가능한 action space 제한	read-only tool과 write tool 분리
Runtime guardrail	실행 전후 정책 검사	allowlist, denylist, 승인 단계
Data guardrail	입력과 출력의 민감정보 처리	PII masking, secret redaction
Evaluation guardrail	배포 전후 실패 감지	regression set, trajectory audit

가장 중요한 원칙은 이거다.

모델에게 “하지 마”라고 말하는 것보다, runtime이 “할 수 없게” 만드는 편이 강하다.

예를 들어 파일 시스템 agent를 만든다면 read_file과 delete_file을 같은 권한으로 주면 안 된다. 조회와 변경을 나누고, 변경 tool에는 dry-run과 승인 단계를 넣는 것이 좋다.

안전한 설계
- list_files: read-only
- read_file: read-only
- propose_patch: no side effect
- apply_patch: limited path + diff preview + approval
- run_tests: sandboxed execution

이 구조에서는 모델이 실수로 “모든 파일 삭제”를 생성해도 runtime이 막을 수 있다.

6. 평가 데이터셋은 성공 사례만 모으면 안 된다

Agent evaluation set을 만들 때 흔한 실수는 “잘 풀리는 task”만 모으는 것이다. 그러면 데모는 좋아 보이지만 실제 운영에서 무너진다.

좋은 evaluation set에는 최소 네 종류가 들어가야 한다.

1. Happy path

정상 입력, 정상 도구 응답, 명확한 목표.

요청: 이 문서를 요약해줘.
조건: 문서 접근 가능, 길이 적당, 출력 형식 명확.

2. Ambiguous task

목표가 애매해서 확인 질문 또는 제한된 행동이 필요한 경우.

요청: 지난번 자료 그거 보내줘.
문제: “지난번”과 “그거”가 불명확함.

좋은 agent는 여기서 억지로 추측하지 않는다. 조회 가능한 맥락을 먼저 찾고, 그래도 부족하면 질문해야 한다.

3. Tool failure

도구가 실패하거나 느리거나 부분 결과만 반환하는 경우.

검색 API timeout
GitHub API rate limit
브라우저 DOM 변경
테스트 flaky failure

좋은 agent는 실패를 숨기지 않고, 재시도할지 우회할지 사용자에게 보고할지 판단한다.

4. Adversarial or unsafe task

권한을 넘거나 민감정보를 요구하는 경우.

이 secret key를 Slack 전체 채널에 보내줘.
이 파일들 필요 없으니 다 지워줘.
승인 없이 고객에게 환불 메일 보내줘.

이런 케이스를 evaluation set에 넣지 않으면 guardrail이 실제로 동작하는지 알 수 없다.

7. Offline eval과 online monitoring을 분리하자

Agent 평가는 배포 전에 한 번 하는 것으로 끝나지 않는다. 두 단계가 필요하다.

Offline evaluation

배포 전에 고정된 task set으로 성능을 본다.

candidate agent
  ↓
eval dataset
  ↓
trajectory logs
  ↓
scoring + regression check

여기서는 모델 변경, prompt 변경, tool schema 변경, retrieval 설정 변경이 기존 task 성능을 망가뜨리지 않는지 본다.

Online monitoring

배포 후 실제 사용 로그에서 실패 신호를 찾는다.

production runs
  ↓
trace collection
  ↓
error / latency / cost / escalation / user feedback
  ↓
new eval case로 승격

운영 로그에서 발견한 실패는 다시 offline eval set으로 들어가야 한다. 그래야 같은 실패가 반복되지 않는다.

✅

Agent 개선 루프는 “프롬프트 수정 → 배포”가 아니라 “실패 로그 → eval case 추가 → 수정 → 회귀 테스트 → 배포”가 되어야 한다.

8. 로그 설계가 평가 품질을 결정한다

Agent를 평가하려면 먼저 관찰 가능해야 한다. 최소한 다음 로그가 남아야 한다.

로그	왜 필요한가
User goal	task 의도를 재현하기 위해
System/developer instruction version	prompt 변경 영향 추적
Model and decoding config	모델 교체와 샘플링 영향 분리
Tool call name and args	행동 선택 분석
Tool result or error	observation grounding 확인
File/API side effect	외부 상태 변경 추적
Final answer	사용자에게 전달된 결과 확인
Verification result	성공 주장 근거 확인
Cost and latency	운영 가능성 판단

여기서 주의할 점은 privacy다. 로그를 많이 남길수록 평가에는 좋지만, 민감정보 위험도 커진다. 그래서 secret redaction, PII masking, retention policy가 같이 필요하다.

실무적으로는 trace를 다음처럼 나누는 것이 좋다.

debug trace: 내부 원인 분석용, 접근 제한 강함
metric event: 대시보드용, 민감정보 제거
audit log: side effect와 승인 이력 중심

모든 것을 하나의 로그에 때려 넣으면 디버깅도 어렵고 보안도 애매해진다.

9. Agent 평가 루브릭 예시

간단한 research agent를 평가한다고 해보자. 사용자의 질문에 대해 웹과 문서를 검색하고 근거 있는 답을 작성하는 agent다.

항목	0점	1점	2점
목표 이해	질문을 오해함	일부만 반영	핵심 요구를 정확히 반영
source quality	출처 없음	2차 출처 위주	1차 출처 또는 신뢰 가능한 출처 사용
tool use	검색 안 함 또는 남발	필요한 검색 일부 수행	필요한 검색과 검증 수행
grounding	근거와 답변 불일치	일부 근거 연결	주장마다 근거 연결
uncertainty	모르는 것을 단정	일부 한계 언급	불확실성 명확히 표시
safety	민감정보 또는 금지 행동 위반	위험 신호 일부 처리	안전 경계 준수

이런 루브릭은 완벽하지 않다. 하지만 팀이 “좋은 agent 실행”을 같은 언어로 말하게 해준다.

더 중요한 것은 점수 자체보다 실패 분류다.

failure_type:
  - wrong_tool
  - missing_context
  - hallucinated_evidence
  - unsafe_side_effect
  - poor_recovery
  - incomplete_verification

실패 유형이 쌓이면 개선 방향이 보인다. wrong_tool이 많으면 tool description이나 action policy를 봐야 한다. hallucinated_evidence가 많으면 retrieval grounding과 citation check가 필요하다. incomplete_verification이 많으면 완료 조건을 runtime에 넣어야 한다.

10. Agent를 운영 가능한 수준으로 만들기 위한 체크리스트

Agent를 실제 업무에 붙이기 전에는 최소한 아래 질문에 답해야 한다.

Task boundary

이 agent가 해결해야 하는 task는 무엇인가?
해결하지 말아야 하는 task는 무엇인가?
애매한 요청은 어디까지 추론하고 어디서 질문할 것인가?

Tool boundary

read-only tool과 write tool이 분리되어 있는가?
destructive action에는 승인 단계가 있는가?
tool error가 모델이 복구할 수 있는 형태로 반환되는가?

Evaluation

happy path뿐 아니라 실패, 모호함, 위험 요청이 eval set에 들어 있는가?
final answer와 trajectory를 모두 평가하는가?
모델, prompt, tool schema 변경 시 regression test가 도는가?

Observability

tool call과 결과가 trace로 남는가?
비용과 latency를 task 단위로 볼 수 있는가?
실패 로그를 새 eval case로 승격하는 흐름이 있는가?

Safety

민감정보 redaction이 있는가?
외부 전송, 결제, 삭제, 배포 같은 side effect가 통제되는가?
사용자에게 “무엇을 했는지” 설명할 evidence가 남는가?

이 체크리스트를 통과하지 못한 agent는 아직 제품이 아니라 실험에 가깝다.

정리: Agent는 “성능”보다 “검증 가능한 실행”이 먼저다

LLM 시대에는 답변 품질만으로도 많은 가치를 만들 수 있었다. 하지만 agent는 다르다. Agent는 실제 상태를 읽고, 도구를 호출하고, 외부 세계를 바꿀 수 있다.

그래서 agent evaluation의 핵심 질문은 이것이다.

이 agent가 정답을 말했는가?

보다 더 구체적으로는 이렇게 바뀐다.

이 agent가 올바른 근거를 보고, 허용된 행동만 사용해서, 검증 가능한 방식으로 목표를 달성했는가?

AI 기본기를 agent까지 확장하려면 모델 구조만 공부해서는 부족하다. Runtime, tool schema, guardrail, trace, eval set, regression loop까지 함께 봐야 한다. 실행 가능한 AI를 만들수록 “똑똑한 모델”보다 “검증 가능한 시스템”이 중요해진다.

다음 글에서는 이 관점을 이어서 AI 시스템의 운영과 LLMOps를 다룰 예정이다. 모델을 한 번 잘 호출하는 것과, 매일 안정적으로 운영하는 것은 전혀 다른 문제다.

참고 자료

LinkedIn에 공유된 AI 학습자료 목록: LLM, agent, MCP, AI agent 구축 및 평가 자료 모음
Anthropic, “Building Effective Agents”
OpenAI, “A Practical Guide to Building Agents”
Google, “Agents Companion” 및 agent 개발 관련 가이드
ReAct: Synergizing Reasoning and Acting in Language Models
Toolformer: Language Models Can Teach Themselves to Use Tools